Network Working Group R. Housley
Request for Comments: 5008 Vigil Security
Category: Informational J. Solinas
NSA
September 2007
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
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 3851.
この文書は、RFC 3851に指定されている/セキュア多目的インターネットメール拡張（S / MIME）に米国国家安全保障局（NSA）のスイートBアルゴリズムを使用するための規則を指定します。
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms [SuiteB] 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.
この文書は、多目的インターネットメール拡張（S / MIME）[MSG]は/セキュアで[SuiteB]米国国家安全保障局（NSA）のスイートBアルゴリズムを使用するための規則を指定します。 S / MIMEは、暗号メッセージ構文（CMS）[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, and the relevant details are repeated to aid developers that choose to support Suite B. In a few cases, additional algorithm identifiers are needed, and they are provided in this document.
スイートBアルゴリズムの多くは、他の環境での使用を楽しむので、スイートBアルゴリズムのために必要な規則の大半は、すでに他の文書で指定されています。この文書では、これらの規則のソースを参照して、関連する詳細情報は、いくつかのケースでは、追加のアルゴリズム識別子が必要とされているスイートBをサポートすることを選択した開発者を支援するために繰り返され、そしてそれらは、この文書で提供されています。
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 security levels: Level 1 and Level 2. Security Level 2 offers greater cryptographic strength by using longer keys.
スイートBは、2つのセキュリティレベルを提供しています：レベル1とレベル2セキュリティレベル2は、長いキーを使用することによって、より暗号の強度を提供しています。
For S/MIME signed messages, Suite B follows the direction set by RFC 3278 [CMSECC], but some additional algorithm identifiers are assigned. Suite B uses these algorithms:
S / MIMEメッセージに署名したため、スイートBは[CMSECC] RFC 3278によって設定された方向に従うが、いくつかの追加のアルゴリズム識別子が割り当てられます。スイートBは、これらのアルゴリズムを使用しています。
Security Level 1 Security Level 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 3278 [CMSECC] and follows the conventions set by RFC 3565 [CMSAES]. Again, additional algorithm identifiers are assigned. Suite B uses these algorithms:
S / MIME暗号化メッセージのために、スイートBは[CMSECC] RFC 3278によって設定された方向に続き、RFC 3565 [CMSAES]によって設定された規則に従います。ここでも、追加のアルゴリズム識別子が割り当てられます。スイートBは、これらのアルゴリズムを使用しています。
Security Level 1 Security Level 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
This section specifies the conventions employed by implementations that support SHA-256 or SHA-384 [SHA2]. In Suite B, Security Level 1, the SHA-256 message digest algorithm MUST be used. In Suite B, Security Level 2, SHA-384 MUST be used.
このセクションでは、SHA-256やSHA-384 [SHA2]をサポートする実装によって使用される規則を指定します。スイートB、セキュリティレベル1では、SHA-256のメッセージは、アルゴリズムが使用されなければならないダイジェスト。スイートB、セキュリティレベル2では、SHA-384を使用しなければなりません。
Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field. Also, message digest values are located in the Message Digest authenticated attribute. In addition, message digest values are input into signature algorithms.
CMS署名されたデータのコンテンツタイプ内で、メッセージは、アルゴリズム識別子のSignedData digestAlgorithmsフィールドとのSignerInfo digestAlgorithmフィールドに配置されているダイジェスト。また、メッセージダイジェスト値は、メッセージダイジェスト認証された属性に位置しています。また、メッセージダイジェスト値が署名アルゴリズムに入力されます。
The SHA-256 and SHA-384 message digest algorithms are defined in FIPS Pub 180-2 [SHA2, EH]. The algorithm identifier for SHA-256 is:
SHA-256およびSHA-384メッセージは、アルゴリズムは、FIPSパブ180-2 [SHA2、EH]で定義されているダイジェスト。 SHA-256アルゴリズムの識別子です。
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
The algorithm identifier for SHA-384 is:
SHA-384アルゴリズムの識別子です。
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
There are two possible encodings for the AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later, the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding for the SHA-256 and SHA-384 message digest algorithms is to omit the parameters field; however, to ensure compatibility, implementations ought to also handle a SHA-256 and SHA-384 AlgorithmIdentifier parameters field, which contains a NULL.
AlgorithmIdentifierパラメータフィールドのための2つの可能なエンコーディングがあります。 2つの選択肢がいるAlgorithmIdentifierのための1988年の構文が1997年の構文に翻訳されたとき、のAlgorithmIdentifierパラメータに関連付けられたオプションが失われてしまったという事実から生じます。その後、オプションは、不具合報告を経て回収されたが、その後で、多くの人々は、アルゴリズムパラメータが必須だと考えました。このため歴史のいくつかの実装は、NULL要素などのパラメータをエンコードし、他の人がそれらを完全に省略します。ダイジェストアルゴリズムSHA-256およびSHA-384メッセージの正しい符号は、パラメータフィールドを省略することです。しかし、互換性を確保するために、実装はまた、NULLを含んSHA-256およびSHA-384のAlgorithmIdentifierパラメータフィールドを処理するべきです。
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. Implementations SHOULD 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を受け入れなければなりません。実装は存在しないパラメータを持つSHA-256およびSHA-384 AlgorithmIdentifiersを生成する必要があります。
This section specifies the conventions employed by implementations that support Elliptic Curve Digital Signature Algorithm (ECDSA). The direction set by RFC 3278 [CMSECC] is followed, but additional message digest algorithms and additional elliptic curves are employed. In Suite B, Security Level 1, ECDSA MUST be used with the SHA-256 message digest algorithm and the P-256 elliptic curve. In Suite B, Security Level 2, ECDSA MUST be used with the SHA-384 message digest algorithm and the P-384 elliptic curve. The P-256 and P-384 elliptic curves are specified in [DSS].
このセクションでは、楕円曲線デジタル署名アルゴリズム（ECDSA）をサポートする実装によって用いられる規則を指定します。 RFC 3278によって設定された方向が[CMSECC]続いているが、追加のメッセージダイジェストアルゴリズムと追加の楕円曲線が用いられます。スイートB、セキュリティレベル1において、ECDSAアルゴリズムおよびP-256楕円曲線を消化SHA-256メッセージで使用されなければなりません。スイートB、セキュリティレベル2では、ECDSAアルゴリズムおよびP-384楕円曲線を消化SHA-384メッセージで使用されなければなりません。 P-256およびP-384楕円曲線は[DSS]で指定されています。
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フィールドに配置されています。
Within the CMS signed-data content type, signature values are located in the SignerInfo signature field of SignedData. In addition, signature values are located in the SignerInfo signature field of countersignature attributes.
CMS署名されたデータのコンテンツタイプ内で、署名値は、のSignedDataののSignerInfo署名フィールドに配置されます。また、署名値は副署属性のSignerInfoの署名フィールドに配置されます。
As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve Diffie-Hellman (ECDH) use the same algorithm identifier for subject public keys in certificates, and it is repeated here:
RFC 3279で指定されたようにPKIX1ALG]、ECDSAと楕円曲線ディフィ - ヘルマン（ECDH）は、証明書内のサブジェクトの公開鍵に対して同じアルゴリズム識別子を使用し、それはここで繰り返されます。
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) keyType(2) 1 }
This object identifier is used in public key certificates for both ECDSA signature keys and ECDH encryption keys. The intended application for the key may be indicated in the key usage field (see RFC 3280 [PKIX1]). The use of separate keys for signature and encryption purposes is RECOMMENDED; however, the use of a single key for both signature and encryption purposes is not forbidden.
このオブジェクト識別子は、ECDSA署名鍵とECDHの暗号化キーの両方のための公開鍵証明書に使用されています。鍵の意図された用途は、鍵使用フィールド（RFC 3280 [PKIX1]を参照のこと）で示すことができます。署名と暗号化の目的のための別個の鍵の使用が推奨されます。しかし、署名と暗号化の両方の目的のために単一のキーを使用することは禁止されていません。
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same encoding for subject public keys in certificates, and it is repeated here:
[PKIX1ALG] RFC 3279で規定されているように、ECDSAとECDHは、証明書で対象の公開鍵のために同じエンコーディングを使用し、それはここでは繰り返されます。
ECPoint ::= OCTET STRING
The elliptic curve public key (an OCTET STRING) is mapped to a subject public key (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curves according to this specification MUST support the uncompressed form and MAY support the compressed form.
オクテット文字列の最上位ビットはビット列の最上位ビットとなり、の最下位ビット以下のように楕円曲線公開鍵（オクテット列）サブジェクトの公開鍵（ビット列）にマップされオクテット文字列は、ビット列の最下位ビットになります。このオクテットストリングは、圧縮または非圧縮形態における楕円曲線点を表してもよいことに留意されたいです。本明細書に記載の楕円曲線をサポートする実装は、非圧縮形式をサポートしなければならないし、圧縮された形式をサポートするかもしれません。
ECDSA and ECDH require use of certain parameters with the public key. The parameters may be inherited from the certificate issuer, implicitly included through reference to a named curve, or explicitly included in the certificate. As specified in RFC 3279 [PKIX1ALG], the parameter structure is:
ECDSAとECDHは、公開鍵を使用して特定のパラメータを使用する必要があります。パラメータは、証明書発行者から継承された暗黙的命名曲線を参照することにより含まれる、または明示的に証明書に含まれていてもよいです。 【PKIX1ALG] RFC 3279で指定されるように、パラメータ構造は以下の通りであります：
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
In Suite B, the namedCurve CHOICE MUST be used. The object identifier for P-256 is:
スイートBでは、namedCurve CHOICEを使用しなければなりません。 P-256のためのオブジェクト識別子です。
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) curves(3) prime(1) 7 }
The object identifier for P-384 is:
P-384のためのオブジェクト識別子です。
secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 }
The algorithm identifier used in CMS for ECDSA with SHA-256 signature values is:
SHA-256の署名値と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 }
The algorithm identifier used in CMS for ECDSA with SHA-384 signature values is:
SHA-384の署名値とECDSAためにCMSで使用されるアルゴリズム識別子です。
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 3279 [PKIX1ALG]:
署名するとき、ECDSAアルゴリズムは一般にR及びSと呼ばれる2つの値を生成します。 ：1つのシグネチャとして、これら2つの値を転送するために、彼らは[PKIX1ALG] RFC 3279に指定されたECDSA-SIG-value型を用いて符号化されなければなりません
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, ephemeral-static key agreement MUST be used as described in Section 4.1.
鍵合意、キー輸送、以前に分配された左右対称キー暗号化キー、およびパスワード：CMSには、以下の一般的な鍵管理技術を収納します。セクション4.1で説明したようにスイートBにおいては、エフェメラル静的鍵合意を使用しなければなりません。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. In Suite B, the Advanced Encryption Standard (AES) Key Wrap, as specified in RFC 3394 [AESWRAP, SH], 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
鍵合意アルゴリズムが使用されている場合は、鍵暗号化アルゴリズムも必要とされています。スイートB、のAdvanced Encryption Standard（AES）キーラップでは、[AESWRAP、SH] RFC 3394で指定されているように、キー暗号化アルゴリズムとして使用しなければなりません。 AESキーラップは、4.2節で詳しく説明されています。 AESキーラップで使用されるキー暗号化キー
algorithm is obtained from a key derivation function (KDF). In Suite B, there are two KDFs, one based on SHA-256 and one based on SHA-384. These KDFs are discussed further in Section 4.3.
アルゴリズムは、鍵導出関数（KDF）から得られます。スイートBにおいて、二つKDFs、SHA-256に基づくものとSHA-384に基づくものがあります。これらのKDFsは、4.3節で詳しく説明されています。
This section specifies the conventions employed by implementations that support ECDH. The direction set by RFC 3278 [CMSECC] is followed, but additional key derivation functions and key wrap algorithms are employed. S/MIME is used in store-and-forward communications, which means that ephemeral-static ECDH is always employed. This means that the message originator uses an ephemeral ECDH key and that the message recipient uses a static ECDH key, which is obtained from an X.509 certificate. In Suite B, Security Level 1, ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 Key Wrap, and the P-256 elliptic curve. In Suite B, Security Level 2, ephemeral-static ECDH MUST be used with the SHA-384 KDF, AES-256 Key Wrap, and the P-384 elliptic curve.
このセクションでは、ECDHをサポートする実装によって使われたコンベンションを指定します。 RFC 3278 [CMSECC]によって設定された方向に続いているが、追加の鍵導出機能とキーラップアルゴリズムが採用されています。 S / MIMEは、はかない静的ECDHが常に使用されることを意味し、ストアアンドフォワード通信に使用されます。これは、メッセージの発信者がはかないECDH鍵を使用してメッセージの受信者がX.509証明書から取得された静的ECDH鍵を使用することを意味します。スイートB、セキュリティレベル1において、はかない静的ECDHは、SHA-256 KDF、AES-128キーラップ、およびP-256楕円曲線を使用する必要があります。スイートB、セキュリティレベル2では、はかない静的ECDHは、SHA-384 KDF、AES-256キーラップ、およびP-384楕円曲線を使用する必要があります。
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フィールドに位置しています。
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same conventions for carrying a subject public key in a certificate. These conventions are discussed in Section 3.
【PKIX1ALG] RFC 3279で指定されるように、ECDSAとECDHは、証明書のサブジェクトの公開鍵を運ぶために同じ規則を使用します。これらの規則は、第3節で議論されています。
Ephemeral-static ECDH key agreement is defined in [SEC1] and [IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData RecipientInfos keyAgreeRecipientInfo field is used as follows:
エフェメラル静的ECDH鍵協定は[SEC1]と[IEEE1363]で定義されています。エフェメラル静的ECDHを使用する場合、以下のように、EnvelopedDataののrecipientInfos keyAgreeRecipientInfoフィールドが使用されています。
version MUST be 3.
バージョンは3でなければなりません。
originator MUST be the originatorKey alternative. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 3) with NULL parameters. The originatorKey publicKey field MUST contain the message originator's ephemeral public key, which is a DER-encoded ECPoint (see Section 3). The ECPoint SHOULD be represented in uncompressed form.
発信者はoriginatorKeyの選択肢でなければなりません。 originatorKeyアルゴリズムフィールドは、NULLパラメータで（セクション3を参照）ID-ecPublicKeyオブジェクト識別子を含まなければなりません。 originatorKey公開フィールドは、DERでエンコードされたECPoint（セクション3を参照）で、メッセージ発信者のはかない公開鍵を、含まなければなりません。 ECPointは非圧縮形式で表現されるべきです。
ukm can be present or absent. However, message originators SHOULD include the ukm. As specified in RFC 3852 [CMS], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. When present, the ukm is used to ensure that a different key-encryption key is generated, even when the ephemeral private key is improperly used more than once. See [RANDOM] for guidance on generation of random values.
UKMは存在するか又は不在であることができます。しかし、メッセージの発信者は、UKMを含むべきです。 [CMS] RFC 3852で指定されるように、実装はUKMメッセージ受信者の処理をサポートしなければならないので、UKMが存在するか存在しない場合の相互運用性が問題ではありません。存在する場合、UKMははかない秘密鍵が不正に複数回使用した場合であっても、異なるキー暗号化キーが生成されることを確実にするために使用されます。ランダム値の生成に関するガイダンスのために[RANDOM]を参照してください。
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). In Suite B, Security Level 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). In Suite B, Security Level 2, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes256-wrap (see Section 4.2). The algorithm identifier for dhSinglePass-stdDH-sha256kdf-scheme and dhSinglePass-stdDH-sha384kdf-scheme are:
keyEncryptionAlgorithmは、以下にリストされている2つのアルゴリズムの識別子のいずれかである必要があり、およびアルゴリズム識別子パラメータフィールドが存在するとキーラップアルゴリズムを識別しなければなりません。キーラップアルゴリズムははかない、静的なECDH鍵協定アルゴリズムを使用して生成されたペアワイズキーと暗号化キーを使用して、コンテンツ暗号化キーを暗号化するために使用される対称暗号化アルゴリズムを表す（4.3節を参照してください）。スイートB、セキュリティレベル1において、keyEncryptionAlgorithmはdhSinglePass-stdDH-sha256kdf-方式でなければなりません、そしてkeyEncryptionAlgorithmパラメータはID-AES128ラップを含むKeyWrapAlgorithm（セクション4.2を参照）でなければなりません。スイートB、セキュリティレベル2では、keyEncryptionAlgorithmはdhSinglePass-stdDH-sha384kdf-方式でなければなりません、そしてkeyEncryptionAlgorithmパラメータはID-AES256ラップを含むKeyWrapAlgorithm（セクション4.2を参照）でなければなりません。 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
recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the ephemeral-static, ECDH-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm (see Section 4.3).
recipientEncryptedKeysは、識別子と受信者ごとに暗号化キーが含まれています。 RecipientEncryptedKey KeyAgreeRecipientIdentifierを含まなければならないのいずれかissuerAndSerialNumberは、受信者の証明書または受信者の証明書のサブジェクトキー識別子を含むRecipientKeyIdentifierを識別する。どちらの場合も、受信者の証明書は、受信者の静的なECDH公開鍵が含まれています。 RecipientEncryptedKey EncryptedKeyにはKeyWrapAlgorithmで指定されたアルゴリズムを使用して、はかない静的、ECDH、生成されたペアワイズキー暗号化キーで暗号化されたコンテンツ暗号化キーを含まなければならない（4.3節を参照してください）。
CMS offers support for symmetric key-encryption key management; however, it is not used in Suite B. Rather, the AES Key Wrap key-encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. In Suite B, Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption algorithm. In Suite B, Security Level 2, AES-256 Key Wrap MUST be used as the key-encryption algorithm.
CMSは、対称鍵暗号鍵管理のためのサポートを提供しています。それはスイートB.むしろ、AESキーラップキー暗号化アルゴリズムで使用されていないが、[AESWRAP、SH] RFC 3394で指定されているように、ある鍵ペア暗号化キーと、コンテンツ暗号化キーを暗号化するために使用されますはかない静的ECDHを使用して生成されました。スイートB、セキュリティレベル1では、AES-128キーラップは、キー暗号化アルゴリズムとして使用しなければなりません。スイートB、セキュリティレベル2では、AES-256キーラップは、キー暗号化アルゴリズムとして使用しなければなりません。
Within the CMS enveloped-data content type, wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, and key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
CMS包まデータのコンテンツタイプの中で、包まれたコンテンツの暗号化キーはEnvelopedDataののrecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys EncryptedKeyにフィールドに配置され、キーラップアルゴリズム識別子は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 are repeated here:
AESキーラップのためのアルゴリズム識別子は、RFC 3394 [SH]で指定されており、スイートBのために必要なものは、ここでは繰り返されています。
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 }
CMS offers support for deriving symmetric key-encryption keys from passwords; however, password-based key management is not used in Suite B. Rather, 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. In Suite B, Security Level 1, the KDF based on SHA-256 MUST be used. In Suite B, Security Level 2, KDF based on SHA-384 MUST be used.
CMSは、パスワードから、対称キー暗号化キーを導出するためのサポートを提供しています。ただし、パスワードベースのキー管理がスイートB.むしろで使用されていない、SHA-256とSHA-384に基づくKDFsははかない、静的なECDHによって生成共有秘密鍵ペアから暗号化キーを導出するために使用されています。スイートB、セキュリティレベル1では、SHA-256に基づくKDFを使用しなければなりません。スイートB、セキュリティレベル2では、SHA-384に基づくKDFを使用しなければなりません。
As specified in Section 8.2 of RFC 3278 [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 3278のセクション8.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, the fields of ECC-CMS-SharedInfo are used as follows:
次のようにスイートBでは、ECC-CMS-SharedInfoのフィールドが使用されます。
keyInfo contains the object identifier of the key-encryption algorithm that will be used to wrap the content-encryption key and NULL parameters. In Suite B, Security Level 1, AES-128 Key Wrap MUST be used, resulting in {id-aes128-wrap, NULL}. In Suite B, Security Level 2, AES-256 Key Wrap MUST be used, resulting in {id-aes256-wrap, NULL}.
KeyInfoには、コンテンツ暗号化キーやNULLパラメータをラップするために使用されるキー暗号化アルゴリズムのオブジェクト識別子が含まれています。スイートB、セキュリティレベル1では、AES-128キーラップは、{ID-AES128ラップ、NULL}で得られ、使用されなければなりません。スイートB、セキュリティレベル2では、AES-256キーラップは、{ID-AES256ラップ、NULL}で得られ、使用されなければなりません。
entityUInfo optionally contains a random value provided by the message originator. If the 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]. In Suite B, Security Level 1, a 128-bit AES key MUST be used, resulting in 0x00000080. In Suite B, Security Level 2, a 256-bit AES key MUST be used, resulting in 0x00000100.
suppPubInfoが生成された鍵暗号化鍵の長さを含むRFC 2631に記載されているように、ビットで、[CMSDH]、32ビットの符号なし数値として表さ。スイートB、セキュリティレベル1において、128ビットのAES鍵は0x00000080で、その結果、使用しなければなりません。スイートB、セキュリティレベル2では、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は[SEC1]のセクション3.6.1で指定されるように、DERエンコードおよび鍵導出関数への入力として使用されます。 ECC-CMS-SharedInfoは[CMSDH]で指定OtherInfoは異なることに留意されたいです。 [SEC1]で指定KDFは十分鍵データが提供されることを確実にするため、ここでは、カウンタ値がキー情報フィールドに含まれていません。
The KDF specified in [SEC1] provides an algorithm for generating an essentially arbitrary amount of keying material 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によって製造共有秘密からの鍵材料の本質的に任意の量を生成するためのアルゴリズムを提供します。 KDFは次のように要約することができます。
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
KM =ハッシュ（Z || ||カウンターECC-CMS-SharedInfo）
To generate a key-encryption key, one or more KM blocks are generated, incrementing Counter appropriately, until enough material has been generated. The KM blocks are concatenated left to right:
キー暗号化キーを生成するには、一つ以上の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, and it is either SHA-256 or SHA-384 [SHA2]. In Suite B, Security Level 1, the SHA-256 MUST be used. In Suite B, Security Level 2, SHA-384 MUST be used.
ハッシュは一方向ハッシュ関数であり、それはSHA-256やSHA-384 [SHA2]のいずれかです。スイートB、セキュリティレベル1では、SHA-256を使用しなければなりません。スイートB、セキュリティレベル2では、SHA-384を使用しなければなりません。
Z is the shared secret value generated by ephemeral-static ECDH. Leading zero bits MUST be preserved. In Suite B, Security Level 1, Z MUST be exactly 256 bits. In Suite B, Security Level 2, Z MUST be exactly 384 bits.
Zは、はかない静的ECDHによって生成された共有秘密値です。先行ゼロのビットが保存されなければなりません。スイートB、セキュリティレベル1では、Zは、正確に256ビットでなければなりません。スイートB、セキュリティレベル2では、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, Security Level 1 and Security Level 2, exactly one iteration is needed; the Counter is not incremented.
カウンタは、ネットワークバイト順で表され、32ビットの符号なし数です。その初期値は、任意のキー導出動作のためには0x00000001でなければなりません。スイートB、セキュリティレベル1及びセキュリティレベル2では、厳密に一回の反復が必要とされています。カウンタがインクリメントされていません。
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, Security Level 1, the key-encryption key MUST be the most significant 128 bits of the SHA-256 output value. In Suite B, Security Level 2, the key-encryption key MUST be the most significant 256 bits of the SHA-384 output value.
スイートB、セキュリティレベル1では、キー暗号化キーは、SHA-256の出力値の最上位128ビットでなければなりません。スイートB、セキュリティレベル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は、メッセージごとに異なっている場合は、異なるキー暗号化キーは、メッセージごとに生成されます。
This section specifies the conventions employed by implementations that support content encryption using AES [AES] in Cipher Block Chaining (CBC) mode [MODES]. The conventions in RFC 3565 [CMSAES] are followed. In Suite B, Security Level 1, the AES-128 in CBC mode MUST be used for content encryption. In Suite B, Security Level 2, AES-256 in CBC mode MUST be used.
このセクションでは、AES [AES]暗号ブロック連鎖（CBC）モード[MODES]を使用してコンテンツの暗号化をサポートする実装によって使用される規則を指定します。 RFC 3565 [CMSAES]内の規則に従います。スイートB、セキュリティレベル1では、CBCモードのAES-128は、コンテンツの暗号化に使用しなければなりません。スイートB、セキュリティレベル2では、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 have been specified in previous documents, although a few new algorithm identifiers have been assigned.
この文書では、S / MIMEでNSAのスイートBアルゴリズムを使用するための規則を指定します。いくつかの新しいアルゴリズム識別子が割り当てられているが、すべてのアルゴリズムは、以前の文書で指定されています。
Two 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.
2つのレベルのセキュリティは、この仕様を使用して達成することができます。ユーザーは、自分の使用に適しているどのレベルかを決定するために彼らのリスク環境を考慮する必要があります。
For signed and encrypted messages, Suite B provides a consistent level of security for confidentiality and integrity of the message content.
署名および暗号化されたメッセージの場合は、スイートBは、メッセージ内容の機密性と整合性のためのセキュリティの一貫性のレベルを提供します。
The security considerations in RFC 3852 [CMS] discuss the CMS as a method for digitally signing data and encrypting data.
RFC 3852のセキュリティ上の考慮事項[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 3278 [CMSECC] discuss the use of elliptic curve cryptography (ECC) in the CMS.
RFC 3278 [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", 17 November 2001. [See http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
[AESWRAP]米国国立標準技術研究所、「AESキーラップ仕様」、11月17日、2001年には、[http://csrc.nist.gov/encryption/kms/key-wrap.pdfを参照してください]
[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-2, January 2000.
[DSS]米国国立標準技術研究所、 "デジタル署名標準（DSS）"、FIPS PUB 186-2の、2000年1月。
[ECDSA] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62-1998, 1999.
[ECDSA]米国規格協会、「金融サービス業界のための公開鍵暗号：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62-1998、1999。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[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] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 3278, April 2002.
[CMSECC]ブレイク・ウィルソン、S.、ブラウン、D.、およびP.ランバート、RFC 3278、2002年4月 "暗号メッセージ構文における楕円曲線暗号（ECC）アルゴリズム（CMS）の使用"。
[IEEE1363] Institute of Electrical and Electronics Engineers, "Standard Specifications for Public Key Cryptography", IEEE Std 1363, 2000.
[IEEE1363]電気電子技術者協会、「公開鍵暗号のための標準仕様」、IEEE STD 1363、2000。
[MODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS Pub 81, 2 December 1980.
[MODES]アメリカ国立標準技術研究所、 "動作のDESモード"、81パブFIPS、1980年12月2日。
[MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX1] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[PKIX1ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[PKIX1ALG]、RFC 3279 Bassham、L.、ポーク、W.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"、2002年4月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", 2000. [See http://www.secg.org/ collateral/sec1.pdf.]
[SEC1]規格は、効率的な暗号化グループのために、「楕円曲線暗号」、2000年には、[担保/ sec1.pdfをhttp://www.secg.org/参照してください。]
[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] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, 1 August 2002.
標準技術[SHA2]国立研究所、FIPS 180-2、2002年8月1日 "ハッシュ標準セキュア"。
[STDWORDS] S. Bradner, "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月。
[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。
[EH] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[EH]イーストレーク第3、D.とT.ハンセン、 "米国のセキュアハッシュアルゴリズム（SHAとHMAC-SHA）"、RFC 4634、2006年7月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[SuiteB] National Security Agency, "Fact Sheet NSA Suite B Cryptography", July 2005. [See http://www.nsa.gov/ia/ industry/crypto_Suite_b.cfm?MenuID=10.2.7)
[SuiteB]国家安全保障局（NSA）、 "ファクトシートNSAスイートB暗号化"、2005年7月[参照http://www.nsa.gov/ia/業界/ crypto_Suite_b.cfm？menuID属性= 10.2.7）
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。