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