adding TOFU/POP to GnuPG

Robert J. Hansen rjh at sixdemonbag.org
Fri Mar 14 19:31:35 CET 2014


> Do you use SSH?

Yep.

> That is the key verification model I am talking about.

I know.

> But perhaps its not widely documented,
> probably because its so simple it doesn't need to be.

There is nothing in engineering so simple it doesn't need to be  
documented.  If you look at a stretch of railroad track, for instance,  
you'll find each length of track is stamped with an ID number.  This  
ID number corresponds to a specific batch of steel.  If a length of  
track breaks, the manufacturer is notified and in short order every  
length of track everywhere that came out of that batch of steel gets  
inspected for manufacturing defects.

We're talking about a simple piece of steel.  No moving parts.  All it  
has to do is sit there and be tough, and yet we still document and  
track it -- because that's engineering.

Compared to that, SSH key exchange and management is orders of  
magnitude more complicated.  That it isn't documented anywhere even  
after 20 years does not fill me with warm fuzzies.

> OpenPGP is so over-complicated, and seemingly only getting more so.  And that
> is making it less and less relevant.  Who cares about the standards if hardly
> anyone actually uses them?!

This is an argument for abandoning OpenPGP and building something  
better.  It is not an argument for expanding GnuPG's scope.

> The user would be responsible for maintaining which key is assigned  
> to a given...

Users tend to be highly irresponsible.

> email address in their own keyring. The user would always manually  
> approve all additions and changes to keyId+email mappings in their  
> local keyring.

Breaks the keyserver network, sort-of kind-of, as DKG has already said.

> GnuPG has configurable trust models, I think this can be implemented  
> as such a trust model.

GnuPG implements the OpenPGP trust model.  If you can get this  
introduced to the OpenPGP standard then I'll be all for introducing it  
to GnuPG.  Until then, I don't believe it belongs here.  It should go  
into the supporting software ecosystem.




More information about the Gnupg-devel mailing list