RFC2510 日本語訳
2510 Internet X.509 Public Key Infrastructure Certificate ManagementProtocols. C. Adams, S. Farrell. March 1999. (Format: TXT=158178 bytes) (Obsoleted by RFC4210) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Adams
Request for Comments: 2510 Entrust Technologies
Category: Standards Track S. Farrell
SSE
March 1999
コメントを求めるワーキンググループC.アダムスの要求をネットワークでつないでください: 2510は技術カテゴリをゆだねます: 1999年の標準化過程S.ファレルSSE行進
Internet X.509 Public Key Infrastructure
Certificate Management Protocols
インターネットX.509公開鍵暗号基盤証明書管理プロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that "certificate" in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM].
このドキュメントはインターネットX.509公開鍵暗号基盤(PKI)証明書Managementプロトコルについて説明します。 プロトコルメッセージは証明書作成と管理のすべての関連局面と定義されます。 X.509v3 Certificateが定義されるとしてその「証明書」によって本書では参照されることに注意してください[COR95、X509-AM]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
Introduction
序論
The layout of this document is as follows:
このドキュメントのレイアウトは以下の通りです:
- Section 1 contains an overview of PKI management;
- Section 2 contains discussion of assumptions and restrictions;
- Section 3 contains data structures used for PKI management messages;
- Section 4 defines the functions that are to be carried out in PKI
management by conforming implementations;
- Section 5 describes a simple protocol for transporting PKI messages;
- the Appendices specify profiles for conforming implementations and
provide an ASN.1 module containing the syntax for all messages
defined in this specification.
- セクション1はPKI管理の概要を含みます。 - セクション2は仮定と制限の議論を含みます。 - セクション3はPKI管理メッセージに使用されるデータ構造を含みます。 - セクション4はPKI管理で実装を従わせることによって行われることになっている機能を定義します。 - セクション5はPKIメッセージを輸送するために簡単なプロトコルについて説明します。 - Appendicesはこの仕様に基づき定義されたすべてのメッセージに、実装を従わせるためのプロフィールを指定して、構文を含むASN.1モジュールを提供します。
Adams & Farrell Standards Track [Page 1] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[1ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
1 PKI Management Overview
1 PKIマネジメントの展望
The PKI must be structured to be consistent with the types of individuals who must administer it. Providing such administrators with unbounded choices not only complicates the software required but also increases the chances that a subtle mistake by an administrator or software developer will result in broader compromise. Similarly, restricting administrators with cumbersome mechanisms will cause them not to use the PKI.
それを管理しなければならない個人のタイプと一致しているようにPKIを構造化しなければなりません。 限りない選択をそのような管理者に提供すると、管理者かソフトウェア開発者による微妙な誤りが、より広い感染をもたらすという可能性は必要であるソフトウェアを複雑にするだけではなく、増強もされます。 同様に、扱いにくいメカニズムで管理者を制限するのに、それらはPKIを使用しないでしょう。
Management protocols are REQUIRED to support on-line interactions between Public Key Infrastructure (PKI) components. For example, a management protocol might be used between a Certification Authority (CA) and a client system with which a key pair is associated, or between two CAs that issue cross-certificates for each other.
管理プロトコルは公開鍵暗号基盤(PKI)コンポーネントの間のオンライン相互作用をサポートするREQUIREDです。 例えば、管理プロトコルは認証局(カリフォルニア)と主要な組が関連しているクライアントシステムの間、または、互いのために交差している証明書を発行する2CAsの間で使用されるかもしれません。
1.1 PKI Management Model
1.1 PKIマネジメント・モデル
Before specifying particular message formats and procedures we first define the entities involved in PKI management and their interactions (in terms of the PKI management functions required). We then group these functions in order to accommodate different identifiable types of end entities.
特定のメッセージ・フォーマットと手順を指定する前に、私たちは最初に、PKI管理にかかわる実体とそれらの相互作用(管理機能が必要としたPKIに関する)を定義します。 そして、私たちは、異なった身元保証可能なタイプの終わりの実体を収容するためにこれらの機能を分類します。
1.2 Definitions of PKI Entities
1.2 PKI実体の定義
The entities involved in PKI management include the end entity (i.e., the entity to be named in the subject field of a certificate) and the certification authority (i.e., the entity named in the issuer field of a certificate). A registration authority MAY also be involved in PKI management.
PKI管理にかかわる実体は終わりの実体(すなわち、証明書の対象の分野で命名される実体)と証明権威(すなわち、証明書の発行人分野で指定された実体)を含んでいます。 また、登録局はPKI管理にかかわるかもしれません。
1.2.1 Subjects and End Entities
1.2.1 対象と終わりの実体
The term "subject" is used here to refer to the entity named in the subject field of a certificate; when we wish to distinguish the tools and/or software used by the subject (e.g., a local certificate management module) we will use the term "subject equipment". In general, the term "end entity" (EE) rather than subject is preferred in order to avoid confusion with the field name.
「対象」という用語は証明書の対象の分野で指定された実体について言及するのにここで使用されます。 対象(例えば、ローカルの証明書管理モジュール)によって使用されるツール、そして/または、ソフトウェアを区別したいと思うとき、私たちは「対象の設備」という用語を使用するつもりです。 一般に、対象よりむしろ用語「終わりの実体」(EE)は、フィールド名への混乱を避けるために好まれます。
It is important to note that the end entities here will include not only human users of applications, but also applications themselves (e.g., for IP security). This factor influences the protocols which the PKI management operations use; for example, application software is far more likely to know exactly which certificate extensions are required than are human users. PKI management entities are also end entities in the sense that they are sometimes named in the subject
ここの終わりの実体がアプリケーションの人間のユーザだけではなく、アプリケーション(例えば、IPセキュリティのための)自体も含むことに注意するのは重要です。 この要素はPKI管理操作が使用するプロトコルに影響を及ぼします。 例えば、アプリケーション・ソフトは人間のユーザよりはるかにどの証明書拡張子が必要であるかをまさに知っていそうです。 また、PKI経営体はそれらが対象で時々命名されるという意味で終わりの実体です。
Adams & Farrell Standards Track [Page 2] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[2ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
field of a certificate or cross-certificate. Where appropriate, the term "end-entity" will be used to refer to end entities who are not PKI management entities.
証明書か交差している証明書の分野。 適切であることで、「終わり実体」という用語がPKI経営体ではなく、そうする終わりの実体について言及するのに使用されるところ。
All end entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA which is directly trusted by this entity and that CA's public key (or a fingerprint of the public key where a self-certified version is available elsewhere). Implementations MAY use secure local storage for more than this minimum (e.g., the end entity's own certificate or application-specific information). The form of storage will also vary -- from files to tamper-resistant cryptographic tokens. Such local trusted storage is referred to here as the end entity's Personal Security Environment (PSE).
すべての終わりの実体がそれら自身の最小限、名前、および秘密鍵(この実体とそのCAの公開鍵(または、自己に公認されたバージョンがほかの場所で入手できる公開鍵の指紋)によって直接信じられるカリフォルニアの名前)で何らかの情報への安全な地方のアクセスを必要とします。 実装は以上にこの最小限(例えば、終わりの実体の自身の証明書かアプリケーション特有の情報)より安全な地方のストレージを使用するかもしれません。 また、ストレージのフォームはファイルから暗号の耐タンパー性トークンに異なるでしょう。 そのような地方の信じられたストレージは終わりの実体のパーソナルSecurity Environment(PSE)としてここと呼ばれます。
Though PSE formats are beyond the scope of this document (they are very dependent on equipment, et cetera), a generic interchange format for PSEs is defined here - a certification response message MAY be used.
PSE形式はこのドキュメントの範囲を超えていますが(それらは設備などに非常に依存しています)、PSEsのためのジェネリック置き換え書式はここで定義されます--証明応答メッセージは使用されるかもしれません。
1.2.2 Certification Authority
1.2.2 認証局
The certification authority (CA) may or may not actually be a real "third party" from the end entity's point of view. Quite often, the CA will actually belong to the same organization as the end entities it supports.
証明権威(カリフォルニア)は実際に終わりの実体の観点からの本当の「第三者」であるかもしれません。 かなりしばしば、カリフォルニアは実際にそれがサポートする終わりの実体と同じ組織に属すでしょう。
Again, we use the term CA to refer to the entity named in the issuer field of a certificate; when it is necessary to distinguish the software or hardware tools used by the CA we use the term "CA equipment".
一方、私たちは証明書の発行人分野で指定された実体について言及するのにカリフォルニアという用語を使用します。 カリフォルニアによって使用されたソフトウェアかハードウェアツールを区別するのが必要であるときに、私たちは「カリフォルニア設備」という用語を使用します。
The CA equipment will often include both an "off-line" component and an "on-line" component, with the CA private key only available to the "off-line" component. This is, however, a matter for implementers (though it is also relevant as a policy issue).
カリフォルニア設備はしばしば「オフライン」のコンポーネントと「オンライン」のコンポーネントの両方を含むでしょう、単に「オフライン」のコンポーネントに利用可能なカリフォルニア秘密鍵で。 しかしながら、これはimplementersのための問題(また、それも政策問題として関連していますが)です。
We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly.
私たちは終わりの実体によって直接信じられるカリフォルニアを示すために「カリフォルニアを根づく」という用語を使用します。 あって、しっかりと根のカリフォルニア公開鍵の値を取得するのがバンドの外でいくつかを必要とするのが(s)を踏みます。 今期は、根のカリフォルニアが必ずどんな階層構造の最上部にもあって、単に、問題のカリフォルニアが直接信じられるのを含意することになっていません。
A "subordinate CA" is one that is not a root CA for the end entity in question. Often, a subordinate CA will not be a root CA for any entity but this is not mandatory.
「下位のカリフォルニア」は問題の終わりの実体のための根のカリフォルニアでないものです。 しばしば、下位のカリフォルニアはどんな実体のためにも根のカリフォルニアになるというわけではないでしょうが、これは義務的ではありません。
Adams & Farrell Standards Track [Page 3] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[3ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
1.2.3 Registration Authority
1.2.3 登録局
In addition to end-entities and CAs, many environments call for the existence of a Registration Authority (RA) separate from the Certification Authority. The functions which the registration authority may carry out will vary from case to case but MAY include personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, et cetera.
終わり実体とCAsに加えて、多くの環境が認証局から別々のRegistration Authority(RA)の存在を求めます。 登録局が行うかもしれない機能は、場合によって異なりますが、本人認証を含むかもしれません、トークン分配、取消しが報告して、名前課題、キー生成、主要な組などでは、記録保管所です。
This document views the RA as an OPTIONAL component - when it is not present the CA is assumed to be able to carry out the RA's functions so that the PKI management protocols are the same from the end- entity's point of view.
このドキュメントはOPTIONALの部品であるとRAをみなします--それが存在していないとき、カリフォルニアがRAの機能を行うことができると思われて、PKI管理プロトコルは終わりの実体の観点から同じです。
Again, we distinguish, where necessary, between the RA and the tools used (the "RA equipment").
一方、私たちはRAと使用される道具(「RA設備」)の間で必要であるところで区別します。
Note that an RA is itself an end entity. We further assume that all RAs are in fact certified end entities and that RAs have private keys that are usable for signing. How a particular CA equipment identifies some end entities as RAs is an implementation issue (i.e., this document specifies no special RA certification operation). We do not mandate that the RA is certified by the CA with which it is interacting at the moment (so one RA may work with more than one CA whilst only being certified once).
RAがそれ自体で終わりの実体であることに注意してください。 私たちは事実上、すべてのRAsが終わりの実体であることが公認されて、RAsには署名に、使用可能な秘密鍵があるとさらに思います。 特定のカリフォルニア設備が、いくつかの終わりの実体がRAsであるとどう認識するかは、導入問題(すなわち、このドキュメントはどんな特別なRA証明操作も指定しない)です。 私たちは、RAがそれが現在相互作用しているカリフォルニアによって公認されるのを強制しません(1RAが一度公認されているだけである間、1以上カリフォルニアと共に働くことができるように)。
In some circumstances end entities will communicate directly with a CA even where an RA is present. For example, for initial registration and/or certification the subject may use its RA, but communicate directly with the CA in order to refresh its certificate.
いくつかの事情では、終わりの実体は、RAがどこに存在してさえいるかを直接カリフォルニアと伝えるでしょう。 例えば、新規登録、そして/または、証明に、対象はRAを使用するかもしれませんが、証明書をリフレッシュするためにカリフォルニアと共に直接伝達してください。
1.3 PKI Management Requirements
1.3 PKI管理要件
The protocols given here meet the following requirements on PKI management.
ここに与えられたプロトコルはPKI管理に関する以下の必要条件を満たします。
1. PKI management must conform to the ISO 9594-8 standard and the
associated amendments (certificate extensions)
1. PKI管理はISO9594-8規格と関連修正に従わなければなりません。(証明書拡張子)
2. PKI management must conform to the other parts of this series.
2. PKI管理はこのシリーズの他の部分に従わなければなりません。
3. It must be possible to regularly update any key pair without
affecting any other key pair.
3. 定期的にいかなる他の主要な組にも影響しないでどんな主要な組もアップデートするのは可能であるに違いありません。
4. The use of confidentiality in PKI management protocols must be
kept to a minimum in order to ease regulatory problems.
4. 規制問題を緩和するためにPKI管理プロトコルにおける秘密性の使用を最小限に保たなければなりません。
Adams & Farrell Standards Track [Page 4] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[4ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
5. PKI management protocols must allow the use of different
industry-standard cryptographic algorithms, (specifically
including RSA, DSA, MD5, SHA-1) -- this means that any given
CA, RA, or end entity may, in principle, use whichever
algorithms suit it for its own key pair(s).
5. PKI管理プロトコルは、異なった業界基準暗号アルゴリズムの使用、(明確にRSA、DSA、MD5、SHA-1を含んでいます)と許容しなければなりません--これは、どんな与えられたカリフォルニア、RA、または終わりの実体も原則としてそれ自身の主要な組にそれに合うどのアルゴリズムを使用するかもしれないかを意味します。
6. PKI management protocols must not preclude the generation of
key pairs by the end-entity concerned, by an RA, or by a CA --
key generation may also occur elsewhere, but for the purposes
of PKI management we can regard key generation as occurring
wherever the key is first present at an end entity, RA, or CA.
6. PKI管理プロトコルは私たちが見なすことができるPKI管理の目的がどこでも、キーが最初に終わっていた状態で存在しているところに起こるとして世代を合わせてRA、またはaによってまた、しかし、カリフォルニア--世代を合わせるのがほかの場所に起こるかもしれないことが心配されている終わり実体実体、RA、またはカリフォルニアによる主要な組の世代を排除してはいけません。
7. PKI management protocols must support the publication of
certificates by the end-entity concerned, by an RA, or by a CA.
Different implementations and different environments may choose
any of the above approaches.
7. PKI管理プロトコルはRAによって関せられた終わり実体の近くかカリフォルニアのそばの証明書の公表をサポートしなければなりません。 異なった実装と異なった環境は上のアプローチのいずれも選ぶかもしれません。
8. PKI management protocols must support the production of
Certificate Revocation Lists (CRLs) by allowing certified end
entities to make requests for the revocation of certificates -
this must be done in such a way that the denial-of-service
attacks which are possible are not made simpler.
8. 公認された終わりの実体が証明書の取消しを求める要求をするのを許容することによって、PKI管理プロトコルはCertificate Revocation Lists(CRLs)の生産をサポートしなければなりません--可能なサービス不能攻撃をより簡単にしないような方法でこれをしなければなりません。
9. PKI management protocols must be usable over a variety of
"transport" mechanisms, specifically including mail, http,
TCP/IP and ftp.
9. PKI管理プロトコルは明確にメール、http、TCP/IP、およびftpを含むさまざまな「輸送」メカニズムの上で使用可能であるに違いありません。
10. Final authority for certification creation rests with the CA;
no RA or end-entity equipment can assume that any certificate
issued by a CA will contain what was requested -- a CA may
alter certificate field values or may add, delete or alter
extensions according to its operating policy. In other words,
all PKI entities (end-entities, RAs, and CAs) must be capable
of handling responses to requests for certificates in which
the actual certificate issued is different from that requested
(for example, a CA may shorten the validity period requested).
Note that policy may dictate that the CA must not publish or
otherwise distribute the certificate until the requesting
entity has reviewed and accepted the newly-created certificate
(typically through use of the PKIConfirm message).
10. 証明作成のための最終的な権威はカリフォルニアに責任があります。 どんなRAも終わり実体設備も、カリフォルニアによって発行されたどんな証明書も要求されたことを含むと仮定できません--運営方針に従って、カリフォルニアは、拡大を証明書分野値を変更するか、加えるか、削除するか、または変更するかもしれません。 言い換えれば、すべてのPKI実体(終わり実体、RAs、およびCAs)は発行された実際の証明書が要求されたそれと異なっている証明書に関する要求への取り扱い応答ができなければなりません(例えば、カリフォルニアは要求された有効期間を短くするかもしれません)。 方針が、要求実体が新たに作成された証明書(通常PKIConfirmメッセージの使用による)を再検討して、受け入れるまで、カリフォルニアが証明書を発表してはいけませんし、またそうでなければ、配布してはいけないと決めるかもしれないことに注意してください。
11. A graceful, scheduled change-over from one non-compromised CA
key pair to the next (CA key update) must be supported (note
that if the CA key is compromised, re-initialization must be
performed for all entities in the domain of that CA). An end
entity whose PSE contains the new CA public key (following a
CA key update) must also be able to verify certificates
verifiable using the old public key. End entities who directly
11. 非感染している主要な1カリフォルニア組から次の組までオーバー優雅で、予定されている変化するのを(カリフォルニアの主要なアップデート)サポートしなければなりません(カリフォルニアキーが感染されるなら、そのカリフォルニアのドメインのすべての実体のために再初期化を実行しなければならないことに注意してください)。 また、PSEが新しいカリフォルニア公開鍵(カリフォルニアの主要なアップデートに続く)を含む終わりの実体は、古い公開鍵を使用することで証明可能な証明書について確かめることができなければなりません。 実体を終わらせてください、だれ、直接
Adams & Farrell Standards Track [Page 5] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[5ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
trust the old CA key pair must also be able to verify
certificates signed using the new CA private key. (Required
for situations where the old CA public key is "hardwired" into
the end entity's cryptographic equipment).
また、古いカリフォルニア主要な組が新しいカリフォルニア秘密鍵を使用することで署名される証明書について確かめることができなければならないと信じてください。 (古いカリフォルニア公開鍵が終わりの実体の暗号の設備に「配線される」状況のために、必要です。)
12. The Functions of an RA may, in some implementations or
environments, be carried out by the CA itself. The protocols
must be designed so that end entities will use the same
protocol (but, of course, not the same key!) regardless of
whether the communication is with an RA or CA.
12. いくつかの実装か環境で、RAのFunctionsがカリフォルニア自体によって行われるかもしれません。 コミュニケーションがRAかカリフォルニアと共にあることにかかわらず終わりの実体が同じプロトコル(しかし、もちろん同じキーでない!)を使用するように、プロトコルを設計しなければなりません。
13. Where an end entity requests a certificate containing a given
public key value, the end entity must be ready to demonstrate
possession of the corresponding private key value. This may be
accomplished in various ways, depending on the type of
certification request. See Section 2.3, "Proof of Possession
of Private Key", for details of the in-band methods defined
for the PKIX-CMP (i.e., Certificate Management Protocol)
messages.
13. 終わりの実体が与えられた公開鍵値を含む証明書を要求するところでは、終わりの実体は対応する秘密鍵価値の所有物のデモをする準備ができているに違いありません。 証明要求のタイプに頼っていて、これはいろいろ達成されるかもしれません。 セクション2.3、「秘密鍵の所有物の証拠」を見てください、バンドにおけるPKIX-CMP(すなわち、Certificate Managementプロトコル)メッセージのために定義されたメソッドの詳細のために。
PKI Management Operations
PKI管理操作
The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The letters in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the lettered lines.
以下のダイヤグラムは上でPKI管理操作で定義された実体の間の関係を示しています。 ダイヤグラムによる手紙はそれぞれの文字入りの系列に沿って定義されたセットのPKI管理メッセージを送ることができるという意味における「プロトコル」を示します。
Adams & Farrell Standards Track [Page 6] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[6ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
+---+ cert. publish +------------+ j
| | <--------------------- | End Entity | <-------
| C | g +------------+ "out-of-band"
| | | ^ loading
| e | | | initial
| r | a | | b registration/
| t | | | certification
| | | | key pair recovery
| / | | | key pair update
| | | | certificate update
| C | PKI "USERS" V | revocation request
| R | -------------------+-+-----+-+------+-+-------------------
| L | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| | V | | |
| R | g +------+ d | |
| e | <------------ | RA | <-----+ | |
| p | cert. | | ----+ | | |
| o | publish +------+ c | | | |
| s | | | | |
| i | V | V |
| t | g +------------+ i
| o | <------------------------| CA |------->
| r | h +------------+ "out-of-band"
| y | cert. publish | ^ publication
| | CRL publish | |
+---+ | | cross-certification
e | | f cross-certificate
| | update
| |
V |
+------+
| CA-2 |
+------+
+---+本命+を発行してください。------------+ j| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 終わりの実体| <、-、-、-、-、-、--、| C| g+------------+ 「バンドの外」| | | ^荷重| e| | | 初期| r| a| | b登録/| t| | | 証明| | | | 主要な組回復| / | | | 主要な組アップデート| | | | 証明書最新版| C| PKI「ユーザ」V| 取消し要求| R| -------------------+-+-----+-+------+-+------------------- | L| PKI管理| ^ | ^ | | 実体a| | b a| | b| | V| | | | R| g+------+ d| | | e| <、-、-、-、-、-、-、-、-、-、-、--、| RA| <、-、-、-、--+ | | | p| 本命。 | | ----+ | | | | o | +を発行してください。------+ c| | | | | s| | | | | | i| V| V| | t| g+------------+ i| o | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| カリフォルニア|、-、-、-、-、-、--、>| r| h+------------+ 「バンドの外」| y| 本命発行してください。| ^公表| | CRLは発行します。| | +---+ | | 相互認証e| | f交差している証明書| | アップデート| | V| +------+ | カリフォルニア-2| +------+
Figure 1 - PKI Entities
図1--PKI実体
At a high level the set of operations for which management messages are defined can be grouped as follows.
高いレベルでは、以下の通り管理メッセージが定義される操作のセットを分類できます。
1 CA establishment: When establishing a new CA, certain steps are
required (e.g., production of initial CRLs, export of CA public
key).
1 カリフォルニアの設立: 新しいカリフォルニアを設置するとき、ある一定のステップが必要です(例えば、初期のCRLsの生産、カリフォルニア公開鍵の輸出)。
2 End entity initialization: this includes importing a root CA
public key and requesting information about the options
supported by a PKI management entity.
2 実体初期化を終わらせてください: これは、根のカリフォルニア公開鍵をインポートして、PKI経営体で後押しされているオプションの情報を要求するのを含んでいます。
Adams & Farrell Standards Track [Page 7] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[7ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3 Certification: various operations result in the creation of new
certificates:
3証明: 様々な操作は新しい証明書の作成をもたらします:
3.1 initial registration/certification: This is the process
whereby an end entity first makes itself known to a CA or
RA, prior to the CA issuing a certificate or certificates
for that end entity. The end result of this process (when it
is successful) is that a CA issues a certificate for an end
entity's public key, and returns that certificate to the end
entity and/or posts that certificate in a public repository.
This process may, and typically will, involve multiple
"steps", possibly including an initialization of the end
entity's equipment. For example, the end entity's equipment
must be securely initialized with the public key of a CA, to
be used in validating certificate paths. Furthermore, an
end entity typically needs to be initialized with its own
key pair(s).
3.1 登録/証明に頭文字をつけてください: これは終わりの実体が最初にカリフォルニアかRAにそれ自体を明らかにするプロセスです、その終わりの実体のための証明書か証明書を発行するカリフォルニアの前に。 このプロセス(それがうまくいっているとき)の結末は終わりの実体の公開鍵、およびリターンのための証明書に終わりの実体へのその証明書を発行する、そして/または、カリフォルニアが公共の倉庫でその証明書をポストに発行するということです。 ことによると終わりの実体の設備の初期化を含んでいて、このプロセスはかかわるかもしれなくて、通常望んでください、そして、複数の「ステップ」にかかわってください。 例えば、カリフォルニアの公開鍵でしっかりと終わりの実体の設備を初期化して、証明書経路を有効にする際に使用されなければなりません。 その上、終わりの実体は、通常それ自身の主要な組と共に初期化される必要があります。
3.2 key pair update: Every key pair needs to be updated
regularly (i.e., replaced with a new key pair), and a new
certificate needs to be issued.
3.2の主要な組アップデート: すべての主要な組が、定期的(すなわち、新しい主要な組に、取って代わる)にアップデートする必要があります、そして、新しい証明書は発行される必要があります。
3.3 certificate update: As certificates expire they may be
"refreshed" if nothing relevant in the environment has
changed.
3.3 アップデートを証明してください: 証明書が期限が切れて、環境で関連しているものは何も変化していないなら、それらは「リフレッシュされるかもしれません」。
3.4 CA key pair update: As with end entities, CA key pairs need
to be updated regularly; however, different mechanisms are
required.
3.4のカリフォルニアの主要な組アップデート: 終わりの実体のように、カリフォルニア主要な組は、定期的にアップデートする必要があります。 しかしながら、異なったメカニズムが必要です。
3.5 cross-certification request: One CA requests issuance of a
cross-certificate from another CA. For the purposes of this
standard, the following terms are defined. A "cross-
certificate" is a certificate in which the subject CA and
the issuer CA are distinct and SubjectPublicKeyInfo contains
a verification key (i.e., the certificate has been issued
for the subject CA's signing key pair). When it is
necessary to distinguish more finely, the following terms
may be used: a cross-certificate is called an "inter-domain
cross-certificate" if the subject and issuer CAs belong to
different administrative domains; it is called an "intra-
domain cross-certificate" otherwise.
3.5相互認証要求: 別のカリフォルニアからの交差している証明書の1つのカリフォルニアの要求発行。 この規格の目的のために、次の用語は定義されます。 「十字証明書」は対象のカリフォルニアと発行人カリフォルニアが異なっている証明書です、そして、SubjectPublicKeyInfoは検証キーを含んでいます(対象のCAの署名重要組のためにすなわち、証明書を発行しました)。 よりきめ細かく区別するのが必要であるときに、次の用語は使用されるかもしれません: 対象と発行人CAsが異なった管理ドメインに属すなら、交差している証明書は「相互ドメインの交差している証明書」と呼ばれます。 それは別の方法で「イントラのドメインの交差している証明書」と呼ばれます。
Adams & Farrell Standards Track [Page 8] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[8ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Notes:
注意:
Note 1. The above definition of "cross-certificate" aligns with the defined term "CA-certificate" in X.509. Note that this term is not to be confused with the X.500 "cACertificate" attribute type, which is unrelated.
1に注意してください。 「交差している証明書」の上の定義はX.509の「カリフォルニア-証明書」という定義された用語に並びます。 X.500"cACertificate"属性タイプに今期を混乱させてはいけないことに注意してください。(その属性タイプは、関係ありません)。
Note 2. In many environments the term "cross-certificate", unless further qualified, will be understood to be synonymous with "inter- domain cross-certificate" as defined above.
2に注意してください。 多くの環境で、さらに資格がないと、「交差している証明書」という用語が上で定義されるように「相互ドメインの交差している証明書」と同義であることが理解されるでしょう。
Note 3. Issuance of cross-certificates may be, but is not necessarily, mutual; that is, two CAs may issue cross-certificates for each other.
3に注意してください。 交差している証明書の発行があるかもしれませんが、必ずあるというわけではない、互い。 すなわち、2CAsが互いのために交差している証明書を発行するかもしれません。
3.6 cross-certificate update: Similar to a normal certificate
update but involving a cross-certificate.
3.6交差している証明書最新版: 通常の証明書最新版と同様ですが、交差している証明書にかかわります。
4 Certificate/CRL discovery operations: some PKI management
operations result in the publication of certificates or CRLs:
4 証明書/CRL発見操作: いくつかのPKI管理操作が証明書かCRLsの公表をもたらします:
4.1 certificate publication: Having gone to the trouble of
producing a certificate, some means for publishing it is
needed. The "means" defined in PKIX MAY involve the
messages specified in Sections 3.3.13 - 3.3.16, or MAY
involve other methods (LDAP, for example) as described in
the "Operational Protocols" documents of the PKIX series of
specifications.
4.1 公表を証明してください: わざわざ証明書を製作して、それを発行するためのいくつかの手段が必要です。 PKIX MAYで定義された「手段」はセクション3.3.13で指定されたメッセージにかかわります--、3.3、.16、「操作上のプロトコル」という仕様のPKIXシリーズのドキュメントで説明されるように他のメソッド(例えば、LDAP)にかかわるかもしれません。
4.2 CRL publication: As for certificate publication.
4.2 CRL公表: 証明書公表のように。
5 Recovery operations: some PKI management operations are used
when an end entity has "lost" its PSE:
5 回復操作: 終わりの実体がPSEを「失った」とき、いくつかのPKI管理操作が使用されています:
5.1 key pair recovery: As an option, user client key materials
(e.g., a user's private key used for decryption purposes)
MAY be backed up by a CA, an RA, or a key backup system
associated with a CA or RA. If an entity needs to recover
these backed up key materials (e.g., as a result of a
forgotten password or a lost key chain file), a protocol
exchange may be needed to support such recovery.
5.1 主要な組回復: オプションとして、ユーザクライアント主要資材(例えば復号化目的に使用されるユーザの秘密鍵)はカリフォルニアかRAに関連しているカリフォルニア、RA、または主要なバックアップ・システムによって支援されるかもしれません。 実体が、主要資材で支持されたこれら(例えば、忘れられたパスワードか無くなっているキーチェーンファイルの結果、)を回復する必要があるなら、プロトコル交換が、そのような回復をサポートするのに必要であるかもしれません。
6 Revocation operations: some PKI operations result in the
creation of new CRL entries and/or new CRLs:
6 取消し操作: いくつかのPKI操作が新しいCRLエントリー、そして/または、新しいCRLsの作成をもたらします:
6.1 revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
6.1取消し要求: 権限保持者は証明書取消しを必要とする異常な状況をカリフォルニアに知らせます。
Adams & Farrell Standards Track [Page 9] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[9ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
7 PSE operations: whilst the definition of PSE operations (e.g.,
moving a PSE, changing a PIN, etc.) are beyond the scope of this
specification, we do define a PKIMessage (CertRepMessage) which
can form the basis of such operations.
7 PSE操作: PSEの定義である間、操作(例えば、暗証番号を変えて、PSEを動かしますなど)はこの仕様の範囲を超えていて、私たちはそのような操作の基礎を形成できるPKIMessage(CertRepMessage)を定義します。
Note that on-line protocols are not the only way of implementing the above operations. For all operations there are off-line methods of achieving the same result, and this specification does not mandate use of on-line protocols. For example, when hardware tokens are used, many of the operations MAY be achieved as part of the physical token delivery.
オンラインプロトコルが唯一の道にどんな上の操作を実装しないものであることに注意してください。 すべての操作のために、同じ結果を獲得するメソッドがオフラインであります、そして、この仕様はオンラインプロトコルの使用を強制しません。 ハードウェアトークンが使用されているとき、例えば、操作の多くが物理的なトークン配送の一部として達成されるかもしれません。
Later sections define a set of standard messages supporting the above operations. The protocols for conveying these exchanges in different environments (file based, on-line, E-mail, and WWW) is also specified.
後のセクションは上の操作をサポートする1セットの標準のメッセージを定義します。 また、異なった環境(ベースの、そして、オンラインのメール、およびWWWをファイルする)におけるこれらの交換を伝えるためのプロトコルは指定されます。
2. Assumptions and restrictions
2. 仮定と制限
2.1 End entity initialization
2.1 終わりの実体初期化
The first step for an end entity in dealing with PKI management entities is to request information about the PKI functions supported and to securely acquire a copy of the relevant root CA public key(s).
PKI経営体に対処することにおける終わりの実体のための第一歩は、機能がサポートしたPKIの情報を要求して、しっかりと関連根のカリフォルニア公開鍵のコピーを入手することです。
2.2 Initial registration/certification
2.2 新規登録/証明
There are many schemes that can be used to achieve initial registration and certification of end entities. No one method is suitable for all situations due to the range of policies which a CA may implement and the variation in the types of end entity which can occur.
終わりの実体の新規登録と証明を達成するのに使用できる多くの体系があります。 いいえ1、メソッドはカリフォルニアが実装するかもしれない方針の範囲と終わりの実体のタイプの起こることができる変化のためにすべての状況に適しています。
We can however, classify the initial registration / certification schemes that are supported by this specification. Note that the word "initial", above, is crucial - we are dealing with the situation where the end entity in question has had no previous contact with the PKI. Where the end entity already possesses certified keys then some simplifications/alternatives are possible.
私たちは、しかしながら、分類できて、この仕様でサポートされる新規登録/証明体系を分類します。 「初期」という言葉が上で重要であることに注意してください--私たちは問題の終わりの実体がPKIとの前の接触を全く持っていないところに時局に処しています。 終わりの実体がその時既に公認されたキーを所有するところでは、いくつかの簡素化/選択肢が可能です。
Having classified the schemes that are supported by this specification we can then specify some as mandatory and some as optional. The goal is that the mandatory schemes cover a sufficient number of the cases which will arise in real use, whilst the optional schemes are available for special cases which arise less frequently. In this way we achieve a balance between flexibility and ease of implementation.
この仕様でサポートされる体系を分類したので、そして、私たちは任意であるとして義務的であるとしてのいくつかといくつかを指定できます。 目標は義務的な体系が本当の使用で起こるケースの十分な数をカバーしているということです、任意の体系が、より頻繁でなく起こる特別なケースに利用可能ですが。 このように、私たちは柔軟性と実装の容易さの間のバランスを獲得します。
Adams & Farrell Standards Track [Page 10] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[10ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
We will now describe the classification of initial registration / certification schemes.
私たちは現在、新規登録/証明体系の分類について説明するつもりです。
2.2.1 Criteria used
2.2.1 使用される評価基準
2.2.1.1 Initiation of registration / certification
2.2.1.1 登録/証明の開始
In terms of the PKI messages which are produced we can regard the initiation of the initial registration / certification exchanges as occurring wherever the first PKI message relating to the end entity is produced. Note that the real-world initiation of the registration / certification procedure may occur elsewhere (e.g., a personnel department may telephone an RA operator).
出されるPKIメッセージに関して、私たちは、新規登録/証明交換の開始をどこでも、終わりの実体に関連する最初のPKIメッセージが出されるところに起こると見なすことができます。 登録/証明手順の本当の世界開始がほかの場所に起こるかもしれないことに注意してください(例えば、人事課はRAオペレータに電話をするかもしれません)。
The possible locations are at the end entity, an RA, or a CA.
可能な位置が終わりの実体、RA、またはカリフォルニアにあります。
2.2.1.2 End entity message origin authentication
2.2.1.2 終わりの実体メッセージ発生源認証
The on-line messages produced by the end entity that requires a certificate may be authenticated or not. The requirement here is to authenticate the origin of any messages from the end entity to the PKI (CA/RA).
証明書を必要とする終わりの実体によって出されたオンラインメッセージは認証されるかもしれません。 ここの要件は終わりの実体からPKI(カリフォルニア/RA)までどんなメッセージの発生源も認証することです。
In this specification, such authentication is achieved by the PKI (CA/RA) issuing the end entity with a secret value (initial authentication key) and reference value (used to identify the transaction) via some out-of-band means. The initial authentication key can then be used to protect relevant PKI messages.
この仕様では、そのような認証はバンドの外でいくつかを通して秘密の値(初期の認証キー)と基準値(以前はよくトランザクションを特定していた)で終わりの実体を発行すると意味するPKI(カリフォルニア/RA)によって達成されます。 そして、関連PKIメッセージを保護するのに初期の認証キーを使用できます。
We can thus classify the initial registration/certification scheme according to whether or not the on-line end entity -> PKI messages are authenticated or not.
その結果、オンライン終わりの実体->PKIメッセージが認証されるかどうかに従って、私たちは新規登録/証明体系を分類できます。
Note 1: We do not discuss the authentication of the PKI -> end entity messages here as this is always REQUIRED. In any case, it can be achieved simply once the root-CA public key has been installed at the end entity's equipment or it can be based on the initial authentication key.
注意1: 私たちは、いつもこれがREQUIREDであるので、ここでPKI->終わりの実体メッセージの認証について議論しません。 どのような場合でも、単にカリフォルニアを根づかせている公開鍵がいったん終わりの実体の設備にインストールされると、それを達成できますか、またはそれは初期の認証キーに基づくことができます。
Note 2: An initial registration / certification procedure can be secure where the messages from the end entity are authenticated via some out- of-band means (e.g., a subsequent visit).
注意2: 新規登録/証明手順はバンドのいくつかの出ている手段(例えば、その後の訪問)で終わりの実体からのメッセージが認証されるところで安全である場合があります。
2.2.1.3 Location of key generation
2.2.1.3 キー生成の位置
In this specification, "key generation" is regarded as occurring wherever either the public or private component of a key pair first occurs in a PKIMessage. Note that this does not preclude a
この仕様では、「キー生成」はどこでも、主要な組の公共の、または、個人的なコンポーネントが最初にPKIMessageに起こるところに起こると見なされます。 これがaを排除しないことに注意してください。
Adams & Farrell Standards Track [Page 11] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[11ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
centralized key generation service - the actual key pair MAY have been generated elsewhere and transported to the end entity, RA, or CA using a (proprietary or standardized) key generation request/response protocol (outside the scope of this specification).
集結されたキー生成サービス--実際のキー組は、(独占であるか標準化された)キー生成要求/応答プロトコルを使用する終わりの実体、RA、またはカリフォルニアに、ほかの場所で生成されて、輸送されたかもしれません(この仕様の範囲の外で)。
There are thus three possibilities for the location of "key generation": the end entity, an RA, or a CA.
その結果、「キー生成」の位置への3つの可能性があります: 終わりの実体、RA、またはカリフォルニア。
2.2.1.4 Confirmation of successful certification
2.2.1.4 うまくいっている証明の確認
Following the creation of an initial certificate for an end entity, additional assurance can be gained by having the end entity explicitly confirm successful receipt of the message containing (or indicating the creation of) the certificate. Naturally, this confirmation message must be protected (based on the initial authentication key or other means).
または、終わりの実体のための初期の証明書の作成に続いて、終わりの実体にメッセージ含有のうまくいっている領収書を明らかに確認させることによって追加保証を獲得できる、(作成を示す、)、証明書。 当然、この確認メッセージを保護しなければなりません(初期の認証主要であるか他の手段に基づいています)。
This gives two further possibilities: confirmed or not.
これはさらなる2つの可能性を与えます: 確認にされる。
2.2.2 Mandatory schemes
2.2.2 義務的な体系
The criteria above allow for a large number of initial registration / certification schemes. This specification mandates that conforming CA equipment, RA equipment, and EE equipment MUST support the second scheme listed below. Any entity MAY additionally support other schemes, if desired.
上の評価基準は多くの新規登録/証明体系を考慮します。 設備が2番目の体系をサポートしなければならないこの仕様の命令のそんなに従っているカリフォルニア設備、RA設備、およびEEは以下に記載しました。 望まれているなら、どんな実体もさらに、他の体系をサポートするかもしれません。
2.2.2.1 Centralized scheme
2.2.2.1 集結された体系
In terms of the classification above, this scheme is, in some ways, the simplest possible, where:
分類で、この体系はいくつかの道、可能な最も簡単の上では、どこです:
- initiation occurs at the certifying CA; - no on-line message authentication is required; - "key generation" occurs at the certifying CA (see Section 2.2.1.3); - no confirmation message is required.
- 開始は公認カリフォルニアに起こります。 - どんなオンライン通報認証も必要ではありません。 - 「キー生成」が公認カリフォルニアに起こる、(セクション2.2.1を見てください、.3)。 - 確認メッセージは全く必要ではありません。
In terms of message flow, this scheme means that the only message required is sent from the CA to the end entity. The message must contain the entire PSE for the end entity. Some out-of-band means must be provided to allow the end entity to authenticate the message received and decrypt any encrypted values.
メッセージ流動で、唯一のメッセージが必要としたこの体系手段をカリフォルニアから終わりの実体に送ります。 メッセージは終わりの実体のための全体のPSEを含まなければなりません。 終わりの実体が受け取られたメッセージを認証して、どんな暗号化された値も解読するのを許容するためにいくつかのバンドで出ている手段を提供しなければなりません。
Adams & Farrell Standards Track [Page 12] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[12ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
2.2.2.2 Basic authenticated scheme
2.2.2.2 基本的な認証された体系
In terms of the classification above, this scheme is where:
分類で、この体系は上では、どこです:
- initiation occurs at the end entity; - message authentication is REQUIRED; - "key generation" occurs at the end entity (see Section 2.2.1.3); - a confirmation message is REQUIRED.
- 開始は終わりの実体で起こります。 - 通報認証はREQUIREDです。 - 「キー生成」が終わりの実体で起こる、(セクション2.2.1を見てください、.3)。 - 確認メッセージはREQUIREDです。
In terms of message flow, the basic authenticated scheme is as follows:
メッセージ流動では、基本的な認証された体系は以下の通りです:
End entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> EE)
Key generation
Creation of certification request
Protect request with IAK
-->>--certification request-->>--
verify request
process request
create response
--<<--certification response--<<--
handle response
create confirmation
-->>--confirmation message-->>--
verify confirmation
終わりの実体RA/カリフォルニア========== ============= バンドの外に、Initial Authentication Key(IAK)とプロセスを要求するProtectがIAK-->>--証明要求(>>)で要求する証明要求のキー生成Creationが、確かめる(RA/カリフォルニア->EE)が応答--<<--証明応答--<<--ハンドル応答を作成するよう要求する基準値の分配は確認を作成します-->>--確認メッセージ-->>--確認について確かめてください。
(Where verification of the confirmation message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.)
(確認メッセージの検証が失敗するところでは、それを発行するか、または別の方法で利用可能にしたなら、RA/カリフォルニアは新譜の証明書を取り消さなければなりません。)
2.3 Proof of Possession (POP) of Private Key
秘密鍵の1.15度の所有物(飛び出します)
In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA is free to choose how to enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in- band messages) in its certification exchanges (i.e., this may be a policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the
ある攻撃を防いで、カリフォルニア/RAが適切に終わりの実体と主要な組の間の結合の正当性をチェックするのを許容するために、ここで指定されたPKI管理操作で、終わりの実体が、(すなわち、使用に、できます)秘密鍵の所有物を証明書が要求されている公開鍵に対応するようにすると立証するのが可能になります。 与えられたカリフォルニア/RAは自由に証明交換でPOPを実施する(-例えば、外では、バンドでは、手続き上の手段は対PKIX-CMP中でメッセージを括ります)方法を選ぶことができます(すなわち、これは政策問題であるかもしれません)。 しかしながら、現在、終わりの実体と秘密鍵の間には、明らかに結合をチェックしない使用中の多くの非PKIX操作上のプロトコル(様々な電子メールプロトコルは1つの例である)があるのでCAs/RAsがどうでもPOPを実施しなければならないのは、REQUIREDです。 それが確かめる操作上のプロトコル
Adams & Farrell Standards Track [Page 13] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[13ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful.
結合(署名、暗号化、および主要な協定主要な組)が存在していて、遍在している、カリフォルニア/RAによって確かめられたとこの結合を思うことができるだけです。 したがって、結合がカリフォルニア/RAによって確かめられないなら、インターネット公開鍵暗号基盤の証明書は結局、いくらか重要ではありません。
POP is accomplished in different ways depending upon the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., an RSA key) then any appropriate method MAY be used (e.g., a key which may be used for signing, as well as other purposes, SHOULD NOT be sent to the CA/RA in order to prove possession).
POPは証明書が要求されているキーのタイプに頼る異なった方法で達成されます。 複数の目的(例えば、RSAキー)にキーを使用できるならどんな適切なメソッドも使用されるかもしれない、(例えば、そうするかもしれないキー、他の目的と同様にSHOULD NOTに署名するのに使用されて、所有物を立証するためにカリフォルニア/RAに送ってください、)
This specification explicitly allows for cases where an end entity supplies the relevant proof to an RA and the RA subsequently attests to the CA that the required proof has been received (and validated!). For example, an end entity wishing to have a signing key certified could send the appropriate signature to the RA which then simply notifies the relevant CA that the end entity has supplied the required proof. Of course, such a situation may be disallowed by some policies (e.g., CAs may be the only entities permitted to verify POP during certification).
この仕様は、終わりの実体が関連証拠をRAに供給して、RAが次にカリフォルニアを証明するケースのために必要な証拠が受け取られたのを(そして、有効にされます!)明らかに許容します。 例えば、署名キーを公認させる終わりの実体願望は次に終わりの実体が必要な証拠を供給したことを単に関連カリフォルニアに通知するRAに適切な署名を送るかもしれません。 もちろん、そのような状況はいくつかの方針で禁じられるかもしれません(例えば、CAsは証明の間、POPについて確かめることが許可された唯一の実体であるかもしれません)。
2.3.1 Signature Keys
2.3.1 署名キー
For signature keys, the end entity can sign a value to prove possession of the private key.
署名キーに関しては、終わりの実体は、秘密鍵の所有物を立証するために値に署名することができます。
2.3.2 Encryption Keys
2.3.2 暗号化キー
For encryption keys, the end entity can provide the private key to the CA/RA, or can be required to decrypt a value in order to prove possession of the private key (see Section 3.2.8). Decrypting a value can be achieved either directly or indirectly.
暗号化キーに関しては、終わりの実体は、カリフォルニア/RAに秘密鍵を供給できるか、または秘密鍵の所有物を立証するために値を解読するために必要とすることができます(セクション3.2.8を見てください)。 直接か間接的に値を解読するのを達成できます。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the EE is required.
ダイレクトメソッドはRA/カリフォルニアがEEによる即時型反応が必要である無作為の挑戦を発行することです。
The indirect method is to issue a certificate which is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in the confirmation message). This allows a CA to issue a certificate in a form which can only be used by the intended end entity.
間接的なメソッドは終わりの実体のために暗号化される証明書を発行する(終わりの実体に確認メッセージにこの証明書を解読する性能を示させてください)ことです。 これで、カリフォルニアは意図している終わりの実体で使用できるだけであるフォームで証明書を下付します。
This specification encourages use of the indirect method because this
requires no extra messages to be sent (i.e., the proof can be
demonstrated using the {request, response, confirmation} triple of
messages).
これがどんな送られるべき付加的なメッセージも必要としないのでこの仕様が間接的なメソッドの使用を奨励する、(すなわち、証拠が示された使用であることができる、要求、応答、確認がメッセージを3倍にする、)
Adams & Farrell Standards Track [Page 14] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[14ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
2.3.3 Key Agreement Keys
2.3.3 主要な協定キー
For key agreement keys, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key.
主要な協定キーに関しては、終わりの実体とPKI経営体(すなわち、カリフォルニアかRA)は、終わりの実体には秘密鍵の所有物があると立証するために共有された秘密鍵を設立しなければなりません。
Note that this need not impose any restrictions on the keys that can be certified by a given CA -- in particular, for Diffie-Hellman keys the end entity may freely choose its algorithm parameters -- provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.
これが与えられたカリフォルニアが公認できるキーに少しの制限も課す必要はないことに注意してください--必要であるときに、カリフォルニアが適切なパラメタで短期的で(1回)の主要な組を生成することができれば、ディフィー-ヘルマンキーのために、特に、終わりの実体は自由にアルゴリズムパラメタを選ぶかもしれません。
2.4 Root CA key update
2.4 根のカリフォルニアキーアップデート
This discussion only applies to CAs that are a root CA for some end entity.
この議論は何らかの終わりの実体のための根のカリフォルニアであるCAsに適用されるだけです。
The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld; OldWithNew; NewWithOld; and NewWithNew).
ここで説明された手順の基礎はカリフォルニアが逆もまた同様に前の秘密鍵を使用することで新しい公開鍵を保護するということです。 したがって、カリフォルニアが主要な組をアップデートすると、X.500ディレクトリ(4の合計: OldWithOld; OldWithNew; NewWithOld and NewWithNewのための)を使用することで証明書を利用可能にするなら、それは、2の付加的なcACertificate属性が値であると生成しなければなりません。
When a CA changes its key pair those entities who have acquired the old CA public key via "out-of-band" means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. However, they will only require this for a limited period (until they have acquired the new CA public key via the "out-of-band" mechanism). This will typically be easily achieved when these end entities' certificates expire.
カリフォルニアが主要な組を変えるとき、「バンドの外」という手段で古いカリフォルニア公開鍵を取得したそれらの実体は最も影響を受けます。 それはなる古いカリフォルニア秘密鍵で保護された新しいカリフォルニア公開鍵へのアクセスが必要にこれらの終わりの実体です。 しかしながら、彼らは限定期間の間、これを必要とするだけでしょう(彼らが「バンドの外」というメカニズムで新しいカリフォルニア公開鍵を取得するまで)。 これらの終わりの実体の証明書が期限が切れるとき、これは容易に通常達成されるでしょう。
The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required.
新しくて古いカリフォルニア公開鍵を保護するのに使用されるデータ構造は標準の証明書(また、拡大を含むかもしれない)です。 必要であるどんな新しいデータ構造もありません。
Note 1. This scheme does not make use of any of the X.509 v3 extensions as it must be able to work even for version 1 certificates. The presence of the KeyIdentifier extension would make for efficiency improvements.
1に注意してください。 この体系は、バージョン1証明書のためにさえ働くことができなければならないので、X.509 v3拡張子のいずれも利用しません。 KeyIdentifier拡張子の存在は効率改良になるでしょう。
Note 2. While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entities' certificates, this generalization seems of dubious value. Not having this generalization simply means that the validity period of a CA key pair must be greater than the validity period of any certificate issued by that CA using that key pair.
2に注意してください。 カリフォルニアが終わりの実体の証明書の1つの有効期間の間の一度より多くの主要な組をアップデートするケースをカバーするために体系を一般化できましたが、この一般化は疑わしい価値について見えます。 単にこの一般化を持っていないのは、カリフォルニア主要な組の有効期間にその主要な組を使用することでそのカリフォルニアによって発行されたどんな証明書の有効期間よりもすばらしいに違いないことを意味します。
Adams & Farrell Standards Track [Page 15] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[15ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Note 3.This scheme forces end entities to acquire the new CA public key on the expiry of the last certificate they owned that was signed with the old CA private key (via the "out-of-band" means). Certificate and/or key update operations occurring at other times do not necessarily require this (depending on the end entity's equipment).
注意3.This体系力は、それらが所有していた古いカリフォルニア秘密鍵(「バンドの外」という手段を通した)を契約された最後の証明書の満期に新しいカリフォルニア公開鍵を取得するために実体を終わらせます。 証明書、そして/または、他の時に起こる主要なアップデート操作は必ずこれを必要とするというわけではありません(終わりの実体の設備によって)。
2.4.1 CA Operator actions
2.4.1 カリフォルニアのOperator動作
To change the key of the CA, the CA operator does the following:
カリフォルニア(カリフォルニア)のオペレータのキーを変えるのは以下をします:
1. Generate a new key pair;
1. 新しい主要な組を生成してください。
2. Create a certificate containing the old CA public key signed
with the new private key (the "old with new" certificate);
2. 新しい秘密鍵(「新しいことで古い」証明書)を契約された古いカリフォルニア公開鍵を含む証明書を作成してください。
3. Create a certificate containing the new CA public key signed
with the old private key (the "new with old" certificate);
3. 古い秘密鍵(「古いことで新しい」証明書)を契約された新しいカリフォルニア公開鍵を含む証明書を作成してください。
4. Create a certificate containing the new CA public key signed
with the new private key (the "new with new" certificate);
4. 新しい秘密鍵(「新しいことで新しい」証明書)を契約された新しいカリフォルニア公開鍵を含む証明書を作成してください。
5. Publish these new certificates via the directory and/or other
means (perhaps using a CAKeyUpdAnn message);
5. ディレクトリ、そして/または、他の手段でこれらの新しい証明書を発表してください(恐らくCAKeyUpdAnnメッセージを使用して)。
6. Export the new CA public key so that end entities may acquire
it using the "out-of-band" mechanism (if required).
6. 終わりの実体が(必要なら、)「バンドの外」というメカニズムを使用することでそれを取得できるように、新しいカリフォルニア公開鍵をエクスポートしてください。
The old CA private key is then no longer required. The old CA public key will however remain in use for some time. The time when the old CA public key is no longer required (other than for non-repudiation) will be when all end entities of this CA have securely acquired the new CA public key.
そして、古いカリフォルニア秘密鍵はもう必要ではありません。 しかしながら、古いカリフォルニア公開鍵はしばらく使用中であり残るでしょう。 古いカリフォルニア公開鍵はもう必要でない(非拒否を除いて)時はこのカリフォルニアのすべての終わりの実体がしっかりと新しいカリフォルニア公開鍵を取得した時になるでしょう。
The "old with new" certificate must have a validity period starting at the generation time of the old key pair and ending at the expiry date of the old public key.
「新しいことで古い」証明書には、古い公開鍵の有効期限日の古い主要な組と結末の時に世代のときに始まる有効期間がなければなりません。
The "new with old" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which all end entities of this CA will securely possess the new CA public key (at the latest, the expiry date of the old public key).
「古いことで新しい」証明書には、時間のこのカリフォルニアのすべての終わりの実体に新しいカリフォルニア公開鍵がしっかりとある新しい主要な組と結末の時に世代のときに始まる有効期間がなければなりません(遅くとも、満期は古い公開鍵とデートします)。
The "new with new" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which the CA will next update its key pair.
「新しいことで新しい」証明書で、カリフォルニアが次にそうする時間の新しい主要な組と結末の時に世代のときに始まる有効期間は主要な組をアップデートしなければなりません。
Adams & Farrell Standards Track [Page 16] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[16ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
2.4.2 Verifying Certificates.
2.4.2 証明書について確かめること。
Normally when verifying a signature, the verifier verifies (among other things) the certificate containing the public key of the signer. However, once a CA is allowed to update its key there are a range of new possibilities. These are shown in the table below.
署名について確かめるとき、通常、検証は(特に)署名者の公開鍵を含む証明書について確かめます。 しかしながら、カリフォルニアがいったんキーをアップデートできると、さまざまな新しい可能性があります。 これらは以下のテーブルに示されます。
Repository contains NEW Repository contains only OLD
and OLD public keys public key (due to, e.g.,
delay in publication)
倉庫が含んでいる、NEW RepositoryはOLDとOLD公開鍵公開鍵だけを含んでいます。(当然であることで、例えば、公表で延着してください)
PSE PSE Contains PSE Contains PSE Contains
Contains OLD public NEW public OLD public
NEW public key key key
key
公共の公共のPSE PSE Contains PSE Contains PSE Contains Contains OLDの公共のNEW公開鍵主要な主要なNEW OLDキー
Signer's Case 1: Case 3: Case 5: Case 7:
certifi- This is In this case Although the In this case
cate is the the verifier CA operator the CA
protected standard must access has not operator has
using NEW case where the updated the not updated
public the directory in directory the the directory
key verifier order to get verifier can and so the
can the value of verify the verification
directly the NEW certificate will FAIL
verify the public key directly -
certificate this is thus
without the same as
using the case 1.
directory
署名者のケース1: ケース3: ケース5: ケース7: その結果、これはそうです。直接検証について確かめてください。certifiこれがIn本件Althoughである、In本件美味がオペレータではなく、保護された標準の必須アクセスが持っている検証カリフォルニアのオペレータカリフォルニアが使用NEWにどこをケースに入れさせるかということである、アップデートされなかった公衆をアップデートする、ディレクトリの主要な検証が缶を検証に手に入れて、缶をそうに手に入れるのを注文するディレクトリのディレクトリ、値、NEW証明書意志のFAILは直接公開鍵について確かめます--、証明書、ケース1を使用するのと同じくらいなしでディレクトリ
Signer's Case 2: Case 4: Case 6: Case 8:
certifi- In this In this case The verifier Although the
cate is case the the verifier thinks this CA operator
protected verifier can directly is the has not
using OLD must verify the situation of updated the
public access the certificate case 2 and directory the
key directory without will access verifier can
in order using the the verify the
to get the directory directory; certificate
value of however, the directly -
the OLD verification this is thus
public key will FAIL the same as
case 4.
署名者のケース2: ケース4: ケース6: ケース8: certifiこのIn本件における検証Although、美味が検証がこのカリフォルニアのオペレータであると考えるケースが直接検証缶を保護したということである、どんな使用しているOLD必須にも状況について確かめさせない、アップデートされることでは、公衆が意志のアクセス検証のない主要なディレクトリが中で使用を命令することができる証明書ケース2とディレクトリにアクセスする、検証、ディレクトリディレクトリを手に入れるために。 しかしながら、値を証明する、直接--、OLD検証、4をケースに入れるとき、これは同じようにその結果、公開鍵意志のFAILです。
Adams & Farrell Standards Track [Page 17] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[17ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
2.4.2.1 Verification in cases 1, 4, 5 and 8.
2.4.2.1 場合1、4、5、および8における検証。
In these cases the verifier has a local copy of the CA public key which can be used to verify the certificate directly. This is the same as the situation where no key change has occurred.
これらの場合では、検証は直接証明書について確かめるのに使用できるカリフォルニア公開鍵の地方のコピーを持っています。 これはキーチェンジが全く起こっていない状況と同じです。
Note that case 8 may arise between the time when the CA operator has generated the new key pair and the time when the CA operator stores the updated attributes in the directory. Case 5 can only arise if the CA operator has issued both the signer's and verifier's certificates during this "gap" (the CA operator SHOULD avoid this as it leads to the failure cases described below).
ケース8がカリフォルニアのオペレータが新しい主要な組を生成した時、カリフォルニアのオペレータがディレクトリのアップデートされた属性を保存する時の間に起こるかもしれないことに注意してください。 カリフォルニアのオペレータがこの「ギャップ」の間、署名者と検証の両方の証明書を発行している場合にだけ(以下で説明された失敗事件に通じて、カリフォルニアのオペレータSHOULDはこれを避けます)、ケース5は起こることができます。
2.4.2.2 Verification in case 2.
2.4.2.2 場合2における検証。
In case 2 the verifier must get access to the old public key of the CA. The verifier does the following:
場合2では、検証はカリフォルニアの古い公開鍵に近づく手段を得なければなりません。 検証は以下をします:
1. Look up the caCertificate attribute in the directory and pick
the OldWithNew certificate (determined based on validity
periods);
2. Verify that this is correct using the new CA key (which the
verifier has locally);
3. If correct, check the signer's certificate using the old CA
key.
1. ディレクトリのcaCertificate属性を見上げてください、そして、OldWithNew証明書(有効期間に基づいて断固とした)を選んでください。 2. これが新しいカリフォルニアキー(検証が局所的に持っている)を使用することで正しいことを確かめてください。 3. 正しいなら、古いカリフォルニアキーを使用することで署名者の証明書をチェックしてください。
Case 2 will arise when the CA operator has issued the signer's certificate, then changed key and then issued the verifier's certificate, so it is quite a typical case.
カリフォルニアのオペレータが署名者の証明書を発行して、次に、キーを変えて、次に、検証の証明書を発行したとき、ケース2が起こるので、それはかなり典型的なケースです。
2.4.2.3 Verification in case 3.
2.4.2.3 場合3における検証。
In case 3 the verifier must get access to the new public key of the CA. The verifier does the following:
場合3では、検証はカリフォルニアの新しい公開鍵に近づく手段を得なければなりません。 検証は以下をします:
1. Look up the CACertificate attribute in the directory and pick
the NewWithOld certificate (determined based on validity
periods);
2. Verify that this is correct using the old CA key (which the
verifier has stored locally);
3. If correct, check the signer's certificate using the new CA
key.
1. ディレクトリのCACertificate属性を見上げてください、そして、NewWithOld証明書(有効期間に基づいて断固とした)を選んでください。 2. これが古いカリフォルニアキー(検証が局所的に保存した)を使用することで正しいことを確かめてください。 3. 正しいなら、新しいカリフォルニアキーを使用することで署名者の証明書をチェックしてください。
Case 3 will arise when the CA operator has issued the verifier's certificate, then changed key and then issued the signer's certificate, so it is also quite a typical case.
カリフォルニアのオペレータが検証の証明書を発行して、次に、キーを変えて、次に、署名者の証明書を発行したとき、ケース3が起こるので、また、それはかなり典型的なケースです。
Adams & Farrell Standards Track [Page 18] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[18ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
2.4.2.4 Failure of verification in case 6.
2.4.2.4 場合6における検証の失敗。
In this case the CA has issued the verifier's PSE containing the new key without updating the directory attributes. This means that the verifier has no means to get a trustworthy version of the CA's old key and so verification fails.
この場合、カリフォルニアはディレクトリ属性をアップデートしないで新しいキーを含む検証のPSEを発行しました。 これが、検証にはCAの古いキーの信頼できるバージョンを得る手段が全くないことを意味するので、検証は失敗します。
Note that the failure is the CA operator's fault.
失敗がカリフォルニアのオペレータのせいであることに注意してください。
2.4.2.5 Failure of verification in case 7.
2.4.2.5 場合7における検証の失敗。
In this case the CA has issued the signer's certificate protected with the new key without updating the directory attributes. This means that the verifier has no means to get a trustworthy version of the CA's new key and so verification fails.
この場合、カリフォルニアは新しいキーでディレクトリ属性をアップデートしないで保護された署名者の証明書を発行しました。 これが、検証にはCAの新しいキーの信頼できるバージョンを得る手段が全くないことを意味するので、検証は失敗します。
Note that the failure is again the CA operator's fault.
失敗が再びカリフォルニアのオペレータのせいであることに注意してください。
2.4.3 Revocation - Change of CA key
2.4.3 取消し--カリフォルニアキーの変化
As we saw above the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks as the CA may have signed the CRL using a newer private key than the one that is within the user's PSE.
私たちが、証明書の検証がかつてより複雑になるのを上を見たとき、カリフォルニアはキーを変えることができます。 また、ユーザのPSEの中にあるものより新しい秘密鍵を使用することでカリフォルニアがCRLに署名したかもしれないので、取消しチェックに、これも本当です。
The analysis of the alternatives is as for certificate verification.
代替手段の分析は証明書検証に似ています。
3. Data Structures
3. データ構造
This section contains descriptions of the data structures required for PKI management messages. Section 4 describes constraints on their values and the sequence of events for each of the various PKI management operations. Section 5 describes how these may be encapsulated in various transport mechanisms.
このセクションはPKI管理メッセージに必要であるデータ構造の記述を含みます。 セクション4はそれぞれの様々なPKI管理操作のためにそれらの値とイベントの系列で規制について説明します。 セクション5はこれらが様々な移送機構でどうカプセル化されるかもしれないかを説明します。
3.1 Overall PKI Message
3.1 総合的なPKIメッセージ
All of the messages used in this specification for the purposes of PKI management use the following structure:
PKI管理の目的にこの仕様で使用されるメッセージのすべてが以下の構造を使用します:
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIMessage:、:= 系列ヘッダーPKIHeader、ボディーPKIBody、保護[0]PKIProtection OPTIONAL、extraCerts[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL
Adams & Farrell Standards Track [Page 19] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[19ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
The PKIHeader contains information which is common to many PKI messages.
PKIHeaderは多くのPKIメッセージに共通の情報を含んでいます。
The PKIBody contains message-specific information.
PKIBodyはメッセージ特殊情報を含んでいます。
The PKIProtection, when used, contains bits that protect the PKI message.
使用されると、PKIProtectionはPKIメッセージを保護するビットを含んでいます。
The extraCerts field can contain certificates that may be useful to the recipient. For example, this can be used by a CA or RA to present an end entity with certificates that it needs to verify its own new certificate (if, for example, the CA that issued the end entity's certificate is not a root CA for the end entity). Note that this field does not necessarily contain a certification path - the recipient may have to sort, select from, or otherwise process the extra certificates in order to use them.
extraCerts分野は受取人の役に立つかもしれない証明書を含むことができます。 例えば、カリフォルニアかRAが、証明書があるそれが確かめる必要がある終わりの実体にそれ自身の新しい証明書を提示するのにこれを使用できます(例えば、終わりの実体のために実体の証明書が根でない終わりにカリフォルニアを発行したカリフォルニアであるなら)。 この分野が必ず証明経路を含むというわけではないことに注意してください--受取人は、それらを使用するために付加的な証明書を分類しなければならないか、選び抜かなければならないか、またはそうでなければ、処理しなければならないかもしれません。
3.1.1 PKI Message Header
3.1.1 PKIメッセージヘッダー
All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope; however, if the PKI message is protected then this information is also protected (i.e., we make no assumption about secure transport).
すべてのPKIメッセージがアドレシングとトランザクション識別のための何らかのヘッダー情報を必要とします。 また、この情報のいくつかも輸送特有の封筒に存在するでしょう。 しかしながら、PKIメッセージが保護されるなら、また、この情報は保護されます(すなわち、私たちは安全な輸送に関する仮定を全くしません)。
The following data structure is used to contain this information:
以下のデータ構造はこの情報を含むのに使用されます:
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
PKIHeader:、:= SEQUENCE、pvno INTEGER ietf-version2(1)、送付者GeneralName--送付者受取人GeneralNameは特定します--、意図している受取人messageTime0GeneralizedTime OPTIONAL--このメッセージの生産を調節するのを特定する、(いつを使用するか、送付者--「適当」すなわちそれでも時間がある領収書で重要な) protectionAlgが1AlgorithmIdentifier OPTIONALであるつもりであったならそれが輸送であると信じています; アルゴリズムは保護ビットの計算にsenderKID2KeyIdentifier OPTIONALを使用しました、recipKID3KeyIdentifier OPTIONAL--特定のキーを特定するのは保護にtransactionID4OCTET STRING OPTIONALを使用しました--一回だけが反復操作による保護を提供するのに使用したトランザクションすなわち、これは同じコネになるでしょう--(対応する要求、応答、および確認はsenderNonce5OCTET STRING OPTIONALを通信させます、recipNonce6OCTET STRING OPTIONAL)を特定します、senderNonce
Adams & Farrell Standards Track [Page 20] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[20ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
-- このメッセージのクリエイターによって挿入されます。 recipNonceに、この意図している受取人はfreeText[7]PKIFreeText OPTIONALを通信させます--これが文脈特有の指示を示すのに使用されるかもしれないという以前に関連するメッセージに挿入された一回だけ(この分野は人間の消費で意図する)はgeneralInfo[8]SEQUENCE SIZE(1..MAX)OF InfoTypeAndValue OPTIONAL(これは文脈特殊情報を伝えるのに使用されるかもしれません)(人間の消費で主として意図しないこの分野)です。
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC 1766 language tag to indicate the language
-- of the contained text)
PKIFreeText:、:= SEQUENCE SIZE(1..MAX)OF UTF8String--UTF-8 Stringとしてコード化されたテキスト(注意: 各UTF8String SHOULD--含まれているテキストの言語を示すために1766年のRFC言語タグを含んでいます)
The pvno field is fixed (at one) for this version of this specification.
pvno分野はこの仕様のこのバージョンのために修理されています(1時に)。
The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be usable to verify the protection on the message. If nothing about the sender is known to the sending entity (e.g., in the init. req. message, where the end entity may not know its own Distinguished Name (DN), e-mail name, IP address, etc.), then the "sender" field MUST contain a "NULL" value; that is, the SEQUENCE OF relative distinguished names is of zero length. In such a case the senderKID field MUST hold an identifier (i.e., a reference number) which indicates to the receiver the appropriate shared secret information to use to verify the message.
送付者分野はPKIMessageの送付者の名前を含んでいます。 この名前(senderKIDであって、供給にされるに関連した)はメッセージで保護について確かめるのにおいて使用可能であるべきです。 送付者に関する何も送付実体に知られていないなら(例えば、イニットでは. reqメッセージは終わりの実体がそれ自身のDistinguished Name(DN)を知らないかもしれないところに名前、IPアドレスなどをメールします)、「送付者」分野は「ヌル」の値を含まなければなりません。 すなわち、SEQUENCE OFの相対的な分類名はゼロ・レングスのものです。 このような場合にはsenderKID分野はメッセージについて確かめるのに使用するのが適切である共有秘密キー情報を受信機に示す識別子(すなわち、参照番号)を保持しなければなりません。
The recipient field contains the name of the recipient of the PKIMessage. This name (in conjunction with recipKID, if supplied) should be usable to verify the protection on the message.
受取人分野はPKIMessageの受取人の名前を含んでいます。 この名前(recipKIDであって、供給にされるに関連した)はメッセージで保護について確かめるのにおいて使用可能であるべきです。
The protectionAlg field specifies the algorithm used to protect the message. If no protection bits are supplied (note that PKIProtection is OPTIONAL) then this field MUST be omitted; if protection bits are supplied then this field MUST be supplied.
protectionAlg分野はメッセージを保護するのに使用されるアルゴリズムを指定します。 ノー・プロテクションビットを供給するなら(PKIProtectionがOPTIONALであることに注意してください)、この分野を省略しなければなりません。 保護ビットを供給するなら、この野原を供給しなければなりません。
senderKID and recipKID are usable to indicate which keys have been used to protect the message (recipKID will normally only be required where protection of the message uses Diffie-Hellman (DH) keys).
どのキーがメッセージを保護するのに使用されたかを示すのにおいてsenderKIDとrecipKIDは使用可能です(通常、recipKIDがメッセージの保護がディフィー-ヘルマン(DH)キーを使用するところで必要であるだけでしょう)。
Adams & Farrell Standards Track [Page 21] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[21ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
The transactionID field within the message header MAY be used to allow the recipient of a response message to correlate this with a previously issued request. For example, in the case of an RA there may be many requests "outstanding" at a given moment.
メッセージヘッダーの中のtransactionID分野は、応答メッセージの受取人が以前に発行された要求でこれを関連させるのを許容するのに使用されるかもしれません。 例えば、RAの場合には、与えられた瞬間に「傑出している」多くの要求があるかもしれません。
The senderNonce and recipNonce fields protect the PKIMessage against replay attacks.
senderNonceとrecipNonce分野は反射攻撃に対してPKIMessageを保護します。
The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct their local time to be consistent with the time on a central system.
messageTime分野は送付者がメッセージを作成した時を含んでいます。 これは、主要なシステムの上に時間がある状態で終わりの実体が一貫しているように彼らの現地時間を修正するのを許容するために役に立つかもしれません。
The freeText field may be used to send a human-readable message to the recipient (in any number of languages). The first language used in this sequence indicates the desired language for replies.
freeText分野は、受取人(いろいろな言語の)に人間読み込み可能なメッセージを送るのに使用されるかもしれません。 この系列に使用される母国語は回答のために必要な言語を示します。
The generalInfo field may be used to send machine-processable additional data to the recipient.
generalInfo分野は、マシン-「プロセス-可能」の追加データを受取人に送るのに使用されるかもしれません。
3.1.2 PKI Message Body
3.1.2 PKIメッセージボディー
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
-- the PKCS #10 certification request (see [PKCS10])
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Response
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
conf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent --Error Message
}
PKIBody:、:= 選択{ -- メッセージ特有のボディー要素不-[0]CertReqMessages--初期設定Request ip[1]CertRepMessage--初期設定Response cr[2]CertReqMessages--証明Request cp[3]CertRepMessage--証明Response p10cr[4]CertificationRequest(--PKCS#10Cert)。 Req。 -- PKCS#10証明要求([PKCS10]を見る)popdecc[5]POPODecKeyChallContent--Challenge popdecr[6]POPODecKeyRespContentを飛び出させてください--Response kur[7]CertReqMessagesを飛び出させてください--主要なUpdate Request kup[8]CertRepMessage--主要なUpdate Response krr[9]CertReqMessages--主要なRecovery Request krp[10]KeyRecRepContent--主要なRecovery Response rr[11]RevReqContent--取消しRequest rp[12]RevRepContent--取消しResponse ccr[13]CertReqMessages--交差している本命。 ccp[14]CertRepMessageを要求してください--交差している本命。 応答ckuann[15]CAKeyUpdAnnContent--カリフォルニアKey Updateアンcann[16]CertAnnContent--Certificateアンrann[17]RevAnnContent--Revocationアンcrlann[18]CRLAnnContent、--CRL Announcement conf[19]PKIConfirmContent--確認は[20] NestedMessageContent--入れ子にされたMessage genm[21]GenMsgContent--一般教書genp[22]GenRepContent--Response ErrorMsgContent誤り[23]司令官--誤りMessageを入れ子にしました。}
Adams & Farrell Standards Track [Page 22] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[22ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
The specific types are described in Section 3.3 below.
特定のタイプは以下のセクション3.3で説明されます。
3.1.3 PKI Message Protection
3.1.3 PKIメッセージ保護
Some PKI messages will be protected for integrity. (Note that if an asymmetric algorithm is used to protect a message and the relevant public component has been certified already, then the origin of message can also be authenticated. On the other hand, if the public component is uncertified then the message origin cannot be automatically authenticated, but may be authenticated via out-of-band means.)
いくつかのPKIメッセージが保全のために保護されるでしょう。 (また、非対称のアルゴリズムがメッセージを保護するのに使用されて、関連公共のコンポーネントが既に公認されたならメッセージの発生源を認証できることに注意してください。 他方では、公共のコンポーネントが非公認されるなら、メッセージ発生源は、自動的に認証できませんが、バンドで出ている手段で認証されるかもしれません。)
When protection is applied the following structure is used:
保護が適用されているとき、以下の構造は使用されています:
PKIProtection ::= BIT STRING
PKIProtection:、:= ビット列
The input to the calculation of PKIProtection is the DER encoding of the following data structure:
PKIProtectionの計算への入力は以下のデータ構造のDERコード化です:
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart:、:= 系列ヘッダーPKIHeader、ボディーPKIBody
There MAY be cases in which the PKIProtection BIT STRING is deliberately not used to protect a message (i.e., this OPTIONAL field is omitted) because other protection, external to PKIX, will instead be applied. Such a choice is explicitly allowed in this specification. Examples of such external protection include PKCS #7 [PKCS7] and Security Multiparts [RFC1847] encapsulation of the PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the relevant PKIHeader information is securely carried in the external mechanism); specification of external protection using PKCS #7 will be provided in a separate document. It is noted, however, that many such external mechanisms require that the end entity already possesses a public-key certificate, and/or a unique Distinguished Name, and/or other such infrastructure-related information. Thus, they may not be appropriate for initial registration, key-recovery, or any other process with "boot-strapping" characteristics. For those cases it may be necessary that the PKIProtection parameter be used. In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent.
PKIXに外部であることの他の保護が代わりに適用されるのでPKIProtection BIT STRINGがメッセージを保護するのに故意に使用されない(すなわち、このOPTIONAL分野は省略されます)場合があるかもしれません。 そのような選択はこの仕様で明らかに許されています。 または、そのような外部の保護に関する例がPKIMessageのPKCS#7[PKCS7]とSecurity Multiparts[RFC1847]のカプセル化を含んでいる、(単にPKIBody(CHOICEタグを省略する)、関連PKIHeader情報が外部のメカニズムでしっかりと運ばれるなら。 PKCS#7を使用する外部の保護の仕様を別々のドキュメントに提供するでしょう。 しかしながら、そのような多くの外部のメカニズムが、終わりの実体には公開鍵証明書、ユニークなDistinguished Name、そして/または、他のそのようなインフラストラクチャ関連の情報が既にあるのを必要とすることに注意されます。 したがって、新規登録、キーリカバリー、またはいかなる他のプロセスにも、それらは特性が「摘み皮」であるのに適切でないかもしれません。 それらのケースに、PKIProtectionパラメタが使用されるのが必要であるかもしれません。 将来、外部のメカニズムであるときに、/が変更されているなら、シナリオ、PKIProtectionの摘み皮の使用を収容するのはまれであるか実在しなくなるかもしれません。
Depending on the circumstances the PKIProtection bits may contain a Message Authentication Code (MAC) or signature. Only the following cases can occur:
事情によって、PKIProtectionビットはメッセージ立証コード(MAC)か署名を含むかもしれません。 以下のケースしか現れることができません:
Adams & Farrell Standards Track [Page 23] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[23ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
- shared secret information
- 共有秘密キー情報
In this case the sender and recipient share secret information (established via out-of-band means or from a previous PKI management operation). PKIProtection will contain a MAC value and the protectionAlg will be the following:
この場合、送付者と受取人は秘密の情報(バンドで出ている手段か前のPKI管理操作から設立される)を共有します。 PKIProtectionはMAC値を含むでしょう、そして、protectionAlgは以下になるでしょう:
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
PasswordBasedMac:、:= オブジェクト識別子--、1 2、840、113533、7、66 13、PBMParameter:、:= SEQUENCE、塩のOCTET STRING、owf AlgorithmIdentifier--One-道のFunction(推薦されたSHA-1)iterationCount INTEGERのためのAlgId--OWFが適用されたmac AlgorithmIdentifierであるという回の数--、MAC AlgId(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
In the above protectionAlg the salt value is appended to the shared
secret input. The OWF is then applied iterationCount times, where the
salted secret is the input to the first iteration and, for each
successive iteration, the input is set to be the output of the
previous iteration. The output of the final iteration (called
"BASEKEY" for ease of reference, with a size of "H") is what is used
to form the symmetric key. If the MAC algorithm requires a K-bit key
and K <= H, then the most significant K bits of BASEKEY are used. If
K > H, then all of BASEKEY is used for the most significant H bits of
the key, OWF("1" || BASEKEY) is used for the next most significant H
bits of the key, OWF("2" || BASEKEY) is used for the next most
significant H bits of the key, and so on, until all K bits have been
derived. [Here "N" is the ASCII byte encoding the number N and "||"
represents concatenation.]
上のprotectionAlgでは、塩の値を共有秘密キー入力に追加します。 次に、OWFは適用されたiterationCount回です、辛辣の秘密が最初の繰り返しへの入力であり、入力が前の繰り返しの出力であるようにそれぞれの連続した繰り返しにおいて設定されるところで。 最終的な繰り返し(参照する場合に便利なように「H」のサイズで"BASEKEY"と呼ばれる)の出力は対称鍵を形成するのに使用されることです。 MACアルゴリズムがK-ビットキーを必要として、K<がHと等しいなら、BASEKEYの最も重要なKビットは使用されています。 BASEKEYのすべてがK>Hであるならキーの最も重要なHビットに使用されます、OWF、(「1インチ| | BASEKEY) キーの次の最も重要なHビットに使用される、OWF、(「2インチ| | BASEKEY) すべてのKビットが引き出されるまでキーの次の最も重要なHビットなどに使用される、」 そして、「[「N」がここのNo.Nをコード化するASCIIバイトである、」 | | 」 連結を表す、]
- DH key pairs
- DH主要な組
Where the sender and receiver possess Diffie-Hellman certificates with compatible DH parameters, then in order to protect the message the end entity must generate a symmetric key based on its private DH key value and the DH public key of the recipient of the PKI message. PKIProtection will contain a MAC value keyed with this derived symmetric key and the protectionAlg will be the following:
次に、送付者と受信機にはディフィー-ヘルマン証明書が終わりの実体が個人的なDHキー値とPKIメッセージの受取人のDH公開鍵に基づく対称鍵を生成しなければならないメッセージを保護するためにコンパチブルDHパラメタと共にあるところで。 PKIProtectionはこの派生している対称鍵で合わせられたMAC値を含むでしょう、そして、protectionAlgは以下になるでしょう:
Adams & Farrell Standards Track [Page 24] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[24ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBasedMac:、:= オブジェクト識別子--{1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBMParameter:、:= SEQUENCE、owf AlgorithmIdentifier--One-道のFunction(推薦されたSHA-1)mac AlgorithmIdentifierのためのAlgId--MAC AlgId(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
In the above protectionAlg OWF is applied to the result of the
Diffie-Hellman computation. The OWF output (called "BASEKEY" for ease
of reference, with a size of "H") is what is used to form the
symmetric key. If the MAC algorithm requires a K-bit key and K <= H,
then the most significant K bits of BASEKEY are used. If K > H, then
all of BASEKEY is used for the most significant H bits of the key,
OWF("1" || BASEKEY) is used for the next most significant H bits of
the key, OWF("2" || BASEKEY) is used for the next most significant H
bits of the key, and so on, until all K bits have been derived. [Here
"N" is the ASCII byte encoding the number N and "||" represents
concatenation.]
上記では、protectionAlg OWFはディフィー-ヘルマンの計算の結果に適用されます。 OWF出力(参照する場合に便利なように「H」のサイズで"BASEKEY"と呼ばれる)は対称鍵を形成するのに使用されることです。 MACアルゴリズムがK-ビットキーを必要として、K<がHと等しいなら、BASEKEYの最も重要なKビットは使用されています。 BASEKEYのすべてがK>Hであるならキーの最も重要なHビットに使用されます、OWF、(「1インチ| | BASEKEY) キーの次の最も重要なHビットに使用される、OWF、(「2インチ| | BASEKEY) すべてのKビットが引き出されるまでキーの次の最も重要なHビットなどに使用される、」 そして、「[「N」がここのNo.Nをコード化するASCIIバイトである、」 | | 」 連結を表す、]
- signature
- 署名
Where the sender possesses a signature key pair it may simply sign the PKI message. PKIProtection will contain the signature value and the protectionAlg will be an AlgorithmIdentifier for a digital signature (e.g., md5WithRSAEncryption or dsaWithSha-1).
送付者には署名主要な組があるところでは、それは単にPKIメッセージに署名するかもしれません。 PKIProtectionは署名値を含むでしょう、そして、protectionAlgはデジタル署名(例えば、md5WithRSAEncryptionかdsaWithSha-1)のためにAlgorithmIdentifierになるでしょう。
- multiple protection
- 多重防護
In cases where an end entity sends a protected PKI message to an RA, the RA MAY forward that message to a CA, attaching its own protection (which MAY be a MAC or a signature, depending on the information and certificates shared between the RA and the CA). This is accomplished by nesting the entire message sent by the end entity within a new PKI message. The structure used is as follows.
終わりの実体が保護されたPKIメッセージをRAに送る場合では、RA MAYはそのメッセージをカリフォルニアに転送します、それ自身の保護(RAとカリフォルニアの間で共有された情報と証明書によって、MACか署名であるかもしれない)を付けて。 これは、新しいPKIメッセージの中で終わりの実体によって送られた全体のメッセージを入れ子にすることによって、達成されます。 使用される構造は以下の通りです。
NestedMessageContent ::= PKIMessage
NestedMessageContent:、:= PKIMessage
3.2 Common Data Structures
3.2 一般的なデータ構造
Before specifying the specific types that may be placed in a PKIBody we define some data structures that are used in more than one case.
PKIBodyに置かれるかもしれない特定のタイプを指定する前に、私たちはより多くのある場合に使用されるいくつかのデータ構造を定義します。
Adams & Farrell Standards Track [Page 25] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[25ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.2.1 Requested Certificate Contents
3.2.1 要求された証明書コンテンツ
Various PKI management messages require that the originator of the message indicate some of the fields that are required to be present in a certificate. The CertTemplate structure allows an end entity or RA to specify as much as it wishes about the certificate it requires. CertTemplate is identical to a Certificate but with all fields optional.
様々なPKI管理メッセージは、メッセージの創始者が証明書に存在しているのに必要である分野のいくつかを示すのを必要とします。 CertTemplate構造で、終わりの実体かRAがそれが必要とする証明書に関して願っているほど指定できます。 すべての分野のために、CertTemplateはCertificateと同じですが、任意です。
Note that even if the originator completely specifies the contents of a certificate it requires, a CA is free to modify fields within the certificate actually issued. If the modified certificate is unacceptable to the requester, the Confirmation message may be withheld, or an Error Message may be sent (with a PKIStatus of "rejection").
創始者がそれが必要とする証明書のコンテンツを完全に指定しても、カリフォルニアが実際に発行された証明書の中に自由に分野を変更できることに注意してください。 変更された証明書がリクエスタに容認できないなら、Confirmationメッセージを差し控えるかもしれませんか、またはError Messageを送るかもしれません(「拒絶」のPKIStatusと共に)。
See [CRMF] for CertTemplate syntax.
CertTemplate構文に関して[CRMF]を見てください。
3.2.2 Encrypted Values
3.2.2 暗号化された値
Where encrypted values (restricted, in this specification, to be either private keys or certificates) are sent in PKI messages the EncryptedValue data structure is used.
PKIメッセージで暗号化された値(この仕様では、秘密鍵か証明書のどちらかになるように、制限される)を送るところでは、EncryptedValueデータ構造は使用されています。
See [CRMF] for EncryptedValue syntax.
EncryptedValue構文に関して[CRMF]を見てください。
Use of this data structure requires that the creator and intended recipient respectively be able to encrypt and decrypt. Typically, this will mean that the sender and recipient have, or are able to generate, a shared secret key.
このデータ構造の使用は、クリエイターと意図している受取人がそれぞれできるのを必要とします。暗号化して、解読するために。 通常、これは送付者と受取人が持っているか、または生成することができる平均、共有された秘密鍵がそうするでしょう。
If the recipient of the PKIMessage already possesses a private key usable for decryption, then the encSymmKey field MAY contain a session key encrypted using the recipient's public key.
PKIMessageの受取人に復号化に、使用可能な秘密鍵が既にあるなら、encSymmKey分野は受取人の公開鍵を使用することで暗号化されたセッションキーを含むかもしれません。
3.2.3 Status codes and Failure Information for PKI messages
3.2.3 PKIメッセージのためのステータスコードとFailure情報
All response messages will include some status information. The following values are defined.
すべての応答メッセージが何らかの状態情報を含むでしょう。 以下の値は定義されます。
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
PKIStatus:、:= INTEGER、あなたはまさにgrantedWithMods(1)のために尋ねたものを得ました--あなたが何かあなたが求めたもののようなものを得たという(0)を与える、--リクエスタは違いの拒絶(2)を確かめるのに原因となります--あなたはそれを得ません、メッセージのほかの場所の詳しい情報
Adams & Farrell Standards Track [Page 26] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[26ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- the key update request message
}
要求身体の部分がまだ処理されていないという(3)を待って、より多くの後のrevocationWarning(4)を聞くと予想してください--このメッセージは取消しがそうであるという警告--差し迫っているrevocationNotification(5)--取消しには起こったkeyUpdateWarning(6)--指定されたoldCertIdのために既に行われたアップデート--主要なアップデート要求メッセージがあるという通知を含んでいます。
Responders may use the following syntax to provide more information about failure cases.
応答者は、失敗事件に関する詳しい情報を提供するのに以下の構文を使用するかもしれません。
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (used for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
PKIFailureInfo:、:= ビット列{ -- 以来、私たちは1つ以上の方法に失敗できます! -- より多くのコードが/であるなら必要であると将来、加えられるかもしれません。badAlg(0)--認識されていないかサポートされないAlgorithm Identifier badMessageCheck(1)--保全チェックが失敗した、(例えば、署名が確かめなかった、)、badRequest(2)--トランザクションは、badTimeが(3)であると許可もしませんでしたし、サポートもしませんでした--messageTimeが地方の方針badCertId(4)によって定義されるようにシステム時間の十分近くにありませんでした; 提出されたデータが間違った形式wrongAuthority(6)を持っているという権威が要求で示したbadDataFormat(5)が異なっている提供された評価基準を合わせているのを証明書を全く見つけることができなかった、リクエスタの--応答トークンincorrectData(7)を作成する1つ--データが不正確な(公証人サービスのために、使用される)missingTimeStamp(8)である(タイムスタンプであるときに、そこ(方針で)にあるべきであるのを除いて、消えるのは、badPOP(9)です)、所有物の証拠は失敗しました。} PKIStatusInfo:、:= 系列状態PKIStatus、statusString PKIFreeText OPTIONAL、failInfo PKIFailureInfo OPTIONAL
Adams & Farrell Standards Track [Page 27] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[27ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.2.4 Certificate Identification
3.2.4 証明書識別
In order to identify particular certificates the CertId data structure is used.
特定の証明書を特定するために、CertIdデータ構造は使用されています。
See [CRMF] for CertId syntax.
CertId構文に関して[CRMF]を見てください。
3.2.5 "Out-of-band" root CA public key
3.2.5 「バンドの外」という根のカリフォルニア公開鍵
Each root CA must be able to publish its current public key via some "out-of-band" means. While such mechanisms are beyond the scope of this document, we define data structures which can support such mechanisms.
各根のカリフォルニアは「バンドの外」といういくつかの手段で現在の公開鍵を発行できなければなりません。 そのようなメカニズムがこのドキュメントの範囲を超えている間、私たちはそのようなメカニズムをサポートできるデータ構造を定義します。
There are generally two methods available: either the CA directly publishes its self-signed certificate; or this information is available via the Directory (or equivalent) and the CA publishes a hash of this value to allow verification of its integrity before use.
一般に、利用可能な2つのメソッドがあります: カリフォルニアは直接自己署名入りの証書を発表します。 または、この情報は、ディレクトリを通して利用可能、そして、(同等)です、そして、カリフォルニアは使用の前に保全の検証を許すためにこの価値のハッシュを発行します。
OOBCert ::= Certificate
OOBCert:、:= 証明書
The fields within this certificate are restricted as follows:
この証明書の中の分野は以下の通り制限されます:
- The certificate MUST be self-signed (i.e., the signature must be
verifiable using the SubjectPublicKeyInfo field);
- The subject and issuer fields MUST be identical;
- If the subject field is NULL then both subjectAltNames and
issuerAltNames extensions MUST be present and have exactly the same
value;
- The values of all other extensions must be suitable for a self-
signed certificate (e.g., key identifiers for subject and issuer
must be the same).
- 自己に証明書に署名しなければなりません(すなわち、署名はSubjectPublicKeyInfo分野を使用することで証明可能であるに違いありません)。 - 対象と発行人分野は同じであるに違いありません。 - 対象の分野がNULLであるなら、subjectAltNamesとissuerAltNames拡張子の両方が、存在していて、まさに同じ値を持たなければなりません。 - 他のすべての拡大の値は自己署名入りの証書に適しているに違いありません(例えば、対象と発行人に、主要な識別子は同じであるに違いありません)。
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over the self-signed
-- certificate with the identifier certID.
}
OOBCertHash:、:= 系列hashAlg[0]AlgorithmIdentifier OPTIONAL、certId[1]CertId OPTIONAL、hashVal BIT STRING--自己によって署名される--識別子でcertIDを証明する上でhashValは計算されます。
The intention of the hash value is that anyone who has securely received the hash value (via the out-of-band means) can verify a self- signed certificate for that CA.
ハッシュ値の意志はしっかりと、ハッシュ値(バンドで出ている手段を通した)を受けただれでもそのカリフォルニアのための自己署名入りの証書について確かめることができるということです。
Adams & Farrell Standards Track [Page 28] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[28ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.2.6 Archive Options
3.2.6 アーカイブオプション
Requesters may indicate that they wish the PKI to archive a private key value using the PKIArchiveOptions structure
リクエスタは、PKIに秘密鍵値を格納してPKIArchiveOptions構造を使用することで欲しいのを示すかもしれません。
See [CRMF] for PKIArchiveOptions syntax.
PKIArchiveOptions構文に関して[CRMF]を見てください。
3.2.7 Publication Information
3.2.7 公表情報
Requesters may indicate that they wish the PKI to publish a certificate using the PKIPublicationInfo structure.
リクエスタは、PKIに証明書を発表してPKIPublicationInfo構造を使用することで欲しいのを示すかもしれません。
See [CRMF] for PKIPublicationInfo syntax.
PKIPublicationInfo構文に関して[CRMF]を見てください。
3.2.8 Proof-of-Possession Structures
3.2、0.4度の所有物、構造
If the certification request is for a signing key pair (i.e., a request for a verification certificate), then the proof of possession of the private signing key is demonstrated through use of the POPOSigningKey structure.
証明要求が署名重要組(すなわち、検証証明書に関する要求)のためのものであるなら、個人的な署名キーの所持の証拠はPOPOSigningKey構造の使用で示されます。
See [CRMF] for POPOSigningKey syntax, but note that POPOSigningKeyInput has the following semantic stipulations in this specification.
POPOSigningKey構文に関して[CRMF]を見なさい、ただし、POPOSigningKeyInputがこの仕様に以下の意味約款を持っていることに注意してください。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- from PKIHeader (used only if an authenticated identity
-- has been established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate))
publicKeyMAC [1] PKMACValue
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- (using the protectionAlg AlgId from PKIHeader) on the
-- DER-encoded value of publicKey
},
publicKey SubjectPublicKeyInfo -- from CertTemplate
}
POPOSigningKeyInput:、:= 系列authInfo CHOICE、PKIHeaderからの送付者[0]GeneralName、(認証されたアイデンティティ(どんな認証されたGeneralNameも現在存在しないなら使用されて、--送付者;publicKeyMACがパスワードベースのMACを含んでいるので、送付者(例えば、aからのDN--以前に、発行されるのと現在の有効な証明書)publicKeyMAC[1]PKMACValueのために設立されました)(PKIHeaderからprotectionAlg AlgIdを使用して)である場合にだけ使用される、オンである、--、publicKeyのDERによってコード化された値、CertTemplateからのpublicKey SubjectPublicKeyInfo
On the other hand, if the certification request is for an encryption key pair (i.e., a request for an encryption certificate), then the proof of possession of the private decryption key may be demonstrated in one of three ways.
他方では、証明要求が暗号化主要な組(すなわち、暗号化証明書に関する要求)のためのものであるなら、個人的な復号化キーの所持の証拠は3つの方法の1つで示されるかもしれません。
1) By the inclusion of the private key (encrypted) in the
CertRequest (in the PKIArchiveOptions control structure).
1) CertRequest(PKIArchiveOptions制御構造の)での秘密鍵(暗号化される)の包含で。
Adams & Farrell Standards Track [Page 29] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[29ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
2) By having the CA return not the certificate, but an encrypted
certificate (i.e., the certificate encrypted under a randomly-
generated symmetric key, and the symmetric key encrypted under
the public key for which the certification request is being
made) -- this is the "indirect" method mentioned previously in
Section 2.3.2. The end entity proves knowledge of the private
decryption key to the CA by MACing the PKIConfirm message using
a key derived from this symmetric key. [Note that if more than
one CertReqMsg is included in the PKIMessage, then the CA uses
a different symmetric key for each CertReqMsg and the MAC uses
a key derived from the concatenation of all these keys.] The
MACing procedure uses the PasswordBasedMac AlgId defined in
Section 3.1.
2) カリフォルニアに証明書ではなく、暗号化された証明書(すなわち、手当たりしだいに発生している対称鍵、および証明要求がされている公開鍵の下で暗号化された対称鍵の下で暗号化された証明書)を返させることによって -- これは以前にセクション2.3.2で言及した「間接的な」メソッドです。 終わりの実体は、MACingによるカリフォルニアの個人的な復号化キーに関する知識がPKIConfirmメッセージであるとこの対称鍵から得られたキーを使用することで立証します。 [1CertReqMsgがPKIMessageに含まれているならカリフォルニアが各CertReqMsgに異なった対称鍵を使用して、MACがこれらのすべてのキーの連結から得られたキーを使用することに注意してください。] MACing手順はセクション3.1で定義されたPasswordBasedMac AlgIdを使用します。
3) By having the end entity engage in a challenge-response
protocol (using the messages POPODecKeyChall and
POPODecKeyResp; see below) between CertReqMessages and
CertRepMessage -- this is the "direct" method mentioned
previously in Section 2.3.2. [This method would typically be
used in an environment in which an RA verifies POP and then
makes a certification request to the CA on behalf of the end
entity. In such a scenario, the CA trusts the RA to have done
POP correctly before the RA requests a certificate for the end
entity.] The complete protocol then looks as follows (note
that req' does not necessarily encapsulate req as a nested
message):
3) 終わりの実体をチャレンジレスポンスプロトコルに従事させる、(メッセージのPOPODecKeyChallとPOPODecKeyRespを使用します。 見る、)、以下にCertReqMessagesとCertRepMessage--これは以前にセクション2.3.2で言及した「ダイレクトな」メソッドです。 [このメソッドはRAが終わりの実体を代表してカリフォルニアにPOPについて確かめて、次に証明要求をする環境で通常使用されるでしょう。 そのようなシナリオでは、RAが終わりの実体のための証明書を要求する前にカリフォルニアは、RAが正しくPOPをしたと信じます。] '次に、完全なプロトコルが以下の通りに見える、(そのreqに注意してください、'、必ず入れ子にされたメッセージとしてreqをカプセル化するというわけではない、)、:
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- rep -----
---- conf --->
EE RAカリフォルニア---- req----><。--- chall--- ---- resp--->。---- 'req'---><。--- レップ----- ---- conf---><。--- レップ----- ---- conf--->。
This protocol is obviously much longer than the 3-way exchange given in choice (2) above, but allows a local Registration Authority to be involved and has the property that the certificate itself is not actually created until the proof of possession is complete.
このプロトコルは、3ウェイ交換より明らかにはるかに長い間、選択で(2) 上に与えますが、地方のRegistration Authorityがかかわるのを許容して、所有物の証拠が完全になるまで作成されて、証明書自体が実際にそうでない特性を持っています。
If the cert. request is for a key agreement key (KAK) pair, then the POP can use any of the 3 ways described above for enc. key pairs, with the following changes: (1) the parenthetical text of bullet 2) is replaced with "(i.e., the certificate encrypted under the symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)"; (2) the first
本命であるなら. 要求は主要な協定主要な(KAK)組のためのものです、次に、POPは上にenc主要な組述べられた3つの方法のどれかを使用できます、以下の変化で: (1) 弾丸2)の挿入句のテキストを「(すなわち、CAの個人的なKAKから得られた対称鍵の下で暗号化された証明書と証明要求がされている公開鍵)」に取り替えます。 (2) 1番目
Adams & Farrell Standards Track [Page 30] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[30ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
parenthetical text of the challenge field of "Challenge" below is replaced with "(using PreferredSymmAlg (see Appendix B6) and a symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)". Alternatively, the POP can use the POPOSigningKey structure given in [CRMF] (where the alg field is DHBasedMAC and the signature field is the MAC) as a fourth alternative for demonstrating POP if the CA already has a D-H certificate that is known to the EE.
以下の「挑戦」の挑戦分野の挿入句のテキストを「(PreferredSymmAlg(Appendix B6を見る)と対称鍵を使用して、CAの個人的なKAKから派生する証明要求がされている公開鍵)」に取り替えます。 あるいはまた、POPは、カリフォルニアにEEにおいて知られているD-H証明書が既にあるならPOPのデモをするのに4分の1に代替として[CRMF](alg分野がDHBasedMACであり、署名分野がMACであるところ)で与えられたPOPOSigningKey構造を使用できます。
The challenge-response messages for proof of possession of a private decryption key are specified as follows (see [MvOV97, p.404] for details). Note that this challenge-response exchange is associated with the preceding cert. request message (and subsequent cert. response and confirmation messages) by the nonces used in the PKIHeader and by the protection (MACing or signing) applied to the PKIMessage.
個人的な復号化キーの所持の証拠へのチャレンジレスポンスメッセージは以下の通り(詳細に関して見ます[MvOV97、p.404])指定されます。 このチャレンジレスポンス交換が前の本命に関連していることに注意してください。PKIHeaderで使用される一回だけと保護(MACingか署名)による要求メッセージ(そして、その後の本命応答と確認メッセージ)はPKIMessageに申し込まれました。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
POPODecKeyChallContent:、:= 中、SEQUENCE OF Challenge、暗号化の主要な証明要求あたりの1つのChallenge、(--、これらの要求としてのオーダーがCertReqMessagesで見える同じこと)
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
以下に挑戦してください:= 系列owf AlgorithmIdentifier OPTIONAL--POPODecKeyChallContentで最初のChallengeで--いずれでも省略されるかもしれない;その後のChallengeを寄贈することでなければならない、(省略される、--、次にすぐに前のChallengeで使用されるowfはそうです--使用されるために). OCTET STRING--一方向関数(owf)をaに適用するという結果--手当たりしだいに発生しているINTEGER、A.を目撃してください、[注意、aそんなに異なる--、INTEGER MUST、各Challenge] 挑戦OCTET STRINGには、使用されてください--、暗号化(公開鍵、どれ、本命。 -- 要求をしています。) Rand(底ならし革: : {の--int INTEGER----手当たりしだいに発生しているINTEGER A(above)(送付者GeneralName)--送付者=SEQUENCEの名前(PKIHeaderに含まれているように))。(そこでは、Randが指定されます)。
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
POPODecKeyRespContent:、:= 中、SEQUENCE OF INTEGER、暗号化の主要な証明要求あたりの1つのINTEGER、(--、これらの要求としてのオーダーがCertReqMessagesで見える同じこと) --、(above)が送付者に返されるINTEGER Aを検索する、--対応するChallenge。
Adams & Farrell Standards Track [Page 31] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[31ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.3 Operation-Specific Data Structures
3.3 操作特有のデータ構造
3.3.1 Initialization Request
3.3.1 初期設定要求
An Initialization request message contains as the PKIBody an CertReqMessages data structure which specifies the requested certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each certificate requested (see Appendix B profiles for further information). This message is intended to be used for entities first initializing into the PKI.
初期設定要求メッセージはPKIBodyとして要求された証明書を指定するCertReqMessagesデータ構造を含んでいます。 SubjectPublicKeyInfo、KeyId、およびValidityは通常、要求された各証明書に供給されるかもしれないテンプレート野原(詳細のためのAppendix Bプロフィールを見る)です。 PKIに初期設定しながら、最初に実体にこのメッセージが使用されることを意図します。
See [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関して[CRMF]を見てください。
3.3.2 Initialization Response
3.3.2 初期設定応答
An Initialization response message contains as the PKIBody an CertRepMessage data structure which has for each certificate requested a PKIStatusInfo field, a subject certificate, and possibly a private key (normally encrypted with a session key, which is itself encrypted with the protocolEncKey).
各証明書がPKIStatusInfo分野、対象の証明書、およびことによると秘密鍵(通常、protocolEncKeyと共に暗号化されるセッションキーで暗号化される)を要求したので、初期設定応答メッセージはPKIBodyとしてそうしたCertRepMessageデータ構造を含んでいます。
See Section 3.3.4 for CertRepMessage syntax. Note that if the PKI Message Protection is "shared secret information" (see Section 3.1.3), then any certificate transported in the caPubs field may be directly trusted as a root CA certificate by the initiator.
CertRepMessage構文に関してセクション3.3.4を見てください。 caPubs分野で輸送されたどんな証明書もPKI Message Protectionが「共有秘密キー情報」(セクション3.1.3を見る)であるなら創始者による根のカリフォルニア証明書として直接信じられるかもしれないことに注意してください。
3.3.3 Registration/Certification Request
3.3.3 登録/証明要求
A Registration/Certification request message contains as the PKIBody a CertReqMessages data structure which specifies the requested certificates. This message is intended to be used for existing PKI entities who wish to obtain additional certificates.
Registration/証明要求メッセージはPKIBodyとして要求された証明書を指定するCertReqMessagesデータ構造を含んでいます。 追加証明書を入手することを願っている既存のPKI実体にこのメッセージが使用されることを意図します。
See [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関して[CRMF]を見てください。
Alternatively, the PKIBody MAY be a CertificationRequest (this structure is fully specified by the ASN.1 structure CertificationRequest given in [PKCS10]). This structure may be required for certificate requests for signing key pairs when interoperation with legacy systems is desired, but its use is strongly discouraged whenever not absolutely necessary.
あるいはまた、PKIBodyはCertificationRequestであるかもしれません(この構造は[PKCS10]で与えられているASN.1構造CertificationRequestによって完全に指定されます)。 レガシーシステムがあるinteroperationが望まれているとき、この構造が主要な組に署名するのを求める証明書要求に必要であるかもしれませんが、絶対に必要でないときはいつも、使用は強くお勧めできないです。
Adams & Farrell Standards Track [Page 32] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[32ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.3.4 Registration/Certification Response
3.3.4 登録/証明応答
A registration response message contains as the PKIBody a CertRepMessage data structure which has a status value for each certificate requested, and optionally has a CA public key, failure information, a subject certificate, and an encrypted private key.
登録応答メッセージは、PKIBodyとして各証明書のための状態値を要求するCertRepMessageデータ構造を含んでいて、任意にカリフォルニア公開鍵、失敗情報、対象の証明書、および暗号化された秘密鍵を持っています。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage:、:= 系列caPubs[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL、応答SEQUENCE OF CertResponse
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertResponse:、:= 系列対応するこの応答が要求するマッチへのcertReqId INTEGER、(値--certReqIdが中で指定されないなら-1に、使用されることになっていてください、--、対応する要求) 状態PKIStatusInfo、certifiedKeyPair CertifiedKeyPair OPTIONAL、CertReqMsgのregInfoのための定義されたイド-regInfo-asciiPairs OCTET STRING[CRMF]への類似のrspInfo OCTET STRING OPTIONAL
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair:、:= 系列privateKey[0]EncryptedValue任意の、そして、publicationInfo[1]PKIPublicationInfo任意のcertOrEncCert CertOrEncCert
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert:、:= 選択証明書[0]証明書、encryptedCert[1]EncryptedValue
Only one of the failInfo (in PKIStatusInfo) and certificate (in CertifiedKeyPair) fields can be present in each CertResponse (depending on the status). For some status values (e.g., waiting) neither of the optional fields will be present.
failInfo(PKIStatusInfoの)と証明書(CertifiedKeyPairの)分野の1つだけが各CertResponseに存在している場合があります(状態によって)。 いくつかの状態値(例えば、待ち)のために、任意の分野のどちらも存在しないでしょう。
Given an EncryptedCert and the relevant decryption key the certificate may be obtained. The purpose of this is to allow a CA to return the value of a certificate, but with the constraint that only the intended recipient can obtain the actual certificate. The benefit of this approach is that a CA may reply with a certificate even in the absence of a proof that the requester is the end entity which can use the relevant private key (note that the proof is not obtained
EncryptedCertと関連復号化キーを考えて、証明書を入手するかもしれません。 この目的はカリフォルニアが証明書の値を返しますが、意図している受取人だけがそうすることができるという規制で実際の証明書を入手するのを許容することです。 このアプローチの恩恵がカリフォルニアがリクエスタが関連秘密鍵を使用できる終わりの実体であるという証拠がないときでさえ証明書で返答するかもしれないということである、(証拠が得られないことに注意してください。
Adams & Farrell Standards Track [Page 33] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[33ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
until the PKIConfirm message is received by the CA). Thus the CA will not have to revoke that certificate in the event that something goes wrong with the proof of possession.
PKIConfirmメッセージがカリフォルニアによって受け取られる、) したがって、何かが所有物の証拠で支障をきたすと、カリフォルニアはその証明書を取り消す必要はないでしょう。
3.3.5 Key update request content
3.3.5 主要な更新要求内容
For key update requests the CertReqMessages syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each key to be updated. This message is intended to be used to request updates to existing (non- revoked and non-expired) certificates.
主要な更新要求において、CertReqMessages構文は使用されています。 SubjectPublicKeyInfo、KeyId、およびValidityは通常、各キーをアップデートするために供給されるかもしれないテンプレート野原です。 既存(非取り消されて非満期の)の証明書にアップデートを要求するのにこのメッセージが使用されることを意図します。
See [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関して[CRMF]を見てください。
3.3.6 Key Update response content
3.3.6 主要なUpdate応答内容
For key update responses the CertRepMessage syntax is used. The response is identical to the initialization response.
主要なアップデート応答において、CertRepMessage構文は使用されています。 応答は初期化応答と同じです。
See Section 3.3.4 for CertRepMessage syntax.
CertRepMessage構文に関してセクション3.3.4を見てください。
3.3.7 Key Recovery Request content
3.3.7 主要なRecovery Request内容
For key recovery requests the syntax used is identical to the initialization request CertReqMessages. Typically, SubjectPublicKeyInfo and KeyId are the template fields which may be used to supply a signature public key for which a certificate is required (see Appendix B profiles for further information).
キーリカバリー要求において、使用される構文は初期化要求CertReqMessagesと同じです。 SubjectPublicKeyInfoとKeyIdは通常、証明書が必要である署名公開鍵を供給するのに使用されるかもしれないテンプレート分野(詳細のためのAppendix Bプロフィールを見る)です。
See [CRMF] for CertReqMessages syntax. Note that if a key history is required, the requester must supply a Protocol Encryption Key control in the request message.
CertReqMessages構文に関して[CRMF]を見てください。 主要な歴史が必要であるなら、リクエスタが要求メッセージにおけるプロトコルEncryption Keyコントロールを供給しなければならないことに注意してください。
3.3.8 Key recovery response content
3.3.8 キーリカバリー応答内容
For key recovery responses the following syntax is used. For some status values (e.g., waiting) none of the optional fields will be present.
キーリカバリー応答において、以下の構文は使用されています。 いくつかの状態値(例えば、待ち)のために、任意の分野のいずれも存在しないでしょう。
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent:、:= 系列状態PKIStatusInfo、newSigCert[0]はOPTIONALを証明します、caCerts[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL、keyPairHist[2]SEQUENCE SIZE(1..MAX)OF CertifiedKeyPair OPTIONAL
Adams & Farrell Standards Track [Page 34] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[34ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.3.9 Revocation Request Content
3.3.9 取消し要求内容
When requesting revocation of a certificate (or several certificates) the following data structure is used. The name of the requester is present in the PKIHeader structure.
証明書(または、いくつかの証明書)の取消しを要求するとき、以下のデータ構造は使用されています。 リクエスタの名前はPKIHeader構造に存在しています。
RevReqContent ::= SEQUENCE OF RevDetails
RevReqContent:、:= RevDetailsの系列
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevDetails:、:= 系列certDetails CertTemplate--リクエスタが指定するのを周囲に許容できるくらい許容します--、本命、取消しは要求されています--(例えば、serialNumberが利用可能でない場合のための)revocationReason ReasonFlags OPTIONAL(取消しが要求されたbadSinceDate GeneralizedTime OPTIONALである理由)は示します中で送付者crlEntryDetails Extensions OPTIONAL--crlEntryExtensionsを要求するのに関する知識最も良い。
3.3.10 Revocation Response Content
3.3.10 取消し応答内容
The response to the above message. If produced, this is sent to the requester of the revocation. (A separate revocation announcement message MAY be sent to the subject of the certificate for which revocation was requested.)
上記のメッセージへの応答。 生産するなら、取消しのリクエスタにこれを送ります。 (別々の取消し発表メッセージを取消しが要求された証明書の対象に送るかもしれません。)
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
RevRepContent:、:= 系列RevReqContent revCerts[0]SEQUENCE SIZE(1..MAX)OF CertId OPTIONALで送られた同じ注文における状態SEQUENCE SIZE(1..MAX)OF PKIStatusInfo--取消しが要求された(状態と同じオーダー)crls[1]SEQUENCE SIZE(1..MAX)OF CertificateList OPTIONALであったID--結果として起こるCRLs(1つ以上があるかもしれません)
3.3.11 Cross certification request content
3.3.11 相互認証要求内容
Cross certification requests use the same syntax (CertReqMessages) as for normal certification requests with the restriction that the key pair MUST have been generated by the requesting CA and the private key MUST NOT be sent to the responding CA.
相互認証要求は通常の証明要求のように要求カリフォルニアが主要な組を生成したに違いなくて、応じるカリフォルニアに秘密鍵を送ってはいけないという制限で同じ構文(CertReqMessages)を使用します。
See [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関して[CRMF]を見てください。
Adams & Farrell Standards Track [Page 35] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[35ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
3.3.12 Cross certification response content
3.3.12 相互認証応答内容
Cross certification responses use the same syntax (CertRepMessage) as for normal certification responses with the restriction that no encrypted private key can be sent.
相互認証応答は通常の証明応答のように暗号化された秘密鍵を全く送ることができないという制限で同じ構文(CertRepMessage)を使用します。
See Section 3.3.4 for CertRepMessage syntax.
CertRepMessage構文に関してセクション3.3.4を見てください。
3.3.13 CA Key Update Announcement content
3.3.13 カリフォルニアKey Update Announcement内容
When a CA updates its own key pair the following data structure MAY be used to announce this event.
カリフォルニアがそれ自身の主要な組をアップデートするとき、以下のデータ構造は、このイベントを発表するのに使用されるかもしれません。
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
CAKeyUpdAnnContent:、:= 系列{oldWithNew Certificate--新しいpriv newWithOld Certificateを契約された古いパブ--新しいパブは古いpriv newWithNew Certificateと契約しました--新しいprivを契約された新しいパブ}
3.3.14 Certificate Announcement
3.3.14 証明書発表
This structure MAY be used to announce the existence of certificates.
この構造は、証明書の存在を発表するのに使用されるかもしれません。
Note that this message is intended to be used for those cases (if any) where there is no pre-existing method for publication of certificates; it is not intended to be used where, for example, X.500 is the method for publication of certificates.
それらのケースに証明書の公表のためのメソッドを先在させてはいけないところでこのメッセージが使用されることを(もしあれば)意図することに注意してください。 例えば、X.500が証明書の公表のためのメソッドであるところでそれが使用されることを意図しません。
CertAnnContent ::= Certificate
CertAnnContent:、:= 証明書
3.3.15 Revocation Announcement
3.3.15 取消し発表
When a CA has revoked, or is about to revoke, a particular certificate it MAY issue an announcement of this (possibly upcoming) event.
カリフォルニアがそれがこの(ことによると今度)のイベントの発表を発行するかもしれない特定の証明書を取り消して、取り消そうとしているとき。
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
RevAnnContent:、:= 系列状態PKIStatus、certId CertId、willBeRevokedAt GeneralizedTime、badSinceDate GeneralizedTime、crlDetails Extensions OPTIONAL、--付加的なCRLが(例えば、crl番号、理由、位置など)を詳しく述べる
Adams & Farrell Standards Track [Page 36] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[36ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
A CA MAY use such an announcement to warn (or notify) a subject that its certificate is about to be (or has been) revoked. This would typically be used where the request for revocation did not come from the subject concerned.
カリフォルニアは、証明書が取り消されようとしている(または、あった)と対象に警告すること(通知する)にそのような発表を使用するかもしれません。 これは取消しを求める要求が関する対象から来なかったところで通常使用されるでしょう。
The willBeRevokedAt field contains the time at which a new entry will be added to the relevant CRLs.
willBeRevokedAt分野は新しいエントリーが関連CRLsに加えられる時を含んでいます。
3.3.16 CRL Announcement
3.3.16 CRL発表
When a CA issues a new CRL (or set of CRLs) the following data structure MAY be used to announce this event.
カリフォルニアが新しいCRL(または、CRLsのセット)を発行するとき、以下のデータ構造は、このイベントを発表するのに使用されるかもしれません。
CRLAnnContent ::= SEQUENCE OF CertificateList
CRLAnnContent:、:= CertificateListの系列
3.3.17 PKI Confirmation content
3.3.17 PKI Confirmation内容
This data structure is used in three-way protocols as the final PKIMessage. Its content is the same in all cases - actually there is no content since the PKIHeader carries all the required information.
このデータ構造は最終的なPKIMessageとして3者間のプロトコルに使用されます。 内容はすべての場合で同じです--PKIHeaderがすべての必須情報を運ぶので、内容が全く実際にありません。
PKIConfirmContent ::= NULL
PKIConfirmContent:、:= ヌル
3.3.18 PKI General Message content
3.3.18 PKI一般教書内容
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
InfoTypeAndValue:、:= SEQUENCE、infoType OBJECT IDENTIFIER、infoValue、どんなDEFINED BY infoType OPTIONAL、も--含んでいますが、例のInfoTypeAndValue内容は制限されません: -- または、CurrentCRLが等しい、イド、-、それ、6、CertificateList、--、どこ、イド、-、それ、= イド-pkix4は1 3 6 1 5 5 7 4と等しいです--また、この構造物が新しいPKIX Certificate--管理プロトコル要求と応答メッセージか、一般--将来の必要性への目的(例えば、発表)メッセージを定義するのに使用されるかもしれないか、--特定の環境。
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue -- May be sent by EE, RA, or CA (depending on message content). -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically -- be omitted for some of the examples given above. The receiver is
GenMsgContent:、:= SEQUENCE OF InfoTypeAndValue--EE、RA、またはカリフォルニアによって送られるかもしれません(メッセージ内容によって)。 -- InfoTypeAndValueのOPTIONAL infoValueパラメタは通常そうするでしょう--上に出された例のいくつかには、省略されてください。 受信機はそうです。
Adams & Farrell Standards Track [Page 37] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[37ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
-- free to ignore any contained OBJ. IDs that it does not recognize. -- If sent from EE to CA, the empty set indicates that the CA may send -- any/all information that it wishes.
-- どんな含まれたOBJも無視するのにおいて、自由です。 それが認識しないID。 -- EEからカリフォルニアに送るなら、空集合が、カリフォルニアがいくらか発信するかもしれないのを示す、/、願っているというすべての情報。
3.3.19 PKI General Response content
3.3.19 PKIの一般Response内容
GenRepContent ::= SEQUENCE OF InfoTypeAndValue -- The receiver is free to ignore any contained OBJ. IDs that it does -- not recognize.
GenRepContent:、:= SEQUENCE OF InfoTypeAndValue--受信機は無料でどんな含まれたOBJも無視できます。 それがするID--認識しません。
3.3.20 Error Message content
3.3.20 誤りMessage内容
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
ErrorMsgContent:、:= 系列pKIStatusInfo PKIStatusInfo、errorCode INTEGER OPTIONAL--実装特有のエラーコードerrorDetails PKIFreeText OPTIONAL--実装特有の誤りの詳細
4. Mandatory PKI Management functions
4. 義務的なPKI Management機能
The PKI management functions outlined in Section 1 above are described in this section.
上のセクション1に概説されたPKI管理機能はこのセクションで説明されます。
This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described (perhaps via one of the transport mechanisms defined in Section 5). This part is effectively the profile of the PKI management functionality that MUST be supported.
このセクションはすべての終わりの実体とカリフォルニア/RA実装が説明された(恐らくセクション5で定義された移送機構の1つを通して)機能性を提供できなければならないという意味で「義務的な」機能に対処します。 事実上、この部分はサポートしなければならないPKI管理の機能性のプロフィールです。
Note that not all PKI management functions result in the creation of a PKI message.
すべてのPKI管理機能がPKIメッセージの作成をもたらすというわけではないことに注意してください。
4.1 Root CA initialization
4.1 根のカリフォルニアの初期化
[See Section 1.2.2 for this document's definition of "root CA".]
[このドキュメントの「根のカリフォルニア」の定義に関してセクション1.2.2を見てください。]
A newly created root CA must produce a "self-certificate" which is a Certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update.
新たに作成された根に、プロフィールが"newWithNew"という根のカリフォルニアキーアップデートに続いて、発行された証明書のために定義されている状態で、カリフォルニアはCertificate構造である「自己証明書」を生産しなければなりません。
In order to make the CA's self certificate useful to end entities that do not acquire the self certificate via "out-of-band" means, the CA must also produce a fingerprint for its public key. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and hence the other attributes contained therein.
CAの自己証明書を「バンドの外」という手段で自己証明書を入手しない実体を終わらせるために役に立つようにして、また、カリフォルニアは公開鍵のために指紋を作り出さなければなりません。 そして、「バンドの外」といういくつかの手段でしっかりとこの指紋を入手する終わりの実体はCAの自己証明書としたがって、そこに含まれた他の属性について確かめることができます。
Adams & Farrell Standards Track [Page 38] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[38ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
The data structure used to carry the fingerprint is the OOBCertHash.
指紋を運ぶのに使用されるデータ構造はOOBCertHashです。
4.2 Root CA key update
4.2 根のカリフォルニアキーアップデート
CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 2.4.1) are issued by the CA to aid existing end entities who hold the current self-signed CA certificate (OldWithOld) to transition securely to the new self- signed CA certificate (NewWithNew), and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.
カリフォルニアキー(他のすべてのキーとしての)を有限生涯を持って、周期的ベースでアップデートしなければならないでしょう。 証明書のNewWithNew、NewWithOld、およびOldWithNew(セクション2.4.1を見る)は、しっかりと、現在の自己によって署名されたカリフォルニア証明書(OldWithOld)を変遷として保持する既存の終わりの実体をカリフォルニア証明書(NewWithNew)であると署名される新しい自己に支援して、なるNewWithNewを持っているのに新しい終わりの実体が既存のデータの検証のためにしっかりとOldWithOldを獲得するのを支援するためにカリフォルニアによって発行されます。
4.3 Subordinate CA initialization
4.3 下位のカリフォルニアの初期化
[See Section 1.2.2 for this document's definition of "subordinate CA".]
[このドキュメントの「下位のカリフォルニア」の定義に関してセクション1.2.2を見てください。]
From the perspective of PKI management protocols the initialization of a subordinate CA is the same as the initialization of an end entity. The only difference is that the subordinate CA must also produce an initial revocation list.
PKI管理プロトコルの見解から、下位のカリフォルニアの初期化は終わりの実体の初期化と同じです。 唯一の違いはまた、下位のカリフォルニアが初期の取消しリストを作り出さなければならないということです。
4.4 CRL production
4.4 CRL生産
Before issuing any certificates a newly established CA (which issues CRLs) must produce "empty" versions of each CRL which is to be periodically produced.
以前、新設されたカリフォルニア(CRLsを発行する)をどんな証明書にも発行すると、定期的に生産されることになっているそれぞれのCRLの「空」のバージョンは生産されなければなりません。
4.5 PKI information request
4.5 PKI情報要求
When a PKI entity (CA, RA, or EE) wishes to acquire information about the current status of a CA it MAY send that CA a request for such information.
PKI実体(カリフォルニア、RA、またはEE)願望であるときに、カリフォルニアの現在の状態の情報を取得するために、それはそのような情報に関する要求をそのカリフォルニアに送るかもしれません。
The CA must respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided then an error must be conveyed to the requester.
カリフォルニアは、(少なくとも)リクエスタによって要求された情報のすべてを提供することによって、要求に応じなければなりません。 何らかの情報を提供できないなら、誤りをリクエスタに伝えなければなりません。
If PKIMessages are used to request and supply this PKI information, then the request must be the GenMsg message, the response must be the GenRep message, and the error must be the Error message. These messages are protected using a MAC based on shared secret information (i.e., PasswordBasedMAC) or any other authenticated means (if the end entity has an existing certificate).
PKIMessagesがこのPKI情報を要求して、提供するのに使用されるなら、要求はGenMsgメッセージであるに違いありません、そして、応答はGenRepメッセージであるに違いありません、そして、誤りはErrorメッセージであるに違いありません。 共有秘密キー情報(すなわち、PasswordBasedMAC)かいかなる他の認証された手段にも基づくMACを使用することで(終わりの実体に既存の証明書があるなら)これらのメッセージは保護されます。
Adams & Farrell Standards Track [Page 39] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[39ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
4.6 Cross certification
4.6 相互認証
The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate.
リクエスタカリフォルニアは交差している証明書の対象になるカリフォルニアです。 応答者カリフォルニアは交差している証明書の発行人になるでしょう。
The requester CA must be "up and running" before initiating the cross-certification operation.
相互認証操作を開始する前に、リクエスタカリフォルニアは「活動していなければなりません」。
4.6.1 One-way request-response scheme:
4.6.1 一方向要求応答体系:
The cross-certification scheme is essentially a one way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross- certificates be created in "both directions" then each CA in turn must initiate a cross-certification operation (or use another scheme).
相互認証体系は本質的には一方通行の操作です。 すなわち、うまくいくとき、この操作は1通の新しい交差している証明書の作成をもたらします。 要件が十字証明書が「両方の方向」に作成されるということであるなら、各カリフォルニアは順番に相互認証操作を開始しなければなりません(別の体系を使用してください)。
This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request.
問題の2CAsが既に互いの署名について確かめることができるか(それらには、一般的な数ポイントの信頼があります)、または証明要求の発生源のバンドで出ている検証があるところでこの体系は適当です。
Detailed Description:
詳述:
Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on- line exchange.
相互認証は応答者として知られている1カリフォルニアで開始されます。 応答者のためのカリフォルニアの管理者はそれがそうしたがっているカリフォルニアを特定します。十字は公認して、応答者カリフォルニア設備は許可コードを生成します。 応答者カリフォルニアの管理者はバンドの外によるこの許可コード手段をリクエスタカリフォルニアの管理者に渡します。 リクエスタカリフォルニアの管理者は、系列が交換するオンを開始するためにリクエスタカリフォルニアで許可コードを入れます。
The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged.
許可コードは認証と保全目的に使用されます。 すべてのメッセージの(MACs)が交換したメッセージ立証コードを生成するのに許可コードに基づいていて、対称鍵を使用することで対称鍵を生成することによって、これをします。
The requester CA initiates the exchange by generating a random number (requester random number). The requester CA then sends to the responder CA the cross certification request (ccr) message. The fields in this message are protected from modification with a MAC based on the authorization code.
リクエスタカリフォルニアが乱数を生成することによって交換を起こす、(リクエスタ、乱数) そして、リクエスタカリフォルニアは相互認証要求(ccr)メッセージを応答者カリフォルニアに送ります。 このメッセージの分野は許可コードに基づくMACとの変更から保護されます。
Upon receipt of the ccr message, the responder CA checks the protocol version, saves the requester random number, generates its own random number (responder random number) and validates the MAC. It then
応答者カリフォルニアがccrメッセージを受け取り次第プロトコルバージョンをチェックして、リクエスタに乱数を保存して、それ自身の乱数を生成する、(応答者、乱数、)、MACを有効にします。 それ、当時
Adams & Farrell Standards Track [Page 40] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[40ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
generates (and archives, if desired) a new requester certificate that contains the requester CA public key and is signed with the responder CA signature private key. The responder CA responds with the cross certification response (ccp) message. The fields in this message are protected from modification with a MAC based on the authorization code.
そして、生成する、(アーカイブ、望まれているならリクエスタカリフォルニア公開鍵を含んでいて、応答者カリフォルニア署名秘密鍵を契約される新しいリクエスタ証明書。 応答者カリフォルニアは相互認証応答(ccp)メッセージで応じます。 このメッセージの分野は許可コードに基づくMACとの変更から保護されます。
Upon receipt of the ccp message, the requester CA checks that its own system time is close to the responder CA system time, checks the received random numbers and validates the MAC. The requester CA responds with the PKIConfirm message. The fields in this message are protected from modification with a MAC based on the authorization code. The requester CA writes the requester certificate to the Repository.
ccpメッセージを受け取り次第、カリフォルニアがそのそれ自身のシステム時にチェックするリクエスタは、応答者カリフォルニアシステム時間の近く間、あって、容認された乱数をチェックして、MACを有効にします。 リクエスタカリフォルニアはPKIConfirmメッセージで応じます。 このメッセージの分野は許可コードに基づくMACとの変更から保護されます。 リクエスタカリフォルニアはリクエスタ証明書をRepositoryに書きます。
Upon receipt of the PKIConfirm message, the responder CA checks the random numbers and validates the MAC.
PKIConfirmメッセージを受け取り次第、応答者カリフォルニアは、乱数をチェックして、MACを有効にします。
Notes:
注意:
1. The ccr message must contain a "complete" certification request,
that is, all fields (including, e.g., a BasicConstraints
extension) must be specified by the requester CA.
2. The ccp message SHOULD contain the verification certificate of the
responder CA - if present, the requester CA must then verify this
certificate (for example, via the "out-of-band" mechanism).
1. ccrメッセージは「完全な」証明要求を含まなければなりません、すなわち、リクエスタカリフォルニアがすべての分野(包含、例えば、BasicConstraints拡張子)を指定しなければなりません。 2. 存在しているなら、ccpメッセージSHOULDは応答者カリフォルニアの検証証明書を含んでいて、次に、リクエスタカリフォルニアはこの証明書(例えば「バンドの外」というメカニズムで)について確かめなければなりません。
4.7 End entity initialization
4.7 終わりの実体初期化
As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps:
CAsなら、終わりの実体を初期化しなければなりません。 終わりの実体の初期設定は以下の少なくとも2ステップを必要とします:
- acquisition of PKI information
- out-of-band verification of one root-CA public key
- PKI情報の獲得--あるカリフォルニアを根づかせている公開鍵のバンドで出ている検証
(other possible steps include the retrieval of trust condition information and/or out-of-band verification of other CA public keys).
(他の可能なステップは信頼状態情報の検索、そして/または、他のカリフォルニア公開鍵のバンドで出ている検証を含んでいます。)
4.7.1 Acquisition of PKI information
4.7.1 PKI情報の獲得
The information REQUIRED is:
情報REQUIREDは以下の通りです。
- the current root-CA public key
- (if the certifying CA is not a root-CA) the certification path
from the root CA to the certifying CA together with appropriate
revocation lists
- the algorithms and algorithm parameters which the certifying CA
supports for each relevant usage
- 現在のカリフォルニアを根づかせている公開鍵--適切な取消しリストに伴う根のカリフォルニアから公認カリフォルニアまでの(公認カリフォルニアが根カリフォルニアでないなら)証明経路--公認カリフォルニアがそれぞれの関連用法のためにサポートするアルゴリズムとアルゴリズムパラメタ
Adams & Farrell Standards Track [Page 41] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[41ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request which will be successful. However, for simplicity we do not mandate that the end entity acquires this information via the PKI messages. The end result is simply that some certification requests may fail (e.g., if the end entity wants to generate its own encryption key but the CA doesn't allow that).
うまくいっている証明要求を作り出すために追加情報を必要とすることができました(例えば、拡大かカリフォルニア方針情報であるとサポートされます)。 しかしながら、簡単さのために、私たちは、終わりの実体がPKIメッセージでこの情報を取得するのを強制しません。 単に、結末はいくつかの証明要求が失敗するかもしれないという(例えば、終わりの実体必需品であるなら、それ自身の暗号化キーにもかかわらず、カリフォルニアを生成するのはそれを許容しません)ことです。
The required information MAY be acquired as described in Section 4.5.
必須情報はセクション4.5で説明されるように後天的であるかもしれません。
4.7.2 Out-of-Band Verification of Root-CA Key
4.7.2 カリフォルニアを根づかせているキーのバンドで出ている検証
An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate.
終わりの実体には、根のカリフォルニアの公開鍵がしっかりとなければなりません。 これを達成する1つのメソッドは「バンドの外」といういくつかの安全な手段でCAの自己証明書指紋を終わりの実体に提供することです。 そして、終わりの実体はしっかりとCAの自己証明書を使用できます。
See Section 4.1 for further details.
さらに詳しい明細についてはセクション4.1を見てください。
4.8 Certificate Request
4.8 証明書要求
An initialized end entity MAY request a certificate at any time (as part of an update procedure, or for any other purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.
初期化している終わりの実体はいつでも(アップデート手順の一部、またはいかなる他の目的のためにも)、証明書を要求するかもしれません。 証明要求(cr)メッセージを使用することでこの要求をするでしょう。 終わりの実体に署名重要組(対応する検証証明書がある)が既にあると、このcrメッセージは実体のデジタル署名で通常保護されるでしょう。 カリフォルニアはCertRepMessageで新しい証明書を返します(要求がうまくいくなら)。
4.9 Key Update
4.9 主要なアップデート
When a key pair is due to expire the relevant end entity MAY request a key update - that is, it MAY request that the CA issue a new certificate for a new key pair. The request is made using a key update request (kur) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.
主要な組が期限が切れることになっているとき、関連終わりの実体は主要なアップデートを要求するかもしれません--すなわち、それは、カリフォルニアが新しい主要な組のために新しい証明書を発行するよう要求するかもしれません。 主要な更新要求(kur)メッセージを使用することで要求をします。 終わりの実体に署名重要組(対応する検証証明書がある)が既にあると、このメッセージは実体のデジタル署名で通常保護されるでしょう。 カリフォルニアは主要なアップデート応答(kup)メッセージで新しい証明書を返します(要求がうまくいくなら)。(それは、シンタクス上CertRepMessageと同じです)。
5. Transports
5. 輸送
The transport protocols specified below allow end entities, RAs and CAs to pass PKI messages between them. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages are suitably protected (that is, if the OPTIONAL PKIProtection parameter is used as specified for each message).
以下で指定されたトランスポート・プロトコルで、終わりの実体、RAs、およびCAsはそれらの間でメッセージをPKIに通過できます。 PKIメッセージが適当に保護されるなら(すなわち、OPTIONAL PKIProtectionパラメタが各メッセージに指定されるように使用されているなら)、特定のセキュリティー対策がこのレベルで適用されるという要件が全くありません。
Adams & Farrell Standards Track [Page 42] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[42ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
5.1 File based protocol
5.1ファイルはプロトコルを基礎づけました。
A file containing a PKI message MUST contain only the DER encoding of one PKI message, i.e., there MUST be no extraneous header or trailer information in the file.
PKIメッセージを含むファイルは1つのPKIメッセージのDERコード化だけを含まなければなりません、すなわち、ファイルにはどんな異質なヘッダーもトレーラ情報もあるはずがありません。
Such files can be used to transport PKI messages using, e.g., FTP.
例えば使用することでPKIメッセージを輸送するのにそのようなファイルを使用できます。FTP。
5.2 Direct TCP-Based Management Protocol
5.2 ダイレクトTCPベースの管理プロトコル
The following simple TCP-based protocol is to be used for transport of PKI messages. This protocol is suitable for cases where an end entity (or an RA) initiates a transaction and can poll to pick up the results.
以下の簡単なTCPベースのプロトコルはPKIメッセージの輸送に使用されることです。 このプロトコルは終わりの実体(または、RA)がトランザクションを開始して、結果を拾うために投票できるケースに適しています。
If a transaction is initiated by a PKI entity (RA or CA) then an end entity must either supply a listener process or be supplied with a polling reference (see below) in order to allow it to pick up the PKI message from the PKI management component.
PKI実体(RAかカリフォルニア)でトランザクションを開始するなら、終わりの実体は、PKI管理の部品からPKIメッセージを受信するのを許容するためにリスナープロセスを供給しなければならないか、または世論調査参照を供給しなければなりません(以下を見ます)。
The protocol basically assumes a listener process on an RA or CA which can accept PKI messages on a well-defined port (port number 829). Typically an initiator binds to this port and submits the initial PKI message for a given transaction ID. The responder replies with a PKI message and/or with a reference number to be used later when polling for the actual PKI message response.
プロトコルは明確なポートに関するPKIメッセージを受け入れることができるRAかカリフォルニアで基本的にリスナープロセスを仮定します(No.829を移植してください)。 創始者は、与えられたトランザクションIDのために通常、このポートに付いて、初期のPKIメッセージを提出します。 応答者は、後で実際のPKIメッセージ応答に投票するとき、使用されるためにPKIメッセージ参照番号で返答します。
If a number of PKI response messages are to be produced for a given request (say if some part of the request is handled more quickly than another) then a new polling reference is also returned.
また、多くのPKI応答メッセージが与えられた要求のために生産する(要求の何らかの部分が別のものよりはやく扱われるかどうか言ってください)ことであるなら、新しい世論調査参照を返します。
When the final PKI response message has been picked up by the initiator then no new polling reference is supplied.
創始者がその時新しくない最終的なPKI応答メッセージを拾ったとき、世論調査参照を提供します。
The initiator of a transaction sends a "direct TCP-based PKI message" to the recipient. The recipient responds with a similar message.
トランザクションの創始者は「ダイレクトTCPベースのPKIメッセージ」を受取人に送ります。 受取人は同様のメッセージで応じます。
A "direct TCP-based PKI message" consists of:
「ダイレクトTCPベースのPKIメッセージ」は以下から成ります。
length (32-bits), flag (8-bits), value (defined below)
(32ビット)(旗(8ビット))が評価する長さ(以下では、定義されます)
The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order.
長さの分野はメッセージ(すなわち、「値」と1の八重奏の数)の残りの八重奏の数を含んでいます。 このプロトコルのすべての32ビットの値が、ネットワークバイトオーダーにはあるように指定されます。
Message name flag value
メッセージ名前旗の価値
pkiMsg '00'H DER-encoded PKI message
pkiMsg'00'のH DERによってコード化されたPKIメッセージ
Adams & Farrell Standards Track [Page 43] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[43ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
-- PKI message
pollRep '01'H polling reference (32 bits),
time-to-check-back (32 bits)
-- poll response where no PKI message response ready; use polling
-- reference value (and estimated time value) for later polling
pollReq '02'H polling reference (32 bits)
-- request for a PKI message response to initial message
negPollRep '03'H '00'H
-- no further polling responses (i.e., transaction complete)
partialMsgRep '04'H next polling reference (32 bits),
time-to-check-back (32 bits),
DER-encoded PKI message
-- partial response to initial message plus new polling reference
-- (and estimated time value) to use to get next part of response
finalMsgRep '05'H DER-encoded PKI message
-- final (and possibly sole) response to initial message
errorMsgRep '06'H human readable error message
-- produced when an error is detected (e.g., a polling reference is
-- received which doesn't exist or is finished with)
-- 参照に投票するPKIメッセージpollRep'01'H(32ビット)、調べ直す時間(32ビット)--メッセージ応答準備ができていた状態で応答どこいいえPKIに投票してくださいか。 次にこれ以上参照(32ビット)に投票しながら応答(すなわち、トランザクション完全な)partialMsgRep'04'Hに投票しないで、世論調査--後でpollReq'02'H世論調査参照(32ビット)に投票するための基準値(そして、時間的価値であると見積もられている)--PKIメッセージ応答がメッセージnegPollRep'03'H'00'Hに頭文字をつけるという要求を使用してください、調べ直す時間(32ビット)、DERによってコード化されたPKIメッセージ; 誤りが検出されるとき、初期のメッセージと新しい世論調査参照への部分応答(応答finalMsgRep'05の次の部分を得る使用への、'HはPKIメッセージをDERコード化しました--メッセージerrorMsgRep'06に頭文字をつける最終的で(ことによると唯一)の応答'という(そして、時間的価値であると見積もられています)人間の読み込み可能なHエラーメッセージ)は生産されました。(例えば、世論調査参照はそうです--存在しないものを受けるか、または終わります)
Where a PKIConfirm message is to be transported (always from the initiator to the responder) then a pkiMsg message is sent and a negPollRep is returned.
PKIConfirmメッセージがその時輸送される(いつも創始者から応答者まで)ことであるところに、pkiMsgメッセージを送ります、そして、negPollRepを返します。
The sequence of messages which can occur is then:
現れることができるメッセージの系列はその時です:
a) end entity sends pkiMsg and receives one of pollRep, negPollRep, partialMsgRep or finalMsgRep in response. b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep, finalMsgRep or errorMsgRep in response.
終わりの実体は、pkiMsgを送って、応答でpollRep、negPollRep、partialMsgRepまたはfinalMsgRepの1つを受け取ります。a) b)終わりの実体は、pollReqメッセージを送って、応答でnegPollRep、partialMsgRep、finalMsgRepまたはerrorMsgRepの1つを受け取ります。
The "time-to-check-back" parameter is a 32-bit integer, defined to be the number of seconds which have elapsed since midnight, January 1, 1970, coordinated universal time. It provides an estimate of the time that the end entity should send its next pollReq.
1970年1月1日に「調べ直す時間」パラメタは真夜中以来経過している秒数になるように定義された32ビットの整数です、連携ユニバーサルタイム。 終わりの実体が次のpollReqを送るべきであるのは現代の見積りに提供されます。
5.3 Management Protocol via E-mail
5.3 メールを通した管理プロトコル
This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via Internet mail.
この小区分は交換がセクション4でインターネット・メールで説明したプロトコルへのASN.1によってコード化されたメッセージを伝えるための手段を指定します。
A simple MIME object is specified as follows.
簡単なMIMEオブジェクトは以下の通り指定されます。
Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
コンテントタイプ: pkixcmp Content転送アプリケーション/コード化: base64
<<the ASN.1 DER-encoded PKIX-CMP message, base64-encoded>>
ASN.1のDERによってコード化されたPKIX-CMPが通信させる<<、base64によってコード化された>>。
Adams & Farrell Standards Track [Page 44] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[44ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
This MIME object can be sent and received using common MIME processing engines and provides a simple Internet mail transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable.
このMIMEオブジェクトは、送ることができて、一般的なMIME処理エンジンを使用することで受信して、PKIX-CMPメッセージのための簡単なインターネット・メール輸送を提供します。 また、実装は、どこでも、適切であるところで後方の互換性をサポートするのに、「アプリケーション/x-pkixcmp」MIMEの種類(このドキュメントの以前のバージョンでは、指定される)を認識して、使用したがっているかもしれません。
5.4 Management Protocol via HTTP
5.4 HTTPを通した管理プロトコル
This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via the HyperText Transfer Protocol.
この小区分は交換がセクション4でHyperText Transferプロトコルで説明したプロトコルへのASN.1によってコード化されたメッセージを伝えるための手段を指定します。
A simple MIME object is specified as follows.
簡単なMIMEオブジェクトは以下の通り指定されます。
Content-Type: application/pkixcmp
コンテントタイプ: アプリケーション/pkixcmp
<<the ASN.1 DER-encoded PKIX-CMP message>>
<<はASN.1のDERによってコード化されたPKIX-CMPメッセージ>>です。
This MIME object can be sent and received using common HTTP processing engines over WWW links and provides a simple browser- server transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable.
このMIMEオブジェクトは、送ることができて、WWWリンクの上に一般的なHTTP処理エンジンを使用することで受信して、PKIX-CMPメッセージのための簡単なブラウザサーバ輸送を提供します。 また、実装は、どこでも、適切であるところで後方の互換性をサポートするのに、「アプリケーション/x-pkixcmp」MIMEの種類(このドキュメントの以前のバージョンでは、指定される)を認識して、使用したがっているかもしれません。
SECURITY CONSIDERATIONS
セキュリティ問題
This entire memo is about security mechanisms.
この全体のメモはセキュリティー対策に関するものです。
One cryptographic consideration is worth explicitly spelling out. In the protocols specified above, when an end entity is required to prove possession of a decryption key, it is effectively challenged to decrypt something (its own certificate). This scheme (and many others!) could be vulnerable to an attack if the possessor of the decryption key in question could be fooled into decrypting an arbitrary challenge and returning the cleartext to an attacker. Although in this specification a number of other failures in security are required in order for this attack to succeed, it is conceivable that some future services (e.g., notary, trusted time) could potentially be vulnerable to such attacks. For this reason we re- iterate the general rule that implementations should be very careful about decrypting arbitrary "ciphertext" and revealing recovered "plaintext" since such a practice can lead to serious security vulnerabilities.
暗号の考慮は明らかに価値がある詳しく説明する1。 終わりの実体が復号化の所有物が主要であると立証するのに必要であるときに上で指定されたプロトコルでは、事実上、何かが(それ自身の証明書)であると解読するように挑まれます。 任意の挑戦を解読して、cleartextを攻撃者に返すように問題の復号化キーの所有者をだますことができるなら、この体系(そして、多くの他のもの!)は攻撃に被害を受け易いかもしれないでしょうに。 この攻撃が引き継ぐのに他の多くの失敗がこの仕様で安全に必要ですが、いくつかの今後のサービス(例えば、公証人、信じられた時間)が潜在的にそのような攻撃に被害を受け易いかもしれないのが想像できます。 私たちが再繰り返すこの理由に関しては、そのような習慣が重大なセキュリティの脆弱性に通じることができるので、実装が任意の「暗号文」を解読することに関して非常に慎重であって、顕であるべきであるという一般的な規則は「平文」を回復しました。
Adams & Farrell Standards Track [Page 45] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[45ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Note also that exposing a private key to the CA/RA as a proof-of- possession technique can carry some security risks (depending upon whether or not the CA/RA can be trusted to handle such material appropriately). Implementers are advised to exercise caution in selecting and using this particular POP mechanism.
また、-所有物では、テクニックがいくつかのセキュリティ危険を運ぶことができるという(カリフォルニア/RAが適切にそのような材料を扱うと信じることができるかどうかによって)証拠としてカリフォルニア/RAに秘密鍵を暴露して、それに注意してください。 Implementersがこの特定のPOPメカニズムを選択して、使用する際に警戒するようにアドバイスされます。
References
参照
[COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC
9594-8: 1990 & 1993 (1995:E), July 1995.
[COR95]ISO/IEC JTC1/サウスカロライナ21、ISO/IEC9594-8への技術的な間違い2: 1990日と1993(1995: E)、7月1995日
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Certificate
Request Message Format", RFC 2511, March 1999.
[CRMF] マイアーズとM.とアダムスとC.と独奏とD.とD.ケンプ、「証明書要求メッセージ形式」、RFC2511、1999年3月。
[MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of
Applied Cryptography", CRC Press, 1997.
[MvOV97] A.メネゼス、P.はOorschot、S.Vanstone、「適用された暗号のハンドブック」、CRC Press、1997をバンに積みます。
[PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California,
November 1993 Release.
RSA Data Security株式会社、レッドウッドシティー(カリフォルニア)、1993年11月は、[PKCS7]RSA研究所、「公開鍵暗号化標準(PKCS)」とリリースします。
[PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California,
November 1993 Release.
RSA Data Security株式会社、レッドウッドシティー(カリフォルニア)、1993年11月は、[PKCS10]RSA研究所、「公開鍵暗号化標準(PKCS)」とリリースします。
[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards -
PKCS #11: Cryptographic token interface standard", RSA
Data Security Inc., Redwood City, California, April 28,
1995.
[PKCS11]RSA研究所、「公開鍵暗号化標準--PKCS#11:、」 「暗号のトークンインターフェース規格」、RSA Data Security株式会社、レッドウッドシティー、1995年4月28日のカリフォルニア。
[RFC1847] Galvin, J., Murphy, S. Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/
Encrypted", RFC 1847, October 1995.
[RFC1847] ガルビン、J.、マーフィー、S.クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
SHA-1", RFC 2202, September 1997.
[RFC2202] チェンとP.とR.グレンと「HMAC-MD5のためのテストケースとHMAC- SHA-1インチ、RFC2202、1997年9月。」
[X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC
9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7,
and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1
December, 1996.
[X509-AM] ISO/IEC9594-6へのダム2、ISO/IEC9594-7へのダム1、およびISO/IEC9594-8にオンなダム1は、ISO/IEC JTC1/Sc21、修正案がISO/IEC9594-2に4をせき止めると拡大、1996年12月1日に証明します。
Adams & Farrell Standards Track [Page 46] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[46ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Acknowledgements
承認
The authors gratefully acknowledge the contributions of various members of the PKIX Working Group. Many of these contributions significantly clarified and improved the utility of this specification.
作者は感謝してPKIX作業部会の様々なメンバーの貢献を承諾します。 これらの貢献の多くが、この仕様に関するユーティリティをかなりはっきりさせて、改良しました。
Authors' Addresses
作者のアドレス
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08, Ottawa, Ontario Canada K1V 1A7
カーライルアダムスは技術750サギの道路、08スイートE、オンタリオオタワ(カナダ)K1V 1A7をゆだねます。
EMail: cadams@entrust.com
メール: cadams@entrust.com
Stephen Farrell Software and Systems Engineering Ltd. Fitzwilliam Court Leeson Close Dublin 2 IRELAND
スティーブンファレルSoftwareとシステム工学株式会社のフィッツウィリアム法廷のリースンはダブリン2アイルランドを閉じます。
EMail: stephen.farrell@sse.ie
メール: stephen.farrell@sse.ie
Adams & Farrell Standards Track [Page 47] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[47ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
APPENDIX A: Reasons for the presence of RAs
付録A: RAsの存在の理由
The reasons which justify the presence of an RA can be split into those which are due to technical factors and those which are organizational in nature. Technical reasons include the following.
RAの存在を正当化する理由は技術的な要素のためであるものと現実に組織的なものに分けることができます。 技術的な理由は以下を含んでいます。
-If hardware tokens are in use, then not all end entities will have
the equipment needed to initialize these; the RA equipment can
include the necessary functionality (this may also be a matter of
policy).
-ハードウェアトークンが使用中であるなら、すべての終わりの実体には、これらを初期化するのが必要である設備があるというわけではないでしょう。 RA設備は必要な機能性を含むことができます(また、これは方針の問題であるかもしれません)。
-Some end entities may not have the capability to publish
certificates; again, the RA may be suitably placed for this.
-いくつかの終わりの実体には、証明書を発表する能力がないかもしれません。 一方、RAはこれのために適当に置かれるかもしれません。
-The RA will be able to issue signed revocation requests on behalf
of end entities associated with it, whereas the end entity may not
be able to do this (if the key pair is completely lost).
-RAはそれに関連している終わりの実体を代表して署名している取消し要求を出すことができるでしょうが、終わりの実体はこれができないかもしれません(主要な組が完全に迷子になるなら)。
Some of the organizational reasons which argue for the presence of an RA are the following.
RAの存在について賛成の議論をする組織的な理由のいくつかが以下です。
-It may be more cost effective to concentrate functionality in the
RA equipment than to supply functionality to all end entities
(especially if special token initialization equipment is to be
used).
-RA設備の機能性を集結するのはすべての終わりの実体に機能性を供給するより(特別なトークン初期化設備が特に使用されていることであるなら)費用効率がよいかもしれません。
-Establishing RAs within an organization can reduce the number of
CAs required, which is sometimes desirable.
-組織の中にRAsを設立するのは必要であるCAsの数を減少させることができます。(CAsは時々望ましいです)。
-RAs may be better placed to identify people with their
"electronic" names, especially if the CA is physically remote from
the end entity.
-RAsは彼らの「電子」の名前と人々を同一視するために置かれるほうがよいです、特にカリフォルニアが終わりの実体から物理的に遠く離れているなら。
-For many applications there will already be in place some
administrative structure so that candidates for the role of RA are
easy to find (which may not be true of the CA).
-多くのアプリケーションのために、何らかの運営機構が適所に既にあるので、RAの役割の候補は見つけやすいです(カリフォルニアに関して本当でないかもしれません)。
Adams & Farrell Standards Track [Page 48] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[48ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Appendix B. PKI Management Message Profiles.
付録B.PKI管理メッセージプロフィール。
This appendix contains detailed profiles for those PKIMessages which MUST be supported by conforming implementations (see Section 4).
この付録は実装を従わせることによってサポートしなければならないそれらのPKIMessagesのための詳細なプロフィールを含んでいます(セクション4を見てください)。
Profiles for the PKIMessages used in the following PKI management operations are provided:
以下のPKI管理操作に使用されるPKIMessagesのためのプロフィールを提供します:
- root CA key update
- information request/response
- cross-certification request/response (1-way)
- initial registration/certification
- basic authenticated scheme
- certificate request
- key update
- 根のカリフォルニアキーアップデート--情報要求/応答--相互認証要求/応答(1ウェイ)(新規登録/証明--基本的な認証された体系)は要求--主要なアップデートを証明します。
<<Later versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).>>
このドキュメントの<の<の後のバージョンは. (他の操作望まれているなら)>>の下に記載された操作のためのプロフィールを含むように上記を広げるかもしれません。
- revocation request - certificate publication - CRL publication
- 取消し要求--証明書公表--CRL公表
B1. General Rules for interpretation of these profiles.
B1。 これらのプロフィールの解釈のためのRules司令官。
1. Where OPTIONAL or DEFAULT fields are not mentioned in individual
profiles, they SHOULD be absent from the relevant message (i.e., a
receiver can validly reject a message containing such fields as
being syntactically incorrect).
Mandatory fields are not mentioned if they have an obvious value
(e.g., pvno).
2. Where structures occur in more than one message, they are
separately profiled as appropriate.
3. The algorithmIdentifiers from PKIMessage structures are profiled
separately.
4. A "special" X.500 DN is called the "NULL-DN"; this means a DN
containing a zero-length SEQUENCE OF RelativeDistinguishedNames
(its DER encoding is then '3000'H).
5. Where a GeneralName is required for a field but no suitable
value is available (e.g., an end entity produces a request before
knowing its name) then the GeneralName is to be an X.500 NULL-DN
(i.e., the Name field of the CHOICE is to contain a NULL-DN).
This special value can be called a "NULL-GeneralName".
6. Where a profile omits to specify the value for a GeneralName
then the NULL-GeneralName value is to be present in the relevant
PKIMessage field. This occurs with the sender field of the
PKIHeader for some messages.
1. どこOPTIONALかDEFAULT分野が個々のプロフィールで言及されないで、それらはSHOULDです。関連メッセージを休んでください(シンタクス上不正確であるような分野を含んでいて、すなわち、受信機は確実にメッセージを拒絶できます)。 それらに明白な値(例えば、pvno)があるなら、義務的な分野は言及されません。 2. 構造が1つ以上のメッセージに現れるところでは、それらは別々に適宜輪郭を描かれます。 3. PKIMessage構造からのalgorithmIdentifiersは別々に輪郭を描かれます。 4. 「特別な」X.500 DNは「ヌルDN」と呼ばれます。 これは無の長さのSEQUENCE OF RelativeDistinguishedNamesを含むDNを意味します(次に、DERコード化は'3000'Hです)。 5. GeneralNameは分野にもかかわらず、どんな適当な値にもどこで必要でないかは、利用可能です(名前を知る前に、例えば、終わりの実体は要求を作り出します)、そして、GeneralNameによるX.500 NULL-DNであることになっています(すなわち、CHOICEのName分野はNULL-DNを含むことです)。 この特別な値を「ヌルGeneralName」と呼ぶことができます。 6. プロフィールが、その時GeneralNameに値を指定するのを忘れるところでは、NULL-GeneralName値は関連PKIMessage分野に存在していることです。 これはいくつかのメッセージのためのPKIHeaderの送付者分野で起こります。
Adams & Farrell Standards Track [Page 49] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[49ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
7. Where any ambiguity arises due to naming of fields, the profile
names these using a "dot" notation (e.g., "certTemplate.subject"
means the subject field within a field called certTemplate).
8. Where a "SEQUENCE OF types" is part of a message, a zero-based
array notation is used to describe fields within the SEQUENCE OF
(e.g., crm[0].certReq.certTemplate.subject refers to a
subfield of the first CertReqMsg contained in a request message).
9. All PKI message exchanges in Sections B7-B10 require a PKIConfirm
message to be sent by the initiating entity. This message is not
included in some of the profiles given since its body is NULL and
its header contents are clear from the context. Any authenticated
means can be used for the protectionAlg (e.g., password-based MAC,
if shared secret information is known, or signature).
7. どんなあいまいさも分野の命名のため起こるところでは、プロフィールは、「ドット」記法を使用するとこれらを命名します(例えば、"certTemplate.subject"はcertTemplateと呼ばれる分野の中で対象の分野を意味します)。 8. 「SEQUENCE OFタイプ」がメッセージの一部であるところでは、無ベースの配列記法は、SEQUENCE OFの中で分野について説明するのに使用されます(例えば、crm[0].certReq.certTemplate.subjectは要求メッセージに含まれた最初のCertReqMsgの部分体について言及します)。 9. セクションB7-B10のすべてのPKI交換処理が開始実体によって送られるべきPKIConfirmメッセージを必要とします。 このメッセージはボディーがNULLであり、ヘッダー含有量が文脈から明確であるので与えられたプロフィールのいくつかに含まれていません。 protectionAlg(例えば、パスワードベースのMAC、共有秘密キー情報が知られているか、そして、または署名)にどんな認証された手段も使用できます。
B2. Algorithm Use Profile
B2。 使用が輪郭を描くアルゴリズム
The following table contains definitions of algorithm uses within PKI management protocols.
以下のテーブルはPKI管理プロトコルの中にアルゴリズム用途の定義を含んでいます。
The columns in the table are:
テーブルのコラムは以下の通りです。
Name: an identifier used for message profiles
Use: description of where and for what the algorithm is used
Mandatory: an AlgorithmIdentifier which MUST be supported by
conforming implementations
Others: alternatives to the mandatory AlgorithmIdentifier
以下を命名してください。 識別子はメッセージプロフィールにUseを使用しました: どこに関する記述とアルゴリズムがことのためのものであるか、中古のMandatory: 実装Othersを従わせることによってサポートしなければならないAlgorithmIdentifier: 義務的なAlgorithmIdentifierへの代替手段
Name Use Mandatory Others
義務的な他のものと使用を命名してください。
MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5...
messages using signature
MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC,
messages using MACing X9.9...
SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5,
an end entity's private EDE, CBC mode) CAST-128...
key where symmetric
key is distributed
out-of-band
PROT_ENC_ALG asymmetric algorithm D-H RSA
used for encryption of
(symmetric keys for
encryption of) private
keys transported in
PKIMessages
PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5,
algorithm used for EDE, CBC mode) CAST-128...
encryption of private
key bits (a key of this
_PKI DSA/SHA-1 RSA/MD5のMSG_SIG ALG Protection(PKI PasswordBasedMac HMACの署名MSG_MAC_ALG保護を使用するメッセージ、MACing X9.9を使用するメッセージ) キャスト-128が対称鍵がD-H RSAが暗号化に使用した分配されたバンドで出ているPROT_ENC_ALG非対称のアルゴリズムであるところに合わせる…3-DES(3主要なRC5、終わりの実体の個人的なEDE、CBCモード)のSYM_PENCの_のALGの左右対称の暗号化、(暗号化のための対称鍵、)、秘密鍵が秘密鍵ビットについてPKIMessages PROT_SYMの_のALGの左右対称の暗号化で3-DES(3主要なRC5、EDEに使用されるアルゴリズム、CBCモード)キャスト-128…暗号化を輸送した、(このキー
Adams & Farrell Standards Track [Page 50] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[50ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
type is encrypted using
PROT_ENC_ALG)
PROT_ENC_ALGを使用することで暗号化されたタイプ)
Mandatory AlgorithmIdentifiers and Specifications:
義務的なAlgorithmIdentifiersと仕様:
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
NIST, FIPS PUB 186: Digital Signature Standard, 1994;
Public Modulus size: 1024 bits.
DSA/SHA-1: 寒けがする: {1 2 840 10040 4 3}; NIST、FIPSパブ186: デジタル署名基準、1994。 公共のModulusサイズ: 1024ビット。
PasswordBasedMac:
{1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;
(this specification), along with
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995;
H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message
Authentication", Internet Request for Comments 2104, February 1997.
PasswordBasedMac: 1 2、840、113533、7、66 13、SHA-1、1 3、14、3 2、26、macパラメタとしてのowfパラメタとHMAC-SHA1 1 3 6 1 5 5 8 1 2として。 (この仕様), NIST、FIPSパブ180-1と共に: ハッシュ規格、1995年4月を確保してください。 H。 Krawczyk、M.Bellare、R.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」コメント2104、1997年2月を求めるインターネット要求。
3-DES:
{1 2 840 113549 3 7};
(used in RSA's BSAFE and in S/MIME).
3デス: {1 2 840 113549 3 7}; (RSAのBSAFEとS/MIMEでは、使用されます。)
D-H:
AlgId: {1 2 840 10046 2 1};
ANSI X9.42;
Public Modulus Size: 1024 bits.
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER -- g
}
D-H: 寒けがする: {1 2 840 10046 2 1}; ANSI X9.42。 公共の係数サイズ: 1024ビット。 DHParameter:、:= 系列主要なINTEGER--pベースINTEGER--g
B3. "Self-signed" certificates
B3。 証明書であると「自己に署名されます」。
Profile of how a Certificate structure may be "self-signed". These structures are used for distribution of "root" CA public keys. This can occur in one of three ways (see Section 2.4 above for a description of the use of these structures):
Certificate構造がどう「自己に署名されるかもしれないか」に関するプロフィール。 これらの構造は「根」カリフォルニア公開鍵の分配に使用されます。 これは3つの方法の1つで起こることができます(これらの構造の使用の記述において、セクション2.4が上であることを見てください):
Type Function
タイプ機能
newWithNew a true "self-signed" certificate; the contained public
key MUST be usable to verify the signature (though this
provides only integrity and no authentication whatsoever)
oldWithNew previous root CA public key signed with new private key
newWithOld new root CA public key signed with previous private key
newWithNew本当の「自己によって署名される」証明書。 含まれた公開鍵は新しい秘密鍵newWithOld新しい根のカリフォルニア公開鍵が前の秘密鍵を契約されている状態で前の根のカリフォルニア公開鍵が署名した署名(保全だけを提供しますが、これはどんな認証も全く提供しませんが)oldWithNewについて確かめるのにおいて使用可能であるに違いありません。
Adams & Farrell Standards Track [Page 51] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[51ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
<<Such certificates (including relevant extensions) must contain "sensible" values for all fields. For example, when present subjectAltName MUST be identical to issuerAltName, and when present keyIdentifiers must contain appropriate values, et cetera.>>
そのようなものが証明する(関連拡大を含んでいます)<<はすべての分野への「分別がある」値を含まなければなりません。 . 現在のsubjectAltNameが例えばissuerAltNameと同じでなければならなく、現在のkeyIdentifiersが適切な値を含まなければならないとき、など>>です。
B4. Proof of Possession Profile
B4。 所有物プロフィールの証拠
POP fields for use (in signature field of pop field of ProofOfPossession structure) when proving possession of a private signing key which corresponds to a public verification key for which a certificate has been requested.
個人的な署名の所有物が主要であると立証するときの証明書が要求されている公共の検証キーに対応する使用(ProofOfPossession構造の大衆的な分野の署名分野の)のためのPOP分野。
Field Value Comment
分野値のコメント
algorithmIdentifier MSG_SIG_ALG only signature protection is
allowed for this proof
signature present bits calculated using MSG_SIG_ALG
algorithmIdentifier MSG、_署名保護だけがこの証拠署名のために許されているSIG_ALGはMSG_SIG_ALGを使用することで計算されたビットを寄贈します。
<<Proof of possession of a private decryption key which corresponds to a public encryption key for which a certificate has been requested does not use this profile; instead the method given in protectionAlg for PKIConfirm in Section B8 is used.>>
証明書が要求されている公共の暗号化キーに対応する個人的な復号化キーの所持の<<証拠はこのプロフィールを使用しません。 代わりに、セクションB8のPKIConfirmのためにprotectionAlgで与えられたメソッドが使用されている、>>。
Not every CA/RA will do Proof-of-Possession (of signing key, decryption key, or key agreement key) in the PKIX-CMP in-band certification request protocol (how POP is done MAY ultimately be a policy issue which is made explicit for any given CA in its publicized Policy OID and Certification Practice Statement). However, this specification MANDATES that CA/RA entities MUST do POP (by some means) as part of the certification process. All end entities MUST be prepared to provide POP (i.e., these components of the PKIX-CMP protocol MUST be supported).
あらゆるカリフォルニア/RAがバンドにおけるPKIX-CMP証明要求プロトコルで所有物のProof(署名キーの復号化の主要であるか、主要な協定キー)をするというわけではないでしょう(結局、POPがどう完了しているかは、そのピーアールされたPolicy OIDとCertification Practice Statementのカリフォルニアを考えて、いずれにも明白にされる政策問題であるかもしれません)。 しかしながら、カリフォルニア/RA実体が証明の一部としてPOP(どうでも)をしなければならないこの仕様MANDATESは処理します。 POPを提供するようにすべての終わりの実体を準備しなければなりません(すなわち、PKIX-CMPプロトコルのこれらの成分をサポートしなければなりません)。
B5. Root CA Key Update
B5。 根のカリフォルニアキーアップデート
A root CA updates its key pair. It then produces a CA key update announcement message which can be made available (via one of the transport mechanisms) to the relevant end entities. A PKIConfirm message is NOT REQUIRED from the end entities.
根のカリフォルニアは主要な組をアップデートします。 そして、それは関連終わりの実体に利用可能に(移送機構の1つを通した)することができるカリフォルニアの主要なアップデート発表メッセージを出します。 PKIConfirmメッセージは終わりの実体からのNOT REQUIREDです。
ckuann message:
ckuannメッセージ:
Field Value Comment
分野値のコメント
sender CA name responding CA name
body ckuann(CAKeyUpdAnnContent)
oldWithNew present see Section B3 above
oldWithNewが提示する送付者カリフォルニア名前応じるカリフォルニア名前ボディーckuann(CAKeyUpdAnnContent)は、セクションB3が上であることを見ます。
Adams & Farrell Standards Track [Page 52] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[52ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
newWithOld present see Section B3 above
newWithNew present see Section B3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
the new private key)
現在のnewWithOldは、newWithNewプレゼントの上のセクションB3が、証明書を「発行すること」にextraCertsの上のB3が任意に提示するセクションを使用できるのを見るのを見ます。(例えば新しい秘密鍵を使用することで署名される証明書)
B6. PKI Information request/response
B6。 PKI情報要求/応答
The end entity sends general message to the PKI requesting details which will be required for later PKI management operations. RA/CA responds with general response. If an RA generates the response then it will simply forward the equivalent message which it previously received from the CA, with the possible addition of the certificates to the extraCerts fields of the PKIMessage. A PKIConfirm message is NOT REQUIRED from the end entity.
終わりの実体は後のPKI管理操作に必要である詳細を要求するPKIに一般的なメッセージを送ります。 RA/カリフォルニアは一般反応で応じます。 単に、以前にカリフォルニアから受け取った同等なメッセージを転送するでしょう、RAが応答を生成するならPKIMessageのextraCerts分野への証明書の可能な追加で。 PKIConfirmメッセージは終わりの実体からのNOT REQUIREDです。
Message Flows:
メッセージは流れます:
Step# End entity PKI
ステップ#End実体PKI
1 format genm 2 -> genm -> 3 handle genm 4 produce genp 5 <- genp <- 6 handle genp
1 形式genm2->genm->3ハンドルgenm4はgenp5<genp<6ハンドルgenpを生産します。
genm:
genm:
Field Value
分野値
recipient CA name -- the name of the CA as contained in issuerAltName extensions or -- issuer fields within certificates protectionAlg MSG_MAC_ALG or MSG_SIG_ALG -- any authenticated protection alg. SenderKID present if required -- must be present if required for verification of message protection freeText any valid value body genr (GenReqContent) GenMsgContent empty SEQUENCE -- all relevant information requested protection present -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
受取人カリフォルニア名--issuerAltName拡張子か--証明書protectionAlg MSG_MAC_ALGかMSG_SIG_ALGの中の発行人分野--いずれの含まれるとしてのカリフォルニアの名前は保護algを認証しました。 必要なら、必要ならメッセージ保護freeTextの検証へのプレゼントがどんな有効値本体のgenr(GenReqContent)のGenMsgContentの空のSEQUENCEであったに違いないならすべて関連情報要求された保護現在のSenderKIDプレゼント--MSG_MAC_ALGかMSG_SIG_ALGを使用することで計算されたビット
Adams & Farrell Standards Track [Page 53] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[53ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
genp:
genp:
Field Value
分野値
sender CA name
-- name of the CA which produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for the CA
-- (e.g., private key for recovery purposes)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers which this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers which
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm which this CA expects to be used in later
-- PKI messages (for encryption)
CAKeyUpdateInfo optionally present, with
relevant value
-- the CA MAY provide information about a relevant root CA key pair
-- using this field (note that this does not imply that the responding
-- CA is the root CA in question)
CurrentCRL optionally present, with relevant value
-- the CA MAY provide a copy of a complete CRL (i.e., fullest possible
-- one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end entity. An RA MAY
-- add its certificate here.
送付者カリフォルニア名--メッセージのprotectionAlg MSG_MAC_ALGかMSG_SIG_ALGを生産したカリフォルニアの名前--いずれも必要なら、alg. senderKIDが提示する保護を認証しました--必要ならメッセージ保護ボディーgenp(GenRepContent)の検証へのプレゼントがCAProtEncCertであったに違いないなら、関連値で(PROT_ENC_ALGに関するオブジェクト識別子1)を提示してください--終わりの実体が、カリフォルニアのための情報を暗号化する必要があるなら使用されるために--関連値の現在の(例えば、回復目的のための秘密鍵)SignKeyPairTypes; このカリフォルニアがそうする署名アルゴリズム識別子のセット--対象の公開鍵のためにEncKeyPairTypesが存在しているのを公認してください、関連値で--暗号化/のセットが協定アルゴリズム識別子を合わせる、どれですか?; このカリフォルニアは、対象の公開鍵のためにPreferredSymmAlgが存在しているのを(PROT_SYM_ALGに関するオブジェクト識別子1)公認するでしょう、関連値--このカリフォルニアが中で使用されて、後でPKIメッセージ(暗号化のための)CAKeyUpdateInfoが関連することで任意に値を提示するということであると予想する左右対称のアルゴリズム--カリフォルニアMAと共にこれが、カリフォルニアは問題のカリフォルニア) CurrentCRLが任意に提示する根です、関連値でカリフォルニアがそうする応じるのが完全なCRLのコピーを提供するのを含意しないことに注意してください。この分野を使用して、Yが関連根のカリフォルニア重要組の情報を提供する、((すなわち、終わりの実体への証明書をいくつか送るMAC_ALGかMSG_SIG_ALG extraCertsが任意に寄贈するMSG_--使用できるのを使用することで計算された可能な限り(1つ) 保護プレゼント)ふくよかなビット。 RA MAY--ここで証明書を加えてください。
B7. Cross certification request/response (1-way)
B7。 相互認証要求/応答(1ウェイ)
Creation of a single cross-certificate (i.e., not two at once). The requesting CA MAY choose who is responsible for publication of the cross-certificate created by the responding CA through use of the PKIPublicationInfo control.
ただ一つの交差している証明書の作成、(すなわち、2でない、すぐに) 要求カリフォルニアは、だれがPKIPublicationInfoコントロールの使用で応じるカリフォルニアによって作成された交差している証明書の公表に責任があるかを選ぶかもしれません。
Adams & Farrell Standards Track [Page 54] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[54ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Preconditions:
前提条件:
1. Responding CA can verify the origin of the request (possibly
requiring out-of-band means) before processing the request.
2. Requesting CA can authenticate the authenticity of the origin of
the response (possibly requiring out-of-band means) before
processing the response
1. カリフォルニアを反応させると、要求を処理する前に、要求(ことによると、バンドの外では、手段を必要とする)の発生源について確かめることができます。 2. 応答を処理する前にカリフォルニアが応答(ことによると、バンドの外では、手段を必要とする)の発生源の信憑性を認証できるよう要求します。
Message Flows:
メッセージは流れます:
Step# Requesting CA Responding CA 1 format ccr 2 -> ccr -> 3 handle ccr 4 produce ccp 5 <- ccp <- 6 handle ccp 7 format conf 8 -> conf -> 9 handle conf
Step# Requesting CA Responding CA 1 format ccr 2 -> ccr -> 3 handle ccr 4 produce ccp 5 <- ccp <- 6 handle ccp 7 format conf 8 -> conf -> 9 handle conf
ccr: Field Value
ccr: Field Value
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
certTemplate present
sender Requesting CA name -- the name of the CA who produced the message recipient Responding CA name -- the name of the CA who is being asked to produce a certificate messageTime time of production of message -- current time at requesting CA protectionAlg MSG_SIG_ALG -- only signature protection is allowed for this request senderKID present if required -- must be present if required for verification of message protection transactionID present -- implementation-specific value, meaningful to requesting CA. -- [If already in use at responding CA then a rejection message -- MUST be produced by responding CA] senderNonce present -- 128 (pseudo-)random bits freeText any valid value body ccr (CertReqMessages) only one CertReqMsg allowed -- if multiple cross certificates are required they MUST be packaged -- in separate PKIMessages certTemplate present
Adams & Farrell Standards Track [Page 55] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 55] RFC 2510 PKI Certificate Management Protocols March 1999
-- details follow version v1 or v3 -- <<v3 STRONGLY RECOMMENDED>> signingAlg present -- the requesting CA must know in advance with which algorithm it -- wishes the certificate to be signed subject present -- may be NULL-DN only if subjectAltNames extension value proposed validity present -- MUST be completely specified (i.e., both fields present) issuer present -- may be NULL-DN only if issuerAltNames extension value proposed publicKey present -- the key to be certified (which must be for a signing algorithm) extensions optionally present -- a requesting CA must propose values for all extensions which it -- requires to be in the cross-certificate
-- details follow version v1 or v3 -- <<v3 STRONGLY RECOMMENDED>> signingAlg present -- the requesting CA must know in advance with which algorithm it -- wishes the certificate to be signed subject present -- may be NULL-DN only if subjectAltNames extension value proposed validity present -- MUST be completely specified (i.e., both fields present) issuer present -- may be NULL-DN only if issuerAltNames extension value proposed publicKey present -- the key to be certified (which must be for a signing algorithm) extensions optionally present -- a requesting CA must propose values for all extensions which it -- requires to be in the cross-certificate
POPOSigningKey present -- see "Proof of possession profile" (Section B4)
POPOSigningKey present -- see "Proof of possession profile" (Section B4)
protection present -- bits calculated using MSG_SIG_ALG extraCerts optionally present -- MAY contain any additional certificates that requester wishes -- to include
protection present -- bits calculated using MSG_SIG_ALG extraCerts optionally present -- MAY contain any additional certificates that requester wishes -- to include
ccp: Field Value
ccp: Field Value
sender Responding CA name -- the name of the CA who produced the message recipient Requesting CA name -- the name of the CA who asked for production of a certificate messageTime time of production of message -- current time at responding CA protectionAlg MSG_SIG_ALG -- only signature protection is allowed for this message senderKID present if required -- must be present if required for verification of message -- protection recipKID present if required transactionID present -- value from corresponding ccr message senderNonce present -- 128 (pseudo-)random bits recipNonce present
sender Responding CA name -- the name of the CA who produced the message recipient Requesting CA name -- the name of the CA who asked for production of a certificate messageTime time of production of message -- current time at responding CA protectionAlg MSG_SIG_ALG -- only signature protection is allowed for this message senderKID present if required -- must be present if required for verification of message -- protection recipKID present if required transactionID present -- value from corresponding ccr message senderNonce present -- 128 (pseudo-)random bits recipNonce present
Adams & Farrell Standards Track [Page 56] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 56] RFC 2510 PKI Certificate Management Protocols March 1999
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
response present
status present
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- granted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST be absent
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection
-- then certifiedKeyPair MUST be absent and failInfo MUST be present
-- and contain appropriate bit settings
-- senderNonce from corresponding ccr message freeText any valid value body ccp (CertRepMessage) only one CertResponse allowed -- if multiple cross certificates are required they MUST be packaged -- in separate PKIMessages response present status present PKIStatusInfo.status present -- if PKIStatusInfo.status is one of: -- granted, or -- grantedWithMods, -- then certifiedKeyPair MUST be present and failInfo MUST be absent failInfo present depending on PKIStatusInfo.status -- if PKIStatusInfo.status is: -- rejection -- then certifiedKeyPair MUST be absent and failInfo MUST be present -- and contain appropriate bit settings
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
certifiedKeyPair present depending on PKIStatusInfo.status certificate present depending on certifiedKeyPair -- content of actual certificate must be examined by requesting CA -- before publication
protection present -- bits calculated using MSG_SIG_ALG extraCerts optionally present -- MAY contain any additional certificates that responder wishes -- to include
protection present -- bits calculated using MSG_SIG_ALG extraCerts optionally present -- MAY contain any additional certificates that responder wishes -- to include
B8. Initial Registration/Certification (Basic Authenticated Scheme)
B8. Initial Registration/Certification (Basic Authenticated Scheme)
An (uninitialized) end entity requests a (first) certificate from a CA. When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
An (uninitialized) end entity requests a (first) certificate from a CA. When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
This scheme allows the end entity to request certification of a locally-generated public key (typically a signature key). The end entity MAY also choose to request the centralized generation and certification of another key pair (typically an encryption key pair).
This scheme allows the end entity to request certification of a locally-generated public key (typically a signature key). The end entity MAY also choose to request the centralized generation and certification of another key pair (typically an encryption key pair).
Certification may only be requested for one locally generated public key (for more, use separate PKIMessages).
Certification may only be requested for one locally generated public key (for more, use separate PKIMessages).
Adams & Farrell Standards Track [Page 57] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 57] RFC 2510 PKI Certificate Management Protocols March 1999
The end entity MUST support proof-of-possession of the private key associated with the locally-generated public key.
The end entity MUST support proof-of-possession of the private key associated with the locally-generated public key.
Preconditions:
Preconditions:
1. The end entity can authenticate the CA's signature based on
out-of-band means
2. The end entity and the CA share a symmetric MACing key
1. The end entity can authenticate the CA's signature based on out-of-band means 2. The end entity and the CA share a symmetric MACing key
Message flow:
Message flow:
Step# End entity PKI
1 format ir
2 -> ir ->
3 handle ir
4 format ip
5 <- ip <-
6 handle ip
7 format conf
8 -> conf ->
9 handle conf
Step# End entity PKI 1 format ir 2 -> ir -> 3 handle ir 4 format ip 5 <- ip <- 6 handle ip 7 format conf 8 -> conf -> 9 handle conf
For this profile, we mandate that the end entity MUST include all (i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI (CA) MUST produce a single response PKIMessage which contains the complete response (i.e., including the OPTIONAL second key pair, if it was requested and if centralized key generation is supported). For simplicity, we also mandate that this message MUST be the final one (i.e., no use of "waiting" status value).
For this profile, we mandate that the end entity MUST include all (i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI (CA) MUST produce a single response PKIMessage which contains the complete response (i.e., including the OPTIONAL second key pair, if it was requested and if centralized key generation is supported). For simplicity, we also mandate that this message MUST be the final one (i.e., no use of "waiting" status value).
ir: Field Value
ir: Field Value
recipient CA name -- the name of the CA who is being asked to produce a certificate protectionAlg MSG_MAC_ALG -- only MAC protection is allowed for this request, based on -- initial authentication key senderKID referenceNum -- the reference number which the CA has previously issued to -- the end entity (together with the MACing key) transactionID present -- implementation-specific value, meaningful to end entity. -- [If already in use at the CA then a rejection message MUST be -- produced by the CA] senderNonce present -- 128 (pseudo-)random bits freeText any valid value
recipient CA name -- the name of the CA who is being asked to produce a certificate protectionAlg MSG_MAC_ALG -- only MAC protection is allowed for this request, based on -- initial authentication key senderKID referenceNum -- the reference number which the CA has previously issued to -- the end entity (together with the MACing key) transactionID present -- implementation-specific value, meaningful to end entity. -- [If already in use at the CA then a rejection message MUST be -- produced by the CA] senderNonce present -- 128 (pseudo-)random bits freeText any valid value
Adams & Farrell Standards Track [Page 58] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 58] RFC 2510 PKI Certificate Management Protocols March 1999
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required requests MUST be packaged in
-- separate PKIMessages
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first (which MUST
-- be present), crm[1] means the second (which is OPTIONAL, and used
-- to ask for a centrally-generated key)
body ir (CertReqMessages) only one or two CertReqMsg are allowed -- if more certificates are required requests MUST be packaged in -- separate PKIMessages CertReqMsg one or two present -- see below for details, note: crm[0] means the first (which MUST -- be present), crm[1] means the second (which is OPTIONAL, and used -- to ask for a centrally-generated key)
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- proof of possession MAY be required in this exchange (see Section
-- B4 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally-generated private key
-- be archived
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[0].certReq. fixed value of zero certReqId -- this is the index of the template within the message crm[0].certReq present certTemplate -- MUST include subject public key value, otherwise unconstrained crm[0].pop... optionally present if public key POPOSigningKey from crm[0].certReq.certTemplate is a signing key -- proof of possession MAY be required in this exchange (see Section -- B4 for details) crm[0].certReq. optionally present controls.archiveOptions -- the end entity MAY request that the locally-generated private key -- be archived crm[0].certReq. optionally present controls.publicationInfo -- the end entity MAY ask for publication of resulting cert.
crm[1].certReq fixed value of one certReqId -- the index of the template within the message crm[1].certReq present certTemplate -- MUST NOT include actual public key bits, otherwise unconstrained -- (e.g., the names need not be the same as in crm[0]) crm[0].certReq. present [object identifier MUST be PROT_ENC_ALG] controls.protocolEncKey -- if centralized key generation is supported by this CA, this -- short-term asymmetric encryption key (generated by the end entity) -- will be used by the CA to encrypt (a symmetric key used to encrypt) -- a private key generated by the CA on behalf of the end entity crm[1].certReq. optionally present controls.archiveOptions crm[1].certReq. optionally present controls.publicationInfo protection present -- bits calculated using MSG_MAC_ALG
crm[1].certReq fixed value of one certReqId -- the index of the template within the message crm[1].certReq present certTemplate -- MUST NOT include actual public key bits, otherwise unconstrained -- (e.g., the names need not be the same as in crm[0]) crm[0].certReq. present [object identifier MUST be PROT_ENC_ALG] controls.protocolEncKey -- if centralized key generation is supported by this CA, this -- short-term asymmetric encryption key (generated by the end entity) -- will be used by the CA to encrypt (a symmetric key used to encrypt) -- a private key generated by the CA on behalf of the end entity crm[1].certReq. optionally present controls.archiveOptions crm[1].certReq. optionally present controls.publicationInfo protection present -- bits calculated using MSG_MAC_ALG
Adams & Farrell Standards Track [Page 59] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 59] RFC 2510 PKI Certificate Management Protocols March 1999
ip: Field Value
ip: Field Value
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MS_MAC_ALG
-- only MAC protection is allowed for this response
recipKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
body ir (CertRepMessage)
contains exactly one response
for each request
-- The PKI (CA) responds to either one or two requests as appropriate.
-- crc[0] denotes the first (always present); crc[1] denotes the
-- second (only present if the ir message contained two requests and
-- if the CA supports centralized key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the corresponding
-- ir message
crc[0].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"granted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
sender CA name -- the name of the CA who produced the message messageTime present -- time at which CA produced message protectionAlg MS_MAC_ALG -- only MAC protection is allowed for this response recipKID referenceNum -- the reference number which the CA has previously issued to the -- end entity (together with the MACing key) transactionID present -- value from corresponding ir message senderNonce present -- 128 (pseudo-)random bits recipNonce present -- value from senderNonce in corresponding ir message freeText any valid value body ir (CertRepMessage) contains exactly one response for each request -- The PKI (CA) responds to either one or two requests as appropriate. -- crc[0] denotes the first (always present); crc[1] denotes the -- second (only present if the ir message contained two requests and -- if the CA supports centralized key generation). crc[0]. fixed value of zero certReqId -- MUST contain the response to the first request in the corresponding -- ir message crc[0].status. present, positive values allowed: status "granted", "grantedWithMods" negative values allowed: "rejection" crc[0].status. present if and only if failInfo crc[0].status.status is "rejection" crc[0]. present if and only if certifiedKeyPair crc[0].status.status is "granted" or "grantedWithMods" certificate present unless end entity's public key is an encryption key and POP is done in this in-band exchange encryptedCert present if and only if end entity's public key is an encryption key and POP done in this in-band exchange publicationInfo optionally present -- indicates where certificate has been published (present at -- discretion of CA)
Adams & Farrell Standards Track [Page 60] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 60] RFC 2510 PKI Certificate Management Protocols March 1999
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "granted"
or "grantedWithMods"
certificate present
privateKey present
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end entity
crc[1]. fixed value of one certReqId -- MUST contain the response to the second request in the -- corresponding ir message crc[1].status. present, positive values allowed: status "granted", "grantedWithMods" negative values allowed: "rejection" crc[1].status. present if and only if failInfo crc[0].status.status is "rejection" crc[1]. present if and only if certifiedKeyPair crc[0].status.status is "granted" or "grantedWithMods" certificate present privateKey present publicationInfo optionally present -- indicates where certificate has been published (present at -- discretion of CA) protection present -- bits calculated using MSG_MAC_ALG extraCerts optionally present -- the CA MAY provide additional certificates to the end entity
conf: Field Value
conf: Field Value
recipient CA name -- the name of the CA who was asked to produce a certificate transactionID present -- value from corresponding ir and ip messages senderNonce present -- value from recipNonce in corresponding ip message recipNonce present -- value from senderNonce in corresponding ip message protectionAlg MSG_MAC_ALG -- only MAC protection is allowed for this message. The MAC is -- based on the initial authentication key if only a signing key -- pair has been sent in ir for certification, or if POP is not -- done in this in-band exchange. Otherwise, the MAC is based on -- a key derived from the symmetric key used to decrypt the -- returned encryptedCert. senderKID referenceNum -- the reference number which the CA has previously issued to the -- end entity (together with the MACing key) body conf (PKIConfirmContent) -- this is an ASN.1 NULL protection present -- bits calculated using MSG_MAC_ALG
recipient CA name -- the name of the CA who was asked to produce a certificate transactionID present -- value from corresponding ir and ip messages senderNonce present -- value from recipNonce in corresponding ip message recipNonce present -- value from senderNonce in corresponding ip message protectionAlg MSG_MAC_ALG -- only MAC protection is allowed for this message. The MAC is -- based on the initial authentication key if only a signing key -- pair has been sent in ir for certification, or if POP is not -- done in this in-band exchange. Otherwise, the MAC is based on -- a key derived from the symmetric key used to decrypt the -- returned encryptedCert. senderKID referenceNum -- the reference number which the CA has previously issued to the -- end entity (together with the MACing key) body conf (PKIConfirmContent) -- this is an ASN.1 NULL protection present -- bits calculated using MSG_MAC_ALG
Adams & Farrell Standards Track [Page 61] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 61] RFC 2510 PKI Certificate Management Protocols March 1999
B9. Certificate Request
B9. Certificate Request
An (initialized) end entity requests a certificate from a CA (for any reason). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
An (initialized) end entity requests a certificate from a CA (for any reason). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
The profile for this exchange is identical to that given in Section B8 with the following exceptions:
The profile for this exchange is identical to that given in Section B8 with the following exceptions:
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request,
response, and confirm messages (the determination in the confirm
message being dependent upon POP considerations for key-
encipherment and key- agreement certificate requests);
- senderKID and recipKID are only present if required for message
verification;
- body is cr or cp;
- protocolEncKey is not present;
- protection bits are calculated according to the protectionAlg
field.
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, response, and confirm messages (the determination in the confirm message being dependent upon POP considerations for key- encipherment and key- agreement certificate requests); - senderKID and recipKID are only present if required for message verification; - body is cr or cp; - protocolEncKey is not present; - protection bits are calculated according to the protectionAlg field.
B10. Key Update Request
B10. Key Update Request
An (initialized) end entity requests a certificate from a CA (to update the key pair and corresponding certificate that it already possesses). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
An (initialized) end entity requests a certificate from a CA (to update the key pair and corresponding certificate that it already possesses). When the CA responds with a message containing a certificate, the end entity replies with a confirmation. All messages are authenticated.
The profile for this exchange is identical to that given in Section B8 with the following exceptions:
The profile for this exchange is identical to that given in Section B8 with the following exceptions:
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request,
response, and confirm messages (the determination in the confirm
message being dependent upon POP considerations for key-
encipherment and key- agreement certificate requests);
- senderKID and recipKID are only present if required for message
verification;
- body is kur or kup;
- protection bits are calculated according to the protectionAlg
field.
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request, response, and confirm messages (the determination in the confirm message being dependent upon POP considerations for key- encipherment and key- agreement certificate requests); - senderKID and recipKID are only present if required for message verification; - body is kur or kup; - protection bits are calculated according to the protectionAlg field.
Adams & Farrell Standards Track [Page 62] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 62] RFC 2510 PKI Certificate Management Protocols March 1999
Appendix C: "Compilable" ASN.1 Module using 1988 Syntax
Appendix C: "Compilable" ASN.1 Module using 1988 Syntax
PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)}
PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)}
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
BEGIN
-- EXPORTS ALL --
-- EXPORTS ALL --
IMPORTS
IMPORTS
Certificate, CertificateList, Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}}
Certificate, CertificateList, Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}}
GeneralName, KeyIdentifier, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
GeneralName, KeyIdentifier, ReasonFlags FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf(5)}}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId, CertReqMessages FROM PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}}
-- CertificationRequest
-- FROM PKCS10 {no standard ASN.1 module defined;
-- implementers need to create their own module to import
-- from, or directly include the PKCS10 syntax in this module}
-- CertificationRequest -- FROM PKCS10 {no standard ASN.1 module defined; -- implementers need to create their own module to import -- from, or directly include the PKCS10 syntax in this module}
-- Locally defined OIDs --
-- Locally defined OIDs --
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL }
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
PKIHeader ::= SEQUENCE { pvno INTEGER { ietf-version2 (1) }, sender GeneralName, -- identifies the sender recipient GeneralName,
Adams & Farrell Standards Track [Page 63] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 63] RFC 2510 PKI Certificate Management Protocols March 1999
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
-- identifies the intended recipient messageTime [0] GeneralizedTime OPTIONAL, -- time of production of this message (used when sender -- believes that the transport will be "suitable"; i.e., -- that the time will still be meaningful upon receipt) protectionAlg [1] AlgorithmIdentifier OPTIONAL, -- algorithm used for calculation of protection bits senderKID [2] KeyIdentifier OPTIONAL, recipKID [3] KeyIdentifier OPTIONAL, -- to identify specific keys used for protection transactionID [4] OCTET STRING OPTIONAL, -- identifies the transaction; i.e., this will be the same in -- corresponding request, response and confirmation messages senderNonce [5] OCTET STRING OPTIONAL, recipNonce [6] OCTET STRING OPTIONAL, -- nonces used to provide replay protection, senderNonce -- is inserted by the creator of this message; recipNonce -- is a nonce previously inserted in a related message by -- the intended recipient of this message freeText [7] PKIFreeText OPTIONAL, -- this may be used to indicate context-specific instructions -- (this field is intended for human consumption) generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL -- this may be used to convey context-specific information -- (this field not primarily intended for human consumption) }
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC 1766 language tag to indicate the language
-- of the contained text)
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String -- text encoded as UTF-8 String (note: each UTF8String SHOULD -- include an RFC 1766 language tag to indicate the language -- of the contained text)
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --imported from [PKCS10]
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
PKIBody ::= CHOICE { -- message-specific body elements ir [0] CertReqMessages, --Initialization Request ip [1] CertRepMessage, --Initialization Response cr [2] CertReqMessages, --Certification Request cp [3] CertRepMessage, --Certification Response p10cr [4] CertificationRequest, --imported from [PKCS10] popdecc [5] POPODecKeyChallContent, --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response kur [7] CertReqMessages, --Key Update Request kup [8] CertRepMessage, --Key Update Response krr [9] CertReqMessages, --Key Recovery Request krp [10] KeyRecRepContent, --Key Recovery Response rr [11] RevReqContent, --Revocation Request rp [12] RevRepContent, --Revocation Response
Adams & Farrell Standards Track [Page 64] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 64] RFC 2510 PKI Certificate Management Protocols March 1999
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Response
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
conf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent --Error Message
}
ccr [13] CertReqMessages, --Cross-Cert. Request ccp [14] CertRepMessage, --Cross-Cert. Response ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. cann [16] CertAnnContent, --Certificate Ann. rann [17] RevAnnContent, --Revocation Ann. crlann [18] CRLAnnContent, --CRL Announcement conf [19] PKIConfirmContent, --Confirmation nested [20] NestedMessageContent, --Nested Message genm [21] GenMsgContent, --General Message genp [22] GenRepContent, --General Response error [23] ErrorMsgContent --Error Message }
PKIProtection ::= BIT STRING
PKIProtection ::= BIT STRING
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody }
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended) iterationCount INTEGER, -- number of times the OWF is applied mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [RFC2104, RFC2202])
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBMParameter ::= SEQUENCE { owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended) mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [RFC2104, RFC2202])
NestedMessageContent ::= PKIMessage
NestedMessageContent ::= PKIMessage
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
PKIStatus ::= INTEGER { granted (0), -- you got exactly what you asked for grantedWithMods (1),
Adams & Farrell Standards Track [Page 65] RFC 2510 PKI Certificate Management Protocols March 1999
Adams & Farrell Standards Track [Page 65] RFC 2510 PKI Certificate Management Protocols March 1999
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- CertReqMsg
}
-- you got something like what you asked for; the -- requester is responsible for ascertaining the differences rejection (2), -- you don't get it, more information elsewhere in the message waiting (3), -- the request body part has not yet been processed, -- expect to hear more later revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5), -- notification that a revocation has occurred keyUpdateWarning (6) -- update already done for the oldCertId specified in -- CertReqMsg }
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIFailureInfo:、:= ビット列{ -- 以来、私たちは1つ以上の方法に失敗できます! -- より多くのコードが/であるなら必要であると将来、加えられるかもしれません。badAlg(0)--認識されていないかサポートされないAlgorithm Identifier badMessageCheck(1)--保全チェックが失敗した、(例えば、署名が確かめなかった、)、badRequest(2)--取引は、badTime(3)を可能にもしませんでしたし、支持もしませんでした--messageTimeが地方の方針badCertId(4)によって定義されるようにシステム時間の十分近くにありませんでした; 提出されたデータが間違った形式wrongAuthority(6)を持っているという権威が要求で示したbadDataFormat(5)が異なっている提供された評価基準を合わせているのを証明書を全く見つけることができなかった、リクエスタの--応答象徴incorrectData(7)を作成する1つ--データが不正確な(公証人サービスのための)missingTimeStamp(8)である(タイムスタンプであるときに、そこ(方針で)にあるべきであるのを除いて、消えるのは、badPOP(9)です)、所有物の証拠は失敗しました。}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
PKIStatusInfo:、:= SEQUENCE、状態PKIStatus、statusString PKIFreeText OPTIONAL、failInfo PKIFailureInfo OPTIONAL
Adams & Farrell Standards Track [Page 66] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[66ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
}
}
OOBCert ::= Certificate
OOBCert:、:= 証明書
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over DER encoding of the
-- subjectPublicKey field of the corresponding cert.
}
OOBCertHash:、:= 系列hashAlg[0]AlgorithmIdentifier OPTIONAL、certId[1]CertId OPTIONAL、hashVal BIT STRING--、hashValがDERコード化に関して計算される、--対応する本命のsubjectPublicKey分野。
POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption key certification request (in the -- same order as these requests appear in CertReqMessages).
POPODecKeyChallContent:、:= 中、SEQUENCE OF Challenge、暗号化の主要な証明要求あたりの1つのChallenge、(--、これらの要求としてのオーダーがCertReqMessagesで見える同じこと)
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
以下に挑戦してください:= 系列owf AlgorithmIdentifier OPTIONAL--POPODecKeyChallContentで最初のChallengeで--いずれでも省略されるかもしれない;その後のChallengeを寄贈することでなければならない、(省略される、--、次にすぐに前のChallengeで使用されるowfはそうです--使用されるために). OCTET STRING--一方向関数(owf)をaに適用するという結果--手当たりしだいに発生しているINTEGER、A.を目撃してください、[注意、aそんなに異なる--、INTEGER MUST、各Challenge] 挑戦OCTET STRINGには、使用されてください--、暗号化(公開鍵、どれ、本命。 -- 要求をしています。) Rand(底ならし革: : {の--int INTEGER----手当たりしだいに発生しているINTEGER A(above)(送付者GeneralName)--送付者=SEQUENCEの名前(PKIHeaderに含まれているように))。(そこでは、Randが指定されます)。
POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge.
POPODecKeyRespContent:、:= 中、SEQUENCE OF INTEGER、暗号化の主要な証明要求あたりの1つのINTEGER、(--、これらの要求としてのオーダーがCertReqMessagesで見える同じこと) --、(above)が送付者に返されるINTEGER Aを検索する、--対応するChallenge。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage:、:= 系列caPubs[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL、応答SEQUENCE OF CertResponse
Adams & Farrell Standards Track [Page 67] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[67ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertResponse:、:= 系列対応するこの応答が要求するマッチへのcertReqId INTEGER、(値--certReqIdが中で指定されないなら-1に、使用されることになっていてください、--、対応する要求) 状態PKIStatusInfo、certifiedKeyPair CertifiedKeyPair OPTIONAL、CertReqMsgのregInfoのための定義されたイド-regInfo-asciiPairs OCTET STRING[CRMF]への類似のrspInfo OCTET STRING OPTIONAL
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair:、:= 系列privateKey[0]EncryptedValue任意の、そして、publicationInfo[1]PKIPublicationInfo任意のcertOrEncCert CertOrEncCert
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert:、:= 選択証明書[0]証明書、encryptedCert[1]EncryptedValue
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent:、:= 系列状態PKIStatusInfo、newSigCert[0]はOPTIONALを証明します、caCerts[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL、keyPairHist[2]SEQUENCE SIZE(1..MAX)OF CertifiedKeyPair OPTIONAL
RevReqContent ::= SEQUENCE OF RevDetails
RevReqContent:、:= RevDetailsの系列
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevDetails:、:= 系列certDetails CertTemplate--リクエスタが指定するのを周囲に許容できるくらい許容します--、本命、取消しは要求されています--(例えば、serialNumberが利用可能でない場合のための)revocationReason ReasonFlags OPTIONAL(取消しが要求されたbadSinceDate GeneralizedTime OPTIONALである理由)は示します中で送付者crlEntryDetails Extensions OPTIONAL--crlEntryExtensionsを要求するのに関する知識最も良い。
RevRepContent ::= SEQUENCE {
RevRepContent:、:= 系列
Adams & Farrell Standards Track [Page 68] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[68ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
状態SEQUENCE SIZE(1..MAX)OF PKIStatusInfo--RevReqContent revCerts[0]SEQUENCE SIZE(1..MAX)OF CertId OPTIONALで送られたコネ同じ注文--取消しがこと(同じことは状態) crls[1]SEQUENCE SIZE(1..MAX)OF CertificateList OPTIONALとして注文されます--結果として起こるCRLs(1つ以上があるかもしれない)}要求されていて、であったID
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
CAKeyUpdAnnContent:、:= 系列{oldWithNew Certificate--新しいpriv newWithOld Certificateを契約された古いパブ--新しいパブは古いpriv newWithNew Certificateと契約しました--新しいprivを契約された新しいパブ}
CertAnnContent ::= Certificate
CertAnnContent:、:= 証明書
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
RevAnnContent:、:= 系列状態PKIStatus、certId CertId、willBeRevokedAt GeneralizedTime、badSinceDate GeneralizedTime、crlDetails Extensions OPTIONAL、--余分なCRLが(例えば、crl番号、理由、位置など)を詳しく述べる
CRLAnnContent ::= SEQUENCE OF CertificateList
CRLAnnContent:、:= CertificateListの系列
PKIConfirmContent ::= NULL
PKIConfirmContent:、:= ヌル
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
InfoTypeAndValue:、:= SEQUENCE、infoType OBJECT IDENTIFIER、infoValue、どんなDEFINED BY infoType OPTIONAL、も--含んでいますが、例のInfoTypeAndValue内容は制限されません: -- または、CurrentCRLが等しい、イド、-、それ、6、CertificateList、--、どこ、イド、-、それ、= イド-pkix4は1 3 6 1 5 5 7 4と等しいです--また、この構造物が新しいPKIX Certificate--管理プロトコル要求と応答メッセージか、一般--将来の必要性への目的(例えば、発表)メッセージを定義するのに使用されるかもしれないか、--特定の環境。
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
GenMsgContent:、:= InfoTypeAndValueの系列
Adams & Farrell Standards Track [Page 69] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[69ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
-- May be sent by EE, RA, or CA (depending on message content). -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically -- be omitted for some of the examples given above. The receiver is -- free to ignore any contained OBJ. IDs that it does not recognize. -- If sent from EE to CA, the empty set indicates that the CA may send -- any/all information that it wishes.
-- EE、RA、またはカリフォルニアによって送られるかもしれません(メッセージ内容によって)。 -- InfoTypeAndValueのOPTIONAL infoValueパラメタは通常そうするでしょう--上に出された例のいくつかには、省略されてください。 受信機があります--どんな含まれたOBJも無視するのにおいて、自由です。 それが認識しないID。 -- EEからカリフォルニアに送るなら、空集合が、カリフォルニアがいくらか発信するかもしれないのを示す、/、願っているというすべての情報。
GenRepContent ::= SEQUENCE OF InfoTypeAndValue -- The receiver is free to ignore any contained OBJ. IDs that it does -- not recognize.
GenRepContent:、:= SEQUENCE OF InfoTypeAndValue--受信機は無料でどんな含まれたOBJも無視できます。 それがするID--認識しません。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
ErrorMsgContent:、:= 系列pKIStatusInfo PKIStatusInfo、errorCode INTEGER OPTIONAL--実現特有のエラーコードerrorDetails PKIFreeText OPTIONAL--実現特有の誤りの詳細
-- The following definition is provided for compatibility reasons with -- 1988 and 1993 ASN.1 compilers which allow the use of UNIVERSAL class -- tags (not a part of formal ASN.1); 1997 and subsequent compilers -- SHOULD comment out this line.
-- 互換性がタグ(正式なASN.1の一部でない)の道理を説くので(UNIVERSALのクラスの使用を許す1988と1993ASN.1コンパイラ)、以下の定義を提供します。 1997 その後のコンパイラ--そして、これから、立ち並んでいますSHOULDが、論評する。
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
UTF8String:、:= [普遍的な12]内在している八重奏ストリング
END
終わり
Adams & Farrell Standards Track [Page 70] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[70ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Appendix D: Registration of MIME Type for Section 5
付録D: セクション5のためのMIMEの種類の登録
To: ietf-types@iana.org Subject: Registration of MIME media type application/pkixcmp
To: ietf-types@iana.org Subject: MIMEメディアタイプアプリケーション/pkixcmpの登録
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: pkixcmp
MIME「副-タイプ」は以下を命名します。 pkixcmp
Required parameters: -
必要なパラメタ: -
Optional parameters: -
任意のパラメタ: -
Encoding considerations: Content may contain arbitrary octet values (the ASN.1 DER encoding of a PKI message, as defined in the IETF PKIX Working Group specifications). base64 encoding is required for MIME e-mail; no encoding is necessary for HTTP.
問題をコード化します: 内容は任意の八重奏値(IETF PKIX作業部会仕様に基づき定義されるようにPKIメッセージをコード化するASN.1DER)を含むかもしれません。base64コード化がMIMEメールに必要です。 コード化はHTTPに必要ではありません。
Security considerations: This MIME type may be used to transport Public-Key Infrastructure (PKI) messages between PKI entities. These messages are defined by the IETF PKIX Working Group and are used to establish and maintain an Internet X.509 PKI. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages themselves are protected as defined in the PKIX specifications.
セキュリティ問題: このMIMEの種類は、PKI実体の間の公開鍵暗号基盤(PKI)メッセージを輸送するのに使用されるかもしれません。 これらのメッセージは、IETF PKIX作業部会によって定義されて、インターネットX.509 PKIを設立して、維持するのに使用されます。 PKIメッセージ自体がPKIX仕様に基づき定義されるように保護されるなら、特定のセキュリティー対策がこのレベルで適用されるという要件が全くありません。
Interoperability considerations: -
相互運用性問題: -
Published specification: this document
広められた仕様: このドキュメント
Applications which use this media type: Applications using certificate management, operational, or ancillary protocols (as defined by the IETF PKIX Working Group) to send PKI messages via E-Mail or HTTP.
このメディアタイプを使用するアプリケーション: メールかHTTPでメッセージをPKIに送るのに、証明書管理、操作上の、または、付属のプロトコル(IETF PKIX作業部会によって定義されるように)を使用するアプリケーション。
Additional information:
追加情報:
Magic number (s): -
File extension (s): ".PKI"
Macintosh File Type Code (s): -
マジックナンバー(s): - ファイル拡張子(s): ".PKI"マッキントッシュファイルタイプは(s)をコード化します: -
Person and email address to contact for further information: Carlisle Adams, cadams@entrust.com
詳細のために連絡する人とEメールアドレス: カーライルアダムス、 cadams@entrust.com
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: Carlisle Adams
コントローラを書くか、または変えてください: カーライルアダムス
Adams & Farrell Standards Track [Page 71] RFC 2510 PKI Certificate Management Protocols March 1999
アダムスとファレル標準化過程[71ページ]RFC2510PKIは1999年3月に管理プロトコルを証明します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Adams & Farrell Standards Track [Page 72]
アダムスとファレル標準化過程[72ページ]
一覧
スポンサーリンク
