makew0rld
commented
4 months ago Thinking about this more, if we sign a root hash or whatever along with the attestation data, all that can be proved is that the signature was created after a certain time, not that the data itself was. It would always be possible to create the data/value of the attestation years in advance, then only add in the latest block hash (or something) at signing time.
This is different than OTS. This means the utility of this feature is pretty limited. When is it useful to prove that the signing operation alone didn't happen earlier than some time?
petertodd
Currently we use OpenTimestamps to prove that a signature (and the data within) was created before a certain date. This is very useful to us to prove that tampering has not happened after the fact.
If we were to add information that proved that the attestation was created after a certain date, that would be only somewhat useful to us, but combined with the above we get a small "time window", allowing the
timestampfield to be provable in both directions within a good interval.This is not a necessity but is still a nice authentication property to have and maybe could be useful in situations some users who are not us may have, like <...>
There are a couple ways of achieving this, all by storing some extra information with each attestation:
Something to note is that even the blockchain solution will still rely on third-parties due to usage of an API. I like the NIST option because it detaches us from any coin, but admittedly it requires that NIST still run the service at time of verification OR that someone has archived the NIST chain.
There is also the question of whether this value should be part of the signature or not.
cc @benhylau