Re: Adding RFC 3161 timestamps to git tags

"Anton Wuerfel" [off-list ref] writes:

as part of an university project we plan to implement time stamp
signatures according to RFC 3161. This enables users to create and verify
cryptographic time stamp signatures to prove that a commit existed at a
certain point in time.

As a long-term goal, we would like to get this new feature accepted into
upstream, so we are very interested in your opinions and suggestions for
our approach described in the following.

We plan to add new command line options to git tag and call openssl
similar to how "git tag -s" is calling gpg. The time stamp query generated
by openssl will be sent to the time stamping authority via libcurl.
Verification of timestamps will be possible via git verify-tag.

In order to store time stamp signatures, the file format for git tags
needs to be extended. Similar to how gpg signatures are stored, we would
store the signed time stamp responses in base64 surrounded by BEGIN and
END tags:
-----BEGIN RFC3161-----
Issuer: [issuer-name]
[time stamp response in base64]
-----END RFC3161-----

We plan to offer git config options to configure, which timestamping
authority to use and where trusted certificates are stored.

A few random thoughts that come to mind, none of which is
rhetorical [*1*]:

 - What should happen when the timestamping service is unreachable?
   The user cannot get her work done at all?  A tag is created
   without timestamp and with a warning?  Something else?

 - Is "signed tag" the only thing that will benefit from such a
   certified timestamping mechanism?  Would it be worthwhile to
   offer a similar support for "signed commit"?

 - How would the certified timestamp interact with GPG signing of
   the tag?  Can they both be applied to the same tag, and if so
   what is signed by which mechanism and in what order or are they
   done independently and in parallel?  E.g. would the timestamp be
   done on the contents without GPG signature, and the GPG signature
   be done on the contents without timestamp, and both signature
   blocks concatenated at the end of the original contents?

 - Would it make sense to store the certified timestamp in the
   object header part, like the way GPG signature for signed commit
   objects are stored [*2*], instead of following the old-style
   "signed tag" that concatenates a separate signature at the end?


[Footnote]

*1* ... meaning that when I ask "Is X true?", I do not mean "I think
    X is true" or "I do not think X can possibly be true".

*2* We designed newer places that use GPG signatures (i.e. signed
    commit and merge tag) to store the signature in the header part
    for a reason: the base64 gobbledygook is not for human
    consumption and showing it together with the original contents
    would not help.

Hello Junio,

thanks for your reply. See my comments below.

"Junio C Hamano" [off-list ref] writes:

A few random thoughts that come to mind, none of which is
rhetorical [*1*]:

 - What should happen when the timestamping service is unreachable?
   The user cannot get her work done at all?  A tag is created
   without timestamp and with a warning?  Something else?

If the timestamping service is unreachable, we plan to output a warning
and abort the tag creation as a default behavior. However we could create
config option to allow the user to create a tag without a signature if the
TSA (timestamp authority) is not available.

 - Is "signed tag" the only thing that will benefit from such a
   certified timestamping mechanism?  Would it be worthwhile to
   offer a similar support for "signed commit"?

This is a good point. We will consider implementing this in signed
commits, too. Like in gpg-signed commits, rebases and changes of these
commits will not be possible any more without invalidating the timestamp
signature. However, the intention behind all this is to be able to verify
important steps in development and continue to be able to work and commit
without internet connection. Therefore our main focus is on tags with
timestamp signatures.

 - How would the certified timestamp interact with GPG signing of
   the tag?  Can they both be applied to the same tag, and if so
   what is signed by which mechanism and in what order or are they
   done independently and in parallel?  E.g. would the timestamp be
   done on the contents without GPG signature, and the GPG signature
   be done on the contents without timestamp, and both signature
   blocks concatenated at the end of the original contents?

Both GPG and timestamp signing can be assigned to the same tag. A GPG
signature includes the timestamp signature for one important reason: It
should not be possible to replace an existing timestamp signature by
another (later) timestamp signature. Including the timestamp signature
into the GPG signature prevents this.
Creating a timestamp signature without any GPG signature at all is
therefore possible but would be vulnerable to the described scenario.

 - Would it make sense to store the certified timestamp in the
   object header part, like the way GPG signature for signed commit
   objects are stored [*2*], instead of following the old-style
   "signed tag" that concatenates a separate signature at the end?

For timestamped commits we will, of course, use the new-style format. We
would also new-style format for git tags, leaving the GPG signature as is
and creating a timesig-header. However, mixing old-style and new-style
format in tag objects would introduce an inconsistency. Is this
problematic?

Regards,
Phillip Raffeck
Anton Wuerfel