Re: Open Timestamps

On Fri, Sep 16, 2016 at 05:40:40AM +0000, Mountie Lee wrote:
> how to handle time accuracy?
> existing timestamping service use atomic clock.
> in your document, seams out-of-scope.

1) Many imestamping applications don't need high accuracy; within a few hours
or days is fine. For example, with PGP and software package signing,
timestamping would be used to show that signatures were created prior to key
rotation/expiration/revocation, and the length of time between the signature
creation and any of those events is likely to be weeks, even years. In that
scenario knowing when data existed down to the second is completely irrelevant.

2) For use-cases where this does matter, you're forced to rely on centralized
trusted timestamping services. I haven't implemented this in OpenTimestamps
yet, but doing so would be quite easy. You'd define a new notary type, e.g. RFC
3161, or some type of Certificate Transparency using scheme, and like any other
notary, use it to timestamp messages. For example, if RFC 3161 timestamping was
added to the public calendar's, they'd return timestamps that looked like the
following:

    append 839037eef449dec6dac322ca97347c45
    sha256
     -> append 6b4023b6edd3a0eeeb09e5d718723b9e
        sha256
        prepend 57d46515
        append eadd66b1688d5574
        verify RFC3161(<trusted timestamping signature>)
     -> append cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788
        sha256
        sha256
        prepend 0be23709859913babd4460bbddf8ed213e7c8773a4b1face30f8acfdf093b705
        sha256
        sha256
        verify BitcoinBlockHeaderAttestation(358391)

Basically, we've created a timestamp whose commitment operation graph is:

    <message> -> {path to calendar} -> <calendar commitment> -> {path to rfc3161} -> <rfc3161 attestation>
                                                             -> {path to bitcoin header} -> <bitcoin block header>

Similarly, if the user wants to use a trusted timestamp, but the public
calendars haven't added support, you'd get a timestamp with this graph:

    <message> -> {path to calendar} -> <calendar commitment> -> {path to bitcoin header} -> <bitcoin block header>
              -> <rfc3161 attestation>

Or even multiple RFC3161 attestations if not everyone in the process trusts the
same set of authorities:

    <message> -> <rfc3161 attestation from authority user trusts>
              -> {path to calendar} -> <calendar commitment> -> {path to rfc3161} -> <rfc3161 attestation>
                                                             -> {path to bitcoin header} -> <bitcoin block header>

Secondly, trusted timestamps are a lot more trustworthy if the attestation
signatures are themselves timestamped: just like any other PGP signature, it's
best if we can prove that the signature was created prior to any revocation
event, such as the private keys being stolen. This means that when support is
added you'd end up with a graph looking something like the following:

    <message> -> {path to calendar} -> <calendar commitment> -> {path to bitcoin header} -> <bitcoin block header>
              -> <rfc3161 attestation> -> {path to bitcoin header} -> <bitcoin block header>

There are some implementation decisions about how exactly this should work; I
think ideally the trusted timestamping protocol would itself be aware of
decentralized timestamps, so that decentralized, secondary, proof can be
handled appropriately in the context of the system. You'd also want to think
about how revocation should actually be handled - in a
"best-effort-notification" system like PGP, you probably want revocation
messages to themselves be timestamped, and then define a key as revoked if a
recovation message exists with a valid timestamp, with some maximum time window
in the past. What that would prevent is an attacker who actually does
sucesfully steal a private key from backdating their revocation to invalidate
all signatures. Of course, sometimes you want to do that too! So lots of tricky
design/policy decisions to make here!

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org