[ietf-dkim] Misc. fairly minor issues

[Eric Allman]

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

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

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

>> #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?

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

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

>> #20, 3.6.1, "k=". This would be a good place to say (again) that
>> "rsa" means a key with a fixed public expontent == 65537.
>
> s/expontent/exponent/; agree.

It's looking like there is no reason to limit it to a single 
exponent, so this is pending removal.

>> #21, 3.6.2.1 Says that "i=" is not used for DNS, but you removed
>> that as an input to dkim_find_key already so I think this sentence
>> should go.
>
> Agree.

I guess.  I still disagree with removing it from dkim_find_key 
though, since it might be used for other query mechanisms.  C'est la 
vie.

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

>> #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?

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

eric