Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Michael Thomas [mailto:m...@mtcc.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