[要約] RFC 9481 は、CMP で複数の暗号アルゴリズムを使用するための規則を説明しており、X.509 証明書のライフサイクルを管理する目的で使用されます。また、RFC 4210 の付録 D.2 のアルゴリズム使用プロファイルを更新します。

Internet Engineering Task Force (IETF)                      H. Brockhaus
Request for Comments: 9481                                   H. Aschauer
Updates: 4210                                                    Siemens
Category: Standards Track                                   M. Ounsworth
ISSN: 2070-1721                                                  J. Gray
                                                                 Entrust
                                                           November 2023
        
Certificate Management Protocol (CMP) Algorithms
証明書管理プロトコル(CMP)アルゴリズム
Abstract
概要

This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. This document also updates the algorithm use profile from Appendix D.2 of RFC 4210.

このドキュメントでは、証明書管理プロトコル(CMP)でいくつかの暗号化アルゴリズムを使用するための規則について説明します。CMPは、X.509証明書のライフサイクルの登録とさらに管理に使用されます。このドキュメントは、RFC 4210の付録D.2からのアルゴリズムの使用プロファイルも更新します。

Status of This Memo
本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(IESG)からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9481.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9481で取得できます。

著作権表示

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。

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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
     1.1.  Terminology
   2.  Message Digest Algorithms
     2.1.  SHA2
     2.2.  SHAKE
   3.  Signature Algorithms
     3.1.  RSA
     3.2.  ECDSA
     3.3.  EdDSA
   4.  Key Management Algorithms
     4.1.  Key Agreement Algorithms
       4.1.1.  Diffie-Hellman
       4.1.2.  ECDH
     4.2.  Key Transport Algorithms
       4.2.1.  RSA
     4.3.  Symmetric Key-Encryption Algorithms
       4.3.1.  AES Key Wrap
     4.4.  Key Derivation Algorithms
       4.4.1.  PBKDF2
   5.  Content-Encryption Algorithms
     5.1.  AES-CBC
   6.  Message Authentication Code Algorithms
     6.1.  Password-Based MAC
       6.1.1.  PasswordBasedMac
       6.1.2.  PBMAC1
     6.2.  Symmetric Key-Based MAC
       6.2.1.  SHA2-Based HMAC
       6.2.2.  AES-GMAC
       6.2.3.  SHAKE-Based KMAC
   7.  Algorithm Use Profiles
     7.1.  Algorithm Profile for PKI Management Message Profiles in
           RFC 4210
     7.2.  Algorithm Profile for Lightweight CMP Profile
   8.  IANA Considerations
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Authors' Addresses
        
1. Introduction
1. はじめに

Appendix D.2 of [RFC4210] contains a set of algorithms that is mandatory to be supported by implementations conforming to [RFC4210]. These algorithms were appropriate at the time CMP was released, but as cryptographic algorithms weaken over time, some of them should no longer be used. In general, new attacks are emerging due to research in cryptanalysis or an increase in computing power. New algorithms were introduced that are more resistant to today's attacks.

[RFC4210]の付録D.2には、[RFC4210]に準拠した実装によってサポートされることが必須のアルゴリズムのセットが含まれています。これらのアルゴリズムは、CMPがリリースされた時点で適切でしたが、暗号化アルゴリズムが時間の経過とともに弱体化するにつれて、それらのいくつかはもはや使用しないでください。一般に、暗号化の研究またはコンピューティング能力の増加により、新しい攻撃が出現しています。今日の攻撃により耐性がある新しいアルゴリズムが導入されました。

This document lists current cryptographic algorithms that can be used with CMP to offer an easier way to maintain the list of suitable algorithms over time.

このドキュメントには、CMPで使用できる現在の暗号化アルゴリズムがリストされており、適切なアルゴリズムのリストを長期にわたって維持するための簡単な方法を提供します。

1.1. Terminology
1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

In the following sections, ASN.1 values and types are used to indicate where algorithm identifier and output values are provided. These ASN.1 values and types are defined in CMP [RFC4210], Certificate Request Message Format (CRMF) [RFC4211], CMP Updates [RFC9480], and Cryptographic Message Syntax (CMS) [RFC5652].

次のセクションでは、ASN.1の値とタイプを使用して、アルゴリズムの識別子と出力値が提供される場所を示します。これらのASN.1の値とタイプは、CMP [RFC4210]、証明書要求メッセージ形式(CRMF)[RFC4211]、CMP更新[RFC9480]、および暗号化メッセージの構文(CMS)[RFC5652]で定義されています。

2. Message Digest Algorithms
2. メッセージダイジェストアルゴリズム

This section provides references to object identifiers and conventions to be employed by CMP implementations that support SHA2 or SHAKE message digest algorithms.

このセクションでは、SHA2またはSake Message DigestアルゴリズムをサポートするCMP実装で採用されるオブジェクト識別子と規則への参照を提供します。

Digest algorithm identifiers are located in the:

ダイジェストアルゴリズム識別子は次のようになります。

* hashAlg field of OOBCertHash and CertStatus,

* Oobcerthashとcertstatusのハッシュフィールド、

* owf field of Challenge, PBMParameter, and DHBMParameter,

* owfチャレンジフィールド、pbmparameter、dhbmparameter、

* digestAlgorithms field of SignedData, and

* signeddataの消化器gorthmsフィールド、および

* digestAlgorithm field of SignerInfo.

* Signerinfoの消化器gorithフィールド。

Digest values are located in the:

ダイジェスト値は以下にあります

* hashVal field of OOBCertHash,

* obcerthashのハッシュバルフィールド、

* certHash field of CertStatus, and

* certhash field of certstatus、および

* witness field of Challenge.

* 挑戦の証人フィールド。

In addition, digest values are input to signature algorithms.

さらに、ダイジェスト値は署名アルゴリズムに入力されます。

2.1. SHA2
2.1. SHA2

The SHA2 algorithm family is defined in FIPS Pub 180-4 [NIST.FIPS.180-4].

SHA2アルゴリズムファミリーは、FIPS Pub 180-4 [nist.fips.180-4]で定義されています。

The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 are identified by the following OIDs:

メッセージダイジェストアルゴリズムSHA-224、SHA-256、SHA-384、およびSHA-512は、次のOIDによって識別されます。

      id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
         us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
         hashalgs(2) 4 }
      id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
         us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
         hashalgs(2) 1 }
      id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
         us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
         hashalgs(2) 2 }
      id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
         us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
         hashalgs(2) 3 }
        

Specific conventions to be considered are specified in Section 2 of [RFC5754].

考慮すべき特定の規則は、[RFC5754]のセクション2で指定されています。

2.2. SHAKE
2.2. 振る

The SHA-3 family of hash functions is defined in FIPS Pub 202 [NIST.FIPS.202] and consists of the fixed output length variants SHA3-224, SHA3-256, SHA3-384, and SHA3-512, as well as the extendable-output functions (XOFs) SHAKE128 and SHAKE256. Currently, SHAKE128 and SHAKE256 are the only members of the SHA3-family that are specified for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way hash functions for use with RSASSA-PSS and ECDSA.

ハッシュ関数のSHA-3ファミリーは、FIPS Pub 202 [nist.fips.202]で定義されており、固定出力長バリアントSHA3-224、SHA3-256、SHA3-384、およびSHA3-512で構成されています。拡張可能な出力関数(XOFS)Shake128およびShake256。現在、Shake128およびShake256は、X.509証明書[RFC8692]およびCMS [RFC8702]で使用するために指定されているSHA3ファミリーの唯一のメンバーです。

SHAKE is an extendable-output function, and FIPS Pub 202 [NIST.FIPS.202] prohibits using SHAKE as a general-purpose hash 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 SHAKE256.

Shakeは拡張可能な出力関数であり、Fips Pub 202 [nist.fips.202]は、汎用ハッシュ関数としてShakeを使用することを禁止しています。CMPでMessage DigestアルゴリズムとしてCMPで使用される場合、出力の長さはShake128で256ビット、Shake256で512ビットでなければなりません。

The message digest algorithms SHAKE128 and SHAKE256 are identified by the following OIDs:

メッセージダイジェストアルゴリズムShake128およびShake256は、次のOIDによって識別されます。

      id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
         us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
         hashalgs(2) 11 }
      id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
         us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
         hashalgs(2) 12 }
        

Specific conventions to be considered are specified in Section 3.1 of [RFC8702].

考慮すべき特定の規則は、[RFC8702]のセクション3.1で指定されています。

