The zeitgitter
protocol sits on top of HTTPS and can be used to obtain
timestamped, signed git
objects to be added to one's git
repository,
typically using the git timestamp
command.
Like this, the timestamping server does not need to know any contents of
your git
repository, with the exception of some hashes and, when
signing a tag, also the name of the tag. Most importantly, the
timestamper does not learn about:
- then contents of your files
- your users
- the number or times of any commits not submitted for timestamping
GET
request to the URL with the following variables:
request
:get-public-key-v1
POST
request to URL with the following variables:
request
:stamp-tag-v1
commit
: The SHA-1 commit ID to be tagged and timestampedtagname
: The name of the tag, limited to ASCII digits, letters, dash and underscore of at most 100 characters. Must start with a letter.
Returns a signed git
tag object referring to the commit object in the
response body as follows:
object <commit object ID>
type commit
tag <tagname>
tagger <timestamper name> <timestamper email> <Unix time> +0000
<message by the timestamper>
-----BEGIN PGP SIGNATURE-----
[…]
-----END PGP SIGNATURE-----
Before adding the object to the git
object store, the client should
verify that:
- The commit ID matches what it sent
- The tag name matches what it sent
- The timestamper name/email matches what it expects; its length does not exceed 200 characters
- The Unix time lies between the start of the request and the end of the request, within a given fuzz parameter (e.g., 30 seconds)
- The message contains only ASCII printable characters and newline
(
\n
, ' '…'~'); its length does not exceed 1000 characters - The PGP signature contains only ASCII printable characters and newline; its length does not exceed 4000 characters
- The PGP signature verifies as a detached signature to the remainder of the tag's contents (the contents are treated as binary data, no text normalization is done).
- The PGP signature timestamp also lies within the window of the Unix time as specified above (it does not necessary need to be identical, as the timestamping process does not make it easy to guarantee this)
- Only a single signature should be present
POST
parameters can submitted in either
application/x-www-form-urlencoded
or multipart/form-data
format.
POST
request to the URL with the following variables:
request
:stamp-branch-v1
commit
: The SHA-1 commit ID to be timestampedparent
(optional): The SHA-1 commit ID to be listed as the branch parenttree
: The SHA-1 tree ID of the file contents
Returns a signed git
commit, looking like a merge from the commit
to the branch of the parent
, but with the exact file contents of the
tree at commit
:
tree <tree ID>
parent <parent ID>
parent <commit ID>
author <timestamper name> <timestamper email> <Unix time> +0000
committer <timestamper name> <timestamper email> <Unix time> +0000
gpgsig -----BEGIN PGP SIGNATURE-----
[…]
-----END PGP SIGNATURE-----
<message by the timestamper>
Before adding the object to the git
object store, similar to the
tag signature behavior above, the client should verify that:
- Tree, parent, and commit IDs match what it sent
- The
author
andcommitter
follow thetagger
rules above - Unix times and PGP signature times follow the rules above
- PGP signature and message bodies follow the rules above
- For signature verification,
gpgsig
multi-line header must be stripped from the resulting file
- For signature verification,
Assuming you branch-sign every commit of the master
branch into the
timestamp
branch, the two will develop in parallel, with timestamp
being a timestamper-signed equivalent of the former.
If your organisation would like to issue many timestamps a day, we recommend
operating your own local zeitgitter
instance and timestamp internally against your
local instance and only obtain timestamps for your zeitgitter
repository from
outside source(s). This results in several advantages:
- No information about your commit rates is leaked.
- No information about your developer's IP addresses is leaked.
- You can assure a level of service according to your own needs.
- You can adjust the security parameters according to your own needs.
- The global network of timestamping servers is being loaded less, …
- … even if you cross-timestamp against multiple outside sources.
- Using multiple cross-timestamps will increase the trust.
(We would appreciate if you would also allow other public timestampers to cross-timestamp against your server to increase the overall trust in the system.)
✅ Help us building an efficient hierarchy of trusted timestampers, or even a complete web of timestampers.