3

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:

  1. 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.

  2. 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 rfc5126, especially sections C.4.1.1 and C.4.3.

Edit:

(Another sub-question has been moved here.)

Community
  • 1
xarx
  • 143
  • 5

1 Answers1

4

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 RFC 3161, 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 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 CMS. 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 Evidence Record Syntax, a competing standard which concentrates on long-term signatures and, in my opinion, does it better than CAdES.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Thank you, Tom, for your answer. Once I know that CRLs are signed, the rest is clear. For some reason I thought (and not only me) that CRLs are unsigned - perhaps that was true 10-15 years ago? But what about the scenario in point 1.? A substantial requirement for all these long-term signatures to work is in that all used CAs and TSAa were trusted at the time when their certificates were used. If a TSA company bankrupts, how will I be able to prove that it was once trusted? One more question in my original post. – xarx Apr 03 '14 at 06:34
  • With the chain of time stamps, you can always verify the archive as long as the newest time stamp is valid _now_, and each other time stamp was valid at the time the immediately newer time stamp was applied. You survive the "bankrupt TSA" situation as long as you re-timestamped it (with its then-valid CRL) before it went bankrupt, with another TSA. To manage unforeseen abrupt breaches (e.g. TSA key compromise), you can double the time stamps, with two distinct TSA, interleaved in the chain. – Tom Leek Apr 03 '14 at 12:24
  • I meant something different. Say `M S T1 T2` is a signed message timestamped with `TSA1` and `TSA2` respectively. All certificates are valid, the time-stamp chain seems OK. But in fact, the message was modified and re-signed, and `T1` was forged by me, because `TSA1` belonged to me. Though everything seems OK, the problem is in that `TSA1` cannot be trusted. How can one detect this problem in future, when `TSA1` won't already exist? Of course, I can use double time-stamps, but how many organizations do that? – xarx Apr 03 '14 at 13:24
  • Actually none of the X.509-related standards, including CAdES, deals with permanently malicious entities. The theory is that if `T1` is evil (or compromised) then its certificate will get revoked at some point. It is often expressed as "rogue CA are out of scope of X.509", which is kind of surprising the first time you hear it, but somehow makes sense. – Tom Leek Apr 03 '14 at 15:19
  • Tom, as I understand it, you write about the case when `TSA1` is trusted and `T1` is compromised. Then I agree that `T1` gets sooner or later to the TSA1's CRL. But I meant, what if `TSA1` itself is malicious? There are thousands of TSAs for "testing" purposes, anyone can issue any time-stamp he wants, and there's none who can revoke their certificates. If I come upon `T1` from an unknown `TSA1`, it seems to me that's there's no recommended mechanism how to prove that `TSA1` was trusted. Is that true? Also, do you know an answer to my question above concerning the "opposite of grace period"? – xarx Apr 03 '14 at 18:59
  • Theoretically, when you decide to verify a signature, you don't trust "any TSA which happens to have a certificate", but a specific set of TSA. In some countries, if you want the signatures to have some legal values, then the involved TSA must also comply to strict regulations; thus, not just "any TSA", but only "TSA you know". – Tom Leek Apr 03 '14 at 19:05
  • So, if TSA1 was ever trustworthy, but gets lost in the dustbin of history, everything would be lost. In order this does not happen, TSA1 must be registered by a higher (possibly state) authority. Thank you for your time! – xarx Apr 03 '14 at 19:21