Key Rotation about specs HOT 3 CLOSED

Disclaimer: the comments below are from a quick read, i haven't thought it through in detail. I still need to review how TUF works exactly.

• Yeah, this (how to do key derivation / chaining) is an important problem to get right.
• I don't think we will find a one-scheme-fits-all solution, but rather should provide function primitives, like descendsFrom(key, ancestorKey Key) bool (offline) and hasBeenRevoked(key Key) bool (online), and others. In the general case, for arbitrary records on DRS, people will have very different-looking PKIs and we don't necessarily want to force them to adopt a single one method of doing things.
• But yes, it is worth picking one method for ProviderRecords and for IPNSRecords` so that all nodes can implement just one thing.
• the above does time-based revocation, which may not be optimal on most DRS implementations.
• the above would generate tons of keys, one per record, with a multiplicative increase on the amount of data people have to download (and store!) per published data block (now they need to get a record, a key, and the data block). I think this is not a good strategy.
• the above also makes it impossible for peers to relay records offline-- (that is, peer A broadcasts record Ra, peer B receives it. A goes offline. peer B and C establish a connection. peer B tries to send C record Ra. Ra is invalid for C, as C is not receiving Ra from A). record relaying will be a really good way to get efficient and robust record distribution.
• one other thing, we actually shouldn't necessarily require that the root key be used for setting up crypto channels. we should probably be using derived keys there too.
• however, before we create an explosion of derived keys, we need a detailed survey of many more approaches.
• what we should focus on is the abstractions, DRS should have functions to check the validity of keys that can be improved over time

I agree we need to find the right way to do key {storage, derivation, rotation, etc}. But this is a much larger thing than signing records, because it impacts how keys are stored, what keys are stored online vs offline, agents, and so on.

from specs.

• also note that the attack mentioned is on ECDSA, not all signing algorithms. Attacks vary according to the key signing algorithms used, so PKI structures + record validity algorithms will have to vary according to key signing algorithm coices, so DRS needs to be able to (a) offload the final choice to the user (via good interfaces), and (b) ship with sane defaults (e.g. ways to do it with RSA, ECDSA, etc)

from specs.

In any case, really good to get the discussion started. what we should do is gather a bibliography, and multiple other people who can help design the right support for the various schemes.

from specs.