Although I have been a big fan of i=, I now support the removal of it. (I've been on vacation the last 3 weeks, so I apologize for this late comment).
On Thu, Mar 31, 2011 at 5:33 PM, Jim Fenton <fen...@cisco.com> 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: > > - 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 > -- Jeff Macdonald Ayer, MA _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
