On Feb 1, 2008, at 2:58 PM, Jim Fenton wrote:
Douglas Otis wrote:
This draft goes to the opposite extreme of the ASP draft and
increases the restrictions for "all" compliance as well. This draft
indicates _ALL_ messages are to include a signature with an i=
parameter matches that of an identity within the From header. This
is not the defined use for RFC 4871.
It is true that RFC 4871 does not require or define any binding
between the i= parameter and the From header field (or any other
header field, for that matter). That is defined by *SP. The
question is really the nature of that binding: whether it's the
entire address (in cases where i= has a local-part) or whether it's
just the domain. That seems to be what's at the heart of issue 1519.
You mean the i= binding is required by SSP. ASP only requires domains
to match. IMHO, even that is too restrictive. ASP should have
permitted signing domains at or above the From header. Only when the
t=s parameter is asserted within the key, would there be a need for
domains to match.
The ASP approach creates fewer corner cases. At least with the ASP
draft, any risk of misuse remains within the control of a domain to
rectify.
This last statement I don't understand. Can you give an example of
"misuse within the control of a domain" that is introduced by
matching the local-part?
A domain using RFC 4871 as defined might wish to clarify which entity
had been authenticated. Such authentication information would help
prevent intra-domain spoofing. SSP essentially prevents a single
signature from offering identity assurances when a message is being
redirected (Resent-From header) or being sent on behalf of (Sender
header) the From header. Is it really reasonable for an MTA to add
two signatures, one ambiguous and the other identity specific? An
additional signature is only needed because of the SSP definition for
a compliant Author's signature. There is enough information within a
signature added on-behalf-of (i=) of the Resent-From header for
compliance to be ascertained without also requiring an additional
ambiguous signature (no local-part).
ASP seems like the better of the two approaches. Eventually, MUAs
will be doing there right thing. Until then, it is important
compliance requirements not lead to the use of falsified or ambiguous
information. The i= parameter could also be a temporal value not
matching with any header when privacy is considered important. A
temporal value could provide a means to control abuse without exposing
the provider's customer's identity.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html