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

Rick Andrews Rick_Andrews at symantec.com
Thu Oct 25 10:51:50 MST 2012


Brian,

We discussed this on our call today, and Gerv explained that your objections are related to this document's application to mobile browsing in offline mode. I said that I believed that this document covered what the application should do when it performs the SSL handshake (chain checking, status checking, etc.), and that offline browsing was a special case that this document wouldn't apply to. To clarify, I propose adding this to Section 5 Introduction:

"These guidelines are intended to cover behavior of the application when establishing a new SSL/TLS connection with a website. They do not apply to resumed sessions, offline browsing, or any other case in which an SSL handshake is not performed."

I agree with your second point about not adding to what RFC 5280 says. The original document contained much of that language; I only added "try the GET method first". I propose cutting down Section 13, Revocation Checking, to this:

"Applications should confirm that the EV certificate has not been revoked before accepting it. This includes verifying the revocation status of any intermediate CA certificates, in conformance with [RFC 5280] Section 6.1.3. That section indicates that for each certificate in the chain except for the trusted root certificate, the client must check that the certificate has not been revoked.

Certificates for which confirmation cannot be obtained should not be granted the EV treatment (see Section 14, EV Treatment, below), and should not be treated as trusted certificates.

The application should follow HTTP redirects and cache-refresh directives."

What do you think?

-Rick

> -----Original Message-----
> From: Brian Smith [mailto:bsmith at mozilla.com]
> Sent: Tuesday, October 23, 2012 3:21 PM
> To: Rick Andrews
> Cc: public at cabforum.org; Gervase Markham
> Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt
> Guidelines for the Processing of EV SSL Certificates v.2
> 
> > Gerv,
> >
> > I've changed the title of the document, the motion on the wiki, and
> > the subject line of this email.
> 
> I have some comments on the draft:
> 
> > * "Certificates for which [revocation information] cannot be obtained
> > [...] should not be treated as trusted certificates."
> 
> This change should be removed from the document.
> 
> It am not sure it is even OK to say, like the previous version did,
> that the EV treatment should be removed when revocation fetching
> fails. It is very confusing when network connections cause the OCSP
> request to fail, and then we show an EV cert as non-EV. IMO, it
> would be better to say something like "Certificates for which
> confirmation has never been obtained must not be granted the EV
> treatment, and applications should check for revocation of EV
> certificates at least as frequently as they check for non-EV
> certificate revocation." This would allows us to make changes to
> avoid the "intermittent not-EV" issue, and it would also enable us
> to show cache EV status properly for offline mode, including web
> apps that use the HTML5 offline cache.
> 
> * "The application should support both CRL and OCSP services. For
> HTTP schemes, the application may use either the GET or POST method,
> but should try the GET method first.
> 
> It is fine to say that we should do some kind of revocation checking,
> but there's no need to over-specify this. These two statements can
> just be removed. There's already language above this saying that we
> must do revocation checking according to RFC 5280, which allows much
> more flexibility. If we're not happy with what RFC 5280 says, then
> lets update RFC 5280.
> 
> Cheers,
> Brian


More information about the Public mailing list