-----BEGIN PGP SIGNED MESSAGE-----
On Dec 9, 2007, at 9:23 AM, Dave Crocker wrote:
6. Signature Semantics
DKIM was devised to provide a means of declaring an
that is taking "responsibility" for placing a message into the
This is a very constrained semantic for the signature, and really
no more than a delivery decision.
In reviewing the apparent semantics of full SSP use, I believe it
move a DKIM signature, which uses the same domain name as is in
field, into the realm of declaring content to be valid. This is a
demanding semantic and, I believe, moves the DKIM/SSP service into
competition with S/MIME and PGP. At best, this seems entirely ill-
At the least, it is considerably more ambitious than the initial
discussed for SSP. For an initial version of a standard, more
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:
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.
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
-----END PGP SIGNATURE-----
NOTE WELL: This list operates according to