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.
I don't see anything on page 11 about EAI, nor any informative notes.
Oops, that's page 12, the note about UTF-8 at the bottom.
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"
Agree. (Though I see that on page 18)
Right, it's p.18. (It was pretty late, one number starts to look a lot
like another.)
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.
Actually I think that whole sentence is redundant to the earlier text of the
paragraph.
OK with me.
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.
Since there are a lot of reasons one might wish to leave out the
local-part (don't know, don't want to say, don't feel like it), I'm
fine with being this simplistic. Maybe what you have, but tack onto
the end "if the signer is unable or unwilling to specify a value
there"?
Sure.
Page 24, informative discussion: delete everything after the second
sentence, since it doesn't help robustness or interoperability
I could live with it being out, but I like it in there if only to document our
deliberations so others later won't have spend the energy to go down the same
path.
Hmmn. Do we want to say "DKIM doesn't identify individual users so
don't try to make it do that?" If so, it's probably better to put
somewhere closer to the top.
Page 27, x= first informative note: delete, doesn't help robustness or
interoperability. (Neither does x= but that's a lost battle.)
I'm not even sure I understand that remark. Can someone remind us of
what it's trying to say?
We had long arguments in which some people argued that one could keep
bad guys from replaying messages by making the x= time short enough.
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?
Interesting. I suppose it should be just basic DKIM-quoted-printable
conversion, meaning this whole paragraph can go except perhaps to
indicate that even eight-bit data can be thus represented.
This is one of those places where I don't know how much we can change
without the IESG deciding to recycle. Just saying to use QP isn't
adequate, since then you couldn't tell whether =BD is the 1/2 symbol
in 8859-1, the oe ligature in 8859-15, or those three characters. My
inclination is just to take it out, since at this point the 5322 rules
say that any non-ASCII should already be MIME-encoded in the headers
that z= copies so there shouldn't be anything to downcode.
Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness
or interoperability.
I had to think about this one for a while. Would it even be
appropriate to describe this as the DNS Text Representation, rather
than just Text Representation? We might do it a different way in
HTTP without XML, for example.
There was a bunch of quite hypothetical discussion of other ways to
represent and serve keys, none of which ever amounted to anything.
That's why I'd rather wait until there actually are other kinds of
keys before describing what they are.
Page 29, description of v=, last sentence: compare that to the note on
page 20 that I suggested deleting.
Not sure what you're saying here; did you want that last sentence out?
It's saying that if, 1.0 != 1, so much for increasing arithmetically.
This language is fine. (My preferred order is 5, 2, 8, 9, 4, 7, 6, 3,
1, 0, which is of course alphabetical order in French.)
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."
I don't like the edited version stuff. I'd prefer it to be positioned as an
explicit
indication of what fields and portion of the body were signed.
If we agree that's an explicit output, that'd be a rather large change
to the spec. My DKIM verifier Mail::DKIM just says yes or no, perhaps
with a note about whether failure was DNS related or one of the hashes
not matching.
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."
I'd rather say that explicitly, even if more concisely. It's better to say
that than
say nothing and leave them wondering why we didn't say anything about it.
OK.
Page 39, first line: "failed" -> "invalid" to be consistent
Actually I find that sentence structure weird. How about:
Verifiers SHOULD treat invalid signatures as though they were not
present in the message.
OK.
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.
What's "the maximum delivery time"? Are you talking about "x="? (I suspect
not...)
RFC5321 recommends "at least 4-5 days" as the time to keep retrying a delivery
before giving up. That's what I had in mind.
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.
Within context, I take it to be a warning against signing trace header fields
like
Received. But I agree that its presentation is a little ambiguous.
We give that advice in other places, so we can probably do without it here.
Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather
than just "a verification header" ?
I think the idea is that RFC5451 is one example of an annotation system, so "a
verification header field such as the one described in RFC5451" would probably
be fine.
OK.
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.
Ours barks if more than one TXT comes back without checking any of them. That
said,
what about saying "MUST process one, MAY process the rest or MAY return an
error if the
first one was no good"?
Unless someone has an implementation that does something with multiple
TXT records, I'd prefer to change the text to match the code.
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.
Hmm. The AUID isn't primary, but that doesn't mean there aren't possibly
interesting
semantics there, especially since we're not talking about the local-part.
Since it's
informative, I don't see that it steers anyone wrong to leave it in there,
again
relying on my earlier feeling that I'd rather opt to relay some non-normative
discussion than nothing so that later people aren't wondering why we weren't
totally
silent on the matter.
There was a long argument here, too. One side argued that subdomains
are entirely at the mercy of parent domains since that's how
delegation works, the other argued that there are cut points like
gTLDs where the parent is different from the subdomain, although they
admitted there is no reliable way to tell where those cut points are,
nor exactly what the problem was. (You can probably tell which side I
was on.)
Thanks for the fine-toothed comb!
You're quite welcome.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html