Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)
Extracted elements (24)
PKCS #1 Version 1.5 key transport is vulnerable to adaptive chosen ciphertext attacks (the 'Million Message Attack'), requiring hundreds of thousands of oracle queries to exploit. RSAES-OAEP was adopted as an improved cryptographic technique to resolve this vulnerability rather than embedding countermeasures within protocols.
The id-RSAES-OAEP OID in the subject public key information allows certificate users to determine that the RSA private key owner intends the public key exclusively for RSAES-OAEP, enabling enforcement of the security recommendation to use RSA key pairs for only one scheme.
PKCS #1 Version 1.5 and PKCS #1 Version 2.1 require the same RSA public key information, so a certified RSA public key may be used with either RSA key transport technique. The choice of OID in the certificate signals which technique the key owner intends.
Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in CMS Section 6. A content-encryption key MUST be randomly generated for each instance of an enveloped-data content type.
If a keyUsage extension is present in a certificate conveying an RSA public key with the id-RSAES-OAEP OID, the extension MUST contain keyEncipherment and/or dataEncipherment, but both SHOULD NOT be present simultaneously.
Implementations MUST represent encoding parameter P using id-pSpecified with an OCTET STRING, MUST support a zero length P value, and encryptors MUST omit pSourceFunc when P is zero length. Decryptors MUST recognize both the explicit OID and an absent pSourceFunc as indicating zero length P.
Implementations MUST support MGF1 for maskGenFunc and MUST support SHA-1 within MGF1. Encryptors MUST omit maskGenFunc when MGF1 with SHA-1 is used; decryptors MUST recognize both the explicit OIDs and an absent maskGenFunc field as indicating MGF1 with SHA-1.
Implementations MUST support SHA-1 for hashFunc and MAY support other hash functions. Implementations that perform encryption MUST omit the hashFunc field when SHA-1 is used; implementations that perform decryption MUST recognize both the id-sha1 OID and an absent hashFunc field as indicating SHA-1.
The EnvelopedData version MUST be 0, 2, or 3 when RSAES-OAEP key transport is employed. The EnvelopedData recipientInfos CHOICE MUST be KeyTransRecipientInfo, and the encryptedContentInfo contentEncryptionAlgorithm field MUST be a symmetric encryption algorithm identifier.
The KeyTransRecipientInfo version MUST be 0 or 2: version MUST be 0 if RecipientIdentifier uses issuerAndSerialNumber, and version MUST be 2 if RecipientIdentifier uses subjectKeyIdentifier.
The recipient's certificate MUST contain an RSA public key, and the RSA public key MUST be at least 1024 bits in length for encrypting the content-encryption key.
When all RSAES-OAEP defaults are selected, the SMIMECapability SEQUENCE MUST include id-RSAES-OAEP in capabilityID and MUST include an empty SEQUENCE in the parameters field, DER-encoded as: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00.
When rsaEncryption OID is used (non-exclusive RSAES-OAEP use), the algorithm field MUST use rsaEncryption and the parameters field MUST contain NULL.
When the RSA private key owner wishes to limit public key use exclusively to RSAES-OAEP, the id-RSAES-OAEP OID MUST be used in the subject public key information algorithm field, and the parameters field MUST contain RSAES-OAEP-params. Certificate users MUST then only use the key for RSAES-OAEP operations with the parameters identified in the certificate.
When using a Triple-DES content-encryption key, implementations MUST adjust the parity bits to ensure odd parity for each octet of each DES key comprising the Triple-DES key prior to RSAES-OAEP encryption.
The RSAES-OAEP algorithm is identified by OID id-RSAES-OAEP { pkcs-1 7 }. The AlgorithmIdentifier parameters field MUST be present and MUST contain RSAES-OAEP-params, a SEQUENCE with hashFunc, maskGenFunc, and pSourceFunc fields, each with SHA-1-based defaults.
No new IANA registries are created by this document. All OIDs used were assigned in PKCS documents or by NIST. No further action by IANA is necessary.
A 1024-bit RSA key and SHA-1 each provide approximately 80 bits of security, which NIST considered adequate until 2015. For higher security, longer RSA keys and hash functions with longer outputs (SHA-256, SHA-384, SHA-512) are needed; the hash value bit length should be at least twice the desired security level in bits.
Compromise of the RSA private key may result in disclosure of all messages protected with that key; compromise of the content-encryption key may result in disclosure of the associated encrypted content. Implementations must protect both keys.
Good cryptographic practice employs a given RSA key pair in only one scheme to avoid cross-scheme vulnerabilities. An RSA key pair used for RSAES-OAEP key transport should not be used for other purposes (e.g., digital signatures), and one RSA key pair should always be used with the same RSAES-OAEP parameters.
The same one-way hash function should be employed for both hashFunc and maskGenFunc to reduce the potential for implementation errors, though this is not required by the specification.
Use of inadequate pseudo-random number generators (PRNGs) for RSA key generation can result in little or no security; an attacker may reproduce the PRNG environment and search a small key space rather than brute-forcing. RFC 1750 provides guidance on quality random number generation.
RSAES-OAEP-params is encoded as an ASN.1 SEQUENCE with three optional fields: hashFunc [0] (default sha1Identifier), maskGenFunc [1] (default mgf1SHA1Identifier), and pSourceFunc [2] (default pSpecifiedEmptyIdentifier with empty OCTET STRING). All three fields are omitted when defaults are used.
The RSA public key MUST be encoded as RSAPublicKey ::= SEQUENCE { modulus INTEGER, publicExponent INTEGER }, carried as a DER-encoded BIT STRING in the subjectPublicKey field of subject public key information.