Support for verifying OpenPGP standalone and timestamp signatures
Open, NormalPublic


Is it possible to add support for OpenPGP standalone (sigclass 0x02) and timestamp (sigclass 0x40) signatures for command "--verify"? Should I supply a patch for this feature?

stm created this task.Aug 24 2018, 7:04 AM
werner added a subscriber: werner.

What are your use cases?

stm added a comment.Aug 25 2018, 9:42 AM

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.

stm added a comment.Aug 27 2018, 9:30 PM

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.


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).

stm added a comment.Aug 30 2018, 6:55 AM

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.

stm added a comment.Aug 30 2018, 8:44 PM

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?

werner triaged this task as Normal priority.May 17 2019, 6:48 PM

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%.

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