On 8/3/17 5:27 PM, Kathleen Wilson via dev-security-policy wrote: > On Thursday, August 3, 2017 at 4:34:27 PM UTC-7, Ryan Sleevi wrote: > In bug #1311832 there is a note about cross-signing: > "[1] The new (replacement) root certificates may be cross-signed by the > Affected Roots. However, the Affected Roots may *not* be cross-signed by the > new (replacement) root certificates, because that would bring the concerns > about the Affected Roots into the scope of the new roots. Due to the way we > are implementing the distrust, the new root certificates must have a Subject > Distinguished Name that does not overlap with the Subject Distinguished Names > listed above." > > I don't see anything expressly forbidding cross-signing of new roots, but > perhaps that was an oversight.
The issue in my eyes isn't necessarily the cross-signature (though the delay in disclosure is a problem), it's using a publicly-trusted CA to fine-tune the issuance process. It's perfectly understandable to sign invalid certificates that violate aspects of root policies and the BRs while proceeding with your test plan. I've certainly done that myself. It's not acceptable to me that the test plan used a CA that either already was or subsequently became publicly-trusted. This is a professional PKI operation, being overseen by industry veterans. If something as concrete as the issuance process had such a glaring quality assurance methodology failure, why should anyone believe that something much harder -- subscriber validation -- is going to be done correctly? I agree that Mozilla should add these intermediates to OneCRL. > Along this line of discussion, I have not felt comfortable with StartCom's > current root inclusion request (bug #1381406), because Hanno raised a concern > about the private key used by the new root is also used by two intermediate > certificates, one of them revoked. This doesn't see like good practice to me, > and I'm not sure that Inigo's response is sufficient. So, I'm also wondering > if I should close Bug #1381406 and request StartCom to start completely over > with their new CA Hierarchy, and get it right, before creating their next > root inclusion request. I agree, it's not good practice, even if it's not prohibited. Since this brings it up, we should consider prohibiting it going forward. Keys, and space on HSMs for keys, are certainly not free, but they aren't so expensive that the Web PKI should suffer the costs of ambiguous mappings of keys to CAs. CRLs and OneCRL revoke trust based on issuer/serial combinations. If this key were compromised in some way, we would need to have knowledge of, and revoke, all combinations. We've discussed before needing a way through OneCRL (or OneCRL 2.0) to revoke based on public key hash; this is part of the reason why. J.C. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
