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