Key rotation at reissuance


#1

Continuing the discussion from Pros and cons of 90-day certificate lifetimes:

Thanks!

Are there specific, deployed systems you’re thinking of? I’m aware of Convergence and TACK. I believe Convergence to be mostly defunct, but I think it should work regardless of key rotation interval. And TACK can definitely work regardless of key rotation interval, but is not implemented in any browsers.

I agree. This, to me, is a big missing piece of Certificate Transparency. Or, to put it another way: it intentionally wasn’t designed into CT, and I agree we still need a solution that will help prevent individual compromises.

However, I don’t think that having servers use a consistent public key for a year contributes to any of those solutions. Any solution needs to deal with the fact of key compromise, which means that a server may need to change its key with zero lead time. So there needs to be a way for clients to receive trusted information about that key rotation almost instantaneously.

That is currently the default.

Besides the potential disadvantages of key rotation we’re discussing above, there is also at least one advantage: For sessions that do not negotiate forward-secret cipher suites, rotating and deleting the server key narrows the window during which a key compromise would expose past sessions.

This reminds me, though: currently the client does not delete old, unused keys, which it probably should do after a reasonable grace period.


#2

Hi, i can understand the reason for key rotation with outdated cipher suites not using PFS.
But to delete the key automatically i would say even if the idea behind it is good should not be done.
Because there can be documentation requirements or other requirements.
This should be enabled via explicit command line switch i think.


#3

That sounds like a good plan.