[cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)
Eddy Nigg (StartCom Ltd.)
eddy_nigg at startcom.org
Tue May 28 18:12:18 UTC 2013
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 <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: <http://lists.cabforum.org/pipermail/public/attachments/20130528/bbb14dff/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130528/bbb14dff/attachment-0001.p7s>
More information about the Public
mailing list