Bug 147452

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.