Root Replacement with digitalSignature Key Usage to Sign OCSP responses

[Ben Wilson]

All,

This is a new thread that I'm branching off of the discussion that started here - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/K8NsiO-VCQAJ.

Additional background for this new discussion can also be found here:  https://bugzilla.mozilla.org/show_bug.cgi?id=1741777#c2.

The issue is whether it is appropriate to replace a root CA certificate (missing the digitalSignature key usage bit) with another root CA certificate (same key pair) that has the digitalSignature key usage bit set.

Section 4.2.1.3 of RFC 5280 says,

      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/.) 

Thanks,

Ben

[Kathleen Wilson]

All,

I need to finalize the December batch of root changes this week (Bug #1733003), which currently contains Bug #1735407, "Replace Google Trust Services LLC (GTS) root certificates in NSS", which is this exact scenario of this discussion -- replacing a root CA certificate (missing the digitalSignature key usage bit) with another root CA certificate (same key pair) that has the digitalSignature key usage bit set.

At this time I am inclined to remove Bug #1735407 from the December 2021 batch of root changes and put it as tentatively to be part of the March 2022 batch of root changes, so that we will have time for this discussion to come to full conclusion.

Does anyone foresee any problems with me postponing Bug #1735407 to March?

Thanks,

Kathleen

[Ryan Sleevi]

For what it’s worth, I think you can separate out the replacement part with the remediation part.

The concerns I raised on Sectigo’s issue were highlighting how replacement does not necessarily equate remediation, and the goal being to figure out what exactly the path towards remediation can or should look like. This is similar to, say, the discussion with SECOM re: https://bugzil.la/1707229 - and how simply issuing a new certificate, without addressing the old, doesn't remediate. That's not to say that there's reason to block this replacement in-and-of-itself (either by GTS or SECOM), but to acknowledge that the issue would still remain unremediated and unresolved, until some further action, either in Mozilla & BR policy or CA practice, occurred.

I captured further details about why this distinction matters, in https://bugzilla.mozilla.org/show_bug.cgi?id=1741777#c5 , in examining the current policies and expectations.

To be clear and explicit: With respect to the digitalSignature bit itself, I think this likely represents something minor on a technical level, but as I tried to capture, has some interesting dimensions from the policy and compliance angle. Sectigo's answer in that bug gave what they saw as the path forward, but didn't really capture what the alternatives considered were, what their impact was, and how that impact was assessed. These are things that I think should be reasonably addressed as part of a remediation plan.

As I tried to call out in https://bugzilla.mozilla.org/show_bug.cgi?id=1741777, and I'm sure especially with the preceding paragraph, bears reiterating: while I believe a very likely outcome is for someone to make a suggestion of "If you don't think this requirement is major, we should just change the requirement and declare things remediated", I also believe that would be taking the intellectually lazy path out, especially for long-term ecosystem health. The question of how to remediate issues like this is, I think, of prime importance to this community, and would benefit from more detailed discussion, such as a more careful analysis of the pros and cons of different approaches, and data that can support the path chosen. The discussion on the issue captures some of these trade-offs, and why I think that discussion is important for long-term ecosystem health, by being more explicit in downsides and risks for the proposed approach. This matters primarily if the proposed path (replacement) is being conflated with remediation, but as I said, we don't have to couple replacement and remediation because they are different.

As an example for "What might a data-driven decision look like", hopefully the bug captures why "replacement != remediation" at present. For discussing options for remediation, there's an obvious path suggested (on both issues) of using delegated signers. Sectigo raised concerns about delegated signers, namely a desire for "smaller response size, less complex, no added certificate lifecycle management burden, no additional HSM-based keys needed". Some of these seem subjective-to-the-CA benefits / aren't obvious why they would rank highly (e.g. HSM-based keys or certificate lifecycle management), some would benefit from more detail ("less complex"), and some would benefit from more data ("smaller response sizes").

To that last point, an example of "more data" could be similar to the work we see come out of other organizations that Mozilla works with have published. For example, Cloudflare shared a data-driven approach to exploring TLS certificate sizes and the effect on a variety of core performance metrics, in https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ . While discussed on the bug how some systems behave re: revocation of CA certificates (e.g. the use of browser-based lists or, in non-browser cases, preferences for CRLs over OCSP), if there's data to show about how often the root responder is queried, and how variances in that response size can affect client performance, could be useful. You could easily imagine an A/B test where a CA, such as Sectigo, issues two intermediates used for testing, one of which has direct-signed OCSP responses issued for queries about that intermediate, another which has delegated-responder signed. Issuing certificates for test sites under each intermediate could allow you to use A/B tests to explore both client metrics (e.g. as reported through existing browser performance metrics systems) and server metrics - as Cloudflare did. For context, the reason for two intermediates is to avoid confounding factors of using an existing intermediate (for which the client already has a primed cache for). When designing such a test, it can also be explored "Exactly how small can a responder be" and, similarly, explored whether there are compatibility issues with responder key sizes (e.g. an ECC responder will have a much smaller key than an RSA responder).

Of course, another alternative, which Sectigo only briefly alluded to in their response, is to look at doing a root transition - to work on fully sunsetting the existing roots, replacing with new roots which are truly new (i.e. new subject and key), and not just "replacements." Sectigo noted they are already exploring this path for other reasons, presumably cross-signing with their existing roots, and this is already what is practiced when such issues like this are detected during inclusion requests. I would imagine that the arguments against this remediation path might be similar: that is, that the increased chain means an increased response size (for older client compatibility, by including the cross-chain). But that's exactly the sort of analysis that these incident reports are meant to cover, by not only covering the "Here's what we're doing", but also exploring the "Here's the alternatives we rejected, and why - showing both we thought of them and here's our understanding about why these might not be best".

Why do I suggest all this work if it is, after all, potentially a "minor" issue, especially knowing how much I vocally criticize when CAs' make such subjective distinctions, as there is no such compliance distinction? Because incidents like this, and the whole goal of incident reporting, is to build shared knowledge, and to address the uncertainty and fear of change in a brittle system, to make CAs more confident of making changes, and how to do them successfully. It may very well be that the decision is to "not remediate" - to expect to see these as incidents listed in the audit reports going forward, as an acknowledgement of the non-compliance, but which root programs might decide (in this limited, specific incident, and for limited, specific CAs), is the best of a bad set of options. I'm not sure the data is there at present to support the conclusion, but I'm not foreclosing on this possibility.

To reiterate: I don't think you need to block the replacement over resolution of this. It's just that replacement is separate from, and neither here nor there, for remediation of the issue, objectively and technically speaking, and so that's still an outstanding issue for Sectigo to weigh.

--
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.

[Kathleen Wilson]

>>  replacement is separate from, and neither here nor there, for remediation of the issue, objectively and technically speaking

Given this information, and that Bug #1735407 is about replacing currently-included root certificates so it does not add risk, I will keep Bug #1735407 in the December 2021 batch of root changes.

Thanks,

Kathleen

[Ryan Dickson]

[Posting on behalf of Google Chrome]

Hi Ben,

A few thoughts for last week's discussion, sorry for the delay:

1. We do not feel that this discussion should delay Sectigo’s remediation planning to align with the BRs or the inclusion of any other approved root that previously performed the same type of certificate modification. Unless/until this behavior is explicitly prohibited, it’s unfair to change course now.  
2. The primary concern in Sectigo’s case is that their Web PKI CP and CPS indicate, “Sectigo does not offer Certificate modification. Instead, Sectigo will revoke the old Certificate and issue a new Certificate as a replacement.”  
3. Long-term, to reduce the potential for interoperability issues and promote simplicity, should we look to prohibit both CA certificate renewal and modification and instead promote the establishment of new CAs (encouraging crypto agility) - either through the BRs or by way of root program requirements?  If this discussion is best served in a separate thread to avoid detracting from the immediate issue at hand, no problem.
4. In the spirit of points above, and alongside personal views shared by Ryan Sleevi, a root transition and subsequent CA decommissioning would be the optimal path forward to comply with the commitments made in Sectigo’s policies and, by extension, the BRs.

Thanks,
Ryan

--
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.

[Ben Wilson]

Thanks for the comments received so far. I'd like to close discussion on this next Tuesday, 14-Dec-2021.

Discussion of Issue #3 (discourage CA certificate renewal/modification and encourage new CAs for crypto agility) could be started in a new thread. 

We could also submit the issue on Github - see https://github.com/mozilla/pkipolicy/issues.

Thanks again,

Ben

[Rob Stradling]

Earlier in this thread, Ryan Sleevi wrote:

> For what it’s worth, I think you can separate out the replacement part with the remediation part.

Hi Ryan (Dickson).

Regarding your first thought, I understand you're stating that replacing ("modifying") root certificates is something that CAs are permitted to do today; and indeed, I haven't yet seen anyone suggest otherwise.

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.  Please could you clarify the Chrome Root Authority Program's view on this?

---

From: 'Ryan Dickson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: 08 December 2021 12:58
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>; Ryan Sleevi <ry...@sleevi.com>; Ben Wilson <bwi...@mozilla.com>
Subject: Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O9YnCy3%2Bcgcygs084Q4_bg_4i5xqrLseK_Syb3NqL7puw%40mail.gmail.com.

[Ryan Sleevi]

On Fri, Dec 10, 2021 at 3:12 PM Rob Stradling <r...@sectigo.com> wrote:

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. 

Rob,

I’m a bit surprised to see the verb “perceived” here; it suggests that you may not think there’s a non-compliance issue with the existing practice? I haven’t seen the final F2F minutes posted yet from the most recent CA/Browser Forum, but from both CAs and root programs, and from the bug itself, there seems to be no disagreement, except by Sectigo previously, that there is in fact a compliance issue. I’m not trying to be difficult, but I was just surprised a bit to see if phrased like that.

If we accept a compliance issue, then the questions that remain is whether OCSP responses are issued by certificates, or by key pairs/subject names, and whether these alternative versions of roots are in scope. That is, the only way this solution could be remediation is either if the (new) responses are only tied to the (new) certificate, or if replacement somehow fully removes the (old) certificate from scope.

It’s unclear your position on both of these. Mozilla Policy has clarified several times of doppelgängers being in scope, even explicitly within policy. Similarly, we’ve seen plenty of incidents with other CAs who have similarly understood and acknowledged the scope, and even crt.sh reports these as disclosure required, as I understand it.

If the digitalSignature-less certificate is in scope, and remains in scope as transitively valid, then the only way it seems it could not be non-compliance is if an OCSP response is somehow tied to a certificate, rather than a keypair.

We know a responderID byKey is tied to the shared key of both certificates, ergo the response is issued by either/or/both, and byName is tied to the subject name, which is also shared by both.

Perhaps you can explain where the compliant view comes in? It’s unclear if you’re arguing doppelgängers are or should be out of scope, or if this is revisiting the earlier argument suggesting the BRs don’t actually require digitalSignature for direct signing (the legacy roots).

I totally appreciate you’re looking for clarity from Ryan, but for those of us on the list (… or a beach 😅), perhaps you can articulate how you see the solution proposed complying with policy? It doesn’t seem that replacement can or should be able to declare “old” as out-of-scope, given that the whole purpose of replacing old with a doppelgänger is to keep everything signed by it valid and accepted.

Just because replacement doesn’t remediate, it doesn’t shut down conversation or remove options. It just necessitates explaining and sharing more data showing the things being taken into consideration. That said, if your goal is unambiguous remediation - without having to worry about BR kremlinology or consequences - it seems rolling to a new key, as Sectigo already planned to do, is the best way to resolve that. Why wouldn’t that be an appropriate (long-term) remediation? It’s unclear if the answer from Ryan is meant to change that prioritization, and if so, why it would?

[Ryan Dickson]

[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:

1. Establish a delegated responder and stop direct OCSP signing using the CA’s key

2. 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

[Rob Stradling]

Thanks Ryan.  We acknowledge that you share Ryan Sleevi's concern that "modifying" our root certificates would not remediate the compliance concern.  We are discussing how to move forward on this matter and expect to be able to announce an updated remediation plan in early January.  We'll follow up at https://bugzilla.mozilla.org/show_bug.cgi?id=1741777.

---

From: 'Ryan Dickson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Sent: 16 December 2021 22:23
To: ry...@sleevi.com <ry...@sleevi.com>
Cc: Rob Stradling <r...@sectigo.com>; Ben Wilson <bwi...@mozilla.com>; Kathleen Wilson <kwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--

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.

[Corey Bonnell]

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:

1. Establish a delegated responder and stop direct OCSP signing using the CA’s key
2. 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?

 

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.

[Ryan Sleevi]

On Wed, Dec 22, 2021 at 1:37 PM 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

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?

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.

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?

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.

[Corey Bonnell]

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:

[Ryan Sleevi]

On Wed, Dec 22, 2021 at 2:41 PM Corey Bonnell <Corey....@digicert.com> 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.

[Ryan Dickson]

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

[Peter Bowen]

Ryan,

I've read the whole thread here, the bugs linked, and prior
discussion, but am still somewhat confused about the actual issue. I'm
hoping you can clarify.

On Wed, Dec 1, 2021 at 1:42 PM Ryan Sleevi <ry...@sleevi.com> wrote:
>
> I captured further details about why this distinction matters, in https://bugzilla.mozilla.org/show_bug.cgi?id=1741777#c5 , in examining the current policies and expectations.
>
> To be clear and explicit: With respect to the digitalSignature bit itself, I think this likely represents something minor on a technical level, but as I tried to capture, has some interesting dimensions from the policy and compliance angle. Sectigo's answer in that bug gave what they saw as the path forward, but didn't really capture what the alternatives considered were, what their impact was, and how that impact was assessed. These are things that I think should be reasonably addressed as part of a remediation plan.

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?

If so, I respectfully disagree with your view. From many prior
discussions on this list, we know that a CA is defined by its public
key and its distinguished name tuple. In a graph, the CA is a vertex
(or node). Certificates are edges in the graph, not vertexes.
Certificates do not control what the CA key can and cannot be used
for. The BRs clearly differentiate between Certificates and keys in
multiple places. For example, section 6.1.7 calls out "Private Keys
corresponding to Root Certificates" and Mozilla policy section 5.3
calls out "signed with a Private Key whose corresponding Public Key is
encoded in the SubjectPublicKeyInfo of that CA certificate or
intermediate certificate".

Given that the BRs and Mozilla policy understand that certificates and
keys are separate, it is not surprising that both explicitly restrict
the usage of the keys. Section 6.1.7 of the BRs has specific limits
on one usage of CA keys and Sections 5.1.1 and 5.1.2 of the Mozilla
policy do limit the types of signatures that can be created: "When a
root or intermediate certificate's [type] key is used to produce a
signature, only the following algorithms may be used". Neither the
BRs nor the Mozilla policy have an overall limit on what data can be
signed. I believe that limiting it would be good for security and
good for the WebPKI, but is not relevant to what is allowed today.

Given this, it seems there is not a policy or BR violation signing
OCSP Responses any more than there would be if a CA signed JSON Web
Tokens using its key. The relying party or application software may
not accept these due to software defined policies that require a
certificate for the key with certain attributes, but that is not the
question. If Mozilla (or another root program) wants to require
something specific, it should be documented. As Rob Stradling has
pointed out, the requirements to sign an OCSP response are hazy at
best. We know that Mozilla prefers id‐kp‐ocspSigning (OID:
1.3.6.1.5.5.7.3.9) for OCSP response signing, given section 5.1.3 of
the policy says "CAs MAY sign SHA-1 hashes over OCSP responses only if
the signing certificate contains an EKU extension which contains only
the id-kp-ocspSigning EKU."

I suggest that the Mozilla policy or the BRs be updated to clarify
several things:
1) What content can be signed by a CA key. It should require all
content be the result of encoding an ASN.1 structure using DER and
enumerate the acceptable ASN.1 structures.
2) Explicitly state that CA key usage is independent from CA
certificate contents.

