How to handle CRLs correctly in long-term electronic signatures?

How to handle CRLs correctly in long-term electronic signatures?

• What is a recommended way of handling CRLs in long-term electronic signatures (specifically the CAdES-A)? The problem I see is in that CRLs are not protected against modification (they are plain text, not signed) and not even mandatory in CAdES-T or CAdES-A. As such, they can be forged, and such forgery cannot be easily detected, if the used time-stamping authority (TSA) is no longer active. I cannot figure out a way of handling CRLs in a way that prevents any doubts about long-term validity of a documents time-stamped with CAdES-A. The same problem I have with verification of trustworthiness of TSAs themselves, if they no longer exist. A typical scenario that worries me is this: An attacker may use his own (=untrusted) time-stamping authority to forge a (CAdES-T or CAdES-A) time-stamp of a document. No one will now able to verify whether this now unreachable TSA was trusted or not at the time the time-stamp seems to be issued. To create a semblance of credibility, the attacker may update the time-stamp with a valid time-stamp of a trusted TSA, and wait for several years. The time-stamp update is possible due to the fact that time-stamps may be issued automatically without verification of credibility of previous time-stamps. On a similar principle, an attacker can use a revoked certificate of a trusted time-stamp authority. He may also attach a modified CRL from which he deletes the S/N of the used time-stamping certificate (which is possible as the CRL is not signed). This way, the attacker may create a series of time-stamps from different TSAs. It's possible that after 10 years at least one of the TSAs won't exist, and no one will be able to receive its correct unmodified CRL to verify validity of the time-stamp. Unfortunately, long-term signature specifications do not treat these problems in detail, or rather they don't mention them at all. For instance in http://tools.ietf.org/html/rfc5126#appendix-C.4, especially sections C.4.1.1 and C.4.3. Edit: (Another sub-question has been moved https://security.stackexchange.com/questions/54807/is-long-term-validity-ultimately-corrupted-upon-tsa-certificate-revocation.)

• Answer:

  A CRL is a signed object, just like a certificate. This is why they need not be covered by the actual document signature. However, for long-term archival, they need to be timestamped. The theoretical background is the following: At a given time T, you may validate certificates and verify signatures by using just-downloaded CRL, which give guarantee about revocation status of involved certificates at the current date (T). If, while the current date is T, you want to prepare for an ulterior signature verification at date T' (later than T), then you assemble all the objects needed to perform the verification and put them all in a bag (some archive format), for which you obtain a time stamp. The time stamp states that all the bag contents existed at date T. At date T', you verify the time stamp, which includes validation of the TSA certificate and CRL download and so on; crucially, you validate the time stamp at date T', which is the current date. Once the time stamp is verified, then you know that all the objects in the bag already existed at date T, so you can virtually project yourself in the past and verify the signature as if the current date was T. The idea behind this time travel is that if at date T you had validated the signature, you would still remember it and act upon the result. Therefore, as long as you have proof (the time stamp) that all used objects (certificates and CRL) already existed at date T, then you can consider that you did validate the certificate at date T, and still remember it now. Recurse. In the description above, you validate the time stamp at date T', then that which was timestamped at date T. The time stamp itself may expire (usually because the TSA certificate will expire), so if you want to prepare for long-term validation, you must obtain a newer time stamp with a longer life-time. That newer time stamp should cover everything that is needed to validate the first time stamp at date T', include the CRL. Ultimately, you should apply a new time stamp every two or three years or so, depending on how fast the TSA expire. Each new time stamp is over a bag containing all objects needed to validate the previous time stamp. All time stamps here are http://tools.ietf.org/html/rfc3161, i.e. they are CMS SignedData. As such, you can a posteriori embed extra certificates and CRL in a time stamp structure. RFC 5126 states as such at the end of http://tools.ietf.org/html/rfc5126#section-4.4.1: NOTE 2: Time-stamp tokens that may themselves include unsigned attributes required to validate the time-stamp token, such as the complete-certificate-references and complete-revocation-references attributes, as defined by the present document. Apart from CAdES-specific unsigned attributes, extra certificates and CRL can always be pushed into the certificates and crls fields of the SignedData structure, as specified in http://tools.ietf.org/html/rfc5652#section-5.1. The overall effect is the same: the SignedData structure is the "bag" format I am talking about, and then you timestamp the whole lot. This chain-of-time-stamps structure may be somewhat easier to understand in http://tools.ietf.org/html/rfc4998, a competing standard which concentrates on long-term signatures and, in my opinion, does it better than CAdES.