RFC5349 日本語訳
5349 Elliptic Curve Cryptography (ECC) Support for Public KeyCryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu,K. Jaganathan, K. Lauter. September 2008. (Format: TXT=19706 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Zhu
Request for Comments: 5349 K. Jaganathan
Category: Informational K. Lauter
Microsoft Corporation
September 2008
コメントを求めるワーキンググループL.朱の要求をネットワークでつないでください: 5349年のK.Jaganathanカテゴリ: 情報のK.ローターマイクロソフト社2008年9月
Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography
for Initial Authentication in Kerberos (PKINIT)
ケルベロスにおける初期の認証のための公開鍵暗号の楕円曲線暗号(ECC)サポート(PKINIT)
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 describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography.
このドキュメントはElliptic Curve証明書の使用について説明します、PKINITのフレームワークの中のElliptic Curve署名体系とElliptic Curveディフィー-ヘルマン(ECDH)の主要な協定--公開鍵暗号の使用に備えるケルベロスバージョン5拡大。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Using Elliptic Curve Certificates and Elliptic Curve
Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . 2
4. Using the ECDH Key Exchange . . . . . . . . . . . . . . . . . . 3
5. Choosing the Domain Parameters and the Key Size . . . . . . . . 4
6. Interoperability Requirements . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コンベンションは本書では.2 3を使用しました。 楕円曲線証明書と楕円曲線署名体系. . . . . . . . . . . . . . . . . . . . . . . 2 4を使用します。 ECDHの主要な交換. . . . . . . . . . . . . . . . . . 3 5を使用します。 ドメインパラメタと主要なサイズ. . . . . . . . 4 6を選びます。 相互運用性要件. . . . . . . . . . . . . . . . . 6 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 7 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 7 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 8
Zhu, et al. Informational [Page 1] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[1ページ]のRFC5349ECCサポート
1. Introduction
1. 序論
Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem that provides security equivalent to currently popular public-key mechanisms such as RSA and DSA with smaller key sizes [LENSTRA] [NISTSP80057].
楕円形のCurve Cryptography(ECC)は、より小さい主要なサイズ[LENSTRA][NISTSP80057]のためにRSAやDSAなどの現在ポピュラーな公開鍵メカニズムに同等なセキュリティを提供する魅力的な公開鍵暗号系として現れています。
Currently, [RFC4556] permits the use of ECC algorithms but it does not specify how ECC parameters are chosen or how to derive the shared key for key delivery using Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363] [X9.63].
現在、[RFC4556]はECCアルゴリズムの使用を可能にしますが、それはECCパラメタがどのように選ばれているか、そして、またはElliptic Curveディフィー-ヘルマン(ECDH)[IEEE1363][X9.63]を使用することで主要な配送のための共有されたキーを引き出す方法を指定しません。
This document describes how to use Elliptic Curve certificates, Elliptic Curve signature schemes, and ECDH with [RFC4556]. However, it should be noted that there is no syntactic or semantic change to the existing [RFC4556] messages. Both the client and the Key Distribution Center (KDC) contribute one ECDH key pair using the key agreement protocol described in this document.
このドキュメントは[RFC4556]と共にElliptic Curve証明書、Elliptic Curve署名体系、およびECDHを使用する方法を説明します。 しかしながら、既存の[RFC4556]メッセージへのどんな構文の、または、意味の変化もないことに注意されるべきです。 クライアントとKey Distributionセンターの両方(KDC)が、本書では説明された主要な協定プロトコルを使用することで主要な1ECDH組を寄付します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Using Elliptic Curve Certificates and Elliptic Curve Signature
Schemes
3. 楕円曲線証明書と楕円曲線署名体系を使用します。
ECC certificates and signature schemes can be used in the Cryptographic Message Syntax (CMS) [RFC3852] [RFC3278] content type 'SignedData'.
Cryptographic Message Syntax(CMS)[RFC3852][RFC3278]content type'SignedData'でECC証明書と署名体系を使用できます。
X.509 certificates [RFC5280] that contain ECC public keys or are signed using ECC signature schemes MUST comply with [RFC3279].
ECC公開鍵を含んでいるか、またはECC署名体系を使用することで署名されるX.509証明書[RFC5280]は[RFC3279]に従わなければなりません。
The signatureAlgorithm field of the CMS data type 'SignerInfo' can contain one of the following ECC signature algorithm identifiers:
'SignerInfo'というCMSデータ型のsignatureAlgorithm分野は以下のECC署名アルゴリズム識別子の1つを含むことができます:
ecdsa-with-Sha1 [RFC3279]
ecdsa-with-Sha256 [X9.62]
ecdsa-with-Sha384 [X9.62]
ecdsa-with-Sha512 [X9.62]
Sha512とSha384とSha256とSha1とecdsa[RFC3279]ecdsa[X9.62]ecdsa[X9.62]ecdsa[X9.62]
The corresponding digestAlgorithm field contains one of the following hash algorithm identifiers respectively:
対応するdigestAlgorithm分野はそれぞれ以下のハッシュアルゴリズム識別子の1つを含んでいます:
Zhu, et al. Informational [Page 2] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[2ページ]のRFC5349ECCサポート
id-sha1 [RFC3279]
id-sha256 [X9.62]
id-sha384 [X9.62]
id-sha512 [X9.62]
イド-sha1[RFC3279]イド-sha256[X9.62]イド-sha384[X9.62]イド-sha512[X9.62]
Namely, id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384 MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512 MUST be used in conjunction with ecdsa-with-Sha512.
すなわち、Sha1とecdsaに関連してイド-sha1を使用しなければなりません、そして、Sha256とecdsaに関連してイド-sha256を使用しなければなりません、そして、Sha384とecdsaに関連してイド-sha384を使用しなければなりません、そして、Sha512とecdsaに関連してイド-sha512を使用しなければなりません。
Implementations of this specification MUST support ecdsa-with-Sha256 and SHOULD support ecdsa-with-Sha1.
この仕様の実装は、Sha256とecdsaとSHOULDがSha1とサポートecdsaであるとサポートしなければなりません。
4. Using the ECDH Key Exchange
4. ECDHの主要な交換を使用します。
This section describes how ECDH can be used as the Authentication Service (AS) reply key delivery method [RFC4556]. Note that the protocol description here is similar to that of Modular Exponential Diffie-Hellman (MODP DH), as described in [RFC4556].
このセクションはAuthentication Service(AS)回答主要な発送方法[RFC4556]としてどうECDHを使用できるかを記述します。 [RFC4556]で説明されるようにここでのプロトコル記述がModular Exponentialディフィー-ヘルマン(MODP DH)のものと同様であることに注意してください。
If the client wishes to use the ECDH key agreement method, it encodes its ECDH public key value and the key's domain parameters [IEEE1363] [X9.63] in clientPublicValue of the PA-PK-AS-REQ message [RFC4556].
クライアントがECDHの主要な協定メソッドを使用したいと思うなら、それはPA-PK-AS-REQメッセージ[RFC4556]のclientPublicValueのECDH公開鍵価値とキーのドメインパラメタ[IEEE1363][X9.63]をコード化します。
As described in [RFC4556], the ECDH domain parameters for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279].
[RFC4556]で説明されるように、クライアントの公開鍵のためのECDHドメインパラメタはタイプSubjectPublicKeyInfo[RFC3279]のアルゴリズム分野で指定されます、そして、[RFC3279]に従って、クライアントのECDH公開鍵価値はsubjectPublicKey(BIT STRING)に写像されます。
The following algorithm identifier is used to identify the client's choice of the ECDH key agreement method for key delivery.
以下のアルゴリズム識別子は、クライアントの主要な配送のためのECDHの主要な協定メソッドの選択を特定するのに使用されます。
id-ecPublicKey (Elliptic Curve Diffie-Hellman [RFC3279])
イド-ecPublicKey(Elliptic Curveディフィー-ヘルマン[RFC3279])
If the domain parameters are not accepted by the KDC, the KDC sends back an error message [RFC4120] with the code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [RFC4556]. This error message contains the list of domain parameters acceptable to the KDC. This list is encoded as TD-DH-PARAMETERS [RFC4556], and it is in the KDC's decreasing preference order. The client can then pick a set of domain parameters from the list and retry the authentication.
ドメインパラメタがKDCによって受け入れられないなら、KDCは_ACCEPTED[RFC4556]ではなく、コードKDC_ERR_DH_KEY_PARAMETERS_でエラーメッセージ[RFC4120]を返送します。 このエラーメッセージはKDCに許容できるドメインパラメタのリストを含んでいます。 このリストはTD-DH-PARAMETERS[RFC4556]としてコード化されます、そして、それはKDCの減少している好みの命令にあります。 クライアントは、次に、リストからの1セットのドメインパラメタを選んで、認証を再試行できます。
Both the client and the KDC MUST have local policy that specifies which set of domain parameters are acceptable if they do not have a priori knowledge of the chosen domain parameters. The need for such local policy is explained in Section 7.
クライアントとKDC MUSTの両方には、それらに選ばれたドメインパラメタに関する先験的な知識がないならどのセットのドメインパラメタが許容できるかを指定するローカルの方針があります。 そのようなローカルの方針の必要性はセクション7で説明されます。
Zhu, et al. Informational [Page 3] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[3ページ]のRFC5349ECCサポート
If the ECDH domain parameters are accepted by the KDC, the KDC sends back its ECDH public key value in the subjectPublicKey field of the PA-PK-AS-REP message [RFC4556].
ECDHドメインパラメタがKDCによって受け入れられるなら、KDCはPA-PK-AS-REPメッセージ[RFC4556]のsubjectPublicKey分野でECDH公開鍵価値を返送します。
As described in [RFC4556], the KDC's ECDH public key value is encoded as a BIT STRING according to [RFC3279].
[RFC4556]で説明されるように、[RFC3279]に従って、KDCのECDH公開鍵価値はBIT STRINGとしてコード化されます。
Note that in the steps above, the client can indicate to the KDC that it wishes to reuse ECDH keys or it can allow the KDC to do so, by including the clientDHNonce field in the request [RFC4556]; the KDC can then reuse the ECDH keys and include the serverDHNonce field in the reply [RFC4556]. This logic is the same as that of the Modular Exponential Diffie-Hellman key agreement method [RFC4556].
KDCが上では、クライアントがそれがECDHキーかそれを再利用したがっているKDCに示すことができるステップにおけるそれでそうすることができることに要求[RFC4556]にclientDHNonce分野を含んでいることによって、注意してください。 KDCは次に、ECDHキーを再利用して、回答[RFC4556]にserverDHNonce分野を含むことができます。 この論理はModular Exponentialのディフィー-ヘルマンの主要な協定メソッド[RFC4556]のものと同じです。
If ECDH is negotiated as the key delivery method, then the PA-PK-AS-REP and AS reply key are generated as in Section 3.2.3.1 of [RFC4556] with the following difference: The ECDH shared secret value (an elliptic curve point) is calculated using operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363]. The x-coordinate of this point is converted to an octet string using operation FE2OSP as described in Section 5.5.4 of [IEEE1363]. This octet string is the DHSharedSecret.
ECDHが主要な発送方法として交渉されるならPA-PK-AS-REPとAS回答キーがセクション3.2.3のように発生している、以下の違いがある.1[RFC4556]: ECDH共有秘密キー価値(楕円曲線ポイント)は、.1セクション7.2[IEEE1363]で説明されるように操作ECSVDP-DHを使用することで計算されます。 このポイントのx-座標は、.4セクション5.5[IEEE1363]で説明されるように操作FE2OSPを使用することで八重奏ストリングに変換されます。 この八重奏ストリングはDHSharedSecretです。
Both the client and KDC then proceed as described in [RFC4556] and [RFC4120].
クライアントとそしてKDCの両方が[RFC4556]と[RFC4120]で説明されるように続きます。
Lastly, it should be noted that ECDH can be used with any certificates and signature schemes. However, a significant advantage of using ECDH together with ECC certificates and signature schemes is that the ECC domain parameters in the client certificates or the KDC certificates can be used. This obviates the need of locally preconfigured domain parameters as described in Section 7.
最後に、どんな証明書と署名体系と共にもECDHを使用できることに注意されるべきです。 しかしながら、ECC証明書と署名体系と共にECDHを使用する重要な利点はクライアント証明書かKDC証明書のECCドメインパラメタを使用できるということです。 これはセクション7で説明されるように局所的にあらかじめ設定されたドメインパラメタの必要性を取り除きます。
5. Choosing the Domain Parameters and the Key Size
5. ドメインパラメタと主要なサイズを選びます。
The domain parameters and the key size should be chosen so as to provide sufficient cryptographic security [RFC3766]. The following table, based on table 2 on page 63 of NIST SP800-57 part 1 [NISTSP80057], gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them.
ドメインパラメタと主要なサイズは、十分な暗号のセキュリティ[RFC3766]を提供するために選ばれるべきです。 63のNIST SP800-57第1部ページ[NISTSP80057]のテーブル2に基づく以下のテーブルはそれらを攻撃するための最もよく知られているアルゴリズムに基づく左右対称の、そして、非対称に主要な暗号系のために大体の匹敵する主要なサイズを与えます。
Zhu, et al. Informational [Page 4] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[4ページ]のRFC5349ECCサポート
Symmetric | ECC | RSA
-------------+----------- +------------
80 | 160 - 223 | 1024
112 | 224 - 255 | 2048
128 | 256 - 383 | 3072
192 | 384 - 511 | 7680
256 | 512+ | 15360
左右対称| ECC| RSA-------------+----------- +------------ 80 | 160 - 223 | 1024 112 | 224 - 255 | 2048 128 | 256 - 383 | 3072 192 | 384 - 511 | 7680 256 | 512+ | 15360
Table 1: Comparable key sizes (in bits)
テーブル1: 匹敵する主要なサイズ(ビットの)
Thus, for example, when securing a 128-bit symmetric key, it is prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g., group P-256 (secp256r1) as described below.
128ビットの対称鍵を固定するとき、このようにして、そして、例えば、256ビットのElliptic Curve Cryptography(ECC)を使用するのは慎重です、例えば以下で説明されるグループP-256(secp256r1)。
A set of ECDH domain parameters is also known as a "curve". A curve is a "named curve" if the domain parameters are well known and can be identified by an Object Identifier; otherwise, it is called a "custom curve". [RFC4556] supports both named curves and custom curves, see Section 7 on the tradeoffs of choosing between named curves and custom curves.
また、1セットのECDHドメインパラメタは「カーブ」として知られています。 ドメインパラメタをよく知られて、Object Identifierが特定できるなら、カーブは「命名されたカーブ」です。 さもなければ、それは「カスタムカーブ」と呼ばれます。 [RFC4556]はカーブとカスタムカーブという両方をサポートします、と命名されたカーブとカスタムカーブを選ぶ見返りのセクション7は見ます。
The named curves recommended in this document are also recommended by the National Institute of Standards and Technology (NIST)[FIPS186-2]. These fifteen ECC curves are given in the following table [FIPS186-2] [SEC2].
また、このドキュメントのお勧めの命名されたカーブは米国商務省標準技術局(NIST)[FIPS186-2]によって推薦されます。 以下のテーブル[FIPS186-2][SEC2]でこれらの15のECCカーブを与えます。
Description SEC 2 OID
----------------- ---------
記述秒2のOID----------------- ---------
ECPRGF192Random group P-192 secp192r1
EC2NGF163Random group B-163 sect163r2
EC2NGF163Koblitz group K-163 sect163k1
ECPRGF192RandomグループP-192 secp192r1 EC2NGF163RandomグループB-163sect163r2 EC2NGF163KoblitzグループK-163sect163k1
ECPRGF224Random group P-224 secp224r1
EC2NGF233Random group B-233 sect233r1
EC2NGF233Koblitz group K-233 sect233k1
ECPRGF224RandomグループP-224 secp224r1 EC2NGF233RandomグループB-233sect233r1 EC2NGF233KoblitzグループK-233sect233k1
ECPRGF256Random group P-256 secp256r1
EC2NGF283Random group B-283 sect283r1
EC2NGF283Koblitz group K-283 sect283k1
ECPRGF256RandomグループP-256 secp256r1 EC2NGF283RandomグループB-283sect283r1 EC2NGF283KoblitzグループK-283sect283k1
ECPRGF384Random group P-384 secp384r1
EC2NGF409Random group B-409 sect409r1
EC2NGF409Koblitz group K-409 sect409k1
ECPRGF384RandomグループP-384 secp384r1 EC2NGF409RandomグループB-409sect409r1 EC2NGF409KoblitzグループK-409sect409k1
ECPRGF521Random group P-521 secp521r1
EC2NGF571Random group B-571 sect571r1
EC2NGF571Koblitz group K-571 sect571k1
ECPRGF521RandomグループP-521 secp521r1 EC2NGF571RandomグループB-571sect571r1 EC2NGF571KoblitzグループK-571sect571k1
Zhu, et al. Informational [Page 5] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[5ページ]のRFC5349ECCサポート
6. Interoperability Requirements
6. 相互運用性要件
Implementations conforming to this specification MUST support curve P-256 and P-384.
この仕様に従う実装はカーブP-256とP-384をサポートしなければなりません。
7. Security Considerations
7. セキュリティ問題
When using ECDH key agreement, the recipient of an elliptic curve public key should perform the checks described in IEEE P1363, Section A16.10 [IEEE1363]. It is especially important, if the recipient is using a long-term ECDH private key, to check that the sender's public key is a valid point on the correct elliptic curve; otherwise, information may be leaked about the recipient's private key, and iterating the attack will eventually completely expose the recipient's private key.
ECDHの主要な協定を使用するとき、楕円曲線公開鍵の受取人はIEEE P1363(セクションA16.10[IEEE1363])で説明されたチェックを実行するべきです。 それは特に重要です、受取人が送付者の公開鍵が正しい楕円曲線の有効なポイントであることをチェックするのに長期のECDH秘密鍵を使用しているなら。 さもなければ、情報は受取人の秘密鍵に関して漏らされるかもしれません、そして、攻撃を繰り返すと、受取人の秘密鍵は結局、完全に暴露するでしょう。
Kerberos error messages are not integrity protected; as a result, the domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered with by an attacker so that the set of domain parameters selected could be either weaker or not mutually preferred. Local policy can configure sets of domain parameters that are acceptable locally or can disallow the negotiation of ECDH domain parameters.
ケルベロスエラーメッセージは保護された保全ではありません。 その結果、TD-DH-PARAMETERSとしてKDCによって送られたドメインパラメタは、攻撃者がパラメタが選択したドメインのセットが、より弱いことができなるようにいじることができないか、互いに好むことができません。 ローカルの方針は、局所的に許容できるドメインパラメタのセットを構成できるか、またはECDHドメインパラメタの交渉を禁じることができます。
Beyond elliptic curve size, the main issue is elliptic curve structure. As a general principle, it is more conservative to use elliptic curves with as little algebraic structure as possible. Thus, random curves are more conservative than special curves (such as Koblitz curves), and curves over F_p with p random are more conservative than curves over F_p with p of a special form. (Also, curves over F_p with p random might be considered more conservative than curves over F_2^m, as there is no choice between multiple fields of similar size for characteristic 2.) Note, however, that algebraic structure can also lead to implementation efficiencies, and implementors and users may, therefore, need to balance conservatism against a need for efficiency. Concrete attacks are known against only very few special classes of curves, such as supersingular curves, and these classes are excluded from the ECC standards such as [IEEE1363] and [X9.62].
楕円曲線サイズを超えて、本題は楕円曲線構造です。 一般的な原則として、できるだけ少ない代数構造がある楕円曲線を使用するのは、より保守的です。 したがって、無作為のカーブが特別なカーブ(Koblitzカーブなどの)より保守的であり、pが無作為のF_pの上のカーブはカーブより特別なフォームのpがあるF_pに関して保守的です。 (また、pが無作為のF_pの上のカーブはF_2^mの上を曲がるより保守的であると考えられるかもしれません、独特の2のための同様のサイズの複数の分野の間に選択が全くないとき。) しかしながら、また、代数構造が実装効率につながることができることに注意してください。そうすれば、したがって、作成者とユーザは、効率の必要性に対して保守主義のバランスをとる必要があってもよいです。 具体的な攻撃はほんのわずかな特別なクラスの「スーパー-単数」カーブなどのカーブだけに対して知られています、そして、これらのクラスは[IEEE1363]や[X9.62]などのECC規格から除かれます。
Another issue is the potential for catastrophic failures when a single elliptic curve is widely used. In this case, an attack on the elliptic curve might result in the compromise of a large number of keys. Again, this concern may need to be balanced against efficiency and interoperability improvements associated with widely used curves. Substantial additional information on elliptic curve choice can be found in [IEEE1363], [X9.62], and [FIPS186-2].
ただ一つの楕円曲線が広く使用されるとき、別の問題は突発故障の可能性です。 この場合、楕円曲線に対する攻撃は多くのキーの感染をもたらすかもしれません。 一方、この関心は、広く使用されたカーブに関連している効率と相互運用性改良に対してバランスをとる必要があるかもしれません。 [IEEE1363]、[X9.62]、および[FIPS186-2]で楕円曲線選択のかなりの追加情報を見つけることができます。
Zhu, et al. Informational [Page 6] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[6ページ]のRFC5349ECCサポート
8. Acknowledgements
8. 承認
The following people have made significant contributions to this document: Paul Leach, Dan Simon, Kelvin Yiu, David Cross, Sam Hartman, Tolga Acar, and Stefan Santesson.
以下の人々はこのドキュメントへの重要な貢献をしました: ポール・リーチ、ダン・サイモン、ケルビンYiu、David Cross、サム・ハートマン、Tolga Acar、およびステファンSantesson。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[FIPS186-2] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[FIPS186-2]NIST、「デジタル署名基準」、FIPS186-2、2000。
[IEEE1363] IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363, 2000.
[IEEE1363]IEEE、「公開鍵暗号のための標準の仕様」、IEEE1363、2000。
[NISTSP80057] NIST, "Recommendation on Key Management", SP 800-57,
August 2005,
<http://csrc.nist.gov/publications/nistpubs/>.
[NISTSP80057]NIST、「Key Managementにおける推薦」、SP800-57、2005年8月、<http://csrc.nist.gov/publications/nistpubs/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)", RFC 3278,
April 2002.
[RFC3278]ブレーク-ウィルソン、S.、ブラウン、D.、およびP.ランバート、「暗号のメッセージ構文(cm)における楕円曲線暗号(ECC)アルゴリズムの使用」、RFC3278(2002年4月)。
[RFC3279] 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.
[RFC3279] Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys",
BCP 86, RFC 3766, April 2004.
[RFC3766] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)",
RFC 4120, July 2005.
[RFC4120]ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos (PKINIT)",
RFC 4556, June 2006.
[RFC4556] 朱とL.とB.タン、「ケルベロス(PKINIT)における初期の認証のための公開鍵暗号」、RFC4556、2006年6月。
Zhu, et al. Informational [Page 7] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[7ページ]のRFC5349ECCサポート
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しは(CRL)プロフィールをリストアップします」、RFC5280、2008年5月。
[X9.62] ANSI, "Public Key Cryptography For The Financial
Services Industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA)", ANSI X9.62, 2005.
[X9.62]ANSI、「財政的のための公開鍵暗号は産業にサービスを提供します」。 「楕円曲線デジタル署名アルゴリズム(ECDSA)」、ANSI X9.62、2005。
[X9.63] ANSI, "Public Key Cryptography for the Financial
Services Industry: Key Agreement and Key Transport
using Elliptic Curve Cryptography", ANSI X9.63, 2001.
[X9.63]ANSI、「財政的のための公開鍵暗号は産業にサービスを提供します」。 ANSI X9.63、2001の「楕円曲線暗号を使用する主要な協定と主要な輸送」
9.2. Informative References
9.2. 有益な参照
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic
Key Sizes", Journal of Cryptography 14, 255-293, 2001.
[LENSTRA] LenstraとA.とE.フェルヘール、「暗号化キーサイズを選択します」、255-293、2001暗号14、年のジャーナル。
[SEC2] Standards for Efficient Cryptography Group, "SEC 2 -
Recommended Elliptic Curve Domain Parameters",
Ver. 1.0, 2000, <http://www.secg.org>.
Ver効率的な暗号グループの[SEC2]規格、「SEC2--楕円曲線ドメインパラメタを推薦する」1.0、2000、<http://www.secg.org>。
Zhu, et al. Informational [Page 8] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[8ページ]のRFC5349ECCサポート
Authors' Addresses
作者のアドレス
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ラリー朱マイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: lzhu@microsoft.com
メール: lzhu@microsoft.com
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Karthik Jaganathanマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: karthikj@microsoft.com
メール: karthikj@microsoft.com
Kristin Lauter Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
クリスティンローターマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: klauter@microsoft.com
メール: klauter@microsoft.com
Zhu, et al. Informational [Page 9] RFC 5349 ECC Support for PKINIT September 2008
朱、他 PKINIT2008年9月の情報[9ページ]のRFC5349ECCサポート
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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に情報を扱ってください。
Zhu, et al. Informational [Page 10]
朱、他 情報[10ページ]
一覧
スポンサーリンク
