draft-ietf-lamps-cmp-algorithms-09.txt   draft-ietf-lamps-cmp-algorithms-10.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: 25 June 2022 J. Gray Expires: 18 August 2022 J. Gray
Entrust Entrust
22 December 2021 14 February 2022
Certificate Management Protocol (CMP) Algorithms Certificate Management Protocol (CMP) Algorithms
draft-ietf-lamps-cmp-algorithms-09 draft-ietf-lamps-cmp-algorithms-10
Abstract Abstract
This document updates RFC 4210 describing the conventions for using This document updates RFC 4210 describing the conventions for using
concrete cryptographic algorithms with the Certificate Management concrete cryptographic algorithms with the Certificate Management
Protocol (CMP). CMP is used to enroll and further manage the Protocol (CMP). CMP is used to enroll and further manage the
lifecycle of X.509 certificates. lifecycle of 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 25 June 2022. This Internet-Draft will expire on 18 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7
4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8
4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8
4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10
4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . 13 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12
5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Message Authentication Code Algorithms . . . . . . . . . . . 14 6. Message Authentication Code Algorithms . . . . . . . . . . . 13
6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 14 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 13
6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14
6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 14
6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 15
6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15 6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15
6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16
7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16
7.1. Algorithm Profile for RFC 4210 PKI Management Message 7.1. Algorithm Profile for RFC 4210 PKI Management Message
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. Normative References . . . . . . . . . . . . . . . . . . . . 25 11. Normative References . . . . . . . . . . . . . . . . . . . . 24
12. Informative References . . . . . . . . . . . . . . . . . . . 29 12. Informative References . . . . . . . . . . . . . . . . . . . 28
Appendix A. History of changes . . . . . . . . . . . . . . . . . 30 Appendix A. History of changes . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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", "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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 4, line 43 skipping to change at page 4, line 35
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] as one-way for use in X.509 and PKIX [RFC8692], and CMS [RFC8702] as one-way
hash function for use with RSASSA-PSS and ECDSA as one-way hash hash function for use with RSASSA-PSS and ECDSA as one-way hash
function for use with RSASSA-PSS and ECDSA. function 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 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 message digested by the SHAKE function MUST be appended with the the output length MUST be 256 bits for SHAKE128 and 512 bits for
OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and SHAKE256.
"CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits
for SHAKE128 and 512 bits for SHAKE256.
< ToDo: This note must be checked and confirmed by experts. >
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 }
skipping to change at page 8, line 9 skipping to change at page 7, line 45
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 RFC 8419
[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 and SHAKE256 with d=512 if signed using Ed448.
< ToDo: This note must be checked and confirmed by experts. >
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 [I-D.ietf-lamps-cmp-updates] promotes
the use of CMS [RFC5652] EnvelopedData by deprecating the use of the use of CMS [RFC5652] EnvelopedData by deprecating the use of
EncryptedValue. EncryptedValue.
4.1. Key Agreement Algorithms 4.1. Key Agreement Algorithms
skipping to change at page 17, line 5 skipping to change at page 16, line 10
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 in
RFC 9044 [RFC9044]. RFC 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 in RFC 8702 [RFC8702] and
FIPS SP 800-185 [NIST.SP.800-185]. FIPS SP 800-185 [NIST.SP.800-185].
Note: Currently it is assumed that the advantage of a HW
implementation over a SW implementation of KMAC is greater than of
HMAC-SHA2. Therefore, the advantage of an attacker is greater if
KMAC is used as a prf in PasswordBasedMac and PBKDF2. For this
reason, the use of KMAC as a prf in PasswordBasedMac and PBKDF2 is
discouraged.
< ToDo: This note must be checked and confirmed by experts. >
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
skipping to change at page 18, line 20 skipping to change at page 17, line 16
algorithms used for the key management technique (Section 7.2: algorithms used for the key management technique (Section 7.2:
PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) PROT_ENC_ALG or Section 7.1: 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.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1:
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 certificate 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 column does not provide respective PKI management operation. If one row does not provide a
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 of |Recommended|RSA / D-H|Elliptic |Hash function |Symmetric | |Bits of |Recommended |RSA / D-H|Elliptic curve|Hash |Symmetric |
|security|for | |curve |or XOF with |encryption| |security|for managing| | |function |encryption|
| |managing | | |specified | | | |keys up to | | |or XOF | |
| |keys up to | | |output length | | | | | | |with | |
| | | | |(d) | | | | | | |specified| |
+========+===========+=========+=========+===============+==========+ | | | | |output | |
|112 |RSA2048 |RSA2048 |secp224r1|SHA224 | | | | | | |length | |
| |secp224r1 |D-H(2048)| | | | | | | | |(d) | |
+--------+-----------+---------+---------+---------------+----------+ +========+============+=========+==============+=========+==========+
|128 |RSA3072 |RSA3072 |secp256r1|SHA256 |AES-128 | |112 |RSA2048, |RSA2048, |ECDSA/ECDH |SHA224 | |
| |secp256r1 |D-H(3072)|Ed25519/ |SHAKE128(d=256)| | | |secp224r1 |D-H(2048)|(secp224r1) | | |
| |Ed25519 | |X25519 | | | +--------+------------+---------+--------------+---------+----------+
+--------+-----------+---------+---------+---------------+----------+ |128 |RSA3072, |RSA3072, |ECDSA/ECDH |SHA256, |AES-128 |
|192 |secp384r1 | |secp384r1|SHA384 |AES-192 | | |secp256r1, |D-H(3072)|(secp256r1), |SHAKE128 | |
+--------+-----------+---------+---------+---------------+----------+ | |Curve25519 | |Ed25519/X25519|(d=256) | |
|224 |Ed448 | |Ed448/ | | | +--------+------------+---------+--------------+---------+----------+
| | | |X448 | | | |192 |secp384r1 | |ECDSA/ECDH |SHA384 |AES-192 |
+--------+-----------+---------+---------+---------------+----------+ | | | |(secp384r1) | | |
|256 |secp521r1 | |secp521r1|SHA512 |AES-256 | +--------+------------+---------+--------------+---------+----------+
| | | | |SHAKE256(d=512)| | |224 |Curve448 | |Ed448/X448 | | |
+--------+-----------+---------+---------+---------------+----------+ +--------+------------+---------+--------------+---------+----------+
|256 |secp521r1 | |ECDSA/ECDH |SHA512, |AES-256 |
| | | |(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 |Recommended |CMP protection |Key management | Key-wrap and | |Bits |Recommended |CMP protection |Key management | Key-wrap and |
|of |for managing | |technique | symmetric | |of |for managing | |technique | symmetric |
|secu-|keys up to | | | encryption | |secu-|keys up to | | | encryption |
skipping to change at page 19, line 30 skipping to change at page 18, line 30
| | |(2048, SHA224),|(2048), | | | | |(2048, SHA224),|(2048), | |
| | |ECDSA |ECDH | | | | |ECDSA |ECDH | |
| | |(secp224r1, |(secp224r1, | | | | |(secp224r1, |(secp224r1, | |
| | |SHA224 or |SHA224), | | | | |SHA224 or |SHA224), | |
| | |SHAKE128), |PBKDF2 (HMAC- | | | | |SHAKE128), |PBKDF2 (HMAC- | |
| | |PBMAC1 (HMAC- |SHA224) | | | | |PBMAC1 (HMAC- |SHA224) | |
| | |SHA224) | | | | | |SHA224) | | |
+-----+-------------+---------------+---------------+---------------+ +-----+-------------+---------------+---------------+---------------+
|128 |RSA3072, |RSASSA-PSS |ESDH (3072), | AES-128 | |128 |RSA3072, |RSASSA-PSS |ESDH (3072), | AES-128 |
| |secp256r1, |(3072, SHA256 |RSAES-OAEP | | | |secp256r1, |(3072, SHA256 |RSAES-OAEP | |
| |Ed25519 |or SHAKE128), |(3072, SHA256),| | | |Curve25519 |or SHAKE128), |(3072, SHA256),| |
| | |RSAEncryption |RSAEncryption | | | | |RSAEncryption |RSAEncryption | |
| | |(3072, SHA256),|(3072), | | | | |(3072, SHA256),|(3072), | |
| | |ECDSA |ECDH | | | | |ECDSA |ECDH | |
| | |(secp256r1, |(secp256r1, | | | | |(secp256r1, |(secp256r1, | |
| | |SHA256 or |SHA256), | | | | |SHA256 or |SHA256), | |
| | |SHAKE128), |ECDH (X25519), | | | | |SHAKE128), |X25519, | |
| | |Ed25519 |PBKDF2 (HMAC- | | | | |Ed25519 |PBKDF2 (HMAC- | |
| | |(SHA512), |SHA256) | | | | |(SHA512), |SHA256) | |
| | |PBMAC1 (HMAC- | | | | | |PBMAC1 (HMAC- | | |
| | |SHA256) | | | | | |SHA256) | | |
+-----+-------------+---------------+---------------+---------------+ +-----+-------------+---------------+---------------+---------------+
|192 |secp384r1 |ECDSA |ECDH | AES-192 | |192 |secp384r1 |ECDSA |ECDH | AES-192 |
| | |(secp384r1, |(secp384r1, | | | | |(secp384r1, |(secp384r1, | |
| | |SHA384), |SHA384), | | | | |SHA384), |SHA384), | |
| | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | |
| | |SHA384) |SHA384) | | | | |SHA384) |SHA384) | |
+-----+-------------+---------------+---------------+---------------+ +-----+-------------+---------------+---------------+---------------+
|224 |Ed448 |Ed448 |ECDH (X448) | | |224 |Curve448 |Ed448 |X448 | |
| | |(SHAKE256) | | | | | |(SHAKE256) | | |
+-----+-------------+---------------+---------------+---------------+ +-----+-------------+---------------+---------------+---------------+
|256 |secp521r1 |ECDSA |ECDH | AES-256 | |256 |secp521r1 |ECDSA |ECDH | AES-256 |
| | |(secp521r1, |(secp521r1, | | | | |(secp521r1, |(secp521r1, | |
| | |SHA512 or |SHA512), | | | | |SHA512 or |SHA512), | |
| | |SHAKE256), |PBKDF2 (HMAC- | | | | |SHAKE256), |PBKDF2 (HMAC- | |
| | |PBMAC1 (HMAC- |SHA512) | | | | |PBMAC1 (HMAC- |SHA512) | |
| | |SHA512) | | | | | |SHA512) | | |
+-----+-------------+---------------+---------------+---------------+ +-----+-------------+---------------+---------------+---------------+
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
< ToDo: Table 1 and 2 above must be checked and confirmed by experts.
>
To avoid consuming too much computational resources it is recommended To avoid consuming too much computational resources it is recommended
to choose a set of algorithms offering roughly the same level of to choose a set of algorithms offering roughly the same level of
security. Below are provided several algorithm profiles which are security. Below are provided several algorithm profiles which are
balanced, assuming the implementer chooses MAC secrets and/or balanced, assuming the implementer chooses MAC secrets and/or
certificate profiles of at least equivalent strength. certificate profiles of at least equivalent strength.
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 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 CMP Appendix D.2
skipping to change at page 24, line 23 skipping to change at page 23, line 23
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 implementer a more up to date choice. Finally, the algorithms offer implementer 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, see
Section 7. Section 7.
SHAKE is an extendable-output function and FIPS Pub 202
[NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
function. To prevent known attacks SHAKE MUST only be used as hash
function within CMP [RFC4210] and CMP Updates
[I-D.ietf-lamps-cmp-updates] if the output length is fixed to d=256
for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702] and
MUST NOT be used with different output lengths.
< ToDo: The above security consideration must be checked and
confirmed by experts. >
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 RFC 4211
Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018
Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update
to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018].
PBKDF2 is superior to PBKDF1 in an improved internal construct for PBKDF2 is superior to PBKDF1 in an improved internal construct for
iterated hashing, and in removing PBKDF1's limitation of only being iterated hashing, and in removing PBKDF1's limitation of only being
able to derive keys up to the size of the underlying hash function. able to derive keys up to the size of the underlying hash function.
skipping to change at page 25, line 9 skipping to change at page 23, line 45
algorithm by most standards bodies, and therefore presents algorithm by most standards bodies, and therefore presents
difficulties to implementer who are submitting their CMP difficulties to implementer 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; 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.
Currently it is assumed that the advantage of a HW implementation
over a SW implementation of KMAC is greater than of HMAC-SHA2.
Therefore, the advantage of an attacker is greater if KMAC is used as
a prf in PasswordBasedMac and PBKDF2. For this reason, the use of
KMAC as a prf in PasswordBasedMac and PBKDF2 is discouraged.
< ToDo: This security consideration must be checked and confirmed by
experts. >
In Section 7 of this document there is also an update to the 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 Appendix 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 the Lightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile]. [I-D.ietf-lamps-lightweight-cmp-profile].
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 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. PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory.
Therefore, it is expected that many CMP systems may already support Therefore, it is expected that many CMP systems may already support
skipping to change at page 26, line 8 skipping to change at page 24, line 34
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., Oheimb, D. V., and J. Gray, "Certificate Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
Management Protocol (CMP) Updates", Work in Progress, Management Protocol (CMP) Updates", Work in Progress,
Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17 Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12
December 2021, <https://datatracker.ietf.org/doc/html/ January 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-cmp-updates-15>. draft-ietf-lamps-cmp-updates-17>.
[I-D.ietf-lamps-lightweight-cmp-profile] [I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight Brockhaus, H., Oheimb, D. V., and S. Fries, "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-09, 17 December 2021, cmp-profile-10, 1 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
lightweight-cmp-profile-09>. lightweight-cmp-profile-10>.
[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 30, line 28 skipping to change at page 29, line 21
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 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: From version 08 -> 09:
* Updated IPR disclaimer * Updated IPR disclaimer
From version 07 -> 08: From version 07 -> 08:
* Fixing issues from WG and AD review * Fixing issues from WG and AD review
* Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of * 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 SHAKE and KMAC and added ToDo regarding checking respective notes
* Added two tables showing algorithms sorted by their strength to * Added two tables showing algorithms sorted by their strength to
 End of changes. 31 change blocks. 
110 lines changed or deleted 72 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/