> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Barry Leiba > Sent: Sunday, May 15, 2011 7:56 PM > To: Hector Santos > Cc: DKIM List > Subject: Re: [ietf-dkim] MLM and C14N > > > Do you know what is being asked? > > 1. We didn't want more than one or two. This obviously never did nor > never should take precedence over a true need for another one, but the > idea is that the bar needs to be very high for a new one. The > combinatorics get messy. > > 2. We wanted to cover the vast majority of the cases, though we knew > there'd always be outlying situations where some mail would get broken > because what we had didn't *quite* cover some other case. We decided > to accept that. > > 3. We absolutely did *not* want to go adding new algorithms for this > or that piece of software that was getting something wrong. > Canonicalization algorithms were *not* designed to work around broken > software. They're meant to deal primarily with legitimate, if > sometimes unfortunate, changes that get made to the mail along the > way, and secondarily with *very common* situations that creep into the > questionable area.
I would add that adding a new canonicalization now has an extremely high cost to the people that want to use it, because signatures using it will go unverified for a very long time until software supporting the new canonicalization is widely deployed. We shouldn't underestimate what all of that means just to handle one or two corner cases that are actually more likely broken software than an actual universal problem mandating a protocol extension. The same goes for new signing algorithms. ECC, whenever DKIM is extended to cover it, will be an interesting experiment. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
