ltvfix feature uses which PADes profile?

[satanu01]

No description provided.

[MatthiasValvekens]

No PAdES profile in particular. It's intended to add required validation info to the document security store (DSS) for a given signature, nothing more, nothing less. In theory, if the initial signature is PAdES-B-T, ltvfix should "upgrade" it to PAdES-B-LT (insofar as that makes sense). You can then (in principle) use the ltaupdate command to kickstart a timestamp chain, which would allow you to get PAdES-B-LTA.

However, in practice, things often aren't that simple:

• If you need ltvfix in the first place, chances are that the affected signature doesn't conform to PAdES structure requirements, which would make it impossible to get any form of PAdES compliance after signing, regardless of the tools you throw at it.

• PAdES profiles are file format requirements. The data you actually have to put in depend on environmental factors as well, so it's dangerous to expect things like "I have PAdES-B-LTA ==> everyone can validate my signature until the end of time".
  I confess that pyHanko's current validation logic muddies the waters on this one a bit, which is mostly my own fault. In my defense, doing trust validation over long timescales properly is hard---this task is currently backlogged pending further changes to my fork of certvalidator.

Executive summary: the ltvfix command adds validation data to the DSS, that's all. It is compatible with PAdES-B-LT(A), but doesn't guarantee compliance with any particular PAdES profile, at least not in the general case (because that's impossible).

Hope that helps.

---

EDIT: I just wanted to add that this is a very valid question, even though the answer probably isn't that satisfying. I'll try to do a better job of explaining these nuances in the documentation.

[satanu01]

Thank You for your reply....

But I have used Adobe Reader for validate the signature..

So please suggest me that which CLI commands and arguments must be use for a document signature, by which Adobe Reader can validate that signature until the end of world?

[MatthiasValvekens]

Well, you can get addsig to produce a PAdES-B-LT signature fairly easily, using the --timestamp-url, --with-validation-info and --use-pades flags. See this section in the documentation for an example. PAdES-B-LTA signature generation is not exposed directly in the CLI right now (not that that's difficult, I just haven't gotten around to it yet). As a workaround, you can use the ltaupdate command on the signed output file (see here). It will generate a warning, which should be safe to ignore on a "fresh" signature.

Bear in mind that your operating system's trust settings aren't necessarily the same as those of Adobe's products---in fact, they almost certainly aren't. You may need to tweak the validation context in the configuration file to get the results you need. See here.

Also, signatures require maintenance to remain validatable over long timescales, but that's usually not the signer's problem.

[satanu01]

Thank for your reply... It helps a lot...

But, I am using PKCS11 token for signing a document, so how to setup the validation context in the configuration file to get the results I need? (You refer https://pyhanko.readthedocs.io/en/latest/cli-guide/config.html#config-validation-context)

[MatthiasValvekens]

Whether you're using PKCS#11 or not shouldn't matter for setting up the validation context. By default, all certificates on the token will be read, and imported as untrusted certificates.

The only situation where you have to do anything special is when you need to set up one of the certificates on your token as a trust root (e.g. because the root certificate you need is not in your system trust store). In that case, you have two choices:

• Download the relevant root certificate from the internet (if you know where to find it) and add it to the trust roots in the usual way (see link above).
• Get the relevant root certificate from the token using a PKCS#11 management tool (I usually use pkcs11-tool), and add the resulting file to the trust root as usual.

Other than that, the validation config / PAdES compliance / revocation checker / ... don't care whether you're signing using a PKCS#11 token or using in-memory key material.

EDIT: Of course, if you have to go through these steps, there's a chance that the root certificate isn't in Acrobat's trust store either. If you're signing with a government-issued ID, Acrobat probably trusts it (while your OS might not), but it's impossible to say for sure without trying.

[stale]

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!