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?
