Qualified signature showing invalid only in Adobe Reader

Question

Here is PDF with qualified electronic signature pdf-qualified.invalid.pdf

All validation apps show it correct as PAdES-BASELINE-LT, however Adobe Reader shows it invalid. What is wrong with this digitally signed PDF? It includes CAdES-BASELINE-LT signature, all OCSPs, all needed Certs.

Adobe reader shows its invalid

EU validation shows signature is valid at https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation

DigiDoc4 app shows signature is valid

https://www.eparaksts.lv/ shows it is valid

Here we can see the PDF structure related to the digital signature

Tritanopia

Answer 1

CAdES signature was baseline-LT level. When downgrading CAdES to baseline-T then it started working.

I would say its Adobe Reader bug unless some specification explicitly says that CAdES in baseline-LT level is not allowed.

Tritanopia

Beware, you don't get a PAdES Baseline-LT by embedding a CAdES Baseline-LT into a PDF. Instead you embed a (specially profiled) CAdES Baseline-B or -T into a PDF and then extend the PDF accordingly by extra objects. – Leer

"I would say its Adobe Reader bug unless some specification explicitly says that CAdES in baseline-LT level is not allowed." - Well, the specifications don't explicitly say CAdES baseline-LT is not allowed but they explicitly state what is allowed and the signature container you embedded originally does not live up to that. – Leer

CAdES is created with European Commission DSS library so should be conformant. When making only change to have CAdES without OSCP at baseline-T instead of -LT the Adobe Reader worked. OCSP and Certs are in DSS as well for PAdES baseline-LT – Tritanopia

Yes, just like i said. – Leer

Answer 2

There are some issues in the signature container embedded in your PDF.

Your PDF is version 1.5 and the signature uses the subfilter ETSI.CAdES.detached. Thus, the embedded signature container should be conform to ETSI EN 319 142-1 (PAdES building blocks) which also refers to ETSI EN 319 122-1 (CAdES building blocks). But there are deviations:

First of all the CMSVersion shall be set to either 1 or 3 (CAdES 4.4). But in your case it is set to 5.

Then SignedData.crls contains entries, in particular one with type other. This field in case of PAdES should not be used anyways, in particular not with such entries. Actually this entry is the reason for the invalid CMSVersion mentioned above: If SignedData.crls contains an entry with a type of other, RFC 5652 requires version 5.

The SignerInfo of your signature container contains a signingTime signed attribute. This is explicitly forbidden for PAdES BASELINE signatures (PAdES 6.3).

It also contains a cmsAlgorithmProtection signed attribute. While not explicitly forbidden, this attribute is not on the list of attributes that may be used in PAdES (PAdES 5.2).

Also there is at least one issue in the embedded certificates: One of them has a long list of extended key usages, timeStamping being one of them. But that extended key usage may only be used alone.

This is where I stopped looking for further issues, so the list might be incomplete. You probably should start by using less complex signature containers and (when that works) try to add extra features one by one to check whether they mean trouble with Adobe Reader.

By the way, such an issue might actually be due to Adobe Reader not supported some algorithm used in your signature; the list of crypto algorithms supported by Adobe Reader is very short, a number of algorithms allowed in the EU for qualified signatures are not supported.

Leer

Good and detailed info here :) – Tritanopia