Arvel,
Thanks for responding.
Arvel Hathcock wrote:
Now, suppose such a
message were displayed based upon a DKIM verification which did not
cover the Subject header and that header had been modified for some
reason. This might tend to make the end user believe that the altered
Subject text was cryptographically verified and true to the original
So, one approach is to make sure to sign all fields that are typically displayed
to users. (A signature can cover multiple "approaches"; I'm merely trying to
characterize one of them, from your comment.)
If you don't want to get into end user details, similar problems could
arise in filtering agents if some filter is based upon the accuracy of
the Subject text, or omits the filtering of the Subject text altogether,
when a valid DKIM signature is present. This issue needn't be
restricted to the Subject header.
This is probably a variant of the MUA display-oriented approach, above: Sign
all fields that are expected to be important to a filtering engine.
> 1. How are folks deciding what fields to sign?
In my own case I decided to a) sign all headers (except X type headers)
and b) not give my customers a UI to decide which headers to sign and
This implies that you sign Received fields, and I'll bet you don't. Perhaps
your criteria are just a bit more elaborate?
> 2. To what extent do we care about different signers choosing
> different fields to sign, in terms of how to process a validated
> signature?
I care greatly if the Subject isn't covered for the reason mentioned above.
Does anyone else have thoughts on this?
What would be the minimum set of headers that you would find credible to have
signed? And, of course, why?
Do you have any fields, besides Received, that you feel should/must NOT be
signed?
And the other line of question is about having different folks signing different
sets of fields. Is that variation important? How? And how can/should they be
distinguished by the validator/filter?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev