[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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