https://bugs.documentfoundation.org/show_bug.cgi?id=147452
Bug ID: 147452
Summary: Timestamps on digital signatures incorrect
Product: LibreOffice
Version: unspecified
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: libreoff...@bug.blue
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.
--
You are receiving this mail because:
You are the assignee for the bug.
