[ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
dhc at dcrocker.net
Thu Mar 31 07:52:21 PDT 2011
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)
> 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
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,
> 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
> Can you offer alternate text that avoids the overloading of the word
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
>>> Nevertheless, suppose a message with From address
>>> <joe at 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
> 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 effort last year.
With respect to i=, there is no "flagged to the user" that is currently part of
the DKIM specification. Personally, I hope we do not have to revisit this
issue, since the working group spent quite a bit of time and energy resolving it
when formulating the Update RFC.
>> 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 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.
Again: The current text is cast in normative language, where we did not approve
normative meaning. The resolution with the Update effort was to have no
normative text about AUID, other than the syntax aspect, in the i= definition.
Retaining normative language in this paragraph is in conflict with that decision.
>> I further suggest removing the second sentence "However...". It is giving
>> (normative) usage guidance for something that it has already made out of
> It's only normative if the "if" clause of that sentence is satisfied, so I
> don't see a problem.
+1. Personally, I'd be delighted to have that text removed.
>> 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."
>> As always, anything DKIM says in the space of human factors varies between
>> problematic and bad. "clear to the reader" nicely falls within that range.
>> I know something about user interface design and don't know how to satisfy
>> this guidance, or what it's supposed benefit is.
> I expected an objection on the grounds that this is a human factors issue.
glad to be predictable...
>>> domain. If these is consensus to eliminate signing for subdomains, there
>>> is a
>> You've jumped to a specific conclusion that implies a significant,
>> unstated logic sequence and I'm not yet understanding the premise, never
>> mind the rest.
>> Please clarify.
> Let's discuss over the phone or something. I don't think I'm going to do any
> better in a typed description.
as we shall do tonight/afternoon...
More information about the ietf-dkim