There has been some discussion about this, and what it means. With the help of Matt Hogstrom, I now understand this a bit more.
Background
Symmetric encryption is when you change A-> B->6 etc. You use the same mapping to decrypt as you used to encrypt. If you have the mapping to encode, you can decode it. If several people use the same mapping – you can read other people’s messages.
Most digital encryption is done these days using asymmetric encryption. With an asymmetric encryption there are two keys. You encrypt with one key, and need the other key to decrypt it.
You make one key public, so anyone can have access to it, and keep the other key private and secure.
- When you encrypt with my public key, and I decrypt it with my private key.
- When I encrypt with my private key, you decrypt with my public key, and you know it came from me, because you used my public key.
A certificate is a package of a public key, and other information such as who it belongs to, what the certificate can be used for, and validity dates. This is packaged up, sent to a certificate authority, who digitally signs it, and returns it.
TLS is a protocol for exchanging information between a client and a server. As part of the handshake the server sends down the server’s certificate. The client checks the digital signature, and if valid, can use the enclosed public certificate to encrypt data to be sent to the server.
The problem
Your organisation, (company or country) has been using the same certificate, and so the same public key for the last 10 years. Some bad guys have been monitoring the network traffic from your organisation during this time, and saving it on tape.
Somehow the private key has escaped. Perhaps the person who looks after the plants was bribed to come in and steal the private key, or you left your laptop on the train. The bad guys have 10 years worth of data, and your private key, and can now read all the traffic sent to and from you!
This scenario has been recognised as a problem.
One solution is to change the public/private keys more frequently.
This leads to a different problem,
How often do you change the public/private key?
A year is too long. Every day is too much of an overhead. Let’s aim for one month – 30 days.
It may be that the person whose job it is to renew certificates take annual leave (up to two weeks). It would be unfortunate for a certificate to expire because that person has just gone on holiday, so let’s allow two weeks for this (Friday to Monday, 16 days). We need to give them a day to go through their mail inbox – so let’s set an expiry interval of 30 days + 16 days +1 = 47 days.
What do you renew?
In the discussion people were talking about renewing the certificate. You can renew the certificate, but specify the old public key – this defeats the purpose of the change.
You need to renew your public/private key every 47 days, and as a consequence, renew your certificate. You do not just renew the certificate with the old key.
What’s the impact?
A certificate is about to expire, so you renew it. You have a program using the old certificate. Your program needs to read the new certificate. This may mean stopping and restarting your program. For those programs which are operational all day, every day, you need to factor restarting your program. This may mean restarting it every Sunday night between 0200 and 0400. If the certificate expires during normal operation you have an emergency set of changes; renew the certificate and restart your application.
This change is for certificates used in TLS, transfering information between client and server. The certificate has a flag saying this can be used as a server, or a client (but do not specify both).
A certificate with its public key can be used for other purposes besides TLS.
For example, signing data.
Signing data
When a file is signed, you calculate the checksum (a hash value) of the file, encrypt this checksum with your private key, and attach this encrypted checksum, and your certificate to the file.
When you receive the signed file. You extract the certificate, validate it, and use the public certificate to decrypt the encrypted checksum. You do the same checksum calculation on the data and compare the two checksums. If they match the data is as the originator provided.
In this case, the public/private key does not have the same problem as TLS. The originator could be recreating the public/private key every week, it would not affect you with the package.
Intermediate certificates
You may not want every user’s certificate to be sent to the commercial certificate authorities for digital signing. You could have your own Certificate Authority.
You send a certificate to the commercial Certificate Authority, and get it signed. You then use this certificate to sign all certificates in your organisation. In this case a user’s certificate has two CA certificates attached to it. When validating a certificate the code checks that the commercial CA matches what is stored in the computer. If that matches, it uses the public key in that certificate to validate the checksum from your CA. If that matches then the public key from your CA is used to validate the end certificate.
If any CA certificate has expired, the whole certificate chain will fail validation. In this case you need your intermediate CA to be long lasting. One of the commercial CA’s has a validity period of 17+ years!
Summary
Renewing a certificate used in Client to Server (TLS) communications should have the public/private keys renewed regularly. It is recommended to have no more than 47 days.
You may want other certificates, which have longer validity periods, such as intermediate certificates.
You may want certificates where you do not care how often the public/keys are refreshed – such as code signing.
One lesson from this is you should have a different public/private key/certificate for each area; TLS, CA, and signing. The areas have different requirements.
ColinPaice 