> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Jim Fenton > Sent: Monday, March 28, 2011 2:27 PM > To: IETF DKIM WG; Dave Crocker > Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04 > > > 0. Can you clarify what it is about the definition that is not clear? > > (Any guidance at all will help for understanding the nature of what > > needs fixing.) The initial text is the definition and it's simplicity > > makes it difficult to guess what the problem is. > > > > 1. "authors and their organizations" could be misinterpreted to mean > > that the conjunction defines a single identity. > > But the current text says "...examples include the author, ..." so that > misinterpretation exists there as well. I'd be fine with just "authors' > organizations".
Since it's in definitions for "Identity" in general, and the "i=" could conceivably identify a specific author, is this a correct change to make? It doesn't seem to be talking specifically about "d=". > > 3. One form of assessment service -- of which the late Goodmail was an > > example > > -- can give a priori assessment and then indicate tghe assessment by > > providing the signature to the message before it is sent. That is, > > the authoring organization passes the message to the assessment > > service and the assessment service hands back the signature to be > > included in the message. (The details can vary, of course, but this > > describes the basic model.) Hence the signature is somewhat akin to a > > capability token. [I thought I had explained this processing option a > > number of times over the years, specifically citing the Goodmail > > example.] > > That's a specific example of an ISP along the handling path. The > potential for misinterpretation of this is greater than the benefit of > explaining this potential usage scenario, especially since "assessment" > has a very specific definition in the DKIM context. I think I'll let Dave reply to this one, since I lack the context. > >> Section 2.9, Common ABNF tokens: Two new tokens are defined based on > >> field-name and dkim-quoted-printable. But where are field-name and > >> dkim-quoted-printable defined? > > > > field-name is defined in Section 2.10 > > > > DKIM-Quoted-Printable is defined in Section 2.11 > > Would it be beneficial to rearrange the sections to avoid the forward > reference? OK by me. I'll swap the "Imported" and "Common" sections. > Section 3.2, paragraph 2: dkim-quoted-printable is now defined in > section 2.11, not 2.6. Fixed. > >> 6.3 paragraph 5 has changed "signing identity" to SDID. The signing > >> identity > >> really corresponds to the AUID. > > > > That has not been correct for any version of rfc4871bis. The term > > Signing Identity has no normative value and is now only used in the > > introductory text. > > > > Also note that the Update removed any meaningful semantics for AUID: > > > > The AUID comprises a domain name and an optional > > <Local-part>. The domain name is the same as that used for the > > SDID or is a sub-domain of it. For DKIM processing, the domain > > name portion of the AUID has only basic domain name semantics; any > > possible owner-specific semantics are outside the scope of DKIM. > > > > In fact, the AUID is not part of DKIM's formal output. So the formal > > specification cannot then direct it be supplied to the assessment engine. > > Nevertheless, suppose a message with From address > <[email protected]> was properly signed with > i=marketing.example.com and d=example.com. What the text is telling us > is that the mail system SHOULD take pains to ensure that example.com is > visible to the user. This is counter to all of the text in the DKIM > specification that permits keys for a subdomain to be managed in a > parent domain. If these is consensus to eliminate signing for > subdomains, there is a lot of other stuff that needs to be removed from > the spec, including the i= tag itself, the "s" flag in the key record, > the text in section 3.9, and the security consideration in section > 8.13. > > The Update removed semantics associated with the local part of the AUID, > and not the domain-part. > > If there is not consensus to remove subdomain signing, the wording > described here makes it meaningless. This goes to the heart of why I > have been arguing that the output of DKIM should be the AUID (or its > default value, which is the SDID), and not the SDID itself. Again I think Dave is the better one to reply as he has the context for the debate, but I suggest that the SDID is the only thing that is completely vetted by DKIM, because the AUID doesn't necessarily correspond to anything real (other than the substring matching the SDID). An implementation that wants to cater to a DKIM consumer which wants the AUID is free to do so, and Paragraph 5 of Section 6.3 doesn't proscribe such an action (in fact, OpenDKIM has mechanisms to provide either). It's simply describing a minimal compliant implementation. > C.2. Compatibility with DomainKeys Key Records > [...] Replaced my text with yours. -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
