> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Hansen
> I don't like being a guinea pig, but that's what it feels > like with the discussions on how to go about upgrading > algorithms. I don't think we know enough yet to even know how > to begin. This is a problem that a variety of protocols are > going to go through, so we are *not* alone (and > *shouldn't* be alone) in trying to figure out how to do it. Actually there is a major difference. We have almost complete flexibility here and almost no legacy base to defend. Our problem is much much easier than anyone else's. We can avoid the need for a SHA 256 transition by making it a base requirement and we can build in a transition strategy into the base. Another major advantage we have uniquely is that we have a policy record. The lack of security policy information is a major reason that existing security protocols are difficult to upgrade and prone to downgrade attack. I think that we will find others are looking at us to see if they can copy our solution. _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
