MH Michael Hammer (5304) wrote:
+1
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
Hmmm. Noting two quick +1s to Murray's text and in the interest of still
trying
to bring this "quick" errata/update effort to a close, I'm inclined to suggest
adding his explanatory text to the existing proposed addition.
While it's entirely plausible that Murray can formulate a superior version of
the basic text for the addition, I think that the existing +1s for the existing
text and the +1s for Murray's commentary offers us something quicker.
So, here's a suggested merging of the two:
<t>This currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for assessment, and have a non-reputation intent in setting the
value in the other. However the verifier might choose the wrong value
to deliver to the assessor, thereby producing an unintended (and
inaccurate) assessment.</t>
<t>This update resolves that confusion. It defines additional, semantic
labels for the two values, clarifies their nature and specifies their
relationship. More specifically, it clarifies that the identifier
intended for delivery to the assessor -- such as one that consults a
white list -- is the value of the "d=" tag. However, this does not
prohibit message filtering engines from using the "i=" tag, or any
other information in the message's header, for filtering decisions.
</t>
<t>For signers and verifiers that have been using the i= tag as the
primary value that is delivered to the assessor, a software change to
using the d= tag is intended.
</t>
<t>So, this Update clarifies the formal interface to DKIM, after
signature verification has been performed. It distinguishes DKIM's
internal signing and
verification activity, from its standardized delivery of data to that
interface.</t>
<t>The focus of the Update is on the portion of DKIM that is much like
an API definition. If DKIM is implemented as a software library for
use by others, it needs to define what outputs are provided, that is,
what data that an application developer who uses the library can expect
to obtain as a result of invoking DKIM on a message.</t>
<t>This Update draft defines the output of that library to include the
yes/no result of the verification and the "d=" value. In other words,
it says what (one) identifier was formally specified for use by the
signer and whether the use of that identifier has been validated. For
a particular library, other information can be provided at the
discretion of the library developer, since developers of assessors --
these are the consumers of the DKIM library -- well might want more
information than the standardized two pieces of information. However
that standardized set is the minimum that is required to be provided
to a consuming module, in order to be able to claim that the library
is DKIM compliant.</t>
<t>This does not state what the implicit value of "i=" is, relative to
"d=". In this context, that fact is irrelevant.</t>
<t>Another example is the difference between the socket interface to TCP
versus the TCP protocol itself. There is the activity within the
protocol
stack, and then there is the activity within in the software libraries
that are actually used.</t>
Comments? (And yes, quick +1s are eagerly sought.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html