Highlighted

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

Community Beginner ,
May 30, 2018

Copy link to clipboard

Copied

Hello,

we are having a strange situation with different Adobe versions and what each version considers a LTV Enabled signature.

In 2017 we were signing PDF documents with a timestamp from a TA and the data from CRL and OCSP check embedded in the digital signatures. This resulted in a signed PDF document that Adobe displayed as : LTV Enabled .  (unfortunately I cannot give you the version number of the Adobe DC instance used at that time)

We are having some problems with the OCSP service of the CA of our document signing certificate, so we have been signing with timestamp and CRL embedded only.

When viewed with Adobe 2017 (2017.12.20098 and 2017.12.20044) we have the following results for some test PDF's:

  • No CLR/ No OCSP (only timestamp)  -> Signature Valid / Not LTV Enabled
  • CLR / NO OCSP -> Signature Valid / LTV Enabled
  • No CLR / OCSP -> Signature Valid / Not LTV Enabled
  • CRL / OCSP -> Signature Valid / LTV Enabled

So the presence of embedded CRL data is enough to get a LTV enabled signature.  Notice how when only the OCSP is embedded we do not get an LTV Enabled signature.

When checking the *same* test PDF with Adobe DC 18 (2018.009.20044) : *none of the digital signatures are marked as LTV enabled* .  An interesting note: when checking the "Revocation tab" only information about OCSP check is shown (embedded or fetched real time or present in local cache) : no more mention of the CRL data.

The following questions arise:

* how is this possible? First both OCSP and CRL data needed to be embedded, then only the CRL data and in the end no signature is considered LTV enabled.

* what has changed ? why has this changed? Is what is considered an LTV Enabled signature by Adobe subject to so many changes?

* how can a LTV enabled signature be placed?

If Adobe support staff wants more info: please contact me : I can send you screenshots and test PDF files.

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:

CMS Examples.png

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

Views

3.3K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

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

Community Beginner ,
May 30, 2018

Copy link to clipboard

Copied

Hello,

we are having a strange situation with different Adobe versions and what each version considers a LTV Enabled signature.

In 2017 we were signing PDF documents with a timestamp from a TA and the data from CRL and OCSP check embedded in the digital signatures. This resulted in a signed PDF document that Adobe displayed as : LTV Enabled .  (unfortunately I cannot give you the version number of the Adobe DC instance used at that time)

We are having some problems with the OCSP service of the CA of our document signing certificate, so we have been signing with timestamp and CRL embedded only.

When viewed with Adobe 2017 (2017.12.20098 and 2017.12.20044) we have the following results for some test PDF's:

  • No CLR/ No OCSP (only timestamp)  -> Signature Valid / Not LTV Enabled
  • CLR / NO OCSP -> Signature Valid / LTV Enabled
  • No CLR / OCSP -> Signature Valid / Not LTV Enabled
  • CRL / OCSP -> Signature Valid / LTV Enabled

So the presence of embedded CRL data is enough to get a LTV enabled signature.  Notice how when only the OCSP is embedded we do not get an LTV Enabled signature.

When checking the *same* test PDF with Adobe DC 18 (2018.009.20044) : *none of the digital signatures are marked as LTV enabled* .  An interesting note: when checking the "Revocation tab" only information about OCSP check is shown (embedded or fetched real time or present in local cache) : no more mention of the CRL data.

The following questions arise:

* how is this possible? First both OCSP and CRL data needed to be embedded, then only the CRL data and in the end no signature is considered LTV enabled.

* what has changed ? why has this changed? Is what is considered an LTV Enabled signature by Adobe subject to so many changes?

* how can a LTV enabled signature be placed?

If Adobe support staff wants more info: please contact me : I can send you screenshots and test PDF files.

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:

CMS Examples.png

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

Views

3.3K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Community Beginner ,
Jun 18, 2018

Copy link to clipboard

Copied

Hello,

So as I mentioned above: I tested earlier with a recent Adobe Reader 2018 (2018.009.20044) and non of the above options got the "LTV Enabled" mark. 

I did some more tests and I had mixed results!  Sometimes the digital signatures with CRL/OCSP embedded were "LTV Enabled" , sometimes not!  When they were not, I restarted Adobe Reader and suddenly they were "LTV Enabled".  Very strange behaviour.

