On Fri, Sep 06, 2013 at 11:39:59PM -0400, Phillip Hallam-Baker wrote: > For purposes of email security it is not about the keys at all. It is the > email addresses that are the real killer. > > I can be very sure that I have the right key for ted.lemon@xxxxxxxxxxx but > is that who I know as Ted Lemon? But if the I-D's that you are reviewing and the protocol suggestions are coming from ted.lemon@xxxxxxxxxxx, does it matter? And if you subsequently then meet a bag of protoplasm at a face-to-face meeting who can speak in great technical detail about his I-D's, and who hands you a business card which says ted.lemon@xxxxxxxxxxx, does it really matter what is on the government-issued I-D? > One value of IETF key signing parties is that we get a better assurance > that we know the email address we are sending to is the address of the Ted > Lemon that participates in IETF than we can possibly get through Web of > Trust where someone may be signing a key in all good faith but for the > wrong person. Exactly. This is basically how we bootstrapped the GPG keyring used for Linux kernel submissions after the kernel.org security breech two years ago. We required everyone to get new GPG keys, thus forcing a key rotation, and we did in-person key verification of people, most of whom we had met at other Linux conferences previously, so we knew who we were dealing with. We did look at each other's government-issued ID's, but honestly, that was much less important than my being able to say, something like, "Why yes, that's James Bottomley, the SCSI maintainer and someone with whom I've worked with for the past decade, on mailing lists and conference calls and at conferences all over the world." For this reason, it's actually better to do mini-key signings (or really, exchange of GPG key fingerprints) at the end of each working group session, rather than trying to do one big key signing one evening. The latter is more time-efficient, but the former is what's actually important, since it will be the working group members who know each other the best. The other thing which is useful for a community to maintain is a centralized keyring of all of the members, backed up on a time stamped WORM drive, where keys only get added to the keyring after it has been signed by a threshold number of trusted core signers. (Initially, for kernel.org there were only four or five us that were core trusted signers, and we were people who knew each other and had been working on the Linux kernel for a long time.) Of course, all of this is not going to solve the problem of someone getting bribed by some state actor to introduce some vulnerability into a codebase, or into some IETF- or NIST- approved standards/protocol document. After all, government ID's don't come with a stamp, "I am an NSA stooge." :-) - Ted