Russ
OK,
but what about extending the choice, are you also opposed to that?
Regards
JR
-----Original Message-----
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
To: John Ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>
Cc: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Monday, December 07, 1998 8:36 PM
Subject: Re: Extensibility discussion
John:
One bucket for unprotected attributes in the EnvelopedData structure is
more than enough. If we put two such buckets (by adding a second one to
keyAgreeRecipientInfo), then the processing gets complex.
I am strongly opposed.
Russ
At 03:12 PM 12/3/98 -0800, John Ross wrote:
--Cut--
The following is an example ASN.1:
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo
kext [3] ExternalyDefinedKeyAgreement --for future or private
key management schemes }
ExternalyDefinedKeyAgreement :: = OCTET STRING
Alternatively, the syntax of the externally defined key management use
the OID extension mechanism:
ExternalyDefinedKeyAgreement :: = SEQUENCE {
ExternalID OBJECT IDENTIFIER {
ExternalValue ANY DEFINED BY ExternalID
}
I slightly favor the OID extension but if there is objection to that
extension mechanism, the OCTET STRING approach would be adequate.
John Ross