[dkim-dev] Choosing sets of headers to sign

[Murray S. Kucherawy]

On Thu, 11 Jan 2007, Dave Crocker wrote:
> 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.)

Yes, I think that's necessary.

Would this be best communicated through a BCP document or another draft 
(or both)?

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

We do, by default anyway.  You can disable it by replacing the list of 
signed headers.

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

I concur.

> What would be the minimum set of headers that you would find credible to 
> have signed?  And, of course, why?

All displayed headers, and any header which indicates ownership of the 
message in some way (e.g. the Sender and Resent-* ones).

> Do you have any fields, besides Received, that you feel should/must NOT 
> be signed?

The feature to change the list of signed headers was specifically added to 
enable someone to omit the Return-Path: header which apparently Exchange 
adds.  If the verifier gets such a message only after the receiving MTA 
has replaced it with its own idea of what that value should be, the 
signatures will not verify.

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

I would think the verifier could be given a list of headers which, if 
present, MUST be signed.  If for example the verifier wants all From 
headers to be signed and it gets a message whose signature verifies but 
>From wasn't signed, the verifier SHOULD act as though the signature was 
not present.

This is all local policy or BCP stuff though, not something the base 
specifications necessarily need to address.

-MSK