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 nob...@nowhere.com, 
then I need to know that this means that's who it came from.  If I mail 
something to nob...@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 

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.  

The cryptography mailing list

Reply via email to