Clarify when Root CAs may stop issuing CRLs

[aarongable]

The BRs v2.0.2 Section 4.9.7 says:

CAs MUST continue issuing CRLs until one of the following is true:

• all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR
• the corresponding Subordinate CA Private Key is destroyed.

The beginning of this sentence just says "CAs", meaning that it applies to both Subordinate CA Certificates which issue Subscriber Certificates, and Root or Subordinate CA Certificates which issue Subordinate CA Certificates.

However the two subsequent bullet points only reference Subordinate CA Certificates and Subordinate CA Private Keys.

It is totally possible for there to be a Root CA which has never been cross-signed, and therefore has no corresponding Subordinate CA Certificates nor a Subordinate CA Private Key. This means that we don't actually have rules around when such a root is allowed to stop issuing CRLs.

I propose the following change, which simply removes the word "Subordinate" from the two bulleted items:

CAs MUST continue issuing CRLs until one of the following is true:

• all CA Certificates containing the same Subject Public Key are expired or revoked; OR
• the corresponding CA Private Key is destroyed.

I think this change is a good candidate for inclusion in a larger cleanup ballot.

[timfromdigicert]

This does not make a lot of sense to me. Whether a root has subordinates or not is completely independent of whether it is cross-signed. Roots without subordinates are extremely rare, as they're mostly useless and therefore not contemplated often :)

I think you're mixing up Subordinate CA with Cross-signed Subordinate CA, but that's just a guess.

[aarongable]

Does the following sentence make sense: "A Root CA MUST continue issuing CRLs until the corresponding Subordinate CA Private Key is destroyed"?

To me, it does not. A Root CA does not necessarily have a Subordinate CA Private Key -- it only would have such a key if it had been cross-signed (and thereby also become a Cross-Certified Subordinate CA in addition to being a Root CA). So to me, there are two ways to fix the sentence:

1. "A CA MUST continue issuing CRLs until the corresponding CA Private Key is destroyed"; or
2. "A Subordinate CA MUST continue issuing CRLs until the corresponding Subordinate CA Private Key is destroyed".

Both fix the mismatch, but the latter leaves open the question of "but what about Root CAs?", so I prefer the former.

---

I think the confusion is arising because I interpret "the corresponding Subordinate CA Private Key" to correspond to "the CA" which is issuing the CRL, while you're interpreting it to refer to any of the CAs which may appear on the CRL?

[timfromdigicert]

Ah. Ok, I get where you went astray. The majority of the uses of "CA" in the Baseline Requirements actually are intended to be read as "CA Organization" not "CA Certificate" we spent quite a bit of time on that a bunch of years back, but never finished it up by updating the document in a ballot with which was which. We probably should. You're right that this particular case is particularly egregious, since "Root CA" makes even less sense.

What it is trying to say is essentially the following:

"A CA organization operating a Root CA must continue issuing and signing CRLs for that Root CA until all private keys corresponding to all Subordinate CAs signed under that CA Root have been destroyed."

Now that I see where you're getting confused, I agree that it is saying it extremely badly and we should fix it.

[timfromdigicert]

Also note that the correct reading has a different meaning that your reading: the relevant private keys are the private keys of subordinates of the root CA, not the root CA's private key itself. The entire possibility that the root might itself be a subordinate of something else due to cross signing is an additional complication that can complicate the analysis in complex PKI scenarios, but that's not the primary situation being contemplated here. The language is unclear even without pulling in that additional potential complication.

[aarongable]

Hmm, but the preceding three paragraphs ("Within 24 hours of issuing its first Certificate, the CA MUST...", "CAs issuing Subscriber Certificates: ...", and "CAs issuing CA Certificates:...") all clearly use "CA" to refer to a specific certificate/keypair, not to organizations. And this language was written very recently (in SC-063) so I think the most reasonable interpretation is for the use of "CA" to be consistent at least across these four paragraphs.

