Subject: CMSKEA Proposed Changes

From: "Pawling, John" <[email-masked]>
Date: Thu, 29 Jul 1999 14:10:43 -0400

All,

I made an error when I updated the "CMS KEA and SKIPJACK Conventions"
(CMSKEA) I-D in May 99 to address Jim Schaad's comments stated in the
attached message trail.  CMSKEA-01, Section 4.2.1, 5th paragraph, second
sentence erroneously states "The KeyAgreeRecipientInfo
keyEncryptionAlgorithm parameters field MUST be the id-fortezzaWrap80 OID
indicating that the FORTEZZA 80-bit wrap function is used to wrap the 80-bit
SKIPJACK CEK."  This must be changed to: "The KeyAgreeRecipientInfo
keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm as
specified in [CMS].  The algorithm field of KeyWrapAlgorithm MUST be the
id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is
used to wrap the 80-bit SKIPJACK CEK.  The parameters field of
KeyWrapAlgorithm MUST be absent."  Thanks to Pierce Leonberger for pointing
this out.  

Furthermore, CMSKEA-01, Section 4.3, 2nd paragraph, 2nd sentence states:
"The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be the
id-fortezzaWrap80 OID (with NULL parameters) indicating that the FORTEZZA
80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK."  This should
be: "The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be the
id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is
used to wrap the 80-bit SKIPJACK CEK.  The KEKRecipientInfo
keyEncryptionAlgorithm parameters field MUST be absent."  This makes the use
of the id-fortezzaWrap80 OID consistent in both sections.

I also clarified the definition of Skipjack-Parm and changed
"initialization_vector" to "initialization-vector" because underscore is an
invalid ASN.1 character.  Thanks to Phil Griffin for pointing this out.

I have submitted a new CMSKEA I-D (CMSKEA-02) to the Internet-Drafts editor
containing these changes.  VDA is developing the S/MIME Freeware Library
(SFL) Fortezza Cryptographic Token Interface Library (CTIL) to implement the
changes included in CMSKEA-02.

Please let me know if anybody disagrees with any of these changes.  Please
review CMSKEA-02 (once it is available) and provide comments, if any.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[email-masked]
============================================

-----Original Message-----
From: Jim Schaad (Exchange) [mailto:[email-masked]] 
Sent: Friday, May 07, 1999 1:45 PM
To: Pawling, John; Ietf-Smime (E-mail)
Subject: RE: More Re: Comments on cmskea

John,

After having worked my way through this, I think it is completely acceptable
and should be done.  This addresses the major problem I had and make things
more in line with the D-H items.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 06, 1999 10:36 AM
To: Ietf-Smime (E-mail)
Subject: More Re: Comments on cmskea

Jim and friends,

Please substitute "id-kEAKeyEncryptionAlgorithm" for "id-KEA" in my 
earlier message. 

Also, change the definition to: "id-kEAKeyEncryptionAlgorithm OBJECT
IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}.  

- John Pawling

Previous message:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Jim,

Thank you very much for your feedback regarding the "CMS KEA and SKIPJACK
Conventions" (CMSKEA) I-D.  I apologize for not answering your message
sooner. 

I believe that you make an excellent point that the id-keyExchangeAlgorithm
OID is overused in CMSKEA.  In fact, the situation is slightly worse than
what you describe.  I added bullet 2 to your list as follows.

1. RFC2528: id-keyExchangeAlgorithm is used in a certificate to identify the
algorithm type of the public key.  The parameters field in this case is an
OCTET STRING identifying the group parameters for the key.

2. CMSKEA, Sec 4.2, 3rd para: id-keyExchangeAlgorithm can be used in a
keyAgreementRecipientInfo originatorKey to identify the type of the public
key.  The parameters field in this case is an OCTET STRING identifying the
group parameters for the key.

3. CMSKEA, Sec 4.2.1, 4th para: id-keyExchangeAlgorithm is used in the
KeyAgreementRecipientInfo keyEncryptionAlgorithm field.  In this case the
parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID).

4. CMSKEA, Sec 4.3, 2nd para: id-keyExchangeAlgorithm is used in
KEKRecipientInfo keyEncryptionAlgorithm field.  In this case the parameters
field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID).

I agree with your proposed change for CMSKEA, Sec 4.3, 2nd para.  I don't
agree with your proposed change for CMSKEA, Sec 4.2.1, 4th para, because it
contradicts CMS section 12.3.1 which states: "Key agreement algorithm
identifiers are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm...fields.  Key wrap algorithm
identifiers are located in the KeyWrapAlgorithm parameters within the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm
... fields."

Recommend the following:

1) Continue to use the id-keyExchangeAlgorithm OID as stated in bullets 1
and 2 above. 

2) Define a new OID for use as stated in bullet 3.  Recommend the following
OID be registered in the Registry of INFOSEC Technical Objects: id-kEA
OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840)
organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEA (23)}.  The
parameters field for this OID will be KeyWrapAlgorithm (using
id-fortezzaWrap80 OID).

3) As you proposed, change CMSKEA, Sec 4.3, 2nd para to state that the
id-fortezzaWrap80 OID (with NULL parameters) is used in KEKRecipientInfo
keyEncryptionAlgorithm field.  

Please let me know if you agree with these recommendations.  If anybody else
has comments, please let me know. If there are no objections from anybody,
then I will change the CMSKEA I-D to implement the aforementioned
recommendations and I will apply for the new id-kEA OID.

- John Pawling

At 09:37 PM 4/29/99 -0700, Jim Schaad (Exchange) wrote:
>John,
>
>I am having a big problem with the amount of overload going on for the the
>OID id-keyExchangeAlgorithm.  It appears to be used in three unique
>locations in encoding an encrypted message and has different meanings and
>two different set of parameters.
>
>
>1.  id-keyExchangeAlgorithm is used in a certificate to identify the
>asymmetric algorithm.  The parameters in this case are an OCTET STRING
>identifing the group parameters for the key.
>
>2.  id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo
>keyEncryptionAlgorithm field.  In this case the parameters is
>KeyWrapAlgorithm (using id-fortezzaWrap80 as the algorithm).
>
>3.  id-keyExchangeAlgorithm is used in KEKRecipientInfo
>keyEncryptionAlgorithm field.  In this case a completely different
algorithm
>is being referenced and again the parameters are KeyWrapAlgorithm.
>
>
>I strong suggest that we change this as follows:
>
>1.  id-keyExchangeAlgorithm is used in certificate w/parameters and in
>KeyAgreementRecipeintInfo w/o parameters.
>
>2.  id-fortezzaWrap80 is used in KEKRecipientInfo for the KEK algorithm
>again w/o parameters are they are not needed.
>
>This should work unless we belive that there would ever be a different
>content encryption algorithm for KEA.
>
>
>jim