I will raise the same objection that I raised within the S/MIME working group.
I have nothing against the CAST-128 algorithm per se, or against proprietary
algorithms in general, but I am strongly opposed to including more and more
algorithms within the S/MIME suite that really don't provide any significant or
measurable improvement in security when compared to existing choices.
The fact that such algorithms are considered "standard", even if they are
optional, inevitably leads to competitive pressure to include those algorithms
within e-mail packages, as well as cryptographic toolkits. The inclusion in
the cryptographic infrastructure then tends to proliferate to other programs
and applications as well. This leads to greatly increased development, test,
and documentation costs within the vendor community, as well as to code bloat
and interoperability headaches, but with no significant benefit to the users.
I see absolutely no reason to include CAST, IDEA, or some of the other
algorithms that have recently been proposed, when AES is about to come out.
I would encourage the IESG to "just say no" to the "let 10,000 standards bloom"
type of mentality, and to make the necessary hard choices. I believe that this
should be an informational RFC, and not a Proposed Standard.
Sincerely,
Bob
Robert R. Jueneman
Security Architect
Novell, Inc.
1800 South novell Place
Provo, Utah 80606
801/861-7387
iesg-secretary(_at_)ietf(_dot_)org 06/16/00 11:27AM >>>
The IESG has received a request from the S/MIME Mail Security Working
Group to consider Use of the CAST-128 Encryption Algorithm in CMS
<draft-ietf-smime-cast-128-02.txt> as a Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by June 27,
2000.
Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cast-128-02.txt