Update 04.08.2018: clarified behavior on timestamping certificate revocation
Hello again! Today I would like to discuss about digital signatures and signature usage questions.
As you know the signature guarantees that the electronic document wasn't changed after signing process. This is a useful feature for sensitive data that may be changed during transfer over network. For example, Internet. There is one well-known attack named Man In The Middle (MITM). In MITM, malicious user intercepts document change some data and transfer to the original recipient. If the document is originally signed (by sender) the recipient will attempt to validate document signature and will see that the document was changed during data transmission. This would invalidate the document.
In real world digital signatures are used very often and use asymmetric encryption/decryption processes.
What is the asymmetric encryption? This encryption type is based on two cryptographic keys — public (this key is available to any user without restriction) and private or a secret (held by the key owner. No one except the owner should know this key) key. These keys are mathematically related so if something is encrypted by one (public or private) key then encrypted string can be decrypted by corresponding second key (private or public). These mathematically related keys usually referred to key pair. In other words, anything that is encrypted by a public key can be decrypted by corresponding private (or secret) key only and vice versa.
How the signing process work?
As you see original hash is encrypted by user's private key. Encrypted string (or sequence) can be decrypted by user's public key. Since the public key may be available to any other user (and as the result can be decrypted by anyone) this encryption type don't guarantee data confidentiality, only integrity!
After that the recipient calculate a hash for a document by using the same hashing algorithm as was used during signing process. If the document is not changed both hashes (calculated by a recipient and extracted from the signature) MUST match and the document is considered as valid. If they don't match then the document was changed by unauthorized person and the document considered as untrusted.
This is what digital signatures does! And here is a simple signature structure:
Pretty simple (actually there is nothing complex).
Windows introduces 4 digital signature trust levels:
For what reason there are so many trust levels? Perhaps it should be simply Trusted/Untrusted? Yes, for certain scenarios this is enough, but not always. Applications use various trust levels depending on internal requirement. As there are many trusted CAs they issue a lot of signing certificates to various publishers. However it is common when we don't want to trust any document signed by these publishers. 4-level trust model allow us to trust only certain publishers and no more.
Suppose the following scenario. You have a signing certificate and you sign a lot of documents. Once, the certificate is expired, you receive a new one and continue document signing.
In normal case (like with SSL and other encryption certificates) once the certificate is expired, all signed data will be invalidated. You cannot connect to web server with expired SSL. However, you need to retain signatures valid even if the signing certificate is expired. One idea is to allow successful signing certificate (and signature) validation even after certificate expiration. However, this solution wouldn't be wise, because we would lost control over illegal certificate usage -- signing operations after signing certificate expiration. In addition, if signing key was compromised and it is confirmed that they was valid prior to specified date/time, we won't be able to tell whether the signature was generated prior or after compromise date.
To address this issue an additional service was introduced -- timestamping. According to wikipedia:
Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one – not even the owner of the document – should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised.
Usually timestamping services are provided by a trusted 3rd party authorities. They have a special device that synchronizes current time with world time sources and have signing certificates for timestamp signing. Signer calculates document hash (usually during signing process) and sends it to a timestamp server. Server append current date and time to a received hash and sign resulting data with its own timestamping certificate. Resulting message is called a signed timestamp. After that server return timestamp back to signer and signer attaches the timestamp to a document signature.
And how the timestamp is attached to a signature:
As you see the timestamp is not a part of a signed document hash (though this is a part of digital signature) so you can update only timestamp. But if you re-sign the document the timestamp will be updated (or removed if during re-signing process you decided to not use timestamps). Since both encrypted hash and timestamp contain document hash it is not possible to detach the timestamp and attach it to a different document to falsify actual signing time.
Next two sections (where each of them contains two subsections) will illustrate the signature validation outcome in different situations.
Suppose the following scenario: you have a document signing certificate with validity: 1 Jan 2015 - 31 Dec 2015. The following two sections will illustrate what will happen with the signature at various time points. First section assumes that you made signatures without timestamping and second scenario assumes that you made timestamped signatures.
The rule here is pretty simple: signatures can be validated only in a signing certificate's validity period time frame. If you attempt to validate signature (non-tampered) in a time frame between 1 Jan 2015 and 31 Dec 2015, validation will succeed. Any validation attempts beyond certificate's vlidity will fail. This is because we do not have any information about when signatures were created.
The bad news here is that when you receive new signing certificate (as a replacement of expired one), you would have to re-sign all previously signed documents, because they are no longer valid.
Validation rules here are a bit different. Since we have a trustworthy information about when the particular signature was created (this is achieved by including a signed timestamp in the signature) we can trust signatures created not only in a signing certificate's validity period time frame, but even after signing/timestamping certificate expiration. This is because we certainly know that the signature was made within signing certificate's validity period and nothing was changed.
As the result we can trust signatures if we perform signature validation even after signing certificate expiration. This scenario eliminates the requirement to re-sign all previously signed documents, because signing certificate is expired. Moreover, the signature will be trusted even if all certificates in both chains (signing certificate and timestamping certificate) are expired, including CA certificates. As long as both roots are explicitly trusted (are presented in the Trusted Root CAs container on the machine).
In short, we can trust timestamped signatures that were made with signing certificate's validity period and it doesn't matter when we perform this validation.
Note that we still can't trust signatures created at time frames outside of signing certificate's validity. The signature MUST be created within certificate's validity, otherwise, the signature is untrusted.
Here we extend previous example by adding an unfortunate case: the signing certificate was stolen/lost and eventually revoked.
You have a document signing certificate with validity: 1 Jan 2015 - 31 Dec 2015. The certificate (and its private key) was lost at 1st August, 2015. You took required actions to immediately revoke the certificate. The following two sections will illustrate what will happen with the signature at various time points. First section assumes that you made signatures without timestamping and second scenario assumes that you made timestamped signatures.
The rule here is pretty simple. If you attempt to validate signature between 1 Jan 2015 (signing cert's start validity) and 1 Aug 2015 (when the certificate was revoked and placed in CRL) we will trust the signature. However, after 1st August the trust will be ended. Once we found signing certificate in CRL, we will invalidate *all* signatures made by revoked certificates.
This is because we don't have any information about when particular signature was created, as the result we invalidate all signatures. Even if they were made prior to certificate revocation. Remember, that timestamps weren't applied, so this information is not available to us. In order to restore the trust to previously signed documents -- we have to re-sign them with new signing certificate.
In general, if the signature is timestamped, we can trust it if the signature was made within signing certificate's validity period. However, our scenario has a condition: the certificate was revoked. Since revocation date is presented in CRL and signature creation time is presented in the timestamp, we can safely trust all signatures generated between signing cert's start validity (1 Jan 2015) and till revocation date (1 Aug 2015). We can't trust any signatures created after 1st August, because the control over the key is lost.
The unobvious point here is that we can successfully validate signature even after signing certificate expiration (and the cert is actively listed in the CRL), because we know that the signature was made in the period when the key was not compromised.
This leads us to another revocation management best practice:
Some certification authorities (CA) remove expired certificates from their certificate revocation lists (CRL). However, for better security you SHALL NOT remove expired code/document/email/whateverelse signing certificates from CRL until the CA is fully decommissioned. Otherwise, you open a breach in successful signature validation when the signing key was revoked.
This section provides a quick table that shows signature validation status under all above described conditions.
Simple signature |
Timestamped signature |
|
Signing certificate (or certificate chain) is valid and not revoked | ||
Signing certificate (or certificate chain) is valid and is revoked before signing | ||
Signing certificate (or certificate chain) is valid and is revoked after signing | ||
Signing certificate (or certificate chain) is expired after signing | ||
Timestamping certificate (or certificate chain) is revoked before signing | N/A | |
Timestamping certificate (or certificate chain) is revoked with Key Compromise reason | N/A | |
Timestamping certificate (or certificate chain) is revoked with any other reason after signing | N/A | |
Timestamping certificate (or certificate chain) is revoked with any other reason before signing | N/A | |
Timestamping certificate (or certificate chain) is expired after signing | N/A |
as you see there is only one case when simple signature remains valid — while the certificate is time valid and is not revoked. In all other cases the signature will become invalid. But timestamped signature remains considered as a valid even if all certificates in the signing and timestamping chains are expired. Therefore you should timestamp your signatures each time you sign something as it is possible. Some time ago (when I wasn't educated in PKI) I asked a question — "for what purposes Windows is shipped with expired root certificates in the Trusted Root CAs container? They are expired and there are no reasons to trust them!". And the answer was pretty simple — for timestamped digital signature checking purposes. Therefore if you issue signing certificates by your internal CA — don't remove your root CA certificate after CA certificate renewal.
Hello Can you explain more the last part about expired root certificates? "For timestamped digital signature checking purposes". I don't understand this part. Thanks
This means that you should not remove expired root CA certificates from Trusted Root CAs store. for example, you have signed certain application and timestamped. After years (after root CA expiration) you need to restrict applications depending on digital signature (by using software restriction policies). Even if root CA certificate is expired (and signing certificate too) digital signature verification will consider as valid. If you remove expired root CA certificate from trusted store, the signing cirtificate will become invalid, because issued by untrusted root and digital signature checking fails. This is because you can find several expired 3rd party root certificates in your Windows box. They are published for the same purposes.
For digital signatures to remain valid after digital certificate expire, you can use digital timestamp along with signature. There are some online digital timestamp websites, you can try tecxoft tsa, they offer free timestamps for evaluation.
HOw signature is still valid ifor a given file if timestamp cert is revoked with key compromised ? bacause if hacker is a person who has signing cert private key , and now he has timstamp private key (Altough key has been revoked) . he can sign a file and put timstamp with a date(in which timestamp cert was valid).
so ideally this file should not be trusted .
> HOw signature is still valid ifor a given file if timestamp cert is revoked with key compromised ?
you are right. I overlooked this point and updated the table to reflect correct behavior when timestamping certificate is revoked.
How can you trust the timestamp (and consequently the signature) after its supporting certificate has expired? Isn't it the same as to trust the simple signature after its supporting certificate has expired? And how about RFC 3161 which states:
The TSA signing key MUST be of a sufficient length to allow for a sufficiently long lifetime. Even if this is done, the key will have a finite lifetime. Thus, any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date to renew the trust that exists in the TSA's signature.
> How can you trust the timestamp (and consequently the signature) after its supporting certificate has expired?
If timestamping certificate is not revoked, then there is no reason to not trust the timestamped signature. The purpose of timestamp certificate is to indirectly prove that signing certtificate was valid and not revoked at signing time.
It is year 2050 and I get a document that was signed and timestamped in 2020.
Document was signed in 2020 using trusted CA qualified certificate and time stamped using qualified TSA.
Signer certificate expired in 2022. TSA certificate expired in a year 2030.
Document has never being signed or timestamped again since the initial signing and timestamping.
Can I tell anything about the integrity of examined document if I do it in 2050?
> Can I tell anything about the integrity of examined document if I do it in 2050?
as long as you have required certificates (signer, TSA certs), their chains AND revocation lists (although, expired, but they must be issued after signing time) you can guarantee that:
1) document existed at specified time (in 2020, determined by timestamp) in exact form as you see it now (in 2050).
2) signing certificate and TSA certificate were valid and weren't revoked at signing time (signing time falls into validity period of both certificates).
You can think of timestamp as shanphot for certain point in history. And all this is possible because of a timestamp.
> as long as you have required certificates (signer, TSA certs), their chains AND revocation lists (although, expired, but they must be issued after signing time) you can guarantee ...
How would I obtain them? Are expired certificates stored somwhere publicly? It think I don't know one of the most crucial part of the whole process or what?
Thank you Vadims, for your kind response!
Cel.
> How would I obtain them?
they are attached to signature.
> they are attached to signature.
Vadims, I didn't know that! Thank you!
So when I sign a document,
- my private key is used to encrypt document's hash
- and my certificate (that contains public key) is also attached.
When someone needs to check the document he simpy uses publick key (he can get from attached certificate) to decrypt hash and compare.
So signature is composed of [Encrpted hash + signers certificate].
And if LTV is used, signature is composed of [Encrpted hash + signers certificate + revocation status (signer's) + timestamp + timestamp certificate + revocation status (timestamp's)]
Correct?
Thank you so much!
Revocation data is not carried along with signature, because CRLs are regularly updated. Only certificates are embedded. In the rest, you are correct, signer certificate (optionally, its chain) and timestamp (optionally, its chain) are sticked there and you don't need to search them anywhere, they are in place.
Thank you Vadims!
You are of great help!
I really don't want to burden you further, but I find your explanations so damn good, short and direct, that I can't resist.
Do any CAs store any information about expired (and not revoked) certificates?
For how long CAs store information about revoked certificates? Just to the expiration date?
Do you think that archives for instance should also employ some Distributed Ledger Technology (blockchain) to safely store important metadata (hashes, signatures, ...) to ease the process of very long term validation of digital records they hold?
> Do any CAs store any information about expired (and not revoked) certificates?
only in internal database which is not exposed to public. However, these days, you can try to find certificates in Certificate Transparency Logs, but not all CAs publish certificates there and its purpose is slightly different (to prove that particular certificate was ever issued).
> For how long CAs store information about revoked certificates? Just to the expiration date?
it depends on CA policy and strategy. Some CAs CAN remove *encryption* certificates from CRLs once they expire, because expired certificates no longer usable for encryption. Decryption doesn't require revocation checking at all. *Signing* certificates (S/MIME, code signing, document signing, whatever-else signing certificates) MUST NOT be removed from CRL for any reason once included. If CA is retired, it publishes its last CRL to CDP location and then can be decommissioned. Maintenance of this last CRL (just server single file, not a big deal) is crucial, since it contains the effective list of revoked signing certificates and the date of revocation. This allows signature validation algorithm to check if signing certificate *was* or *was not* revoked at signing time.
> Do you think that archives for instance should also employ some Distributed Ledger Technology (blockchain) to safely store important metadata (hashes, signatures, ...) to ease the process of very long term validation of digital records they hold?
I don't see any particular benefit from this.
Hi,
I have a certificate
DST Root CA X3 ---- expiry date = 9/20/2021
Let's Encrypt Authority ----- expiry date = 3/17/2021
*.abc.something.au ----- expiry date = 3/30/2021
Now the Let's Encrypt Authority is going to expire tomorrow 3/17/2021 but the *.abc.something.au which is the main certificate is going to expire after two weeks 3/30/2021. My question is will my website or service will stop working tomorrow or it will work until the certificate expire i.e. 3/30/2021.
Thanks
This should continue to work. Let's Encrypt CA is originally signed by DST Root CA X3 and cross-certified with new ISRG Root X1 (see Let's Encrypt's New Root and Intermediate Certificates). Certificates issued by LE X3 and X4 will be trusted via new cross-certificates: https://crt.sh/?id=47997543 or https://crt.sh/?id=47997546.
I just have to say i have been doing PKI for over 20 years.
Vadims Podāns YOU ARE the greatest.!!
Do applications work after both the signer certificate and timestamp certificate expire?
Who is responsible to renew timestamp certificate?
> Do applications work after both the signer certificate and timestamp certificate expire?
please take a look at the table (in the end) where I've outlined all validity scenarios. In short, they will work.
> Who is responsible to renew timestamp certificate?
time stamping authority (TSA) owner.
Hi - not sure i got it - in particular i am struggeling to understand what happens after a timpstamp expires - would this mean the the digitally signed document is no longer valid?
@Silvio,
I don't understand what do you mean? Timestamp itself is always a point in past time. If you ask about timestamping certificate, then nothing happens, the signature remains valid. Look at the bottom table with possible scenarios.
Post your comment:
Comments: