-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Monday, March 28, 2011 2:27 PM
To: IETF DKIM WG; Dave Crocker
Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
0. Can you clarify what it is about the definition that is not clear?
(Any guidance at all will help for understanding the nature of what
needs fixing.) The initial text is the definition and it's simplicity
makes it difficult to guess what the problem is.
1. "authors and their organizations" could be misinterpreted to mean
that the conjunction defines a single identity.
But the current text says "...examples include the author, ..." so that
misinterpretation exists there as well. I'd be fine with just "authors'
organizations".
Since it's in definitions for "Identity" in general, and the "i=" could
conceivably identify a specific author, is this a correct change to make? It
doesn't seem to be talking specifically about "d=".
3. One form of assessment service -- of which the late Goodmail was an
example
-- can give a priori assessment and then indicate tghe assessment by
providing the signature to the message before it is sent. That is,
the authoring organization passes the message to the assessment
service and the assessment service hands back the signature to be
included in the message. (The details can vary, of course, but this
describes the basic model.) Hence the signature is somewhat akin to a
capability token. [I thought I had explained this processing option a
number of times over the years, specifically citing the Goodmail
example.]
That's a specific example of an ISP along the handling path. The
potential for misinterpretation of this is greater than the benefit of
explaining this potential usage scenario, especially since "assessment"
has a very specific definition in the DKIM context.
I think I'll let Dave reply to this one, since I lack the context.
Section 2.9, Common ABNF tokens: Two new tokens are defined based on
field-name and dkim-quoted-printable. But where are field-name and
dkim-quoted-printable defined?
field-name is defined in Section 2.10
DKIM-Quoted-Printable is defined in Section 2.11
Would it be beneficial to rearrange the sections to avoid the forward
reference?
OK by me. I'll swap the "Imported" and "Common" sections.
Section 3.2, paragraph 2: dkim-quoted-printable is now defined in
section 2.11, not 2.6.
Fixed.
6.3 paragraph 5 has changed "signing identity" to SDID. The signing
identity
really corresponds to the AUID.
That has not been correct for any version of rfc4871bis. The term
Signing Identity has no normative value and is now only used in the
introductory text.
Also note that the Update removed any meaningful semantics for AUID:
The AUID comprises a domain name and an optional
<Local-part>. The domain name is the same as that used for the
SDID or is a sub-domain of it. For DKIM processing, the domain
name portion of the AUID has only basic domain name semantics; any
possible owner-specific semantics are outside the scope of DKIM.
In fact, the AUID is not part of DKIM's formal output. So the formal
specification cannot then direct it be supplied to the assessment engine.
Nevertheless, suppose a message with From address
<joe(_at_)marketing(_dot_)example(_dot_)com> was properly signed with
i=marketing.example.com and d=example.com. What the text is telling us
is that the mail system SHOULD take pains to ensure that example.com is
visible to the user. This is counter to all of the text in the DKIM
specification that permits keys for a subdomain to be managed in a
parent domain. If these is consensus to eliminate signing for
subdomains, there is a lot of other stuff that needs to be removed from
the spec, including the i= tag itself, the "s" flag in the key record,
the text in section 3.9, and the security consideration in section
8.13.
The Update removed semantics associated with the local part of the AUID,
and not the domain-part.
If there is not consensus to remove subdomain signing, the wording
described here makes it meaningless. This goes to the heart of why I
have been arguing that the output of DKIM should be the AUID (or its
default value, which is the SDID), and not the SDID itself.
Again I think Dave is the better one to reply as he has the context for the
debate, but I suggest that the SDID is the only thing that is completely vetted
by DKIM, because the AUID doesn't necessarily correspond to anything real
(other than the substring matching the SDID).
An implementation that wants to cater to a DKIM consumer which wants the AUID
is free to do so, and Paragraph 5 of Section 6.3 doesn't proscribe such an
action (in fact, OpenDKIM has mechanisms to provide either). It's simply
describing a minimal compliant implementation.
C.2. Compatibility with DomainKeys Key Records
[...]
Replaced my text with yours.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html