One person's interpretation...
#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?
RFC 2045 is probably sufficient for a mail implementer.
#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.
Yep.
#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?
'tag-name = ALPHA 0*ALNUMPUNC' seems to clearly say "it can be any
length greater than zero".
#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?
It isn't.
#5 3.2 Just checking. Is the final ";" always really necessary as indicated by
the ABNF? If so, does current code insist upon this?
It isn't necessary; it is optional as indicated by [ ";" ]
#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.)
Fully disagree. Given the known attacks on RSA, keys shorter than
1024 bits are useful for short periods of time (such as a week or
month), and will be for many years in the future, particularly for
the low value of short-term DKIM keys. See RFC 3776 (BCP 86) for the
math.
#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.)
There are no RFCs that demonstrate this.
#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.
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.
This paragraph should not list signing algorithms at all. If it did,
it should list the algorithm fully as rsa-sha256, of course.
#9 3.4 Last para. I18n again - we may need more instructions here if the
headers now need to be normalised first.
They don't with any of the standards we are dealing with.
#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?
Correct.
#11 3.4.2 Just checking. The relaxed form of " =20 " is a single space,
right? Or is it " =20 "?
The latter. None of the five bullets talk about undoing QP.
#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.
That would be nice.
#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?
Or, better, why not get rid of it, as discussed in a different thread?
#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.
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.
however for the special case of "l=0" it seems
odd to include "bh=" at all.
Disagree.
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.
It also adds another special case.
#14 3.5, "d=". The relationship between "d=" and "t=s" in the key record and
"i=" is a bit complicated.
Agree.
If it could be simpler that'd be good, but at least
a paragraph elsewhere explaining it (incl. ASCII art?) would be good.
Agree.
#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.)
The punycode is straight ASCII, so there is no "binary comparison".
It is simple equality.
#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.
Good catch. The same sentence for d= should be in i= as well.
#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.
#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 "*"?
#19 3.6.1, "h=". This says MUST sha1 but the text never mentions sha256. I
think this should be MUST for both.
Agree.
#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.
#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.
#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.
It prevents a MITM attack that many people think is significant,
namely adding headers that mean something to the recipient.
#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.
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.)
Agree.
#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.
#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.
It would be.
#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.
#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.
Current DNS RRtypes which result in a leaf record will not loop.
#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.)
No. The Verifier MAY reject the key if it was created on the first
Tuesday of the month, but we do not need to list that.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html