[ietf-dkim] NEW ISSUE: Signature semantics

[Jon Callas]

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