On Nov 27, 2007, at 11:09 AM, Dave Crocker wrote:
Steve Atkins wrote:
Mechanisms like OpenPGP and S/MIME essentially validate the
authenticity of content. DKIM does not. For example, a DKIM
signature does not contain the semantics that claim that the From
field is correct, nevermind that it does not distinguish between
"brands" such as are often implied by the display string in the
From field, versus the email address in it.
DKIM is a mix of the two (as are pgp and s/mime).
I believe that a basic DKIM signature is not. I believe the
semantics of a signature are stated rather plainly in the -base
specification.
Opening line of the -base Introduction:
"DomainKeys Identified Mail (DKIM) defines a mechanism...
permitting a signing domain to claim responsibility for the
introduction of a message into the mail stream."
A message is identified and defined by it's content. You cannot claim
responsibility for a message with also claiming responsibility for
the content of the message. If the content were to change, it
wouldn't be the same message.
It's setup to not only say "this message came from THIS
recipient", but also "THIS message came from this recipient".
Depends on what one means by "from" since a DKIM signature is not
required to relate to the rfc2822.From string.
Also do not at all understand the second half of your sentence.
Came from this *recipient*???
Sender. Thinko.
"Signer" is better still, of course. It's no different to, say, PGP,
where the signer need not be the same as the sender (but usually will
be).
Rather, DKIM's task is to allow an organization to say this it
has some responsibility for the message; that is, come to them if
there is a problem.
That, to me, is it's *intended* use, sure, but there's no denying
that a validly signed DKIM message asserts that the content has
not been tampered with since it was signed (within some fairly
well-defined limitations).
Yes, it carries semantics about in-transit modification. But it
says nothing about correctness prior to signing.
No more nor less than PGP or S/MIME. All three simply demonstrate
that the content you see is the content that the sender signed.
To: dcrocker
From: epimenides(_at_)crete(_dot_)gr
All Cretans are liars.
If that is validly dkim signed by crete.gr, that doesn't make the
content valid. Nor would it were it PGP signed by epimenides(_at_)crete(_dot_)gr(_dot_)
(If it were dkim signed by blighty.com then crete.gr *could* assert,
via SSP, that the From field is not correct, and perhaps that the
entire message should be treated with some little-S suspicion.)
PGP, S/MIME and DKIM all make the same basic statement: "*this*
sender sent you *this* message and it's not been tampered with
since they signed it". Intended usage may be different, but the
basic function is the same.
Mumble. My impression is that the semantics of these other
signatures is taken to be considerable stronger.
Less fragile operationally, certainly, but no stronger, I don't think.
SSP is primarily about making negative assertions about mail with
a particular from address that is not dkim signed.
That is only one of SSP's features.
OK, it also allows you to make negative assertions about validly dkim
signed messages where the domain name of the From field and the
signer differ. It's still only capable of making negative assertions
about validity ("the content is not valid"), though.
> Given it makes negative
assertions I don't see how it can really be used as part of a "the
content is valid" mechanism other than by discriminating between
"I assert the content is invalid" and "I make no assertion about
the content".
Discussions about SSP seem to conflate From field domain name
correlations with "brand" representation authenticity in the
message. That type of issue is what prompted my sending my note.
SSPs goal is the same as SPFs original goal - to protect the sanctity
of the user-visible From address - but I've not really noticed that
being conflated with "brand", "friendy from" or any of the other user
visible parts of the message much. Do you have an example you're
thinking of?
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html