On Wed, May 28, 2014 3:19 pm, Kathleen Wilson wrote: > On 5/25/14, 9:53 AM, Kurt Roeckx wrote: > > On Tue, May 20, 2014 at 11:23:54AM -0700, Kathleen Wilson wrote: > >> Maybe we should re-visit the idea of a "wall of shame", and publicly > >> list > >> the CAs who are still issuing certificates with the following problems. > > [...] > >> * Certificate not version 3 > > > > I've only seen 1 such subscriber certificate, but I see 14 such > > certificates in the CA root list. > >... > > Do we also want all the root CAs to change to v3? > > > > I've been checking the cert version for roots during the > inclusion/approval process, so those version 1 root certs must be old -- > issued before the Baseline Requirements initial Effective Date of 1 July > 2012. > > So really the question is: Should we have a project to proactively > remove those old version 1 roots? > > Kathleen >
For roots, it really doesn't matter. A root certificate is, at least as implemented in NSS, nothing more than a container format for a set of user-visible strings (the cert metadata) and a (public key, subject name) tuple of a trust anchor. Whether it's version 1 or 3 has no effect on path building. If the policy does require this, it's largely for cosmetic reasons than any strong technical reasons. That said, cutting a new v3 root may involve bringing the root signing key out of storage, hoisting a signing ceremony, etc. It may not be worth the cost. NSS could, if it wanted, create dummy certs (with invalid signatures) that looked just like the real thing, and things 'should' just work (mod, you know, the inevitable avalanche of bugs that crop up when I make statements like this). _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
