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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html