RFC 6160 - Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6160
タイトル : RFC 6160 - 対称キーパッケージコンテンツタイプの暗号化メッセージ構文（CMS）保護のアルゴリズム
翻訳編集 : 自動生成

[要約] RFC 6160は、Cryptographic Message Syntax (CMS)を使用して対称鍵パッケージのコンテンツタイプを保護するためのアルゴリズムに関する仕様です。この文書の目的は、対称鍵の安全な配布と管理を支援するための標準的な方法を提供することにあります。利用場面としては、対称鍵を安全に交換、保存、または転送する必要があるシステムやアプリケーションでの使用が想定されます。関連するRFCには、CMSを定義するRFC 5652などがあります。RFC 6160は、鍵管理のセキュリティを強化するために、特定のアルゴリズムの使用を推奨しています。

Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 6160                                          IECA
Category: Standards Track                                     April 2011
ISSN: 2070-1721

Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types

対称キーパッケージコンテンツタイプの暗号化メッセージ構文（CMS）保護のアルゴリズム

Abstract

概要

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.

このドキュメントでは、暗号化メッセージ構文（CMS）でいくつかの暗号化アルゴリズムを使用して、対称キーパッケージのコンテンツタイプを保護するための規則について説明します。具体的には、SignedData、EnvelopedData、EncryptedData、AuthEnvelopedDataの実装に必要な規則が含まれています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

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

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6160で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

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

1. Introduction

1. はじめに

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) [RFC5652] to protect the symmetric key package content type defined in [RFC6031]. Specifically, it includes conventions necessary to implement the following CMS content types: SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652], and AuthEnvelopedData [RFC5083]. Familiarity with [RFC5083], [RFC5652], [RFC5753], and [RFC6031] is assumed.

このドキュメントでは、[RFC6031]で定義されている対称キーパッケージのコンテンツタイプを保護するために、暗号化メッセージ構文（CMS）[RFC5652]でいくつかの暗号化アルゴリズムを使用するための規則について説明します。具体的には、SignedData [RFC5652]、EnvelopedData [RFC5652]、EncryptedData [RFC5652]、AuthEnvelopedData [RFC5083]のCMSコンテンツタイプを実装するために必要な規則が含まれています。 [RFC5083]、[RFC5652]、[RFC5753]、および[RFC6031]に精通していることを前提としています。

This document does not define any new algorithms; instead, it refers to previously defined algorithms.

このドキュメントでは、新しいアルゴリズムを定義していません。代わりに、以前に定義されたアルゴリズムを参照します。

1.1. Terminology

1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. SignedData

If an implementation supports SignedData, then it MUST support the signature scheme RSA [RFC3370] and SHOULD support the signature schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and Digital Signature Algorithm (DSA) [RFC3370]. Additionally, implementations MUST support the hash function SHA-256 [RFC5754] in concert with these signature schemes, and they SHOULD support the hash function SHA-1 [RFC3370]. If an implementation supports SignedData, then it MAY support Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6090][RFC5753].

実装がSignedDataをサポートする場合、それは署名スキームRSA [RFC3370]をサポートしなければならず（MUST）、署名スキームRSA確率的署名スキーム（RSASSA-PSS）[RFC4056]およびデジタル署名アルゴリズム（DSA）[RFC3370]をサポートする必要があります。さらに、実装はこれらの署名方式と連携してハッシュ関数SHA-256 [RFC5754]をサポートしなければならず（MUST）、ハッシュ関数SHA-1 [RFC3370]をサポートする必要があります（SHOULD）。実装がSignedDataをサポートしている場合、楕円曲線デジタル署名アルゴリズム（ECDSA）[RFC6090] [RFC5753]をサポートする場合があります。

3. EnvelopedData

If an implementation supports EnvelopedData, then it MUST implement key transport, and it MAY implement key agreement.

実装がEnvelopedDataをサポートする場合、キー転送を実装する必要があり、キー合意を実装できます（MAY）。

When key transport is used, RSA encryption [RFC3370] MUST be supported, and RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) [RFC3560] SHOULD be supported.

