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

[Rick Andrews]

Let's discuss this further on the call on Thursday. I hope you and reps from other browser companies can attend.

-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