Network Working Group W. Polk
Request for Comments: 3279 NIST
Obsoletes: 2528 R. Housley
Category: Standards Track RSA Laboratories
L. Bassham
NIST
April 2002
Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject.
このドキュメントはインターネットX.509公開鍵基盤（PKI）で使用されるデジタル署名と対象の公開鍵のためのアルゴリズム識別子とASN.1のエンコード形式を指定します。デジタル署名は証明書と証明書失効リスト（CRL）の署名に使用されています。証明書は、指定されたサブジェクトの公開鍵が含まれます。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2 Algorithm Support . . . . . . . . . . . . . . . . . . . . 3
2.1 One-Way Hash Functions . . . . . . . . . . . . . . . . 3
2.1.1 MD2 One-Way Hash Functions . . . . . . . . . . . . . 3
2.1.2 MD5 One-Way Hash Functions . . . . . . . . . . . . . 4
2.1.3 SHA-1 One-Way Hash Functions . . . . . . . . . . . . 4
2.2 Signature Algorithms . . . . . . . . . . . . . . . . . 4
2.2.1 RSA Signature Algorithm . . . . . . . . . . . . . . . 5
2.2.2 DSA Signature Algorithm . . . . . . . . . . . . . . . 6
2.2.3 Elliptic Curve Digital Signature Algorithm . . . . . 7
2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 7
2.3.1 RSA Keys . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 DSA Signature Keys . . . . . . . . . . . . . . . . . 9
2.3.3 Diffie-Hellman Key Exchange Keys . . . . . . . . . . 10
2.3.4 KEA Public Keys . . . . . . . . . . . . . . . . . . . 11
2.3.5 ECDSA and ECDH Public Keys . . . . . . . . . . . . . 13
3 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 18
4 References . . . . . . . . . . . . . . . . . . . . . . . 24
5 Security Considerations . . . . . . . . . . . . . . . . . 25
6 Intellectual Property Rights . . . . . . . . . . . . . . 26
7 Author Addresses . . . . . . . . . . . . . . . . . . . . 26
8 Full Copyright Statement . . . . . . . . . . . . . . . . 27
1 Introduction
1はじめに
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
This document specifies algorithm identifiers and ASN.1 [X.660] encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). This specification supplements [RFC 3280], "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile." Implementations of this specification MUST also conform to RFC 3280.
このドキュメントはインターネットX.509公開鍵インフラストラクチャ（PKI）で使用されるデジタル署名と対象の公開鍵のためのアルゴリズム識別子とASN.1 [X.660]エンコード形式を指定します。この仕様は、サプリメント[RFC 3280]、「インターネットX.509公開鍵インフラストラクチャ：証明書と証明書失効リスト（CRL）プロフィール」この仕様の実装はまた、RFC 3280に従わなければなりません。
This specification defines the contents of the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and CRLs.
この仕様は、インターネットX.509証明書およびCRL内のsignatureAlgorithm、signatureValue、署名、及びSubjectPublicKeyInfoでフィールドの内容を定義します。
This document identifies one-way hash functions for use in the generation of digital signatures. These algorithms are used in conjunction with digital signature algorithms.
この文書は、デジタル署名の生成に使用するための一方向ハッシュ関数を識別する。これらのアルゴリズムは、デジタル署名アルゴリズムと組み合わせて使用されます。
This specification describes the encoding of digital signatures generated with the following cryptographic algorithms:
この仕様は、次の暗号化アルゴリズムを用いて生成されたデジタル署名の符号化について説明します。
* Rivest-Shamir-Adelman (RSA); * Digital Signature Algorithm (DSA); and * Elliptic Curve Digital Signature Algorithm (ECDSA).
*リベスト - シャミア - エーデルマン（RSA）。 *デジタル署名アルゴリズム（DSA）。そして*楕円曲線デジタル署名アルゴリズム（ECDSA）。
This document specifies the contents of the subjectPublicKeyInfo field in Internet X.509 certificates. For each algorithm, the appropriate alternatives for the the keyUsage extension are provided. This specification describes encoding formats for public keys used with the following cryptographic algorithms:
このドキュメントはインターネットのX.509証明書にSubjectPublicKeyInfoでフィールドの内容を指定します。各アルゴリズムについて、keyUsageの拡張のための適切な選択肢が提供されています。この仕様は、次の暗号化アルゴリズムで使用する公開鍵の符号化形式について説明します。
* Rivest-Shamir-Adelman (RSA);
* Digital Signature Algorithm (DSA);
* Diffie-Hellman (DH);
* Key Encryption Algorithm (KEA);
* Elliptic Curve Digital Signature Algorithm (ECDSA); and * Elliptic Curve Diffie-Hellman (ECDH).
*楕円曲線デジタル署名アルゴリズム（ECDSA）。そして*楕円曲線のDiffie-Hellmanの（ECDH）。
2 Algorithm Support
2アルゴリズムのサポート
This section describes cryptographic algorithms which may be used with the Internet X.509 certificate and CRL profile [RFC 3280]. This section describes one-way hash functions and digital signature algorithms which may be used to sign certificates and CRLs, and identifies object identifiers (OIDs) for public keys contained in a certificate.
このセクションでは、インターネットX.509証明書とCRLプロファイル[RFC 3280]で使用することができる暗号化アルゴリズムを記載しています。このセクションでは、証明書とCRLを署名するために使用することができる一方向ハッシュ関数、デジタル署名アルゴリズムを記述し、証明書に含まれる公開鍵のためのオブジェクト識別子（OID）を識別する。
Conforming CAs and applications MUST, at a minimum, support digital signatures and public keys for one of the specified algorithms. When using any of the algorithms identified in this specification, conforming CAs and applications MUST support them as described.
CAおよびアプリケーションは、最低でも、指定されたアルゴリズムの一つのデジタル署名と公開鍵をサポートしなければなりません準拠。本明細書で同定されたアルゴリズムのいずれかを使用する場合のように、適合CAおよびアプリケーションは、それらをサポートしなければなりません。
This section identifies one-way hash functions for use in the Internet X.509 PKI. One-way hash functions are also called message digest algorithms. SHA-1 is the preferred one-way hash function for the Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] and MD5 is used in other legacy applications. For these reasons, MD2 and MD5 are included in this profile. The data that is hashed for certificate and CRL signing is fully described in [RFC 3280].
このセクションでは、インターネットX.509 PKIでの使用のために一方向ハッシュ関数を識別します。一方向ハッシュ関数は、メッセージダイジェストアルゴリズムと呼ばれています。 SHA-1は、インターネットX.509 PKIのための好ましい一方向ハッシュ関数です。しかし、PEMは、証明書のMD2 [RFC 1422]、[RFC 1423]を使用し、MD5は他のレガシーアプリケーションで使用されています。これらの理由から、MD2とMD5は、このプロファイルに含まれています。証明書とCRLの署名のためにハッシュされたデータは、完全[RFC 3280]に記載されています。
MD2 was developed by Ron Rivest for RSA Security. RSA Security has recently placed the MD2 algorithm in the public domain. Previously, RSA Data Security had granted license for use of MD2 for non-commercial Internet Privacy-Enhanced Mail (PEM). MD2 may continue to be used with PEM certificates, but SHA-1 is preferred. MD2 produces a 128-bit "hash" of the input. MD2 is fully described in [RFC 1319].
MD2はRSAセキュリティのためのRon Rivest氏によって開発されました。 RSAセキュリティは最近、パブリックドメインにMD2アルゴリズムを置いています。以前は、RSAデータセキュリティは、非商用のインターネット個人情報保護・強化メール（PEM）のためにMD2を使用するためのライセンスを付与されていました。 MD2は、PEM証明書と一緒に使用し続けることができるが、SHA-1が好ましいです。 MD2は、入力の128ビットの「ハッシュ」を生成します。 MD2は、完全[RFC 1319]に記載されています。
At the Selected Areas in Cryptography '95 conference in May 1995, Rogier and Chauvaud presented an attack on MD2 that can nearly find collisions [RC95]. Collisions occur when one can find two different messages that generate the same message digest. A checksum operation in MD2 is the only remaining obstacle to the success of the attack. For this reason, the use of MD2 for new applications is discouraged. It is still reasonable to use MD2 to verify existing signatures, as the ability to find collisions in MD2 does not enable an attacker to find new messages having a previously computed hash value.
1995年5月における暗号'95会議で選択された領域では、ロジェとChauvaudは、ほぼ衝突[RC95]を見つけることができますMD2への攻撃を発表しました。 1が同じメッセージダイジェストを生成する2つの異なるメッセージを見つけることができたときに衝突が発生します。 MD2のチェックサム操作は、攻撃の成功への唯一の残りの障害となっています。このため、新しいアプリケーションのMD2の使用が推奨されていません。 MD2で衝突を見つける能力は以前に計算されたハッシュ値を持つ新しいメッセージを見つけるために、攻撃者が有効にならないよう、既存の署名を検証するためにMD2を使用することが合理的です。
MD5 was developed by Ron Rivest for RSA Security. RSA Security has placed the MD5 algorithm in the public domain. MD5 produces a 128- bit "hash" of the input. MD5 is fully described in [RFC 1321].
MD5は、RSAセキュリティのためのRon Rivest氏によって開発されました。 RSAセキュリティは、パブリックドメインにMD5アルゴリズムを置いています。 MD5は、入力の128ビット「ハッシュ」を生成します。 MD5は、完全[RFC 1321]に記載されています。
Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, but there are no other known cryptanalytic results. The use of MD5 for new applications is discouraged. It is still reasonable to use MD5 to verify existing signatures.
DENボーアとBosselaers [DB94]はMD5のための擬似衝突を発見したが、他の既知の暗号解読の結果はありません。新しいアプリケーションのMD5の使用は推奨されません。既存の署名を検証するためにMD5を使用することが合理的です。
SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit "hash" of the input. SHA-1 is fully described in [FIPS 180-1]. RFC 3174 [RFC 3174] also describes SHA-1, and it provides an implementation of the algorithm.
SHA-1は、米国政府によって開発されました。 SHA-1は、入力の160ビットの「ハッシュ」を生成します。 SHA-1は、完全に[FIPS 180-1]に記載されています。 RFC 3174 [RFC 3174]はまた、SHA-1を記載し、それはアルゴリズムの実装を提供します。
Certificates and CRLs conforming to [RFC 3280] may be signed with any public key signature algorithm. The certificate or CRL indicates the algorithm through an algorithm identifier which appears in the signatureAlgorithm field within the Certificate or CertificateList. This algorithm identifier is an OID and has optionally associated parameters. This section identifies algorithm identifiers and parameters that MUST be used in the signatureAlgorithm field in a Certificate or CertificateList.
[RFC 3280]に準拠した証明書およびCRLは、任意の公開鍵署名アルゴリズムを使用して署名することができます。証明書またはCRLは、証明書またはCertificateListの内のsignatureAlgorithmフィールドに表示されたアルゴリズム識別子を通してアルゴリズムを示しています。このアルゴリズム識別子は、OIDであり、必要に応じて関連するパラメータを有しています。このセクションでは、証明書またはCertificateListの中のsignatureAlgorithmフィールドで使用しなければならないアルゴリズム識別子およびパラメータを識別する。
Signature algorithms are always used in conjunction with a one-way hash function.
署名アルゴリズムは常に一方向ハッシュ関数と組み合わせて使用されています。
This section identifies OIDS for RSA, DSA, and ECDSA. The contents of the parameters component for each algorithm vary; details are provided for each algorithm.
このセクションでは、RSA、DSA、およびECDSAのOIDを識別します。各アルゴリズムのパラメータ成分の内容が変わります。詳細は各アルゴリズムのために提供されます。
The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA encryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in the signature field.
署名されるべきデータ（例えば、一方向ハッシュ関数の出力値）が使用される署名アルゴリズムのためにフォーマットされます。その後、秘密鍵操作（例えば、RSA暗号化）が署名値を生成するために実行されます。この署名値は、署名フィールドにおけるビット列と証明書またはCertificateListの中に含まれる符号化されたASN.1です。
The RSA algorithm is named for its inventors: Rivest, Shamir, and Adleman. This profile includes three signature algorithms based on the RSA asymmetric encryption algorithm. The signature algorithms combine RSA with either the MD2, MD5, or the SHA-1 one-way hash functions.
Rivest氏、Shamir、およびAdlemanの：RSAアルゴリズムは、その発明者にちなんで命名されました。このプロファイルは、RSA非対称暗号化アルゴリズムに基づいて3つの署名アルゴリズムを含んでいます。署名アルゴリズムは、MD2、MD5またはSHA-1一方向ハッシュ関数のいずれかでRSAを組み合わせます。
The signature algorithm with SHA-1 and the RSA encryption algorithm is implemented using the padding and encoding conventions described in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 hash algorithm.
SHA-1およびRSA暗号化アルゴリズムと署名アルゴリズムはPKCS＃1 [RFC 2313]に記載のパディング及び符号化規則を用いて実現されます。メッセージダイジェストは、SHA-1ハッシュアルゴリズムを使用して計算されます。
The RSA signature algorithm, as specified in PKCS #1 [RFC 2313] includes a data encoding step. In this step, the message digest and the OID for the one-way hash function used to compute the digest are combined. When performing the data encoding step, the md2, md5, and id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way hash functions, respectively:
RSA署名アルゴリズムは、PKCS＃1 [RFC 2313]で指定されたデータ符号化ステップとを含みます。このステップでは、メッセージダイジェストとダイジェストを計算するために使用される一方向ハッシュ関数のOIDが組み合わされます。データ符号化ステップを実行するとき、MD2、MD5、およびID-SHA1 OIDはそれぞれ、MD2、MD5およびSHA-1一方向ハッシュ関数を指定するために使用されなければなりません。
md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 2 }
md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 5 }
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) 26 }
The signature algorithm with MD2 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the ASN.1 OID used to identify this signature algorithm is:
MD2とRSA暗号化アルゴリズムと署名アルゴリズムはPKCS＃1 [RFC 2313]で定義されています。 PKCS＃1 [RFC 2313]で定義されるように、ASN.1 OIDは、この署名アルゴリズムを識別するために使用されます。
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 2 }
The signature algorithm with MD5 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the ASN.1 OID used to identify this signature algorithm is:
MD5およびRSA暗号化アルゴリズムと署名アルゴリズムはPKCS＃1 [RFC 2313]で定義されています。 PKCS＃1 [RFC 2313]で定義されるように、ASN.1 OIDは、この署名アルゴリズムを識別するために使用されます。
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 4 }
The ASN.1 object identifier used to identify this signature algorithm is:
この署名アルゴリズムを識別するために使用されるASN.1オブジェクト識別子です。
sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5 }
When any of these three OIDs appears within the ASN.1 type AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1 type NULL.
これら三つのOIDのいずれかがASN.1タイプのAlgorithmIdentifierの中に表示されたら、そのタイプのパラメータ・コンポーネントは、ASN.1タイプNULLものでなければなりません。
The RSA signature generation process and the encoding of the result is described in detail in PKCS #1 [RFC 2313].
RSA署名生成プロセスと結果の符号化は、PKCS＃1 [RFC 2313]に詳細に記載されています。
The Digital Signature Algorithm (DSA) is defined in the Digital Signature Standard (DSS). DSA was developed by the U.S. Government, and DSA is used in conjunction with the SHA-1 one-way hash function. DSA is fully described in [FIPS 186]. The ASN.1 OID used to identify this signature algorithm is:
デジタル署名アルゴリズム（DSA）は、デジタル署名標準（DSS）で定義されています。 DSAは、米国政府によって開発された、およびDSAはSHA-1一方向ハッシュ関数と組み合わせて使用されます。 DSAは完全に[FIPS 186]に記載されています。この署名アルゴリズムを識別するために使用されるASN.1のOIDです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
When the id-dsa-with-sha1 algorithm identifier appears as the algorithm field in an AlgorithmIdentifier, the encoding SHALL omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.
ID-DSA-WITH-SHA1アルゴリズム識別子のAlgorithmIdentifierにアルゴリズムフィールドとして表示された場合、符号化は、パラメータフィールドを省略する。オブジェクト識別子ID-DSA-WITH-SHA1：すなわち、のAlgorithmIdentifierは、一つの成分の順序でなければなりません。
The DSA parameters in the subjectPublicKeyInfo field of the certificate of the issuer SHALL apply to the verification of the signature.
発行者の証明書のSubjectPublicKeyInfoでフィールドのDSAパラメータは、署名の検証に適用されるものとします。
When signing, the DSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they SHALL be ASN.1 encoded using the following ASN.1 structure:
署名するとき、DSAアルゴリズムは2つの値を生成します。これらの値は、一般的にRおよびSと呼ばれます。簡単に1つのシグネチャとして、これら2つの値を転送するために、それらは以下のASN.1構造を使用してエンコードASN.1でなければなりません。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. The ASN.1 object identifiers used to identify ECDSA are defined in the following arc:
楕円曲線デジタル署名アルゴリズム（ECDSA）は[X9.62]で定義されています。 ECDSAを識別するために使用されるASN.1オブジェクト識別子は、次の円弧で定義されています。
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
id-ecSigType OBJECT IDENTIFIER ::= {
ansi-X9-62 signatures(4) }
ECDSA is used in conjunction with the SHA-1 one-way hash function. The ASN.1 object identifier used to identify ECDSA with SHA-1 is:
ECDSAは、SHA-1一方向ハッシュ関数と組み合わせて使用されます。 SHA-1とECDSAを識別するために使用されるASN.1オブジェクト識別子です。
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
id-ecSigType 1 }
When the ecdsa-with-SHA1 algorithm identifier appears as the algorithm field in an AlgorithmIdentifier, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.
ECDSA-WITH-SHA1アルゴリズム識別子のAlgorithmIdentifierにアルゴリズムフィールドとして表示されたら、符号化パラメータフィールドを省略しなければなりません。オブジェクト識別子ECDSA-WITH-SHA1：つまり、のAlgorithmIdentifierは、一つの成分の順序でなければなりません。
The elliptic curve parameters in the subjectPublicKeyInfo field of the certificate of the issuer SHALL apply to the verification of the signature.
発行者の証明書のSubjectPublicKeyInfoでフィールドの楕円曲線パラメータは、署名の検証に適用されるものとします。
When signing, the ECDSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they MUST be ASN.1 encoded using the following ASN.1 structure:
署名するとき、ECDSAアルゴリズムは、2つの値を生成します。これらの値は、一般的にRおよびSと呼ばれます。簡単に1つのシグネチャとして、これら2つの値を転送するために、それらはASN.1は、以下のASN.1構造を使用して符号化されなければなりません。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
Certificates conforming to [RFC 3280] may convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. This algorithm identifier is an OID and optionally associated parameters.
[RFC 3280]に準拠した証明書は、任意の公開鍵アルゴリズムの公開鍵を伝えることができます。証明書は、アルゴリズム識別子を通してアルゴリズムを示しています。このアルゴリズム識別子は、OIDと任意に関連するパラメータです。
This section identifies preferred OIDs and parameters for the RSA, DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms. Conforming CAs MUST use the identified OIDs when issuing certificates containing public keys for these algorithms. Conforming applications supporting any of these algorithms MUST, at a minimum, recognize the OID identified in this section.
このセクションでは、RSA、DSA、ディフィー - ヘルマン、KEA、ECDSA、およびECDHアルゴリズムのための好ましいのOIDとパラメータを識別する。これらのアルゴリズムの公開鍵を含む証明書を発行する際に準拠するCAは、特定されたOIDを使用しなければなりません。これらのアルゴリズムのいずれかを支持準拠アプリケーションは、最低でも、このセクションで指定OIDを認識しなければなりません。
The OID rsaEncryption identifies RSA public keys.
OID rsaEncryptionはRSA公開鍵を識別します。
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
The rsaEncryption OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field MUST have ASN.1 type NULL for this algorithm identifier.
rsaEncryption OIDはタイプのAlgorithmIdentifierの値のアルゴリズム分野で使用されることが意図されます。パラメータフィールドは、このアルゴリズム識別子のためのASN.1タイプNULLを持たなければなりません。
The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:
RSA公開鍵はASN.1タイプのRSAPublicKeyを使用してエンコードされなければなりません。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
where modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is the value of the BIT STRING subjectPublicKey.
ここで、弾性率は、モジュラスNであり、そしてpublicExponentは、公開指数eです。 DER符号化されたのRSAPublicKeyはビット列のsubjectPublicKeyの値です。
This OID is used in public key certificates for both RSA signature keys and RSA encryption keys. The intended application for the key MAY be indicated in the key usage field (see [RFC 3280]). The use of a single key for both signature and encryption purposes is not recommended, but is not forbidden.
このOIDは、RSA署名鍵とRSA暗号化キーの両方のための公開鍵証明書に使用されています。鍵の意図される用途には、（[RFC 3280]を参照）キー使用フィールドに示されてもよいです。両方の署名と暗号化の目的のために単一のキーを使用することは推奨されていませんが、禁止されていません。
If the keyUsage extension is present in an end entity certificate which conveys an RSA public key, any combination of the following values MAY be present:
KeyUsage拡張がRSA公開鍵を伝えるエンドエンティティ証明書に存在している場合は、以下の値のいずれかの組み合わせが存在することがあります。
digitalSignature;
nonRepudiation;
keyEncipherment; and
dataEncipherment.
If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an RSA public key, any combination of the following values MAY be present:
keyUsageエクステンションがRSA公開鍵を伝えるCAまたはCRLの発行者証明書に存在している場合は、以下の値のいずれかの組み合わせが存在することがあります。
digitalSignature;
nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.
However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, both keyEncipherment and dataEncipherment SHOULD NOT be present.
しかし、この仕様はKeyCertSignがまたはcRLSignが存在する場合、keyEnciphermentとdataEnciphermentの両方が存在してはならないことをお勧めします。
The Digital Signature Algorithm (DSA) is defined in the Digital Signature Standard (DSS) [FIPS 186]. The DSA OID supported by this profile is:
デジタル署名アルゴリズム（DSA）は、デジタル署名標準（DSS）[FIPS 186]で定義されています。このプロファイルでサポートされているDSA OIDは次のとおりです。
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
The id-dsa algorithm syntax includes optional domain parameters. These parameters are commonly referred to as p, q, and g. When omitted, the parameters component MUST be omitted entirely. That is, the AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa.
ID-DSAアルゴリズムの構文は、オプションのドメインパラメータを含んでいます。これらのパラメータは一般にP、Q、及びGと呼ばれます。省略した場合、パラメータ成分が完全に省略されなければなりません。 OBJECT識別子ID-DSA：すなわち、のAlgorithmIdentifierは、一つの成分の順序でなければなりません。
If the DSA domain parameters are present in the subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included using the following ASN.1 structure:
DSAのドメインパラメータがSubjectPublicKeyInfoでのAlgorithmIdentifierに存在している場合は、パラメータは以下のASN.1構造を使用して含まれています。
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the DSA algorithm parameters are omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA parameters apply to the subject's DSA key. If the DSA domain parameters are omitted from the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the subject's DSA domain parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the subject's DSA parameters are not available through other means, then clients MUST reject the certificate.
SubjectPublicKeyInfoで以内のAlgorithmIdentifierパラメータを使用することができる証明書内の唯一の場所です。 DSAアルゴリズムパラメータがSubjectPublicKeyInfoでのAlgorithmIdentifierから省略され、CAがDSAを使用してサブジェクト証明書に署名した場合は、証明書発行者のDSAパラメータは、被験者のDSA鍵に適用されます。 DSAドメインパラメータがSubjectPublicKeyInfoでのAlgorithmIdentifierとCAから省略された場合DSA以外の署名アルゴリズムを使用して、対象証明書に署名し、その後、被験者のDSAドメインパラメータは、他の手段によって分配されます。 SubjectPublicKeyInfoでのAlgorithmIdentifierフィールドは、パラメータのコンポーネントを省略した場合は、CAがDSA以外の署名アルゴリズムを有する対象を署名し、そして対象のDSAパラメータは、他の手段を介して利用できない場合、クライアントは証明書を拒絶しなければなりません。
The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.
DSA公開鍵はINTEGERとしてコード化ASN.1 DERでなければなりません。この符号化はSubjectPublicKeyInfoでデータ要素ののsubjectPublicKeyコンポーネント（ビット列）の内容（即ち、値）として使用しなければなりません。
DSAPublicKey ::= INTEGER -- public key, Y
If the keyUsage extension is present in an end entity certificate which conveys a DSA public key, any combination of the following values MAY be present:
KeyUsage拡張は、DSA公開鍵を伝えるエンドエンティティ証明書内に存在する場合、以下の値の任意の組み合わせが存在することがあります。
digitalSignature;
nonRepudiation;
If the keyUsage extension is present in a CA or CRL issuer certificate which conveys a DSA public key, any combination of the following values MAY be present:
keyUsageエクステンションがDSA公開鍵を伝えるCAまたはCRLの発行者証明書に存在している場合は、以下の値のいずれかの組み合わせが存在することがあります。
digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.
The Diffie-Hellman OID supported by this profile is defined in [X9.42].
このプロファイルでサポートされているのDiffie-HellmanのOIDは[X9.42]で定義されています。
dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
The dhpublicnumber OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field of that type, which has the algorithm-specific syntax ANY DEFINED BY algorithm, have the ASN.1 type DomainParameters for this algorithm.
dhpublicnumberのOIDはタイプのAlgorithmIdentifierの値のアルゴリズム分野で使用されることが意図されます。 ANYは、アルゴリズムによって定義されたアルゴリズム固有の構文を持っているそのタイプのパラメータフィールドは、このアルゴリズムのためのASN.1タイプDomainParametersを持っています。
DomainParameters ::= 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 }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
The fields of type DomainParameters have the following meanings:
型DomainParametersのフィールドは以下の意味があります。
p identifies the prime p defining the Galois field;
pはガロア体を定義する素数pを識別します。
g specifies the generator of the multiplicative subgroup of order g;
Gはオーダーgの乗法サブグループのジェネレータを指定します。
q specifies the prime factor of p-1;
qは、P-1の素因数を指定します。
j optionally specifies the value that satisfies the equation p=jq+1 to support the optional verification of group parameters;
jは任意には、グループのパラメータの任意の検証をサポートするために、式P = JQ + 1を満足する値を指定します。
seed optionally specifies the bit string parameter used as the seed for the domain parameter generation process; and
種子は、任意のドメインパラメータ生成プロセスのためのシードとして使用されるビット文字列パラメータを指定します。そして
pgenCounter optionally specifies the integer value output as part of the of the domain parameter prime generation process.
pgenCounterは、必要に応じてドメインパラメータ素数生成プロセスの一部として整数値の出力を指定します。
If either of the domain parameter generation components (pgenCounter or seed) is provided, the other MUST be present as well.
ドメインパラメータ生成コンポーネント（pgenCounter又は種子）のいずれかが提供されている場合、他は同様に存在しなければなりません。
The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.
ディフィー・ヘルマン公開鍵は整数として符号化されたASN.1なければなりません。この符号化はSubjectPublicKeyInfoでデータ要素ののsubjectPublicKeyコンポーネント（ビット列）の内容（即ち、値）として使用しなければなりません。
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
If the keyUsage extension is present in a certificate which conveys a DH public key, the following values may be present:
keyUsage拡張子がDH公開鍵を伝達する証明書内に存在する場合、次の値が存在してもよいです。
keyAgreement; encipherOnly; and decipherOnly.
するKeyAgreement; encipherOnly;そしてdecipherOnly。
If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.
存在する場合、keyUsageの拡張機能はするKeyAgreementを主張しなければならないとencipherOnlyとdecipherOnlyのいずれかをアサートしてもよいです。 keyUsageの拡張は、encipherOnlyとdecipherOnlyの両方を主張してはなりません。
This section identifies the preferred OID and parameters for the inclusion of a KEA public key in a certificate. The Key Exchange Algorithm (KEA) is a key agreement algorithm. Two parties may generate a "pairwise key" if and only if they share the same KEA parameters. The KEA parameters are not included in a certificate; instead a domain identifier is supplied in the parameters field.
このセクションでは、証明書内KEA公開鍵を含めるための好ましいOIDとパラメータを識別する。鍵交換アルゴリズム（KEA）は、キー合意アルゴリズムです。彼らは同じKEAのパラメータを共有している場合にのみ場合、2つの当事者は、「鍵ペア」を生成してもよいです。 KEAパラメータは、証明書に含まれていません。代わりに、ドメイン識別子は、パラメータフィールドに供給されています。
When the SubjectPublicKeyInfo field contains a KEA key, the algorithm identifier and parameters SHALL be as defined in [SDN.701r]:
SubjectPublicKeyInfoでフィールドはKEAキーが含まれている場合[SDN.701r]で定義されるように、アルゴリズム識別子とパラメータがなければなりません。
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
{ 2 16 840 1 101 2 1 1 22 }
KEA-Parms-Id ::= OCTET STRING
CAs MUST populate the parameters field of the AlgorithmIdentifier within the SubjectPublicKeyInfo field of each certificate containing a KEA public key with an 80-bit parameter identifier (OCTET STRING), also known as the domain identifier. The domain identifier is computed in three steps:
CAは、ドメイン識別子としても知られている80ビットのパラメータ識別子（オクテット列）とKEA公開鍵を含む各証明書のSubjectPublicKeyInfoでフィールド内のAlgorithmIdentifierのパラメータフィールドを移入する必要があります。ドメイン識別子は、次の3つのステップで計算されます。
(1) the KEA domain parameters (p, q, and g) are DER encoded using the Dss-Parms structure;
（1）KEAドメインパラメータ（p、q、およびg）DERは、DSS-PARMS構造を用いて符号化されます。
(2) a 160-bit SHA-1 hash is generated from the parameters; and
（2）160ビットSHA-1ハッシュをパラメータから生成されます。そして
(3) the 160-bit hash is reduced to 80-bits by performing an "exclusive or" of the 80 high order bits with the 80 low order bits.
（3）160ビットのハッシュは、80下位ビットと上位80ビットの「排他的または」を行うことにより、80ビットに低減されます。
The resulting value is encoded such that the most significant byte of the 80-bit value is the first octet in the octet string. The Dss-Parms is provided above in Section 2.3.2.
得られた値は80ビット値の最上位バイトは、オクテットストリングの最初のオクテットであるように符号化されます。 DSS-PARMSは、セクション2.3.2に上方に設けられています。
A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING such that the most significant bit (MSB) of y becomes the MSB of the BIT STRING value field and the least significant bit (LSB) of y becomes the LSB of the BIT STRING value field. This results in the following encoding:
KEA公開鍵、Yは、Yの最上位ビット（MSB）はビット列値フィールドのMSBになり、yの最下位ビット（LSB）LSBビットとなるようのsubjectPublicKeyビット列に搬送されますSTRING値フィールド。これは、次のエンコードのような結果になります。
BIT STRING tag;
BIT STRING length;
0 (indicating that there are zero unused bits in the final octet
of y); and
BIT STRING value field including y.
The key usage extension may optionally appear in a KEA certificate. If a KEA certificate includes the keyUsage extension, only the following values may be asserted:
鍵用途拡張は、必要に応じてKEA証明書に表示されてもよいです。 KEA証明書がkeyUsageの拡張が含まれている場合は、次の値のみをアサートすることができます。
keyAgreement; encipherOnly; and decipherOnly.
するKeyAgreement; encipherOnly;そしてdecipherOnly。
If present, the keyUsage extension MUST assert keyAgreement and MAY assert either encipherOnly and decipherOnly. The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.
存在する場合、keyUsageの拡張機能はするKeyAgreementを主張しなければならないとencipherOnlyとdecipherOnlyのいずれかをアサートしてもよいです。 keyUsageの拡張は、encipherOnlyとdecipherOnlyの両方を主張してはなりません。
This section identifies the preferred OID and parameter encoding for the inclusion of an ECDSA or ECDH public key in a certificate. The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. ECDSA is the elliptic curve mathematical analog of the Digital Signature Algorithm [FIPS 186]. The Elliptic Curve Diffie Hellman (ECDH) algorithm is a key agreement algorithm defined in [X9.63].
このセクションでは、証明書内ECDSA又はECDH公開鍵を含めるための好ましいOIDとパラメータ符号化を識別する。楕円曲線デジタル署名アルゴリズム（ECDSA）は[X9.62]で定義されています。 ECDSAは、デジタル署名アルゴリズム[FIPS 186]の楕円曲線の数学的類似体です。楕円曲線ディフィー・ヘルマン鍵共有（ECDH）アルゴリズムは[X9.63]で定義された鍵合意アルゴリズムです。
ECDH is the elliptic curve mathematical analog of the Diffie-Hellman key agreement algorithm as specified in [X9.42]. The ECDSA and ECDH specifications use the same OIDs and parameter encodings. The ASN.1 object identifiers used to identify these public keys are defined in the following arc:
ECDHは[X9.42]で指定されたDiffie-Hellman鍵合意アルゴリズムの楕円曲線の数学的類似体です。 ECDSAとECDH仕様が同じのOIDとパラメータのエンコーディングを使用します。これらの公開鍵を識別するために使用されるASN.1オブジェクト識別子は、次の円弧で定義されています。
ansi-X9-62 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) 10045 }
When certificates contain an ECDSA or ECDH public key, the id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey algorithm identifier is defined as follows:
証明書は、ECDSA、またはECDH公開鍵が含まれている場合、ID-ecPublicKeyアルゴリズム識別子を使用しなければなりません。次のようにID-ecPublicKeyアルゴリズム識別子が定義されています。
id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 }
id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
This OID is used in public key certificates for both ECDSA signature keys and ECDH encryption keys. The intended application for the key may be indicated in the key usage field (see [RFC 3280]). The use of a single key for both signature and encryption purposes is not recommended, but is not forbidden.
このOIDは、ECDSA署名鍵とECDHの暗号化キーの両方のための公開鍵証明書に使用されています。鍵の意図される用途には、（[RFC 3280]を参照）キー使用フィールドで示すことができます。両方の署名と暗号化の目的のために単一のキーを使用することは推奨されていませんが、禁止されていません。
ECDSA and ECDH require use of certain parameters with the public key. The parameters may be inherited from the issuer, implicitly included through reference to a "named curve," or explicitly included in the certificate.
ECDSAとECDHは、公開鍵を使用して特定のパラメータを使用する必要があります。パラメータは「名前のカーブ」暗黙のうちに基づいて含まれ、発行者から継承されたか、明示的に証明書に含まれていてもよいです。
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
When the parameters are inherited, the parameters field SHALL contain implictlyCA, which is the ASN.1 value NULL. When parameters are specified by reference, the parameters field SHALL contain the named-Curve choice, which is an object identifier. When the parameters are explicitly included, they SHALL be encoded in the ASN.1 structure ECParameters:
パラメータが継承される場合は、パラメータフィールドがASN.1値NULLであるimplictlyCAを含まなければなりません。パラメータを参照することにより指定された場合、パラメータフィールドは、オブジェクト識別子であるという名前のカーブの選択を、含まなければなりません。パラメータが明示的に含まれている場合、彼らはASN.1構造ECParametersで符号化されなければなりません。
ECParameters ::= SEQUENCE {
version ECPVer, -- version is always 1
fieldID FieldID, -- identifies the finite field over
-- which the curve is defined
curve Curve, -- coefficients a and b of the
-- elliptic curve
base ECPoint, -- specifies the base point P
-- on the elliptic curve
order INTEGER, -- the order n of the base point
cofactor INTEGER OPTIONAL -- The integer h = #E(Fq)/n
}
ECPVer ::= INTEGER {ecpVer1(1)}
Curve ::= SEQUENCE {
a FieldElement,
b FieldElement,
seed BIT STRING OPTIONAL }
FieldElement ::= OCTET STRING
ECPoint ::= OCTET STRING
The value of FieldElement SHALL be the octet string representation of a field element following the conversion routine in [X9.62], Section 4.3.3. The value of ECPoint SHALL be the octet string representation of an elliptic curve point following the conversion routine in [X9.62], Section 4.3.6. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form.
FieldElementの値は[X9.62]に変換ルーチン、セクション4.3.3以下フィールド要素のオクテットストリング表現でなければなりません。 ECPointの値は[X9.62]に変換ルーチン、セクション4.3.6以下楕円曲線点のオクテットストリング表現でなければなりません。このオクテットストリングは、圧縮または非圧縮形態における楕円曲線点を表してもよいことに留意されたいです。
Implementations that support elliptic curve according to this specification MUST support the uncompressed form and MAY support the compressed form.
この仕様によれば、楕円曲線をサポートする実装は、非圧縮形式をサポートしなければならないし、圧縮された形式をサポートするかもしれません。
The components of type ECParameters have the following meanings:
型ECParametersのコンポーネントには以下の意味があります。
version specifies the version number of the elliptic curve parameters. It MUST have the value 1 (ecpVer1).
バージョンは、楕円曲線パラメータのバージョン番号を指定します。これは、値1（ecpVer1）が必要です。
fieldID identifies the finite field over which the elliptic curve is defined. Finite fields are represented by values of the parameterized type FieldID, constrained to the values of the objects defined in the information object set FieldTypes. Additional detail regarding fieldID is provided below.
fieldidは、楕円曲線が定義される上に、有限フィールドを識別する。有限体は、情報オブジェクトセットFieldTypesで定義されたオブジェクトの値に制約パラメータ化された型フィールド識別子の値によって表されます。フィールド識別子に関する追加の詳細は以下に提供されます。
curve specifies the coefficients a and b of the elliptic curve E. Each coefficient is represented as a value of type FieldElement, an OCTET STRING. seed is an optional parameter used to derive the coefficients of a randomly generated elliptic curve.
曲線は、各係数がタイプFieldElement、オクテットストリングの値として表される楕円曲線Eの係数a、bを指定します。種子は、ランダムに生成された楕円曲線の係数を導出するために使用されるオプションのパラメータです。
base specifies the base point P on the elliptic curve. The base point is represented as a value of type ECPoint, an OCTET STRING.
塩基は、楕円曲線上のベース点Pを指定します。基点は、タイプECPoint、オクテットストリングの値として表されます。
order specifies the order n of the base point.
順序は、ベースポイントの次数nを指定します。
cofactor is the integer h = #E(Fq)/n. This parameter is specified as OPTIONAL. However, the cofactor MUST be included in ECDH public key parameters. The cofactor is not required to support ECDSA, except in parameter validation. The cofactor MAY be included to support parameter validation for ECDSA keys. Parameter validation is not required by this specification.
補因子は、整数、H = #E（体F q）/ Nです。このパラメータはオプションとして指定されています。しかし、補因子はECDH公開鍵のパラメータに含めなければなりません。補因子は、パラメータの検証を除き、ECDSAをサポートする必要はありません。補因子は、ECDSAキーのパラメータの検証をサポートするために含まれるかもしれません。パラメータの検証は、この仕様によって必要とされていません。
The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the elliptic curve parameters are specified as implicitlyCA in the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using ECDSA, then the certificate issuer's ECDSA parameters apply to the subject's ECDSA key. If the elliptic curve parameters are specified as implicitlyCA in the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the certificate using a signature algorithm other than ECDSA, then clients MUST not make use of the elliptic curve public key.
SubjectPublicKeyInfoで以内のAlgorithmIdentifierパラメータを使用することができる証明書内の唯一の場所です。楕円曲線パラメータがSubjectPublicKeyInfoでのAlgorithmIdentifierでimplicitlyCAとして指定し、CAは、ECDSAを用いて対象証明書に署名している場合は、証明書発行者のECDSAパラメータは、被験者のECDSAキーに適用します。楕円曲線パラメータがSubjectPublicKeyInfoでのAlgorithmIdentifierでimplicitlyCAとして指定し、CAがECDSA以外の署名アルゴリズムを使用して証明書に署名している場合、クライアントは楕円曲線公開鍵を使用してはなりません。
FieldID ::= SEQUENCE {
fieldType OBJECT IDENTIFIER,
parameters ANY DEFINED BY fieldType }
FieldID is a SEQUENCE of two components, fieldType and parameters. The fieldType contains an object identifier value that uniquely identifies the type contained in the parameters.
fieldidは、二つの成分、FIELDTYPEおよびパラメータの配列です。 FIELDTYPE一意のパラメータに含まれるタイプを識別するオブジェクト識別子の値を含みます。
The object identifier id-fieldType specifies an arc containing the object identifiers of each field type. It has the following value:
オブジェクト識別子ID-FIELDTYPEは、各フィールドタイプのオブジェクト識別子を含むアークを指定します。それは次の値があります。
id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
The object identifiers prime-field and characteristic-two-field name the two kinds of fields defined in this Standard. They have the following values:
オブジェクト識別子プライムフィールド及び特性-2フィールド名、この規格で定義されたフィールドの二種類。彼らは、次の値が設定されています
prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
Prime-p ::= INTEGER -- Field size p (p in bits)
characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m
basis OBJECT IDENTIFIER,
parameters ANY DEFINED BY basis }
The object identifier id-characteristic-two-basis specifies an arc containing the object identifiers for each type of basis for the characteristic-two finite fields. It has the following value:
オブジェクト識別子ID-特性-二基礎特性、2つの有限フィールドの基礎の各タイプのオブジェクト識別子を含むアークを指定します。それは次の値があります。
id-characteristic-two-basis OBJECT IDENTIFIER ::= {
characteristic-two-field basisType(1) }
The object identifiers gnBasis, tpBasis and ppBasis name the three kinds of basis for characteristic-two finite fields defined by [X9.62]. They have the following values:
オブジェクト識別子gnBasis、tpBasisとppBasis名[X9.62]によって定義された特性、2つの有限フィールドの基礎の三種類。彼らは、次の値が設定されています
gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
-- for gnBasis, the value of the parameters field is NULL
- gnBasisのために、パラメータフィールドの値はNULLです
tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
-- type of parameters field for tpBasis is Trinomial
- tpBasisためのパラメータフィールドのタイプは、三項です
Trinomial ::= INTEGER
ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
-- type of parameters field for ppBasis is Pentanomial
- ppBasisためのパラメータフィールドのタイプがあるPentanomial
Pentanomial ::= SEQUENCE {
k1 INTEGER,
k2 INTEGER,
k3 INTEGER }
The elliptic curve public key (an ECPoint which is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curve according to this specification MUST support the uncompressed form and MAY support the compressed form.
オクテット文字列の最上位ビットはビット列の最上位ビットと最下位ビットとなる次のように楕円曲線公開鍵（オクテット列であるECPointは）のsubjectPublicKey（ビット列）にマップされオクテット文字列のビット列の最下位ビットになります。このオクテットストリングは、圧縮または非圧縮形態における楕円曲線点を表してもよいことに留意されたいです。この仕様によれば、楕円曲線をサポートする実装は、非圧縮形式をサポートしなければならないし、圧縮された形式をサポートするかもしれません。
If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:
keyUsage拡張子は、楕円曲線公開鍵を伝えるCAまたはCRLの発行者証明書内に存在する場合、以下の値の任意の組み合わせが存在することがあります。
digitalSignature; nonRepudiation; and keyAgreement.
デジタル署名;否認防止;そして、するKeyAgreement。
If the keyAgreement value is present, either of the following values MAY be present:
するKeyAgreement値が存在する場合は、次の値のいずれかが存在することがあります。
encipherOnly; and decipherOnly.
encipherOnly;そしてdecipherOnly。
The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.
keyUsageの拡張は、encipherOnlyとdecipherOnlyの両方を主張してはなりません。
If the keyUsage extension is present in a CA certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:
KeyUsage拡張は、楕円曲線公開鍵を伝達するCA証明書内に存在する場合、以下の値の任意の組み合わせが存在することがあります。
digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.
As above, if the keyUsage extension asserts keyAgreement then it MAY assert either encipherOnly and decipherOnly. However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
keyUsage拡張子がするKeyAgreementを主張する場合は、上記のとおり、それはencipherOnlyとdecipherOnlyのいずれかをアサートしてもよいです。しかし、この仕様はKeyCertSignがまたはcRLSignが存在する場合、するKeyAgreement、encipherOnly、およびdecipherOnlyが存在してはならないことをお勧めします。
3 ASN.1 Module
3 ASN.1モジュール
PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms(17) }
PKIX1Algorithms88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-pkix1・アルゴリズム（17）}
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS All;
- すべてのエクスポート。
-- IMPORTS NONE;
- NONE輸入ません。
-- -- One-way Hash Functions --
- - 一方向ハッシュ関数 -
md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 2 }
md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 5 }
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) 26 }
-- -- DSA Keys and Signatures --
- - DSA鍵と署名 -
-- OID for DSA public key
- DSA公開鍵のOID
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
-- encoding for DSA public key
- DSA公開鍵のエンコーディング
DSAPublicKey ::= INTEGER -- public key, y
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
-- OID for DSA signature generated with SHA-1 hash
- SHA-1ハッシュを用いて生成されたDSA署名のためのOID
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
-- encoding for DSA signature generated with SHA-1 hash
- SHA-1ハッシュを用いて生成されたDSA署名の符号化
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
-- -- RSA Keys and Signatures --
- - RSA鍵と署名 -
-- arc for RSA public key and RSA signature OIDs
- RSA公開鍵とRSA署名のOIDのためのアーク
pkcs-1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
-- OID for RSA public keys
- RSA公開鍵のOID
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-- OID for RSA signature generated with MD2 hash
- MD2ハッシュで生成されたRSA署名のためのOID
md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
-- OID for RSA signature generated with MD5 hash
- MD5ハッシュを用いて生成されたRSA署名のためのOID
md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
-- OID for RSA signature generated with SHA-1 hash
- SHA-1ハッシュを用いて生成されたRSA署名のためのOID
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
-- encoding for RSA public key
- RSA公開鍵のエンコーディング
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
-- -- Diffie-Hellman Keys --
- - のDiffie-Hellmanの鍵 -
dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046)
number-type(2) 1 }
-- encoding for DSA public key
- DSA公開鍵のエンコーディング
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor, j>= 2
validationParms ValidationParms OPTIONAL }
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
-- -- KEA Keys --
- - KEAキー -
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
{ 2 16 840 1 101 2 1 1 22 }
KEA-Parms-Id ::= OCTET STRING
-- -- Elliptic Curve Keys, Signatures, and Curves --
- - 楕円曲線キー、署名、および曲線 -
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
FieldID ::= SEQUENCE { -- Finite field
fieldType OBJECT IDENTIFIER,
parameters ANY DEFINED BY fieldType }
-- Arc for ECDSA signature OIDS
- ECDSA署名OIDS用アーク
id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
-- OID for ECDSA signatures with SHA-1
- SHA-1 ECDSA署名のためのOID
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
-- OID for an elliptic curve signature -- format for the value of an ECDSA signature value
- 楕円曲線署名のためのOID - ECDSA署名値の値のフォーマット
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
-- recognized field type OIDs are defined in the following arc
- 認識されたフィールドタイプのOIDは、以下の円弧で定義されています
id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
-- where fieldType is prime-field, the parameters are of type Prime-p
- FIELDTYPEはプライム・フィールドがある場合、パラメータは、タイププライム-Pのあります
prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime
-- where fieldType is characteristic-two-field, the parameters are -- of type Characteristic-two
- FIELDTYPE特性-2フィールドである場合、パラメータは、 - 型の特徴個
characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m
basis OBJECT IDENTIFIER,
parameters ANY DEFINED BY basis }
-- recognized basis type OIDs are defined in the following arc
- 認識された基本型のOIDは、以下の円弧で定義されています
id-characteristic-two-basis OBJECT IDENTIFIER ::= {
characteristic-two-field basisType(3) }
-- gnbasis is identified by OID gnBasis and indicates -- parameters are NULL
- gnbasisはOID gnBasisによって識別さを示している - パラメータがNULLであります
gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
-- parameters for this basis are NULL
- この基礎のためのパラメータがNULLです
-- trinomial basis is identified by OID tpBasis and indicates -- parameters of type Pentanomial
- 三項基礎はOID tpBasisによって識別さを示している - タイプPentanomialのパラメータ
tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
-- Trinomial basis representation of F2^m -- Integer k for reduction polynomial xm + xk + 1
- F2の三項基底表現^ M - 還元多項式XM + XK + 1に対する整数k
Trinomial ::= INTEGER
-- for pentanomial basis is identified by OID ppBasis and indicates -- parameters of type Pentanomial
- pentanomial基づいためOID ppBasisによって識別さを示している - タイプPentanomialのパラメータ
ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
-- Pentanomial basis representation of F2^m -- reduction polynomial integers k1, k2, k3 -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
還元多項式整数K1、K2、K3 - - F（X）= X ** M + X ** K3 + X ** K2 + X ** K1 + 1 - F2 ^ MのPentanomial基底表現
Pentanomial ::= SEQUENCE {
k1 INTEGER,
k2 INTEGER,
k3 INTEGER }
-- The object identifiers gnBasis, tpBasis and ppBasis name -- three kinds of basis for characteristic-two finite fields
- オブジェクト識別子gnBasis、tpBasisとppBasis名 - 特性-2有限体の基礎の3種類
FieldElement ::= OCTET STRING -- Finite field element
ECPoint ::= OCTET STRING -- Elliptic curve point
-- Elliptic Curve parameters may be specified explicitly, -- specified implicitly through a "named curve", or -- inherited from the CA
- 楕円曲線のパラメータは、明示的に指定することができる - 「と名付けられた曲線」によって暗黙的に指定、または - CAから継承されました
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
ECParameters ::= SEQUENCE { -- Elliptic curve parameters
version ECPVer,
fieldID FieldID,
curve Curve,
base ECPoint, -- Base point G
order INTEGER, -- Order n of the base point
cofactor INTEGER OPTIONAL } -- The integer h = #E(Fq)/n
ECPVer ::= INTEGER {ecpVer1(1)}
Curve ::= SEQUENCE {
a FieldElement, -- Elliptic curve coefficient a
b FieldElement, -- Elliptic curve coefficient b
seed BIT STRING OPTIONAL }
id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) }
id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
-- Named Elliptic Curves in ANSI X9.62.
- ANSI X9.62に楕円曲線を名前付き。
ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }
c-TwoCurve OBJECT IDENTIFIER ::= {
ellipticCurve characteristicTwo(0) }
c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 }
c2pnb163v2 OBJECT IDENTIFIER ::= { c-TwoCurve 2 }
c2pnb163v3 OBJECT IDENTIFIER ::= { c-TwoCurve 3 }
c2pnb176w1 OBJECT IDENTIFIER ::= { c-TwoCurve 4 }
c2tnb191v1 OBJECT IDENTIFIER ::= { c-TwoCurve 5 }
c2tnb191v2 OBJECT IDENTIFIER ::= { c-TwoCurve 6 }
c2tnb191v3 OBJECT IDENTIFIER ::= { c-TwoCurve 7 }
c2onb191v4 OBJECT IDENTIFIER ::= { c-TwoCurve 8 }
c2onb191v5 OBJECT IDENTIFIER ::= { c-TwoCurve 9 }
c2pnb208w1 OBJECT IDENTIFIER ::= { c-TwoCurve 10 }
c2tnb239v1 OBJECT IDENTIFIER ::= { c-TwoCurve 11 }
c2tnb239v2 OBJECT IDENTIFIER ::= { c-TwoCurve 12 }
c2tnb239v3 OBJECT IDENTIFIER ::= { c-TwoCurve 13 }
c2onb239v4 OBJECT IDENTIFIER ::= { c-TwoCurve 14 }
c2onb239v5 OBJECT IDENTIFIER ::= { c-TwoCurve 15 }
c2pnb272w1 OBJECT IDENTIFIER ::= { c-TwoCurve 16 }
c2pnb304w1 OBJECT IDENTIFIER ::= { c-TwoCurve 17 }
c2tnb359v1 OBJECT IDENTIFIER ::= { c-TwoCurve 18 }
c2pnb368w1 OBJECT IDENTIFIER ::= { c-TwoCurve 19 }
c2tnb431r1 OBJECT IDENTIFIER ::= { c-TwoCurve 20 }
primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }
prime192v1 OBJECT IDENTIFIER ::= { primeCurve 1 }
prime192v2 OBJECT IDENTIFIER ::= { primeCurve 2 }
prime192v3 OBJECT IDENTIFIER ::= { primeCurve 3 }
prime239v1 OBJECT IDENTIFIER ::= { primeCurve 4 }
prime239v2 OBJECT IDENTIFIER ::= { primeCurve 5 }
prime239v3 OBJECT IDENTIFIER ::= { primeCurve 6 }
prime256v1 OBJECT IDENTIFIER ::= { primeCurve 7 }
END
終わり
4 References
4つの参考文献
[FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. [Supersedes FIPS PUB 180 dated 11 May 1993.]
[FIPS 180-1]連邦情報処理規格出版（FIPS PUBの）180-1、セキュアハッシュ標準、4月17日1995年[1993年5月11日付けの取って代わるのFIPS PUB 180]
[FIPS 186-2] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 27 January 2000. [Supersedes FIPS PUB 186-1 dated 15 December 1998.]
[FIPS 186-2]連邦情報処理規格出版（FIPS PUBの）186、デジタル署名標準、1月27日2000年[1998年12月15日付けより優先FIPS PUB 186-1]
[P1363] IEEE P1363, "Standard Specifications for Public-Key Cryptography", 2001.
[P1363] IEEE P1363、 "公開鍵暗号のための標準仕様"、2001年。
[RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2 is not collision free," Presented at Selected Areas in Cryptography '95, May 1995.
[RC95]ロジェ、N.とChauvaud、P.、「MD2の圧縮機能は、衝突の自由ではない、」暗号'95、1995年5月には選択された領域で発表。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
[RFC 1319] Kaliski、B.、 "MD2メッセージダイジェストアルゴリズム"、RFC 1319、1992年4月。
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC 1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[RFC 1422]ケント、S.、 "インターネット電子メールのためのプライバシー増進：パートII：証明書ベースのキー管理"、RFC 1422、1993年2月。
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[RFC 1423] Balenson、D.、 "インターネット電子メールのためのプライバシー増進：パートIII：アルゴリズム、モード、および識別子"、RFC 1423、1993年2月。
[RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[RFC 2313] Kaliski、B.、 "PKCS＃1：RSA暗号化バージョン1.5"、RFC 2313、1998年3月。
[RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January, 1999.
[RFC 2459] Housley氏、R.、フォード、W.、ポーク、W.およびD.ソロ "インターネットX.509公開鍵インフラストラクチャ：証明書とCRLプロファイル"、RFC 2459、1999年1月。
[RFC 3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC 3174]イーストレイク、D.とP.ジョーンズは、 "米国は、ハッシュアルゴリズム1（SHA1）を確保"、RFC 3174、2001年9月。
[RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC 3280] Housley氏、R.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[SDN.701r] SDN.701, "Message Security Protocol 4.0", Revision A 1997-02-06.
[SDN.701r] SDN.701、 "メッセージセキュリティプロトコル4.0"、改訂A 1997年2月6日。
[X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[X.208] CCITT勧告X.208：抽象構文記法1（ASN.1）、1988の仕様。
[X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997.
[X.660] ITU-T勧告X.660情報技術 - ASN.1符号化ルール：基本符号化規則（BER）、Canonicalの符号化規則（CER）と識別符号化規則（DER）、1997年仕様。
[X9.42] ANSI X9.42-2000, "Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", December, 1999.
[X9.42] ANSI X9.42-2000、「金融サービス業界向け公開鍵暗号：離散対数暗号使用対称鍵の契約」、12月、1999年。
[X9.62] X9.62-1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", January 7, 1999.
[X9.62] X9.62-1998、「金融サービス業界のための公開鍵暗号：楕円曲線デジタル署名アルゴリズム（ECDSA）」、1999年1月7日。
[X9.63] ANSI X9.63-2001, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", Work in Progress.
[X9.63] ANSI X9.63-2001、「金融サービス業界のための公開鍵暗号：鍵合意と楕円曲線暗号を使用した主な交通」が進行中で働いています。
5 Security Considerations
5セキュリティに関する考慮事項
This specification does not constrain the size of public keys or their parameters for use in the Internet PKI. However, the key size selected impacts the strength achieved when implementing cryptographic services. Selection of appropriate key sizes is critical to implementing appropriate security.
この仕様は、公開鍵またはインターネットPKIでの使用のためにそれらのパラメータの大きさを制限しません。暗号化サービスを実装するときただし、キーのサイズ選択の影響は強度を実現しました。適切なキーサイズの選択は、適切なセキュリティを実装するために重要です。
This specification does not identify particular elliptic curves for use in the Internet PKI. However, the particular curve selected impact the strength of the digital signatures. Some curves are cryptographically stronger than others!
この仕様は、インターネットPKIでの使用のために特定の楕円曲線を識別しません。しかし、特定の曲線は、デジタル署名の強度に影響を与える選択されました。いくつかの曲線は、他の人よりも、暗号強いです！
In general, use of "well-known" curves, such as the "named curves" from ANSI X9.62, is a sound strategy. For additional information, refer to X9.62 Appendix H.1.3, "Key Length Considerations" and Appendix A.1, "Avoiding Cryptographically Weak Keys".
一般に、このようなANSI X9.62から「という名前の曲線」と「既知の」曲線の使用は、音の戦略です。詳細については、「暗号で弱い鍵の回避」、X9.62付録H.1.3、「キー長の考慮事項」および付録A.1を参照してください。
This specification supplements RFC 3280. The security considerations section of that document applies to this specification as well.
この仕様では、そのドキュメントのセキュリティに関する考慮事項のセクションが同様にこの仕様に適用されるRFC 3280を補足します。
6 Intellectual Property Rights
6知的財産権
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックとstandards-関連文書の権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
7 Author Addresses:
7つの著者アドレス：
Tim Polk NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USA EMail: tim.polk@nist.gov
ティムポークNIST 100局ドライブ、ストップ8930ゲイサーズバーグ、MD 20899から8930 USA電子メール：tim.polk@nist.gov
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: rhousley@rsasecurity.com
ラッセルHousleyのRSA Laboratories社918春小山Driveハーンドン、VA 20170 USA電子メール：rhousley@rsasecurity.com
Larry Bassham NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USA EMail: lbassham@nist.gov
ラリーBassham NIST 100局ドライブ、ストップ8930ゲイサーズバーグ、MD 20899から8930 USA電子メール：lbassham@nist.gov
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。