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 <[EMAIL PROTECTED]>
> 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
[EMAIL PROTECTED]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
