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
<joe(_at_)marketing(_dot_)example(_dot_)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 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
scope.
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...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html