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 Answers 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.)

  • 1
    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
    Commented Jun 23, 2015 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? Commented Jun 23, 2015 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
    Commented Jun 23, 2015 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. Commented Jun 23, 2015 at 16:24

First, the purpose of this extension is context specific. From Rec. ITU-T X.509, " Private key usage period extension":

NOTE 3 – In general, this Specification does not associate any semantic with this extension. Any particular use of this extension will have to specify the semantic associated with that usage.

Now, some possible use for that extension that I can think of is for commercial/billing purposes.

For example, if a CA is about to sign a TSU certificate for an external TSA and it wants to limit the TSA to sign time-stamps tokens (TSTs) for only one year (private key usage period) but let the final time-stamping users to validate the TSTs for six years (the full certificate public key validity), this way, providing them more time to perform time-stamp refreshing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .