Re: pgp signing in van

[Phillip Hallam-Baker <[e-mail]>]

On Sat, Sep 7, 2013 at 11:29 AM, Theodore Ts'o <[e-mail]> wrote:

> 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 [e-mail]
> > 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 [e-mail], 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
> [e-mail], does it really matter what is on the
> government-issued I-D?


The difference is the ability to write a validation criteria that is
auditable. People used to get really freaked out about the fact that my
former employer accepted a CostCo membership card for ID purposes entering
the building.

The control here is accountability. If you claim to be Ted Lemon and I just
accept that then it is fairly hard to see a prosecution being viable. If on
the other hand you present a fraudulent ID then you have committed two
separate acts of fraud (one obtaining, second presenting). There are
criminal sanctions possible.




> > 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.
>

Which is exactly the type of community where PGP works well. The problem is
that you can't scale to populations of a billion or more by holding key
signing parties.



> 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."
>

Government issued IDs do have one big advantage and that is they allow new
people to introduce themselves into the group. They also provide a control
against long term undercover agents.

Police don't usually have access to forged documents when they go
undercover. Even intelligence agencies are forced to use them sparingly as
maintaining them is high cost.



> 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.
>

You want me to give up my coffee and biscuits?


> 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.)
>

Oddly enough that is similar to the proposal I have been looking at and Ben
Laurie has. Only instead of hardware we are looking at catenate
certificates (Harber & Stornetta hash chains) now the patent is expired.



> 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."  :-)
>

And some folk may well have been unwitting stooges.

-- 
Website: http://hallambaker.com/