RFC5008 日本語訳
5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME).R. Housley, J. Solinas. September 2007. (Format: TXT=32869 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 5008 Vigil Security
Category: Informational J. Solinas
NSA
September 2007
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5008年の不寝番セキュリティカテゴリ: 情報のJ.Solinas NSA2007年9月
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
安全な/マルチパーパスインターネットメールエクステンションにおけるスイートB(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.
このドキュメントはRFC3851の指定されるとしてのSecure/マルチパーパスインターネットメールエクステンション(S/MIME)に合衆国国家安全保障局のSuite Bアルゴリズムを使用するのにコンベンションを指定します。
1. Introduction
1. 序論
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.
このドキュメントはSecure/マルチパーパスインターネットメールエクステンション(S/MIME)[MSG]に合衆国国家安全保障局のSuite Bアルゴリズム[SuiteB]を使用するのにコンベンションを指定します。 S/MIMEはCryptographic Message Syntax(CMS)[CMS]を利用します。 署名しているデータとおおわれたデータcontent typeは特に、使用されています。
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.
Suite Bアルゴリズムの多くがまた、他の環境における用途を楽しむので、Suite Bアルゴリズムに必要であるコンベンションの大部分が他のドキュメントで既に指定されます。 このドキュメントはこれらのコンベンションの源に参照をつけます、そして、Suite B.Inにいくつかのケースを支えるのを選ぶ開発者を支援するために関連詳細を繰り返します、そして、追加アルゴリズム識別子を必要とします、そして、本書ではそれらを提供します。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[STDWORDS]で説明されるように本書では解釈されることであるべきですか?
Housley & Solinas Informational [Page 1] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[1ページ]のRFC5008スイートB
1.2. ASN.1
1.2. ASN.1
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値はASN.1[X.208-88]を使用して、Basic Encoding Rules(BER)[X.209-88]と、Distinguished Encoding Rules(DER)[X.509-88]であると生成されます。
1.3. Suite B Security Levels
1.3. スイートBセキュリティー・レベル
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を平らにしてください。 Level2が、より長いキーを使用することによって、より大きい暗号の強さを提供するセキュリティ。
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のために、RFC3278[CMSECC]をSuite Bは方向セットに続けますが、いくつかの追加アルゴリズム識別子が割り当てられます。 スイートBはこれらのアルゴリズムを使用します:
Security Level 1 Security Level 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
セキュリティー・レベル1 セキュリティー・レベル2---------------- ---------------- メッセージダイジェスト: SHA-256 SHA-384署名: P-384とP-256 ECDSAとECDSA
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:
MIME S/暗号化メッセージに関しては、Suite BはRFC3278[CMSECC]を方向セットに続けて、RFC3565[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
セキュリティー・レベル1 セキュリティー・レベル2---------------- ---------------- 主要な協定: P-384の主要な派生があるP-256 ECDHとECDH: SHA-256 SHA-384の主要な包装: 主要なAES-128の包装AES-256主要な包装満足している暗号化: AES-128 CBC AES-256 CBC
2. SHA-256 and SHA-256 Message Digest Algorithms
2. SHA-256とSHA-256メッセージダイジェストアルゴリズム
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]をサポートする実装によって使われたコンベンションを指定します。 Suite B、Security Level1では、SHA-256メッセージダイジェストアルゴリズムを使用しなければなりません。 Suite B、Security Level2、SHA-384 MUSTでは、使用されてください。
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署名しているデータcontent typeの中では、メッセージダイジェストアルゴリズム識別子はSignedData digestAlgorithms分野とSignerInfo digestAlgorithm分野に位置しています。 また、メッセージダイジェスト値は中に位置して、Message Digestが属性を認証したということです。 さらに、メッセージダイジェスト値は署名アルゴリズムに入力されます。
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 Pub180-2[SHA2、EH]で定義されます。 SHA-256のためのアルゴリズム識別子は以下の通りです。
Housley & Solinas Informational [Page 2] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[2ページ]のRFC5008スイートB
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
イド-sha256 OBJECT IDENTIFIER:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(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 }
イド-sha384 OBJECT IDENTIFIER:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(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可能なencodingsがあります。 2つの選択肢がAlgorithmIdentifierのための1988年の構文が1997年の構文に翻訳されたとき、AlgorithmIdentifierパラメタに関連しているOPTIONALが失せたという事実から起こります。 その後、OPTIONALは不具合報告で回収されましたが、次にそのアルゴリズムであると考えられた多くの人々で、パラメタは義務的でした。 この歴史のために、NULL要素と他のものが彼らを完全に省略するとき、いくつかの実装がパラメタをコード化します。 SHA-256とSHA-384メッセージダイジェストアルゴリズムのための正しいコード化はパラメタ分野を省略することです。 しかしながら、互換性を確実にするために、また、実装はSHA-256とSHA-384 AlgorithmIdentifierパラメタ分野を扱うべきです。(それは、NULLを含みます)。
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パラメタ分野はOPTIONALです、そして、存在しているなら、パラメタ分野はNULLを含まなければなりません。 実装は欠けているパラメタがあるSHA-256とSHA-384 AlgorithmIdentifiersを受け入れなければなりません。 実装はNULLパラメタがあるSHA-256とSHA-384 AlgorithmIdentifiersを受け入れなければなりません。 実装SHOULDは欠けているパラメタがあるSHA-256とSHA-384 AlgorithmIdentifiersを生成します。
3. ECDSA Signature Algorithm
3. ECDSA署名アルゴリズム
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].
このセクションはElliptic Curve Digital Signature Algorithm(ECDSA)をサポートする実装によって使われたコンベンションを指定します。 RFC3278[CMSECC]によって設定された方向は従われていますが、追加メッセージダイジェストアルゴリズムと追加楕円曲線は採用しています。 Suite B、Security Level1、ECDSA MUSTでは、SHA-256メッセージダイジェストアルゴリズムとP-256楕円曲線と共に使用されてください。 Suite B、Security Level2、ECDSA MUSTでは、SHA-384メッセージダイジェストアルゴリズムとP-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署名しているデータcontent typeの中では、署名アルゴリズム識別子はSignedDataのSignerInfo signatureAlgorithm分野に位置しています。 さらに、署名アルゴリズム識別子は副署属性のSignerInfo signatureAlgorithm分野に位置しています。
Housley & Solinas Informational [Page 3] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[3ページ]のRFC5008スイートB
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署名しているデータcontent typeの中では、署名値は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:
RFC3279[PKIX1ALG]で指定されるように、ECDSAとElliptic Curveディフィー-ヘルマン(ECDH)は対象の公開鍵に証明書で同じアルゴリズム識別子を使用します、そして、それはここで繰り返されます:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) keyType(2) 1 }
イド-ecPublicKeyオブジェクト識別子:、:= iso(1)は(2) 私たち(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暗号化キーの両方に公開鍵証明書で使用されます。 キーの意図しているアプリケーションは主要な用法分野で示されるかもしれません(RFC3280[PKIX1]を見てください)。 別々のキーの署名と暗号化目的の使用はRECOMMENDEDです。 しかしながら、単一のキーの署名と暗号化目的の両方の使用は禁じられません。
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same encoding for subject public keys in certificates, and it is repeated here:
RFC3279[PKIX1ALG]で指定されるように、ECDSAとECDHは対象の公開鍵に証明書で同じコード化を使用します、そして、それはここで繰り返されます:
ECPoint ::= OCTET STRING
ECPoint:、:= 八重奏ストリング
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.
楕円曲線公開鍵(OCTET STRING)は以下の対象の公開鍵(BIT STRING)に写像されます: OCTET STRINGの最も重要なビットはBIT STRINGの最も重要なビットになります、そして、OCTET STRINGの最下位ビットはBIT STRINGの最下位ビットになります。 この八重奏ストリングが圧縮されたか解凍されたフォームに楕円曲線ポイントを表すかもしれないことに注意してください。 この仕様通りに楕円曲線をサポートする実装は、解凍されたフォームをサポートしなければならなくて、圧縮形をサポートするかもしれません。
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は公開鍵がある、あるパラメタの使用を必要とします。 パラメタは、証明書発行人から引き継がれるか、命名されたカーブの参照でそれとなく含まれているか、または証明書に明らかに含まれるかもしれません。 RFC3279[PKIX1ALG]で指定されるように、パラメタ構造は以下の通りです。
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
EcpkParameters:、:= 選択ecParameters ECParameters、namedCurveオブジェクト識別子、implicitlyCAヌル
Housley & Solinas Informational [Page 4] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[4ページ]のRFC5008スイートB
In Suite B, the namedCurve CHOICE MUST be used. The object identifier for P-256 is:
Suite Bでは、namedCurve CHOICEを使用しなければなりません。 P-256のためのオブジェクト識別子は以下の通りです。
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) curves(3) prime(1) 7 }
ansip256r1 OBJECT IDENTIFIER:、:= iso(1)が(840)ansi-x9-62(10045)カーブ(3)主要な状態で(2) 私たちをメンバーと同じくらい具体化させる、(1)7
The object identifier for P-384 is:
P-384のためのオブジェクト識別子は以下の通りです。
secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 }
secp384r1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)certicom(132)カーブ(0)34
The algorithm identifier used in CMS for ECDSA with SHA-256 signature values is:
ECDSAにCMSでSHA-256署名値で使用されるアルゴリズム識別子は以下の通りです。
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
SHA256とecdsaオブジェクト識別子:、:= iso(1)は(2) 私たちsha2(3)と(840) ansi-X9-62(10045)署名(4)ecdsa2をメンバーと同じくらい具体化させます。
The algorithm identifier used in CMS for ECDSA with SHA-384 signature values is:
ECDSAにCMSでSHA-384署名値で使用されるアルゴリズム識別子は以下の通りです。
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
SHA384とecdsaオブジェクト識別子:、:= iso(1)は(2) 私たちsha2(3)と(840) ansi-X9-62(10045)署名(4)ecdsa3をメンバーと同じくらい具体化させます。
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
SHA256とecdsaかSHA384とecdsaアルゴリズム識別子のどちらかが使用されているとき、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つの値を移すために、RFC3279[PKIX1ALG]で指定されたEcdsa-Sig-値のタイプを使用して、それらをコード化しなければなりません:
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をEcdsa-Sig評価してください:= 系列r整数、s整数
4. Key Management
4. Key Management
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は以下の一般的なかぎ管理のテクニックに対応します: 主要な協定(主要な輸送)は以前に、左右対称の主要な暗号化キー、およびパスワードを分配しました。 Suite Bでは、はかなく静的な主要な協定はセクション4.1で説明されるように使用されているに違いありません。
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
また、主要な協定アルゴリズムが使用されているとき、主要な暗号化アルゴリズムが必要です。 Suite Bでは、主要な暗号化アルゴリズムとしてRFC3394[AESWRAP、SH]で指定されるエー・イー・エス(AES)の主要なWrapを使用しなければなりません。 セクション4.2で、より詳しくAES Key Wrapについて議論します。 AES Key Wrapと共に使用される主要な暗号化キー
Housley & Solinas Informational [Page 5] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[5ページ]のRFC5008スイートB
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)からアルゴリズムを得ます。 Suite Bに、2KDFs、SHA-256に基づいた1とSHA-384に基づいた1があります。 セクション4.3で、より詳しくこれらのKDFsについて議論します。
4.1. ECDH Key Agreement Algorithm
4.1. ECDHの主要な協定アルゴリズム
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をサポートする実装によって使われたコンベンションを指定します。 RFC3278[CMSECC]によって設定された方向は従われていますが、追加主要な派生機能と主要な包装アルゴリズムは採用しています。 S/MIMEは用意して、前方に使用されます。コミュニケーション。(そのコミュニケーションは、はかなく静的なECDHがいつも使われることを意味します)。 これは、メッセージ創始者がはかないECDHキーを使用して、メッセージ受取人が静的なECDHキーを使用することを意味します。(キーはX.509証明書から入手されます)。 Suite B、Security Level1、はかなく静的なECDH MUST、SHA-256 KDF、AES-128 Key Wrap、およびP-256楕円曲線と共に使用されてください。 Suite B、Security Level2、はかなく静的なECDH MUST、SHA-384 KDF、AES-256 Key Wrap、およびP-384楕円曲線と共に使用されてください。
Within the CMS enveloped-data content type, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
CMSおおわれたデータcontent typeの中では、主要な協定アルゴリズム識別子は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.
RFC3279[PKIX1ALG]で指定されるように、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パラメタでイド-ecPublicKeyオブジェクト識別子を含まなければなりません(セクション3を見ます)。 originatorKey publicKey分野はメッセージ創始者のはかない公開鍵を含まなければなりません(セクション3を見てください)。(それは、DERによってコード化されたECPointです)。 ECPoint SHOULD、解凍されたフォームに表されてください。
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
ukmは現在である、または欠けている場合があります。 しかしながら、メッセージ創始者SHOULDはukmを含んでいます。 実装が、RFC3852[CMS]で指定されるようにukmがメッセージ受取人処理であるとサポートしなければならないので、ukmが現在である、または欠けるなら、相互運用性は関心ではありません。 存在しているとき、ukmは異なった主要な暗号化キーが発生しているのを保証するのに使用されます、はかない秘密鍵が不適切に使用さえされるとき
Housley & Solinas Informational [Page 6] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[6ページ]のRFC5008スイートB
more than once. See [RANDOM] for guidance on generation of random
values.
一度より多くです。 指導に関して無作為の値の世代に[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つのアルゴリズム識別子の1つであるに違いなく、アルゴリズム識別子パラメタ分野は、存在していて、主要な包装アルゴリズムを特定しなければなりません。 対状の主要な暗号化キーが生成されている状態で、主要な包装アルゴリズムは、はかなく静的なECDH主要な協定アルゴリズムを使用することで満足している暗号化キーを暗号化するのに使用される左右対称の暗号化アルゴリズムを指示します(セクション4.3を見てください)。 Suite B、Security Level1では、keyEncryptionAlgorithmはdhSinglePass-stdDH- sha256kdf-体系であるに違いありません、そして、keyEncryptionAlgorithmパラメタはイドaes128包装を含むKeyWrapAlgorithmであるに違いありません(セクション4.2を見てください)。 Suite B、Security Level2では、keyEncryptionAlgorithmはdhSinglePass-stdDH-sha384kdf-体系であるに違いありません、そして、keyEncryptionAlgorithmパラメタはイド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-sha256kdf-体系オブジェクト識別子:、:= iso(1)の特定された組織(3)certicom(132)体系(1)11 1
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
dhSinglePass-stdDH-sha384kdf-体系オブジェクト識別子:、:= iso(1)の特定された組織(3)certicom(132)体系(1)11 2
Both of these algorithm identifiers use KeyWrapAlgorithm as the
type for their parameter:
これらのアルゴリズム識別子の両方がそれらのパラメタにタイプとしてKeyWrapAlgorithmを使用します:
KeyWrapAlgorithm ::= AlgorithmIdentifier
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ははかなく静的で、ECDHが発生している対状主要な暗号化キーがKeyWrapAlgorithmによって指定されたアルゴリズムを使用している状態で暗号化された内容暗号化キーを含まなければなりません(セクション4.3を見てください)。
Housley & Solinas Informational [Page 7] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[7ページ]のRFC5008スイートB
4.2. AES Key Wrap
4.2. AESの主要な包装
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は左右対称の主要な暗号化かぎ管理のサポートを提供します。 しかしながら、それはSuite B.ラザーで使用されないで、RFC3394[AESWRAP、SH]で指定されるAES Key Wrapの主要な暗号化アルゴリズムは、はかなく静的なECDHを使用するのが生成される対状主要な暗号化キーによって主要な満足している暗号化を暗号化するのに使用されます。 Suite B、Security Level1では、主要な暗号化アルゴリズムとしてAES-128 Key Wrapを使用しなければなりません。 Suite B、Security Level2では、主要な暗号化アルゴリズムとしてAES-256 Key Wrapを使用しなければなりません。
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おおわれたデータcontent typeの中では、包装された内容暗号化キーは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 Key Wrapのためのアルゴリズム識別子はRFC3394[SH]で指定されます、そして、Suite 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 }
イドaes128包装OBJECT IDENTIFIER:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(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 }
イドaes256包装OBJECT IDENTIFIER:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(1)gov(101) csor(3) nistAlgorithm(4) aes(1)45
4.3. Key Derivation Functions
4.3. 主要な派生機能
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はパスワードから左右対称の主要な暗号化キーを得るサポートを提供します。 しかしながら、パスワードを拠点とするかぎ管理はSuite B.ラザーで使用されないで、SHA-256とSHA-384に基づくKDFsは、はかなく静的なECDHによって作り出された共有秘密キーから主要な対状主要な暗号化を引き出すのに使用されます。 Suite B、Security Level1、SHA-256 MUSTに基づくKDFでは、使用されてください。 Suite B、Security Level2、SHA-384 MUSTに基づく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おおわれたデータcontent typeがあるECDHを使用して、RFC3278[CMSECC]のセクション8.2で指定されるように、主要な暗号化キーの派生はECC-CMS-SharedInfoタイプを利用します:(タイプはここで繰り返されます)。
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
ECC cm SharedInfo:、:= 系列keyInfo AlgorithmIdentifier、entityUInfoの明白な八重奏ストリング任意の、そして、suppPubInfo[2]明白な八重奏[0]ストリング
Housley & Solinas Informational [Page 8] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[8ページ]のRFC5008スイートB
In Suite B, the fields of ECC-CMS-SharedInfo are used as follows:
Suite 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パラメタを包装するのに使用される主要な暗号化アルゴリズムに関するオブジェクト識別子を含んでいます。 Suite B、Security Level1では、イドaes128包装、NULLをもたらして、AES-128 Key Wrapを使用しなければなりません。 Suite B、Security Level2では、イドaes256包装、NULLをもたらして、AES-256 Key Wrapを使用しなければなりません。
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はRFC2631[CMSDH]で説明されるように32ビットの符号のない数として表されたビットで主要な発生している主要な暗号化の長さを含んでいます。 Suite B、Security Level1では、0×00000080をもたらして、128ビットのAESキーを使用しなければなりません。 Suite B、Security Level2では、0×00000100をもたらして、256ビットのAESキーを使用しなければなりません。
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によってコード化されています、そして、入力されるように使用されて、主要な派生に、.1[SEC1]がセクション3.6で指定されるように機能します。 ECC-CMS-SharedInfoが[CMSDH]で指定されたOtherInfoと異なっていることに注意してください。 ここに、[SEC1]で指定されたKDFが、十分な合わせるデータが提供されるのを確実にするので、対価はkeyInfo分野に含まれていません。
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 cm 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:
主要な暗号化キーを生成するために、1つ以上のKMブロック以上が発生しています、適切にCounterを増加して、十分な材料が生成されるまで。 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]のどちらかです。 Suite B、Security Level1SHA-256 MUSTでは、使用されてください。 Suite B、Security Level2、SHA-384 MUSTでは、使用されてください。
Housley & Solinas Informational [Page 9] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[9ページ]のRFC5008スイートB
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によって生成された共有秘密キー値です。 先行ゼロビットを保存しなければなりません。 Suite B、Security Level1では、Zはちょうど256ビットでなければなりません。 Suite B、Security Level2では、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ビットの符号のない数です。 初期の値はどんな主要な派生操作のための0×00000001でなければなりません。 Suite BとSecurity Level1とSecurity Level2、ちょうど1では、繰り返しが必要です。 Counterは増加されていません。
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ブロックが0×00000001のCounter値で生成されます:
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
KEK=km( 1 )=ハッシュ(Z| | カウンタ=1| | ECC cm 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.
Suite B、Security Level1では、主要な暗号化キーはSHA-256出力価値の最も重要な128ビットでなければなりません。 Suite B、Security Level2では、主要な暗号化キーは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が異なると、異なった主要な暗号化キーは各メッセージのために生成されるでしょう。
5. AES CBC Content Encryption
5. AES CBCの満足している暗号化
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.
このセクションはCipher Block Chaining(CBC)モード[MODES]で内容暗号化使用AES[AES]をサポートする実装によって使われたコンベンションを指定します。 RFC3565[CMSAES]のコンベンションは続かれています。 Suite B、Security Level1では、満足している暗号化にCBCモードによるAES-128を使用しなければなりません。 Suite B、Security Level2では、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おおわれたデータcontent typeの中では、満足している暗号化アルゴリズム識別子はEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm分野に位置しています。 満足している暗号化アルゴリズムは、EnvelopedData EncryptedContentInfo encryptedContent分野に位置する内容を暗号化するのに使用されます。
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]と[MODES]で説明されます。 CBCモードによるAES-128のためのアルゴリズム識別子は以下の通りです。
Housley & Solinas Informational [Page 10] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[10ページ]のRFC5008スイートB
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 }
イド-aes128-CBCオブジェクト識別子:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(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 }
イド-aes256-CBCオブジェクト識別子:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(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))
AES-IV:、:= 八重奏ストリング(サイズ(16))
The 16-octet initialization vector is generated at random by the originator. See [RANDOM] for guidance on generation of random values.
16八重奏の初期化ベクトルは創始者によって無作為に生成されます。 指導に関して無作為の値の世代に[RANDOM]を見てください。
6. Security Considerations
6. セキュリティ問題
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のSuite 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.
署名していて暗号化されたメッセージのために、Suite Bは一貫したレベルのセキュリティをメッセージ内容の秘密性と保全に提供します。
The security considerations in RFC 3852 [CMS] discuss the CMS as a method for digitally signing data and encrypting data.
RFC3852の問題がデータにデジタルに署名して、データを暗号化しながらメソッドとしてのCMSについて議論する[CMS]セキュリティ。
The security considerations in RFC 3370 [CMSALG] discuss cryptographic algorithm implementation concerns in the context of the CMS.
RFC3370[CMSALG]のセキュリティ問題はCMSの文脈における暗号アルゴリズム実施にかかわる懸念について議論します。
The security considerations in RFC 3278 [CMSECC] discuss the use of elliptic curve cryptography (ECC) in the CMS.
RFC3278[CMSECC]のセキュリティ問題はCMSにおける楕円曲線暗号(ECC)の使用について議論します。
The security considerations in RFC 3565 [CMSAES] discuss the use of AES in the CMS.
RFC3565[CMSAES]のセキュリティ問題はCMSにおけるAESの使用について議論します。
Housley & Solinas Informational [Page 11] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[11ページ]のRFC5008スイートB
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001.
2001年11月の[AES]米国商務省標準技術局、「エー・イー・エス(AES)」FIPSパブ197。
[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の主要な包装仕様」、2001年11月17日。 [ 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パブ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]American National Standards Institut、「財政的のための公開鍵暗号は産業にサービスを提供します」。 「楕円曲線デジタル署名アルゴリズム(ECDSA)」、ANSI X9.62-1998、1999。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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.、「暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)暗号化アルゴリズムの使用」、RFC3565(2003年7月)。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[CMSDH] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、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.ランバート、「暗号のメッセージ構文(cm)における楕円曲線暗号(ECC)アルゴリズムの使用」、RFC3278(2002年4月)。
[IEEE1363] Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography",
IEEE Std 1363, 2000.
[IEEE1363]米国電気電子技術者学会、「公開鍵暗号のための標準の仕様」、IEEE Std1363、2000。
[MODES] National Institute of Standards and Technology, "DES
Modes of Operation", FIPS Pub 81, 2 December 1980.
[モード]米国商務省標準技術局、「DES運転モード」、FIPSパブ81、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メッセージ仕様」、RFC3851、2004年7月。
Housley & Solinas Informational [Page 12] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[12ページ]のRFC5008スイートB
[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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(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] Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", 2000. [See http://www.secg.org/
collateral/sec1.pdf.]
効率的な暗号グループ、「楕円曲線暗号」、2000年の[SEC1]規格。 [ http://www.secg.org/ 傍系親族/sec1.pdfを見てください。]
[SH] Schaad, J., and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SH] Schaad、J.、およびR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。
[SHA2] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, 1 August 2002.
[SHA2]米国商務省標準技術局、「安全なハッシュ規格」、FIPS180-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.ブラドナー、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.
7.2. Informative References
7.2. 有益な参照
[EH] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[えっ] イーストレーク3番目とD.とT.ハンセン、「米国の安全なハッシュアルゴリズム(SHAとHMAC-SHA)」、RFC4634、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.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。
[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スイートB暗号」、2005年7月。 [ http://www.nsa.gov/ia/ 産業/暗号_スイート_b.cfmを見てください--MenuID=10.2.7)
Housley & Solinas Informational [Page 13] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[13ページ]のRFC5008スイートB
Authors' Addresses
作者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国
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の国家の情報保証研究所国家安全保障局9800サヴェージ・道路とりでジョージ・G.MD20755ミード(米国)
EMail: jasolin@orion.ncsc.mil
メール: jasolin@orion.ncsc.mil
Housley & Solinas Informational [Page 14] RFC 5008 Suite B in S/MIME September 2007
S/MIME2007年9月のHousley&Solinasの情報[14ページ]のRFC5008スイートB
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Housley & Solinas Informational [Page 15]
Housley&Solinas情報です。[15ページ]
一覧
スポンサーリンク
