On 3/4/2011 5:02 PM, Jim Fenton wrote:
1. Introduction: The opening paragraph has lost the sense that the signer has
to be authorized by the domain owner to apply a signature on behalf of that
domain. While the previous draft was a bit too restrictive (implied that the
signer had to actually be the domain owner) this version is too loose. For
the opening sentence I suggest something like, "DomainKeys Identified Mail
(DKIM) permits a person, role, or organization to claim some responsibility
for a message by associating a domain name [RFC1034] for which they are
authorized with the message [RFC5322]."
I believe the 'authorization' issue is implied by the 'validation' sentence in
that paragraph. However as long as it does not make the opening sentence
overly
long or convoluted, it cant hurt to call this point out explictly.
So...
<t>DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name <xref
target="RFC1034"/> with the message <xref
target="RFC5322"/>, which they are authorized to use. This can
be an author's organization, an operational relay or one of their
agents. Assertion of responsibility is validated through a
cryptographic signature and querying the signer's domain directly
to retrieve the appropriate public key. Message transit from
author to recipient is through relays that typically make no
substantive change to the message content and thus preserve the
DKIM signature. A message can contain multiple signatures, from
the same or different organizations involved with the message. </t>
Section 2.3, Identity: I realize this is taken from RFC 5672, but the
definition is not clear to me. Suggest that the second sentence read,
"Identities that may be associated with DKIM signatures include authors and
their organizations, ISPs along the message handling path, and mailing list
operators." (I'm not sure how the independent trust assessment services apply
here, since their assessment happens AFTER signature verification). [same as
last call comment on -02]
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.
2. It turns out that this sort of text is much clearer when it makes a singular
rather than plural reference, especially given that the term being defined is
singular.
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.]
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
Section 3.7, Computing the Message Hashes: "ABNF of the algorithm" does not
make sense; ABNF is a syntax specification, it does not specify algorithms
(and this isn't ABNF, either).
How about:
<preamble>More formally, pseudo-code for the signature
algorithm is:</preamble>
Section 5.3 paragraph 2: remove comma after RFC 2047 (happy National Grammar
Day!)
ack
Section 6.1.2 Note: The first sentence is describing behavior of a number of
queries, and should be plural, i.e., "The use of wildcard TXT records in the
DNS will produce responses to DKIM queries that are likely not to be valid
DKIM key records."
One of several problems with that Note is, again, the use of plural where
singular works better. The original text also is overly broad and,
consequentially, ambiguous. So:
<t
hangText="NOTE:"> The use of a wildcard TXT record
that covers a queried DKIM domain name will produce a
response to a DKIM query that is unlikely to be valid
DKIM key record. This problem is not specific to DKIM
and applies to many other types of queries. Client
software that processes DNS responses needs to take
this problem into account.</t>
But note that the final sentence is meaningless, since it provides no guidance
about what it means to "take this problem into account". And the answer isn't
obvious. For example, I have no idea what a DKIM implementer should do to
satisfy this caution.
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.
As currently worded, the mail system is
advised to take pains to ensure that the SDID is displayed for a message
signed on behalf of a subdomain; this isn't necessary. Given the WG's past
consensus to ignore the local part of the AUID, I suggest the following
wording for the last sentence of the paragraph: "If the domain of the AUID is
not the same as domain of the address in the From: header field, the mail
system SHOULD take pains to ensure that the actual AUID domain is clear to
the reader." [same as last call comment on -02; the point is that if the AUID
references a subdomain of the SDID, it should still match]
I do not understand the basis for providing any results/policy guidance
concerning use of AUID.
8.14: Remove extraneous> in last paragraph.
ack. (but it someone beat you to the punch on that one, since it is already
gone from the xml.)
(not sure where) g= resolution: As Murray pointed out
(http://mipassoc.org/pipermail/ietf-dkim/2010q4/015030.html), we need to make
the appropriate adjustments to the registries making g= obsolete, and an
informative appendix cautioning signers not to put empty g= values in their
key records because of the legacy behavior of many verifiers.
yeah, but I have to confess the way to handle this isn't obvious to me.
does anyone have guidance for this?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html