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

Rick Andrews Rick_Andrews at symantec.com
Thu Nov 8 02:26:12 UTC 2012

> -----Original Message-----
> From: Brian Smith [mailto:bsmith at mozilla.com]
> Sent: Wednesday, November 07, 2012 2:01 AM
> To: Rick Andrews
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt
> Guidelines...EV SSL Certificates - All Else
> 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.

OK, now that I understand how you're doing it, I agree that my scenario isn't realistic.
> > 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'm surprised by this. We, and probably most other CAs, are very diligent about updating CRLs and OCSP responses before they expire, so there's no gap but more importantly so end-users are notified of a status change sooner rather than later. We won't serve up any expired revocation status. Why do you think it may be reasonable to cache status information after a CA has said it's expired? That may improve the browser's performance but at the expense of security, IMO.

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

I will concede that according to the letter of the RFC, you comply because you have an out-of-band means. But I'm definitely not in favor of using that means, for several reasons:
 - "You just have to email us" How secure is that? How do you know it's me? The email isn't signed, but an OCSP response and a CRL are.
 - It's quite a burden for a CA to have to locate contact info for each and every browser to notify them. AFAIK, it's not collected together somewhere. Do I just email CABF members?
 - We (and probably other CAs) have invested a lot of money into our CRL and OCSP infrastructures. We don't want to use a different out-of-band means to convey information that we already have a system for.

Is this Mozilla policy posted somewhere? Do all the CAs who have roots in Mozilla's trust store know that if they revoke an end-entity, they just have to publish a CRL and/or OCSP response, but if they revoke an intermediate, they have to contact Mozilla?

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

No, I don't agree that Mozilla is going above and beyond its requirements. From my perspective, Mozilla doesn't fetch CRLs unless the end-user has pre-loaded them, it doesn't check OCSP responses for intermediates, and it ignores signals from CAs on how long revocation status should be cached. 

> Cheers,
> Brian

More information about the Public mailing list