I am quite new to the topic. I have signed a PDF document with PKCS#12 digital certificate. In Adobe Reader, when I open signature panel I can see that "Signature is LTV enabled". Reading this article, I cannot really understand, whether I need to apply timestamp or not. If not, how do I validate the time when the signature was applied? or what kind of validation information should I add?
1 Answers
The term LTV enabled
First of all the term LTV enabled is a term introduced by Adobe and not properly specified. In particular it is not identical with the term PDF document with LTV as used by ETSI in their PAdES specification part 4 (ETSI TS 102 778-4).
Steven Madwin (at the time being employed by Adobe) once 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.
Thus, the meaning of that term depends on
- Adobe's validation code and
- the related security settings used by that code.
For additional backgrounds cf. this answer.
The OP's case
The OP observed
I have signed a PDF document with PKCS#12 digital certificate. In Adobe Reader, when I open signature panel I can see that "Signature is LTV enabled".
and explained in comments
my certificate must be self-signed
and
I have imported the certificate into the "Trusted Root Certification Authorities" in Internet options.
Depending on its security settings, Adobe Acrobat / Reader may automatically trust certificates configured as trusted roots in the operation system it runs on. This seems to be the case for the OP.
Thus, the OP's signer certificate is a trusted root certificate for Adobe validators on his system. Therefore, they require no additional validation related information when verifying his signature and call it LTV enabled.
On another person's computer, though, on which the certificate in question has not been trusted, Adobe validators cannot validate the signature let alone call it LTV enabled.
Self-signed certificates and LTV
LTV hardly makes any sense for signatures signed with self-signed certificates, in particular there are no revocation information of interest which may be added to the document.
Why? This is due to the trust model used here.
It basically is hierarchical:
- We start by trusting a few institutions (certificate authorities) which we do by registering their root certificates as unconditionally trustable in our applications or operation systems.
- We furthermore trust all certificates issued by trusted certificates (if the trusted certificates are not marked as end entity certificates, that is).
This sounds great until one becomes aware that private keys for some of those certificates will sooner or later be compromised. Obviously we don't want to trust such compromised certificates anymore. In the basic model above this means that we have to withdraw the trust for the root certificate which directly or indirectly issued the compromised one. As there might be millions and millions certificates issued directly or indirectly by this root, this is not desirable.
So we extend the basic model by adding revocation check services:
- We again start by trusting a few institutions (certificate authorities) which we do by registering their root certificates as unconditionally trustable in our applications or operation systems.
- We furthermore trust all certificates issued by trusted certificates (if the trusted certificates are not marked as end entity certificates, that is) unless the revocation check service associated with the issuing certificate indicates that the certificate has been revoked.
This sounds great until one becomes aware that these revocation check services might stop working (e.g. because the company running the certificate authority in question goes out of business). At least signatures on documents which are of interest for a long time are at risk of becoming unverifiable this way.
To get around this issue, LTV (Long Term Validation) mechanisms have been introduced. They essentially collect the chain of certificates from trusted root to signer certificate and the responses from revocation check services for all but the root certificate and bundle them with the signature. (The root certificates must still be explicitly trusted.)
Using these information a signature can be validated long after the certificate authority stopped providing the revocation check services.
(This is a bit simplified; particularly issuing, signing, revocation, and validation times have to be considered. But it should give an idea...)
So back to the original claim that LTV hardly makes any sense for signatures signed with self-signed certificates: Self-signed certificates are root certificates which one either trusts explicitly or not at all. There are neither other root, intermediary or end entity certificates of interest nor revocation check responses for them to collect.
Does it mean then with self-signed certificate I can never obtain PAdES LTV compliant pdf?
More to the point there is nothing of interest to put into the PAdES LTV validation related information. The only LTV operation of interest would be adding a document timestamp (not explained above) to narrow down the signing time.