Mark Delany wrote:
Informative Note: DKIM signatures by parent domains as described
in section 3.8 of [RFC4871] (in which a signer uses "i=" to assert
that it is signing for a subdomain) do not satisfy the
requirements for an Author Domain Signature as defined above.
[ . . . ]
Works for me.
+1
(I'd use commas instead of parentheses, but that's minor.)
IMHO, this is still wrong. The i= value should be _ignored_ when
determining ADSP compliance. I'll try some examples.
Any sub-domain included within the i= value (AUID) will not affect
ADSP compliance. Only email-address domains that reference the DKIM
key can comply with ADSP assertions.
'----
Right. The point is that i= is irrelevant at this stage to ADSP, just
as other tags in the signature may be. The question is whether we want
to be explicit about this tag not being relevant (and hence all the
others that aren't relevant need to be stated too).
Maybe the right thing to say is that a future extension to ADSP may
address how to interpret other signature tags, such as i=, but for now
they are explicitly *not* part of the ADSP evaluation.
It would be nice to use this "life time" to get this resolve now. Fr
some reason, I don't see a "future extension" coming, maybe something
completely different. Nevertheless, the key issue as I see it that we
lack protocol consistency and because of that we will be forced to
invent new and better policies.
Per 4871, i=, if any, must comply to d= formatting.
From: user @ domain.com
DKIM-Signature: d=domain.com
i=signer(_at_)domain(_dot_)com <= DKIM key tag t == s
i=signer(_at_)subdomain(_dot_)domain(_dot_)com <= DKIM key tag t !=
s
This would satisfy ADSP "1st party only" requirement, but 4871 does
have semantics that suggest possible "3rd party" using numerous
reference to terminology such as "on behalf of" using the i= tag.
The problem overall is that that 4871 requires the d=/i= to match (per
section 3.8).
Personally the big "invention" here is to not enforce that i= must be
the same domain name space. Since it is suppose to be "opaque", and
only useful for accessors, and its a concept beyond the verification
process, maybe we can afford this.
Here's why:
1) WITHOUT ADSP
Per 4871, right now with DKIM verifiers, if the d.domain and
i.domain are not compliant, the signature is considered invalid.
From.domain doesn't need to be considered in this test.
Like wise per 4871, if the From.domain and the d.domain are not
compliant, the signature is considered invalid. The i.domain
doesn't need to be considered in this test.
2) WITH ADSP
As far as ADSP is concern, the only thing that is important is the
From.domain and the d.domain matching. The validity of the
signature only includes the binding of i= regardless of its value.
So from a protocol consistency standpoint, i= really is open to be any
value and if that was allowed to be the case, the benefits are:
1) ADSP and 4871 are protocol consistency
2) 3rd party designs are now more possible using i= as part of
algorithm
3) MUA can benefit to possible gain "On Behalf" display ergonomics.
I see verifiers in the long run doing fast lookup for the From: domain
before invoking heavy overhead DKIM hashing. The signature, if it
exist, must first pass syntax and formatting checking. i.e., check the
that domains match, before really anything else. So if i= is tied to
d= as it is now, then it create issues for policies like it does not
and limits 3rd party designs.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html