-----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