In cases where the recipient is not yet known or it is a group of recipients that may share a secret, encryption should be done with a secret key.
this results in a different algorithm and logic to be executed and a different RecipientInfo block in the cms message.
Recipient information using previously distributed symmetric keys is
represented in the type KEKRecipientInfo. Each instance of
KEKRecipientInfo will transfer the content-encryption key to one or
more recipients who have the previously distributed key-encryption
key.
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
It should be possible to add a recipient with a symmetric key and key identifier before encryption takes place.
In cases where the recipient is not yet known or it is a group of recipients that may share a secret, encryption should be done with a secret key. this results in a different algorithm and logic to be executed and a different RecipientInfo block in the cms message.
From the rfc: https://datatracker.ietf.org/doc/html/rfc5652#page-25
Recipient information using previously distributed symmetric keys is represented in the type KEKRecipientInfo. Each instance of KEKRecipientInfo will transfer the content-encryption key to one or more recipients who have the previously distributed key-encryption key.
It should be possible to add a recipient with a symmetric key and key identifier before encryption takes place.