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

[Brian Smith]

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.

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.

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

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

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.

In addition, I think it would be good for the document to additionally recommend the following things, until we have an IETF/W3C/WHATWG specification for revocation checking:

"If the application uses OCSP, then the application should support the TLS Certificate Status Request Extension (better known as OCSP Stapling), specified in RFC 4366 Section 3.6. If/when the application makes OCSP requests over HTTP (RFC 2650 Appendix A) then it should do so in conformance with the Lightweight Online Certificate Status Protocol (RFC 5019)."

Generally, I consider the recommendation of OCSP stapling to be a prerequisite for saying anything about revocation checking over HTTP.

Also, it is important that we make corresponding changes to the the baseline requirements to add something like the following:

"CAs must advise their customers that they implement the TLS Certificate Status Request Extension (better known as OCSP Stapling), specified in RFC 4366 Section 3.6. CAs must advise their customers that applications (including, in particular, some web browsers and email clients) may, now and/or in the future, not support revocation checking using OCSP requests over HTTP. CAs should include corresponding instructions for configuring OCSP Stapling with the instructions they provide for configuring server side products to use their certificates. CAs must support the Lightweight Online Certificate Status Protocol (RFC 5019) for all end-entity certificates that do not include the must-staple extension (citation for must-staple extension spec). CAs must not return 300-level responses (redirects) to OCSP requests over HTTP."

In addition, the "Guidelines for the Processing of EV SSL Certificates" document should have a section that defines requirements for servers, that includes the following statement: "Web servers should support the TLS Certificate Status Request Extension (better known as OCSP Stapling), specified in RFC 4366 Section 3.6. Note that client applications (including, in particular, some web browsers and email clients) may, now and/or in the future, not support revocation checking using using OCSP requests over HTTP." It also seems like a good idea to rename the document "Guidelines for Client Applications and Servers for the Processing of EV SSL Certificates" to make it clearer that there would now be requirements for servers in the document.

I think these changes I proposed here are very fair in how they express the importance for CAs, client application vendors, server product vendors, and server administrators to work together to ensure that revocation information is reliably transmitted from the CA to the client application with minimal negative impact on reliability, performance, and user experience of any of the parties involved. Also, note that OCSP stapling as the recommended form of conveying revocation information seems to mostly resolve the issue of intermittent OCSP fetching failures leading to confusing EV indicator "false negative" glitches in web browsers. Also note that notifying web server administrators and web server product vendors about the unclear fate of OCSP fetching over HTTP in client applications isn't an endorsement of applications turning off OCSP fetching; it's simply documenting the reality of the current situation and encouraging them to do something we all seem to want them to do anyway.

Also, while I do think that the suggestions I make above are the ones most likely to get consensus within Mozilla, please do not interpret these suggestions as an official position of Mozilla. If we (CABForum) agree to move forward with these suggestions, then I will work within Mozilla to get the consensus we need. It may be helpful for people to read https://wiki.mozilla.org/Standards/Participating_in_a_W3C_Working_Group, which also applies to Mozillians' participation in CABForum.

Cheers,
Brian