adding TOFU/POP to GnuPG

[Robert J. Hansen]

> 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.

> 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.

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.