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

[Brian Smith]

> 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