On Wed, 27 Jul 2005, Douglas Otis wrote:
How does the signer know who the verifier(s) will ultimately be?
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.
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 alredy deployed.
There are minor
differences where signatures appear as an attachment, rather than hidden
within headers. The identities' email address within the certificate can be
compared against the header's mailbox addresses. S/MIME minimizes header
dependence where the 'From' and 'Subject' information may be repeated within
the message body.
Not really, it require repeating entire message header (i.e. entire data is
put in Message/RFC2822 entity and that is in itself signed) and that put
back into the message.
I would not conclude great benefit signing visible
headers, which remain optional for DKIM. In either case, a decision to
reject the message will likely be based upon the domain of the validated
In case of S/MIME or PGP the decision would be based on email address of
the sender (but can be domain for S/MIME as well I think). Its all pretty
damn close to what MASS works on.
The great difference between S/MIME and DKIM is how keys are
obtained. Why replicate S/MIME which is already widely deployed?
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
To use a CA of any sort, the sender needs to obtain a certificate from
a CA trusted by the recipient's email handling application. This
process involves both initial and ongoing costs to establish the
exchanges of these certificates.
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
This results in a technology harder to deploy with greater
overhead, where end-users also do not appreciate higher costs for the
improvement in security.
We have quite a bit of experience with deployment of S/MIME and PGP,
with creation of X.509 certificates (many tools to do it), so in fact
new system would benefit from interaction with existing base rather then
the other way around.
DKIM is about _wide_ deployment of domain authentication for email
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.