Eric Allman wrote:
I've deleted the points where I have nothing to add to Paul's comments.
--On July 1, 2006 9:46:19 PM -0400 Paul Hoffman
<phoffman(_at_)proper(_dot_)com>
wrote:
#8 3.4, 5th para ("In all cases...") is now incorrect since we
have "bh="
Not sure why this is incorrect. The sentence is about the headers
used in tags that list headers; there are lots of other tags.
It's incorrect because the paragraph talks about sending the CRLF
followed by the canonicalized body. This algorithm is presented
elsewhere though --- does anyone object to just removing this paragraph
entirely?
Alternatively, remove the sentence "The CRLF ... body.". The rest of the
information still seems to be useful supportive text.
#13 3.4.5, 3.5 and 3.7. "l=0" is allowed, but "bh=" is REQUIRED,
which is a bit
of a contradiction.
"l=0;bh=;" seems valid.
(I think this has already been discussed.) "l=0;bh=;" is not valid.
There is always a bh= value, even if it is just the hash of the
zero-length string.
correct
And "l=" is not mentioned when saying how to calculate
"bh=". I guess the right thing to do might be to add some mention
of "l=" when talking about calculating "bh=",
Agree.
I changed the first line of the bh= description to read "The hash of the
body part of the message as limited by the "l=" tag (base64; REQUIRED)."
+1 with Jim's change to say "canonicalized body"
#14 3.5, "d=". The relationship between "d=" and "t=s" in the key
record and "i=" is a bit complicated.
Agree.
Could someone please propose simpler wording?
How about separating out the syntactic and semantic descriptions of d=,
i= and t=s? That is, leave the syntactic description there, but with a
forward reference to another section. That other section gives the
semantic description of the three values and their interaction.
If it could be simpler that'd be good, but at least
a paragraph elsewhere explaining it (incl. ASCII art?) would be
good.
Agree.
I'm not at all clear how ASCII art would apply here.
#17 3.5 "q=" says that different mechanisms MUST NOT change the
interpretation of the signature. I don't think we can require that
since different key services (e.g. xkms, scvp) may have different
information about the public key s.t. one says its a good key and
the other says not. Just deleting the sentence
should be ok though.
Agree.
I disagree. If you list multiple key query mechanisms, and the
semantics change depending on which one gives you the answer, isn't this
just asking for trouble? If you want different semantics, you should
have two separate signature header fields.
I agree; the semantics of a DKIM signature had better not change
depending on which key query mechanism returned an answer.
#18 3.6.1, "g=". Is "g=*s*t*e*p*h*e*n" allowed or is one "*" the
limit? I don't care, but it should say.
Good catch. Why does the definition for key-g-tag-lpart only allow
one "*"?
As already noted, simplicity. There was a comment that it should only
allow "*" at the end, but this would limit the applicability, e.g., for
companies that had a class of addresses that all ended in "-foo". Is
this a large enough use case? I don't know.
#19 3.6.1, "h=". This says MUST sha1 but the text never mentions
sha256. I think this should be MUST for both.
Agree.
My recollection is that we had agreed that signers MUST support sha256
and that verifiers must support both. On this assumption I changed the
wording to "Signers and Verifiers MUST support the "sha256" hash
algorithm. Verifiers MUST also support the "sha1" hash algorithm." If
we want to make both algorithms a MUST on both sides, it's easy to do so.
We had agreed that the MUST for both algorithms was only on the
verifier, and the MUST for signing was just for sha256.
#23, 5.5 Says "To avoid possible ambiguity, a signer SHOULD either
sign or remove any preexisting header fields which convey the
results of previous..." Is it wise to include a SHOULD referring
to a header field that's not yet defined?
No, and in fact it is nonsensical.
I can see that this doesn't make sense here because the signer doesn't
know what header fields will be used to convey this information on the
verifier side. However, the verifier should be sure to remove such
fields so that a spoofer can't just insert a header asserting that the
message was properly signed. With this in mind, I've added the sentence
"Verifiers may wish to delete existing results header fields after
verification and before adding a new header field to circumvent this
attack" to the end of the informative advice paragraph in 6.2.
+1
#24, same issue as #23 occurs in section 6 2nd para, where it says
that a verifier MAY add something. The MAY is wrong since the
something isn't defined.
Agree.
The point here is that the verifier is allowed to convey authentication
status in the header. Why is this not a MAY?
I know that there is a push against being specific here as to what is
added, but I think we really need to keep this concept alive and well.
If we were being specific about using Authentication-Results, I'd even
want to make it a SHOULD or even a MUST. But just because we've watered
it down this much doesn't mean we should get rid of it entirely.
Keep it a MAY at the minimum.
#26, 6.1.1. Section 5 says that "From" MUST be signed. I expected
to see a verifier rule for that here. Suggest adding that.
Agree.
I added a paragraph reading "If the "h=" tag does not include the "From"
header field the verier MUST ignore the DKIM-Signature header field and
return PERMFAIL (From field not signed)."
+1
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html