On Mon, Oct 7, 2019 at 12:20 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote:
> For example, suppose a root was created before a rule went into place and > the root needs to be renewed for some reason. If the root was compliant > before creation and modifying the profile would break something with the > root, then there's a good argument that you shouldn't modify the root > during the resign. That assumes the reasons are discussed here and > alternatives are explored fully. This should then be documented (including > the reasons) in an incident report and the subsequent audit. > For sure. Note that because Root 1's Subject was non-conforming (and pre-BR enforcement, even though post-BR), there's nothing to work around with on that Subject. It, more or less, needs to be retired. It's unfortunate this was missed during the inclusion request, as I think it would have dramatically altered the request: CAs have been rejected for failing to conform to the profile, so it's unfortunate that during the whole process, no one spotted this. However, it "should" have come up during the review prior to cross-signing, which is ostensibly why there's an incident with that CA. The solutions all involve retiring that root (since it can't be cross-signed), or creating a new root, and cross-signing it by two different parents (i.e. it prohibits a linear history). > > Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. > But I could see there being reasons for the CA to do so. > > (And I haven't scanned CT to discover if it is us. Crossing my fingers > it's not 😊. If I don't scan, it's like a terrible version of Christmas.) > It's not DigiCert (or its many aquisitions) To your follow-up question: - At least within mozilla::pkix (relevant to Mozilla) and Chrome's handling of CRLSets, revocation is integrated as part of the path building algorithm, allowing alternative paths to be found. However, that's not necessarily the case for other certificate path building and verification libraries, and revocation could have impact. That is, of course, all the more reason that CAs should be extremely diligent in their cross-signs, to avoid creating issues, and to rotate names early and often. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
