On Feb 18, 2009, at 4:51 AM, Wietse Venema wrote:
Eliot Lear:
The question one has to ask is broader than inputs and outputs.
Are each of the protocol elements described in the specification
clear enough to be understood as to their meaning? If they are not
then that is what needs to be clarified. Regardless, this debate
about functional programming (which is really what this boils down
to) is pointless, and you are ossifying a structure around a model
that you needn't do. As we have seen many times at the IETF,
successful specifications are those in which the model can easily
evolve over time based on circumstances.
This is precisely the case with DKIM, where the AD's and the IESG's
intent was to walk slowly before we run. The DKIM specification
reflects that intent.
Your errata reflect a different intent.
If intelligent people cannot agree on what is the result of a
protocol, then there is a problem that needs to be fixed. The
proposed errata address the problem. The alternative does not.
Eliot makes a good point. Eloit's errata does less violence to DKIM.
However, rather than describing the i= value as a being an opaque
string, when this value within the i= value matches exactly with that
of some signed header field, it should be safe to assume name
collision has been avoided which is easily done with DKIM. Otherwise,
extensions like ADSP represent little more than a signature mandate
with little other value.
A rush to create an errata that emasculates the information offered by
DKIM (without batteries) seems ill advised. The general goal DKIM's
charter was to enable detection of domain spoofing. As such, the d=
value within the DKIM signature can not be described as opaque to
achieve this role. DKIM is not just an exercise of attaching
cryptographic tokens unrelated to other message content.
Although a DKIM i= value may include namespace that does not
reference a valid destination, this namespace is still that of the
same domain. Any semblance of accountability requires that DKIM
ensure a valid signature represents message control by an
authoritative entity for this domain's namespace. As a general
practice, this entity should avoid colliding non-valid and valid
namespace within the same message, or the i= value might be deceptive.
In general, DKIM should not sanction deceptive messages.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html