At 21:39 21-10-10, John R. Levine wrote: >Overall: in several places such as the informative note at the top of > page 18, the language says that the verifer produces an edited > version of the message. We either should say that the edited message > is part of the verifier's output, probably in section 2.2, or delete > the editing language. I'd suggest the latter.
I suggest the latter. >Page 11, informative operations note at the end of section 3.1: Either > change to "Signers SHOULD NOT reuse a selector with a new key" or > delete it. As it is informative, it is better to avoid the "SHOULD NOT". >Page 11, informative implementation note at the bottom of the page: > Delete it. If we want to support EAI, we should support EAI, but > this language just encourages code that won't interoperate. That depends on the text in Section 3.5 on which I commented previously. >Page 13: section 3.3: should it also say "Verifiers MUST implement > both sha1 and sha256"? It says so on page 20 in a= and page 30 in > h=, but I think this is a better place to put it. Yes. >Page 13, informative note at the bottom of the page: Delete. I realize >that people still use sha1, so we should document it, but is there any >reason to encourage it. Yes. >Page 14, sec 3.3.3, first paragraph. I don't understand what this pp > is telling me to do. In the second sentence, what does "for > long-lived keys" mean? A week? A decade? And what's the life of > the key? The time from when it's published in the DNS until it's > deleted? The time that signers use it, regardless of time in the > DNS? Suggest trimming this down to say signers MUST use at least > 1024 bits, verifiers MUST handle 512 to 2048 bits, and leave it at > that. If we think a 512 bit signature is no good, we should say so. The long-lived keys is related to the time it takes to succumb to an attack. I would say that the validity is as long as the keys can be used to verify a message. >Page 20, informative note under v=: Delete. Has a version number ever >increased other than arithmetically? I suggest keeping this as version numbering is always a problem. >Page 24. first pp: delete "or MAY choose other means of representing > its users." An AUID need have no relationship to any user. Some of > my AUIDs refer to web scripts and mailing lists. > >Page 24, informative note: suggest deleting, again because AUID need have > no relation to any user. Or perhaps rewrite as: I suggest not touching those two to avoid rehashing previous discussions. >Page 24, informative discussion: delete everything after the second > sentence, since it doesn't help robustness or interoperability See above. >Page 25, informative implementation warning: remove language at the > end of the paragraph suggesting that the verifier can remove text > from the body. Yes. >Page 29, description of v=, last sentence: compare that to the note on > page 20 that I suggested deleting. I suggest keeping it. >Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather > than just "a verification header" ? My previous comment about this was ignored. At 17:39 22-10-10, Murray S. Kucherawy wrote: >Can you say SHOULD NOT in something informative? No. > > Page 27, x= first informative note: delete, doesn't help robustness or > > interoperability. (Neither does x= but that's a lost battle.) > >I'm not even sure I understand that remark. Can someone remind us >of what it's trying to say? "x=" should not be considered as a way to mitigate replay attacks. >Verifiers SHOULD treat invalid signatures as though they were not >present in the message. Verifiers SHOULD ignore invalid signatures ... >I think the idea is that RFC5451 is one example of an annotation >system, so "a verification header field such as the one described in >RFC5451" would probably be fine. You argued for standardization of the header field. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