3. Signature Algorithms
3. 署名アルゴリズム

This section provides references to object identifiers and conventions to be employed by CMP implementations that support signature algorithms like RSA, ECDSA, or EdDSA.

このセクションでは、RSA、ECDSA、EDDSAなどの署名アルゴリズムをサポートするCMP実装で採用されるオブジェクト識別子と規則への参照を提供します。

The signature algorithm is referred to as MSG_SIG_ALG in Appendices D and E of [RFC4210], in the Lightweight CMP Profile [RFC9483], and in Section 7.2.

署名アルゴリズムは、[RFC4210]の付録DおよびE、軽量CMPプロファイル[RFC9483]、およびセクション7.2のMSG_SIG_ALGと呼ばれます。

Signature algorithm identifiers are located in the:

署名アルゴリズム識別子は、

* protectionAlg field of PKIHeader,

* pkiheaderの保護分野、

* algorithmIdentifier field of POPOSigningKey, and

* AlgorithMidentifier PoposimingKeyのフィールド、および

* signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, and SignerInfo

* SignatureAlgorithm certificationRequest、signkeypairtypes、およびsignerinfoのフィールド

Signature values are located in the:

署名値は以下にあります

* protection field of PKIMessage,

* pkimessageの保護場、

* signature field of POPOSigningKey, and

* PoposimingKeyの署名フィールド、および

* signature field of CertificationRequest and SignerInfo.

* 認定RequestおよびSignerinfoの署名フィールド。

3.1. RSA
3.1. RSA

The RSA (RSASSA-PSS and PKCS #1 version 1.5) signature algorithm is defined in [RFC8017].

RSA(RSASSA-PSSおよびPKCS#1バージョン1.5)の署名アルゴリズムは[RFC8017]で定義されています。

The algorithm identifier for RSASAA-PSS signatures used with SHA2 message digest algorithms is identified by the following OID:

SHA2メッセージダイジェストアルゴリズムで使用されるRSASAA-PSS署名のアルゴリズム識別子は、次のOIDによって識別されます。

      id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
        

Specific conventions to be considered are specified in [RFC4056].

考慮すべき特定の規則は、[RFC4056]で指定されています。

The signature algorithm RSASSA-PSS used with SHAKE message digest algorithms is identified by the following OIDs:

Sake Message Digestアルゴリズムで使用される署名アルゴリズムrsassa-PSSは、次のOIDによって識別されます。

      id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1)
         identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) algorithms(6) 30 }
      id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1)
         identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) algorithms(6) 31 }
        

Specific conventions to be considered are specified in Section 3.2.1 of [RFC8702].

考慮すべき特定の規則は、[RFC8702]のセクション3.2.1で指定されています。

The signature algorithm PKCS #1 version 1.5 used with SHA2 message digest algorithms is identified by the following OIDs:

SHA2メッセージダイジェストアルゴリズムで使用される署名アルゴリズムPKCS#1バージョン1.5は、次のOIDによって識別されます。

      sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 }
      sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { iso(1)
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 }
      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { iso(1)
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }
      sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { iso(1)
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 }
        

Specific conventions to be considered are specified in Section 3.2 of [RFC5754].

考慮すべき特定の規則は、[RFC5754]のセクション3.2で指定されています。

3.2. ECDSA
3.2. ecdsa

The ECDSA signature algorithm is defined in FIPS Pub 186-5 [NIST.FIPS.186-5].

ECDSA署名アルゴリズムは、FIPS Pub 186-5 [nist.fips.186-5]で定義されています。

The signature algorithm ECDSA used with SHA2 message digest algorithms is identified by the following OIDs:

SHA2メッセージダイジェストアルゴリズムで使用される署名アルゴリズムECDSAは、次のOIDによって識別されます。

      ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 }
      ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
      ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
      ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
        

As specified in [RFC5480], the NIST-recommended curves are identified by the following OIDs:

[RFC5480]で指定されているように、NISTが推奨する曲線は、次のOIDによって識別されます。

      secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) curves(3) prime(1) 1 }
      secp224r1 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) curve(0) 33 }
      secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }
      secp384r1 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) curve(0) 34 }
      secp521r1 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) curve(0) 35 }
        

Specific conventions to be considered are specified in Section 3.3 of [RFC5754].

考慮すべき特定の規則は、[RFC5754]のセクション3.3で指定されています。

The signature algorithm ECDSA used with SHAKE message digest algorithms is identified by the following OIDs:

Sake Message Digestアルゴリズムで使用される署名アルゴリズムECDSAは、次のOIDによって識別されます。

      id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1)
         identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) algorithms(6) 32 }
      id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1)
         identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) algorithms(6) 33 }
        

Specific conventions to be considered are specified in Section 3.2.2 of [RFC8702].

考慮すべき特定の規則は、[RFC8702]のセクション3.2.2で指定されています。

3.3. EdDSA
3.3. eddsa

The EdDSA signature algorithm is defined in Section 3.3 of [RFC8032] and FIPS Pub 186-5 [NIST.FIPS.186-5].

EDDSA署名アルゴリズムは、[RFC8032]のセクション3.3で定義されており、FIPS PUB 186-5 [nist.fips.186-5]。

The signature algorithm Ed25519 that MUST be used with SHA-512 message digest algorithms is identified by the following OIDs:

SHA-512メッセージダイジェストアルゴリズムで使用する必要がある署名アルゴリズムED25519は、次のOIDによって識別されます。

      id-Ed25519 OBJECT IDENTIFIER  ::=  { iso(1)
         identified-organization(3) thawte(101) 112 }
        

The signature algorithm Ed448 that MUST be used with SHAKE256 message digest algorithms is identified by the following OIDs:

Shake256メッセージダイジェストアルゴリズムで使用する必要がある署名アルゴリズムED448は、次のOIDによって識別されます。

      id-Ed448 OBJECT IDENTIFIER  ::=  { iso(1)
         identified-organization(3) thawte(101) 113 }
        

Specific conventions to be considered are specified in [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 or SHAKE256 with d=512 if the certificate to be confirmed has been signed using Ed448.

注:CERTCONFメッセージのCerthashを計算するために使用されるハッシュアルゴリズムは、証明書がED25519を使用して署名されている場合はSHA512でなければなりません。

4. Key Management Algorithms
4. キー管理アルゴリズム

CMP utilizes the following general key management techniques: key agreement, key transport, and passwords.

CMPは、次の一般的な主要な管理手法を利用しています:主要な合意、キートランスポート、パスワード。

CRMF [RFC4211] and CMP Updates [RFC9480] promote the use of CMS EnvelopedData [RFC5652] by deprecating the use of EncryptedValue.

CRMF [RFC4211]およびCMPの更新[RFC9480]は、暗号化されたバリューの使用を非難することにより、CMS EnvelopedData [RFC5652]の使用を促進します。

4.1. Key Agreement Algorithms
4.1. キー契約アルゴリズム

The key agreement algorithm is referred to as PROT_ENC_ALG in Appendices D and E of [RFC4210] and as KM_KA_ALG in the Lightweight CMP Profile [RFC9483] and Section 7.

主要な合意アルゴリズムは、[RFC4210]の付録DおよびEのprot_enc_algと呼ばれ、軽量CMPプロファイル[RFC9483]およびセクション7のKM_KA_ALGと呼ばれます。

Key agreement algorithms are only used in CMP when using CMS EnvelopedData [RFC5652] together with the key agreement key management technique. When a key agreement algorithm is used, a key-encryption algorithm (Section 4.3) is needed next to the content-encryption algorithm (Section 5).

主要な契約アルゴリズムは、CMS EnvelopedData [RFC5652]を使用する場合にのみCMPで使用されます。キー契約アルゴリズムを使用する場合、コンテンツ暗号化アルゴリズム(セクション5)の横にキー暗号化アルゴリズム(セクション4.3)が必要です。

Key agreement algorithm identifiers are located in the:

キー契約アルゴリズム識別子は、

* keyEncryptionAlgorithm field of KeyAgreeRecipientInfo.

* keyagreerecipientinfoのkeyencryptionalgorithmフィールド。

Key wrap algorithm identifiers are located in the:

キーラップアルゴリズム識別子は次のようになります。

* KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of KeyAgreeRecipientInfo.

* keywrapalgorithm keyagreerecipientinfoのkeyencryptionalgorithmフィールド内のパラメーター。

Wrapped content-encryption keys are located in the:

ラップされたコンテンツ暗号化キーは、

* encryptedKey field of RecipientEncryptedKeys.

* RecipientEncryptedKeysの暗号化されたキーフィールド。

4.1.1. Diffie-Hellman
4.1.1. diffie-hellman

The Diffie-Hellman (DH) key agreement is defined in [RFC2631] and SHALL be used in the ephemeral-static variants, as specified in [RFC3370]. Static-static variants SHALL NOT be used.

diffie-hellman(DH)キー契約は[RFC2631]で定義されており、[RFC3370]で指定されているように、はかない静的バリアントで使用されます。静的なバリアントは使用してはなりません。

The DH key agreement algorithm is identified by the following OID:

DHキー契約アルゴリズムは、次のOIDによって識別されます。

      id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
        

Specific conventions to be considered are specified in Section 4.1 of [RFC3370].

考慮すべき特定の規則は、[RFC3370]のセクション4.1で指定されています。

4.1.2. ECDH
4.1.2. ECDH

The Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in [RFC5753] and SHALL be used in the ephemeral-static variant, as specified in [RFC5753], or the 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) variant, as specified in [RFC5753]. Static-static variants SHALL NOT be used.

