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

Robin Alden robin at comodo.com
Thu Jul 11 05:50:00 MST 2013


Hi Ben,
	We think the 2nd paragraph of 13.2.1 (as amended) commencing
"The CA MAY rely on stapling ...." doesn't really have anything useful
left to say and so should probably be removed in its entirety.  
If it still has a message to put across then maybe it's just to be
explicitly permissive about the use of stapling or to flag to relying
parties to check for stapling using the TLS Certificate Status Request
extension as specified in RFC 6066.

We also think the 2 instances of "an AIA with" in Appendix B 2C&3C
should be dropped.  They are both in subsections entitled
"authorityInformationAccess", so I don't think it is ambiguous where the
accessMethods are to be encoded.

For Appendix B 3G, we think that a reference to Phill's I-D [1] should
be added.  Otherwise, nobody will know what "TLS Feature Extension"
actually means. 
BTW, Phill's I-D calls it "TLS Security Policy Extension", not "TLS
Feature Extension".  We should name it consistently if we can.

[1] http://datatracker.ietf.org/doc/draft-hallambaker-tlssecuritypolicy/

Otherwise it looks good to us and we certainly support and endorse it.

Regards
Robin



> -----Original Message-----
> From: Ben Wilson [mailto:ben at digicert.com]
> Sent: 11 July 2013 07:44
> To: 'Robin Alden'; 'Rob Stradling'
> Cc: public at cabforum.org
> Subject: RE: [cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)
> 
> Rob/Robin,
> 
> Attached is a revised redline of the changes to the Baseline
> Requirements proposed by Ballot 103, which as amended would require
> just one other endorser.  Please review and see if your requested
> change has been made.
> 
> Ballot 103 - OCSP AIA and TLS Feature Extension
> 
> Ben Wilson of DigiCert made the following motion, and _____ from
> Comodo and ______ from _______ endorsed it:
> 
> Motion Begins
> 
> EFFECTIVE IMMEDIATELY, in order to amend language in section 13.2.1 of
> the Baseline Requirements, clarify the requirement for an OCSP
> responder authorityInformationaccess (AIA) in Appendix B, and allow
> the use of a TLS Feature Extension, we propose the following
> amendments:
> 
> (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 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.
> 
> 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 implemented 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).
> 
> 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 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, June 07, 2013 10:20 AM
> To: 'Rob Stradling'; ben at digicert.com
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)
> 
> Hi Ben,
> 	If you accept Rob's amendment, below, Comodo will endorse
> ballot 103.
> 
> Regards
> Robin
> 
> 
> > -----Original Message-----
> > From: public-bounces at cabforum.org [mailto:public-
> > bounces at cabforum.org] On Behalf Of Rob Stradling
> > Sent: 29 May 2013 10:32
> > To: ben at digicert.com
> > Cc: public at cabforum.org
> > Subject: Re: [cabfpub] Ballot 103 - OCSP Staping and AIA (DRAFT)
> >
> > On 28/05/13 18:14, Ben Wilson wrote:
> > > 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.
> > <snip>
> > > 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.]
> >
> > Ben, I suggest changing "MUST NOT" to "SHOULD NOT".
> >
> > Phill's draft [1] says:
> >    "The TLS Feature Extension SHOULD NOT be marked critical.  RFC
5280
> >     [RFC5280] requires that implementations that do not understand
the
> >     extension MUST reject the certificate.  Marking the TLS Feature
> >     Extension critical breaks backward compatibility and is not
> >     recommended unless this is the desired behavior."
> >
> >
> > [1] http://www.ietf.org/id/draft-hallambaker-tlsfeature-02.txt
> >
> > --
> > Rob Stradling
> > Senior Research & Development Scientist COMODO - Creating Trust
> Online
> >
> > _______________________________________________
> > 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: 5246 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130711/7a671969/attachment.bin 


More information about the Public mailing list