Subject: [saag] Mapping from email addresses to crypto parameters

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jul 2014 16:24:09 -0400

One of the issues raised in the plenary was how to go from an email
address to a validated public key for encrypting email to that
address. WebFinger was proposed as a solution, PPE uses a slightly
different solution. This is because there is more than one problem
here.

lets start with terms, we actually have four types of data

1) The email address (e.g. [email-masked])

2) A public key for encryption for that address (there is likely to be
more than one to address spam issues, confidentiality levels, etc.)

3) Information to establish a root of trust (e.g. a root cert or
phingerprint of a root cert, for Alice this is
D6TK2-NDKN2W-JRME7DA-RXYYHZ-T4A)

4) (Optionally) A chain of certificates/assertions/etc to establish
the validity of (2) with respect to (3).

Depending on the precise trust model we have different ways of moving
these types of data around. In the WebPKI we have a limited number of
(3) and push them out to every browser and so all we need to send in
band is (2) and (4).

In PPE I avoid the problem of discovering (2) by binding it into the
email address to create a 'strong email address':

D6TK2-NDKN2W-JRME7DA-RXYYHZ-T4A?[email-masked]

So in PPE we know the root of trust but not the public encryption key
or the validation chain. One of the main differences between PGP and
PPE is that in PGP the fingerprint is of the encryption key itself and
in PPE that is only the case in PGP legacy mode. Checking cert chains
in 1992 was a serious performance drag, today it is not.

So in PPE the most convenient lookup mechanism to use that does not
introduce a trusted party is to extract a domain from the email
address and throw a .well-known query at it to pull the encryption
chain and validation data. All the data is validated to the
phingerprint so the Web Server is not 'trusted' except as regards
service.

As it turns out, this does not quite work for the general case since
gmail.com does not host a phinger for Alice. So what we do instead is
to put the data on orac.hallambaker.com and substitute that into the
email address:

D6TK2-NDKN2W-JRME7DA-RXYYHZ-T4A?[email-masked]

It would of course be better if we could avoid this and have both
domains. But that turns out to start to exceed hard limits in various
contacts and address book apps.

The problem with involving Webfinger here is that only the strong
email address is static. The encryption key will change on a monthly
basis and so will the validation data. So I would not really want to
have to edit my webfinger data each time there is an update. The only
way it can work then is if either the webfinger service provider is
pulling the key data on each update and updating its record or if the
webfinger service is supplied by a keybroker type service.

Adding the phingerprint to the webfinger data makes perfect sense of
course. If I am attempting to send a message to
[email-masked] it makes perfect sense to add the
phingerprint into that record so that it can be used as a trust chain
locator but I really can't use it as strong root of trust for a
validation model.

This is where we get out of the 'key discovery' problem which is
finishing our main course and start eating desert.