Created attachment 188110 [details] Signed PDF from AVDH service Attached document was signed by the https://magyarorszag.hu/avdh document signing service. When opened in LO, Draw sees two digital signatures, but one of them is not working, no details are shown about it. 1. Open attached document in Draw 2. Notice the infobar shows "This document has invalid signatures" warning. 3. Push the Show Signatures button 4. In the Digital Signatures dialog there are two signatures listed: one by AVDH Sign which is valid in itself, and one without any information. When opened in a browser, it lists one attachment which is a 1 page document. Maybe this part is misunderstood. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: df29592493367bc03c9602c924711852eecf64c4 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Note: the AVDH Signature requires two root CAs to be imported into the Firefox certificate store: from the https://hiteles.gov.hu/cikk/22/szolgaltatoi_tanusitvanyok site: http://qca.hiteles.gov.hu/cer/GOVCA-ROOT.cer (RSA Főtanúsítványkiadó) and http://qca.hiteles.gov.hu/cer/GOVCA-Qv2.cer (Minősített Tanúsítványkiadó v2)
Created attachment 188111 [details] The document in Draw with Digital Signatures dialog open
Self-confirming, since it's a somewhat(?) country-specific issue. Mikos, maybe this can interest you :).
Created attachment 199118 [details] A document with a valid document timestamp The file is unrelated to the Hungarian AVDH service. The (valid) document timestamp is reported by LibreOffice as an invalid (additional) signature.
Created attachment 199119 [details] A document with a valid signature timestamp The (valid) signature timestamp is ignored by LibreOffice.
This is due to a document timestamp (ETSI EN 319 142-1 Clause 5.4.3 / ISO 32000-2 Clause 12.8.5) included in the file. The issue is not country (or signer) specific and can be reproduced with any PDF file containing a document timestamp. We even log a rather helpful warning xmlsecurity/source/helper/pdfsignaturehelper.cxx:356: ValidateSignature: unsupported sub-filter: 'ETSI.RFC3161' and then report the "signature" as invalid. In general, it is not unreasonable to call a signature invalid if one cannot validate it. Yet it may make sense to report an unsupported signature as such. Most invalid signatures are invalid, because we know how to validate them and the process demonstrably fails. A signature we do not even attempt to validate is a different kind of "invalid". Ideally, one would implement the rather straightforward validation of (both kinds of) timestamps. In the meantime, it might make sense to (silently) ignore document timestamps the same way we ignore signature timestamps. Such behaviour would at least be consistent. Because they must have Type set to DocTimeStamp (and should also have SubFilter == ETSI.RFC3161), document timestamps are easy to tell apart from "real" signatures. Until we are able to validate the timestamps, properly ignoring them should be a reasonably easy hack.
> Until we are able to validate the timestamps, properly ignoring them should be a reasonably easy hack. I'm fine with that, the German d-trust pdf sign service creates the same ETSI.RFC3161 "signature", where I also saw this. Once concern is: when it comes to security, sometimes failing is better than ignoring something to be verified. So if we just ignore the signed timestamp, possibly somebody will consider it a security bug that the timestamp signature is silently not verified. Perhaps the way out is either just implementing the missing feature or a new error result saying "the signature is valid, but the timestamp is not verified".