RFC2986 日本語訳

Network Working Group                                         M. Nystrom
Request for Comments: 2986                                    B. Kaliski
Obsoletes: 2314                                             RSA Security
Category: Informational                                    November 2000

コメントを求めるワーキンググループM.ニストロムの要求をネットワークでつないでください: 2986B.Kaliskiは以下を時代遅れにします。 2314年のRSAセキュリティカテゴリ: 情報の2000年11月

          PKCS #10: Certification Request Syntax Specification
                              Version 1.7

PKCS#10: 証明要求構文仕様バージョン1.7

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 (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This memo represents a republication of PKCS #10 v1.7 from RSA
   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
   change control is retained within the PKCS process.  The body of this
   document, except for the security considerations section, is taken
   directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.

このメモはRSA研究所の公開鍵暗号化標準(PKCS)シリーズからPKCS#10v1.7の再刊を表します、そして、変化コントロールはPKCSプロセスの中で保有されます。 セキュリティ問題部を除いて、このドキュメントのボディーは直接PKCS#9v2.0かPKCS#10v1.7ドキュメントから抜粋されます。

   This memo describes a syntax for certification requests.

このメモは証明要求のための構文について説明します。

Table of Contents

目次

   1.  Introduction ................................................. 2
   2.  Definitions and notation ..................................... 2
   2.1  Definitions ................................................. 2
   2.2  Notation .................................................... 4
   3.  Overview ..................................................... 4
   4.  Certification request syntax ................................. 5
   4.1  CertificationRequestInfo .................................... 5
   4.2  CertificationRequest ........................................ 7
   5.  Security Considerations ...................................... 8
   6.  Authors' Addresses ........................................... 8
   A.  ASN.1 module ................................................. 9
   B.  Intellectual property considerations ........................ 10
   C.  Revision history ............................................ 10
   D.  References .................................................. 11
   E.  Contact information & About PKCS ............................ 12
   Full Copyright Statement ........................................ 14

1. 序論… 2 2. 定義と記法… 2 2.1の定義… 2 2.2記法… 4 3. 概要… 4 4. 証明要求構文… 5 4.1CertificationRequestInfo… 5 4.2CertificationRequest… 7 5. セキュリティ問題… 8 6. 作者のアドレス… 8 A. ASN.1モジュール… 9 B.知的所有権問題… 10 C.改訂履歴… 10 D.参照… 11 E.問い合わせ先とAbout PKCS… 12 完全な著作権宣言文… 14

Nystrom & Kaliski            Informational                      [Page 1]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[1ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

1. Introduction

1. 序論

   This document describes syntax for certification requests.  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, which transforms the request into an X.509
   [9] public-key certificate.  (In what form the certification
   authority returns the newly signed certificate is outside the scope
   of this document.  A PKCS #7 [2] message is one possibility.)

このドキュメントは証明要求のための構文について説明します。 証明要求は分類名から成ります、公開鍵、そして、任意に、aが証明を要求する実体によってまとめて署名される属性をセットしました。 証明要求を証明権威に送ります。(それは、要求をX.509[9]公開鍵証明書に変えます)。 (このドキュメントの範囲の外に証明権威がどんなフォームで新たに署名している証明書を返すかがあります。 PKCS#7[2]メッセージは1つの可能性です。)

   The intention of including a set of attributes is twofold: to provide
   other information about a given entity , or a "challenge password" by
   which the entity may later request certificate revocation; and to
   provide attributes for inclusion in X.509 certificates.  A non-
   exhaustive list of attributes is given in PKCS #9 [3].

1セットの属性を含んでいるという意志は二つです: 与えられた実体、または実体が後で証明書取消しを要求するかもしれない「挑戦パスワード」に関して他の情報を提供するために。 そして、提供するのは包含のためにX.509で証明書を結果と考えます。 PKCS#9[3]で属性に関する非完全なりストを与えます。

   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 certification authorities.

証明当局は、また、要求の非電子申込書を必要として、非電子の回答を返すかもしれません。 このドキュメントの範囲の外にあるそのような形式の記述が証明当局から利用可能になると予想されます。

   The preliminary intended application of this document is to support
   PKCS #7 cryptographic messages, but it is expected that other
   applications will be developed (see e.g. [4]).

このドキュメントの予備の意図しているアプリケーションはPKCS#が7つの暗号のメッセージであるとサポートすることですが、他のアプリケーションが開発されると予想されます。(例えば、[4])を見てください。

2. Definitions and notation

2. 定義と記法

 2.1 Definitions

2.1 定義

   For the purposes of this document, the following definitions apply.

このドキュメントの目的のために、以下の定義は申し込まれます。

   ALGORITHM       An information object class defined in X.509 to
                   describe objects composed of an algorithm (a unique
                   object identifier) and its parameters (any ASN.1
                   type).  The values of objects in this class can be
                   represented by the ASN.1 type AlgorithmIdentifier{}.
                   ALGORITHM is defined as the "useful" information
                   object class TYPE-IDENTIFIER, specified in [11],
                   Annex A.

オブジェクトについて説明するためにX.509で定義されたALGORITHM An情報オブジェクトのクラスはアルゴリズム(ユニークなオブジェクト識別子)とそのパラメタで構成されました(どんなASN.1もタイプします)。 ASN.1タイプAlgorithmIdentifierはこのクラスにおける、オブジェクトの値を表すことができます。 Annex A、ALGORITHMは[11]で指定された「役に立つ」情報オブジェクトのクラスTYPE-IDENTIFIERと定義されます。

   AlgorithmIdentifier{}
                   A useful parameterized version of X.509 type
                   AlgorithmIdentifier is defined in this document.
                   This type tightly binds pairs of algorithm object
                   identifiers to their associated parameter types.
                   When referenced, the single parameter of
                   AlgorithmIdentifier{} specifies a constraint on the

AlgorithmIdentifier、X.509タイプAlgorithmIdentifierの役に立つparameterizedバージョンは本書では定義されます。 このタイプはしっかり組のアルゴリズムオブジェクト識別子を彼らの関連パラメータの型に縛ります。 参照をつけられる、AlgorithmIdentifierのただ一つのパラメタ、規制を指定します。

Nystrom & Kaliski            Informational                      [Page 2]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[2ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

                   pairs of values that may appear in that instance of
                   the type.  The encoded values of
                   AlgorithmIdentifier{} are equivalent to those of type
                   AlgorithmIdentifier.

タイプのそのインスタンスに現れるかもしれない組の値。 AlgorithmIdentifierのコード化された値、タイプAlgorithmIdentifierのものと同等物はそうです。

   ASN.1           Abstract Syntax Notation One, as defined in the ASN.1
                   standards ([10], [11], [12], and [13]).

ASN.1規格([10]、[11]、[12]、および[13])で定義されるようなASN.1の抽象的なSyntax Notation One。

   ATTRIBUTE       This class describes objects composed of an attribute
                   (a unique object identifier) and an associated set of
                   attribute values (any ASN.1 type).  The values of
                   objects in this class can be represented by type
                   Attribute{}.

ATTRIBUTE Thisのクラスは属性(ユニークなオブジェクト識別子)と関連属性値から構成されたオブジェクトについて説明します(どんなASN.1もタイプします)。 タイプAttributeはこのクラスにおける、オブジェクトの値を表すことができます。

   Attribute{}     A useful parameterized version of X.501 [8] type
                   Attribute is defined in this document.  This type
                   tightly binds pairs of attribute type object
                   identifiers to one or more attribute values types.
                   In the ASN.1 open type notation, an attribute type is
                   defined as ATTRIBUTE.&id and an attribute value as
                   ATTRIBUTE.&Type.  When referenced, the single
                   parameter of Attribute{} specifies a constraint on
                   the pairs of values that may appear in an instance of
                   the type.  The encoded values of Attribute{} are
                   equivalent to those of type Attribute.

属性、X.501[8]タイプAttributeの役に立つparameterizedバージョンは本書では定義されます。 このタイプはしっかり組の属性タイプオブジェクト識別子を1つ以上の属性値タイプまで縛ります。 ASN.1開放型記法では、属性タイプはATTRIBUTE TypeとしてATTRIBUTEイドと属性値と定義されます。 参照をつけられる、Attributeのただ一つのパラメタ、タイプのインスタンスに現れるかもしれない値の組で規制を指定します。 Attributeのコード化された値、タイプAttributeのものと同等物はそうです。

   BER             Basic Encoding Rules for ASN.1, as defined in X.690
                   ([14]).

ASN.1のためのX.690([14])で定義されるようなBER Basic Encoding Rules。

   Certificate     A type that binds a subject 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, a validity
                   period, and an optional set of certificate
                   extensions.

デジタル署名で対象の実体の分類名を公開鍵に縛るAタイプを証明してください。 このタイプはX.509で定義されます。 また、このタイプは証明書発行人(署名者)の分類名を含んでいます、発行人特有の通し番号、発行人の署名アルゴリズム識別子、有効期間、および任意の証明書拡張子。

   DER             Distinguished Encoding Rules for ASN.1, as defined in
                   X.690.  DER is a subset of BER.

ASN.1のためのX.690で定義されるようなDER Distinguished Encoding Rules。 DERはBERの部分集合です。

   Name            A type that uniquely identifies or "distinguishes"
                   objects in an X.500 [7] directory.  This type is
                   defined in X.501.  In an X.509 certificate, the type
                   identifies the certificate issuer and the certificate
                   subject, the entity whose public key is certified.

X.500[7]ディレクトリで唯一オブジェクトを特定するか、または「区別する」タイプとAを命名してください。 このタイプはX.501で定義されます。 X.509証明書では、タイプは証明書発行人と証明書対象(公開鍵が公認される実体)を特定します。

Nystrom & Kaliski            Informational                      [Page 3]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[3ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

  2.2 Notation

2.2 記法

   No special notation is used in this document.

どんな特別な記法も本書では使用されません。

3. Overview

3. 概要

   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つの部品から成ります: 「証明要求情報」、署名アルゴリズム識別子、および証明要求情報におけるデジタル署名。 証明要求情報は実体の他の情報を提供する属性の実体の分類名、実体の公開鍵、およびセットから成ります。

   The process by which a certification request is constructed involves
   the following steps:

証明要求が構成されるプロセスは以下のステップにかかわります:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

1. 対象の分類名、対象の公開鍵を含むCertificationRequestInfo値、任意に、1セットの属性は証明を要求する実体によって構成されます。

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

2. CertificationRequestInfo値は対象の実体の秘密鍵を契約されます。 (セクション4.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 authenticating the
   requesting entity and verifying the entity's signature, and, if the
   request is valid, constructing an X.509 certificate from the
   distinguished name and public key, the issuer name, and the
   certification authority's choice of serial number, validity period,
   and signature algorithm.  If the certification request contains any
   PKCS #9 attributes, the certification authority may also use the
   values in these attributes as well as other information known to the
   certification authority to construct X.509 certificate extensions.

証明権威は、要求実体を認証して、分類名と公開鍵からのX.509証明書、発行人名、および通し番号の証明権威の選択を構成して、要求が有効であり実体の署名、有効期間、および署名アルゴリズムを確かめることによって、要求を実現させます。 また、証明要求が何かPKCS#9つの属性を含んでいるなら、証明権威はX.509証明書拡張子を構成する証明権威に知られている他の情報と同様にこれらの属性に値を使用するかもしれません。

   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)を含むかもしれません。 別の可能性は証明権威が新しい証明書を主要なデータベースに挿入するということです。

Nystrom & Kaliski            Informational                      [Page 4]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[4ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   Note 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--公開鍵/秘密鍵組を生成した後に証明要求を通常送るでしょうが、また、実体の分類名における変化の後にそう存在するかもしれません。

   Note 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--証明要求の署名は、実体が別のパーティーの公開鍵で証明書を要求するのを防ぎます。 そのような攻撃は相手によって署名されたどんなメッセージの創始者であるもふりをする小さい方の能力を実体に与えるでしょう。 実体が、署名されるメッセージとメッセージの署名している部分が署名者を特定しないのを知らない場合にだけ、この攻撃は重要です。 実体がまだ相手のために意図するメッセージを解読することができないだろう、もちろん。

   Note 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--このドキュメントの範囲の外に実体がどう証明要求を証明権威に送るかがあります。 紙と電子申込書の両方が可能です。

   Note 4 - This document is not compatible with the certification
   request syntax for Privacy-Enhanced Mail, as described in RFC 1424
   [5].  The syntax here 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.  This document is designed to minimize request size, an
   important feature for certification authorities accepting requests on
   paper.

注意4--Privacyによって高められたメールにおいて、このドキュメントは証明要求構文と互換性がありません、RFC1424[5]で説明されるように。 ここの構文は3つの点において異なります: それは1セットの属性を許容します。 それは発行人名、通し番号、または有効期間を含んでいません。 そして、それは署名するべき「無毒」のメッセージを必要としません。 証明当局受諾のための重要な特徴は、このドキュメントが要求サイズを最小にするように設計されているよう紙上で要求します。

4. Certification request syntax

4. 証明要求構文

   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について説明します。

 4.1 CertificationRequestInfo

4.1 CertificationRequestInfo

   Certification request information shall have ASN.1 type
   CertificationRequestInfo:

証明要求情報で、ASN.1はCertificationRequestInfoをタイプするものとします:

   CertificationRequestInfo ::= SEQUENCE {
        version       INTEGER { v1(0) } (v1,...),
        subject       Name,
        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
        attributes    [0] Attributes{{ CRIAttributes }}
   }

CertificationRequestInfo:、:= 系列バージョンINTEGER v1(0)(v1、…)、対象のName、subjectPKInfo SubjectPublicKeyInfo PKInfoAlgorithms 、属性[0]属性 CRIAttributes

   SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
        algorithm        AlgorithmIdentifier {{IOSet}},
        subjectPublicKey BIT STRING
   }

SubjectPublicKeyInfo、アルゴリズム: IOSet:、:= 系列アルゴリズムAlgorithmIdentifierIOSet、subjectPublicKey BIT STRING

Nystrom & Kaliski            Informational                      [Page 5]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[5ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   PKInfoAlgorithms ALGORITHM ::= {
        ...  -- add any locally defined algorithms here -- }

PKInfoAlgorithmsアルゴリズム:、:= …--ここであらゆる局所的に定義されたアルゴリズムを加えてください--

   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}

属性: 属性IOSet:、:= 属性のセット IOSet

   CRIAttributes  ATTRIBUTE  ::= {
        ... -- add any locally defined attributes here -- }

CRIAttributesは以下を結果と考えます:= …--ここであらゆる局所的に定義された属性を加えてください--

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
   }

属性: IOSetを結果と考えてください:、:= 系列値のSET SIZE(1..MAX)OF ATTRIBUTE ATTRIBUTEイド(IOSet)、Typeをタイプしてください、(IOSet、@type)

   The components of type CertificationRequestInfo have the following
   meanings:

タイプCertificationRequestInfoの部品には、以下の意味があります:

        version is the version number, for compatibility with future
          revisions of this document.  It shall be 0 for this version of
          the standard.

バージョンはこのドキュメントの今後の改正との互換性のバージョン番号です。 それは規格のこのバージョンのために0になるでしょう。

        subject is the distinguished name of the certificate subject
          (the entity whose public key is to be certified).

対象は証明書対象(公認される公開鍵がことである実体)の分類名です。

        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 the rsaEncryption object
          identifier from PKCS #1 [1].  The information also includes a
          bit-string representation of the entity's public key.  For the
          public-key algorithm just mentioned, the bit string contains
          the DER encoding of a value of PKCS #1 type RSAPublicKey.  The
          values of type SubjectPublicKeyInfo{} allowed for
          subjectPKInfo are constrained to the values specified by the
          information object set PKInfoAlgorithms, which includes the
          extension marker (...).  Definitions of specific algorithm
          objects are left to specifications that reference this
          document.  Such specifications will be interoperable with
          their future versions if any additional algorithm objects are
          added after the extension marker.

公認されていて、subjectPublicKeyInfoは公開鍵の情報を含んでいます。 情報は実体の公開鍵アルゴリズム(そして、どんな関連パラメタも)を特定します。 公開鍵アルゴリズムに関する例はPKCS#1[1]からのrsaEncryptionオブジェクト識別子を含んでいます。 また、情報は実体の公開鍵のしばらくストリング表現を含んでいます。 ただ言及された公開鍵アルゴリズムのために、ビット列はPKCS#1タイプRSAPublicKeyの価値のDERコード化を含んでいます。 タイプSubjectPublicKeyInfoの値、考慮されて、subjectPKInfoは情報オブジェクトセットPKInfoAlgorithmsによって指定された値に抑制されます。PKInfoAlgorithmsは拡大マーカー(…)を含んでいます。 特定のアルゴリズムオブジェクトの定義は仕様へのこれが記録するその参照に残されます。 何か追加アルゴリズムオブジェクトが拡大マーカーの後に加えられると、そのような仕様はそれらの将来のバージョンで共同利用できるでしょう。

        attributes is a collection 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
          certificate revocation.  Another example is information to
          appear in X.509 certificate extensions (e.g. the
          extensionRequest attribute from PKCS #9).  The values of type

属性は証明書に関する追加情報を提供する属性の収集です。 ここで役に立つかもしれない属性タイプの中にはPKCS#9で定義される人もいます。 例は挑戦パスワード属性です。(その属性は実体が証明書取消しを要求するかもしれないパスワードを指定します)。 別の例はX.509証明書拡張子(例えば、PKCS#9からのextensionRequest属性)で見える情報です。 タイプの値

Nystrom & Kaliski            Informational                      [Page 6]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[6ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

          Attributes{} allowed for attributes are constrained to the
          values specified by the information object set CRIAttributes.
          Definitions of specific attribute objects are left to
          specifications that reference this document.  Such
          specifications will be interoperable with their future
          versions if any additional attribute objects are added after
          the extension marker.

属性、考慮されて、属性は情報オブジェクトセットCRIAttributesによって指定された値に抑制されます。 特定の属性オブジェクトの定義は仕様へのこれが記録するその参照に残されます。 何か追加属性オブジェクトが拡大マーカーの後に加えられると、そのような仕様はそれらの将来のバージョンで共同利用できるでしょう。

 4.2 CertificationRequest

4.2 CertificationRequest

   A certification request shall have ASN.1 type CertificationRequest:

証明要求で、ASN.1はCertificationRequestをタイプするものとします:

   CertificationRequest ::= SEQUENCE {
        certificationRequestInfo CertificationRequestInfo,
        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
        signature          BIT STRING
   }

CertificationRequest:、:= 系列certificationRequestInfo CertificationRequestInfo、signatureAlgorithm AlgorithmIdentifier SignatureAlgorithms 、署名BIT STRING

   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
        algorithm          ALGORITHM.&id({IOSet}),
        parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
   }

AlgorithmIdentifier、アルゴリズム: IOSet:、:= 系列パラメタALGORITHMアルゴリズムALGORITHMイド(IOSet)、Type、(IOSet、@algorithm) OPTIONAL

   SignatureAlgorithms ALGORITHM ::= {
        ... -- add any locally defined algorithms here -- }

SignatureAlgorithmsアルゴリズム:、:= …--ここであらゆる局所的に定義されたアルゴリズムを加えてください--

   The components of type CertificationRequest have the following
   meanings:

タイプCertificationRequestの部品には、以下の意味があります:

        certificateRequestInfo is the "certification request
          information." It is the value being signed.

certificateRequestInfoは「証明要求情報」です。 それは署名される値です。

        signatureAlgorithm identifies the signature algorithm (and any
          associated parameters) under which the certification-request
          information is signed.  For example, a specification might
          include an ALGORITHM object for PKCS #1's
          md5WithRSAEncryption in the information object set
          SignatureAlgorithms:

signatureAlgorithmは証明要求情報に署名する署名アルゴリズム(そして、どんな関連パラメタも)を特定します。 例えば、仕様は情報オブジェクトセットSignatureAlgorithmsにPKCS#1md5WithRSAEncryptionのためのALGORITHMオブジェクトを含むかもしれません:

          SignatureAlgorithms ALGORITHM ::= {
               ...,
               { NULL IDENTIFIED BY md5WithRSAEncryption }
          }

SignatureAlgorithmsアルゴリズム:、:= …、md5WithRSAEncryptionによって特定されたヌル

        signature is the result of signing the certification request
          information with the certification request subject's private
          key.

署名は証明要求対象の秘密鍵で証明要求が情報であると署名するという結果です。

Nystrom & Kaliski            Informational                      [Page 7]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[7ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   The signature process consists of two steps:

署名プロセスは以下の2ステップから成ります:

        1. The value of the certificationRequestInfo component 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 - An equivalent syntax for CertificationRequest could be
   written:

注意--CertificationRequestに、同等な構文を書くことができました:

   CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo }
        (CONSTRAINED BY { -- Verify or sign encoded
         -- CertificationRequestInfo -- })

CertificationRequest:、:= EncodedCertificationRequestInfoであると署名されます。(CONSTRAINED BY、--、コード化されて(CertificationRequestInfo)、確かめるか、または署名する、)

   EncodedCertificationRequestInfo ::=
        TYPE-IDENTIFIER.&Type(CertificationRequestInfo)

EncodedCertificationRequestInfo:、:= タイプ識別子タイプしてください。(CertificationRequestInfo)

   SIGNED { ToBeSigned } ::= SEQUENCE {
        toBeSigned ToBeSigned,
        algorithm  AlgorithmIdentifier { {SignatureAlgorithms} },
        signature  BIT STRING
   }

署名しているToBeSigned:、:= 系列toBeSigned ToBeSigned、アルゴリズムAlgorithmIdentifier SignatureAlgorithms、署名BIT STRING

5. Security Considerations

5. セキュリティ問題

   Security issues are discussed throughout this memo.

このメモ中で安全保障問題について議論します。

6. Authors' Addresses

6. 作者のアドレス

   Magnus Nystrom
   RSA Security
   Box 10704
   S-121 29 Stockholm
   Sweden

マグヌス・ニストロム・RSAセキュリティ箱10704秒間-121 29のストックホルムスウェーデン

   EMail: magnus@rsasecurity.com

メール: magnus@rsasecurity.com

   Burt Kaliski
   RSA Security
   20 Crosby Drive
   Bedford, MA 01730 USA

バートKaliski RSA Security20クロズビー・Drive MA01730ベッドフォード(米国)

   EMail: bkaliski@rsasecurity.com

メール: bkaliski@rsasecurity.com

Nystrom & Kaliski            Informational                      [Page 8]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[8ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

APPENDICES

付録

A. ASN.1 Module

A。 ASN.1モジュール

   This appendix includes all of the ASN.1 type and value definitions
   contained in this document in the form of the ASN.1 module PKCS-10.

この付録は定義が本書ではASN.1モジュールPKCS-10の形に含んだASN.1タイプと価値のすべてを含んでいます。

   PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   pkcs-10(10) modules(1) pkcs-10(1)}

PKCS-10iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-10(10)モジュール(1)pkcs-10(1)

   DEFINITIONS IMPLICIT TAGS ::=

定義、内在しているタグ:、:=

   BEGIN

始まってください。

   -- EXPORTS All --

-- すべてをエクスポートします--

   -- All types and values defined in this module are exported for use
   -- in other ASN.1 modules.

-- このモジュールで定義されたすべてのタイプと値は他のASN.1モジュールにおける使用のためにエクスポートされます。

   IMPORTS

輸入

   informationFramework, authenticationFramework
        FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
        usefulDefinitions(0) 3}

UsefulDefinitionsからのinformationFramework、authenticationFramework共同iso-ituのt(2)ds(5)のモジュール(1)usefulDefinitions(0)3

   ATTRIBUTE, Name
        FROM InformationFramework informationFramework

InformationFramework informationFrameworkからの属性、名前

   ALGORITHM
        FROM AuthenticationFramework authenticationFramework;

AuthenticationFramework authenticationFrameworkからのアルゴリズム。

   -- Certificate requests
   CertificationRequestInfo ::= SEQUENCE {
        version       INTEGER { v1(0) } (v1,...),
        subject       Name,
        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
        attributes    [0] Attributes{{ CRIAttributes }}
   }

-- 証明書要求CertificationRequestInfo:、:= 系列バージョンINTEGER v1(0)(v1、…)、対象のName、subjectPKInfo SubjectPublicKeyInfo PKInfoAlgorithms 、属性[0]属性 CRIAttributes

   SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE {
        algorithm        AlgorithmIdentifier {{IOSet}},
        subjectPublicKey BIT STRING
   }

SubjectPublicKeyInfo、アルゴリズム: IOSet:、:= 系列アルゴリズムAlgorithmIdentifierIOSet、subjectPublicKey BIT STRING

   PKInfoAlgorithms ALGORITHM ::= {
        ...  -- add any locally defined algorithms here -- }

PKInfoAlgorithmsアルゴリズム:、:= …--ここであらゆる局所的に定義されたアルゴリズムを加えてください--

   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}

属性: 属性IOSet:、:= 属性のセット IOSet

Nystrom & Kaliski            Informational                      [Page 9]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[9ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   CRIAttributes  ATTRIBUTE  ::= {
        ... -- add any locally defined attributes here -- }

CRIAttributesは以下を結果と考えます:= …--ここであらゆる局所的に定義された属性を加えてください--

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
   }

属性: IOSetを結果と考えてください:、:= 系列値のSET SIZE(1..MAX)OF ATTRIBUTE ATTRIBUTEイド(IOSet)、Typeをタイプしてください、(IOSet、@type)

   CertificationRequest ::= SEQUENCE {
        certificationRequestInfo CertificationRequestInfo,
        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
        signature          BIT STRING
   }

CertificationRequest:、:= 系列certificationRequestInfo CertificationRequestInfo、signatureAlgorithm AlgorithmIdentifier SignatureAlgorithms 、署名BIT STRING

   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
        algorithm  ALGORITHM.&id({IOSet}),
        parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
   }

AlgorithmIdentifier、アルゴリズム: IOSet:、:= 系列パラメタALGORITHMアルゴリズムALGORITHMイド(IOSet)、Type、(IOSet、@algorithm) OPTIONAL

   SignatureAlgorithms ALGORITHM ::= {
        ... -- add any locally defined algorithms here -- }

SignatureAlgorithmsアルゴリズム:、:= …--ここであらゆる局所的に定義されたアルゴリズムを加えてください--

   END

終わり

B. Intellectual property considerations

B。 知的所有権問題

   RSA Security makes no patent claims on the general constructions
   described in this document, although specific underlying techniques
   may be covered.

RSA Securityは一般的な構造の特許請求の範囲について全く本書では説明させません、特定の基本的なテクニックがカバーされているかもしれませんが。

   License to copy this document is granted provided that it is
   identified as "RSA Security Inc.  Public-Key Cryptography Standards
   (PKCS)" in all material mentioning or referencing this document.

「RSAセキュリティ株式会社公開鍵暗号化標準(PKCS)」としてそれを特定すれば、このドキュメントに言及するか、または参照をつけながら、すべての材料の中でこのドキュメントをコピーするライセンスを与えます。

   RSA Security makes no representations regarding intellectual property
   claims by other parties.  Such determination is the responsibility of
   the user.

RSA Securityは相手による知的所有権クレームに関する表現を全くしません。 そのような決断はユーザの責任です。

C. Revision history

C。 改訂履歴

   Version 1.0

バージョン1.0

         Version 1.0 was the previous version of this document (also
         published as "version 1.5" in [6]).

バージョン1.0はこのドキュメントの旧バージョンでした。(また、「[6])のバージョン1.5インチ」として、発行されています。

Nystrom & Kaliski            Informational                     [Page 10]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[10ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   Version 1.7

バージョン1.7

         This version incorporates several editorial changes, including
         updates to the references, and changes to ASN.1 type
         definitions.  The following substantive changes have been made:

このバージョンは参照へのアップデート、およびASN.1型定義への変化を含む数回の編集の変化を取り入れます。 以下の実質的な変更は行われました:

         - This version refers to X.680-X.690, the current international
           standards for ASN.1 and its encoding rules.  All references
           to X.208 and X.209 have been eliminated.

- このバージョンはX.680-X.690、ASN.1のための現在の世界規格、およびその符号化規則を示します。 X.208とX.209のすべての参照が排除されました。

         - The X.690 standard requires that the encoded values of SET OF
           components be sorted in ascending order under DER.
           Regardless of this, applications should not rely on the
           ordering of attribute components.

- X.690規格は、SET OFの部品のコード化された値が昇順にDERの下で分類されるのを必要とします。 これにかかわらず、アプリケーションは属性コンポーネントの注文を当てにするべきではありません。

         - All references to PKCS #6 Extended-Certificate Syntax
           Standard have been removed.  With the addition of extensions
           to X.509 version 3 certificates, RSA Laboratories is
           withdrawing support for PKCS #6.

- PKCS#6Extended-証明書Syntax Standardのすべての参照を取り除いてあります。 X.509バージョン3証明書、RSA研究所への拡大の追加と共に、PKCS#6のサポートを引き下がらせるのがあります。

   Note - The reason for using version 1.7 for this document is to avoid
   confusion with [6], which is named version 1.5, and an unsupported
   PKCS #10 version named Version 1.6.

注意--このドキュメントのためのバージョン1.7を使用する理由はバージョン1.6と命名されるバージョン1.5と命名される[6]とサポートされないPKCS#10バージョンへの混乱を避けることです。

D. References

D。 参照

   [1]  RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0,
        October 1998.

[1] RSA研究所。 PKCS#1: RSA暗号化規格。 1998年10月のバージョン2.0。

   [2]  RSA Laboratories. PKCS #7: Cryptographic Message Syntax
        Standard.  Version 1.5, November 1993.

[2] RSA研究所。 PKCS#7: 暗号のメッセージ構文規格。 1993年11月のバージョン1.5。

   [3]  RSA Laboratories. PKCS #9: Selected Attribute Types. Version
        2.0, February 2000.

[3] RSA研究所。 PKCS#9: 属性タイプを選びました。 2000年2月のバージョン2.0。

   [4]  Adams, C. and S. Farrell, "Internet X.509 Public Key
        Infrastructure - Certificate Management Protocols", RFC 2510,
        March 1999.

[4] アダムスとC.とS.ファレル、「インターネットX.509公開鍵基盤--管理プロトコルを証明する」RFC2510、1999年3月。

   [5]  Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
        Part IV: Key Certification and Related Services", RFC 1424,
        February 1993.

[5]Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、1993年2月。

   [6]  Kaliski, B., "PKCS #10: Certification Request Syntax Version
        1.5", RFC 2314, March 1998.

[6]Kaliski、B.、「PKCS#10:」 証明は1998年3月に構文バージョン1.5インチ、RFC2314を要求します。

Nystrom & Kaliski            Informational                     [Page 11]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[11ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   [7]  ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1998,
        Information technology - Open Systems Interconnection - The
        Directory: Overview of concepts, models and services.

[7] ITU-T推薦X.500(1997)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-1:1998、ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要。

   [8]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995,
        Information technology - Open Systems Interconnection - The
        Directory: Models.

[8] ITU-T推薦X.501(1993)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-2:1995、ディレクトリ: モデル。

   [9]  ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
        Information technology - Open Systems Interconnection -The
        Directory:  Authentication framework.

[9] ITU-T推薦X.509(1997)| ISO/IEC9594-8: 1998、情報技術--オープン・システム・インターコネクション、-、ディレクトリ: 認証フレームワーク。

   [10] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Specification of Basic Notation.

[10] ITU-T推薦X.680(1997)| ISO/IEC8824-1: 1998、情報技術--抽象構文記法1(ASN.1): 基本的な記法の仕様。

   [11] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Information Object Specification.

[11] ITU-T推薦X.681(1997)| ISO/IEC8824-2: 1998、情報技術--抽象構文記法1(ASN.1): 情報オブジェクト仕様。

   [12] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Constraint Specification.

[12] ITU-T推薦X.682(1997)| ISO/IEC8824-3: 1998、情報技術--抽象構文記法1(ASN.1): 規制仕様。

   [13] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Parameterization of ASN.1 Specifications.

[13] ITU-T推薦X.683(1997)| ISO/IEC8824-4: 1998、情報技術--抽象構文記法1(ASN.1): ASN.1仕様のパラメタリゼーション。

   [14] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
        Information Technology - ASN.1 Encoding Rules: Specification of
        Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
        Distinguished Encoding Rules (DER).

[14] ITU-T推薦X.690(1997)| ISO/IEC8825-1: 1998、情報技術--ASN.1符号化規則: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。

E. Contact Information & About PKCS

E。 問い合わせ先とPKCS

   The Public-Key Cryptography Standards are specifications produced by
   RSA Laboratories in cooperation with secure systems developers
   worldwide for the purpose of accelerating the deployment of public-
   key cryptography.  First published in 1991 as a result of meetings
   with a small group of early adopters of public-key technology, the
   PKCS documents have become widely referenced and implemented.
   Contributions from the PKCS series have become part of many formal
   and de facto standards, including ANSI X9 documents, PKIX, SET,
   S/MIME, and SSL.

公開鍵暗号化標準は公共の主要な暗号の展開を加速する目的のために世界中の安全なシステム開発者と提携してRSA研究所によって作り出された仕様です。 まず最初に、1991年に公開カギ技術の初期採用者の小さいグループとのミーティングの結果、発行されています、PKCSドキュメントは広く参照をつけられて実行されるようになりました。 PKCSシリーズからの貢献は多くの正式で事実上の規格の一部になりました、ANSI X9ドキュメント、PKIX、SET、S/MIME、およびSSLを含んでいて。

Nystrom & Kaliski            Informational                     [Page 12]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[12ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

   Further development of PKCS occurs through mailing list discussions
   and occasional workshops, and suggestions for improvement are
   welcome.  For more information, contact:

PKCSのさらなる開発はメーリングリスト議論と時々のワークショップで起こります、そして、改善提案を歓迎します。 詳しくは、以下に連絡してください。

        PKCS Editor
        RSA Laboratories
        20 Crosby Drive
        Bedford, MA  01730 USA
        pkcs-editor@rsasecurity.com
        http://www.rsasecurity.com/rsalabs/pkcs

PKCS Editor RSA研究所20のクロズビー・Driveベッドフォード、MA01730米国 pkcs-editor@rsasecurity.com http://www.rsasecurity.com/rsalabs/pkcs

Nystrom & Kaliski            Informational                     [Page 13]

RFC 2986       Certification Request Syntax Specification  November 2000

ニストロムとKaliskiの情報[13ページ]のRFC2986証明は2000年11月に構文仕様を要求します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society 2000. All Rights Reserved.

Copyright(C)インターネット協会2000。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others provided that the above copyright notice and this paragraph
   are included on all such copies.  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 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機能のための基金は現在、インターネット協会によって提供されます。

Nystrom & Kaliski            Informational                     [Page 14]

ニストロムとKaliski情報です。[14ページ]