What are your use cases?

DKGPG will contain programs to generate such signatures in its next release. Thus it would be nice, if those signatures can be verified by GnuPG as one of the most widespread OpenPGP implementations.

Moreover, in the mid term I will create and maintain a free set of utilities to operate Distributed OpenPGP Time-Stamping Services. Then a time-stamping unit (TSU, cf. RFC 3628) can be distributed among multiple parties to avoid single points of failure.

Last but not least, enhanced support of some fancy features from RFC 4880[bis] may be of independent interest. Otherwise technological progress and agility will circumvent OpenPGP.

Okay, can you please provide sample data for the test suite? Best using one of the existing keys but adding another one won't harm either.

Attached is a timestamp signature created with the test key (alfa, alpha, alice) from tests/openpgp.

The embedded signature is the so-called signature target, i.e., the signature the timestamp refers to.

Thanks.

The question is now to model the API for this. For 0x02 it seems to be pretty clear: We assume it is a detached signature on a zero length file and make sure that no signed file is given.

For 0x40 I am not sure what to do. Only checking the signature would be easy but does it then make sense to let the user parse the embedded signature? What I can imagine is to check the embedded signature against the second command line arg (signed data).

According to RFC 3628 there are two additional conditions to consider:

A timestamp or a time mark (which is an audit record kept in a secure
audit trail from a trusted third party) applied to a digital
signature value proves that the digital signature was created before
the date included in the time-stamp or time mark.

To prove the digital signature was generated while the signer's
certificate was valid, the digital signature must be verified and the
following conditions satisfied:

   1. the time-stamp (or time mark) was applied before the end of the
      validity period of the signer's certificate,

   2. the time-stamp (or time mark) was applied either while the
      signer's certificate was not revoked or before the revocation
      date of the certificate.

Please note that the time-stamping authority (TSA) probably cannot check these conditions, because the signer's certificate may not available there. Moreover, only the user (relying party) has the signed data to verify the embedded signature.

BTW: For TSA keys an additional key (usage) flag ("This key may be used for time-stamping") in RFC 4880bis would be nice. What do you think?

Snap question regards to the clock;

Can I ask what time scale the specifications are concern about? is it 10^-3 (millisecond classical internet) or 10^-6? (microsecond cloud-based RPC). I am asking because in engineering measurements inside fibre optic cables still a reduction of about 30%.

https://physics.stackexchange.com/questions/80043/how-fast-does-light-travel-through-a-fibre-optic-cable

FWIW, I disabled @aa7356 because he again started to troll.