On Jul 27, 2005, at 11:14 AM, william(at)elan.net wrote:
On Wed, 27 Jul 2005, Douglas Otis wrote:
>
It seems any weakness in DNS will equally impact a DNS based policy
statement that requests an alternative. There is already S/MIME.
There is also PGP. Both provide end-end security and basicly only
focus
on body of the message (neither S/MIME nor PGP have good ways of
including
header fields). MASS focuses on transit email security which seems to
be different matter and also has requirement (?) to provide security
for email header as well as body.
Is the option to include headers with the message body a sufficient
reason to replicate existing and widely deployed email signature
alternatives? The difference is how trust in the identity is
established. Each differ in relative strength, cost, and suitability.
Clearly MASS field is not same as S/MIME or PGP, but that does not
mean
it can not share some of the authorization mechanisms considering they
are already deployed.
If you want to use S/MIME or openPGP you can. Nothing prevents that
choice. If these alternative mechanisms were suitable for wide
deployment, there would be no need for DKIM. Even with DKIM, these
alternatives still remain available. Adding various trust mechanisms
based upon a DNS policy assertion goes against any goal of wide
deployment, nor does this improve upon trust, beyond that available
from DNS anyway.
The difference between these schemes is purpose and what processing
systems are going to be adding the signatures. How keys are obtained
are functionlity. PGP/MIME could be built to have keys obtained from
DNS as well and so could MASS be built to obtain keys from PGP
keyserver
or similar.
Why would this make sense? Should MASS consider developing the
equivalent of RFC3830 MIKEY to negotiate key options? What added
benefit would there be by adding this complexity? How would this
improve the chances of succeeding at achieve wide deployment where
all nodes must support a _common_ mechanism?
Nobody is saying this is to be a requirement. CA certificate serve
mostly as type of accreditation, this does not mean that domain owner
can not publish his own certificate and make it available on his
server
for download.
How is this different or better than using DNS to do the same thing?
To say first read a policy from DNS, and then as an option do
something better? If DNS can not be trusted, how can the policy
that suggests using an alternative?
DKIM is about _wide_ deployment of domain authentication for email
using _DNS_.
That is what DKIM is, that is not necessarily what MASS in general
is about. DKIM is trying to push particular very strict proposal
for standization of mechanism for this entire field with very limited
ability to extend it in the future.
How does adding alternative mechanisms improve anything? If you wish
to use the mechanisms offered by either S/MIME or openPGP, then use
these protocols. Not replicating other protocols does not prevent
future changes to DKIM when needed. Overloading this vehicle before
there are paved roads risks a broken axle.
-Doug