pyhanko.sign.validation.status - WARNING - The path could not be validated because the end-entity certificate expired 2022-05-25 04:17:25Z

[thomasgundlach]

Hello,

we try to validate a pdf-document from a bank which signer we basically trust by trusting D-TRUST_Root_CA_3_2016.crt. But the signers certificate was already expired in the moment of validation. Because of the expiration the validation will fail:

pyhanko sign validate --pretty-print 2022-07-15/2022-02-28_BKA_DEXX20050550XXXXXXXXXX_EUR_2-2022.pdf 2>&1
2022-07-15 15:37:43,064 - pyhanko.sign.validation.status - WARNING - The path could not be validated because the end-entity certificate expired 2022-05-25 04:17:25Z
2022-07-15 15:37:43,064 - pyhanko.sign.validation.status - WARNING - Chain of trust validation for Pseudonym: signaturservice_SPK_64:PN, Serial Number: DTRWM464089276922325, Common Name: signaturservice_SPK_64:PN, Country: DE failed.
======================
Field 1: Signaturfeld1
======================


Signer info
-----------
Certificate subject: "Pseudonym: signaturservice_SPK_64:PN, Serial Number: DTRWM464089276922325, Common Name: signaturservice_SPK_64:PN, Country: DE"
Certificate SHA1 fingerprint: f6429ca6dd69a41032fd5a8e8851d527cce707a5
Certificate SHA256 fingerprint: d474d45d188ca8ebbc3f39cf2b3e752babec09e2267339d4d7a5cde15cfc0e6e
Trust anchor: "No path to trust anchor found."
The signer's certificate is untrusted.


Integrity
---------
The signature is cryptographically sound.

The digest algorithm used was 'sha256'.
The signature mechanism used was 'rsassa_pss'.


Signing time
------------
Signing time as reported by signer: 2022-02-28T23:37:48+01:00


Modifications
-------------
The signature covers the entire file.


Bottom line
-----------
The signature is judged INVALID.


Error: Validation failed

If we had validate this document 2 months before the validation would be successful.
We cannot change the document. Everything else will be fine.

Is there any Option for pyhanko (CLI or python) that tells pyhanko to validate the document no matter of date certificate expiredate?

I cannot find anything in the docs that helps or may be don't understand it.

Best Regards,

Thomas

[MatthiasValvekens]

Hi @thomasgundlach,

This is a common issue in document signing, and common practice dictates that, if possible, one should attempt to ascertain the validity of the certificate at the time the signature was produced. The catch is that to allow that to be done more or less securely, the signer needs to supply a whole lot of additional data to ensure that

(a) there's a proper record of the signature's existence at (or close to) the claimed time of signing, witnessed by a trusted time stamping authority, and
(b) the revocation status of the certificate at that time can be checked.

Long story short, (a) is necessary because you generally can't trust signers to accurately report the time of signing themselves (that would allow backdating signatures, for example), and (b) is necessary because CAs can't be relied on to supply historical revocation info, especially not w.r.t. expired certificates.

While pyHanko's handling of point-in-time validation is still quite rough around the edges (as indicated on the known issues page), this document is a good example of someone Doing It Wrong™: the time of signing is an untrusted assertion (=unverifiable) and judging from the weird expiration timestamps, the signing service uses short-lived certificates, which pretty much require securely timestamped signatures to work in any reasonable trust model. To put it bluntly: given only this information, there's no way to distinguish between a valid signed document for which the signer's certificate happens to have expired, and a signature created with a (compromised?) key that was backdated to the original certificate's validity window. You might as well forget about all the expiration dates, then.

---

Anyway, assuming you don't care about any of that, there's a way to make all of that work by taking the time of signing at face value. That requires two things:

1. Extracting the (signer-reported!) time of signing from the signature, as documented in the API reference.
2. Setting the moment parameter in your ValidationContext to that value: https://github.com/MatthiasValvekens/certvalidator/blob/0.19.5/pyhanko_certvalidator/context.py#L302

Everything else follows the usual procedures for validation.

None of this is exposed in the CLI at this point, though. Would that help? Or are you happy with a Python-based solution?

[thomasgundlach]

Hej @MatthiasValvekens ,

thank you so much for another detailed answer, the background and that easy solution. I will contact the bank for asking why they doing that wrong :-)
If they are decide to continue doing that wrong, i'm fine with your python-based solution.

Have a nice weekend :-)

Thomas

[MatthiasValvekens]

Hi @thomasgundlach,

OK, great! One word of warning, though: given proper timestamping, revocation info and the like, it's very likely that pyHanko will be able to validate the signature, but currently that requires selecting an LTV profile using the --ltv-profile switch. That still doesn't work "automagically". Also, if you care about AdES-style point-in-time validation: pyHanko's PAdES-style validator is currently only a first-order approximation of the "real thing".

Anyway, that's being worked on, but it's not easy to get right :).

[MatthiasValvekens]

FYI, I went ahead and implemented the CLI support for this in #131. You can now get the behaviour you asked for in the CLI by calling the validate subcommand with --validation-time claimed (in the next release, that is). All the caveats from my initial answer still apply, though.

Having said that, for these short-lived, purpose-specific certificates, a validation approach of this type might nonetheless be fine if you have access through some kind of proof of existence of the signature very close to the time of signing (e.g. an upload record from a server you control, some kind of receipt from a third party, etc.). It all depends on your threat model and compliance requirements, though. YMMV.