[Cryptography] Functional specification for email client?

[John Kelsey]

I think it makes sense to separate out the user-level view of what happens (the first five or six points) from how it's implemented (the last few points, and any other implementation discussions).  In order for security to be usable, the user needs to know what he is being promised by the security mechanisms--not which digital signature scheme is being used or whether decoy messages are sent to frustrate traffic analysis.  

If something arrives in my inbox with a from address of nobody at nowhere.com, then I need to know that this means that's who it came from.  If I mail something to nobody at nowhere.com, then I need to know that only the owner of that address will be able to read it.  I need to know that nobody should be able to know with whom I'm communicating.  But I don't need to know about keys, digital signatures, mix nets, etc.  That's what I want to know as a cryptographer, but as a user, I just want to know what the security system is promising and how reliable its promises are. 

My intuition is that binding the security promises to email addresses instead of identities is the right way to proceed.  I think this is something most people can understand, and more importantly it's something we can do with existing technology and no One True Name Authority In The Sky handing out certs.  

One side issue here is that this system's email address space needs to somehow coexist with the big wide internet's address space.  It will really suck if someone else can get my gmail address n the secure system, but it will also be confusing if my inbox has a random assortment of secure and insecure emails, and I have to do some extra step to know which is which.  

--John