I've gone through 4871bis-02 again to look for sections that don't deal
with correctness, robustness, or interoperability and have some suggested
changes. I also noticed a few editing nits on the way. None of this is
intended to be contentious, or to change any of the bits on the wire.
Overall: in several places such as the informative note at the top of
page 18, the language says that the verifer produces an edited
version of the message. We either should say that the edited message
is part of the verifier's output, probably in section 2.2, or delete
the editing language. I'd suggest the latter.
Page 11, informative operations note at the end of section 3.1: Either
change to "Signers SHOULD NOT reuse a selector with a new key" or
delete it.
Page 11, informative implementation note at the bottom of the page:
Delete it. If we want to support EAI, we should support EAI, but
this language just encourages code that won't interoperate.
Page 13: section 3.3: should it also say "Verifiers MUST implement
both sha1 and sha256"? It says so on page 20 in a= and page 30 in
h=, but I think this is a better place to put it.
Page 13, informative note at the bottom of the page: Delete. I realize
that people still use sha1, so we should document it, but is there any
reason to encourage it.
Page 14, sec 3.3.3, first paragraph. I don't understand what this pp
is telling me to do. In the second sentence, what does "for
long-lived keys" mean? A week? A decade? And what's the life of
the key? The time from when it's published in the DNS until it's
deleted? The time that signers use it, regardless of time in the
DNS? Suggest trimming this down to say signers MUST use at least
1024 bits, verifiers MUST handle 512 to 2048 bits, and leave it at
that. If we think a 512 bit signature is no good, we should say so.
Page 17, informative implementation note at the top: Delete message
editing language "or remove text that appears after the specified
content length, perhaps based on other criteria"
Page 17, second informative informative implementation note in the
middle: suggest deleting the whole thing. It's a recipe for disaster
which has not (I hope) ever been implemented. At least not on purpose.
Page 20, informative note under v=: Delete. Has a version number ever
increased other than arithmetically?
Page 22, discussion of d=: "Internationalized domain names MUST be
represented as A-labels as described in [RFC5891]"
Page 23, discussion of i=: "Internationalized domain names MUST be
represented as A-labels as described in [RFC5891]"
Page 24. first pp: delete "or MAY choose other means of representing
its users." An AUID need have no relationship to any user. Some of
my AUIDs refer to web scripts and mailing lists.
Page 24, informative note: suggest deleting, again because AUID need have
no relation to any user. Or perhaps rewrite as:
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional.
It can include the domain part without the Local-part of the
identity.
Page 24, informative discussion: delete everything after the second
sentence, since it doesn't help robustness or interoperability
Page 25, informative implementation warning: remove language at the
end of the paragraph suggesting that the verifier can remove text
from the body.
Page 27, x= first informative note: delete, doesn't help robustness or
interoperability. (Neither does x= but that's a lost battle.)
Page 28, z= last pp: it says that header fields " SHOULD be converted
as described in MIME Part Three [RFC2047]." That document describes
encoding of specific character sets such as ISO-8859-1. What
character set is it supposed to use?
Page 28, sec 3.6, second pp: delete, since in fact the only key server
we describe is the DNS. If some future document adds other key servers,
that would be an appropriate time to add language about them.
Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness
or interoperability.
Page 29, description of v=, last sentence: compare that to the note on
page 20 that I suggested deleting.
Page 29, description of g=: address -> AUID, in four places. The i=
value is an AUID, not an address.
Page 30, h=: suggest moving the language about which algorithms a verifier
supports to page 13 as suggested above.
Page 33, informative operational note: delete it, since the first
sentence is wrong, and the second sentence is out of scope.
Wildcards work just fine as key records if that's what you want to
do. For example, you could publish a wildcard with an empty p= to
make all unknown selectors be revoked.
Page 35, first pp, last sentence: delete it, or else get rid of l=
Page 35, sec 3.8: language about "on behalf of its subdomains" is
confusing since we now say the d= domain is the primary identity.
Suggest renaming this section to "Subdomains in AUIDs" and flip the
language around, e.g.:
In some circumstances, a domain may wish to apply a signature with
an AUID that is a subdomain of the SDID. By default, signatures can
contain an AUID that is any subdomain of the SDID. For example, if
a signature's SDID (the domain in the "d=" tag) is example.com, the
domain in the signature's AUID ("i=" tag of the signature) is
sub.example.com, or even sub1.sub2.example.com. In order to limit
the capability of such keys when this is not intended, the "s" flag
MAY be set in the "t=" tag of the key record, to constrain the
domain of the AUID. If the referenced key record contains the "s"
flag as part of the "t=" tag, the domain of the AUID ("i=" flag)
MUST be the same as that of the SDID (d=) domain. If this flag is
absent, the domain of the AUID MUST be the same as, or a subdomain
of, the SDID.
Top of page 36, first sentence. If we leave in the message editing
stuff, change to "Hence, DKIM's mandatory output to a receive-side
Identity Assessor is a single domain name and a possibly edited
version of the message that has been verified."
Page 36, informative discussion: delete it, since as far as I can tell
what it says is "we don't know what if anything an AUID will be used
for."
Page 38, pp starting "Signers SHOULD NOT": delete? Recent discussion
suggests that people don't follow this.
Page 39, first line: "failed" -> "invalid" to be consistent
Page 40, informative operations advice at the top: do we believe this
advice to keep a verification key around until the recipient reads
the message? I think in other discussions we've agreed that the key
should be valid for the maximum delivery time, not until someone
reads his mail which could be months.
Page 42, informative admonition: I don't understand what we're supposed
to do with this advice, which appears to be intended for the authors
of relay MTAs. Perhaps to make this operational, it should warn signers
that signing multiple fields makes it more likely that the signature
will break due to gratuitous reordering, as it says in sec 8.11.
Page 44, end of section 5.5: suggest changing that warning to "SHOULD
NOT specify a body length of zero, since this allows a hostile party
to replay the message with an entirely different body without
invalidating the signature."
Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather
than just "a verification header" ?
Page 46, informative implementation note: the previous pp just said not
to depend on signing order, and this note tells you how to guess what
the order was. Huh? Delete the note.
Page 46, pp after note: bad -> invalid, good -> valid, for consistency
Page 46, informative note: faulty -> invalid, for consistency
Page 47, first pp: why would a verifier make note of invalid
signatures? There's no subsequent step that uses them. Suggest
deleting that sentence unless we can explain what to do with them.
Page 47, 3rd pp: "should be performed" -> MUST be performed. This is
not optional.
Page 47, Sec 6.1.1, informative implementation note: delete it, since
an implementation can do whatever it wants. Does not help robustness
or interoperation.
Page 48, Sec 6.1.1, informational note: Delete second sentence, unless
we really think we're that bad at proofreading.
Page 49, item 4: does any implementation really cycle through multiple
key records? The one I use (Mail::DKIM) doesn't. Suggest limit of
one key record per selector with undefined results otherwise to improve
interoperability.
Page 51, informative implementation note: tells verifier to edit the message,
delete last two sentences.
Page 51, sec 6.2: more message editing, adding and deleting headers. There's
nothing wrong with recording results that way, but is the verifier the
right place to do it?
Page 52, second to last pp: more message editing, suggest deleting entire pp.
Why is the verifier paying any attention to unsigned header fields at all?
Page 62, sec 8.13: since we've agreed that the SDID rather than the
AUID is the primary identifier, how is this section useful? Suggest
deleting it.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html