[dkim-dev] Choosing sets of headers to sign

[Arvel Hathcock]

 > However it also opens the door to insufficient or incompatible
 > signing.  I sign a few fields, and you validate as if there
 > is a robust protection of the headers.  I sign a few headers and you
 > sign a lot, with little overlap between our sets; should the validator
 > treat validation of our two messages the same?

The way the spec is written I suppose the validator will have to treat 
the two messages the same (at least as far as validation of the 
signature goes).  However, afterward, which headers were included in the 
validation will have to be considered if you intend to take some action 
based upon the valid state of the message.

For example, consider the case of Yahoo with DomainKeys.  Currently, 
they present a message in the MUA to the effect of "DomainKeys has 
confirmed that this message was sent from <domain>".  My own product 
inserts a similar message into its web based MUA.  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 
when, in fact, it wasn't, and isn't.  This is why Yahoo's choice of 
wording in their message was very careful and particular.  Some might 
not be so thoughtful.

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.

 > 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 
not sign.  This was largely decided because of the issue mentioned above 
and because there is some uncertainty about the impact of DKIM's 
flexible header signing capability.

 > 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.

Arvel