[ietf-dkim] ISSUE 1519: SSP-02:Author Signature scope too narrow
dotis at mail-abuse.org
Wed Feb 13 16:19:49 PST 2008
On Feb 13, 2008, at 3:46 PM, Jim Fenton wrote:
> Douglas Otis wrote:
> Also relates to issue 1399 "clarify i= vs. SSP" if I understand that
> 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.
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
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
More information about the ietf-dkim