How to distinguish signature and timestamp during validation about pyhanko HOT 6 CLOSED

The use case is the following:
We have a web application that drives the signatures process. The author can upload a document and invite people to sign by email. These get an email in which they can click on a link for signing the PDF at its current storage location with Adobe Reader DC. The web application detects changes in the pdf and updates the status of the document in the web application. The author can check the current status in the web application. If all invited persons have signed the web application makes sure that the document is LTA-compliant by adding, if required, verification information to each signature (makes them LT compliant) and put a final timestamp to the PDF at the end (makes them LTA). Since users sign with their Adobe Reader DC, we sometimes have the problem that the Adobe reader is not correctly configured (e.g. is not using an external timestamp provider). When the author checks the progress of the signing process, each already available signature shall be checked and validated and the result displayed in the web app. That works fine. But if the author looks at the document at the end of the process, there is already the final timestamp that causes the problem.

For our use-case it would probably already be ok if the final timestamp would not be validated. But to skip its validation I have to be able to distinguish EmbeddedPDFSignature objects that are normal signatures from objects that represent a simple timestamp. Something like EmbeddedPDFSignature::isSignature() ->true,false

Otherwise, I have to switch to the LTV validation method once the process is finished.

I hope that clarifies the use-case. Otherwise, let me know.

from pyhanko.

from pyhanko.

That's a very valid point. The short answer is that right now there's no easy way to only validate a timestamp using the high-level API.

The long story is that I'm aware of this limitation, and that validating timestamps separately is an issue on my backlog. Not that it's hard to do, but representing it properly in the API is a bit of a challenge. I'll see if I can do something about that by the 0.6.0 release, but I can't promise anything yet :).
Note: the LTV validation logic does validate all relevant timestamps, for what it's worth.

For reference: what's your use case for validating timestamps outside that context? Is it because a failing timestamp blocks further LTV validation altogether? I'm certainly not judging, just gathering input for how I should improve the API design. :)

Somewhat related to this: I'm trying to figure out a good way to do "true" policy-based validation, which is less affected by most of the gotchas that plague pyHanko's current LTV trust model, but that'll be a slow process (and probably won't replace the current API either).

from pyhanko.

I think I see what you mean, and I actually was misremembering a number of things. The API already exposes separate functions for validating signatures and document timestamps. However, I apparently forgot to add the timestamp validation function to __all__, which caused it to be treated as internal API by the documentation generator, so it was probably hard to find. I'll rectify that (see here:

You're right though that EmbeddedPdfSignature should expose an easy way to tell the difference between signatures and document timestamps, which makes these APIs a bit clumsy to use. I'll add that in as well. :)

from pyhanko.

Do the changes in b611394 adequately address your concerns? There's a new sig_object_type property on EmbeddedPdfSignature to tell you whether something is a regular signature or a document timestamp, and there are also two new convenience accessors on PdfFileReader to only list regular signatures/timestamps.

(Don't worry about the pipeline supposedly failing, the simplifications resulting from this change ended up causing a very small net reduction in code coverage, which is what Codecov is complaining about)

from pyhanko.

The requested changes have been included in the 0.6.0 release I just did, and I believe that they adequately address the question in the issue title, so I'll close this issue now. If the fix doesn't address your needs, feel free to reopen, or (preferably) create a new issue. Thanks a lot!

from pyhanko.