On Wed, Feb 5, 2014 at 11:59 AM, Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:
This document should be of obvious interest to anyone on this mailing
list. Please review it and send comments here to the list for discussion.
+1
One toplevel comment is that the only real challenge here is working around
the constraints of the legacy installed base. That is part of what makes
S/MIME so attractive. It is also what shots you in the foot.
this is one of those cases where pushing for a big change or several
changes at once might actually be easier than a small one. The difficulty
of the deployment problem comes from the diversity and ambiguities of the
deployed base.
Getting signature to work right when the mail is received by an application
or service that does the right thing is easy. The problem comes when the
receiver does not understand what the right thing is.
Working domain to domain is a good idea. We have infrastructures that work
very well making domain level assertions. So lets imagine that Bank of
Ethel, a major money center bank with $100 billion under management decides
to send all their mail signed with S/MIME. That can't work today because if
even 0.01% of that mail is received by faulty mail clients that give a
terrible user experience, that is several million dollars worth of customer
support calls.
Now lets imagine that we work at the domain level. We have two
infrastructures available:
DNS allows us to make domain level statements about the Internet
infrastructure, DNSSEC allows us to authenticate those statements.
WebPKI allows us to make statements about the accountability of
organizations and tie them to domains.
Ideally I would want to use EV certificates with logotype data embedded to
show the logo of the organization sending mail. DNS does not really help us
very much when making statements about the sender of a message because the
mail protocols don't really require the sender to have a DNS domain at all.
On the receiver side, the DNS is the maypole around which the mail
protocols dance. This is not an accident, email is the killer application
that made the DNS necessary in the first place.
Lets imagine that we have a statement from the MDA (i.e. receiver) that
says 'please send all mail to me with group S/MIME signatures and/or
encryption, I will make sure that all the necessary transformations get
done to ensure that the receiving MUA gets the message in a form that it
can understand.' The logical place to make that statement is actually an
SMTP extension. But we would ideally want to authenticate that statement
under STARTTLS and then tie the STATTLS credentials back to the DNS domain
with something like DANE or WebPKI or both.
I won't go into it here, but a lot of my objections to DNSSEC under the
ICANN hierarchy, the fact that many registrars are crooks etc. etc. are
answered if we tie DNSSEC authentication inside a domain to a certificate
that is published in a Certificate Transparency log.
That one statement allows us to unlock the deployment deadlock that makes
progress in the S/MIME world so difficult. The changes that we then need on
the protocol side are a few flags in the IMAP and SMTP services. The
workings of these flags is essentially no different to the
internationalization flags that already exist and Paul H. can probably tell
us how these work.
--
Website: http://hallambaker.com/
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime