LTV enabled signatures not longer LTV enabled after update to Adobe DC 2018

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