At 05:53 04-10-10, Barry Leiba wrote: >Thus begins working group last call on the DKIM-base update, >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 n...@news-site.com <j...@example.com>. (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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html