[cabfpub] [cabfquest] Ballot 103 - OCSP Staping and TLS Security Policy Extension
Ben Wilson
ben at digicert.com
Tue Oct 15 22:00:10 UTC 2013
Thanks. I'll remove subsection (4).
I'm not sure whether your assumption on the reasons for the exceptions in
subsections (2) and (3) are accurate, I thought it was an error, but Ryan
Sleevi pointed out that there may be a CA out there who has "configure[d]
the AIA for the associated server certificate using some out-of-band
configuration mechanism." So, in that case, how much time should be given
on subsections (2) and (3) for CAs who have enabled server OCSP stapling in
some way to put the URL for their OCSP responder in their AIA?
Maybe it would also help to learn which CA is already doing this, because it
does seem like a bad because non-OCSP clients would not know where to fetch
OCSP responses.
-----Original Message-----
From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org]
On Behalf Of Bruce Morton
Sent: Tuesday, October 15, 2013 2:27 PM
To: ben at digicert.com; questions at cabforum.org
Subject: Re: [cabfquest] [cabfpub] Ballot 103 - OCSP Staping and TLS
Security Policy Extension
Ben,
I understand the ballot to take away some exceptions regarding OCSP (item C
for both Subordinate CA and Subscriber certificates). If there are any CAs
which are using these exceptions, then "EFEECTIVE IMMEDIATELY" should not be
used. I assume that we put the exception in the requirements to support at
least one CA.
Also, since there is now no change to the Basic Constraints requirement, it
can be removed from the ballot.
Bruce.
-----Original Message-----
From: Ben Wilson [mailto:ben at digicert.com]
Sent: Tuesday, October 15, 2013 3:54 PM
To: Bruce Morton; public at cabforum.org
Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
Extension
I don't understand. The language as revised basically says, for end entity
certificates, if you include the basic constraints OID, don't say that the
certificate is a CA certificate.
D. basicConstraints (optional)
If present, the cA field MUST be set to false.
What's wrong with that? I thought this change resolved your comment. I am
not rejecting the argument that changes in standard practices should have
implementation schedules - I agree that "effective immediately" isn't the
best formula, but if there is something else here that causes concern
because it creates a new requirement with implementation time, then it would
be good to know. And it would also be good to know how much time everyone
thinks will be needed in order to become compliant.
Thanks,
Ben
-----Original Message-----
From: Bruce Morton [mailto:bruce.morton at entrust.com]
Sent: Tuesday, October 15, 2013 1:32 PM
To: ben at digicert.com; public at cabforum.org
Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
Extension
Removing "this field MUST be marked critical" does meet my main objection as
this complies with how we provide the basic constraints OID.
However, you may have some objections with CAs that must make changes as the
ballot states "EFFECTIVE IMMEDIATELY." I would suggest that a ballot that
may require technical changes should provide a validity date at a reasonable
time in the future.
Bruce.
-----Original Message-----
From: Ben Wilson [mailto:ben at digicert.com]
Sent: Tuesday, October 15, 2013 3:18 PM
To: Bruce Morton; public at cabforum.org
Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
Extension
Bruce and all,
If the following language "this field MUST be marked critical" is removed
from subsection (4) of the ballot, does that satisfy everyone's concerns?
See restated ballot below.
Ben
Ballot 103 - OCSP Stapling and TLS Security Policy Extension
Explanation - This motion is made to clarify and simplify language about
OCSP stapling and to promote the development and use of OCSP Stapling by
allowing certificates to contain a TLS Security Policy Extension.
Ben Wilson of DigiCert made the following motion, and Robin Alden from
Comodo and ______ from _______ endorsed it:
Motion Begins
EFFECTIVE IMMEDIATELY, in order to clarify language in section 13.2.1 of the
Baseline Requirements and in Appendix B concerning
authorityInformationaccess (AIA), and allow use of the TLS Security Policy
Extension, we propose the following amendments:
(1) Delete the second paragraph of Section 13.2.1 "Mechanisms" so that as
amended the section will read as follows:
"13.2.1 Mechanisms
The CA SHALL make revocation information for Subordinate Certificates and
Subscriber Certificates available in accordance with Appendix B."
(2) In Appendix B "(2) Subordinate CA Certificate" replace point C.
authorityInformationAccess with:
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).
For Certificates that are not issued by a Root CA, this extension SHOULD
contain 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" replace point C.
authorityInformationAccess with:
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).
This extension SHOULD contain 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" replace point D.
basicConstraints (optional) with:
D. basicConstraints (optional)
If present, the cA field MUST be set to false.
(5) In Appendix B "(3) Subscriber Certificate" after point F insert a new
point G (TLS Security Policy Extension) as follows:
G. TLS Security Policy Extension (optional)
Subscriber Certificates MAY contain the TLS Security Policy Extension
[http://datatracker.ietf.org/doc/draft-hallambaker-tlssecuritypolicy/]
advertising that the status_request feature of OCSP stapling is available
and supported by the Subscriber. If present, this field SHOULD NOT be marked
critical.
=====Motion Ends=====
-----Original Message-----
From: Bruce Morton [mailto:bruce.morton at entrust.com]
Sent: Thursday, September 05, 2013 10:58 AM
To: ben at digicert.com; questions at cabforum.org
Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
Extension
Ben,
The ballot requires for Subscriber Certificates that the optional OID of
basicConstraints be set to critical. I'm not sure why this optional OID
needs to be set at critical, but if it does then some CAs will have to make
a change. As such, I do not believe that the ballot should be "EFFECTIVE
IMMEDIATELY."
Just so we understand, can someone please advise why the basicConstraints
OID needs to be set as critical for a Subscriber Certificate.
Thanks, Bruce.
-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Wednesday, September 04, 2013 6:22 PM
To: public at cabforum.org
Subject: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
Extension
Robin,
If this draft is acceptable, then we would only be looking for one more
endorser. Please let me know.
Thanks,
Ben
Ballot 103 - OCSP Stapling and TLS Security Policy Extension
Explanation - This motion is made to clarify and simplify language about
OCSP stapling and to promote the development and use of OCSP Stapling by
allowing certificates to contain a TLS Security Policy Extension.
Ben Wilson of DigiCert made the following motion, and Robin Alden from
Comodo and ______ from _______ endorsed it:
Motion Begins
EFFECTIVE IMMEDIATELY, in order to clarify language in section 13.2.1 of the
Baseline Requirements and in Appendix B concerning
authorityInformationaccess (AIA), and allow use of the TLS Security Policy
Extension, we propose the following amendments:
(1) Delete the second paragraph of Section 13.2.1 "Mechanisms" so that as
amended the section will read as follows:
"13.2.1 Mechanisms
The CA SHALL make revocation information for Subordinate Certificates and
Subscriber Certificates available in accordance with Appendix B."
(2) In Appendix B "(2) Subordinate CA Certificate" replace point C.
authorityInformationAccess with:
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).
For Certificates that are not issued by a Root CA, this extension SHOULD
contain 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" replace point C.
authorityInformationAccess with:
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).
This extension SHOULD contain 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" replace point D.
basicConstraints (optional) with:
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 Security Policy Extension) as follows:
G. TLS Security Policy Extension (optional)
Subscriber Certificates MAY contain the TLS Security Policy Extension
[http://datatracker.ietf.org/doc/draft-hallambaker-tlssecuritypolicy/]
advertising that the status_request feature of OCSP stapling is available
and supported by the Subscriber. If present, this field SHOULD NOT be marked
critical.
=====Motion Ends=====
_______________________________________________
Questions mailing list
Questions at cabforum.org
https://cabforum.org/mailman/listinfo/questions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131015/2a11527e/attachment-0001.p7s>
More information about the Public
mailing list