There isn’t that policy. It used to be a limit of three in the old MS policy, which is why all roots came in threes until things started getting sold off and passed around. As for source, it was always a CAB Forum discussion back under Tom Albertson. I can probably find the notes in the old CAB Forum discussion but those aren’t posted publicly. However, considering the need for ubiquity, I don’t think it’s practical to apply that retroactively to CAs, especially considering how cross-signing works.
From: Richard Barnes [mailto:[email protected]] Sent: Wednesday, March 9, 2016 2:04 PM To: Jeremy Rowley Cc: Jakob Bohm; [email protected] Subject: Re: More SHA-1 certs On Wed, Mar 9, 2016 at 4:01 PM, Jeremy Rowley <[email protected] <mailto:[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 <mailto:dev-security-policy-bounces%2Bjeremy.rowley> [email protected] .org] On Behalf Of Jakob Bohm Sent: Monday, March 7, 2016 4:50 PM To: [email protected] <mailto:[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 <tel:%2B45%2031%2013%2016%2010> 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] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