Thanks,
Peter
(my personal view and does not necessarily reflect the views of anyone else)

[Ryan Sleevi]

On Wed, Dec 29, 2021 at 3:18 PM Peter Bowen <pzb...@gmail.com> wrote:

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?

Not quite, at least how you framed it.

That is, I think you're spot on and we're in very much agreement about the vertices being (CA key, DN), which is also how it's reflected in tools like crt.sh (e.g. the CA ID), with certificates linking as edges between these vertices.

To borrow from that terminology, I think we can agree that a self-signed certificate effectively serves as an edge that is a self-loop. That is, for a self-signed certificate, the Subject DN == Issuer DN, and the SPKI == Signing Key, we draw an edge from the vertex back to itself, with that edge being the self-signed certificate.

The distinction here is that doppelgangers for CA certificates also serve as self-loops between these (Key, DN) tuples. If you have Cert A (using Key 1, Issuer DN == Subject DN == DN Foo), and Cert A' (using Key 1, Issuer DN == Subject DN == DN Foo), then we can say that A issued A', and A' issued A. If we're imagining these as vertices and edges, then for A and A', there are two edges between the vertex (Key, DN) - the first edge is a self-loop A, the second edge is a self-loop A'.

When it comes to building paths to the vertex (Key, DN), then we can build a path [A], [A'], [A, A'], and [A', A], while paths such as [A, A], [A', A'], [A, A', A], and [A', A, A'] are prohibited by X.509 (specifically, Section 10.1(a), at least in 08/2005).

