On 10/21/2010 1:48 PM, Murray S. Kucherawy wrote:
draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871. RFC 5672 updates RFC
4871. Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures --
Update" document not being obsoleted by this document?
That sounds right to me.
+1
In the Introduction Section:
"DomainKeys Identified Mail (DKIM) permits a person, role, or organization
that owns the signing domain to claim some responsibility for a message by
associating the domain with the message."
Dave proposed a change to add a RFC 1034 reference in that sentence.
DomainKeys Identified Mail (DKIM) permits a person, role, or organization
that owns the signing domain to claim some responsibility for a message
[RFC5322] by associating the domain name [RFC1034] with the message.
I suggest adding a reference to RFC 5322 in there to make it clear what
"message" is.
I forget; does the email architecture document talk about the difference
between a DNS domain and an ADMD? This was an issue during the IESG
Well, it /defines/ ADMD (eg, Section 2.3) and merely uses dns domain names
(section 3.3). It does not compare or contrast the two uses of the word
'domain'. ADMD has a bit of extra verbiage to make it substantially different
from DNS domain. It still has the word domain because folks seemed to want to
use it, rather tenaciously.
evaluation of Authentication-Results and I seem to recall it being a place to
which readers could be referred to learn the difference. Maybe changing
"domain" to "DNS domain" would be appropriate, and also changing the RFC1034
reference to point at RFC5598?
Couldn't hurt.
As I mentioned previously, in Section 3.3:
"In general, sha256 should always be used whenever possible."
That text was in RFC 4871 too as part of the informative note. Could it be
removed to avoid any dilution of the SHOULD in the "Signers MUST implement
and SHOULD sign using rsa-sha256" sentence?
The OpenDKIM stats shows that SHA1 is still in very widespread use,
After the latest round about SHA1, I believe where we landed is to keep the
relevant text in the spec as is. No changes.
"The practical constraint that large (e.g., 4096 bit) keys may not fit
within a 512-byte DNS UDP response packet"
Could a normative reference to RFC 1035 be added in that sentence?
It's now in the pending -03 version.
The practical constraint that large (e.g., 4096 bit) keys may not fit
within a 512-byte DNS UDP response packet [RFC1035]
Seems reasonable to me, though I don't think it needs to be normative since
that text is discussion rather than protocol specification.
Sorry. I'm not understanding what text to add, or where.
I'll mention it again; in Section 3.5 for the d= tag:
"Internationalized domain names MUST be encoded as described in
[RFC3490]."
And i= tag:
"Internationalized domain names MUST be converted using the steps listed in
Section 4 of [RFC3490] using the "ToASCII" function."
Is there a reason why this working group requires that a document with an
intended status of "Draft Standard" should have a normative reference to a
RFC that has been obsoleted?
I can't remember the disposition of this, but I think the problem is that we
want to use ToASCII while no current (i.e. not obsolete) document contains a
definition of it. I seem to recall one of the other co-authors looking into
it and finding this was acceptable, but I don't recall. Dave, can you
comment?
We've had no call to change that aspect of the specification. While the formal
status of the cited document (that defines toAscii) might have changed, the
algorithm has not been a problem for DKIM and still works, and the cited
document is still accessible.
My concern is that shifting the reference to the newer document also requires
changing the DKIM technical specification and that that will require recycling
at Proposed, for merely bureaucratic reasons rather than from any technical
need.
"Therefore, a verifier SHOULD NOT validate a message that is not
conformant."
That sounds like good advice.
Given the mathematics of a signature, I believe the formal RFC 5322 conformance
of the message is actually irrelevant to DKIM.
It's highly relevant to other processing engines, but not DKIM.
In other words, if a DKIM signature validates, it validates. That's the /only/
test or assurance that is needed.
According to draft-ietf-dkim-implementation-report-03, the interoperability
and testing event was held in 2007. Was the above requirement tested
during that event? If this working group wants to add such a requirement,
I suggest setting the intended status of draft-ietf-dkim-rfc4871bis to
"Proposed Standard".
I don't recall it being tested specifically. And I don't have a good sense
about whether the addition of this normative requirement would require a
recycle or not. I defer to those more experienced than me.
I believe it was not explicitly (or probably even implicitly) text. I'll
repeat
that I think it is actually irrelevant.
In Section 5.5:
"Verifiers MUST be capable of verifying signatures even if one or more of
the recommended header fields is not signed (with the exception of From,
which must always be signed)"
Is the last "must" a requirement?
No, I think it's simply an informative back-reference to another specified
requirement. Maybe changing "must always" to "always has to" would clear
that up.
On reflection, I am going to suggest some slightly different wording:
Except for the requirement to have a signature cover the From header field,
the list of header fields that determines signature validity is determined only
by the list in the h= parameter.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html