On Feb 13, 2008, at 4:50 PM, Jim Fenton wrote:
Douglas Otis wrote:
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.
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
subdomain.
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
after all.
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html