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
[email protected]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
