When designing the validity period of a Certificate Authority (CA), many factors have to be taken into consideration: Lifetime of the parent CA, desired lifetime for issued certificates, key algorithm used, and security of the private key. Now let’s look into what you have to take into account when looking at each of the factors mentioned.
Lifetime of the parent CA and desired lifetime for issued certificates are both based on the fact that CAs cannot issue certificates that are longer than their lifetime. Let’s look at a scenario where you want to issue 2 year certificates in a two tier PKI. The intermediate CA’s validity period has to be larger than 2 years, ideally you would want to be able to achieve at least one rotation of certificates before having to rotate the CA, meaning that the intermediate CA’s validity period has to be larger than 4 years. Industry standards would recommend to have an intermediate CA of 5 years and create a new intermediate CA to replace it after 2.5 years, giving IT administrators enough time to push the new intermediate CA certificate to clients before the 3 year mark where the first intermediate CA would not be able to issue 2 year certificates. Once we have established the lifetime of the intermediate CA we can establish the minimum validity period for the root CA: >10 years.
Another factor that affects the maximum lifetime of a certificate’s validity period, is the cryptographic strength of the algorithm being used. In 2018, Chris Adams and Ben Shy from Microsoft presented a session where they recommended the following lifetimes for key lengths based on how long it takes to break each key:
| RSA Key bit length | ECDSA Key bit length | Maximum Validity Period |
|---|---|---|
| 1024 | 160 | not greater than 6-12 months |
| 2048 | 256 | not greater than 2 years |
| 4096 | N/A | not greater than 16 years |
Last but not least, you have to consider how will the key private key be secured. If a private key is not secured by a hardware security module, it is not recommended to issue keys with validity periods larger than a month (making it a requirement to have HSM backed certificate authorities). For HSM backed CAs that are kept online, the industry standard is a validity period of ~5 years. However, this number might change based on: security threats, administration overhead, system availability, and the costs of issuing new intermediate CA certificates.
CRL Validity is very dependant on your revocation practices for that specific CA. If you do not revoke certificates very often, staying with the recommended standard of 7 days is ideal. However, if you revoke certificates often, or cannot afford a compromised certificate to maintain access to the infrastructure up to a week after it has been revoked. A shorter CRL lifetime or a delta CRL is recommended. It is important to note that shortening the CRL time will increase your network traffic from the clients needing to download the CRL more often and will also increase the probability of an outage due to not distributing a CRL on a timely manner.
For offline root certificate authorities the recommended best practice for CRL validity is 6 months to a year. This is due to the CRL publishing requiring manual intervention from the PKI team (sometimes requiring traveling to a secure location). 6 months is a good compromise between reducing management costs, while also doing it often enough that the PKI team does not forget the procedure.