楕円曲線diffie-hellman(ECDH)の主要な合意は[RFC5753]で定義されており、[RFC5753]、または1パス楕円曲線メネゼス-QUバンストーン(ECMQV)で指定されている短命静脈変異体で使用されます。[RFC5753]で指定されているバリアント。静的なバリアントは使用してはなりません。

The ECDH key agreement algorithm used together with NIST-recommended SECP curves are identified by the following OIDs:

NIST推奨のSECP曲線とともに使用されるECDHキー契約アルゴリズムは、次のOIDによって識別されます。

      dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 11(11) 0 }
      dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 11(11) 1 }
      dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 11(11) 2 }
      dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 11(11) 3 }
      dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) certicom(132) schemes(1)
         14(14) 0 }
      dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) certicom(132) schemes(1)
         14(14) 1 }
      dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) certicom(132) schemes(1)
         14(14) 2 }
      dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) certicom(132) schemes(1)
         14(14) 3 }
      mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 15(15) 0 }
      mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 15(15) 1 }
      mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 15(15) 2 }
      mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) schemes(1) 15(15) 3 }
        

As specified in [RFC5480], the NIST-recommended SECP curves are identified by the following OIDs:

[RFC5480]で指定されているように、NIST推奨のSECP曲線は、次のOIDによって識別されます。

      secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) curves(3) prime(1) 1 }
      secp224r1 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) curve(0) 33 }
      secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) ansi-X9-62(10045) curves(3) prime(1) 7 }
      secp384r1 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) curve(0) 34 }
      secp521r1 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) certicom(132) curve(0) 35 }
        

Specific conventions to be considered are specified in [RFC5753].

考慮すべき特定の規則は、[RFC5753]で指定されています。

The ECDH key agreement algorithm used together with curve25519 or curve448 is identified by the following OIDs:

Curve25519またはCurve448とともに使用されるECDHキー契約アルゴリズムは、次のOIDによって識別されます。

      id-X25519 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) thawte(101) 110 }
      id-X448 OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) thawte(101) 111 }
        

Specific conventions to be considered are specified in [RFC8418].

考慮すべき特定の規則は、[RFC8418]で指定されています。

4.2. Key Transport Algorithms
4.2. キートランスポートアルゴリズム

The key transport algorithm is also referred to as PROT_ENC_ALG in Appendices D and E of [RFC4210] and as KM_KT_ALG in the Lightweight CMP Profile [RFC9483] and Section 7.

キートランスポートアルゴリズムは、[RFC4210]の付録DおよびEのprot_enc_algとも呼ばれ、軽量CMPプロファイル[RFC9483]およびセクション7のKM_KT_ALGと呼ばれます。

Key transport algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData together with the key transport key management technique.

キートランスポートアルゴリズムは、CMS [RFC5652] EnvelopedDataを使用してキートランスポートキー管理手法を使用する場合にのみCMPで使用されます。

Key transport algorithm identifiers are located in the:

主要な輸送アルゴリズム識別子は、

* keyEncryptionAlgorithm field of KeyTransRecipientInfo.

* keyencranscipientinfoのkeyencryptionalgorithmフィールド。

Key transport encrypted content-encryption keys are located in the:

主要な輸送暗号化されたコンテンツ - 暗号化キーは、

* encryptedKey field of KeyTransRecipientInfo.

* KeyTransrecipientInfoの暗号化されたキーフィールド。

4.2.1. RSA
4.2.1. RSA

The RSA key transport algorithm is the RSA encryption scheme defined in [RFC8017].

RSAキートランスポートアルゴリズムは、[RFC8017]で定義されているRSA暗号化スキームです。

The algorithm identifier for RSA (PKCS #1 v1.5) is:

RSAのアルゴリズム識別子(PKCS#1 V1.5)は次のとおりです。

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
        

The algorithm identifier for RSAES-OAEP is:

RSAES-OAEPのアルゴリズム識別子は次のとおりです。

      id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 }
        

Further conventions to be considered for PKCS #1 v1.5 are specified in Section 4.2.1 of [RFC3370] and for RSAES-OAEP in [RFC3560].

PKCS#1 V1.5のさらなる規則は、[RFC3370]のセクション4.2.1および[RFC3560]のRSAES-OAEPで指定されています。

4.3. Symmetric Key-Encryption Algorithms
4.3. 対称キー暗号化アルゴリズム

The symmetric key-encryption algorithm is also referred to as KM_KW_ALG in Section 7.2 and the Lightweight CMP Profile [RFC9483].

対称キー暗号化アルゴリズムは、セクション7.2および軽量CMPプロファイル[RFC9483]のKM_KW_ALGとも呼ばれます。

As the symmetric key-encryption key management technique is not used by CMP, the symmetric key-encryption algorithm is only needed when using the key agreement or password-based key management technique with CMS [RFC5652] EnvelopedData.

対称キー暗号化キー管理手法はCMPでは使用されていないため、CMS [RFC5652] EnvelopedDataでキー契約またはパスワードベースのキー管理手法を使用する場合にのみ対称的なキー暗号化アルゴリズムが必要です。

Key wrap algorithm identifiers are located in the:

キーラップアルゴリズム識別子は次のようになります。

* parameters field of the KeyEncryptionAlgorithmIdentifier of KeyAgreeRecipientInfo and PasswordRecipientInfo.

* KeyAgreereCipientInfoおよびPasswordRecipientInfoのKeyEncryptionAlgorithMidentifierのパラメーターフィールド。

Wrapped content-encryption keys are located in the:

ラップされたコンテンツ暗号化キーは、

* encryptedKey field of RecipientEncryptedKeys (for key agreement) and PasswordRecipientInfo (for password-based key management).

* RecipientEncryptedKeys(キー契約のため)およびPasswordRecipientInfo(パスワードベースのキー管理用)の暗号化されたフィールド。

4.3.1. AES Key Wrap
4.3.1. AESキーラップ

The AES encryption algorithm is defined in FIPS Pub 197 [NIST.FIPS.197], and the key wrapping is defined in [RFC3394].

AES暗号化アルゴリズムは、FIPS Pub 197 [nist.fips.197]で定義されており、キーラッピングは[RFC3394]で定義されています。

AES key encryption has the algorithm identifier:

AESキー暗号化には、アルゴリズム識別子があります。

      id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 5 }
      id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 25 }
      id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 45 }
        

The underlying encryption functions for the key wrap and content-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 algorithm with AES-128 content-encryption algorithm); see [RFC8551].

キーラップおよびコンテンツ暗号化アルゴリズムの基礎となる暗号化(セクション5で指定)と2つのアルゴリズムのキーサイズは同じでなければなりません(たとえば、AES-128コンテンツ - 暗号化アルゴリズムを備えたキーラップアルゴリズムなど);[RFC8551]を参照してください。

Further conventions to be considered for AES key wrap are specified in Section 2.2 of [RFC3394] and Section 2.3.2 of [RFC3565].

AESキーラップのさらなる規則は、[RFC3394]のセクション2.2および[RFC3565]のセクション2.3.2で指定されています。

4.4. Key Derivation Algorithms
4.4. キー派生アルゴリズム

The key derivation algorithm is also referred to as KM_KD_ALG in Section 7.2 and the Lightweight CMP Profile [RFC9483].

