A signature is not valid forever
An electronic signature is not valid forever. It is valid at a date. The statement is surprising at first, but it is easily explained.
A signing certificate has a lifetime. It expires, and it can be revoked before term, for example if its private key is compromised. What then becomes of a document signed with such a certificate? Should it be treated as unsigned?
No. But on one condition: being able to prove when it was signed.
Handwritten signature, electronic signature
A handwritten signature binds a person to a document, but it says nothing about its content: nothing prevents a page from being altered afterwards. And verifying it calls for expertise that can be a delicate matter.
An electronic signature answers these limits because it is computed from the document itself. It provides three guarantees:
- Integrity: the signature covers the fingerprint of the document. A single byte modified, and verification fails.
- Identity: the signing key is associated with a certificate issued by an authority that has verified the identity of its holder.
- Non-repudiation: the private key remains under the exclusive control of the signer, especially when it never leaves a smart card or a token.
To this is added a verifiable date, as soon as the signature is timestamped. That is precisely what the handwritten signature lacks most: a date written by hand is only a declaration.
Signature formats
The eIDAS regulation recognises several signature formats standardised by ETSI. They differ first by the type of file they apply to:
- XAdES for XML documents
- PAdES for PDF, where the signature is embedded in the document
- JAdES for JSON, in particular exchanges between applications
- CAdES for any type of file
CAdES is the general-purpose format. Since it assumes nothing about the structure of the signed file, the signature is not inserted into it: it accompanies it. This is called a detached signature. That is what allows it to sign an image, an archive, an encrypted file or a proprietary format without ever touching it.
Level T, the one that adds the date
Each of these formats then comes in levels:
- Level B (Basic): the signature alone, with the essential attributes
- Level T (Timestamp): a timestamp token is added to the signature
- Level LT (Long Term): the elements needed for verification, certificate chain and revocation evidence, are embedded in the signature
- Level LTA (Long Term Archive): archive timestamps are added, then renewed over time
The difference between LT and LTA lies in what is being protected. Level LT answers a problem of availability: in ten years, the authority's revocation service may well have disappeared, so the evidence that will make verification possible is kept today, inside the signature. Level LTA also answers a problem of ageing keys and algorithms: an algorithm considered secure today will not stay that way indefinitely, and the same holds for the keys in use. Finally, the certificate of the timestamping authority has an end of life too. An archive timestamp therefore periodically seals the whole, evidence included, each new token extending the validity of the chain before the previous one weakens.
A CAdES-T signature therefore embeds a timestamp token issued by a trusted authority, attesting that the signature existed at that precise moment.
Timestamping a document, timestamping a signature
These are two distinct possibilities, and they do not prove the same thing.
Timestamping a document, that is, its fingerprint, proves the existence of the file at that date. It says nothing about its author: a timestamp is not a signature.
Timestamping a signature proves that the signature of the document took place before that date, and therefore that the certificate was still valid at the moment it was made. (And since the signature value already covers the fingerprint of the document, the proof of date applies to the document as well!)
Timestamping a signature is what level T does.
Verifying is not just recomputing a fingerprint
Verifying a signature is not just a matter of comparing two fingerprints. It means answering a question of law: was the signer's certificate valid at the date attested by the token?
This calls for three distinct checks:
- Did the validity period of the certificate cover that date?
- Was the certificate revoked at that date? The question applies to the signer's certificate, but also to that of the authority which issued it.
- Does the certification chain lead up to a recognised trusted authority?
This last point deserves attention, because a chain that leads somewhere is not enough: it still has to lead far enough. Each member state publishes a signed eIDAS trusted list which lists the qualified trust service providers and the certificates of their authorities. These national lists are themselves referenced by a list of lists, published by the European Commission, whose signing certificates appear in the Official Journal of the European Union.
It is this chain of publication that gives the word qualified its meaning. An authority is not qualified because its certificate says so, but because a state has entered it on its list, and because that entry is verifiable by anyone. These lists keep the history of statuses, which makes it possible to answer the only question that matters here: was this authority qualified at the date of the token?
Because these checks are assessed at the date of the token, and not at the moment the file is opened. A certificate that expired two years ago can perfectly well carry a valid signature. Conversely, a certificate still within its validity period carries a signature that proves very little if its chain leads to no recognised authority.
Without a provable date, the signature dies with its certificate
That is the direct consequence. A level B signature, without a token, provides no proof of its own date: the date it contains is declared by the signer, and therefore cannot be relied upon. The day the certificate expires or is revoked, nothing establishes any longer that the signature predates it.
And generally nobody notices before they need it. And there is nothing to be done about it.
CAdES-T in Sigalion Vault
It is for all these reasons that we chose the CAdES-T format for signing in Sigalion Vault, available on macOS, Windows and Linux:
- CAdES baseline-T (ETSI EN 319 122-1), detached CMS signature (RFC 5652) combined with the document in an ASiC-S container
- RFC 3161 token placed on the signature value, with a choice of Sigalion timestamping or eIDAS qualified timestamping (recommended)
- Software certificate, smart card or token (IDOpte, YubiKey), depending on the medium available to you
- Trusted authorities and eIDAS qualification taken from the official Trusted List, revocation status of the signer and of its issuer checked at the date attested by the timestamp
The file produced is an .asics envelope combining the document and its signature in a standardised format, verifiable by tools compliant with the ETSI standards.
Signing, timestamping, encrypting: three distinct needs
More broadly, Vault answers three distinct and complementary needs that are often confused:
- Signing, to guarantee the integrity of the document and the identity of its author, and to express their agreement
- Timestamping, to attest that it existed at a given date
- Encrypting, to guarantee confidentiality and restrict reading to the designated recipients
The three combine: a document can be signed and timestamped, then encrypted for its recipient, and the whole can be timestamped as well.