These don't all deserve an individual entry in the tracker, so maybe
just create one for the lot and we can spin out new ones if necessary
later.
Stephen.
#1 2.6. How would multibyte characters be handled? If its clear from the quoted
rfc, then fine. If not, do we need to say something in case the mail i18n folks
(eai) get going?
#2 3.1 Just checking. This part says: "Periods are allowed in selectors and
are component separators. If keys are stored in DNS, the period defines
sub-domain boundaries." Does that mean that the lookup for tcd.ie's foo.bar
selector is in foo.bar_domainkey.tcd.ie? I assume so. If it means something
else then I'm confused.
#3 3.2 Tags. We say nothing about the max. lengths for either tags or values.
Given that all but one of the currently defined tags are only one character
long, coders might make bad assumptions here. What, if anything, are the max
lengths for these?
#4 3.2 Tags. As with #1, we assume single byte characters here in tag values
(VALCHAR in the ABNF). What if/when Unicode is allowed in headers?
#5 3.2 Just checking. Is the final ";" always really necessary as indicated by
the ABNF? If so, does current code insist upon this?
#6 3.3.4 says signers MUST use 1024 for *long-lived* keys, but we never say
what long-lived means. I think we need to delete the term "long-lived" and just
say that signers MUST use at least 1024 bit RSA moduli. (See also editorial #7
below.)
#7 3.4 Starts "Empirical evidence demonstrates..." so shouldn't there be a
reference? (This isn't just editorial - if there is quotable evidence that may
help the WG in closing some issues.)
#8 3.4, 5th para ("In all cases...") is now incorrect since we have "bh=" And
when fixing this try be careful to talk about the signing algorithm as
rsa-sha256 and not rsa, i.e. hashing takes place *inside* the signing API - so
no-one outside sees the hash.
#9 3.4 Last para. I18n again - we may need more instructions here if the
headers now need to be normalised first.
#10 3.4.1 Just checking. When the value of a z= header field is fed into
simple, the spaces that are quoted remain quoted, right?
#11 3.4.2 Just checking. The relaxed form of " =20 " is a single space,
right? Or is it " =20 "?
#12 3.4 generally. Could we get someone to volunteer some pseudocode for these
algorithms? I think that that might help cut out some corner cases.
#12 3.4.4 Why not replace this algorithm with the S/MIME c14n alg (of pgp's).
The logic behind that replacement is that there is code and experience with
those body c14n's?
#13 3.4.5, 3.5 and 3.7. "l=0" is allowed, but "bh=" is REQUIRED, which is a bit
of a contradiction. 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=", however for the special case of "l=0" it seems
odd to include "bh=" at all. I think I'd prefer to outlaw "l=0" and make "bh="
optional for just that case, but that might be a bit broken for backwards
compatability.
#14 3.5, "d=". The relationship between "d=" and "t=s" in the key record and
"i=" is a bit complicated. If it could be simpler that'd be good, but at least
a paragraph elsewhere explaining it (incl. ASCII art?) would be good.
#15 3.5 "d=" says that idns names MUST be punycoded and depending on stuff,
might have to be the same as in "i=". Does the dkim verifier have to be able to
handle only binary comparisons of the punycode or is support for any
alternatives needed? (I hope not.)
#16 3.5 "i=" if "d=" MUST be punycode, then so must the domain part of "i="
(where needed), but it doesn't say that.
#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.
#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.
#19 3.6.1, "h=". This says MUST sha1 but the text never mentions sha256. I
think this should be MUST for both.
#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.
#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.
#22, 5.4 Says "The signer MAY include more header field names than there are
actual corresponding header fields to indicate that additional header fields of
that name SHOULD NOT be added." Is this feature needed? Seems like it just adds
complexity, in particular to the verifier and may be a source of bugs.
#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? E.g. could it happen that sign-or-remove would be the wrong thing to
do, if the signer couldn't verify the assertion in that field but perhaps the
verifier could? Note: while such a scheme could be invented, I am not saying it
ought be. (Same issue crops up in last sentence of the next para.)
#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.
#25, 6.1. Just checking. Would an implementation that only tries to verify one
single signature ever (regardless of how many are present) be compliant? Its
hard to tell from reading this section since so much is down to local policy.
#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.
#27, 6.1.2, list #4. This is probably dumb, but I'm not afraid to embaras
myself:-) Is there any way someone could cause the DNS to loop, returning a
stream of (presumably bogus) public key records? If not, fine (and I suspect
that this is the case). If so, then we might want to advise verifiers to
include a max. after which they handle the message as a PERMFAIL.
#28, 6.1.1, list. Should we add another item to the list to the effect that the
verifier MAY reject the key if its too short? (Could also be added to item #9
in the list.)
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html