On May 1, 2009, at 8:56 AM, Barry Leiba wrote: > Apart from the item that resulted in the "errata" draft, now heading > to the IESG as an update to 4871, there are a bunch of other non- > controversial errata that Pasi needs a response to. Will the 4871 > authors please handle those, so the working group and Pasi can clear > them?
Barry, Forgive the confusion about what was to be accomplished by the errata now heading to the IESG. There was a vote in SF to _not_ make functional changes to RFC 4871, and that such changes were to be as a RFC 4871bis draft. The errata however, either through error or by intent, made a significant change to RFC 4871 by excluding the i= value from being information passed to the MUA. RFC 4871 indicates that the i= value IS the information passed to the MUA, where the d= value represents a default i= value when the i= value is not included within the signature. In addition, the d= value must be included within the i= value. The current RFC 4871 is in sync with the just released RFC 5451. To avoid changing the role of the i= value (the signing identity), the text within the MUA consideration section 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.. '--- Limiting address annotations to just the d= value prevents a signing domain _any_ means to eliminate on-behalf-of ambiguity for the recipient. Without this feature, social engineering attacks that glean and spoof a person's acquaintances will be much more difficult to mitigate. Any account from the same provider will always result in the same annotation of the From header. :^( Don't make changes in an errata that impacts a fundamental and potentially crucial feature of DKIM. Reserve such changes for a fully reviewed RFC 4871bis draft. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
