dkim-dev
[Top] [All Lists]

Re: [dkim-dev] Choosing sets of headers to sign

2007-01-12 15:41:26
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
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev