--- 1/draft-ietf-lamps-cmp-algorithms-04.txt 2021-05-07 07:13:31.751282983 -0700 +++ 2/draft-ietf-lamps-cmp-algorithms-05.txt 2021-05-07 07:13:31.807284367 -0700 @@ -1,21 +1,21 @@ LAMPS Working Group H. Brockhaus, Ed. Internet-Draft H. Aschauer Updates: 4210 (if approved) Siemens Intended status: Standards Track M. Ounsworth -Expires: 6 November 2021 J. Gray +Expires: 8 November 2021 J. Gray Entrust - 5 May 2021 + 7 May 2021 Certificate Management Protocol (CMP) Algorithms - draft-ietf-lamps-cmp-algorithms-04 + draft-ietf-lamps-cmp-algorithms-05 Abstract This document describes the conventions for using concrete cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 6 November 2021. + This Internet-Draft will expire on 8 November 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -524,21 +524,21 @@ 5. Content Encryption Algorithms The content encryption algorithm is also referred to as PROT_SYM_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Content encryption algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData to transport a signed private key package in case of central key generation or key archiving, a certificate to - facilitate implicit proofe-of-possession, or a revocation passphrase + facilitate implicit proof-of-possession, or a revocation passphrase in encrypted form. Content encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. Encrypted content is located in the EnvelopedData EncryptedContentInfo encryptedContent field. 5.1. AES-CBC @@ -692,27 +692,27 @@ nistAlgorithm(4) 2 20 } Specific conventions to be considered for KMAC with SHAKE are specified in RFC 8702 Section 3.4 [RFC8702]. 7. Algorithm Use Profiles This section provides profiles of algorithms and respective conventions for different application use cases. - To promote interoperability, based on the recommendations of NIST - SP 800-57 Recommendation for Key Management [NIST.SP.800-57pt1r5] and - ECRYPT Algorithms, Key Size and Protocols Report (2018) - [ECRYPT.CSA.D5.4], the following guidelines should be followed. + Recommendations like NIST SP 800-57 Recommendation for Key Management + [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols + Report (2018) [ECRYPT.CSA.D5.4] provide general information on + current cryptographic algorithms. - The strength of the overall certificate management system is - determined by two criteria: + The following criteria will help implementers choose appropriate + algorithms for managing certificates: * The cryptographic strength of the algorithm with the lowest security. Note: To avoid consuming too much computational resources it is recommended to choose a set of algorithms offering roughly the same level of security. * The entropy of the shared secret information or password when MAC- based message protection is used, e.g., MSG_MAC_ALG. @@ -763,21 +763,21 @@ |PROT_ENC_ALG|asymmetric | D-H |D-H | | |algorithm used | |Others: RSA, ECDH | | |for encryption | | | | |of (symmetric | | | | |keys for | | | | |encryption of) | | | | |private keys | | | | |transported in | | | | |PKIMessages | | | +------------+---------------+------------------+-------------------+ - |PROT_SYM_ALG|symmetric | AES |3-DES(3-key-EDE), | + |PROT_SYM_ALG|symmetric | AES-CBC |3-DES(3-key-EDE), | | |encryption | |CBC Mode | | |algorithm used | |Others: AES, RC5, | | |for encryption | |CAST-128 | | |of private key | | | | |bits (a key of | | | | |this type is | | | | |encrypted using| | | | |PROT_ENC_ALG) | | | +------------+---------------+------------------+-------------------+ @@ -792,21 +792,21 @@ PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key derivation function, see Section 4.4.1 and id-hmacWithSHA256 as message authentication scheme, see Section 6.2.1). It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac. D-H: id-alg-ESDH, see Section 4.1.1 AES-wrap: id-aes256-wrap, see Section 4.3.1 - AES: id-aes256-CBC, see Section 5.1 + AES-CBC: id-aes256-CBC, see Section 5.1 7.2. Algorithm Profile for Lightweight CMP Profile The following table contains definitions of algorithms which MAY be supported by implementations of the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. As the set of algorithms to be used for implementations of the Lightweight CMP Profile heavily depends on the PKI management operations implemented, the certificates used for messages @@ -850,21 +850,21 @@ | | PROT_SYM_ALG | | +--------------+--------------------------------+------------------+ | KM_KD_ALG | symmetric key derivation | PBKDF2 | | | algorithm used for derivation | | | | of a symmetric key for use | | | | with KM_KW_ALG | | +--------------+--------------------------------+------------------+ | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | | | key for PROT_SYM_ALG | | +--------------+--------------------------------+------------------+ - | PROT_SYM_ALG | symmetric content encryption | AES | + | PROT_SYM_ALG | symmetric content encryption | AES-CBC | | | algorithm used for encryption | | | | of EnvelopedData, e.g., a | | | | private key transported in | | | | PKIMessages | | +--------------+--------------------------------+------------------+ Table 2 8. IANA Considerations @@ -884,27 +884,27 @@ offer implementers a more up to date choice. Finally, the algorithms to be supported also heavily depend on the certificates and PKI management operations utilized in the target environment. The algorithm with the lowest security strength and the entropy of shared secret information define the security of the overall solution, see Section 7. When using MAC-based message protection the use of PBMAC1 is preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known scrutinized algorithm, which is not true for PasswordBasedMac and - second, there exists a theoretical weaknesses in PasswordBasedMac, + second, there exists a theoretical weakness in PasswordBasedMac, where the generated MAC key can be easily distinguished from a random key. - As the pseudo random function is used several times in PBKDF2, AES- - GMAC MUST NOT be used here, because the security of AES-GMAC is - broken when using it twice with the same nonce. + 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 + nonce will break the security. In Section 7 of this document there is also an update to the Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY be supported when implementing the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. To keep the list of algorithms to be used with CMP up to date and to enlist secure algorithms resisting known attack scenarios, future algorithms should be added and weakened algorithms should be deprecated. @@ -1146,25 +1146,27 @@ Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, DOI 10.17487/RFC8692, December 2019, . Appendix A. History of changes Note: This appendix will be deleted in the final version of the document. + From version 04 -> 05: + + * Minor changes and corrections in wording From version 03 -> 04: * Added John Gray to the list of authors due to his extensive support and valuable feedback - * Added some clarification of the use AES-GMAC to Section 6.2.1 * Extended the guidance on how to select a set of algorithms in Section 7 and deleted former Section 7.1 * Deleted the algorithms mandatory to support in Section 7.2 as discussed at IETF 110 * Extended the Security considerations in Section 9 * Minor changes in wording From version 02 -> 03: