[cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy Extension
Rob Stradling
rob.stradling at comodo.com
Mon Nov 4 11:24:16 UTC 2013
Ben, Phill renamed his TLS Security Policy I-D a while ago.
http://datatracker.ietf.org/doc/draft-hallambaker-tlssecuritypolicy/
...is the old one.
http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/
...is the new one.
Even the new I-D is now expired. Why? Because folks on the PKIX
mailing list expressed an interest more than a year ago in allocating an
OID for a "must staple" certificate extension from the official PKIX OID
arc, but they haven't actually gone ahead and allocated one.
A year should be more than enough time to allocate an OID!
Now that the PKIX WG is officially shut down, I think we should assume
that no new OIDs will ever be allocated from the PKIX OID arc ever again.
Previously you wrote on the PKIX list:
"CABF was looking at adopting “2.23.140.16.1” 2.23.140 is the
ca-browser-forum, 16 is ocsp, and 1 would become “must-staple”."
Can we please just use 2.23.140.16.1 and ask Phill to refresh his I-D?
On 01/11/13 21:05, Ben Wilson wrote:
> All,
> Here is the current draft of the Ballot - I need two endorsers or Robin and
> one other endorser to move this forward to review and voting periods.
> 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 1 January 2014, 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" 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: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Robin Alden
> Sent: Friday, September 06, 2013 10:00 AM
> To: 'Bruce Morton'; CABFPub
> Subject: Re: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
> Extension
>
> Hi Bruce,
> We'll withdraw that section about basicConstraints in subscriber
> certificates from the ballot.
>
>> (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.
>>
>
> I think it probably deserves its own ballot. When it appears in that
> context, I'd like to see basicConstraints required instead of optional, but
> am less fussy about the criticality.
>
> Regards
> Robin Alden
> Comodo
>
>
>> -----Original Message-----
>> From: questions-bounces at cabforum.org [mailto:questions-
>> bounces at cabforum.org] On Behalf Of Bruce Morton
>> Sent: 05 September 2013 17:58
>> To: ben at digicert.com; questions at cabforum.org
>> Subject: Re: [cabfquest] [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
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
More information about the Public
mailing list