Jim and friends,
After reading the R-H requirements, I now agree with Jim that
"originatorCertificateSelector CertificateAssertion OPTIONAL" should be
added to the RecipientInfo SEQUENCE.
However, I have another concern as follows: CertificateAssertion includes
"pathToName" as an option. X.509 describes "pathToName" as follows:
"pathToName matches unless the certificate has a name constraints extension
which inhibits the construction of a certification path to the presented
name value." Do we really need the pathToName option in the
originatorCertificateSelector CertificateAssertion in the RecipientInfo
SEQUENCE?? It adds significant complexity to the process of matching the
originator's key material with the recipientInfo. Could we adopt Jim's
recommended solution with a caveat stating that "pathToName" is prohibited?
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 04:58 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
John,
I respectfully disagree with proposal #5 in the enclosed message trail that
"originator-certificate-selector" needs to be added to the RecipientInfo
SEQUENCE. IMHO, there should only be a single originating entity that
protects keys for inclusion in the EnvelopedData ReceipientInfos. That
single originating entity can include multiple key management certs in the
OriginatorInfo component of EnvelopedData. For example, if the originator
has included both DH-protected and KEA-protected
copies of the content-encryption key in recipientInfos, then separate
certificates including the originator's KEA and DH public key material would
be present in originatorInfo. The recieving agent can identify the correct
originator's cert from which to extract the public key to use to form the
pairwise key to decrypt a RecipientInfo encryptedKey by comparing the
keyEncryptionIdentifier with the subjectPublicKeyInfo algorithm identifier
in each of the originator's certs.
What you say may be true for these algorithms. However, for Royal Holloway
algorithms the originator uses a send key which is different for each
recipient's CA - that is, the same originator send key can only be used for
multiple recipients who share a common CA. So in general the originator will
include several certificates for different public send keys for the same
algorithm - hence the need for the originator-certificate-selector.
IMHO, the addition of "originator-certificate-selector" to the
ReceipientInfo SEQUENCE adds needless complexity. Furthermore, it allows
the syntax to support different originating entities protecting keys using
the same algorithm. I don't believe that is a valid requirement.
The requirement for originator-certificate-selector is not for the case of
different originating entities, although if the solution happens to support
this isn't that a bonus.
Jim