Split "meta" into two terms? (trust/revocation/child/parent vs claims/index/reduced/in/out)

[tschudin]

Something that bugs me since long is that classic SSB has no revocation mechanism. I thought that one should make it mandatory that the first message of each feed has the hash of the revocation msg, the revocation message itself stored in a safe offline place or securely sharded.

(Hash) information of the revocation msg is meta data about a feed, but here I would argue it should be in the feed itself because otherwise it is not causally credible: I would like to prevent that a compromised key can be used to invalidate a whole feed including its past - instead, only the revocation msg that was generated at genesis time would be the valid one for invalidating everything - later revocation msgs can only prune from where they are put into the feed. Speculation mode on: Such "pinned" revocation msgs (call it "prune point msg") could become useful to handle forks and key compromise events because an attacker not being able to prune into the past and the network keeping the chain with the earliest prune point (an attacker cannot fork the chain at an earlier log index, only pruning and continuing with a new branch is accepted as a consequence of revocating at a prune point). (speculation mode off, and we still need a way to recover from accidental forks, and prevent rewriting the past with prune points ..).

I imagine that the main feed on which all subsequent feeds depend would be "a decent personal CA" and the messages declaring dependent feeds are the certs. A note in light of the fork discussion: I think that the trust anchor (that others will store when "following" the main feed) needs to be the public key and the hash of the genesis message (or the hash alone), otherwise the holder of a compromised key can fork at index position 0. This also applies to dependent feeds (in both directions) as well as referenced feeds of others where only referring to some ID is not sufficient.

What I want to say, for the meta-feed discussion: Is "meta" the good name? To me it looks too broad and unspecific. What about replacing "meta" with two different terms, depending on the use: "child and parent feed" where trust is flowing from the root/main/privateCA feed in a tree-shaped manner and where revocation rules apply, and independent from trust the "index/claim/mapreduced/input/output" feeds which create feed relations that are not necessarily organized in a tree?

[arj03]

I'll leave the two different terms because I'm not entirely convinced by that. I have a feeling it might become more complicated, lets see.

The first point is really interesting. As I see what you are described with revocation messages would be anchor points, meaning instead of just talking about a feeds at any point in time I'm actually talking about the feed that is the sum of all the messages until this point. Coming back to the fork discussion this creates an interesting point for the follow mechanism where because you have more granularity you can also specify the follow relationship to be more general that just "I follow whatever this key does forever". You could even say things like, I follow all the messages up until anchor point X and no further. The anchor points would also be natural places to reduce the state of a certain part of the feed, because they become public reference points for other feeds. Making claims easier to reason about.

I guess the revocation mechanism itself would also be useful, but would need its own topic as it can become rather complicated considering what it would mean for messages that now reference messages that are revoked.

[arj03]

Been thinking some more about the fork handling and revocation. There are a lot of cases to handle, but what I think is fundamental is that we add fork detection to the replication layer so that we can leverage this information higher up in the stack.

[arj03]

Some further points from my bike ride to work:

• I feel that these revocation messages should only be used to terminate an account, no further messages after that point is possible. I think we can handle the fork case in another way and the other case is that the key is compromised in which case it doesn't make sense to try to add anything more to the log. Furthermore with the meta feeds in place, we are in a much better position to rotate logs.
• As always there is the granularity aspect of these messages, how often do you write them.
• These revocation messages can act as tombstones which is a nice bonus feature.
• As for the flow of trust, the keys are independent, this means that if a key of a sub feed was broken, but none feed keys under that was, your could rotate the sub feed and reuse all the feeds under that. I would argue that the claims still have trust in that it is highly relevant what identity posted these claims. In the worst case, a meta feed would be compromised. I would argue that one would very rarely use that key, so it could be stored in a much safer place than the rest of the keys. This comes back to the argument about does a revocation key even add anything if people can't even properly backup their private keys, but then again, I don't think a lowest common denominator should determine the security model.