Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6318 Vigil Security
Obsoletes: 5008 J. Solinas
Category: Informational National Security Agency
ISSN: 2070-1721 June 2011
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
Abstract
抽象
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008.
この文書は、この文書はRFC 5008を廃止RFC 5751.に指定されている/セキュア多目的インターネットメール拡張（S / MIME）で、米国国家安全保障局（NSA）のスイートBアルゴリズムを使用するための規則を指定します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6318.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6318で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. ASN.1 ......................................................4
1.3. Suite B Security Levels ....................................4
2. SHA-256 and SHA-384 Message Digest Algorithms ...................5
3. ECDSA Signature Algorithm .......................................6
4. Key Management ..................................................7
4.1. ECDH Key Agreement Algorithm ...............................7
4.2. AES Key Wrap ...............................................8
4.3. Key Derivation Functions ...................................9
5. AES CBC Content Encryption .....................................11
6. Security Considerations ........................................12
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
The Fact Sheet on National Security Agency (NSA) Suite B Cryptography [NSA] states:
国家安全保障局（NSA）スイートB暗号化は、[NSA]状態のファクトシート：
A Cryptographic Interoperability Strategy (CIS) was developed to find ways to increase assured rapid sharing of information both within the U.S. and between the U.S. and her partners through the use of a common suite of public standards, protocols, algorithms and modes referred to as the "Secure Sharing Suite" or S.3. The implementation of CIS will facilitate the development of a broader range of secure cryptographic products which will be available to a wide customer base. The use of selected public cryptographic standards and protocols and Suite B is the core of CIS.
暗号相互運用戦略（CIS）は、米国内および米国と呼ば公共の規格、プロトコル、アルゴリズムおよびモードの共通スイートを使用して、彼女のパートナー間の両方の情報を確実に迅速な共有化を拡大する方法を見つけるために開発されました「安全に共有スイート」またはS.3。 CISの実装は、幅広い顧客ベースに利用できるようになり、安全な暗号化製品の広い範囲の開発を促進します。選択された公開暗号規格とプロトコルとスイートBの使用は、CISの中核です。
In 2005, NSA announced Suite B Cryptography which built upon the National Policy on the use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information. In addition to the AES algorithm, Suite B includes cryptographic algorithms for key exchanges, digital signatures and hashing. Suite B cryptography has been selected from cryptography that has been approved by NIST for use by the U.S. Government and specified in NIST standards or recommendations.
2005年には、NSAは、国家安全保障システムと国家安全保障情報を保護するためのAdvanced Encryption Standard（AES）の使用上の国家政策に基づいて構築スイートB暗号化を発表しました。 AESアルゴリズムに加えて、スイートBは、キー交換、デジタル署名およびハッシュの暗号化アルゴリズムを含みます。スイートB暗号化は、米国政府による使用のためにNISTによって承認され、NIST規格または勧告に指定されている暗号化方式から選択されています。
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms [NSA] in Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME makes use of the Cryptographic Message Syntax (CMS) [CMS]. In particular, the signed-data and the enveloped-data content types are used. This document only addresses Suite B compliance for S/MIME. Other applications of CMS are outside the scope of this document.
この文書は、多目的インターネットメール拡張（S / MIME）[MSG]は/セキュアで[NSA]米国国家安全保障局（NSA）のスイートBアルゴリズムを使用するための規則を指定します。 S / MIMEは、暗号メッセージ構文（CMS）[CMS]を利用します。具体的には、署名されたデータおよびエンベロープデータのコンテンツタイプが使用されています。この文書では、唯一のS / MIMEのためのスイートBのコンプライアンスに対応しています。 CMSの他のアプリケーションは、この文書の範囲外です。
Since many of the Suite B algorithms enjoy uses in other environments as well, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support Suite B.
スイートBアルゴリズムの多くは、他の環境での使用を楽しむので、スイートBアルゴリズムのために必要な規則の大半は、すでに他の文書で指定されています。この文書では、スイートBをサポートすることを選択した開発者を支援するために繰り返して、いくつかの関連する詳細と、これらの規則のソースを参照します
This specification obsoletes RFC 5008 [SUITEBSMIME]. The primary reason for the publication of this document is to allow greater flexibility in the use of the Suite B Security Levels as discussed in Section 1.3. It also removes some duplication between this document and referenced RFCs.
この仕様はRFC 5008 [SUITEBSMIME]を廃止します。この文書の公開のための主な理由は、セクション1.3で説明したようにスイートBのセキュリティレベルを使用することでより大きな柔軟性を可能にすることです。また、この文書と参照RFCの間にいくつかの重複を削除します。
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 RFC 2119 [STDWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [STDWORDS]に記載されているように解釈されます。
CMS values are generated using ASN.1 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88].
CMS値は[X.208-88] ASN.1を用いて生成される、基本符号化規則（BER）[X.209-88]、および識別符号化規則（DER）[X.509-88]。
Suite B offers two suites of algorithms for key agreement, key derivation, key wrap and content encryption, and two possible combinations of hash and signing algorithm. Suite B algorithms are defined to support two minimum levels of cryptographic security: 128 and 192 bits.
スイートBは、鍵合意、鍵導出、キーラップやコンテンツの暗号化、およびハッシュと署名アルゴリズムの2つの可能性のある組み合わせのためのアルゴリズムの2つのスイートを提供しています。 128と192ビット：スイートBアルゴリズムは、暗号化セキュリティの2つの極小レベルをサポートするために定義されています。
For S/MIME signed messages, Suite B follows the direction set by RFC 5753 [CMSECC] and RFC 5754 [SHA2]. Suite B uses these combinations of message digest (hash) and signature functions (Sig Sets):
S / MIMEメッセージに署名したため、スイートBは、RFC 5753 [CMSECC]およびRFC 5754 [SHA2]によって設定された方向に従います。スイートBは、メッセージダイジェスト（ハッシュ）と署名機能（Sigはセット）のこれらの組み合わせを使用します。
Sig Set 1 Sig Set 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
For S/MIME encrypted messages, Suite B follows the direction set by RFC 5753 [CMSECC] and follows the conventions set by RFC 3565 [CMSAES].
S / MIME暗号化されたメッセージのために、スイートBは[CMSECC] RFC 5753によって設定された方向に続き、RFC 3565 [CMSAES]によって設定された規則に従います。
Suite B uses these key establishment (KE) algorithms (KE Sets):
スイートBは、これらの鍵確立（KE）のアルゴリズム（KEがセット）を使用しています。
KE Set 1 KE Set 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
The two elliptic curves used in Suite B are specified in [DSS], and each appear in the literature under two different names. For the sake of clarity, we list both names below:
スイートBで使用される2つの楕円曲線は、[DSS]で指定され、それぞれ2つの異なる名前で文献に表示されています。明確にするために、我々は、以下の両方の名前をリスト：
Curve NIST Name SECG Name OID [DSS]
---------------------------------------------------------
nistp256 P-256 secp256r1 1.2.840.10045.3.1.7
nistp384 P-384 secp384r1 1.3.132.0.34
If configured at a minimum level of security of 128 bits, a Suite B compliant S/MIME system performing encryption MUST use either KE Set 1 or KE Set 2, with KE Set 1 being the preferred suite. A digital signature, if applied, MUST use either Sig Set 1 or Sig Set 2, independent of the encryption choice.
128ビットのセキュリティの最小レベルに設定されている場合、暗号化を行うスイートB準拠S / MIMEシステムがKEセット1は、好ましいスイートされた状態で、KEセット1又はセットKE 2のいずれかを使用しなければなりません。デジタル署名は、適用された場合、暗号化の選択とは無関係に、シグセット1またはシグセット2のいずれかを使用しなければなりません。
A recipient in an S/MIME system configured at a minimum level of security of 128 bits MUST be able to verify digital signatures from Sig Set 1 and SHOULD be able to verify digital signatures from Sig Set 2.
128ビットのセキュリティの最小レベルで設定S / MIMEシステムにおける受信者は、Sigをセット1からのデジタル署名を検証できなければならないとSigをセット2からのデジタル署名を検証することができるべきです。
Note that for S/MIME systems configured at a minimum level of security of 128 bits, the algorithm set used for a signed-data content type is independent of the algorithm set used for an enveloped-data content type.
128ビットのセキュリティの最小レベルで設定S / MIMEシステム用なお、署名されたデータのコンテンツタイプに使用されるアルゴリズムのセットは、エンベロープデータ・コンテンツ・タイプに使用されるアルゴリズムのセットとは無関係です。
If configured at a minimum level of security of 192 bits, a Suite B compliant S/MIME system performing encryption MUST use KE Set 2. A digital signature, if applied, MUST use Sig Set 2.
192ビットのセキュリティの最小レベル、暗号化はKEセット2のデジタル署名を使用しなければなりません実行スイートB準拠S / MIMEシステムで構成した場合、適用された場合、Sigのセット2を使用しなければなりません。
A recipient in an S/MIME system configured at a minimum level of security of 192 bits MUST be able to verify digital signatures from Sig Set 2.
192ビットのセキュリティの最小レベルで設定S / MIMEシステムにおける受信者は、Sigをセット2からのデジタル署名を検証することができなければなりません。
SHA-256 and SHA-384 are the Suite B message digest algorithms. RFC 5754 [SHA2] specifies the conventions for using SHA-256 and SHA-384 with the Cryptographic Message Syntax (CMS). Suite B compliant S/MIME implementations MUST follow the conventions in RFC 5754. Relevant details are repeated below.
SHA-256およびSHA-384は、スイートBメッセージダイジェストアルゴリズムです。 RFC 5754 [SHA2]は、暗号メッセージ構文（CMS）とSHA-256およびSHA-384を使用するための規則を指定します。スイートB準拠したS / MIMEの実装は、関連する詳細は以下に繰り返されるRFC 5754.での規則に従わなければなりません。
Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field.
CMS署名されたデータのコンテンツタイプ内で、メッセージは、アルゴリズム識別子のSignedData digestAlgorithmsフィールドとのSignerInfo digestAlgorithmフィールドに配置されているダイジェスト。
The SHA-256 and SHA-384 message digest algorithms are defined in FIPS Pub 180-3 [SHA2FIPS]. The algorithm identifiers for SHA-256 and SHA-384 are defined in [SHA2] and are repeated here:
SHA-256およびSHA-384メッセージは、アルゴリズムは、FIPSパブ180-3 [SHA2FIPS]で定義されているダイジェスト。 SHA-256およびSHA-384アルゴリズム識別子は、[SHA2]で定義され、ここでは繰り返されます。
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 }
For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL, and if present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters. As specified in RFC 5754 [SHA2], implementations MUST generate SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters.
SHA-256およびSHA-384の両方について、AlgorithmIdentifierパラメタ分野は任意であり、存在する場合、パラメータフィールドはNULLを含まなければなりません。実装は存在しないパラメータを持つSHA-256およびSHA-384 AlgorithmIdentifiersを受け入れなければなりません。実装はNULLパラメータを持つSHA-256とSHA-384 AlgorithmIdentifiersを受け入れなければなりません。 RFC 5754 [SHA2]で指定されるように、実装は存在しないパラメータを持つSHA-256およびSHA-384 AlgorithmIdentifiersを生成しなければなりません。
In Suite B, public key certificates used to verify S/MIME signatures MUST be compliant with the Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT].
スイートBでは、S / MIME署名を検証するために使用される公開鍵証明書は、RFC 5759 [SUITEBCERT]で指定されたスイートB証明書プロファイルに準拠しなければなりません。
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the Suite B digital signature algorithm. RFC 5753 [CMSECC] specifies the conventions for using ECDSA with the Cryptographic Message Syntax (CMS). Suite B compliant S/MIME implementations MUST follow the conventions in RFC 5753. Relevant details are repeated below.
楕円曲線デジタル署名アルゴリズム（ECDSA）は、スイートBデジタル署名アルゴリズムです。 RFC 5753 [CMSECC]は、暗号メッセージ構文（CMS）とECDSAを使用するための規則を指定します。スイートB準拠したS / MIMEの実装は、関連する詳細は以下に繰り返されるRFC 5753.での規則に従わなければなりません。
Within the CMS signed-data content type, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
CMS署名されたデータのコンテンツタイプ内で、署名アルゴリズム識別子はSignedDataのののSignerInfoのsignatureAlgorithmフィールドに配置されています。また、署名アルゴリズム識別子は副署属性のSignerInfoのsignatureAlgorithmフィールドに配置されています。
RFC 5480 [PKI-ALG] defines the signature algorithm identifiers used in CMS for ECDSA with SHA-256 and ECDSA with SHA-384. The identifiers are repeated here:
RFC 5480 [PKI-ALG]はSHA-384とSHA-256およびECDSAとECDSAためにCMSで使用される署名アルゴリズムの識別子を定義します。識別子は、ここで繰り返されています。
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 }
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
ECDSA-WITH-SHA256またはECDSA-WITH-SHA384アルゴリズム識別子のいずれかが使用されるとき、AlgorithmIdentifierパラメタ分野は存在してはなりません。
When signing, the ECDSA algorithm generates two values, commonly called r and s. To transfer these two values as one signature, they MUST be encoded using the ECDSA-Sig-Value type specified in RFC 5480 [PKI-ALG]:
署名するとき、ECDSAアルゴリズムは一般にR及びSと呼ばれる2つの値を生成します。 1つのシグネチャとして、これら2つの値を転送するために、彼らは、RFC 5480で指定されたECDSA-SIG-value型[PKI-ALG]を使用して符号化されなければなりません。
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords. In Suite B for S/MIME, ephemeral-static key agreement MUST be used as described in Section 4.1.
鍵合意、キー輸送、以前に分配された左右対称キー暗号化キー、およびパスワード：CMSには、以下の一般的な鍵管理技術を収納します。セクション4.1で説明したようにS / MIMEのためのスイートBにおいては、エフェメラル静的鍵合意を使用しなければなりません。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. In Suite B for S/MIME, the Advanced Encryption Standard (AES) Key Wrap, as specified in RFC 3394 [SH] and [AESWRAP], MUST be used as the key-encryption algorithm. AES Key Wrap is discussed further in Section 4.2. The key-encryption key used with the AES Key Wrap algorithm is obtained from a key derivation function (KDF). In Suite B for S/MIME, there are two KDFs -- one based on SHA-256 and one based on SHA-384. These KDFs are discussed further in Section 4.3.
鍵合意アルゴリズムが使用されている場合は、鍵暗号化アルゴリズムも必要とされています。 S / MIME、高度暗号化標準（AES）キーラップのための組曲B、[SH] RFC 3394で指定し、[AESWRAP]、鍵暗号化アルゴリズムとして使用されなければならないようで。 AESキーラップは、4.2節で詳しく説明されています。 AESキーラップアルゴリズムで使用されるキー暗号化キーは、鍵導出関数（KDF）から取得されます。 SHA-256に基づくものとSHA-384に基づくもの - S / MIMEのためのスイートBにおいて、二つKDFsがあります。これらのKDFsは、4.3節で詳しく説明されています。
Elliptic Curve Diffie-Hellman (ECDH) is the Suite B key agreement algorithm.
楕円曲線のDiffie-Hellmanの（ECDH）は、スイートBキー合意アルゴリズムです。
S/MIME is used in store-and-forward communications, which means that ephemeral-static ECDH is always employed. This means that the message originator possesses an ephemeral ECDH key pair and that the message recipient possesses a static ECDH key pair whose public key is represented by an X.509 certificate. In Suite B, the certificate used to obtain the recipient's public key MUST be compliant with the Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT].
S / MIMEは、はかない静的ECDHが常に使用されることを意味し、ストアアンドフォワード通信に使用されます。これは、メッセージの発信者は、はかないECDH鍵ペアを有することと、メッセージの受信者は、その公開鍵X.509証明書によって表される静的ECDH鍵ペアを所有していることを意味します。スイートBでは、証明書は、受信者の公開鍵は、RFC 5759 [SUITEBCERT]で指定されたスイートB証明書プロファイルに準拠している必要があり得るために使用します。
Section 3.1 of RFC 5753 [CMSECC] specifies the conventions for using ECDH with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
RFC 5753 [CMSECC]のセクション3.1は、CMSでECDHを使用するための規則を指定します。スイートB準拠したS / MIME実装は、これらの規則に従わなければなりません。関連する詳細は、以下を繰り返します。
Within the CMS enveloped-data content type, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
CMS包まデータコンテンツタイプ内では、キー合意アルゴリズム識別子はEnvelopedDataののrecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールドに位置しています。
keyEncryptionAlgorithm MUST be one of the two algorithm identifiers listed below, and the algorithm identifier parameter field MUST be present and identify the key wrap algorithm. The key wrap algorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the ephemeral-static ECDH key agreement algorithm (see Section 4.3).
keyEncryptionAlgorithmは、以下にリストされている2つのアルゴリズムの識別子のいずれかである必要があり、およびアルゴリズム識別子パラメータフィールドが存在するとキーラップアルゴリズムを識別しなければなりません。キーラップアルゴリズムははかない、静的なECDH鍵協定アルゴリズムを使用して生成されたペアワイズキーと暗号化キーを使用して、コンテンツ暗号化キーを暗号化するために使用される対称暗号化アルゴリズムを表す（4.3節を参照してください）。
When implementing KE Set 1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2). When implementing KE Set 2, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes256-wrap.
KEセット1を実装する場合、keyEncryptionAlgorithmはdhSinglePass-stdDH-sha256kdf-方式でなければなりません、そしてkeyEncryptionAlgorithmパラメータはID-AES128ラップを含むKeyWrapAlgorithm（セクション4.2を参照）でなければなりません。 KEセット2を実装する場合、keyEncryptionAlgorithmはdhSinglePass-stdDH-sha384kdf-方式でなければなりません、そしてkeyEncryptionAlgorithmパラメータがKeyWrapAlgorithm含むID-AES256ラップしていなければなりません。
The algorithm identifiers for dhSinglePass-stdDH-sha256kdf-scheme and dhSinglePass-stdDH-sha384kdf-scheme, repeated from Section 7.1.4 of [CMSECC], are:
【CMSECC]のセクション7.1.4から繰り返さdhSinglePass-stdDH-sha256kdf-方式とdhSinglePass-stdDH-sha384kdf-方式、アルゴリズム識別子は、次のとおりです。
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
Both of these algorithm identifiers use KeyWrapAlgorithm as the type for their parameter:
これらのアルゴリズム識別子の両方が彼らのパラメータの型としてKeyWrapAlgorithmを使用します。
KeyWrapAlgorithm ::= AlgorithmIdentifier
The AES Key Wrap key-encryption algorithm, as specified in RFC 3394 [SH] and [AESWRAP], is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. Section 8 of RFC 5753 [CMSECC] specifies the conventions for using AES Key Wrap with the pairwise key generated with ephemeral-static ECDH with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
AESキーラップ鍵暗号化アルゴリズムは、RFC 3394 [SH]と[AESWRAP]で指定されるように、はかない静的ECDHを使用して生成されるペアワイズ鍵暗号鍵でコンテンツ暗号化キーを暗号化するために使用されます。 RFC 5753のセクション8 [CMSECC]は、CMSとのはかない静的ECDHで生成した鍵ペアとAESキーラップを使用するための規則を指定します。スイートB準拠したS / MIME実装は、これらの規則に従わなければなりません。関連する詳細は、以下を繰り返します。
When implementing KE Set 1, the KeyWrapAlgorithm MUST be id-aes128-wrap. When implementing KE Set 2, the KeyWrapAlgorithm MUST be id-aes256-wrap.
KEセット1を実装する場合、KeyWrapAlgorithmは、ID-AES128-ラップでなければなりません。 KEセット2を実装する場合、KeyWrapAlgorithmは、ID-AES256-ラップでなければなりません。
Within the CMS enveloped-data content type, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
CMS包まデータのコンテンツタイプの中で、キーラップアルゴリズム識別子はEnvelopedDataののrecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmフィールド内KeyWrapAlgorithmパラメータに位置しています。
The algorithm identifiers for AES Key Wrap are specified in RFC 3394 [SH], and the ones needed for Suite B compliant S/MIME implementations are repeated here:
AESキーラップのためのアルゴリズム識別子は、RFC 3394 [SH]で指定されている、とのものがここで繰り返されスイートB準拠したS / MIME実装のために必要：
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-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-encryption key from the shared secret produced by ephemeral-static ECDH. Sections 7.1.8 and 7.2 of RFC 5753 [CMSECC] specify the conventions for using the KDF with the shared secret generated with ephemeral-static ECDH with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
SHA-256とSHA-384に基づくKDFsははかない、静的なECDHによって生成共有秘密鍵ペアから暗号化キーを導出するために使用されています。セクション7.1.8およびRFC 5753の7.2には、[CMSECC] CMSとのはかない静的ECDHで生成された共有秘密とKDFを使用するための規則を指定します。スイートB準拠したS / MIME実装は、これらの規則に従わなければなりません。関連する詳細は、以下を繰り返します。
When implementing KE Set 1, the KDF based on SHA-256 MUST be used. When implementing KE Set 2, the KDF based on SHA-384 MUST be used.
KEセット1を実装する場合、SHA-256に基づくKDFを使用しなければなりません。 KEセット2を実装する場合、SHA-384に基づくKDFを使用しなければなりません。
As specified in Section 7.2 of RFC 5753 [CMSECC], using ECDH with the CMS enveloped-data content type, the derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo type, which is repeated here:
CMS包まデータコンテンツタイプにECDHを使用して、RFC 5753のセクション7.2 [CMSECC]で指定されているように、キー暗号化キーの導出ここでは繰り返されるECC-CMS-SharedInfoタイプ、を使用します：
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
In Suite B for S/MIME, the fields of ECC-CMS-SharedInfo are used as follows:
次のようにS / MIMEのための組曲Bでは、ECC-CMS-SharedInfoのフィールドが使用されます。
keyInfo contains the object identifier of the key-encryption algorithm used to wrap the content-encryption key. In Suite B for S/MIME, if the AES-128 Key Wrap is used, then the keyInfo will contain id-aes128-wrap, and the parameters will be absent. In Suite B for S/MIME, if AES-256 Key Wrap is used, then the keyInfo will contain id-aes256-wrap, and the parameters will be absent.
KeyInfoには、コンテンツ暗号化キーをラップするために使用されるキー暗号化アルゴリズムのオブジェクト識別子が含まれています。 AES-128キーラップを使用する場合はS / MIMEのためのスイートBに、次いでするKeyInfoは、ID-AES128ラップを含むであろうし、パラメータが存在しないであろう。 AES-256キーラップを使用する場合は、S / MIMEのための組曲Bでは、その後のKeyInfoは、ID-AES256-ラップが含まれます、そしてパラメータが存在しないことになります。
entityUInfo optionally contains a random value provided by the message originator. If the user keying material (ukm) is present, then the entityUInfo MUST be present, and it MUST contain the ukm value. If the ukm is not present, then the entityUInfo MUST be absent.
entityUInfoは、必要に応じてメッセージ発信元によって提供されるランダム値を含みます。ユーザ鍵材料（UKM）が存在する場合、entityUInfoが存在している必要があり、それはUKM値を含まなければなりません。 UKMが存在しない場合、entityUInfoは存在してはなりません。
suppPubInfo contains the length of the generated key-encryption key, in bits, represented as a 32-bit unsigned number, as described in RFC 2631 [CMSDH]. When a 128-bit AES key is used, the length MUST be 0x00000080. When a 256-bit AES key is used, the length MUST be 0x00000100.
suppPubInfoが生成された鍵暗号化鍵の長さを含むRFC 2631に記載されているように、ビットで、[CMSDH]、32ビットの符号なし数値として表さ。 128ビットAESキーを使用した場合、長さは0x00000080なければなりません。 256ビットAESキーを使用した場合、長さは0x00000100なければなりません。
ECC-CMS-SharedInfo is DER encoded and used as input to the key derivation function, as specified in Section 3.6.1 of [SEC1]. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in [CMSDH]. Here, a counter value is not included in the keyInfo field because the KDF specified in [SEC1] ensures that sufficient keying data is provided.
ECC-CMS-SharedInfoは、DER符号化され、[SEC1]のセクション3.6.1で指定されるように、鍵導出関数への入力として使用されます。 ECC-CMS-SharedInfoは[CMSDH]で指定OtherInfoは異なることに留意されたいです。 [SEC1]で指定KDFは十分鍵データが提供されることを確実にするため、ここでは、カウンタ値がキー情報フィールドに含まれていません。
The KDF specified in [SEC1] provides an algorithm for generating an essentially arbitrary amount of keying material (KM) from the shared secret produced by ephemeral-static ECDH, which is called Z for the remainder of this discussion. The KDF can be summarized as:
[SEC1]で指定KDFは、この説明の残りのZと呼ばれるエフェメラル静的ECDHによって製造共有秘密から鍵材料（KM）の本質的に任意の量を生成するためのアルゴリズムを提供します。 KDFは次のように要約することができます。
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
KM =ハッシュ（Z || ||カウンターECC-CMS-SharedInfo）
To generate a key-encryption key (KEK), one or more KM blocks are generated, incrementing Counter appropriately, until enough material has been generated. The KM blocks are concatenated left to right:
キー暗号化キー（KEK）を生成するには、一つ以上のKMブロックは十分な材料が生成されるまで、適切なカウンタをインクリメント、生成されます。 KMブロックは、左から右に連結されています。
KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
KEK = KM（カウンタ= 1）|| KM（カウンタ= 2）...
The elements of the KDF are used as follows:
次のようにKDFの要素が使用されます。
Hash is the one-way hash function. If KE Set 1 is used, the SHA-256 hash MUST be used. If KE Set 2 is used, the SHA-384 hash MUST be used.
ハッシュは一方向ハッシュ関数です。 KEセット1が使用されている場合は、SHA-256ハッシュを使用しなければなりません。 KEセット2を使用する場合は、SHA-384ハッシュを使用しなければなりません。
Z is the shared secret value generated by ephemeral-static ECDH. Leading zero bits MUST be preserved. In Suite B for S/MIME, if KE Set 1 is used, Z MUST be exactly 256 bits. In Suite B for S/MIME, if KE Set 2 is used, Z MUST be exactly 384 bits.
Zは、はかない静的ECDHによって生成された共有秘密値です。先行ゼロのビットが保存されなければなりません。 KEセット1が使用される場合、S / MIMEのためのスイートBにおいて、Zは、正確に256ビットでなければなりません。 KEセット2を使用する場合、S / MIMEのためのスイートBにおいて、Zは、正確に384ビットでなければなりません。
Counter is a 32-bit unsigned number, represented in network byte order. Its initial value MUST be 0x00000001 for any key derivation operation. In Suite B for S/MIME, with both KE Set 1 and KE Set 2, exactly one iteration is needed; the Counter is not incremented.
カウンタは、ネットワークバイト順で表され、32ビットの符号なし数です。その初期値は、任意のキー導出動作のためには0x00000001でなければなりません。 KEセット1及びKEセット2の両方とS / MIMEのためのスイートBでは、正確に一つの反復が必要です。カウンタがインクリメントされていません。
ECC-CMS-SharedInfo is composed as described above. It MUST be DER encoded.
ECC-CMS-SharedInfoは、上述のように構成されています。これは、DERエンコードする必要があります。
To generate a key-encryption key, one KM block is generated, with a Counter value of 0x00000001:
キー暗号化キーを生成するには、1 KMブロックは0x00000001にのカウンタ値と、生成されます。
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
KEK = KM（1）=ハッシュ（Z ||カウンタ= 1 || ECC-CMS-SharedInfo）
In Suite B for S/MIME, when KE Set 1 is used, the key-encryption key MUST be the most significant 128 bits of the SHA-256 output value. In Suite B for S/MIME, when KE Set 2 is used, the key-encryption key MUST be the most significant 256 bits of the SHA-384 output value.
S / MIMEのためのスイートBで、KEセット1を用いた場合、キー暗号化キーは、SHA-256の出力値の最上位128ビットでなければなりません。 S / MIMEのためのスイートBで、KEセット2を用いた場合、キー暗号化キーは、SHA-384の出力値の最上位256ビットでなければなりません。
Note that the only source of secret entropy in this computation is Z. The effective key space of the key-encryption key is limited by the size of Z, in addition to any security level considerations imposed by the elliptic curve that is used. However, if entityUInfo is different for each message, a different key-encryption key will be generated for each message.
この計算に秘密のエントロピーの唯一の供給源が使用される楕円曲線によって課される任意のセキュリティ・レベルの考慮事項に加えて、鍵暗号化鍵の有効鍵空間はZのサイズによって制限されるZ.であることに留意されたいです。 entityUInfoは、メッセージごとに異なっている場合は、異なるキー暗号化キーは、メッセージごとに生成されます。
AES [AES] in Cipher Block Chaining (CBC) mode [MODES] is the Suite B for S/MIME content-encryption algorithm. RFC 3565 [CMSAES] specifies the conventions for using AES with the CMS. Suite B compliant S/MIME implementations MUST follow these conventions. Relevant details are repeated below.
AESは[AES]暗号ブロック連鎖（CBC）モードで[MODES]はS / MIMEコンテンツ暗号化アルゴリズムのスイートBです。 RFC 3565 [CMSAES]は、CMSとAESを使用するための規則を指定します。スイートB準拠したS / MIME実装は、これらの規則に従わなければなりません。関連する詳細は、以下を繰り返します。
In Suite B for S/MIME, if KE Set 1 is used, AES-128 in CBC mode MUST be used for content encryption. In Suite B for S/MIME, if KE Set 2 is used, AES-256 in CBC mode MUST be used.
KEセット1が使用される場合、S / MIMEのためのスイートBにおいては、CBCモードでAES-128は、コンテンツの暗号化に使用されなければなりません。 KEセット2を使用する場合、S / MIMEのためのスイートBにおいては、CBCモードでAES-256を使用しなければなりません。
Within the CMS enveloped-data content type, content-encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content-encryption algorithm is used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field.
CMS包まデータコンテンツタイプ内では、コンテンツ暗号化アルゴリズム識別子はEnvelopedDataのEncryptedContentInfo contentEncryptionAlgorithmフィールドに位置しています。コンテンツの暗号化アルゴリズムはEnvelopedDataのEncryptedContentInfo暗号化コンテンツフィールドにあるコンテンツを暗号化するために使用されます。
The AES CBC content-encryption algorithm is described in [AES] and [MODES]. The algorithm identifier for AES-128 in CBC mode is:
AES CBCコンテンツ暗号化アルゴリズムは、[AES]と[機能]に記載されています。 CBCモードのAES-128のためのアルゴリズム識別子です。
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 }
The algorithm identifier for AES-256 in CBC mode is:
CBCモードのAES-256のためのアルゴリズム識別子は以下のとおりです。
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 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain AES-IV:
AlgorithmIdentifierパラメータフィールドが存在しなければならない、とパラメータフィールドは、AES-IVが含まれている必要があります。
AES-IV ::= OCTET STRING (SIZE(16))
The 16-octet initialization vector is generated at random by the originator. See [RANDOM] for guidance on generation of random values.
16オクテットの初期化ベクトルは、発信者によってランダムに生成されます。ランダム値の生成に関するガイダンスのために[RANDOM]を参照してください。
This document specifies the conventions for using the NSA's Suite B algorithms in S/MIME. All of the algorithms and algorithm identifiers have been specified in previous documents.
この文書では、S / MIMEでNSAのスイートBアルゴリズムを使用するための規則を指定します。アルゴリズムとアルゴリズム識別子のすべては、以前の文書で指定されています。
Two minimum levels of security may be achieved using this specification. Users must consider their risk environment to determine which level is appropriate for their own use.
セキュリティの二つの最小レベルは、この仕様を使用して達成することができます。ユーザーは、自分の使用に適しているどのレベルかを決定するために彼らのリスク環境を考慮する必要があります。
See [RANDOM] for guidance on generation of random values.
ランダム値の生成に関するガイダンスのために[RANDOM]を参照してください。
The security considerations in RFC 5652 [CMS] discuss the CMS as a method for digitally signing data and encrypting data.
RFC 5652のセキュリティ上の考慮事項[CMS]デジタルデータに署名し、データを暗号化するための方法として、CMSを議論します。
The security considerations in RFC 3370 [CMSALG] discuss cryptographic algorithm implementation concerns in the context of the CMS.
RFC 3370のセキュリティの考慮事項は、[CMSALG] CMSの文脈における暗号アルゴリズムの実装上の問題を議論します。
The security considerations in RFC 5753 [CMSECC] discuss the use of elliptic curve cryptography (ECC) in the CMS.
RFC 5753 [CMSECC]におけるセキュリティの考慮事項は、CMSでの楕円曲線暗号（ECC）の使用について説明します。
The security considerations in RFC 3565 [CMSAES] discuss the use of AES in the CMS.
RFC 3565 [CMSAES]におけるセキュリティの考慮事項は、CMSでのAESの使用を議論します。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AES]米国国立標準技術研究所、 "高度暗号化標準（AES）"、FIPS PUBの197、2001年11月。
[AESWRAP] National Institute of Standards and Technology, "AES Key Wrap Specification", November 2001.
[AESWRAP]米国国立標準技術研究所、「AESキーラップ仕様」、2001年11月。
[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
[DSS]米国国立標準技術研究所、 "デジタル署名標準（DSS）"、FIPS PUB 186-3の、2009年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、STD 70、RFC 5652、2009年9月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES] Schaad、J.、 "暗号メッセージ構文内のAdvanced Encryption Standard（AES）暗号化アルゴリズム（CMS）の使用"、RFC 3565、2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG] Housley氏、R.、 "暗号メッセージ構文（CMS）アルゴリズム"、RFC 3370、2002年8月。
[CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMSDH]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、RFC 2631、1999年6月。
[CMSECC] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.
[CMSECC]ターナー、S.およびD.ブラウン、RFC 5753、2010年1月 "暗号メッセージ構文における楕円曲線暗号（ECC）アルゴリズム（CMS）の使用"。
[MODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS Pub 81, December 1980.
[MODES]米国国立標準技術研究所、 "動作のDESモード" には、FIPSパブ81、1980 12月。
[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[MSG] Ramsdell、B.、およびS.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。
[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[PKI-ALG]ターナー、S.、ブラウン、D.、耀輝、K.、Housley氏、R.、およびT.ポーク、 "楕円曲線暗号件名公開鍵情報"、RFC 5480、2009年3月。
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", September 2000. <http://www.secg.org/collateral/sec1_final.pdf>.
[SEC1]効率的な暗号化グループ、 "SEC 1：楕円曲線暗号" の基準、2000年9月<http://www.secg.org/collateral/sec1_final.pdf>。
[SH] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SH] Schaad、J.とR. Housley氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、RFC 3394、2002年9月。
[SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[SHA2]ターナー、S.、RFC 5754 "暗号メッセージ構文とSHA2アルゴリズムを使用する"、2010年1月。
[SHA2FIPS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS 180-3, October 2008.
[SHA2FIPS]アメリカ国立標準技術研究所は、 "ハッシュ規格（SHS）を確保"、2008年10月、180-3をFIPS。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SUITEBCERT] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[SUITEBCERT] Solinas、J.とL.チーグラー、 "スイートB証明書と証明書失効リスト（CRL）プロフィール"、RFC 5759、2010年1月。
[SUITEBSMIME] Housley, R. and J. Solinas, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", RFC 5008, September 2007.
[SUITEBSMIME] Housley氏、R.とJ. Solinas、 "/セキュア多目的インターネットメール拡張でスイートB（S / MIME）"、RFC 5008、2007年9月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
【X.208-88] CCITT。勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
【X.209-88] CCITT。勧告X. 209：抽象構文記法1（ASN.1）のための基本的な符号化規則の仕様。 1988。
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
【X.509-88] CCITT。勧告X.509：ディレクトリ - 認証フレームワーク。 1988。
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためにランダム要件"、BCP 106、RFC 4086、2005年6月。
[NSA] U.S. National Security Agency, "Fact Sheet NSA Suite B Cryptography", January 2009. <http://www.nsa.gov/ia/programs/suiteb_cryptography>.
[NSA]米国国家安全保障局、 "ファクトシートNSAスイートB暗号化"、2009年1月<http://www.nsa.gov/ia/programs/suiteb_cryptography>。
Authors' Addresses
著者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Jerome A. Solinas National Information Assurance Laboratory National Security Agency 9800 Savage Road Fort George G. Meade, MD 20755 USA
ジェロームA. Solinas国立情報保証研究所国家安全保障局（NSA）9800サベージロードフォートジョージG.ミード、MD 20755 USA
EMail: jasolin@orion.ncsc.mil
メールアドレス：jasolin@orion.ncsc.mil