Network Working Group M. Shimaoka, Ed.
Request for Comments: 5217 SECOM
Category: Informational N. Hastings
NIST
R. Nielsen
Booz Allen Hamilton
July 2008
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）、ドメインの運用要件を提案することです。この文書では、証明機関（CA）の間の関係を記述する定義とPKIドメインの要件を提供し、マルチドメインPKIの代表的なモデルについて説明します。
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
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）当局が利用できる運用要件を提供することにあります。文書は、可能な信頼関係の異なる種類を定義するのPKIはPKIの間で信頼関係を促進するために実装する必要があり、設計と実装の考慮事項を識別し、信頼関係を実装する際に考慮すべき問題を特定します。この文書では、1つの視点からマルチドメインPKIのための用語との相互運用性の要件を定義します。 PKIドメインは、この文書の要求事項を遵守することにより、マルチドメインPKIの相互運用性を実現することができます。しかし、定義し、マルチドメインPKIの相互運用性を実現するための他の方法があります。
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の代表的なモデルについて説明します。 （彼らは、このドキュメントの焦点ではないようではなく、CA-CAの信頼関係）第4章では、パーティー-CAとの関係を頼りに応じて、信頼リストのモデルを検討します。第5節では、文書内で使用される略語を識別します。
The following terms are used throughout this document. Where possible, definitions found in RFC 4949 [RFC4949] have been used.
以下の用語は、この文書全体で使用されています。可能な場合には、RFC 4949 [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]).
証明書：公開鍵値（RFC 4949で公開鍵証明書の定義に基づいて、[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）」を定義するドキュメントを参照するために、「証明書ポリシー文書」の用語を使用しています。
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.
証明書ポリシー文書：証明書の発行と管理のためのルールを定義し、これらのルールのためのポリシーオブジェクト識別子（OID）を特定した文書。証明書ポリシー文書は、複数のポリシー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ポリシー）：証明書の発行と管理を管理する規則のセットに適用される識別子。ポリシーOIDが証明書ポリシー文書で定義されています。
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]).
証明機関（CA）：証明書（特にX.509証明書）を発行し、証明書のデータ項目間の結合（RFC 4949 [RFC4949]）を保証するエンティティ。
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）：それが使用している、または許可され、唯一の目的または証明書に署名する以外の目的のために、一致する秘密鍵を使用することができる証明書の主題であり、システムのエンティティ。 CAではない、すなわち、エンティティ（RFC 4949 [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).
依拠当事者（例えば、別のエンティティの公開鍵値として）情報の有効性に依存するシステムエンティティ（証明書ユーザーのRFC 4949 [RFC4949]の定義から）証明書によって提供されます。
CAs establish trust relationships by issuing certificates to other CAs. CA relationships are divided into 'certification hierarchy' [RFC4949] and 'cross-certification' [RFC4949].
CAは他のCAに証明書を発行することによって信頼関係を確立します。 CAの関係は、「証明階層」[RFC4949]及び「相互認証」[RFC4949]に分割されます。
In a certification hierarchy, there are two types of CAs: 'superior CA' and 'subordinate CA', as described in RFC 4949 [RFC4949].
「優れたCA」および「下位CA」、RFC 4949に記載されているように[RFC4949]：証明階層構造において、CAの2種類があります。
Superior CA: A CA that is an issuer of a subordinate CA certificate.
優れたCA：下位CA証明書の発行者であるCA。
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.
片側相互認証：別のCA（CA2）が、CA1によってCA2の無い相互認証により、1 CA（CA1）の相互認証。
Bilateral cross-certification: Cross-certification of one CA (CA1) by another CA (CA2) and cross-certification of CA2 by CA1.
二国間の相互認証：別のCA（CA2）ずつCA（CA1）の相互認証およびCA1により、CA2の相互認証。
In a hierarchical relationship, as shown in Figure 1, one CA assumes a parent relationship to the other CA.
階層関係では、図1に示すように、1つのCAは他のCAに親子関係を想定して
+----+
| CA |
+----+
|
v
+----+
| CA |
+----+
Figure 1: Hierarchical CA Relationship
図1：階層的なCAの関係
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.
下位CA証明書または一方的なクロス証明書が使用されているかどうかに応じて階層関係の2種類があります。一方（スーペリア）CAが別の下位CA証明書を発行する場合には、それ自体が自己署名証明書を持っている必要があり、階層の最上部にあるCAは、ルートCAと呼ばれています一方的な1つのCAの問題、他のCAに相互証明書は、一方的なクロス証明書を発行するCAは、統一のCAと呼ばれている場合には統一CAは唯一の一方的な相互証明書を使用しています。
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.
注：この文書では、ルートCAの定義は、RFC 4949 [RFC4949]の「ルートCA」の2番目の定義（階層PKIのコンテキスト）に応じています。この文書は、RFC 4949の「ルートCA」の最初の定義（PKIのコンテキスト）のための用語「トラストアンカーCA」を使用しています。
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.
ルートCA：階層の最上位にあるCA、それ自体は（自身の動作に必要なものを除く）のエンティティが、1つのまたは複数のCAに発行下位CA証明書を終了するには、証明書を発行するべきではありません。
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.
下位CA：その公開鍵証明書、別の優れたCAによって発行され、それ自体はトラストアンカーCAとして使用することはできません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.
統一CA：階層の最上位にあるCA、それ自体は（自身の動作に必要なものを除く）のエンティティを終了するために証明書を発行するが、他のCAとの一方的な相互認証を確立してはいけません。統一CAは、それが自己署名証明書を持って、クロス証明書を発行したCAを許可する必要があります。
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：ピアツーピアCAの関係
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.
CAは、CAが橋のCAと呼ばれていることを、唯一のクロス証明書を管理するために存在する場合には図3に示すように、CAは、ブリッジCAとの片側または両側の相互認証を確立することができます。
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.
ブリッジCA：CA、自身が、（自身の動作に必要なものを除く）のエンティティを終了する証明書を発行するが、他のCAとの一方的または二国間の相互認証を確立していないこと。
Bilateral
Cross-Certification
+----+ ----------+ +--------- +----+
| CA | | | | CA |
+----+ <-------+ | | +------> +----+
| v v |
+-----------+
| Bridge CA |
+-----------+
+----+ | | +----+
| CA | <-------+ +-------> | CA |
+----+ Unilateral +----+
Cross-Certification
Figure 3: Bridge CA
図3：ブリッジCA
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）：非対称暗号化および共有の信頼関係のアプリケーションでユーザーのコミュニティのための証明書管理、アーカイブ管理、鍵管理、およびトークンの管理機能のいくつかのセットを実行するCAのシステムは、同じ証明書の下で動作しますポリシー文書は、ポリシーOID（S）の共有セットを指定し、いずれかの単一の組織によって、または単一組織の指示の下で操作されます。
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.
また、他のPKIとの信頼関係に入るつもりPKIは、すべての信頼関係を管理します校長CA（PCA）を指定する必要があります。この主なCAはまた、PKIの依拠当事者のためのトラストアンカーCAでなければなりません。
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.
主なCA（PCA）：自己署名証明書を持つべきであるCAは、他のPKIにおける校長のCAに相互証明書を発行するCAとして指定され、そして他ののPKIにおける校長のCAによって発行された相互証明書の対象となることがあり。
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のために異なる可能なアーキテクチャを議論するには、証明書パスの概念が必要です。証明書パスは、CA間の信頼関係に基づいて構築されています。
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.
証明のパス：パス内の各証明書のサブジェクトは、パスの次の証明書の発行者である証明書の順序付けられたシーケンス。証明書パスは、トラストアンカー証明書で始まり、エンドエンティティ証明書で終わります。
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は、図4に示すように、エンティティ（EEの）を終了するために証明書を発行する自己署名証明書を持つ単一のCAから構成されています。
+----+
| CA |
+----+
|
+------+-----+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
Figure 4: Simple PKI Architecture
図4：単純なPKIのアーキテクチャ
Trust anchor CA: The trust anchor CA must be the CA that has a self-signed certificate.
トラストアンカーCA：トラストアンカーCAが自己署名証明書を持つCAでなければなりません。
Principal CA: Since this PKI architecture has one CA, the Principal CA must be that CA.
主なCA：このPKIアーキテクチャは1つのCAを持っているので、主なCAは、そのCAでなければなりません
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は、単一のルートCAと1つ以上の下位CAのEEにその証明書を発行で構成されています。階層PKI自体は下位CA有することのCA従属する中間CAを有していてもよいです。ルートCAは、トラストアンカー（公開鍵および関連するデータ）を配布しなければならないが、形式およびプロトコルは、本明細書には無関係です。図5に示すように、すべての下位CAは、下位CA証明書を持っている必要があります。
Trust anchor CA: The trust anchor CA must be the root CA.
トラストアンカーCA：トラストアンカーCAは、ルートCAである必要があります
Principal CA: The Principal CA must be the root CA.
主なCA：校長CAは、ルート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 |
+----+ +----+ +----+ +----+ +----+
Figure 5: Hierarchical PKI Architecture
図5：階層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のEEに自己署名証明書を使用して複数のCAその問題の証明書で構成され、相互にクロス証明書を発行します。メッシュPKIは、他のすべてのCASにすべてのCAの発行クロス証明書は、図6に示すように、Aは、PKIはまた、すべてのCAが他のすべてのCASに相互証明書を発行しない部分メッシュであってもよく、メッシュフルメッシュであってもよいです。図7に示すように、部分的なメッシュPKIにおいて、認証パスは、他のすべてのCASに、すべてのCAから存在しなくてもよいです。
+--------- +-----+ <--------+
| | CA1 | |
| +------> +-----+ -------+ |
| | | | |
| | +---+--+ | |
| | v v | |
| | +----+ +----+ | |
| | | EE | | EE | | |
| | +----+ +----+ | |
v | v |
+-----+ ----------------> +-----+
| CA2 | | CA3 |
+-----+ <---------------- +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 6: Full Mesh PKI Architecture
図6：フルメッシュPKIのアーキテクチャ
+--------- +-----+
| | CA1 | --------+
| +------> +-----+ |
| | | |
| | +---+--+ |
| | v v |
| | +----+ +----+ |
| | | EE | | EE | |
| | +----+ +----+ |
v | v
+-----+ +-----+
| CA2 | ----------------> | CA3 |
+-----+ +-----+
| |
+---+--+ +------+------+
v v 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.
トラストアンカーCA：エンドエンティティのためのトラストアンカーCAは、通常、エンドエンティティの証明書を発行したCAです。メッシュPKIから証明書を発行されていないエンドエンティティのためのトラストアンカーCAは、PKI内の任意のCAかもしれません。部分メッシュでは、トラストアンカーの選択は、メッシュ内の1つのまたは複数のCAにトラストアンカーからノー証明書パスになることがあります。例えば、上記の図7に、トラストアンカーCAとしてCA1又はCA2の選択は、図中のすべてのエンドエンティティから経路をもたらすであろう。しかし、トラストアンカーCAとしてCA3の選択が唯一その証明書CA3によって発行されたものをEEのための証明書パスになります。いいえ証明書パスは、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.
主なCA：CAは、メッシュPKI内の任意のCAかもしれ校長。しかし、メッシュPKIは、唯一の主要なCAを持っている必要がありますし、証明書パスは、メッシュPKI内校長CAから他のすべてのCAに存在している必要があります。
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に、すべてのCAから存在するため、フルメッシュ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は、下位CA証明書およびクロス証明書を使用して、純粋なメッシュモデルを使用して、純粋な階層モデルの組み合わせを使用してPKIです。
+-----+ <----- +-----+
| CA2 | | CA1 |
+-----+ -----> +-----+
| |
+---+--+ +---+--+-------+
v v v v v
+----+ +----+ +----+ +----+ +-----+
| EE | | EE | | EE | | EE | | CA3 |
+----+ +----+ +----+ +----+ +-----+
|
+------+------+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
Figure 8: Hybrid PKI Architecture
図8：ハイブリッド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.
トラストアンカーCA：ハイブリッドPKIのトラストアンカーCAは、ハイブリッドPKIにおける自己発行証明書付きのCAかもしれません。証明書利用者は、彼らが不適切なトラストアンカーを選択した場合、加入者に適切な証明書パスを構築するために失敗することがあるのでしかし、ハイブリッド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.
主CA：主CAハイブリッドPKI内の任意のCAであってもよく、他のPKIドメインと相互認証のために自己署名証明書を有していなければなりません。しかし、ハイブリッドPKIは、唯一の主なCAおよび証明書パスは、PKI内のすべてのCAへの主なCAから存在している必要があります持っている必要があります。
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.
留意事項：このモデルは、理由は信頼アンカーを決定し、証明書パスの構築の複雑さを慎重に使用する必要があります。しかし、ハイブリッドのPKIは、単一のPKIなるように一緒に接合組織内のそのようなCAとして、経時的PKIの進化の結果として生じ得ます。
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にトラストアンカーによって信頼関係を確立します。依拠当事者は、一の以上のPKIに信頼関係を確立するために信頼リストを使用することができます。信頼リストは、一の以上のPKIを信頼する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種類があります。二つのモデルは、4.1節に詳細に記載されています。
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.
二つ以上のPKIは、お互いに信頼関係に入ることもできます。これらの関係については、各PKIは、証明書ポリシーのOIDと、自身の主なCAの独自のセットを保持します信頼関係を検討するために、ビジネスの意思決定を行うことに加えて、各PKIは、ポリシーマッピングと呼ばれるプロセスを介して外部PKI証明書ポリシードキュメント（複数可）および他のPKIガバナンスのマニュアルを見直すことにより、各外部PKIの信頼のレベルを決定します。信頼関係は、技術的に相互証明書の発行を通じて正式にされています。二つ以上のPKIのようなコレクションは、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ドメイン：クロス証明書を使用してお互いに信頼関係に入ることを選択した二つ以上のPKIのセット。 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ドメインを指定します。これは、CAドメインの同義語としてPKIドメインを提供し、CAの観点から、その被写体のエンティティにそれを定義RFC 4949 [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.
ドメインポリシーオブジェクト識別子：ドメインポリシーオブジェクト識別子（OID）は、PKIドメイン間で共有されているポリシーOIDです。 PKIドメイン内の各CAは、ドメインポリシーOIDの下で動作する必要があります。各CAは、ドメインポリシーOIDに加えて、独自のポリシーOIDを有していてもよいです。そのような場合には、CAは、両方のポリシーを遵守しなければなりません。ドメインポリシー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ドメインのメンバが証明書ポリシーを評価するプロセス（CPS）および他の潜在的なPKIドメインのメンバーの他のガバナンスのドキュメント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ドメインは、それらのメンバーに相互証明書を発行することによって、ドメインのメンバを定義するブリッジCAまたは統一CAを動作させることができます。
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ドメインが新しい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ドメインに参加することを選択したが、その同じPKIドメインの1つのまたは複数の他のメンバーの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ドメインの作成とメンテナンスに注意する必要があります。
In order for a PKI to participate in one or more PKI domains, that PKI must have the following:
PKIは、以下を持たなければならないことを、一つ以上の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 A証明書ポリシー文書は、PKIの動作のための要件を文書化。証明書ポリシー文書は、RFC 3647 [RFC3647]の形式でなければなりません。
o One or more Policy OIDs defined in the Certificate Policy Document that are also asserted in all certificates issued by that PKI.
また、そのPKIによって発行されたすべての証明書で主張されている証明書ポリシー文書で定義された1つのまたは複数のポリシーのOID O。
o A defined Principal CA.
O定義された主なCA.
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ドメインに参加すると、ドメインポリシーOID（複数可）、参加PKIによって発行された相互証明書に少なくともアサートする必要があります。参加した後、PKIは、そのPKIによって発行された証明書のドメインポリシーOID（複数可）を主張することができ、またはドメインをマッピングすることができます
Policy OID(s) to the Policy OID(s) asserted in certificates issued by that PKI.
ポリシーOID（S）へのポリシーOID（S）は、その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.
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.
o Unless the PKI domain has a predetermined membership, describe the requirements and methods for joining the PKI domain, such as FPKIMETHOD [FPKIMETHOD].
PKIドメインが所定の会員を有していない限り、O、[FPKIMETHOD]例えばFPKIMETHODとして、PKIのドメインに参加するための要件及び方法を記載します。
Examples of governance documents that PKI domains may choose to use are:
PKIドメインが使用することを選択するかもしれガバナンス文書の例は以下のとおりです。
o Statement of intent between two or more parties;
二つ以上の当事者間の意思のO文。
o Memorandum of Agreement between two or more parties;
O 2つの以上の当事者間の協定の覚書。
o Certificate Policy Document for the PKI domain;
O PKIドメインの証明書ポリシーの文書;
o Charter for the PKI domain; or
O PKIドメインのチャーター。または
o Methodology for PKI domain membership.
PKIドメインのメンバシップのための方法論O。
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.
別のPKIの主なCAに1つのPKIの主なCAからクロス証明書は、第PKIの1つまたは複数のポリシーと第二PKIの1つまたは複数のポリシーとの間のマッピングを示しています。証明書を検証することができれば、依拠当事者が決定されると、それがトラストアンカーに提示された証明書から証明書パスを構築します。単一PKIは、2つの以上の異なるPKIドメインのメンバーであるとき、PKIドメイン間で不用意な信頼関係を作成しないようにするには、各PKIドメインは、そのメンバーのPKIが参加するどのようなPKIドメインを認識しなければなりません。図9は、この概念を示しています。
+-----------------------------+
| PKI domain 2 |
+----------------------------+ |
| | | |
| +------+ <------ +------+ <------ +------+ |
| | PKI1 | | | PKI2 | | | PKI3 | |
| +------+ ------> +------+ ------> +------+ |
| | | |
| +-----------------------------+
| PKI domain 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証明書パスがPKI1からPKI2に、およびPKI2からPKI3にPKIドメイン1およびPKIドメイン2の両方のメンバーが存在しているので、認証パスもPKI1からPKI3に存在します。しかし、PKI1はPKI3でドメインメンバシップを共有していないので、PKIドメイン1の検証ポリシーにPKI3へPKI1から認証パス検証が成功してはいけません。正しい認証パス検証及びポリシマッピングを確実にするために、PKI2にPKI1およびPKI3の両方によって発行されたクロス証明書は、それぞれのドメイン外部認証パスの検証を許可しないようなポリシーマッピングまたは名前制約などの制約を含んでいなければなりません。
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 disallowed certification paths, the PKI domain must ensure that all such cross-certificates are revoked and re-issued with correct constraints.
完全に不注意信頼を防止するために、一つ以上のPKIドメインのメンバーである任意のPKIは、他のすべてのPKIドメインにその会員のすべてのそれらのPKIドメインを通知しなければなりません。また、PKIは、それがメンバー、他のPKIドメインに関してでいつでもそのメンバーシップのステータスが変更になっているすべてのそれらのPKIドメインを通知しなければならないということ。 PKIドメインが他のPKIドメインに関してとそのメンバのPKIの1の状態の変化が通知されている場合は、そのPKIドメインは、そのPKIに発行されたすべてのクロス証明書内の制約を確認する必要があります。メンバーシップの変更が許されているかどうか証明書パスへの変更につながる場合は、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は、複数の保証レベルで証明書を発行することができます。その場合は、証明書ポリシー文書は、各保証レベルに別々のポリシーOIDを定義する必要があり、異なる保証レベルの証明書の違いを定義する必要があります。
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ドメインは、複数の保証レベルをサポートすることができます。その場合は、PKIドメインは、各保証レベルに別々のポリシーOIDを定義する必要があり、各レベルの要件の違いを定義する必要があります。
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.
PKIとPKIドメインが信頼関係を確立することを選択した場合には、これらの信頼関係は、PKIの保証レベルとPKIドメイン保証レベル間の1対1の関係を有していてもよく、または多対1を有していてもよく、一つだけ定義されている保証レベルのために存在してもよいです保証レベル間または1対多の関係。これらの関係は、PKIドメインでの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.
二つ以上のPKIドメインは互いに信頼関係に入ることもできます。その場合には、彼らは新しい統一やブリッジCAを確立することによって、またはその主要なCA間のクロス証明書を発行することによって、より大きなPKIドメインを形成することができます。
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.
統一トラストポイントモデルでは、PKIドメインは優れたCAが統一CAとして定義され、図10にこのような接合部を示すように、各PKIドメインに片側クロス証明書を発行関節、優れたCAを確立することによって作成され、各PKIドメイン内の主なCAは、その統一CAと階層的なCAの関係を持っていますこのモデルでは、PKIドメインのいずれかから任意の証明書利用者は、他のPKIドメイン内の加入者を検証するために、そのトラストアンカーCAとして統一CAを指定する必要があります。証明書利用者は、他のPKIドメイン内の加入者を検証することを希望しない場合は、証明書利用者は、そのトラストアンカーCAとして古いPKIドメインからの主なCAを使用し続けることができます
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 parties. The unilateral cross-certificate issued by the Unifying CA to the Principal CAs in each PKI domain may include any policy mapping.
このモデルは、既存のPKIドメインにあまり変化により、単一のPKIドメインに複数のPKIドメインをマージするために使用することができる、または依拠当事者のための1つのPKIドメインに複数のPKIドメインを組み合わせるために使用することができます。各PKIドメインの校長CASに統一CAによって発行された一方的なクロス証明書は、任意のポリシーマッピングを含むことができます。
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 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
Figure 10: Unifying Trust Point (Unifying Domain) Model
図10：統一トラストポイント（統一ドメイン）モデル
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.
独立したトラストポイントモデルでは、依拠当事者は、彼らのPKIドメインの唯一のトラストアンカーを継続して使用します。個々の信頼ポイントモデルにおける依存者は、そのPKIドメインのトラストアンカーを使用し続けることができます。
In this model, each PKI domain trusts each other by issuing a cross-certificate directly between each Principal CA, as shown in
に示すように、このモデルでは、各PKIドメインは、各プリンシパルCAの間に直接の相互証明書を発行することによって互いを信頼し
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 | |
| +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +------------------------+
Figure 11: Direct Cross-Certification Model
図11：直接相互認証モデル
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.
このモデルでは、図12に示すように、相互認証により、ブリッジCAを介して互いに毎PKIドメイン信頼は、信頼関係は、加入者のドメインと直接信頼当事者のドメイン間で確立されていないが、のプリンシパルCAから確立しますブリッジCAを経由して相手のPKIドメインを頼りますこのモデルは、他のPKIドメインと相互運用するPKIドメインに必要な相互認証の数を減少させるのに有用です。
Requirements for Bridge model:
ブリッジモデルの要件：
o The Bridge CA must not be used as the trust anchor CA in any PKI domain.
OブリッジCAは、任意のPKIドメイン内のトラストアンカーCAとして使用することはできません。
o The Bridge CA should issue cross-certificates with other PKI domains mutually or may issue cross-certificates unilaterally.
OブリッジCAは、相互に他のPKIドメインとの相互証明書を発行する必要があるか、一方的に相互証明書を発行することができます。
o The Bridge CA must not issue End Entity (EE) certificates except when it is necessary for the CA's operation.
OブリッジCAは、エンドエンティティ（EE）はCAの動作に必要である場合を除いて、証明書を発行してはなりません。
o The Bridge CA must use its own domain Policy OID, not other PKI domain Policy OID(s), for the policy mapping.
OブリッジCAは、ポリシーマッピングするための独自のドメインポリシーOIDはなく、他のPKIドメインポリシー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ブリッジCAは、ブリッジCAを経由信頼すべてのPKIドメイン、中立位置でなければなりません例えば、図12で、そのトラストアンカーCAとしてPCA PKIのドメイン1を信頼する証明書利用者は、PKIドメイン3内の加入者への証明書パスを構築する場合：
Cross-Certificate from PKI domain 1 to the Bridge CA:
PKIドメイン1からブリッジCAの相互証明書：
issuerDomainPolicy ::= domain Policy OID of PKI domain 1
subjectDomainPolicy := domain Policy OID of the Bridge CA
subjectDomainPolicy：ブリッジCAの=ドメインポリシーOID
Cross-Certificate from the Bridge CA to PKI domain 3:
PKIドメイン3へのブリッジCAからクロス証明書：
issuerDomainPolicy ::= domain Policy OID of the Bridge CA
subjectDomainPolicy ::= domain Policy OID of PKI domain 3
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ブリッジCAに発行されたブリッジCAと相互認証によって発行されたクロス証明書は、証明書利用者がTRUEに初期の明示的なポリシーを設定していない可能性があるため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 PKIは、ブリッジCAとの相互認証ドメインと同じブリッジCAとの相互認証、他のPKIドメインに直接相互認証べきではありません
o The Bridge CA should clarify the method for the policy mapping of cross-certification to keep its transparency.
OブリッジCAは、その透明性を維持するための相互認証のポリシーマッピングのための方法を明確にする必要があります。
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:
留意事項：ブリッジCAは、独立した第三者によって運営されなければならないPKIドメインまたはPKIドメインメンバーからの代表者からなるコンソーシアムで合意しました。ブリッジCAは、十分に文書化され、合意された方法のすべてのPKIドメインでポリシーマッピングを行う必要があります。名前制約を適用する場合、ブリッジCAは、クロス認定PKIドメインのネームスペース間の競合を作成しないようにする必要があります。ブリッジCAとの相互認証を行うPKIドメインは、次の点を確認する必要があります。
* Does the Bridge CA perform the policy mapping via its own domain Policy OID?
*ブリッジCAは、独自のドメインポリシーOIDを経由してポリシーマッピングを実行していますか？
* Does the Bridge CA clarify the method of policy mapping in the cross-certification?
*ブリッジCAは、相互認証におけるポリシーマッピングの方法を明確にしていますか？
* Is the Bridge CA able to accept the domain policy that the PKI domain desires?
*ブリッジCAは、ドメインポリシー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ドメインは慎重に低いセキュリティレベルで証明書を受け入れるに伴うリスクを考慮する必要があります。
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 | |
| +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +---------------+ +----------------------+
Figure 12: Bridge Model
図12：ブリッジモデル
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ドメインが認識して続きます。
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.
PKI自身で締結したPKIドメインの信頼関係とは対照的に、複数のPKI間で信頼関係がトラストアンカーのローカルに設定されたリストを経由のPKIへの外部エンティティによって作成することができます。
Trust List: A set of one or more trust anchors used by a relying party to explicitly trust one or more PKIs.
信頼リスト：明示的に一の以上のPKIを信頼する証明書利用者によって使用される1つまたは複数の信頼アンカーのセット。
Note that Trust Lists are often created without the knowledge of the PKIs that are included in the list.
信頼リストは、多くの場合、リストに含まれているのPKIの知識なしに作成されていることに注意してください。
A Trust List can be created and maintained by a single relying party for its own use.
信頼リストが作成され、自身が使用するための単一の証明書利用者によって維持することができます。
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.
ローカル信頼リスト：信頼リストがインストールされており、自身が使用するための単一の依拠当事者によって維持。注：この定義は、RFC 4949 [RFC4949]で定義された「信頼ファイルPKI」に似ています。しかし、この文書では、用語「ローカル信頼リスト」は以下に定義する「トラスト当局」と対照的な好みます。
Figure 13 illustrates a Local Trust List.
図13は、ローカル信頼リストを示しています。
+-------------------------------------------------------------+
| Relying party |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
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 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.
ローカル信頼リストを作成すると、EE証明書を信頼するように依拠当事者のための最も簡単な方法です。パス内のすべてのCAが含まれることができるようローカル信頼リストを使用すると、依拠当事者自身の証明書を発行したPKIとEEの証明書を発行したPKI間の相互認証を必要としません。また、複雑な証明書パスを処理するためのメカニズムを実装する必要がありませんローカル信頼リストインチその結果、ローカルの信頼リストを使用して、今日最も一般的なモデルです。ローカルの信頼リストを作成し、各依存者によって独立して管理されているので、企業が管理するしかし、ローカルの信頼リストの使用が困難な場合があります。
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 Authority: An entity that manages a Trust List for use by one or more relying parties.
信託機関：一つ以上の信頼者が使用するために信頼リストを管理するエンティティ。
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は、信頼機関を示し、どのようにそれが依拠当事者により使用されます。トラスト当局は、各参加証明書利用者のためのローカル信頼リストにおけるPKIのトラストアンカー（複数可）を置き換えることに注意してください。
+-------------------------------------------------------------+
| Trust Authority |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+---------------------+ +---------------------+
| Relying party 1 | | Relying party 2 |
| +-----------------+ | | +-----------------+ | ...
| | Trust Authority | | | | Trust Authority | |
| +-----------------+ | | +-----------------+ |
+---------------------+ +---------------------+
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
トラスト当局は、PKI、ユーザーの共通セット、その依拠当事者のすべてに代わって、企業、または独立したエンティティを共有依拠当事者の集まりで動作させることができます。 PKIは、一般的に、クロス証明書による信頼関係を確立しますが、PKIは、証明書パスの処理をサポートしていない信頼者をサポートするために、信頼管轄を提供することもできます。ユーザーの共通セットを共有する依拠当事者のコレクションは、信頼リストの管理を簡素化するために、単一の信頼管轄を維持することもできます。企業が提供することもできます
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.
トラスト当局は、企業のポリシーを実装し、その信頼管轄を使用するために、企業内のすべての依拠当事者を指示します。最後に、独立したエンティティは、管理対象サービスとして信頼管轄を操作することもできます。
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.
依拠当事者とトラスト当局があれば、保証はEE証明書への依存に関するPKIによって提供されているもの、を判断できるように、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が広く、他の適切なメカニズム失効またはWebページ、プレスリリースの告知を通じてトラストアンカーCAや校長CA証明書の妥協に関する情報を公表、および/または必要がある場合はトラストアンカーCAまたは信頼リストにインストール主なCA証明書を削除する必要があります。
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証明書に依存することを望む当事者でアクセスできるリポジトリに証明書失効リスト（CRL）またはEE証明書の失効状態に関するその他の情報を公開しなければなりません。
Relying Parties and Trust Authorities are responsible for the following prior to including a PKI in the Trust List:
依拠当事者とトラスト当局の責任は、以下の信頼リストでPKIを含む前に：
o Reviewing the Certificate Policy Document of each PKI to determine that the PKI is operated to an acceptable level of assurance;
PKIは、保証の許容レベルに操作されたことを決定するために、各PKIの証明書ポリシードキュメントをレビューOであり;
o Reviewing the Certificate Policy Document of each PKI to ensure any requirements imposed on Relying Parties are met;
依拠当事者に課せられたすべての要件が満たされていることを確認するために、各PKIの証明書ポリシー文書のレビューO;
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
PKIは、EE証明書への依存度に関していかなる保証を提供する場合、これらの保証は、EE証明書上の意図した信頼のために許容されるかどうかの確認、O。リライアンスは、依拠当事者自身の危険にさらされる可能性があります。そして
o Periodically reviewing information published by the PKI to its repository, including Certificate Policy Document updates or notice of CA revocation or compromise.
O定期的に証明書ポリシー文書の更新またはCAの失効や妥協の通知を含め、そのリポジトリへのPKIにより、公開された情報を検討。
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, it is the responsibility of the relying party or Trust Authority to inhibit policy mapping.
PKIは、その証明書ポリシー文書に従ってPKIドメインに参加するか、残すことを選択することができます。証明書利用者または信託機関がこれらのPKIドメインの他のメンバーの信頼を継承したくない場合は、ポリシーマッピングを抑制するために依存者やトラスト当局の責任です。
A Trust Authority should establish a Trust Authority Policy that identifies the following:
トラスト当局は、以下を識別トラスト当局の方針を確立する必要があります。
o The intended community of Relying Parties that will use the Trust Authority;
信頼管轄を使用します依拠当事者の意図コミュニティO;
o The process by which trust anchors are added or removed from the Trust List;
Oトラストアンカーは、信頼リストから追加または削除されるプロセス。
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;
EE証明書への依存のために信託公社が提供する保証、O。これらの保証は、それ自体のPKIによって提供されるものであってもよいし、信頼機関によって提供される追加の保証であってもよいです。
o Information regarding how the Trust Authority protects the integrity of its Trust List; and
Oトラスト当局はその信頼リストの整合性を保護する方法に関する情報。そして
o Information regarding how Relying Parties interact with the Trust Authority to obtain information as to whether an EE certificate is trusted.
O依拠当事者は、EE証明書が信頼されているか否かの情報を得るためにトラスト当局との対話方法に関する情報。
CA: Certification Authority
CA：認証局
EE: End Entity
この：エンドエンティティ
OID: Object Identifier
OID：オブジェクト識別子
PCA: Principal Certification Authority
PCA：主な認証局
PKI: Public Key Infrastructure
PKI：公開鍵インフラストラクチャ
This section highlights security considerations related to establishing PKI domains.
このセクションでは、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 applicable because all information created by CAs, including policy mapping and constraints, is digitally signed by the CA generating the cross-certificate.
クロス証明書を発行して作成したセクション3.3に記載されているすべてのPKIドメインモデルでは、メッセージの挿入、変更、および中間者を含む標準の脅威が適用されないため、ポリシーマッピングと制約を含むCAによって作成されたすべての情報は、デジタルクロス証明書を生成するCAによって署名されています。
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の信頼。
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.
証明書がデジタル署名されているので、これらのモデルでは、多くの標準的な攻撃は適用されません。信頼が信頼リストを介して作成されたときに、追加のセキュリティに関する考慮事項が適用されます。
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.
修正攻撃のバリエーションは、信頼リストモデルで可能です。攻撃者は、証明書利用者または信頼管轄信頼リストからCAを追加または削除することができた場合、攻撃者はその証明書があろうか、受け入れられないであろう影響を与えることができます。この攻撃を防ぐには、信頼リストへのアクセスが適切に不正な変更から保護されなければなりません。この保護は、それがこのモデルの重要な脆弱性があるとして、複数のアプリケーションで使用されているトラストアンカーのために特に重要です。 CAが信頼リストに追加された場合、またはサービス拒否するCAが信頼リストから削除された場合、この攻撃は、不正利用状況になることがあります。
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.
アプリケーションは、トラストアンカーからタイムリーな情報を取得できない場合は信頼管轄モデルでは、サービス拒否攻撃も可能です。アプリケーションは、トラスト当局とのサービスレベル契約を指定する必要があります。また、アプリケーションは、ローカルトラストアンカーのリポジトリ（たとえば、LDAP（Lightweight Directory Access Protocol）ディレクトリ）という場合のバックアップとしてトラスト当局によって維持CAのリストをキャッシュに選択することができません。
[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）のプロフィール」、RFC 5280、2008年5月。
[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/documents/ crosscert_method_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公開鍵基盤証明書ポリシーと認証実践フレームワーク"、RFC 3647、2003年11月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、RFC 4949、2007年8月。
Authors' Addresses
著者のアドレス
Masaki Shimaoka (editor) SECOM Co., Ltd. Intelligent System Laboratory SECOM SC Center, 8-10-16 Shimorenjaku Mitaka, Tokyo 181-8528 JP
まさき しまおか （えぢとｒ） せこＭ こ。、 Ｌｔｄ。 いんてっぃげんｔ Ｓｙｓてｍ ぁぼらとｒｙ せこＭ ＳＣ せんてｒ、 ８ー１０ー１６ しもれんじゃく みたか、 ときょ １８１ー８５２８ ＪＰ
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ゲイサーズバーグ、MD 20899から8930米を停止
EMail: nelson.hastings@nist.gov
メールアドレス：nelson.hastings@nist.gov
Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US
レベッカ・ニールセンブーズ・アレン・ハミルトン8283グリーンズボロドライブマクリーン、バージニア州22102米国
EMail: nielsen_rebecca@bah.com
メールアドレス：nielsen_rebecca@bah.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。