On Feb 17, 2009, at 7:38 AM, Dave CROCKER wrote:
Eliot Lear wrote:
For example, Eliot's draft does not attend to the basic
requirement for
specifying what is primary output.
...
And that is because it is not a basic requirement; and in fact hits
against our charter limit of discussing reputation systems. You've
cleverly couched this debate in terms of interoperability, but what
are
we really talking about? It's the input to reputation services, no
matter what terminology you throw at the matter.
Eliot,
You are confusing the difference between output and input. DKIM
Signature
output, versus Assessment input. The Errata discusses the former,
but you are
referring to the latter.
Protocols have payload, or output. A protocol that does not specify
what its
payload is is not complete.
Take a look at Figure 1 in the new Deployment draft:
<http://dkim.org/specs/draft-ietf-dkim-deployment-03.html>
Note the transition from Identity Validator to Identity Assessor.
The former is
part of DKIM; the latter is not. But that transition entails
delivery of the
payload by DKIM to its receive-side consuming module, the Assessor.
The current RFC 4871 does not specify what its payload is, versus
what is
internal to the protocol operations. The DKIM-Signature: header
field contains
both DKIM internals and DKIM payload. Which is which?
Take a look at the TCP Header Format diagram in the TCP spec:
<http://www.rfc-editor.org/rfc/rfc793.txt>
Note the field at the end labeled "data". That's payload.
The DKIM spec has no equivalently clear and precise definition of
its payload.
Your version of the errata declares the d= value, ( a domain which
includes all contained sub-domains) to be opaque to the "Identity
Assessor". DKIM has established that a signer controls this domain,
unlike the possible sub-domains within the i= value. Even Ellen seems
to have confused the role of i= values with that of d= values in her
statements. The d= value should be considered definitive and
extremely useful to an "Identity Assessor". In addition, the DKIM
signature semantics limit i= value assertions to be at or below the
domain defined by the d= value.
Taking away the d= value as input to an "Identity Assessor" will mean
no relationship can be established. Why must a reasonably safe
conclusion require an undefined external entity or mechanism to
restore an obvious and safe relationship such as From
jon(_at_)example(_dot_)com, i=jon(_at_)example(_dot_)com
d=example.com? An email-address signed by the email-address domain
offers significant value when assessing whether the email-address may
have been spoofed, does it not? Is this not the function of "DKIM"
and an "Identity Assessor"?
At least Eliot's version of the errata did not significantly modify
the role of the d= value. Efforts to change DKIM definitions should
be done within a subsequent draft, and not in a rushed errata.
While indeed the i= value can be opaque, it is often used to represent
valid email-addresses as with ADSP. If the DKIM WG were to declare in
some document or errata that the i= fictitious and real namespace
should not collide within the same message, this would help restore
value to ADSP without the need of some out-of-band signaling. IMHO,
ADSP should only require that the d= value match against a From email-
address, and allow the i= value to play whatever role the domain may
wish.
Why add unnecessary overhead to an already high overhead protocol?
Why add unnecessary delay by mandating the use of redundant auxiliary
mechanisms?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html