1

I had issues some months ago with signed PDFs and LTV. Acrobat Reader showed that the signature is LTV enabled and after some months it started to say otherwise, the signature is not LTV enabled and will expire in around 1 year after the signing.

Now I'm working on an a new implementation and just wanna make sure that the LTV won't disappear this time. I got some tips about using the DSS library also to validate my signatures. Adobe says this time also that the signature is LTV enabled. The DSS validator is complaining about one thing: The signed attribute: 'signing-certificate' is absent! I have checked and it's right because there is no signing-certificate attribute in the ASN1 structure but there is signing certificate V2. I tried to also add the signing-certificate attribute but then I got some other issues. I may have done this the wrong way though. Is there a need for having both? Should/can I ignore this warning? How can one be sure about the LTV? Is there some other way for validation?

enter image description here

enter image description here

krillov
  • 79
  • 1
  • 14

2 Answers2

1

First off, the term "LTV enabled" is not as well defined as one might wish for. As has been mentioned a number of times here on stack overflow (e.g. here, here, or here), Adobe Acrobat displays that a given signature is "LTV enabled" if during validation it observed that it did not need to access remote sources to retrieve information it required for validation.

Thus, whether or not Adobe Acrobat considers your signature LTV enabled, depends on the (closed!) algorithms of the Adobe signature validation code and the configuration of the signature validation in Adobe Acrobat.

Both these factors are subject to change!

In essence, therefore, you cannot be "sure about the LTV"!

Nonetheless, you can try your best to provide as much relevant validation related information and fix it in time. This improves your chances that your signatures are and will continue to be considered LTV enabled by Adobe Acrobat.


Now concerning your questions:

signing-certificate ... signing-certificate V2 ... Is there a need for having both?

To begin with, these attributes are not required by Adobe Acrobat validation routines. (Not yet, that is.) So this is not (yet?) relevant for your objective.

If you are interested nonetheless - no. If your signature algorithm relies on SHA-1 for hashing (which it of course should not!), you should use the plain signing-certificate attribute (in CMS called ESSCertID). If it relies on a different, more advanced algorithm, you should use the newer signing-certificate-V2 attribute (in CMS called ESSCertIDv2) and use the same hash algorithm as in your signature algorithm.

Only if your signatures will also be verified by older (well, ancient) software that supports ESSCertID but not yet ESSCertIDv2, you might consider adding both attributes.

In the context at hand, by the way, eSig DSS does support both ESSCertID and ESSCertIDv2. Thus, if it says that the signing attribute is missing, that means that there is something fishy about the signing-attribute V2 you saw in your signature...

Should/can I ignore this warning?

In respect to Adobe's "LTV enabled" profile, you currently can ignore the warning for now. And whether or not Adobe will start requiring that attribute by default in the future and (if yes) how exactly, is hard to tell.

How can one be sure about the LTV? Is there some other way for validation?

As mentioned above, you can not be sure about the "LTV enabled" status of your signatures.

Considering the screen shot you shared, though, it mentions that your PDF signature reached only a BASELINE-T equivalent level. In particular, you did not reach a BASELINE-LT equivalent, let alone a BASELINE-LTA equivalent here. Thus, as far as ETSI conform validation goes, the required revocation information were not all found in your PDF.

Adobe's validation rules (currently) are very lax in comparison with the ETSI rules, so it might display "LTV enabled" nonetheless. Unless you want to improve your signatures to BASELINE-LT at least, though, using eSignature DSS won't help you as validation tool...

mkl
  • 90,588
  • 15
  • 125
  • 265
  • Really good and detailed as always. I'm using SHA-256 and also Bouncy castle CMSSignedDataGenerator partially for generating the signed data object and it adds that attribute automatically. Might change to PAdES in the future but right now that isn't an option because as I understand PAdES needs multiple increments for one signature if I want to have LTV. I checked the requirements for BASELINE-LT but I think I should have everything already in the signature to reach that level. I'm adding the certificates, ocsp, crl and timestamp. Could the format be PKCS7-LT in the validator? – krillov Feb 08 '22 at 15:56
  • *"Could the format be PKCS7-LT in the validator?"* - Which eSignature DSS version do you use? IIRC there was some additional support for legacy validation information added not too long ago... – mkl Feb 08 '22 at 16:20
  • I use the online one for now just for testing purposes. – krillov Feb 08 '22 at 16:24
  • Well, by the online one you mean which one? https://dss.nowina.lu/validation and https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation should both be quite current but there might also be some older mirrors. – mkl Feb 08 '22 at 16:35
  • I meant the second one. – krillov Feb 08 '22 at 16:35
  • Hhmmm, ok. Well, essentially I'd need an example file to check the validator with to look into that. – mkl Feb 08 '22 at 16:37
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/241826/discussion-between-krillov-and-mkl). – krillov Feb 08 '22 at 16:39
0

Use DSS, not Adobe

Your signature is "total passed" : no problem about the seal itself.

Check the "Validation Process for Signatures with Archival Data" in DSS "Detailed Report" tab for the result of LTV Validation. Beware validation only makes sense when you make it (if a certificate used for validation expires ...). You can extend a signature (include CRL / OCSP while they are valid).

pibou
  • 51
  • 5