Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
Extracted elements (28)
Symmetric key-encryption key and password-based key management techniques in CMS are deliberately excluded from this specification because they are already quantum resistant when used with adequate key sizes and quantum-resistant KDFs. The specification focuses only on key transport and key agreement, which are broken by Shor's algorithm.
The mechanism mixes the output of existing key transport or key agreement algorithms with a pre-shared key (PSK) to protect CMS-protected communications from a future large-scale quantum computer. An adversary who stores encrypted traffic today could decrypt it once a quantum computer becomes available; mixing with a PSK whose secrecy does not rely on the broken algorithm closes this window.
The PSK is included directly inside the CMSORIforPSKOtherInfo 'info' structure passed to the KDF rather than as the IKM, so that the PSK is cryptographically bound to the key-encryption algorithm identity and key management type. This prevents cross-context use of a derived key with a different algorithm or key management mode.
Two separate key management techniques are defined — keyTransPSK and keyAgreePSK — rather than one unified approach, because CMS already distinguishes key transport (e.g., RSA encrypt) from key agreement (e.g., ECDH), and each requires a structurally different way to produce the key-derivation key that is subsequently mixed with the PSK.
The version field is always set to 0 in both KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo, even as the syntax may evolve. The document notes that some implementations do not check version numbers before attempting a decode and only check them as part of error handling; this 'forgiving' approach is described as reasonable.
An acceptable KDF MUST accept IKM, L, and info inputs, and all of these inputs MUST influence the output of the KDF. If the KDF requires a salt or other inputs, those MUST be provided as parameters of the KeyDerivationAlgorithmIdentifier.
Cryptographic algorithm implementations SHOULD be modular, allowing new algorithms to be readily inserted, because algorithms become weaker over time as cryptanalysis and computing performance improve.
Implementations MUST accept a KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field; implementations that do not support key agreement algorithms making use of UKMs MUST gracefully handle the presence of UKMs.
Implementations MUST support all three alternatives for specifying the sender's public key in the originator field of KeyAgreePSKRecipientInfo (issuerAndSerialNumber, subjectKeyIdentifier, and originatorKey).
The PSK MUST be distributed to the sender and all recipients by some out-of-band means that does not make it vulnerable to the future invention of a large-scale quantum computer, and an identifier MUST be assigned to the PSK.
The version field of KeyTransPSKRecipientInfo MUST be 0.
An observer can identify which parties share each PSK by watching the PSK key identifiers (pskid) in messages. However, this does not meaningfully worsen privacy compared to baseline CMS, because key transport always exposes RecipientIdentifier and key agreement always exposes IssuerAndSerialNumber or RecipientKeyIdentifier.
The KDF 'info' input is the DER encoding of CMSORIforPSKOtherInfo, a SEQUENCE containing: psk (OCTET STRING with the actual PSK value), keyMgmtAlgType (ENUMERATED: keyTrans=5, keyAgree=10), keyEncryptionAlgorithm (KeyEncryptionAlgorithmIdentifier), pskLength (INTEGER, length of PSK in octets), and kdkLength (INTEGER, length of the key-derivation key in octets). EXPLICIT tagging is used.
The keyAgreePSK technique is identified by id-ori-keyAgreePSK (1.2.840.113549.1.9.16.13.2). The sender establishes a pairwise KEK1 via key agreement, then runs the KDF over the PSK and KEK1 to produce KEK2, which wraps the CEK for each recipient.
The keyTransPSK technique uses the OtherRecipientInfo mechanism (RFC 5652 Section 6.2.5) identified by id-ori-keyTransPSK (1.2.840.113549.1.9.16.13.1). The sender encrypts a randomly generated key-derivation key (KDK) in each recipient's public key, then runs the KDF over the PSK and KDK to produce the key-encryption key (KEK), which wraps the content-encryption key (CEK).
A new IANA registry titled 'SMI Security for S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)' is created. Updates are governed by the Specification Required policy. Initial entries are id-ori-keyTransPSK (arc value 1) and id-ori-keyAgreePSK (arc value 2), both referencing this document.
One OID for the ASN.1 module (id-mod-cms-ori-psk-2019, value 69) was assigned in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry, and the id-ori arc (value 13) was added to the 'SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16)' registry.
Implementations must compute the entire KDF output (the key-encryption key) before outputting any portion of it, and must protect the resulting KEK. Compromise of the KEK may result in disclosure of all CEKs protected with that keying material.
Implementations must protect the PSK, key transport private key, agreement private key, and key-derivation key. Compromise of the PSK alone makes encrypted content vulnerable to a future quantum computer; compromise of PSK plus either private key or KDK may result in disclosure of all protected content.
Implementations must use high-quality random number generators for key-derivation keys, CEKs, and key-pair generation; use of inadequate PRNGs reduces security to the size of the PRNG state space. RFC 4086 guidance applies.
Implementers should not mix quantum-resistant key management algorithms with non-quantum-resistant counterparts on the same content — e.g., a message should not be protected by both KeyTransRecipientInfo and KeyTransPSKRecipientInfo simultaneously, as this makes the content vulnerable to a future quantum computer.
Implementers should not send the same content in different messages, one using a quantum-resistant key management algorithm and one using a non-quantum-resistant algorithm, even with independently generated CEKs, because an eavesdropper may correlate the messages and exploit the weaker one.
The key-encryption algorithm must be as strong or stronger than the content-encryption algorithm; if the CEK is protected with 256-bit AES but wrapped with 128-bit AES, only 128 bits of protection are provided. Implementers must ensure matching algorithm strengths.
The PSK needs at least 256 bits of entropy to provide 128 bits of security, because a large-scale quantum computer effectively halves the security of symmetric keys. To match, the KDF must be quantum resistant and produce a key-encryption key of at least 256 bits, and the CEK must also be at least 256 bits.
Using a recipient's public key for both traditional CMS and the PSK-mixing variation violates the cryptographic hygiene principle of single-purpose keys. While no known attack exploits this, applications should enforce key separation wherever possible, potentially via an X.509 extended key usage OID.
When a PSK is shared among a group, group members can record each other's traffic and decrypt it if they ever gain access to a large-scale quantum computer. Large groups also increase the risk of PSK theft; once an attacker obtains the PSK, stored traffic becomes vulnerable if the attacker later acquires a quantum computer.
KeyAgreePSKRecipientInfo is a SEQUENCE containing: version (CMSVersion, always 0), pskid (PreSharedKeyIdentifier OCTET STRING), originator ([0] EXPLICIT OriginatorIdentifierOrKey), ukm ([1] EXPLICIT UserKeyingMaterial OPTIONAL), kdfAlgorithm (KeyDerivationAlgorithmIdentifier), keyEncryptionAlgorithm (KeyEncryptionAlgorithmIdentifier), and recipientEncryptedKeys (RecipientEncryptedKeys).
KeyTransPSKRecipientInfo is a SEQUENCE containing: version (CMSVersion, always 0), pskid (PreSharedKeyIdentifier OCTET STRING), kdfAlgorithm (KeyDerivationAlgorithmIdentifier), keyEncryptionAlgorithm (KeyEncryptionAlgorithmIdentifier), ktris (SEQUENCE OF KeyTransRecipientInfo, each carrying the encrypted KDK rather than the CEK), and encryptedKey (EncryptedKey OCTET STRING, the wrapped CEK).