[cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)

Tue May 28 14:14:12 MST 2013

Eddy

Attached is the comparison.  Here is my explanation of how each proposed change might affect you.

(1)  Removing the first sentence in the second paragraph of Section 13.2.1 would allow all subscribers to use OCSP stapling. The current language implies that stapling is prohibited except for “high-traffic” FQDNs.  “High traffic” is also undefined, so if we are to keep the language, then someone will need to define what it and isn’t a “high traffic” FQDN.   This change takes away any discriminatory effects of limiting OCSP stapling only to “high traffic” sites, which without a definition, could result in allegations of arbitrary and capricious application of a standard.  I would say this change benefits everyone and harms no one.

(2)  In Appendix B, subsection 2.C., the amendment would delete an exception for stapling granted in the model described above.  In that model, only “high traffic” sites could use stapling, and if they stapled, then they would be exempt from having to have an AIA pointer to the OCSP responder.  The proposed change takes away any exception.  This change may effect a “high traffic” site that has implemented OCSP stapling without an AIA for the OCSP responder.  I am unaware of any such site, but I would be interested to find out if there have been any that have successfully implemented it this way, which as Ryan Sleevi pointed out last Friday can be done “using some out-of-band configuration mechanism”.  However, if this exception remains, then it ought to be tightened to provide further assurance that the out-of-band mechanism works.  For example, is anyone aware of any “out-of-band” mechanism that would also resolve all of the legacy issues with clients that are not able to process stapled OCSP responses, which might still be able to check OCSP by referring to the AIA?  I would argue there are none, and that the best practice is for all Baseline SSL/TLS certificates to contain the AIA for OCSP without granting an exception because the most reliable mechanism to communicate the location of the OCSP responder is in the AIA. 

Also, in subsection 2.C. the amendment makes a minor change to improve the language concerning the AIA for CA issuer.  The current language states, “It SHOULD also contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2).”  The amendment clarifies that “it” really refers to “Certificates that are not issued by a Root CA.”  There is no new requirement because the provision is still a “SHOULD”.  The amendment also makes the provision more clear as to the “where” – even the subheading of the subsection is “authorityInformationaccess”, for avoidance of doubt, I think a complete sentence stating, “Certificates that are not issued by a Root CA SHOULD contain an AIA with the HTTP URL where a copy of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded from a 24x7 online repository” is better.    Finally, this last language, “where a copy … can be downloaded from a 24x7 online repository” provide the where, when, and how.  Otherwise, I can put in an unreachable, internal URI for the CA certificate, which does nobody any good.  This will affect any CA who wants to include an AIA in accordance with best practice, but it also allows CAs place their Issuing CA certificate in an access-controlled LDAP directory or elsewhere if they want to use suboptimal methods. 

(3)  This amendment to subsection 3.C. does the same for end entity certificates as the one above does for intermediates.  Because it uses the directive “SHOULD”, I do not think that you would argue that it also needs to exempt end entity certificates issued directly from a Root as it does with intermediate CAs.

(4)  The amendment to subsection 3.D. in Appendix B, concerning basicConstraints, makes it clear that IF you include the basicConstraints extension, even though it is optional, it is best practice to mark it CRITICAL.  I think there were some issues with certificate profiles similar to this recently, and so the reasoning is that the CA/Browser Forum should be more explicit and clear in these kinds of areas.  For example, any software that cannot properly process the basicConstraints extension should fail, rather than treat an end entity certificate as an issuing CA.  However, this explicit requirement might have an effect on any CA that issues end entity certificates without marking basicConstraints critical.   The result of more consistency with implementing basicConstraints by CAs does not affect browsers.  Any browser can still ignore whether basicConstraints is marked critical or not.  Even though I have not looked at whether any browser will fail if basicConstraints is not marked critical, if any does, then best practice would still be to mark it critical for end entity certificates.

