SignatureValidationError: LTV signatures require a trusted timestamp about pyhanko HOT 2 CLOSED

Hi Leon,

Thanks for your interest in this project, and for the detailed report! That's an excellent question.

First, I'd like to caution that pyHanko's LTV validation is a little finicky, and the validation model is one of the things I still want to address before going to 1.0.0. So issues of this type occasionally arise. Due to these quirks, pyHanko's validation functionality is not super useful in production workflows in its current form, but it's still a handy diagnostic tool.

Having said that, in this particular case, the failure with --ltv-profile adobe is expected behaviour, and I actually disagree with the validation result in Acrobat. While "LTV enabled" is a proprietary Acrobat notion for which the exact criteria aren't publicly documented, this signature doesn't seem to contain a timestamp token (see: "Signing time from the clock on the signers computer"). I would argue that there's no reasonable definition of "LTV enabled" that covers this situation: after the signer's certificate expires/is revoked, the signature will become effectively impossible to validate if it's not timestamped, regardless of whether revocation information is present. This is perhaps easier to explain with an example.

Suppose that Bob works for Alice Corp. in the purchasing department. His job involves signing purchase orders, various legal agreements, etc., and submitting them to vendors. Suppose that he uses a personal certificate that identifies him as an employee of Alice Corp to sign those documents. If Bob changes jobs one day (or gets fired), it's reasonable to expect that his personal certificate will get revoked. Nonetheless, since employee churn is a normal thing, it would be problematic if that would suddenly cause Bob's prior signatures to become meaningless. The reason why this requires a timestamp becomes clear if we try to reason about what Bob would be capable of if he were acting in bad faith.

While working at the company, Bob (or anyone else, really) could collect & store revocation information for his personal certificate on a daily basis. Note that revocation data isn't linked to any particular signature. If Bob wanted to cause trouble for his boss after getting fired (and after having his certificate revoked), he could still pull this trick:

• draft up a purchase order for some ridiculous amount of money,
• backdate it to some date in the past (when his certificate was still valid),
• sign the document with revocation information from that time in the past, and
• conveniently "lose" the private key and claim that it was compromised, for plausible deniability.

If Bob's earlier signatures weren't timestamped, a forgery of this type is indistinguishable from any past "legitimate" signatures that Bob may have made. Therefore, the cryptographic guarantees of those earlier signatures would break down in this case. As such, I don't think you can call them LTV-enabled.

TL;DR: since revocation information is typically not bound to any specific signature, embedding revocation info alone is not sufficient to make a signature future-proof. So in this particular instance, I'd argue that pyHanko does the right thing.

Anyway, the fact that I had to type all of this up clearly illustrates that pyHanko's docs aren't sufficiently clear on this point, so I suppose I'll have to do something about that! :)
Regardless, there are some validation improvements in the pipeline that should also give you (as the user) more control over what you consider acceptable, but I can't promise when those new features will land.

from pyhanko.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions!

from pyhanko.