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

Yngve N. Pettersen yngve at spec-work.net
Fri Jul 26 21:12:56 UTC 2013


Hi,

I think that could be fixed by specifically stating that document  
referencing the BR can specify a that they apply for different kinds of  
certificates, with attributes X, Y, Z, including or excluding specific  
attributes U,V,W in the BR, or words to that effect. Then update the EV  
code signing doc correspondingly.


On Fri, 26 Jul 2013 23:06:32 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

> Maybe I'm the only one whose thinking is this twisted, but might someone
> look at the EV Code Signing doc, and see that it says "See the BRs for
> requirements on this extension" (for example), then they look at the BRs  
> and
> see that the BRs are not meant to apply to code signing certs?
>
> -Rick
>
>> -----Original Message-----
>> From: Stephen Davidson [mailto:S.Davidson at quovadisglobal.com]
>> Sent: Friday, July 26, 2013 1:55 PM
>> To: Rick Andrews; jeremy.rowley at digicert.com; 'Geoff Keating'; 'Ryan
>> Sleevi'
>> Cc: 'CABFPub'
>> Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline
>> requirements
>>
>> The BR already have this caveat:
>>
>> 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.
>>
>>
>>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On
>> Behalf Of Rick Andrews
>> Sent: Friday, July 26, 2013 5:54 PM
>> To: jeremy.rowley at digicert.com; 'Geoff Keating'; 'Ryan Sleevi'
>> Cc: 'CABFPub'
>> Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
>> requirements
>>
>> 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
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/



More information about the Public mailing list