|
Re: [ietf-dkim] Misc. fairly minor issues
2006-07-07 16:35:44
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?
#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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|