This is a copy of an email I posted to the nikita-noark mailing list. Please follow up there if you would like to discuss this topic. The background is that we are making a free software archive system based on the Norwegian Noark 5 standard for government archives.
I've been wondering a bit lately how trusted timestamps could be stored in Noark 5. Trusted timestamps can be used to verify that some information (document/file/checksum/metadata) have not been changed since a specific time in the past. This is useful to verify the integrity of the documents in the archive.
Then it occured to me, perhaps the trusted timestamps could be stored as dokument variants (ie dokumentobjekt referered to from dokumentbeskrivelse) with the filename set to the hash it is stamping?
Given a "dokumentbeskrivelse" with an associated "dokumentobjekt", a new dokumentobjekt is associated with "dokumentbeskrivelse" with the same attributes as the stamped dokumentobjekt except these attributes:
- format -> "RFC3161"
- mimeType -> "application/timestamp-reply"
- formatDetaljer -> "<source URL for timestamp service>"
- filenavn -> "<sjekksum>.tsr"
This assume a service following IETF RFC 3161 is used, which specifiy the given MIME type for replies and the .tsr file ending for the content of such trusted timestamp. As far as I can tell from the Noark 5 specifications, it is OK to have several variants/renderings of a dokument attached to a given dokumentbeskrivelse objekt. It might be stretching it a bit to make some of these variants represent crypto-signatures useful for verifying the document integrity instead of representing the dokument itself.
Using the source of the service in formatDetaljer allow several timestamping services to be used. This is useful to spread the risk of key compromise over several organisations. It would only be a problem to trust the timestamps if all of the organisations are compromised.
The following oneliner on Linux can be used to generate the tsr
file. $input is the path to the file to checksum, and $sha256 is the
SHA-256 checksum of the file (ie the "
openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
| curl -s -H "Content-Type: application/timestamp-query" \
--data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr
To verify the timestamp, you first need to download the public key of the trusted timestamp service, for example using this command:
wget -O ca-cert.txt \ https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
Note, the public key should be stored alongside the timestamps in the archive to make sure it is also available 100 years from now. It is probably a good idea to standardise how and were to store such public keys, to make it easier to find for those trying to verify documents 100 or 1000 years from now. :)
The verification itself is a simple openssl command:
openssl ts -verify -data $inputfile -in $sha256.tsr \ -CAfile ca-cert.txt -text
Is there any reason this approach would not work? Is it somehow against the Noark 5 specification?