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