On Sun, Dec 29, 2013 at 5:08 PM, Phillip Hallam-Baker <[email protected]> wrote: > > > > On Sun, Dec 29, 2013 at 2:38 PM, 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. > > > There are several problems with identity based crypto. The main one being > that the technology > > 1) Requires a trusted third party
In this system the trusted third party is already trusted right now: they are the recipients ISP. This system doesn't interfere with spam trapping and advertising, and so is easy to adopt. I'm not trying to replace PGP, just make something we can turn on by default. > 2) The trusted third party has knowledge of every user's private key A user can opt-out by running their own receiving mail server. > 3) There is no way to revoke a private key in the case of key compromise This one is probably the most serious limitation. I think the best way to fix it is to use keys with limited temporal validity periods, say by hashing with the year or month/year as well. Then you wait a month and the old key is expired. Accessing old mail gets a bit tricky here, but clients could store local copies or servers could hand out the needed keys if you are logged in. > > There are of course various proposals to mitigate the last problem but none > that does not completely erase all the benefits of identity based crypto. > > If the relying party is going to check some service to get key status they > might was well check for a certificate. I was thinking sender mail client. Certificates could work, but then we would have to serve them up efficiently, and that's likely to be a bit of a mess, particularly if we don't want to reveal address books. If you could give every Gmail user a Google signed S/MIME certificate, and have Google distribute the list (s/Google/mail provider of choice/) that solves the issue, but adding 64 bytes (or maybe 128 bytes) in a DNS extension is much easier operationally. > > > > -- > Website: http://hallambaker.com/ -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
