[cabfpub] Revised document for Ballot 89 - Adopt Guidelines...EV SSL Certificates - OCSP Stapling

[Rick Andrews]

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

I oppose adding this, for the same reason you opposed my addition of RFC 5280 references. If it's not adding any new requirements, why add it? 

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

If you want to propose the above change to the Baseline Requirements, I suggest you start a completely different ballot. This ballot is specific to the EV doc, not BR, and I don't want to expand the scope of this ballot - it's taken enough time already!

> In addition, the "Guidelines for the Processing of EV SSL Certificates"
> document should have a section that defines requirements for servers,

I disagree - although the Scope section of the doc currently says: "This document contains guidelines for Application Software Suppliers who rely on extended Extended validation Validation certificates." and that can be interpreted as meaning web servers too, I would argue that the intent of the doc has always been to provide guidance for browsers and other SSL clients, not servers. CAs went to lengths to insure that EV certs could be supported by existing web 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.

Again, I'd like to resist expanding the scope for now. I'm all for OCSP Stapling, but I don't want to turn this doc into a means of promoting Stapling.
 
> 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