Jim Fenton wrote:
1. Introduction. The introduction, particularly paragraphs 2 and 3, assert
that the payload (the output of DKIM verification) is only a validated
signing domain. The output of DKIM verification is considerably more than
that:
The Errata draft carefully documents the basis for what it asserts.
Where is the documentation that substantiates the claim of broader functionality
that you keep making?
RFC 4871 somewhat narrowly defines a protocol between the signer and
verifier.
4871 defines a means of associating a domain name to a message and conveying it
with the message, so that the validator can trust its... validity.
6. SDID definition
I am confused by the definition of the SDID as opaque. This makes it sound
like it's a pseudonym for the actual signing domain.
I can't guess how you are deriving that interpretation, since the use of the
term, here, is identical with its typical use in the field, and that's not what
it means.
8. Identity Assessor
The term is imprecise: it is not assessing an identity but a message.
Imprecise? What could be more precise than "name of the module that consumes
DKIM's primary payload"?
In any event, there is a difference between assessing the associated identity,
versus assessing a message. The former has to do with whether the indicated
identity is believed to be a Good Actor or a Bad Actor. The later reviews
attributes of the message, such as whether it promises a vigorous sex life, and
decides whether it is a legitimate message or an abusive one.
Entirely different functions. The latter, of course, has nothing to do with
DKIM. The former is the consumer of the identifier DKIM outputs.
9. d= tag definition
The corrected text removes the required relationship between the SDID and the
AUID, which is perhaps repetitive of information in the i= tag definition,
but which we felt important to repeat in the original
It was a forward reference, and yes repetitive, and it placed the requirement
into the functionality that isn't responsible for making the relationship
happen. That is, the requirement is on i=, not on d=. So that's where the
specification of the requirement is now placed.
Stated differently: d= doesn't care whether i= conforms. d= doesn't really
even "know" about i=. On the other hand, i= is required to relate to d= by
being a sub-domain of it.
10. i= tag definition
paragraph 2, simple change:
OLD:
value of the "d=" tag.
NEW:
SDID.
[There are probably many more places in 4871 where words like this could be
changed to the new terminology. Should this update those as well, for
clarity?]
oops. good catch! (I tried to fully audit the text for exactly this but pretty
much never get all the occurrences during such an exercise. Thanks!.
=====
11. Signing by Parent Domains
Small change, also in the original text:
OLD:
domain of the AUID ("i=" flag)
NEW:
domain of the AUID ("i=" value)
Oops. But actually, neither of us got it right. According to 4871, it's a
"tag".
=====
12. Relationship between SDID and AUID
This is another place where I'm having a problem with the premise that all a
verifier needs to output is the SDID.
Since all of the finished DKIM documents offer the deliver of an identifier as
its only goal, are you suggesting explicitly expanding DKIM's scope?
This section is engaging in considerable discussion about the relationship of
the SDID and UAID to each other and to other header fields, most of which is
not actionable by implementers of the DKIM base specification and in any case
is covered elsewhere in the specification.
The section is intended to counteract a couple of years of confusion.
NEW:
The SDID and AUID represent two different identifiers that may be relevant to
assessors.
Might be, yes. All sorts of things /might/ be relevant to the heuristic
evaluation engine. But that's outside the scope of DKIM. DKIM's job is to
deliver an identifier.
Unlike the SDID, the AUID, or parts of it, represents an
assertion on the part of the signer whose meaning is not defined by this
specification.
parts of it???
assertion? it's an identifier. the only assertion the spec suggests is that
it
can be used to identify a user -- although that's a bit problematic if it is
only a domain name.
The assessor MUST consider AUID values in
the context of being an assertion:
There is no requirement that the assessor see it and certainly no requirement
that the assessor process it, nevermind process it in a particular way.
The AUID local-part and any subdomain of the SDID used in the AUID are, in
general, opaque. Signing domains MAY make specific practices known regarding
their use of the AUID, such as that it does represent an actual email
address, but in the absence of such assertions MUST NOT be assumed by the
assessor.
They /may/ do all sorts of things that aren't in the DKIM spec. The fact that
it's outside the DKIM spec means it's irrelevant to the spec. So I don't
understand how your observation relates to the current effort.
15. MUA Considerations
I find both the original and corrected text to be too specific here, because
as it says this is a matter of continuing research. And there isn't really
any "tendency" at present. So I would adjust the corrected text to say:
One option is to have the MUA highlight some identifier associated with the
signature in an attempt to represent the identity that is claiming
responsibility for the message or on whose behalf the message is signed.
For the Errata, the only change to this text was intended to reflect the
SDID/AUID changes, rather than attack the deeper problem of having this section
be present at all.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html