public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha•warpmail.net>
To: Anton Wuerfel <anton.wuerfel@fau•de>, git@vger•kernel.org
Cc: i4passt@cs•fau.de, phillip.raffeck@fau•de,
	Junio C Hamano <gitster@pobox•com>
Subject: Re: Adding RFC 3161 timestamps to git tags
Date: Tue, 8 Mar 2016 14:28:54 +0100	[thread overview]
Message-ID: <56DED396.5070009@drmicha.warpmail.net> (raw)
In-Reply-To: <9bf0ad940a5ce20c0c3742a3dfca70f8.squirrel@faumail.uni-erlangen.de>

Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15:
> Hello,
> 
> 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.

Before talking about a specific header format (and, possibly, repeating
mistakes of the past) we should take a step back to exactly here: What
is the goal that you are trying to achieve?

"prove that a commit existed at a certain point in time" is a good
definition for that goal.

Based on our standing assumption that a commit SHA1 is unique, it is
sufficient to "prove that a SHA1 existed[was known] at a certain point
in time".

In particular, this does not need to take into account the DAG (beyond
what is determined through the SHA1) nor any prior timestamps.
Consequently, I don't think that warrants extending the object format in
any way - it is information in addition to what is in the DAG.

Also, it is conceivable that more than one user of the timestamp service
requests a timestamp for the same SHA1, and does so for a commit which
has children already, without wanting to (and without any intrinsic need
to) rewrite history.

To me, this means timestamps have no place in commit objects.

As for adding additional information to the DAG without altering it, we
have two means: tags and notes. Tags suffer from a "merge problem",
notes from a "transport" problem; for both of them you have to know how
to set up your refspecs.

So, I think a proper first step would be to make our "metadata handling"
(default notes refspec, merging) more use friendly, i.e. work out of the
box for the common use case (whatever that is).

That would serve timestamps well, and many other use cases.

> 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.
> 
> Regards,
> Phillip Raffeck
> Anton Wuerfel
> 

  parent reply	other threads:[~2016-03-08 13:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07 14:15 Adding RFC 3161 timestamps to git tags Anton Wuerfel
2016-03-07 20:19 ` Junio C Hamano
2016-03-08 10:20   ` Anton Wuerfel
2016-03-08 13:28 ` Michael J Gruber [this message]
2016-03-08 17:59   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DED396.5070009@drmicha.warpmail.net \
    --to=git@drmicha$(echo .)warpmail.net \
    --cc=anton.wuerfel@fau$(echo .)de \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=i4passt@cs$(echo .)fau.de \
    --cc=phillip.raffeck@fau$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox