Hi Hannes, >Hi Paul, > >I am now guess what you are trying to say here. So, apologies for >misinterpreting your suggestion.
No apologies required .. You should always ignore what I type and only pay attention to what I mean :-) > >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 *. S/MIME and PGP have specific public key trust models that have > >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? Yes - we should start from scratch (versus direct augmentation of S/MIME/PKI or PGP). In a key centric model, the recipient would be identified by a cryptographic identifier. P2P authentication would be based on the identifier and the friendly human readable email address would be secondary or even unbound. Decentralized transitive binding of email addresses to a identifier should be possible, but not mandated (e.g. signed bindings/certificates of id to Email address). This would be Œforest¹ versus Œsingle tree¹ model for name/attribute binding. Where there was no visible explicit binding, some level of anonymity and traffic analysis protection could be provided. Public keys and identifiers for public keys (e.g. Hash of key) could be used for more than email. I¹m currently working on layer 2 proposals for P2P authentication with these ideas, but see no reason that the same model should not work quite well for email. Paul > > >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" <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
