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 been restructured.
• Cryptographic algorithms have expired or been deemed insecure.

To help mitigate these conditions that are outside the signer's control, LTV was established 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 time-stamper'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. Although 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, for 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 the following:

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

Thus, a "proper" LTV signature must have not only 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 enabled 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. All such revocation information, however, 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 because of 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 enabled (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 will add it to the document when the Update method is called. Although 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, because chain validation occurs only 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 through the TimestampServer property, the Update method will perform these steps automatically.

This process can be repeated indefinitely, beginning an archival loop in which 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: 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.