キー派生アルゴリズムは、セクション7.2および軽量CMPプロファイル[RFC9483]のKM_KD_ALGとも呼ばれます。

Key derivation algorithms are only used in CMP when using CMS EnvelopedData [RFC5652] together with the password-based key management technique.

キー派生アルゴリズムは、パスワードベースのキー管理手法とともに、CMS EnvelopedData [RFC5652]を使用する場合にのみCMPで使用されます。

Key derivation algorithm identifiers are located in the:

キー派生アルゴリズム識別子は、

* keyDerivationAlgorithm field of PasswordRecipientInfo.

* KeyDederivationalGorithm PasswordRecipientInfoのフィールド。

When using the password-based key management technique with EnvelopedData as specified in CMP Updates [RFC9480] together with PKIProtection based on the message authentication code (MAC), the salt for the password-based MAC and key derivation function (KDF) must be chosen independently to ensure usage of independent symmetric keys.

CMP更新[RFC9480]で指定されているエンベロッドダタを使用してパスワードベースのキー管理手法を使用する場合、メッセージ認証コード(MAC)に基づくPKIPROTECTIONとともに、パスワードベースのMACおよびキー導出関数(KDF)の塩を選択する必要があります。独立して、独立した対称キーの使用を確保する。

4.4.1. PBKDF2
4.4.1. PBKDF2

Password-based key derivation function 2 (PBKDF2) is defined in [RFC8018].

パスワードベースのキー導入関数2(PBKDF2)は[RFC8018]で定義されています。

PBKDF2 has the algorithm identifier:

PBKDF2にはアルゴリズム識別子があります。

      id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
         rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
        

Further conventions to be considered for PBKDF2 are specified in Section 4.4.1 of [RFC3370] and Section 5.2 of [RFC8018].

PBKDF2のさらなる規則は、[RFC3370]のセクション4.4.1および[RFC8018]のセクション5.2で指定されています。

5. Content-Encryption Algorithms
5. Content-dencryptionアルゴリズム

The content-encryption algorithm is also referred to as PROT_SYM_ALG in Appendices D and E of [RFC4210], in the Lightweight CMP Profile [RFC9483], and in Section 7.

コンテンツ結晶アルゴリズムは、[RFC4210]の付録DおよびE、軽量CMPプロファイル[RFC9483]、およびセクション7でもprot_sym_algと呼ばれます。

Content-encryption algorithms are used in CMP when using CMS EnvelopedData [RFC5652] to transport a signed private key package in case of central key generation or key archiving, a certificate to facilitate implicit proof-of-possession, or a revocation passphrase in encrypted form.

CMS EnvelopedData [RFC5652]を使用してCMPでCMPで使用され、中央のキー生成またはキーアーカイブの場合に署名された秘密鍵パッケージを輸送する場合、暗黙のプルーフの証明の証明を促進する証明書、または暗号化された形式での取り消しパスフレーズを容易にします。。

Content-encryption algorithm identifiers are located in the:

Content-rincryptionアルゴリズム識別子は次のようになります。

* contentEncryptionAlgorithm field of EncryptedContentInfo.

* contentencryptionalgorithm encryptedcontentinfoのフィールド。

Encrypted content is located in the:

暗号化されたコンテンツは、

* encryptedContent field of EncryptedContentInfo.

* 暗号化されたコンテンツコンテンツフィールドの暗号化されたContentInfo。

5.1. AES-CBC
5.1. AES-CBC

The AES encryption algorithm is defined in FIPS Pub 197 [NIST.FIPS.197].

AES暗号化アルゴリズムは、FIPS Pub 197 [nist.fips.197]で定義されています。

AES Cipher Block Chaining (AES-CBC) content encryption has the algorithm identifier:

AES暗号ブロックチェーン(AES-CBC)コンテンツ暗号化には、アルゴリズム識別子があります。

      id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 2 }
      id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1)22 }
      id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1)42 }
        

Specific conventions to be considered for AES-CBC content encryption are specified in [RFC3565].

AES-CBCコンテンツ暗号化のために考慮される特定の規則は、[RFC3565]で指定されています。

6. Message Authentication Code Algorithms
6. メッセージ認証コードアルゴリズム

The message authentication code (MAC) is either used for shared secret-based CMP message protection or together with the password-based key derivation function (PBKDF2).

メッセージ認証コード(MAC)は、共有されたシークレットベースのCMPメッセージ保護に使用されるか、パスワードベースのキー派生関数(PBKDF2)とともに使用されます。

The MAC algorithm is also referred to as MSG_MAC_ALG in Section 7, Appendices D and E of [RFC4210], and the Lightweight CMP Profile [RFC9483].

Macアルゴリズムは、セクション7のMSG_MAC_ALG、[RFC4210]の付録DおよびE、および軽量CMPプロファイル[RFC9483]とも呼ばれます。

6.1. Password-Based MAC
6.1. パスワードベースのMac

Password-based message authentication code (MAC) algorithms combine the derivation of a symmetric key from a password or other shared secret information and a symmetric key-based MAC function, as specified in Section 6.2, using this derived key.

パスワードベースのメッセージ認証コード(MAC)アルゴリズムは、この派生キーを使用して、セクション6.2で指定されているように、パスワードまたはその他の共有秘密情報と対称キーベースのMAC関数からの対称キーの導出を組み合わせています。

MAC algorithm identifiers are located in the:

MACアルゴリズム識別子は次のようになります。

* protectionAlg field of PKIHeader.

* Pkiheaderの保護分野。

Message authentication code values are located in the:

メッセージ認証コード値は、

* PKIProtection field of PKIMessage.

* pkimessageのpkiprotectionフィールド。

6.1.1. PasswordBasedMac
6.1.1. PasswordBasedMac

The PasswordBasedMac algorithm is defined in Section 5.1.3.1 of [RFC4210], Section 4.4 of [RFC4211], and "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)" [RFC9045].

パスワードベースのMacアルゴリズムは、[RFC4210]のセクション5.1.3.1、[RFC4211]のセクション4.4、および「インターネットX.509公開キーインフラストラクチャー証明書リクエストメッセージフォーマット(CRMF)(CRMF)の更新」[RFC9045]で定義されています。

The PasswordBasedMac algorithm is identified by the following OID:

Password BasedMacアルゴリズムは、次のOIDによって識別されます。

      id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) nt(113533) nsn(7) algorithms(66) 13 }
        

Further conventions to be considered for PasswordBasedMac are specified in Section 5.1.3.1 of [RFC4210], Section 4.4 of [RFC4211], and "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)" [RFC9045].

パスワードベースMACのさらなる規則は、[RFC4210]のセクション5.1.3.1、[RFC4211]のセクション4.4、および「インターネットX.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット(CRMF)(CRMF)へのアルゴリズム要件の更新」で指定されています。]。

6.1.2. PBMAC1
6.1.2. PBMAC1

Password-Based Message Authentication Code 1 (PBMAC1) is defined in [RFC8018]. PBMAC1 combines a password-based key derivation function, like PBKDF2 (Section 4.4.1), with an underlying symmetric key-based message authentication scheme.

パスワードベースのメッセージ認証コード(PBMAC1)は[RFC8018]で定義されています。PBMAC1は、PBKDF2(セクション4.4.1)のようなパスワードベースのキー派生関数を、基礎となる対称キーベースのメッセージ認証スキームと組み合わせます。

PBMAC1 has the following OID:

PBMAC1には次のOIDがあります。

      id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
         rsadsi(113549) pkcs(1) pkcs-5(5) 14 }
        

Specific conventions to be considered for PBMAC1 are specified in Section 7.1 and Appendix A.5 of [RFC8018].

PBMAC1で考慮される特定の規則は、[RFC8018]のセクション7.1および付録A.5で指定されています。

6.2. Symmetric Key-Based MAC
6.2. 対称キーベースのMac

Symmetric key-based message authentication code (MAC) algorithms are used for deriving the symmetric encryption key when using PBKDF2, as described in Section 4.4.1, as well as with password-based MAC, as described in Section 6.1.

対称キーベースのメッセージ認証コード(MAC)アルゴリズムは、セクション4.4.1で説明されているように、およびセクション6.1で説明されているように、PBKDF2を使用する場合、PBKDF2を使用するときに対称暗号化キーを導出するために使用されます。

MAC algorithm identifiers are located in the:

MACアルゴリズム識別子は次のようになります。

* protectionAlg field of PKIHeader,

* pkiheaderの保護分野、

* messageAuthScheme field of PBMAC1,

* pbmac1のmessageauthschemeフィールド、

* mac field of PBMParameter, and

* pbmparameterのMacフィールド、および

* prf field of PBKDF2-params.

* PBKDF2-PARAMSのPRFフィールド。

MAC values are located in the:

Mac値は次のようにあります。

* PKIProtection field of PKIMessage.

* pkimessageのpkiprotectionフィールド。

6.2.1. SHA2-Based HMAC
6.2.1. SHA2ベースのHMAC

The HMAC algorithm is defined in [RFC2104] and FIPS Pub 198-1 [NIST.FIPS.198-1].

HMACアルゴリズムは[RFC2104]およびFIPS Pub 198-1 [nist.fips.198-1]で定義されています。

The HMAC algorithm used with SHA2 message digest algorithms is identified by the following OIDs:

SHA2メッセージダイジェストアルゴリズムで使用されるHMACアルゴリズムは、次のOIDによって識別されます。

      id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) digestAlgorithm(2) 8 }
      id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) digestAlgorithm(2) 9 }
      id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) digestAlgorithm(2) 10 }
      id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) digestAlgorithm(2) 11 }
        

Specific conventions to be considered for SHA2-based HMAC are specified in Section 3.1 of [RFC4231].

SHA2ベースのHMACに対して考慮される特定の規則は、[RFC4231]のセクション3.1で指定されています。

6.2.2. AES-GMAC
6.2.2. AES-GMAC

The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and NIST SP 800-38d [NIST.SP.800-38d].

AES-GMACアルゴリズムは、FIPS Pub 197 [nist.fips.197]およびnist sp 800-38d [nist.sp.800-38d]で定義されています。

Note: The AES-GMAC MUST NOT be used twice with the same parameter set, especially the same nonce. Therefore, it MUST NOT be used together with PBKDF2. When using it with PBMAC1, it MUST be ensured that the AES-GMAC is only used as a message authentication scheme and not for the key derivation function PBKDF2.

注:AES-GMACは、同じパラメーターセット、特に同じノンセで2回使用してはなりません。したがって、PBKDF2と一緒に使用してはなりません。PBMAC1でそれを使用する場合、AES-GMACがキー派生関数PBKDF2ではなくメッセージ認証スキームとしてのみ使用されることを保証する必要があります。

The AES-GMAC algorithm is identified by the following OIDs:

AES-GMACアルゴリズムは、次のOIDによって識別されます。

      id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 9 }
      id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 29 }
      id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) aes(1) 49 }
        

Specific conventions to be considered for the AES-GMAC are specified in [RFC9044].

AES-GMACに対して考慮される特定の規則は、[RFC9044]で指定されています。

6.2.3. SHAKE-Based KMAC
6.2.3. シェイクベースのKMAC

The KMAC algorithm is defined in [RFC8702] and FIPS SP 800-185 [NIST.SP.800-185]].

KMACアルゴリズムは[RFC8702]およびFIPS SP 800-185 [nist.sp.800-185]で定義されています。

The SHAKE-based KMAC algorithm is identified by the following OIDs:

シェイクベースのKMACアルゴリズムは、次のOIDによって識別されます。

      id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) hashAlgs(2) 19 }
      id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
         country(16) us(840) organization(1) gov(101) csor(3)
         nistAlgorithm(4) hashAlgs(2) 20 }
        

Specific conventions to be considered for KMAC with SHAKE are specified in Section 3.4 of [RFC8702].

KMACで検討される特定の規則は、[RFC8702]のセクション3.4で指定されています。

7. Algorithm Use Profiles
7. アルゴリズムはプロファイルを使用します

This section provides profiles of algorithms and respective conventions for different application use cases.

このセクションでは、さまざまなアプリケーションユースケースのアルゴリズムとそれぞれの規則のプロファイルを提供します。

Recommendations like those described in Table 2 of NIST SP 800-57 "Recommendation for Key Management" [NIST.SP.800-57pt1r5] and Section 4.6 of ECRYPT "Algorithms, Key Size and Protocols Report (2018)" [ECRYPT.CSA.D5.4] provide general information on current cryptographic algorithms.

NIST SP 800-57の表2に記載されているような推奨事項「キー管理に関する推奨」[nist.sp.800-57pt1r5]およびecrypt "アルゴリズム、キーサイズおよびプロトコルレポート(2018)" [ecrypt.csaのセクション4.6。D5.4]現在の暗号化アルゴリズムに関する一般情報を提供します。

The overall cryptographic strength of CMP implementations will depend on several factors, including:

CMP実装の全体的な暗号化強度は、次のようないくつかの要因に依存します。

* capabilities of the end entity: What kind of algorithms does the end entity support? The cryptographic strength of the system SHOULD be at least as strong as the algorithms and keys used for the certificate being managed.

* 最終エンティティの機能:最終エンティティはどのようなアルゴリズムをサポートしていますか?システムの暗号強度は、少なくとも証明書に管理されているアルゴリズムとキーと同じくらい強力でなければなりません。

* algorithm profile: The overall strength of the profile will be the strength of the weakest algorithm it contains.

* アルゴリズムプロファイル:プロファイルの全体的な強度は、含まれる最も弱いアルゴリズムの強度になります。

* message protection: The overall strength of the CMP message protection.

* メッセージ保護:CMPメッセージ保護の全体的な強度。

- MAC-based protection: The entropy of the shared secret information or password when MAC-based message protection is used (MSG_MAC_ALG).

- Macベースの保護:Macベースのメッセージ保護が使用される場合の共有秘密情報またはパスワードのエントロピー(MSG_MAC_ALG)。

- signature-based protection: The strength of the key pair and signature algorithm when signature-based protection is used (MSG_SIG_ALG).

- 署名ベースの保護:署名ベースの保護が使用されている場合のキーペアの強度と署名アルゴリズム(MSG_SIG_ALG)。

