draft-ietf-lamps-cmp-algorithms-13.txt   draft-ietf-lamps-cmp-algorithms-14.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: 14 November 2022 J. Gray Expires: 26 November 2022 J. Gray
Entrust Entrust
13 May 2022 25 May 2022
Certificate Management Protocol (CMP) Algorithms Certificate Management Protocol (CMP) Algorithms
draft-ietf-lamps-cmp-algorithms-13 draft-ietf-lamps-cmp-algorithms-14
Abstract Abstract
This document describes the conventions for using several This document describes the conventions for using several
cryptographic algorithms with the Certificate Management Protocol cryptographic algorithms with the Certificate Management Protocol
(CMP). CMP is used to enroll and further manage the lifecycle of (CMP). CMP is used to enroll and further manage the lifecycle of
X.509 certificates. This document also updates the algorithm use X.509 certificates. This document also updates the algorithm use
profile from RFC 4210 Appendix D.2. profile from RFC 4210 Appendix D.2.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 14 November 2022. This Internet-Draft will expire on 26 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
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.
In the following sections ASN.1 values and types are used to indicate In the following sections ASN.1 values and types are used to indicate
where algorithm identifier and output values are provided. Theses where algorithm identifier and output values are provided. These
ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211], ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211],
CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652]. CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652].
2. Message Digest Algorithms 2. Message Digest Algorithms
This section provides references to object identifiers and This section provides references to object identifiers and
conventions to be employed by CMP implementations that support SHA2 conventions to be employed by CMP implementations that support SHA2
or SHAKE message digest algorithms. or SHAKE message digest algorithms.
Digest algorithm identifiers are located in: Digest algorithm identifiers are located in:
skipping to change at page 4, line 26 skipping to change at page 4, line 26
hashalgs(2) 3 } hashalgs(2) 3 }
Specific conventions to be considered are specified in RFC 5754 Specific conventions to be considered are specified in RFC 5754
Section 2 [RFC5754]. Section 2 [RFC5754].
2.2. SHAKE 2.2. SHAKE
The SHA-3 family of hash functions is defined in FIPS Pub 202 The SHA-3 family of hash functions is defined in FIPS Pub 202
[NIST.FIPS.202] and includes fixed output length variants SHA3-224, [NIST.FIPS.202] and 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 certificates [RFC8692] and CMS [RFC8702] as one-way for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way
hash function for use with RSASSA-PSS and ECDSA. hash 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 output length MUST be 256 bits for SHAKE128 and 512 bits for the output length MUST be 256 bits for SHAKE128 and 512 bits for
SHAKE256. SHAKE256.
skipping to change at page 16, line 31 skipping to change at page 16, line 31
Specific conventions to be considered for KMAC with SHAKE are Specific conventions to be considered for KMAC with SHAKE are
specified in RFC 8702 Section 3.4 [RFC8702]. specified in RFC 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 like NIST SP 800-57 Recommendation for Key Management
Table2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Table 2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and
Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general
information on current cryptographic algorithms. information on current cryptographic algorithms.
The overall cryptographic strength of a CMP deployment will depend on The overall cryptographic strength of a CMP deployment will depend on
several factors, including: several factors, including:
* Capabilities of the end entity: What kind of algorithms does the * Capabilities of the end entity: What kind of algorithms does the
end entity support. The cryptographic strength of the system end entity support. The cryptographic strength of the system
SHOULD be at least as strong as the algorithms and keys used for SHOULD be at least as strong as the algorithms and keys used for
the certificate being managed. the certificate being managed.
skipping to change at page 19, line 17 skipping to change at page 19, line 17
| | |SHA512 or |SHA512), | | | | |SHA512 or |SHA512), | |
| | |SHAKE256 |PBKDF2 (HMAC- | | | | |SHAKE256 |PBKDF2 (HMAC- | |
| | |(d=512)), |SHA512) | | | | |(d=512)), |SHA512) | |
| | |PBMAC1 (HMAC- | | | | | |PBMAC1 (HMAC- | | |
| | |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
To avoid consuming too much computational resources it is recommended To avoid consuming too many 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
[RFC4210]. [RFC4210].
skipping to change at page 19, line 41 skipping to change at page 19, line 41
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
Optional: Algorithms which are OPTIONAL to support Optional: Algorithms which are OPTIONAL to support
Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be
used anymore used any more
+============+==============+======+===================+============+ +============+==============+======+===================+============+
|Name |Use |Manda-| Optional |Deprecated | |Name |Use |Manda-| Optional |Deprecated |
| | |tory | | | | | |tory | | |
+============+==============+======+===================+============+ +============+==============+======+===================+============+
|MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, | |MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, |
| |PKI messages | | |combinations| | |PKI messages | | |combinations|
| |using | | |with MD5 and| | |using | | |with MD5 and|
| |signature | | |SHA-1 | | |signature | | |SHA-1 |
+------------+--------------+------+-------------------+------------+ +------------+--------------+------+-------------------+------------+
|MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 | |MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 |
skipping to change at page 23, line 8 skipping to change at page 23, line 8
Table 4: Algorithms Used Within Lightweight CMP Profile Table 4: Algorithms Used Within Lightweight CMP Profile
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. These
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 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.
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
skipping to change at page 24, line 34 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-18, 6 April Internet-Draft, draft-ietf-lamps-cmp-updates-19, 25 May
2022, <https://datatracker.ietf.org/doc/html/draft-ietf- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cmp-updates-18>. lamps-cmp-updates-19>.
[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-11, 15 April 2022, cmp-profile-12, 13 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
lightweight-cmp-profile-11>. lightweight-cmp-profile-12>.
[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 29, line 21 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 13 -> 14:
* Providing changes addressing comments from GEN AD review
From version 12 -> 13: From version 12 -> 13:
* Providing changes addressing comments from OPSDIR and GENART last * Providing changes addressing comments from OPSDIR and GENART last
call reviews call reviews
From version 11 -> 12: From version 11 -> 12:
* Capitalized all headlines * Capitalized all headlines
From version 10 -> 11: From version 10 -> 11:
skipping to change at page 30, line 4 skipping to change at page 30, line 8
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
Section 7 and added ToDo regarding checking theses tables Section 7 and added ToDo regarding checking these tables
* Updates the algorithm use profile in Section 7.1 * Updates the algorithm use profile in Section 7.1
* Updated and added security consideration on SHAKE, * Updated and added security consideration on SHAKE,
PasswordBasedMac, KMAC, and symmetric key-based MAC functions and PasswordBasedMac, KMAC, and symmetric key-based MAC functions and
added ToDo regarding checking the security consideration on SHAKE added ToDo regarding checking the security consideration on SHAKE
From version 06 -> 07: From version 06 -> 07:
* Fixing minor formatting nits * Fixing minor formatting nits
From version 05 -> 06: From version 05 -> 06:
 End of changes. 18 change blocks. 
17 lines changed or deleted 20 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/