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

[Yngve Nysaeter Pettersen]

On Fri, 12 Oct 2012 02:31:44 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

> Colleagues,
>
> I've updated the document again to include feedback from Kathleen. I  
> changed the title back to Guidelines as opposed to Requirements, and  
> changed a lot of musts to shoulds.
>
> Please look it over again, especially browser members. If we have  
> consensus on this version, I'll advance it towards a ballot. Thanks,

Sectiion 3: Should the EVSSL reference be so specific about the version,  
or is it possible to reference the most recent version instead?

Section 5: Does minimum requirements refer to the BR or EV guidelines?  EV  
was minimum requirements at the time of the first document, but we now  
have the BR as a new minimum. I would suggest clarifying this section.

Section 10:

   - What about Triple-DES? It may have 168 bit key material, but as far as  
I know it can be argued that its real strength is 112 bit, when a  
meet-in-the-middle brute force attack is used.

   - Ephemeral Diffie-Hellman (DHE) cipher suites: Most servers use 1024  
bit, but a large number use 768 bit (in particular captive portals;  
example iBahn); see [1].     Should DHE keysize be included in the  
determination of EV? What should the client do if the DHE keysize is too  
low (at present Opera retries with reordered cipher suite sequence if the  
keysize is less than 1024, but disabling the cipher suites may be better,  
since some servers ignore the reordering; this could be done for EV with  
too weak DHE). If so, what is "too low"? (IMO  either less than 2048 bit  
or less than the site certificate keysize). Of course, an issue here is  
that this key size may be controlled by the server's code, not the  
configuration.


Section 12:

   - Perhaps it need to be made clear that the policy identifier (EV-OID)  
does not match if the non-root issuing CA certificate(s) of the chain does  
not contain either the EV-OID itself, or the any-policy OID?

Section 13:

   - "should not be treated as trusted certificates" +1

   - POST is only relevant for OCSP;  it might be an idea to split OCSP  
 from CRL at this point.

   - Following redirects can cause trouble when dealing with captive  
portals. Opera does follow redirects for CRLs, but not OCSP.

   - I think "cache-refresh" should not be used, instead use  
"cache-expiration"

   - Maybe it should be specified that the client should not send or accept  
HTTP cookies when retrieving revocation information? (Opera does not send  
or accept cookie for CRL/OCSP/AIA)



[1]
 From this weeks run of the TLS prober:

All sites:

       0 (not used) | 401706
                512 |    575
                768 |   1200
               1024 | 317362
               1536 |      1
               2048 |    427
               2049 |      1

EV sites

                  0 |  5877
                512 |    10
                768 |     4
               1024 |  2795
               2048 |     4


-- 
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
********************************************************************