Re: More Re: Comments on cmskea

[Russ Housley <[e-mail]>]

John:

In my opinion, only one parameter structure should ever be associated with
an OID.  Do #2 and #3 below have this problem?

Russ


At 01:36 PM 5/6/99 -0400, John Pawling wrote:
>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
>>
>>
>
>