[cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy Extension
Ben Wilson
ben at digicert.com
Mon Nov 4 18:04:16 UTC 2013
Phill,
I agree with Rob - could we just wrap this up as proposed with the OID as
2.23.140.16.1 and the description of that OID as whatever you recommend
(e.g. must-staple TLS feature, etc.)?
Thanks,
Ben
-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rob Stradling
Sent: Monday, November 04, 2013 4:24 AM
To: ben at digicert.com; 'Robin Alden'; 'Bruce Morton'; 'CABFPub'
Subject: Re: [cabfpub] Ballot 103 - OCSP Staping and TLS Security Policy
Extension
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.
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- 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/20131104/e9c05177/attachment-0001.p7s>
More information about the Public
mailing list