[cabfpub] FW: [cabfquest] Key Size Exception

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Thu Mar 7 03:21:41 UTC 2013


I would only point out this - we should not let the perfect be the enemy of the very, very, very good.

The BRs and EV Guidelines represent a huge leap by the industry in raising standards - something I have not seen among other main players in the internet ecosystem (common, enforceable, auditable standards) that these players are willing to impose on themselves.

Many of the BRs and EVGLs are simply statements of good practices that we want to standardize and require - but for many of the BRs, there is no magic in a particular standard or deadline - rather, it's a matter of judgment, taking steps to improve the ecosystem, and heading off a practice we see as a potential problem in the future.  (Have any 1024 bit certs been proven to be hacked yet?)

In taking the major step of adopting BRs to improve the ecosystem,  it would be an error to ignore special transition cases where there is no particular showing that the transition case is too dangerous to allow.  There are customers with major legacy systems that can't quickly be modified to deal with new requirements or prohibitions, and these customers were never consulted or informed about the BRs.  They will typically discover the "problem" with their legacy system when they try to renew a cert with only 3 weeks left before expiration and are told they can't get one.

Few customers can completely modify major legacy systems with such short notice, and I don't think the Forum should adopt an absolutist position in every case (again, especially when the requirements of the BRs, adopted only last July 1, have not yet been widely disseminated to general users - look at the surprise among customers on the prohibition against internal server name and IP address certs.)  We need to take a more practical approach, in my opinion, to get users to full compliance with legacy applications as quickly as possible.

Finally, Ryan, no one has ever suggested the Forum - or the BRs - will control any browser's root program requirements.  However, the Forum (including both browsers and CAs) does control what's in the BRs - including transition rules like we already have in BR 9.4.  In my view, the Forum could amend the BRs to include additional transition rules if needed for legacy systems (short-term, narrow, and auditable).

If any browser objected to a BR transition rule for a legacy system, the browser could of course make it clear in its root program that it would not allow a CA to follow that particular BR transition rule - all browsers retain that right (but it's not really in the spirit of the Forum or the BRs.).

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, March 06, 2013 2:56 PM
To: Eddy Nigg (StartCom Ltd.)
Cc: public at cabforum.org
Subject: Re: [cabfpub] FW: [cabfquest] Key Size Exception

On Wed, Mar 6, 2013 at 2:48 PM, Eddy Nigg (StartCom Ltd.) <eddy_nigg at startcom.org<mailto:eddy_nigg at startcom.org>> wrote:

On 03/07/2013 12:23 AM, From Ryan Sleevi:
I think regardless of what this Forum decides, Browsers/Root Stores will continue to operate their programs independently. Granting exceptions through language in the BR certainly can provide a framework, but if no root store respects or accepts that framework, it serves no end. Likewise, this Forum may decide NOT to include particular language in the BRs, but Browsers/Root Stores that are committed to moving the security standard higher may decide to independently impose such restrictions, for the protection and safety of their users.


Right, but for the record here we are talking about "downgrading" or introducing an exception. Even if software vendors would agree to it, I believe such certificates would be not in compliance with the BR - until that has been changed and approved for such an exception.

Therefor I believe the software vendors acceptance is also limited in this respect.

Regards



Signer:

Eddy Nigg, COO/CTO



StartCom Ltd.<http://www.startcom.org>

XMPP:

startcom at startcom.org<mailto:startcom at startcom.org>

Blog:

Join the Revolution!<http://blog.startcom.org>

Twitter:

Follow Me<http://twitter.com/eddy_nigg>





_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

Correct - without changes to the BRs, such certs are definitely not compliant with the BRs.

Whether or not a root store accepts them (compliant or not) is a separate and independent question, that gets to the heart of the matter.

Watering down the BRs to make such certs 'acceptable' (by virtue of exceptions) only serves to weaken the BRs, and such weakening may or may not be acceptable to root programs.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130307/e399f2d6/attachment-0003.html>


More information about the Public mailing list