RFC3370 日本語訳
3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August 2002. (Format: TXT=51001 bytes) (Obsoletes RFC2630, RFC3211) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley Request for Comments: 3370 RSA Laboratories Obsoletes: 2630, 3211 August 2002 Category: Standards Track
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3370のRSA研究所が以下を時代遅れにします。 2630、3211年2002年8月のカテゴリ: 標準化過程
Cryptographic Message Syntax (CMS) Algorithms
暗号のメッセージ構文(cm)アルゴリズム
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS). The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents.
このドキュメントは、いくつかの暗号アルゴリズムを使用するためにCryptographic Message Syntax(CMS)と共にコンベンションについて説明します。 CMSは、任意のメッセージ内容をデジタルに署名するか、読みこなすか、認証するか、または暗号化するのに使用されます。
Table of Contents
目次
1 Introduction ............................................... 2 1.1 Changes Since RFC 2630 ..................................... 2 1.2 Terminology ................................................ 2 2 Message Digest Algorithms .................................. 3 2.1 SHA-1 ...................................................... 3 2.2 MD5 ........................................................ 3 3 Signature Algorithms ....................................... 4 3.1 DSA ........................................................ 4 3.2 RSA ........................................................ 5 4 Key Management Algorithms .................................. 6 4.1 Key Agreement Algorithms ................................... 6 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ...................... 7 4.1.2 X9.42 Static-Static Diffie-Hellman ......................... 8 4.2 Key Transport Algorithms ................................... 9 4.2.1 RSA (PKCS #1 v1.5) ......................................... 10 4.3 Symmetric Key-Encryption Key Algorithms .................... 10 4.3.1 Triple-DES Key Wrap ........................................ 11 4.3.2 RC2 Key Wrap ............................................... 12 4.4 Key Derivation Algorithms .................................. 12
1つの序論… 2 1.1 RFC2630以来、変化します… 2 1.2用語… 2 2のメッセージダイジェストアルゴリズム… 3 2.1SHA-1… 3 2.2MD5… 3 3の署名アルゴリズム… 4 3.1DSA… 4 3.2RSA… 5 4のKey Managementアルゴリズム… 6 4.1 主要な協定アルゴリズム… 6 4.1 .1 X9.42のはかなく静的なディフィー-ヘルマン… 7 4.1 .2 X9.42の静的に静的なディフィー-ヘルマン… 8 4.2 主要な輸送アルゴリズム… 9 4.2 .1RSA(PKCS#1v1.5)… 10 4.3 左右対称の主要な暗号化主要なアルゴリズム… 10 4.3 .1 三重のDESの主要な包装… 11 4.3 .2 RC2の主要な包装… 12 4.4 主要な誘導アルゴリズム… 12
Housley Standards Track [Page 1] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[1ページ]RFCアルゴリズム2002年8月
4.4.1 PBKDF2 ..................................................... 13 5 Content Encryption Algorithms .............................. 13 5.1 Triple-DES CBC ............................................. 14 5.2 RC2 CBC .................................................... 14 6 Message Authentication Code (MAC) Algorithms ............... 15 6.1 HMAC with SHA-1 ............................................ 15 7 ASN.1 Module ............................................... 16 8 References ................................................. 18 9 Security Considerations .................................... 20 10 Acknowledgments ............................................ 22 11 Author's Address ........................................... 23 12 Full Copyright Statement ................................... 24
4.4.1 PBKDF2… 13 5 満足している暗号化アルゴリズム… 13 5.1 三重のDES CBC… 14 5.2RC2 CBC… 14 6 メッセージ立証コード(MAC)アルゴリズム… 15 SHA-1と6.1HMAC… 15 7 ASN.1モジュール… 16 8つの参照箇所… 18 9 セキュリティ問題… 20 10の承認… 22 11作者のアドレス… 23 12の完全な著作権宣言文… 24
1 Introduction
1つの序論
The Cryptographic Message Syntax (CMS) [CMS] is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. This companion specification describes the use of common cryptographic algorithms with the CMS. Implementations of the CMS may support these algorithms; implementations of the CMS may also support other algorithms as well. However, if an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document.
Cryptographic Message Syntax(CMS)[CMS]は、任意のメッセージ内容をデジタルに署名するか、読みこなすか、認証するか、または暗号化するのに使用されます。 この仲間仕様はCMSとの一般的な暗号アルゴリズムの使用について説明します。CMSの実装はこれらのアルゴリズムをサポートするかもしれません。 また、CMSの実装はまた、他のアルゴリズムをサポートするかもしれません。 しかしながら、実装が、本書では議論したアルゴリズムの1つをサポートするのを選ぶなら、実装は本書では説明されるようにそうしなければなりません。
The CMS values are generated using ASN.1 [X.208-88], using BER- encoding [X.209-88]. Algorithm identifiers (which include ASN.1 object identifiers) identify cryptographic algorithms, and some algorithms require additional parameters. When needed, parameters are specified with an ASN.1 structure. The algorithm identifier for each algorithm is specified, and when needed, the parameter structure is specified. The fields in the CMS employed by each algorithm are identified.
[X.209-88]をコード化しながらBERを使用して、ASN.1[X.208-88]を使用するのはCMS値に生成されます。 アルゴリズム識別子(ASN.1オブジェクト識別子を含んでいる)は暗号アルゴリズムを特定します、そして、いくつかのアルゴリズムが追加パラメタを必要とします。 必要であると、パラメタはASN.1構造で指定されます。 各アルゴリズムのためのアルゴリズム識別子は指定されます、そして、必要であると、パラメタ構造は指定されます。 各アルゴリズムで使われたCMSの分野は特定されます。
1.1 Changes Since RFC 2630
1.1 RFC2630以来の変化
This document obsoletes section 12 of RFC 2630 [OLDCMS]. RFC 3369 [CMS] obsoletes the rest of RFC 2630. Separation of the protocol and algorithm specifications allows each one to be updated without impacting the other. However, the conventions for using additional algorithms with the CMS are likely to be specified in separate documents.
このドキュメントはRFC2630[OLDCMS]のセクション12を時代遅れにします。 RFC3369[CMS]はRFC2630の残りを時代遅れにします。 プロトコルとアルゴリズム仕様の分離は、もう片方に影響を与えないでそれぞれをアップデートするのを許容します。 しかしながら、CMSがある追加アルゴリズムを使用するためのコンベンションは別々のドキュメントで指定されそうです。
1.2 Terminology
1.2 用語
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described in [STDWORDS].
本書では、キーワードが解釈しなければならない、[STDWORDS]で説明されるようにNOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、および5月を解釈することになっていなければなりませんか?
Housley Standards Track [Page 2] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[2ページ]RFCアルゴリズム2002年8月
2 Message Digest Algorithms
2 メッセージダイジェストアルゴリズム
This section specifies the conventions employed by CMS implementations that support SHA-1 or MD5.
このセクションはSHA-1かMD5をサポートするCMS実装によって使われたコンベンションを指定します。
Digest algorithm identifiers are located in the SignedData digestAlgorithms field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm field, and the AuthenticatedData digestAlgorithm field.
ダイジェストアルゴリズム識別子はSignedData digestAlgorithms分野、SignerInfo digestAlgorithm分野、DigestedData digestAlgorithm分野、およびAuthenticatedData digestAlgorithm分野に位置しています。
Digest values are located in the DigestedData digest field and the Message Digest authenticated attribute. In addition, digest values are input to signature algorithms.
ダイジェスト値はDigestedDataダイジェスト分野に位置しました、そして、Message Digestは属性を認証しました。 さらに、ダイジェスト値は署名アルゴリズムに入力されます。
2.1 SHA-1
2.1 SHA-1
The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is:
SHA-1メッセージダイジェストアルゴリズムはFIPS Pub180-1[SHA1]で定義されます。 SHA-1のためのアルゴリズム識別子は以下の通りです。
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(2)26
There are two possible encodings for the SHA-1 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 is to omit the parameters field; however, implementations MUST also handle a SHA-1 AlgorithmIdentifier parameters field which contains a NULL.
SHA-1 AlgorithmIdentifierパラメタ分野への2可能なencodingsがあります。 2つの選択肢がAlgorithmIdentifierのための1988年の構文が1997年の構文に翻訳されたとき、AlgorithmIdentifierパラメタに関連しているOPTIONALが失せたという事実から起こります。 その後、OPTIONALは不具合報告で回収されましたが、次にそのアルゴリズムであると考えられた多くの人々で、パラメタは義務的でした。 この歴史のために、NULL要素と他のものが彼らを完全に省略するとき、いくつかの実装がパラメタをコード化します。 正しいコード化はパラメタ分野を省略することです。 しかしながら、また、実装はNULLを含むSHA-1 AlgorithmIdentifierパラメタ分野を扱わなければなりません。
The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-1 AlgorithmIdentifiers with absent parameters.
AlgorithmIdentifierパラメタ分野はOPTIONALです。 存在しているなら、パラメタ分野はNULLを含まなければなりません。 実装は欠けているパラメタがあるSHA-1 AlgorithmIdentifiersを受け入れなければなりません。 実装はNULLパラメタがあるSHA-1 AlgorithmIdentifiersを受け入れなければなりません。 実装SHOULDは欠けているパラメタがあるSHA-1 AlgorithmIdentifiersを生成します。
2.2 MD5
2.2 MD5
The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm identifier for MD5 is:
MD5ダイジェストアルゴリズムはRFC1321[MD5]で定義されます。 MD5のためのアルゴリズム識別子は以下の通りです。
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
md5 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) digestAlgorithm(2)5をメンバーと同じくらい具体化させます。
Housley Standards Track [Page 3] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[3ページ]RFCアルゴリズム2002年8月
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL. Implementations MAY accept the MD5 AlgorithmIdentifiers with absent parameters as well as NULL parameters.
AlgorithmIdentifierパラメタ分野は存在していなければなりません、そして、パラメタ分野はNULLを含まなければなりません。 実装はNULLパラメタと同様に欠けているパラメタがあるMD5 AlgorithmIdentifiersを受け入れるかもしれません。
3 Signature Algorithms
3 署名アルゴリズム
This section specifies the conventions employed by CMS implementations that support DSA or RSA (PKCS #1 v1.5).
このセクションはDSAかRSAが(PKCS#1v1.5)であるとサポートするCMS実装によって使われたコンベンションを指定します。
Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. Also, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
署名アルゴリズム識別子はSignedDataのSignerInfo signatureAlgorithm分野に位置しています。 また、署名アルゴリズム識別子は副署属性のSignerInfo signatureAlgorithm分野に位置しています。
Signature values are located in the SignerInfo signature field of SignedData. Also, signature values are located in the SignerInfo signature field of countersignature attributes.
署名値はSignedDataのSignerInfo署名分野に位置しています。 また、署名値は副署属性のSignerInfo署名分野に位置しています。
3.1 DSA
3.1 DSA
The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA MUST be used with the SHA-1 message digest algorithm.
DSA署名アルゴリズムはFIPS Pub186[DSS]で定義されます。 DSA MUST、SHA-1メッセージダイジェストアルゴリズムで、使用されてください。
The algorithm identifier for DSA subject public keys in certificates is:
証明書のDSAの対象の公開鍵のためのアルゴリズム識別子は以下の通りです。
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 1 }
イド-dsa OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9cm(4)1をメンバーと同じくらい具体化させます。
DSA signature validation requires three parameters, commonly called p, q, and g. When the id-dsa algorithm identifier is used, the AlgorithmIdentifier parameters field is optional. If present, the AlgorithmIdentifier parameters field MUST contain the three DSA parameter values encoded using the Dss-Parms type. If absent, the subject DSA public key uses the same DSA parameters as the certificate issuer.
DSA署名合法化は一般的にp、q、およびgと呼ばれる3つのパラメタを必要とします。 イド-dsaアルゴリズム識別子が使用されているとき、AlgorithmIdentifierパラメタ分野は任意です。 存在しているなら、AlgorithmIdentifierパラメタ分野はDss-Parmsタイプを使用することでコード化された3つのDSAパラメタ値を含まなければなりません。 休むなら、対象のDSA公開鍵は証明書発行人と同じDSAパラメタを使用します。
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER
When the id-dsa algorithm identifier is used, the DSA public key, commonly called Y, MUST be encoded as an INTEGER. The output of this encoding is carried in the certificate subject public key.
イド-dsaアルゴリズム識別子が使用されているとき、INTEGERとして一般的にYと呼ばれたDSA公開鍵をコード化しなければなりません。 このコード化の出力は証明書対象公開鍵で運ばれます。
Dss-Pub-Key ::= INTEGER -- Y
Dssパブキー:、:= 整数--Y
Housley Standards Track [Page 4] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[4ページ]RFCアルゴリズム2002年8月
The algorithm identifier for DSA with SHA-1 signature values is:
SHA-1署名値があるDSAのためのアルゴリズム識別子は以下の通りです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9cm(4)3をメンバーと同じくらい具体化させます。
When the id-dsa-with-sha1 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
sha1とイドdsaアルゴリズム識別子が使用されているとき、AlgorithmIdentifierパラメタ分野は欠けているに違いありません。
When signing, the DSA algorithm generates two values, commonly called r and s. To transfer these two values as one signature, they MUST be encoded using the Dss-Sig-Value type:
署名するとき、DSAアルゴリズムは一般的にrとsと呼ばれる2つの値を生成します。 1つの署名としてこれらの2つの値を移すために、Dss-Sig-値のタイプを使用して、それらをコード化しなければなりません:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
3.2 RSA
3.2 RSA
The RSA (PKCS #1 v1.5) signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 2437 specifies the use of the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms.
RSA(PKCS#1v1.5)署名アルゴリズムはRFC2437[NEWPKCS#1]で定義されます。 RFC2437はSHA-1とMD5メッセージダイジェストアルゴリズムがあるRSA署名アルゴリズムの使用を指定します。
The algorithm identifier for RSA subject public keys in certificates is:
証明書のRSAの対象の公開鍵のためのアルゴリズム識別子は以下の通りです。
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)1をメンバーと同じくらい具体化させます。
When the rsaEncryption algorithm identifier is used, the AlgorithmIdentifier parameters field MUST contain NULL.
rsaEncryptionアルゴリズム識別子が使用されているとき、AlgorithmIdentifierパラメタ分野はNULLを含まなければなりません。
When the rsaEncryption algorithm identifier is used, the RSA public key, which is composed of a modulus and a public exponent, MUST be encoded using the RSAPublicKey type. The output of this encoding is carried in the certificate subject public key.
rsaEncryptionアルゴリズム識別子が使用されているとき、RSAPublicKeyタイプを使用して、RSA公開鍵(係数と公共の解説者で構成される)をコード化しなければなりません。 このコード化の出力は証明書対象公開鍵で運ばれます。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
RSAPublicKey:、:= SEQUENCE、係数INTEGER--、n publicExponent INTEGER、--、e
CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST also implement the SHA-1 message digest algorithm. Such implementations SHOULD also support the MD5 message digest algorithm.
また、RSA(PKCS#1v1.5)署名アルゴリズムを含んでいるCMS実装はSHA-1メッセージダイジェストアルゴリズムを実装しなければなりません。 また、そのような実装SHOULDはMD5メッセージダイジェストアルゴリズムをサポートします。
Housley Standards Track [Page 5] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[5ページ]RFCアルゴリズム2002年8月
The rsaEncryption algorithm identifier is used to identify RSA (PKCS #1 v1.5) signature values regardless of the message digest algorithm employed. CMS implementations that include the RSA (PKCS #1 v1.5) signature algorithm MUST support the rsaEncryption signature value algorithm identifier, and CMS implementations MAY support RSA (PKCS #1 v1.5) signature value algorithm identifiers that specify both the RSA (PKCS #1 v1.5) signature algorithm and the message digest algorithm.
rsaEncryptionアルゴリズム識別子は、使われたメッセージダイジェストアルゴリズムにかかわらずRSA(PKCS#1v1.5)署名値を特定するのに使用されます。 RSA(PKCS#1v1.5)署名アルゴリズムを含んでいるCMS実装はrsaEncryption署名値のアルゴリズム識別子をサポートしなければなりません、そして、CMS実装はRSA(PKCS#1v1.5)署名価値がRSA(PKCS#1v1.5)署名アルゴリズムとメッセージダイジェストアルゴリズムの両方を指定するアルゴリズム識別子であるとサポートするかもしれません。
The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature values is:
SHA-1署名値があるRSA(PKCS#1v1.5)のためのアルゴリズム識別子は以下の通りです。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
sha1WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)5をメンバーと同じくらい具体化させます。
The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature values is:
MD5署名値があるRSA(PKCS#1v1.5)のためのアルゴリズム識別子は以下の通りです。
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
md5WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)4をメンバーと同じくらい具体化させます。
When the rsaEncryption, sha1WithRSAEncryption, or md5WithRSAEncryption signature value algorithm identifiers are used, the AlgorithmIdentifier parameters field MUST be NULL.
rsaEncryption、sha1WithRSAEncryption、またはmd5WithRSAEncryption署名値のアルゴリズム識別子が使用されているとき、AlgorithmIdentifierパラメタ分野はNULLであるに違いありません。
When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value.
署名するとき、RSAアルゴリズムはただ一つの値を生成します、そして、その値は直接署名値として使用されます。
4 Key Management Algorithms
4 Key Managementアルゴリズム
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key- encryption keys, and passwords.
CMSは以下の一般的なかぎ管理のテクニックに対応します: 主要な協定(主要な輸送)は以前に、左右対称の主要な暗号化キー、およびパスワードを分配しました。
4.1 Key Agreement Algorithms
4.1 主要な協定アルゴリズム
This section specifies the conventions employed by CMS implementations that support key agreement using X9.42 Ephemeral- Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-Hellman (X9.42 S-S D-H).
このセクションはX9.42 Ephemeralの静的なディフィー-ヘルマン(X9.42E-S D-H)とX9.42 Static静的なディフィー-ヘルマン(X9.42 S-S D-H)を使用することで主要な協定をサポートするCMS実装によって使われたコンベンションを指定します。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. Therefore, when key agreement is supported, a key- encryption algorithm MUST be provided for each content-encryption algorithm. The key wrap algorithms for Triple-DES and RC2 are described in RFC 3217 [WRAP].
また、主要な協定アルゴリズムが使用されているとき、主要な暗号化アルゴリズムが必要です。 したがって、主要な協定をサポートするとき、それぞれの満足している暗号化アルゴリズムに主要な暗号化アルゴリズムを提供しなければなりません。 Triple-DESとRC2に、主要な包装アルゴリズムはRFC3217[WRAP]で説明されます。
Housley Standards Track [Page 6] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[6ページ]RFCアルゴリズム2002年8月
For key agreement of RC2 key-encryption keys, 128 bits MUST be generated as input to the key expansion process used to compute the RC2 effective key [RC2].
RC2主要な暗号化キーの主要な協定において、128ビットはRC2の有効なキー[RC2]を計算するのに使用される主要な拡張プロセスに入力されるように発生しているに違いありません。
Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
主要な協定アルゴリズム識別子はEnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmとAuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm分野に位置しています。
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
主要な包装アルゴリズム識別子はEnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmとAuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm分野の中にKeyWrapAlgorithmパラメタに位置しています。
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
包装された満足している暗号化キーはEnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey分野に位置しています。 包装された通報認証キーはAuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey分野に位置しています。
4.1.1 X9.42 Ephemeral-Static Diffie-Hellman
4.1.1 X9.42のはかなく静的なディフィー-ヘルマン
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as follows:
はかなく静的なディフィー-ヘルマン主要な協定はRFC2631[DH-X9.42]で定義されます。 Ephemeral静的なディフィー-ヘルマンを使用するとき、EnvelopedData RecipientInfos KeyAgreeRecipientInfo分野は以下の通り使用されます:
version MUST be 3.
バージョンは3であるに違いありません。
originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the dh-public-number
object identifier with absent parameters. The originatorKey
publicKey field MUST contain the sender's ephemeral public key.
The dh-public-number object identifier is:
創始者はoriginatorKey代替手段であるに違いありません。 originatorKeyアルゴリズム分野は欠けているパラメタがあるdhの公共の番号オブジェクト識別子を含まなければなりません。 originatorKey publicKey分野は送付者のはかない公開鍵を含まなければなりません。 dhの公共の番号オブジェクト識別子は以下の通りです。
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
dhの公共の番号OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。
ukm may be present or absent. CMS implementations MUST support
ukm being absent, and CMS implementations SHOULD support ukm being
present. When present, the ukm is used to ensure that a different
key-encryption key is generated when the ephemeral private key
might be used more than once.
ukmは現在である、または欠けているかもしれません。 CMS実装は、欠けているukm、およびCMS実装SHOULDが存在しているサポートukmであるとサポートしなければなりません。 存在しているとき、ukmは、はかない秘密鍵が一度より使用されるかもしれないとき、異なった主要な暗号化キーが発生しているのを保証するのに使用されます。
Housley Standards Track [Page 7] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[7ページ]RFCアルゴリズム2002年8月
keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
identifier. The algorithm identifier parameter field for id-alg-
ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Ephemeral-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are described in RFC 3217 [WRAP]. The id-alg-ESDH
algorithm identifier and parameter syntax is:
keyEncryptionAlgorithmはイド-alg-ESDHアルゴリズム識別子であるに違いありません。 イド-alg- ESDHのためのアルゴリズム識別子パラメタ分野はKeyWrapAlgorithmです、そして、このパラメタは存在していなければなりません。 対状の主要な暗号化キーが生成されている状態で、KeyWrapAlgorithmは、X9.42 Ephemeral静的なディフィーヘルマンキー協定アルゴリズムを使用することで満足している暗号化キーを暗号化するのに使用される左右対称の暗号化アルゴリズムを指示します。 三重のDESとRC2の主要な包装アルゴリズムはRFC3217[WRAP]で説明されます。 イド-alg-ESDHアルゴリズム識別子とパラメタ構文は以下の通りです。
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 5 }
イド-alg-ESDHオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)5をメンバーと同じくらい具体化させます。
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 public key.
RecipientEncryptedKey EncryptedKey MUST contain the
content-encryption key encrypted with the X9.42 Ephemeral-Static
Diffie-Hellman generated pairwise key-encryption key using the
algorithm specified by the KeyWrapAlgorithm.
recipientEncryptedKeysは各受取人のための識別子と暗号化されたキーを含んでいます。 RecipientEncryptedKey KeyAgreeRecipientIdentifierは受取人の証明書を特定するissuerAndSerialNumberか受取人の証明書からの対象の主要な識別子を含むRecipientKeyIdentifierのどちらかを含まなければなりません。 どちらの場合も、受取人の証明書は受取人の静的な公開鍵を含んでいます。 RecipientEncryptedKey EncryptedKeyはX9.42 Ephemeral静的なディフィー-ヘルマンが対状主要な暗号化キーであると生成されている状態でKeyWrapAlgorithmによって指定されたアルゴリズムを使用することで暗号化された満足している暗号化キーを含まなければなりません。
4.1.2 X9.42 Static-Static Diffie-Hellman
4.1.2 X9.42の静的に静的なディフィー-ヘルマン
Static-Static Diffie-Hellman key agreement is defined in RFC 2631 [DH-X9.42]. When using Static-Static Diffie-Hellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are used as follows:
静的に静的なディフィー-ヘルマン主要な協定はRFC2631[DH-X9.42]で定義されます。 Static静的なディフィー-ヘルマンを使用するとき、EnvelopedData RecipientInfos KeyAgreeRecipientInfoとAuthenticatedData RecipientInfos KeyAgreeRecipientInfo分野は以下の通り使用されます:
version MUST be 3.
バージョンは3であるに違いありません。
originator MUST be either the issuerAndSerialNumber or
subjectKeyIdentifier alternative. In both cases, the originator's
certificate contains the sender's static public key. RFC 3279
[CERTALGS] specifies the AlgorithmIdentifier parameters syntax and
values that are included in the originator's certificate. The
originator's certificate subject public key information field MUST
contain the dh-public-number object identifier:
創始者は、issuerAndSerialNumberかsubjectKeyIdentifier代替手段であるに違いありません。 どちらの場合も、創始者の証明書は送付者の静的な公開鍵を含んでいます。 RFC3279[CERTALGS]は創始者の証明書に含まれているAlgorithmIdentifierパラメタ構文と値を指定します。 創始者の証明書対象公開鍵情報フィールドはdhの公共の番号オブジェクト識別子を含まなければなりません:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
dhの公共の番号OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。
Housley Standards Track [Page 8] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[8ページ]RFCアルゴリズム2002年8月
ukm MUST be present. The ukm ensures that a different key-
encryption key is generated for each message between the same
sender and recipient.
ukmは存在していなければなりません。 ukmは、異なった主要な暗号化キーが同じ送付者と受取人の間の各メッセージのために生成されるのを確実にします。
keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm
identifier. The algorithm identifier parameter field for id-alg-
SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Static-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are described in RFC 3217 [WRAP]. The id-alg-SSDH
algorithm identifier and parameter syntax is:
keyEncryptionAlgorithmはイド-alg-SSDHアルゴリズム識別子であるに違いありません。 イド-alg- SSDHのためのアルゴリズム識別子パラメタ分野はKeyWrapAlgorihtmです、そして、このパラメタは存在していなければなりません。 対状の主要な暗号化キーが生成されている状態で、KeyWrapAlgorithmは、X9.42 Static静的なディフィーヘルマンキー協定アルゴリズムを使用することで満足している暗号化キーを暗号化するのに使用される左右対称の暗号化アルゴリズムを指示します。 三重のDESとRC2の主要な包装アルゴリズムはRFC3217[WRAP]で説明されます。 イド-alg-SSDHアルゴリズム識別子とパラメタ構文は以下の通りです。
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 10 }
イド-alg-SSDHオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)10をメンバーと同じくらい具体化させます。
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 public key.
RecipientEncryptedKey EncryptedKey MUST contain the content-
encryption key encrypted with the X9.42 Static-Static Diffie-
Hellman generated pairwise key-encryption key using the algorithm
specified by the KeyWrapAlgortihm.
recipientEncryptedKeysは各受取人のための識別子と暗号化されたキーを含んでいます。 RecipientEncryptedKey KeyAgreeRecipientIdentifierは受取人の証明書を特定するissuerAndSerialNumberか受取人の証明書からの対象の主要な識別子を含むRecipientKeyIdentifierのどちらかを含まなければなりません。 どちらの場合も、受取人の証明書は受取人の静的な公開鍵を含んでいます。 RecipientEncryptedKey EncryptedKeyはX9.42 Static静的なディフィー・ヘルマンが対状主要な暗号化キーであると生成されている状態でKeyWrapAlgortihmによって指定されたアルゴリズムを使用することで暗号化された内容暗号化キーを含まなければなりません。
4.2 Key Transport Algorithms
4.2 主要な輸送アルゴリズム
This section specifies the conventions employed by CMS implementations that support key transport using RSA (PKCS #1 v1.5).
このセクションはRSA(PKCS#1v1.5)を使用することで主要な輸送をサポートするCMS実装によって使われたコンベンションを指定します。
Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
主要な輸送アルゴリズム識別子はEnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm分野に位置しています。
Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field.
主要な輸送暗号化された満足している暗号化キーはEnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey分野に位置しています。
Housley Standards Track [Page 9] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[9ページ]RFCアルゴリズム2002年8月
4.2.1 RSA (PKCS #1 v1.5)
4.2.1 RSA(PKCS#1v1.5)
The RSA key transport algorithm is the RSA encryption scheme defined in RFC 2313 [PKCS#1], block type is 02, where the message to be encrypted is the content-encryption key. The algorithm identifier for RSA (PKCS #1 v1.5) is:
RSAの主要な輸送アルゴリズムがRFC2313[PKCS#1]で定義されたRSA暗号化体系である、ゴシック体は02歳です。(そこでは、暗号化されるべきメッセージが満足している暗号化キーです)。 RSA(PKCS#1v1.5)のためのアルゴリズム識別子は以下の通りです。
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)1をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL.
AlgorithmIdentifierパラメタ分野は存在していなければなりません、そして、パラメタ分野はNULLを含まなければなりません。
When using a Triple-DES content-encryption key, CMS implementations MUST adjust the parity bits for each DES key comprising the Triple- DES key prior to RSA encryption.
Triple-DES満足している暗号化キーを使用するとき、CMS実装はRSA暗号化の前に主要なTriple- DESを包括するそれぞれのDESキーのためのパリティビットを調整しなければなりません。
The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 [PKCS#1], to provide confidentiality has a known vulnerability. The vulnerability is primarily relevant to usage in interactive applications rather than to store-and-forward environments. Further information and proposed countermeasures are discussed in the Security Considerations section of this document and RFC 3218 [MMA].
RSA(PKCS#1v1.5)暗号化の使用、RFC2313[PKCS#1]で定義されるように、秘密性を提供するのにおいて、知られている脆弱性があります。 脆弱性は主として店とフォワード環境にというよりむしろ対話型アプリケーションにおける用法に関連しています。 このドキュメントとRFC3218[MMA]のSecurity Considerations部で詳細と提案された対策について議論します。
Note that the same RSA encryption scheme is also defined in RFC 2437 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called RSAES-PKCS1-v1_5.
また、同じRSA暗号化体系がRFC2437[NEWPKCS#1]で定義されることに注意してください。 RFC2437の中では、このRSA暗号化体系はRSAES-PKCS1-v1_5と呼ばれます。
4.3 Symmetric Key-Encryption Key Algorithms
4.3 左右対称の主要な暗号化主要なアルゴリズム
This section specifies the conventions employed by CMS implementations that support symmetric key-encryption key management using Triple-DES or RC2 key-encryption keys. When RC2 is supported, RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58. A CMS implementation MAY support mixed key-encryption and content- encryptionalgorithms. For example, a 40-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption key.
このセクションはTriple-DESを使用する左右対称の主要な暗号化かぎ管理かRC2が主要な暗号化キーであるとサポートするCMS実装によって使われたコンベンションを指定します。 RC2がサポートされるとき、主要な暗号化キーとしてRC2の128ビットのキーを使用しなければなりません、そして、RC2ParameterVersionパラメタセットと共にそれらを58まで使用しなければなりません。 CMS実装は複雑な主要な暗号化と内容encryptionalgorithmsをサポートするかもしれません。例えば、40ビットのRC2満足している暗号化キーは168ビットのTriple-DES主要な暗号化キーか128ビットのRC2主要な暗号化キーで包装されるかもしれません。
Key wrap algorithm identifiers are located in the EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm fields.
主要な包装アルゴリズム識別子はEnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithmとAuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm分野に位置しています。
Housley Standards Track [Page 10] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[10ページ]RFCアルゴリズム2002年8月
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey field.
包装された満足している暗号化キーはEnvelopedData RecipientInfos KEKRecipientInfo encryptedKey分野に位置しています。 包装された通報認証キーはAuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey分野に位置しています。
The output of a key agreement algorithm is a key-encryption key, and this key-encryption key is used to encrypt the content-encryption key. To support key agreement, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. However, only key agreement algorithms that inherently provide authentication ought to be used with AuthenticatedData. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, wrapped message- authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
主要な協定アルゴリズムの出力は主要な暗号化キーです、そして、この主要な暗号化キーは、満足している暗号化キーを暗号化するのに使用されます。 主要な協定をサポートするために、主要な包装アルゴリズム識別子はEnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithmとAuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm分野のKeyWrapAlgorithmパラメタに位置しています。 しかしながら、本来認証を提供する主要な協定アルゴリズムだけがAuthenticatedDataと共に使用されるべきです。 包装された満足している暗号化キーはEnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey分野に位置していて、包装されたメッセージ認証キーはAuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey分野に位置しています。
4.3.1 Triple-DES Key Wrap
4.3.1 三重のDESの主要な包装
A CMS implementation MAY support mixed key-encryption and content- encryption algorithms. For example, a 128-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key.
CMS実装は複雑な主要な暗号化と内容暗号化アルゴリズムをサポートするかもしれません。例えば、128ビットのRC2満足している暗号化キーは168ビットのTriple-DES主要な暗号化キーで包装されるかもしれません。
Triple-DES key encryption has the algorithm identifier:
三重のDESの主要な暗号化には、アルゴリズム識別子があります:
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
イド-alg-CMS3DESwrapオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)6をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifierパラメタ分野はNULLであるに違いありません。
The key wrap algorithm used to encrypt a Triple-DES content- encryption key with a Triple-DES key-encryption key is specified in section 3.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified in section 3.2 of RFC 3217 [WRAP].
Triple-DES主要な暗号化キーによって主要なTriple-DES満足している暗号化を暗号化するのに使用される主要な包装アルゴリズムはRFC3217[WRAP]のセクション3.1で指定されます。 対応するキーはアルゴリズムを開けます。セクション3.2のRFC3217[WRAP]では、指定されます。
Out-of-band distribution of the Triple-DES key-encryption key used to encrypt the Triple-DES content-encryption key is beyond the scope of this document.
バンドの外では、Triple-DES満足している暗号化キーを暗号化するのに使用されるTriple-DES主要な暗号化キーの分配はこのドキュメントの範囲を超えています。
Housley Standards Track [Page 11] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[11ページ]RFCアルゴリズム2002年8月
4.3.2 RC2 Key Wrap
4.3.2 RC2の主要な包装
A CMS implementation MAY support mixed key-encryption and content- encryption algorithms. For example, a 128-bit RC2 content-encryption key MAY be wrapped with a 168-bit Triple-DES key-encryption key. Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with a 128-bit RC2 key-encryption key.
CMS実装は複雑な主要な暗号化と内容暗号化アルゴリズムをサポートするかもしれません。例えば、128ビットのRC2満足している暗号化キーは168ビットのTriple-DES主要な暗号化キーで包装されるかもしれません。 同様に、40ビットのRC2満足している暗号化キーは128ビットのRC2主要な暗号化キーで包装されるかもしれません。
RC2 key encryption has the algorithm identifier:
RC2の主要な暗号化には、アルゴリズム識別子があります:
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
イド-alg-CMSRC2wrapオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)7をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:
AlgorithmIdentifierパラメタ分野はRC2wrapParameterであるに違いありません:
RC2wrapParameter ::= RC2ParameterVersion
RC2wrapParameter:、:= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
RC2ParameterVersion:、:= 整数
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the RC2ParameterVersion. For the effective-key- bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), because the one octet (A0) encoding represents a negative number.
32以上の(主要なサイズ)と256RC2有効なキービットはRC2ParameterVersionでコード化されます。 rc2ParameterVersion値は、それぞれ40、64、および128の有効に主要なビット単位で、160と、120と、58です。 これらの値は単にRC2キー長ではありません。 2つの八重奏(00A0)として値160をコード化しなければならないことに注意してください、1つの八重奏(A0)のコード化が負数を表すので。
RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be used with the RC2ParameterVersion parameter set to 58.
主要な暗号化キーとしてRC2の128ビットのキーを使用しなければなりません、そして、RC2ParameterVersionパラメタセットと共にそれらを58まで使用しなければなりません。
The key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2 key-encryption key is specified in section 4.1 of RFC 3217 [WRAP]. The corresponding key unwrap algorithm is specified 4.2 of RFC 3217 [WRAP].
RC2主要な暗号化キーによって主要なRC2満足している暗号化を暗号化するのに使用される主要な包装アルゴリズムはRFC3217[WRAP]のセクション4.1で指定されます。 対応するキーはアルゴリズムを開けます。RFC3217[WRAP]について4.2に指定されます。
Out-of-band distribution of the RC2 key-encryption key used to encrypt the RC2 content-encryption key is beyond of the scope of this document.
バンドの外では、RC2満足している暗号化キーを暗号化するのに使用されるRC2主要な暗号化キーの分配は向こうのこのドキュメントの範囲のものです。
4.4 Key Derivation Algorithms
4.4 主要な誘導アルゴリズム
This section specifies the conventions employed by CMS implementations that support password-based key management using PBKDF2.
このセクションはPBKDF2を使用することでパスワードを拠点とするかぎ管理をサポートするCMS実装によって使われたコンベンションを指定します。
Key derivation algorithms are used to convert a password into a key- encryption key as part of the password-based key management technique.
主要な誘導アルゴリズムは、パスワードベースのかぎ管理のテクニックの一部として主要な主要な暗号化にパスワードを変換するのに使用されます。
Housley Standards Track [Page 12] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[12ページ]RFCアルゴリズム2002年8月
Key derivation algorithm identifiers are located in the EnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and AuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm fields.
主要な誘導アルゴリズム識別子はEnvelopedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithmとAuthenticatedData RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm分野に位置しています。
The key-encryption key that is derived from the password is used to encrypt the content-encryption key.
パスワードから得られる主要な暗号化キーは、満足している暗号化キーを暗号化するのに使用されます。
The content-encryption keys encrypted with password-derived key- encryption keys are located in the EnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey field. The message-authentication keys encrypted with password-derived key-encryption keys are located in the AuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey field.
パスワードで派生している主要な暗号化キーで暗号化された満足している暗号化キーはEnvelopedData RecipientInfos PasswordRecipientInfo encryptedKey分野に位置しています。 パスワードで派生している主要な暗号化キーで暗号化された通報認証キーはAuthenticatedData RecipientInfos PasswordRecipientInfo encryptedKey分野に位置しています。
4.4.1 PBKDF2
4.4.1 PBKDF2
The PBKDF2 key derivation algorithm is specified in RFC 2898 [PKCS#5]. The KeyDerivationAlgorithmIdentifer identifies the key- derivation algorithm, and any associated parameters used to derive the key-encryption key from the user-supplied password. The algorithm identifier for the PBKDF2 key derivation algorithm is:
PBKDF2の主要な誘導アルゴリズムはRFC2898[PKCS#5]で指定されます。 KeyDerivationAlgorithmIdentiferは主要な誘導アルゴリズム、およびユーザによって与えられたパスワードから主要な主要な暗号化を引き出すのに使用されるどんな関連パラメタも特定します。 PBKDF2の主要な誘導アルゴリズムのためのアルゴリズム識別子は以下の通りです。
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
イド-PBKDF2オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-5(5)12をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameter field MUST be PBKDF2-params:
AlgorithmIdentifierパラメタ分野はPBKDF2-paramsであるに違いありません:
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
PBKDF2-params:、:= 系列塩のCHOICEはOCTET STRING、otherSource AlgorithmIdentifierを指定しました、iterationCount INTEGER(1..MAX)、keyLength INTEGER(1..MAX)OPTIONAL、prf AlgorithmIdentifier DEFAULT、アルゴリズムhMAC-SHA1、パラメタNULL
Within the PBKDF2-params, the salt MUST use the specified OCTET STRING.
PBKDF2-paramsの中では、塩は指定されたOCTET STRINGを使用しなければなりません。
5 Content Encryption Algorithms
5 満足している暗号化アルゴリズム
This section specifies the conventions employed by CMS implementations that support content encryption using Three-Key Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC mode.
このセクションは内容が暗号化のCBCモードでThree主要なTriple-DESを使用するか、CBCモードによるTwo主要なTriple-DES、またはCBCモードでRC2であるとサポートするCMS実装によって使われたコンベンションを指定します。
Housley Standards Track [Page 13] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[13ページ]RFCアルゴリズム2002年8月
Content encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.
満足している暗号化アルゴリズム識別子はEnvelopedData EncryptedContentInfo contentEncryptionAlgorithmとEncryptedData EncryptedContentInfo contentEncryptionAlgorithm分野に位置しています。
Content encryption algorithms are used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent field.
満足している暗号化アルゴリズムは、EnvelopedData EncryptedContentInfo encryptedContent分野とEncryptedData EncryptedContentInfo encryptedContent分野に位置する内容を暗号化するのに使用されます。
5.1 Triple-DES CBC
5.1 三重のDES CBC
The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The Triple-DES is composed from three sequential DES [DES] operations: encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different key for each DES operation. Two-Key Triple-DES uses one key for the two encrypt operations and a different key for the decrypt operation. The same algorithm identifiers are used for Three-Key Triple-DES and Two-Key Triple-DES. The algorithm identifier for Triple-DES in Cipher Block Chaining (CBC) mode is:
Triple-DESアルゴリズムはANSI X9.52[3DES]で説明されます。 Triple-DESは3連続したDES[DES]の操作から構成されます: 暗号化して、解読して、暗号化します。 3主要なTriple-DESはそれぞれのDES操作に異なったキーを使用します。 2のためのあるキーが操作と異なったキーを暗号化する2主要なTriple-DES用途、操作を解読してください。 同じアルゴリズム識別子はThree主要なTriple-DESとTwo主要なTriple-DESに使用されます。 Cipher Block Chaining(CBC)モードによるTriple-DESのためのアルゴリズム識別子は以下の通りです。
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) encryptionAlgorithm(3)7をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a CBCParameter:
AlgorithmIdentifierパラメタ分野は存在していなければなりません、そして、パラメタ分野はCBCParameterを含まなければなりません:
CBCParameter ::= IV
CBCParameter:、:= IV
IV ::= OCTET STRING -- exactly 8 octets
IV:、:= OCTET STRING--まさに8つの八重奏
5.2 RC2 CBC
5.2 RC2 CBC
The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm identifier for RC2 in CBC mode is:
RC2アルゴリズムはRFC2268[RC2]で説明されます。 CBCモードによるRC2のためのアルゴリズム識別子は以下の通りです。
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
rc2-cbc OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) encryptionAlgorithm(3)2をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a RC2CBCParameter:
AlgorithmIdentifierパラメタ分野は存在していなければなりません、そして、パラメタ分野はRC2CBCParameterを含まなければなりません:
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
RC2CBCParameter:、:= SEQUENCE、rc2ParameterVersion INTEGER、iv OCTET STRING--、まさに8つの八重奏
Housley Standards Track [Page 14] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[14ページ]RFCアルゴリズム2002年8月
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the rc2ParameterVersion. For the effective-key- bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), since the one octet (A0) encoding represents a negative number.
32以上の(主要なサイズ)と256RC2有効なキービットはrc2ParameterVersionでコード化されます。 rc2ParameterVersion値は、それぞれ40、64、および128の有効に主要なビット単位で、160と、120と、58です。 これらの値は単にRC2キー長ではありません。 2つの八重奏(00A0)として値160をコード化しなければならないことに注意してください、1つの八重奏(A0)のコード化が負数を表すので。
6 Message Authentication Code Algorithms
6 メッセージ立証コードアルゴリズム
This section specifies the conventions employed by CMS implementations that support the HMAC with SHA-1 message authentication code (MAC).
このセクションはSHA-1メッセージ確認コード(MAC)でHMACをサポートするCMS実装によって使われたコンベンションを指定します。
MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field.
MACアルゴリズム識別子はAuthenticatedData macAlgorithm分野に位置しています。
MAC values are located in the AuthenticatedData mac field.
MAC値はAuthenticatedData mac分野に位置しています。
6.1 HMAC with SHA-1
6.1 SHA-1とHMAC
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The algorithm identifier for HMAC with SHA-1 is:
SHA-1アルゴリズムがあるHMACはRFC2104[HMAC]で説明されます。 SHA-1とHMACのためのアルゴリズム識別子は以下の通りです。
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) 8 1 2 }
hMAC-SHA1オブジェクト識別子:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティが特定された(5)メカニズム(5)8 1 2
There are two possible encodings for the HMAC with SHA-1 AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for the AlgorithmIdentifier type 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 may encode parameters as a NULL while others omit them entirely.
SHA-1 AlgorithmIdentifierパラメタがあるHMACのための可能なencodingsがさばく2があります。 2つの選択肢がAlgorithmIdentifierタイプのための1988年の構文が1997年の構文に翻訳されたとき、AlgorithmIdentifierパラメタに関連しているOPTIONALが失せたという事実から起こります。 その後、OPTIONALは不具合報告で回収されましたが、次にそのアルゴリズムであると考えられた多くの人々で、パラメタは義務的でした。 この歴史のために、他のものが彼らを完全に省略している間、いくつかの実装がNULLとしてパラメタをコード化するかもしれません。
The AlgorithmIdentifier parameters field is OPTIONAL. If present, the parameters field MUST contain a NULL. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with absent parameters. Implementations MUST accept HMAC with SHA-1 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate HMAC with SHA-1 AlgorithmIdentifiers with absent parameters.
AlgorithmIdentifierパラメタ分野はOPTIONALです。 存在しているなら、パラメタ分野はNULLを含まなければなりません。 実装は欠けているパラメタがあるSHA-1 AlgorithmIdentifiersとHMACを受け入れなければなりません。 実装はNULLパラメタがあるSHA-1 AlgorithmIdentifiersとHMACを受け入れなければなりません。 実装SHOULDは欠けているパラメタがあるSHA-1 AlgorithmIdentifiersとHMACを生成します。
Housley Standards Track [Page 15] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[15ページ]RFCアルゴリズム2002年8月
7 ASN.1 Module
7 ASN.1モジュール
CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
CryptographicMessageSyntaxAlgorithmsiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cmsalg-2001(16)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
-- EXPORTS All -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes.
-- EXPORTS All--このモジュールで定義されたタイプと値は他のASN.1モジュールにおける使用のためにエクスポートされます。 アプリケーションがそれらを使用するかもしれないもう一方--それら自身の目的。
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } ;
IMPORTS--RFC3280[PROFILE]からの輸入、Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)モッズ(0)pkix1明白な(18)。
-- Algorithm Identifiers
-- アルゴリズム識別子
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(2)26
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
md5 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) digestAlgorithm(2)5をメンバーと同じくらい具体化させます。
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9cm(4) 1 }
イド-dsa OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)x9-57(10040) x9cm(4)1をメンバーと同じくらい具体化させます。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57(10040) x9cm(4) 3 }
sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(840)x9-57(10040) x9cm(4)3をメンバーと同じくらい具体化させます。
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
rsaEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)1をメンバーと同じくらい具体化させます。
md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
md5WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)4をメンバーと同じくらい具体化させます。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
sha1WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)5をメンバーと同じくらい具体化させます。
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
dhの公共の番号OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。
Housley Standards Track [Page 16] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[16ページ]RFCアルゴリズム2002年8月
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
イド-alg-ESDHオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)5をメンバーと同じくらい具体化させます。
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
イド-alg-SSDHオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)10をメンバーと同じくらい具体化させます。
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
イド-alg-CMS3DESwrapオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)6をメンバーと同じくらい具体化させます。
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
イド-alg-CMSRC2wrapオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)7をメンバーと同じくらい具体化させます。
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) encryptionAlgorithm(3)7をメンバーと同じくらい具体化させます。
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
rc2-cbc OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) encryptionAlgorithm(3)2をメンバーと同じくらい具体化させます。
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
hMAC-SHA1オブジェクト識別子:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティが特定された(5)メカニズム(5)8 1 2
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
イド-PBKDF2オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-5(5)12をメンバーと同じくらい具体化させます。
-- Public Key Types
-- 公開鍵タイプ
Dss-Pub-Key ::= INTEGER -- Y
Dssパブキー:、:= 整数--Y
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
RSAPublicKey:、:= SEQUENCE、係数INTEGER--、n publicExponent INTEGER、--、e
DHPublicKey ::= INTEGER -- y = g^x mod p
DHPublicKey:、:= INTEGER--yはg^xモッズpと等しいです。
-- Signature Value Types
-- 署名値のタイプ
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
-- Algorithm Identifier Parameter Types
-- アルゴリズム識別子パラメータの型
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER
Housley Standards Track [Page 17] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[17ページ]RFCアルゴリズム2002年8月
DHDomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor
validationParms ValidationParms OPTIONAL }
DHDomainParameters:、:= 系列p INTEGER--奇素数、+1gのINTEGER(ジェネレータ、g q INTEGER)が因数分解するp-1j INTEGER OPTIONALのp=jq--サブグループ要素validationParms ValidationParms OPTIONAL
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
ValidationParms:、:= 系列種子BIT STRING、pgenCounter INTEGER
KeyWrapAlgorithm ::= AlgorithmIdentifier
KeyWrapAlgorithm:、:= AlgorithmIdentifier
RC2wrapParameter ::= RC2ParameterVersion
RC2wrapParameter:、:= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
RC2ParameterVersion:、:= 整数
CBCParameter ::= IV
CBCParameter:、:= IV
IV ::= OCTET STRING -- exactly 8 octets
IV:、:= OCTET STRING--まさに8つの八重奏
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets
RC2CBCParameter:、:= SEQUENCE、rc2ParameterVersion INTEGER、iv OCTET STRING--、まさに8つの八重奏
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
PBKDF2-params:、:= 系列塩のCHOICEはOCTET STRING、otherSource AlgorithmIdentifierを指定しました、iterationCount INTEGER(1..MAX)、keyLength INTEGER(1..MAX)OPTIONAL、prf AlgorithmIdentifier DEFAULT、アルゴリズムhMAC-SHA1、パラメタNULL
END -- of CryptographicMessageSyntaxAlgorithms
終わり--CryptographicMessageSyntaxAlgorithmsについて
8 References
8つの参照箇所
[3DES] American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation.
1998.
[3DES]American National Standards Institut。 ANSI X9.52-1998、データ暗号化アルゴリズム運転モードを3倍にしてください。 1998.
[CERTALGS] Bassham, L., Housley, R. and W. Polk, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[CERTALGS] Bassham、L.、Housley、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
Housley Standards Track [Page 18] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[18ページ]RFCアルゴリズム2002年8月
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3269,
August 2002.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC3269、2002年8月。
[DES] American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems -
Data Link Encryption". 1983.
[DES]American National Standards Institut。 ANSI X3.106、「情報システムのための米国標準規格--データは暗号化をリンクします」。 1983.
[DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[DH-X9.42] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。
[DSS] National Institute of Standards and Technology. FIPS Pub
186: Digital Signature Standard. 19 May 1994.
[DSS]米国商務省標準技術局。 FIPSパブ186: デジタル署名基準。 1994年5月19日。
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk、H.、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[MMA] Rescorla, E., "Preventing the Million Message Attack on
CMS", RFC 3218, January 2002.
[MMA] レスコラ、E.、「cmに対する100万メッセージ攻撃を防ぎます」、RFC3218、2002年1月。
[MODES] National Institute of Standards and Technology. FIPS Pub
81: DES Modes of Operation. 2 December 1980.
[モード]米国商務省標準技術局。 FIPSパブ81: DES運転モード。 1980年12月2日。
[NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Encryption,
Version 2.0, RFC 2437, October 1998.
[NEWPKCS#1]のKaliski、B.、およびJ.Staddon、「PKCS#1:」 RSA暗号化、バージョン2.0、RFC2437、1998年10月。
[OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[OLDCMS]Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[PKCS#1] Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC
2437, October, 1998.
[PKCS#1]Kaliski、B、「PKCS#1:」 RSA暗号化、バージョン2インチ、RFC2437、1998年10月。
[PKCS#5] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification", RFC 2898, September 2000.
[PKCS#5]Kaliski、B.、「PKCS#5:」 「パスワードベースの暗号仕様」、RFC2898、2000年9月。
[PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[プロフィール]HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security, RFC 1750, December 1994.
[無作為の] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティ、RFC1750、1994年12月のための偶発性推薦。」
[RC2] Rivest, R., "A Description of the RC2 (r) Encryption
Algorithm", RFC 2268, March 1998.
[RC2] Rivest、R.、「RC2(r)暗号化アルゴリズムの記述」、RFC2268、1998年3月。
Housley Standards Track [Page 19] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[19ページ]RFCアルゴリズム2002年8月
[SHA1] National Institute of Standards and Technology. FIPS Pub
180-1: Secure Hash Standard. 17 April 1995.
[SHA1]米国商務省標準技術局。 FIPSパブ180-1: ハッシュ規格を保証してください。 1995年4月17日。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001.
[包装します] Housley、R.、「三重のDESとRC2の主要なラッピング」、RFC3217、2001年12月。
[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.
9 Security Considerations
9 セキュリティ問題
The CMS provides a method for digitally signing data, digesting data, encrypting data, and authenticating data. This document identifies the conventions for using several cryptographic algorithms for use with the CMS.
データを暗号化して、データを認証して、CMSはデータを読みこなして、データにデジタルに署名するためのメソッドを提供します。 このドキュメントは、CMSとの使用にいくつかの暗号アルゴリズムを使用するためにコンベンションを特定します。
Implementations must protect the signer's private key. Compromise of the signer's private key permits masquerade.
実装は署名者の秘密鍵を保護しなければなりません。 署名者の秘密鍵の感染は仮面舞踏会を可能にします。
Implementations must protect the key management private key, the key-encryption key, and the content-encryption key. Compromise of the key management private key or the key-encryption key may result in the disclosure of all contents protected with that key. Similarly, compromise of the content-encryption key may result in disclosure of the associated encrypted content.
実装はかぎ管理秘密鍵、主要な暗号化キー、および満足している暗号化キーを保護しなければなりません。 かぎ管理秘密鍵か主要な暗号化キーの感染はそのキーで保護されたすべてのコンテンツの公開をもたらすかもしれません。 同様に、満足している暗号化キーの感染は関連暗号化された内容の公開をもたらすかもしれません。
Implementations must protect the key management private key and the message-authentication key. Compromise of the key management private key permits masquerade of authenticated data. Similarly, compromise of the message-authentication key may result in undetectable modification of the authenticated content.
実装はかぎ管理秘密鍵と通報認証キーを保護しなければなりません。 かぎ管理秘密鍵の感染は認証されたデータの仮面舞踏会を可能にします。 同様に、通報認証キーの感染は認証された内容の検知されない変更をもたらすかもしれません。
The key management technique employed to distribute message- authentication keys must itself provide authentication, otherwise the content is delivered with integrity from an unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH- X9.42] provide the necessary data origin authentication. Static- Static Diffie-Hellman [DH-X9.42] does provide the necessary data origin authentication when both the originator and recipient public keys are bound to appropriate identities in X.509 certificates [PROFILE].
それ自体でキーが広げなければならないメッセージ認証を広げるのに使われたかぎ管理のテクニックは認証を提供します。さもなければ、内容は保全で未知の情報源から提供されます。 RSA[PKCS#1、NEWPKCS#1]もEphemeral静的なディフィー-ヘルマン[DH- X9.42]も必要なデータ発生源認証を提供しません。 創始者と受取人公開鍵の両方が必ずX.509証明書[PROFILE]でアイデンティティを当てるとき、静的な静的なディフィー-ヘルマン[DH-X9.42]は必要なデータ発生源認証を提供します。
Housley Standards Track [Page 20] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[20ページ]RFCアルゴリズム2002年8月
When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties.
2回以上のパーティーが同じ通報認証キーを共有するとき、データ発生源認証は提供されません。 通報認証キーを知っているどんなパーティーも有効なMACを計算できます、したがって、内容はパーティーのいずれからも発するかもしれません。
Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), one-time values (such as the k value when generating a DSA signature), and padding. Also, the generation of public/private key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic such values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 1750 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
実装は手当たりしだいに満足している暗号化キー、通報認証キー、初期化ベクトル(IVs)、1回の値(kとしてのそのようなものはDSA署名を生成しながら、いつを評価する)、および詰め物を生成しなければなりません。 また、公衆/秘密鍵組の世代は乱数を当てにします。 暗号のそのようなものが値であると生成する不十分な疑似乱数生成器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、キーを生産したPRNG環境を再生させるのがはるかに簡単であることがわかるかもしれません、全体の主要なスペースを捜す馬鹿力よりむしろ結果として起こる小さい可能性を捜して。 上質の乱数の世代は難しいです。 RFC1750[RANDOM]はこの領域で重要な指導を提供します、そして、FIPS Pub186[DSS]のAppendix3は1つの上質のPRNGのテクニックを提供します。
When using key agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with 168-bit Triple-DES and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms.
主要な協定アルゴリズムか以前に分配された左右対称の主要な暗号化キーを使用するとき、主要な暗号化キーは、満足している暗号化キーを暗号化するのに使用されます。 主要な暗号化と満足している暗号化アルゴリズムが異なるなら、有効なセキュリティは2つのアルゴリズムについて、より弱いことで決定します。例えば、内容が168ビットのTriple-DESと共に暗号化されて、Triple-DES満足している暗号化キーが40ビットのRC2キーで包装されるなら、高々保護の40ビットしか提供されません。 内容を解読するのに40ビットのRC2キーの値はTriple-DESキーを回収して、次に、Triple-DESキーを回収できることを決定する些細な検索を使用できます。 したがって、implementersは主要な暗号化アルゴリズムが確実に同じくらい強いか満足している暗号化アルゴリズムより強くなるようにしなければなりません。
RFC 3217 [WRAP] specifies key wrap algorithms used to encrypt a Triple-DES content-encryption key with a Triple-DES key-encryption key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key-encryption key [RC2]. The key wrap algorithms makes use of CBC mode [MODES]. These key wrap algorithms have been reviewed for use with Triple-DES and RC2. They have not been reviewed for use with other cryptographic modes or other encryption algorithms. Therefore, if a CMS implementation wishes to support ciphers in addition to Triple-DES or RC2, then additional key wrap algorithms need to be defined to support the additional ciphers.
RFC3217[WRAP]はアルゴリズムがTriple-DES主要な暗号化キー[3DES]によって主要なTriple-DES満足している暗号化を暗号化するか、またはRC2主要な暗号化キー[RC2]によって主要なRC2満足している暗号化を暗号化するのに使用した主要な包装を指定します。 主要な包装アルゴリズムはCBCモード[MODES]を利用します。 これらの主要な包装アルゴリズムはTriple-DESとRC2との使用のために見直されました。 それらは使用のために他の暗号のモードか他の暗号化アルゴリズムで見直されていません。したがって、Triple-DESかRC2に加えた暗号をサポートするというCMS実装願望であるなら、追加主要な包装アルゴリズムは、追加暗号をサポートするために定義される必要があります。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic
Implementersは時間に従って暗号アルゴリズムが、より弱くなるのを意識しているべきです。 新しい暗号文解読術のテクニックが開発されていて、性能を計算するのが向上するのに従って、特定の暗号アルゴリズムを破るワーク・ファクタは減少するでしょう。 したがって、暗号
Housley Standards Track [Page 21] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[21ページ]RFCアルゴリズム2002年8月
algorithm implementations should be modular allowing new algorithms to be readily inserted. That is, implementers should be prepared to regularly update the set of algorithms in their implementations.
新しいアルゴリズムが容易に挿入されるのを許容することにおいてアルゴリズム実装はモジュールであるべきです。 すなわち、implementersは定期的にそれらの実装におけるアルゴリズムのセットをアップデートするように準備されるべきです。
Users of the CMS, particularly those employing the CMS to support interactive applications, should be aware that RSA (PKCS #1 v1.5), as specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen ciphertext attacks when applied for encryption purposes. Exploitation of this identified vulnerability, revealing the result of a particular RSA decryption, requires access to an oracle which will respond to a large number of ciphertexts (based on currently available results, hundreds of thousands or more), which are constructed adaptively in response to previously-received replies providing information on the successes or failures of attempted decryption operations. As a result, the attack appears significantly less feasible to perpetrate for store-and-forward S/MIME environments than for directly interactive protocols. Where the CMS constructs are applied as an intermediate encryption layer within an interactive request-response communications environment, exploitation could be more feasible.
CMSのユーザ(特に対話型アプリケーションをサポートするのにCMSを使うもの)は暗号化目的のために適用されるとRFC2313[PKCS#1]で指定されるRSA(PKCS#1v1.5)が適応型の選ばれた暗号文攻撃に被害を受け易いのを意識しているべきです。 特定のRSA復号化の結果を明らかにして、この特定された脆弱性の攻略は適応型に試みられた復号化操作の成功か失敗の情報を提供する以前に容認された回答に対応して構成される多くの暗号文(現在利用可能な結果、何十万または以上に基づいている)に応じる神託へのアクセスを必要とします。 その結果、攻撃は直接対話的なプロトコルよりかなり店とフォワードS/MIME環境のために犯すのにおいて可能でなく見えます。 CMS構造物が中間的暗号化層として対話的な要求応答コミュニケーション環境の中で適用されるところでは、攻略は、より可能であるかもしれません。
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1 Version 2.0 preserves support for the encryption padding format defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 Version 2.0 specifies and recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption is used to provide confidentiality. Designers of protocols and systems employing CMS for interactive environments should either consider usage of OAEP, or should ensure that information which could reveal the success or failure of attempted PKCS #1 Version 1.5 decryption operations is not provided. Support for OAEP will likely be added to a future version of the CMS algorithm specification.
PKCS#1のアップデートされたバージョンは発行されて、PKCS#は1つのバージョン2.0です[NEWPKCS#1]。 このアップデートされたドキュメントはRFC2313に取って代わります。 PKCS#1バージョン2.0はPKCS#1バージョン1.5[PKCS#1]で定義された書式を水増しする暗号化のサポートを保存します、そして、また、それは新しい代替手段を定義します。 RSA暗号化が秘密性を提供するのに使用されるとき、PKCS#1バージョン2.0は、適応型の選ばれた暗号文脆弱性を決議するために、Optimal Asymmetric Encryption Padding(OAEP)の使用を指定して、推薦します。 対話的な環境でCMSを使うプロトコルとシステムのデザイナーは、OAEPの使用法を考えるべきであるか、または1.5の復号化操作が提供されない試みられたPKCS#1バージョンの成否を明らかにすることができたその情報を確実にするべきです。 OAEPのサポートはおそらくCMSアルゴリズム仕様の将来のバージョンに追加されるでしょう。
See RFC 3218 [MMA] for more information about thwarting the adaptive chosen ciphertext vulnerability in PKCS #1 Version 1.5 implementations.
PKCS#で適応型の選ばれた暗号文脆弱性を阻んで、周囲で詳しい情報のためのRFC3218[MMA]を見てください。1つのバージョンの1.5の実装。
10 Acknowledgments
10の承認
This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave Solo for their efforts and support.
このドキュメントは多くの専門家からの貢献の結果です。 私はIETF S/MIME作業部会のすべてのメンバーのきつい仕事に感謝します。 私はリッシュAnkney、サイモン・ブレーク-ウィルソン、ティム・ディーン、スティーブDusse、カール・エリソン、ピーター・ガットマン、ボブJueneman、スティーブン・ヘンソン、ポール・ホフマン、スコットHollenbeck、ドン・ジョンソン、バートKaliski、ジョン・リン、ジョンPawling、ブレークRamsdell、フランソア・ルソー、ジムSchaad、およびデーヴSoloのおかげで彼らの取り組みとサポートのために特別番組を広げます。
Housley Standards Track [Page 22] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[22ページ]RFCアルゴリズム2002年8月
11 Author Address
11 作者アドレス
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 EMail: rhousley@rsasecurity.com
ラッセルHousley RSA研究所918は小山Driveハーンドンを跳ばせて、ヴァージニア 20170はメールされます: rhousley@rsasecurity.com
Housley Standards Track [Page 23] RFC 3370 CMS Algorithms August 2002
3370cmのHousley標準化過程[23ページ]RFCアルゴリズム2002年8月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Housley Standards Track [Page 24]
Housley標準化過程[24ページ]
一覧
スポンサーリンク
