Time services can help with these sorts of things. They aren’t notarizing the message. You don’t trust the service to validate who wrote it or who sent it, you just trust that it saw these bytes at this time.
Something that maintains a mapping between a signature+domain and the earliest seen timestamp for that combination? I think at that point the time service becomes a viable aggregated index for readers who use to look for updates. I think this also solves the problem for lowering the cost of participation… since the index would only store a small amount of data per-post, and since indexes can be composed by the reader, it could scale cost effectively.
I’ve only briefly worked with these but got a rundown from someone more broadly experienced with them. Essentially you treat trust as a checklist. I accept this message (and any subsequent transactions implied by its existence) if it comes from the right person, was emitted during the right time frame (whether I saw it during a separate time frame), and <insert other criteria here>. If I miss the message due to transmission errors or partitioning, I can still honor it later even though it now changes the consequences of some later message I can now determine to have arrived out of order.
I wonder if another way to think about this is as an authenticated vector clock. I think a merkle tree approach is probably too heavy weight as it’s not necessary to keep that information around. You kind of just need quorum (defined as appropriate to mitigate abuse) to update your local version of the vector clock, but unlike a merkle tree, you only need partial updates based on the subset of posters you care about and you basically only need to keep around the last few versions of each vector component.
I don’t recall if any of the signatures sign across any other signatures. I think in some cases it’s just a… Merkle List?
Merkle trees get weird if they’re done as signatures. With bitcoin everyone votes on the validity in a fairly narrow timeframe and the implausibility of spoofing a record and then spoofing the next n is what allows for the trust-in-the-blind to be practical (even if I don’t agree that the theory is sound).
For signatures, on data at rest, it gets complicated. Because at some point you’re trusting a payload that has signatures from expired certificates. You end up having/needing transitive trust, because the two signatures you care about are valid, and they signed the payload while the signatures they cared about were still valid. So now you need to look at signature timestamps, Cert validity range, Cert chain validity range, CRLs or OCSP, and you better make sure all your timestamps are in UTC…
It’s easier if the system has a maximum deliver-by date, and you just drop anything that shows up too out of band. I can use a piece of software that was created and signed over a year ago, but maybe I shouldn’t accept year-old messages.
I did a code signing system for avionics software, that supported chain of custody via countersigning (Merkle before anyone heard of bitcoin). The people who needed to understand it did but it broke some brains. I lost count of how many meetings we had where we had to explain the soundness of the transitivity. People were nervous, and frankly there weren’t enough people watching the watchers. Sometimes you only catch your own mistakes when teaching.
Comments
Time services can help with these sorts of things. They aren’t notarizing the message. You don’t trust the service to validate who wrote it or who sent it, you just trust that it saw these bytes at this time.
Something that maintains a mapping between a signature+domain and the earliest seen timestamp for that combination? I think at that point the time service becomes a viable aggregated index for readers who use to look for updates. I think this also solves the problem for lowering the cost of participation… since the index would only store a small amount of data per-post, and since indexes can be composed by the reader, it could scale cost effectively.
I’ve only briefly worked with these but got a rundown from someone more broadly experienced with them. Essentially you treat trust as a checklist. I accept this message (and any subsequent transactions implied by its existence) if it comes from the right person, was emitted during the right time frame (whether I saw it during a separate time frame), and <insert other criteria here>. If I miss the message due to transmission errors or partitioning, I can still honor it later even though it now changes the consequences of some later message I can now determine to have arrived out of order.
I wonder if another way to think about this is as an authenticated vector clock. I think a merkle tree approach is probably too heavy weight as it’s not necessary to keep that information around. You kind of just need quorum (defined as appropriate to mitigate abuse) to update your local version of the vector clock, but unlike a merkle tree, you only need partial updates based on the subset of posters you care about and you basically only need to keep around the last few versions of each vector component.
I don’t recall if any of the signatures sign across any other signatures. I think in some cases it’s just a… Merkle List?
Merkle trees get weird if they’re done as signatures. With bitcoin everyone votes on the validity in a fairly narrow timeframe and the implausibility of spoofing a record and then spoofing the next n is what allows for the trust-in-the-blind to be practical (even if I don’t agree that the theory is sound).
For signatures, on data at rest, it gets complicated. Because at some point you’re trusting a payload that has signatures from expired certificates. You end up having/needing transitive trust, because the two signatures you care about are valid, and they signed the payload while the signatures they cared about were still valid. So now you need to look at signature timestamps, Cert validity range, Cert chain validity range, CRLs or OCSP, and you better make sure all your timestamps are in UTC…
It’s easier if the system has a maximum deliver-by date, and you just drop anything that shows up too out of band. I can use a piece of software that was created and signed over a year ago, but maybe I shouldn’t accept year-old messages.
I did a code signing system for avionics software, that supported chain of custody via countersigning (Merkle before anyone heard of bitcoin). The people who needed to understand it did but it broke some brains. I lost count of how many meetings we had where we had to explain the soundness of the transitivity. People were nervous, and frankly there weren’t enough people watching the watchers. Sometimes you only catch your own mistakes when teaching.
that's too much tech for a trust problem it can't solve. just use a TimeStamp Authority like https://freetsa.org/index_en.php or https://knowledge.digicert.com/general-information/rfc3161-c...
Thanks for sharing! That RFC led me to this one, which helps fill in some of the other implementation details: https://datatracker.ietf.org/doc/html/rfc4998