rfc9481.original   rfc9481.txt 
LAMPS Working Group H. Brockhaus, Ed. Internet Engineering Task Force (IETF) H. Brockhaus
Internet-Draft H. Aschauer Request for Comments: 9481 H. Aschauer
Updates: 4210 (if approved) Siemens Updates: 4210 Siemens
Intended status: Standards Track M. Ounsworth Category: Standards Track M. Ounsworth
Expires: 4 December 2022 J. Gray ISSN: 2070-1721 J. Gray
Entrust Entrust
2 June 2022 October 2023
Certificate Management Protocol (CMP) Algorithms Certificate Management Protocol (CMP) Algorithms
draft-ietf-lamps-cmp-algorithms-15
Abstract Abstract
This document describes the conventions for using several This document describes the conventions for using several
cryptographic algorithms with the Certificate Management Protocol cryptographic algorithms with the Certificate Management Protocol
(CMP). CMP is used to enroll and further manage the lifecycle of (CMP). CMP is used to enroll and further manage the lifecycle of
X.509 certificates. This document also updates the algorithm use X.509 certificates. This document also updates the algorithm use
profile from RFC 4210 Appendix D.2. profile from Appendix D.2 of RFC 4210.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 4 December 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9481.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 2. Message Digest Algorithms
2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. SHA2
2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SHAKE
3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 3. Signature Algorithms
3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. RSA
3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. ECDSA
3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. EdDSA
4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 8 4. Key Management Algorithms
4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 4.1. Key Agreement Algorithms
4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 4.1.1. Diffie-Hellman
4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. ECDH
4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 4.2. Key Transport Algorithms
4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. RSA
4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 4.3. Symmetric Key-Encryption Algorithms
4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 4.3.1. AES Key Wrap
4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 4.4. Key Derivation Algorithms
4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. PBKDF2
5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 13 5. Content-Encryption Algorithms
5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. AES-CBC
6. Message Authentication Code Algorithms . . . . . . . . . . . 14 6. Message Authentication Code Algorithms
6.1. Password-Based MAC . . . . . . . . . . . . . . . . . . . 14 6.1. Password-Based MAC
6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 6.1.1. PasswordBasedMac
6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. PBMAC1
6.2. Symmetric Key-Based MAC . . . . . . . . . . . . . . . . . 15 6.2. Symmetric Key-Based MAC
6.2.1. SHA2-Based HMAC . . . . . . . . . . . . . . . . . . . 15 6.2.1. SHA2-Based HMAC
6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16 6.2.2. AES-GMAC
6.2.3. SHAKE-Based KMAC . . . . . . . . . . . . . . . . . . 16 6.2.3. SHAKE-Based KMAC
7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17 7. Algorithm Use Profiles
7.1. Algorithm Profile for RFC 4210 PKI Management Message 7.1. Algorithm Profile for PKI Management Message Profiles in
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 RFC 4210
7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22 7.2. Algorithm Profile for Lightweight CMP Profile
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. References
11. Normative References . . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References
12. Informative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References
Appendix A. History of Changes . . . . . . . . . . . . . . . . . 29 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses
1. Introduction 1. Introduction
RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, Appendix D.2 of [RFC4210] contains a set of algorithms that is
mandatory to be supported by conforming implementations. These mandatory to be supported by implementations conforming to [RFC4210].
algorithms were appropriate at the time CMP was released, but as These algorithms were appropriate at the time CMP was released, but
cryptographic algorithms weaken over time, some of them should not be as cryptographic algorithms weaken over time, some of them should no
used anymore. In general, new attacks are emerging due to research longer be used. In general, new attacks are emerging due to research
cryptoanalysis or increase in computing power. New algorithms were in cryptanalysis or an increase in computing power. New algorithms
introduced that are more resistant to today's attacks. were introduced that are more resistant to today's attacks.
This document lists current cryptographic algorithms usable with CMP This document lists current cryptographic algorithms that can be used
to offer an easier way maintaining the list of suitable algorithms with CMP to offer an easier way to maintain the list of suitable
over time. algorithms over time.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In the following sections ASN.1 values and types are used to indicate In the following sections, ASN.1 values and types are used to
where algorithm identifier and output values are provided. These indicate where algorithm identifier and output values are provided.
ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211], These ASN.1 values and types are defined in CMP [RFC4210],
CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652]. Certificate Request Message Format (CRMF) [RFC4211], CMP Updates
[RFC9480], and Cryptographic Message Syntax (CMS) [RFC5652].
2. Message Digest Algorithms 2. Message Digest Algorithms
This section provides references to object identifiers and This section provides references to object identifiers and
conventions to be employed by CMP implementations that support SHA2 conventions to be employed by CMP implementations that support SHA2
or SHAKE message digest algorithms. or SHAKE message digest algorithms.
Digest algorithm identifiers are located in: Digest algorithm identifiers are located in the:
* hashAlg field of OOBCertHash and CertStatus * hashAlg field of OOBCertHash and CertStatus,
* owf field of Challenge, PBMParameter, and DHBMParameter * owf field of Challenge, PBMParameter, and DHBMParameter,
* digestAlgorithms field of SignedData * digestAlgorithms field of SignedData, and
* digestAlgorithm field of SignerInfo * digestAlgorithm field of SignerInfo.
Digest values are located in: Digest values are located in the:
* hashVal field of OOBCertHash * hashVal field of OOBCertHash,
* certHash field of CertStatus * certHash field of CertStatus, and
* witness field of Challenge * witness field of Challenge.
In addition, digest values are input to signature algorithms. In addition, digest values are input to signature algorithms.
2.1. SHA2 2.1. SHA2
The SHA2 algorithm family is defined in FIPS Pub 180-4 The SHA2 algorithm family is defined in FIPS Pub 180-4
[NIST.FIPS.180-4]. [NIST.FIPS.180-4].
The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512
are identified by the following OIDs: are identified by the following OIDs:
skipping to change at page 4, line 29 skipping to change at line 162
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 1 } hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 2 } hashalgs(2) 2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
hashalgs(2) 3 } hashalgs(2) 3 }
Specific conventions to be considered are specified in RFC 5754 Specific conventions to be considered are specified in Section 2 of
Section 2 [RFC5754]. [RFC5754].
2.2. SHAKE 2.2. SHAKE
The SHA-3 family of hash functions is defined in FIPS Pub 202 The SHA-3 family of hash functions is defined in FIPS Pub 202
[NIST.FIPS.202] and includes fixed output length variants SHA3-224, [NIST.FIPS.202] and consists of the fixed output length variants
SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output SHA3-224, SHA3-256, SHA3-384, and SHA3-512, as well as the
functions (SHAKEs) SHAKE128 and SHAKE256. Currently, SHAKE128 and extendable-output functions (XOFs) SHAKE128 and SHAKE256. Currently,
SHAKE256 are the only members of the SHA3-family which are specified SHAKE128 and SHAKE256 are the only members of the SHA3-family that
for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way are specified for use in X.509 certificates [RFC8692] and CMS
hash function for use with RSASSA-PSS and ECDSA. [RFC8702] as one-way hash functions for use with RSASSA-PSS and
ECDSA.
SHAKE is an extendable-output function and FIPS Pub 202 SHAKE is an extendable-output function, and FIPS Pub 202
[NIST.FIPS.202] prohibits using SHAKE as general-purpose hash [NIST.FIPS.202] prohibits using SHAKE as a general-purpose hash
function. When SHAKE is used in CMP as a message digest algorithm, function. When SHAKE is used in CMP as a message digest algorithm,
the output length MUST be 256 bits for SHAKE128 and 512 bits for the output length MUST be 256 bits for SHAKE128 and 512 bits for
SHAKE256. SHAKE256.
The message digest algorithms SHAKE128 and SHAKE256 are identified by The message digest algorithms SHAKE128 and SHAKE256 are identified by
the following OIDs: the following OIDs:
id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
hashalgs(2) 11 } hashalgs(2) 11 }
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
hashalgs(2) 12 } hashalgs(2) 12 }
Specific conventions to be considered are specified in RFC 8702 Specific conventions to be considered are specified in Section 3.1 of
Section 3.1 [RFC8702]. [RFC8702].
3. Signature Algorithms 3. Signature Algorithms
This section provides references to object identifiers and This section provides references to object identifiers and
conventions to be employed by CMP implementations that support RSA, conventions to be employed by CMP implementations that support
ECDSA, or EdDSA signature algorithms. signature algorithms like RSA, ECDSA, or EdDSA.
The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, The signature algorithm is referred to as MSG_SIG_ALG in Appendices D
RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP and E of [RFC4210], in the Lightweight CMP Profile [RFC9483], and in
Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Section 7.2.
Signature algorithm identifiers are located in: Signature algorithm identifiers are located in the:
* protectionAlg field of PKIHeader * protectionAlg field of PKIHeader,
* algorithmIdentifier field of POPOSigningKey * algorithmIdentifier field of POPOSigningKey, and
* signatureAlgorithm field of CertificationRequest, * signatureAlgorithm field of CertificationRequest,
SignKeyPairTypes, and SignerInfo SignKeyPairTypes, and SignerInfo
Signature values are located in: Signature values are located in the:
* protection field of PKIMessage * protection field of PKIMessage,
* signature field of POPOSigningKey * signature field of POPOSigningKey, and
* signature field of CertificationRequest and SignerInfo * signature field of CertificationRequest and SignerInfo.
3.1. RSA 3.1. RSA
The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is The RSA (RSASSA-PSS and PKCS #1 version 1.5) signature algorithm is
defined in RFC 8017 [RFC8017]. defined in [RFC8017].
The algorithm identifier for RSASAA-PSS signatures used with SHA2 The algorithm identifier for RSASAA-PSS signatures used with SHA2
message digest algorithms is identified by the following OID: message digest algorithms is identified by the following OID:
id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
Specific conventions to be considered are specified in RFC 4056 Specific conventions to be considered are specified in [RFC4056].
[RFC4056].
The signature algorithm RSASSA-PSS used with SHAKE message digest The signature algorithm RSASSA-PSS used with SHAKE message digest
algorithms are identified by the following OIDs: algorithms is identified by the following OIDs:
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 30 } mechanisms(5) pkix(7) algorithms(6) 30 }
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 31 } mechanisms(5) pkix(7) algorithms(6) 31 }
Specific conventions to be considered are specified in RFC 8702 Specific conventions to be considered are specified in Section 3.2.1
Section 3.2.1 [RFC8702]. of [RFC8702].
The signature algorithm PKCS#1 version 1.5 used with SHA2 message The signature algorithm PKCS #1 version 1.5 used with SHA2 message
digest algorithms is identified by the following OIDs: digest algorithms is identified by the following OIDs:
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 }
Specific conventions to be considered are specified in RFC 5754 Specific conventions to be considered are specified in Section 3.2 of
Section 3.2 [RFC5754]. [RFC5754].
3.2. ECDSA 3.2. ECDSA
The ECDSA signature algorithm is defined in FIPS Pub 186-4 The ECDSA signature algorithm is defined in FIPS Pub 186-5
[NIST.FIPS.186-4]. [NIST.FIPS.186-5].
The signature algorithm ECDSA used with SHA2 message digest The signature algorithm ECDSA used with SHA2 message digest
algorithms is identified by the following OIDs: algorithms is identified by the following OIDs:
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves As specified in [RFC5480], the NIST-recommended curves are identified
are identified by the following OIDs: by the following OIDs:
secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } us(840) ansi-X9-62(10045) curves(3) prime(1) 1 }
secp224r1 OBJECT IDENTIFIER ::= { iso(1) secp224r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 33 } identified-organization(3) certicom(132) curve(0) 33 }
secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }
secp384r1 OBJECT IDENTIFIER ::= { iso(1) secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 } identified-organization(3) certicom(132) curve(0) 34 }
secp521r1 OBJECT IDENTIFIER ::= { iso(1) secp521r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 35 } identified-organization(3) certicom(132) curve(0) 35 }
Specific conventions to be considered are specified in RFC 5754 Specific conventions to be considered are specified in Section 3.3 of
Section 3.3 [RFC5754]. [RFC5754].
The signature algorithm ECDSA used with SHAKE message digest The signature algorithm ECDSA used with SHAKE message digest
algorithms are identified by the following OIDs: algorithms is identified by the following OIDs:
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 32 } mechanisms(5) pkix(7) algorithms(6) 32 }
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 33 } mechanisms(5) pkix(7) algorithms(6) 33 }
Specific conventions to be considered are specified in RFC 8702 Specific conventions to be considered are specified in Section 3.2.2
Section 3.2.2 [RFC8702]. of [RFC8702].
3.3. EdDSA 3.3. EdDSA
The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 The EdDSA signature algorithm is defined in Section 3.3 of [RFC8032]
[RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. and FIPS Pub 186-5 [NIST.FIPS.186-5].
The signature algorithm Ed25519 that MUST be used with SHA-512 The signature algorithm Ed25519 that MUST be used with SHA-512
message digest algorithms is identified by the following OIDs: message digest algorithms is identified by the following OIDs:
id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) id-Ed25519 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 112 } identified-organization(3) thawte(101) 112 }
The signature algorithm Ed448 that MUST be used with SHAKE256 message The signature algorithm Ed448 that MUST be used with SHAKE256 message
digest algorithms is identified by the following OIDs: digest algorithms is identified by the following OIDs:
id-Ed448 OBJECT IDENTIFIER ::= { iso(1) id-Ed448 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 113 } identified-organization(3) thawte(101) 113 }
Specific conventions to be considered are specified in RFC 8419 Specific conventions to be considered are specified in [RFC8419].
[RFC8419].
Note: The hash algorithm used to calculate the certHash in certConf Note: The hash algorithm used to calculate the certHash in certConf
messages MUST be SHA512 if the certificate to be confirmed has been messages MUST be SHA512 if the certificate to be confirmed has been
signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. signed using Ed25519 or SHAKE256 with d=512 if the certificate to be
confirmed has been signed using Ed448.
4. Key Management Algorithms 4. Key Management Algorithms
CMP utilizes the following general key management techniques: key CMP utilizes the following general key management techniques: key
agreement, key transport, and passwords. agreement, key transport, and passwords.
CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes CRMF [RFC4211] and CMP Updates [RFC9480] promote the use of CMS
the use of CMS [RFC5652] EnvelopedData by deprecating the use of EnvelopedData [RFC5652] by deprecating the use of EncryptedValue.
EncryptedValue.
4.1. Key Agreement Algorithms 4.1. Key Agreement Algorithms
The key agreement algorithm is referred to as PROT_ENC_ALG in The key agreement algorithm is referred to as PROT_ENC_ALG in
RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the Appendices D and E of [RFC4210] and as KM_KA_ALG in the Lightweight
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as CMP Profile [RFC9483] and Section 7.
well as in Section 7.
Key agreement algorithms are only used in CMP when using CMS Key agreement algorithms are only used in CMP when using CMS
[RFC5652] EnvelopedData together with the key agreement key EnvelopedData [RFC5652] together with the key agreement key
management technique. When a key agreement algorithm is used, a key- management technique. When a key agreement algorithm is used, a key-
encryption algorithm (Section 4.3) is needed next to the content- encryption algorithm (Section 4.3) is needed next to the content-
encryption algorithm (Section 5). encryption algorithm (Section 5).
Key agreement algorithm identifiers are located in: Key agreement algorithm identifiers are located in the:
* keyEncryptionAlgorithm field of KeyAgreeRecipientInfo * keyEncryptionAlgorithm field of KeyAgreeRecipientInfo.
Key wrap algorithm identifiers are located in: Key wrap algorithm identifiers are located in the:
* KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of * KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of
KeyAgreeRecipientInfo KeyAgreeRecipientInfo.
Wrapped content-encryption keys are located in: Wrapped content-encryption keys are located in the:
* encryptedKey field of RecipientEncryptedKeys * encryptedKey field of RecipientEncryptedKeys.
4.1.1. Diffie-Hellman 4.1.1. Diffie-Hellman
Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and The Diffie-Hellman (DH) key agreement is defined in [RFC2631] and
SHALL be used in the ephemeral-static as specified in RFC 3370 SHALL be used in the ephemeral-static variants, as specified in
[RFC3370]. Static-static variants SHALL NOT be used. [RFC3370]. Static-static variants SHALL NOT be used.
The Diffie-Hellman key agreement algorithm is identified by the The DH key agreement algorithm is identified by the following OID:
following OID:
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
Specific conventions to be considered are specified in RFC 3370 Specific conventions to be considered are specified in Section 4.1 of
Section 4.1 [RFC3370]. [RFC3370].
4.1.2. ECDH 4.1.2. ECDH
Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in The Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in
RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant [RFC5753] and SHALL be used in the ephemeral-static variant, as
as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as specified in [RFC5753], or the 1-Pass Elliptic Curve Menezes-Qu-
specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be Vanstone (ECMQV) variant, as specified in [RFC5753]. Static-static
used. variants SHALL NOT be used.
The ECDH key agreement algorithm used together with NIST-recommended The ECDH key agreement algorithm used together with NIST-recommended
SECP curves are identified by the following OIDs: SECP curves are identified by the following OIDs:
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 0 } identified-organization(3) certicom(132) schemes(1) 11(11) 0 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 1 } identified-organization(3) certicom(132) schemes(1) 11(11) 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 2 } identified-organization(3) certicom(132) schemes(1) 11(11) 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 11(11) 3 } identified-organization(3) certicom(132) schemes(1) 11(11) 3 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 0 } 14(14) 0 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 1 } 14(14) 1 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 2 } 14(14) 2 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) iso(1) identified-organization(3) certicom(132) schemes(1)
14(14) 3 } 14(14) 3 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 0 } identified-organization(3) certicom(132) schemes(1) 15(15) 0 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 1 } identified-organization(3) certicom(132) schemes(1) 15(15) 1 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 2 } identified-organization(3) certicom(132) schemes(1) 15(15) 2 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) schemes(1) 15(15) 3 } identified-organization(3) certicom(132) schemes(1) 15(15) 3 }
As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves As specified in [RFC5480], the NIST-recommended SECP curves are
are identified by the following OIDs: identified by the following OIDs:
secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } us(840) ansi-X9-62(10045) curves(3) prime(1) 1 }
secp224r1 OBJECT IDENTIFIER ::= { iso(1) secp224r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 33 } identified-organization(3) certicom(132) curve(0) 33 }
secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }
secp384r1 OBJECT IDENTIFIER ::= { iso(1) secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 } identified-organization(3) certicom(132) curve(0) 34 }
secp521r1 OBJECT IDENTIFIER ::= { iso(1) secp521r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 35 } identified-organization(3) certicom(132) curve(0) 35 }
Specific conventions to be considered are specified in RFC 5753 Specific conventions to be considered are specified in [RFC5753].
[RFC5753].
The ECDH key agreement algorithm used together with curve25519 or The ECDH key agreement algorithm used together with curve25519 or
curve448 are identified by the following OIDs: curve448 is identified by the following OIDs:
id-X25519 OBJECT IDENTIFIER ::= { iso(1) id-X25519 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 110 } identified-organization(3) thawte(101) 110 }
id-X448 OBJECT IDENTIFIER ::= { iso(1) id-X448 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) thawte(101) 111 } identified-organization(3) thawte(101) 111 }
Specific conventions to be considered are specified in RFC 8418 Specific conventions to be considered are specified in [RFC8418].
[RFC8418].
4.2. Key Transport Algorithms 4.2. Key Transport Algorithms
The key transport algorithm is also referred to as PROT_ENC_ALG in The key transport algorithm is also referred to as PROT_ENC_ALG in
RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the Appendices D and E of [RFC4210] and as KM_KT_ALG in the Lightweight
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as CMP Profile [RFC9483] and Section 7.
well as in Section 7.
Key transport algorithms are only used in CMP when using CMS Key transport algorithms are only used in CMP when using CMS
[RFC5652] EnvelopedData together with the key transport key [RFC5652] EnvelopedData together with the key transport key
management technique. management technique.
Key transport algorithm identifiers are located in: Key transport algorithm identifiers are located in the:
* keyEncryptionAlgorithm field of KeyTransRecipientInfo * keyEncryptionAlgorithm field of KeyTransRecipientInfo.
Key transport encrypted content-encryption keys are located in: Key transport encrypted content-encryption keys are located in the:
* encryptedKey field of KeyTransRecipientInfo * encryptedKey field of KeyTransRecipientInfo.
4.2.1. RSA 4.2.1. RSA
The RSA key transport algorithm is the RSA encryption scheme defined The RSA key transport algorithm is the RSA encryption scheme defined
in RFC 8017 [RFC8017]. in [RFC8017].
The algorithm identifier for RSA (PKCS #1 v1.5) is: The algorithm identifier for RSA (PKCS #1 v1.5) is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The algorithm identifier for RSAES-OAEP is: The algorithm identifier for RSAES-OAEP is:
id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
Further conventions to be considered for PKCS #1 v1.5 are specified Further conventions to be considered for PKCS #1 v1.5 are specified
in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 in Section 4.2.1 of [RFC3370] and for RSAES-OAEP in [RFC3560].
[RFC3560].
4.3. Symmetric Key-Encryption Algorithms 4.3. Symmetric Key-Encryption Algorithms
The symmetric key-encryption algorithm is also referred to as The symmetric key-encryption algorithm is also referred to as
KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile KM_KW_ALG in Section 7.2 and the Lightweight CMP Profile [RFC9483].
[I-D.ietf-lamps-lightweight-cmp-profile].
As symmetric key-encryption key management technique is not used by As the symmetric key-encryption key management technique is not used
CMP, the symmetric key-encryption algorithm is only needed when using by CMP, the symmetric key-encryption algorithm is only needed when
the key agreement or password-based key management technique with CMS using the key agreement or password-based key management technique
[RFC5652] EnvelopedData. with CMS [RFC5652] EnvelopedData.
Key wrap algorithm identifiers are located in: Key wrap algorithm identifiers are located in the:
* parameters field of the KeyEncryptionAlgorithmIdentifier of * parameters field of the KeyEncryptionAlgorithmIdentifier of
KeyAgreeRecipientInfo and PasswordRecipientInfo KeyAgreeRecipientInfo and PasswordRecipientInfo.
Wrapped content-encryption keys are located in: Wrapped content-encryption keys are located in the:
* encryptedKey field of RecipientEncryptedKeys (for key agreement) * encryptedKey field of RecipientEncryptedKeys (for key agreement)
and PasswordRecipientInfo (for password-based key management) and PasswordRecipientInfo (for password-based key management).
4.3.1. AES Key Wrap 4.3.1. AES Key Wrap
The AES encryption algorithm is defined in FIPS Pub 197 The AES encryption algorithm is defined in FIPS Pub 197
[NIST.FIPS.197] and the key wrapping is defined in RFC 3394 [NIST.FIPS.197], and the key wrapping is defined in [RFC3394].
[RFC3394].
AES key encryption has the algorithm identifier: AES key encryption has the algorithm identifier:
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 } nistAlgorithm(4) aes(1) 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 25 } nistAlgorithm(4) aes(1) 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 } nistAlgorithm(4) aes(1) 45 }
The underlying encryption functions for the key wrap and content- The underlying encryption functions for the key wrap and content-
encryption algorithms (as specified in Section 5) and the key sizes encryption algorithms (as specified in Section 5) and the key sizes
for the two algorithms MUST be the same (e.g., AES-128 key wrap for the two algorithms MUST be the same (e.g., AES-128 key wrap
algorithm with AES-128 content-encryption algorithm), see also algorithm with AES-128 content-encryption algorithm); see [RFC8551].
RFC 8551 [RFC8551].
Further conventions to be considered for AES key wrap are specified Further conventions to be considered for AES key wrap are specified
in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 in Section 2.2 of [RFC3394] and Section 2.3.2 of [RFC3565].
[RFC3565].
4.4. Key Derivation Algorithms 4.4. Key Derivation Algorithms
The key derivation algorithm is also referred to as KM_KD_ALG in The key derivation algorithm is also referred to as KM_KD_ALG in
Section 7.2 and in the Lightweight CMP Profile Section 7.2 and the Lightweight CMP Profile [RFC9483].
[I-D.ietf-lamps-lightweight-cmp-profile].
Key derivation algorithms are only used in CMP when using CMS Key derivation algorithms are only used in CMP when using CMS
[RFC5652] EnvelopedData together with password-based key management EnvelopedData [RFC5652] together with the password-based key
technique. management technique.
Key derivation algorithm identifiers are located in: Key derivation algorithm identifiers are located in the:
* keyDerivationAlgorithm field of PasswordRecipientInfo * keyDerivationAlgorithm field of PasswordRecipientInfo.
When using the password-based key management technique with When using the password-based key management technique with
EnvelopedData as specified in CMP Updates together with message EnvelopedData as specified in CMP Updates [RFC9480] together with
authentication code (MAC)-based PKIProtection, the salt for the PKIProtection based on the message authentication code (MAC), the
password-based MAC and KDF must be chosen independently to ensure salt for the password-based MAC and key derivation function (KDF)
usage of independent symmetric keys. must be chosen independently to ensure usage of independent symmetric
keys.
4.4.1. PBKDF2 4.4.1. PBKDF2
The password-based key derivation function 2 (PBKDF2) is defined in Password-based key derivation function 2 (PBKDF2) is defined in
RFC 8018 [RFC8018]. [RFC8018].
Password-based key derivation function 2 has the algorithm PBKDF2 has the algorithm identifier:
identifier:
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 } rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
Further conventions to be considered for PBKDF2 are specified in Further conventions to be considered for PBKDF2 are specified in
RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. Section 4.4.1 of [RFC3370] and Section 5.2 of [RFC8018].
5. Content Encryption Algorithms 5. Content-Encryption Algorithms
The content encryption algorithm is also referred to as PROT_SYM_ALG The content-encryption algorithm is also referred to as PROT_SYM_ALG
in Section 7, RFC 4210 Appendix D and E [RFC4210], and the in Appendices D and E of [RFC4210], in the Lightweight CMP Profile
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. [RFC9483], and in Section 7.
Content encryption algorithms are only used in CMP when using CMS Content-encryption algorithms are used in CMP when using CMS
[RFC5652] EnvelopedData to transport a signed private key package in EnvelopedData [RFC5652] to transport a signed private key package in
case of central key generation or key archiving, a certificate to case of central key generation or key archiving, a certificate to
facilitate implicit proof-of-possession, or a revocation passphrase facilitate implicit proof-of-possession, or a revocation passphrase
in encrypted form. in encrypted form.
Content encryption algorithm identifiers are located in: Content-encryption algorithm identifiers are located in the:
* contentEncryptionAlgorithm field of EncryptedContentInfo * contentEncryptionAlgorithm field of EncryptedContentInfo.
Encrypted content is located in: Encrypted content is located in the:
* encryptedContent field of EncryptedContentInfo * encryptedContent field of EncryptedContentInfo.
5.1. AES-CBC 5.1. AES-CBC
The AES encryption algorithm is defined in FIPS Pub 197 The AES encryption algorithm is defined in FIPS Pub 197
[NIST.FIPS.197]. [NIST.FIPS.197].
AES-CBC content encryption has the algorithm identifier: AES Cipher Block Chaining (AES-CBC) content encryption has the
algorithm identifier:
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 } nistAlgorithm(4) aes(1) 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1)22 } nistAlgorithm(4) aes(1)22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1)42 } nistAlgorithm(4) aes(1)42 }
Specific conventions to be considered for AES-CBC content encryption Specific conventions to be considered for AES-CBC content encryption
are specified in RFC 3565 [RFC3565]. are specified in [RFC3565].
6. Message Authentication Code Algorithms 6. Message Authentication Code Algorithms
The message authentication code (MAC) is either used for shared The message authentication code (MAC) is either used for shared
secret-based CMP message protection or together with the password- secret-based CMP message protection or together with the password-
based key derivation function (PBKDF2). based key derivation function (PBKDF2).
The message authentication code algorithm is also referred to as The MAC algorithm is also referred to as MSG_MAC_ALG in Section 7,
MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and Appendices D and E of [RFC4210], and the Lightweight CMP Profile
the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. [RFC9483].
6.1. Password-Based MAC 6.1. Password-Based MAC
Password-based message authentication code (MAC) algorithms combine Password-based message authentication code (MAC) algorithms combine
the derivation of a symmetric key from a password or other shared the derivation of a symmetric key from a password or other shared
secret information and a symmetric key-based MAC function as secret information and a symmetric key-based MAC function, as
specified in Section 6.2 using this derived key. specified in Section 6.2, using this derived key.
Message authentication code algorithm identifiers are located in: MAC algorithm identifiers are located in the:
* protectionAlg field of PKIHeader * protectionAlg field of PKIHeader.
Message authentication code values are located in: Message authentication code values are located in the:
* PKIProtection field of PKIMessage * PKIProtection field of PKIMessage.
6.1.1. PasswordBasedMac 6.1.1. PasswordBasedMac
The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 The PasswordBasedMac algorithm is defined in Section 5.1.3.1 of
[RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements [RFC4210], Section 4.4 of [RFC4211], and "Algorithm Requirements
Update to the Internet X.509 Public Key Infrastructure Certificate Update to the Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF) [RFC9045]. Request Message Format (CRMF)" [RFC9045].
The PasswordBasedMac algorithm is identified by the following OID: The PasswordBasedMac algorithm is identified by the following OID:
id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) nt(113533) nsn(7) algorithms(66) 13 } us(840) nt(113533) nsn(7) algorithms(66) 13 }
Further conventions to be considered for password-based MAC are Further conventions to be considered for PasswordBasedMac are
specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 specified in Section 5.1.3.1 of [RFC4210], Section 4.4 of [RFC4211],
[RFC4211], and Algorithm Requirements Update to the Internet X.509 and "Algorithm Requirements Update to the Internet X.509 Public Key
Public Key Infrastructure Certificate Request Message Format (CRMF) Infrastructure Certificate Request Message Format (CRMF)" [RFC9045].
[RFC9045].
6.1.2. PBMAC1 6.1.2. PBMAC1
The Password-Based Message Authentication Code 1 (PBMAC1) is defined Password-Based Message Authentication Code 1 (PBMAC1) is defined in
in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key [RFC8018]. PBMAC1 combines a password-based key derivation function,
derivation function like PBKDF2 (Section 4.4.1) with an underlying like PBKDF2 (Section 4.4.1), with an underlying symmetric key-based
symmetric key-based message authentication scheme. message authentication scheme.
PBMAC1 has the following OID: PBMAC1 has the following OID:
id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 14 } rsadsi(113549) pkcs(1) pkcs-5(5) 14 }
Specific conventions to be considered for PBMAC1 are specified in Specific conventions to be considered for PBMAC1 are specified in
RFC 8018 Section 7.1 and A.5 [RFC8018]. Section 7.1 and Appendix A.5 of [RFC8018].
6.2. Symmetric Key-Based MAC 6.2. Symmetric Key-Based MAC
Symmetric key-based message authentication code (MAC) algorithms are Symmetric key-based message authentication code (MAC) algorithms are
used for deriving the symmetric encryption key when using PBKDF2 as used for deriving the symmetric encryption key when using PBKDF2, as
described in Section 4.4.1 as well as with Password-based MAC as described in Section 4.4.1, as well as with password-based MAC, as
described in Section 6.1. described in Section 6.1.
Message authentication code algorithm identifiers are located in: MAC algorithm identifiers are located in the:
* protectionAlg field of PKIHeader * protectionAlg field of PKIHeader,
* messageAuthScheme field of PBMAC1 * messageAuthScheme field of PBMAC1,
* mac field of PBMParameter * mac field of PBMParameter, and
* prf field of PBKDF2-params * prf field of PBKDF2-params.
Message authentication code values are located in: MAC values are located in the:
* PKIProtection field of PKIMessage * PKIProtection field of PKIMessage.
6.2.1. SHA2-Based HMAC 6.2.1. SHA2-Based HMAC
The HMAC algorithm is defined in RFC 2104 [RFC2104] and The HMAC algorithm is defined in [RFC2104] and FIPS Pub 198-1
FIPS Pub 198-1 [NIST.FIPS.198-1]. [NIST.FIPS.198-1].
The HMAC algorithm used with SHA2 message digest algorithms is The HMAC algorithm used with SHA2 message digest algorithms is
identified by the following OIDs: identified by the following OIDs:
id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 8 } us(840) rsadsi(113549) digestAlgorithm(2) 8 }
id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 9 } us(840) rsadsi(113549) digestAlgorithm(2) 9 }
id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 10 } us(840) rsadsi(113549) digestAlgorithm(2) 10 }
id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 11 } us(840) rsadsi(113549) digestAlgorithm(2) 11 }
Specific conventions to be considered for SHA2-based HMAC are Specific conventions to be considered for SHA2-based HMAC are
specified in RFC 4231 Section 3.1 [RFC4231]. specified in Section 3.1 of [RFC4231].
6.2.2. AES-GMAC 6.2.2. AES-GMAC
The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and
NIST SP 800-38d [NIST.SP.800-38d]. NIST SP 800-38d [NIST.SP.800-38d].
Note: AES-GMAC MUST NOT be used twice with the same parameter set, Note: The AES-GMAC MUST NOT be used twice with the same parameter
especially the same nonce. Therefore, it MUST NOT be used together set, especially the same nonce. Therefore, it MUST NOT be used
with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- together with PBKDF2. When using it with PBMAC1, it MUST be ensured
GMAC is only used as message authentication scheme and not for the that the AES-GMAC is only used as a message authentication scheme and
key derivation function PBKDF2. not for the key derivation function PBKDF2.
The AES-GMAC algorithm is identified by the following OIDs: The AES-GMAC algorithm is identified by the following OIDs:
id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 9 } nistAlgorithm(4) aes(1) 9 }
id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 29 } nistAlgorithm(4) aes(1) 29 }
id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 49 } nistAlgorithm(4) aes(1) 49 }
Specific conventions to be considered for AES-GMAC are specified in Specific conventions to be considered for the AES-GMAC are specified
RFC 9044 [RFC9044]. in [RFC9044].
6.2.3. SHAKE-Based KMAC 6.2.3. SHAKE-Based KMAC
The KMAC algorithm is defined in RFC 8702 [RFC8702] and The KMAC algorithm is defined in [RFC8702] and FIPS SP 800-185
FIPS SP 800-185 [NIST.SP.800-185]. [NIST.SP.800-185]].
The SHAKE-based KMAC algorithm is identified by the following OIDs: The SHAKE-based KMAC algorithm is identified by the following OIDs:
id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 19 } nistAlgorithm(4) hashAlgs(2) 19 }
id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 20 } nistAlgorithm(4) hashAlgs(2) 20 }
Specific conventions to be considered for KMAC with SHAKE are Specific conventions to be considered for KMAC with SHAKE are
specified in RFC 8702 Section 3.4 [RFC8702]. specified in Section 3.4 of [RFC8702].
7. Algorithm Use Profiles 7. Algorithm Use Profiles
This section provides profiles of algorithms and respective This section provides profiles of algorithms and respective
conventions for different application use cases. conventions for different application use cases.
Recommendations like NIST SP 800-57 Recommendation for Key Management Recommendations like those described in Table 2 of NIST SP 800-57
Table 2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and "Recommendation for Key Management" [NIST.SP.800-57pt1r5] and
Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general Section 4.6 of ECRYPT "Algorithms, Key Size and Protocols Report
information on current cryptographic algorithms. (2018)" [ECRYPT.CSA.D5.4] provide general information on current
cryptographic algorithms.
The overall cryptographic strength of a CMP deployment will depend on The overall cryptographic strength of CMP implementations will depend
several factors, including: on several factors, including:
* Capabilities of the end entity: What kind of algorithms does the * capabilities of the end entity: What kind of algorithms does the
end entity support. The cryptographic strength of the system end entity support? The cryptographic strength of the system
SHOULD be at least as strong as the algorithms and keys used for SHOULD be at least as strong as the algorithms and keys used for
the certificate being managed. the certificate being managed.
* Algorithm profile: The overall strength of the profile will be the * algorithm profile: The overall strength of the profile will be the
strength of the weakest algorithm it contains. strength of the weakest algorithm it contains.
* Message protection: The overall strength of the CMC message * message protection: The overall strength of the CMP message
protection protection.
- MAC-based protection: The entropy of the shared secret - MAC-based protection: The entropy of the shared secret
information or password when MAC-based message protection is information or password when MAC-based message protection is
used (MSG_MAC_ALG). used (MSG_MAC_ALG).
- Signature-based protection: The strength of the key pair and - signature-based protection: The strength of the key pair and
signature algorithm when signature-based protection is used signature algorithm when signature-based protection is used
(MSG_SIG_ALG). (MSG_SIG_ALG).
- Protection of centrally generated keys: The strength of the - protection of centrally generated keys: The strength of the
algorithms used for the key management technique (Section 7.2: algorithms used for the key management technique (Section 7.1:
PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) PROT_ENC_ALG or Section 7.2: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG)
and the encryption of the content-encryption key and private and the encryption of the content-encryption key and private
key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: key (Section 7.1: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.2:
KM_KW_ALG, PROT_SYM_ALG). KM_KW_ALG, PROT_SYM_ALG).
The following table shows the algorithms listed in this document The following table shows the algorithms listed in this document
sorted by their bits of security. If an implementation intends to sorted by their bits of security. If an implementation intends to
enroll and manage certificate for keys of a specific security, it enroll and manage certificates for keys of a specific security, it
SHALL implement and use algorithms of at least that strength for the SHALL implement and use algorithms of at least that strength for the
respective PKI management operation. If one row does not provide a respective PKI management operation. If one row does not provide a
suitable algorithm, the implementer MUST choose one offering more suitable algorithm, the implementer MUST choose one offering more
bits of security. bits of security.
+=======+==========+================+==================+============+ +========+==========+==============+==================+============+
| Bits | RSA or | Elliptic | Hash Function or | Symmetric | |Bits of | RSA or | Elliptic | Hash Function or | Symmetric |
| of | DH | Curve | XOF with | Encryption | |Security| DH | Curve | XOF with | Encryption |
| Secu- | | | Specified Output | | | | | Cryptography | Specified Output | |
| rity | | | Length (d) | | | | | | Length (d) | |
+=======+==========+================+==================+============+ +========+==========+==============+==================+============+
| 112 | RSA2048, | ECDSA/ECDH | SHA224 | | |112 | RSA2048, | ECDSA/ECDH | SHA-224 | |
| | DH(2048) | (secp224r1) | | | | | DH(2048) | (secp224r1) | | |
+-------+----------+----------------+------------------+------------+ +--------+----------+--------------+------------------+------------+
| 128 | RSA3072, | ECDSA/ECDH | SHA256, | AES-128 | |128 | RSA3072, | ECDSA/ECDH | SHA-256, | AES-128 |
| | DH(3072) | (secp256r1), | SHAKE128(d=256) | | | | DH(3072) | (secp256r1), | SHAKE128(d=256) | |
| | | Ed25519/ | | | | | | Ed25519/ | | |
| | | X25519 | | | | | | X25519 | | |
| | | (Curve25519) | | | | | | (curve25519) | | |
+-------+----------+----------------+------------------+------------+ +--------+----------+--------------+------------------+------------+
| 192 | | ECDSA/ECDH | SHA384 | AES-192 | |192 | | ECDSA/ECDH | SHA-384 | AES-192 |
| | | (secp384r1) | | | | | | (secp384r1) | | |
+-------+----------+----------------+------------------+------------+ +--------+----------+--------------+------------------+------------+
| 224 | | Ed448/X448 | | | |224 | | Ed448/X448 | | |
| | | (Curve448) | | | | | | (curve448) | | |
+-------+----------+----------------+------------------+------------+ +--------+----------+--------------+------------------+------------+
| 256 | | ECDSA/ECDH | SHA512, | AES-256 | |256 | | ECDSA/ECDH | SHA-512, | AES-256 |
| | | (secp521r1) | SHAKE256(d=512) | | | | | (secp521r1) | SHAKE256(d=512) | |
+-------+----------+----------------+------------------+------------+ +--------+----------+--------------+------------------+------------+
Table 1: Cryptographic Algorithms Sorted by their Bits of Security Table 1: Cryptographic Algorithms Sorted by Their Bits of Security
The following table shows the cryptographic algorithms sorted by The following table shows the cryptographic algorithms sorted by
their usage in CMP and with more details. their usage in CMP and with more details.
+========+==========+===============+===============+===============+ +========+==========+================+================+=============+
|Bits of |Key Types |CMP Protection |Key Management | Key-Wrap and | |Bits of |Key Types | CMP Protection | Key Management |Key-Wrap and |
|Security|to Be | |Technique | Symmetric | |Security|to Be | MSG_SIG_ALG, | Technique |Symmetric |
| |Certified | | | Encryption | | |Certified | MSG_MAC_ALG | PROT_ENC_ALG |Encryption |
+========+==========+===============+===============+===============+ | | | | or KM_KA_ALG, |PROT_SYM_ALG,|
| | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, | | | | | KM_KT_ALG, |SYM_PENC_ALG |
| | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG | | | | | KM_KD_ALG |or |
| | | |KM_KT_ALG, | or | | | | | |KM_KW_ALG |
| | | |KM_KD_ALG | KM_KW_ALG | +========+==========+================+================+=============+
+--------+----------+---------------+---------------+---------------+ |112 |RSA2048, | RSASSA-PSS | DH(2048), | |
|112 |RSA2048, |RSASSA-PSS |DH(2048), | | | |secp224r1 | (2048, SHA-224 | RSAES-OAEP | |
| |secp224r1 |(2048, SHA224 |RSAES-OAEP | | | | | or SHAKE128 | (2048, SHA- | |
| | |or SHAKE128 |(2048, SHA224),| | | | | (d=256)), | 224), | |
| | |(d=256)), |RSAEncryption | | | | | RSAEncryption | RSAEncryption | |
| | |RSAEncryption |(2048, SHA224),| | | | | (2048, SHA- | (2048, SHA- | |
| | |(2048, SHA224),|ECDH | | | | | 224), | 224), | |
| | |ECDSA |(secp224r1, | | | | | ECDSA | ECDH | |
| | |(secp224r1, |SHA224), | | | | | (secp224r1, | (secp224r1, | |
| | |SHA224 or |PBKDF2 (HMAC- | | | | | SHA-224 or | SHA-224), | |
| | |SHAKE128 |SHA224) | | | | | SHAKE128 | PBKDF2 (HMAC- | |
| | |(d=256)), | | | | | | (d=256)), | SHA-224) | |
| | |PBMAC1 (HMAC- | | | | | | PBMAC1 (HMAC- | | |
| | |SHA224) | | | | | | SHA-224) | | |
+--------+----------+---------------+---------------+---------------+ +--------+----------+----------------+----------------+-------------+
|128 |RSA3072, |RSASSA-PSS |DH(3072), | AES-128 | |128 |RSA3072, | RSASSA-PSS | DH(3072), |AES-128 |
| |secp256r1,|(3072, SHA256 |RSAES-OAEP | | | |secp256r1,| (3072, SHA-256 | RSAES-OAEP | |
| |Curve25519|or SHAKE128 |(3072, SHA256),| | | |curve25519| or SHAKE128 | (3072, SHA- | |
| | |(d=256)), |RSAEncryption | | | | | (d=256)), | 256), | |
| | |RSAEncryption |(3072, SHA256),| | | | | RSAEncryption | RSAEncryption | |
| | |(3072, SHA256),|ECDH | | | | | (3072, SHA- | (3072, SHA- | |
| | |ECDSA |(secp256r1, | | | | | 256), | 256), | |
| | |(secp256r1, |SHA256), | | | | | ECDSA | ECDH | |
| | |SHA256 or |X25519, | | | | | (secp256r1, | (secp256r1, | |
| | |SHAKE128 |PBKDF2 (HMAC- | | | | | SHA-256 or | SHA-256), | |
| | |(d=256)), |SHA256) | | | | | SHAKE128 | X25519, | |
| | |Ed25519 | | | | | | (d=256)), | PBKDF2 (HMAC- | |
| | |(SHA512), | | | | | | Ed25519 (SHA- | SHA-256) | |
| | |PBMAC1 (HMAC- | | | | | | 512), | | |
| | |SHA256) | | | | | | PBMAC1 (HMAC- | | |
+--------+----------+---------------+---------------+---------------+ | | | SHA-256) | | |
|192 |secp384r1 |ECDSA |ECDH | AES-192 | +--------+----------+----------------+----------------+-------------+
| | |(secp384r1, |(secp384r1, | | |192 |secp384r1 | ECDSA | ECDH |AES-192 |
| | |SHA384), |SHA384), | | | | | (secp384r1, | (secp384r1, | |
| | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | | | | SHA-384), | SHA-384), | |
| | |SHA384) |SHA384) | | | | | PBMAC1 (HMAC- | PBKDF2 (HMAC- | |
+--------+----------+---------------+---------------+---------------+ | | | SHA-384) | SHA-384) | |
|224 |Curve448 |Ed448 |X448 | | +--------+----------+----------------+----------------+-------------+
| | |(SHAKE256) | | | |224 |curve448 | Ed448 | X448 | |
+--------+----------+---------------+---------------+---------------+ | | | (SHAKE256) | | |
|256 |secp521r1 |ECDSA |ECDH | AES-256 | +--------+----------+----------------+----------------+-------------+
| | |(secp521r1, |(secp521r1, | | |256 |secp521r1 | ECDSA | ECDH |AES-256 |
| | |SHA512 or |SHA512), | | | | | (secp521r1, | (secp521r1, | |
| | |SHAKE256 |PBKDF2 (HMAC- | | | | | SHA-512 or | SHA-512), | |
| | |(d=512)), |SHA512) | | | | | SHAKE256 | PBKDF2 (HMAC- | |
| | |PBMAC1 (HMAC- | | | | | | (d=512)), | SHA-512) | |
| | |SHA512) | | | | | | PBMAC1 (HMAC- | | |
+--------+----------+---------------+---------------+---------------+ | | | SHA-512) | | |
Table 2: Cryptographic Algorithms Sorted by their Bits of +--------+----------+----------------+----------------+-------------+
Table 2: Cryptographic Algorithms Sorted by Their Bits of
Security and Usage by CMP Security and Usage by CMP
To avoid consuming too many computational resources it is recommended To avoid consuming too many computational resources, choosing a set
to choose a set of algorithms offering roughly the same level of of algorithms offering roughly the same level of security is
security. Below are provided several algorithm profiles which are recommended. Below are several algorithm profiles that are balanced,
balanced, assuming the implementer chooses MAC secrets and/or assuming the implementer chooses MAC secrets and/or certificate
certificate profiles of at least equivalent strength. profiles of at least equivalent strength.
7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 7.1. Algorithm Profile for PKI Management Message Profiles in RFC 4210
The following table updates the definitions of algorithms used within The following table updates the definitions of algorithms used within
PKI Management Message Profiles as defined in CMP Appendix D.2 PKI Management Message Profiles, as defined in Appendix D.2 of
[RFC4210]. [RFC4210].
The columns in the table are: The columns in the table are:
Name: An identifier used for message profiles Name: An identifier used for message profiles
Use: Description of where and for what the algorithm is used Use: Description of where and for what the algorithm is used
Mandatory: Algorithms which MUST be supported by conforming Mandatory: Algorithms that MUST be supported by conforming
implementations implementations
Optional: Algorithms which are OPTIONAL to support Optional: Algorithms that are OPTIONAL to support
Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be Deprecated: Algorithms from [RFC4210] that SHOULD NOT be used any
used any more more
+============+==============+======+===================+============+
|Name |Use |Manda-| Optional |Deprecated |
| | |tory | | |
+============+==============+======+===================+============+
|MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, |
| |PKI messages | | |combinations|
| |using | | |with MD5 and|
| |signature | | |SHA-1 |
+------------+--------------+------+-------------------+------------+
|MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 |
| |PKI messages | | HMAC, KMAC | |
| |using MACing | | | |
+------------+--------------+------+-------------------+------------+
|SYM_PENC_ALG|symmetric |AES- | |3-DES(3-key-|
| |encryption of |wrap | |EDE, CBC |
| |an end | | |Mode), RC5, |
| |entity's | | |CAST-128 |
| |private key | | | |
| |where | | | |
| |symmetric key | | | |
| |is distributed| | | |
| |out-of-band | | | |
+------------+--------------+------+-------------------+------------+
|PROT_ENC_ALG|asymmetric |DH | ECDH, RSA | |
| |algorithm used| | | |
| |for encryption| | | |
| |of (symmetric | | | |
| |keys for | | | |
| |encryption of)| | | |
| |private keys | | | |
| |transported in| | | |
| |PKIMessages | | | |
+------------+--------------+------+-------------------+------------+
|PROT_SYM_ALG|symmetric |AES- | |3-DES(3-key-|
| |encryption |CBC | |EDE, CBC |
| |algorithm used| | |Mode), RC5, |
| |for encryption| | |CAST-128 |
| |of private key| | | |
| |bits (a key of| | | |
| |this type is | | | |
| |encrypted | | | |
| |using | | | |
| |PROT_ENC_ALG) | | | |
+------------+--------------+------+-------------------+------------+
Table 3: Algorithms Used Within RFC 4210 Appendix D.2 +============+=============+=========+=================+============+
|Name |Use |Mandatory|Optional |Deprecated |
+============+=============+=========+=================+============+
|MSG_SIG_ALG |protection of|RSA |ECDSA, EdDSA |DSA, |
| |PKI messages | | |combinations|
| |using | | |with MD5 and|
| |signatures | | |SHA-1 |
+------------+-------------+---------+-----------------+------------+
|MSG_MAC_ALG |protection of|PBMAC1 |PasswordBasedMac,|X9.9 |
| |PKI messages | |HMAC, KMAC | |
| |using MACs | | | |
+------------+-------------+---------+-----------------+------------+
|SYM_PENC_ALG|symmetric |AES-wrap | |3-DES(3-key-|
| |encryption of| | |EDE, CBC |
| |an end | | |Mode), RC5, |
| |entity's | | |CAST-128 |
| |private key | | | |
| |where the | | | |
| |symmetric key| | | |
| |is | | | |
| |distributed | | | |
| |out of band | | | |
+------------+-------------+---------+-----------------+------------+
|PROT_ENC_ALG|asymmetric |DH |ECDH, RSA | |
| |algorithm | | | |
| |used for | | | |
| |encryption of| | | |
| |(symmetric | | | |
| |keys for | | | |
| |encryption | | | |
| |of) private | | | |
| |keys | | | |
| |transported | | | |
| |in | | | |
| |PKIMessages | | | |
+------------+-------------+---------+-----------------+------------+
|PROT_SYM_ALG|symmetric |AES-CBC | |3-DES(3-key-|
| |encryption | | |EDE, CBC |
| |algorithm | | |Mode), RC5, |
| |used for | | |CAST-128 |
| |encryption of| | | |
| |private key | | | |
| |bits (a key | | | |
| |of this type | | | |
| |is encrypted | | | |
| |using | | | |
| |PROT_ENC_ALG)| | | |
+------------+-------------+---------+-----------------+------------+
Mandatory Algorithm Identifiers and Specifications: Table 3: Algorithms Used within Appendix D.2 of RFC 4210
RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 The following are the mandatory algorithm identifiers and
specifications:
PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1
sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as
the mac parameter, see Section 6.2.1)
PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id-
derivation function, see Section 4.4.1 and id-hmacWithSHA256 as sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256
message authentication scheme, see Section 6.2.1). It is RECOMMENDED as the mac parameter, see Section 6.2.1)
to prefer the usage of PBMAC1 instead of PasswordBasedMac.
DH: id-alg-ESDH, see Section 4.1.1 PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key
derivation function, see Section 4.4.1 and id-hmacWithSHA256 as
the message authentication scheme, see Section 6.2.1). It is
RECOMMENDED to prefer the usage of PBMAC1 instead of
PasswordBasedMac.
AES-wrap: id-aes128-wrap, see Section 4.3.1 DH: id-alg-ESDH, see Section 4.1.1
AES-CBC: id-aes128-CBC, see Section 5.1 AES-wrap: id-aes128-wrap, see Section 4.3.1
AES-CBC: id-aes128-CBC, see Section 5.1
7.2. Algorithm Profile for Lightweight CMP Profile 7.2. Algorithm Profile for Lightweight CMP Profile
The following table contains definitions of algorithms which MAY be The following table contains definitions of algorithms that MAY be
supported by implementations of the Lightweight CMP Profile supported by implementations of the Lightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile]. [RFC9483].
As the set of algorithms to be used for implementations of the As the set of algorithms to be used for implementations of the
Lightweight CMP Profile heavily depends on the PKI management Lightweight CMP Profile heavily depends on the PKI management
operations implemented, the certificates used for messages operations implemented, the certificates used for message protection,
protection, and the certificates to be managed, this document will and the certificates to be managed, this document will not specify a
not specify a specific set that is mandatory to support for specific set that is mandatory to support for conforming
conforming implementations. implementations.
The columns in the table are: The columns in the table are:
Name: An identifier used for message profiles Name: An identifier used for message profiles
Use: Description of where and for what the algorithm is used Use: Description of where and for what the algorithm is used
Examples: Lists the algorithms as described in this document. The Examples: Lists the algorithms, as described in this document. The
list of algorithms depends on the set of PKI management operations to list of algorithms depends on the set of PKI management operations
be implemented. to be implemented.
Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of
PasswordBasedMac. PasswordBasedMac.
+==============+================================+==================+ +==============+================================+==================+
| Name | Use | Examples | | Name | Use | Examples |
+==============+================================+==================+ +==============+================================+==================+
| MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, |
| | using signature and for | EdDSA | | | using signatures and for | EdDSA |
| | SignedData, e.g., a private | | | | SignedData, e.g., a private | |
| | key transported in PKIMessages | | | | key transported in PKIMessages | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac |
| | using MACing | (see Section 9), | | | using MACing | (see Section 9), |
| | | PBMAC1, HMAC, | | | | PBMAC1, HMAC, |
| | | KMAC | | | | KMAC |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| KM_KA_ALG | asymmetric key agreement | DH, ECDH | | KM_KA_ALG | asymmetric key agreement | DH, ECDH |
| | algorithm used for agreement | | | | algorithm used for agreement | |
| | of a symmetric key for use | | | | of a symmetric key for use | |
| | with KM_KW_ALG | | | | with KM_KW_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| KM_KT_ALG | asymmetric key encryption | RSA | | KM_KT_ALG | asymmetric key-encryption | RSA |
| | algorithm used for transport | | | | algorithm used for transport | |
| | of a symmetric key for | | | | of a symmetric key for | |
| | PROT_SYM_ALG | | | | PROT_SYM_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| KM_KD_ALG | symmetric key derivation | PBKDF2 | | KM_KD_ALG | symmetric key derivation | PBKDF2 |
| | algorithm used for derivation | | | | algorithm used for derivation | |
| | of a symmetric key for use | | | | of a symmetric key for use | |
| | with KM_KW_ALG | | | | with KM_KW_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap |
| | key for PROT_SYM_ALG | | | | key for PROT_SYM_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| PROT_SYM_ALG | symmetric content encryption | AES-CBC | | PROT_SYM_ALG | symmetric content-encryption | AES-CBC |
| | algorithm used for encryption | | | | algorithm used for encryption | |
| | of EnvelopedData, e.g., a | | | | of EnvelopedData, e.g., a | |
| | private key transported in | | | | private key transported in | |
| | PKIMessages | | | | PKIMessages | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
Table 4: Algorithms Used Within Lightweight CMP Profile Table 4: Algorithms Used within the Lightweight CMP Profile
8. IANA Considerations 8. IANA Considerations
This document does not request changes to the IANA registry. This document has no IANA actions.
9. Security Considerations 9. Security Considerations
This document lists many cryptographic algorithms usable with CMP to This document lists many cryptographic algorithms usable with CMP to
offer implementer a more up-to-date choice. Finally, the algorithms offer implementers a more up-to-date choice. Finally, the algorithms
to be supported also heavily depend on the certificates and PKI to be supported also heavily depend on the certificates and PKI
management operations utilized in the target environment. The management operations utilized in the target environment. The
algorithm with the lowest security strength and the entropy of shared algorithm with the lowest security strength and the entropy of shared
secret information define the security of the overall solution, see secret information defines the security of the overall solution; see
Section 7. Section 7.
When using MAC-based message protection the use of PBMAC1 is When using MAC-based message protection, the use of PBMAC1 is
preferable to that of PasswordBasedMac. First, PBMAC1 is a well- preferable to that of PasswordBasedMac. First, PBMAC1 is a well-
known scrutinized algorithm, which is not true for PasswordBasedMac. known scrutinized algorithm, which is not true for PasswordBasedMac.
Second, the PasswordBasedMac algorithm as specified in RFC 4211 Second, the PasswordBasedMac algorithm as specified in Section 4.4 of
Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 [RFC4211] is essentially PBKDF1 (as defined in Section 5.1 of
Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update [RFC8018]) with an HMAC step at the end. Here, we update to use the
to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. PBKDF2 is
PBKDF2 is superior to PBKDF1 in an improved internal construct for superior to PBKDF1 in an improved internal construct for iterated
iterated hashing, and in removing PBKDF1's limitation of only being hashing and in removing PBKDF1's limitation of only being able to
able to derive keys up to the size of the underlying hash function. derive keys up to the size of the underlying hash function.
Additionally, PBKDF1 is not recommended for new applications as Additionally, PBKDF1 is not recommended for new applications as
stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved stated in Section 5.1 of [RFC8018] and is no longer an approved
algorithm by most standards bodies, and therefore presents algorithm by most standards bodies. Therefore, it presents
difficulties to implementer who are submitting their CMP difficulties to implementers who are submitting their CMP
implementations for certification, hence moving to a PBKDF2-based implementations for certification, hence moving to a PBKDF2-based
mechanism. This change is in alignment with [RFC9045] which updates mechanism. This change is in alignment with [RFC9045], which updates
[RFC4211] to allow the use of PBMAC1 in CRMF. [RFC4211] to allow the use of PBMAC1 in CRMF.
AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; The AES-GMAC MUST NOT be used as the pseudorandom function (PRF) in
the use of AES-GMAC more than once with the same key and the same PBKDF2; the use of the AES-GMAC more than once with the same key and
nonce will break the security. the same nonce will break the security.
In Section 7 of this document there is also an update to the
Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY
be supported when implementing the Lightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile].
In Section 7 of this document, there is also an update to
Appendix D.2 of [RFC4210] and a set of algorithms that MAY be
supported when implementing the Lightweight CMP Profile [RFC9483].
It is recognized that there may be older CMP implementations in use It is recognized that there may be older CMP implementations in use
that conform to the algorithm use profile from Appendix D.2 of that conform to the algorithm use profile from Appendix D.2 of
RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for [RFC4210]. For example, the use of AES is now mandatory for
PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. PROT_SYM_ALG, while 3-DES was mandatory in [RFC4210]. Therefore, it
Therefore, it is expected that many CMP systems may already support is expected that many CMP systems may already support the recommended
the recommended algorithms in this specification. In such systems algorithms in this specification. In such systems, the weakened
the weakened algorithms should be disabled from further use. If algorithms should be disabled from further use. If critical systems
critical systems cannot be immediately updated to conform to the cannot be immediately updated to conform to the recommended algorithm
recommended algorithm use profile, it is recommended a plan to use profile, it is recommended that a plan to migrate the
migrate the infrastructure to conforming profiles be adopted as soon infrastructure to conforming profiles be adopted as soon as possible.
as possible.
Symmetric key-based MAC algorithms as described in Section 6.2 MAY be Symmetric key-based MAC algorithms as described in Section 6.2 MAY be
used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and
ensure that the key has sufficient entropy to match the overall ensure that the key has sufficient entropy to match the overall
security level of the algorithm profile. These considerations are security level of the algorithm profile. These considerations are
outside the scope of the profile. outside the scope of the profile.
10. Acknowledgements 10. References
Thanks to Russ Housley for supporting this draft with submitting
[RFC9044] and [RFC9045].
May thanks also to all reviewers like Serge Mister, Mark Ferreira,
Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen
Fries for their input and feedback to this document. Apologies to
all not mentioned reviewers and supporters.
11. Normative References
[I-D.ietf-lamps-cmp-updates]
Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
Management Protocol (CMP) Updates", Work in Progress,
Internet-Draft, draft-ietf-lamps-cmp-updates-20, 31 May
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cmp-updates-20>.
[I-D.ietf-lamps-lightweight-cmp-profile] 10.1. Normative References
Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", Work in
Progress, Internet-Draft, draft-ietf-lamps-lightweight-
cmp-profile-12, 13 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
lightweight-cmp-profile-12>.
[NIST.FIPS.180-4] [NIST.FIPS.180-4]
Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal
180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, Information Processing Standards Publications 180-4,
DOI 10.6028/NIST.FIPS.180-4, July 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[NIST.FIPS.186-4]
National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST NIST FIPS 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[NIST.FIPS.186-5] [NIST.FIPS.186-5]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"FIPS Pub 186-5 (Draft): Digital Signature Standard "Digital Signature Standard (DSS)", FIPS PUB 186-5,
(DSS)", October 2019, DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-5-draft.pdf>. NIST.FIPS.186-5.pdf>.
[NIST.FIPS.197] [NIST.FIPS.197]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Advanced encryption standard (AES)", NIST NIST FIPS 197, "Advanced Encryption Standard (AES)", NIST FIPS 197,
DOI 10.6028/NIST.FIPS.197, November 2001, DOI 10.6028/NIST.FIPS.197, November 2001,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.197.pdf>. NIST.FIPS.197.pdf>.
[NIST.FIPS.198-1] [NIST.FIPS.198-1]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"The Keyed-Hash Message Authentication Code (HMAC)", "The Keyed-Hash Message Authentication Code (HMAC)", FIPS
NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July PUB 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,
2008, <https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.198-1.pdf>. NIST.FIPS.198-1.pdf>.
[NIST.FIPS.202] [NIST.FIPS.202]
Dworkin, Morris J., "SHA-3 Standard: Permutation-Based Dworkin, M. J. and NIST, "SHA-3 Standard: Permutation-
Hash and Extendable-Output Functions", NIST NIST FIPS 202, Based Hash and Extendable-Output Functions", NIST Federal
Information Processing Standards Publications 202,
DOI 10.6028/NIST.FIPS.202, July 2015, DOI 10.6028/NIST.FIPS.202, July 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.202.pdf>. NIST.FIPS.202.pdf>.
[NIST.SP.800-185] [NIST.SP.800-185]]
Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 Kelsey, J., Change, S., Perlner, R., and NIST, "SHA-3
derived functions: cSHAKE, KMAC, TupleHash and derived functions: cSHAKE, KMAC, TupleHash and
ParallelHash", NIST NIST SP 800-185, ParallelHash", NIST Special Publications
DOI 10.6028/NIST.SP.800-185, December 2016, (General) 800-185, DOI 10.6028/NIST.SP.800-185, December
2016,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-185.pdf>. NIST.SP.800-185.pdf>.
[NIST.SP.800-38d] [NIST.SP.800-38d]
Dworkin, M J., "Recommendation for block cipher modes of Dworkin, M J. and NIST, "Recommendation for block cipher
operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST modes of operation :GaloisCounter Mode (GCM) and GMAC",
SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, NIST Special Publications (General) 800-38d,
DOI 10.6028/NIST.SP.800-38d, 2007,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38d.pdf>. nistspecialpublication800-38d.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 29, line 5 skipping to change at line 1254
Agreement Algorithm with X25519 and X448 in the Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", RFC 8418, Cryptographic Message Syntax (CMS)", RFC 8418,
DOI 10.17487/RFC8418, August 2018, DOI 10.17487/RFC8418, August 2018,
<https://www.rfc-editor.org/info/rfc8418>. <https://www.rfc-editor.org/info/rfc8418>.
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature
Algorithm (EdDSA) Signatures in the Cryptographic Message Algorithm (EdDSA) Signatures in the Cryptographic Message
Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
2018, <https://www.rfc-editor.org/info/rfc8419>. 2018, <https://www.rfc-editor.org/info/rfc8419>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key
Infrastructure: Additional Algorithm Identifiers for
RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
DOI 10.17487/RFC8692, December 2019,
<https://www.rfc-editor.org/info/rfc8692>.
[RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash
Functions in the Cryptographic Message Syntax (CMS)", Functions in the Cryptographic Message Syntax (CMS)",
RFC 8702, DOI 10.17487/RFC8702, January 2020, RFC 8702, DOI 10.17487/RFC8702, January 2020,
<https://www.rfc-editor.org/info/rfc8702>. <https://www.rfc-editor.org/info/rfc8702>.
[RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the
Cryptographic Message Syntax (CMS)", RFC 9044, Cryptographic Message Syntax (CMS)", RFC 9044,
DOI 10.17487/RFC9044, June 2021, DOI 10.17487/RFC9044, June 2021,
<https://www.rfc-editor.org/info/rfc9044>. <https://www.rfc-editor.org/info/rfc9044>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the [RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045, Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021, DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>. <https://www.rfc-editor.org/info/rfc9045>.
12. Informative References [RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, October 2023,
<https://www.rfc-editor.org/info/rfc9480>.
[RFC9483] Brockhaus, H., Fries, S., and D. von Oheimb, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, October 2023,
<https://www.rfc-editor.org/info/rfc9483>.
10.2. Informative References
[ECRYPT.CSA.D5.4] [ECRYPT.CSA.D5.4]
University of Bristol, "Algorithms, Key Size and Protocols University of Bristol, "Algorithms, Key Size and Protocols
Report (2018)", March 2015, Report (2018)", March 2015,
<https://www.ecrypt.eu.org/csa/documents/ <https://www.ecrypt.eu.org/csa/documents/
D5.4-FinalAlgKeySizeProt.pdf>. D5.4-FinalAlgKeySizeProt.pdf>.
[NIST.SP.800-57pt1r5] [NIST.SP.800-57pt1r5]
Barker, Elaine., "Recommendation for key management:part 1 Barker, E. and NIST, "Recommendation for key
- general", NIST NIST SP 800-57pt1r5, management:part 1 - general", NIST Special Publications
DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, (General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5,
May 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>. NIST.SP.800-57pt1r5.pdf>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Acknowledgements
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key
Infrastructure: Additional Algorithm Identifiers for
RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
DOI 10.17487/RFC8692, December 2019,
<https://www.rfc-editor.org/info/rfc8692>.
Appendix A. History of Changes
Note: This appendix will be deleted in the final version of the
document.
From version 14 -> 15:
* Providing changes addressing comment from Martin Duke and
Zaheduzzaman Sarker regarding the introduction
From version 13 -> 14:
* Providing changes addressing comments from GEN AD review
From version 12 -> 13:
* Providing changes addressing comments from OPSDIR and GENART last
call reviews
From version 11 -> 12:
* Capitalized all headlines
From version 10 -> 11:
* Changes on the tables in Section 7 after direct exchange with
Quynh
From version 09 -> 10:
* Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors
granted BCP78 rights to the IETF Trust
* Implemented the changes proposed by Quynh, (see thread "Quynh
Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed
markers for ToDos regarding this review of SHAKE and KMAC usage as
well as on the tables in Section 7
From version 08 -> 09:
* Updated IPR disclaimer
From version 07 -> 08:
* Fixing issues from WG and AD review
* Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of
SHAKE and KMAC and added ToDo regarding checking respective notes
* Added two tables showing algorithms sorted by their strength to
Section 7 and added ToDo regarding checking these tables
* Updates the algorithm use profile in Section 7.1
* Updated and added security consideration on SHAKE,
PasswordBasedMac, KMAC, and symmetric key-based MAC functions and
added ToDo regarding checking the security consideration on SHAKE
From version 06 -> 07:
* Fixing minor formatting nits
From version 05 -> 06:
* Added text to Section 2 and Section 3.3 to clearly specify the
hash algorithm to use for certConf messages for certificates
signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us
for calculating certHash")
* Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I-
D.ietf-lamps-crmf-update-algs
From version 04 -> 05:
* Minor changes and corrections in wording
From version 03 -> 04:
* Added John Gray to the list of authors due to his extensive
support and valuable feedback
* Added some clarification of the use AES-GMAC to Section 6.2.1
* Extended the guidance on how to select a set of algorithms in
Section 7 and deleted former Section 7.1
* Deleted the algorithms mandatory to support in Section 7.2 as
discussed at IETF 110
* Extended the Security considerations in Section 9
* Minor changes in wording
From version 02 -> 03:
* Moved former Appendix A to new Section 7 as suggested by Rich and
Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms-
02.txt")
* Added a column to Table 1 in Section 7.2 to reflect the changes to
RFC 4210
* Updated Table 2 in Section 7.3
* Added a paragraph to Section 9 to discuss backward compatibility
with RFC 4210
* Minor changes in wording
From version 01 -> 02:
* Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author
* Changed to XML V3
* Added SHAKE digest algorithm to Section 2 as discussed at IETF 109
* Deleted DSA from Section 3 as discussed at IETF 109
* Added RSASSA-PSS with SHAKE to Section 3
* Added SECP curves the section on ECDSA with SHA2, ECDSA with
SHAKE, and EdDSA to Section 3 as discussed at IETF 109
* Deleted static-static D-H and ECDH from Section 4.1 based on the
discussion on the mailing list (see thread "[CMP Algorithms]
Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement
algorithms for use in CMP")
* Added ECDH OIDs and SECP curves, as well as ECDH with curve25519
and curve448 to Section 4.1 as discussed at IETF 109
* Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109,
but re-added it after discussion on the mailing list (see thread
"Mail regarding draft-ietf-lamps-cmp-algorithms")
* Added a paragraph to Section 4.3.1 to explain that the algorithms
and key length for content encryption and key wrapping must be
aligned as discussed on the mailing list (see thread "[CMP
Algorithms] Use Key-Wrap with or without padding in Section 4.3
and Section 5")
* Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as
discussed at IETF 109
* Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing
list (see thread "Mail regarding draft-ietf-lamps-crmf-update-
algs-02") and restructured text in Section 6 to be easier to
differentiate between password- and shared-key-based MAC
* Deleted Diffie-Hellmann based MAC from Section 6 as is only
relevant when using enrolling Diffie-Hellmann certificates
* Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at
IETF 109
* Extended Section 9 to mention Russ supporting with two additional
I-Ds and name further supporters of the draft
* Added a first draft of a generic algorithm selection guideline to
Appendix A
* Added a first proposal for mandatory algorithms for the
Lightweight CMP Profile to Appendix A
* Minor changes in wording
From version 00 -> 01: Thanks to Russ Housley for his work on [RFC9044] and [RFC9045] upon
which this RFC relies heavily.
* Changed sections Symmetric Key-Encryption Algorithms and Content May thanks also to all reviewers like Serge Mister, Mark Ferreira,
Encryption Algorithms based on the discussion on the mailing list Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb, and
(see thread "[CMP Algorithms] Use Key-Wrap with or without padding Steffen Fries for their input and feedback to this document.
in Section 4.3 and Section 5") Apologies to all not mentioned reviewers and supporters.
* Added Appendix A with updated algorithms profile for RDC4210
Appendix D.2 and first proposal for the Lightweight CMP Profile
* Minor changes in wording
Authors' Addresses Authors' Addresses
Hendrik Brockhaus (editor) Hendrik Brockhaus
Siemens AG Siemens AG
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
Hans Aschauer Hans Aschauer
Siemens AG Siemens AG
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hans.aschauer@siemens.com Email: hans.aschauer@siemens.com
URI: https://www.siemens.com
Mike Ounsworth Mike Ounsworth
Entrust Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: mike.ounsworth@entrust.com Email: mike.ounsworth@entrust.com
URI: https://www.entrust.com
John Gray John Gray
Entrust Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: john.gray@entrust.com Email: john.gray@entrust.com
URI: https://www.entrust.com
 End of changes. 214 change blocks. 
726 lines changed or deleted 584 lines changed or added

This html diff was produced by rfcdiff 1.48.