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

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 <jsp(_at_)jgvandyke(_dot_)com>
> To: ross(_at_)secstan <ross(_at_)secstan(_dot_)com>; 
> ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
> 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(_at_)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
> > > .