[ietf-dkim] ISSUE 1519: SSP-02:Author Signature scope too narrow
dotis at mail-abuse.org
Wed Feb 13 17:24:16 PST 2008
On Feb 13, 2008, at 4:50 PM, Jim Fenton wrote:
> Douglas Otis wrote:
>> 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
>> 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.
There is some confusion. This is _not_ about multiple From headers.
A message can be signed where there are multiple email-addresses
within different headers that are also within the same domain. This
situation is not rare at all.
> 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
When the key has not been restricted from being able to sign for the
sub-domain, why would it matter what had been used in the i=
parameter. By the same token, the i= could be blank and the default
would become the d= parameter. Although this signature might not
directly associate with the identity within the From header, it would
still provide a valid signature. Unless restricted by the key, there
is no reason to assume the signature is any less trustworthy as a
result. The From identity is included within the signature's hash
> If a signature was supposed to be valid for any subdomain, RFC 4871
> should say that.
A signature can be valid without being associated with any specific
identity. Don't confuse being valid with being associating with a
specific identity. These are too entirely separate issues.
> 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".
Identity may also include sub-domains and local-parts extending the
range of the domain's signature.
> But what you want to do is check the key restriction against an
> Author Address, not the i= value, right?
First and foremost, the signature must be valid. When a key is g=
restricted, the i= parameter must conform to the g= restriction. For
the conservative view, this would be saying that restricted keys must
be signing on behalf of the From header identity. However, there are
two separate key restrictions that come into play. Each of these
restrictions should be handled separately. The t= parameter may not
relate directly to the i= parameter. In other words, local-parts may
vary when the key is only restricted by the t=s parameter.
More information about the ietf-dkim