0

In my case users need to be able to off-line validate PDF files using Adobe Reader DC in a network environment where Internet access is prohibited. Also long-term archival is expected by embedding revocation information and protecting them with document time stamps.

What I found is that Adobe Acrobat/Reader DC will nicely validate all signatures with embedded OCSP responses after they are created. However, in 2 hours the validation on time stamps that are embedded in signatures FAIL, as Adobe wants to download revocation data which it obviously can't due to lack of Internet access. I also noticed that Adobe always validates signature time stamps according to 'current time' while document time stamps are validated according to their own time stamp time.

So the question is: Why does Adobe not accept the revocation information from a couple of hours ago? Could it be that since the signature time stamp is always validated according to the current time, Adobe thinks that the OCSP response is too old (current time being after the NextUpdate time indicated in the OCSP response) and tries to obtain a new one?

If this is the case then I have two further questions:

  1. Why do we need to embed revocation data for signature embedded time stamps when creating LTA signatures, if Adobe always wants to have the current revocation?
  2. How is it possible to produce PDF documents that can be off-line validated if the embedded time stamp always requires revocation information to be freshly downloaded?
Amedee Van Gasse
  • 7,280
  • 5
  • 55
  • 101
Daniel
  • 1,391
  • 2
  • 19
  • 40
  • *Why do we need to embed revocation data for signature embedded time stamps when creating LTA signatures, if Adobe always wants to have the current revocation* - first of all: **adobe is *not* relevant**, you embed certain information to create a signature conforming to a given standard. Adobe merely is a software manufacturer and Adobe Reader and Adobe Acrobat merely are often used programs. But they don't define (anymore) what's right or wrong in the context of pdf. – mkl Aug 22 '16 at 20:44
  • You're right. Unfortunately Adobe Reader is still considered by many as a de-facto standard for anything PDF related. You have no idea how many times we had to implement workarounds for off-spec PDF files just because Reader could open/display/handle them. The same thing goes on here. I began my post with "In my case [...] using Adobe Reader DC" so I need to work with Adobe products at this particular client. Despite Adobe not _defining what's right or wrong_, I'm still curious about what the reasoning behind the workings of revocation checking is. – Daniel Aug 22 '16 at 20:54
  • BTW, the down-vote is not from me. It's sometimes really unfortunate that people can down-vote something without giving a reason. – mkl Aug 22 '16 at 20:58
  • I'd never think such thing after reading many of your other replies on SO. I'm curious though what triggered the down-vote. – Daniel Aug 22 '16 at 21:04
  • Could you also provide the pdf you observed this with? – mkl Aug 23 '16 at 04:38
  • Sure, here it is: https://www.dropbox.com/s/ef5rnsf09c187np/bitcoin-LTA.pdf?dl=0 (it's the same file as in my other question, but for conciseness it should be linked here too). – Daniel Aug 23 '16 at 07:10
  • This is not an iText question. I will remove the tag. – Amedee Van Gasse Aug 23 '16 at 11:04

0 Answers0