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

[Ryan Sleevi]

On Fri, May 24, 2013 at 5:19 PM, Ben Wilson <ben at digicert.com> wrote:

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

As I expressed on previous calls, this is not accurate. It's entirely
possible to configure the AIA for the associated server certificate using
some out-of-band configuration mechanism.

The current language permits this, and through the use of the contractual
language, allows CAs to omit such information from the certificate.

Our past calls and minutes established this as a "Harder for customers to
make misconfiguration" feature, rather than "Impossible to use correctly",
which you seem to be suggesting.

While I can certainly see some motivation, particularly for clients that do
not support stapling, I definitely see this as a change in meaning/intent,
and have to agree with Kirk that this takes the form of an amendment, if we
want to quibble on that vs errata :)

Cheers,
Ryan


> ****
>
> ** **
>
> *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<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.****
>
> ** **
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130524/3a9035ad/attachment.html