adding TOFU/POP to GnuPG

[Daniel Kahn Gillmor]

On 03/14/2014 01:26 PM, Robert J. Hansen wrote:
> 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 does not limit itself to the RFCs, particularly when it comes to
its role as a keyring/contact manager for OpenPGP.  the OpenPGP RFC
(4880) does not make any statements about how the network of identity
certifications should actually be evaluated other than implying that
some sort of validity calculation should be done by the implementation.
  RFC 4880 mentions a description of "trust signatures" (public
indications of ownertrust, which most people don't use) and "trust
packets" (private records about which certifiers the user is willing to
rely on, which are by definition implementation-specific) and has a
vague one-off reference to "validity calculations" in the revocation
section -- that's it.

But the feature of deciding which keys do actually belong to which users
("validity calculations") is a critical task performed by gpg, and
implementations like enigmail and other MUAs rely on GnuPG to perform
this task correctly.

Implementing TOFU/POP in enigmail itself instead of pushing the
information into GnuPG would mean that other users of GnuPG (who already
rely on GnuPG for existing validity calculations) wouldn't get the
benefit of the decisions the user already made in enigmail.  That would
be a mistake.

If GnuPG wasn't already in the business of doing these validity
calculations, there might be more merit in Robert's argument, but in
practice, this is one of the core features of the tool.  So any
consideration about extending or modifying user ID validity calculations
is *definitely* in-scope for GnuPG.

	--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/6b995fa4/attachment.sig>