ietf-dkim
[Top] [All Lists]

[ietf-dkim] editorials and nits

2006-07-01 15:37:05

These definitely only need to be a single tracker entry.

S.


Editorial
---------

#1 saying "proof" and "non-repudiation" in the abstract is a mistake and
potentially misleading. Rephase to use less difficult terms, e.g.  talk about
signatures being evidence rather than proof.

#2 1.1, 1st set of bullets. The biggest difference between dkim and s/mime or
pgp signatures IMO is that with dkim we do not expect that signature failure
will lead to message (delivery) failure, whereas with s/mime or pgp we do. I'd
mention this in a bullet.

#3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS. Better to say
that dkim requires no *new* ttp.

#4 1.1, last para. Seems a bit early to introduce selectors here - was there a
reason (that still applies)? If not, then maybe this can be deleted now.

#4 3.2, 1st sentence. "multiple key signing/verfication algorithms" is not
a good phrase, suggest changing to "multiple digital signature algorithms"
instead.

#5 3.3.1 and 3.3.1, phraseology is still a bit odd. Suggest changing from:
"That hash is then signed by the signer using the RSA algorithm (defined in
PKCS#1 version 1.5 [RFC3447]; in particular see section 5.2) with an exponent
of 65537 as the crypt-alg and the signer's private key.  The hash MUST NOT be
truncated or converted into any form other than the native binary form before
being signed." ...to... "The signature is calculated using the RSA algorithm
with a fixed public exponent of 65537 - if a different public exponent is
required, then a new DKIM signing algorithm must be defined."

#6 3.3.3 suggest s/"do not understand"/"cannot verify"/

#7 3.3.4 says "RSA keys of at least 1024 bits" and similar. The 1024
refers to the modulus length so that would be more correctly stated
as "RSA keys with modulus at leat 1024 bits long". Similar fixes could
be done with other parts of the same section.

#8 3.3.4 would be a little clearer if it said that "Verifier security
policies may use the length..."

#9 3.4 s/result in an authentication failure/result in signature
verification failure/ since dkim isn't authenticating, strictly
speaking.

#10 3.4.5, 1st sentence: s/and verified/and to be verified/
or just drop the last two words. 

#11 3.4.5, end of 1st informative note: s/ignore the tag/ignore
content after the indicated length/ Reason - if the ignore the tag
then they won't verify the signature.

#12 3.4.5, 3rd para: s/body length count is made after/body
length count is calculated after/ 

#13 3.4.5, 2nd informative note: I think this just repeats stuff in 
the 1st informative note and could be deleted.

#14 3.4.5, last informative note: again I think this could be 
deleted.

#15 3.5 "q=" the text says "dns/txt" but the ABNF contains "txt/dns"
and the text description isn't clear (enough) that "dns" is allowed
and means "dns/txt".

#16 3.5, example at end. This example doesn't contain a "bh=", it'd
be better if it did since that's REQUIRED.

#17 3.6.1 talks about "the response" which is dns specific, and I
thought we didn't want to be here, so s/response/record/ maybe?

#18 3.6.2.1 and elsewhere, I see ""_domainkey"" and other instances
of double-double quotes. Can't see why those are there.

#19, 3.7. This talks about two hashes all the time, which is correct, but a bit
misleading since any sensible API will include both hashing and private key
application inside a "sign()" function. The end result is that the dkim
programmer calls "hash()" once and either "sign()" or "verify()" once. Suggest
adding a sentence along these lines to clear that up. If someone ever
calculated "sign(hash())" then they'd be wrong and this text sort of
suggests that. Similar comment about the pseudo-code at the end where
I'd rather see something like:

       body-hash = hash( canon_body )
       signature = sign( canon_header || DKIM-SIG )

#20, 3.7, 4th last para. This sort-of threw me a bit since it seems like an MUA
instruction. Is it? If so, then maybe move to the appendix/overview? This is
the one starting "When calculating the hash on messages..."

#21, 3.7, last para. "sans" is nice, but would it confuse non-franglish
speakers?

#22, 5.2, last para. Change "when the selector containing the corresponding
public key is expected to be removed before the verifier...", to, "when
the public key in the relevant selector is expected to be revoked before
the verifier..." since we're not recommending removing the selector but
rather zeroing out the key.

#23, 5.5, last 2 paras about "l=". I think this has all already been said, so
it could be removed from here.

#24, Section 6, 1st sentence says "may expire a public key" s/expire/revoke/
since dkim, (properly), doesn't do expiry, only revocation.

#25, 6.1, 1st note, "other clues" is a bit opaque - include a reference
to somewhere where the reader can find those clues or maybe reword.

#26, 6.1 "; this is local policy..." that "this" is a maybe a tad
ambiguous, suggest replacing with "; such treatment is a matter
for local policy..."

#27, 6.1.3, list item #1 says "create a canonicalised copy" which isn't
necessary - all you need to is feed the right bits through the hashing,
so an entire copy need never be created. Suggest rewording to say
"re-create the canonicalized octets" or something. (Or, add an informative
note along the above lines.)

#28, 6.2. The reference to ID-AUTH-RES might be better off being removed
for process reasons.

#29, 8.1.1. Missing the example.

#30, 8.2. This section mainly applies to MUA signing, which is not the
main use-case, and so the threat is less serious. Suggest saying that 
at the start of the section along with a sentence like: "Protection of
private keys on servers can be easily achieved though the use of 
specialised crytographic hardware."

#31, A.2, the example has no "bh=". Needs recalculating. And would be
better if the example inlcuded real signatures and the corresponding
public key record too.

#32, A.3, the authentication results header should not, IMO be included
here.

#33, Appendix B. I expected to see a bit here about the type of setup
we have at IETF meetings, where the IETF's MTA signs and the verifier
has to handle the From being nothing like the signer identity. 

#34, Appendix C. I think that this can be deleted. Others may disagree.
In any case, the text says 768 and the command line 1024, no 
password handling is shown and the last part could confuse since
that signature is not usable for DKIM. So if this isn't deleted, then
a bunch of changes are needed.


Total Nits
----------

#1 When the [[]] text disappears there'll be nothing between "introduction" and
"overview" - suggest getting rid of 1.1 and just having the text be the
introduction.

#2 1.1, 2nd set of bullets. The last point here would be better in the 1st set
of bullets.

#3 2.3, last sentence. Does the single abnf definition here offer value? If so,
then why not one for FWS too? Suggest deleting this.

#4 3.5, 3rd para: is "the null string" well enough defined? Maybe "an
empty string" would be better?

#5 3.5, last para before tags says: "Defined tags are described below."
which is sort of obvious. Suggest deleting it.

#6 3.6.1 "k=" says that the public key is in the "p=" value, but its
actually the modulus.

#7 3.6, 3rd last para s/string of characters/string of octets/

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html