Re: More on KEKIdentifiers, and a suggested addition to CMS

[Russ Housley <[e-mail]>]

No.  CMS will not be modified at this time to support additional
RecipiontInfo CHOICES.  This will be addressed as a separate charter item
once the current charter is fulfilled.

Russ

At 06:08 PM 3/17/99 +0000, you wrote:
>Does this mean that we have come to closure on this? i.e using:
>RecipientInfo ::= CHOICE {
>>>        ktri KeyTransRecipientInfo,
>>>        kari [1] KeyAgreeRecipientInfo,
>>>        kekri [2] KEKRecipientInfo,
>>>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>management schemes }
>>>
>>>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>>>    keyTypeIdentifier ObjectIdentier,
>>>    keyTypeInfo OCTECT STRING --any defined by OID}
>>
>
>
>-----Original Message-----
>From: John Pawling <[e-mail]>
>To: ross@secstan <[e-mail]>; [e-mail] <[e-mail]>
>Date: 16 March 1999 19:50
>Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
>
>
>>John,
>>
>>Upon further investigation, your proposal (excerpted below) does not cause
>>the ASN.1 decoding problems that I thought that it would.  Contrary to what
>>I stated in yesterday's message, I agree that your proposal would allow
>>general purpose ASN.1 libraries (such as SNACC) to be able to successfully
>>decode the RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and
>>keyTypeInfo OCTET STRING on the first pass.  The receiving software could
>>then examine the keyTypeIdentifier OID to determine if it is able to decode
>>the data within the keyTypeInfo OCTET STRING.  If it does not recognize the
>>OID, then it could skip the processing of this instance of RecipientInfo
>and
>>attempt to find another instance that it recognizes.  If it does not find a
>>recognized RecipientInfo CHOICE syntax that includes the recipient's
>>protected CEK, then the software would return an error.
>>
>>Also, Darren Harter's comment to change keyTypeInfo to an ANY will allow
>>general purpose ASN.1 decode libraries to be able to successfully decode
>the
>>RecipientInfo kext CHOICE down to the keyTypeIdentifier OID and keyTypeInfo
>>ANY on the first pass.  I agree with Darren's comment that the receiving
>>software could completely decode the keyTypeInfo ANY as part of the first
>>pass if it recognizes the keyTypeIdentifier OID.
>>
>>> RecipientInfo ::= CHOICE {
>>>        ktri KeyTransRecipientInfo,
>>>        kari [1] KeyAgreeRecipientInfo,
>>>        kekri [2] KEKRecipientInfo,
>>>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>>>management schemes }
>>>
>>>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>>>    keyTypeIdentifier ObjectIdentier,
>>>    keyTypeInfo OCTECT STRING --any defined by OID}
>>
>>In summary, I agree that your proposal is technically feasible, but I am
>>still not sure that adding kext is the right thing to do.  This strategy
>>leads us to yet another S/MIME v3 spec that would define
>>ExternallyDefinedKeyAgreement syntaxes.  It seems that another strategy
>>would be to develop a new version of the base CMS document when the syntax
>>needs to be enhanced.
>>
>>- John Pawling
>>
>>
>>
>>At 05:11 PM 3/16/99 -0000, ross@secstan wrote:
>>>John,
>>>
>>>If the choice includes an OID extension with an OCTET STRING, then the one
>>>pass ASN.1 decoding strategy on the entire object works OK. Correct?
>>>
>>>If the implementation can support an OID extension will  it need to dig
>>>deeper into the OCTETSTRING.  Implementations that do not support any OID
>>>extension to the choice will just ignore it,  there should be no syntax or
>>>decoder failure.   The end result will be that envelopeData will decode
>>>correctly.
>>>
>>>So I favour adding the OID extension to the choice.
>>>
>>>Regards
>>>
>>>JR
>>>.
>>>
>>>
>>>
>>
>