Hi Corey, Comments inline:
> Modifying the certificate to include the appropriate key usage will > ensure alignment with BRs Section 7.1.2.1, but it also creates an > additional violation given Sectigo’s CP and CPS prohibit modification. > > As far as I am aware, there is currently no blanket prohibition in the > Baseline Requirements or in Chrome or Mozilla Root Policy on certificate > modification. Additionally, I don’t believe Sectigo has added this language > in their CP/CPS as a pledge to the community to remediate a previous > incident. Given this, would an amendment to the Sectigo CP/CPS prior to > certificate modification resolve the concern here? Correct, there is no prohibition on modification at this time by the BRs or the Chrome and Mozilla root program policies. The additional policy violation that the modification would have triggered wasn't our primary concern (which was that even with a modified certificate to include the digitalSigature key usage, the signing key still corresponds to a valid certificate that does not). Suppose Sectigo updated its policies to clearly state that CA certificates may be modified and retain the same subject public key. In that case, we'd essentially be looking at the same remediation as the GTS issue. In my last message, I noted that although this was not the preferred remediation, we'd be willing to accept it when considering the previously established community precedent and the absence of risk to Chrome users. So, although modifying the policy documents would free us of the secondary issue, the primary one still exists. > As far as I can tell, there are only two paths that would avoid the > introduction of additional policy violations in the process of aligning > with the BRs: > > 1. Establish a delegated responder and stop direct OCSP signing using > the CA’s key > > > 1. Migrate to a new root with the appropriate key usage > > > There may be a third option which avoids the complexity of OCSP delegated > responder key management but resolves the compliance and potential client > interoperability issues. The root can issue a self-signed end-entity OCSP > responder certificate (same name + key as the root, but BC cA=False and EKU > = id-kp-OCSPSigning and KU=digitalSignature, etc.) and all subsequently > generated OCSP responses will include this certificate in the “certs” field > of the BasicOCSPResponse. This will provide clients with the certificates > necessary to validate the OCSP response signature, as they can build a > certification path of root -> OCSP delegated responder certificate. Would > such a solution also remediate the issues? If the key signing responses corresponds to what would then be three different certificates (2 CA certificates and one acting as a responder), how can we reliably guarantee which one(s) clients will use during response validation? 6960 states the optional certs field is intended to *help* the client verify the responder's signature, but I don't know enough to say that it guarantees the use of the provided certificate. It would also seem that by introducing another doppelgänger certificate with a different intended function than the existing certificates, we're adding unnecessary complexity into the ecosystem (personal opinion). Thanks, Ryan On Wed, Dec 22, 2021 at 9:06 PM Ryan Sleevi <[email protected]> wrote: > > > On Wed, Dec 22, 2021 at 2:41 PM Corey Bonnell <[email protected]> > wrote: > >> Do you agree that this is the goal of the requirements, or do you see it >> differently? >> > I’m not sure I understand the question here, or it’s bearing on the > compliance aspect. Could you help me understand how this is compliant with > the requirements written? > > It sounds like, based on the question you posed, that the answer is “This > doesn’t comply with the BRs, but might help achieve the presumptive goal.” > That’s not to say that’s not an interesting area worth exploring, if the > goal is to change the requirements, but I’m not sure it addresses the > immediate issue here? > > If you believe (as your later reply suggests), that it complies, perhaps > you can add more detail about how you see the private key usage being > acceptable here, when considering doppelgänger certificates being - and > remaining - in scope, regardless/independent of the BasicOCSPResponse. > > Recall: the core issue is the use of the private key, and the > certificate(s) associated with that private key. Doppelgängers of > self-signed certificates - that is, certificates with the same subject, > issuer, and subject key - are all intrinsically linked together in scope, > because each signed each other, and that’s key to understanding this issue. > > The BasicOCSPResponse tricks here, which are not part of the signed data > nor necessary to the verification process of the response, seem to amount > to ignoring that relationship, which is why I’m struggling to see how > that’s compliant. > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-fgVp7GLSwF4voDMBWGy8uket3k1QUyq90ADY5-DQg4g%40mail.gmail.com.
