That's a lot of nits. Comments below.
#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.
I guess I disagree with you on this one --- I think you're being a
bit over-sensitive. What's the difference between "minimal" and "no
extensive"? From a "sales-ish" point of view they seem equivalent to
me. I did change the "transparency" comment to "is compatible with
the existing email infrastructure and transparent to the fullest
extent possible" though.
#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.
Done.
#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;-).
Done.
#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.
So noted.
#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"
I've changed this to read:
<t>Selecting appropriate key sizes is a trade-off between
cost, performance and risk. Since short RSA keys more easily
succumb to off-line attacks, signers MUST use RSA keys of at
least 1024 bits for long-lived keys. Verifiers MUST be able
to validate signatures with keys ranging from 512 bits to
2048 bits, and they MAY be able to validate signatures with
larger keys. Security policies may use the length of the
signing key as one metric for determining whether a signature
is acceptable.</t>
<t>Factors that should influence the key size choice include:
<list
style="symbols">
<t>The practical constraint that a 2048 bit key is the
largest key that fits within a 512 byte DNS UDP response
packet</t>
<t>The security constraint that keys smaller than 1024 bits
are subject to brute force attacks.</t>
<t>Larger keys impose higher CPU costs to verify and sign
email</t>
<t>Keys can be replaced on a regular basis, thus their
lifetime can be relatively short</t>
<t>The security goals of this specification are modest
compared to typical goals of public-key systems</t>
</list>
</t>
#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.
Updated to "Unknown tags MUST be signed and verified but MUST be
otherwise ignored by verifiers."
#7 section 3.5 defines the 'c' tag as Body c14n, but it actually
specifies both c14n uses, so s/Body canon.../Canon.../
Changed to be "Message canon...".
#8 section 3.5, "d=" bit, introduces the "i=" tag without
explanation (its a forward reference). Suggest adding something in
brackets to explain
Done.
#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.
Intro now reads "Identity of the user or agent (e.g., a mailing list
manager) on behalf of which this message is signed (quoted-printable;
OPTIONAL, default is an empty local-part followed by an "@" followed
by the domain from the "d=" tag). The syntax is a standard email
address where the local-part MAY be omitted. The domain part of the
address MUST be the same as or a subdomain of the value of the "d="
tag."
I've added: "INFORMATIVE NOTE: The local-part of the "i=" tag is
optional because in some cases a signer may not be able to establish
a verified individual identity. In such cases, the signer may wish
to assert that although it is willing to go as far as signing for the
domain, it is unable or unwilling to commit to an individual user
name within their domain. It can do so by including the domain part
but not the local-part of the identity."
#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:-).
See above.
#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?
"No harm"? Downright important. Done.
#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.
Your definition of defensive is clearly different than mine. I think
your proposed wording is actually more defensive than the
matter-of-fact statement we had before. However, I've changed it
anyway.
#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.)
I didn't understand this point. In any case, the separate hashes has
been accepted. The whole section now reads:
<?xml version="1.0"?>
<ns:clipboard
xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboar
d"
><section
anchor="hashing"
title="Computing the Message Hashes"
><t
>Both signing and verifying message signatures starts with a
step of computing two cryptographic hash over the message.
Signers will choose the parameters of the signature as
described in <xref
target="signer-actions"
>Signer Actions</xref
>; verifiers will use the parameters specified in the
"DKIM-Signature" header field being verified. In the
following discussion, the names of the tags in the
"DKIM-Signature" header field which either exists (when
verifying) or will be created (when signing) are used. Note
that <xref
target="canonicalization"
>canonicalization</xref
> is only used to prepare the email for signing or verifying;
it does not affect the transmitted email in any way.</t
><t
>The signer or verifier must compute two hashes, one over the
body of the message and one over the header of the message.
Signers MUST compute them in the order shown. Verifiers MAY
compute them in any order convenient to the verifier,
provided that the result is semantically identical to the
semantics that would be the case had they been computed in
this order.</t
><t
>In hash step 1, the signer or verifier MUST hash the message
body, canonicalized using the header canonicalization
algorithm specified in the "c=" tag and truncated to the
length specified in the "l=" tag. That hash value is then
converted to base64 form and inserted into the "XXX=" tag of
the DKIM-Signature: header field.</t
><t
>In hash step 2, the signer or verifier MUST pass the
following to the hash algorithm in the indicated order.</t
><t
><list
style="numbers"
><t
>The header fields specified by the "h=" tag, in the order
specified in that tag, and canonicalized using the header
canonicalization algorithm specified in the "c=" tag.</t
><t
>A single CRLF.</t
><t
>The message body, canonicalized using the body
canonicalization algorithm specified in the "c=" tag, and
truncated to the length specified in the "l=" tag.</t
><t
>A single CRLF.</t
><t
>The "DKIM-Signature" header field that exists (verifying) or
will be inserted (signing) in the message, with the content
of the "b=" tag deleted (i.e., treated as the empty string),
canonicalized using the header canonicalization algorithm
specified in the "c=" tag, and without a trailing CRLF.</t
></list
></t
><t
>After the body is processed, a single CRLF followed by the
"DKIM-Signature" header field being created or verified is
presented to the algorithm.  The value portion of the
"b=" tag (that is, the portion after the "=" sign) must be
treated as though it were empty, and the header field must be
canonicalized according to the algorithm that is specified in
the "c=" tag.  Any final CRLF on the "DKIM-Signature"
header field MUST NOT be included in the signature
computation.</t
><t
>All tags and their values in the DKIM-Signature header field
are included in the cryptographic hash with the sole
exception of the value portion of the "b=" (signature) tag,
which MUST be treated as the null string. All tags MUST be
included even if they might not be understood by the
verifier. The header field MUST be presented to the hash
algorithm after the body of the message rather than with the
rest of the header fields and MUST be canonicalized as
specified in the "c=" (canonicalization) tag. The
DKIM-Signature header field MUST NOT be included in its own
h= tag.</t
><t
>When calculating the hash on messages that will be
transmitted using base64 or quoted-printable encoding,
signers MUST compute the hash after the encoding. Likewise,
the verifier MUST incorporate the values into the hash before
decoding the base64 or quoted-printable text. However, the
hash MUST be computed before transport level encodings such
as SMTP "dot-stuffing."</t
><t
>With the exception of the canonicalization procedure
described in <xref
target="canonicalization"
></xref
>, the DKIM signing process treats the body of messages as
simply a string of characters. DKIM messages MAY be either in
plain-text or in MIME format; no special treatment is
afforded to MIME content. Message attachments in MIME format
MUST be included in the content which is signed.</t
><figure
><preamble
>More formally, the algorithm for the signature is:</preamble
><artwork
> body-hash = hash-alg(canon_body)
header-hash = crypt-alg(hash-alg(canon_header ||
DKIM-SIG), key)</artwork
></figure
><t
>where crypt-alg is the encryption algorithm specified by the
"a=" tag, hash-alg is the hash algorithm specified by the
"a=" tag, canon_header and canon_body are the canonicalized
message header and body (respectively) as defined in <xref
target="canonicalization"
></xref
> (excluding the DKIM-Signature header field), and DKIM-SIG
is the canonicalized DKIM-Signature header field sans the
signature value itself, but with body-hash included as the
"bh=" tag.</t
></section
></ns:clipboard
>
#14 section 5.1 2nd para. I can't see much point in this - would
the spec be worse were this deleted?
I think this would diminish the spec. I think it's important to
point out that a DKIM-compliant signer doesn't have to sign messages
that it's not willing to take some responsibility for.
#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).
I've changed the first sentence to read "Signers MUST sign any header
fields that the signers wish to assert were present at the time of
signing" (although I'm not wild about this). The 2nd sentence
needn't be MUA-oriented at all; the verifier might be making
server-level spam decisions on the basis of various headers.
#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.
I don't understand this one either.
#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.
Yeah, but that wouldn't be a text form, it would be an XML form. I
could change it to read "otherwise unstructured text form" --- will
that do the trick? With that in mind, I now have "It is expected
that many key servers will choose to present the keys in an otherwise
unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose). The following
definition MUST be used for any DKIM key represented in an otherwise
unstructured textual form."
Of course, we could pull this out entirely and put it in another
document. But if we keep pulling things out of -base we'll have
nothing left.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html