DomainKeys Identified Mail (DKIM) Service Overview
RFC 5585

Note: This ballot was opened for revision 12 and is now closed.

(Jari Arkko) Yes

Comment (2009-05-21 for -)
No email
send info
I want to discuss this on the call:

> Mail that is
> not signed by DKIM is handled in the same way as it was before DKIM
> was defined.

Isn't this a contradiction to what the signing practices model does?
That is, if the signing practices claim that all mail is signed
by DKIM, and this particular message has no DKIM signature, aren't
we throwing the message away?


>    service as its key server technology.  [RFC4871] It permits

Odd use of the reference. Which sentence does the reference belong

(Pasi Eronen) Yes

(Alexey Melnikov) Yes

Comment (2009-05-16 for -)
No email
send info
1.  Introduction


   DKIM allows an organization to take responsibility for a message, in
   a way that can be verified by a recipient.  The organization can be a
   direct handler of the message, such as the author's, the originating
   sending site's or an intermediary's along the transit path.  However
   it can also be and indirect handler, such as an independent service
   that is providing assistance to a direct handler.  DKIM defines a
   domain-level digital signature authentication framework for email
   through the use of public-key cryptography and using the domain name
   service as its key server technology.  [RFC4871] It permits

I think the reference is meant to be before the dot.

   verification of the signer of a message, as well as the integrity of
   its contents.  DKIM will also provide a mechanism that permits
   potential email signers to publish information about their email
   signing practices; this will permit email receivers to make
   additional assessments of unsigned messages.  DKIM's authentication
   of email identity can assist in the global control of "spam" and

1.2.  Prior Work


   There have been four previous IETF Internet Mail signature standards.
   Their goals have differed from those of DKIM.  The first two are only
   of historical interest.

Actually, I think the 2nd and the 3rd are of historical interest.
I.e. OpenPGP is still in use.

   o  Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
      first released in 1991.  A later version was standardized as
      OpenPGP.  [RFC2440] [RFC3156] [RFC4880]

   o  Privacy Enhanced Mail (PEM) was first published in 1987.

   o  PEM eventually transformed into MIME Object Security Services
      (MOSS) in 1995.  [RFC1848] [RFC1991]

RFC 1991 is "PGP Message Exchange Formats". Is it the correct reference here?

   o  RSA Security independently developed Secure MIME (S/MIME) to
      transport a PKCS #7 data object.  It was standardized as [RFC3851]

2.2.  Enabling Trust Assessments


   In order to formulate reputation information, an accurate, stable
   identifier is needed.  Otherwise, the information might not pertain
   to the identified organization's own actions.  When using an IP
   Address, accuracy is based on the belief that the underlying Internet
   infrastructure supplies an accurate address.  When using domain based
   reputation data, some other form of verification is needed, since it
   is not supplied independently by the infrastructure

Missing dot.

3.1.1.  Use Domain-level granularity for assurance


   Contrast this with OpenPGP and S/MIME, which associate verification
   with individual authors, using their using full email addresses.

I think the second "using" should be deleted from this sentence.

3.1.4.  Distinguish the core authentication mechanism from its
        derivative uses

   An authenticated identity can be subject to a variety of assessment
   policies, either ad hoc or standardized.  DKIM separates basic
   authentication from assessment.  The only semantics inherent to a
   DKIM signature is that the signer is asserting some kind of
   responsibility for the message.  Any interpretation of this kind of
   responsibility is the job of services building on DKIM, but the
   details are beyond the scope of that core.  One such mechanism might
   assert a relationship between the SDID and the author, as specified
   in the From: header field's domain identity.[RFC5322] Another might

I think "[RFC5322]" should be before the dot.

   specify how to treat an unsigned message with that From: field

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Adrian Farrel) No Objection

Comment (2009-05-21 for -)
No email
send info
In section 1.4.1 you have "(per Allman)". Presume this is a reference to RFC 4871 and so changning to "[RFC4871]" would be nice. but if it is a reference to something else, perhaps you could iclude it.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Tim Polk) No Objection

Comment (2009-05-21 for -)
No email
send info
In Figure 1, the flow from the "Assessments" box is non-deterministic; it appears the next step could be "Check Signing Practices" or "Message Filtering Engine".  The supporting text in Section 5.5 did not clarify the situation.

I would suggest labeling the diagram or adding explanatory text in 5.5.

(Dan Romascanu) No Objection