Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
In an internal PKI using SHA1 for hashing, will S/MIME signature and CRL/ARL signature be considered invalid in the next few years (SHA1 Deprecation) ? End certificates can be revoked, CA certificates too (or may be updated and signed again), but what about S/MIME signature and CRL ?
The question is not really about certification path (in S/MIME case, suppose the upper path is SHA256 but not the end entity certificate), but more about signature or CRL validity.
The general situation looks like this:
A signature relies on some certificates, that assert the ownership of public keys. Certificates are primarily designed to be validated now (e.g. the certificate's date of validities are compared with the current date).
These objects tend to degrade over time. CRL expire (usually rather fast). Certificates expire; when a certificate has expired, it ceases to be included in CRL, so even if you can download a new CRL, you won't be able to know whether the now-expired certificate was still unrevoked at expiration time. Possibly, a CA may go out of business. And, as you note, involved cryptographic algorithms may also become deprecated.
The really important point is that when you want to verify a signature, you want to know whether the signature was valid at the time it was produced. Suppose, for instance, that somebody sent you a signed email (with S/MIME) on November 12th. Three weeks later (early December), the sender's computer is compromised and his key stolen; he dutifully contacts his CA, and the CA revokes his certificate. Does that mean that his signature ceases to be valid ? We certainly hope not !
When you sign, you really are building a legal weapon pointed at you. In the example above, if Bob sends you a signed email, then you want to keep it in order to sue Bob if he wants to default on his responsibilities described in the email. It would be too easy if Bob could escape your legal retaliation by simply losing his private key !
However, once Bob's certificate has been revoked, it can no longer be validated in the X.509 sense. What that implies is that S/MIME signature validation is transient. It works for some time, then ceases to work.
To really support long-term archival of signed object, you need to freeze things in time. The tool for that is a time stamp.
Suppose that Bob signs the email on November 12th, 2014. Two days later, you open your mailbox and you verify the signature; at that point, Bob's certificate is still valid and unrevoked, and you can obtain a set of CA certificates and CRL that demonstrate (within the X.509 model) that, on November 14th, Bob had really signed the email. Then you take the email, CA certificates and CRL, put all of these in a big bag (e.g. some archive format), and then obtain a time stamp from some time stamping authority. The time stamp is, basically, a short document containing both the time stamping date (November 14th) and the hash of the time stamped data (a hash of the Zip file containing the email, its signature, the extra CA certificate and CRL); and the time stamp is signed by the time stamping authority.
Then fast forward to December 11th. At that time, Bob's certificate is revoked, because he claimed to have been robbed of his private key on December 3rd. You want to revalidate the signature. To do that, you verify the signature on the time stamp; if it is correct, then it is a proof that the archive contents already existed "as is" on November 14th. So you can then validate the S/MIME signature, using the objects from the archive, as if the current date was still November 14th. At that date, no certificate was revoked, archived CRL were not expired, SHA-1 was still trustworthy, so everything is fine.
A time stamp is thus a time-travelling machine. The time stamp demonstrates that a set of objects existed at some date T; so it allows you to run any validation algorithm using these objects (and only them) as if the current date was T.
Now the problem becomes: how to organize that time stamping process ? In particular, the time stamp is itself a signature, that is verified at the current date (it is because the time stamp is valid now that you can then jump back to date T when using the archived objects). That signature, with standard time stamps, also uses X.509 certificates and is subject to the same kind of degradation. So what you really need is to chain time stamps: whenever the top time stamp is getting close to cessation of verifiability (typically the expiration date of the TSA certificate), freeze it with another time stamp. And so on.
Theoretically, there are standards for that. S/MIME relies on CMS, an extensible format for encrypted and signed objects. Among defined extensions for CMS are the CAdES attributes; when you get all of them, you have a CAdES-A object, which is basically the archive-with-chain-of-time-stamps that I was talking about.
(However, I strongly doubt that you will find any S/MIME-aware tool that also knows how to process CAdES attributes.)
The same concept is also applied for XML documents (and the XAdES standard), and for PDF (with PAdES). Recent versions of Adobe Acrobat support PAdES.
Regarding CRLs: CRLs are issued regularly. They don't need -- nor should they have -- long durations between updates. They are regularly reissued. (I just checked Facebooks certificate and they use http://crl3.digicert.com/ca3-g29.crl -- This CRL lists 7 days as the maximum time until the next update.) So you can just sign them with the signature of your choice when the next update is due.
S/Mime: I don't know enough about S/Mime.
I think that Tom Leek's answer is very good, but it captures only part of the truth, as there can be many cases in practice where it is possible to deal with the problem more easily.
With signatures, you can achieve one or more of the three following security goals:
Tom Leek's answer refers mainly to the case of non-repudiation, but that may not be the purpose of a specific signed communication. For example, two parties might want to communicate with each other in an authenticated way and without any third-party tampering, but they accept that nobody makes any legally binding statements in that communication.
I believe actually most email communication is not intended to include legal statements. For example if you someone invites you to a party, you are interested in whether this is real or just some bot who sends outs hoax invitations -- but you will probably not sue your friend if she or he later decides to cancel the party. Same thing if your colleague invites you to a meeting.
So how do you deprecate an internal PKI, for which some certificates are still valid for some time? You may issue a CRL with long validity, probably for the whole remaining CA lifetime. Then, you lose the capability to effectively revoke certificates, but you do not have to maintain the PKI systems anymore and all existing certificates and signatures keep being valid.
