Bug 119309 - AdES Digital Signatures
Summary: AdES Digital Signatures
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Miklos Vajna
Whiteboard: target:6.2.0
: 105856 (view as bug list)
Depends on:
Reported: 2018-08-16 07:33 UTC by Andrii Melashchenko
Modified: 2021-10-29 18:29 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrii Melashchenko 2018-08-16 07:33:25 UTC
EU has developed the opensource tool https://github.com/esig/dss to verify different Digital Signatures including ASiC-E type = ODT container.
But while trying to use LibreOffice to created signed AdES document, DSS tool can't verify ODT signature.
Details - https://ec.europa.eu/cefdigital/tracker/browse/DSS-1473

Way to reproduce
1 Sign odt with libreoffice
2 Use online tool https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation to validate odt object (simply upload under Signed file)

According to recommendations, we must add type="http://uri.etsi.org/01903#SignedProperties" to ds:Reffernce object

Steps to Reproduce:
1 Sign odt with libreoffice
2 Use online tool https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation to validate odt object (simply upload under Signed file)

Actual Results:
invalid XAdES signature

Expected Results:
XAdES signature according ETSI EN 319 132-1 V1.1.1 (2016-04) + packed as ASiC ETSI EN 319 162-1 V1.1.1 (2016-04)

Reproducible: Always

User Profile Reset: Yes

OpenGL enabled: Yes

Additional Info:
Comment 1 Julien Nabet 2018-08-16 07:53:35 UTC
Miklos/Samuel: thought you might be interested in this one since it concerns ODT signature.
Comment 2 Andrii Melashchenko 2018-08-16 10:09:59 UTC
FYI online app is not correct yet, according to DSS app comment (https://ec.europa.eu/cefdigital/tracker/browse/DSS-1473 )
" I'll need to adapt DSS to fix the "signatures cover the mimetype file and manifest file(s). I'm not sure that these files require to be covered. I'll need to contact experts to confirm." (I sent an email and I'm waiting for their reply). For now, DSS will always conclude with INDETERMINATE / SIGNED_DATA_NOT_FOUND."
Comment 3 Miklos Vajna 2018-08-16 11:48:32 UTC
FWIW our implementation covers both and there is a good reason for that: if that's not the case then you only sign part of the document, which is quite misleading.

Needinfo till there are known problems with the validation tool.
Comment 4 Pierrick Vandenbroucke 2018-08-16 12:15:38 UTC

I'll keep you informed about the files covering. IMO, if we refer to ETSI EN 319 162-1 ch, the META-INF/manifest.xml could be covered but the mimetype file is not in the scope of the signature.

Anyway, there's another issue with the XAdES building. The reference which points to the SignedProperties shall have this specific type : http://uri.etsi.org/01903#SignedProperties. (rf : ETSI EN 319 132-1 ch 4.4.2). This point was also specified in the previous standard ETSI TS 101 903 ch 6.3.1.


Comment 5 Miklos Vajna 2018-08-16 12:35:58 UTC

No problem if you don't warn on that, my worry is if you reject a signature because it covers the mimetype file.

That would be unfortunate, as reducing the data we sign is not great, but otherwise the signatures we generate won't pass your validation.


Comment 6 Pierrick Vandenbroucke 2018-08-16 13:19:01 UTC

The second point is much more important (missing type attribute). If DSS (and probably other tools) doesn't validate your files, that will be the main cause.

I invite you to test the conformance of your XAdES files with the ETSI conformance checker (http://signatures-conformance-checker.etsi.org).


Comment 7 Miklos Vajna 2018-08-16 18:03:12 UTC
Oh, I'm just stupid. We already do what you say for OOXML signatures, we should do the same for ODF. I'll take care of this.
Comment 8 Commit Notification 2018-08-27 17:16:31 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":


tdf#119309 xmlsecurity xades: missing XML attribute on idSignedProperties ref

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 9 Miklos Vajna 2018-08-27 18:13:15 UTC
^ this improves the DSS validator output, so that "Qualification Signature" section is no longer just a red "N/A" but an orange "Indeterminate QESig" for me.

Please open follow-up bugs if anything else is still needed (i.e. not something that should be fixed in the validator). Thanks!
Comment 10 Pierrick Vandenbroucke 2018-09-13 09:40:31 UTC

I have tested the version 6.2 from daily builds. The type attribute is well present.

Which is the followed specifications to select covered files ? 

ODF 1.2 ch 3.16 specifies all files except META-INF/documentsignatures.xml  and external-data/.


Comment 11 Miklos Vajna 2018-09-13 09:46:39 UTC
Hi Pierrick,

It's correct to expect we follow what's in ODF 1.2.

When we append META-INF/documentsignatures.xml to a previously unsigned document, we sign all the existing streams, which in practice matches what you write. If some of the streams (except the signature stream itself) is not signed, then we don't consider the signature valid.


Comment 12 Pierrick Vandenbroucke 2018-09-13 10:39:22 UTC
Hi Miklos,

Thanks for your reply.

In the signed ODT that I generated, the files in the Configurations2 folder are not covered. 

Does it the expected behavior ? 


Comment 13 Miklos Vajna 2018-09-13 11:49:35 UTC
As long as you only have empty subfolders in the Configurations2 folder, yes. The signatures stream is supposed to sign files only, not folders.
Comment 14 Pierrick Vandenbroucke 2018-09-13 12:19:29 UTC
Ok, thanks for the clarification.

You are right, this folder only has empty sub-folders.
Comment 15 Gabor Kelemen (allotropia) 2021-10-29 18:29:55 UTC
*** Bug 105856 has been marked as a duplicate of this bug. ***