draft-ietf-lamps-cmp-algorithms-05.txt   draft-ietf-lamps-cmp-algorithms-06.txt 
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft H. Aschauer Internet-Draft H. Aschauer
Updates: 4210 (if approved) Siemens Updates: 4210 (if approved) Siemens
Intended status: Standards Track M. Ounsworth Intended status: Standards Track M. Ounsworth
Expires: 8 November 2021 J. Gray Expires: 1 January 2022 J. Gray
Entrust Entrust
7 May 2021 30 June 2021
Certificate Management Protocol (CMP) Algorithms Certificate Management Protocol (CMP) Algorithms
draft-ietf-lamps-cmp-algorithms-05 draft-ietf-lamps-cmp-algorithms-06
Abstract Abstract
This document describes the conventions for using concrete This document describes the conventions for using concrete
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. X.509 certificates.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 November 2021. This Internet-Draft will expire on 1 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 21 skipping to change at page 2, line 21
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3
2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 4 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5
3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7
4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 7 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8
4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8
4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10
4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11
4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11
4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12
4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12
5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12
5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 13 skipping to change at page 3, line 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 22 11. Normative References . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . 26 12. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. History of changes . . . . . . . . . . . . . . . . . 26 Appendix A. History of changes . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174] when, and only when, they appear in all capitals, as shown 14[RFC2119] [RFC8174]when, and only when, they appear in all
here. capitals, as shown here.
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 the hashAlg field of Digest algorithm identifiers are located in the hashAlg field of
OOBCertHash, the owf field of Challenge, PBMParameter, and OOBCertHash, the owf field of Challenge, PBMParameter, CertStatus,
DHBMParameter, and the digestAlgorithms field of SignedData and the and DHBMParameter, and the digestAlgorithms field of SignedData and
digestAlgorithm field of SignerInfo. the digestAlgorithm field of SignerInfo.
Digest values are located in the hashVal field of OOBCertHash, the Digest values are located in the hashVal field of OOBCertHash, the
witness field of Challenge, and the certHash field of CertStatus. In witness field of Challenge, and the certHash field of CertStatus. In
addition, digest values are input to signature algorithms. addition, digest values are input to signature algorithms.
Note: Specific conventions are needed for CertStatus content in
certConf messages when confirming certificates where the
AlgorithmIdentifier of the certificate signature does not clearly
imply a specific hash algorithm. In such cases the hash algorithm to
use to build certHash should be specified, e.g., as done
inSection 2.1andSection 2.2for certificates signed using EdDSA.
2.1. SHA2 2.1. SHA2
The SHA2 algorithm family is defined in FIPS Pub 180-4 The SHA2 algorithm family is defined inFIPS 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:
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) id-sha224 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) 4 } hashalgs(2) 4 }
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 inRFC 5754
Section 2 [RFC5754]. Section 2 [RFC5754].
The hash algorithm used to calculate the certHash in certConf
messages MUST be SHA512 if the certificate to be confirmed has been
signed using EdDSA with Ed25519.
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 inFIPS Pub 202
[NIST.FIPS.202] and includes fixed output length variants SHA3-224, [NIST.FIPS.202]and includes fixed output length variants SHA3-224,
SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output
functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and
SHAKE256 are the only members of the SHA3-family which are specified SHAKE256 are the only members of the SHA3-family which are specified
for use in X.509 and PKIX [RFC8692], and CMS [RFC8702]. Therefore, for use in X.509 and PKIX[RFC8692], and CMS[RFC8702]. Therefore, CMP
CMP specifies them as defined in RFC 8702 [RFC8702], which are specifies them as defined inRFC 8702 [RFC8702], which are identified
identified by the following OIDs: by 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 inRFC 8702
Section 3.1 [RFC8702]. Section 3.1 [RFC8702].
The hash algorithm used to calculate the certHash in certConf
messages MUST be SHAKE256 if the certificate to be confirmed has been
signed using EdDSA with Ed448.
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 RSA,
ECDSA, or EdDSA signature algorithms. ECDSA, or EdDSA signature algorithms.
The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, The signature algorithm is referred to as MSG_SIG_ALG
RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP inSection 7.2,RFC 4210 Appendix D and E [RFC4210], and in
Profile [I-D.ietf-lamps-lightweight-cmp-profile]. theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].
Signature algorithm identifiers are located in the protectionAlg Signature algorithm identifiers are located in the protectionAlg
field of PKIHeader, the algorithmIdentifier field of POPOSigningKey, field of PKIHeader, the algorithmIdentifier field of POPOSigningKey,
signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, signatureAlgorithm field of CertificationRequest, SignKeyPairTypes,
and the SignerInfo signatureAlgorithm field of SignedData. and the SignerInfo signatureAlgorithm field of SignedData.
Signature values are located in the protection field of PKIMessage, Signature values are located in the protection field of PKIMessage,
signature field of POPOSigningKey, signature field of signature field of POPOSigningKey, signature field of
CertificationRequest, and SignerInfo signature field of SignedData. CertificationRequest, and SignerInfo signature field of SignedData.
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 inRFC 8017 [RFC8017].
The algorithm identifiers for RSASAA-PSS signatures used with SHA2 The algorithm identifiers 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 inRFC 4056
[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 are 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 inRFC 8702
Section 3.2.1 [RFC8702]. Section 3.2.1 [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 inRFC 5754
Section 3.2 [RFC5754]. Section 3.2 [RFC5754].
3.2. ECDSA 3.2. ECDSA
The ECDSA signature algorithm is defined in FIPS Pub 186-4 The ECDSA signature algorithm is defined inFIPS Pub 186-4
[NIST.FIPS.186-4]. [NIST.FIPS.186-4].
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)
skipping to change at page 6, line 39 skipping to change at page 6, line 48
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 inRFC 5754
Section 3.3 [RFC5754]. Section 3.3 [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 are 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 inRFC 8702
Section 3.2.2 [RFC8702]. Section 3.2.2 [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 inRFC 8032 Section 3.3
[RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. [RFC8032]andFIPS Pub 186-5 (Draft) [NIST.FIPS.186-5].
The signature algorithm Ed25519 MUST be used with SHA-512 message The signature algorithm Ed25519 MUST be used with SHA-512 message
digest algorithms is identified by the following OIDs: 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 MUST be used with SHAKE256 message The signature algorithm Ed448 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 inRFC 8419
[RFC8419]. [RFC8419].
Note: The hash algorithm used to calculate the certHash in certConf
messages MUST be SHA512 if the certificate to be confirmed has been
signed using Ed25519, seeSection 2.1, and SHAKE256 if signed using
Ed448, seeSection 2.2.
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]andCMP Updates [I-D.ietf-lamps-cmp-updates]promotes the
the use of CMS [RFC5652] EnvelopedData by deprecating the use of use ofCMS [RFC5652]EnvelopedData 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 inRFC 4210
RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the Appendix D and E [RFC4210]and as KM_KA_ALG in theLightweight CMP
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as Profile [I-D.ietf-lamps-lightweight-cmp-profile], as well as
well as in Section 7. inSection 7.
Key agreement algorithms are only used in CMP when using CMS Key agreement algorithms are only used in CMP when usingCMS
[RFC5652] EnvelopedData together with the key agreement key [RFC5652]EnvelopedData together with the key agreement key management
management technique. When a key agreement algorithm is used, a key- technique. When a key agreement algorithm is used, a key-encryption
encryption algorithm (Section 4.3) is needed next to the content- algorithm (Section 4.3) is needed next to the content-encryption
encryption algorithm (Section 5). algorithm (Section 5).
Key agreement algorithm identifiers are located in the EnvelopedData Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
Key encryption algorithm identifiers are located in the EnvelopedData Key encryption algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field. RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field. encryptedKey field.
4.1.1. Diffie-Hellman 4.1.1. Diffie-Hellman
Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and Diffie-Hellman key agreement is defined inRFC 2631 [RFC2631]and SHALL
SHALL be used in the ephemeral-static as specified in RFC 3370 be used in the ephemeral-static as specified inRFC 3370 [RFC3370].
[RFC3370]. Static-static variants SHALL NOT be used. Static-static variants SHALL NOT be used.
The Diffie-Hellman key agreement algorithm is identified by the The Diffie-Hellman 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 inRFC 3370
Section 4.1 [RFC3370]. Section 4.1 [RFC3370].
4.1.2. ECDH 4.1.2. ECDH
Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined
RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant inRFC 5753 [RFC5753]and SHALL be used in the ephemeral-static variant
as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as as specified inRFC 5753 [RFC5753]or the 1-Pass ECMQV variant as
specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be specified inRFC 5753 [RFC5753]. Static-static variants SHALL NOT be
used. 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)
skipping to change at page 9, line 48 skipping to change at page 9, line 48
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 inRFC 5753
[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 are 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 inRFC 8418
[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
RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the inRFC 4210 Appendix D and E [RFC4210]and as KM_KL_ALG in
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile],
well as in Section 7. as well as inSection 7.
Key transport algorithms are only used in CMP when using CMS Key transport algorithms are only used in CMP when usingCMS
[RFC5652] EnvelopedData together with the key transport key [RFC5652]EnvelopedData together with the key transport key management
management technique. technique.
Key transport algorithm identifiers are located in the EnvelopedData Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
Key transport encrypted content-encryption keys are located in the Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
field. field.
4.2.1. RSA 4.2.1. RSA
skipping to change at page 10, line 47 skipping to change at page 10, line 47
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 inRFC 3370 Section 4.2.1 [RFC3370]and for RSAES-OAEP inRFC 3560
[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 inSection 7.2and in theLightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile]. [I-D.ietf-lamps-lightweight-cmp-profile].
As symmetric key-encryption key management technique is not used by As symmetric key-encryption key management technique is not used by
CMP, the symmetric key-encryption algorithm is only needed when using CMP, the symmetric key-encryption algorithm is only needed when using
the key agreement or password-based key management technique with CMS the key agreement or password-based key management technique withCMS
[RFC5652] EnvelopedData. [RFC5652]EnvelopedData.
Key-encryption algorithm identifiers are located in the EnvelopedData Key-encryption algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
EnvelopedData RecipientInfos PasswordRecipientInfo EnvelopedData RecipientInfos PasswordRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey and EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey and EnvelopedData RecipientInfos PasswordRecipientInfo
encryptedKey fields. encryptedKey fields.
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 inFIPS Pub 197
[NIST.FIPS.197] and the key wrapping is defined in RFC 3394 [NIST.FIPS.197]and the key wrapping is defined inRFC 3394 [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
RFC 8551 [RFC8551]. alsoRFC 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 inRFC 3394 Section 2.2 [RFC3394]andRFC 3565 Section 2.3.2 [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
Section 7.2 and in the Lightweight CMP Profile inSection 7.2and in theLightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile]. [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 usingCMS
[RFC5652] EnvelopedData together with password-based key management [RFC5652]EnvelopedData together with password-based key management
technique. technique.
Key derivation algorithm identifiers are located in the EnvelopedData Key derivation algorithm identifiers are located in the EnvelopedData
RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm field. RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm field.
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 MAC-based EnvelopedData as specified in CMP Updates together with MAC-based
PKIProtection, the salt for the password-based MAC and KDF must be PKIProtection, the salt for the password-based MAC and KDF must be
chosen independently to ensure usage of independent symmetric keys. 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 The password-based key derivation function 2 (PBKDF2) is defined
RFC 8018 [RFC8018]. inRFC 8018 [RFC8018].
Password-based key derivation function 2 has the algorithm Password-based key derivation function 2 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
RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. inRFC 3370 Section 4.4.1 [RFC3370]andRFC 8018 Section 5.2 [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 inSection 7,RFC 4210 Appendix D and E [RFC4210], and theLightweight
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].
Content encryption algorithms are only used in CMP when using CMS Content encryption algorithms are only used in CMP when using CMS
[RFC5652] EnvelopedData to transport a signed private key package in [RFC5652] EnvelopedData 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 the Content encryption algorithm identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.
Encrypted content is located in the EnvelopedData Encrypted content is located in the EnvelopedData
EncryptedContentInfo encryptedContent field. EncryptedContentInfo encryptedContent field.
5.1. AES-CBC 5.1. AES-CBC
The AES encryption algorithm is defined in FIPS Pub 197 The AES encryption algorithm is defined inFIPS Pub 197
[NIST.FIPS.197]. [NIST.FIPS.197].
AES-CBC content encryption has the algorithm identifier: 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 inRFC 3565 [RFC3565].
6. Message Authentication Code Algorithms 6. Message Authentication Code Algorithms
The message authentication code is either used for shared secret- The message authentication code is either used for shared secret-
based CMP message protection or together with the password-based key based CMP message protection or together with the password-based key
derivation function (PBKDF2). derivation function (PBKDF2).
The message authentication code algorithm is also referred to as The message authentication code algorithm is also referred to as
MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and MSG_MAC_ALG inSection 7,RFC 4210 Appendix D and E [RFC4210], and
the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. theLightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].
6.1. Password-based MAC 6.1. Password-based MAC
Password-based MAC algorithms combine the derivation of a symmetric Password-based MAC algorithms combine the derivation of a symmetric
key from a password or other shared secret information and a key from a password or other shared secret information and a
symmetric key-based MAC function as specified in Section 6.2 using symmetric key-based MAC function as specified in Section 6.2 using
this derived key. this derived key.
Message authentication code algorithm identifiers are located in the Message authentication code algorithm identifiers are located in the
protectionAlg field of PKIHeader. protectionAlg field of PKIHeader.
Message authentication code values are located in the PKIProtection Message authentication code values are located in the PKIProtection
field. field.
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 inRFC 4210 Section 5.1.3.1
[RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements [RFC4210],RFC 4211 Section 4.4 [RFC4211], andAlgorithm 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) [I-D.ietf-lamps-crmf-update-algs]. 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 password-based MAC are
specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 specified inRFC 4210 Section 5.1.3.1 [RFC4210],RFC 4211 Section 4.4
[RFC4211], and Algorithm Requirements Update to the Internet X.509 [RFC4211], andAlgorithm Requirements Update to the Internet X.509
Public Key Infrastructure Certificate Request Message Format (CRMF) Public Key Infrastructure Certificate Request Message Format (CRMF)
[I-D.ietf-lamps-crmf-update-algs]. [RFC9045].
6.1.2. PBMAC1 6.1.2. PBMAC1
The Password-Based Message Authentication Code 1 (PBMAC1) is defined The Password-Based Message Authentication Code 1 (PBMAC1) is defined
in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key inRFC 8018 [RFC8018]. PBMAC1 combines a password-based key
derivation function like PBKDF2 (Section 4.4.1) with an underlying derivation function like PBKDF2 (Section 4.4.1) with an underlying
symmetric key-based message authentication scheme. symmetric key-based 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
RFC 8018 Section 7.1 and A.5 [RFC8018]. inRFC 8018 Section 7.1 and A.5 [RFC8018].
6.2. Symmetric key-based MAC 6.2. Symmetric key-based MAC
Symmetric key-based MAC algorithms are used for deriving the Symmetric key-based MAC algorithms are used for deriving the
symmetric encryption key when using PBKDF2 as described in symmetric encryption key when using PBKDF2 as described
Section 4.4.1 as well as with Password-based MAC as described in inSection 4.4.1as well as with Password-based MAC as described
Section 6.1. inSection 6.1.
Message authentication code algorithm identifiers are located in the Message authentication code algorithm identifiers are located in the
protectionAlg field of PKIHeader, the mac field of PBMParameter, the protectionAlg field of PKIHeader, the mac field of PBMParameter, the
messageAuthScheme field of PBMAC1, and the prf field of messageAuthScheme field of PBMAC1, and the prf field of
PBKDF2-params. PBKDF2-params.
Message authentication code values are located in the PKIProtection Message authentication code values are located in the PKIProtection
field. field.
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 inRFC 2104 [RFC2104]andFIPS 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 inRFC 4231 Section 3.1 [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 inFIPS Pub 197
NIST SP 800-38d [NIST.SP.800-38d]. [NIST.FIPS.197]andNIST SP 800-38d [NIST.SP.800-38d].
NOTE: AES-GMAC MUST NOT be used twice with the same parameter set, NOTE: AES-GMAC MUST NOT be used twice with the same parameter set,
especially the same nonce. Therefore, it MUST NOT be used together especially the same nonce. Therefore, it MUST NOT be used together
with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES-
GMAC is only used as message authentication scheme and not for the GMAC is only used as message authentication scheme and not for the
key derivation function PBKDF2. 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 AES-GMAC are specified
draft-ietf-lamps-cms-aes-gmac-alg [I-D.ietf-lamps-cms-aes-gmac-alg]. inRFC 9044 [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 inRFC 8702 [RFC8702]andFIPS 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) 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) 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 inRFC 8702 Section 3.4 [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 likeNIST SP 800-57 Recommendation for Key Management
[NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols [NIST.SP.800-57pt1r5]andECRYPT Algorithms, Key Size and Protocols
Report (2018) [ECRYPT.CSA.D5.4] provide general information on Report (2018) [ECRYPT.CSA.D5.4]provide general information on current
current cryptographic algorithms. cryptographic algorithms.
The following criteria will help implementers choose appropriate The following criteria will help implementers choose appropriate
algorithms for managing certificates: algorithms for managing certificates:
* The cryptographic strength of the algorithm with the lowest * The cryptographic strength of the algorithm with the lowest
security. security.
Note: To avoid consuming too much computational resources it is Note: To avoid consuming too much computational resources it is
recommended to choose a set of algorithms offering roughly the recommended to choose a set of algorithms offering roughly the
same level of security. same level of security.
skipping to change at page 17, line 8 skipping to change at page 17, line 8
* The entropy of the shared secret information or password when MAC- * The entropy of the shared secret information or password when MAC-
based message protection is used, e.g., MSG_MAC_ALG. based message protection is used, e.g., MSG_MAC_ALG.
Finally, the cryptographic strength of the system SHOULD be at least Finally, the cryptographic strength of the system SHOULD be at least
as strong as the algorithms and keys used for the certificate being as strong as the algorithms and keys used for the certificate being
managed. managed.
7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles
The following table contains definitions of algorithms used within The following table contains definitions of algorithms used within
PKI Management Message Profiles as defined in CMP Appendix D.2 PKI Management Message Profiles as defined inCMP Appendix D.2
[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 which MUST be supported by conforming
implementations implementations
Change from 4210: Shows the changes in the Mandatory and Other Change from 4210: Shows the changes in the Mandatory and Other
algorithms from RFC 4210 [RFC4210]. These are included for backwards algorithms fromRFC 4210 [RFC4210]. These are included for backwards
compatibility considerations. compatibility considerations.
+============+===============+==================+===================+ +============+===============+==================+===================+
|Name |Use | Mandatory |Change from 4210 | |Name |Use | Mandatory |Change from 4210 |
+============+===============+==================+===================+ +============+===============+==================+===================+
|MSG_SIG_ALG |protection of | RSA |DSA/SHA1 | |MSG_SIG_ALG |protection of | RSA |DSA/SHA1 |
| |PKI messages | |Others: RSA/MD5, | | |PKI messages | |Others: RSA/MD5, |
| |using signature| |ECDSA | | |using signature| |ECDSA |
+------------+---------------+------------------+-------------------+ +------------+---------------+------------------+-------------------+
|MSG_MAC_ALG |protection of | PasswordBasedMac |PasswordBasedMac | |MSG_MAC_ALG |protection of | PasswordBasedMac |PasswordBasedMac |
skipping to change at page 18, line 50 skipping to change at page 18, line 50
| |bits (a key of | | | | |bits (a key of | | |
| |this type is | | | | |this type is | | |
| |encrypted using| | | | |encrypted using| | |
| |PROT_ENC_ALG) | | | | |PROT_ENC_ALG) | | |
+------------+---------------+------------------+-------------------+ +------------+---------------+------------------+-------------------+
Table 1 Table 1
Mandatory Algorithm Identifiers and Specifications: Mandatory Algorithm Identifiers and Specifications:
RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 RSA: sha256WithRSAEncryption with 2048 bit, seeSection 3.1
PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- PasswordBasedMac: id-PasswordBasedMac, seeSection 6.1(with id-sha256
sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as as the owf parameter, seeSection 2.1and id-hmacWithSHA256 as the mac
the mac parameter, see Section 6.2.1) parameter, seeSection 6.2.1)
PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key PBMAC1: id-PBMAC1, seeSection 6.1.2(with id-PBKDF2 as the key
derivation function, see Section 4.4.1 and id-hmacWithSHA256 as derivation function, seeSection 4.4.1and id-hmacWithSHA256 as message
message authentication scheme, see Section 6.2.1). It is RECOMMENDED authentication scheme, seeSection 6.2.1). It is RECOMMENDED to
to prefer the usage of PBMAC1 instead of PasswordBasedMac. prefer the usage of PBMAC1 instead of PasswordBasedMac.
D-H: id-alg-ESDH, see Section 4.1.1 D-H: id-alg-ESDH, seeSection 4.1.1
AES-wrap: id-aes256-wrap, see Section 4.3.1 AES-wrap: id-aes256-wrap, seeSection 4.3.1
AES-CBC: id-aes256-CBC, see Section 5.1 AES-CBC: id-aes256-CBC, seeSection 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 which MAY be
supported by implementations of the Lightweight CMP Profile supported by implementations of theLightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile]. [I-D.ietf-lamps-lightweight-cmp-profile].
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 messages
protection, and the certificates to be managed, this document will protection, and the certificates to be managed, this document will
not specify a specific set that is mandatory to support for not specify a specific set that is mandatory to support for
conforming implementations. conforming implementations.
The columns in the table are: The columns in the table are:
skipping to change at page 21, line 7 skipping to change at page 21, line 7
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
Table 2 Table 2
8. IANA Considerations 8. IANA Considerations
This document does not request changes to the IANA registry. This document does not request changes to the IANA registry.
9. Security Considerations 9. Security Considerations
RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, RFC 4210 Appendix D.2 [RFC4210]contains a set of algorithms,
mandatory to be supported by conforming implementations. Theses mandatory to be supported by conforming implementations. Theses
algorithms were appropriate at the time CMP was released, but as algorithms were appropriate at the time CMP was released, but as
cryptographic algorithms weaken over time, some of them should not be cryptographic algorithms weaken over time, some of them should not be
used anymore. In general, new attacks are emerging due to research used anymore. In general, new attacks are emerging due to research
cryptoanalysis or increase in computing power. New algorithms were cryptoanalysis or increase in computing power. New algorithms were
introduced that are more resistant to today's attacks. introduced that are more resistant to today's attacks.
This document lists many cryptographic algorithms usable with CMP to This document lists many cryptographic algorithms usable with CMP to
offer implementers 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 define the security of the overall solution,
Section 7. seeSection 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-known preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known
scrutinized algorithm, which is not true for PasswordBasedMac and scrutinized algorithm, which is not true for PasswordBasedMac and
second, there exists a theoretical weakness in PasswordBasedMac, second, there exists a theoretical weakness in PasswordBasedMac,
where the generated MAC key can be easily distinguished from a random where the generated MAC key can be easily distinguished from a random
key. key.
AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2;
the use of AES-GMAC more than once with the same key and the same the use of AES-GMAC more than once with the same key and the same
nonce will break the security. nonce will break the security.
In Section 7 of this document there is also an update to the InSection 7of this document there is also an update to
Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY theAppendix D.2 of RFC 4210 [RFC4210]and a set of algorithms that MAY
be supported when implementing the Lightweight CMP Profile be supported when implementing theLightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile]. [I-D.ietf-lamps-lightweight-cmp-profile].
To keep the list of algorithms to be used with CMP up to date and to To keep the list of algorithms to be used with CMP up to date and to
enlist secure algorithms resisting known attack scenarios, future enlist secure algorithms resisting known attack scenarios, future
algorithms should be added and weakened algorithms should be algorithms should be added and weakened algorithms should be
deprecated. deprecated.
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 fromAppendix D.2 of
RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for
PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. In most PROT_SYM_ALG but inRFC 4210 [RFC4210]3-DES was mandatory. In most
cases the newer mandatory algorithms were listed as "other" cases the newer mandatory algorithms were listed as "other"
algorithms in RFC 4210 [RFC4210]. Therefore, it is expected that algorithms inRFC 4210 [RFC4210]. Therefore, it is expected that many
many CMP systems may already support the recommended algorithms in CMP systems may already support the recommended algorithms in this
this specification. In such systems the weakened algorithms should specification. In such systems the weakened algorithms should be
be disabled from further use. If critical systems cannot be disabled from further use. If critical systems cannot be immediately
immediately updated to conform to the recommended algorithm use updated to conform to the recommended algorithm use profile, it is
profile, it is recommended a plan to migrate the infrastructure to recommended a plan to migrate the infrastructure to conforming
conforming profiles be adopted as soon as possible. profiles be adopted as soon as possible.
10. Acknowledgements 10. Acknowledgements
Thanks to Russ Housley for supporting this draft with submitting Thanks to Russ Housley for supporting this draft with
[I-D.ietf-lamps-cms-aes-gmac-alg] and submitting[RFC9044]and[RFC9045].
[I-D.ietf-lamps-crmf-update-algs].
May thanks also to all reviewers like Serge Mister, Mark Ferreira, May thanks also to all reviewers like Serge Mister, Mark Ferreira,
Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen
Fries for their input and feedback to this document. Apologies to Fries for their input and feedback to this document. Apologies to
all not mentioned reviewers and supporters. all not mentioned reviewers and supporters.
11. Normative References 11. Normative References
[I-D.ietf-lamps-cmp-updates] [I-D.ietf-lamps-cmp-updates]
Brockhaus, H. and D. V. Oheimb, "Certificate Management Brockhaus, H. and D. V. Oheimb, "Certificate Management
Protocol (CMP) Updates", Work in Progress, Internet-Draft, Protocol (CMP) Updates", Work in Progress, Internet-Draft,
draft-ietf-lamps-cmp-updates-10, 4 May 2021, draft-ietf-lamps-cmp-updates-10, 4 May 2021,
<https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
10>. cmp-updates-10>.
[I-D.ietf-lamps-cms-aes-gmac-alg]
Housley, R., "Using the AES-GMAC Algorithm with the
Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-ietf-lamps-cms-aes-gmac-alg-05, 2
April 2021, <https://tools.ietf.org/html/draft-ietf-lamps-
cms-aes-gmac-alg-05>.
[I-D.ietf-lamps-crmf-update-algs]
Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", Work in Progress,
Internet-Draft, draft-ietf-lamps-crmf-update-algs-07, 8
April 2021, <https://tools.ietf.org/html/draft-ietf-lamps-
crmf-update-algs-07>.
[NIST.FIPS.180-4] [NIST.FIPS.180-4]
Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS
180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, 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] [NIST.FIPS.186-4]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4,
skipping to change at page 26, line 10 skipping to change at page 25, line 49
[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>.
[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
Cryptographic Message Syntax (CMS)", RFC 9044,
DOI 10.17487/RFC9044, June 2021,
<https://www.rfc-editor.org/info/rfc9044>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>.
12. Informative References 12. 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>.
[I-D.ietf-lamps-lightweight-cmp-profile] [I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight
Certificate Management Protocol (CMP) Profile", Work in Certificate Management Protocol (CMP) Profile", Work in
Progress, Internet-Draft, draft-ietf-lamps-lightweight- Progress, Internet-Draft, draft-ietf-lamps-lightweight-
cmp-profile-05, 22 February 2021, cmp-profile-05, 22 February 2021,
<https://tools.ietf.org/html/draft-ietf-lamps-lightweight- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cmp-profile-05>. lightweight-cmp-profile-05>.
[NIST.SP.800-57pt1r5] [NIST.SP.800-57pt1r5]
Barker, Elaine., "Recommendation for key management:part 1 Barker, Elaine., "Recommendation for key management:part 1
- general", NIST NIST SP 800-57pt1r5, - general", NIST NIST SP 800-57pt1r5,
DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 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/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
skipping to change at page 26, line 49 skipping to change at page 26, line 50
Infrastructure: Additional Algorithm Identifiers for Infrastructure: Additional Algorithm Identifiers for
RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
DOI 10.17487/RFC8692, December 2019, DOI 10.17487/RFC8692, December 2019,
<https://www.rfc-editor.org/info/rfc8692>. <https://www.rfc-editor.org/info/rfc8692>.
Appendix A. History of changes Appendix A. History of changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
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: From version 04 -> 05:
* Minor changes and corrections in wording * Minor changes and corrections in wording
From version 03 -> 04: From version 03 -> 04:
* Added John Gray to the list of authors due to his extensive * Added John Gray to the list of authors due to his extensive
support and valuable feedback support and valuable feedback
* Added some clarification of the use AES-GMAC to Section 6.2.1 * 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 * Extended the guidance on how to select a set of algorithms in
Section 7 and deleted former Section 7.1 Section 7 and deleted former Section 7.1
* Deleted the algorithms mandatory to support in Section 7.2 as * Deleted the algorithms mandatory to support in Section 7.2 as
discussed at IETF 110 discussed at IETF 110
* Extended the Security considerations in Section 9 * Extended the Security considerations in Section 9
 End of changes. 85 change blocks. 
164 lines changed or deleted 187 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/