Hi Eric,
I would generally agree with you about the enthusiasm of the document.
This is probably a good place for it, so long as it's accurate. I would
quibble with you on one point:
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.
I believe the point Dave is trying to make is that you don't need to
deploy a huge infrastructure to deploy DKIM. DKIM does NOT require
DNSSEC. Deploying DNSSEC improves the security of DKIM in the face of
DNS attacks.
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 intent is to state that if you know who you're dealing with you can
decide how best to dispose of the message.
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.
I believe it would be pedantic to define a commonly used English word.
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.
I agree. If you're going to cite statistics provide the cite.
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.
I read Dave's claim is to the contrary. They presumed a directory
infrastructure that in fact has proven difficult to widely deploy to the
level of the individual.
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.
I agree that this assertion is poorly worded, to say the least. For
one, I believe it has always been the case the the binding between
protocol end points and "trust end points" has been a matter of debate.
I would suggest sticking with the idea that we are attempting to make a
weaker assertion - that the message originated from a particular domain
and that its contents have not been tampered with since departing that
domain, and nothing more at this point.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html