Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On Mar 30, 2011, at 11:49 PM, Jim Fenton wrote: . Goodmail .. . . V V Client - Mail - Transfer - Service - Receiver - Recipient Goodmail interacted with the creator of the document and, separately, with the receiving mail service, as an adjunct back office service. To repeat: /It was not in the direct handling path./ DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that configuration in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. This still seems to me to be too specialized a use case to list in the specification, but would look to WG consensus on which way to go here. I agree. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
With the output of DKIM being the SDID, the identity associated with the signature is of course that of the domain. But when my author-specific domain signs a message for me, it's the domain that does that -- it doesn't matter that it's an organization of one. Putting author here just hints that authors might sign messages as well, and I don't think that's intended. I suggest removing author to make that clear. The author can be an organization. For mail from ESPs, I'd say that the author is almost always an organization. Please leave the language alone. DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that configuration in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. This still seems to me to be too specialized a use case to list in the specification, but would look to WG consensus on which way to go here. I can easily see applications in universities, where the central IT group often has only a tenuous hold over the departments who jealously guard their autonomy, often well past any point of rationality. A department wouldn't dream of sending their mail through the servers run by those bureaucratic morons in central IT, but would be OK with a remote signer where the mail stays on their computers. The point is that the choice of i= had determined whether something ought to be flagged to the recipient. Now it doesn't. That is a behavioral change that is potentially incompatible with the RFC 4871 behavior. Flagged to the recipient is UI design advice, which I think we've agreed we're not doing. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID. I suggest that the first sentence change MAY to might in order to make it non-normative. I really don't think changing MAY to might here is going to make things any clearer for implementers. Much the opposite. Agree. Let's leave it alone. (radical idea alert) The point is that if the AUID does not affect the result of the verification at all, why even have it? In my case, it's a comment that helps me figure out what happened when someone sends back a message with a complaint. I would be quite happy to change i= to be a private comment for the benefit of the signer and remove any syntactic restrictions on it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On 3/31/2011 5:49 AM, Jim Fenton wrote: On 3/29/11 4:53 AM, Dave CROCKER wrote: Just to be clear: A domain name is capable of being author-specific. I recognize that it's not typical, but the construct of 'author' is so fundamental in this game, it's worth acknowledging that it is (still) permitted. With the output of DKIM being the SDID, the identity associated with the signature is of course that of the domain. But when my author-specific domain signs a message for me, it's the domain that does that -- it doesn't matter that it's an organization of one. This confuses the actor with the identifier for the actor. The domain does not do signing. The actor does the signing. They use the domain name as an identifier. The actor might be an author, identifying themself (themselves?) or the actor might be an organization. In other words, the semantics and the activity are as I described. Putting author here just hints that authors might sign messages as well, and I don't think that's intended. I suggest removing author to make that clear. It is not meant to hint at that. It is meant to call it out explicitly. There are configurations for using DKIM that are not in the main line of thinking but are nonetheless entirely reasonable and legal to explore using and could be quite constructive to employ. Text that introduces or otherwise describes a mechanism's capabilities should be careful to give a good sense of the range, rather than directing everyone only to the most common case, or rather the most common case that is expect. Besides helping to educate readers, this reminds folks who later seek to modify the spec that they need to be careful not to (unintentionally) impose restrictions that eliminate these previously-legal scenarios. Please note that this exchange is about non-normative, pedagogical text. . Goodmail .. . . V V Client - Mail - Transfer - Service - Receiver - Recipient Goodmail interacted with the creator of the document and, separately, with the receiving mail service, as an adjunct back office service. To repeat: /It was not in the direct handling path./ DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that configuration in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. This still seems to me to be too specialized a use case to list in the specification, but would look to WG consensus on which way to go here. Indeed, working group consensus controls wg choice. 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 we've just seen a good example that indeed it is easily misunderstood. That begs explicit reference, not potentially confusing conflation. Can you offer alternate text that avoids the overloading of the word assessment? Sorry, no I can't. I am not seeing the problem that you are, which makes me a poor choice for guessing how to satisfy your concern. Again note that this is non-normative text. 6.3 paragraph 5 has changed signing identity to SDID. The signing identity really corresponds to the AUID. ... 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 j...@marketing.example.com was properly signed with i=marketing.example.com and d=example.com. What the Your example has d= using a 'parent' domain, not a sub-domain. Your following discussion refers to aspects of the spec that concern sub-domains and I am not understanding how the example is relevant to it. Yes, I see that i= has a subdomain but, again, I don't see how that relates to your comments. Yes, d= is a parent domain, signing for a subdomain. DKIM has no concept of signing for a subdomain. d= is d=. It is what is used to sign and verify. The only semantics are that it is the identifier to be delivered as payload and used for assessment. While, yes, one might be able to observe various details about it and i=, there is no standardized semantic about it and i= is not officially payload. The point is that the choice of i= had determined whether something ought to be flagged to the recipient. Now it doesn't. That is a behavioral change that is potentially incompatible with the RFC 4871 behavior. The rule for i= is indeed that its domain must be the same as d= or may be a subdomain is nice, but this doesn't wind up meaning much. In particular, it means nothing at all for the recipient, because we never specified a meaning. You are trying to have the specification document conform to semantics that we chose not to provide, per the Update
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On 3/29/11 4:53 AM, Dave CROCKER wrote: Jim, I found that I got seriously bogged down on some parts of your note, as you and everyone else will surely see. I am glad to try to set up a phone call to get a better channel for discussing this. Beyond the obvious timezone challenges, this week, I've got quite a bit of flexibility in time and am glad to find a slot where I can call you. Also, everyone else is hereby invited to jump in and straighten me out. That said, here's where I got in responding: On 3/28/2011 11:27 PM, Jim Fenton wrote: 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. How is the examples list a misinterpretation? The list was crafted carefully to draw some distinctions that can be significant. Your wording loses the distinction between author and author's organization. I think the distinction is worth maintaining. Just to be clear: A domain name is capable of being author-specific. I recognize that it's not typical, but the construct of 'author' is so fundamental in this game, it's worth acknowledging that it is (still) permitted. With the output of DKIM being the SDID, the identity associated with the signature is of course that of the domain. But when my author-specific domain signs a message for me, it's the domain that does that -- it doesn't matter that it's an organization of one. Putting author here just hints that authors might sign messages as well, and I don't think that's intended. I suggest removing author to make that clear. 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. Goodmail was not an ISP and it was not along the path. . Goodmail .. . . V V Client - Mail - Transfer - Service - Receiver - Recipient Goodmail interacted with the creator of the document and, separately, with the receiving mail service, as an adjunct back office service. To repeat: /It was not in the direct handling path./ DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that configuration in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. This still seems to me to be too specialized a use case to list in the specification, but would look to WG consensus on which way to go here. 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 we've just seen a good example that indeed it is easily misunderstood. That begs explicit reference, not potentially confusing conflation. Can you offer alternate text that avoids the overloading of the word assessment? 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 j...@marketing.example.com was properly signed with i=marketing.example.com and d=example.com. What the Your example has d= using a 'parent' domain, not a sub-domain. Your following discussion refers to aspects of the spec that concern sub-domains and I am not understanding how the example
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
Jim, I found that I got seriously bogged down on some parts of your note, as you and everyone else will surely see. I am glad to try to set up a phone call to get a better channel for discussing this. Beyond the obvious timezone challenges, this week, I've got quite a bit of flexibility in time and am glad to find a slot where I can call you. Also, everyone else is hereby invited to jump in and straighten me out. That said, here's where I got in responding: On 3/28/2011 11:27 PM, Jim Fenton wrote: 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. How is the examples list a misinterpretation? The list was crafted carefully to draw some distinctions that can be significant. Your wording loses the distinction between author and author's organization. I think the distinction is worth maintaining. Just to be clear: A domain name is capable of being author-specific. I recognize that it's not typical, but the construct of 'author' is so fundamental in this game, it's worth acknowledging that it is (still) permitted. 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. Goodmail was not an ISP and it was not along the path. . Goodmail .. . . V V Client - Mail - Transfer - Service - Receiver - Recipient Goodmail interacted with the creator of the document and, separately, with the receiving mail service, as an adjunct back office service. To repeat: /It was not in the direct handling path./ DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that configuration in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. 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 we've just seen a good example that indeed it is easily misunderstood. That begs explicit reference, not potentially confusing conflation. 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? Sounds like moving the current 2.9 to be after the current 2.11 will solve your concern. 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 j...@marketing.example.com was properly signed with i=marketing.example.com and d=example.com. What the Your example has d= using a 'parent' domain, not a sub-domain. Your following discussion refers to aspects of the spec that concern sub-domains and I am not understanding how the example is relevant to it. Yes, I see that i= has a subdomain but, again, I don't see how that relates to your comments. With obvious trepidation, I am going to raise a concern: On reviewing the text, I find, under the Section 3.5 text for i= includes: The Signer MAY choose to use the same namespace for
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On 3/28/2011 11:27 PM, Jim Fenton wrote: 1. authors and their organizations could be misinterpreted ... I'm with Dave. It looks clear ro me that it's a list of examples. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID. I suggest that the first sentence change MAY to might in order to make it non-normative. I further suggest removing the second sentence However It is giving (normative) usage guidance for something that it has already made out of scope. I'd also take out the INFORMATIVE NOTE. It's an opaque token, so a signer can do anything with the mailbox part of that token that it wants. With a d=example.com, you could equally well use i=b...@example.com or i=@bob.example.com. They're different names, but receivers can infer equally little from each of them. The closest I can come to what you describe in Section 6.3 is: If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. Good lord, no. My users don't see SDIDs or any other part of a DKIM signature. That goes in the same bit bucket with the advice to display the signed and unsigned parts of the message in different colors. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 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 j...@marketing.example.com 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
