-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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