Dave Crocker wrote:
6. Signature Semantics
DKIM was devised to provide a means of declaring an (organization's)
identity
that is taking "responsibility" for placing a message into the
transit stream.
This is a very constrained semantic for the signature, and really
pertains to
no more than a delivery decision.
In reviewing the apparent semantics of full SSP use, I believe it
seeks to
move a DKIM signature, which uses the same domain name as is in the From
field, into the realm of declaring content to be valid. This is a
much more
demanding semantic and, I believe, moves the DKIM/SSP service into
direct
competition with S/MIME and PGP. At best, this seems entirely
ill-advised.
At the least, it is considerably more ambitious than the initial
functions
discussed for SSP. For an initial version of a standard, more
ambitious means
more risky.
To the extent that the above is not sufficiently clear:
As discussion on the mailing list this past week has made clear,
there is continuing working group disparity about the semantics of
using DKIM, with or without SSP. The use of SSP's handling options
clearly moves things into statements about message content. This
exceeds the semantics for which DKIM was designed. See, for example:
<http://mipassoc.org/pipermail/ietf-dkim/2007q4/008136.html>
Before SSP can be stabilized the working group must reach consensus on
basic issues of semantics for the mechanism.
SSP does require one additional semantic over that of DKIM-base: in
addition to taking responsibility for the message, those domains that
publish SSP records other than "unknown" must assert that, when the
address in the From: header field is really their domain, that this is
actually true. Whether this assertion extends to the local-part of the
address is the subject of another issue (1399) so let's discuss that
part separately.
In other words, those publishing SSP records must make sure that they
don't sign spoofed messages claiming to come from their own domain.
Aside from that, no assertion is made regarding the content. As I have
frequently said, I would not want a DKIM signature to authorize a
transfer from my bank account.
This new semantic only applies to those who deploy (publish) SSP records
and therefore does not extend to DKIM-base (and therefore does not
require a modification to 4871). This semantic is not currently
described in the SSP draft, and needs to be in my opinion.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html