Subject: [saag] Scaling a PGP Key signing

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Feb 2014 11:14:42 -0500

There has been a proposal to hold a PGP key signing in London. Exchanging
keys between thirty or a hundred people seems pretty pointless to me. If
the exercise is going to be worthwhile we should aim to have a system that
could scale to the point where if everyone attending IETF 89 wants to
participate, this is practical.

The objective is that at the end of the meeting we end up with a signed
list mapping names, email addresses and pgp fingerprints. The effort
required of a participant must be constant regardless of the number of
participants. But we will allow an administration effort that scales O(N).

One simplifying assumption that we can make is that an attacker is not
willing to risk exposure to make an attack. So if the process is
transparent and any default can be tracked back to a particular individual,
they are unlikely to attack.

Note that while we are talking about PGP, the real objective here is to
explore what capabilities we could support in PGP+ or S/MIME+. PGP is an
easier sandbox in which to play.

Here is one proposal

1) Appoint Registrars

If we want to tie the validation process to government documents then we
will need people to look at them.

If there are 1000 attendees, then we might have ten registrars, appointing
more during the conference should the need arise.

2) Sign up Web site.

To sign up for the key signing, participants have to generate a pgp keypair
(if they haven't got one already) and submit their purported name,
purported email address and PGP fingerprint to a Web form. [We assume the
pgp key corresponding to the fingerprint is loaded on to some PGP key
server that we can find]

The sign up Web site can verify the email part by sending an email
challenge encrypted under the corresponding public key.

3) At the conference

What we need to do at the conference is to establish the binding between
the fingerprint and the person's name. Here we have a choice of validation
policy. Should we require validation to the IETF name badge? or to
government issued documents?

Validation to an IETF name badge could be done automatically by importing
data from the IETF registration process to see that the registration was
paid and the person showed up.

Otherwise people would have to find one of the registrars while at the
conference, show their government identity documents and the registrar
would have to enter some sort of confirmation that this has happened into
the Web site.

To make this transparent in a CT sense, the confirmation should be signed
so that the action is accountable and auditable.

4) Distribute a signed directory of user names to keys.

Entries could also be used to validate a request for an S/MIME cert, etc...

But if we could pipe information from the registration process then we can
establish that anyone who wanted to create a fraudulent registration would
have to spend a minimum of $650 to do so and show up at the conference to
collect the packet.

If we timestamp the key signing participation we can make the cost of
creating a bogus registration cumulative.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2014 09:37:35 -0500

> If we want to tie the validation process to government documents then we will
    > need people to look at them.

    > If there are 1000 attendees, then we might have ten registrars, appointing more
    > during the conference should the need arise.

I'm personally, not particularly interested in FirstLast name.
I care about email address.  Government documents do not contain that.

    > To sign up for the key signing, participants have to generate a pgp keypair (if
    > they haven't got one already) and submit their purported name, purported email
    > address and PGP fingerprint to a Web form. [We assume the pgp key corresponding
    > to the fingerprint is loaded on to some PGP key server that we can
    > find]

The easiest is to set up a key server that people can push to.
That may actually be easier in many GUIs than copy&paste to a web site.

    > What we need to do at the conference is to establish the binding between the
    > fingerprint and the person's name. Here we have a choice of validation policy.
    > Should we require validation to the IETF name badge? or to government issued
    > documents?

    > Validation to an IETF name badge could be done automatically by importing data
    > from the IETF registration process to see that the registration was paid and
    > the person showed up.

    > conference, show their government identity documents and the registrar would
    > have to enter some sort of confirmation that this has happened into the Web
    > site.

    > To make this transparent in a CT sense, the confirmation should be signed so
    > that the action is accountable and auditable.

If we are going to do all of this, can we get an S/MIME out of it too?
Seriously.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Feb 2014 10:15:36 -0500

> I care about email address.  Government documents do not contain that.

I think we are all on the same page there, although I am not sure we have
got to a precise description of what the page is.

Signing messages to IETF lists has little value as a means of
authenticating the messages as I am not going to check them. But it is
really useful as a means of authenticating the long term continuity of use
of the key.

If people's email client signed their mail using DKIM, even just the
message ID we would get key continuity out of that.

I would like to end up with a directory mapping IETF-er's email addresses
to public keys that authenticate a key I can encrypt a message to them.

So when I discover a security hole in their software, I can tell them about
it without also telling the opposition.

> That may actually be easier in many GUIs than copy&paste to a web site.

If it is supported in the software, fine.

> If we are going to do all of this, can we get an S/MIME out of it too?

I would really like to bind the two systems together. S/MIME solves a bunch
of problems that PGP does not try to solve.

My view is that if we can get one key out to people we can add in an S/MIME
capability. At minimum we just run up a CA that sends an email challenge
that people have to sign with their PGP key. If we want to bind the model
further, the certificate could embed or link to a proof that the
certificate request confirmation was signed with the PGP key matching the
fingerprint.

But PGP does solve one major problem that S/MIME does not understand exists
which is continuity of the key-set over long periods. The way I see it
(following discussions on the crypto list with many others) is that people
should have multiple keys but the software should make this invisible to
them. So in PPE I establish (or will when the infrastructure is done) the
following keys:

1) A master key: This does not have an expiry period but there is a
mechanism to declare it inactive on the death of the holder. This key
requires extensive safeguards to avoid loss. It is only used to sign
subordinate keys.

2) A current encryption key: Since users want to be able to read their
messages on multiple machines, the decryption key must be accessible on all
the machines that need to decrypt the messages and some sort of key
transport scheme is required. The key is changed regularly. Users may have
multiple keys for different purposes.

3) A current authentication key per device: Signature keys should only be
on one device so that compromise can be mitigated if a device is lost.

A fingerprint of a master key is something that can and should be permanent
for decades. That allows for things like etching the key onto phones and
laptops as a QR code to allow for recovery if the item is lost or stolen.

This is an approach that sophisticated PGP users can opt for. But it isn't
made default and the PGP infrastructure is not primed to make use of it.
Making it a requirement solves a lot of usability issues. Basically instead
of letting the user get themselves into a mess that is impossible to fix if
they mess up (lose a device, key, whatever) we make it so that it is very
hard to screw up and if they do the consequences can be mitigated in a
straightforward manner.

Outside of the IETF/Linux Plumbers type community the expertise needed to
run a key ceremony and get it right is not common and certainly not cheap.
The only way that the prices can be brought down to an acceptable level for
medical and legal conferences is to make running the ceremonies a
commodity. Which means that we need to have some sort of franchising model
that can train a notary public to run a ceremony and provide some degree of
assurance that they are doing it in a proper way.