On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote: > On 04/06/2011 10:53 AM, Murray S. Kucherawy wrote: >> >>> Having cross semantic correlation of what headers mean with the >>> presence of dkim signatures from various different signers seems >>> like a lot more of layer violation to me. >>> >> That a DKIM hash covers a header field doesn't assign any new meaning to the >> field. It only guarantees its integrity. >> > > But that's the basic problem with the approach that Steve > laid out: we don't enforce any semantics about why a signer > signs something.
Nope, we don't. And shouldn't. > Doing so would open a large can of worms. It certainly might. Which is why we should avoid that sort of thing in DKIM itself, and let potential users specify what semantics they mean on a case by case basis (in, say, the specification for the particular metadata they're adding as a header). > Limiting new additions to the dkim header itself at least > would limit the problem of adding new semantics of a > signature header to exactly the entity doing the signing. Ah, no. If it's added to the DKIM header itself it will affect the entity doing the signing, and every entity they send email to. The affect on those who aren't cooperating with the sender may be small, but it's certainly there. Encouraging people to add semantics into the DKIM-Signature beyond the basics of "These headers and this body were sent by this d= defined entity" seems somewhat dangerous, whether it be by adding non-standard fields to the header or by overloading the semantics of existing fields. The fewer moving parts, the less likely it is to break. And I'd be much less bothered by some proprietary bit of metadata being broken than I would by the entire DKIM authentication being broken. Not putting those extensions within the DKIM data itself reduces the chance of them breaking the DKIM authentication. > The alternative would be very squirrelly when you think > of the general case of multiple signers in the path. The approach I suggest has no problems with multiple signers even if they, for some reason, all want to add conflicting metadata. (And I don't actually see much of a use case for it, it's just a demonstration that there is no need to shove unrelated data into the DKIM signature, rather it can be added cleanly at a different layer.) Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
