ietf-smime
[Top] [All Lists]

RE: Comments on draft-ietf-smime-cast-128-00.txt

1999-11-23 11:23:49
Hi Jim,

Thank you for your comments.  I will take these into account (along with the
name change suggestion from Russ) when I update the draft.

Carlisle.


----------
From:         Jim Schaad 
(Exchange)[SMTP:jimsch(_at_)Exchange(_dot_)Microsoft(_dot_)com]
Sent:         Thursday, November 18, 1999 12:45 PM
To:   cadams(_at_)entrust(_dot_)com
Cc:   ietf-smime(_at_)imc(_dot_)org
Subject:      Comments on draft-ietf-smime-cast-128-00.txt

I have the following comments on this draft: 

1.  You are currently missing an analogus statement to "Only 128-bit RC2
keys may be used as key-encryption keys, and they must be used with the
RC2ParameterVersion parameter set to 58." (from section 12.3.3.2 of RFC
2630).  This was deemed important by the group for inclusion to prevent
the usage of weaker KEK than CEK keys.  (I do note that you have a should
be equal in size in the security considerations.  I believe this should be
moved up to the main document however to match CMS.)

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.

3.  Section 3. Para 1.  You appear to state that the parameters could be
either the SMIMECapabilitiesParametersForCAST5CBC or
cast5CMSkeywrapParameter or cast5CBCParameters.  The last would lead to a
different encoding from the first two and RFC 2633 states in section 2.5.2
that capabilties must be single value.  Please determine which of the
parameters is to be used.  I would also like to see the encoded binary
sequence included in the document so that there is no question on the
single encoding.  I plan to suggest that this be done for RFC 2633 on
progression as well.

4.  Section 2.1 para 5.  I'm sorry, but I don't have RFC 2144 in front of
me.  If this document contains clear language on the use of the default IV
of 0 then everything is fine.  If not please include a SHOULD NOT use the
default IV.

jim 


<Prev in Thread] Current Thread [Next in Thread>