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

Sat May 25 00:19:46 UTC 2013

I am thinking this as errata – it was a mistake in language from the start because servers can’t do OCSP stapling unless they can look at the AIA for the OCSP in certificate.  To say that with OCSP stapling you don’t need an AIA was clearly a mistake.

From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] 
Sent: Friday, May 24, 2013 6:11 PM
To: ben at digicert.com; public at cabforum.org
Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and AIA Errata (DRAFT)

Ben – does this really address errors (errata), or is it simply an amendment to our existing standards?  If the latter, can we start re-naming these motions as simple “Amendments”?

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, May 24, 2013 5:08 PM
To: public at cabforum.org
Subject: [cabfpub] Ballot 103 - OCSP Staping and AIA Errata (DRAFT)

This is a Draft Ballot to address BR Issue 7.  I’ve reworked it since our last discussion, and I’m looking for endorsers.  One question that we need to resolve is whether (5) below is premature.  It states, “The certificate MAY contain the TLS Feature Extension advertising that the status_request feature of OCSP stapling is available and supported by the subscriber.”  (Must staple)    If premature, then subsection (5) of the motion can be deleted.  However, if we think we can address this now, then we can leave it in.  Eventually whether we use IETF OIDs or our own CABF OIDs, (we’ve said that must-staple was going to have the OID of 2.23.140.16.1), any numbers could be added in later as parentheticals.  A redlined PDF of the proposal is attached.

Ballot 103 OCSP Stapling and AIA Errata

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

---Motion Begins ---

EFFECTIVE IMMEDIATELY, in order to correct erroneous statements concerning the allowance of stapling in section 13.2.1 and the requirement for an authorityInformationaccess (AIA) uniform resource identifier for OCSP responders in Appendix B of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, we propose the following amendments:

---List of errata 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.

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

=====Motion Ends=====

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130524/00e7fc45/attachment-0003.html>