鍵転送が使用されるとき、RSA暗号化[RFC3370]がサポートされなければならず（MUST）、RSA暗号化スキーム-最適非対称暗号化パディング（RSAES-OAEP）[RFC3560]がサポートされるべきです（SHOULD）。

When key agreement is used, Diffie-Hellman (DH) ephemeral-static [RFC3370] MUST be supported. When key agreement is used, Elliptic Curve Diffie-Hellman (ECDH) [RFC6090][RFC5753] MAY be supported.

鍵合意を使用する場合、Diffie-Hellman（DH）ephemeral-static [RFC3370]をサポートする必要があります。鍵合意が使用される場合、楕円曲線Diffie-Hellman（ECDH）[RFC6090] [RFC5753]がサポートされる場合があります。

Regardless of the key management technique choice, implementations MUST support AES-128 Key Wrap with Padding [RFC5649] as the content-encryption algorithm. Implementations SHOULD support AES-256 Key Wrap with Padding [RFC5649] as the content-encryption algorithm.

鍵管理技術の選択に関係なく、実装はコンテンツ暗号化アルゴリズムとしてパディング付きのAES-128鍵ラップ[RFC5649]をサポートする必要があります。実装では、コンテンツ暗号化アルゴリズムとしてAES-256 Key Wrap with Padding [RFC5649]をサポートする必要があります（SHOULD）。

When key agreement is used, the same key-wrap algorithm MUST be used for both key and content encryption. If the content-encryption algorithm is AES-128 Key Wrap with Padding, then the key-wrap algorithm MUST be AES-128 Key Wrap with Padding [RFC5649]. If the content-encryption algorithm is AES-256 Key Wrap with Padding, then the key-wrap algorithm MUST be AES-256 Key Wrap with Padding [RFC5649].

鍵合意を使用する場合、鍵とコンテンツの両方の暗号化に同じ鍵ラップアルゴリズムを使用する必要があります。コンテンツ暗号化アルゴリズムがAES-128 Key Wrap with Paddingの場合、キーラップアルゴリズムはAES-128 Key Wrap with Padding [RFC5649]である必要があります。コンテンツ暗号化アルゴリズムがAES-256 Key Wrap with Paddingである場合、キーラップアルゴリズムはAES-256 Key Wrap with Padding [RFC5649]である必要があります。

4. EncryptedData

If an implementation supports EncryptedData, then it MUST implement AES-128 Key Wrap with Padding [RFC5649] and SHOULD implement AES-256 Key Wrap with Padding [RFC5649].

実装がEncryptedDataをサポートする場合は、AES-128キーラップとパディング[RFC5649]を実装する必要があり、AES-256キーラップとパディング[RFC5649]を実装する必要があります。

NOTE: EncryptedData requires that keys be managed by other means; therefore, the only algorithm specified is the content-encryption algorithm.

注：EncryptedDataでは、キーを他の方法で管理する必要があります。したがって、指定された唯一のアルゴリズムはコンテンツ暗号化アルゴリズムです。

5. AuthEnvelopedData

If an implementation supports AuthEnvelopedData, then it MUST implement the EnvelopedData recommendations except for the content-encryption algorithm, which, in this case, MUST be AES-GCM [RFC5084]; the 128-bit version MUST be implemented, and the 256-bit version SHOULD be implemented. Implementations MAY also support AES-CCM [RFC5084].

実装がAuthEnvelopedDataをサポートする場合は、コンテンツ暗号化アルゴリズムを除くEnvelopedData推奨を実装する必要があります。この場合、AES-GCM [RFC5084]でなければなりません。 128ビットバージョンを実装する必要があり、256ビットバージョンを実装する必要があります（SHOULD）。実装はAES-CCM [RFC5084]もサポートしてもよい（MAY）。

6. Public Key Sizes

6. 公開鍵のサイズ

The easiest way to implement SignedData, EnvelopedData, and AuthEnvelopedData is with public key certificates [RFC5280]. If an implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, or Diffie-Hellman, then it MUST support key lengths from 1024-bit to 2048-bit, inclusive. If an implementation supports ECDSA or ECDH, then it MUST support keys on P-256.

