How should CA keys be replaced in a PKI system?

[cooper]

The question sounds like something I should be asking Google, and I did but it's rather mum on the subject.

So here's the deal:

When you use asymmetric cryptography, you vigilantly protect your private key while anybody can have your public key. But the two are linked and to be able to use the one you need to have done something with the other. The problem is that at some point your private key will expire. That means that the outside world that took in your public key needs to not only expire your old key aswell, but accept your new key as a replacement key for you.

How do people set about achieving this?

My paranoia is such that I DO NOT trust the current crop of so-called trusted third parties such as the Verisigns and GeoTrusts of this world. I work in healthcare transporting some rather private and very personal information of patients and when I choose to trust you, I will trust YOU. Not some nameless entity that supposedly has its shit together and as a direct result anything else it chooses to trust that I don't have ANY intention of trusting.

My paranoia paid dividents when mere years ago dutch government CA's DigiNotar and GemNet were hacked. The outcome was that DigiNotar was shut down and GemNet decided to stop using a default, password-less PHP-MyAdmin for administering the underlying DB (hrmm, yeah, now there's a thought...) and continue under a different name (KPN Locale Overheid).

My current approach however highlights a problem. The entities that do get their cert into our truststore typically have certs with a 1 to 5-year lifetime set to them. That sucks because in the case of the 1-year certs I get an email once a year, hopefully of an impending update but typically a complaint that a service died on us, because a cert has been or soon will be replaced. And the changeover is of the 'big bang' variety. One moment the service uses cert A and the next it's cert B. I can add cert B to our truststore ahead of time, which nicely deals with the client-side of things, but what about the server-side? At any given time there can only be 1 private key protecting a service. When I replace the key here, unless I'm missing something, the old key (and associated cert) stops being accepted.

Now much of this can be dealt with using procedures, informing users of our service that we'll be changing our cert over on DAY Z at XX:XX local time which is 4 weeks from now and here's the new cert for that, but what happens when it's one step closer to CA territory? Since we have a lot of systems with a lot of services each with their own cert, the company wants us to be our own CA and when your CA signs subdomain certs, that cert will show this. When you need to replace the CA keypair, shouldn't the certs signed by that key be invalidated aswell? I feel like I'm missing something...

I can imagine a procedure where a CA cert lasts, say, 10 years, is used for up to 5 years to sign certs that can last themselves for up to 5 years (so the last-signed cert expires on the same day as the CA cert) and all new certs are signed using the new CA key. That would probably work, but is that how others do it?

I've been dealing with certificates for the better part of 10 years now and typically explain their use and workings to others, but this one bit I just can't get my head around. Maybe someone here can enlighten me?

Edited May 19, 2014 by Cooper

[Lost In Cyberia]

I could be way off, but isn't this where 'intermediate certs' come in? https://support.globalsign.com/customer/portal/articles/1217450-overview---intermediate-root-certificates

Where the intermediate can be changed, revoked etc.. but the root stays the same?

[cooper]

But at some point the root expires. Then what?

[Lost In Cyberia]

True... lol this feels like a philosophical question, like the existence of god or something.