LTV Signatures in PDF

Requirements: Secure PDF

Introduction

Long-term validation (LTV) signatures are an extremely useful type of PDF signature because they can be verified long after any or all of the following have occurred:

• The certificate used to sign the document has expired or been revoked.
• Online validation sources that existed at the signing time have become unavailable.
• Certificate Authorities (CAs) have shut down or restructured.
• Cryptographic algorithms have expired or been deemed insecure.

To help mitigate these conditions that are outside the signer's control, LTV was established as a way to preserve the long-term integrity and validity of PDF signatures. The basic idea is that all the cryptographic validation material (i.e., certificates, CRLs, OCSP responses) used for the signer's or timestamper's chain validation is included in the signed document at the time of signing so that the signature becomes verifiable without needing to contact external sources.

This article will explain the differences between the official, standardized definition of the concept and Adobe's interpretation of it within the context of PDF signature verification. It will also show how to use the PDFSign component from Secure PDF to create LTV signatures.

Contents

• LTV in ETSI
• LTV in Adobe
• Creating an LTV Signature
• Extending an LTV Signature

LTV in ETSI

In the PDF Advanced Electronic Signatures (PAdES) ecosystem devised by the European Telecommunications Standards Institute (ETSI), LTV signatures are more formally known as long-term archival (LTA) signatures. While an earlier version of the specification defined the PAdES-LTV profile, this was effectively superseded in ETSI EN 319 142-1 by the PAdES-B-LTA signature profile, of which LTA is an abbreviation.

The ETSI understanding of an LTV-enabled signature is one that can be validated in the very distant future. This implies that:

1. The document must include all the validation material in itself (assuming, e.g., that a CA may not exist in 10-20 years and would not be able to confirm the validity of the signing certificate), independently of whether the root certificate is trusted or not, and
2. The signature is periodically renewed with an additional document timestamp to protect from the expiration of the previously used TSA certificate (please see the Extending an LTV Signature section for more details).

That is, a "proper" LTV signature must not only have all its validation material located in the document but also a document timestamp that certifies the validation material. This type of timestamp is a standalone signature that is created over the document by a TSA rather than by the signer.

LTV in Adobe

Adobe's interpretation of LTV is quite different – it is misleading in some aspects and outright contradicts the original idea in others. Sometimes it advises that a signature is not LTV when in fact it is according to its own criteria.

To consider a signature LTV-enabled, Adobe requires neither the full validation material nor a document timestamp to be present; effectively, only some revocation information (i.e., CRLs or OCSP responses) must be included in the signed document. However, all such revocation information must be placed in the Document Security Store (DSS). The DSS is a PDF dictionary that stores both revocation information and certificates used to validate signatures.

In addition, Adobe Reader is sensitive to local certificate trust settings when reporting (or misreporting) the LTV feature. If the signing chain has a trust anchor (which may not even be the root certificate) on the local system or in the European Union Trusted Lists (EUTL), the signature will be shown as LTV-enabled. This means that from Adobe's perspective, the same signature can be LTV-enabled on one system but not on another.

To summarize, if Adobe Reader says your signature is LTV-enabled, it is not necessarily an LTA signature under the ETSI definition. Conversely, even if your signature meets the official requirements of the LTA level, Adobe Reader may not show it as LTV-enabled due to the trust aspect.

Secure PDF uses a stricter method to establish the LTV capability, which is aligned with ETSI practices. For the PDFVerify component to classify a signature as LTV (pfBaselineLTA), the document must contain the full validation material necessary to validate the signature in OfflineMode at the time of signing as well as a document timestamp. The LTV status returned by PDFVerify may differ from that returned by Adobe, but it will always match the ETSI understanding.

Creating an LTV Signature

Secure PDF also follows the ETSI understanding of LTV when creating signatures with PDFSign. The component will attempt to collect the full validation material and add it to the document when the Update method is called. While there is generally more than one way to create an LTV signature, it is recommended to use the following two-step approach:

1. Create a base extended signature with an embedded signature timestamp.
2. Update the signature by gathering all the missing validation material, incorporating it into the signed document, and certifying it with a document timestamp.

// Step 1 pdfsign.InputFile = "input.pdf"; pdfsign.OutputFile = "signed.pdf"; pdfsign.SigningCert = new Certificate(CertStoreTypes.cstPFXFile, "cert.pfx", "password", "*"); pdfsign.SignatureProfile = PDFSignSignatureProfiles.pfBaselineT; pdfsign.TimestampServer = "http://time.certum.pl"; pdfsign.ValidationPolicy = PDFSignValidationPolicies.vpNone; pdfsign.Sign();
// Step 2 pdfsign.Reset(); pdfsign.InputFile = "signed.pdf"; pdfsign.OutputFile = "updated.pdf"; pdfsign.TimestampServer = "http://time.certum.pl"; pdfsign.Update();

This method separates the signing stage from the chain validation stage, since chain validation only occurs in step 2. It is also more robust than other methods because, for example, intermittent unavailability of an OCSP or CRL responder will not break the signing process – you can repeat the Update attempt later with the same signature if needed.

Extending an LTV Signature

The main idea of LTV is to extend the validity of the signature long into the future, when online CA services may theoretically no longer be available. An LTV signature is therefore not "fixed" and may require updating over time.

Normally such an update is performed shortly before the TSA certificate that produced the most recent timestamp (either the main signature timestamp or a previous document timestamp) expires. It involves validating this TSA certificate's chain, including the newly collected revocation information in the document, and adding a document timestamp. As long as the PDFSign component has access to the TSA details via the TimestampServer property, the Update method will perform these steps automatically.

This process can be repeated indefinitely, beginning an archival loop where a chain of document timestamps is updated periodically to preserve the document's long-term status. This archival loop can be leveraged to extend the original signature's validity such that the whole continuous period from the expiration date of the first TSA certificate up to the current time is covered.

Note that you will need to monitor the validity period of the latest document timestamp and remember to add a new one before it expires. If the TSA certificate has expired, any document timestamps it created will no longer be trusted, leaving the document unverifiable.