[要約] RFC 5217は、異なるドメイン間での公開鍵基盤（PKI）の相互運用性に関するメモです。その目的は、異なるPKIドメイン間での信頼性と相互運用性を向上させるためのガイドラインを提供することです。
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）ドメインの運用要件を提案することです。このドキュメントでは、認証当局（CAS）間の関係について説明し、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の典型的なモデルについて説明します。セクション4では、党とCAの関係に依存することに応じて、信頼リストモデルを検討します（CA-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]).
証明書：システムエンティティのIDの公開鍵値への拘束力を証明するデジタル署名されたデータ構造（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]).
END ENTITY（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].
CASは、他の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].
認証階層には、RFC 4949 [RFC4949]に記載されているように、「優れたCA」と「下位CA」の2種類のCASがあります。
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）による1つのCa（Ca1）の相互認定ですが、Ca1によるCa2の相互認証はありません。
Bilateral cross-certification: Cross-certification of one CA (CA1) by another CA (CA2) and cross-certification of CA2 by CA1.
二国間相互認証：別のCa（Ca2）による1つの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つのタイプがあります。1つ（上位）CAが部下のCA証明書を別の証明書に発行する場合、自己署名証明書を持たなければならない階層の上部にあるCAは、ルートCAと呼ばれます。1つのCAが他のCASに対して一方的な相互認証を発行する場合、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のコンテキスト）には、用語「Trust Anchor 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と呼ばれます。CASは、図3に示すように、ブリッジ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.
Bridge 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）：証明書管理、アーカイブ管理、主要な管理、トークン管理機能を実行するCASシステムのシステムは、非対称暗号化の適用においてユーザーのコミュニティのために、同じ証明書の下で運営されています。ポリシーOIDの共有セットを指定するポリシー文書。単一の組織または単一の組織の指示の下で運営されています。
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で主要なCASに相互認知度を発行するCAとして指定され、他の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.
認定パス：パス内の各証明書の主題がパスの次の証明書の発行者である証明書の順序付けられたシーケンス。認定パスは、Trust Anchor証明書から始まり、End Entity証明書で終わります。
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.
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は、EESに証明書を発行する単一のルートCAと1つ以上の下位CAで構成されています。階層的なPKIには中間CAがあり、それ自体が下位CAを持っているCASです。ルートCAは、トラストアンカー（公開キーと関連データ）を配布する必要がありますが、この仕様とは形式とプロトコルは無関係です。図5に示すように、すべての下位CASには下位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は、EESに証明書を発行し、相互に相互に認証を発行する自己署名証明書を持つ複数のCAで構成されています。メッシュPKIは、図6に示すように、すべてのCASが他のすべてのCASに相互認証を発するフルメッシュである場合があります。メッシュPKIは、すべてのCAが他のすべてのCAに相互認証を発行しない部分メッシュである場合があります。。部分的なメッシュPKIでは、図7に示すように、認定パスはすべての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.
Trust Anchor CA：最終エンティティのTrust Anchor CAは、通常、End Entityの証明書を発行したCAです。メッシュPKIから証明書を発行されていない最終エンティティのトラストアンカーCAは、PKIの任意のCAである可能性があります。部分的なメッシュでは、信頼アンカーの選択により、メッシュ内の1つ以上のCASへの信頼アンカーから認証パスがなくなる場合があります。たとえば、上記の図7では、トラストアンカーCAとしてのCA1またはCA2の選択により、図のすべてのエンティティからのパスが生じます。ただし、CA3をトラストアンカーCAとして選択すると、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.
プリンシパルCA：主要なCAは、メッシュPKI内の任意のCAである場合があります。ただし、メッシュPKIには1つの主要な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の経路がすべてのCAからメッシュ内の他のすべての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には1つの主要な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への信頼アンカーによって信頼関係を確立します。頼る当事者は、1つ以上のPKIに信頼関係を確立するために信託リストを使用する場合があります。信頼リストは、1つ以上の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種類のメンテナンスモデルがあります。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.
2つ以上のPKIは、互いに信頼関係に入ることを選択する場合があります。これらの関係について、各PKIは、独自の証明書ポリシーOIDSと独自の主要なCAを保持しています。信頼関係を検討するビジネス上の決定を下すことに加えて、各PKIは、ポリシーマッピングとして知られるプロセスを通じて、外部PKI証明書ポリシードキュメントおよびその他のPKIガバナンスドキュメントをレビューすることにより、各外部PKIの信頼レベルを決定します。信頼関係は、異文学の発行を通じて技術的に形式化されます。このような2つ以上の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ドメイン：クロス認証を使用して互いに信頼関係を築くことを選択した2つ以上の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ドメインを再帰的に指定します。これは、RFC 4949 [RFC4949]の定義とは異なり、CAドメインの同義語としてPKIドメインを与え、CAおよびその主題エンティティの観点から定義します。
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ドメインのメンバーが証明書ポリシー（CPS）および他の潜在的なPKIドメインメンバーのその他のガバナンス文書を評価するプロセスで、PKIドメインの各PKIが互いの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 2つ以上の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が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の操作の要件を文書化する証明書ポリシー。証明書ポリシードキュメントは、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.
o 証明書のポリシー文書で定義されている1つ以上のポリシーOIDは、そのPKIによって発行されたすべての証明書にも主張されています。
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 Policy OID(s) to the Policy OID(s) asserted in certificates issued by that PKI.
PKIドメインに参加する場合、少なくとも参加PKIによって発行されたクロス認証でドメインポリシーOIDを主張する必要があります。参加後、PKIはそのPKIによって発行された証明書にドメインポリシーOIDを主張することができます。または、そのPKIが発行した証明書で主張されたポリシーOID（s）にドメインポリシーをマッピングすることができます。
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ドメイン当局の例は、（1）単純なPKIドメインを形成することに同意する2つのPKIの代表者です。各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.
PKIドメインの意図の例は、（1）あるPKIの当事者に別のPKIによって発行された証明書を信頼することを許可することを許可します。すべての要件を満たす多くのPKIによって発行された証明書。
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ドメインに事前に決められたメンバーシップがない限り、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 2つ以上の当事者間の意図の声明。
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.
o 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.
あるPKIの主要なCAから別のPKIの主要なCAへの相互認証は、最初のPKIの1つ以上のポリシーと2番目の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は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 disallowed certification paths, the PKI domain must ensure that all such cross-certificates are revoked and re-issued with correct constraints.
不注意な信頼を完全に防ぐために、1つ以上の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ドメインが信頼関係を確立することを選択する場合、これらの信頼関係は1つの定義された保証レベルのみで存在する可能性があり、PKI保証レベルとPKIドメイン保証レベルの間に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.
2つ以上の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.
統合トラストポイントモデルでは、図10に示すように、各PKIドメインに一方的なクロス認証を発行する共同の優れたCAを確立することにより、PKIドメインが作成されます。各PKIドメインの主要なCAは、その統一CAと階層的なCAとの関係を持っています。このモデルでは、PKIドメインのいずれかからの依存者は、他のPKIドメインのサブスクライバーを検証するために、その信頼アンカーCAとして統一CAを指定する必要があります。頼っている当事者が他のPKIドメインの加入者を検証することを望んでいない場合、頼る当事者は、古いPKIドメインの主要なCAをその信頼アンカー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ドメインに統合するために使用される場合や、複数のPKIドメインを1つのPKIドメインに組み合わせて依存関係者に組み合わせることができます。各PKIドメインの主要なCAに統一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 Figure 11. This model may be used for shortening a certification path or establishing a trust relationship expeditiously.
このモデルでは、各PKIドメインは、図11に示すように、各プリンシパルCAの間に直接クロス認証を発行することにより互いに信頼しています。このモデルは、認証パスの短縮または信頼関係の確立に使用される場合があります。
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に示すように、すべてのPKIドメインは、相互認証によるブリッジCAを介して互いに信頼しています。信頼関係は、サブスクライバードメインと頼るパーティドメインの間に直接確立されていませんが、主要な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 Bridge CAは、他のPKIドメインと相互に相互に相互に認識するか、クロス認証を一方的に発行する可能性があります。
o The Bridge CA must not issue End Entity (EE) certificates except when it is necessary for the CA's operation.
o Bridge CAは、CAの操作に必要な場合を除き、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 ブリッジCAは、ポリシーマッピングのために、他のPKIドメインポリシーOIDではなく、独自のドメインポリシー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は、すべてのPKIドメインにとって中立的な位置である必要があります。たとえば、図12では、PKIドメイン1のPCAを信頼できるAnchor CAとして信頼する依存者が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：=ブリッジのドメインポリシーoid ca
Cross-Certificate from the Bridge CA to PKI domain 3:
Bridge CAからPKI Domain 3への相互認証
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 Bridge CAおよびBridge CAに発行されたBridge CAによって発行された相互認証は、依存する当事者が初期標準型を真に設定しない可能性があるため、PolicyConstraints拡張でゼロより大きい値を持つReaceexplicitPolicyを含める必要があります。
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 Caと相互認定されたPKIドメインは、同じブリッジと相互認定された他の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:
考慮事項：Bridge CAは、PKIドメインまたはPKIドメインメンバーの代表者で構成されるコンソーシアムによって合意された独立した第三者によって運営されるべきです。Bridge CAは、すべてのPKIドメインで十分に文書化され、合意された方法でポリシーマッピングを行う必要があります。名前の制約を適用する場合、Bridge CAは、相互認定PKIドメインの名前空間間に競合を作成しないようにする必要があります。Bridge CAで相互認証を実行するPKIドメインは、次のことを確認する必要があります。
* Does the Bridge CA perform the policy mapping via its own domain Policy OID?
* Bridge 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.
+ ドメインポリシーがセキュリティレベルが低いものにマッピングされている場合、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ドメインが制約に認定パスへの影響に影響を与える場合、CrossexplictificatesのPolicyConstraints拡張でrequesexplicitpolicyをゼロに設定する必要があります。そのような制約について頼る当事者の検証ポリシーに依存している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.
信頼リスト：頼りになる当事者が使用する1つ以上の信頼できるアンカーのセットは、1つ以上のPKIを明示的に信頼しています。
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]で定義されている「Trust-File 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証明書を信頼するために当事者に依存する最も簡単な方法です。ローカルトラストリストの使用には、頼りになる当事者自身の証明書を発行したPKIとEEの証明書を発行したPKI間の相互認証は必要ありません。また、パス内のすべてのCAを含めることができるため、複雑な認証パスを処理するための実装メカニズムを必要としません。ローカルトラストリストで。その結果、ローカルトラストリストは、今日使用されている最も一般的なモデルです。ただし、ローカルトラストリストは依存する各当事者によって独立して作成および管理されるため、エンタープライズが管理するのは困難な場合があります。
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.
信託当局：1つ以上の当事者が使用するための信託リストを管理するエンティティ。
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 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.
信託当局は、PKI、共通のユーザーセットを共有する頼る当事者のコレクション、すべての依存関係者に代わって企業、または独立したエンティティによって運営される場合があります。PKIは一般に異文学を通じて信頼関係を確立しますが、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は、証明書のポリシー文書を公開して、当事者と信託当局が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は、Webページの通知、プレスリリース、および/またはその他の適切なメカニズムを通じて、信託アンカー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証明書に依存したい当事者がアクセスできるリポジトリへのEE証明書の取り消しステータスに関する証明書の取り消しリスト（CRL）またはその他の情報を公開する必要があります。
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;
o 各PKIの証明書ポリシー文書を確認して、PKIが許容可能なレベルの保証に操作されることを判断します。
o Reviewing the Certificate Policy Document of each PKI to ensure any requirements imposed on Relying Parties are met;
o 各PKIの証明書ポリシー文書を確認して、依存する当事者に課される要件が満たされていることを確認します。
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が公開した情報をリポジトリに定期的に確認します。
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;
o EE証明書に依存するために信託当局が提供する保証。これらの保証は、PKIS自体によって提供される保証である場合もあれば、信託当局によって提供される追加の保証である場合もあります。
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
EE：終了エンティティ
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.
信頼リストモデルでは、変更攻撃のバリエーションが可能です。攻撃者が頼っている当事者または信託機関の信託リストからCASを追加または削除できる場合、攻撃者はどの証明書に影響を与えるか、または受け入れられないかに影響を与えることができます。この攻撃を防ぐには、信頼リストへのアクセスを不正な変更から適切に保護する必要があります。この保護は、このモデルの重要な脆弱性であるため、複数のアプリケーションで使用される信頼アンカーにとって特に重要です。この攻撃により、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.
信頼機関のモデルの場合、アプリケーションがトラストアンカーからタイムリーな情報を取得できない場合、サービス拒否攻撃も可能です。申請書は、信託当局とのサービスレベルの契約を指定する必要があります。さらに、アプリケーションは、Trust Anchorのリポジトリ（Lightweight Directory Access Protocol（LDAP）ディレクトリなど）が利用できない場合、信託当局がバックアップとして維持しているCASのリストをローカルにキャッシュすることを選択できます。
[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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、and W. Polk、 "Internet 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.、Ford、W.、Sabett、R.、Merrill、C。、およびS. Wu、「インターネット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
マサキ・シマカ（編集者）Secom Co.、Ltd。Intelligent System Laboratory Secom SC Center、8-10-16 Shimorenjaku Mitaka、Tokyo 181-8528 JP
EMail: 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 Gaithersburg、MD 20899-8930 US
EMail: nelson.hastings@nist.gov
Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US
レベッカニールセンブーズアレンハミルトン8283グリーンズボロドライブマクリーン、バージニア州22102 US
EMail: nielsen_rebecca@bah.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。