Last Call Review of draft-ietf-dkim-rfc4871-errata-
review-ietf-dkim-rfc4871-errata-secdir-lc-yu-2009-05-24-00
Request | Review of | draft-ietf-dkim-rfc4871-errata |
---|---|---|
Requested revision | No specific revision (document currently at 07) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2009-05-08 | |
Requested | 2009-04-24 | |
Authors | Dave Crocker | |
I-D last updated | 2009-05-24 | |
Completed reviews |
Secdir Last Call review of -??
by Taylor Yu
|
|
Assignment | Reviewer | Taylor Yu |
State | Completed | |
Request | Last Call review on draft-ietf-dkim-rfc4871-errata by Security Area Directorate Assigned | |
Completed | 2009-05-24 |
review-ietf-dkim-rfc4871-errata-secdir-lc-yu-2009-05-24-00
This document updates the DKIM specification to clarify the roles of two DKIM identifier tag values that a consumer of DKIM verification may use. The Security Considerations section states that the clarifications in this document should improve the security characteristics of the protocol. I find this statement to be reasonably accurate. Section 12, which adds a new Section 3.9 to RFC 4871, contains a number of statements giving guidance about assessor policy. A summary of these statements, along with a pointer to the full text, should probably appear in an amendment to the RFC 4871 Security Considerations. The following are editorial comments. In Section 1, delete the spurious "and" following "specifies". old: This update resolves this confusion. It defines new labels for the two values, clarifies their nature, and specifies and their relationship. new: This update resolves this confusion. It defines new labels for the two values, clarifies their nature, and specifies their relationship. In Section 8, the text: The name of the module that consumes DKIM's mandatory payload, the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However this additional activity is outside the scope of the DKIM signature specification. might be better written as: A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification. in order to align with the form of other definitions added in this document. In Sections 9 and 10, the ABNF in the new text looks misformatted. In Section 10, the sentence: However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a finer grained, stable identifier than the SDID. might be better written as: However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID.