[cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2

[Yngve N. Pettersen (Developer Opera Software ASA)]

On Sun, 14 Oct 2012 01:23:55 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

>> The only issue with this specific example is with regards to a
>> 1024-bit Debian weak key, but this, along with other such "security
>> failures", are checks that are being jointly implemented by both CAs
>> (at time of issuance) and Browsers (at time of verification), as a
>> form of defense in depth. So even under a DNSSEC/DANE regime, there is
>> still defense against this class of errors.
>
> I know of no browser that's building in Debian weak key checks. That's  
> best done at the CA, because then we can tell the customer about it.  
> What will a browser do? Tell the user to tell the web site operator that  
> their key is weak?

Just to add to the above:

What to do isn't the real question (fatal error, IMO), where to store the  
information about the weak keys is the big question: The OpenSSL blacklist  
package from Debian is 12 MB (6 MB compressed) covering 1024 and 2048 bit  
keys (Opera's Windows installer download is 9-12 MB, that is, the weak  
list would increase the download size by 50-70%).

It is IMO not practical for a client to check for Debian Weak Keys using a  
downloaded/shipped list, and calculating them is also not going to be  
practical either.

Either the website owner or the CA will have to check for weak keys. That  
will become even more true as more weak generation methods are discovered.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************