- protection of centrally generated keys: The strength of the algorithms used for the key management technique (Section 7.1: PROT_ENC_ALG or Section 7.2: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key and private key (Section 7.1: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.2: KM_KW_ALG, PROT_SYM_ALG).

- 中心に生成されたキーの保護:キー管理手法(セクション7.1:prot_enc_algまたはセクション7.2:km_kt_alg、km_kd_alg)に使用されるアルゴリズムの強度、およびコンテンツ暗号化キーと秘密キーの暗号化の暗号化(セクション7.1:Sym_penc_alg、prot_sym_algまたはセクション7.2:km_kw_alg、prot_sym_alg)。

The following table shows the algorithms listed in this document sorted by their bits of security. If an implementation intends to enroll and manage certificates for keys of a specific security, it SHALL implement and use algorithms of at least that strength for the respective PKI management operation. If one row does not provide a suitable algorithm, the implementer MUST choose one offering more bits of security.

次の表は、このドキュメントにリストされているアルゴリズムを、セキュリティのビットでソートしたことを示しています。実装が特定のセキュリティのキーの証明書を登録および管理することを目的としている場合、少なくともそれぞれのPKI管理操作にその強度のアルゴリズムを実装および使用するものとします。1つの行が適切なアルゴリズムを提供しない場合、実装者はより多くのセキュリティを提供する1つの1つを選択する必要があります。

   +========+==========+==============+==================+============+
   |Bits of | RSA or   | Elliptic     | Hash Function or | Symmetric  |
   |Security| DH       | Curve        | XOF with         | Encryption |
   |        |          | Cryptography | Specified Output |            |
   |        |          |              | Length (d)       |            |
   +========+==========+==============+==================+============+
   |112     | RSA2048, | ECDSA/ECDH   | SHA-224          |            |
   |        | DH(2048) | (secp224r1)  |                  |            |
   +--------+----------+--------------+------------------+------------+
   |128     | RSA3072, | ECDSA/ECDH   | SHA-256,         | AES-128    |
   |        | DH(3072) | (secp256r1), | SHAKE128(d=256)  |            |
   |        |          | Ed25519/     |                  |            |
   |        |          | X25519       |                  |            |
   |        |          | (curve25519) |                  |            |
   +--------+----------+--------------+------------------+------------+
   |192     |          | ECDSA/ECDH   | SHA-384          | AES-192    |
   |        |          | (secp384r1)  |                  |            |
   +--------+----------+--------------+------------------+------------+
   |224     |          | Ed448/X448   |                  |            |
   |        |          | (curve448)   |                  |            |
   +--------+----------+--------------+------------------+------------+
   |256     |          | ECDSA/ECDH   | SHA-512,         | AES-256    |
   |        |          | (secp521r1)  | SHAKE256(d=512)  |            |
   +--------+----------+--------------+------------------+------------+
        

Table 1: Cryptographic Algorithms Sorted by Their Bits of Security

表1:セキュリティのビットでソートされた暗号化アルゴリズム

The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details.

次の表は、CMPでの使用によってソートされた暗号化アルゴリズムと詳細を示しています。

   +========+==========+================+================+=============+
   |Bits of |Key Types | CMP Protection | Key Management |Key-Wrap and |
   |Security|to Be     | MSG_SIG_ALG,   | Technique      |Symmetric    |
   |        |Certified | MSG_MAC_ALG    | PROT_ENC_ALG   |Encryption   |
   |        |          |                | or KM_KA_ALG,  |PROT_SYM_ALG,|
   |        |          |                | KM_KT_ALG,     |SYM_PENC_ALG |
   |        |          |                | KM_KD_ALG      |or           |
   |        |          |                |                |KM_KW_ALG    |
   +========+==========+================+================+=============+
   |112     |RSA2048,  | RSASSA-PSS     | DH(2048),      |             |
   |        |secp224r1 | (2048, SHA-224 | RSAES-OAEP     |             |
   |        |          | or SHAKE128    | (2048, SHA-    |             |
   |        |          | (d=256)),      | 224),          |             |
   |        |          | RSAEncryption  | RSAEncryption  |             |
   |        |          | (2048, SHA-    | (2048, SHA-    |             |
   |        |          | 224),          | 224),          |             |
   |        |          | ECDSA          | ECDH           |             |
   |        |          | (secp224r1,    | (secp224r1,    |             |
   |        |          | SHA-224 or     | SHA-224),      |             |
   |        |          | SHAKE128       | PBKDF2 (HMAC-  |             |
   |        |          | (d=256)),      | SHA-224)       |             |
   |        |          | PBMAC1 (HMAC-  |                |             |
   |        |          | SHA-224)       |                |             |
   +--------+----------+----------------+----------------+-------------+
   |128     |RSA3072,  | RSASSA-PSS     | DH(3072),      |AES-128      |
   |        |secp256r1,| (3072, SHA-256 | RSAES-OAEP     |             |
   |        |curve25519| or SHAKE128    | (3072, SHA-    |             |
   |        |          | (d=256)),      | 256),          |             |
   |        |          | RSAEncryption  | RSAEncryption  |             |
   |        |          | (3072, SHA-    | (3072, SHA-    |             |
   |        |          | 256),          | 256),          |             |
   |        |          | ECDSA          | ECDH           |             |
   |        |          | (secp256r1,    | (secp256r1,    |             |
   |        |          | SHA-256 or     | SHA-256),      |             |
   |        |          | SHAKE128       | X25519,        |             |
   |        |          | (d=256)),      | PBKDF2 (HMAC-  |             |
   |        |          | Ed25519 (SHA-  | SHA-256)       |             |
   |        |          | 512),          |                |             |
   |        |          | PBMAC1 (HMAC-  |                |             |
   |        |          | SHA-256)       |                |             |
   +--------+----------+----------------+----------------+-------------+
   |192     |secp384r1 | ECDSA          | ECDH           |AES-192      |
   |        |          | (secp384r1,    | (secp384r1,    |             |
   |        |          | SHA-384),      | SHA-384),      |             |
   |        |          | PBMAC1 (HMAC-  | PBKDF2 (HMAC-  |             |
   |        |          | SHA-384)       | SHA-384)       |             |
   +--------+----------+----------------+----------------+-------------+
   |224     |curve448  | Ed448          | X448           |             |
   |        |          | (SHAKE256)     |                |             |
   +--------+----------+----------------+----------------+-------------+
   |256     |secp521r1 | ECDSA          | ECDH           |AES-256      |
   |        |          | (secp521r1,    | (secp521r1,    |             |
   |        |          | SHA-512 or     | SHA-512),      |             |
   |        |          | SHAKE256       | PBKDF2 (HMAC-  |             |
   |        |          | (d=512)),      | SHA-512)       |             |
   |        |          | PBMAC1 (HMAC-  |                |             |
   |        |          | SHA-512)       |                |             |
   +--------+----------+----------------+----------------+-------------+
        

Table 2: Cryptographic Algorithms Sorted by Their Bits of Security and Usage by CMP

表2:CMPがセキュリティと使用法のビットでソートした暗号化アルゴリズム

To avoid consuming too many computational resources, choosing a set of algorithms offering roughly the same level of security is recommended. Below are several algorithm profiles that are balanced, assuming the implementer chooses MAC secrets and/or certificate profiles of at least equivalent strength.

あまりにも多くの計算リソースを消費することを避けるために、ほぼ同じレベルのセキュリティを提供するアルゴリズムのセットを選択することをお勧めします。以下は、実装者が少なくとも同等の強度のMACシークレットおよび/または証明書プロファイルを選択すると仮定して、バランスのとれたいくつかのアルゴリズムプロファイルです。

7.1. Algorithm Profile for PKI Management Message Profiles in RFC 4210
7.1. RFC 4210のPKI管理メッセージプロファイルのアルゴリズムプロファイル

The following table updates the definitions of algorithms used within PKI Management Message Profiles, as defined in Appendix D.2 of [RFC4210].

次の表は、[RFC4210]の付録D.2で定義されているように、PKI管理メッセージプロファイル内で使用されるアルゴリズムの定義を更新します。

The columns in the table are:

テーブルの列は次のとおりです。

Name:

名前:

An identifier used for message profiles

メッセージプロファイルに使用される識別子

Use:

使用:

Description of where and for what the algorithm is used

アルゴリズムが使用される場所の説明

Mandatory:

必須:

Algorithms that MUST be supported by conforming implementations

実装の適合によってサポートする必要があるアルゴリズム

Optional:

オプション:

Algorithms that are OPTIONAL to support

サポートするためにオプションのアルゴリズム

Deprecated:

非推奨:

Algorithms from [RFC4210] that SHOULD NOT be used any more

これ以上使用すべきではない[RFC4210]からのアルゴリズム

   +============+=============+=========+=================+============+
   |Name        |Use          |Mandatory|Optional         |Deprecated  |
   +============+=============+=========+=================+============+
   |MSG_SIG_ALG |protection of|RSA      |ECDSA, EdDSA     |DSA,        |
   |            |PKI messages |         |                 |combinations|
   |            |using        |         |                 |with MD5 and|
   |            |signatures   |         |                 |SHA-1       |
   +------------+-------------+---------+-----------------+------------+
   |MSG_MAC_ALG |protection of|PBMAC1   |PasswordBasedMac,|X9.9        |
   |            |PKI messages |         |HMAC, KMAC       |            |
   |            |using MACs   |         |                 |            |
   +------------+-------------+---------+-----------------+------------+
   |SYM_PENC_ALG|symmetric    |AES-wrap |                 |3-DES(3-key-|
   |            |encryption of|         |                 |EDE, CBC    |
   |            |an end       |         |                 |Mode), RC5, |
   |            |entity's     |         |                 |CAST-128    |
   |            |private key  |         |                 |            |
   |            |where the    |         |                 |            |
   |            |symmetric key|         |                 |            |
   |            |is           |         |                 |            |
   |            |distributed  |         |                 |            |
   |            |out of band  |         |                 |            |
   +------------+-------------+---------+-----------------+------------+
   |PROT_ENC_ALG|asymmetric   |DH       |ECDH, RSA        |            |
   |            |algorithm    |         |                 |            |
   |            |used for     |         |                 |            |
   |            |encryption of|         |                 |            |
   |            |(symmetric   |         |                 |            |
   |            |keys for     |         |                 |            |
   |            |encryption   |         |                 |            |
   |            |of) private  |         |                 |            |
   |            |keys         |         |                 |            |
   |            |transported  |         |                 |            |
   |            |in           |         |                 |            |
   |            |PKIMessages  |         |                 |            |
   +------------+-------------+---------+-----------------+------------+
   |PROT_SYM_ALG|symmetric    |AES-CBC  |                 |3-DES(3-key-|
   |            |encryption   |         |                 |EDE, CBC    |
   |            |algorithm    |         |                 |Mode), RC5, |
   |            |used for     |         |                 |CAST-128    |
   |            |encryption of|         |                 |            |
   |            |private key  |         |                 |            |
   |            |bits (a key  |         |                 |            |
   |            |of this type |         |                 |            |
   |            |is encrypted |         |                 |            |
   |            |using        |         |                 |            |
   |            |PROT_ENC_ALG)|         |                 |            |
   +------------+-------------+---------+-----------------+------------+
        

Table 3: Algorithms Used within Appendix D.2 of RFC 4210

表3:RFC 4210の付録D.2で使用されるアルゴリズム

The following are the mandatory algorithm identifiers and specifications:

以下は、必須のアルゴリズム識別子と仕様です。

RSA:

RSA:

sha256WithRSAEncryption with 2048 bit, see Section 3.1

sha256withrsaencryption 2048ビットで、セクション3.1を参照してください

PasswordBasedMac:

PasswordBasedMac:

id-PasswordBasedMac, see Section 6.1 (with id-sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as the mac parameter, see Section 6.2.1)

id-passwordbasedmac、セクション6.1を参照してください(OWFパラメーターとしてID-SHA256を参照してください。MACパラメーターとしてのセクション2.1およびID-HMACWithSha256を参照してください。セクション6.2.1を参照)

PBMAC1:

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 the message authentication scheme, see Section 6.2.1). It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac.

ID-PBMAC1、セクション6.1.2を参照してください(ID-PBKDF2をキー派生関数として、メッセージ認証スキームとしてセクション4.4.1およびID-HMACWITHSHA256を参照してください。セクション6.2.1を参照)。Password BasedMacの代わりにPBMAC1の使用を好むことをお勧めします。

DH:

DH:

id-alg-ESDH, see Section 4.1.1

id-alg-esdh、セクション4.1.1を参照してください

AES-wrap:

aes-rap:

id-aes128-wrap, see Section 4.3.1

ID-aes128-wrap、セクション4.3.1を参照してください

AES-CBC:

AES-CBC:

id-aes128-CBC, see Section 5.1

ID-AES128-CBC、セクション5.1を参照してください

7.2. Algorithm Profile for Lightweight CMP Profile
7.2. 軽量CMPプロファイルのアルゴリズムプロファイル

The following table contains definitions of algorithms that MAY be supported by implementations of the Lightweight CMP Profile [RFC9483].

次の表には、軽量のCMPプロファイル[RFC9483]の実装によってサポートされる可能性のあるアルゴリズムの定義が含まれています。

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 message protection, and the certificates to be managed, this document will not specify a specific set that is mandatory to support for conforming implementations.

軽量CMPプロファイルの実装に使用されるアルゴリズムのセットは、実装されたPKI管理操作、メッセージ保護に使用される証明書、および管理される証明書に大きく依存するため、このドキュメントは、必須の特定のセットを指定しません。適合実装のサポート。

The columns in the table are:

テーブルの列は次のとおりです。

Name:

名前:

An identifier used for message profiles

メッセージプロファイルに使用される識別子

Use:

使用:

Description of where and for what the algorithm is used

アルゴリズムが使用される場所の説明

Examples:

例:

Lists the algorithms, as described in this document. The list of algorithms depends on the set of PKI management operations to be implemented.

このドキュメントで説明されているように、アルゴリズムをリストします。アルゴリズムのリストは、実装されるPKI管理操作のセットに依存します。

Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac.

注:Password BasedMacの代わりにPBMAC1の使用を好むことをお勧めします。

   +==============+================================+==================+
   | Name         | Use                            | Examples         |
   +==============+================================+==================+
   | MSG_SIG_ALG  | protection of PKI messages     | RSA, ECDSA,      |
   |              | using signatures and for       | EdDSA            |
   |              | SignedData, e.g., a private    |                  |
   |              | key transported in PKIMessages |                  |
   +--------------+--------------------------------+------------------+
   | MSG_MAC_ALG  | protection of PKI messages     | PasswordBasedMac |
   |              | using MACing                   | (see Section 9), |
   |              |                                | PBMAC1, HMAC,    |
   |              |                                | KMAC             |
   +--------------+--------------------------------+------------------+
   | KM_KA_ALG    | asymmetric key agreement       | DH, ECDH         |
   |              | algorithm used for agreement   |                  |
   |              | of a symmetric key for use     |                  |
   |              | with KM_KW_ALG                 |                  |
   +--------------+--------------------------------+------------------+
   | KM_KT_ALG    | asymmetric key-encryption      | RSA              |
   |              | algorithm used for transport   |                  |
   |              | of a symmetric key for         |                  |
   |              | 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-CBC          |
   |              | algorithm used for encryption  |                  |
   |              | of EnvelopedData, e.g., a      |                  |
   |              | private key transported in     |                  |
   |              | PKIMessages                    |                  |
   +--------------+--------------------------------+------------------+
        

Table 4: Algorithms Used within the Lightweight CMP Profile

表4:軽量CMPプロファイル内で使用されるアルゴリズム

8. IANA Considerations
8. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

9. Security Considerations
9. セキュリティに関する考慮事項

This document lists many cryptographic algorithms usable with CMP to 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 defines the security of the overall solution; see Section 7.

このドキュメントには、CMPで使用可能な多くの暗号化アルゴリズムが、実装者に最新の選択肢を提供します。最後に、サポートされるアルゴリズムは、ターゲット環境で利用される証明書とPKI管理操作に大きく依存します。セキュリティ強度が最も低く、共有された秘密情報のエントロピーを備えたアルゴリズムは、全体的なソリューションのセキュリティを定義します。セクション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. Second, the PasswordBasedMac algorithm as specified in Section 4.4 of [RFC4211] is essentially PBKDF1 (as defined in Section 5.1 of [RFC8018]) with an HMAC step at the end. Here, we update to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. PBKDF2 is superior to PBKDF1 in an improved internal construct for iterated hashing and in removing PBKDF1's limitation of only being able to derive keys up to the size of the underlying hash function. Additionally, PBKDF1 is not recommended for new applications as stated in Section 5.1 of [RFC8018] and is no longer an approved algorithm by most standards bodies. Therefore, it presents difficulties to implementers who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with [RFC9045], which updates [RFC4211] to allow the use of PBMAC1 in CRMF.

MACベースのメッセージ保護を使用する場合、PBMAC1の使用がパスワードベースMACの使用よりも好ましいです。まず、PBMAC1はよく知られている精査アルゴリズムであり、パスワードベースMACには当てはまりません。第二に、[RFC4211]のセクション4.4で指定されているパスワードベースのアルゴリズムは、基本的にPBKDF1([RFC8018]のセクション5.1で定義されている)であり、最後にHMACステップがあります。ここでは、[RFC8018]でPBMAC1として定義されたPBKDF2-HMACコンストラクトを使用するように更新します。PBKDF2は、繰り返しのハッシュのための改善された内部構築と、基礎となるハッシュ関数のサイズまでキーを導出できるというPBKDF1の制限を除去する際に、PBKDF1よりも優れています。さらに、[RFC8018]のセクション5.1に記載されているように、PBKDF1は新しいアプリケーションには推奨されず、ほとんどの標準団体で承認されたアルゴリズムではなくなりました。したがって、CMP実装を認証のために提出している実装者に困難をもたらし、PBKDF2ベースのメカニズムに移行します。この変更は[RFC9045]と一致しており、[RFC9045]は[RFC4211]を更新して、CRMFでPBMAC1を使用できるようにします。

The AES-GMAC MUST NOT be used as the pseudorandom function (PRF) in PBKDF2; the use of the AES-GMAC more than once with the same key and the same nonce will break the security.

AES-GMACは、PBKDF2の擬似ランダム関数(PRF)として使用してはなりません。AES-GMACを同じキーと同じノンセを使用して複数回使用すると、セキュリティが破壊されます。

In Section 7 of this document, there is also an update to Appendix D.2 of [RFC4210] and a set of algorithms that MAY be supported when implementing the Lightweight CMP Profile [RFC9483]. It is recognized that there may be older CMP implementations in use that conform to the algorithm use profile from Appendix D.2 of [RFC4210]. For example, the use of AES is now mandatory for PROT_SYM_ALG, while 3-DES was mandatory in [RFC4210]. Therefore, it is expected that many CMP systems may already support the recommended algorithms in this specification. In such systems, the weakened algorithms should be disabled from further use. If critical systems cannot be immediately updated to conform to the recommended algorithm use profile, it is recommended that a plan to migrate the infrastructure to conforming profiles be adopted as soon as possible.

