At 23:00 03-02-2009, Eliot Lear wrote:
Here, the consumer of this information, the
verifier, is warned against making use of
i=. However, what we are now saying is that
practical deployment experience requires a
stronger warning; that absent additional
information from the signer that is not exposed
by this specification, verifiers SHOULD NOT rely
on i= as any sort of identity, because the value may not be present or stable.
The warning is about requiring the "i=" tag to
match any header fields. More comments below.
* Is the above statement actually true? Do
we have practical experience that shows that i=
is either unstable or unused? Can someone talk to that point?
The catch is that i= may appear unused because of
the way it defaults to the d= tag.
One remaining point of discussion:
While the confusion arises between d= and i=,
what verifiers do with a valid signed message is
still up to them. They could take input from
various header fields if they wish (and some assuredly do and will).
Some verifiers may do that but there isn't
anything we can do about it except to put a note.
The following contains text from RFC 4871.
The d= tag must be the same as or a parent domain
of the "i=" tag. Restrictions can be enforced on
the i= tag with the g= tag or the t= flag.
"In some circumstances, it is desirable for a domain to apply a
signature on behalf of any of its subdomains without the need to
maintain separate selectors (key records) in each subdomain."
In practical terms, I can sign for a subdomain
without further DNS changes. I noticed a few
sub-domains from a (biased) sample of over two thousand domain identifiers.
"If the DKIM-Signature header field does not contain the "i=" tag, the
verifier MUST behave as though the value of that tag were "@d", where
"d" is the value from the "d=" tag"
That's one of the uses of the domain in the "i="
as we can use the value from "d=" when the "i="
is absent in the DKIM-Signature header. The
question is which signing domain identifier
should we use. RFC 4871 says that it should be
the domain value from "i=". There are
specifications from this WG and outside it that are built upon that.
There is a well-known email service provider that
is not interpreting the "i=" correctly. Instead,
they use the domain part of "d=" as the "i="
domain value. I'm not aware of other implementations with that problem.
Technically, there is nothing that stop us from having:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=(_at_)x(_dot_)example(_dot_)com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe(_at_)football(_dot_)example(_dot_)com>
where x.example.com is an identifier used to
aggregate the Joe SixPack group of users. We
could also pass such information as:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt;
i=clue(_at_)football(_dot_)example(_dot_)com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe(_at_)football(_dot_)example(_dot_)com>
where "clue" in used to aggregate the Joe SixPack
group of users. But then it doesn't fit the description of user or agent.
For assessment purposes, some vendors may find it
easier to use example.com as the identifier from
the two above examples. Note that there isn't
any tie to information available through Whois as
the domain could have been "podunk.ca.us" or some
domain without any valid registrant information.
The domain value is generally useful for feedback
loops, for organizations with a homogenous
user-base, if the receiver will only accept DKIM
signed messages or by agreement between the
sender and receiver. For what it's worth, there
are some gov.uk messages which include an i= tag
where the Local-part matches the author of the
message; the is an email address match.
At 10:58 04-02-2009, Dave CROCKER wrote:
Opaque does not mean that the signer had no
intent behind the choices they made in doing the
encoding. And in the case of domain name
strings, it doesn't mean that the recipient side
can't know it's a domain name. It means that
they cannot know the scheme the signer used for choosing sub-domain names.
From previous discussions, it has been mentioned
that DNS does not have a feature to determine
administrative boundaries. In the dot-com world,
the sub-domain may seem obvious.
There is a difference between being able to use
the d= signing domain versus having deep
knowledge about the underlying intent behind encoding choices for it.
Agreed.
You know my name is David. You do not know why
my parents chose that name, and it doesn't
matter for your use of it as an identifier.
If you use that name for signing, then I can use
it as an identifier for you. I do not need to
know why you are using that name. The argument
against i= seems to be that it should not be used
as we don't know why that name is being used.
The WG could, as part of some future work,
consider obsoleting the "i=" tag if it believes
that it is a source of confusion when identifying
which domain value is appropriate or if it
believes that it is better to have one instead of
two more identifiers for Internet Mail.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html