2.7. Replace Section 5.2.2 - Encrypted Values
2.7. Replace Section 5.2.2 - Encrypted Values
Section 5.2.2 of [RFC4210] describes the use of EncryptedValue to transport encrypted data. This document extends the encryption of data to preferably use EnvelopedData.
Replace the text of the section with the following text:
5.2.2. Encrypted Values
Where encrypted data (in this specification, private keys, certificates, or revocation passphrase) is sent in PKI messages, the EncryptedKey data structure is used.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
See Certificate Request Message Format (CRMF) [RFC4211] for EncryptedKey and EncryptedValue syntax and Cryptographic Message Syntax (CMS) [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data structure offers the choice to either use EncryptedValue (for backward compatibility only) or EnvelopedData. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. Therefore, it is RECOMMENDED to use EnvelopedData.
Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused here, which makes the update backward compatible. Using the new syntax with the untagged default choice EncryptedValue is bits-on-the-wire compatible with the old syntax.
To indicate support for EnvelopedData, the pvno cmp2021 has been introduced. Details on the usage of the protocol version number (pvno) are described in Section 7.
The EncryptedKey data structure is used in CMP to transport a private key, certificate, or revocation passphrase in encrypted form.
EnvelopedData is used as follows:
-
It contains only one RecipientInfo structure because the content is encrypted only for one recipient.
-
It may contain a private key in the AsymmetricKeyPackage structure, as defined in
[RFC5958], that is wrapped in a SignedData structure, as specified in Section 5 of CMS[RFC5652]and[RFC8933], and signed by the Key Generation Authority. -
It may contain a certificate or revocation passphrase directly in the encryptedContent field.
The content of the EnvelopedData structure, as specified in Section 6 of CMS [RFC5652], MUST be encrypted using a newly generated symmetric content-encryption key. This content-encryption key MUST be securely provided to the recipient using one of three key management techniques.
The choice of the key management technique to be used by the sender depends on the credential available at the recipient:
-
recipient's certificate with an algorithm identifier and a public key that supports key transport and where any given key usage extension allows keyEncipherment: The content-encryption key will be protected using the key transport key management technique, as specified in Section 6.2.1 of CMS
[RFC5652]. -
recipient's certificate with an algorithm identifier and a public key that supports key agreement and where any given key usage extension allows keyAgreement: The content-encryption key will be protected using the key agreement key management technique, as specified in Section 6.2.2 of CMS
[RFC5652]. -
a password or shared secret: The content-encryption key will be protected using the password-based key management technique, as specified in Section 6.2.4 of CMS
[RFC5652].