This is explicitly called out in RFC 4158, Section 5.2 (and Section 2.4.2), when discussing paths that are valid in RFC 5280 (Section 6.1.3) but can otherwise cause suboptimal loops. From an RFC 5280 perspective, if we imagine a CA A, CA A' (as above), and EE B, then the possible valid paths here are [[A, B], [A', B], [A', A, B], [A, A', B]].

As a first check for possible disagreement:

1) Do we agree that [A, A', B] and [A', A, B] are valid paths?

  - If we don't agree, we should dig into that more, to figure out if there's a misunderstanding of the relevant documents.

Assuming we agree here, the next possible source of disagreement is:

2) Is the following statement accurate, assuming A is a trust anchor: "A' is an intermediate certificate which has at least one valid, unrevoked chain up to a CA certificate included in, or under consideration for inclusion in, the Mozilla root program"

  - If we don't agree, we should dig into that more, because this can have some truly interesting consequences for what misissuance means.

Note that, in tools like CCADB and crt.sh, there's been an understanding that both A and A', because they share (Key, DN), are considered "in-scope". For example, disclosure is required for these certificates; if A' is encountered in CT, for example, and not disclosed in CCADB (at minimum, as an intermediate of A), then it's been treated as a failure to disclose and a violation of policy. This is what I mean when I say that doppelgangers have been considered in scope. Section 5.3 of Mozilla's policy makes this very explicit, in the discussion of "directly or transitively chain to a CA certificate", by defining the technical properties that apply here, and Section 5.3.2 applies the audit and disclosure requirement.

