-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 9, 2007, at 9:23 AM, 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. > Since I'm being quoted, I'm not sure if I should give a quick comment or not. I don't believe that DKIM/SSP can come into competition with OpenPGP or S/MIME, even if that became an explicit goal. The issue is mandatory end-user identification with i=. Now, Jim Fenton called me on the phone after that, and explained that there are some uses (like using g= for delegation) of i= where the signer is not at liberty to put anything they want there. I'm not concerned with that. I'm also not saying that an administrative domain *cannot* essentially have one key per user. My objection is with any language that dictates in the general case what the signer *must* put there, so that the receiver can depend on it. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHX0tgsTedWZOD3gYRAhUMAKCwYrIqBWp8KQ+vuQ9bQcEmDiEkLACgp3nL tjFuqY4kBMMoZIYj8YQ+d2E= =JnxP -----END PGP SIGNATURE----- _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
