All,
I believe that the following clarifying text should be appended to CMS
section 12.3.1.1: "When an EnvelopedData is constructed for sets of
recipients whose public keys have been generated using different D-H
parameters (i.e. p,q,g values), then a separate RecipientInfo
KeyAgreeRecipientInfo field must be constructed for each set of recipients
that possess common D-H parameters. For example, if a user needs to send an
envelopedData to a set of recipients possessing D-H parameter "set 1" and
another set of recipients possessing D-H parameter "set 2", then the
envelopedData must include one RecipientInfo KeyAgreeRecipientInfo that
includes the recipientEncryptedKeys for the set of recipients possessing D-H
parameter "set 1" and a separate RecipientInfo KeyAgreeRecipientInfo that
includes the recipientEncryptedKeys for the set of recipients possessing D-H
parameter "set 2". This is needed because the originatorKey will be
different for each of these sets of recipients because the originator uses
the recipient's D-H parameters as part of the process of generating the
originator's ephemeral private-public D-H key pair."
Please note that this is an editorial comment. It does add to or change any
of the CMS concepts.
=========================================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================