On Jul 25, 2005, at 2:15 PM, Earl Hood wrote:
At the data level, S/MIME and DKIM (or similiar-type proposals)
are different. For example, S/MIME does not deal with arbitrary
header fields, only the MIME Content- ones to protect the integrity
of the body. I.e. S/MIME deals with the body part while DKIM and
others try to deal with the message as a whole (or in select
parts).
From a usage model perspective, S/MIME implies, "I have some
data I want to sign/encrypt using email as my transport." While
DKIM and others imply, "I have an email message that I want
to sign to verify the sender and content." See the difference?
One is at the MIME entity level while the other is at the
message level.
The major difference I see is that S/MIME 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. The 'From' and 'Subject' can be repeated within
the message body if desired. While S/MIME attempts to minimize
headers dependence, with a greater focus upon the message body
itself, there is not a great difference between these two schemes
with respect to what is protected. The great difference is how keys
are obtained. I would not conclude any great benefit derived by
including often problematic visible headers, which remain optional
for DKIM.
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
exchange of these certificates. This results in a technology harder
to deploy where end-users do not appreciate this added security
compared to the cost. If there is a desire, I think there must be
some better reasons given why S/MIME does not address this need.
As for "wide use of an authentication scheme suitable for the exchange
of email." as DKIM is currently defined, I do not think it can achieve
that goal (and I have raised my concerns in past emails and looking
forward to the next draft revision, including the next revision
of SSP).
I too have concerns, but feel these can be addressed.
-Doug