I think the use of "...containing the same Subject Public Key..." is what really locks it in for me: the same as what? It can't just mean "the same as each other", as there are thousands of completely unrelated (e.g. issued by totally different CA organizations) certificates which contain the same public keys as each other but are irrelevant to this CA. So it has to mean "the same as the CA", in which case the CA at the beginning of the sentence refers to a keypair, not an organization.

Also, your interpretation ("A CA organization ... must continue issuing and signing CRLs for that Root CA...") would mean that the BRs place no requirements on when Subordinate CAs which issue Subscriber Certificates can stop issuing CRLs. And the first bulleted point would mean "A CA organization operating a Root CA must continue issuing and signing CRLs for that Root CA until all Subordinate CAs under that Root are revoked" which is clearly bad.

Regardless, I think we're in agreement that the current phrasing is very bad and needs to be replaced.

My original proposal here does have an obvious flaw now that I think about it more: it doesn't address situations like the DST Root CA X3 cross-sign of ISRG Root X1, where the Cross-Certified Subordinate CA Certificate outlives the Root CA Certificate which issued it. My proposal would allow the expired DST Root CA X3 to stop issuing CRLs before the cross-signed ISRG Root X1 expires, which is a problem.

So here's an alternate proposal:

CAs MUST continue issuing CRLs until one of the following is true:

• the CA's Private Key is destroyed; or
• all certificates issued by the CA are expired.

This, I believe, captures the desired behavior very simply: A given CA certificate/keypair has to keep producing CRLs as long as there are any certificates capable of being revoked, unless you do an audited key destruction ceremony that makes it physically impossible to continue doing so.

[techliaison]

You might want to include in there something about not intentionally destroying the CA keys until all certificates signed by it have either expired or been revoked. If any unexpired certs were revoked, the CA should be able to issue a long term CRL that doesn't expire until after that last issued certificate expires. (This situation may be more useful in the context of a Root CA that has issued cross-certs or subordinate CA certs since CA certs tend to be for longer periods than subscriber certificates.)

