Feature: Append only time stamp without own digital signature

[Mato-Z]

Hello. Would be possible add option append only time stamp without own digital signature from some TSA server (HTTP/HTTPS)?
This is necessary, for example:

• To preserve the so-called of "digital continuity" (for example by using periodical timestamping (e.g. each year), the availability or integrity of the validation data is maintained) - append only time stamp to the signed PDF document, so that it is still valid and usable for legal acts even after the expiration of the time stamp originally appended at the time of signing. This is the addition of the so-called "archival electronic time stamp" (this can also be qualified if TSA is on the EUTL list). The process is also defined by eIDAS and is described by ETSI here. This is a necessary requirement for the AdES (PAdES) BASELINE-LTA signature format (e.g. also addressed here). Adding a time stamp must be done before the expiration of the original time stamp (eg a moment before the expiration of its validity).
• To supplement the time stamp if you receive an digitally signed PDF document without any time stamp and you need to keep its validity indefinitely...

Many thanks for your consideration.

[JohnPlanetary]

I totally agree with the need of these functionality: be able to add only timestamps.
I myself would like to have it, and in fact I use it quite a lot, but I have to use another tool because JSignPDF doesn't have it yet. or sometimes I will keep signing the same document with my signature + different timestamp source.

Even better: allow the user to setup more that one (up to whatever number the user wants) timestamp sources to add after signing the file, or just add those timestamps either the file is already signed or not.
The purpose of these is to make it harder for third parties to deny something really existed, because with more and more sources it becomes increasingly more difficult to deny that something really existed at some date & hour in time. Also to prevent if some source starts declaring their timestamp as invalid. Also to allow to sign the same document to be considered valid (timestamp part) in more that one jurisdiction (for example EU timestamp authorities may not be accepted has valid source outside EU, and EUA timestamp sources may not be considered valid in EU, or may be valid in EU and USA but not in Brazil for example, these way it is possible to timestamp something to be valid to all relevant jurisdictions at once).

I'm curious because by reading the documents my doubt didn't disappear.
Example: I sign some document with my personal certificate, it is valid from 01-01-2021 to 01-02-2023, If I add a timestamp inside that time frame it will make it bigger up to the limit of that timestamping. But if I sign after the expiring date (say in 01-12-2035), while some timestamp is still valid that won't make the original certificate (that expires on 01-02-2023) still valid, correct? Because there is no way to be sure that the original certificate existed between 01-01-2021 to 01-02-2023 specially if all certificates and logs related to that cert are gone. Or I'm missing something? And sometime people can't even verify the timestamping certs because those ones also go way, and the logs eventually are also gone.
So I may keep signing the document while some existing timestamp certificate is valid, but that won't make the date go above after the 01-02-2023 original expiring date, if I sign it after that owner certificate was expire? To me that is the logic, no one can really know that the certificate was even really valid at that time if the current valid timestamp wasn't apply inside the validity time frame.

My main trouble with these Timestamping thing is that timestamping authorities are not required to add some sort of unique identifier that will be the same for ever that they add to some common database used by everyone else, and that anyone can download at anytime, and query at anytime, and aren't able to remove things, in order for anyone, anytime in the future to go there and see if that entry with that unique identifier, and associated data (hash, nonce, date & time and anything else relevant) are present. And something flexible enough to accept different hash algorithms (currently in use and future ones).
Today sometimes some timestamp certificates are even revoked... once revoked some or all timestamps may not even be trusted inside that time period! The only way to try to go around that is to use more than one timestamp service... but all of these won't stop the main problem: somewhere in the future no one will trust that data and there won't be any data to be sure is authentic... these is not a problem for short term validation, but if I need to proof in 50 years that I was the original person that created some program code, or some music letter, or something else there won't be any way someone can verify easily and beyond any doubt. I'm aware about other thing on the Internet some even based on bitcoin network and on other networks, but none of them seem either easy enough for anyone to check the information by itself, and even if there is one with a easy way, there isn't any guarantee it will still be around tomorrow much less in 50 years since there isn't dedicated security industry, governments and education institutions behind it making sure it is up and running for everyone benefit. The closest thing that I've seen online that would allow to anyone to see the info is correct was notbot [.] me service because it uses NXT blockchain and that one specifically allows the service to add a message with the original SHA256 hash received by the service, and that way anyone can compare the file/ document hash with the hash in the NXT blockchain message hash... but I don't have any idea if notbot or even NXT blockchain won't be gone tomorrow and much less in 50 or 100 years since it is not a blockchain widely used for the timestamping purpose by private and public sector... maybe exists maybe it won't exist tomorrow.

[kwart]

Partially addressed by the new DSS engine (#422): an archive timestamp is produced at LTA signing time (-eng dss -pl LTA). A standalone DocTimeStamp (append-only timestamp without a new signature) and LTA refresh on an already-signed PDF are still not implemented — keeping this open to track that remaining work.