As it says in the subject.
S.
#1 Overview is still somewhat sales-ish. A bit more objectivity would arguably
be more appropriate. E.g. "requires minimal new infrastructure" would be better
stated as "reqiures no extensive new infrastructure", "transparent to..." is
also a bit inaccurate, since there are some cases where DKIM is not
transparent, e.g. some mailing list cases.
#2, section 1.2, 1st sentence, maybe "the question of the identity of..." would
be better. As it is, the words don't quite make sense, even though I know
what's meant.
#3, section 1.2 "Recipients can..." should be "Verifiers can..." since most
recipients won't look at DKIM stuff (unless I've gotten this wrong again;-).
#4, section 2.5, an informative note after the 1st para might be nice, or is it
obvious that obs-* are obsoleted? Are there no others to exclude? Why not?
That stuff is not obvious to me as it happens.
#5 section 3.3.3: "keys smaller than... are subject to brute force.." The fact
is that every algorithm is subject to brute force. Whether or not factoring is
considered brute force is also perhaps debatable. I suggest replacing with
something like "using keys with a modulus shorter than 1024 bits may be
considered unwise"
#6 section 3.5 says that "Unknown tags MUST be signed but MUST otherwise be
ignored by verifiers." I think s/signed/verified/ would be a little better
there on the basis that the tag presumably wasn't unknown to the signer. Feel
free to ignore this though.
#7 section 3.5 defines the 'c' tag as Body c14n, but it actually specifies both
c14n uses, so s/Body canon.../Canon.../
#8 section 3.5, "d=" bit, introduces the "i=" tag without explanation (its a
forward reference). Suggest adding something in brackets to explain
#9 section 3.5, "i=" tag. I think the "If the ...is unwilling...MUST be
omitted" sentence is wrong, since its hard for a programmer to know who's
willing to do what. Suggest saying that the localpart MAY be omitted and put
anything else in an informative note.
#10 section 3.5, "i=" tag text says that if the local part is absent then the
key MUST be valid for signing any address in the domain, but having read this
far I've no idea how that's determined. A forward reference is needed here I
think (or else I'm confused again:-).
#11 section 3.5, "t=" I think it'd be no harm to specify the timezone here, its
seconds-since-197001010000Z isn't it? (Modulo leap seconds or whatever.) And
there should be a sentence saying the the x= value had better be less than the
t= value if both are present, right?
#12 section 3.6, 1st para is a bit defensive while at the same time overselling
DKIM. How about the following instead: "Signature applications require some
level of assurance that the verification public key is associated with the
claimed signer. Many applications achieve this by using public key certificates
issued by a trusted third party. However, DKIM can achieve a sufficient level
of security, with significantly enhanced scalability, by simply having the
verifier query the purported signer's DNS entry (or some security-equivalent)
in order to retrieve the public key." Maybe a bit wordy though.
#13 section 3.7 would be better off talking about the signature input bytes
rather than hash calculations which will often happen inside some signature
API. (This might change if the existing issue about separate body and header
hashes gets accepted.)
#14 section 5.1 2nd para. I can't see much point in this - would the spec be
worse were this deleted?
#15 section 5.4, 3rd para. Text is a bit odd - how's the signer supposed to
know which fields it wants the verifier to "treat as trusted"? Also, the 2nd
sentence is very MUA oriented. Suggest deleting the paragraph (though I like
the "extreme skepticism" phrase).
#16 (like #13 above) section 6.3, last bullet: "Compare the decrypted signature
to the message hash..." is wrong. PKCS#1 (and later) signature schemes require
more, in the case of pkcs#1v1.5 there should be an algorithm OID in the
recovered plaintext as well. As before, suggest rephrasing this in terms of
calculating the bytes input to a signature verification API.
#17 Why the MUST on the textual representation in section 3.6.1? Seems like
anything that can be mapped to this would be ok, and there's only a need for a
MUST for the DNS case. Suggest restricting it that way. E.g. were an XKMS key
server option to be defined, it would likely represent the keying material in
xml as a ds:KeyInfo or xkms:KeyBinding and there's no reason to prevent that.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html