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
news(_at_)news-site(_dot_)com <jdoe(_at_)example(_dot_)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