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

["ross@secstan" <[e-mail]>]

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
>>.
>>
>>
>>
>