[messaging] Separation of concerns, usability, and partial verification
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed Mar 12 08:50:31 PDT 2014
I agree with the general goal that a contact manager is the right place
to store the sort of information you're describing.
other useful material might be:
* public key pinning information (whether HPKP or TACK or something else)
* version or feature-specific "latches" (as currently being discussed
in UTA) to avoid downgrade attacks
On 03/12/2014 11:28 AM, Ximin Luo wrote:
> For example, often people will sign all the email addresses on a GPG key, without checking if the signee actually owns each address. This is not an obvious thing to do, since everyone is so focused on (OMG) fingerprints.
yeah, this is a usability fail for GnuPG at least, including most GUI
frontends. Up until a few years ago, enigmail was actually reporting
the validity metric of the highest-validated key, while displaying the
user ID that matches the (unverified) From: header of the e-mail. This
was a serious flaw, as allowed mail from anyone who happened to have a
valid key+userid to spoof mail from any other address, as long as they
were willing to add a new User ID to their own key. :/ (i looked for
the reference for this, but can't find it right now -- it's fixed though)
> One bug I noticed for the debian keyserver is that it performs no verification of email updates on submitted keys, so any Debian Developer can claim they own obama at whitehouse.gov, and Debian keyring infrastructure will automatically import this.
all keyservers do this; official debian keyring updates themselves are
handled manually based on material gathered from the keyservers. you're
right that these manual updates should be inspected closely before
shipping as part of the canonical debian keyring. are you aware of any
key that has shipped in the debian keyring with a bogus e-mail address
associated with it?
> A further consequence is that, such an architecture would encourage contact managers to secure (auth-encrypt) ALL contact metadata.
i'm not sure what you mean by this. can you explain more?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1010 bytes
Desc: OpenPGP digital signature
More information about the Messaging