[email protected] writes: > > If we allocate new numbers to do it right then we will, in fact, live > > forever with an ambiguous interpretation of groups 19, 20, and 21. I > > agree we should fix the problem and not live with ambiguity. The proposal > > to allocate new numbers doesn't seem to do that though. > > Fine, here's how to accomplish that goal - the RFC that allocates > the new group numbers should: > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > 3) instruct IANA to remove the group number registrations for > 19, 20 and 21 in a fashion that prevents reallocation; and > 4) obsolete RFC 4753. > That should avoid long term problems.
Yes. Exactly that was what I was trying to say, except same thing also needs to be done for RFC5114, as it refers to RFC4753, and perhaps also RFC4869 as it also refers to RFC4753. > That said, I'd like to see more reason to believe that there is > an actual "running code" problem before doing something this drastic. As I said QuickSec versions 4.4 - 5.0 (i.e. QuickSec versions released between 2007-2009) do include original RFC4753 code, the person who fixed our code to support RFC4753 didn't notice the errata... As our OEM toolkit is used quite widely I think there are quite a lot of existing products doing things without errata. Also most of those people (our customers) are not reading this list. > If most people working with elliptic curve "just know" that only > one coordinate is used, we might not have a problem in practice. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
