[ietf-dkim] editorials and nits

[Jim Fenton]

Eric Allman wrote:
>> #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.
>
> Given the sensitivity over the exact wording of the abstract, I'm not
> willing to make this change without discussion of some proposed wording.
Given that the abstract is the only place in the document where the term
"repudiation" appears and virtually the only place where the term
"proof" appears, I think that the terms don't belong here.  Suggest
changing the wording of the last sentence of the abstract to the following:

Protection of email identity may assist in the global control of "spam"
and "phishing".

>
>> #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.
>
> I would like some discussion on this.  This might be more technically
> accurate for a cryto expert, but I know that if I as a non-crypto guy
> read this, I would immediately ask myself "now, is that the same as
> the key length or something else altogether?"
I prefer the current "colloquial" usage.  The difference in security
involved depending on whether the modulus is included or not is
inconsequential.
>
>> #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.
>
> Actually, in our early discussion over this we actually did mean that
> the verifier can simply ignore the tag, and yes, it won't verify. Some
> people deemed that to be a feature, not a bug.
If the verifier doesn't like the l= tag, they should just reject the
signature, rather than bother doing the math to verify it.

Perhaps we need to more globally describe what we mean by "ignore the
tag", since paragraph 9 of section 3.2 says, "Unrecognized tags MUST be
ignored."  In that case, what we want to say is that the verifier MUST
not take action on the tag, but MUST include it in the hash calculation
for this DKIM-Signature header field.  Do we need to spell this out?

-Jim