[ietf-dkim] chained signatures, was l= summary

[Charles Lindsey]

On Thu, 04 Jun 2009 20:19:34 +0100, Douglas Otis <dotis at mail-abuse.org>  
wrote:

> On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:
>
>> On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy

>>> You're not required to sign them, but it's not a bad idea.
>>
>> Then why are people on this list not trying to enocourage that good
>> practice? Indeed, why are they so vociferously trying to DIScourage
>> it?
>
> Before A-R headers can be trusted, A-R headers MUST be removed by
> incoming border MTAs.  See section 1.6 of RFC 5451.

No, that is NOT what section 1.6 of RFC 5451 says. It requires removal of  
any pre-existing A-R header "claiming to be valid with in its [the ADMD's]  
boundaries", which essentially means (AIUI) any A-R header that might be  
mistaken for one that might/would/should have been created within that  
same ADMD.

BUT the cases we are considering are where, in the course of its travels,  
a message has picked up two signatures, S_1 and S_2, but where S_1 has  
(possibly) been invalidated by some change at an intermediate site  
(typically a mailing list expander) en route, and even where S_1 has been  
removed at some point. So there are at least three ADMDs involved:

|    sending ADMD   |       Mail List ADMD        |       Receiving  
ADMD     |
| orig MUA orig MTA |                             |    Recv MTA     Recv  
MUA |
|    M ---> M+S_1 --+-> M+S_1+A_1 -> M*+A_1+S_2 --+-> M*+A_1+S_2+A_2  
-->     |

A_1 was added by a validator/assessor on the strength of S_!
A_2 was added by a validator/assessor on the strength of S_2
Observe that M was transmogrified into M* at some point, breaking S_!.

If some "helpful" MTA, somewhere between the Mail List and Receiving  
ADMDs, had also added an A_2, then THAT is the one that should be removed  
by Recv MTA, before inserting its own (which it obviously would not do if  
S_2 covered A_1, and A_1 was no longer there).

What Recv MTA passes on to Recv MUA is entirely a matter to be decided  
within the Receiving ADMD, but I hope it would be everything that was  
available (even S_1 if it were still available).

Note that Appendix B.6 of RFC 5451 contains an example exactly equivalent  
to the one I have just given, including the retention of A_1 (and even  
S_1).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5