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(_dot_)lemon(_at_)nominum(_dot_)com 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(_dot_)lemon(_at_)nominum(_dot_)com, 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(_dot_)lemon(_at_)nominum(_dot_)com, 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