RFC2314 日本語訳
2314 PKCS #10: Certification Request Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT=15814 bytes) (Obsoleted by RFC2986) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Kaliski Request for Comments: 2314 RSA Laboratories East Category: Informational March 1998
Kaliskiがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2314年のRSA研究所東洋カテゴリ: 情報の1998年3月
PKCS #10: Certification Request Syntax
Version 1.5
PKCS#10: 証明要求構文バージョン1.5
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Overview
概要
This document describes a syntax for certification requests.
このドキュメントは証明要求のための構文について説明します。
1. Scope
1. 範囲
A certification request consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. Certification requests are sent to a certification authority, who transforms the request to an X.509 public-key certificate, or a PKCS #6 extended certificate. (In what form the certification authority returns the newly signed certificate is outside the scope of this document. A PKCS #7 message is one possibility.)
証明要求は分類名から成ります、公開鍵、そして、任意に、aが証明を要求する実体によってまとめて署名される属性をセットしました。 証明権威、だれが要求をX.509公開鍵証明書に変えるか、そして、またはPKCS#6の拡張証明書に証明要求を送ります。 (このドキュメントの範囲の外に証明権威がどんなフォームで新たに署名している証明書を返すかがあります。 PKCS#7メッセージは1つの可能性です。)
The intention of including a set of attributes is twofold: to provide other information about a given entity, such as the postal address to which the signed certificate should be returned if electronic mail is not available, or a "challenge password" by which the entity may later request certificate revocation; and to provide attributes for a PKCS #6 extended certificate. A non-exhaustive list of attributes is given in PKCS #9.
1セットの属性を含んでいるという意志は二つです: 電子メールが利用可能でないなら署名入りの証書が返されるべきである郵便の宛先、または実体が後で証明書取消しを要求するかもしれない「挑戦パスワード」などの与えられた実体に関して他の情報を提供するために。 そして、PKCS#6、に属性を提供するのは証明書を広げました。 PKCS#9で属性に関する非完全なりストを与えます。
Certification authorities may also require non-electronic forms of request and may return non-electronic replies. It is expected that descriptions of such forms, which are outside the scope of this document, will be available from the certification authority.
証明当局は、また、要求の非電子申込書を必要として、非電子の回答を返すかもしれません。 このドキュメントの範囲の外にあるそのような形式の記述が証明権威から利用可能になると予想されます。
Kaliski Informational [Page 1] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[1ページ]のRFC2314PKCS#10: 証明要求構文行進1998
The preliminary intended application of this document is to support PKCS #7 cryptographic messages, but is expected that other applications will be developed.
このドキュメントの予備の意図しているアプリケーションは、サポートPKCS#7の暗号のメッセージにはありますが、予想されて、その他のアプリケーションが開発されるということです。
2. References
2. 参照
PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption
Standard. Version 1.5, November 1993.
PKCS#1RSA研究所。 PKCS#1: RSA暗号化規格。 1993年11月のバージョン1.5。
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
Syntax. Version 1.5, November 1993.
PKCS#6つのRSA研究所。 PKCS#6: 拡張証明書構文。 1993年11月のバージョン1.5。
PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message
Syntax. Version 1.5, November 1993.
PKCS#7つのRSA研究所。 PKCS#7: 暗号のメッセージ構文。 1993年11月のバージョン1.5。
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
Types. Version 1.1, November 1993.
PKCS#9つのRSA研究所。 PKCS#9: 属性タイプを選びました。 1993年11月のバージョン1.1。
RFC 1424 Kaliski, B., "Privacy Enhancement for
Internet Electronic Mail: Part IV: Key
Certification and Related Services," RFC 1424,
February 1993.
RFC1424Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、1993年2月。
X.208 CCITT. Recommendation X.208: Specification of
Abstract Syntax Notation One (ASN.1). 1988.
X.208CCITT。 推薦X.208: 抽象構文記法1(ASN.1)の仕様。 1988.
X.209 CCITT. Recommendation X.209: Specification of
Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1). 1988.
X.209CCITT。 推薦X.209: 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 1988.
X.500 CCITT. Recommendation X.500: The Directory--
Overview of Concepts, Models and
Services. 1988.
X.500CCITT。 推薦X.500: ディレクトリ--概念の、そして、モデルの、そして、サービスの概要。 1988.
X.501 CCITT. Recommendation X.501: The Directory--
Models. 1988.
X.501CCITT。 推薦X.501: ディレクトリ--モデル。 1988.
X.509 CCITT. Recommendation X.509: The Directory--
Authentication Framework. 1988.
X.509CCITT。 推薦X.509: ディレクトリ--認証フレームワーク。 1988.
3. Definitions
3. 定義
For the purposes of this document, the following definitions apply.
このドキュメントの目的のために、以下の定義は申し込まれます。
AlgorithmIdentifier: A type that identifies an algorithm (by object identifier) and any associated parameters. This type is defined in X.509.
AlgorithmIdentifier: アルゴリズムを特定する(オブジェクト識別子で)タイプといずれもパラメタを関連づけました。 このタイプはX.509で定義されます。
Kaliski Informational [Page 2] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[2ページ]のRFC2314PKCS#10: 証明要求構文行進1998
Attribute: A type that contains an attribute type (specified by object identifier) and one or more attribute values. This type is defined in X.501.
以下を結果と考えてください。 属性タイプ(オブジェクト識別子で、指定される)と1つ以上の属性値を含むタイプ。 このタイプはX.501で定義されます。
ASN.1: Abstract Syntax Notation One, as defined in X.208.
ASN.1: X.208で定義されるような抽象的なSyntax Notation One。
BER: Basic Encoding Rules, as defined in X.209.
BER: X.209で定義されるような基本的なEncoding Rules。
Certificate: A type that binds an entity's distinguished name to a public key with a digital signature. This type is defined in X.509. This type also contains the distinguished name of the certificate issuer (the signer), an issuer- specific serial number, the issuer's signature algorithm identifier, and a validity period.
以下を証明してください。 デジタル署名で実体の分類名を公開鍵に縛るタイプ。 このタイプはX.509で定義されます。 また、このタイプは証明書発行人(署名者)、発行人の特定の通し番号、発行人の署名アルゴリズム識別子、および有効期間の分類名を含んでいます。
DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, Section 8.7.
DER: ASN.1のためのX.509、セクション8.7で定義されるような顕著なEncoding Rules。
Name: A type that uniquely identifies or "distinguishes" objects in a X.500 directory. This type is defined in X.501. In an X.509 certificate, the type identifies the certificate issuer and the entity whose public key is certified.
以下を命名してください。 それが唯一特定するか、または「区別する」タイプはX.500ディレクトリで反対します。 このタイプはX.501で定義されます。 X.509証明書では、タイプは証明書発行人と公開鍵が公認される実体を特定します。
4. Symbols and abbreviations
4. シンボルと略語
No symbols or abbreviations are defined in this document.
どんなシンボルも略語も本書では定義されません。
5. General overview
5. 概要
The next section specifies certification request syntax.
次のセクションは証明要求構文を指定します。
This document exports one type, CertificationRequest.
このドキュメントは1つのタイプ、CertificationRequestをエクスポートします。
6. Certification request syntax
6. 証明要求構文
This section gives the syntax for certification requests.
このセクションは証明要求のための構文を与えます。
A certification request consists of three parts: "certification request information," a signature algorithm identifier, and a digital signature on the certification request information. The certification request information consists of the entity's distinguished name, the entity's public key, and a set of attributes providing other information about the entity.
証明要求は3つの部品から成ります: 「証明要求情報」、署名アルゴリズム識別子、および証明要求情報におけるデジタル署名。 証明要求情報は実体の他の情報を提供する属性の実体の分類名、実体の公開鍵、およびセットから成ります。
Kaliski Informational [Page 3] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[3ページ]のRFC2314PKCS#10: 証明要求構文行進1998
The process by which a certification request is constructed involves the following steps:
証明要求が構成されるプロセスは以下のステップにかかわります:
1. A CertificationRequestInfo value containing a
distinguished name, a public key, and optionally a set of
attributes is constructed by an entity.
1. 分類名を含む公開鍵をCertificationRequestInfoは評価します、そして、任意に、1セットの属性は実体によって構成されます。
2. The CertificationRequestInfo value is signed with
the entity's private key. (See Section 6.2.)
2. CertificationRequestInfo値は実体の秘密鍵を契約されます。 (セクション6.2を見てください。)
3. The CertificationRequestInfo value, a signature
algorithm identifier, and the entity's signature are
collected together into a CertificationRequest value,
defined below.
3. CertificationRequestInfo値、署名アルゴリズム識別子、および実体の署名は以下で定義されたCertificationRequest値に一緒に集められます。
A certification authority fulfills the request by verifying the entity's signature, and, if it is valid, constructing a X.509 certificate from the distinguished name and public key, as well as an issuer name, serial number, validity period, and signature algorithm of the certification authority's choice. If the certification request contains a PKCS #9 extended-certificate-attributes attribute, the certification authority also constructs a PKCS #6 extended certificate from the X.509 certificate and the extended-certificate- attributes attribute value.
証明権威はそれが有効であり証明権威の選択の実体の署名について確かめて、分類名と公開鍵からのX.509証明書を構成して、発行人名、通し番号、有効期間、および署名アルゴリズムで要求を実現させます。 また、証明要求がPKCS#9拡張証明書属性属性を含んでいるなら、証明権威はX.509証明書からのPKCS#6の拡張証明書と拡張証明書の属性の属性値を構成します。
In what form the certification authority returns the new certificate is outside the scope of this document. One possibility is a PKCS #7 cryptographic message with content type signedData, following the degenerate case where there are no signers. The return message may include a certification path from the new certificate to the certification authority. It may also include other certificates such as cross-certificates that the certification authority considers helpful, and it may include certificate-revocation lists (CRLs). Another possibility is that the certification authority inserts the new certificate into a central database.
このドキュメントの範囲の外に証明権威がどんなフォームで新しい証明書を返すかがあります。 1つの可能性がcontent type signedDataがあるPKCS#7の暗号のメッセージです、署名者が全くない堕落したケースに従って。 リターンメッセージは新しい証明書から証明権威までの証明経路を含むかもしれません。 また、それは証明権威が役立っていると考える交差している証明書などの他の証明書を含むかもしれません、そして、証明書失効リスト(CRLs)を含むかもしれません。 別の可能性は証明権威が新しい証明書を主要なデータベースに挿入するということです。
This section is divided into two parts. The first part describes the certification-request-information type CertificationRequestInfo, and the second part describes the top-level type CertificationRequest.
このセクションは2つの部品に分割されます。 最初の部分は証明要求情報タイプCertificationRequestInfoについて説明します、そして、第二部はトップレベルタイプCertificationRequestについて説明します。
Notes.
注意。
1. An entity would typically send a certification
request after generating a public-key/private-key pair, but
may also do so after a change in the entity's distinguished
name.
1. 公開鍵/秘密鍵組を生成した後に証明要求を通常送るでしょうが、また、実体の分類名における変化の後にそう存在するかもしれません。
Kaliski Informational [Page 4] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[4ページ]のRFC2314PKCS#10: 証明要求構文行進1998
2. The signature on the certification request
prevents an entity from requesting a certificate with
another party's public key. Such an attack would give the
entity the minor ability to pretend to be the originator of
any message signed by the other party. This attack is
significant only if the entity does not know the message
being signed, and the signed part of the message does not
identify the signer. The entity would still not be able to
decrypt messages intended for the other party, of course.
2. 証明要求の署名は、実体が別のパーティーの公開鍵で証明書を要求するのを防ぎます。 そのような攻撃は相手によって署名されたどんなメッセージの創始者であるもふりをする小さい方の能力を実体に与えるでしょう。 実体が署名されるメッセージを知らない場合にだけ、この攻撃は重要です、そして、メッセージの署名している部分は署名者を特定しません。 実体がまだ相手のために意図するメッセージを解読することができないだろう、もちろん。
3. How the entity sends the certification request to
a certification authority is outside the scope of this
document. Both paper and electronic forms are possible.
3. このドキュメントの範囲の外に実体がどう証明要求を証明権威に送るかがあります。 紙と電子申込書の両方が可能です。
4. This document is not compatible with the
certification request syntax for Privacy-Enhanced Mail, as
described in RFC 1424. The syntax in this document differs
in three respects: It allows a set of attributes; it does
not include issuer name, serial number, or validity period;
and it does not require an "innocuous" message to be
signed. The syntax in this document is designed to minimize
request size, an important constraint for those
certification authorities accepting requests on paper.
4. Privacyによって高められたメールにおいて、このドキュメントはRFC1424で説明されるように証明要求構文と互換性がありません。 構文は3つの点において本書では異なります: それは1セットの属性を許容します。 それは発行人名、通し番号、または有効期間を含んでいません。 そして、それは署名するべき「無毒」のメッセージを必要としません。 構文は、要求サイズ(紙上の要求を受け入れるそれらの証明当局の重要な規制)を最小にするように本書では設計されています。
6.1 CertificationRequestInfo
6.1 CertificationRequestInfo
Certification request information shall have ASN.1 type CertificationRequestInfo:
証明要求情報で、ASN.1はCertificationRequestInfoをタイプするものとします:
CertificationRequestInfo ::= SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes }
CertificationRequestInfo:、:= 系列バージョンバージョン、対象のName、subjectPublicKeyInfo SubjectPublicKeyInfo、属性[0]IMPLICIT Attributes
Version ::= INTEGER
バージョン:、:= 整数
Attributes ::= SET OF Attribute
属性:、:= 属性のセット
The fields of type CertificationRequestInfo have the following meanings:
タイプCertificationRequestInfoの分野には、以下の意味があります:
o version is the version number, for compatibility
with future revisions of this document. It shall be 0 for
this version of the document.
o バージョンはこのドキュメントの今後の改正との互換性のバージョン番号です。 それはドキュメントのこのバージョンのために0になるでしょう。
Kaliski Informational [Page 5] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[5ページ]のRFC2314PKCS#10: 証明要求構文行進1998
o subject is the distinguished name of the
certificate subject (the entity whose public key is to be
certified).
o 対象は証明書対象(公認される公開鍵がことである実体)の分類名です。
o subjectPublicKeyInfo contains information about
the public key being certified. The information identifies
the entity's public-key algorithm (and any associated
parameters); examples of public-key algorithms include
X.509's rsa and PKCS #1's rsaEncryption. The information
also includes a bit-string representation of the entity's
public key. For both public-key algorithms just mentioned,
the bit string contains the BER encoding of a value of
X.509/PKCS #1 type RSAPublicKey.
o 公認されていて、subjectPublicKeyInfoは公開鍵の情報を含んでいます。 情報は実体の公開鍵アルゴリズム(そして、どんな関連パラメタも)を特定します。 公開鍵アルゴリズムに関する例はX.509のrsaとPKCS#1rsaEncryptionを含んでいます。 また、情報は実体の公開鍵のしばらくストリング表現を含んでいます。 ただ言及された両方の公開鍵アルゴリズムのために、ビット列はX.509/PKCS#1タイプRSAPublicKeyの価値のBERコード化を含んでいます。
o attributes is a set of attributes providing
additional information about the subject of the
certificate. Some attribute types that might be useful here
are defined in PKCS #9. An example is the challenge-
password attribute, which specifies a password by which the
entity may request that the certificate revocation. Another
example is the extended-certificate-attributes attribute,
which specifies attributes for a PKCS #6 extended
certificate.
o 属性は証明書に関する追加情報を提供する1セットの属性です。 ここで役に立つかもしれない属性タイプの中にはPKCS#9で定義される人もいます。 例は挑戦パスワード属性です、実体がそれを要求するかもしれないパスワードを指定するもの。証明書取消し。 別の例は拡張証明書属性属性です。(その属性はPKCS#6の拡張証明書に属性を指定します)。
6.2 CertificationRequest
6.2 CertificationRequest
A certification request shall have ASN.1 type CertificationRequest:
証明要求で、ASN.1はCertificationRequestをタイプするものとします:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
CertificationRequest:、:= 系列certificationRequestInfo CertificationRequestInfo、signatureAlgorithm SignatureAlgorithmIdentifier、署名Signature
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier:、:= AlgorithmIdentifier
Signature ::= BIT STRING
署名:、:= ビット列
The fields of type CertificationRequest have the following meanings:
タイプCertificationRequestの分野には、以下の意味があります:
o certificateRequestInfo is the "certification
request information." It is the value being
signed.
o certificateRequestInfoは「証明要求情報」です。 それは署名される値です。
o signatureAlgorithm identifies the signature
algorithm (and any associated parameters) under
which the certification-request information is
signed. Examples include PKCS #1's
md2WithRSAEncryption and md5WithRSAEncryption.
o signatureAlgorithmは証明要求情報に署名する署名アルゴリズム(そして、どんな関連パラメタも)を特定します。 例はPKCS#1のmd2WithRSAEncryptionとmd5WithRSAEncryptionを含んでいます。
Kaliski Informational [Page 6] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[6ページ]のRFC2314PKCS#10: 証明要求構文行進1998
o signature is the result of signing the
certification request information with the
certification request subject's private key.
o 署名は証明要求対象の秘密鍵で証明要求が情報であると署名するという結果です。
The signature process consists of two steps:
署名プロセスは以下の2ステップから成ります:
1. The value of the certificationRequestInfo field is
DER encoded, yielding an octet string.
1. certificationRequestInfo分野の値は八重奏ストリングをもたらして、コード化されたDERです。
2. The result of step 1 is signed with the
certification request subject's private key under
the specified signature algorithm, yielding a bit
string, the signature.
2. ステップ1の結果は指定された署名アルゴリズムの下で証明要求対象の秘密鍵を契約されます、ストリング(署名)を少しもたらして
Note. The syntax for CertificationRequest could equivalently be written with the X.509 SIGNED macro:
注意します。 X.509 SIGNEDマクロで同等にCertificationRequestのための構文を書くことができました:
CertificationRequest ::= SIGNED CertificateRequestInfo
CertificationRequest:、:= CertificateRequestInfoであると署名されます。
Security Considerations
セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Revision history
改訂履歴
Version 1.0
バージョン1.0
Version 1.0 is the initial version.
バージョン1.0は初期のバージョンです。
Acknowledgements
承認
This document is based on a contribution of RSA Laboratories, a division of RSA Data Security, Inc. Any substantial use of the text from this document must acknowledge RSA Data Security, Inc. RSA Data Security, Inc. requests that all material mentioning or referencing this document identify this as "RSA Data Security, Inc. PKCS #10".
このドキュメントはRSA研究所の貢献に基づいています、とこのドキュメント必須からのテキストのRSA Data SecurityのInc.のAnyのかなりの使用の分割がこのドキュメントに言及するか、または参照をつけるすべての材料がこれを特定するというRSA Data Security Inc.RSA Data Security Inc.要求を承諾する、「RSA Data Security、Inc.PKCS#10インチ」
Author's Address
作者のアドレス
Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford, MA 01730
バートKaliski RSA研究所東20のクロズビー・Driveベッドフォード、MA 01730
Phone: (617) 687-7000 EMail: burt@rsa.com
以下に電話をしてください。 (617) 687-7000 メールしてください: burt@rsa.com
Kaliski Informational [Page 7] RFC 2314 PKCS #10: Certification Request Syntax March 1998
Kaliskiの情報[7ページ]のRFC2314PKCS#10: 証明要求構文行進1998
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Kaliski Informational [Page 8]
Kaliski情報です。[8ページ]
一覧
スポンサーリンク
