On 3/31/2011 5:33 PM, Jim Fenton wrote:
The direction of the DKIM specifications since RFC 4871 have been to
rely less and less on the AUID (agent or user identifier, the i= value
on the signature) to the point that it provides no security benefit. On
the other hand, a malformed AUID can cause a DKIM signature not to
verify, and i= currently adds to the complexity of the DKIM
specification. For this reason, I am formally proposing that the i= tag
and supporting text be removed from 4871bis.
i= was introduced in RFC 4871 as a mechanism to:
(1) Allow a parent domain to sign for a subdomain, simplifying the
management of keys. So if example.com had several subdomains and wanted
to use the same keys to sign for all of them, it could put the actual
domain name being used in the i= value (e.g., marketing.example.com) and
the location where the keys were stored in the d= value (e.g., example.com).
(2) Support finer-grained verification in conjunction with the g=
tag/value in the key record. We have already decided to remove the g=
tag/value in 4871bis.
(3) Support matching with the From address to determine if a signature
was an Author Signature in SSP. SSP became ADSP, and WG consensus was
to match the domain of the From address against the SDID instead.
In order to remove i= from the specification, we need to: ....
In a conversation with Dave Crocker and Murray Kucherawy, they noted the
use of the local part of i= as an opaque identifier. Its use as such an
identifier is not described in any standard, but the relaxation of the
current restrictions on the use of i= (that the domain-part be a
subdomain of d=, etc.) would result in an incompatibility with RFC
4871-compliant verifiers. It is, however, possible to remove it
entirely without creating a compatibility problem.
Comments, please.
-Jim
Interesting. I've been thinking in exactly 180 degrees from that, from
the point of view of "what would need to be added to make i= useful?"
The problem I see with i= is the opacity, and as an opaque value with no
semantics for the localpart of it. If there were a way for a domain to
indicate exactly what semantics the signer is using for the i= value,
the combination of that plus the i= value can then be used in various
ways by the recipient verification engine. For example, our
implementation would put the username@domain into the i= value when it
was dealing with an authenticated user mail submission, and otherwise
leave it blank. If there were a way in the DNS key record to indicate
those semantics, the recipients could use that information for
additional processing.
So, -1 without full consideration of what could be done to make it useful.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html