Subject: [ietf-dkim] Working group last call on draft-ietf-dkim-rfc4871bis

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Oct 2010 08:53:07 -0400

Thus begins working group last call on the DKIM-base update,
draft-ietf-dkim-rfc4871bis-01:
   http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis
The working group last call will run through Friday, 22 October, 2010.

This is the version of the specification that will be advanced to
Draft Standard.  Everyone please review it, and post comments/issues.
Please also post here if you've reviewed it and think it's ready to
go.

There is one outstanding discussion on the -01 version:
   http://mipassoc.org/pipermail/ietf-dkim/2010q4/014608.html
Please comment specifically on that, stating whether you agree with
the proposed change or prefer leaving the text as it is.  Remember
that a change will NOT be made without support, so if you like the
change it's important to say so.

Because this is moving the existing specification along the standards
track, substantive changes are explicitly out of scope unless someone
uncovers a serious error in the protocol.  In scope are clarifications
and editorial issues.

So: everyone please review draft-ietf-dkim-rfc4871bis-01, and comment
here by 22 October.  Thanks.

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

---

From: SM <[email-masked]>
Date: Wed, 06 Oct 2010 01:26:08 -0700

>draft-ietf-dkim-rfc4871bis-01:

The document should obsolete both RFC 4871 and RFC 5672.

Please update the RFC 2821 and RFC 2822 references to RFC 5321 and 
RFC 5322 respectively.

The reference for OpenPGP should be RFC 4880.

The reference for RFC 4234 should be changed to RFC 5234.

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?

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."

I suggest updating the first reference to RFC 5890 and RFC 5891.  The 
second reference could be replaced by RFC 5891.  I would have been 
more comfortable with a review for Internationalization 
considerations.  That would expand the scope of the work to move RFC 
4871 to Draft Standard though.

In Section 3.6:

   's= Service Type (plain-text; OPTIONAL; default is "*").'

Are the SIP folks using this? :-)

Section 3.6.1.1 is about compatibility with DomainKeys.  Can that 
section be removed?

In Section 7, please change the reference to RFC 5226.  The initial 
entries in the registries come from RFC 4871.  I suggest asking IANA 
to update the registries to point to this document.

There might be a nit about the "example.podunk.ca.us" example in Section 8.13.

Please update the OpenPGP reference in Section 8.4.  Please use RFC 
5751 as a reference for S/MIME.

RFC 5451 should be a normative reference because of Section 6.2.

The "X-Authentication-Results" header in Appendix A.3 should be 
changed.  I suggest changing the 192.168.1.1 IPv4 address to 
198.51.100.1. BTW, are the spaces necessary for the "h=" tags in the examples?

In Appendix B.1.3:

   "If neither of these are possible, these roaming users will not be
    able to send mail signed using their own domain key."

I suggest a minor change:

    If neither of these are possible, these roaming users will not be
    able to send mail signed using a signing identity associated with
    their domain.

In Section B.1.4:

   "Receiving sites often wish to provide their end users with
    information about mail that is mediated in this fashion.  Although
    the real efficacy of different approaches is a subject for human
    factors usability research, one technique that is used is for the
    verifying system to rewrite the From header field, to indicate the
    address that was verified.  For example: From: John Doe via
    [email-masked] <[email-masked]>.  (Note that such rewriting
    will break a signature, unless it is done after the verification pass
    is complete.)"

I suggest removing that paragraph.  Section 6.2 mentions how results 
of verification can be communicated.

I suggest removing Appendix B.2.3 if the working group is of the 
opinion that it can produce an informational document about mailing 
list considerations.

"signatures inside parts" should not be processed.

Is it ludicrous to believe that one of the participants in this 
working group is the president of an unnamed country?  If it is the 
opinion of this working group that such participation may harm the 
unnamed country, I suggest adding text to the Security Considerations 
section about messages that are not RFC 5322 compliant.

On an unrelated note, unconfirmed figures slate global DKIM 
deployment at 19.3% and usage within the IETF at around 6.8%.

Regards,
-sm

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Oct 2010 10:39:19 -0700

The diffs at http://dkim.org/specs/rfc4871-to-bis-diff.htm and the 
differences between 4871 and the -00 version of the draft, not the Last 
Call revision.

Dave Crocker, can you update the diffs please?

-Jim