RE: More Re: Comments on cmskea

["Jim Schaad (Exchange)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
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
>
>