Idea for storing trusted timestamps in Noark 5

[Kent Inge Fagerland Simonsen]

Hi Petter

Although the noark 5 specification sems to be unavailable at the moment, I
dont think that storing trusted timestamps as documenc objects are in the
spirit of Noark 5 (if that is, at all, a thing). The reason is that these
objects are meant to contain variations (i.e. different formats) and
versions of archiived documents.

A timestamp, trusted or not, is more like metadata and, in my oppinion
should be treated as such. The  Noark specification, afaik, allows
implementations to add aditional metadata, so this could be another way to
go here.


Also: Hi everybody, my name is Kent Inge and I hope to help.
-- 
Best regards
Kent Inge


ons. 7. jun. 2017 kl. 21:15 skrev Petter Reinholdtsen <pere at hungry.com>:

>
> I've been wondering a bit about how trusted timestamps could be stored
> in Noark 5.  Trusted timestamps[1] 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.
>
>  [1] <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[2] 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.
>
>  [2] <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 \
>     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?
>
> --
> Happy hacking
> Petter Reinholdtsen
> _______________________________________________
> nikita-noark mailing list
> nikita-noark at nuug.no
> https://lists.nuug.no/mailman/listinfo/nikita-noark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.nuug.no/pipermail/nikita-noark/attachments/20170608/80f12e4f/attachment.htm