On Wed, Mar 9, 2016 at 4:01 PM, Jeremy Rowley <[email protected]> wrote:
> Restricting by root isn't feasible. The browsers limit the number of root > CAs each CA can have. [citation-needed] (?) I'm not aware of any such restriction in the Mozilla policy. And in fact, this discussion seems like a good reason for removing one if there is. --Richard > , meaning most CAs chain Code Signing and Client chain > to the same root as server certs. > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley > [email protected] > .org] On Behalf Of Jakob Bohm > Sent: Monday, March 7, 2016 4:50 PM > To: [email protected] > Subject: Re: More SHA-1 certs > > On 07/03/2016 11:36, Rob Stradling wrote: > > On 04/03/16 23:14, Matt Palmer wrote: > >> On Fri, Mar 04, 2016 at 09:19:36PM +0000, Rob Stradling wrote: > >>> Maybe we need to take a different approach that ignores the > >>> end-entity certificate profile completely. How about we propose > that... > >>> > >>> - An X.509 certificate is in scope for the BRs if it's signed by > >>> an Issuing CA that is in scope. > >>> > >>> - An Issuing CA is in scope if: > >>> i) it chains to a Root Certificate that is trusted for server > >>> authentication > >> > >> You'll want to describe *who* trusts the root. > > > > Hi Matt. I thought somebody might point that out. Sorry for my > > handwaviness. ;-) > > > > "*who* trusts" is indeed important, but it wasn't the aspect of the > > scope problem I was trying to solve with my previous post. > > > >> I trust lots of private PKI > >> roots for server authentication in my own gear, but they're never > >> going mainstream. > >> > >> Perhaps "it chains to a Root Certificate that is trusted, or is > >> intended to be trusted, by one or more Browser members of the > >> CA/Browser Forum for server authentication"? The "intended to be > >> trusted" is to make sure that candidates for browser trust programs > >> know they're on the hook, too. > >> > >> - Matt > > > > > How about "It chains to a Root certificate claiming compliance with > these BRs". This is a clear condition with a well-defined and > controllable meaning. Either a CA root is intended as a CAB/F compliant > root submitted to all the relevant browser related trust lists and thus > would seek compliance with the BR, or that root (even if operated by the > same entity as a BR compliant root) doesn't do that. > > And while we are at it, we also need to look at what the scope rules would > be for e-mail and code certificates and CAs. E-mail because of > Thunderbird. > > Code certificates because while the Mozilla corporate folks have abandoned > the concept, many other people have not, and this Mozilla forum remains the > primary contact point between the open source community and the CAs, > partially because many Open Source distributions (including at least Debian > and Ubuntu) use the Mozilla CA list as the basis for their system-wide > general purpose certificate stores. > > > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej > 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion > message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
