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