Overall comment: ISTM that a lot of the document is explicit
advocacy for DKIM and in some places it's perhaps more enthusiastic
than necessary.
S 1.2.1:
pass today without some form of strong authentication mechanism.
DKIM provides such a strong authentication mechanism.
I think calling DKIM a "strong authentication mechanism" in view
of the dependence on DNS is probably too uh, strong.
In the difference list, I would add that it's domain only signing.
In the difference list:
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities,
This isn't a property of any previous e-mail signature systems
either. They depend on issued certificates, not issued key
pairs.
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation,
I think this is a bit misleading. DKIM depends partly on DNSSEC
for security, and that is not yet widely deployed.
S 1.2.2
the basis for evaluating whether to trust the message for delivery.
I'm not sure "trust" is a useful word here.
The owner of the domain name being used for a DKIM signature is
declaring that they are accountable for the message. This means that
their reputation is at stake.
I'm not sure I understand what reputation means in this context.
o does not require the use of trusted third parties (e.g.,
certificate authorities) which might impose significant costs or
introduce delays to deployment
See discussion on the mailing list about DNS servers being TTPs.
S 3.3.2, 3.3.3.
Note: these are unfinished..
S 5.2:
While modern messaging infrastructure is considerably friendlier to
the use of digital signatures than in the past even a residual
failure rate of 1% results in unacceptably high support costs when
signatures are used ubiquitously.
While this may well be true, it's asserted without evidence.
S 5.4:
The Kohnfelder architecture was originally designed to allow use of
public key cryptography before the ubiquitous availability of
networking. A particular benefit of the Kohnfelder architecture is
that Alice can send an encrypted message to Bob when the only
transport available is sending floppy disks through the postal
system. Another benefit of the Kohnfelder architecture is that a
signed message supported by a digital certificate is self supporting
and may be verified years after the fact provided only that the CA
signing key does not become compromised.
The principle weakness in PKIs based on the Kohnfelder architecture
is the difficulty of locating the correct digital key in the absence
of a directory infrastructure. This led Brian LaMacchia, then at MIT
to develop the MIT PGP key server, in effect returning to the
original public key directory model proposed by Whitt Diffe and Marty
^^^^^^^^^^^
Whit Diffie
Hellman.
This claim strikes me as rather strange.... Remember that X.509 *was*
intended to work with a directory, indeed The Directory (X.500). So,
while it's certainly true that it's hard to get keys, it's not that
the guys who designed it were somehow too stupid to know about
directory systems.
S 5.5
As previously mentioned PGP and S/MIME were designed in the heyday of
the security end-to-end principle. It has since been realized that
the end points with respect to trust are not the same as the end
points with respect to the communication protocol.
When Alice sends a personal message to Bob it is Alice the person,
not the machine Alice happens to be using that is the true trust end
point. When Alice sends a piece of business correspondence to Bob it
is her employer.
I don't think this is necessarily true. Rather, the issue is that the
application here (e-mail responsibility attestation) is different
from the ordinary e-mail signature issue.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html