adding TOFU/POP to GnuPG
Hans-Christoph Steiner
hans at guardianproject.info
Fri Mar 14 18:54:08 CET 2014
On 03/14/2014 01:26 PM, Robert J. Hansen wrote:
>> The term TOFU/POP is not widely used, but that does not mean that the concept
>> is not widely used or deployed.
>
> If the concept is widely used and deployed, then there should be a name by
> which it can be referred to and looked up. If there isn't a commonly-used
> name associated with a concept, that tells me the concept is probably ad hoc
> and in need of codification. That doesn't mean it's a bad idea: it just means
> there's nowhere I can look up to find detailed information. That's what makes
> me cautious more than anything else.
>
>> Yup, that would be one effect of this model, to make it so that signatures on
>> keys don't change the level of trust of keys in the keyring.
>
> Can't support your idea. You're talking about a radical change to the model
> presented in RFC4880, and I think GnuPG should stick close to RFC4880.
>
>> In my experience, most OpenPGP users do not ever sign other keys anyhow, and
>> managing trust settings is even more rare.
>
> My experience is similar, but that's not a reason to make radical changes that
> draw GnuPG away from RFC4880.
Do you use SSH? That is the key verification model I am talking about. I
think you're missing the point if you are calling the SSH model ad hoc and in
need of codification. Its been the same for almost 20 years. Its widely
deployed, used, and understood. But perhaps its not widely documented,
probably because its so simple it doesn't need to be.
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?! Hundreds of millions of people use email, there
are only about 55,000 people in the OpenPGP strong set. That is the sad state
of OpenPGP.
>> One key difference would be assuming one key per email address.
>
> Unfounded assumption: there are *many, many* users who don't follow this
> rule. People forget passphrases and generate new certificates with
> astonishing regularity. People also migrate to new certificates with longer
> primary signing key lengths without invalidating their previous certificates.
> Further, people can generate user IDs with whatever email address they want:
> look at how many user IDs claim to be "president at whitehouse.gov", for instance.
The user would be responsible for maintaining which key is assigned to a given
email address in their own keyring. 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 a workaround should be possible for people who insist on multiples.
> I don't think this is a good idea for GnuPG. I think Daniel is right in that
> there could be a good idea here waiting to be brought out, but I think it
> would be best served as something similar to Enigmail. GnuPG's mission is to
> provide conformant, high-quality implementations of the OpenPGP and S/MIME
> RFCs. Let's not expand that mission to include things unrelated to those RFCs.
GnuPG has configurable trust models, I think this can be implemented as such a
trust model. Then all of the programs (e.g. Enigmail) that use gnupg as its
engine can choose to use it. People who want all the complications of the
full OpenPGP standard can still use that. I'm not talking about changing the
defaults, but just giving another option.
.hc
--
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
More information about the Gnupg-devel
mailing list