Cryptographic Message Syntax (CMS) Algorithms
obsoletes
updated by
Extracted elements (29)
Algorithm specifications were separated from the CMS protocol document (RFC 3369 obsoletes RFC 2630's protocol; RFC 3370 covers algorithms) so that each can be updated independently without impacting the other. Additional algorithm conventions are expected in separate documents.
RC2 effective-key-bits values (40, 64, 128) map to non-intuitive RC2ParameterVersion integers (160, 120, 58) rather than directly encoding the key length. The value 160 requires two octets because 0xA0 would be interpreted as a negative number in BER.
Static-Static D-H mandates ukm (unlike Ephemeral-Static where it is optional) because the same static key pair is reused across multiple messages. Without ukm, every message between the same sender and recipient would generate the same key-encryption key.
HMAC with SHA-1 AlgorithmIdentifier parameters suffer the same historical ambiguity as SHA-1: some implementations encode NULL while others omit parameters entirely due to the 1988-to-1997 ASN.1 translation defect.
SHA-1 AlgorithmIdentifier parameters may be absent or encoded as NULL because when the 1988 ASN.1 syntax was translated to 1997 syntax, the OPTIONAL qualifier was lost and later recovered via a defect report, by which time many implementations had already encoded parameters as mandatory NULL.
CMS implementations supporting RSA (PKCS #1 v1.5) signatures MUST implement SHA-1, MUST support the rsaEncryption signature value algorithm identifier, and SHOULD also support MD5. The rsaEncryption, sha1WithRSAEncryption, and md5WithRSAEncryption AlgorithmIdentifier parameters fields MUST be NULL.
DSA MUST be used with SHA-1. When id-dsa-with-sha1 is used, the AlgorithmIdentifier parameters field MUST be absent. DSA parameters (p, q, g) in the certificate AlgorithmIdentifier are optional; if absent the subject uses the same parameters as the issuer.
For HMAC with SHA-1, implementations MUST accept AlgorithmIdentifiers with absent parameters and MUST accept those with NULL parameters. Implementations SHOULD generate HMAC-SHA1 AlgorithmIdentifiers with absent parameters.
For MD5, the AlgorithmIdentifier parameters field MUST be present and MUST contain NULL. Implementations MAY also accept absent parameters.
For X9.42 Ephemeral-Static D-H: version MUST be 3; originator MUST be the originatorKey alternative with dh-public-number OID and absent parameters containing the sender's ephemeral public key; keyEncryptionAlgorithm MUST be id-alg-ESDH with KeyWrapAlgorithm parameter present.
For X9.42 Static-Static D-H: version MUST be 3; originator MUST be issuerAndSerialNumber or subjectKeyIdentifier; ukm MUST be present to ensure a different key-encryption key per message; keyEncryptionAlgorithm MUST be id-alg-SSDH with KeyWrapAlgorithm parameter present.
If a CMS implementation chooses to support any algorithm described in this document, it MUST do so exactly as described. Implementations may also support other algorithms not covered here.
Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters and MUST accept those with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters.
When a key agreement algorithm is used, a key-encryption algorithm MUST be provided for each content-encryption algorithm. For RC2 key agreement, 128 bits MUST be generated as input to the key expansion process.
When RC2 is used as a symmetric key-encryption key, 128-bit keys MUST be used and they MUST be used with RC2ParameterVersion set to 58.
When using RSA key transport (PKCS #1 v1.5) with a Triple-DES content-encryption key, implementations MUST adjust the parity bits for each DES key comprising the Triple-DES key prior to RSA encryption.
PBKDF2 parameters are encoded as PBKDF2-params ::= SEQUENCE { salt CHOICE { specified OCTET STRING, otherSource AlgorithmIdentifier }, iterationCount INTEGER, keyLength INTEGER OPTIONAL, prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }. The salt MUST use the specified OCTET STRING alternative.
The SHA-1 message digest algorithm identifier is sha-1 OID { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }. It appears in SignedData digestAlgorithms, SignerInfo digestAlgorithm, DigestedData digestAlgorithm, and AuthenticatedData digestAlgorithm fields.
Implementations must protect the signer's private key and all key management private keys. Compromise of a private key permits masquerade; compromise of a key-encryption key may reveal all content protected with it.
Implementations must use quality random number generation for content-encryption keys, message-authentication keys, IVs, one-time DSA k values, and key pairs. Inadequate PRNGs can reduce security to near zero by enabling an attacker to reproduce the PRNG state and search a small key space.
RSA (PKCS #1 v1.5) is vulnerable to adaptive chosen ciphertext attacks requiring access to a decryption oracle for hundreds of thousands of ciphertexts. The attack is more feasible for interactive request-response environments than for store-and-forward S/MIME. OAEP (PKCS #1 v2.0) or RFC 3218 countermeasures are recommended.
The key management technique used to distribute message-authentication keys must itself provide authentication. Neither RSA (PKCS#1) nor Ephemeral-Static D-H provide data origin authentication; Static-Static D-H does, when both parties' public keys are bound to identities in X.509 certificates.
When key-encryption and content-encryption algorithms differ in strength, effective security is determined by the weaker algorithm. For example, wrapping a 168-bit Triple-DES key with a 40-bit RC2 key-encryption key yields only 40 bits of protection. Key-encryption algorithms must be at least as strong as the content-encryption algorithm.
When more than two parties share the same message-authentication key, data origin authentication is not provided because any party knowing the key can compute a valid MAC for content it did not originate.
DSA signature values r and s are encoded as Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }. DSA public key Y is encoded as an INTEGER (Dss-Pub-Key). Domain parameters use Dss-Parms ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER }.
RC2 CBC content encryption uses rc2-cbc OID with RC2CBCParameter ::= SEQUENCE { rc2ParameterVersion INTEGER, iv OCTET STRING } where iv is exactly 8 octets. The rc2ParameterVersion encodes effective-key-bits using the same non-linear mapping as the key wrap parameter (40→160, 64→120, 128→58).
RC2 key wrap uses RC2wrapParameter ::= RC2ParameterVersion (INTEGER). Effective-key-bits 40, 64, and 128 map to RC2ParameterVersion values 160, 120, and 58 respectively. The value 160 must be encoded as two octets (00 A0) because the single-octet encoding (A0) is negative in BER.
RSA public key is encoded as RSAPublicKey ::= SEQUENCE { modulus INTEGER, publicExponent INTEGER }. The rsaEncryption algorithm identifier OID is { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }.
Triple-DES CBC content encryption uses des-ede3-cbc OID with CBCParameter ::= IV where IV ::= OCTET STRING of exactly 8 octets. The AlgorithmIdentifier parameters field MUST be present.