(5)  This amendment would help support implementation of OCSP stapling by allowing (“MAY”) a feature that can provide additional security to OCSP stapling solutions.    To quote the abstract of the ID (draft-hallambaker-tlsfeature-02), “The purpose of the TLS Feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol.  In particular, the TLS Feature extension may be used to mandate support for revocation checking features in the TLS protocol such as OCSP stapling.  Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled.  This in turn prevents a denial of service attack that might otherwise be possible.”  The ID goes on to explain why this feature is beneficial.  As I said, I’m looking for comments on whether we could include this permissive language now, just to get suppliers to start thinking about this now, rather than two years from now.  Because this is a “MAY”, I don’t think it has any negative effect on anyone.

Ben

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Tuesday, May 28, 2013 12:12 PM
To: public at cabforum.org
Subject: Re: [cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)

Ben, can you please explain what the changes are that you propose and perhaps a diff from the current guidelines. It's not clear what exactly is proposed and how it would affect us.

On 05/28/2013 08:14 PM, From Ben Wilson: 

I am looking for two endorsers of Ballot 103 OCSP Stapling and AIA, which I’ve revised below.  I’m flexible on subparagraph (5), and I’ve sent a note to the TLS WG to solicit comments on it.

 Ben Wilson of DigiCert made the following motion, and ____ from _____  and ______ from ______ endorsed it:

 ---Motion Begins ---

EFFECTIVE IMMEDIATELY, in order clarify the use case for stapling in section 13.2.1 and to modify the OCSP URI requirement in the authorityInformationaccess of Appendix B of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, we propose the following amendments:

 ---List of amendments begins--- 

(1)  In Section 13.2.1 “Mechanisms” DELETE the first clause in the second paragraph "If the Subscriber Certificate is for a high-traffic FQDN so that as amended the section reads as follows:

 "13.2.1  Mechanisms

 The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with Appendix B.

The CA MAY rely on stapling, in accordance with [RFC4366], to distribute its OCSP responses.  In this case, the CA SHALL ensure that the Subscriber “staples” the OCSP response for the Certificate in its TLS handshake.  The CA SHALL enforce this requirement on the Subscriber either contractually, through the Subscriber or Terms of Use Agreement, or by technical review measures implement by the CA."

 (2)  In Appendix B "2. Subordinate CA Certificate" remove point C (authorityInformationAccess) and insert:

 C.  authorityInformationAccess 

This extension MUST be present.  It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). 

See Section 13.2.1 for details about OCSP stapling requirements.

Certificates that are not issued by a Root CA SHOULD contain an AIA with the HTTP URL where a copy of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded from a 24x7 online repository.

 (3)  In Appendix B "3. Subscriber Certificate" remove point C (authorityInformationAccess) and insert:

                C. authorityInformationAccess 

This extension MUST be present.  It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). 

Subscriber Certificates SHOULD contain an AIA with the HTTP URL where a copy of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded from a 24x7 online repository.

(4)  In Appendix B "3. Subscriber Certificate" remove point D (basicConstraints) and insert:

D.  basicConstraints (optional)

If present, this field MUST be marked critical and the cA field MUST be set to false.

[Optional part of motion:  (5)  In Appendix B "3. Subscriber Certificate" after point F insert a new point G (TLS Feature Extension) as follows:

G.  TLS Feature Extension (optional)

Subscriber Certificates MAY contain the TLS Feature Extension advertising that the status_request feature of OCSP stapling is available and supported by the subscriber.  If present, this field MUST NOT be marked critical.]

Regards 

Signer: 

Eddy Nigg, COO/CTO

StartCom Ltd. <http://www.startcom.org> 

XMPP: 

startcom at startcom.org

Blog: 

Join the Revolution! <http://blog.startcom.org> 

Twitter: 

Follow Me <http://twitter.com/eddy_nigg> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130528/4d149e14/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ballot_103_Comparison with Baseline.pdf
Type: application/pdf
Size: 31524 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130528/4d149e14/attachment-0001.pdf 