Today I did some more tests:  like before digital signatures with CRL/OCSP embedded were "LTV Enabled" , no restarts needed.

Note that the old Adobe Reader 2017 version also accepts digital signatures with only CRL embedded as "LTV Enabled" .

Can anybody at Adobe staff (Steven.Madwin​ maybe?) shed some light on this please?

Can we assume now that we need to embed both CRL and OCSP data in to get an LTV enabled signature?

Thank you for your time.

best regards,

Loïc

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Community Beginner ,
Jul 27, 2018

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Aug 15, 2018

Copy link to clipboard

Copied

Hi Loïc,

Please send me a signed PDF file where the OCSP response has been embedded into the PDF file, but Acrobat is reporting that the signature is not LTV enabled. Please send the file to Steven.Madwin@adobe.com and I'll take a look. My initial guess is the OCSP response is not actually embedded, but is being procured in real time, but we'll know when I can crack the file open.

<sarcasm> It's not like we've ever had a bug in Acrobat before.</sarcasm>

Thanks,

Steve

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Aug 16, 2018

Copy link to clipboard

Copied

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:

CMS Examples.png

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Community Beginner ,
Aug 17, 2018

Copy link to clipboard

Copied

Thank you very much for your detailed response!

I will  talk to iText about the issue concerning the OCSP response that does not end up embedded in the PDF document. I can now also explain to the end users about why the document is not always marked as LTV enabled.  Thank you!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Community Beginner ,
Oct 01, 2018

Copy link to clipboard

Copied

Steven.Madwin​ Thanks this helped me a lot too!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
New Here ,
Apr 03, 2019

Copy link to clipboard

Copied

Hi Steven Madwin,

We are experiencing the same issue while producing the PDF ISO based (PKCS7) long term signature with embedded revocation information. Revocation information of complete signer certificate chain is embedded in signature signed attributes. But when we open signed document in Adobe Reader DC, Adobe Acrobat and Adobe Reader XI, it says Signature is not LTV enabled. I have sent the signed PDF document, certificate chain, TSA chain, embedded CRLs, OCSP response etc. to your email address Steven.Madwin@adobe.com

Your prompt response is highly appreciable to solve this issue.

Thanks.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Apr 04, 2019

Copy link to clipboard

Copied

Responded via e-mail reply. I'm not going to post the response because it contained PII, but I can say that the crux of the matter was the non-Adobe, third-party signing application did not embed all of the necessary revocation information that is required for a digital signature to be considered Long Term Validation (LTV) enabled.

Steve

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
New Here ,
Apr 09, 2019

Copy link to clipboard

Copied

Hi Steve,

I have provided you all the details via email. We are embedding the correct necessary revocation information in the digital signature.

Your quick feedback on it is appreciable.

Kind Regards,

Israr

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Apr 11, 2019

Copy link to clipboard

Copied

Hi Israr,

You are correct, this is a bug. What is happening is Acrobat (and when I say Acrobat I really mean both Acrobat and Reader) validates the timestamp first in order to make sure that it is okay to use the timestamp time to perform the document signature validation. The timestamp signature is validated at the current time (all signature timestamps are validated at the current time, not just this one) which causes Acrobat to procure revocation information for both the DigitalSign Primary CA and AC Camerfirma Portugal – 2015 certificates (it’s really getting it for all four certs, but these are the two we care about in this instance). In this case Acrobat is procuring OCSP responses for both of those certificates. These two OCSP responses get loaded into Acrobat’s memory in order to facilitate signature validation elsewhere.

Elsewhere in this instance is the document signature. The signer’s cert, and its issuing Intermediate CA (ICA) cert are different than what was in the timestamp signing chain, so Acrobat won’t find valid rev info in memory so it looks first in the PDF file, finds the embedded OCSP response and the CRL and uses those. When it comes to validating the next two ICA certificates it finds the OCSP responses in memory and uses those, thus eliminating the need to look in the PDF file (Acrobat always uses what’s in memory first because it is significantly faster that reading from disk). Because Acrobat never verified that the CRLs were embedded in the file it reports LTV not being enabled.

The internal Adobe bug reference number is ADC-4259405.

Steve

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Urmi96 LATEST
New Here ,
Nov 05, 2019

Copy link to clipboard

Copied

Is this Bug with id: ADC-4259405 is Resolved ? I am facing same issue with diffrent Adobe versions on same file.  

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...