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: - Remove section 2.6 (definition) - Remove i= tag definition from 3.5 - Remove i= from example at the end of 3.5 - Remove "s" flag from t= tag definition in 3.6 - Remove section 3.9 (Signing by Parent Domains) - Remove section 3.10 (relationship between SDID and AUID) or change it to reflect SDID-only information - Remove reference to i= tag in 6.1.1 paragraph 5 - Remove section 8.13 (Inappropriate Signing by Parent Domains) - Remove i= from examples in A.2 and A.3 - Change IANA registries to retain i= tag in signature and "s" flag in key record as deprecated That's what I could find, but I may have missed something. 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html