The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), ....(Using a CA with the digitalSignature key usage bit set to sign OCSP responses is discussed somewhat here: https://mailarchive.ietf.org/arch/msg/pkix/0eZNhjidM89nB8vBbb_W7XL-QV8/.)
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6d5313f6-390b-4523-8b05-2d7f97461d22n%40mozilla.org.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/98f61dfe-6389-4fbb-b611-fe73b336addbn%40mozilla.org.
However, I'm not clear if you intended your post to also convey an opinion on Ryan Sleevi's view (expressed at https://www.mail-archive.com/dev-secur...@mozilla.org/msg00224.html and in https://bugzilla.mozilla.org/show_bug.cgi?id=1741777) that the GTS and Sectigo root replacement plans will not actually remediate the perceived non-compliance issue.
[Posting on behalf of Google Chrome]
Hi Rob,
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.
Further, this example highlights one of the challenges associated with CA certificate modification, particularly when considering root CA certificates that cannot be revoked. Unless certificate consumers or relying party applications have a mechanism to distrust the existing certificate, it could still be used during OCSP response validation. While I do not believe this specific scenario introduces security or interoperability concerns for Chrome users or other relying parties, the “problem” 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:
Establish a delegated responder and stop direct OCSP signing using the CA’s key
Migrate to a new root with the appropriate key usage
We would prefer if Sectigo committed to one of the two options above.
However, in the case of GTS, the community established a precedent, perhaps unintentionally, that modification was an acceptable mechanism for addressing the missing key usage issue. Consequently, we are willing to accept Sectigo’s proposed path forward (i.e., modification), recognizing that:
the original violation is not fully remediated
the resolution triggers an additional CP violation that must be reported and included in a future audit report
As stated in my last post, to further promote ecosystem improvement and reduce possible future confusion, we will continue exploring whether certificate modification should be prohibited long-term.
We'd be happy to hear other perspectives from the community.
Please let me know if you have any questions.
- Ryan
Hi Ryan,
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?
> 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:
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?
Thanks,
Corey
From: 'Ryan Dickson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Thursday, December 16, 2021 5:23 PM
To: ry...@sleevi.com
Cc: Rob Stradling <r...@sectigo.com>; Ben Wilson <bwi...@mozilla.com>; Kathleen Wilson <kwi...@mozilla.com>; dev-secur...@mozilla.org
Subject: Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses
[Posting on behalf of Google Chrome]
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O94rdDGZJrQVHrQnZ0Ms2_14KRw5xLNJ%2BuUb32x4%3DK8Yw%40mail.gmail.com.
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?
Hi Ryan S.,
> Isn’t this effectively suggesting that a certificate, not a key, signs a response? That doesn’t seem to square with any of the technologies in play.
> That is, such an OCSP response would still be signed by the root’s private key, which is the key issue here.
My understanding is that the requirements surrounding the inclusion of the digitalSignature KU have in mind a theoretical client that will reject OCSP responses unless the client can build a certification path (through being presented such certificates through the “certs” field of the BasicOCSPResponse, local policy, etc.) where the signing key is certified to create digital signatures (i.e., KU includes digitalSignature). CAs are under an obligation to serve OCSP responses that will be accepted by this theoretical client, but we know from BR section 4.9.9 that CAs may employ OCSP delegated signing certificates to accomplish this.
Do you agree that this is the goal of the requirements, or do you see it differently?
> This approach would have significant comparability risk, for all the issues that doppelgängers have to begin with, so it doesn’t seem to be functionally any different. It seems like the goal is to work around the CPS issue, but that wouldn’t address the underlying compliance issue, right?
This solution would provide the theoretical client described above with sufficient information to verify the signature on the OCSP response, so I believe it does resolve both the compliance issue and the practical client interoperability issue.
> Note: While the key reuse issue is the functional root problem, even ignoring it, this option would have issues, in that the certs field of the BasicOCSPResponse isn’t part of the signed data - it’s supplemental data. So the signature is still not bound to the “new” certificate.
Not sure why this matters here, because this is a general issue for all delegated OCSP signing; an attacker can mangle the response to strip out such information so that the client rejects the response. But if they can do that, they can likely just block the response entirely from ever being received by the client, achieving the same goal.
Thanks,
Corey
From: Ryan Sleevi <ry...@sleevi.com>
Sent: Wednesday, December 22, 2021 2:02 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Ryan Dickson <ryand...@google.com>; dev-secur...@mozilla.org
Subject: Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses
On Wed, Dec 22, 2021 at 1:37 PM 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:
Do you agree that this is the goal of the requirements, or do you see it differently?
> 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.
> 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:
- Establish a delegated responder and stop direct OCSP signing using the CA’s key
- 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?
From the bug above, and linked bugs, it seems that the status issue is
that the root certificate profile in the current version of the BRs
says "If the Root CA Private Key is used for signing OCSP responses,
then the digitalSignature bit MUST be set." You are asserting that if
_any_ certificate exists that identifies a CA in the Mozilla trust
store as the subject exists that does not assert the digitalSignature,
then that CA key may not directly sign OCSP responses. For example,
if CA in the Mozilla trust store has an old v1 certificate issued
before the BRs, then it cannot directly sign OCSP responses, even if
the certificate in the Mozilla trust store is v3 and has the
digitalSignature bit asserted. You appear to be asserting that there
is no possible remediation action that can be taken by the CA operator
to allow this - the only two actions would be Mozilla updating the
Mozilla policy to explicitly allow this or for the CA/BF to modify the
BRs to either remove the requirement or clarify that the sentence is
not normative.
Is this an accurate representation of your view?