> [mailto:[EMAIL PROTECTED] On Behalf Of Keith Moore
> Now maybe we could get businesses to sign their messages with > S/MIME or > OpenPGP and solve the phishing problem that way, but somehow I don't > think they'll go for it. And for any of this to work we need > widespread > buyin. If the market hasn't bought into S/MIME or OpenPGP by now I > don't think they're going to do so. While I agree with the sentiment it is worth pointing out here that these were not really designed for elderly grandmothers to use to secure their email. The specs work fine for the markets they were intended to serve, the problem is that they do not serve the billion user Internet well. I think we can make use of much of the work done on them, in particular the work done on building out PKI and the ubiquitous support for S/MIME encryption. But I don't think that the charter for DKIM should have a 'no poaching' clause to prohibit uses that might conflict with PGP or S/MIME. I agree with Keith than the mindshare war was a disaster for all concerned, in my book I state: The division between S/MIME and PGP has ideological and commercial roots that appeared to make sense at the time but have resulted in a stalemate in which every party has failed to achieve its objective. RSA failed to create a market for email certificates, the PGP proponents failed to make use of cryptography ubiquitous and Louis Freeh failed to stop criminals getting access to encryption technology. I see no need to re-fight that war. If we end up in a situation where email clients effectively have to support S/MIME and PGP and DKIM I don't think that is a bad situation. The only bad outcome is if nobody uses any of it. I expect that in the future CAs are going to have to publish key information through both the DNS (for DKIM) and also via a PKI for persistent key lookup, end-user keying etc. I also expect that the issue of how to configure an email client to work with all of this will need something of a profile, this is not something I think should be done here in this group and since it will probably need a user interface component should probably not be here in the IETF. _______________________________________________ ietf-dkim mailing list http://dkim.org
