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
