[cabfpub] Revised document for Ballot 89 - Adopt Guidelines...EV SSL Certificates - All Else

[Brian Smith]

Rick Andrews wrote:
> IMO, your proposal raises another issue: what if the later OCSP fetch
> fails because the attacker is in the middle or has otherwise changed
> the certificate to a different one? The browser would have to be
> careful to only continue showing the EV treatment if the same
> certificate was returned. I think it would be simpler to take down
> the EV treatment if the browser can't verify that the cert is valid,
> whenever it does a new handshake, rather than come up with more
> rules about when it's ok to continue in the case of an OCSP failure.

I don't understand your question. Any cache of revocation information would be keyed on serial number and issuer or equivalent, so effectively we would always do the "same cert" check. And, though I agree your suggested method is simpler, it is a horrible UX, and that horrible UX is what I'm trying to avoid.

> I'm not understanding something. The cached revocation information,
> whether CRL or OCSP, can't be valid longer than 10 days (according
> to the BR). Why would FF cache it for longer than that?

The BR define requirements on the information that CAs publish, not on browser's interpretation of that information. I think it is important to have latitude in how long we accept a stale OCSP response. I know others at Mozilla have suggested that we should never cache revocation information longer than 24 hours (regardless of the dates in the OCSP response). I actually think that it may be more reasonable to make the length of time we trust cached revocation information a function of the length of time the certificate has been "alive," and perhaps that caching could even extend beyond the nextUpdate date in the OCSP response.

> I cite an example below where Firefox, for non-EV certs, violates RFC
> 5280 Section 6.1.3 by not checking the status of intermediates.

That is not true and I clarified this in an earlier message. Notice that RFC 5280 says "At the current time, the certificate is not revoked. This may be determined by [...] out-of-band mechanisms." We provide all of our CAs with an out-of-band mechanism for notifying us about security incidents, including in particular mis-issuances and key compromises of intermediate certificates. You just have to email us a  description of the security incident along with the technical information about the affected certificates. When we are notified about a mis-issuance or a key compromise we will ensure that our product dis-trusts the certificate and related certificates from other CAs (assuming those other CAs cooperate). Usually that distrust will become effective well within the time period suggested by the "nextUpdate" time in an OCSP response, and also this distrust is more comprehensive than an OCSP check would be, because we distrust related certificates from other CAs after being notified of such security incidents.

Also, like I said in my previous message, I am very open to the idea of automating this. However, the current OCSP/CRL mechanism does not seem like an appropriate automation because we receive both too much information (revocations that aren't security incidents) and too little information (e.g. CRLs and OCSP do not include the DER-encoded X.509 certificate being revoked, the CA's description of the security incident, contact information for the CA and the customer involved, and information about cross-signings of the certificate). But, this is something that we can definitely fix by working together.

Also, I think that our proposed CA inclusion policy changes go a long way towards *preventing* security incidents, which is even better than responding to those incidents after they occur. In fact, based on feedback we've received from CAs and some of their customers, those proposed policy changes have likely already reduced risk to our users before they've even been incorporated into our policy.

> It isn't asserting any new requirements beyond RFC 5280 Section
> 6.1.3, however I wanted to make it more visible precisely because
> some browsers (at least Firefox, maybe others) don't check
> revocation of intermediates for non-EV certs. IMO, the CABF wanted
> to assert that EV Certificates represented a higher level of
> security, and this (mandatory checking of intermediates) could be an
> example of why that is so.

This mis-understanding is exactly why I want to be precise here. I think we can all agree, based on what I've said above, that not only is Mozilla complying with RFC 5280 to the letter, but we're in fact going above and beyond its requirements and doing things that aren't even possible with OCSP and CRL fetching. And, I hope we can work together to improve upon what Mozilla is already doing.

Cheers,
Brian