My comments on the -03 draft:
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]."
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]
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?
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).
Section 5.3 paragraph 2: remove comma after RFC 2047 (happy National
Grammar Day!)
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."
6.3 paragraph 5 has changed "signing identity" to SDID. The signing
identity really corresponds to the AUID. 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]
8.14: Remove extraneous > in last paragraph.
(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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html