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: mailing-list@xxxxxxxxxxxxxxxxxxx
From: jon.doe@xxxxxxxxxxx
DKIM-Signature: i=mailing-list@xxxxxxxxxxxxxxxxxxx;
d=example.com; ...
A message from a user within the domain might be signed as follows:
From: jon.doe@xxxxxxxxxxx
DKIM-Signature: i=jon.doe@xxxxxxxxxxx;
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: office-admin@xxxxxxxxxxx
From: jon.doe@xxxxxxxxxxx
DKIM-Signature: i=office-admin@xxxxxxxxxxx;
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:sally.doe@xxxxxxxxxxx
From: jon.doe@xxxxxxxxxxx
DKIM-Signature: i=1234567.radius@xxxxxxxxxxx;
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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf