Certificate Management Protocol (CMP) Algorithms
updates
- rfc-4210 — Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
Extracted elements (31)
PBMAC1 is preferred over PasswordBasedMac because PasswordBasedMac is essentially PBKDF1 (not recommended for new applications by FIPS and standards bodies), whereas PBMAC1 uses PBKDF2 which has an improved iterated hashing construct and removes the key-size limitation tied to the underlying hash function output length.
The algorithm profile in this document updates Appendix D.2 of RFC 4210 to replace deprecated algorithms (3-DES, DSA, MD5/SHA-1 combinations, RC5, CAST-128) with modern equivalents, making AES-CBC and PBMAC1 mandatory instead of 3-DES and X9.9, to address weakening cryptographic strength over time.
Older CMP implementations conforming to the algorithm profile from Appendix D.2 of RFC 4210 may still be in use. Weakened algorithms should be disabled, and if critical systems cannot be immediately updated, a migration plan should be adopted as soon as possible.
AES-GMAC MUST NOT be used twice with the same parameter set (especially the same nonce), and therefore MUST NOT be used together with PBKDF2.
DH key agreement SHALL be used only in ephemeral-static variants; static-static variants SHALL NOT be used.
ECDH key agreement SHALL be used only in the ephemeral-static or 1-Pass ECMQV variants; static-static variants SHALL NOT be used.
Ed25519 MUST be used with SHA-512, and Ed448 MUST be used with SHAKE256 message digest algorithms.
For the RFC 4210 Appendix D.2 algorithm profile, RSA (sha256WithRSAEncryption, 2048-bit) is mandatory for MSG_SIG_ALG; PBMAC1 is mandatory for MSG_MAC_ALG; DH is mandatory for PROT_ENC_ALG; AES-wrap is mandatory for SYM_PENC_ALG; and AES-CBC is mandatory for PROT_SYM_ALG.
If an implementation intends to enroll and manage certificates for keys of a specific security level, it SHALL implement and use algorithms of at least that strength for the respective PKI management operation.
It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac for MAC-based CMP message protection.
The hash algorithm used to calculate the certHash in certConf messages MUST be SHA-512 if the certificate was signed using Ed25519, or SHAKE256 with d=512 if signed using Ed448.
The key sizes for the AES key-wrap algorithm and the content-encryption algorithm MUST be the same (e.g., AES-128 key wrap with AES-128 content-encryption).
When SHAKE is used in CMP as a message digest algorithm, the output length MUST be 256 bits for SHAKE128 and 512 bits for SHAKE256.
When using AES-GMAC with PBMAC1, it MUST be ensured that AES-GMAC is used only as the message authentication scheme and not for the key derivation function PBKDF2.
When using the password-based key management technique with PKIProtection based on MAC, the salt for the password-based MAC and KDF must be chosen independently to ensure usage of independent symmetric keys.
AES-CBC (id-aes128-CBC, id-aes192-CBC, id-aes256-CBC) is specified as the content-encryption algorithm for CMS EnvelopedData, used to transport private key packages, implicit PoP certificates, or encrypted revocation passphrases.
AES-GMAC (id-aes128-GMAC, id-aes192-GMAC, id-aes256-GMAC) is specified as a symmetric key-based MAC for CMP message protection but must never be reused with the same nonce and must not be used as the PRF in PBKDF2.
AES Key Wrap algorithms (id-aes128-wrap, id-aes192-wrap, id-aes256-wrap) are specified as symmetric key-encryption algorithms for use with key agreement and password-based key management in CMS EnvelopedData.
ECDH key agreement supports NIST SECP curves (id-X25519, id-X448 for curve25519/curve448) and covers ephemeral-static DH and 1-Pass ECMQV variants via OIDs in the certicom schemes arc.
ECDSA signature algorithms are specified with SHA2 (ecdsa-with-SHA224/256/384/512) and with SHAKE (id-ecdsa-with-shake128/shake256), usable with NIST-recommended curves secp192r1 through secp521r1.
EdDSA algorithms Ed25519 (id-Ed25519, OID thawte 101 112) and Ed448 (id-Ed448, OID thawte 101 113) are specified as signature algorithms for CMP, with mandatory hash pairings.
PasswordBasedMac (id-PasswordBasedMac) is a legacy MAC algorithm combining PBKDF1-derived keys with HMAC, carried in the protectionAlg field of PKIHeader; it is optional in the updated profile and should be replaced by PBMAC1.
PBKDF2 (id-PBKDF2) is the specified key derivation algorithm for use with CMS EnvelopedData password-based key management, carried in the keyDerivationAlgorithm field of PasswordRecipientInfo.
PBMAC1 (id-PBMAC1) combines PBKDF2 with a symmetric MAC (e.g., HMAC-SHA256) and is the mandatory MAC protection algorithm in the updated RFC 4210 profile, carried in the protectionAlg field of PKIHeader.
RSA signature algorithms supported include RSASSA-PSS (with SHA2 via id-RSASSA-PSS and with SHAKE via id-RSASSA-PSS-SHAKE128/SHAKE256) and PKCS #1 v1.5 (sha224/256/384/512WithRSAEncryption); DSA and MD5/SHA-1 combinations are deprecated.
SHA-224, SHA-256, SHA-384, and SHA-512 are specified for use in CMP as message digest algorithms, carried in fields such as hashAlg of OOBCertHash/CertStatus, owf of Challenge/PBMParameter, and digestAlgorithm of SignerInfo.
SHAKE-based KMAC algorithms (id-KMACWithSHAKE128, id-KMACWithSHAKE256) are specified as optional symmetric MAC algorithms for CMP message protection and for use as the PRF in PBKDF2.
SHAKE128 and SHAKE256 are specified as extendable-output functions usable in CMP as one-way hash functions; their OIDs are id-shake128 and id-shake256 under the NIST algorithm arc.
AES-GMAC MUST NOT be used as the pseudorandom function (PRF) in PBKDF2 because reusing AES-GMAC with the same key and nonce breaks its security guarantees.
Symmetric key-based MAC algorithms MAY be used as MSG_MAC_ALG, but the implementer MUST choose a suitable PRF and ensure the key has sufficient entropy to match the overall security level of the algorithm profile.
The overall security of a CMP implementation is bounded by the weakest algorithm in the profile and the entropy of shared secret information; all components (message protection, key management, content encryption) must be at least as strong as the certificates being managed.