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 ".tsr" value mentioned
-above).
-
-
-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?
-
