At 05:11 PM 6/24/98 -0400, dontspam-tzeruch(_at_)ceddec(_dot_)com wrote:
What is the status of HAVAL's algorithm number.
Haval is 7 -- 4 is reserved for the double-width experimental.
Also, I didn't write this up in detail before, but somewhere, probably
near the top or in the algorithm section it should say (feel free to
edit):
"MAY implement" algorithms are only for experimental or internal use.
Implementations MUST NOT send keys to any public keyserver that uses
algorithms other than those listed below. Implementations SHOULD NOT
create keys or messages that use algorithms other than those listed below
in any normal or common useage. Implementations SHOULD make it very
difficult to generate PGP packets using "MAY" or experimental algorithms.
This limits the available algorithms: hashes to MD5, SHA1, and RIPEMD160;
symmetric algorithms to IDEA, 3DES, and CAST5; encryption algorithms to
RSA and DH (ElGamal); and signature algorithms to RSA and DSA. Further,
DSA signatures should be limited to using SHA1. MD5, IDEA, and RSA should
only be used to interoperate with earlier implementations of PGP.
This is sort of implied by the definition of MAY, SHOULD, etc. but I think
it would be a good idea to reinforce it by stating this clearly and
explicitly. Although I am for leaving the algorithm list alone at this
late stage, I do think it would be best to strongly state that the extra
stuff is experimental and not intended for use in any commercial product.
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 understand that there are also now a flurry of new algorithms coming out,
because of AES that are worth looking at. I've also had the suggestion that
some of the algorithms there be included, even replacing ones already here
because the AES submissions are often later versions of algorithms that are
here.
Implementors are free to do what they want with MAY algorithms. Some
implementors might do precisely what you suggest -- restrict yourself to
the minimal set. (In fact, that's the likely outcome here. There is no
consensus at NAI to add any new algorithms to our products.)
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.
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.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 3965 Freedom Circle
Network Associates, Inc. Santa Clara, CA 95054
(408) 346-5860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)