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.

Recently, I started a new project at savannah for developing free software and documentation in order to operate a Distributed OpenPGP Timestamping Service. Everyone is welcome to join.

@werner I think as a first approach GnuPG should only verify timestamp signatures similar as your above suggestion on standalone signatures. Later we can add more functionality by an appropriate command line interface. What do you think?

Indeed we are in urgent need for a timestamping service. I was already pondering with the idea to integrate existing X.509 stamping services into OpenPGP signatures. Please write to gnupg-devel if you want to reach a wider audience. Unfortunately I need to abstain for getting involved in your project; there are too many other things to do.

We definitely should have this in 2.3.

I'm also interested in fine details especially w.r.t. interfacing with GnuPG. I've seen multiple timestamping standards starting from RFC3161, to blockchains or secure time protocols even (ab)using Certificate Transparency logs and ideas on how to append the signature (timestamp flag vs unhashed notations) so I'll be eager to hear the details on the ML @stm!

@wiktor-k Thanks for your interest.

My idea is to keep everything as simple as possible. Currently, the program dkg-timestamp generates the following structure of such an OpenPGP timestamp signature:

$ cat SecureSkat-2.15.tar.gz.sig | gpg --list-packets
# off=0 ctb=c2 tag=2 hlen=3 plen=337 new-ctb
:signature packet: algo 17, keyid 11CEB0B8A34891CE
	version 4, created 1565430330, md5len 0, sigclass 0x40
	digest algo 8, begin of digest 5f b2
	critical hashed subpkt 2 len 4 (sig created 2019-08-10)
	critical hashed subpkt 7 len 1 (not revocable)
	critical hashed subpkt 16 len 8 (issuer key ID 11CEB0B8A34891CE)
	hashed subpkt 20 len 31 (notation: accuracy@dkg-timestamp=1)
	hashed subpkt 20 len 87 (notation: serialnumber@i53u25l4zprfim66.onion=0A0CCBE6158CB4C76725B223F7123B729A2EC3E51978)
	critical hashed subpkt 32 len 93 (signature: v4, class 0x00, algo 17, digest algo 2)
	hashed subpkt 33 len 21 (issuer fpr v4 B20595F0156C521DCF56980311CEB0B8A34891CE)
	data: [254 bits]
	data: [254 bits]

The target signature, i.e. the target the timestamp refers to, is included as critical hashed subpacket of type 32. In the above example it is a binary document signature (class 0x00). To verify such a timestamp the user could call GnuPG with the regular "--verify" option and it infers the filename of the corresponding binary document by the filename of timestamp signature.

Sounds interesting @stm! Are there technical documents or specifications I could read to dig into details?