[Top] [All Lists]

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

1999-03-16 12:29:08

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(_at_)secstan wrote:

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

So I favour adding the OID extension to the choice.