Jon Callas says:
Ummm, I don't agree. An implementor may implement any "MAY implement"
algorithm. They are not required to, but they MAY. The above language would
change MAY to SHOULD NOT. I don't see the sense in adding an algorithm,
only to say it shouldn't be used.
I support Jon's position.
The users are protected by symmetric pref rules. If my self-sig doesn't
have algorithm X in it, then an implementation is not to use X. This
permits us to be relatively free with assigning algorithm IDs. In any
event, once IDs are assigned by IANA, they're more likely to be more free
than the stingy folks would like.
This protection is perfectly good enough in my opinion.
To sum up, MAY means MAY, it doesn't mean SHOULD NOT. I think that any new
algorithm that is born SHOULD NOT simply shouldn't be there. If there's
rousing, quick, consensus here to delete some set of algorithms, that
change is easy for me to do. If anyone wants to comment, the comments
better come quickly.
I'm against it. As a matter of fact, I'd like to propose to ADD some
more, that AES competition will "unearth". Surely we'll want to AT
THE VERY LEAST support the AES winner itself? And for the sake
of interoperability with Fortezza might we not include SKIPJACK?
Just two examples...
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>