ietf-dkim
[Top] [All Lists]

[ietf-dkim] AD review comments for draft-ietf-dkim-overview-10

2009-02-27 03:35:08
Tony, Dave, Phillip and others,

I've finally gone through dkim-overview-10. Basically, it looks good,
but I have some suggestions on how to make it more accessible to
readers who don't already know what DKIM is, plus some minor nits:

- I think introducing clear terminology for the identity/identities (or
identifier/identifiers) "output by DKIM" would make DKIM significantly
easier to understand, and would be useful in this document, too.
Places that probably would get easier to understand with this
terminology include at leastSections 1.1, 2, 2.1, 2.2, 3.1.1, 3.1.4,
4.1, 4.3, 4.5, and 5.

- Section 1.1: should the "By itself, a DKIM signature.." list also
include something like "Does not necessarily authenticate the
message's author"? (that might help understanding DKIM's role)

- Section 1.2, one possible way to contrast DKIM vs. the other
signature standards might be that DKIM adds a new identifier to the
message (SDID/UAID) that is authenticated, while the other standards
have usually focused on authenticating the author/origin of message
(using an identifier already present in the message, like "From:")

- Section 1.2, the text about the history of mail signature standards
looks a bit strange to me. The text about PGP probably should be a
bulleted item, not ordinary paragraph. And "later version was
standardized as OpenPGP" probably referes to PGP, not MOSS?

- Section 2.3, perhaps "...has not been modified" should be clarified
to "...has not been modified after it was signed. However, DKIM cannot
tell whether the message was modified after it was submitted by the
Author but before being signed" or something? (perhaps obvious to a
reader who wants to compare DKIM and SPF/SenderID, but less obvious to
someone whose starting point is S/MIME or OpenPGP)

- Section 3, "end-to-end authentication" might make sense to a reader
whose prior knowledge is about SPF/SenderID, but makes less sense to
someone whose background is S/MIME or OpenPGP (which are usually much
more end-to-end than DKIM). Perhaps this could be rephrased as "DKIM
adds an authentication capability to the existing email transfer
infrastructure that is independent of SMTP connections (i.e. not
hop-by-hop)" or something?

- Section 5: Figure 1 shows that signing practices are not applied if
the DKIM signature is valid. That's not the case for ADSP -- it's
still relevant for valid DKIM signatures that are not Author
Signatures.

- From idnits:
== Unused Reference: 'I-D.kucherawy-sender-auth-header' is defined on line
   814, but no explicit reference was found in the text
== Unused Reference: 'RFC2821' is defined on line 840, but no explicit
   reference was found in the text
== Unused Reference: 'RFC3164' is defined on line 849, but no explicit
   reference was found in the text
== Unused Reference: 'RFC4870' is defined on line 869, but no explicit
   reference was found in the text

- I think mentioning 4870 and sender-auth-header somewhere in this
document would be useful.

Could you take the first shot in proposing concrete edits, with
the goal of getting a revised ID submitted before the cut-off date?
(Although the terminology part has a dependency to errata-02)

Best regards,
Pasi

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>