blog/data/2017-06-07-noark-trusted-timestamp.txt

   1 Title: Idea for storing trusted timestamps in a Noark 5 archive
   2 Tags: english, offentlig innsyn, standard, noark5
   3 Date: 2017-06-07 21:40
   4
   5 <p><em>This is a copy of
   6 <a href="https://lists.nuug.no/pipermail/nikita-noark/2017-June/000297.html">an
   7 email I posted to the nikita-noark mailing list</a>.  Please follow up
   8 there if you would like to discuss this topic.  The background is that
   9 we are making a free software archive system based on the Norwegian
  10 <a href="https://www.arkivverket.no/forvaltning-og-utvikling/regelverk-og-standarder/noark-standarden">Noark
  11 5 standard</a> for government archives.</em></p>
  12
  13 <p>I've been wondering a bit lately how trusted timestamps could be
  14 stored in Noark 5.
  15 <a href="https://en.wikipedia.org/wiki/Trusted_timestamping">Trusted
  16 timestamps</a> can be used to verify that some information
  17 (document/file/checksum/metadata) have not been changed since a
  18 specific time in the past.  This is useful to verify the integrity of
  19 the documents in the archive.</p>
  20
  21 <p>Then it occured to me, perhaps the trusted timestamps could be
  22 stored as dokument variants (ie dokumentobjekt referered to from
  23 dokumentbeskrivelse) with the filename set to the hash it is
  24 stamping?</p>
  25
  26 <p>Given a "dokumentbeskrivelse" with an associated "dokumentobjekt",
  27 a new dokumentobjekt is associated with "dokumentbeskrivelse" with the
  28 same attributes as the stamped dokumentobjekt except these
  29 attributes:</p>
  30
  31 <ul>
  32
  33 <li>format -> "RFC3161"
  34 <li>mimeType -> "application/timestamp-reply"
  35 <li>formatDetaljer -> "&lt;source URL for timestamp service&gt;"
  36 <li>filenavn -> "&lt;sjekksum&gt;.tsr"
  37
  38 </ul>
  39
  40 <p>This assume a service following
  41 <a href="https://tools.ietf.org/html/rfc3161">IETF RFC 3161</a> is
  42 used, which specifiy the given MIME type for replies and the .tsr file
  43 ending for the content of such trusted timestamp.  As far as I can
  44 tell from the Noark 5 specifications, it is OK to have several
  45 variants/renderings of a dokument attached to a given
  46 dokumentbeskrivelse objekt.  It might be stretching it a bit to make
  47 some of these variants represent crypto-signatures useful for
  48 verifying the document integrity instead of representing the dokument
  49 itself.</p>
  50
  51 <p>Using the source of the service in formatDetaljer allow several
  52 timestamping services to be used.  This is useful to spread the risk
  53 of key compromise over several organisations.  It would only be a
  54 problem to trust the timestamps if all of the organisations are
  55 compromised.</p>
  56
  57 <p>The following oneliner on Linux can be used to generate the tsr
  58 file.  $input is the path to the file to checksum, and $sha256 is the
  59 SHA-256 checksum of the file (ie the "<sjekksum>.tsr" value mentioned
  60 above).</p>
  61
  62 <p><blockquote><pre>
  63 openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
  64   | curl -s -H "Content-Type: application/timestamp-query" \
  65       --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr
  66 </pre></blockquote></p>
  67
  68 <p>To verify the timestamp, you first need to download the public key
  69 of the trusted timestamp service, for example using this command:</p>
  70
  71 <p><blockquote><pre>
  72 wget -O ca-cert.txt \
  73   https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
  74 </pre></blockquote></p>
  75
  76 <p>Note, the public key should be stored alongside the timestamps in
  77 the archive to make sure it is also available 100 years from now.  It
  78 is probably a good idea to standardise how and were to store such
  79 public keys, to make it easier to find for those trying to verify
  80 documents 100 or 1000 years from now. :)</p>
  81
  82 <p>The verification itself is a simple openssl command:</p>
  83
  84 <p><blockquote><pre>
  85 openssl ts -verify -data $inputfile -in $sha256.tsr \
  86   -CAfile ca-cert.txt -text
  87 </pre></blockquote></p>
  88
  89 <p>Is there any reason this approach would not work?  Is it somehow against
  90 the Noark 5 specification?</p>