Murray S. Kucherawy wrote:
-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Wednesday, April 06, 2011 11:06 AM
To: Murray S. Kucherawy
Cc: DKIM WG
Subject: Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i=
tag/value))
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.
The alternative would be very squirrelly when you think
of the general case of multiple signers in the path.
That's a good perspective. I hadn't considered the idea
of multiple independent signers.
And equally as important are multiple independent verifiers where
there are no realistic expectation for persistent verification
extensions to be supported. The only persistent expectation among all
compliant verifiers is what's spelled out in the DKIM-BASE standard.
So if anything Murray, if you wish to write something about
extensions, IMO, would be a note regarding increasing authenticity
computational thresholds when using "extra header" bound versus using
DKIM-Signature tags. The former has a higher threshold for integrity
due to the presumption the extra headers will be persistent and
survive unaltered along the transport and/or gateway path.
As a side note Murray, currently from an API standpoint, we provide
operators the option to add extra headers to bind, but not add extra
DKIM header tags outside the specification. I believe you indicated
OpenDKIM is currently prepared to same way?
Therefore, if we wish to provide guidance to current and future DKIM
software developers, I think maybe you should consider to also add
some generalized text, if its not already there in explicit form,
indicating the DKIM standard allows for signer-defined non-standard
tags to exist and be bound to the DKIM-Signature. Of course, the only
technical requirement would be for it to follow the tag=value ABNF syntax.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html