Stupid question around the issuing CA lifetimes for 6-day certs

Issuance Tech
1

This is a brand new thought (to me) and I need to get this out there before I lose it. Sorry if this has already been debated. This post is "rambly" in nature.

We're talking about 6-day certs. Cool, I'm all for it. So here's a thought ... why are the issuing CA certs in operation for longer than 12 days?

I mean if you think about it, the hardest part of a PKI's chain of trust is the root(s). Everything you do below the root is determined by your certificate lifetimes so that you can comfortably renew things at the half-life (yes, I'm applying some old school thinking here).

Is there opportunity here to apply the same logic to subscriber certificates one level higher in the chain?

I know what you're probably thinking - we don't want to bring up the HSMs all the time to sign the issuing CA certificates. I hear you. Sign the certificates, just don't put them into service.

Let me throw together an example assuming a spherical calendar in a vacuum. I'm oversimplifying.

  1. Create RSA issuing CA keypairs 1..30.
  2. Create EC issuing CA keypairs 1..30.
  3. Bring up the root HSM on or before 2025-01-01. Sign the R1 and E1 certificates with an expiry date of 2025-01-13. Sign the R2 and E2 certificates with an expiry date of 2025-01-25. And so on until R30 and E30's expiry date on 2025-12-27.
    a. No one's signing certificates from 2025-12-27 through 2025-12-31 anyway, so we don't issue certs for those dates. /s
  4. Export the certificates from the root HSM as needed.
  5. 2025-01-01 until 2025-01-07, E1 and R1 are in service and issuing certificates. None of the other CAs are in service/used by boulder to sign subscriber certs.
  6. 2025-01-07 until 2025-01-19, E2 and R2 are in service/used by boulder to sign subscriber certs. None of the other CAs are in service/used to sign subscriber certs.
  7. Extend two previous points. You get the point.

Hell why stop there, why not go 7 day issuing CAs? Issuing CA only issues for 24 hours. Beyond that? Not needed, kill it off.

As with all things the balance between convenience and security must be achieved. The current issuing CA certs are issued for 3 years. Thinking here strictly of 6-day certs, why? Obviously we'll need separate CAs for 90-day certs.

As further food for thought, consider (ignoring leaps):

  • The root CAs have a lifetime of 20 years (7300 days).
  • The issuing CAs have a lifetime of 3 years (1095 days).

The ratio between the root and issuing? 6.66...
The ratio between issuing and a 90-day subscriber? 12.166...
The ratio between issuing and 6-day subscriber? 182.5

Something feels off here. This train of thought isn't even convincing/persuasive to myself but I do hope this is at least being considered.

2

There are probably many factors.

One factor though- read up on "Key Ceremony", aka "Key Signing Ceremony". The Roots are stored offline, and usually offsite hundreds of miles away, in extremely secure vaults. Accessing the root is a big deal, in terms of logistics and physical security. Signing an Intermediate requires staff visiting the vault, along with third party observers for auditing and compliance. Multiple Intermediates are signed at the same time - planned rotations and emergency backups - because of the logistics and expenses required for a key ceremony.

4 Likes
3

Key ceremony is exactly what I addressed in the middle portion of my post.

Don't sign 4 CAs, sign 120 CAs (numbers are estimates). Don't put them into service until you need to.

Maybe it's even possible with the right methods/software to modify the NotBefore time of the issuing CAs in addition to the NotAfter time.

4

What's the added benefit for these short lived intermediates?

5

Same reason as reducing the lifetime for any certificate. The less time a public exponent is in service, the less time it is exposed to all manner of threats.

This might even allow to drop keying sizes if we want and make crypto operations faster. Not that I'm necessarily in favor of that, I'm just continuing the discussion here. Never know where you might end up.

6

What you are describing is already (sort of) happening, altough at a (much) slower rate than you seem to be anticipating.

When Let's Encrypt first started, there used to be two intermediates, each valid for 5 years each: One active, one used as a backup.

