LTV (Long Term Validation) and PDF signatures
The term LTV-enabled
4 Profile for PAdES-LTV
4.1 Overview
Validation of an electronic signature requires data to validate the signature such as CA certificates, Certificate Revocation List (CRLs) or Certificate status information (OCSP) commonly provided by an online service (referred to in the present document as validation data). If the document is stored and the signatures are to be verifiable long after first created, in particular after the signing certificate has expired, the original validation data may no longer available or there may uncertainty as to what validation data was used when the document was first verified.
This profile uses an extension to ISO 32000-1 [...] to carry such validation data as necessary to validate a signature.
(ETSI TS 102 778-4)
Based on this extension of the PDF specification ISO 32000-1 Adobe created the term LTV-enabled in Acrobat / Reader XI. According to Leonard Rosenthol, Adobe's PDF evangelist:
Our customers asked that we clearly identify a PDF that contained LTV (vs. one that did not). That was that term that we determined was simple and clear in conveying that message.
Unfortunately this simple and clear term is not really well-defined.
Early 2013, a few months after Acrobat XI has been released, people started wondering why their signatures (which in Acrobat X looked great without any restriction) suddenly were criticized as not LTV enabled and soon to expire. At that time Leonard characterized "LTV-enabled" signed PDFs on the iText mailing list:
LTV enabled means that all information necessary to validate the file (minus root certs) is contained within.
Another Adobe employee, Steven.Madwin, more bluntly put it like this
When you open the file Acrobat (and when I say Acrobat I mean both Acrobat & Reader) does the signature validation. As part of the validation process it figures out if it has to go online to download revocation information, or, is all of the revocation information embedded in the PDF file. At this point it knows what it's going to say in the Signature Navigation Panel. If it had to download data then the signature is not LTV enabled, but if all of the revocation collateral is in the file then the signature is LTV enabled.
So on one hand we have a simple and clear term LTV-enabled making the impression that it is a clear on/off matter, and on the other hand the meaning of the term depends on the (closed) signature verification algorithms in Adobe Acrobat and Reader.
Even worse, the behavior of those algorithms depends on the local configuration of the Acrobat / Reader! For any valid PDF signature Adobe Acrobat and Reader can be configured to show it as LTV-enabled by simply adding the immediate signer certificates to the trusted certificates for the signature type at hands, and analogously the other way around.
LTV-enabling a signature
Considering the above-said one can never be sure whether a PDF showing LTV-enabled on your Acrobat / Reader also shows LTV-enabled on the next person's Acrobat / Reader.
That been said, you can at least do your best to provide all the revocation information required by a verifier. This includes
- providing all the certificates required to build certificate paths from every certificate involved to the canonical trusted root certificates;
- providing revocation information (CRLs / OCSP responses) for all these certificates with the obvious exception of the root certificates;
for ALL signatures involved... and all signatures include the signatures signing individual CRLs, OCSP responses, and time stamps! Then add a time stamp and add certificates and revocation information related to the time stamp.
As Leonard remarks this usually requires the use of the PAdES part 4 extensions to ISO 32000-1, the Document Security Store (DSS):
LTV may be enabled when all collaterals are embedded in the signatures and not DSS [...]. In this case there may be no DSS. However, this is very unusual, because signatures over CRLs and OCSPs do not contain embedded rev info which is Adobe extension. Yet, this is a distant possibility.
LTV-enabled vs. PDF 1.4
In a comment the following question arose
But is it possible to add a DSS in a PDF v1.4
You can add DSS entries to a PDF v1.4 document. A PDF 1.4 also is a PDF 1.7 according to ISO 32000-1, and the DSS is an extension to ISO 32000-1.
Yes, but I assume you actually want to know whether the result still is PDF 1.4.
The answer to this is a bit vague because being PDF 1.4 is not really well defined: As Leonard once put it:
the PDF References aren't "normative" in nature - they don't (usually) make final, definitive statements - just sort of general ones.
Thus, there is nothing "normative" in nature specifying what a PDF 1.4 is at all.
This didn't keep ISO from using the PDF Reference 1.4 as normative base for their PDF/A-1 specification, though, so let us argue along the lines of that PDF Reference anyway. ;)
The PDF Reference, third edition, Adobe Portable Document Format, Version 1.4 says in Appendix E:
A PDF producer or Acrobat plug-in extension may also add keys to any PDF object that is implemented as a dictionary, except the file trailer dictionary (see Section 3.4.4, “File Trailer”).
Thus, the additions to existing dictionaries required for adding a DSS should be no problem, nor should the added indirect objects be as they do conform to section 3 Syntax of the PDF Reference.
Arguing along this line, therefore, a PDF v1.4 with the addition of a DSS can still be a PDF 1.4.
Obviously, though, software only understanding PDF 1.4
- cannot, without further ado, make use of the DSS information but
- may consider the addition of DSS a change of the signed document resulting in verification warnings or errors.
Concerning the latter item I would assume that, confronted with a PDF 1.4 plus DSS, e.g. Adobe Reader version 5 through 7 warn about changes after signing, Adobe Reader version 8 and 9 even consider the signature broken due to the changes, and Adobe Reader X and XI accept the addition and use it happily.
