adding TOFU/POP to GnuPG

[Daniel Kahn Gillmor]

On 03/14/2014 02:00 PM, Hans-Christoph Steiner wrote:

> My goal in bringing up TOFU/POP is to simplify things, OpenPGP is already way
> over-complicated so adding more fine grained control over new aspects would
> only make things worse for the large majority.  The goal is to make a small
> subset of OpenPGP that is usable by anyone who uses email.  Simplicity also
> makes security analysis a lot easier.

You may not want OpenPGP for this, then.  OpenPGP clients have to cope
with data that they see that covers the whole spec, even if they want to
present a simplified interface for users.

But if you want interoperability with the installed set of OpenPGP
users, as small as that group  may be, this is the standard to use.

> Yes, this would reduce the flexibility but OpenPGP is far too complicated for
> the vast majority of users to understand.  Its taken me years of using it to
> feel I have some grasp, and I still feel lost it in.  So I'm talking about a
> mode that is designed for anyone who can use email.  I am not talking about
> changing the existing, standard OpenPGP model, so those who want all that
> complexity and flexibility can choose that route.

you'll note that the only user-facing parts of my proposal were a single
button added to the MUA, and a possible configurable knob for GnuPG
itself (the decay parameter D, which we can presumably choose a
reasonable default for so users won't see it).

I'm with you on not exposing extra complexity to the users; there is
already too much exposed.

> Key to this idea is that the user would always manually approve all additions
> and changes to keyId+email mappings in their local keyring.  That's the very
> basis of TOFU/POP.  Ideally there would only be one key per email address, but
> workaround should be possible for people who insist on multiples, for the sake
> of compatibility.  But I think the interface should strongly encourage a
> one-to-one mapping of key<-->email.

This also seems quite possible, within the constraints i mentioned
above.  you'd want to modify the decision about when to present the
button to the user, probably.

> In the pure TOFU/POP model, keyservers would only used for updates about
> revokation, expiry, and subkeys.

how does new key discovery work if keyservers are not used in this
context?  what about new User ID discovery on existing keys?

> As for my language, sorry I don't speak proper OpenPGP/IETF speak.  I've tried
> to learn it, but it has so many arcane details that it does not stick in my
> brain.  So I'll stick to standard English and try to make myself understood.

Unfortunately, there is no standard English for some of these concepts,
and in other cases, the standard English refers to multiple things that
we need to distinguish between as implementers.   so it's critical to
use unambiguous terminology if we want to nail down what we're actually
hoping to do.  Please try.

"trust" in the OpenPGP world (and in the X.509 world) is an indication
that the user is willing to rely on certifications made by the key in
question.  "validity" is whether the key and the user ID should go
together.  "this key+UserID is valid" is the same as "we should expect
the person identified by this User ID to use this key".

	--dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140314/58ea6113/attachment.sig>