Douglas Otis wrote:
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.
This seems like the rarest of situations: Not only do you have multiple
From addresses in the message, which is rare to start with, but you're
considering a case where the multiple From addresses come from different
subdomains and optimizing for that case so that only one signature will
work for any of them. This seems like it's trying to redefine RFC 4871,
where the default value of i= comes from the value of d=, and if a
domain wants to sign for a subdomain it MUST include an i= tag with the
name of the subdomain. If a signature was supposed to be valid for any
subdomain, RFC 4871 should say that.
So: -1
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.
Ignoring the subdomain stuff (see above) I think this corresponds to
what I said, although you're using the term "identity" where I'm using
"local-part". But what you want to do is check the key restriction
against an Author Address, not the i= value, right?
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html