Since then, Let's Encrypt has started to reduce intermediate lifetimes, and increase the number of non-active certificates: Right now, there are 4 active (E5, E6, R10, R11) and 6 standby (E7-9, R12-14) intermediates - all valid for a reduced time of 3 years. AFAIK, the current goal is to rotate these intermediates on a yearly basis i.e. the next pair of standby certificates will become the active at some point in the future.

Intermediate rotations have been nontrivial in the past: The web PKI has originally been designed as a mostly-static architecture with few changes anticipated: leafs used to be valid for 3 years, intermediates for 10, roots for 20-30. Since then effort has been applied to make the entire web PKI more agile and ready for changes, but changing millions of systems is never a fast process. Previous chain changes made by Let's Encrypt broke subscriber setups who hardcoded intermediates. Let's Encrypt is now trying to discourage this behaviour by randomizing the issuing intermediate, so that eventually intermediate changes will become painless.

Scaling down the intermediate lifetimes even further, e.g. to 180 active days in the future sounds reasonable, though I don't know if that's planned. Since the 90 day certificates are going to stick with us for the foreseeable future, intermediates need to keep them in mind. A dedicated chain for short-lived could be considered, but I don't see the urgent need for that.

It's important to recall why the 6 day certificates are even a thing (or will be): To get passive revocation, because (leaf) certificate revocation is broken. Shortlived certs expire naturally fast and eliminate the need for dedicated revocation infrastructure. Intermediates could also benefit from passive revocation - yes. However, the pressure is smaller for them: Intermediates are revoked, much, much less often than leaf certificates. The major browser vendors also all have dedicated first-party revocation infrastructure for CA certs: Meaning revocation is more reliable for intermediates than it is for subscriber certificates. This reduces the risk for intermediates. Thus, passive revocation for intermediates would be good to have, but is probably not realistically feasible it this point - but may be in the future.

4 Likes
7

Thanks for responding fully and cogently.

Yes - currently three years, but definitely doesn't need to be that long. If the new goal is indeed 1-year rotations/lifetimes that seems like a reasonable balance. I think last night I observed the root CRL had a 1-year lifetime, so there's some alignment there.

[Aside] Personally I roll my eyes at intermediate CA pinning - if you understand how x.509 PKI and AIA works there's never a reason for it.

2 Likes
8

Are you saying the current intermediate pairs E5+E6 and R10+R11 will be replaced by pairs E7+E8 and R12+R13 ? I always assumed LE would extend the sets of active intermediates from 2 to 4 each (providing more randomization). But re-reading the original announcement, it's not stated explicitly.

4 Likes
9

Yes

We intend to put two of each of the new RSA and ECDSA keys into rotation in the next few months. Two of each will be ready to swap in at a future date, and one of each will be held in reserve in case of an emergency. Read more about the strategy in our December 2023 post on the Community Forum.

swap in -> swapped with the current active set. I don't think there's much benefit to increase the number of active signers, but they do want the rotation.

AFAIK, the current randomization is a temporary thing anyway. LE engineers shared an idea (privately) some time ago that in the future, each DC will have local certificates that are not shared between DCs. Thus, the load balancer effectively decides what intermediate you're getting, but the DC itself doesn't randomize. Adding more randomization into the mix doesn't align that well with that idea.

3 Likes
10

Ok, I guess that makes sense.

However it was also suggested in that same thread:

From which I assumed they would be extending the initial sets of 2 issuing certificates to 4.
But just switching the pairs makes sense as well.

@mcpherrinm can you confirm that is indeed the plan?

Btw, and also:

Perhaps this changed with OCSP being taken out of the equation.

3 Likes
11

We are currently mapping out the future of our PKI, including upcoming roots and intermediates, etc.

We'll likely switch E5 and E6 to E7 and E8 (and R10/R11 -> R12/R13) some time this summer. Two of each type issuing at a time still.

We are not likely to do DC-specific intermediates at this time, but we may consider it in the future still.

7 Likes