Email-only UIDs and verification (was: Making the case for smart cards for the average user)

[Jose Castillo]

On Mar 20, 2015, at 2:47 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> If the followup is just "click this link" then i agree it's probably
> encouraging bad habits.  What if the suggested followup was an e-mail
> reply?  What if we require the verifier to sign its outbound messages,
> and tell users "don't do this unless the message is signed by the
> verifier”?

I think MFPA had a good idea earlier in the thread: the first message, the request for a signature on the UID, is signed; whether the from address is spoofed or not, the automated service can’t be sure. What if the automated service went ahead and made the certification anyway, but encrypted it before sending it? At that point only the recipient in the UID field will receive the email, and they’ll only have access to the certification if they’re also in control of the key to decrypt it. There’s no followup required. 

> I'm still not sure how useful this is in the big picture -- is such a
> verifier only for first-contact, or is it supposed to be useful
> longer-term as well?

The thought process here is that when someone generates their identity, it’s not trusted by anyone, and they don’t trust anyone by default. It’s up to them to build the trust landscape themselves, which isn’t a great user experience for the layperson. This proposal is about establishing a minimal viable trust scheme based around persona-level certification of verified email addresses. The user can augment that with their own web of trust as needed. 

Ideally, I’d like to be able to present UI that shows a signature from an untrusted key as an error condition, in much the same way your browser warns you about an untrusted SSL certificate. That’s difficult if you have to establish yourself in a web of trust first. 

-- 

Joey Castillo
www.joeycastillo.com