Idea for storing trusted timestamps in Noark 5
pere at hungry.com
Wed Jun 7 21:14:41 CEST 2017
I've been wondering a bit about 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.
 <URL: https://en.wikipedia.org/wiki/Trusted_timestamping >
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.
 <URL: https://tools.ietf.org/html/rfc3161 >
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 "<sjekksum>.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 \
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?
More information about the nikita-noark