Den 11 feb 2015 07:37 skrev "Trevor Perrin" <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>>: > > On Mon, Feb 9, 2015 at 5:13 PM, elijah <<a href="mailto:elijah@riseup.net">elijah@riseup.net</a>> wrote: > > > > (3) We need common practices for "verified key transitions". > > Do you mean this: > - When you replace your long-term key, the old key signs the new (and > maybe vice versa)? > - When someone presents their new key with correct signatures, you > silently replace the old one in your local trust store (no key change > warning) > > I wonder how useful that is. Consider the reasons for key replacement: > > 1) You lost your old key > 2) You're proactively replacing your old key > 3) Your old key was compromised > > This doesn't help (1). > > It avoids the warning in (2), but adds complexity - a public key no > longer matches one fingerprint, now it can be verified by any > fingerprint that chains to it. So your protocols have to deal with > these chains, and users will encounter situations where they had one > fingerprint for Alice before talking to her, and a different one > after. > > (3) arguably becomes worse, because someone who steals your private > key can silently replace the public key your correspondents have for > you, just by messaging them. > > I'm not sure this is a net positive. What I want is identity declarations like more advanced PGP keys. They would be static (append-only mechanism for updates), identified by the hash. And the main difference is that they would have room for new ways fields like key succession policies (requiring a chosen third party to agree?), revocation policy (if 3 of 5 of entities out of the group XYZ signs the revocation, it is valid even without a signature from my own key - allows you to show up in person with an ID card to get your key revoked if you lose your computer and all backups of the key), messaging policy (always sign mail to me, encrypt with PFS if sensitive; I always sign mails I send), updates must follow rules ABC (this can also even ban certain future configurations, you can say "I will NEVER send unsigned email), updates are available via sources 1, 2 and 3 (append-only, signed and using hash chains like git and Bitcoin blocks do), etc... But you won't need to store the full multi-megabyte raw blob of all data, as all the fields could be separately hashed in a Merkle tree hash (or patricia tree? Supposedly you can prove if entries are lacking or not with them, IIRC), and a regular hash of that tree hash would be the identifier. Not sure if a signature always should be appended or not, thoughts? Should it still be self-signed if the hash is how you always identify it? Maybe it is sufficient with having one of the entries in the tree hash be a signature of the other entries that are considered mandatory to include. Or you have two levels of tree hashes, one which is signed and which is based on the raw data as well as another tree hash that includes all the raw data plus the previous tree hash plus the signature. But that doesn't seem strictly necessary for avoiding tampering if you're always careful with verifying the hash. With an interconnected network that propagate all public identity declaration hashes (like a mix of PGP keyservers and DHT) and that tracks who to ask to get the details for each key, lookups using the hash could be fast and reliable as long as you have an Internet connection. A scheme like certificate transparency or a blockchain like Namecoin could be used to make sure there's no conflicting sets of appended entries or changes that has been published, as well as for key lookups.