4

In the section about certificate extensions, the ITU-T X.509 recommendation writes:

The private key corresponding to a certified public key is typically used over a different period from the validity of the public key. With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key. The validity period of the certificate indicates a period for which the public key may be used, which is not necessarily the same as the usage period of the private key. In the event of a private key compromise, the period of exposure can be limited if the relying party knows the legitimate use period for the private key. There is therefore a requirement to be able to indicate the usage period of the private key in a public-key certificate.

I don't understand why there is a difference in public vs private key validity period. Why would the private key be used over a different period? When the private key is compromised, there is no point in using the public key anymore. Except to authenticate a message that we know has been issued before the private key's compromission. But then why would the public key lose validity after some time?

2

But then why would the public key lose validity after some time?

One reason is that the way certificates are signed might become outdated.

For example because either the hashing algorithm or the signature algorithm/key length is too old.

Take the hashing algorithm for example. At the moment SHA-1 signed certificates are on the way out. Because that hash no longer seems secure.

And before SHA-1 was used there was MD5 in certificates. And that has been phased out as well. (And people had to ask their CA to please resign their public keys with some other, stronger parameters. MD5 -> SHA1, SHA1->SHA2, etc.)

  • That's a good answer, but not the real reason why. As the quoted text says: With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key – Jacques Jun 23 '15 at 12:17
  • Okay, I answered the question "Why does the cert/pubkey expire?". What I didn't answer was "Why does the privkey expire first?" -- And I'd say that's because this way around makes sense. Example: You sign something from 2000 to 2005. You trust the cert/pubkey to verify this from 2000 to 2015. If it were the other way around it'd be absurd. You'd keep on signing stuff, but you'd not trust any key to verify the signatures. In that case, why sign at all anymore? I'm confused. Is this what you meant? – StackzOfZtuff Jun 23 '15 at 14:36
  • The way I understand your explanation, it would (only?) make sense in a scenario where the private key is assumed broken in 2006 and the certificate's signature is assumed broken in 2016, and the verifier got the certificate somewhere between 2006 and 2015, but knows that the message was signed by the private key before 2005? – Jacques Jun 23 '15 at 15:47
  • Yes. And you'd need to be sure that the document was in fact signed before 2006. One way to that is to embed another signature. Namely a signed timestamp. -- Now that signature will not last forever either. So you need to resign fresh timestamps on top of it every 10 years or so. I'm fuzzy on the details but there's an interesting related question on Crypto-SE. – StackzOfZtuff Jun 23 '15 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.