On Mon, Oct 7, 2019 at 12:20 PM Jeremy Rowley <jeremy.row...@digicert.com>

> 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

Reply via email to