On Jul 27, 2005, at 8:53 AM, Michael Thomas 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 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. 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
signature. The great difference between S/MIME and DKIM is how keys
are obtained. Why replicate S/MIME which is already widely deployed?
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. 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. If there is
a desire to develop a scheme that closely mirrors existing IETF work,
there must be some better reasons given why S/MIME does not already
address this particular need, and how S/MIME is prevented by DKIM.
Why force DKIM into offering the _same_ choice. It makes sense _not_
to overlap the work of S/MIME which supports the minor use of author
specific keys. DKIM is about _wide_ deployment of domain
authentication for email using _DNS_.
-Doug