Subject: [ietf-dkim] Last Call comments on draft-ietf-dkim-rfc4871bis-02

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 21:50:53 -0700

I'll go through my comments on rfc4871bis in this message, but will 
split a couple of the larger comments out into separate messages.

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).

Section 3.3: Is there now no requirement on hash algorithms that must be 
implemented by verifiers?  If the requirement for verifiers to implement 
rsa-sha1, the informative note acknowledging a preference to use sha1 on 
low-security messages such as newsletters doesn't make sense.  It should 
probably be removed.

Section 3.3.1:  rsa-sha1 should probably be marked as deprecated if no 
longer required by 3.3.

Section 3.4.5:

a=: Why has the ABNF been changed from sig-a-tag to a-tag?  It is 
inconsistent with the ABNF for all of the other tags.

d=: The introductory phrase of all of the tag definitions is a phrase, 
not a sentence with a verb.  Remove the word "Specifies" and capitalize 
"the" (nit).  Also s/address-literall/address-literal/

h=: The definition of hdr-name has gone away; is it defined elsewhere?

i=: second paragraph, "or a subdomain of the value of" is an essential 
phrase and should not be set off by commas.  Also in the informative 
note, "in come cases" should not be set off by commas.

z=: Where has the definition of qp-hdr-value gone?  It is also needed 
for the q= tag.

3.6.1.1:  I have a problem with this new provision for g= but that is a 
longer discussion for a separate message.

3.8: "or a subdomain of" should not be set off with commas. (This was in 
4871 as well).

3.9 paragraph 2: s/hnamas/has/

3.9: Paragraph 3 makes it sound like it conveys the SDID regardless of 
whether the signature verifies or not, and does not require the result 
(pass/fail) of the verification to be reported.  I suggest that the SDID 
only be reported if the verification was successful, in order to 
discourage assessors from inappropriately using the SDID of an invalid 
signature for anything.

3.9 Paragraph 4 + informative discussion seem to wander off into the 
realm of how (or more accurately how not) to use the results from DKIM.  
This text was in 5672, so there may already be WG consensus for 
including it, but I'd rather see this sort of thing in the operations 
spec (RFC 5863).  If fact, it is already there, although it references 
back to the text I'm talking about.

5.3 paragraph 2 first sentence doesn't make any sense.  Use either 
"conformant" or "compliant", but be consistent.  This paragraph needs a 
fair amount of work yet.

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."

8.14 needs some editing work and I don't think characterizes the threat 
quite accurately.  I have jumped into the active thread on this section 
to discuss that.

Appendix C, there is a stray "[" character in one of the sample outputs, 
just before -----BEGIN PUBLIC KEY-----

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 10:27:47 -0400

> actual AUID domain is clear to the reader."

I may be alone in this thinking, but I think SDID/AUID should be
treated like a license id or social security number. It isn't really
meant for human consumption. End users are not going to be able to
make head or tails of an AUID or SDID. I think that last sentence
should be left out. There probably should be a MUA considerations doc
instead.

-- 
Jeff Macdonald
Ayer, MA