このドキュメントのセクション7には、[RFC4210]の付録D.2の更新と、軽量CMPプロファイル[RFC9483]の実装時にサポートされるアルゴリズムのセットもあります。[RFC4210]の付録D.2のアルゴリズムを使用するプロファイルに準拠する古いCMP実装が使用されている可能性があることが認識されています。たとえば、AESの使用はPROT_SYM_ALGに必須であり、3-DEは[RFC4210]では必須でした。したがって、多くのCMPシステムがこの仕様で推奨されるアルゴリズムをすでにサポートする可能性があると予想されます。このようなシステムでは、弱体化したアルゴリズムをさらに使用して無効にする必要があります。重要なシステムをすぐに更新して推奨されるアルゴリズムの使用プロファイルに適合できない場合は、インフラストラクチャを移行する計画をできるだけ早く採用することをお勧めします。

Symmetric key-based MAC algorithms as described in Section 6.2 MAY be used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and ensure that the key has sufficient entropy to match the overall security level of the algorithm profile. These considerations are outside the scope of the profile.

セクション6.2で説明されている対称キーベースのMacアルゴリズムは、MSG_MAC_ALGとして使用できます。実装者は、適切なPRFを選択し、キーにアルゴリズムプロファイルの全体的なセキュリティレベルに合うのに十分なエントロピーがあることを確認する必要があります。これらの考慮事項は、プロファイルの範囲外です。

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献
   [NIST.FIPS.180-4]
              Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal
              Information Processing Standards Publications 180-4,
              DOI 10.6028/NIST.FIPS.180-4, July 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.
        
   [NIST.FIPS.186-5]
              National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS)", FIPS PUB 186-5,
              DOI 10.6028/NIST.FIPS.186-5, February 2023,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-5.pdf>.
        
   [NIST.FIPS.197]
              National Institute of Standards and Technology (NIST),
              "Advanced Encryption Standard (AES)", NIST FIPS 197,
              DOI 10.6028/NIST.FIPS.197, November 2001,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.197.pdf>.
        
   [NIST.FIPS.198-1]
              National Institute of Standards and Technology (NIST),
              "The Keyed-Hash Message Authentication Code (HMAC)", FIPS
              PUB 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.198-1.pdf>.
        
   [NIST.FIPS.202]
              Dworkin, M. J. and NIST, "SHA-3 Standard: Permutation-
              Based Hash and Extendable-Output Functions", NIST Federal
              Information Processing Standards Publications 202,
              DOI 10.6028/NIST.FIPS.202, July 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.202.pdf>.
        
   [NIST.SP.800-185]]
              Kelsey, J., Change, S., Perlner, R., and NIST, "SHA-3
              derived functions: cSHAKE, KMAC, TupleHash and
              ParallelHash", NIST Special Publications
              (General) 800-185, DOI 10.6028/NIST.SP.800-185, December
              2016,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-185.pdf>.
        
   [NIST.SP.800-38d]
              Dworkin, M J. and NIST, "Recommendation for block cipher
              modes of operation :GaloisCounter Mode (GCM) and GMAC",
              NIST Special Publications (General) 800-38d,
              DOI 10.6028/NIST.SP.800-38d, 2007,
              <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
              nistspecialpublication800-38d.pdf>.
        
   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.
        
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.
        
   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, DOI 10.17487/RFC2631, June 1999,
              <https://www.rfc-editor.org/info/rfc2631>.
        
   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
              <https://www.rfc-editor.org/info/rfc3370>.
        
   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
              September 2002, <https://www.rfc-editor.org/info/rfc3394>.
        
   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
              Algorithm in Cryptographic Message Syntax (CMS)",
              RFC 3560, DOI 10.17487/RFC3560, July 2003,
              <https://www.rfc-editor.org/info/rfc3560>.
        
   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
              <https://www.rfc-editor.org/info/rfc3565>.
        
   [RFC4056]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
              Cryptographic Message Syntax (CMS)", RFC 4056,
              DOI 10.17487/RFC4056, June 2005,
              <https://www.rfc-editor.org/info/rfc4056>.
        
   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <https://www.rfc-editor.org/info/rfc4210>.
        
   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF)", RFC 4211,
              DOI 10.17487/RFC4211, September 2005,
              <https://www.rfc-editor.org/info/rfc4211>.
        
   [RFC4231]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
              224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
              RFC 4231, DOI 10.17487/RFC4231, December 2005,
              <https://www.rfc-editor.org/info/rfc4231>.
        
   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
              <https://www.rfc-editor.org/info/rfc5480>.
        
   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.
        
   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
              2010, <https://www.rfc-editor.org/info/rfc5753>.
        
   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
              2010, <https://www.rfc-editor.org/info/rfc5754>.
        
   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <https://www.rfc-editor.org/info/rfc8017>.
        
   [RFC8018]  Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
              Password-Based Cryptography Specification Version 2.1",
              RFC 8018, DOI 10.17487/RFC8018, January 2017,
              <https://www.rfc-editor.org/info/rfc8018>.
        
   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.
        
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
        
   [RFC8418]  Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
              Agreement Algorithm with X25519 and X448 in the
              Cryptographic Message Syntax (CMS)", RFC 8418,
              DOI 10.17487/RFC8418, August 2018,
              <https://www.rfc-editor.org/info/rfc8418>.
        
   [RFC8419]  Housley, R., "Use of Edwards-Curve Digital Signature
              Algorithm (EdDSA) Signatures in the Cryptographic Message
              Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
              2018, <https://www.rfc-editor.org/info/rfc8419>.
        
   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
        
   [RFC8692]  Kampanakis, P. and Q. Dang, "Internet X.509 Public Key
              Infrastructure: Additional Algorithm Identifiers for
              RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
              DOI 10.17487/RFC8692, December 2019,
              <https://www.rfc-editor.org/info/rfc8692>.
        
   [RFC8702]  Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash
              Functions in the Cryptographic Message Syntax (CMS)",
              RFC 8702, DOI 10.17487/RFC8702, January 2020,
              <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>.
        
   [RFC9480]  Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
              Management Protocol (CMP) Updates", RFC 9480,
              DOI 10.17487/RFC9480, November 2023,
              <https://www.rfc-editor.org/info/rfc9480>.
        
   [RFC9483]  Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
              Certificate Management Protocol (CMP) Profile", RFC 9483,
              DOI 10.17487/RFC9483, November 2023,
              <https://www.rfc-editor.org/info/rfc9483>.
        
10.2. Informative References
10.2. 参考引用
   [ECRYPT.CSA.D5.4]
              University of Bristol, "Algorithms, Key Size and Protocols
              Report (2018)", March 2015,
              <https://www.ecrypt.eu.org/csa/documents/
              D5.4-FinalAlgKeySizeProt.pdf>.
        
   [NIST.SP.800-57pt1r5]
              Barker, E. and NIST, "Recommendation for key
              management:part 1 - general", NIST Special Publications
              (General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5,
              May 2020,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-57pt1r5.pdf>.
        
Acknowledgements
謝辞

Thanks to Russ Housley for his work on [RFC9044] and [RFC9045] upon which this RFC relies heavily.

このRFCが大きく依存している[RFC9044]と[RFC9045]に関する彼の作業について、Russ Housleyに感謝します。

May thanks also to all reviewers like Serge Mister, Mark Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb, and Steffen Fries for their input and feedback to this document. Apologies to all not mentioned reviewers and supporters.

また、セルジュ・ミスター、マーク・フェレイラ、Yuefei Lu、Tomas Gustavsson、Lijun Liao、David Von Oheimb、Steffen Friesなどのすべてのレビュアーにも感謝します。言及されていないすべてのレビュアーとサポーターに謝罪します。

Authors' Addresses
著者のアドレス
   Hendrik Brockhaus
   Siemens AG
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany
   Email: hendrik.brockhaus@siemens.com
   URI:   https://www.siemens.com
        
   Hans Aschauer
   Siemens AG
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany
   Email: hans.aschauer@siemens.com
   URI:   https://www.siemens.com
        
   Mike Ounsworth
   Entrust
   1187 Park Place
   Minneapolis, MN 55379
   United States of America
   Email: mike.ounsworth@entrust.com
   URI:   https://www.entrust.com
        
   John Gray
   Entrust
   1187 Park Place
   Minneapolis, MN 55379
   United States of America
   Email: john.gray@entrust.com
   URI:   https://www.entrust.com