{"thread":{"id":"41637","subject":"Adding RFC 3161 timestamps to git tags","startedAt":"2016-03-07T14:15:16Z","lastAt":"2016-03-08T17:59:39Z","messageCount":5,"participants":["Anton Wuerfel","Junio C Hamano","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"280325","messageId":"9bf0ad940a5ce20c0c3742a3dfca70f8.squirrel@faumail.uni-erlangen.de","threadId":"41637","inReplyTo":null,"subject":"Adding RFC 3161 timestamps to git tags","fromName":"Anton Wuerfel","fromEmail":"anton.wuerfel@fau.de","sentAt":"2016-03-07T14:15:16Z","receivedAt":"2016-03-07T14:15:16Z","isPatch":false,"sender":{"key":"anton.wuerfel@fau.de","avatar":null},"body":"Hello,\n\nas part of an university project we plan to implement time stamp\nsignatures according to RFC 3161. This enables users to create and verify\ncryptographic time stamp signatures to prove that a commit existed at a\ncertain point in time.\n\nAs a long-term goal, we would like to get this new feature accepted into\nupstream, so we are very interested in your opinions and suggestions for\nour approach described in the following.\n\nWe plan to add new command line options to git tag and call openssl\nsimilar to how \"git tag -s\" is calling gpg. The time stamp query generated\nby openssl will be sent to the time stamping authority via libcurl.\nVerification of timestamps will be possible via git verify-tag.\n\nIn order to store time stamp signatures, the file format for git tags\nneeds to be extended. Similar to how gpg signatures are stored, we would\nstore the signed time stamp responses in base64 surrounded by BEGIN and\nEND tags:\n-----BEGIN RFC3161-----\nIssuer: [issuer-name]\n[time stamp response in base64]\n-----END RFC3161-----\n\nWe plan to offer git config options to configure, which timestamping\nauthority to use and where trusted certificates are stored.\n\nRegards,\nPhillip Raffeck\nAnton Wuerfel\n"},{"id":"280331","messageId":"xmqq4mcioxbz.fsf@gitster.mtv.corp.google.com","threadId":"41637","inReplyTo":"9bf0ad940a5ce20c0c3742a3dfca70f8.squirrel@faumail.uni-erlangen.de","subject":"Re: Adding RFC 3161 timestamps to git tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-07T20:19:12Z","receivedAt":"2016-03-07T20:19:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Anton Wuerfel\" <anton.wuerfel@fau.de> writes:\n\n> as part of an university project we plan to implement time stamp\n> signatures according to RFC 3161. This enables users to create and verify\n> cryptographic time stamp signatures to prove that a commit existed at a\n> certain point in time.\n>\n> As a long-term goal, we would like to get this new feature accepted into\n> upstream, so we are very interested in your opinions and suggestions for\n> our approach described in the following.\n>\n> We plan to add new command line options to git tag and call openssl\n> similar to how \"git tag -s\" is calling gpg. The time stamp query generated\n> by openssl will be sent to the time stamping authority via libcurl.\n> Verification of timestamps will be possible via git verify-tag.\n>\n> In order to store time stamp signatures, the file format for git tags\n> needs to be extended. Similar to how gpg signatures are stored, we would\n> store the signed time stamp responses in base64 surrounded by BEGIN and\n> END tags:\n> -----BEGIN RFC3161-----\n> Issuer: [issuer-name]\n> [time stamp response in base64]\n> -----END RFC3161-----\n>\n> We plan to offer git config options to configure, which timestamping\n> authority to use and where trusted certificates are stored.\n\nA few random thoughts that come to mind, none of which is\nrhetorical [*1*]:\n\n - What should happen when the timestamping service is unreachable?\n   The user cannot get her work done at all?  A tag is created\n   without timestamp and with a warning?  Something else?\n\n - Is \"signed tag\" the only thing that will benefit from such a\n   certified timestamping mechanism?  Would it be worthwhile to\n   offer a similar support for \"signed commit\"?\n\n - How would the certified timestamp interact with GPG signing of\n   the tag?  Can they both be applied to the same tag, and if so\n   what is signed by which mechanism and in what order or are they\n   done independently and in parallel?  E.g. would the timestamp be\n   done on the contents without GPG signature, and the GPG signature\n   be done on the contents without timestamp, and both signature\n   blocks concatenated at the end of the original contents?\n\n - Would it make sense to store the certified timestamp in the\n   object header part, like the way GPG signature for signed commit\n   objects are stored [*2*], instead of following the old-style\n   \"signed tag\" that concatenates a separate signature at the end?\n\n\n[Footnote]\n\n*1* ... meaning that when I ask \"Is X true?\", I do not mean \"I think\n    X is true\" or \"I do not think X can possibly be true\".\n\n*2* We designed newer places that use GPG signatures (i.e. signed\n    commit and merge tag) to store the signature in the header part\n    for a reason: the base64 gobbledygook is not for human\n    consumption and showing it together with the original contents\n    would not help.\n"},{"id":"280359","messageId":"10a16fd003f1cc963cf64b42a2964fdf.squirrel@faumail.uni-erlangen.de","threadId":"41637","inReplyTo":"xmqq4mcioxbz.fsf@gitster.mtv.corp.google.com","subject":"Re: Adding RFC 3161 timestamps to git tags","fromName":"Anton Wuerfel","fromEmail":"anton.wuerfel@fau.de","sentAt":"2016-03-08T10:20:44Z","receivedAt":"2016-03-08T10:20:44Z","isPatch":false,"sender":{"key":"anton.wuerfel@fau.de","avatar":null},"body":"Hello Junio,\n\nthanks for your reply. See my comments below.\n\n\"Junio C Hamano\" <gitster@pobox.com> writes:\n\n> A few random thoughts that come to mind, none of which is\n> rhetorical [*1*]:\n>\n>  - What should happen when the timestamping service is unreachable?\n>    The user cannot get her work done at all?  A tag is created\n>    without timestamp and with a warning?  Something else?\n\nIf the timestamping service is unreachable, we plan to output a warning\nand abort the tag creation as a default behavior. However we could create\nconfig option to allow the user to create a tag without a signature if the\nTSA (timestamp authority) is not available.\n\n\n>  - Is \"signed tag\" the only thing that will benefit from such a\n>    certified timestamping mechanism?  Would it be worthwhile to\n>    offer a similar support for \"signed commit\"?\n\nThis is a good point. We will consider implementing this in signed\ncommits, too. Like in gpg-signed commits, rebases and changes of these\ncommits will not be possible any more without invalidating the timestamp\nsignature. However, the intention behind all this is to be able to verify\nimportant steps in development and continue to be able to work and commit\nwithout internet connection. Therefore our main focus is on tags with\ntimestamp signatures.\n\n\n>  - How would the certified timestamp interact with GPG signing of\n>    the tag?  Can they both be applied to the same tag, and if so\n>    what is signed by which mechanism and in what order or are they\n>    done independently and in parallel?  E.g. would the timestamp be\n>    done on the contents without GPG signature, and the GPG signature\n>    be done on the contents without timestamp, and both signature\n>    blocks concatenated at the end of the original contents?\n\nBoth GPG and timestamp signing can be assigned to the same tag. A GPG\nsignature includes the timestamp signature for one important reason: It\nshould not be possible to replace an existing timestamp signature by\nanother (later) timestamp signature. Including the timestamp signature\ninto the GPG signature prevents this.\nCreating a timestamp signature without any GPG signature at all is\ntherefore possible but would be vulnerable to the described scenario.\n\n\n>  - Would it make sense to store the certified timestamp in the\n>    object header part, like the way GPG signature for signed commit\n>    objects are stored [*2*], instead of following the old-style\n>    \"signed tag\" that concatenates a separate signature at the end?\n\nFor timestamped commits we will, of course, use the new-style format. We\nwould also new-style format for git tags, leaving the GPG signature as is\nand creating a timesig-header. However, mixing old-style and new-style\nformat in tag objects would introduce an inconsistency. Is this\nproblematic?\n\nRegards,\nPhillip Raffeck\nAnton Wuerfel\n"},{"id":"280367","messageId":"56DED396.5070009@drmicha.warpmail.net","threadId":"41637","inReplyTo":"9bf0ad940a5ce20c0c3742a3dfca70f8.squirrel@faumail.uni-erlangen.de","subject":"Re: Adding RFC 3161 timestamps to git tags","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-03-08T13:28:54Z","receivedAt":"2016-03-08T13:28:54Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15:\n> Hello,\n> \n> as part of an university project we plan to implement time stamp\n> signatures according to RFC 3161. This enables users to create and verify\n> cryptographic time stamp signatures to prove that a commit existed at a\n> certain point in time.\n\nBefore talking about a specific header format (and, possibly, repeating\nmistakes of the past) we should take a step back to exactly here: What\nis the goal that you are trying to achieve?\n\n\"prove that a commit existed at a certain point in time\" is a good\ndefinition for that goal.\n\nBased on our standing assumption that a commit SHA1 is unique, it is\nsufficient to \"prove that a SHA1 existed[was known] at a certain point\nin time\".\n\nIn particular, this does not need to take into account the DAG (beyond\nwhat is determined through the SHA1) nor any prior timestamps.\nConsequently, I don't think that warrants extending the object format in\nany way - it is information in addition to what is in the DAG.\n\nAlso, it is conceivable that more than one user of the timestamp service\nrequests a timestamp for the same SHA1, and does so for a commit which\nhas children already, without wanting to (and without any intrinsic need\nto) rewrite history.\n\nTo me, this means timestamps have no place in commit objects.\n\nAs for adding additional information to the DAG without altering it, we\nhave two means: tags and notes. Tags suffer from a \"merge problem\",\nnotes from a \"transport\" problem; for both of them you have to know how\nto set up your refspecs.\n\nSo, I think a proper first step would be to make our \"metadata handling\"\n(default notes refspec, merging) more use friendly, i.e. work out of the\nbox for the common use case (whatever that is).\n\nThat would serve timestamps well, and many other use cases.\n\n> As a long-term goal, we would like to get this new feature accepted into\n> upstream, so we are very interested in your opinions and suggestions for\n> our approach described in the following.\n> \n> We plan to add new command line options to git tag and call openssl\n> similar to how \"git tag -s\" is calling gpg. The time stamp query generated\n> by openssl will be sent to the time stamping authority via libcurl.\n> Verification of timestamps will be possible via git verify-tag.\n> \n> In order to store time stamp signatures, the file format for git tags\n> needs to be extended. Similar to how gpg signatures are stored, we would\n> store the signed time stamp responses in base64 surrounded by BEGIN and\n> END tags:\n> -----BEGIN RFC3161-----\n> Issuer: [issuer-name]\n> [time stamp response in base64]\n> -----END RFC3161-----\n> \n> We plan to offer git config options to configure, which timestamping\n> authority to use and where trusted certificates are stored.\n> \n> Regards,\n> Phillip Raffeck\n> Anton Wuerfel\n> \n"},{"id":"280377","messageId":"xmqqfuw0luk4.fsf@gitster.mtv.corp.google.com","threadId":"41637","inReplyTo":"56DED396.5070009@drmicha.warpmail.net","subject":"Re: Adding RFC 3161 timestamps to git tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-08T17:59:39Z","receivedAt":"2016-03-08T17:59:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15:\n>> Hello,\n>> \n>> as part of an university project we plan to implement time stamp\n>> signatures according to RFC 3161. This enables users to create and verify\n>> cryptographic time stamp signatures to prove that a commit existed at a\n>> certain point in time.\n>\n> Before talking about a specific header format (and, possibly, repeating\n> mistakes of the past) we should take a step back to exactly here: What\n> is the goal that you are trying to achieve?\n>\n> \"prove that a commit existed at a certain point in time\" is a good\n> definition for that goal.\n\nMoving the timestamp signature out of line has merits and demerits.\n\n - Inline timestamp signature proves that the commit existed at a\n   certain point in time, and also it proves that any descendant\n   commit was not there before that time.  Also, the object name\n   of the signed object itself protects the fact that it was created\n   with the signature (i.e. if you replace the signature, its object\n   name would change)--this can be a feature or inconvenience,\n   depending on your use case.\n\n - Out of line timestamp signature allows you to say \"I didn't\n   bother timestamping that commit I made 5 days ago, and it now is\n   buried 200 commits deep in the history from the tip, but I am\n   asking a timestamping service that the commit existed as of\n   now--I cannot go back and prove that it actually was made 5 days\n   ago, but at least the timestamp proves it was there today\".\n\n   It does not allow you to say anything about descendant commits,\n   though, like an inline timestamp would.\n\nThere is a convenience argument, too, for and against inline vs out\nof line signatures.\n\n - The original \"signed tag\" is a good out-of-line signature\n   mechanism that you can add signed attestation to a different\n   object (i.e. you made a commit either 2 seconds or 5 days ago,\n   and then you certify that you would want to call that with a\n   tagname with some messages and cryptgraphically sign that\n   retroactively).  Being in the ref namespace, it didn't scale for\n   use cases where you would want to have as many signatures as you\n   would have commits, though.\n\n - The \"signed commit\" is made in-line, and for those who want to\n   always validate each and every commit, not having to maintain a\n   separate collection of signatures was a convenience.\n\n - The \"merge signed tags\" is also made in-line, primarily for\n   convenience benefit, i.e. not having to keep collection of all\n   pull request tags out of line.\n\nI haven't thought deeply enough between in-line and out-of-line\nwhich would suit better for timestamp signatures, though.\n"}]}