Re: Last Call: Use of the CAST-128 Encryption Algorithm in CMS toProposed Standard

"Bob Jueneman" <bjueneman@novell.com> Fri, 23 June 2000 17:25 UTC

Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15788 for <smime-archive@odin.ietf.org>; Fri, 23 Jun 2000 13:25:56 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23021 for ietf-smime-bks; Fri, 23 Jun 2000 09:52:27 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23015 for <ietf-smime@imc.org>; Fri, 23 Jun 2000 09:52:25 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Jun 2000 10:52:11 -0600
Message-Id: <s953415b.010@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 23 Jun 2000 10:52:01 -0600
From: Bob Jueneman <bjueneman@novell.com>
To: iesg@ietf.org, iesg-secretary@ietf.org
Cc: kent@bbn.com, ietf-smime@imc.org, WFord@verisign.com
Subject: Re: Last Call: Use of the CAST-128 Encryption Algorithm in CMS toProposed Standard
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23017
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit

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@ietf.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@ietf.org or ietf@ietf.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