[ietf-dkim] Draft minutes...

[Eric Allman]

A few comments on my action items:

1308 (language recommending use of t=s): In the description of the 
t=s flag, I've added "Use of this flag is RECOMMENDED unless 
subdomaining is required."

DNS discussion: There's a note from Olafur suggesting that the 
document add "do not use wildcards."  I'm not completely clear where 
this belongs: it can't be for _domainkey.*.example.com, so perhaps 
this means for *._domainkey.example.com?  Or is this about policy?

1316 #1 (define plain-text): It turns out it's already defined for 
tag=value lists (which is what matters for us) in the ABNF for 
VALCHAR.  I've added "INFORMATIVE IMPLEMENTATION NOTE: Although the 
"plain text" defined below only includes 7-bit characters, an 
implementation that wished to anticipate future standards would be 
advised to not preclude the use of UTF8-encoded text in tag=value 
lists."

1316 #22 (guidance on limiting trace headers): Section 5.4 now 
includes the text "Signers choosing to sign an existing header field 
that occurs more than once in the message (such as Received) MUST 
sign the physically last instance of that header field in the header 
block. Signers wishing to sign multiple instances of such a header 
field MUST include the header field name multiple times in the h= tag 
of the DKIM-Signature header field, and MUST sign such header fields 
in order from the bottom of the header field block to the top. The 
signer MAY include more instances of a header field name in h= than 
there are actual corresponding header fields to indicate that 
additional header fields of that name SHOULD NOT be added."

1317 #33 (use cases for 3rd party MTAs --- the notes have this listed 
as #30-#34, but I believe that is incorrect): I have added Appendix 
B.7 reading (sorry for the XML):

        <section
        title="SMTP Servers for Roaming Users"
        ><t
        >Roaming users may find themselves in circumstances where it
        is convenient or necessary to use an SMTP server other than
        their home server; examples are IETF conferences and many
        hotels.  In such circumstances the signature, if any, will be
        added by a party other than the user's home system.</t
        ><t
        >Ideally roaming users would connect back to their home
        server using either a VPN or a SUBMISSION server running with
        SMTP AUTHentication on port 587.  If the signing can be
        performed on the roaming user's laptop then they can sign
        before submission, although the risk of further modification
        may be high.  If neither of these are possible, these roaming
        users will not be able to send mail signed using their own
        domain key.</t
        ></section
        >

Not explicitly listed in the notes:

Section 5.4 (Determine the header fields to sign) now has the 
following language (again, sorry for the XML):

        The From header field MUST be signed (that is, included in
        the h= tag of the resulting DKIM-Signature header field); any
        header field defined as an Originator Field in <xref
        target="RFC2822"
        ></xref
        > section 3.6.2, Resent-From, and Resent-Sender MUST also be
        included. The signed header fields SHOULD also include the
        Subject and Date header fields as well as all MIME header
        fields. Signers SHOULD NOT sign an existing header field
        likely to be legitimately modified or removed in transit. In
        particular, <xref
        target="RFC2821"
        ></xref
        > explicitly permits modification or removal of the
        "Return-Path" header field in transit. Signers MAY include
        any other header fields present at the time of signing at the
        discretion of the signer.<list
        style="empty"
        ><t
        >INFORMATIVE OPERATIONS NOTE: The choice of which header
        fields to sign is non-obvious. One strategy is to sign all
        existing, non-repeatable header fields. An alternative
        strategy is to sign only header fields that are likely to be
        displayed to or otherwise be likely to affect the processing
        of the message at the receiver. A third strategy is to sign
        only "well known" headers. Note that verifiers may treat
        unsigned header fields with extreme skepticism, including
        refusing to display them to the end user.</t
        ></list
        >

eric