Re: BR compliance of legacy certs at root inclusion time

On 22/08/17 11:02, Ryan Sleevi wrote: > I think it'd be useful if we knew of reasons why standing up (and > migrating) to a new infrastructure was not desirable? It is true that in the case of a legacy root, creating a new root with a cross-sign is not technically all that complex (although it

Re: BR compliance of legacy certs at root inclusion time

Actually previous SHA-1 certs might be one of the least objectionable non-compliances assuming that nobody expects Firefox, or other clients in the Web PKI to actually trust these certs, because the difference in signature algorithm contains the risk nicely. Bad guys who have speculatively

Re: BR compliance of legacy certs at root inclusion time

Yes, I think it's fair for Mozilla to stake out the position that only those certs which comply with the relevant standards, policies, etc. will be accepted. Indeed, much of the other discussion on this list of

Re: BR compliance of legacy certs at root inclusion time

On Tue, Aug 22, 2017 at 12:01 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 21/08/17 06:20, Peter Kurrasch wrote: > > The CA should decide what makes the most sense for their particular > > situation, but I think they‎ should be able to provide

Re: BR compliance of legacy certs at root inclusion time

On 21/08/17 06:20, Peter Kurrasch wrote: > The CA should decide what makes the most sense for their particular > situation, but I think they‎ should be able to provide assurances that > only BR-compliant certs will ever chain to any roots they submit to the > Mozilla root inclusion program. So

Re: BR compliance of legacy certs at root inclusion time

I don't think Mozilla ‎can tolerate having certs that successfully chain to a root contained in its trust store that are not BR compliant.The end user trusts Mozilla products to provide a certain level of

Re: BR compliance of legacy certs at root inclusion time

On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen wrote: > From the perspective of being "clean" from a given NSS version this, > makes sense. However the reality for most situations is there is > demand to support applications and devices with trust stores that have > not been

Re: BR compliance of legacy certs at root inclusion time

On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy wrote: > On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Sometimes, CAs apply for inclusion with new, clean

BR compliance of legacy certs at root inclusion time

I'll speak up for transparency again. In terms of policy the most vital thing is that a CA tells us about such certs during application. One way to do that would be to CT log them, but especially for small sets there might be other sensible ways. If we can't be shown the certs in question (or

Re: BR compliance of legacy certs at root inclusion time

[Intro; long time lurker but I rarely post, but given this is an open question not directly tied to any CA or official capacity my opinions are..] On 08/18/2017 05:02 PM, Gervase Markham via dev-security-policy wrote: > Sometimes, CAs apply for inclusion with new, clean roots. Other times, > CAs

Re: BR compliance of legacy certs at root inclusion time

On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Sometimes, CAs apply for inclusion with new, clean roots. Other times, > CAs apply to include roots which already have a history of issuance. The > previous certs issued by

BR compliance of legacy certs at root inclusion time

Sometimes, CAs apply for inclusion with new, clean roots. Other times, CAs apply to include roots which already have a history of issuance. The previous certs issued by that CA aren't always all BR-compliant. Which is in one sense understandable, because up to this point the CA has not been bound