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