Why not set Root CA CRL for Sub-CA to be really long?

Question

I am designing a two-tier AD-CS PKI and when it comes to the Root CA I am struggling to understand the validity period of the CRL which is used to validate the sub-CAs by end entitites.

Documentation appears to recommend 3months, 6months or 1yr but what I don't really understand is, why not longer?

I'm planning on 5yr certs for the sub-CAs so they will be renewed at 2.5yrs, following the half-life cycle. Why then should I set the CRL from the Root to be less than that and just cause myself administrative overhead of powering on the Root every few months to refresh the CRL?

I am thinking about what a CRL is actually used for and I understand that the longer the validity period of a CRL, the longer it remains in the cache of a client. But, I'm also thinking about the cirucmstances that I might actually revoke a sub-CA's certificate, i.e., key compromise.

Am I really then supposed to wait several months or even a year for end entities to update their cached CRL with the most recent one which will contain the revoked CA cert and only then will they stop trusting and using the certificates issued by the compromised CA?

Surely immediate remediation steps are going to be taken? Revoking the CA will be the first step but then I will be standing up a new sub-CA, creating a new key pair and start issuing new certificates to all the entities, adding the compromised CA to their untrusted store, manually clearing their CRL cache and forcing them to get the new one.

It seems that the routine of bringing the Root CA online every few months is just a needless ceremony because when push comes to shove, that long CRL validity is going to be useless. Wouldn't it just make more sense to only bring the Root online to issue a new CRL if the sub-CA needs to be revoked?

Answer 1

I completely agree with you -- you seem to understand the complexities of the issue.

Let's look at the extremes:

1. CRL Lifetime = subCA Lifetime. ==> the CRL is completely useless; you have no ability to revoke the subCA because so long as the previous CRL is within its validity period, clients have no reason to fetch a new one, unfortunately that's how the protocols work.

2. CRL Lifetime = 1 hour. We have to change how we think about "offline" root CAs.

I agree that 3 months or 1 year seems like a worst-of-all-worlds compromise.

The high-value production CAs I've worked with take the latter approach and keep the root CAs in a "root firewall zone" that allows CRL data out, to be picked up and published by a machine in the DMZ, but no other connections. You still need physical access to the root CA box for anything other than fetching CRLs. The auditors we work with are satisfied to call that "air gapped".

I even heard of one clever solution sending CRL data out over the Line-Out audio jack!