If these two previous statements hold, then the conclusion is that, on encountering an OCSP Response, Signed by Key 1, issued by DN Foo, then the OCSP response is signed by both A and A'. Both A and A' are subject to policy and the BRs, as the alternative can have quite interesting consequences.

If A and A' differ in their capabilities - for example, in key usage - then one of them has violated the BRs, and thus, policy. By A existing, it means you cannot create an A', because even if A' replaces A as the trust anchor, the path [A', A, B] remains valid, A is subject to the BRs, and A is thus violating the requirements. A and A' share a Root CA Private Key, and the nature of the valid transitive paths mean that there is, indeed, no remediation, at least as it applies to root certificates, that would allow you to use Key 1 to sign OCSP Responses while asserting DN=Foo.

Now, to briefly discuss Section 8.1.5 of X.509, which specifically touches on how to extend the capabilities of the CA with DN=Foo to include other key usages. If we read this as a closed-set (i.e. a default deny), then the scenario being described is that A' is being created to serve as a "type b)" certificate (e.g. used to add OCSP signing to a CA that lacks the capability for its public key). However, in this scenario, the expectation is a key change event, certifying a new public key, such that you're really creating a Certificate C, which shares the DN (DN=Foo), but contains a different key (Key 2). Certificate A/Key 1 signs Certificate C/Key 2, and the path for certificates remains [A, B], while the path for OCSP responses is [A, C]. This is, in effect, a delegated OCSP signing certificate whose DN (Foo) is shared between A and C, but which otherwise represents distinct paths. Understandably, if you read Section 8.1.5 as an illustrative set (i.e. default allow), this argument doesn't hold, but it's also not key to understanding the scope issues touched on above.

Of course, this scenario (of DN=Foo being associated with both Key 1 and Key 2) has its own set of complications, as some CAs have discovered in the context of generic key rollover (i.e. rekeying for expiration purposes). That's why I intentionally elided it from the set of options here, and which tracks with your own past thoughts on the binding between DN and Keys [1].

[1] https://archive.cabforum.org/pipermail/public/2016-November/008966.html