On Tue, Aug 19, 2014 at 8:45 AM, Ximin Luo <[email protected]> wrote:
> These are not specified in great detail, partly because there are so many > ways of doing it, but it is an important part of the system. Often we don't > even have an agreed precise *definition* of what it means for the key to be > valid. We only have rough definitions, and we try to design auditing and > monitoring around this; this is brittle and so we should decide on more > precise definitions. I think there are two philosophies on what constitutes a valid key certification: (1) You can verify real life identities, or (2) you can verify email addresses. The first strategy has been the dominant one culturally for OpenPGP since the 90s, and often involves going to something called a key signing party (not actually a party and not to be confused with a key party!) with your passport and key fingerprint and wandering around the room looking at other people's documents and collecting their fingerprints. I've heard that people have come up with new schemes to optimize this process so you only have to sit in a chair and listen to somebody recite hex digits half an hour. As a reward for participation in this ritual you are now connected into something called the 'web of trust' which makes information available allowing other users to derive metrics on the trustworthiness of your key with vaguely documented graph path calculations deep inside GnuPG. I'm not sure anybody understands precisely how this even works with the possible exception of Werner Koch, dkg, and a few people writing academic papers. I understand the appeal of putting the emphasis on real life identity, since if you're confident that you have the right public key for a certain other human then it doesn't really matter where you send encrypted messages to since the worst that can happen is you send it to the wrong place but the recipient is unable to read it. Problems emerge however when you have only an email address from which you want to bootstrap secure communication because your email client doesn't care much about legal names printed on passports and even though everybody includes email addresses in their public key UIDs, no due diligence was performed on email addresses at the key signing party so it might not be such a good idea to just let your email client automagically ask the web of trust for advice about email <--> public key mappings. (Yes, I know that after the key party you could hypothetically encrypt some thing or receive some other signed thing, but whatever ad hoc verification isn't what actually happened after the key party) Now users expect that in order to send email to somebody they haven't previously corresponded with they are only going to need an email address. I think this is a reasonable expectation, especially since our counter-offer is "Ok, how about an email address AND... 32 random hexadecimal digits". So I'm arguing from a usability perspective that in order to build better tools so that Johnny can finally encrypt and get on with his life, the important definition of key validity needs to be (only) about authenticating the relationship between a public key and an email address. If you accept this assumption, then that quickly narrows down the options available in order to accomplish this task and makes it easier to reason about how strong the security guarantees are of a system that proposes to deliver 'valid' keys to users. --brl _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
