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
<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.
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.
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.
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.
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
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.
Offhand, it appears to reflect the original misunderstanding that DKIM
"validates" the message.
That said, I don't understand how making the SDID clear to the
'reader' is relevant to your concern about AUID.
I expected an objection on the grounds that this is a human factors
issue. This probably does belong in the deployment document if anywhere.
DKIM specification that permits keys for a subdomain to be managed in
a parent
In what way is any of this counter (per your above assertion)?
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.
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.
Whereas I think it made changes to the semantics for the entire value.
Please point to the current version's specification of AUID "semantics".
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.
I am not understanding how this language affects the use of AUID at all.
(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 RFC 4871, we had very
carefully put together the specification so that a parent domain could
sign on behalf of one of its subdomains, and have the same signature
semantics as if the subdomain had signed it (including the signature
being considered an Author Domain Signature in ADSP). Over time, AUID
has been watered down and caveated to the point that it is basically
meaningless.
If AUID doesn't have any normative effect on DKIM verification, we could
eliminate it altogether and make the specification considerably easier
to understand and implement, provided there is WG consensus to do so.
ADSP already ignores the AUID, and as far as I can tell the only
described use of AUID is to perhaps provide some more fine-grained
reputation support, which is where you have proposed changing MAY to
"might".
I'm not really in favor of getting rid of the AUID, but I'm not in favor
of keeping features in the spec that have no purpose either.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html