On 4/1/11 2:08 PM, Murray S. Kucherawy wrote:
In our conference call with Jim, Dave and I are left with three things
that need discussion in the working group before we request a working
group last call on it.
The first, and biggest, is the removal of “i=” that Jim has proposed
separately, so please comment on that thread.
For ADSP the d= and the From domain must match, which removes the need
for i=. Nevertheless, the i= can introduce different identities that
might assist when transitioning to different IDN encodings.
There is a growing use of UTF-8 DNS labels. For example use dig to
resolve バスケ指導.meblog.biz or xn--rckp2e534u8jh.meblog.biz. RFC6055
should be read with an understanding there will be increased UTF-8 use
in DNS. While currently RFC5321 requires email domains to use letters
digits and hyphens, such a requirement will be problematic for other
name services. It is also not clear whether UTF-8 aliases would be
prohibited, since the only requirement appears to be resolution of
necessary resources. It is too soon to know how this might be best
resolved, so why toss out options that might help resolve what a signing
domain hopes to permit.
Two lesser issues are:
1) The document currently talks about authors signing their mail, when
authors really don’t sign their mail, ADMDs do. The point of the
objection is that it might be wiser to talk about actual uses only and
not include possible uses. The suggestion is thus to remove the idea
that an author can do signing, changing it to “authors’ organizations”
or perhaps “authors’ ADMDs”. Is there support for this, or support
against making that change, or does it not really matter?
It matters, and it should indicate the domain does the signing, while
also getting rid of the g= stuff in the key.
2) The document has text related to “assessment”. Does an “independent
assessment service” fit into the DKIM model? Again, the issue is
whether or not we want to include discussion of uses that are possible
but uncommon. Is there support for this change, or support against
making the change, or does it not really matter?
It is likely the only sustainable assessment will be matching with known
good sources, which would benefit by having a means to handle aliases
and authorized paths. :^)
The text in question is this:
*2.3**. Identity*
A person, role, or organization. In the context of DKIM, examples
include the author, the author's organization, an ISP along the
handling path, an independent trust assessment service, and a mailing
list operator.
DKIM should make no claims about identities. DKIM only relates signed
portions of a message with that of a domain that publishes the public
key. Would it be right to suggest this domain _is_ an identity?
Take your time. There is no rush is there?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html