[dkim-dev] Choosing sets of headers to sign
dhc at dcrocker.net
Thu Jan 11 12:58:29 PST 2007
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?
More information about the dkim-dev