draft-ietf-lamps-cmp-algorithms-04.txt   draft-ietf-lamps-cmp-algorithms-05.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: 6 November 2021 J. Gray Expires: 8 November 2021 J. Gray
Entrust Entrust
5 May 2021 7 May 2021
Certificate Management Protocol (CMP) Algorithms Certificate Management Protocol (CMP) Algorithms
draft-ietf-lamps-cmp-algorithms-04 draft-ietf-lamps-cmp-algorithms-05
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 6 November 2021. This Internet-Draft will expire on 8 November 2021.
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 12, line 46 skipping to change at page 12, line 46
5. Content Encryption Algorithms 5. Content Encryption Algorithms
The content encryption algorithm is also referred to as PROT_SYM_ALG The content encryption algorithm is also referred to as PROT_SYM_ALG
in Section 7, RFC 4210 Appendix D and E [RFC4210], and the in Section 7, RFC 4210 Appendix D and E [RFC4210], and the
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Lightweight 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 proofe-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
skipping to change at page 16, line 27 skipping to change at page 16, line 27
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 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.
To promote interoperability, based on the recommendations of NIST Recommendations like NIST SP 800-57 Recommendation for Key Management
SP 800-57 Recommendation for Key Management [NIST.SP.800-57pt1r5] and [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols
ECRYPT Algorithms, Key Size and Protocols Report (2018) Report (2018) [ECRYPT.CSA.D5.4] provide general information on
[ECRYPT.CSA.D5.4], the following guidelines should be followed. current cryptographic algorithms.
The strength of the overall certificate management system is The following criteria will help implementers choose appropriate
determined by two criteria: 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.
* 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.
skipping to change at page 18, line 35 skipping to change at page 18, line 35
|PROT_ENC_ALG|asymmetric | D-H |D-H | |PROT_ENC_ALG|asymmetric | D-H |D-H |
| |algorithm used | |Others: RSA, ECDH | | |algorithm used | |Others: RSA, ECDH |
| |for encryption | | | | |for encryption | | |
| |of (symmetric | | | | |of (symmetric | | |
| |keys for | | | | |keys for | | |
| |encryption of) | | | | |encryption of) | | |
| |private keys | | | | |private keys | | |
| |transported in | | | | |transported in | | |
| |PKIMessages | | | | |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 | | |encryption | |CBC Mode |
| |algorithm used | |Others: AES, RC5, | | |algorithm used | |Others: AES, RC5, |
| |for encryption | |CAST-128 | | |for encryption | |CAST-128 |
| |of private key | | | | |of private key | | |
| |bits (a key of | | | | |bits (a key of | | |
| |this type is | | | | |this type is | | |
| |encrypted using| | | | |encrypted using| | |
| |PROT_ENC_ALG) | | | | |PROT_ENC_ALG) | | |
+------------+---------------+------------------+-------------------+ +------------+---------------+------------------+-------------------+
skipping to change at page 19, line 17 skipping to change at page 19, line 17
PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key 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 derivation function, see Section 4.4.1 and id-hmacWithSHA256 as
message authentication scheme, see Section 6.2.1). It is RECOMMENDED message authentication scheme, see Section 6.2.1). It is RECOMMENDED
to prefer the usage of PBMAC1 instead of PasswordBasedMac. to prefer the usage of PBMAC1 instead of PasswordBasedMac.
D-H: id-alg-ESDH, see Section 4.1.1 D-H: id-alg-ESDH, see Section 4.1.1
AES-wrap: id-aes256-wrap, see Section 4.3.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 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 the Lightweight 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
skipping to change at page 20, line 35 skipping to change at page 20, line 35
| | PROT_SYM_ALG | | | | PROT_SYM_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| KM_KD_ALG | symmetric key derivation | PBKDF2 | | KM_KD_ALG | symmetric key derivation | PBKDF2 |
| | algorithm used for derivation | | | | algorithm used for derivation | |
| | of a symmetric key for use | | | | of a symmetric key for use | |
| | with KM_KW_ALG | | | | with KM_KW_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap |
| | key for PROT_SYM_ALG | | | | key for PROT_SYM_ALG | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
| PROT_SYM_ALG | symmetric content encryption | AES | | PROT_SYM_ALG | symmetric content encryption | AES-CBC |
| | algorithm used for encryption | | | | algorithm used for encryption | |
| | of EnvelopedData, e.g., a | | | | of EnvelopedData, e.g., a | |
| | private key transported in | | | | private key transported in | |
| | PKIMessages | | | | PKIMessages | |
+--------------+--------------------------------+------------------+ +--------------+--------------------------------+------------------+
Table 2 Table 2
8. IANA Considerations 8. IANA Considerations
skipping to change at page 21, line 26 skipping to change at page 21, line 26
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, 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-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 weaknesses 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.
As the pseudo random function is used several times in PBKDF2, AES- AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2;
GMAC MUST NOT be used here, because the security of AES-GMAC is the use of AES-GMAC more than once with the same key and the same
broken when using it twice with the same nonce. nonce will break the security.
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].
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.
skipping to change at page 26, line 49 skipping to change at page 26, line 49
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 04 -> 05:
* 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
* Minor changes in wording * Minor changes in wording
From version 02 -> 03: From version 02 -> 03:
 End of changes. 14 change blocks. 
19 lines changed or deleted 21 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/