1 Correct answer
Hi Loïc,
Thanks for the files. Here are several takeaways in no particular order.
1) I can't help you with the iText app you are using to create the digital signatures as it's not an Adobe application.
2) LTV in General - LTV being enabled is only dependent on the revocation information having been embedded into the PDF file. The Timestamp has no bearing on LTV.
3) PAdES - Getting the digital signature to be PAdES B-T (basic - timestamped) is pretty straight forward, and it's something you've alre
...
14
Replies
I am updating this issue for people who are experiencing the same problem.
At this point I sadly do not expect an answer from Adobe 
.
I have found the inconsistency/bug/problem in Adobe Reader : whether or not a signature is marked as LTV is influenced by the fact if other documents with digital signatures were opened before in the same session when using Adobe Reader!
I have found the following consistent behavior when using Adobe Reader DC 2017 and 2018 (versions, see above)
A digital signature is considered LTV enabled when:
* timestamp from TSA and CRL data is embedded
* timestamp from TSA and CRL/OCSP data is embedded
if this document is the first document that was opened after opening Adobe Reader!
If after opening Adobe reader you first either open a signed document with only timestamping OR timestamping and OCSP data embedded and after this you open a document signed as described above they are considered not LTV.
I would think this a bug in Adobe Reader. Once again paging Steven.Madwin​ in the hope this gets looked at.
One would expect the embedding of both a Timestamp of a TSA and data of revocation services of the CA , be it either CRL or OCSP , would result in a LTV enabled signature. Why this is not the case when using OCSP revocation data I have no idea.
best regards,
Loïc
Hi Loïc,
Thanks for the files. Here are several takeaways in no particular order.
1) I can't help you with the iText app you are using to create the digital signatures as it's not an Adobe application.
2) LTV in General - LTV being enabled is only dependent on the revocation information having been embedded into the PDF file. The Timestamp has no bearing on LTV.
3) PAdES - Getting the digital signature to be PAdES B-T (basic - timestamped) is pretty straight forward, and it's something you've already achieved. Getting to PAdES B-TL (same as above + LTV) is not achievable because that requires the revocation information being embedded in the DSS dictionary, whereas as the current implementation of adding revocation information is to write it into the CMS package (i.e. the Contents dictionary) in the Signature Object.
4) Why no LTV for the OCSP only file - It's because there is no OCSP response to cover the ICA certificate embedded in the CMS. Yes, there is an OCSP entry in the Authority Information Access extension in the DigiCert Document Signing CA certificate, and Acrobat can get it, so why iText didn't procure it and then embed it is a mystery, but see Item 1. There is no CRL either, but I doubt you were looking for the CRL in this test.
Here is what's in the CRL + OCSP file as well as the OCSP only file:
5) Why (maybe) sometimes Acrobat is reporting that it is using the cached copy of the CRL instead of an OCSP obtained in real time - That's because there is a cached copy of the CRL file on disk in the Security\CRLCache folder and Acrobat will always use a locally found piece of revocation collateral before initiating a network operation. If you delete all of the CRLs in the Security\CRLCache folder, then restart Acrobat and open the file you'll see that both the ICA and end-entity certs are using OCSP responses.
6) Why the order of file opening matters with regard to LTV, and YES it's a bug - First, it's not just Reader, this bug manifests itself in Acrobat as well. The reason it happens is the order in which Acrobat (and Reader, it's the same code) looks for rev info. The very first place it looks is in memory, because if it's there that's the fastest way to get it. If it's not in memory it then looks on disk, and failing that it will make a network call to download it. When falling through to the network call it will first try to see if it can procure an OCSP response, and if not then download a CRL. If all that fails you end up with a signature in an Unknown status because revocation checking could not occur, but that's not the issue here. The issue here is, when the first file is open (that is, one of the files without embedded rev info) Acrobat may (or may not) find a CRL on disk, and if not then it gets the OCSP response. Now the OCSP response is loaded into Acrobat's session memory. When the second file (with the embedded info) is opened Acrobat finds the rev info in memory and doesn't bother to check in the file to see if it is embedded. That caused the LTV status to be "Signature is not LTV enabled and will expire". In the interest of speeding-up the whole signature validation process we ended up losing the proper LTV status. I'll let my counterparts in Acrobat know.
I hope this helps,
Steve
Dear @Steven_Madwin ,
I am also facing same issue.
In older Adobe Version --
Signature + CertificateChain was enough to show LTV.
But after the upgrade of adobe acrobat reader.
Signature + LTV + CertificateChain + CRL is also not showing the LTV enabled. But same document if open older adobe reader it shows as LTV enabled.
AdChoices