SignedData、EnvelopedData、AuthEnvelopedDataを実装する最も簡単な方法は、公開鍵証明書[RFC5280]を使用することです。実装がRSA、RSASSA-PSS、DSA、RSAES-OAEP、またはDiffie-Hellmanをサポートする場合、1024ビットから2048ビットまでのキー長をサポートする必要があります。実装がECDSAまたはECDHをサポートする場合、P-256のキーをサポートする必要があります。

7. Security Considerations

7. セキュリティに関する考慮事項

The security considerations from [RFC3370], [RFC3560], [RFC4056], [RFC5083], [RFC5084], [RFC5649], [RFC5652], [RFC5753], [RFC5754], and [RFC6031] apply.

[RFC3370]、[RFC3560]、[RFC4056]、[RFC5083]、[RFC5084]、[RFC5649]、[RFC5652]、[RFC5753]、[RFC5754]、および[RFC6031]のセキュリティに関する考慮事項が適用されます。

The choice of content-encryption algorithms for this document was based on [RFC5649]:

このドキュメントのコンテンツ暗号化アルゴリズムの選択は、[RFC5649]に基づいています。

In the design of some high assurance cryptographic modules, it is desirable to segregate cryptographic keying material from other data. The use of a specific cryptographic mechanism solely for the protection of cryptographic keying material can assist in this goal.

一部の高保証暗号化モジュールの設計では、暗号化キーイング情報を他のデータから分離することが望ましいです。暗号化キーイング材料の保護のためだけに特定の暗号化メカニズムを使用すると、この目標を支援できます。

Unfortunately, there is no AES-GCM or AES-CCM mode that provides the same properties. If an AES-GCM and AES-CCM mode that provides the same properties is defined, then this document will be updated to adopt that algorithm.

残念ながら、同じプロパティを提供するAES-GCMまたはAES-CCMモードはありません。同じプロパティを提供するAES-GCMおよびAES-CCMモードが定義されている場合、このドキュメントはそのアルゴリズムを採用するように更新されます。

[SP800-57] provides comparable bits of security for some algorithms and key sizes. [SP800-57] also provides time frames during which certain numbers of bits of security are appropriate, and some environments may find these time frames useful.

[SP800-57]は、一部のアルゴリズムとキーサイズに対して同等のセキュリティを提供します。 [SP800-57]は、セキュリティの特定のビット数が適切な時間枠も提供します。環境によっては、これらの時間枠が役立つ場合があります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.

[RFC3370] Housley、R。、「Cryptographic Message Syntax（CMS）Algorithms」、RFC 3370、2002年8月。

[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.

[RFC3560] Housley、R。、「暗号化メッセージ構文（CMS）でのRSAES-OAEPキー転送アルゴリズムの使用」、RFC 3560、2003年7月。

[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.

[RFC4056] Schaad、J。、「暗号化メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用」、RFC 4056、2005年6月。

[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.

[RFC5083] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、2007年11月。

[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.

[RFC5084] Housley、R。、「Cryptographic Message Syntax（CMS）でのAES-CCMおよびAES-GCM Authenticated Encryptionの使用」、RFC 5084、2007年11月。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。

[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.

[RFC5649] Housley、R。およびM. Dworkin、「Advanced Encryption Standard（AES）Key Wrap with Padding Algorithm」、RFC 5649、2009年9月。

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.

[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。

[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.

[RFC5753]ターナーS.およびD.ブラウン、「暗号化メッセージ構文（CMS）での楕円曲線暗号化（ECC）アルゴリズムの使用」、RFC 5753、2010年1月。

[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.

[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、2010年1月。

[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.

[RFC6031]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Symmetric Key Package Content Type」、RFC 6031、2010年12月。

[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.

[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。

8.2. Informative Reference

8.2. 参考情報

[SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management - Part 1 (Revised), March 2007.

[SP800-57]米国国立標準技術研究所（NIST）、特別刊行物800-57：鍵管理の推奨-パート1（改訂）、2007年3月。

Author's Address

著者のアドレス

Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA

Sean Turner IECA、Inc. 3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA

   EMail: turners@ieca.com