On 02/10/2015 10:36 PM, Trevor Perrin wrote: > On Mon, Feb 9, 2015 at 5:13 PM, elijah <[email protected]> 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)
Yes. We asked dkg what it should be called, although he may have intended it to denote only the first part. > 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. I think we have established that keys will change, regardless of our desires. Any "automatic" key manager will need to deal with changing keys anyway. Am I missing something? One complexity is that the new key, when using OpenPGP, might have many uids. In this case, any uids not in the intersection of the uids in the old key and the uids in the new key would need to be stripped from the new key before accepting it. > (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. We added verified key transitions to https://pad.riseup.net/p/key-validation for two specific reasons: (a) For sensitive situations, it should always be recommended practice to perform manual verification of keys via fingerprint or SAS. Once you have done this, however, it does not make sense to ever accept a new public key for that uid without a verified key transition or a new fingerprint check. To do otherwise would be to defeat the benefit of checking fingerprints. In our terminology, manual fingerprint verification is the highest level of validation, and new keys much match this level of validation or include a verified key transition. (b) None of the OpenPGP keys in existence currently use any system of automatic key validation. If you want to send mail to them, an automatic key manager will need to perform some sort of TOFU (via keyservers, attached public key, message signature, or header, etc). Once this happens, the key manager will still need to regularly search for updates for that key or for that email address. If the key manager does detect a new key for a uid there will probably still be no automated key validation support for it. The key manager is then faced with a choice: blindly accept the new key, require a verified key transition, or complain to the user. Blindly accepting is not always bad, such as when you can validate the key via some third party service or protocol, but in the case of a key that has been purely TOFU'ed, and nothing else, blind acceptance of a new key would be disastrous. It is very tempting to say we should prompt the user (in a way, like TLS certificates in the browser, that nudge the user to say "no"), but I worry this could open an annoyance attack vector where an attacker can trigger frequent warnings by polluting keyservers or sending bogus emails to the target. I think asking would be OK if new key comes inline the message and the "from" header is DKIM signed. But yes, automatic "verified key transitions" perhaps make it worse when private keys are stolen. But maybe it is like rain on a car crash. The crash is what really sucks, the rain just adds insult to injury. -elijah _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
