On 5/6/11 6:28 AM, Charles Lindsey wrote:
On Thu, 05 May 2011 21:24:00 +0100, Barry
Leiba<barryleiba(_at_)computer(_dot_)org>
wrote:
Doug says...
This can *only* be achieved by some mandatory test within the Verifier.
Not at all; that's exactly Dave's point in discussing the difference
between the protocol and the software system that wraps around it.
The Verifier is a component that verifies the signature, and that's
all we're defining normatively here. Other parts of the system will
evaluate things whether the verified signature can be relied upon, and
what it can be relied upon for; whether the domain that signed it is
trustworthy; whether a failed signature can nonetheless provide useful
information; and so on.
Not so. As you should know from off-list discussions, that sentence is
actually mine, though used in a marginally different context than Doug
used it.
IF there were to be some "mandatory test within the Verifier", then that
test would be, ipso facto, a part of the protocol and not part of the
"software system that wraps around it". So your argument was circular :-( .
This sentence was indeed written by Charles. He is far more eloquent,
and I wanted to respond but was rushed by other pressing security
matters. While we have collaborated in creating something that should
better clarify DKIM's role, it is my opinion verification requirements
are better stated as MUST.
Unreliable Assurances are Worse than NONE.
From the aspect of proper protocol design and layering aspects, proper
design must not expect consumers of the protocol to second guess the
validity of the inputs used, especially when these inputs become less
clear in the process.
SMTP can not be expected to ensure header field ordering, especially
those defined by DKIM. The modern version of the message format also
clearly stipulates which header fields are required not to repeat. The
premise used by DKIM in requiring the From header field to be signed,
incorrectly assumed that by requiring this header field to be included
in the signature's validation, the particular header field would be
obvious to subsequent consumers of its output. This was clearly a
mistake made by DKIM that MUST BE corrected.
As email transitions into the use of UTF-8, DKIM's role in better
securing messages becomes even more significant. As such, it is
important to embrace the incumbent obligations. DKIM must not blame
SMTP or DNS for its failings.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html