[要約] RFC 5959は、非対称キーパッケージコンテンツタイプのアルゴリズムに関する仕様です。その目的は、非対称キーのパッケージングと交換に使用されるアルゴリズムを定義することです。
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5959 IECA
Category: Standards Track August 2010
ISSN: 2070-1721
Algorithms for Asymmetric Key Package Content Type
非対称キーパッケージコンテンツタイプのアルゴリズム
Abstract
概要
This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData.
このドキュメントでは、RFC 5958で定義されているように、暗号化されたPrivateKeyInfo構造を使用していくつかの暗号化アルゴリズムを使用するための規則について説明しています。これは、SignedData、EnvelopedData、EncryptedData、認定data、およびauthenvelopeddataを備えた非対称スキップパッケージのコンテンツタイプを保護するために必要な規則も含まれています。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc5959.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5959で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure [RFC5958]. The EncryptedPrivateKeyInfo is used by [P12] to encrypt PrivateKeyInfo [RFC5958]. It is similar to EncryptedData [RFC5652] in that it has no recipients, no originators, and no content encryption keys and requires keys to be managed by other means.
このドキュメントでは、暗号化されたPrivateKeyInfo構造[RFC5958]でいくつかの暗号化アルゴリズムを使用するための規則について説明します。暗号化されたPrivateKeyInfo [RFC5958]を暗号化するために[P12]によって暗号化されたPrivateKeyInfoが使用されます。これは、cyncyptedData [RFC5652]に似ています。これは、受信者、オリジネーター、コンテンツの暗号化キーがなく、他の手段で管理するためにキーを必要とするという点で類似しています。
This document also includes conventions necessary to protect the AsymmetricKeyPackage content type [RFC5958] with Cryptographic Message Syntax (CMS) protecting content types: SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083]. Implementations of AsymmetricKeyPackage do not require support for any CMS protecting content type; however, if the AsymmetricKeyPackage is CMS protected it is RECOMMENDED that conventions defined herein be followed.
このドキュメントには、コンテンツタイプを保護する暗号化メッセージの構文（CMS）を使用して、非対称Keypackageコンテンツタイプ[RFC5958]を保護するために必要な規則も含まれています。]。非対称KMEPACKAGEの実装では、CMS保護コンテンツタイプをサポートする必要はありません。ただし、非対称KMSがCMS保護されている場合は、ここで定義されている規則に従うことをお勧めします。
This document does not define any new algorithms instead it refers to previously defined algorithms.
このドキュメントは、以前に定義されたアルゴリズムを指す代わりに、新しいアルゴリズムを定義するものではありません。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The de facto standard used to encrypt the PrivateKeyInfo structure, which is subsequently placed in the EncryptedPrivateKeyInfo encryptedData field, is Password Based Encryption (PBE) based on PKCS #5 [RFC2898] and PKCS #12 [P12]. The major difference between PKCS #5 and PKCS #12 is the supported encoding for the password: ASCII for PKCS #5 and Unicode for PKCS #12, encoded as specified in Section B.1 of [P12]. [RFC2898] specifies two PBE Schemes (PBES) 1 and 2; [RFC2898] recommends PBES2 for new specification. PBES2 with a key derivation algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an encryption algorithm of AES Key Wrap with Padding as defined in [RFC5649] MUST be supported. AES-256 Key Wrap with Padding [RFC5649] MAY also be supported as an encryption algorithm.
PrivateKeyInfo構造を暗号化するために使用される事実上の基準は、その後暗号化されたPrivateKeyInfoの暗号化されたDataフィールドに配置され、PKCS＃5 [RFC2898]およびPKCS＃12 [P12]に基づくパスワードベースの暗号化（PBE）です。PKCS＃5とPKCS＃12の主な違いは、パスワードのサポートされているエンコードです。PKCS＃5のASCIIとPKCS＃12のUnicodeは、[P12]のセクションB.1で指定されているようにエンコードされています。[RFC2898]は、2つのPBEスキーム（PBE）1および2を指定します。[RFC2898]新しい仕様にはPBES2を推奨します。SHA-256 [RFC5754]を使用してHMACを使用してPBKDF2のキー派生アルゴリズムを備えたPBES2と、[RFC5649]で定義されているパディングを使用したAESキーラップの暗号化アルゴリズムをサポートする必要があります。AES-256パディング付きキーラップ[RFC5649]も暗号化アルゴリズムとしてサポートされる場合があります。
As noted in Asymmetric Key Packages [RFC5958], CMS can be used to protect the AsymmetricKeyPackage. The following provides guidance for SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData
非対称のキーパッケージ[RFC5958]で述べたように、CMSを使用して非対称KeyPackageを保護できます。以下は、SignedData [RFC5652]、EnvelopedData [RFC5652]、暗号化のガイダンスを提供します。
[RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083].
[RFC5652]、認証されたData [RFC5652]、およびAuthEnvelopedData [RFC5083]。
If an implementation supports SignedData, then it MUST support the signature scheme RSA [RFC3370] [RFC5754] and SHOULD support the signature schemes RSASSA-PSS [RFC4056] and DSA [RFC3370] [RFC5754]. Additionally, implementations MUST support in concert with these signature schemes the hash function SHA-256 [RFC5754] and SHOULD support the hash function SHA-1 [RFC3370].
実装がSignedDataをサポートする場合、署名スキームRSA [RFC3370] [RFC5754]をサポートする必要があり、RSASSA-PSS [RFC4056]およびDSA [RFC3370] [RFC5754]をサポートする必要があります。さらに、実装は、これらの署名スキームと協調してハッシュ関数SHA-256 [RFC5754]をサポートする必要があり、ハッシュ関数SHA-1 [RFC3370]をサポートする必要があります。
If an implementation supports EnvelopedData, then it MUST implement key transport and it MAY implement key agreement.
実装がEnvelopedDataをサポートする場合、主要な輸送を実装する必要があり、重要な合意を実装する必要があります。
When key transport is used, RSA encryption [RFC3370] MUST be supported and RSAES-OAEP (RSA Encryption Scheme - Optimal Asymmetric Encryption Padding) [RFC3560] SHOULD be supported.
キートランスポートを使用する場合、RSA暗号化[RFC3370]をサポートする必要があり、RSAES -OAEP（RSA暗号化スキーム - 最適な非対称暗号化パッド）[RFC3560]をサポートする必要があります。
When key agreement is used, Diffie-Hellman (DH) ephemeral-static [RFC3370] MUST be supported.
主要な合意が使用される場合、Diffie-Hellman（DH）Ephemeral-Static [RFC3370]をサポートする必要があります。
Since the content type is used to carry a cryptographic key and its attributes, an algorithm that is traditionally used to encrypt one key with another is employed. 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.
コンテンツタイプは暗号化キーとその属性を運ぶために使用されるため、1つのキーを別のキーと暗号化するために伝統的に使用されていたアルゴリズムが採用されています。主要な管理手法の選択に関係なく、実装はコンテンツ暗号化アルゴリズムとしてパディング[RFC5649]を使用したAES-128キーラップをサポートする必要があります。実装は、コンテンツ暗号化アルゴリズムとしてパディング[RFC5649]を使用したAES-256キーラップをサポートする必要があります。
When key agreement is used, a key wrap algorithm is also specified to wrap the content encryption key. 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キーラップである場合、キーラップアルゴリズムはパディング付きAES-128キーラップでなければなりません[RFC5649]。コンテンツ暗号化アルゴリズムがパディングを備えたAES-256キーラップである場合、キーラップアルゴリズムはパディング付きのAES-256キーラップでなければなりません[RFC5649]。
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].
実装が暗号化されたDataをサポートする場合、パディング[RFC5649]を使用してAES-128キーラップを実装する必要があり、パディング[RFC5649]でAES-256キーラップを実装する必要があります。
NOTE: EncryptedData requires that keys be managed by other means; therefore, the only algorithm specified is the content encryption algorithm. Since the content type is used to carry a cryptographic key and its attributes, an algorithm that is traditionally used to encrypt one key with another is employed.
注：暗号化されたDataでは、キーを他の手段で管理する必要があります。したがって、指定された唯一のアルゴリズムは、コンテンツ暗号化アルゴリズムです。コンテンツタイプは暗号化キーとその属性を運ぶために使用されるため、1つのキーを別のキーと暗号化するために伝統的に使用されていたアルゴリズムが採用されています。
If an implementation supports AuthenticatedData, then it MUST implement SHA-256 [RFC5754] and SHOULD support SHA-1 [RFC3370] as the message digest algorithm. Additionally, HMAC with SHA-256 [RFC4231] MUST be supported and HMAC with SHA-1 [RFC3370] SHOULD be supported.
実装が認証されたDataをサポートする場合、SHA-256 [RFC5754]を実装し、メッセージダイジェストアルゴリズムとしてSHA-1 [RFC3370]をサポートする必要があります。さらに、SHA-256 [RFC4231]を使用したHMACをサポートする必要があり、SHA-1 [RFC3370]を使用したHMACをサポートする必要があります。
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 for AES-CCM [RFC5084].
実装がAuthEnvelopedDataをサポートする場合、コンテンツ暗号化アルゴリズムを除き、封筒の推奨事項を実装する必要があります。この場合はAES-GCM [RFC5084]でなければなりません。128ビットバージョンを実装する必要があり、256ビットバージョンを実装する必要があります。実装は、AES-CCM [RFC5084]をサポートする場合があります。
The easiest way to implement the SignedData, EnvelopedData, and AuthEnvelopedData is with public key certificates [RFC5280]. If an implementation support RSA, RSASSA-PSS, DSS, RSAES-OAEP, or DH, then it MUST support key lengths from 1024-bit to 2048-bit, inclusive.
SignedData、EnvelopedData、およびAuthEnvelopedDataを実装する最も簡単な方法は、公開キー証明書[RFC5280]を使用しています。実装がRSA、RSASSA-PSS、DSS、RSAES-OAEP、またはDHをサポートする場合、1024ビットから2048ビットまでのキー長、包括的サポートする必要があります。
[RFC5751] defines the SMIMECapabilities attribute as a mechanism for recipients to indicate their supported capabilities including the algorithms they support. The following are values for the SMIMECapabilities attribute for AES Key Wrap with Padding [RFC5649] when used as a content encryption algorithm:
[RFC5751]は、SmimeCapability属性を、サポートするアルゴリズムを含むサポートされている機能を受信者が示すメカニズムとして定義します。以下は、コンテンツ暗号化アルゴリズムとして使用した場合、パディングを使用したAESキーラップのsmimeCapabilities属性の値です。
AES-128 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 08 AES-192 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 1C AES-256 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 30
パディング付きAES-128 kW：30 06 09 60 86 48 01 65 03 04 01 01 08 AES-192 kWパディング付きAES-192 kW：30 06 09 60 86 48 01 65 03 04 0109 60 86 48 01 65 03 04 01 30
The security considerations from [RFC3370], [RFC3560], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649], [RFC5652], [RFC5754], and [RFC5958] apply.
[RFC3370]、[RFC3560]、[RFC4056]、[RFC4231]、[RFC5084]、[RFC5084]、[RFC5649]、[RFC5652]、[RFC5754]、[RFC5754]、[RFC5958]からのセキュリティに関する考慮事項。
The strength of any encryption scheme is only as good as its weakest link, which in the case of a PBES is the password. Passwords need to provide sufficient entropy to ensure they cannot be easily guessed. The U.S. National Institute of Standards and Technology (NIST) Electronic Authentication Guidance [SP800-63] provides some information on password entropy. [SP800-63] indicates that a user-chosen 20-character password from a 94-character keyboard with no checks provides 36 bits of entropy. If the 20-character password is randomly chosen, then the amount of entropy is increased to roughly 131 bits of entropy. The amount of entropy in the password does not correlate directly to bits of security but in general the more than the better.
暗号化スキームの強度は、PBEの場合にパスワードである場合に最も弱いリンクと同じくらい優れています。パスワードは、簡単に推測できないことを確認するために、十分なエントロピーを提供する必要があります。米国国立標準技術研究所（NIST）電子認証ガイダンス[SP800-63]は、パスワードエントロピーに関する情報を提供しています。[SP800-63]は、チェックなしで94文字のキーボードからユーザーが選択した20文字のパスワードが36ビットのエントロピーを提供することを示しています。20文字のパスワードがランダムに選択されている場合、エントロピーの量は約131ビットのエントロピーに増加します。パスワードのエントロピーの量は、セキュリティのビットと直接相関するのではなく、一般的にはより良いものです。
The choice of content encryption algorithms for this document was based on [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.
このドキュメントのコンテンツ暗号化アルゴリズムの選択は、[RFC5649]に基づいていました。暗号化のキーイング素材の材料は、この目標を支援できます」。残念ながら、同じプロパティを提供する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]は、特定の数のセキュリティが適切であり、一部の環境がこれらの時間枠が有用であると感じる時間枠を提供します。
[P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information Exchange Syntax", June 1999.
[P12] RSA Laboratories、「PKCS＃12 V1.0：個人情報交換構文」、1999年6月。
[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月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B。、「PKCS＃5：パスワードベースの暗号化仕様バージョン2.0」、RFC 2898、2000年9月。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、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月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231] Nystrom、M。、「HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512 "の識別子およびテストベクター、RFC 4231、2005年12月。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083] Housley、R。、「暗号化メッセージ構文（CMS）認証されたエンベロープDATAコンテンツタイプ」、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。、「暗号化メッセージ構文（CMS）でAES-CCMおよびAES-GCM認証暗号化を使用して」、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公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、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）パディングアルゴリズム付きキーラップ」、RFC 5649、2009年9月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754] Turner、S。、「暗号化メッセージ構文を使用したSHA2アルゴリズムを使用」、RFC 5754、2010年1月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]ターナー、S。、「非対称キーパッケージ」、RFC 5958、2010年8月。
[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月。
[SP800-63] National Institute of Standards and Technology (NIST), Special Publication 800-63: Electronic Authentication Guidance, April 2006.
[SP800-63]国立標準技術研究所（NIST）、特別出版800-63：電子認証ガイダンス、2006年4月。
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