In https://datatracker.ietf.org/doc/html/rfc5126#section-4.3.1 There is explained how CAdES-T works. +-------------------------------------------------CAdES-T ---------+ |+------ CAdES-BES or CAdES-EPES -------+ | ||+-----------------------------------+ | +----------------------+ | |||+---------+ +----------+ | | | | | ||||Signer's | | Signed | Digital | | | Signature-time-stamp | | ||||Document | |Attributes| Signature | | | attribute required | | |||| | | | | | | when using time | | |||+---------+ +----------+ | | | stamps. | | ||+-----------------------------------+ | | | | |+--------------------------------------+ | or the BES/EPES | | | | shall be time-marked | | | | | | | | Management and | | | | provision of time | | | | mark is the | | | | responsibility of | | | | the TSP. | | | +----------------------+ | +------------------------------------------------------------------+ In basics it's simple. Inside a CMS message there are things called 'signed attributes'. These consist of: * a hash of the original document and hash method (document-hash) * some reference to a certificate * and some more. Not to detailed here. A hash of these attributes is made (signedattrs-hash) A signature is generated with this signedattrs-hash. Therefore now a signature can be checked to an extend that: * The certificate provided proofs that a certain hash was signed (signing is just encrypting the signedattrs-hash basicly). * The signed attributes proof that it's about the document * Something checks the certificate for a root that matches. LibreOffice does this nice when using NSS (I don't do windows). The bug: How does timestamping work: When requesting a timestamp a new hash is made from the signature (sig-hash). This hash is sent to a timestamp provider. The timestamp provider signs this hash and you have an external proof that at some point in time the signature existed. Completing the above tree where you can proof that at (according to the timestamp provider) at some point in time the document signature (sig-hash) did exist and therefore the document. In master/svl/source/crypto/cryptosign.cxx#977 there is a new cms message created, this gets filled with some data and a signature is made at #988 At line #1000 a hash is made from the signature and after that converted into a timestamprequest (#1031), send to a timestamp server (#1047) At line #1193 the timestamp response is added to the final CMS message that is going to be used to sign the document: cms_signer At line #1288 after filling the cms_signer with a lot of (needed) contents a new signature is being generated. Conclusion: The signature made at line #988 is thrown away however this was the signature where a timestamp was requested for. The timestamp on at least any PDF being made with this bug existing is invalid and therefore all documents generated with this bug are not valid PAdES-T (or better) documents. What should be done is: * Generated a signature like on line #1288. * Use that signature to do the same as from line #1000 * Insert that timestamp into the signer infos. * Inform users about this bug and file internal compliance issues is libreoffice is being used on linux to sign documents with timestamps.
Created attachment 198625 [details] RSA PKCS #1 v1.5 signature produced on Linux; valid timestamp
Created attachment 198626 [details] RSA PKCS #1 v1.5 signature produced on Windows; valid timestamp
Created attachment 198627 [details] ECDSA signature produced on Linux; invalid timestamp
Created attachment 198628 [details] ECDSA signature produced on Windows; invalid timestamp
Thank you for reporting the bug. I was able to reproduce it on the following systems: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6e781525c4781e1b62dfd03f0352a82386c94019 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6e781525c4781e1b62dfd03f0352a82386c94019 CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win > The timestamp on at least any PDF being made with this bug existing is invalid If one uses a deterministic signature scheme such as RSA PKCS#1 v1.5, the timestamps are in fact valid. The signature computed in the second pass is equal to the discarded one. Depending on the token type, one may have to enter a PIN twice. This inconvenience alone can be considered a bug. If one uses a "randomized" signature scheme such as ECDSA, the timestamps are indeed invalid. The bug is present on both Windows and Linux. A fix shall follow shortly.
Juraj Šarinay committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/637e3c46192dc6fb5ff1a289f626b2fac698aed6 tdf#147452 Do not compute the signature twice when adding a timestamp on Windows It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Juraj Šarinay committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6783d251608ee09ff7167bb19d81160bd3de1d31 tdf#147452 Do not compute the signature twice when adding a timestamp using NSS It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Juraj: feel free to close this as fixed.