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