On 12/03/14 15:50, Daniel Kahn Gillmor wrote: > Hi Ximin-- > > 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 [email protected], 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? >
Sure - I meant to emphasize that the debian keyserver additionally then takes this information and puts it into the debian-keyring package, assuming that it is valid (in a way that other keyservers do not), and distributes this to other people with implicit authority. Fortunately, I haven't seen an actual abuse of this. >> 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? > It's a minor point - a keyring should already be auth-encrypting its secrets. If we had an integrated keyring/contacts/verification program, it would be very little effort to extend this protection to other metadata that is often treated more carelessly. Another usability topic is to gamify the verification process - give people rewards for "doing things properly". It sounds gimmicky, but people are quite happy to do lots of even more weird/useless things. :) Some people are even gamifying entropy collection. Like the "sync to other devices" point, it would be much more suitable to do this inside a central system component, since it's quite a separate concern from secure messaging. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
