[dkim-dev] Choosing sets of headers to sign

[Hector Santos]

Doug, two things are clear.

One, your design philosophy for DKIM is counter that of the current 
consensus and direction; two, I don't think I will go wrong with 
sticking with the what has been the standard electronic communications 
variables in any environment since the dawn of time, WHO ARE YOU? 
(From:), ARE YOU TALKING TO ME? (To:) , ABOUT WHAT (Subject:) and WHEN 
(Date:).

Any new "altering" system being consider is a FOREIGN concept and should 
follow a "reversibility" rule of thumb that is the standard 
consideration in all transformations.

In short, if you can secure these four fundamental message variables, 
From:, To: Subject: and Date: then nothing will work right, never mind DKIM.

Dave asked a simple question and as it is TODAY and has been for 
multiple decades of years, these variables are pretty sound across the 
board.  Thats obvious and they will be our defaults.

--
HLS

Douglas Otis wrote:
> 
> On Jan 11, 2007, at 12:36 PM, Hector Santos wrote:
> 
>> Dave Crocker wrote:
>>>
>>> 1. How are folks deciding what fields to sign?
>>
>> Odds are good we will use a default of the most common fields across 
>> all mail networks and devices. The top most:
>>
>>    From:
>>    To:
>>    Subject:
>>    Date:
> 
> These questions need to be asked of MUA vendors as well.  Should signed 
> headers be annotated in some fashion?  For example, what if the 
> signature included the identity found in the Sender header, but was not 
> signed?  Should the Display-Name be highlighted differently?  When 
> header annotation depends upon the identity being recognized by retained 
> information and associated with the signature, then retained 
> Display-Names might supplant this questionable component in an unsigned 
> header.
 >
>> and throw in Message-ID:
>>
>>> 2. To what extent do we care about different signers choosing 
>>> different fields to sign, in terms of how to process a validated 
>>> signature?
>>
>> Only that it isn't something that will readily change and use a field 
>> that may not survive.
> 
> How should a header <utf-8 at utf-8 <ascii at ascii>> be annotated?  Should it 
> be signed?  Which component of this header can be trusted as having been 
> confirmed via the DKIM signature?  Keep in mind, domains might differ.
> 
> -Doug
> 
>