ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Please post issues with draft-dkim-rfc4871-errata-03

2009-02-11 06:21:56
MH Michael Hammer (5304) wrote:

Jeff Macdonald wrote:

d= is just an identfier that is used to look up the public key

Jeff,

It a DNS DOMAIN and a DNS DOMAIN is a well defined entity. And this d=
DNS DOMAIN must match the 2822 (DNS) [From] Domain.  It is well forth,
bloody, scared specific 1st PARTY only signing requirement. It does
not lack clarity. It is not obtuse, it is not "hard to understand or
explain," nor is it unintelligible, and it is certainly not opaque.


Hector,

There is no requirement in RFC4871 (DKIM Base) that the d=domain must
match the 2822 (DNS) [From] domain. There is no requirement that it 
be 1st PARTY only signing as you put it. The relevant section of
4871 is as follows:

d=  The domain of the signing entity (plain-text; REQUIRED).  This is
       the domain that will be queried for the public key.  This domain
       MUST be the same as or a parent domain of the "i=" tag (the
       signing identity, as described below), or it MUST meet the
       requirements for parent domain signing described in Section 3.8.
       When presented with a signature that does not meet these
       requirement, verifiers MUST consider the signature invalid.

I believe you are thinking of the ADSP draft, which is not what the
errata or bis (whichever path is taken) discussion is about.

Yes and no.

Its all inter-related.

Consider:

1) From: user1(_at_)domain1(_dot_)com
    DKIM-Signature: d=domain1.com
                    i=user1(_at_)domain1(_dot_)com

2) From: user1(_at_)domain1(_dot_)com
    DKIM-Signature: d=domain1.com
                    i=user2(_at_)sub1(_dot_)domain1(_dot_)com

3) From: user1(_at_)domain1(_dot_)com
    DKIM-Signature: d=otherdomain.com
                    i=user3(_at_)special(_dot_)otherdomain(_dot_)com

In 1, everything is kolser, d=/i= matches, in fact, redundant (i= is 
not necessary.  It's a clear example of a 1st party signature.

In 2, everything is kolser, d=/i= still satisfies the requirements, 
but you begin to touch base with '3rd party' signing.

In 3, everything is kolser, but you have a clear 3rd party situation.

According to the errata, for 2 and 3 (less so 2) there is a mismatch 
and the receiver SHOULD take pain to point this out to the user.

In other words, the confusion with the equality or inequality with the 
2822.From address with that of i= is indirectly related to d= because 
d=/i= domain must be correct according to RFC 4871.

The only time there is "question" about a valid signature is when in 
fact, there is a 3rd party signing involved and the authorization of 
the author domain allowing it.

For 1st party signatures, it is less of an issue, 2822.From must 
conform to d= domain, or vice versa and therefore by virtue of the 
specification, so those i= must conform to the same domain name space.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html