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
