Hi Paul, I am now guess what you are trying to say here. So, apologies for misinterpreting your suggestion.
Some on this list are trying to do the following: they take the existing email infrastructure as a starting point and brainstorm about how to add end-to-end security to it. Of course, there are solutions available already (namely S/MIME and PGP) but both are not widely deployed for a variety of reasons *. Another approach, however, is to start from scratch and to define an entirely new email system, which uses cryptographic addresses instead of human-readable identifiers. I guess that's the approach you are suggesting. Is this correct? Ciao Hannes PS: It would be great if someone could point me to a good write-up about the reasons why these two solutions are not widely deployed. I know about a number of "not-so-useful" write-ups... On 12/30/2013 06:26 PM, Paul Lambert wrote: > Why do we even need DNS and names for email encryption? > > The path/address to reach a peer should be independent > of the cryptographic identity used for peer-to-peer > authentication/encryption. > > IMHO we should be looking a key centric approaches that loosely > bind one or more sets of names/email addresses to public key identifiers. > > Paul > > > > On 12/29/13, 11:38 AM, "Watson Ladd" <watsonbl...@gmail.com> wrote: > >> One obvious solution for end-to-end email encryption is to use >> ID-based cryptography: a new record type would be defined in the DNS >> containing the system key for an ID-based system, and the username >> (everything before the '@') would be the identity used. This would not >> obscure addresses or the fact of communication right now, but would >> prevent interception at intermediate nodes. It would be webmail >> compatible. >> >> Are there any issues beyond the merely cryptographic that I need to >> consider here? Can this be shoehorned into S/MIME, or do we need to do >> something new? In the next few days I will try to make a >> draft/implementation for this. >> >> Sincerely, >> Watson Ladd >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
