Re: [Endymail] Another view of the problem and what the IETF could do

On the key discovery problem, there are several separate questions:

1) I want to send email to Alice Splunge, what is her email address and what is her trust anchor

2) I know Alice Splunge has email address, alice.splunge@example.com, what is her trust anchor

3) I know Alice's trust anchor and email address, what public key should Bob Cratchet use to send her email?

Some of these questions are easier to answer than others. Which is why I distinguish trust anchor discovery (i.e. discovering the hash of a key that signs a security policy) from key discovery. 

Since spam is a concern, we might well not want to answer question 1, or at least not to just anyone. But we might distribute keys through social networks. So I my might not publish my email address on my Web site (I do actually) but I might put it on my linked in profile complete with my trust anchor.

For in person trust anchor exchange, QR codes are the way to go.

Sent from my iPad

> On Sep 2, 2014, at 4:03 PM, Adam Caudill <adam@adamcaudill.com> wrote:
> 
>> On Sep 1, 2014, at 12:49 PM, Eliot Lear <lear@cisco.com> wrote:
>> 
>>> On 8/27/14, 6:21 PM, Tim Bray wrote:
>>> 
>>> 1. Find a public key for the user that the sender’s prepared to trust.
>>> 
>>> This is a big problem. The PGP Web of Trust has failed, and we’ve all heard the griping about the CA biz.  Joe Hildebrand mentioned POSH & WebFinger and they’re both interesting.  I’m also interested in the notion of a key directory with associated proofs that you don’t have to trust, for example the one from https://keybase.io.  In particular see https://keybase.io/docs/server_security
>>> WORK FOR IETF: Get pro-active on key discovery/trust work? Standardize key search APIs?
>> 
>> If the IETF could solve but this problem such that it scales to the size of the Internet, everything else on your list would I think fall into place.  Unfortunately, key management really wasn't on your list, and that has to be addressed as well.  Also, I suspect that email programs probably need to evolve a bit to cope with all of this.  Case and point: I'm pretty sure I've lot one or two private keys along the way.  And, at least compared to your average Joe, I'm good at this.
> 
> No matter what the path forward is for secure messaging, key discovery (and reasonable key management) will be the cornerstone. If we don’t have solid public key discovery, then I fear we’ll just end up reinventing PGP.  For a system to scale to the same level email as we know it has, there needs to be transparent key discovery so that the average user need not be aware it’s even happening.
> 
> In the design I’ve been working on, it’s the responsibility of the messaging service provider to host a user directory, with signed updates that senders can use to get the proper key for a user (so, example.com would provide the sender with the info they need to send to bob@example.com).
> 
> I really think this needs to be a primary focus, and as Tim pointed out, this is something that makes sense for the IETF to work on. If we can establish a solid solution here, I agree completely with Eliot here, the rest will fall into place - and will open the door to many good options.
> 
> -- 
> Adam Caudill
> adam@adamcaudill.com
> http://adamcaudill.com/
> 
> 
> 
> _______________________________________________
> Endymail mailing list
> Endymail@ietf.org
> https://www.ietf.org/mailman/listinfo/endymail