B – Basic Signature

A basic signature is a cryptographic signature with accompanying signing certificate and chain. It provides authenticity (we know who signed) and integrity (we know what was signed and that it has not been altered) of the document. It is the minimal (useful) signature level possible.

T – Basic Signature with Timestamp

A basic signature provides authenticity and integrity guarantees, but it does not provide us a trustworthy indication of the point in time the signature has been created. A timestamp is an additional type of signature that will be created by a TSA (Time Stamping Authority) and linked to the created signature. Embedding a timestamp to a signed document, provides proof that the signature existed at (or before) a specific point in time. If a timestamp has been added immediately after the document has been signed, the timestamping time can be considered the time of signing. The response of the timestamp authority is signed by the timestamping authority.

When no timestamp is used, the signing time is the time when data was added to the document. Because this can be any date/time (mostly the “local” or “server” time) and there is no way to verify the correctness, this time should be considered not trustworthy (with maybe an exception for internal systems). It is therefore recommended to always add a timestamp to the document by at least choosing the level of signature.

LTA – Long Term Archival (not supported yet)

Even when all information is contained in the document, over a longer period other issues may pose themselves. One notable example is the fact that certain signing algorithms, hashing algorithms and key sizes may become weaker over time. To counter this, a document timestamp can be added to the document, this timestamp creates a signature using, at the time of creation, secure algorithms, keys, … and is calculated over the complete content of the document indicating a trusted time when the document timestamp was applied to the document. This process may be executed multiple times during the lifetime of a document and is mostly used in archiving systems. When a document timestamp is added to the document, missing revocation data should also be added to the document in order to have a new package containing all validation data and preserving integrity of the document and its signatures.

LT – Long Term Validation (LTV)

Certificates used in PKI can be revoked before the end of their validity (for example when private key get lost/compromised). CA’s can provide 2 services to allow one to check if a certificate has not been revoked. Typically, this service is called before using a certificate (for example creating signatures) or validating a certificate (for example building a certificate chain).

CRL – Certificate Revocation List

This is the oldest mechanism and is basically a list of certificate serial numbers that have been revoked. If a certificate’s serial number is on the list of revoked certificates, it cannot be used. The list is signed by the CA and contains the issuing time and when to expect a next update. Typically, a CRL is valid for several hours after which an update will be published. During this time span, the CRL can be reused and so it may be cached. Note however that updates may be published before the announced update time.

OCSP – Online Certificate Status Protocol

The online certificate status protocol is a more recent mechanism, it is request/response based. One sends the serial number to the OCSP responder, the OCSP responder will reply with the status of the certificate. The response of the OCSP responder is also signed and contains the time of the response.

The availability of one or both services for a certificate is indicated by extensions in the certificate.

When validating a signature, one of the steps in the process is checking if none of the used certificates have been revoked. Because validation will be performed after the signature has been created, at a time where the certificate may not be valid anymore due to expiry or because it has been revoked. This would mean that the signature would be considered invalid while it may have been valid at the time of signing. This issue can be solved by embedding the OCSP or CRL response in the document at the time of signing. OCSP is always preferred over CRL since it is smaller and more granular. When validating the signature, the embedded revocation information can be used to check if a certificate was not revoked at the time of signing.

The iSigner Client Library will support CRL distribution points of the certificate (using HTTP(s)), as well as OCSP (over HTTP(s)). If necessary, the CRLs can be downloaded from the certificates’ distribution point and saved for reuse during their validity window.

If the certificate is valid the iSigner Client Library will embed the digitally signed CRL or OCSP response in the signature. This shows that the certificate was valid at the time of certification, even if the document is subsequently opened after certificate expiration or revocation. Only documents signed after revocation will be affected if the OCSP/CRL response was embedded in the signature. If no OCSP/CRL response is embedded in the signature the validity of the signature expires with the validity of the certificate used to sign the document.