RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard

"Jim Schaad" <jimsch@nwlink.com> Fri, 23 June 2000 20:39 UTC

Reply-To: jimsch@nwlink.com
From: Jim Schaad <jimsch@nwlink.com>
To: Carlisle Adams <carlisle.adams@entrust.com>, 'Blake Ramsdell' <blake.ramsdell@tumbleweed.com>
Cc: ietf-smime@imc.org
Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS to Proposed Standard
Date: Fri, 23 Jun 2000 13:09:53 -0700
Message-ID: <NDBBJGDMMGBPBDENLEIHIEGKCBAA.jimsch@nwlink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <ED026032A3FCD211AEDA00105A9C469601E04375@sothmxs05.entrust.com>
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

This is still my position.  If, for a D-H key, you make the statment that
CAST128 is supported as a bulk algorithm, then you must support the CAST128
wrap of CAST128 because that is the only way of doing it.

jim

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org
> [mailto:owner-ietf-smime@mail.imc.org]On Behalf Of Carlisle Adams
> Sent: Tuesday, June 20, 2000 7:19 AM
> To: 'Blake Ramsdell'
> Cc: 'ietf-smime@imc.org'
> Subject: RE: Last Call: Use of the CAST-128 Encryption Algorithm in CMS
> to Proposed Standard
>
>
> 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