[cabfpub] Ballot 108: Clarifying the scope of the baseline requirements

Rick Andrews Rick_Andrews at symantec.com
Fri Jul 26 20:52:53 UTC 2013


I agree with tightening up the definition of an SSL certificate, but does that cause problems for the EV Code Signing Guidelines, which incorporate the BR by reference?

-Rick

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Jeremy Rowley
> Sent: Friday, July 26, 2013 1:06 PM
> To: 'Geoff Keating'; 'Ryan Sleevi'
> Cc: 'CABFPub'
> Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
> requirements
> 
> Sounds good.  I'll circulate a formal ballot with Ryan's modifications.
> 
> Thanks,
> Jeremy
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On
> Behalf Of Geoff Keating
> Sent: Friday, July 26, 2013 1:37 PM
> To: Ryan Sleevi
> Cc: CABFPub
> Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
> requirements
> 
> I would endorse the proposal with Ryan's improved wording.
> 
> On 26/07/2013, at 12:34 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> > Jeremy,
> >
> > If I might suggest a slight modification to the wording, which still
> > leaves things a little ambiguous. "All root and intermediate
> > certificates included in a browser's trust store" - AIUI, none of the
> > browsers are really accepting intermediates to the trust store at
> this
> > point.
> >
> > This was a sticky point when working on Mozilla's wording on this
> > policy to. Luckily, the terminology for "Root CA" and "Subordinate
> CA"
> > may be sufficient here to help clarify.
> >
> > "All root certificates included in a browser's trust store, all
> > subordinate CA certificates signed by one of these root certificates,
> > and all end-entity certificates that either lack any Extended Key
> > Usage extension or contain an Extended Key Usage extension that
> > contains one of the following:
> > - Server Authentication (1.3.6.1.5.5.7.3.1)
> > - anyExtendedKeyUsage (2.5.29.37.0)
> > - Netscape Server Gated Cryptography (2.16.840.1.113730.4.1)
> > - Microsoft Server Gated Cryptography (1.3.6.1.4.1.311.10.3.3) are
> > expressly covered by these requirements."
> >
> > Note that Appendix B, 3.F lists other values as SHOULD NOT. However,
> > that presumably only applies when a certificate is 'in scope' of the
> > BRs, hence the restatement of potential EKUs that are relevant.
> >
> >
> >
> > On Fri, Jul 26, 2013 at 12:22 PM, Jeremy Rowley
> > <jeremy.rowley at digicert.com> wrote:
> >> Hi everyone,
> >>
> >>
> >>
> >> As mentioned on the phone call last week, CAs have claimed exemption
> >> from the BRs because the definition of a publicly-trusted SSL
> certificate
> is not
> >> clear.   I would like to clarify the scope of the BRs to avoid
> confusion
> on
> >> what particular certificate contents are necessary to require
> >> compliance.  I am looking for on endorser (Stephen Davidson has
> already
> endorsed).
> >>
> >>
> >>
> >> The third paragraph of Section 1 of the baseline requirements is:
> >>
> >> "This version of the Requirements only addresses Certificates
> >> intended to be used for authenticating servers  accessible through
> >> the Internet. Similar requirements for code signing, S/MIME,
> >> time-stamping, VoIP, IM, Web services, etc. may be covered in future
> versions."
> >>
> >>
> >>
> >> I'd like to replace the above text with the following:
> >>
> >> "This version of the Baseline Requirements addresses all root,
> >> intermediate, and end entity certificates that can be used in
> >> publicly-trusted SSL handshakes.  All root and intermediate
> >> certificates included in a browser's trust store and all end entity
> >> certificates containing an extended key usage extension of Server
> >> Authentication (1.3.6.1.5.5.7.3.1) are expressly covered by these
> >> requirements. Similar requirements for code signing, S/MIME,
> >> time-stamping, VoIP, IM, Web services, etc. may be covered in future
> versions."
> >>
> >>
> >>
> >> I look forward to your comments.
> >>
> >>
> >>
> >> Jeremy
> >>
> >>
> >> _______________________________________________
> >> Public mailing list
> >> Public at cabforum.org
> >> https://cabforum.org/mailman/listinfo/public
> >>
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public



More information about the Public mailing list