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

Rick Andrews Rick_Andrews at symantec.com
Tue Nov 6 16:42:25 MST 2012


Brian,

Thanks again for your thorough review. Since your reply was long, I'm going to break this into two threads, one related to OCSP Stapling, and one related to everything else.

This is related to everything else. Note that I recognize that this discussion is taking is somewhat away from the document in question. Comments inline.

> -----Original Message-----
> From: Brian Smith [mailto:bsmith at mozilla.com]
> Sent: Sunday, October 28, 2012 6:02 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
> 
> Rick Andrews wrote:
> > 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."
> 
> Rick, I appreciate you taking the time to address my concerns.
> 
> The offline mode is one case I am concerned about. But, it isn't the
> only case. One other concern I have is the transient "false negative"
> case, where we show the EV treatment for paypal.com 30 times to a user,
> and then on the 31st visit the OCSP fetch fails, and we show it as not
> EV, even though it is the same certificate that we verified as being
> not revoked 30 previous times, perhaps even fairly recently. IMO,
> insisting on showing the certificate as "not EV" in this case is more
> harmful than helpful, because it teaches users to ignore the EV
> indicator (though, I suspect many are already happily ignoring the EV
> indicator anyway). It's too confusing.
> 
> I see that the current draft tries to address this by effectively
> making the EV OID an indicator for "hard fail." I think it doesn't make
> sense for us to endorse that position unless/until we have more
> widespread consensus on that between client application developers
> (especially web browser developers); please see below for more on this.

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 welcome feedback from the other browser vendors on the list. Brian has made his opinion clear; how about the others?

> Also, I think there is some ambiguity in the current draft. If Firefox
> were changed to cache revocation information persistently for 365 days,
> so that would only do an OCSP fetch once per year per certificate,
> would it be considered to be acting in line with the guidelines in this
> paper? If 365 days is too much, then how about 90 days, or 30 days? In
> general, if a browser uses some function f(cert-chain, current-time,
> ev-indicator) to determine how long to trust a cached revocation
> response, what are the constraints on that function? Without an answer
> to that question, I cannot evaluate whether the revocation checking
> recommendations in the document are good or bad, and leaving those
> constraints undefined is more harmful than not saying anything more
> than recommending that RFC 5280 be followed.

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?

> In general, I am very much in favor of the idea of standardizing
> revocation checking behavior all around (including hard fail).
> Practically speaking, I think it would be bad for us to support
> standards/recommendations/guidelines that, if we implemented them,
> would result in us failing to load websites more frequently than other
> browsers do and/or if it means we would not be able to be as fast as
> browsers that do not implement the
> standards/recommendations/guidelines. I think that in order to get the
> type of agreement between vendors that we need for that, we need to
> have a completely open standard for revocation checking behavior in an
> open, nearly-universally-respected forum like IETF, W3C, and/or WHATWG,
> that has well-established IPR rules. Then we probably need to get
> explicit sponsorship/endorsement of that standard from a significant
> plurality of key implementers. I think attempting such agreement within
> CABForum is counter-productive. CABForum is too-frequently perceived as
> a "cartel" or similar; even though such characterizations of CABForum
> may be completely wrong, IMO it is not worth the effort and time needed
> to correct them when there are already alternative standards bodies.
> Also, it seems much better for us to use the well-established W3C and
> IETF IPR rules rather than spending time on IPR rules for CABForum
> technical specifications. Accordingly, I would really like CABForum to
> avoid making recommendations about revocation checking (in particular)
> any more than necessary, beyond referring to appropriate
> standards/recommendations from the aforementioned organizations. FWIW,
> I hope to take a minute of time at the WebPKI BoF next week to make
> this same point.

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's a document produced by a nearly-universally-respected forum, but Firefox doesn’t follow that. So I'm not convinced that going to some other forum and getting an agreement written into a spec is going to be any different. Can you say why Firefox doesn't follow RFC 5280 Section 6.1.3 by not checking status of intermediate certs for non-EV?

I fully understand browsers needing to compete with each other, but I thought that we could reach agreement on security-related features (non-gui). And if all browsers agreed to implement these security-related features, then there wouldn't be any competitive disadvantage to any browser doing so. And I thought the CABF was a relatively small group with the right players, and therefore might be a good venue to try to achieve such agreement.

> > 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.
> 
> This idea seems fine to me. Below, I suggest rewording it slightly to
> reuse the RFC 5280 wording, in order to clarify that this document is
> not specifying behavior beyond what RFC 5280 requires.
> 
> > 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.
> 
> If this is redundant with RFC 5280 Section 6.1.3, then it should be
> removed, to make it clear that this isn't asserting any new
> requirements. And, if it isn't redundant with RFC 5280 Section 6.1.3
> then (a) it isn't clear enough, and (b) as I mentioned above, it is
> better to define new requirements for revocation checking behavior
> within the IETF, instead of within this document.

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.

> > 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 first part of the sentence--"Certificates for which confirmation
> cannot be obtained should not be
> granted the EV treatment (see Section 14, EV Treatment, below)"--seems
> OK, as it is in scope as far as this document being about special
> things that need to be done specifically for EV certificates. But, the
> second part about hard fail should be specified elsewhere (e.g. in an
> IETF standard), as explained above.
> 
> > The application should follow HTTP redirects and cache-refresh
> > directives."
> 
> First, I am concerned that RFC 5019 doesn't require support for HTTP
> redirects. I give the people who worked on that spec the benefit of the
> doubt that they made the right call there. If they made a mistake then
> let's update RFC 5019 at the IETF, instead of trying to correct that
> here, especially since support for HTTP redirects doesn't seem like an
> EV-specific requirement.
> 
> Second, requiring browsers to support redirects would encourage CAs to
> use redirects. The use of redirects seems likely to substantially
> increase the latency of making an SSL connection for sites with
> certificates from such CAs, and it seems likely to increase the odds of
> the fetch failing. One of the major arguments against doing revocation
> fetching *at all* in Firefox is that it adds too much latency to SSL
> connections, and another major argument is that revocation fetching is
> too unreliable. Consequently, specifying that proper support for OCSP
> fetching requires support for HTTP redirects will likely push us even
> more towards doing less OCSP fetching and/or not doing OCSP fetching at
> all. That seems like it may be counter-productive to the goals of the
> people who are supporting these changes, AFAICT, so it seems like it's
> actually better to avoid using redirects completely.

I'm very willing to remove that, although I believe it was in the original 2007 version.

> With all that in mind, I'm leaning towards supporting the idea that
> this section should say (only) this:
> 
> "Applications should verify that the certificate is not revoked, as
> specified in RFC 5280 Section 6.1.3. Certificates for which
> confirmation cannot be obtained should not be granted the EV treatment
> (see Section 14, EV Treatment, below)."
> 
> Note, importantly, that the suggested wording for the beginning of the
> first sentence is copy/pasted directly from RFC 5280, to show that this
> sentence is not specifying any new behavior beyond what that RFC says.



More information about the Public mailing list