RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Carlisle Adams <carlisle.adams@entrust.com> Tue, 20 June 2000 14:48 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 KAA24710 for <smime-archive@odin.ietf.org>; Tue, 20 Jun 2000 10:48:44 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07989 for ietf-smime-bks; Tue, 20 Jun 2000 07:20:02 -0700 (PDT)
Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07982 for <ietf-smime@imc.org>; Tue, 20 Jun 2000 07:20:01 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <NFRN311J>; Tue, 20 Jun 2000 10:19:35 -0400
Message-ID: <ED026032A3FCD211AEDA00105A9C469601E04375@sothmxs05.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: 'Blake Ramsdell' <blake.ramsdell@tumbleweed.com>
Cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Tue, 20 Jun 2000 10:19:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
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>
Hi Blake, Good to hear from you again! > ---------- > From: Blake Ramsdell[SMTP:blake.ramsdell@tumbleweed.com] > Sent: Monday, June 19, 2000 4:14 PM > To: 'ietf-smime@imc.org' > Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in > CMS to Proposed Standard > > Two comments, don't know if they're major. > > 1. Section 3 does not list an SMIMECapability for key wrapping using IDEA, > only for symmetric encryption. Don't know if that was intended. I suspect that you mean "CAST-128" above, rather than "IDEA"... In any case, I originally had both OIDs here (symm. encryption and key wrapping), but in a note posted on Nov. 18, 1999, Jim Schaad included the following comment: "2. Section 3 Para 1. You state that you must include the above OIDs in the symmetric algorithms section of capabilities, but only one of the oids is a symmetric algorithm. At the current time we are "implying" the key wrap from the symmetric algorithm as only same key wrap is supported in CMS. Please change to the correct OID reference." So, I took out the key wrap OID and left only the one for symmetric encryption. > 2. I think that the example in section 3 should clarify that the > cast5CBCParameters are encoded with the iv omitted. I guess it seemed clear to me that if you were only advertising your capabilities (in this case, symmetric algorithm and key length), an IV would be irrelevant and would therefore be omitted. If you wish, however, I can add a sentence to this effect when the document has been approved and I get the 1-day window to send any tiny edits to the RFC editor. Let me know if you really think this is necessary. Thanks for taking the time to look through this draft! Carlisle.
- Last Call: Use of the CAST-128 Encryption Algorit… The IESG
- RE: Last Call: Use of the CAST-128 Encryption Alg… Blake Ramsdell
- RE: Last Call: Use of the CAST-128 Encryption Alg… Carlisle Adams
- RE: Last Call: Use of the CAST-128 Encryption Alg… Jim Schaad
- RE: Last Call: Use of the CAST-128 Encryption Alg… Blake Ramsdell
- RE: Last Call: Use of the CAST-128 Encryption Alg… Jim Schaad