http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata-04
Errata: Original Text: ,--- The tendency is to have the MUA highlight the address associated with this *signing identity* in some way, in an attempt to show the user the address from which the mail was sent. '--- Corrected Text: ,--- The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message. '--- This text revises the meaning of the original RFC . The over-reaching errata represents an effort to simplify output elements that are obtained from DKIM signatures. This simplification is already in conflict with the recent Authentication-Results header RFC5451, and misrepresents the i= value as an unimportant element contained within the DKIM signature. In addition, when the i=value (AUID) is not present within the signature, it defaults to being the d= value (SDID). Properly corrected without changing definitions or roles, the text could be as follows: ,--- The tendency is to have the MUA highlight the address associated AUID, in some way, in an attempt to show the user the address from which the mail was sent.. '--- or ,--- The tendency is to have the MUA highlight the AUID, in an attempt to show the user the on-behalf-of identity asserted by the authoritative SDID. Please note that the AUID or its default value will always include the SDID, the domain claiming responsibility for the message. '--- Use of the AUID ensures intra-domain sources can be differentiated by recipients. Section 3.5 of the current RFC4871: ,--- d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. '--- Here are some examples that argue against making this errata simplification: Scenario: A domain establishes a mailing-list within a sub-domain of their user domain. The user domain asserts ADSP restrictions based upon the From email-address domain. In the case of a sub-domain use, the Authentication-Results header presently collects the i= value, where the i= value is expected to provide information to assist the MUA with message annotations. A message from the mailing list might signed as follows: Sender: [email protected] From: [email protected] DKIM-Signature: [email protected]; d=example.com; ... A message from a user within the domain might be signed as follows: From: [email protected] DKIM-Signature: [email protected]; d=example.com; ... By allowing annotation of the Sender header field when from the Mailing-List versus the From header field when from authenticated users, a recipient can recognize different sources within the domain that might provide different levels of authentication while still purporting to be from the same author. Another example might be: Sender: [email protected] From: [email protected] DKIM-Signature: [email protected]; d=example.com; ... Here a message may have been authenticated as being sent by the office- admin on behalf of jon.doe, The DKIM signature indicates it was added on behalf of the office-admin. Another example of a possible valid signatures that might be: Sender:[email protected] From: [email protected] DKIM-Signature: [email protected]; d=example.com; ... A valid DKIM signature by the SDID verifies that it is authoritative for the namespace used within the AUID. This namespace may not always match against header fields, nor is this namespace assured to always represent valid email-addresses. When the i= value does not match against a signed header field, it may instead represent an internal on- behalf-of identifier. Perhaps the MUA may wish to annotate both header fields, or perhaps none when the Sender header field is not being displayed. Either way, the i= value represents a important output of the DKIM signature header specifically intended for consumption by the MUA as currently stated by RFC4871 and supported by RFC5451. A valid DKIM signature would be analogous to a tamper resistant laminate placed on a driver's license. The signing domain, or SDID, would be analogous to the State issuing the license. The i= value, or AUID, would be analogous to the driver's ID registered with the State. Both the State and the registered driver ID represent critical and essential identifiers. A driver's license lacking any driver ID would be fairly useless whenever there is a need to assess responsibility, and yet the change being made in the errata takes away the driver's ID. Please, don't emasculate DKIM with an errata. Being able to track intra-domain identifiers may become an essential element needed to deal with possible DKIM signature replay abuse. Without this convention, likely essential for larger domains, DKIM based behavior assessments become meaningless without path based registration. Extending DKIM by adding other headers will be highly problematic as a retro-active repair of damage caused by the errata. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
