RFC5217 日本語訳
5217 Memorandum for Multi-Domain Public Key InfrastructureInteroperability. M. Shimaoka, Ed., N. Hastings, R. Nielsen. July 2008. (Format: TXT=64814 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Shimaoka, Ed.
Request for Comments: 5217 SECOM
Category: Informational N. Hastings
NIST
R. Nielsen
Booz Allen Hamilton
July 2008
ワーキンググループM.Shimaoka、エドをネットワークでつないでください。コメントのために以下を要求してください。 5217年のセコムカテゴリ: 情報のN.のR.ニールセンBoozアレンハミルトンヘイスティングズNIST2008年7月
Memorandum for Multi-Domain Public Key Infrastructure Interoperability
マルチドメイン公開鍵暗号基盤相互運用性のためのメモ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi- domain PKI.
このドキュメントの目的は、用語枠組みを確立して、マルチドメイン公開鍵基盤の相互運用性のための公開鍵暗号基盤(PKI)ドメインの操作上の要件を示すことです。(そこでは、それぞれのPKIドメインが異なった方針の下で操作されます)。 このドキュメントは、Certification Authorities(CAs)の間の関係について説明して、PKIドメインのための定義と要件を提供して、マルチドメインPKIの典型的なモデルについて議論します。
Shimaoka, et al. Informational [Page 1] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[1ページ]のRFC5217
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 3
2. Public Key Infrastructure (PKI) Basics . . . . . . . . . . . . 3
2.1. Basic Terms . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Relationships between Certification Authorities . . . . . 4
2.2.1. Hierarchical CA Relationships . . . . . . . . . . . . 5
2.2.2. Peer-to-Peer CA Relationships . . . . . . . . . . . . 6
2.3. Public Key Infrastructure (PKI) Architectures . . . . . . 7
2.3.1. Single CA Architecture . . . . . . . . . . . . . . . . 7
2.3.2. Multiple CA Architectures . . . . . . . . . . . . . . 8
2.4. Relationships between PKIs and Relying Parties . . . . . . 12
3. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. PKI Domain Properties . . . . . . . . . . . . . . . . . . 13
3.2. Requirements for Establishing and Participating in PKI
Domains . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . . 13
3.2.2. PKI Domain Documentation . . . . . . . . . . . . . . . 14
3.2.3. PKI Domain Membership Notification . . . . . . . . . . 15
3.2.4. Considerations for PKIs and PKI Domains with
Multiple Policies . . . . . . . . . . . . . . . . . . 16
3.3. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Unifying Trust Point (Unifying Domain) Model . . . . . 16
3.3.2. Independent Trust Point Models . . . . . . . . . . . . 17
3.4. Operational Considerations . . . . . . . . . . . . . . . . 21
4. Trust Models External to PKI Relationships . . . . . . . . . . 22
4.1. Trust List Models . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Local Trust List Model . . . . . . . . . . . . . . . . 22
4.1.2. Trust Authority Model . . . . . . . . . . . . . . . . 23
4.2. Trust List Considerations . . . . . . . . . . . . . . . . 24
4.2.1. Considerations for a PKI . . . . . . . . . . . . . . . 24
4.2.2. Considerations for Relying Parties and Trust
Authorities . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. Additional Considerations for Trust Authorities . . . 25
5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 25
6.2. Trust List Models . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 27
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 目的. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 アウトライン. . . . . . . . . . . . . . . . . . . . . 3 2を記録してください。 公開鍵暗号基盤(PKI)基礎. . . . . . . . . . . . 3 2.1。 基本用語. . . . . . . . . . . . . . . . . . . . . . . 3 2.2。 証明当局. . . . . 4 2.2.1の間の関係。 階層的なカリフォルニアの関係. . . . . . . . . . . . 5 2.2.2。 ピアツーピアカリフォルニアの関係. . . . . . . . . . . . 6 2.3。 公開鍵暗号基盤(PKI)構造. . . . . . 7 2.3.1。 カリフォルニア構造. . . . . . . . . . . . . . . . 7 2.3.2人を選抜してください。 複数のカリフォルニア構造. . . . . . . . . . . . . . 8 2.4 PKIsと信用党. . . . . . 12 3との関係。 PKIドメイン. . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1。 PKIドメインの特性. . . . . . . . . . . . . . . . . . 13 3.2。 PKIドメイン. . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1を確立して、参加するための要件。 PKI要件. . . . . . . . . . . . . . . . . . . 13 3.2.2。 PKIドメインドキュメンテーション. . . . . . . . . . . . . . . 14 3.2.3。 PKIドメイン会員資格通知. . . . . . . . . . 15 3.2.4。 複数の方針. . . . . . . . . . . . . . . . . . 16 3.3があるPKIsのための問題とPKIドメイン PKIドメインは.1に.163.3をモデル化します。 信用ポイント(ドメインを統一する)モデル. . . . . 16 3.3.2を統一します。 独立している信用ポイントは.173.4をモデル化します。 操作上の問題. . . . . . . . . . . . . . . . 21 4。 PKI関係. . . . . . . . . . 22 4.1への外部のモデルを信じてください。 .1にリストモデル. . . . . . . . . . . . . . . . . . . . 22 4.1を信じてください。 ローカルの信用リストモデル. . . . . . . . . . . . . . . . 22 4.1.2。 権威モデル. . . . . . . . . . . . . . . . 23 4.2を信じてください。 リスト問題. . . . . . . . . . . . . . . . 24 4.2.1を信じてください。 PKI. . . . . . . . . . . . . . . 24 4.2.2のための問題。 信用党と信用当局. . . . . . . . . . . . . . . . . . . . . 24 4.2.3のための問題。 信用当局. . . 25 5のための追加問題。 略語. . . . . . . . . . . . . . . . . . . . . . . . 25 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 25 6.1。 PKIドメインは.256.2をモデル化します。 リストモデル. . . . . . . . . . . . . . . . . . . . 26 7を信じてください。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 27 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 27
Shimaoka, et al. Informational [Page 2] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[2ページ]のRFC5217
1. Introduction
1. 序論
1.1. Objective
1.1. 目的
The objective of this document is to establish a terminology framework and to provide the operational requirements, which can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other. The document defines different types of possible trust relationships, identifies design and implementation considerations that PKIs should implement to facilitate trust relationships across PKIs, and identifies issues that should be considered when implementing trust relationships. This document defines terminology and interoperability requirements for multi-domain PKIs from one perspective. A PKI domain can achieve multi-domain PKI interoperability by complying with the requirements in this document. However, there are other ways to define and realize multi-domain PKI interoperability.
このドキュメントの目的は、用語枠組みを確立して、操作上の要件を提供することです。(互いとの信用関係を確立すると考えている異なった公開鍵暗号基盤(PKI)当局は要件を使用できます)。 ドキュメントは、異なったタイプの可能な信用関係を定義して、PKIsがPKIsの向こう側に信用関係を容易にするために実行するはずである設計と実装問題を特定して、信用関係を実行するとき考えられるべきである問題を特定します。 このドキュメントは1からのマルチドメインPKIs見解のための用語と相互運用性要件を定義します。 PKIドメインは、本書では要件に従うことによって、マルチドメインPKI相互運用性を実現できます。 しかしながら、マルチドメインPKI相互運用性を定義して、わかる他の方法があります。
1.2. Document Outline
1.2. ドキュメントアウトライン
Section 2 introduces the PKI basics, which provide a background for multi-domain PKI. Section 3 provides the definitions and requirements of 'PKI domain' and describes the typical models of multi-domain PKI. Section 4 considers the Trust List Models depending on relying party-CA relationships (not CA-CA trust relationships, as they are not a focus of this document). Section 5 identifies abbreviations used in the document.
セクション2はPKI基礎を紹介します。(基礎はマルチドメインPKIにバックグラウンドを供給します)。 セクション3は、'PKIドメイン'の定義と要件を提供して、マルチドメインPKIの典型的なモデルについて説明します。 セクション4は当てにしているパーティーカリフォルニアの関係によるTrust List Modelsを考えます(どんなカリフォルニア-カリフォルニアも関係を信じません、それらがこのドキュメントの焦点でないので)。 セクション5はドキュメントで使用される略語を特定します。
2. Public Key Infrastructure (PKI) Basics
2. 公開鍵暗号基盤(PKI)基礎
2.1. Basic Terms
2.1. 基本用語
The following terms are used throughout this document. Where possible, definitions found in RFC 4949 [RFC4949] have been used.
次の用語はこのドキュメント中で使用されます。 可能であるところでは、RFC4949[RFC4949]で見つけられた定義が使用されました。
Certificate: A digitally signed data structure that attests to the
binding of a system entity's identity to a public key value (based
on the definition of public key certificate in RFC 4949
[RFC4949]).
以下を証明してください。 公開鍵値(RFC4949[RFC4949]との公開鍵証明書の定義に基づいている)へのシステム実体のアイデンティティの結合を証明するデジタルにサインされたデータ構造。
Certificate Policy: A named set of rules that indicates the
applicability of a certificate to a particular community and/or
class of application with common security requirements (X.509
[CCITT.X509.2000]). Note that to avoid confusion, this document
uses the terminology "Certificate Policy Document" to refer to the
document that defines the rules and "Policy Object Identifier
(OID)" to specify a particular rule set.
方針を証明してください: 共通の安全保障要件(X.509[CCITT.X509.2000])で特定の共同体、そして/または、クラスの適用への証明書の適用性を示す命名されたセットの規則。 混乱を避けるなら、このドキュメントが特定の規則セットを指定するために規則と「政策目的識別子(OID)」を定義するドキュメントを参照するのに用語「証明書方針ドキュメント」を使用することに注意してください。
Shimaoka, et al. Informational [Page 3] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[3ページ]のRFC5217
Certificate Policy Document: A document that defines the rules for
the issuance and management of certificates and identifies Policy
Object Identifiers (OIDs) for these rules. A Certificate Policy
Document may define more than one Policy OID.
方針ドキュメントを証明してください: 証明書の発行と管理のために規則を決めて、これらの規則のために、Policy Object Identifiers(OIDs)を特定するドキュメント。 Certificate Policy Documentは1Policy OIDを定義するかもしれません。
Policy Object Identifier (Policy OID): An identifier applied to a
set of rules governing the issuance and management of
certificates. Policy OIDs are defined in the Certificate Policy
Documents.
政策目的識別子(方針OID): 識別子は発行を支配する1セットの規則と証明書の経営者側に適用されました。 方針OIDsはCertificate Policy Documentsで定義されます。
Certification Authority (CA): An entity that issues certificates
(especially X.509 certificates) and vouches for the binding
between the data items in a certificate (RFC 4949 [RFC4949]).
認証局(カリフォルニア): 証明書(RFC4949[RFC4949])のデータ項目の間で証明書(特にX.509証明書)を発行して、結合を保証する実体。
End Entity (EE): A system entity that is the subject of a
certificate and that is using, or is permitted and able to use,
the matching private key only for a purpose or purposes other than
signing a certificate; i.e., an entity that is not a CA (RFC 4949
[RFC4949]).
実体(EE)を終わらせてください: 証明書とその対象であるシステム実体は、使用に使用するか、受入れられてまたはできます、証明書にサインするのを除いた目的か目的のためだけの合っている秘密鍵。 すなわち、カリフォルニア(RFC4949[RFC4949])でない実体。
Relying party: A system entity that depends on the validity of
information (such as another entity's public key value) provided
by a certificate (from the RFC 4949 [RFC4949] definition of
certificate user).
信用パーティー: 証明書(証明書ユーザのRFC4949[RFC4949]定義からの)によって提供された情報(別の実体の公開鍵値などの)の正当性によるシステム実体。
2.2. Relationships between Certification Authorities
2.2. 証明当局の間の関係
CAs establish trust relationships by issuing certificates to other CAs. CA relationships are divided into 'certification hierarchy' [RFC4949] and 'cross-certification' [RFC4949].
CAsは、他のCAsに証明書を発行することによって、信用関係を確立します。 カリフォルニアの関係は'証明階層構造'[RFC4949]と'相互認証'[RFC4949]に分割されます。
In a certification hierarchy, there are two types of CAs: 'superior CA' and 'subordinate CA', as described in RFC 4949 [RFC4949].
証明階層構造には、CAsの2つのタイプがあります: '優れたカリフォルニア'とRFC4949の説明されるとしての'カリフォルニアを下位に置かせてください'という[RFC4949。]
Superior CA: A CA that is an issuer of a subordinate CA certificate.
上司カリフォルニア: 下位のカリフォルニア証明書の発行人であるカリフォルニア。
A cross-certification can be either unilateral or bilateral.
相互認証は、一方的であるか、または双方である場合があります。
Unilateral cross-certification: Cross-certification of one CA (CA1)
by another CA (CA2) but no cross-certification of CA2 by CA1.
一方的な相互認証: 別のカリフォルニア(CA2)にもかかわらず、CA1によるCA2の相互認証がないのによる1カリフォルニア(CA1)の相互認証。
Bilateral cross-certification: Cross-certification of one CA (CA1)
by another CA (CA2) and cross-certification of CA2 by CA1.
双方の相互認証: CA1によるCA2の別のカリフォルニア(CA2)と相互認証による1カリフォルニア(CA1)の相互認証。
Shimaoka, et al. Informational [Page 4] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[4ページ]のRFC5217
2.2.1. Hierarchical CA Relationships
2.2.1. 階層的なカリフォルニアの関係
In a hierarchical relationship, as shown in Figure 1, one CA assumes a parent relationship to the other CA.
上下関係では、図1、1に示されるように、カリフォルニアはもう片方のカリフォルニアとの親関係を仮定します。
+----+
| CA |
+----+
|
v
+----+
| CA |
+----+
+----+ | カリフォルニア| +----+ | +に対して----+ | カリフォルニア| +----+
Figure 1: Hierarchical CA Relationship
図1: 階層的なカリフォルニアの関係
There are two types of hierarchical relationships, depending on whether a subordinate CA certificate or a unilateral cross- certificate is used. In the case where one (superior) CA issues a subordinate CA certificate to another, the CA at the top of the hierarchy, which must itself have a self-signed certificate, is called a root CA. In the case where one CA issues unilateral cross- certificates to other CAs, the CA issuing unilateral cross- certificates is called a Unifying CA. Unifying CAs use only unilateral cross-certificates.
2つのタイプの上下関係があります、下位のカリフォルニア証明書か一方的な十字証明書が使用されているかどうかによって。 ある(優れる)のカリフォルニアが下位のカリフォルニア証明書を別のものに発行するケース、その必須自体には自己署名入りの証書がある階層構造の最上部のカリフォルニアでは、カリフォルニアが根と呼ばれています。 1カリフォルニアが一方的な十字証明書を他のCAsに発行する場合では、一方的な十字証明書を発行するカリフォルニアはUnifyingカリフォルニアと呼ばれます。 CAsを統一して、一方的な交差している証明書だけを使用してください。
NOTE: In this document, the definition of root CA is according to the second definition (context for hierarchical PKI) of 'root CA' in RFC 4949 [RFC4949]. This document uses the terminology 'trust anchor CA' for the first definition (context for PKI) of 'root CA' in RFC 4949.
以下に注意してください。 本書では、RFC4949の'カリフォルニアを根づかせてください'という[RFC4949]の2番目の定義(階層的なPKIのための文脈)に従って、根のカリフォルニアの定義があります。 このドキュメントは''根のカリフォルニアの最初の定義(PKIのための文脈)'にRFC4949で用語'信用アンカーカリフォルニアを使用します。
Root CA: A CA that is at the top of a hierarchy, and itself should
not issue certificates to end entities (except those required for
its own operation) but issues subordinate CA certificates to one
or more CAs.
カリフォルニアを根づかせてください: 階層構造、およびそれ自体の先端にあるカリフォルニアは従属するべきです。実体(それ自身の操作に必要であるものを除いた)を終わらせる問題証明書ではなく、問題が1CAsにカリフォルニア証明書を従属します。
Subordinate CA: A CA whose public key certificate is issued by
another superior CA, and itself must not be used as a trust anchor
CA.
カリフォルニアを下位に置かせてください: 信用がカリフォルニアを据えつけるとき、公開鍵証明書が別の優れたカリフォルニア、およびそれ自体で発行されるカリフォルニアを使用してはいけません。
Unifying CA: A CA that is at the top of a hierarchy, and itself
should not issue certificates to end entities (except those
required for its own operation) but establishes unilateral cross-
certification with other CAs. A Unifying CA must permit CAs to
which it issues cross-certificates to have self-signed
certificates.
カリフォルニアを統一します: 階層構造、およびそれ自体の先端にあるカリフォルニアは確立するべきです。実体(それ自身の操作に必要であるものを除いた)を終わらせるために証明書を発行しませんが、他のCAsとの一方的な十字証明を確立します。 Unifyingカリフォルニアは、それが交差している証明書を発行するCAsが自己署名入りの証書を持っていることを許可しなければなりません。
Shimaoka, et al. Informational [Page 5] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[5ページ]のRFC5217
2.2.2. Peer-to-Peer CA Relationships
2.2.2. ピアツーピアカリフォルニアの関係
In a peer relationship, no parent-child relationship is created. To establish peer relationships, only cross-certificates are used. Peer relationships can be either unilateral or bilateral, as shown in Figure 2.
同輩関係では、親子関係は全く作成されません。 同輩関係を証明するために、交差している証明書だけが使用されています。 同輩関係は、図2に示されるように一方的であるか、または双方である場合があります。
Bilateral
Unilateral Cross-Certification
Cross-Certification +----+ +----+
+----+ +----+ | | ---> | |
| CA | ---> | CA | | CA | | CA |
+----+ +----+ | | <--- | |
+----+ +----+
双方の一方的な相互認証相互認証+----+ +----+ +----+ +----+ | | --->|、|、| カリフォルニア| --->| カリフォルニア| | カリフォルニア| | カリフォルニア| +----+ +----+ | | <--、|、| +----+ +----+
Figure 2: Peer-to-Peer CA Relationships
図2: ピアツーピアカリフォルニアの関係
In the case where a CA exists only to manage cross-certificates, that CA is called a Bridge CA. CAs can establish unilateral or bilateral cross-certification with a Bridge CA, as shown in Figure 3.
カリフォルニアが存在する交差している証明書を管理する場合では、そのカリフォルニアはBridgeカリフォルニアと呼ばれます。 CAsは図3に示されるようにBridgeカリフォルニアとの一方的であるか双方の相互認証を確立できます。
Bridge CA: A CA that, itself, does not issue certificates to end
entities (except those required for its own operation) but
establishes unilateral or bilateral cross-certification with other
CAs.
カリフォルニアに橋を架けてください: しかしそれ(それ自体)が実体(それ自身の操作に必要であるものを除いた)を終わらせるために証明書を発行しないカリフォルニアは他のCAsとの一方的であるか双方の相互認証を確立します。
Bilateral
Cross-Certification
+----+ ----------+ +--------- +----+
| CA | | | | CA |
+----+ <-------+ | | +------> +----+
| v v |
+-----------+
| Bridge CA |
+-----------+
+----+ | | +----+
| CA | <-------+ +-------> | CA |
+----+ Unilateral +----+
Cross-Certification
双方の相互認証+----+ ----------+ +--------- +----+ | カリフォルニア| | | | カリフォルニア| +----+ <。-------+ | | +------>+----+ | vに対して| +-----------+ | カリフォルニアに橋を架けてください。| +-----------+ +----+ | | +----+ | カリフォルニア| <、-、-、-、-、-、--+ +------->| カリフォルニア| +----+ 一方的な+----+ 相互認証
Figure 3: Bridge CA
図3: カリフォルニアに橋を架けてください。
Shimaoka, et al. Informational [Page 6] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[6ページ]のRFC5217
2.3. Public Key Infrastructure (PKI) Architectures
2.3. 公開鍵暗号基盤(PKI)構造
Public Key Infrastructure (PKI): A system of CAs that perform some
set of certificate management, archive management, key management,
and token management functions for a community of users in an
application of asymmetric cryptography and share trust
relationships, operate under the same Certificate Policy Document
specifying a shared set of Policy OID(s), and are either operated
by a single organization or under the direction of a single
organization.
公開鍵基盤(PKI): 何らかのセットの証明書経営を実行するCAsのシステム、非対称の暗号のアプリケーションにおけるユーザの共同体へのアーカイブ管理、かぎ管理、および象徴管理機能は、信用関係を共有して、Policy OID(s)の共有されたセットを指定する同じCertificate Policy Documentの下で作動して、単純組織によって運用されるか、単純組織の指示のどちらかにはあります。
In addition, a PKI that intends to enter into trust relationships with other PKIs must designate a Principal CA (PCA) that will manage all trust relationships. This Principal CA should also be the trust anchor CA for relying parties of that PKI.
さらに、他のPKIsとの信用関係に入るつもりであるPKIはすべての信用を管理するプリンシパル・カリフォルニア(PCA)を関係に指定しなければなりません。 また、このプリンシパル・カリフォルニアはそのPKIの当てにしているパーティーのための信用アンカーカリフォルニアであるべきです。
Principal CA (PCA): A CA that should have a self-signed certificate
is designated as the CA that will issue cross-certificates to
Principal CAs in other PKIs, and may be the subject of cross-
certificates issued by Principal CAs in other PKIs.
カリフォルニアの校長(PCA): 自己署名入りの証書を持つべきであるカリフォルニアによる他のPKIsでプリンシパルCAsに交差している証明書を発行するカリフォルニアを任じて、他のPKIsのプリンシパルCAsによって発行された十字証明書の対象であるかもしれないということです。
In discussing different possible architectures for PKI, the concept of a certification path is necessary. A certification path is built based on trust relationships between CAs.
PKIのために異なった可能な構造について議論するのにおいて、証明経路の概念が必要です。 証明経路はCAsの間の信用関係に基づいて造られます。
Certification Path: An ordered sequence of certificates where the
subject of each certificate in the path is the issuer of the next
certificate in the path. A certification path begins with a trust
anchor certificate and ends with an end entity certificate.
証明経路: 経路のそれぞれの証明書の対象が経路の次の証明書の発行人である証明書の規則正しい系列。 証明経路は、信用アンカー証明書で始まって、終わりの実体証明書で終わります。
2.3.1. Single CA Architecture
2.3.1. ただ一つのカリフォルニア構造
Definition: A simple PKI consists of a single CA with a self-signed
certificate that issues certificates to End Entities (EEs), as
shown in Figure 4.
定義: 簡単なPKIはEnd Entities(EEs)に証明書を発行する自己署名入りの証書で単一のカリフォルニアから成ります、図4に示されるように。
+----+
| CA |
+----+
|
+------+-----+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
+----+ | カリフォルニア| +----+ | +------+-----+ v対+に----+ +----+ +----+ | EE| | EE| | EE| +----+ +----+ +----+
Figure 4: Simple PKI Architecture
図4: 簡単なPKI構造
Shimaoka, et al. Informational [Page 7] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[7ページ]のRFC5217
Trust anchor CA: The trust anchor CA must be the CA that has a self-
signed certificate.
アンカーカリフォルニアを信じてください: 信用アンカーカリフォルニアは自己署名入りの証書があるカリフォルニアであるに違いありません。
Principal CA: Since this PKI architecture has one CA, the Principal
CA must be that CA.
カリフォルニアの校長: カリフォルニア、このPKI構造には1つがあるので、プリンシパル・カリフォルニアはそのカリフォルニアであるに違いありません。
2.3.2. Multiple CA Architectures
2.3.2. 複数のカリフォルニア構造
2.3.2.1. Hierarchical PKI Architecture
2.3.2.1. 階層的なPKI構造
Definition: A hierarchical PKI consists of a single root CA and one
or more subordinate CAs that issue certificates to EEs. A
hierarchical PKI may have intermediate CAs, which are subordinate
CAs that themselves have subordinate CAs. The root CA must
distribute a trust anchor (public key and associated data), but
the format and protocol are irrelevant for this specification.
And all subordinate CAs must have subordinate CA certificates, as
shown in Figure 5.
定義: 階層的なPKIがただ一つの根カリフォルニアと1から成るか、または以上は証明書を発行するCAsをEEsに従属します。 階層的なPKIには中間的CAsがあるかもしれません。(CAsは自分たちで下位のCAsを持っている下位のCAsです)。 根のカリフォルニアは信用アンカー(公開鍵と関連データ)を分配しなければなりませんが、この仕様に、形式とプロトコルは無関係です。 そして、すべての下位のCAsには下位のカリフォルニア証明書が図5に示されるようになければなりません。
Trust anchor CA: The trust anchor CA must be the root CA.
アンカーカリフォルニアを信じてください: 信用アンカーカリフォルニアは根のカリフォルニアであるに違いありません。
Principal CA: The Principal CA must be the root CA.
カリフォルニアの校長: プリンシパル・カリフォルニアは根のカリフォルニアであるに違いありません。
+---------+
| Root CA |
+---------+
|
+------------+------------+
v v
+----+ +----+
| CA | | CA |
+----+ +----+
| |
+------+------+ +--------+-------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | CA | | CA |
+----+ +----+ +----+ +----+ +----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
+---------+ | カリフォルニアを根づかせてください。| +---------+ | +------------+------------+ v対+----+ +----+ | カリフォルニア| | カリフォルニア| +----+ +----+ | | +------+------+ +--------+-------+ v v v対+に----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | カリフォルニア| | カリフォルニア| +----+ +----+ +----+ +----+ +----+ | | +---+--+ +------+------+ v v v対+に----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+
Figure 5: Hierarchical PKI Architecture
図5: 階層的なPKI構造
Shimaoka, et al. Informational [Page 8] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[8ページ]のRFC5217
2.3.2.2. Mesh PKI Architectures
2.3.2.2. メッシュPKI構造
Definition: A mesh PKI consists of multiple CAs with self-signed
certificates that issue certificates to EEs and issue cross-
certificates to each other. A mesh PKI may be a full mesh, where
all CAs issue cross-certificates to all other CAs, as shown in
Figure 6. A mesh PKI may also be a partial mesh, where all CAs do
not issue cross-certificates to all other CAs. In a partial mesh
PKI, certification paths may not exist from all CAs to all other
CAs, as shown in Figure 7.
定義: メッシュPKIはEEsに証明書を発行して、十字証明書を互いに発行する自己署名入りの証書がある複数のCAsから成ります。 メッシュPKIは完全なメッシュであるかもしれません、図6に示されるように。そこでは、すべてのCAsが他のすべてのCAsに交差している証明書を発行します。 また、メッシュPKIは部分的なメッシュであるかもしれません。(そこでは、すべてのCAsが他のすべてのCAsに交差している証明書を発行しません)。 部分的なメッシュPKIでは、証明経路はすべてのCAsから他のすべてのCAsまで存在しないかもしれません、図7に示されるように。
+--------- +-----+ <--------+
| | CA1 | |
| +------> +-----+ -------+ |
| | | | |
| | +---+--+ | |
| | v v | |
| | +----+ +----+ | |
| | | EE | | EE | | |
| | +----+ +----+ | |
v | v |
+-----+ ----------------> +-----+
| CA2 | | CA3 |
+-----+ <---------------- +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
+--------- +-----+ <。--------+ | | CA1| | | +------>+-----+ -------+ | | | | | | | | +---+--+ | | | | vに対して| | | | +----+ +----+ | | | | | EE| | EE| | | | | +----+ +----+ | | v| v| +-----+ ---------------->+-----+ | CA2| | CA3| +-----+ <。---------------- +-----+ | | +---+--+ +------+------+ v v v対+に----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+
Figure 6: Full Mesh PKI Architecture
図6: 完全なメッシュPKI構造
Shimaoka, et al. Informational [Page 9] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[9ページ]のRFC5217
+--------- +-----+
| | CA1 | --------+
| +------> +-----+ |
| | | |
| | +---+--+ |
| | v v |
| | +----+ +----+ |
| | | EE | | EE | |
| | +----+ +----+ |
v | v
+-----+ +-----+
| CA2 | ----------------> | CA3 |
+-----+ +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
+--------- +-----+ | | CA1| --------+ | +------>+-----+ | | | | | | | +---+--+ | | | vに対して| | | +----+ +----+ | | | | EE| | EE| | | | +----+ +----+ | v| +に対して-----+ +-----+ | CA2| ---------------->| CA3| +-----+ +-----+ | | +---+--+ +------+------+ v v v対+に----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+
Figure 7: Partial Mesh PKI Architecture
図7: 部分的なメッシュPKI構造
Trust anchor CA: The trust anchor CA for an end entity is usually
the CA that issued the end entity's certificate. The trust anchor
CA for an end entity that is not issued a certificate from the
mesh PKI may be any CA in the PKI. In a partial mesh, selection
of the trust anchor may result in no certification path from the
trust anchor to one or more CAs in the mesh. For example, in
Figure 7 above, the selection of CA1 or CA2 as the trust anchor CA
will result in paths from all end entities in the figure.
However, the selection of CA3 as the trust anchor CA will result
in certification paths only for those EEs whose certificates were
issued by CA3. No certification path exists to CA1 or CA2.
アンカーカリフォルニアを信じてください: 通常、終わりの実体のための信用アンカーカリフォルニアは終わりの実体の証明書を発行したカリフォルニアです。 メッシュPKIからの証明書が発行されない終わりの実体のための信用アンカーカリフォルニアはPKIのどんなカリフォルニアであるかもしれません。 部分的なメッシュでは、信用アンカーの選択は信用アンカーからのメッシュの1CAsへの証明経路を全くもたらさないかもしれません。 例えば、上の図7、カリフォルニアがもたらす信用アンカーとしてのCA1かCA2の選択では、すべてからの経路は実体を図に終わらせます。 しかしながら、信用アンカーカリフォルニアとしてのCA3の選択は証明書がCA3によって発行されたそれらのEEsのためだけの証明経路をもたらすでしょう。 証明経路は全くCA1かCA2に存在していません。
Principal CA: The Principal CA may be any CA within the mesh PKI.
However, the mesh PKI must have only one Principal CA, and a
certification path should exist from the Principal CA to all other
CAs within the mesh PKI.
カリフォルニアの校長: プリンシパル・カリフォルニアはメッシュPKIの中のどんなカリフォルニアであるかもしれません。 しかしながら、メッシュPKIには、1だけプリンシパル・カリフォルニアがなければなりません、そして、証明経路はメッシュPKIの中にプリンシパル・カリフォルニアから他のすべてのCAsまで存在するべきです。
Considerations: This model should be used sparingly, especially the
partial mesh model, because of the complexity of determining trust
anchors and building certification paths. A full mesh PKI may be
useful for certification path building because paths of length one
exist from all CAs to all other CAs in the mesh.
問題: このモデルは控えめに使用されるべきです、特に部分的なメッシュモデル、信用アンカーを決定して、証明経路を造る複雑さのために。 長さ1の経路がメッシュにすべてのCAsから他のすべてのCAsまで存在しているので、完全なメッシュPKIは証明経路ビルの役に立つかもしれません。
Shimaoka, et al. Informational [Page 10] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[10ページ]のRFC5217
2.3.2.3. Hybrid PKI Architectures
2.3.2.3. ハイブリッドPKI構造
Definition: A hybrid PKI is a PKI that uses a combination of the
pure hierarchical model using subordinate CA certificates and the
pure mesh model using cross-certificates.
定義: ハイブリッドPKIは交差している証明書を使用することで下位のカリフォルニア証明書と純粋なメッシュモデルを使用することで純粋な階層的なモデルの組み合わせを使用するPKIです。
+-----+ <----- +-----+
| CA2 | | CA1 |
+-----+ -----> +-----+
| |
+---+--+ +---+--+-------+
v v v v v
+----+ +----+ +----+ +----+ +-----+
| EE | | EE | | EE | | EE | | CA3 |
+----+ +----+ +----+ +----+ +-----+
|
+------+------+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
+-----+ <。----- +-----+ | CA2| | CA1| +-----+ ----->+-----+ | | +---+--+ +---+--+-------+ v v v対+に----+ +----+ +----+ +----+ +-----+ | EE| | EE| | EE| | EE| | CA3| +----+ +----+ +----+ +----+ +-----+ | +------+------+ v対+に----+ +----+ +----+ | EE| | EE| | EE| +----+ +----+ +----+
Figure 8: Hybrid PKI Architecture
エイト環: ハイブリッドPKI構造
Trust anchor CA: The trust anchor CA for a hybrid PKI may be any CA
with self-issued certificates in the hybrid PKI. However, because
of the potential complexity of a hybrid PKI, the PKI should
provide guidance regarding the selection of the trust anchor to
relying parties because a relying party may fail to build an
appropriate certification path to a subscriber if they choose an
inappropriate trust anchor.
アンカーカリフォルニアを信じてください: ハイブリッドPKIのための信用アンカーカリフォルニアは自己によって発行された証明書がハイブリッドPKIにあるどんなカリフォルニアであるかもしれません。 しかしながら、彼らが不適当な信用アンカーを選ぶなら信用パーティーが適切な証明経路を加入者に造らないかもしれないので、ハイブリッドPKIの潜在的複雑さによるPKIは信用アンカーの選択に関して信用パーティーに指導を提供するはずです。
Principal CA: The Principal CA may be any CA within the hybrid PKI
and should have a self-signed certificate for cross-certification
with other PKI domains. However, the hybrid PKI must have only
one Principal CA and a certification path must exist from the
Principal CA to every CA within the PKI.
カリフォルニアの校長: プリンシパル・カリフォルニアは、ハイブリッドPKIの中のどんなカリフォルニアであるかもしれなくも、他のPKIドメインと共に相互認証のための自己署名入りの証書を持つべきです。 しかしながら、ハイブリッドPKIには、1だけプリンシパル・カリフォルニアがなければなりません、そして、証明経路はPKIの中にプリンシパル・カリフォルニアからあらゆるカリフォルニアまで存在しなければなりません。
Considerations: This model should be used sparingly because of the
complexity of determining trust anchors and building certification
paths. However, hybrid PKIs may occur as a result of the
evolution of a PKI over time, such as CAs within an organization
joining together to become a single PKI.
問題: このモデルは信用アンカーを決定して、証明経路を造る複雑さのために控えめに使用されるべきです。 しかしながら、ハイブリッドPKIsは時間がたつにつれてPKIの発展の結果、起こるかもしれません、独身のPKIになるように結合する組織の中のCAsなどのように。
Shimaoka, et al. Informational [Page 11] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[11ページ]のRFC5217
2.4. Relationships between PKIs and Relying Parties
2.4. PKIsと信用党との関係
Relying Parties establish trust relationships by trust anchor to a PKI. Relying Parties may use a Trust List for establishing trust relationships to one or more PKIs. A Trust List is a set of one or more trust anchors for trusting one or more PKIs.
信用党は信用による関係がPKIに据えつける信用を確立します。 信用党は、1PKIsとの信用関係を確立するのにTrust Listを使用するかもしれません。 Trust Listは1PKIsを信じるための1人以上の信用アンカーのセットです。
There are two types of maintenance models of Trust List, Local Trust List Model and Trust Authority Model. The two models are described in detail in Section 4.1.
2つのタイプのTrust List、Local Trust List Model、およびTrust Authority Modelのメンテナンスモデルがあります。 2つのモデルがセクション4.1で詳細に説明されます。
3. PKI Domain
3. PKIドメイン
Two or more PKIs may choose to enter into trust relationships with each other. For these relationships, each PKI retains its own set of Certificate Policy OIDs and its own Principal CA. In addition to making a business decision to consider a trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI Certificate Policy Document(s) and any other PKI governance documentation through a process known as policy mapping. Trust relationships are technically formalized through the issuance of cross-certificates. Such a collection of two or more PKIs is known as a PKI domain.
2PKIsが、互いとの信用関係に入るのを選ぶかもしれません。 これらの関係のために、各PKIはCertificate Policy OIDsとそれ自身のプリンシパル・カリフォルニアに関するそれ自身のセットを保有します。 信用関係を考えるというビジネス決定をすることに加えて、各PKIは、方針マッピングとして知られている過程で外部のPKI Certificate Policy Document(s)といかなる他のPKI支配ドキュメンテーションも批評することによって、それぞれの外部のPKIの信用のレベルを決定します。 信用関係は交差している証明書の発行を通して技術的に正式にされます。 2PKIsのそのような収集はPKIドメインとして知られています。
PKI domain: A set of two or more PKIs that have chosen to enter into
trust relationships with each other through the use of cross-
certificates. Each PKI that has entered into the PKI domain is
considered a member of that PKI domain.
PKIドメイン: 十字証明書の使用で互いとの信用関係に入るのを選んだ2PKIsの1セット。 PKIドメインに入った各PKIはそのPKIドメインのメンバーであると考えられます。
NOTE: This definition specifies a PKI domain recursively in terms
of its constituent domains and associated trust relationships;
this is different to the definition in RFC 4949 [RFC4949] that
gives PKI domain as a synonym for CA domain and defines it in
terms of a CA and its subject entities.
以下に注意してください。 この定義はその構成しているドメインと関連信用関係に関してPKIドメインを再帰的に指定します。 これはカリフォルニアドメインとの同義語としてPKIドメインを与えて、カリフォルニアとその対象の実体に関してそれを定義するRFC4949[RFC4949]との定義に異なっています。
Domain Policy Object Identifier: A domain Policy Object Identifier
(OID) is a Policy OID that is shared across a PKI domain. Each CA
in the PKI domain must be operated under the domain Policy OID.
Each CA may also have its own Policy OID(s) in addition to the
domain Policy OID. In such a case, the CA must comply with both
policies. The domain Policy OID is used to identify the PKI
domain.
ドメイン政策目的識別子: ドメインPolicy Object Identifier(OID)はPKIドメインの向こう側に共有されるPolicy OIDです。 ドメインPolicy OIDの下でPKIドメインの各カリフォルニアを操作しなければなりません。 また、各カリフォルニアはドメインPolicy OIDに加えてそれ自身のPolicy OID(s)を持っているかもしれません。 このような場合には、カリフォルニアは両方の方針に従わなければなりません。 ドメインPolicy OIDは、PKIドメインを特定するのに使用されます。
Policy Mapping: A process by which members of a PKI domain evaluate
the Certificate Policies (CPs) and other governance documentation
of other potential PKI domain members to determine the level of
trust that each PKI in the PKI domain places on certificates
issued by each other PKI in the PKI domain.
方針マッピング: PKIドメインのメンバーが証明書の上のPKIドメイン地域の各PKIがPKIドメインで互いでPKIを発行した信用のレベルを決定するために他の潜在的PKIドメインメンバーのCertificate Policies(CPs)と他の支配ドキュメンテーションを評価する過程。
Shimaoka, et al. Informational [Page 12] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[12ページ]のRFC5217
3.1. PKI Domain Properties
3.1. PKIドメインの特性
o A PKI domain may operate a Bridge CA or a Unifying CA that defines
members of the domain by issuing cross-certificates to those
members.
o PKIドメインはそれらのメンバーに交差している証明書を発行することによってドメインのメンバーを定義するBridgeカリフォルニアかUnifyingカリフォルニアを操作するかもしれません。
o A single PKI may simultaneously belong to two or more PKI domains.
o 独身のPKIは同時に、2つ以上のPKIドメインに属すかもしれません。
o A PKI domain may contain PKI domains within its own membership.
o PKIドメインはそれ自身の会員資格の中にPKIドメインを含むかもしれません。
o Two or more PKI domains may enter into a trust relationship with
each other, creating a new PKI domain. They may choose to retain
the existing PKI domains in addition to the new PKI domain or
collapse the existing PKI domains into the new PKI domain.
o 新しいPKIドメインを作成して、2つ以上のPKIドメインが互いとの信用関係に入るかもしれません。 彼らは、新しいPKIドメインに加えて既存のPKIドメインを保有するか、または新しいPKIドメインまで既存のPKIドメインを潰すのを選ぶかもしれません。
o A member of a PKI domain may choose to participate in the PKI
domain but restrict or deny trust in one or more other member PKIs
of that same PKI domain.
o PKIドメインのメンバーは、その同じPKIドメインの他の1メンバーPKIsで信用をPKIドメインに参加しますが、制限するか、または否定するのを選ぶかもしれません。
3.2. Requirements for Establishing and Participating in PKI Domains
3.2. PKIドメインを確立して、参加するための要件
The establishment of trust relationships has a direct impact on the trust model of relying parties. As a result, consideration must be taken in the creation and maintenance of PKI domains to prevent creating inadvertent trust relationships.
信用関係の設立は信用パーティーの信用モデルの上に直接的な衝撃を持っています。 不注意に作成するのを防ぐためにPKIドメインの創造と維持で結果、考慮を取らなければならないように、関係を信じてください。
3.2.1. PKI Requirements
3.2.1. PKI要件
In order for a PKI to participate in one or more PKI domains, that PKI must have the following:
PKIが1つ以上のPKIドメインに参加するように、そのPKIには、以下がなければなりません:
o A Certificate Policy Document documenting the requirements for
operation of that PKI. The Certificate Policy Document should be
in RFC 3647 [RFC3647] format.
o そのPKIの操作のための要件を記録するCertificate Policy Document。 RFC3647[RFC3647]形式にはCertificate Policy Documentがあるはずです。
o One or more Policy OIDs defined in the Certificate Policy Document
that are also asserted in all certificates issued by that PKI.
o また、そのPKIによって発行されたすべての証明書で断言されるCertificate Policy Documentで定義された1Policy OIDs。
o A defined Principal CA.
o 定義されたプリンシパル・カリフォルニア。
PKI domains may also impose additional technical, documentation, or policy requirements for membership in the PKI domain.
また、PKIドメインはPKIドメインの会員資格のために技術的な追加ドキュメンテーション、または方針要件を課すかもしれません。
When participating in a PKI domain, the domain Policy OID(s) must be asserted at least in cross-certificates issued by a participating PKI. After the participation, the PKI can assert the domain Policy OID(s) in certificates issued by that PKI, or may map the domain
PKIドメインに参加するとき、少なくとも参加PKIによって発行された交差している証明書でドメインPolicy OID(s)について断言しなければなりません。 参加の後に、PKIはそのPKIによって発行された証明書でドメインがPolicy OID(s)であると断言できるか、またはドメインを写像するかもしれません。
Shimaoka, et al. Informational [Page 13] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[13ページ]のRFC5217
Policy OID(s) to the Policy OID(s) asserted in certificates issued by that PKI.
そのPKIによって発行された証明書で断言されたPolicy OID(s)への方針OID(s)。
3.2.2. PKI Domain Documentation
3.2.2. PKIドメインドキュメンテーション
PKI domains must be formally defined and documented. This documentation may vary greatly depending on the PKI domain. However, it must:
PKIドメインを正式に定義されて、記録しなければなりません。 PKIドメインに大いによって、このドキュメンテーションは異なるかもしれません。 しかしながら、そうしなければなりません:
o Establish the existence of the PKI domain;
o PKIドメインの存在を確立してください。
o Define the authority for maintaining the PKI domain;
o PKIドメインを維持するために権威を定義してください。
Examples of PKI domain Authorities are (1) Representatives from
two PKIs that agree to form a simple PKI domain, (2) A single
entity that may or may not be related to any of the PKIs in the
PKI domain, (3) A governance board made up of representatives
from each PKI domain member.
PKIドメインAuthoritiesに関する例は(1) (2) (3) 簡単なPKIドメインを形成するのに同意する2PKIsからの代表、PKIドメインでPKIsのいずれにも関連するかもしれない単一体、支配板がそれぞれのPKIドメインメンバーから代表に仲直りしたということです。
o Define how the PKI domain is governed;
o PKIドメインがどう治められるかを定義してください。
o Define the purpose and community of interest of the PKI domain;
and
o PKIドメインの目的と利益共同体を定義してください。 そして
Examples of PKI domain intents are (1) allow relying parties of
one PKI to trust certificates issued by another PKI, (2) allow
PKIs that support similar subscriber communities of interest to
interact with each other, and (3) allow relying parties to
trust certificates issued by a number of PKIs that all meet a
set of requirements.
(3) PKIドメイン「不-テント」に関する例は(1)が別のPKIによって発行された証明書を信じるために1PKIのパーティーを信用に許容するということです、そして、(2) 興味がある同様の加入者社会を支持するPKIsと互いに対話させてください、そして、信用にパーティーを許容して、証明書が、多くのPKIsですべてが1セットの必要条件を満たすのを発行したと信じてください。
o Unless the PKI domain has a predetermined membership, describe the
requirements and methods for joining the PKI domain, such as
FPKIMETHOD [FPKIMETHOD].
o PKIドメインに予定された会員資格がない場合、PKIドメインを接合するための要件と方法を説明してください、FPKIMETHOD[FPKIMETHOD]などのように。
Examples of governance documents that PKI domains may choose to use are:
PKIドメインが使用するのを選ぶかもしれない支配ドキュメントに関する例は以下の通りです。
o Statement of intent between two or more parties;
o 2の間の主旨書か以上がパーティーへ行きます。
o Memorandum of Agreement between two or more parties;
o 2の間のAgreementか以上のメモはパーティーへ行きます。
o Certificate Policy Document for the PKI domain;
o PKIドメインにPolicy Documentを証明してください。
o Charter for the PKI domain; or
o PKIドメインへの憲章。 または
o Methodology for PKI domain membership.
o PKIドメイン会員資格のための方法論。
Shimaoka, et al. Informational [Page 14] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[14ページ]のRFC5217
3.2.3. PKI Domain Membership Notification
3.2.3. PKIドメイン会員資格通知
A cross-certificate from the Principal CA of one PKI to the Principal CA of another PKI indicates a mapping between one or more policies of the first PKI and one or more policies of the second PKI. When a relying party is determining if a certificate can be validated, it builds a certification path from the certificate being presented to a trust anchor. To prevent creating inadvertent trust relationships across PKI domains when a single PKI is a member of two or more disparate PKI domains, each PKI domain must be cognizant of what PKI domains in which its member PKIs participate. Figure 9 illustrates this concept.
交差している1PKIのプリンシパル・カリフォルニアから別のPKIのプリンシパル・カリフォルニアまでの証明書は最初のPKIの1つ以上の方針と第2PKIの1つ以上の方針の間のマッピングを示します。 信用パーティーが、証明書を有効にすることができるかどうかと決心しているとき、それは提示される証明書から信用アンカーまで証明経路を造ります。 独身のPKIが2つ以上の異種のPKIドメイン、それぞれのPKIドメインのメンバーであるときに、PKIドメインの向こう側に不注意な信用関係を作成するのを防ぐのがメンバーPKIsが参加するどんなPKIドメインを認識していなければならないか。 図9はこの概念を例証します。
+-----------------------------+
| PKI domain 2 |
+----------------------------+ |
| | | |
| +------+ <------ +------+ <------ +------+ |
| | PKI1 | | | PKI2 | | | PKI3 | |
| +------+ ------> +------+ ------> +------+ |
| | | |
| +-----------------------------+
| PKI domain 1 |
+----------------------------+
+-----------------------------+ | PKIドメイン2| +----------------------------+ | | | | | | +------+ <。------ +------+ <。------ +------+ | | | PKI1| | | PKI2| | | PKI3| | | +------+ ------>+------+ ------>+------+ | | | | | | +-----------------------------+ | PKIドメイン1| +----------------------------+
Figure 9: Participation in Multiple PKI Domains
図9: 複数のPKIドメインへの参加
As shown in Figure 9, PKI2 is a member of both PKI domain 1 and PKI domain 2. Since a certification path exists from PKI1 to PKI2, and from PKI2 to PKI3, a certification path also exists from PKI1 to PKI3. However, PKI1 does not share domain membership with PKI3, so the certification path validation from PKI1 to PKI3 with a validation policy for PKI domain 1 must not succeed. To ensure correct certification path validation and policy mapping, the cross- certificates issued by both PKI1 and PKI3 to PKI2 must contain constraints such as policy mapping or name constraints disallowing the validation of certification paths outside their respective domains.
図9に示されるように、PKI2はPKIドメイン1とPKIドメイン2の両方のメンバーです。 証明経路がPKI1からPKI2までPKI2からPKI3まで存在しているので、また、証明経路はPKI1からPKI3まで存在しています。 しかしながら、PKI1がドメイン会員資格をPKI3と共有しないので、PKIドメイン1への合法化方針があるPKI1からPKI3までの証明経路合法化は成功してはいけません。 正しい証明経路合法化と方針マッピングを確実にするために、PKI1とPKI3の両方によってPKI2に発行された十字証明書はそれらのそれぞれのドメインの外で証明経路の合法化を禁じる方針マッピングか名前規制などの規制を含まなければなりません。
To fully prevent inadvertent trust, any PKI that is a member of one or more PKI domains must inform all those PKI domains of its membership in all other PKI domains. In addition, that PKI must inform all those PKI domains of which it is a member, any time its membership status changes with regards to any other PKI domain. If a PKI domain is informed of the change in status of one of its member PKIs with regards to other PKI domains, that PKI domain must review the constraints in any cross-certificate issued to that PKI. If the change in membership would result in a change to the allowed or
不注意な信用を完全に防ぐために、1つ以上のPKIドメインのメンバーであるどんなPKIも他のすべてのPKIドメインで会員資格のそれらのすべてのPKIドメインを知らせなければなりません。 さらに、そのPKIはそれがメンバーであるそれらのすべてのPKIドメインを知らせなければなりません、会員資格状態がいかなる他のPKIドメインにもあいさつを交換する何時でも。 PKIドメインはメンバーPKIsの1つの状態の他のPKIドメインへの尊敬がある変化において知識があるなら、そのPKIドメインがそのPKIに発行されたどんな交差している証明書でも規制を見直さなければなりません。 または会員資格における変化が許容への変化をもたらすだろう。
Shimaoka, et al. Informational [Page 15] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[15ページ]のRFC5217
disallowed certification paths, the PKI domain must ensure that all such cross-certificates are revoked and re-issued with correct constraints.
禁じられた証明経路であり、PKIドメインは、そのようなすべての交差している証明書が正しい規制で取り消されて、再発行されるのを確実にしなければなりません。
3.2.4. Considerations for PKIs and PKI Domains with Multiple Policies
3.2.4. PKIsのための問題と複数の方針があるPKIドメイン
In some cases, a single PKI may issue certificates at more than one assurance level. If so, the Certificate Policy Document must define separate Policy OIDs for each assurance level, and must define the differences between certificates of different assurance levels.
いくつかの場合、独身のPKIは1つ以上の保証レベルで証明書を発行するかもしれません。 そうだとすれば、Certificate Policy Documentはそれぞれの保証レベルのために別々のPolicy OIDsを定義しなければならなくて、異なった保証レベルの証明書の違いを定義しなければなりません。
A PKI domain may also support more than one assurance level. If so, the PKI domain must also define separate Policy OIDs for each assurance level, and must define the differences in requirements for each level.
また、PKIドメインは1つ以上の保証レベルを支持するかもしれません。 そうだとすれば、PKIドメインは、また、それぞれの保証レベルのために別々のPolicy OIDsを定義しなければならなくて、各レベルのために要件の違いを定義しなければなりません。
When PKIs and PKI domains choose to establish trust relationships, these trust relationships may exist for only one defined assurance level, may have a one-to-one relationship between PKI assurance levels and PKI domain assurance levels, or may have many-to-one or one-to-many relationships between assurance levels. These relationships must be defined in cross-certificates issued between PKIs in the PKI domain.
PKIsとドメインが設立するのを選ぶPKIが関係を信じるとき、これらの信用関係は、1つの定義された保証レベルだけのために存在しているか、PKI保証レベルとPKIドメイン保証レベルとの1〜1つの関係を持っているか、または保証レベルの間に1つへの多くか一対多の関係を持っているかもしれません。 PKIドメインのPKIsの間で発行された交差している証明書でこれらの関係を定義しなければなりません。
3.3. PKI Domain Models
3.3. PKIドメインモデル
Two or more PKI domains may choose to enter into trust relationships with each other. In that case, they may form a larger PKI domain by establishing a new Unifying or Bridge CA or by issuing cross- certificates between their Principal CAs.
2つ以上のPKIドメインが、互いとの信用関係に入るのを選ぶかもしれません。 その場合、彼らは、それらのプリンシパルCAsの間で新しいUnifyingかBridgeカリフォルニアを設置するか、または十字証明書を発行することによって、より大きいPKIドメインを形成するかもしれません。
3.3.1. Unifying Trust Point (Unifying Domain) Model
3.3.1. 信用ポイント(ドメインを統一する)モデルを統一します。
In the Unifying Trust Point Model, a PKI domain is created by establishing a joint, superior CA that issues unilateral cross- certificates to each PKI domain, as shown in Figure 10. Such a joint, superior CA is defined as a Unifying CA, and the Principal CAs in each PKI domain have the hierarchical CA relationship with that Unifying CA. In this model, any relying party from any of the PKI domains must specify the Unifying CA as its trust anchor CA in order to validate a subscriber in the other PKI domains. If the relying party does not desire to validate subscribers in other PKI domains, the relying party may continue to use the Principal CA from the old PKI domain as its trust anchor CA.
Unifying Trust Point Modelでは、PKIドメインはそれぞれのPKIドメインに一方的な十字証明書を発行する共同していて、優れたカリフォルニアを設置することによって、作成されます、図10に示されるように。 そのような共同していて、優れたカリフォルニアはUnifyingカリフォルニアと定義されます、そして、それぞれのPKIドメインのプリンシパルCAsには、そのUnifyingカリフォルニアとの階層的なカリフォルニアの関係があります。 このモデルでは、PKIドメインのどれかからのどんな信用パーティーも、他のPKIドメインで加入者を有効にするために信用アンカーカリフォルニアとしてUnifyingカリフォルニアを指定しなければなりません。 信用パーティーが、他のPKIドメインで加入者を有効にすることを望んでいないなら、信用パーティーは、信用アンカーカリフォルニアとして古いPKIドメインからプリンシパル・カリフォルニアを使用し続けるかもしれません。
This model may be used for merging multiple PKI domains into a single PKI domain with less change to existing PKI domains, or may be used to combine multiple PKI domains into one PKI domain for relying
このモデルは、既存のPKIドメインへの、より少ない変化で複数のPKIドメインをただ一つのPKIドメインに合併するのに使用されるか、または当てにするために複数のPKIドメインを1つのPKIドメインに結合するのに使用されるかもしれません。
Shimaoka, et al. Informational [Page 16] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[16ページ]のRFC5217
parties. The unilateral cross-certificate issued by the Unifying CA to the Principal CAs in each PKI domain may include any policy mapping.
パーティー。 UnifyingカリフォルニアによってそれぞれのPKIドメインのプリンシパルCAsに発行された一方的な交差している証明書はどんな方針マッピングも含むかもしれません。
Cross-certified Cross-certified
Unifying CA Unifying CA
to PKI domain 1 +--------------+ to PKI domain 3
+---------| Unifying CA |---+
| +--------------+ |
| | |
| Cross-certified| |
| Unifying CA | |
| to PKI domain 2| |
+-----------|---+ +-----------|---+ +----|-----------------+
| PKI | | | PKI | | | | PKI |
| domain 1 | | | domain 2 | | | | domain 3 |
| v | | v | | v |
| +-----+ | | +-----+ | | +-----+ ----+ |
| +---| PCA | | | | PCA | | | | PCA | | |
| | +-----+ | | +-----+ | | +-----+ <-+ | |
| | | | | | | | | ^ | v |
| | | | | | | | | | +----+ |
| | | | | | | | | | | CA |---+ |
| | | | | | | | | | +----+ | |
| | | | | v | | v | ^ | | |
| | | | | +----+ | | +----+ | | | |
| | | | | +---| CA | | | | CA |---+ | | |
| | | | | | +----+ | | +----+ | | |
| | | | | | | | | | | | |
| v v | | v v | | v v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
PKIドメイン1+への十字で公認されたCrossによって公認されたUnifyingカリフォルニアUnifyingカリフォルニア--------------+ PKIドメイン3+に---------| カリフォルニアを統一します。|---+ | +--------------+ | | | | | 十字で、公認されています。| | | カリフォルニアを統一します。| | | PKIドメイン2に| | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI| | | PKI| | | | PKI| | ドメイン1| | | ドメイン2| | | | ドメイン3| | v| | v| | v| | +-----+ | | +-----+ | | +-----+ ----+ | | +---| PCA| | | | PCA| | | | PCA| | | | | +-----+ | | +-----+ | | +-----+ <-+| | | | | | | | | | | ^ | v| | | | | | | | | | | +----+ | | | | | | | | | | | | カリフォルニア|---+ | | | | | | | | | | | +----+ | | | | | | | v| | v| ^ | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| カリフォルニア| | | | カリフォルニア|---+ | | | | | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | vに対して| | vに対して| | v vに対して| | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE| | EE| | | | EE| | EE| | | | EE| | EE| | EE| | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+
Figure 10: Unifying Trust Point (Unifying Domain) Model
図10: 信用ポイント(ドメインを統一する)モデルを統一します。
3.3.2. Independent Trust Point Models
3.3.2. 独立している信用ポイントモデル
In Independent Trust Point Models, relying parties continue to use only the trust anchor of their PKI domain. A relying party in the individual trust point model can continue to use the trust anchor of its PKI domain.
無党派Trust Point Modelsでは、信用パーティーは、彼らのPKIドメインの信用アンカーだけを使用し続けています。 個人信託ポイントモデルという信用パーティーは、PKIドメインの信用アンカーを使用し続けることができます。
3.3.2.1. Direct Cross-Certification Model
3.3.2.1. ダイレクト相互認証モデル
In this model, each PKI domain trusts each other by issuing a cross- certificate directly between each Principal CA, as shown in
このモデル、PKIドメインが目立つようにそれぞれのプリンシパル・カリフォルニアの直接間の十字証明書を発行しながら互いを信じるそれぞれで
Shimaoka, et al. Informational [Page 17] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[17ページ]のRFC5217
Figure 11. This model may be used for shortening a certification path or establishing a trust relationship expeditiously.
図11。 このモデルは、証明経路を短くするか、または迅速に信用関係を確立するのに使用されるかもしれません。
Considerations: A PKI domain in this model needs to take into
account that the other PKI domain may cross-certify with any other
PKI domains. If a PKI domain wants to restrict a certification
path, the PKI domain should not rely on the validation policy of
the relying party, but should include the constraints in the
cross-certificate explicitly. A PKI domain that relies on the
validation policy of the relying party about such constraints
cannot guarantee that the constraints will be recognized and
followed.
問題: このモデルのPKIドメインは、もう片方のPKIドメインがいかなる他のPKIドメインでも十字で公認するかもしれないアカウントを連れていく必要があります。 PKIドメインが証明経路を制限したいなら、PKIドメインは、合法化方針を信用パーティーを当てにするべきではありませんが、交差している証明書に明らかに規制を含むべきです。 規制がそのような規制に関するパーティーが保証できない信用の合法化方針になりますが、認識されて、続かれて、それが当てにするPKIドメイン。
+---------------+ +------------------------+
| PKI | cross-certified | PKI |
| domain 1 | each other | domain 2 |
| +-----+ --------------------> +-----+ ----+ |
| | PCA | | | | PCA | | |
| +-----+ <-------------------- +-----+ <-+ | |
| | | | ^ | v |
| | | | | +----+ |
| | | | | | CA |---+ |
| | | | | +----+ | |
| v | | v ^ | | |
| +----+ | | +----+ | | | |
| +---| CA | | | | CA |--+ | | |
| | +----+ | | +----+ | | |
| | | | | | | | |
| v v | | v v v |
| +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +------------------------+
+---------------+ +------------------------+ | PKI| 十字で、公認されています。| PKI| | ドメイン1| 互い| ドメイン2| | +-----+ -------------------->+-----+ ----+ | | | PCA| | | | PCA| | | | +-----+ <。-------------------- +-----+ <-+| | | | | | ^ | v| | | | | | +----+ | | | | | | | カリフォルニア|---+ | | | | | | +----+ | | | v| | ^に対して| | | | +----+ | | +----+ | | | | | +---| カリフォルニア| | | | カリフォルニア|--+ | | | | | +----+ | | +----+ | | | | | | | | | | | | | vに対して| | v vに対して| | +----+ +----+ | | +----+ +----+ +----+ | | | EE| | EE| | | | EE| | EE| | EE| | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +------------------------+
Figure 11: Direct Cross-Certification Model
図11: ダイレクト相互認証モデル
3.3.2.2. Bridge Model
3.3.2.2. 橋のモデル
In this model, every PKI domain trusts each other through a Bridge CA by cross-certification, as shown in Figure 12. The trust relationship is not established between a subscriber domain and a relying party domain directly, but established from the Principal CA of the relying party's PKI domain via a Bridge CA. This model is useful in reducing the number of cross-certifications required for a PKI domain to interoperate with other PKI domains.
このモデルでは、あらゆるPKIドメインが図12に示されるようにBridgeカリフォルニアを通って相互認証で互いを信じます。 信用関係は、加入者ドメインと当てにしているパーティードメインの間に直接設立されませんが、Bridgeカリフォルニア経由で信用パーティーのPKIドメインのプリンシパル・カリフォルニアから確立されます。 このモデルはPKIドメインが他のPKIドメインで共同利用するのに必要である相互認証の数を減少させる際に役に立ちます。
Shimaoka, et al. Informational [Page 18] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[18ページ]のRFC5217
Requirements for Bridge model:
Bridgeのための要件はモデル化されます:
o The Bridge CA must not be used as the trust anchor CA in any PKI
domain.
o 信用アンカーカリフォルニアとしてどんなPKIドメインでもBridgeカリフォルニアを使用してはいけません。
o The Bridge CA should issue cross-certificates with other PKI
domains mutually or may issue cross-certificates unilaterally.
o Bridgeカリフォルニアは、互いに他のPKIドメインがある交差している証明書を発行するべきであるか、または一方的に交差している証明書を発行するかもしれません。
o The Bridge CA must not issue End Entity (EE) certificates except
when it is necessary for the CA's operation.
o それがCAの操作に必要である時以外に、BridgeカリフォルニアはEnd Entity(EE)に証明書を発行してはいけません。
o The Bridge CA must use its own domain Policy OID, not other PKI
domain Policy OID(s), for the policy mapping.
o Bridgeカリフォルニアは方針マッピングに他のPKIドメインPolicy OID(s)ではなく、それ自身のドメインPolicy OIDを使用しなければなりません。
o The Bridge CA should be a neutral position to all PKI domains,
which trust through the Bridge CA. For example, in Figure 12, in
the case that a relying party who trusts the PCA of PKI domain 1
as its trust anchor CA builds the certification path to a
subscriber in PKI domain 3:
o BridgeカリフォルニアはすべてのPKIドメインへのニュートラル・ポジションであるべきであり、Bridgeを通したどの信用がカリフォルニアであるか。 例えば、図12では、信用としてPKIドメイン1のPCAを信じる信用パーティーが投錨して、カリフォルニアは証明経路をPKIドメイン3の加入者に造ります:
Cross-Certificate from PKI domain 1 to the Bridge CA:
BridgeカリフォルニアへのPKIからの交差している証明書のドメイン1:
issuerDomainPolicy ::= domain Policy OID of PKI domain 1
issuerDomainPolicy:、:= PKIドメイン1のドメインPolicy OID
subjectDomainPolicy := domain Policy OID of the Bridge CA
BridgeカリフォルニアのsubjectDomainPolicy:=ドメインPolicy OID
Cross-Certificate from the Bridge CA to PKI domain 3:
交差しているBridgeカリフォルニアからPKIまでの証明書のドメイン3:
issuerDomainPolicy ::= domain Policy OID of the Bridge CA
issuerDomainPolicy:、:= BridgeカリフォルニアのドメインPolicy OID
subjectDomainPolicy ::= domain Policy OID of PKI domain 3
subjectDomainPolicy:、:= PKIドメイン3のドメインPolicy OID
o Cross-certificates issued by the Bridge CA and cross-certificate
issued to the Bridge CA should include the requireExplicitPolicy
with a value that is greater than zero in the policyConstraints
extension because a relying party may not set the initial-
explicit-policy to TRUE.
o 信用パーティーが初期の明白な方針をTRUEに設定しないかもしれないので、Bridgeカリフォルニアに発行されたBridgeカリフォルニアと交差している証明書によって発行された交差している証明書はpolicyConstraints拡張子でゼロ以上である値があるrequireExplicitPolicyを含んでいるはずです。
o PKI domains cross-certified with the Bridge CA should not cross-
certify directly to other PKI domains cross-certified with the
same Bridge CA.
o 十字で公認されたBridgeと共にカリフォルニアが交差するべきでないPKIドメインは十字で公認された同じBridgeと共にカリフォルニアを直接他のPKIドメインに公認します。
o The Bridge CA should clarify the method for the policy mapping of
cross-certification to keep its transparency.
o Bridgeカリフォルニアは相互認証に関する方針マッピングが透明を保つ方法をはっきりさせるべきです。
Shimaoka, et al. Informational [Page 19] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[19ページ]のRFC5217
Considerations: The Bridge CA should be operated by an independent
third party agreed upon by the PKI domains or a consortium
consisting of representatives from the PKI domain members. The
Bridge CA should do policy mapping in a well-documented and
agreed-upon manner with all PKI domains. When applying the name
constraints, the Bridge CA needs to avoid creating conflicts
between the name spaces of the cross-certified PKI domains. The
PKI domains that perform cross-certification with the Bridge CA
should confirm the following:
問題: BridgeカリフォルニアはPKIドメインによって同意された独立した第三者か代表から成る共同体によってPKIドメインメンバーから運用されるべきです。 BridgeカリフォルニアはすべてのPKIドメインでよく記録されて同意している方法による方針マッピングをするべきです。 規制という名前を適用するとき、Bridgeカリフォルニアは、十字で公認されたPKIドメインの名前空間の間の闘争を引き起こすのを避ける必要があります。 Bridgeカリフォルニアとの相互認証を実行するPKIドメインは以下を確認するべきです:
* Does the Bridge CA perform the policy mapping via its own
domain Policy OID?
* Bridgeカリフォルニアはそれ自身のドメインを通してPolicy OIDを写像する方針を実行しますか?
* Does the Bridge CA clarify the method of policy mapping in the
cross-certification?
* Bridgeカリフォルニアは相互認証における方針マッピングの方法をはっきりさせますか?
* Is the Bridge CA able to accept the domain policy that the PKI
domain desires?
* BridgeカリフォルニアはPKIドメインが望んでいるドメイン方針を受け入れることができますか?
+ If the domain policy is mapped to one with a lower security
level, the PKI domain should not accept it. Otherwise, the
PKI domain must carefully consider the risks involved with
accepting certificates with a lower security level.
ドメイン方針であるなら下側のセキュリティー・レベルで+によって1つに写像されて、PKIドメインはそれを受け入れるべきではありません。 さもなければ、PKIドメインは慎重に下側のセキュリティー・レベルで証明書を受け入れるのに伴われる危険を考えなければなりません。
Shimaoka, et al. Informational [Page 20] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[20ページ]のRFC5217
cross-certified cross-certified
PKI domain 1 with BCA PKI domain 3 with BCA
+---------> +-----------+ -----+
| | Bridge CA | |
| +-------- +-----------+ <--+ |
| | ^ | | |
| | cross-certified | | | |
| | PKI domain 2 | | | |
| | with BCA | | | |
+---------|-|---+ +-----------|-|-+ +--|-|-----------------+
| PKI | | | | PKI | | | | | | PKI |
|domain 1 | v | | domain 2 | v | | | v domain 3 |
| +-----+ | | +-----+ | | +-----+ ----+ |
| +---| PCA | | | | PCA | | | | PCA | | |
| | +-----+ | | +-----+ | | +-----+ <-+ | |
| | | | | | | | | ^ | v |
| | | | | | | | | | +----+ |
| | | | | | | | | | | CA |---+ |
| | | | | | | | | | +----+ | |
| | | | | v | | v | ^ | | |
| | | | | +----+ | | +----+ | | | |
| | | | | +---| CA | | | | CA |---+ | | |
| | | | | | +----+ | | +----+ | | |
| | | | | | | | | | | | |
| v v | | v v | | v v v |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
BCA+があるBCA PKIドメイン3がある十字で公認された十字で公認されたPKIドメイン1--------->+-----------+ -----+ | | カリフォルニアに橋を架けてください。| | | +-------- +-----------+<--+| | | ^ | | | | | 十字で、公認されています。| | | | | | PKIドメイン2| | | | | | BCAと共に| | | | +---------|-|---+ +-----------|-|-+ +--|-|-----------------+ | PKI| | | | PKI| | | | | | PKI| |ドメイン1| v| | ドメイン2| v| | | ドメイン3に対して| | +-----+ | | +-----+ | | +-----+ ----+ | | +---| PCA| | | | PCA| | | | PCA| | | | | +-----+ | | +-----+ | | +-----+ <-+| | | | | | | | | | | ^ | v| | | | | | | | | | | +----+ | | | | | | | | | | | | カリフォルニア|---+ | | | | | | | | | | | +----+ | | | | | | | v| | v| ^ | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| カリフォルニア| | | | カリフォルニア|---+ | | | | | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | vに対して| | vに対して| | v vに対して| | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE| | EE| | | | EE| | EE| | | | EE| | EE| | EE| | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+
Figure 12: Bridge Model
図12: 橋のモデル
3.4. Operational Considerations
3.4. 操作上の問題
Each PKI domain may use policy mapping for crossing different PKI domains. If a PKI domain wants to restrict a certification path, the PKI domain should not rely on the validation policy of the relying party, but should include the constraints in the cross-certificate explicitly.
それぞれのPKIドメインは異なったPKIに交差するようにドメインを写像する方針を使用するかもしれません。 PKIドメインが証明経路を制限したいなら、PKIドメインは、合法化方針を信用パーティーを当てにするべきではありませんが、交差している証明書に明らかに規制を含むべきです。
For example, when each PKI domain wants to affect the constraints to a certification path, it should set the requireExplicitPolicy to zero in the policyConstraints extension of any cross-certificates. A PKI domain that relies on the validation policy of the relying party about such constraints cannot guarantee the constraints will be recognized and followed.
それぞれのPKIドメインが証明経路に規制に影響したがっているとき、例えば、それはどんな交差している証明書のpolicyConstraints拡張子でもゼロにrequireExplicitPolicyを設定するべきです。 そのような規制に関するパーティーが規制を保証できない信用の合法化方針を当てにするPKIドメインは、認識されて、続かれるでしょう。
Shimaoka, et al. Informational [Page 21] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[21ページ]のRFC5217
4. Trust Models External to PKI Relationships
4. PKI関係への外部の信用モデル
As opposed to PKI domain trust relationships entered into by PKIs themselves, trust across multiple PKIs can be created by entities external to the PKIs through locally configured lists of trust anchors.
関係がPKIs自身で入ったPKIドメイン信用と対照的に、PKIsへの信用アンカーの局所的に構成されたリストを通した外部の実体で複数のPKIsの向こう側の信用を作成できます。
Trust List: A set of one or more trust anchors used by a relying
party to explicitly trust one or more PKIs.
リストを信じてください: 1セットのものか以上が、信用パーティーによって使用されたアンカーが明らかに1PKIsを信じると信じます。
Note that Trust Lists are often created without the knowledge of the PKIs that are included in the list.
Trust Listsがリストに含まれているPKIsに関する知識なしでしばしば作成されることに注意してください。
4.1. Trust List Models
4.1. 信用リストモデル
4.1.1. Local Trust List Model
4.1.1. ローカルの信用リストモデル
A Trust List can be created and maintained by a single relying party for its own use.
独身の信用パーティーは、それ自身の使用のためにTrust Listを作成して、維持できます。
Local Trust List: A Trust List installed and maintained by a single
relying party for its own use. NOTE: This definition is similar
to "trust-file PKI" defined in RFC 4949 [RFC4949]. However, this
document prefers the term "Local Trust List" contrasting with
"Trust Authority" defined below.
ローカルの信用リスト: それ自身の使用のために独身の信用パーティーによってインストールされて、維持されたTrust List。 以下に注意してください。 この定義はRFC4949[RFC4949]で定義された「信用ファイルPKI」と同様です。 しかしながら、このドキュメントは、以下で定義される「信用権威」を対照をなしながら、「ローカルの信用リスト」という用語が都合がよいです。
Figure 13 illustrates a Local Trust List.
図13はLocal Trust Listを例証します。
+-------------------------------------------------------------+
| Relying party |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+-------------------------------------------------------------+ | 信用パーティー| | +---------------------------------------------------------+ | | | 信用リスト| | | | +--------------+ +--------------+ +--------------+ | | | | | PKI1| | PKI2| ... | PKI n| | | | | | 信用アンカー| | 信用アンカー| | 信用アンカー| | | | | +--------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------+ | +-------------------------------------------------------------+
Figure 13: Relying Party Local Trust List Model
図13: 当てにしているパーティローカルの信用リストモデル
Creating a Local Trust List is the simplest method for relying parties to trust EE certificates. Using Local Trust Lists does not require cross-certification between the PKI that issued the relying party's own certificate and the PKI that issued the EE's certificate,nor does it require implementing mechanisms for processing complex certification paths, as all CAs in a path can be included in the Local Trust List. As a result, Local Trust Lists are
Local Trust Listを作成するのは、信用パーティーがEE証明書を信じる最も簡単な方法です。 Local Trust Listsを使用するのはパーティーの自身の証明書を信用に発行したPKIとEEの証明書を発行したPKIの間の相互認証を必要としません、そして、それはLocal Trust Listに経路のすべてのCAsを含むことができるので複雑な証明経路を処理するためにメカニズムを実行するのを必要としません。 その結果、Local Trust Listsはそうです。
Shimaoka, et al. Informational [Page 22] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[22ページ]のRFC5217
the most common model in use today. However, because Local Trust Lists are created and managed independently by each relying party, the use of Local Trust Lists can be difficult for an enterprise to manage.
今日の使用中の最も一般的なモデル。 しかしながら、Local Trust Listsがそれぞれ当てにしているパーティーによって独自に作成されて、管理されるので、企業に、Local Trust Listsの使用は管理するのが難しい場合があります。
4.1.2. Trust Authority Model
4.1.2. 信用権威モデル
Alternatively, a Trust List can be created and maintained for using by multiple relying parties. In this case, the entity responsible for the Trust List is known as a Trust Authority.
あるいはまた、複数の当てにしているパーティーによる使用のためにTrust Listを作成して、維持できます。 この場合、Trust Listに原因となる実体はTrust Authorityとして知られています。
Trust Authority: An entity that manages a Trust List for use by one
or more relying parties.
権威を信じてください: 使用のために1時までにTrust Listを管理する実体かさらに当てにしているパーティー。
Figure 14 illustrates a Trust Authority and how it is used by Relying Parties. Note that the Trust Authority replaces the PKI trust anchor(s) in the Local Trust List for each participating relying party.
図14はTrust AuthorityとそれがRelying党によってどう使用されるかを例証します。 Trust Authorityがそれぞれ参加している信用パーティーのためにLocal Trust ListでPKI信用アンカーを取り替えることに注意してください。
+-------------------------------------------------------------+
| Trust Authority |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+-------------------------------------------------------------+ | 信用権威| | +---------------------------------------------------------+ | | | 信用リスト| | | | +--------------+ +--------------+ +--------------+ | | | | | PKI1| | PKI2| ... | PKI n| | | | | | 信用アンカー| | 信用アンカー| | 信用アンカー| | | | | +--------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------+ | +-------------------------------------------------------------+
+---------------------+ +---------------------+
| Relying party 1 | | Relying party 2 |
| +-----------------+ | | +-----------------+ | ...
| | Trust Authority | | | | Trust Authority | |
| +-----------------+ | | +-----------------+ |
+---------------------+ +---------------------+
+---------------------+ +---------------------+ | 信用パーティー1| | 信用パーティー2| | +-----------------+ | | +-----------------+ | ... | | 信用権威| | | | 信用権威| | | +-----------------+ | | +-----------------+ | +---------------------+ +---------------------+
Figure 14: Trust Authority Model
図14: 信用権威モデル
A Trust Authority may be operated by a PKI, a collection of relying parties that share a common set of users, an enterprise on behalf of all of its relying parties, or an independent entity. Although PKIs generally establish trust relationships through cross-certificates, a PKI may choose to provide a Trust Authority to support relying parties that do not support processing of certification paths. A collection of relying parties that share a common set of users may choose to maintain a single Trust Authority to simplify the management of Trust Lists. An enterprise may choose to provide a
Trust AuthorityはPKI、一般的なセットのユーザを共有する信用パーティーの収集、信用パーティーのすべてを代表した企業、または独立実体によって操作されるかもしれません。 PKIsは交差している証明書を通して一般に信用関係を確立しますが、PKIは、処理するのを支持しない証明経路の信用パーティーを支持するためにTrust Authorityを提供するのを選ぶかもしれません。 一般的なセットのユーザを共有する信用パーティーの収集は、Trust Listsの管理を簡素化するために独身のTrust Authorityを維持するのを選ぶかもしれません。 企業は、aを提供するのを選ぶかもしれません。
Shimaoka, et al. Informational [Page 23] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[23ページ]のRFC5217
Trust Authority to implement enterprise policies and direct all Relying Parties within the enterprise to use its Trust Authority. Finally, an independent entity may choose to operate a Trust Authority as a managed service.
Authorityが、企業政策を実施して、Trust Authorityを使用するよう企業の中のすべてのRelying党に指示すると信じてください。 最終的に、独立実体は、管理されたサービスとしてTrust Authorityを操作するのを選ぶかもしれません。
4.2. Trust List Considerations
4.2. 信用リスト問題
4.2.1. Considerations for a PKI
4.2.1. PKIのための問題
A PKI should publish its Certificate Policy Document so that Relying Parties and Trust Authorities can determine what, if any, warranties are provided by the PKI regarding reliance on EE certificates.
PKIはRelying党とTrust Authoritiesがなにかを決定できるように、Certificate Policy Documentを発行するはずであるか、保証がEE証明書への信用に関してPKIによっていくらか提供されるなら。
A PKI should broadly publicize information regarding revocation or compromise of a trust anchor CA or Principal CA certificate through notice on a web page, press release, and/or other appropriate mechanisms so that Relying Parties and Trust Authorities can determine if a trust anchor CA or Principal CA certificate installed in a Trust List should be removed.
PKIは、Relying党とTrust Authoritiesが、カリフォルニアかプリンシパルカリフォルニア証明書がTrust Listにインストールした信用アンカーが外されるべきであるかどうか決定できるように、取消しの情報かウェブページにおける通知による信用アンカーカリフォルニアかプリンシパルカリフォルニア証明書、プレスリリース、そして/または、他の適切な手段の妥協について広くピーアールするはずです。
A PKI should publish Certificate Revocation Lists (CRLs) or other information regarding the revocation status of EE certificates to a repository that can be accessed by any party that desires to rely on the EE certificates.
PKIはEE証明書の取消し状態のCertificate Revocation Lists(CRLs)か他の情報をEE証明書を当てにすることを望んでいるどんなパーティーもアクセスできる倉庫に発表するはずです。
4.2.2. Considerations for Relying Parties and Trust Authorities
4.2.2. 当てにしている党と信用当局のための問題
Relying Parties and Trust Authorities are responsible for the following prior to including a PKI in the Trust List:
Trust ListにPKIを含む前に、当てにしている党とTrust Authoritiesは以下に責任があります:
o Reviewing the Certificate Policy Document of each PKI to determine
that the PKI is operated to an acceptable level of assurance;
o それを決定するためにそれぞれのPKIのCertificate Policy Documentを見直して、PKIは合格水準を保証に操作されます。
o Reviewing the Certificate Policy Document of each PKI to ensure
any requirements imposed on Relying Parties are met;
o Relyingに課されたどんな要件も確実にするためにそれぞれのPKIのCertificate Policy Documentを見直して、党は会合されます。
o Determining if the PKI provides any warranties regarding reliance
on EE certificates, and if these warranties are acceptable for the
intended reliance on the EE certificates. Reliance may be at the
relying party's own risk; and
o PKIが何かEE証明書への信用に関する保証を提供するかどうかと、EE証明書への意図している信用において、これらの保証が許容できるかどうか決定します。 信用が信用パーティーの自己のリスクであるかもしれません。 そして
o Periodically reviewing information published by the PKI to its
repository, including Certificate Policy Document updates or
notice of CA revocation or compromise.
o 定期的にPKIによってカリフォルニアの取消しか妥協のCertificate Policy Documentアップデートか通知を含む倉庫に発表された情報を再検討します。
A PKI can choose to join or leave PKI domains in accordance with its Certificate Policy Document. If the relying party or Trust Authority does not wish to inherit trust in other members of these PKI domains,
PKIは、接合するか、またはCertificate Policy Documentに応じてドメインをPKIに出るのを選ぶことができます。 当てにしているパーティーかTrust Authorityが世襲したくないなら、これらのPKIドメインの他のメンバーを信じてください。
Shimaoka, et al. Informational [Page 24] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[24ページ]のRFC5217
it is the responsibility of the relying party or Trust Authority to inhibit policy mapping.
方針マッピングを禁止するのは、当てにしているパーティーかTrust Authorityの責任です。
4.2.3. Additional Considerations for Trust Authorities
4.2.3. 信用当局のための追加問題
A Trust Authority should establish a Trust Authority Policy that identifies the following:
Trust Authorityは以下を特定するTrust Authority Policyを設立するはずです:
o The intended community of Relying Parties that will use the Trust
Authority;
o Trust Authorityを使用するRelying党の意図している共同体。
o The process by which trust anchors are added or removed from the
Trust List;
o 信用アンカーがTrust Listから加えられるか、または外される過程。
o Any warranties provided by the Trust Authority for reliance on EE
certificates. These warranties may be those provided by the PKIs
themselves or may be additional warranties provided by the Trust
Authority;
o Trust AuthorityによってEE証明書への信用に提供されたどんな保証。 これらの保証は、PKIs自身によって提供されたものであるかもしれないかTrust Authorityによって提供された追加保証であるかもしれません。
o Information regarding how the Trust Authority protects the
integrity of its Trust List; and
o Trust AuthorityがどうTrust Listの保全を保護するかに関する情報。 そして
o Information regarding how Relying Parties interact with the Trust
Authority to obtain information as to whether an EE certificate is
trusted.
o Relying党がEE証明書が信じられるかどうかに関して情報を得るためにどうTrust Authorityと対話するかに関する情報。
5. Abbreviations
5. 略語
CA: Certification Authority
カリフォルニア: 認証局
EE: End Entity
EE: 終わりの実体
OID: Object Identifier
OID: 物の識別子
PCA: Principal Certification Authority
PCA: 主要な認証局
PKI: Public Key Infrastructure
PKI: 公開鍵暗号基盤
6. Security Considerations
6. セキュリティ問題
This section highlights security considerations related to establishing PKI domains.
このセクションはPKIドメインを確立すると関連するセキュリティ問題を強調します。
6.1. PKI Domain Models
6.1. PKIドメインモデル
For all PKI domain models described in Section 3.3 created through the issuance of cross-certificates, standard threats including message insertion, modification, and man-in-the-middle are not
交差している証明書の発行を通して創設されたセクション3.3で説明されたすべてのPKIドメインモデルのために、メッセージ挿入、変更、および中央の男性を含む標準の脅威はそうではありません。
Shimaoka, et al. Informational [Page 25] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[25ページ]のRFC5217
applicable because all information created by CAs, including policy mapping and constraints, is digitally signed by the CA generating the cross-certificate.
方針マッピングと規制を含むCAsによって作成されたすべての情報が交差している証明書を作るカリフォルニアによってデジタルにサインされるので、適切です。
Verifying that a given certificate was issued by a member of a PKI domain may be a time-critical determination. If cross-certificates and revocation status information cannot be obtained in a timely manner, a denial of service may be experienced by the end entity. In situations where such verification is critical, caching of cross- certificates and revocation status information may be warranted.
与えられた証明書がPKIドメインのメンバーによって発行されたことを確かめるのは、時間重要な決定要因であるかもしれません。 直ちに交差している証明書と取消し状態情報を入手できないなら、サービスの否定は終わりの実体によって経験されるかもしれません。 そのような検証が批判的である状況で、十字証明書と取消し状態情報のキャッシュは保証されるかもしれません。
An additional security consideration for PKI domains is creating inadvertent trust relationships, which can occur if a single PKI is a member of multiple PKI domains. See Section 3.2.3 for a discussion of creating inadvertent trust relationships and mechanisms to prevent it.
PKIドメインのための追加担保の考慮は不注意な信用関係を作成しています。(関係は独身のPKIが複数のPKIドメインのメンバーであるなら起こることができます)。 セクション3.2.3を見て、不注意な信用関係とメカニズムを作成する議論はそれを防いでください。
Finally, members of PKI domains must participate in domain governance, or at a minimum, be informed anytime a PKI joins or leaves the domain, so that domain members can make appropriate decisions for maintaining their own membership in the domain or choosing to restrict or deny trust in the new member PKI.
最終的に、PKIドメインのメンバーは、いつでも知らされて、PKIがドメインを接合するか、または出ます、ドメインメンバーがそのドメインでそれら自身のを維持するための適切な決定を会員資格にすることができるようにことであるドメイン支配、または最小限で参加しなければならないか、または新しいメンバーPKIへの信用を制限するか、または否定するのを選んでいます。
6.2. Trust List Models
6.2. 信用リストモデル
In these models, many standard attacks are not applicable since certificates are digitally signed. Additional security considerations apply when trust is created through a Trust List.
これらのモデルでは、証明書がデジタルにサインされるので、多くの標準の攻撃は適切ではありません。 信用がTrust Listを通して作成されるとき、追加担保問題は適用されます。
A variation of the modification attack is possible in Trust List Models. If an attacker is able to add or remove CAs from the relying party or Trust Authority Trust List, the attacker can affect which certificates will or will not be accepted. To prevent this attack, access to Trust Lists must be adequately protected against unauthorized modification. This protection is especially important for trust anchors that are used by multiple applications, as it is a key vulnerability of this model. This attack may result in unauthorized usage if a CA is added to a Trust List, or denial of service if a CA is removed from a Trust List.
変更攻撃の変化はTrust List Modelsで可能です。 攻撃者が当てにしているパーティーかTrust Authority Trust ListからCAsを加えるか、または取り外すことができるなら、攻撃者は、どの証明書を受け入れるか、または受け入れないかに影響できます。 この攻撃を防ぐために、適切に権限のない変更に対してTrust Listsへのアクセスを保護しなければなりません。 複数のアプリケーションで使用される信用アンカーにとって、この保護は特に重要です、それがこのモデルの主要な脆弱性であるので。 カリフォルニアがTrust Listに加えられるなら、この攻撃が権限のない用法をもたらすかもしれませんか、またはカリフォルニアであるならTrust Listからサービスの否定を取り除きます。
For Trust Authority models, a denial-of-service attack is also possible if the application cannot obtain timely information from the trust anchor. Applications should specify service-level agreements with Trust Authority. In addition, applications may choose to locally cache the list of CAs maintained by the Trust Authority as a backup in the event that the trust anchor's repository (e.g., Lightweight Directory Access Protocol (LDAP) directory) is not available.
また、Trust Authorityモデルにおいて、アプリケーションが信用アンカーから時宜を得た情報を得ることができないなら、サービス不能攻撃も可能です。 アプリケーションはTrust Authorityとのサービスレベル協定を指定するべきです。 さらに、アプリケーションは、局所的に信用アンカーの倉庫(例えば、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリ)が利用可能でない場合バックアップとしてTrust Authorityによって維持されたCAsのリストをキャッシュするのを選ぶかもしれません。
Shimaoka, et al. Informational [Page 26] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[26ページ]のRFC5217
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen,
S., Housley, R., and W. Polk, "Internet X.509
Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[RFC5280] クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しは(CRL)プロフィールをリストアップします」、RFC5280、2008年5月。
7.2. Informative References
7.2. 有益な参照
[CCITT.X509.2000] International Telephone and Telegraph Consultative
Committee, "Information Technology - Open Systems
Interconnection - The Directory: Authentication
Framework", CCITT Recommendation X.509,
March 2000.
国際[CCITT.X509.2000]が諮問委員会に電話をして、電報を打つ、「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 「認証枠組み」、CCITT推薦X.509、2000年3月。
[FPKIMETHOD] "US Government PKI Cross-Certification Criteria
and Methodology", January 2006, <http://
www.cio.gov/fpkia/documents/
crosscert_method_criteria.pdf>.
_[FPKIMETHOD]「米国政府PKI相互認証評価基準と方法論」2006年1月<http://www.cio.gov/fpkia/ドキュメント/crosscertな_方法criteria.pdf>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C.,
and S. Wu, "Internet X.509 Public Key
Infrastructure Certificate Policy and
Certification Practices Framework", RFC 3647,
November 2003.
[RFC3647] Chokhani、S.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、「インターネットX.509公開鍵暗号基盤証明書方針と証明は枠組みを練習します」、RFC3647、2003年11月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version
2", RFC 4949, August 2007.
[RFC4949] Shirey、R.、「インターネットセキュリティ用語集、バージョン2インチ、RFC4949、2007年8月。」
Shimaoka, et al. Informational [Page 27] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[27ページ]のRFC5217
Authors' Addresses
作者のアドレス
Masaki Shimaoka (editor) SECOM Co., Ltd. Intelligent System Laboratory SECOM SC Center, 8-10-16 Shimorenjaku Mitaka, Tokyo 181-8528 JP
8-10-16 Shimorenjaku三鷹、東京181-8528JPのMasaki Shimaoka(エディタ)知的なシステム研究所のセコムサウスカロライナのセコム株式会社センター
EMail: m-shimaoka@secom.co.jp
メール: m-shimaoka@secom.co.jp
Nelson Hastings National Institute of Standard and Technology 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 US
ネルソンヘイスティングズ国立標準技術研究所100の事務局ドライブ、8930ゲイザースバーグ、停止MD20899-8930米国
EMail: nelson.hastings@nist.gov
メール: nelson.hastings@nist.gov
Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US
レベッカ・ニールセン・Boozアレン・ハミルトン8283・グリーンスバロDriveヴァージニア22102マクリーン(米国)
EMail: nielsen_rebecca@bah.com
メール: nielsen_rebecca@bah.com
Shimaoka, et al. Informational [Page 28] RFC 5217 Multi-Domain PKI Interoperability July 2008
Shimaoka、他 PKI相互運用性2008年7月のマルチドメインの情報[28ページ]のRFC5217
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Shimaoka, et al. Informational [Page 29]
Shimaoka、他 情報[29ページ]
一覧
スポンサーリンク
