On May 1, 2009, at 11:43 AM, Barry Leiba wrote:
On Fri, May 1, 2009 at 1:26 PM, Doug Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com>
wrote:
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
I understand your concern, Doug, but I think things are really OK
there. Here's why:
First, item 12 in the subject draft, updating section 3.9 of 4871,
says this:
A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the User Agent Identifier (i=) if present. In other
words, it's up to the verifier how to handle d= and i=, and the
verifier can certainly take i= into consideration in assessing the
signature.
RFC 5451 passes information to "*Mail User Agent (MUA)* and downstream
filters".
The MUA consideration section now in RFC 4871 refers to information
passed to the *MUA* as does the incorrectly transcribed by the
errata. The Signing Identity (the i= value or its default), is what
is defined as the information passed to the MUA. RFC 4871 clearly
indicates the i= value is optional, and its default is an empty Local-
part followed by an "@" followed by the domain from the "d=" tag.
The errata erroneously transcribed Signing Identity as being SDID.
Change RFC 4871 back to AUID, otherwise the information available to
the MUA is being changed. The AUID always includes the SDID. The
correct transcription for Signing Identity into the new terminology is
AUID.
Second, note that the Identity Assessor module, for which we
clarified the definition after San Francisco, is NOT the MUA, so be
sure not to confuse the two.
Agreed. The new Identity Assessor terminology creates confusion. We
both appear to agree an MUA is not an Identity Assessor. However, an
MUA may include an Identity Assessor.
The working group had consensus on the definition of "Identity
Assessor", with the recent update to it.
Currently, RFC 4871 indicates the AUID is to be passed to the MUA.
The AUID, or its default, is assured to contain the SDID.
Importantly, the SDID does NOT contain the AUID. This is a functional
protocol change via errata. In this case, the errata reduces
information passed to the MUA. In doing so, this potentially leaves
the "on-behalf-of" identity ambiguous for recipients. This errata
reduces clarity and weakens the protections being sought.
Third, remember that this update is trying to make a formal
distinction between the piece of code that does the "Identity
Assessor" function and any other code (including the MUA) that makes
other decisions. We'll certainly see the i= value included in
Authentication-Results headers, for example, and this text won't
change anything there.
But the errata IS functionally changing what is to be passed to the
MUA. Defining the term "Identity Assessor" does not change what is
currently defined as being provided to the MUA. By the errata
changing Signing Identity (AUID) into SDID within the MUA
consideration section, the information that MUAs might expect is
reduced. It would be fine to replace Signing Identity with AUID or
its default (@SDID) when not present.
Finally, the working group decided not to try to address any changes
to the "MUA Considerations" section, where we might talk more about
this sort of thing, because it's something that probably should be
pulled from the base spec in a -bis effort, and re-worked as an
informational document on its own.
This was my understanding as well. This section should only replace
"Signing Identity" with AUID to be consistent with the terminology
changes.
So... I concur with you that the i= value may be important for
deciding how to handle the message, and I don't think the text in
this update changes anything in that regard. And I think the
working group expressed comfort with that as well, in arriving at
consensus on this text.
Agreed. Defining MUA details in the RFC 4871bis draft or perhaps some
other draft as you suggested. Please don't make functional changes
in an errata that has the effect of reducing user protections.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html