EKR wrote:
Paul Hoffman <paul(_dot_)hoffman(_at_)domain-assurance(_dot_)org> writes:
At 3:43 PM -0800 12/26/06, EKR wrote:
I don't know what's being proposed here, but as a technical matter
it's not really the case that you can't individually insulate each
header from breakage without doing a separate signature for each
one. Rather, you could simply include digests for the header value in
the header specification, i.e.,
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=(_at_)eng(_dot_)example(_dot_)net;
t=1117574938; x=1118006938;
h=from=<digest-value>:to=<digest-value>:subject-<digest-value>:date=<digest-value>;
...
This is actually less information than the z= tag, which says what the
value was when signed.
Yes, that's true, so even without this optimization it's not true
that you need to a separate signature for each header.
That said, this representation is more compact, so it's a tradeoff.
It also doesn't come with this restriction:
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
But of course that restriction could be relaxed.
There's two ways to read this restriction: one is that you should
never do this under any conditions which ventures into silly net.cop
delusions of what the protocol document can mandate, and a more
innocent caution that the actual headers to be used for a dkim
verification are the outside headers, not the copied headers.
The latter is the only reasonable way to read this. I agree with
John that this is pretty well trod ground and that it's pretty much
hopeless that we'll agree on any particular approach -- including
what started this thread. Nor do I think we ought to since it's an
inherently driven by heuristics which involve risk/reward tradeoffs
for the receiver which a standard should not be trying to second
guess. Leaving some raw tools around like z= and letting receivers
decide for themselves is about all we need for now, IMO.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html