On Feb 13, 2008, at 3:46 PM, Jim Fenton wrote:
Douglas Otis wrote:
See:
https://rt.psg.com/Ticket/Display.html?id=1519
Also relates to issue 1399 "clarify i= vs. SSP" if I understand that
correctly.
To briefly summarize, I understand Doug's issue to be the question
of whether the local-part of an Author Address should be matched
against the i= value, if a local-part is present in i=.
SSP matches the local part if present
draft-levine-asp-00 matches only the domain part
Doug is suggesting a third alternative: to match the Author Address
against the g= field in the key record used to verify the signature.
Doug, please verify that I understand the issue correctly before I
invest a lot of keystrokes in responding.
Jim,
Almost. Here is the 10,000 foot view from the two perspectives.
View 1: (recommended)
The verifier does not police how someone might make use of a DKIM key.
Restrictions on the key (g= t= parameters) only limit which identities
can be associated with a signature. Policy, on the other hand, is
constrained only by DNS hierarchy. When a domain signs a message for
a group of users within different sub-domains, the message would be
considered compliant with an "all" assertion when a valid signature's
d= parameter is at or above the From email-address domain (referencing
the policy). The identity and header associated with a signature is
not germane to DKIM policy.
View 2: (conservative)
The verifier should police how someone might make use of a DKIM
restricted key.
Restrictions on the key (g= t= parameters) limit which identities can
be associated with a signature. In essence, the sub-domain and
identity within the From email-address must be encompassed within the
scope of the key's restrictions. In the case of restricted keys, the
key should be able to have provided a valid signature for the From
email-address identity and domain (referencing the policy). The
identity and sub-domain associated with a signature is not germane to
DKIM policy. The signature might be on-behalf-of of some other
identity within headers other than the From, or even in no header at
all.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html