From: Aaron Gable @.> Sent: Thursday, February 15, 2024 1:48 PM To: cabforum/servercert @.> Cc: Subscribed @.***> Subject: Re: [cabforum/servercert] Clarify when Root CAs may stop issuing CRLs (Issue #484)

Hmm, but the preceding three paragraphs ("Within 24 hours of issuing its first Certificate, the CA MUST...", "CAs issuing Subscriber Certificates: ...", and "CAs issuing CA Certificates:...") all clearly use "CA" to refer to a specific certificate/keypair, not to organizations. And this language was written very recently (in SC-063) so I think the most reasonable interpretation is for the use of "CA" to be consistent at least across these four paragraphs.

Also, your interpretation ("A CA organization ... must continue issuing and signing CRLs for that Root CA...") would mean that the BRs place no requirements on when Subordinate CAs which issue Subscriber Certificates can stop issuing CRLs. And the first bulleted point would mean "A CA organization operating a Root CA must continue issuing and signing CRLs for that Root CA until all Subordinate CAs under that Root are revoked" which is clearly bad.

Regardless, I think we're in agreement that the current phrasing is very bad and needs to be replaced.

My original proposal here does have an obvious flaw now that I think about it more: it doesn't address situations like the DST Root CA X3 cross-sign of ISRG Root X1, where the Cross-Certified Subordinate CA Certificate outlives the Root CA Certificate which issued it. My proposal would allow the expired DST Root CA X3 to stop issuing CRLs before the cross-signed ISRG Root X1 expires, which is a problem.

So here's an alternate proposal:

CAs MUST continue issuing CRLs until one of the following is true:

• the CA's Private Key is destroyed; or
• all certificates issued by the CA are expired.

This, I believe, captures the desired behavior very simply: A given CA certificate/keypair has to keep producing CRLs as long as there are any certificates capable of being revoked, unless you do an audited key destruction ceremony that makes it physically impossible to continue doing so.

- Reply to this email directly, view it on GitHubhttps://github.com/cabforum/servercert/issues/484#issuecomment-1946939667, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENXKO7JTVCWXIKREUPFFHTYTZJ63AVCNFSM6AAAAABDKSPN66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWHEZTSNRWG4. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

[timfromdigicert]

I agree that we want something simple that expresses the security policy and requirements instead of diving into the weeds on details, so I like how simple your proposals are getting. Don't you want 'expired or revoked', though? It seems to me that if you want to revoke all your subordinates and post a final CRL for the root, that probably should be allowed even if not all subordinates have expired.

The question of subordinates remaining valid and outliving roots due to cross signs is a policy question, and perhaps one that should be discussed independently of clarifying this bad language. When it happened, several of us were rather surprised to discover after digging into the requirements that it was not prohibited. Whether it's a good practice or not is something that perhaps should be debated.

[aarongable]

Don't you want 'expired or revoked', though? It seems to me that if you want to revoke all your subordinates and post a final CRL for the root, that probably should be allowed even if not all subordinates have expired.

Yeah, I considered that, but I don't think we do want "or revoked" in there. Suppose a Subordinate CA Certificate issues only a single Subscriber Certificate which expires 398 days in the future. It then revokes that certificate, and publishes that information in a CRL with a nextUpdate at most 10 days in the future (per BRs 7.2 CRL Profile). At this point all certificates issued by that CA have been revoked... but we definitely don't want it to stop publishing CRLs because the last CRL is going to become invalid before the revoked certificate expires.

The same applies to a Root CA which issues and subsequently revokes a Subordinate CA Certificate -- the Subordinate CA could be valid for another five years, while the CRL in which it is revoked is only valid for at most one year.

Personally, I think the solution in both these cases is straightforward: if you want to revoke all your issued certs and then stop publishing CRLs, do a key destruction ceremony.

[aarongable]

You might want to include in there something about not intentionally destroying the CA keys until all certificates signed by it have either expired or been revoked.

I actually think this is a good idea. What if the language were changed to:

CAs MUST continue issuing CRLs until one of the following is true:

• all certificates issued by the CA are expired; or
• all certificates issued by the CA are expired or revoked and the CA's Private Key is destroyed.

I think this would be a slightly bigger change, and worth more debate / discussion that might be afforded in a clean-up ballot, but I like this direction.

[timfromdigicert]

"The same applies to a Root CA which issues and subsequently revokes a Subordinate CA Certificate -- the Subordinate CA could be valid for another five years, while the CRL in which it is revoked is only valid for at most one year."

Well, obviously a revoked certificate does not become unrevoked just because a CA fails to refresh their CRLs in a timely manner, though I do understand that some certificate processing systems may unfortunately fail open in this scenario. If a CA is issuing one year CRLs, they have implicitly signed up to issue another before it expires.

The standard practice here though is that the last CRL issued when shutting a CA down has a much longer lifetime ... in fact we should probably clarify explicitly that that's allowed. I.e. if you issue a CRL that revokes all your subordinates, you can give it a long lifetime and no further updates are necessary. Key destruction would be possible and even desirable at that point.

I thought issuing one last CRL was documented in 5280 but couldn't find it in a quick search, maybe it was from somewhere else.

[aarongable]

The standard practice here though is that the last CRL issued when shutting a CA down has a much longer lifetime ... in fact we should probably clarify explicitly that that's allowed. I.e. if you issue a CRL that revokes all your subordinates, you can give it a long lifetime and no further updates are necessary.

While I believe you that this may have been standard practice in the past, and I freely admit that my four years of experience in the WebPKI are dwarfed by many others around here, this is surprising and sounds bad to me.

A CA could issue a long-lived CRL revoking all of its subordinates, go quiescent for a year, and then begin issuing again. Then none of its new subordinates could be effectively revoked, because a malicious actor could provide CRL consumers with the old still-valid CRL instead of any newer one.

[techliaison]

Aaron My experience with a CA issuing a long term final CRL is ONLY in conjunction with the termination of the CA, including destruction of all copies of its keys.

My first email describing this was in response to your email containing: So here's an alternate proposal: CAs MUST continue issuing CRLs until one of the following is true:

• the CA's Private Key is destroyed; or
• all certificates issued by the CA are expired

I was trying to say that a CA's Private Key should not be intentionally destroyed until either all certificates it was used to issue had expired or been revoked. If any of those revoked certificates are not also expired, a long term CRL with a nextUpdate past the latest expiration date should be created before the Private Key is destroyed. That long term CRL must be available until the last issued cert has expired. In other words, you don't want to destroy a CA's Private Key while there are still unexpired valid certs out there that may require revocation in the future.

RFC3647 has a section to describe how a CA is terminated: 5.8 CA OR RA TERMINATION That section also requires the inclusion of how they will deal with archive records and who should be notified of the termination. Currently the BRs leave 5.8 blank, but if you are going to propose language about destroying a CA's private key, that is the section where it might be appropriate.

From: Aaron Gable @.> Sent: Thursday, February 15, 2024 5:52 PM To: cabforum/servercert @.> Cc: Brown, Wendy (10421) @.>; Comment @.> Subject: Re: [cabforum/servercert] Clarify when Root CAs may stop issuing CRLs (Issue #484)

The standard practice here though is that the last CRL issued when shutting a CA down has a much longer lifetime ... in fact we should probably clarify explicitly that that's allowed. I.e. if you issue a CRL that revokes all your subordinates, you can give it a long lifetime and no further updates are necessary.

While I believe you that this may have been standard practice in the past, and I freely admit that my four years of experience in the WebPKI are dwarfed by many others around here, this is surprising and sounds bad to me.

A CA could issue a long-lived CRL revoking all of its subordinates, go quiescent for a year, and then begin issuing again. Then none of its new subordinates could be effectively revoked, because a malicious actor could provide CRL consumers with the old still-valid CRL instead of any newer one.

- Reply to this email directly, view it on GitHubhttps://github.com/cabforum/servercert/issues/484#issuecomment-1947467658, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENXKO6BGBNGRUIFKCDAPPTYT2GQFAVCNFSM6AAAAABDKSPN66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXGQ3DONRVHA. You are receiving this because you commented.Message ID: @.**@.>>

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

[timfromdigicert]

A malicious CA can also post its private key to the internet, or offer to sign arbitrary content. Once you enter the world where the CA is intentionally performing actions that violate previous commitments, you have left the land of Trusted Third Parties.

Doing what you describe, such as issuing from a CA that has been intentionally shut down, is a rather severe compliance violation that the root programs would come down pretty hard on.

[CBonnell]

In what scenario is it desirable to revoke every non-expired certificate a given CA has issued and destroy the CA key material but not revoke the CA itself? The only case I can think of is the issuance of (document) signing certificates, where signatures need to be validated in the future and the revocation/invalidity date of CRL revocation entries is significant. But, that case is not relevant for TLS serverauth certificates. The simplest approach is to merely revoke the (subordinate) CA in question. Doing so relieves the CA (organization) from the obligation to issue and publish CRLs.

Given this, I'd be supportive of entirely removing the following clause from the BRs:

CAs MUST continue issuing CRLs until one of the following is true: - all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR - the corresponding Subordinate CA Private Key is destroyed.

And replace it with:

CAs MUST continue issuing CRLs until all certificates issued by the CA have expired.

[BenWilson-Mozilla]

I would rephrase that to allow for a long-lived CRL. A second phrase might be needed that covers the life of the CRL instead of just the issuance of CRLs.

[techliaison]

As I said originally, this is more likely with a CA that issues subordinate or cross-certs than one that is issuing subscriber certs, because the subordinate CA certs may be for a longer validity period. One case might be that you are trying to migrate to a new Root CA since the browsers are pushing for shorter CA lifetimes and more agility. So maybe you stand up a new root, issue CA certificates to any subordinates that still have valid subscriber certs from that new CA, revoke them from the old Root and decommission the old Root rather than continuing to operate it in parallel. You would also need to notify any browsers that may be including the old Root in its trust stores and ask them to distrust it. As has been discussed many times, there is no real way to revoke a self-signed root cert, but you don't want to keep those old keys around just to keep signing CRLs for another few years.

You may want to do this even if none of the subordinates are moved to the new Root - you just want to terminate the entire PKI under the Root to be decommissioned., but it signed a couple of 10 year subordinate CA certs 2 years ago that still have 8 years left till expiration. Do you want to require that Root to retain its private key for the additional 8 years so it can resign the same CRL (with all unexpired issued certificates revoked), once a year or is it more secure to issue an 8 year CRL and destroy the Root's keys?

Speaking from experience, not all PDVAL libraries clean out revoked or expired CA certificates from their trust stores without some management. So the retiring PKI would want to ensure that if revocation is actually being checked by RPs, there are no valid paths still in existence to that old, decommissioned Root, regardless of whether it is still being distributed as a trusted Root in the browsers in the CAB Forum.

[aarongable]

(Nota bene: I am on vacation for the next two weeks, so likely won't respond again until March.)

On 2024-02-16, @techliaison said:

I was trying to say that a CA's Private Key should not be intentionally destroyed until either all certificates it was used to issue had expired or been revoked.

Totally agreed. That's why my most recent proposal changes "the CA's private key is destroyed" to "all certificates issued by the CA are expired or revoked and the CA's Private Key is destroyed."

On 2024-02-16, @timfromdigicert said:

A malicious CA can also post its private key to the internet, or offer to sign arbitrary content. Once you enter the world where the CA is intentionally performing actions that violate previous commitments, you have left the land of Trusted Third Parties.

Sure, but my "revoke everything, go quiescent, start issuing again" example isn't necessarily about a malicious CA. It could be about a CA that legitimately expected to never use the intermediate again, but then revived it during an emergency or to serve a new customer. I think it is incumbent upon the BRs to not encourage behavior which can totally innocently lead to bad security outcomes. Long-lived CRLs are dangerous, and the BRs recognize that -- we shouldn't add in a carve-out which allows them to exist in one weird corner case.

On 2024-02-16, @CBonnell said:

In what scenario is it desirable to revoke every non-expired certificate a given CA has issued and destroy the CA key material but not revoke the CA itself?

In the case that the CA itself is a Root CA, since revocation of Root CAs is questionably effective (should the CRL signed by the root be trusted, given that the entity which signed it is revoked? do trust stores care about revocation at all? etc).

On 2024-02-16, @techliaison said:

Do you want to require that Root to retain its private key for the additional 8 years so it can resign the same CRL (with all unexpired issued certificates revoked), once a year or is it more secure to issue an 8 year CRL and destroy the Root's keys?

No, I don't -- my most recent proposed language would instead have that Root undergo a key destruction ceremony, and then it can stop issuing CRLs. Or, if a key destruction ceremony is infeasible, then yes, it should continue issuing CRLs for the whole remaining period.

---

Currently, I still think that the following language is the best we've come up with so far:

CAs MUST continue issuing CRLs until one of the following is true:
- all certificates issued by the CA are expired; or
- all certificates issued by the CA are expired or revoked and the CA's Private Key is destroyed.

I don't think anything has been said which indicates that a CA should continue issuing CRLs once either of those conditions has been met. And I don't think any additional cases in which a CA could stop issuing CRLs have been raised.

From here, I seem to be seeing two categories of proposals: a) make it even simpler, requiring ongoing CRLs until everything is expired, no matter what; or b) make it more complex, allowing for a single long-lived CRL when the CA is being shut down.

Neither of these holds much appeal for me. The former is unfortunate for exactly the reasons @techliaison described: a CA should not be forced to keep key material around just for the sake of continuing to issue CRLs. The latter I am both personally opposed to from a policy standpoint, and sounds like a major pain to draft airtight language around. Are there strong arguments to the contrary on either point?