Handling a TOFU conflict

[Neal H. Walfield]

Hi,

Currently, when a TOFU conflict is encountered, the --status-fd
transcript looks like the following:

  $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e 
  [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
  [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
  [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
  [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
  The email address "joke.factory at example.com" is associated with 3 keys!
  Please indicate whether this email address should be associated with key
  16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 or whether you think someone is
  impersonating "joke.factory at example.com".
  
  This key's user IDs:
    Joke Factory <joke.factory at example.com> (policy: auto)
  
  Statistics for keys with the email address "joke.factory at example.com":
    1604 5E5F D857 2D7C 44AA  6DCE CC8D 32F3 1C00 5AF3 (this key):
      Encrypted 0 messages.
      Verified 0 messages.
    6F34 3BAD CC2A BE3C 5A2E  295B 2A16 A78F B662 E42F (policy: auto):
      Encrypted 0 messages.
      Verified 0 messages.
    97D6 8CB9 B03F 8137 EB88  4940 EE7C 7DA4 BE04 EB2B (policy: auto):
      Encrypted 0 messages.
      Verified 0 messages.
  
  Normally, an email address is associated with a single key.  However,
  people sometimes generate a new key if their key is too old or they think
  it might be compromised.  Alternatively, a new key may indicate a
  man-in-the-middle attack!  Before accepting this association, you should
  talk to or call the person to make sure this new key is legitimate.
  
  [GNUPG:] GET_LINE tofu.conflict

The MUA has to manually figure out what the conflicting keys are and
gather the statistics.  In addition to the extra work for the
programmer and the minor computational overhead, this introduces a
small race.  Further, it means that the MUA has to know that conflicts
are based on the email address (and not whole user id) as well as any
normalization rules that we use.  Currently, we only lowercase the
email address, but one could imagine adding support for google's
aliases ('.'s don't mean anything) and puny code.


I think that we should change this to print the stats for each
conflicting binding before the tofu.conflict prompt is emitted.  For
this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or
just using the TOFU_STATS line, but extending it to include the
required context (i.e., the fingerprint and the mbox).  Thus, the
--status-fd output could look like this:

  [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
  [GNUPG:] TOFU_USER <fingerprint> <mbox>
  [GNUPG:] TOFU_STATS ...
  [GNUPG:] TOFU_USER <fingerprint2> <mbox>
  [GNUPG:] TOFU_STATS ...
  [GNUPG:] GET_LINE tofu.conflict

I'm confident that this would at least simplify the TOFU integration
in EPG.  Other thoughts?

Thanks!

:) Neal