RFC4158 日本語訳
4158 Internet X.509 Public Key Infrastructure: Certification PathBuilding. M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas. September 2005. (Format: TXT=199297 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Cooper
Request for Comments: 4158 Orion Security Solutions
Category: Informational Y. Dzambasow
A&N Associates
P. Hesse
Gemini Security Solutions
S. Joseph
Van Dyke Technologies
R. Nicholas
BAE Systems
September 2005
コメントを求めるワーキンググループM.桶屋要求をネットワークでつないでください: 4158年のオリオンセキュリティソリューションカテゴリ: 情報のY.Dzambasow A&NはP.ヘッセ双子座セキュリティソリューションS.ジョゼフヴァンダイク技術R.ニコラスBAEシステム2005年9月に交際します。
Internet X.509 Public Key Infrastructure:
Certification Path Building
インターネットX.509公開鍵暗号基盤: 証明経路ビル
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.
このドキュメントは彼らのアプリケーションの中に公開鍵証明経路をX.509に造る開発者に指導と推薦を提供します。 本書では定義された指導と推薦に続くことによって、アプリケーション開発者は強健なX.509を開発するのがさまざまなPKI環境の向こう側に有効な証明経路を造ることができるアプリケーションを証明書で可能にしたより傾向があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................4
1.2. Purpose ....................................................4
1.3. Terminology ................................................5
1.4. Notation ...................................................8
1.5. Overview of PKI Structures .................................8
1.5.1. Hierarchical Structures .............................8
1.5.2. Mesh Structures ....................................10
1.5.3. Bi-Lateral Cross-Certified Structures ..............11
1.5.4. Bridge Structures ..................................13
1.6. Bridge Structures and Certification Path Processing .......14
1. 序論…3 1.1. 動機…4 1.2. 目的…4 1.3. 用語…5 1.4. 記法…8 1.5. PKI構造の概要…8 1.5.1. 階層的な構造…8 1.5.2. 構造を網の目にかけてください…10 1.5.3. 双方の十字で公認された構造…11 1.5.4. 構造をブリッジしてください…13 1.6. 構造と証明経路処理をブリッジしてください…14
Cooper, et al. Informational [Page 1] RFC 4158 Certification Path Building September 2005
クーパー、他 [1ページ]情報のRFC4158証明経路ビル2005年9月
2. Certification Path Building ....................................15
2.1. Introduction to Certification Path Building ...............15
2.2. Criteria for Path Building ................................16
2.3. Path-Building Algorithms ..................................17
2.4. How to Build a Certification Path .........................21
2.4.1. Certificate Repetition .............................23
2.4.2. Introduction to Path-Building Optimization .........24
2.5. Building Certification Paths for Revocation Signer
Certificates ..............................................30
2.6. Suggested Path-Building Software Components ...............31
2.7. Inputs to the Path-Building Module ........................33
2.7.1. Required Inputs ....................................33
2.7.2. Optional Inputs ....................................34
3. Optimizing Path Building .......................................35
3.1. Optimized Path Building ...................................35
3.2. Sorting vs. Elimination ...................................38
3.3. Representing the Decision Tree ............................41
3.3.1. Node Representation for CA Entities ................41
3.3.2. Using Nodes to Iterate Over All Paths ..............42
3.4. Implementing Path-Building Optimization ...................45
3.5. Selected Methods for Sorting Certificates .................46
3.5.1. basicConstraints Is Present and cA Equals True .....47
3.5.2. Recognized Signature Algorithms ....................48
3.5.3. keyUsage Is Correct ................................48
3.5.4. Time (T) Falls within the Certificate Validity .....48
3.5.5. Certificate Was Previously Validated ...............49
3.5.6. Previously Verified Signatures .....................49
3.5.7. Path Length Constraints ............................50
3.5.8. Name Constraints ...................................50
3.5.9. Certificate Is Not Revoked .........................51
3.5.10. Issuer Found in the Path Cache ....................52
3.5.11. Issuer Found in the Application Protocol ..........52
3.5.12. Matching Key Identifiers (KIDs) ...................52
3.5.13. Policy Processing .................................53
3.5.14. Policies Intersect the Sought Policy Set ..........54
3.5.15. Endpoint Distinguished Name (DN) Matching .........55
3.5.16. Relative Distinguished Name (RDN) Matching ........55
3.5.17. Certificates are Retrieved from
cACertificate Directory Attribute .................56
3.5.18. Consistent Public Key and Signature Algorithms ....56
3.5.19. Similar Issuer and Subject Names ..................57
3.5.20. Certificates in the Certification Cache ...........57
3.5.21. Current CRL Found in Local Cache ..................58
3.6. Certificate Sorting Methods for Revocation Signer
Certification Paths .......................................58
3.6.1. Identical Trust Anchors ............................58
3.6.2. Endpoint Distinguished Name (DN) Matching ..........59
3.6.3. Relative Distinguished Name (RDN) Matching .........59
2. 証明経路ビル…15 2.1. 証明経路ビルへの序論…15 2.2. 経路ビルの評価基準…16 2.3. 経路ビルアルゴリズム…17 2.4. どう証明経路を造るか…21 2.4.1. 反復を証明してください…23 2.4.2. 経路を造る最適化への序論…24 2.5. 取消し署名者証明書のために証明経路を造ります…30 2.6. 経路を造るソフトウェアコンポーネントを示します…31 2.7. 経路を造るモジュールに入力します。33 2.7.1. 入力を必要とします…33 2.7.2. 任意の入力…34 3. 経路ビルを最適化します…35 3.1. 経路ビルを最適化します…35 3.2. 除去に対して分類します。38 3.3. 意思決定の樹状図を表します…41 3.3.1. カリフォルニア実体のノード表現…41 3.3.2. すべての経路にわたって繰り返すノードを使用します…42 3.4. 経路を造る最適化を実装します…45 3.5. ソーティング証明書のためにメソッドを選択します…46 3.5.1basicConstraintsは本当にプレゼントとcA同輩です…47 3.5.2. 署名アルゴリズムを認識します…48 3.5.3keyUsageは正しいです…48 3.5.4. 時間(T)は証明書の正当性の中に下がります…48 3.5.5. 証明書は以前に、有効にされました…49 3.5.6. 以前に、署名について確かめます…49 3.5.7. 経路長さの規制…50 3.5.8. 規制を命名してください…50 3.5.9. 証明書は取り消されません…51 3.5.10. 経路キャッシュで見つけられた発行人…52 3.5.11. 発行人はアプリケーションでプロトコルを見つけました…52 3.5.12. 主要な識別子(子供)を合わせます…52 3.5.13. 方針処理…53 3.5.14. 方針は交差しています。探された方針はセットしました…54 3.5.15. 終点分類名(DN)マッチング…55 3.5.16. 相対的な分類名(RDN)マッチング…55 3.5.17. 証明書はcACertificateディレクトリAttributeからのRetrievedです…56 3.5.18. 一貫した公開鍵と署名アルゴリズム…56 3.5.19. 同様の発行人と対象の名前…57 3.5.20. 証明キャッシュにおける証明書…57 3.5.21. 現在のCRLは地方でキャッシュを見つけました…58 3.6. 取消し署名者証明経路にソーティングメソッドを証明してください…58 3.6.1. 同じ信頼は投錨されます…58 3.6.2. 終点分類名(DN)マッチング…59 3.6.3. 相対的な分類名(RDN)マッチング…59
Cooper, et al. Informational [Page 2] RFC 4158 Certification Path Building September 2005
クーパー、他 [2ページ]情報のRFC4158証明経路ビル2005年9月
3.6.4. Identical Intermediate Names .......................60
4. Forward Policy Chaining ........................................60
4.1. Simple Intersection .......................................61
4.2. Policy Mapping ............................................62
4.3. Assigning Scores for Forward Policy Chaining ..............63
5. Avoiding Path-Building Errors ..................................64
5.1. Dead Ends .................................................64
5.2. Loop Detection ............................................65
5.3. Use of Key Identifiers ....................................66
5.4. Distinguished Name Encoding ...............................66
6. Retrieval Methods ..............................................67
6.1. Directories Using LDAP ....................................67
6.2. Certificate Store Access via HTTP .........................69
6.3. Authority Information Access ..............................69
6.4. Subject Information Access ................................70
6.5. CRL Distribution Points ...................................70
6.6. Data Obtained via Application Protocol ....................71
6.7. Proprietary Mechanisms ....................................71
7. Improving Retrieval Performance ................................71
7.1. Caching ...................................................72
7.2. Retrieval Order ...........................................73
7.3. Parallel Fetching and Prefetching .........................73
8. Security Considerations ........................................74
8.1. General Considerations for Building a Certification Path ..74
8.2. Specific Considerations for Building Revocation
Signer Paths ..............................................75
9. Acknowledgements ...............................................78
10. Normative References ..........................................78
11. Informative References ........................................78
3.6.4. 同じ中間的名前…60 4. 方針推論を進めてください…60 4.1. 簡単な交差点…61 4.2. 方針マッピング…62 4.3. 割り当ては前向きな方針推論のために得点されます…63 5. 経路を造る誤りを避けます…64 5.1. 行き止まり…64 5.2. 検出を輪にしてください…65 5.3. 主要な識別子の使用…66 5.4. 分類名コード化…66 6. 検索メソッド…67 6.1. LDAPを使用するディレクトリ…67 6.2. HTTPでストアAccessを証明してください…69 6.3. 権威情報アクセス…69 6.4. 対象の情報アクセス…70 6.5. CRL分配は指します…70 6.6. Applicationプロトコルを通したデータObtained…71 6.7. 独占メカニズム…71 7. 検索性能を向上させます…71 7.1. キャッシュします。72 7.2. 検索命令…73 7.3. とって来るのとPrefetchingに沿ってください…73 8. セキュリティ問題…74 8.1. 証明経路を造るための一般問題。74 8.2. ビル取消し署名者経路への特定の問題…75 9. 承認…78 10. 標準の参照…78 11. 有益な参照…78
1. Introduction
1. 序論
[X.509] public key certificates have become an accepted method for securely binding the identity of an individual or device to a public key, in order to support public key cryptographic operations such as digital signature verification and public key-based encryption. However, prior to using the public key contained in a certificate, an application first has to determine the authenticity of that certificate, and specifically, the validity of all the certificates leading to a trusted public key, called a trust anchor. Through validating this certification path, the assertion of the binding made between the identity and the public key in each of the certificates can be traced back to a single trust anchor.
[X.509]公開鍵証明書はしっかりと個人かデバイスのアイデンティティを公開鍵に縛るための受け入れられたメソッドになりました、デジタル署名照合や公開鍵ベースの暗号化などの公開鍵の暗号の操作をサポートするために。 しかしながら、アプリケーションは最初に証明書に含まれた公開鍵を使用する前にその証明書の信憑性を決定しなければなりません、そして、明確に信じられた公開鍵につながるすべての証明書の正当性は信頼アンカーに電話をしました。 この証明経路を有効にすることで、それぞれの証明書のアイデンティティと公開鍵の間でされた結合の主張を独身の信頼アンカーにたどって戻すことができます。
The process by which an application determines this authenticity of a certificate is called certification path processing. Certification path processing establishes a chain of trust between a trust anchor and a certificate. This chain of trust is composed of a series of
アプリケーションが証明書のこの信憑性を決定するプロセスは証明経路処理と呼ばれます。 証明経路処理は信頼アンカーと証明書の間の信頼のチェーンを設立します。 これはaシリーズについて構成された信頼をチェーニングします。
Cooper, et al. Informational [Page 3] RFC 4158 Certification Path Building September 2005
クーパー、他 [3ページ]情報のRFC4158証明経路ビル2005年9月
certificates known as a certification path. A certification path begins with a certificate whose signature can be verified using a trust anchor and ends with the target certificate. Path processing entails building and validating the certification path to determine whether a target certificate is appropriate for use in a particular application context. See Section 3.2 of [RFC3280] for more information on certification paths and trust.
証明経路として知られている証明書。 証明経路は、信頼アンカーを使用することで署名について確かめることができる証明書で始まって、目標証明書で終わります。 経路処理は、特定用途文脈における使用に、目標証明書が適切であるかどうか決定するために証明経路を建てて、有効にするのを伴います。 証明経路と信頼の詳しい情報に関して[RFC3280]のセクション3.2を見てください。
1.1. Motivation
1.1. 動機
Many other documents (such as [RFC3280]) cover certification path validation requirements and procedures in detail but do not discuss certification path building because the means used to find the path does not affect its validation. This document therefore is an effort to provide useful guidance for developers of certification path- building implementations.
以前はよく経路が合法化に影響しないのが手段によってわかっていたので、他の多くのドキュメント([RFC3280]などの)は、詳細に証明経路合法化要件と手順を含んでいますが、証明経路ビルについて議論しません。 したがって、このドキュメントは実装を築き上げながら証明経路の開発者に役に立つ指導を提供する取り組みです。
Additionally, the need to develop complex certification paths is increasing. Many PKIs are now using complex structures (see Section 1.5) rather than simple hierarchies. Additionally, some enterprises are gradually moving away from trust lists filled with many trust anchors, and toward an infrastructure with one trust anchor and many cross-certified relationships. This document provides helpful information for developing certification paths in these more complicated situations.
さらに、複雑な証明経路を開発する必要性は大きくなっています。 多くのPKIsが現在、簡単な階層構造よりむしろ複雑な構造(セクション1.5を見る)を使用しています。 さらに、いくつかの企業は、徐々に多くの信頼アンカーで満たされた信頼リストと、1人の信頼アンカーがいるインフラストラクチャに向かった遠くに移行して、多くの十字で公認された関係です。 このドキュメントは展開している証明経路のための役立つ情報をこれらのより複雑な状況に提供します。
1.2. Purpose
1.2. 目的
This document provides information and guidance for certification path building. There are no requirements or protocol specifications in this document. This document provides many options for performing certification path building, as opposed to just one particular way. This document draws upon the authors' experiences with existing complex certification paths to offer insights and recommendations to developers who are integrating support for [X.509] certificates into their applications.
このドキュメントは証明経路ビルのための情報と指導を提供します。 どんな要件もプロトコル仕様も本書ではありません。 このドキュメントはちょうど1つの特定の方法と対照的に証明経路ビルを実行するための多くのオプションを提供します。 このドキュメントは、[X.509]証明書のサポートを彼らのアプリケーションと統合している開発者に洞察と推薦を提供するのに既存の複雑な証明経路の作者の経験を利用します。
In addition, this document suggests using an effective general approach to path building that involves a depth first tree traversal. While the authors believe this approach offers the balance of simplicity in design with very effective and infrastructure-neutral path-building capabilities, the algorithm is no more than a suggested approach. Other approaches (e.g., breadth first tree traversals) exist and may be shown to be more effective under certain conditions. Certification path validation is described in detail in both [X.509] and [RFC3280] and is not repeated in this document.
さらに、このドキュメントは、深さ第1木の縦断にかかわる経路ビルへの有効な一般的方法を使用するのを示します。 作者は、このアプローチが非常に効果的でインフラストラクチャ中立の経路を造る能力があるデザインにおける、簡単さの残額を提供すると信じていますが、アルゴリズムは提案されたアプローチにすぎません。 他のアプローチ(例えば、幅の第1木の縦断)は、存在していて、一定の条件の下でより効果的になるように示されるかもしれません。 証明経路合法化は、[X.509]と[RFC3280]の両方で詳細に説明されて、本書では繰り返されません。
Cooper, et al. Informational [Page 4] RFC 4158 Certification Path Building September 2005
クーパー、他 [4ページ]情報のRFC4158証明経路ビル2005年9月
This document does not provide guidance for building the certification path from an end entity certificate to a proxy certificate as described in [RFC3820].
このドキュメントは[RFC3820]で説明されるように終わりの実体証明書からプロキシ証明書まで証明経路を造るための指導を提供しません。
1.3. Terminology
1.3. 用語
Terms used throughout this document will be used in the following ways:
このドキュメント中で使用される用語は以下の方法で使用されるでしょう:
Building in the Forward direction: The process of building a
certification path from the target certificate to a trust anchor.
'Forward' is the former name of the crossCertificatePair element
'issuedToThisCA'.
Forward方向のビル: 目標証明書から信頼アンカーまで証明経路を造るプロセス。 '前方'に、crossCertificatePair要素'issuedToThisCA'の旧名があります。
Building in the Reverse direction: The process of building a
certification path from a trust anchor to the target certificate.
'Reverse' is the former name of the crossCertificatePair element
'issuedByThisCA'.
Reverse方向のビル: 信頼アンカーから目標証明書まで証明経路を造るプロセス。 ''crossCertificatePair要素が旧名があり'issuedByThisCAを逆にしてください'。
Certificate: A digital binding that cannot be counterfeited between
a named entity and a public key.
以下を証明してください。 命名された実体と公開鍵の間で偽造できないデジタル結合。
Certificate Graph: A graph that represents the entire PKI (or all
cross-certified PKIs) in which all named entities are viewed as
nodes and all certificates are viewed as arcs between nodes.
グラフを証明してください: 実体というすべてがノードとして見なされる全体のPKI(または、すべての十字で公認されたPKIs)を表すグラフとすべての証明書がノードの間のアークとして見なされます。
Certificate Processing System: An application or device that
performs the functions of certification path building and
certification path validation.
処理システムを証明してください: 証明経路ビルと証明経路合法化の機能を実行するアプリケーションかデバイス。
Certification Authority (CA): An entity that issues and manages
certificates.
認証局(カリフォルニア): 証明書を発行して、管理する実体。
Certification Path: An ordered list of certificates starting with a
certificate signed by a trust anchor and ending with the target
certificate.
証明経路: 証明書から始まる証明書の規則正しいリストは目標証明書がある信頼アンカーと結末で署名しました。
Certification Path Building: The process used to assemble the
certification path between the trust anchor and the target
certificate.
証明経路ビル: プロセスは以前はよく信頼アンカーと目標証明書の間の証明経路を組み立てていました。
Certification Path Validation: The process that verifies the binding
between the subject and the subject-public-key defined in the
target certificate, using a trust anchor and set of known
constraints.
証明経路合法化: 対象と目標証明書で定義された受けることがある公開鍵の間の結合について確かめるプロセス、信頼を使用するのは知られている規制を据えつけて、セットしました。
Cooper, et al. Informational [Page 5] RFC 4158 Certification Path Building September 2005
クーパー、他 [5ページ]情報のRFC4158証明経路ビル2005年9月
Certificate Revocation List (CRL): A signed, time stamped list
identifying a set of certificates that are no longer considered
valid by the certificate issuer.
取消しリスト(CRL)を証明してください: 時間の押し込まれたリストがもう証明書発行人によって有効であることは考えられない1セットの証明書を特定して、Aが署名しました。
CRL Signer Certificate: The specific certificate that may be used for
verifying the signature on a CRL issued by, or on behalf of, a
specific CA.
CRL署名者証明書: カリフォルニアの近く、または、特定のカリフォルニアで発行されたCRLで署名について確かめるのに使用されるかもしれない特定の証明書。
Cross-Certificate: A certificate issued by one CA to another CA for
the purpose of establishing a trust relationship between the two
CAs.
交差している証明書: 2CAsの間の信頼関係を確立する目的のために1カリフォルニアによって別のカリフォルニアに発行された証明書。
Cross-Certification: The act of issuing cross-certificates.
相互認証: 交差している証明書を発行する行為。
Decision Tree: When the path-building software has multiple
certificates to choose from, and must make a decision, the
collection of possible choices is called a decision tree.
意思決定の樹状図: 経路を造るソフトウェアが選ぶ複数の証明書を持って、決定しなければならないと、可能な選択の収集は意思決定の樹状図と呼ばれます。
Directory: Generally used to refer an LDAP accessible repository for
certificates and PKI information. The term may also be used
generically to refer to any certificate storing repository.
ディレクトリ: 一般に、証明書とPKI情報についてLDAPのアクセスしやすい倉庫を参照するのにおいて、使用されています。 また、用語は、倉庫を保存するどんな証明書も参照するのに一般的に使用されるかもしれません。
End Entity: The holder of a private key and corresponding
certificate, whose identity is defined as the Subject of the
certificate. Human end entities are often called "subscribers".
実体を終わらせてください: 秘密鍵と対応する証明書の所有者。そのアイデンティティは証明書のSubjectと定義されます。 人間の終わりの実体はしばしば「加入者」と呼ばれます。
Is-revocation-signer indicator: A boolean flag furnished to the
path-building software. If set, this indicates that the target
certificate is a Revocation Signer certificate for a specific CA.
For example, if building a certification path for an indirect CRL
Signer certificate, this flag would be set.
取消しが署名者であるインディケータ: 論理演算子旗は経路を造るソフトウェアを提供しました。 設定されるなら、これは、目標証明書が特定のカリフォルニアのためのRevocation Signer証明書であることを示します。 例えば、間接的なCRL Signer証明書のために証明経路を造るなら、この旗は設定されるでしょう。
Local PKI: The set of PKI components and data (certificates,
directories, CRLs, etc.) that are created and used by the
certificate using organization. In general, this concept refers
to the components that are in close proximity to the certificate
using application. The assumption is that the local data is more
easily accessible and/or inexpensive to retrieve than non-local
PKI data.
地方のPKI: 組織を使用する証明書によって作成されて、使用されるPKIの部品とデータ(証明書、ディレクトリ、CRLsなど)のセット。 一般に、この概念は極めて接近して証明書にはアプリケーションを使用することであるコンポーネントについて言及します。 仮定はローカルのデータが検索するために非ローカルのPKIデータより容易にアクセスしやすい、そして/または、安価であるということです。
Local Realm: See Local PKI.
地方の分野: 地方のPKIを見てください。
Node (in a certificate graph): The collection of certificates having
identical subject distinguished names.
ノード(証明書グラフによる): 同じ対象の分類名を持っている証明書の収集。
Online Certificate Status Protocol (OCSP): An Internet protocol used
by a client to obtain the revocation status of a certificate from
a server.
オンライン証明書状態プロトコル(OCSP): サーバから証明書の取消し状態を得るのにクライアントによって使用されたインターネットプロトコル。
Cooper, et al. Informational [Page 6] RFC 4158 Certification Path Building September 2005
クーパー、他 [6ページ]情報のRFC4158証明経路ビル2005年9月
OCSP Response Signer Certificate: The specific certificate that may
be used for verifying the signature on an OCSP response. This
response may be provided by the CA, on behalf of the CA, or by a
different signer as determined by the Relying Party's local
policy.
OCSP応答署名者証明書: OCSP応答のときに署名について確かめるのに使用されるかもしれない特定の証明書。 カリフォルニアを代表したカリフォルニアかRelyingパーティのローカルの方針で決定する異なった署名者はこの応答を提供するかもしれません。
Public Key Infrastructure (PKI): The set of hardware, software,
personnel, policy, and procedures used by a CA to issue and manage
certificates.
公開鍵基盤(PKI): 証明書を発行して、管理するのにカリフォルニアによって用いられたハードウェア、ソフトウェア、人員、方針、および手順のセット。
Relying Party (RP): An application or entity that processes
certificates for the purpose of 1) verifying a digital signature,
2) authenticating another entity, or 3) establishing confidential
communications.
当てにしているパーティ(RP): 1の目的のための証明書を処理するアプリケーションか実体) 別の実体を認証する2か)、1か3つのデジタル署名について確かめます) 機密情報を確立します。
Revocation Signer Certificate: Refers collectively to either a CRL
Signer Certificate or OCSP Response Signer Certificate.
取消し署名者証明書: CRL Signer CertificateかOCSP Response Signer Certificateのどちらかについてまとめて言及します。
Target Certificate: The certificate that is to be validated by a
Relying Party. It is the "Certificate targeted for validation".
Although frequently this is the End Entity or a leaf node in the
PKI structure, this could also be a CA certificate if a CA
certificate is being validated. (e.g., This could be for the
purpose of building and validating a certification path for the
signer of a CRL.)
証明書を狙ってください: Relyingパーティによって有効にされることになっている証明書。 それは「合法化のために狙う証明書」です。 頻繁のPKI構造のEnd Entityか葉のノードですが、また、カリフォルニア証明書が有効にされているなら、これはカリフォルニア証明書であるかもしれません。 (例えば、ThisはCRLの署名者のために証明経路を建てて、有効にする目的のためのものであるかもしれません。)
Trust (of public keys): In the scope of this document, a public key
is considered trustworthy if the certificate containing the public
key can be validated according to the procedures in [RFC3280].
信頼(公開鍵の): このドキュメントの範囲では、[RFC3280]の手順によると、公開鍵を含む証明書を有効にすることができるなら、公開鍵が信頼できると考えられます。
Trust List: A list of trust anchors.
信頼は記載します: 信頼のリストは投錨されます。
Trust Anchor: The combination of a trusted public key and the name of
the entity to which the corresponding private key belongs.
信頼は投錨されます: 信じられた公開鍵の組み合わせと対応する秘密鍵が属する実体の名前。
Trust Anchor Certificate: A self-signed certificate for a trust
anchor that is used in certification path processing.
アンカー証明書を信じてください: 証明経路処理に使用される信頼アンカーへの自己署名入りの証書。
User: An individual that is using a certificate processing system.
This document refers to some cases in which users may or may not
be prompted with information or requests, depending upon the
implementation of the certificate processing system.
ユーザ: 証明書処理システムを使用している個人。 このドキュメントはユーザが情報か要求でうながされるかもしれないいくつかの場合について言及します、証明書処理システムの実装によって。
Cooper, et al. Informational [Page 7] RFC 4158 Certification Path Building September 2005
クーパー、他 [7ページ]情報のRFC4158証明経路ビル2005年9月
1.4. Notation
1.4. 記法
This document makes use of a few common notations that are used in the diagrams and examples.
このドキュメントはダイヤグラムと例で使用されるいくつかの一般的な記法を利用します。
The first is the arrow symbol (->) which represents the issuance of a certificate from one entity to another. For example, if entity H were to issue a certificate to entity K, this is denoted as H->K.
1番目は1つの実体から別の実体まで証明書の発行を表す矢のシンボル(->)です。 例えば、実体Hが実体Kに証明書を下付することであったなら、これはH>Kとして指示されます。
Sometimes it is necessary to specify the subject and issuer of a given certificate. If entity H were to issue a certificate to entity K this can be denoted as K(H).
時々、与えられた証明書の対象と発行人を指定するのが必要です。 実体Hが実体Kに証明書を下付することであったなら、K(H)としてこれを指示できます。
These notations can be combined to denote complicated certification paths such as C(D)->B(C)->A(B).
C(D)->などの複雑な証明経路を指示するためにこれらの記法を結合できる、B(C)、-、>A(B)。
1.5. Overview of PKI Structures
1.5. PKI構造の概要
When verifying [X.509] public key certificates, often the application performing the verification has no knowledge of the underlying Public Key Infrastructure (PKI) that issued the certificate. PKI structures can range from very simple, hierarchical structures to complex structures such as mesh architectures involving multiple bridges (see Section 1.5.4). These structures define the types of certification paths that might be built and validated by an application [MINHPKIS]. This section describes four common PKI structures.
[X.509]公開鍵証明書について確かめるとき、しばしば、検証を実行するアプリケーションは証明書を発行した基本的な公開鍵暗号基盤(PKI)に関する知識を全く持っているというわけではありません。 PKI構造は非常に簡単で、階層的な構造から複数のブリッジにかかわるメッシュアーキテクチャなどの複雑な構造に変化できます(セクション1.5.4を見てください)。 これらの構造はアプリケーション[MINHPKIS]で、建てられて、有効にされるかもしれない証明経路のタイプを定義します。 このセクションは4つの一般的なPKI構造について説明します。
1.5.1. Hierarchical Structures
1.5.1. 階層構造
A hierarchical PKI, depicted in Figure 1, is one in which all of the end entities and relying parties use a single "Root CA" as their trust anchor. If the hierarchy has multiple levels, the Root CA certifies the public keys of intermediate CAs (also known as subordinate CAs). These CAs then certify end entities' (subscribers') public keys or may, in a large PKI, certify other CAs. In this architecture, certificates are issued in only one direction, and a CA never certifies another CA "superior" to itself. Typically, only one superior CA certifies each CA.
図1に表現された階層的なPKIは彼らの信頼が投錨されるとき終わりの実体と信用パーティーが皆、単一の「Rootカリフォルニア」を使用するものです。 階層構造に複数のレベルがあるなら、Rootカリフォルニアは、中間的CAsの公開鍵が(また、下位のCAsとして、知られています。)であると公認します。 大きいPKIでは、これらのCAsは次に、終わりの実体の(加入者)の公開鍵を公認するか、または他のCAsを公認するかもしれません。 このアーキテクチャでは、一方向だけに証明書を発行します、そして、カリフォルニアは別のカリフォルニアがそれ自体より「優れていること」を決して公認しません。 1人の上司だけのカリフォルニアは各カリフォルニアを公認します。
Cooper, et al. Informational [Page 8] RFC 4158 Certification Path Building September 2005
クーパー、他 [8ページ]情報のRFC4158証明経路ビル2005年9月
+---------+
+---| Root CA |---+
| +---------+ |
| |
| |
v v
+----+ +----+
+-----| CA | +-----| CA |------+
| +----+ | +----+ |
| | |
v v v
+----+ +----+ +----+
+--| CA |-----+ | CA |-+ +---| CA |---+
| +----+ | +----+ | | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+---------+ +---| カリフォルニアを根づかせてください。|---+ | +---------+ | | | | | v対+----+ +----+ +-----| カリフォルニア| +-----| カリフォルニア|------+ | +----+ | +----+ | | | | v対+に----+ +----+ +----+ +--| カリフォルニア|-----+ | カリフォルニア|-+ +---| カリフォルニア|---+ | +----+ | +----+ | | +----+ | | | | | | | | | | | | | | | | | v v v v v v対+に----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 1 - Sample Hierarchical PKI
図1--サンプルの階層的なPKI
Certification path building in a hierarchical PKI is a straightforward process that simply requires the relying party to successively retrieve issuer certificates until a certificate that was issued by the trust anchor (the "Root CA" in Figure 1) is located.
階層的なPKIの証明経路ビルは信頼アンカー(図1の「Rootカリフォルニア」)によって発行された証明書が見つけられるまで信用パーティーが相次ぐ発行人証明書を検索するのを単に必要とする簡単なプロセスです。
A widely used variation on the single-rooted hierarchical PKI is the inclusion of multiple CAs as trust anchors. (See Figure 2.) Here, end entity certificates are validated using the same approach as with any hierarchical PKI. The difference is that a certificate will be accepted if it can be verified back to any of the set of trust anchors. Popular web browsers use this approach, and are shipped with trust lists containing dozens to more than one hundred CAs. While this approach simplifies the implementation of a limited form of certificate verification, it also may introduce certain security vulnerabilities. For example, the user may have little or no idea of the policies or operating practices of the various trust anchors, and may not be aware of which root was used to verify a given certificate. Additionally, the compromise of any trusted CA private key or the insertion of a rogue CA certificate to the trust list may compromise the entire system. Conversely, if the trust list is properly managed and kept to a reasonable size, it can be an efficient solution to building and validating certification paths.
信頼が投錨されるとき、単一に根づいている階層的なPKIの広く使用された変化は複数のCAsの包含です。 (図2を参照してください。) ここで、終わりの実体証明書は、どんな階層的なPKIのようにも同じアプローチを使用することで有効にされます。 違いは信頼アンカーのセットのどれかにそれについて確かめて戻すことができると証明書を受け入れるということです。 ポピュラーなウェブブラウザをこのアプローチを使用して、信頼リストが100CAsに数十を含んでいて、出荷します。 また、このアプローチが限局型の証明書検証の実装を簡素化している間、それはあるセキュリティの脆弱性を導入するかもしれません。 例えば、ユーザは、まず、方針か様々な信頼アンカーの習慣を操作するという考えを持っていないかもしれなくて、またどの根が与えられた証明書について確かめるのに使用されたかを意識していないかもしれません。 さらに、どんな信じられたカリフォルニア秘密鍵の感染か信頼リストへの凶暴なカリフォルニア証明書の挿入も全体のシステムに感染するかもしれません。 逆に、信頼リストが妥当なサイズに適切に管理されて、保たれるなら、それは証明経路を建てて、有効にすることへの効率的なソリューションであるかもしれません。
Cooper, et al. Informational [Page 9] RFC 4158 Certification Path Building September 2005
クーパー、他 [9ページ]情報のRFC4158証明経路ビル2005年9月
+-------------------------------------------------------+
| Trust List |
| |
| +---------+ +---------+ +---------+ |
| +--| Root CA | | Root CA | | Root CA | |
| | +---------+ +---------+ +---------+ |
| | | | | |
+--|------|----------------|---------------- |----------+
| | | |
| | | |
| | v |
| | +----+ |
| | +----| CA |---+ |
| | | +----+ | |
| | | | |
| | v v v
| | +----+ +----+ +----+
| | | CA |---+ | CA |-+ | CA |---+
| | +----+ | +----+ | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+-------------------------------------------------------+ | 信用リスト| | | | +---------+ +---------+ +---------+ | | +--| カリフォルニアを根づかせてください。| | カリフォルニアを根づかせてください。| | カリフォルニアを根づかせてください。| | | | +---------+ +---------+ +---------+ | | | | | | | +--|------|----------------|---------------- |----------+ | | | | | | | | | | v| | | +----+ | | | +----| カリフォルニア|---+ | | | | +----+ | | | | | | | | | v vに対して| | +----+ +----+ +----+ | | | カリフォルニア|---+ | カリフォルニア|-+ | カリフォルニア|---+ | | +----+ | +----+ | +----+ | | | | | | | | | | | | | | | | | v v v v v v対+に----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 2 - Multi-Rooted Hierarchical PKI
図2--マルチ根づいている階層的なPKI
1.5.2. Mesh Structures
1.5.2. メッシュ構造
In a typical mesh style PKI (depicted in Figure 3), each end entity trusts the CA that issued their own certificate(s). Thus, there is no 'Root CA' for the entire PKI. The CAs in this environment have peer relationships; they are neither superior nor subordinate to one another. In a mesh, CAs in the PKI cross-certify. That is, each CA issues a certificate to, and is issued a certificate by, peer CAs in the PKI. The figure depicts a mesh PKI that is fully cross-certified (sometimes called a full mesh). However, it is possible to architect and deploy a mesh PKI with a mixture of uni-directional and bi- directional cross-certifications (called a partial mesh). Partial meshes may also include CAs that are not cross-certified with other CAs in the mesh.
典型的なメッシュスタイルPKI(図3では、表現される)、各端の実体受託カリフォルニアでは、それがそれら自身の証明書を発行しました。 したがって、全体のPKIのための'Rootカリフォルニア'が全くありません。 この環境におけるCAsには、同輩関係があります。 それらは、お互いに優れていなくてまた下位ではありません。 メッシュ、中のPKIが十字で公認するCAsで。 すなわち、カリフォルニアに証明書を下付して、証明書が発行されるそれぞれがじっと見ます。PKIのCAs。 図は十字によって完全に公認された(時々完全なメッシュと呼ばれた)メッシュPKIについて表現します。 しかしながら、建築家にとって、それは可能です、そして、uni方向上の、そして、両性愛者の方向の相互認証(部分的なメッシュと呼ばれる)の混合物でメッシュPKIを配備してください。 また、部分的なメッシュはメッシュの他のCAsと共に十字によって公認されなかったCAsを含むかもしれません。
Cooper, et al. Informational [Page 10] RFC 4158 Certification Path Building September 2005
クーパー、他 [10ページ]情報のRFC4158証明経路ビル2005年9月
+---------------------------------+
| |
+-----------+----------------------+ |
| v v |
| +-------+ +------+ |
| +--->| CA B |<------------->| CA C |<--+ |
| | +-------+ +------+ | |
| | | ^ ^ | | |
| | v | | | | |
| | +----+ | | | | |
| | | EE | +----+ +--------+ v | |
| | +----+ | | +----+ | |
| | | | | EE | | |
v v v v +----+ v v
+------+ +------+ +------+
| CA E |<----------->| CA A |<----------->| CA D |
+------+ +------+ +------+
| ^ ^ ^ ^ |
| | | | | |
v | +------------------------------------+ | v
+----+ | | +----+
| EE | | +------+ | | EE |
+----+ +----------------| CA F |-----------------+ +----+
+------+
+---------------------------------+ | | +-----------+----------------------+ | | vに対して| | +-------+ +------+ | | +--->| カリフォルニアB| <、-、-、-、-、-、-、-、-、-、-、-、--、>| カリフォルニアC| <--+ | | | +-------+ +------+ | | | | | ^ ^ | | | | | v| | | | | | | +----+ | | | | | | | | EE| +----+ +--------+ v| | | | +----+ | | +----+ | | | | | | | EE| | | v v対+に----+ v対+------+ +------+ +------+ | カリフォルニアE| <、-、-、-、-、-、-、-、-、-、--、>| カリフォルニアA| <、-、-、-、-、-、-、-、-、-、--、>| カリフォルニアD| +------+ +------+ +------+ | ^ ^ ^ ^ | | | | | | | v| +------------------------------------+ | +に対して----+ | | +----+ | EE| | +------+ | | EE| +----+ +----------------| カリフォルニアF|-----------------+ +----+ +------+
Figure 3 - Mesh PKI
図3--メッシュPKI
Certification path building in a mesh PKI is more complex than in a hierarchical PKI due to the likely existence of multiple paths between a relying party's trust anchor and the certificate to be verified. These multiple paths increase the potential for creating "loops", "dead ends", or invalid paths while building the certification path between a trust anchor and a target certificate. In addition, in cases where no valid path exists, the total number of paths traversed by the path-building software in order to conclude "no path exists" can grow exceedingly large. For example, if ignoring everything except the structure of the graph, the Mesh PKI figure above has 22 non-self issued CA certificates and a total of 5,092,429 certification paths between CA F and the EE issued by CA D without repeating any certificates.
メッシュPKIの証明経路ビルは信用パーティーの信用アンカーと確かめられるべき証明書の間の複数の経路のありそうな存在のために階層的なPKIより複雑です。 これらの複数の経路が信用アンカーと目標証明書の間の証明経路を造っている間、「輪」、「行き止まり」、または無効の経路を作成する可能性を増加させます。 さらに、どんな有効な経路も存在しない場合では、「経路は全く存在していません」と結論づけるために経路を造るソフトウェアによって横断された経路の総数はきわめて大きくなることができます。 例えば、グラフの構造以外のすべてを無視するなら、上のMesh PKI数値で、どんな証明書も繰り返さないでカリフォルニアDによって発行されたカリフォルニアFとEEの間でカリフォルニア証明書と合計509万2429の証明経路を22非自己に発行します。
1.5.3. Bi-Lateral Cross-Certified Structures
1.5.3. 双方の十字で公認された構造
PKIs can be connected via cross-certification to enable the relying parties of each to verify and accept certificates issued by the other PKI. If the PKIs are hierarchical, cross-certification will typically be accomplished by each Root CA issuing a certificate for the other PKI's Root CA. This results in a slightly more complex,
それぞれの信用パーティーがもう片方のPKIによって発行された証明書について確かめて、受け入れるのを可能にするために相互認証でPKIsを接続できます。 PKIsが階層的であるなら、相互認証はもう片方のPKIのRootカリフォルニアに証明書を下付するそれぞれのRootカリフォルニアによって通常実行されるでしょう。 これはわずかに複雑な状態でaをもたらします。
Cooper, et al. Informational [Page 11] RFC 4158 Certification Path Building September 2005
クーパー、他 [11ページ]情報のRFC4158証明経路ビル2005年9月
but still essentially hierarchical environment. If the PKIs are mesh style, then a CA within each PKI is selected, more or less arbitrarily, to establish the cross-certification, effectively creating a larger mesh PKI. Figure 4 depicts a hybrid situation resulting from a hierarchical PKI cross-certifying with a mesh PKI.
しかし、まだ本質的には階層的な環境。 PKIsがメッシュスタイルであるなら、各PKIの中のカリフォルニアが相互認証を確立するのが多少任意に選択されます、事実上、より大きいメッシュPKIを作成して。 図4はメッシュでPKIを十字で公認する階層的なPKIから生じるハイブリッド状況について叙述します。
PKI 1 and 2 cross-certificates
+-------------------------------+
| |
| v
| +---------+
| +----| Root CA |---+
| | +---------+ |
| | PKI 1 |
| v v
| +------+ +------+
v PKI 2 +-| CA |-+ | CA |
+------+ | +------+ | +------+
+------->| CA |<-----+ | | | | |
| +------+ | | | | | |
| | | | v v v v v
| | | | +----+ +----+ +----+ +----+ +----+
| v v | | EE | | EE | | EE | | EE | | EE |
| +----+ +----+ | +----+ +----+ +----+ +----+ +----+
| | EE | | EE | |
| +----+ +----+ |
v v
+------+ +------+
| CA |<-------------->| CA |------+
+------+ +------+ |
| | | | |
| | | | |
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
PKI1と2交差している証明書+-------------------------------+ | | | v| +---------+ | +----| カリフォルニアを根づかせてください。|---+ | | +---------+ | | | PKI1| | vに対して| +------+ +------+ PKI2+に対して| カリフォルニア|-+ | カリフォルニア| +------+ | +------+ | +------+ +------->| カリフォルニア| <、-、-、-、--+ | | | | | | +------+ | | | | | | | | | | v対v vに| | | | +----+ +----+ +----+ +----+ +----+ | vに対して| | EE| | EE| | EE| | EE| | EE| | +----+ +----+ | +----+ +----+ +----+ +----+ +----+ | | EE| | EE| | | +----+ +----+ | v対+------+ +------+ | カリフォルニア| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| カリフォルニア|------+ +------+ +------+ | | | | | | | | | | | v v v対+に----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+
Figure 4 - Hybrid PKI
図4--ハイブリッドPKI
In current implementations, this situation creates a concern that the applications used under the hierarchical PKIs will not have path building capabilities robust enough to handle this more complex certificate graph. As the number of cross-certified PKIs grows, the number of the relationships between them grows exponentially. Two principal concerns about cross-certification are the creation of unintended certification paths through transitive trust, and the dilution of assurance when a high-assurance PKI with restrictive operating policies is cross-certified with a PKI with less
現在の実現では、この状況は階層的なPKIsの下で使用されるアプリケーションで経路ビル能力がこのより複雑な証明書グラフを扱うほど強健にならないという関心を引き起こします。 十字で公認されたPKIsの数が成長するのに従って、それらの間の関係の数は指数関数的に成長します。 相互認証に関する2回の主たる関心事は、他動な信用による故意でない証明経路の創造と、制限している運営方針がある高保証PKIが以下があるPKIと共に十字によって公認されているときの保証の希釈です。
Cooper, et al. Informational [Page 12] RFC 4158 Certification Path Building September 2005
クーパー、他 [12ページ]情報のRFC4158証明経路ビル2005年9月
restrictive policies. (Proper name constraints and certificate policies processing can help mitigate the problem of assurance dilution.)
引締政策。 (正式名称規制と証明書方針処理は、保証希釈の問題を緩和するのを助けることができます。)
1.5.4. Bridge Structures
1.5.4. 橋かけ構造
Another approach to the interconnection of PKIs is the use of a "bridge" certification authority (BCA). A BCA is a nexus to establish trust paths among multiple PKIs. The BCA cross-certifies with one CA in each participating PKI. Each PKI only cross-certifies with one other CA (i.e., the BCA), and the BCA cross-certifies only once with each participating PKI. As a result, the number of cross certified relationships in the bridged environment grows linearly with the number of PKIs whereas the number of cross-certified relationships in mesh architectures grows exponentially. However, when connecting PKIs in this way, the number and variety of PKIs involved results in a non-hierarchical environment, such as the one as depicted in Figure 5. (Note: as discussed in Section 2.3, non- hierarchical PKIs can be considered hierarchical, depending upon perspective.)
PKIsのインタコネクトへの別のアプローチは「橋」証明権威(BCA)の使用です。 BCAは複数のPKIsの中で信用経路を確立する結びつきです。 BCAは1でそれぞれ参加しているPKIのカリフォルニアを十字で公認します。 PKIが他の1カリフォルニア(すなわち、BCA)と共に十字で公認するだけであり、BCAがそれぞれ参加しているPKIと共に一度だけ十字で公認するそれぞれ。 その結果、橋を架けられた環境における、交差している公認された関係の数はPKIsの数で直線的になりますが、メッシュ構造の十字で公認された関係の数は指数関数的に成長します。 しかしながら、このようにPKIsを接続するとき、PKIsの数とバラエティーは非階層的な環境に結果にかかわりました、図5に表現されるものなどのように。 (セクション2.3で議論するように以下に注意してください、そして、見解によって、階層的であると非階層的なPKIsを考えることができます。)
Cooper, et al. Informational [Page 13] RFC 4158 Certification Path Building September 2005
クーパー、他 [13ページ]情報のRFC4158証明経路ビル2005年9月
PKI 1 cross-certified with Bridge
+-------------------------------+
| |
v v
+-----------+ +---------+
| Bridge CA | +---| Root CA |-----+
+-----------+ | +---------+ |
^ | PKI 1 |
PKI 2 cross|cert with Bridge v v
| +------+ +------+
v PKI 2 +-| CA |-+ | CA |
+------+ | +------+ | +------+
+------->| CA |<-----+ | | | | |
| +------+ | | | | | |
| | | | v v v v v
| | | | +----+ +----+ +----+ +----+ +----+
| v v | | EE | | EE | | EE | | EE | | EE |
| +----+ +----+ | +----+ +----+ +----+ +----+ +----+
| | EE | | EE | |
| +----+ +----+ |
v v
+------+ +------+
| CA |<-------------->| CA |------+
+------+ +------+ |
| | | | |
| | | | |
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
PKI1はBridgeと共に+を十字で公認しました。-------------------------------+ | | v対+-----------+ +---------+ | カリフォルニアに橋を架けてください。| +---| カリフォルニアを根づかせてください。|-----+ +-----------+ | +---------+ | ^ | PKI1| PKI2は交差しています。|Bridgeをもっている本命対v| +------+ +------+ PKI2+に対して| カリフォルニア|-+ | カリフォルニア| +------+ | +------+ | +------+ +------->| カリフォルニア| <、-、-、-、--+ | | | | | | +------+ | | | | | | | | | | v対v vに| | | | +----+ +----+ +----+ +----+ +----+ | vに対して| | EE| | EE| | EE| | EE| | EE| | +----+ +----+ | +----+ +----+ +----+ +----+ +----+ | | EE| | EE| | | +----+ +----+ | v対+------+ +------+ | カリフォルニア| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| カリフォルニア|------+ +------+ +------+ | | | | | | | | | | | v v v対+に----+ +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+ +----+
Figure 5 - Cross-Certification with a Bridge CA
図5--カリフォルニア橋との相互認証
1.6. Bridge Structures and Certification Path Processing
1.6. 橋かけ構造と証明経路処理
Developers building certificate-enabled applications intended for widespread use throughout various sectors are encouraged to consider supporting a Bridge PKI structure because implementation of certification path processing functions to support a Bridge PKI structure requires support of all the PKI structures (e.g., hierarchical, mesh, hybrid) which the Bridge may connect. An application that can successfully build valid certification paths in all Bridge PKIs will therefore have implemented all of the processing logic required to support the less complicated PKI structures. Thus, if an application fully supports the Bridge PKI structure, it can be deployed in any standards-compliant PKI environment and will perform the required certification path processing properly.
普及使用のためにさまざまな分野中で意図する証明書で可能にされたアプリケーションを組立てる開発者が、Bridge PKI構造を支える証明経路処理機能の実現がBridgeが接続するかもしれないすべてのPKI構造(階層的です、かみ合ってください、例えば、ハイブリッドです、)のサポートを必要とするのでBridge PKI構造を支えると考えるよう奨励されます。 したがって、首尾よくすべてのBridge PKIsの有効な証明経路を造ることができるアプリケーションは論理がそれほど複雑でないPKI構造を支えるのを必要とした処理のすべてを実行してしまうでしょう。 したがって、アプリケーションがBridge PKI構造を完全に支えると、それは、どんな規格対応することのPKI環境でも配備できて、適切に必要な証明経路処理を実行するでしょう。
Cooper, et al. Informational [Page 14] RFC 4158 Certification Path Building September 2005
クーパー、他 [14ページ]情報のRFC4158証明経路ビル2005年9月
2. Certification Path Building
2. 証明経路ビル
Certification path building is the process by which the certificate processing system obtains the certification path between a trust anchor and the target certificate. Different implementations can build the certification path in different ways; therefore, it is not the intent of this document to recommend a single "best" way to perform this function. Rather, guidance is provided on the technical issues that surround the path-building process, and on the capabilities path-building implementations need in order to build certification paths successfully, irrespective of PKI structures.
証明経路ビルは証明書処理システムが信用アンカーと目標証明書の間の証明経路を得る過程です。 異なった実現は異なった方法で証明経路を造ることができます。 したがって、この機能を実行するただ一つの「最も良い」方法を推薦するのは、このドキュメントの意図ではありません。 むしろ、経路建築の過程を囲む専門的な問題の上と、そして、経路を造る実現が首尾よく証明経路を造るために必要とする能力の上で指導を提供します、PKI構造の如何にかかわらず。
2.1. Introduction to Certification Path Building
2.1. 証明経路ビルへの序論
A certification path is an ordered list of certificates starting with a certificate that can be validated by one of the relying party's trust anchors, and ending with the certificate to be validated. (The certificate to be validated is referred to as the "target certificate" throughout this document.) Though not required, as a matter of convenience these trust anchors are typically stored in trust anchor certificates. The intermediate certificates that comprise the certification path may be retrieved by any means available to the validating application. These sources may include LDAP, HTTP, SQL, a local cache or certificate store, or as part of the security protocol itself as is common practice with signed S/MIME messages and SSL/TLS sessions.
証明経路はパーティーの信用が据えつける信用のものと、有効にされるために証明書で終わることによって有効にすることができる証明書から始まる証明書の規則正しいリストです。 (有効にされるべき証明書はこのドキュメント中に「目標証明書」と呼ばれます。) 必要ではありませんが、都合上これらの信用アンカーは信用アンカー証明書に通常格納されます。 証明経路を包括する中間的証明書は有効にするアプリケーションになんとか利用可能な状態で検索されるかもしれません。 これらのソースがLDAPを入れるかもしれなくて、HTTP、SQL、ローカルなキャッシュまたは証明書自体が、メッセージとSSL/TLSセッションについて格納するか、またはセキュリティの一部一般的な習慣のようにサインされたS/MIMEで議定書の中で述べます。
Figure 6 shows an example of a certification path. In this figure, the horizontal arrows represent certificates, and the notation B(A) signifies a certificate issued to B, signed by A.
図6は証明経路に関する例を示しています。 この図では、水平な矢は証明書を表します、そして、記法B(A)はAによってサインされたBに発行された証明書を意味します。
+---------+ +-----+ +-----+ +-----+ +--------+
| Trust |----->| CA |---->| CA |---->| CA |---->| Target |
| Anchor | : | A | : | B | : | C | : | EE |
+---------+ : +-----+ : +-----+ : +-----+ : +--------+
: : : :
: : : :
Cert 1 Cert 2 Cert 3 Cert 4
A(Trust Anchor) B(A) C(B) Target(C)
+---------+ +-----+ +-----+ +-----+ +--------+ | 信用|、-、-、-、--、>| カリフォルニア|、-、-、--、>| カリフォルニア|、-、-、--、>| カリフォルニア|、-、-、--、>| 目標| | アンカー| : | A| : | B| : | C| : | EE| +---------+ : +-----+ : +-----+ : +-----+ : +--------+ : : : : : : : : (信用アンカー)B(A)C(B)あたり4が狙う1人の本命本命2本命3本命(C)
Figure 6 - Example Certification Path
図6--例の証明経路
Unlike certification path validation, certification path building is not addressed by the standards that define the semantics and structure of a PKI. This is because the validation of a certification path is unaffected by the method in which the certification path was built. However, the ability to build a valid certification path is of paramount importance for applications that
証明経路合法化と異なって、証明経路ビルはPKIの意味論と構造を定義する規格によって記述されません。 これは証明経路の合法化が証明経路が造られた方法で影響を受けないからです。 しかしながら、有効な証明経路を造る能力がアプリケーションのために最高のに重要である、それ
Cooper, et al. Informational [Page 15] RFC 4158 Certification Path Building September 2005
クーパー、他 [15ページ]情報のRFC4158証明経路ビル2005年9月
rely on a PKI. Without valid certification paths, certificates cannot be validated according to [RFC3280] and therefore cannot be trusted. Thus, the ability to build a path is every bit as important as the ability to validate it properly.
PKIを当てにしてください。 有効な証明経路がなければ、証明書を[RFC3280]に従って有効にすることができないで、したがって、信じることができません。 したがって、経路を造る能力は適切にそれを有効にする能力とちょうど同じくらい重要です。
There are many issues that can complicate the path-building process. For example, building a path through a cross-certified environment could require the path-building module to traverse multiple PKI domains spanning multiple directories, using multiple algorithms, and employing varying key lengths. A path-building client may also need to manage a number of trust anchors, partially populated directory entries (e.g., missing issuedToThisCA entries in the crossCertificatePair attribute), parsing of certain certificate extensions (e.g., authorityInformationAccess) and directory attributes (e.g., crossCertificatePair), and error handling such as loop detection.
経路建築の過程を複雑にすることができる多くの問題があります。 例えば、十字で公認された環境を通して経路を造るのは複数のディレクトリにかかる複数のPKIドメインを横断するために経路を造るモジュールを必要とするかもしれません、複数のアルゴリズムを使用して、異なったキー長を使って。 また、経路を造るクライアントは、多くの信用アンカー、部分的に居住されたディレクトリエントリー(例えば、crossCertificatePair属性におけるなくなったissuedToThisCAエントリー)、ある証明書拡張子(例えば、authorityInformationAccess)とディレクトリ属性(例えば、crossCertificatePair)の構文解析、および輪の検出などのエラー処理を管理する必要があるかもしれません。
In addition, a developer has to decide whether to build paths from a trust anchor (the reverse direction) to the target certificate or from the target certificate (the forward direction) to a trust anchor. Some implementations may even decide to use both. The choice a developer makes should be dependent on the environment and the underlying PKI for that environment. More information on making this choice can be found in Section 2.3.
さらに、開発者は、信用アンカー(反対の方向)から目標証明書まで目標証明書(順方向)から信用アンカーまで経路を造るかどうか決めなければなりません。 いくつかの実現が、両方を使用すると決めさえするかもしれません。 その環境において、開発者がする選択は環境と基本的なPKIに依存しているべきです。 セクション2.3でこの選択をする詳しい情報を見つけることができます。
2.2. Criteria for Path Building
2.2. 経路ビルの評価基準
From this point forward, this document will be discussing specific algorithms and mechanisms to assist developers of certification path-building implementations. To provide justification for these mechanisms, it is important to denote what the authors considered the criteria for a path-building implementation.
このポイントフォワードから、このドキュメントは、経路を造る証明実現の開発者を補助するために特定のアルゴリズムとメカニズムについて議論するでしょう。 これらのメカニズムのための正当化を提供するために、作者が経路を造る実現の評価基準であると考えたことを指示するのは重要です。
Criterion 1: The implementation is able to find all possible paths, excepting paths containing repeated subject name/public key pairs. This means that all potentially valid certification paths between the trust anchor and the target certificate which may be valid paths can be built by the algorithm. As discussed in Section 2.4.2, we recommend that subject names and public key pairs are not repeated in paths.
評価基準1: 繰り返された対象の名前/公開鍵組を含む経路を除いて、実現はすべての可能な経路を見つけることができます。 これは、アルゴリズムで有効な経路であるかもしれない信用アンカーと目標証明書の間のすべての潜在的に有効な証明経路を造ることができることを意味します。 セクション2.4.2で議論するように、私たちは、対象の名前と公開鍵組が経路で繰り返されないことを勧めます。
Criterion 2: The implementation is as efficient as possible. An efficient certification path-building implementation is defined to be one that builds paths that are more likely to validate following [RFC3280], before building paths that are not likely to validate, with the understanding that there is no way to account for all possible configurations and infrastructures. This criterion is intended to ensure implementations that can produce useful error
評価基準2: 実現はできるだけ効率的です。 経路を造る効率的な証明実現は、すべての可能な構成とインフラストラクチャを説明するある理解でいいえを有効にしそうにない経路を造る前に、次の[RFC3280]方法をより有効にしそうな経路を造るものになるように定義されます。 この評価基準が役に立つ誤りを起こすことができる実現を確実にすることを意図します。
Cooper, et al. Informational [Page 16] RFC 4158 Certification Path Building September 2005
クーパー、他 [16ページ]情報のRFC4158証明経路ビル2005年9月
information. If a particular path is entirely valid except for a single expired certificate, this is most likely the 'right' path. If other paths are developed that are invalid for multiple obscure reasons, this provides little useful information.
情報。 ただ一つの満期の証明書を除いて、特定の経路が完全に有効であるなら、これはたぶん'正しい'経路です。 開発された他の倍数に、無効の経路が理由をあいまいにするなら、これはほとんど役に立つ情報を提供しません。
The algorithms and mechanisms discussed henceforth are chosen because the authors consider them to be good methods for meeting the above criteria.
作者が、彼らが上の評価基準を満たすための良い方法であると考えるので、今後は議論したアルゴリズムとメカニズムは選ばれています。
2.3. Path-Building Algorithms
2.3. 経路を造るアルゴリズム
It is intuitive for people familiar with the Bridge CA concept or mesh type PKIs to view path building as traversing a complex graph. However, from the simplest viewpoint, writing a path-building module can be nothing more than traversal of a spanning tree, even in a very complex cross-certified environment. Complex environments as well as hierarchical PKIs can be represented as trees because certificates are not permitted to repeat in a path. If certificates could be repeated, loops can be formed such that the number of paths and number of certificates in a path both increase without bound (e.g., A issues to B, B issues to C, and C issues to A). Figure 7 below illustrates this concept from the trust anchor's perspective.
Bridgeカリフォルニア概念かメッシュタイプPKIsに詳しい人々にとって、それは複雑なグラフを横断するとして視点経路ビルに直感的です。 しかしながら、最も簡単な観点から経路を造るモジュールを書くのは、ただスパニングツリーの縦断であるかもしれません、非常に複雑な十字で公認された環境でさえ。 証明書が経路で繰り返すことが許可されていないので、木として階層的なPKIsと同様に複雑な環境を表すことができます。 証明書を繰り返すことができるなら、経路の数と経路の証明書の数がバウンド(例えば、BへのA問題、CへのB問題、およびAへのC問題)なしでともに増加するように、輪を形成できます。 図7 以下では、信用アンカーの見解からのこの概念が例証します。
Cooper, et al. Informational [Page 17] RFC 4158 Certification Path Building September 2005
クーパー、他 [17ページ]情報のRFC4158証明経路ビル2005年9月
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
| | | |
v v v v
+---+ +---+ +---+ +---+
| A |<-->| C | +--| A | | C |--+
+---+ +---+ | +---+ +---+ |
| | | | | |
| +---+ | v v v v
+->| B |<-+ +---+ +---+ +---+ +---+
+---+ | B | | C | | A | | B |
| +---+ +---+ +---+ +---+
v | | | |
+----+ v v v v
| EE | +----+ +---+ +---+ +----+
+----+ | EE | | B | | B | | EE |
+----+ +---+ +---+ +----+
A certificate graph with | |
bi-directional cross-cert. v v
between CAs A and C. +----+ +----+
| EE | | EE |
+----+ +----+
+---------+ +---------+ | 信用| | 信用| | アンカー| | アンカー| +---------+ +---------+ | | | | v v対+に---+ +---+ +---+ +---+ | A| <-->、| C| +--| A| | C|--+ +---+ +---+ | +---+ +---+ | | | | | | | | +---+ | v対v+に>| B| <、-+ +---+ +---+ +---+ +---+ +---+ | B| | C| | A| | B| | +---+ +---+ +---+ +---+ v| | | | +----+ v対vに| EE| +----+ +---+ +---+ +----+ +----+ | EE| | B| | B| | EE| +----+ +---+ +---+ +----証明書がグラフ化する+| | 双方向の交差している本命C. CAs Aと+の間のvに対して----+ +----+ | EE| | EE| +----+ +----+
The same certificate graph
rendered as a tree - the
way path-building software
could see it.
木として表された同じ証明書グラフ--経路を造るソフトウェアがそれを見るかもしれない方法。
Figure 7 - Simple Certificate Graph - From Anchor Tree Depiction
アンカー木の描写からの図7(簡単な証明書グラフ)
When viewed from this perspective, all PKIs look like hierarchies emanating from the trust anchor. An infrastructure can be depicted in this way regardless of its complexity. In Figure 8, the same graph is depicted from the end entity (EE) (the target certificate in this example). It would appear this way if building in the forward (from EE or from target) direction. In this example, without knowing any particulars of the certificates, it appears at first that building from EE has a smaller decision tree than building from the trust anchor. While it is true that there are fewer nodes in the tree, it is not necessarily more efficient in this example.
この見解から見られると、すべてのPKIsが信用アンカーから発する階層構造に似ています。 複雑さにかかわらずこのようにインフラストラクチャについて表現できます。 図8では、同じグラフは終わりの実体(EE)(この例の目標証明書)から表現されます。 前進(EEか目標からの)の方向に建てるなら、それはこの道に現れるでしょう。 この例では、証明書のどんな子細も知らないで、初めに、EEから建てるのにおいて信用アンカーから建てるより小さい意思決定の樹状図があるように見えます。 より少ないノードが木にあるのが、本当ですが、この例では、それは必ずより効率的であるというわけではありません。
Cooper, et al. Informational [Page 18] RFC 4158 Certification Path Building September 2005
クーパー、他 [18ページ]情報のRFC4158証明経路ビル2005年9月
+---------+ +---------+
| Trust | | Trust |
| Anchor | | Anchor |
+---------+ +---------+
^ ^
| |
| |
+---+ +---+
| A | | C |
+---+ +---+
+---------+ ^ ^ +---------+
| Trust | | | | Trust |
| Anchor | | | | Anchor |
+---------+ | | +---------+
^ | | ^
| +---+ +---+ |
+-------| C | | A |---------+
+---+ +---+
^ ^
| |
| +---+ |
+---------| B |------+
+---+
^
|
|
+----+
| EE |
+----+
+---------+ +---------+ | 信用| | 信用| | アンカー| | アンカー| +---------+ +---------+ ^ ^ | | | | +---+ +---+ | A| | C| +---+ +---+ +---------+ ^ ^ +---------+ | 信用| | | | 信用| | アンカー| | | | アンカー| +---------+ | | +---------+ ^ | | ^ | +---+ +---+ | +-------| C| | A|---------+ +---+ +---+ ^ ^ | | | +---+ | +---------| B|------+ +---+ ^ | | +----+ | EE| +----+
The same certificate graph rendered
as a tree but from the end entity
rather than the trust anchor.
木にもかかわらず、信用よりむしろ終わりの実体から投錨するとき表された同じ証明書グラフ。
Figure 8 - Certificate Graph - From Target Certificate Depiction
エイト環--目標証明書描写からの証明書グラフ
Suppose a path-building algorithm performed no optimizations. That is, the algorithm is only capable of detecting that the current certificate in the tree was issued by the trust anchor, or that it issued the target certificate (EE). From the tree above, building from the target certificate will require going through two intermediate certificates before encountering a certificate issued by the trust anchor 100% of the time (e.g., EE chains to B, which then chains to C, which is issued by the Trust Anchor). The path-building module would not chain C to A because it can recognize that C has a certificate issued by the Trust Anchor (TA).
経路を造るアルゴリズムが最適化を全く実行しなかったと仮定してください。 すなわち、アルゴリズムは検出できるだけです木の現在の証明書が信用アンカーによって発行されたか、またはそれが目標証明書(EE)を発行した。 木から、上では、目標証明書から建てるのが、100%の割合(例えば、その時Trust Anchorによって発行されるCに鎖を作るBへのEEチェーン)で信用アンカーによって発行された証明書に遭遇する前に2通の中間的証明書を調べるのを必要とするでしょう。 Trust Anchor(TA)がCで証明書を発行すると認めることができるので、経路を造るモジュールはAにCを束縛しないでしょう。
Cooper, et al. Informational [Page 19] RFC 4158 Certification Path Building September 2005
クーパー、他 [19ページ]情報のRFC4158証明経路ビル2005年9月
On the other hand, in the first tree (Figure 7: from anchor depiction), there is a 50% probability of building a path longer than needed (e.g., TA to A to C to B to EE rather than the shorter TA to A to B to EE). However, even given our simplistic example, the path- building software, when at A, could be designed to recognize that B's subject distinguished name (DN) matches the issuer DN of the EE. Given this one optimization, the builder could prefer B to C. (B's subject DN matches that of the EE's issuer whereas C's subject DN does not.) So, for this example, assuming the issuedByThisCA (reverse) and issuedToThisCA (forward) elements were fully populated in the directory and our path-building module implemented the aforementioned DN matching optimization method, path building from either the trust anchor or the target certificate could be made roughly equivalent. A list of possible optimization methods is provided later in this document.
他方では、1番目では、木に登ってください、(図7:、アンカー描写)、必要とされるより長い間経路を造るというaの50%の確率(例えば、AへのAへの、より短いTAよりむしろEEへのBへのEEへのCからBまでのTA)があります。 しかしながら、Aにあるとき、私たちの安易な例を考えさえして、ビーズの対象の分類名(DN)がEEの発行人DNに合っていると認めるように経路ビルソフトウェアを設計できました。 これを考えて、最適化、建築業者はC.よりBを好むことができました。(ビーズの対象のDNはEEの発行人のものに合っていますが、Cの対象DNは合わせるというわけではありません。) それで、この例のためにissuedByThisCA(逆にする)とissuedToThisCA(前方)要素がディレクトリで完全に居住されて、私たちの経路を造るモジュールが前述のDN合っている最適化方法を実行したと仮定する場合、手荒く信用アンカーか目標証明書のどちらかからの経路ビルを同等にするかもしれません。 後で本書では可能な最適化方法のリストを提供します。
A more complicated example is created when the path-building software encounters a situation when there are multiple certificates from which to choose while building a path. We refer to this as a large decision tree, or a situation with high fan-out. This might occur if an implementation has multiple trust anchors to choose from, and is building in the reverse (from trust anchor) direction. Or, it may occur in either direction if a Bridge CA is encountered. Large decision trees are the enemy of efficient path-building software. To combat this problem, implementations should make careful decisions about the path-building direction, and should utilize optimizations such as those discussed in Section 3.1 when confronted with a large decision tree.
経路を造っている間に選ぶ複数の証明書があるとき、経路を造るソフトウェアが状況に遭遇するとき、より複雑な例は作成されます。 私たちは大きい意思決定の樹状図にこれについて言及するか、または高値がある状況が四方八方に広がります。 実現が選ぶ複数の信用アンカーがいて、反対(信用アンカーからの)の方向に建てられているなら、これは起こるかもしれません。 または、Bridgeカリフォルニアが遭遇するなら、それはどちらの方向にも起こるかもしれません。 大きい意思決定の樹状図は効率的な経路を造るソフトウェアの敵です。 実現は、この問題と戦うのに、経路を造る指示に関する注意深い決定をするべきであり、大きい意思決定の樹状図に立ち向かわれているとセクション3.1で議論したものなどの最適化を利用するべきです。
Irrespective of the path-building approach for any path-building algorithm, cases can be constructed that make the algorithm perform poorly. The following questions should help a developer decide from which direction to build certification paths for their application:
どんな経路を造るアルゴリズムのための経路を造るアプローチの如何にかかわらず、アルゴリズムが不十分に働くケースは構成できます。 以下の質問は、開発者が、どの指示から彼らのアプリケーションのために証明経路を造ると決めるかを助けるべきです:
1) What is required to accommodate the local PKI environment and the
PKI environments with which interoperability will be required?
1) 相互運用性が必要である地方のPKI環境とPKI環境を収容するのに必要であること?
a. If using a directory, is the directory [RFC2587] compliant
(specifically, are the issuedToThisCA [forward] cross-
certificates and/or the cACertificate attributes fully
populated in the directory)? If yes, you are able to build in
the forward direction.
a。 ディレクトリを使用するなら、ディレクトリが[RFC2587]対応である、(明確に、issuedToThisCA[フォワード] 十字証明書、そして/または、ディレクトリで完全に居住されたcACertificate属性)はそうですか? はいなら、あなたは順方向に建てることができます。
b. If using a directory, does the directory contain all the
issuedByThisCA (reverse) cross-certificates in the
crossCertificatePair attribute, or, alternately, are all
certificates issued from each CA available via some other
means? If yes, it is possible to build in the reverse
b。 ディレクトリを使用するなら、ディレクトリがcrossCertificatePair属性にすべてのissuedByThisCA(逆にする)の交差している証明書を含んでいますか、または交互に、起こされるすべての証明書がある他の手段を通して利用可能なそれぞれのカリフォルニアですか? はい、逆で建てるのが可能であるなら
Cooper, et al. Informational [Page 20] RFC 4158 Certification Path Building September 2005
クーパー、他 [20ページ]情報のRFC4158証明経路ビル2005年9月
direction. Note: [RFC2587] does not require the issuedByThisCA
(reverse) cross-certificates to be populated; if they are
absent it will not be possible to build solely in the reverse
direction.
指示。 以下に注意してください。 [RFC2587]は、issuedByThisCA(逆にする)の交差している証明書が居住されるのを必要としません。 それらが休むと、唯一反対の方向に建てるのは可能でないでしょう。
c. Are all issuer certificates available via some means other than
a directory (e.g., the authorityInformationAccess extension is
present and populated in all certificates)? If yes, you are
able to build in the forward direction.
c。 ディレクトリを除いて、いくつかの手段を通して利用可能なすべての発行人証明書がありますか?(例えば、authorityInformationAccess拡張子は、現在であってすべての証明書で居住されています) はいなら、あなたは順方向に建てることができます。
2) How many trust anchors will the path-building and validation
software be using?
2) 経路ビルと合法化ソフトウェアは何人の信用アンカーを使用するでしょうか?
a. Are there (or will there be) multiple trust anchors in the
local PKI? If yes, forward path building may offer better
performance.
a。 複数の信用アンカーが地方のPKIにいますか?(または、あるでしょう) はいなら、フォワードパスビルは、より良い性能を提供するかもしれません。
b. Will the path-building and validation software need to place
trust in trust anchors from PKIs that do not populate reverse
cross-certificates for all intermediate CAs? If no, and the
local PKI populates reverse cross-certificates, reverse path
building is an option.
b。 経路ビルと合法化ソフトウェアは、信用アンカーですべての中間的CAsのための逆の交差している証明書に居住しないPKIsから信頼する必要があるでしょうか? いいえ、地方のPKIは逆の交差している証明書に居住して、逆の経路ビルはオプションです。
2.4. How to Build a Certification Path
2.4. 証明経路を造る方法
As was discussed in the prior section, path building is essentially a tree traversal. It was easy to see how this is true in a simple example, but how about a more complicated one? Before taking a look at more a complicated scenario, it is worthwhile to address loops and what constitutes a loop in a certification path. [X.509] specifies that the same certificate may not repeat in a path. In a strict sense, this works well as it is not possible to create an endless loop without repeating one or more certificates in the path. However, this requirement fails to adequately address Bridged PKI environments.
先のセクションで議論したように、経路ビルは本質的には木の縦断です。 これが簡単な例でどう本当であるかを見るのが簡単でしたが、より複雑なものはどうですか? 複雑なシナリオをさらに見る前に、輪と証明経路で輪を構成することを記述する価値があります。 [X.509]は、同じ証明書が経路で繰り返されないかもしれないと指定します。 厳しい意味で、経路で繰り返している1通以上の証明書なしで永久ループを作成するのが可能でないときに、これはうまくいきます。 しかしながら、この要件は適切にBridged PKI環境を記述しません。
Cooper, et al. Informational [Page 21] RFC 4158 Certification Path Building September 2005
クーパー、他 [21ページ]情報のRFC4158証明経路ビル2005年9月
+---+ +---+
| F |--->| H |
+---+ +---+
^ ^ ^
| \ \
| \ \
| v v
| +---+ +---+
| | G |--->| I |
| +---+ +---+
| ^
| /
| /
+------+ +-----------+ +------+ +---+ +---+
| TA W |<----->| Bridge CA |<------>| TA X |-->| L |-->| M |
+------+ +-----------+ +------+ +---+ +---+
^ ^ \ \
/ \ \ \
/ \ \ \
v v v v
+------+ +------+ +---+ +---+
| TA Y | | TA Z | | J | | N |
+------+ +------+ +---+ +---+
/ \ / \ | |
/ \ / \ | |
/ \ / \ v v
v v v v +---+ +----+
+---+ +---+ +---+ +---+ | K | | EE |
| A |<--->| C | | O | | P | +---+ +----+
+---+ +---+ +---+ +---+
\ / / \ \
\ / / \ \
\ / v v v
v v +---+ +---+ +---+
+---+ | Q | | R | | S |
| B | +---+ +---+ +---+
+---+ |
/\ |
/ \ |
v v v
+---+ +---+ +---+
| E | | D | | T |
+---+ +---+ +---+
+---+ +---+ | F|、-、--、>| H| +---+ +---+ ^ ^ ^ | \ \ | \ \ | vに対して| +---+ +---+ | | G|、-、--、>| I| | +---+ +---+ | ^ | / | / +------+ +-----------+ +------+ +---+ +---+ | バイバイ、W| <、-、-、-、--、>| カリフォルニアに橋を架けてください。| <、-、-、-、-、--、>| バイバイ、X| -->、| L| -->、| M| +------+ +-----------+ +------+ +---+ +---+ ^ ^ \ \ / \ \ \ / \ \ \ v v v v +------+ +------+ +---+ +---+ | バイバイ、Y| | バイバイ、Z| | J| | N| +------+ +------+ +---+ +---+ / \ / \ | | / \ / \ | | /\/\v v v v v v+---+ +----+ +---+ +---+ +---+ +---+ | K| | EE| | A| <、-、--、>| C| | O| | P| +---+ +----+ +---+ +---+ +---+ +---+ v v対+への\//\\\//\\\/v---+ +---+ +---+ +---+ | Q| | R| | S| | B| +---+ +---+ +---+ +---+ | /\ | / \ | v対+に---+ +---+ +---+ | E| | D| | T| +---+ +---+ +---+
Figure 9 - Four Bridged PKIs
図9--4はPKIsに橋を架けました。
Cooper, et al. Informational [Page 22] RFC 4158 Certification Path Building September 2005
クーパー、他 [22ページ]情報のRFC4158証明経路ビル2005年9月
Figure 9 depicts four root certification authorities cross-certified with a Bridge CA (BCA). While multiple trust anchors are shown in the Figure, our examples all consider TA Z as the trust anchor. The other trust anchors serve different relying parties. By building certification paths through the BCA, trust can be extended across the four infrastructures. In Figure 9, the BCA has four certificates issued to it; one issued from each of the trust anchors in the graph. If stored in the BCA directory system, the four certificates issued to the BCA would be stored in the issuedToThisCA (forward) entry of four different crossCertificatePair structures. The BCA also has issued four certificates, one to each of the trust anchors. If stored in the BCA directory system, those certificates would be stored in the issuedByThisCA (reverse) entry of the same four crossCertificatePair structures. (Note that the cross-certificates are stored as matched pairs in the crossCertificatePair attribute. For example, a crossCertificatePair structure might contain both A(B) and B(A), but not contain A(C) and B(A).) The four crossCertificatePair structures would then be stored in the BCA's directory entry in the crossCertificatePair attribute.
図9は4根の証明の当局の十字で公認されたBridgeと共にカリフォルニア(BCA)について表現します。 複数の信用アンカーが図で見せられている間、私たちの例はすべて、TA Zが信用アンカーであるとみなします。 他の信用アンカーは異なった信用にパーティーに勤めます。 BCAを通して証明経路を造ることによって、4つのインフラストラクチャの向こう側に信用を広げることができます。 図9では、BCAは4通の証明書をそれに発行させます。 1つはグラフで信用アンカーの各人から外へ出ました。 BCAディレクトリシステムに格納されるなら、BCAに発行された4通の証明書が4つの異なったcrossCertificatePair構造のissuedToThisCA(前方)エントリーに格納されるでしょう。 BCAも信用アンカーの各人に4通の証明書、1を発行しました。 BCAディレクトリシステムに格納されるなら、それらの証明書は同じ4つのcrossCertificatePair構造のissuedByThisCA(逆にする)エントリーに格納されるでしょう。 (交差している証明書が互角のペアとしてcrossCertificatePair属性に格納されることに注意してください。 例えば、crossCertificatePair構造は、A(B)とB(A)の両方を含んでいますが、A(C)とB(A)は含まないかもしれません。) そして、4つのcrossCertificatePair構造がBCAのディレクトリエントリにcrossCertificatePair属性で格納されるでしょう。
2.4.1. Certificate Repetition
2.4.1. 証明書反復
[X.509] requires that certificates are not repeated when building paths. For instance, from the figure above, do not build the path TA Z->BCA->Y->A->C->A->C->B->D. Not only is the repetition unnecessary to build the path from Z to D, but it also requires the reuse of a certificate (the one issued from C to A), which makes the path non- compliant with [X.509].
[X.509]は、経路を造るとき、証明書が繰り返されないのを必要とします。 例えば、図から、上では、BCA>Y>A>C>A>C>B>Dを経路TA Z->に造らないでください。 また、ZからDまで経路を造るために不要な反復があるだけではなく、それは証明書(CからAまで発行されたもの)の再利用を必要とします。(証明書は経路を[X.509]と共に非対応するのにします)。
What about the following path from TA Z to EE?
以下のTA ZからEEまでの経路はどうですか?
TA Z->BCA->Y->BCA->W->BCA->X->L->N->EE
バイバイ、Z、-、>BCA>Y>、BCA>W、-、>BCA>X>Lの>N>のEE
Unlike the first example, this path does not require a developer to repeat any certificates; therefore, it is compliant with [X.509]. Each of the BCA certificates is issued from a different source and is therefore a different certificate. Suppose now that the bottom left PKI (in Figure 9) had double arrows between Y and C, as well as between Y and A. The following path could then be built:
最初の例と異なって、この経路は、開発者がどんな証明書も繰り返すのを必要としません。 したがって、それは[X.509]と共に言いなりになっています。 それぞれのBCA証明書は、異なったソースから発行されて、したがって、異なった証明書です。 左の下部PKI(図9の)がYとCの間と、そして、次に次の経路を造ることができたYとA.の間に二重矢を持っていたので、思ってください:
TA Z->BCA->Y->A->C->Y->BCA->W->BCA->X->L->N->EE
バイバイ、Z、-、>BCA>Y>A>C>Y>、BCA>W、-、>BCA>X>Lの>N>のEE
A path such as this could become arbitrarily complex and traverse every cross-certified CA in every PKI in a cross-certified environment while still remaining compliant with [X.509]. As a practical matter, the path above is not something an application would typically want or need to build for a variety of reasons:
まだ[X.509]と共に言いなりになったままで残っている間、これなどの経路は、任意に複雑になって、十字で公認された環境であらゆるPKIのあらゆる十字で公認されたカリフォルニアを横断するかもしれません。 実際問題として、上の経路は、アプリケーションが通常必要としないどんなものと、またはさまざまな理由で建てる必要性でもありません:
Cooper, et al. Informational [Page 23] RFC 4158 Certification Path Building September 2005
クーパー、他 [23ページ]情報のRFC4158証明経路ビル2005年9月
- First, certification paths like the example above are generally
not intended by the PKI designers and should not be necessary in
order to validate any given certificate. If a convoluted path
such as the example above is required (there is no corresponding
simple path) in order to validate a given certificate, this is
most likely indicative of a flaw in the PKI design.
- まず最初に、上記の例のような証明経路は、一般に、PKIデザイナーによって意図されないで、どんな与えられた証明書も有効にするのに必要であるべきではありません。 上記の例などの複雑な経路が与えられた証明書を有効にするのに必要であるなら(どんな対応する簡単な経路もありません)、これはたぶんPKIデザインにおける欠点を暗示しています。
- Second, the longer a path becomes, the greater the potential
dilution of trust in the certification path. That is, with each
successive link in the infrastructure (i.e., certification by
CAs and cross-certification between CAs) some amount of
assurance may be considered lost.
- 2番目に、経路が長ければ長いほど、証明経路での信用の潜在的希釈は、より大きいです。 すなわち、インフラストラクチャ(すなわち、CAsによる証明とCAsの間の相互認証)におけるそれぞれの連続したリンクで、いくらかの量の保証が無くなると考えられるかもしれません。
- Third, the longer and more complicated a path, the less likely
it is to validate because of basic constraints, policies or
policy constraints, name constraints, CRL availability, or even
revocation.
- 経路が3番目に、より長くて、複雑であれば複雑であるほど、それは基本的な規制、方針または方針のために規制、名前規制、CRLの有用性、または取消しさえより有効にしそうにはありません。
- Lastly, and certainly not least important from a developer's or
user's perspective, is performance. Allowing paths like the one
above dramatically increases the number of possible paths for
every certificate in a mesh or cross-certified environment.
Every path built may require one or more of the following:
validation of certificate properties, CPU intensive signature
validations, CRL retrievals, increased network load, and local
memory caching. Eliminating the superfluous paths can greatly
improve performance, especially in the case where no path
exists.
- 最後に、そして、確かに、開発者かユーザの見解から特に重要であることで、性能はそうですか? 上のもののような経路を許容すると、可能な経路の数はあらゆる証明書のためにメッシュか十字で公認された環境で劇的に増加します。 造られたあらゆる経路が以下の1つ以上を必要とするかもしれません: 証明書の特性、CPUの徹底的な署名合法化の合法化(CRL retrievals)はネットワーク負荷、および地方のメモリキャッシュを増加させました。 余計な経路を排除するのは特に経路が全く存在しない場合で性能を大いに向上させることができます。
There is a special case involving certificates with the same distinguished names but differing encodings required by [RFC3280]. This case should not be considered a repeated certificate. See Section 5.4 for more information.
同じ分類名に証明書にかかわる特別なケースがありますが、異なったencodingsが[RFC3280]が必要です。 繰り返された証明書であると本件を考えるべきではありません。 詳しい情報に関してセクション5.4を見てください。
2.4.2. Introduction to Path-Building Optimization
2.4.2. 経路を造る最適化への序論
How can these superfluous paths be eliminated? Rather than only disallowing identical certificates from repeating, it is recommended that a developer disallow the same public key and subject name pair from being repeated. For maximum flexibility, the subject name should collectively include any subject alternative names. Using this approach, all of the intended and needed paths should be available, and the excess and diluted paths should be eliminated. For example, using this approach, only one path exists from the TA Z to EE in the diagram above: TA Z->BCA->X->L->N->EE.
どうしたらこれらの余計な経路を排除できますか? 反復から同じ証明書を禁じるだけのむしろ、開発者が繰り返されるので同じ公開鍵と対象の名前組を禁じるのは、お勧めです。 最大の柔軟性のために、対象の名前はどんな対象の代替名もまとめて含むべきです。 このアプローチを使用して、意図していて必要な経路のすべてが利用可能であるべきです、そして、余分で希釈された経路は排除されるべきです。 例えば、このアプローチを使用して、1つの経路だけが以下の上にダイヤグラムでTA ZからEEまで存在しています。 バイバイ、Z->。BCA>X>L>N>のEE。
Cooper, et al. Informational [Page 24] RFC 4158 Certification Path Building September 2005
クーパー、他 [24ページ]情報のRFC4158証明経路ビル2005年9月
Given the simplifying rule of not repeating pairs of subject names (including subject alternative names) and public keys, and only using certificates found in the cACertificate and forward (issuedToThisCA) element of the crossCertificatePair attributes, Figure 10 depicts the forward path-building decision tree from the EE to all reachable nodes in the graph. This is the ideal graph for a path builder attempting to build a path from TA Z to EE.
組の対象の名前(対象の代替名を含んでいる)と公開鍵を繰り返さない簡素化規則を与えて、crossCertificatePair属性のcACertificateと急進的な(issuedToThisCA)要素で見つけられた証明書を使用するだけであって、図10はグラフにEEから届いているすべてのノードまで早稲の経路を造る意思決定の樹状図について表現します。 これはTA ZからEEまで経路を造るのを試みる経路建築業者にとって、理想的なグラフです。
+------+ +-----------+ +------+ +---+
| TA W |<------| Bridge CA |<-------| TA X |<--| L |
+------+ +-----------+ +------+ +---+
/ \ ^
/ \ \
/ \ \
v v \
+------+ +------+ +---+
| TA Y | | TA Z | | N |
+------+ +------+ +---+
^
\
\
+----+
| EE |
+----+
+------+ +-----------+ +------+ +---+ | バイバイ、W| <、-、-、-、-、--、| カリフォルニアに橋を架けてください。| <、-、-、-、-、-、--、| バイバイ、X| <--、| L| +------+ +-----------+ +------+ +---+ / \ ^ / \ \ / \ \ v v \ +------+ +------+ +---+ | バイバイ、Y| | バイバイ、Z| | N| +------+ +------+ +---+ ^ \ \ +----+ | EE| +----+
Figure 10 - Forward (From Entity) Decision Tree
図10--早稲(実体からの)の意思決定の樹状図
It is not possible to build forward direction paths into the infrastructures behind CAs W, Y, and Z, because W, Y, and Z have not been issued certificates by their subordinate CAs. (The subordinate CAs are F and G, A and C, and O and P, respectively.) If simplicity and speed are desirable, the graph in Figure 10 is a very appealing way to structure the path-building algorithm. Finding a path from the EE to one of the four trust anchors is reasonably simple. Alternately, a developer could choose to build in the opposite direction, using the reverse cross-certificates from any one of the four trust anchors around the BCA. The graph in Figure 11 depicts all possible paths as a tree emanating from TA Z. (Note: it is not recommended that implementations attempt to determine all possible paths, this would require retrieval and storage of all PKI data including certificates and CRLs! This example is provided to demonstrate the complexity which might be encountered.)
CAs W、Y、およびZの後ろで順方向経路をインフラストラクチャに組み込むのは可能ではありません、それらの下位のCAsによる証明書がW、Y、およびZに発行されていないので。 (下位のCAsはそれぞれFと、Gと、Aと、Cと、OとPです。) 簡単さと速度が望ましいなら、図10のグラフは経路を造るアルゴリズムを構造化する非常に魅力的な方法です。 EEから4人の信用アンカーのひとりにとって経路を見つけるのは合理的に簡単です。 交互に、開発者は、逆方向に建てるのを選ぶことができました、BCAの周りの4人の信用アンカーのどれかからの交差している証明書の逆を使用して。 図11のグラフはTA Zから発する木としてすべての可能な経路について表現します。(以下に注意してください。 決定するその実現試みはすべての可能な経路、これが証明書とCRLsを含むすべてのPKIデータの検索と格納を必要とするのが推薦されません! 遭遇するかもしれない複雑さを示すためにこの例を提供します。)
Cooper, et al. Informational [Page 25] RFC 4158 Certification Path Building September 2005
クーパー、他 [25ページ]情報のRFC4158証明経路ビル2005年9月
+---+ +---+
| I |--->| H |
+---+ +---+
^
| +---+ +---+
| | H |--->| I |
| +---+ +---+
+---+ ^
| G | / +---+ +---+ +---+
+---+ / | F |--->| H |--->| I |
^ / +---+ +---+ +---+
\ / ^
\/ /
+---+ +---+ +---+ +---+ +---+
| F | | G |--->| I |--->| H | | M |
+---+ +---+ +---+ +---+ +---+
^ ^ ^
| / |
+------+ +-----------+ +------+ +---+
| TA W |<------| Bridge CA |-------->| TA X |-->| L |
+------+ +-----------+ +------+ +---+
/ ^ \ \
v \ v v
+------+ +------+ +---+ +---+
| TA Y | | TA Z | | J | | N |
+------+ +------+ +---+ +---+
/ \ / \ \ \
v v v v v v
+---+ +---+ +---+ +---+ +---+ +----+
| A | | C | | O | | P | | K | | EE |
+---+ +---+ +---+ +---+ +---+ +----+
/ \ / \ / \ \
v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+
| B | | C | | A | | B | | Q | | R | | S |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
/ \ \ \ \ \ \
v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+
| E | | D | | B | | B | | E | | D | | T |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
/ | | \
v v v v
+---+ +---+ +---+ +---+
| E | | D | | E | | D |
+---+ +---+ +---+ +---+
+---+ +---+ | I|、-、--、>| H| +---+ +---+ ^ | +---+ +---+ | | H|、-、--、>| I| | +---+ +---+ +---+ ^ | G| / +---+ +---+ +---+ +---+ / | F|、-、--、>| H|、-、--、>| I| ^ / +---+ +---+ +---+ \ / ^ \/ / +---+ +---+ +---+ +---+ +---+ | F| | G|、-、--、>| I|、-、--、>| H| | M| +---+ +---+ +---+ +---+ +---+ ^ ^ ^ | / | +------+ +-----------+ +------+ +---+ | バイバイ、W| <、-、-、-、-、--、| カリフォルニアに橋を架けてください。|、-、-、-、-、-、-、--、>| バイバイ、X| -->、| L| +------+ +-----------+ +------+ +---\v対+への+/^ \ \------+ +------+ +---+ +---+ | バイバイ、Y| | バイバイ、Z| | J| | N| +------+ +------+ +---+ +---v v v対+への+/\/\\\v---+ +---+ +---+ +---+ +---+ +----+ | A| | C| | O| | P| | K| | EE| +---+ +---+ +---+ +---+ +---+ +----v v v v対+への+/\/\/\\v---+ +---+ +---+ +---+ +---+ +---+ +---+ | B| | C| | A| | B| | Q| | R| | S| +---+ +---+ +---+ +---+ +---+ +---+ +---v v v v対+への+/\\\\\\v---+ +---+ +---+ +---+ +---+ +---+ +---+ | E| | D| | B| | B| | E| | D| | T| +---+ +---+ +---+ +---+ +---+ +---+ +---+ / | | \v対v v+---+ +---+ +---+ +---+ | E| | D| | E| | D| +---+ +---+ +---+ +---+
Figure 11 - Reverse (From Anchor) Decision Tree
図11--意思決定の樹状図を逆にしてください(アンカーから)。
Cooper, et al. Informational [Page 26] RFC 4158 Certification Path Building September 2005
クーパー、他 [26ページ]情報のRFC4158証明経路ビル2005年9月
Given the relative complexity of this decision tree, it becomes clear that making the right choices while navigating the tree can make a large difference in how quickly a valid path is returned. The path- building software could potentially traverse the entire graph before choosing the shortest path: TA Z->BCA->X->L->N->EE. With a decision tree like the one above, the basic depth first traversal approach introduces obvious inefficiencies in the path-building process. To compensate for this, a path-building module needs to decide not only in which direction to traverse the tree, but also which branches of the tree are more likely to yield a valid path.
この意思決定の樹状図の相対的な複雑さを考えて、木にナビゲートしている間、正しい選択をするとどれくらいすばやく有効な経路を返すかで大きな違いを作ることができるのは明確になります。 最短パスを選ぶ前に、経路ビルソフトウェアは潜在的に全体のグラフを横断するかもしれません: バイバイ、Z->。BCA>X>L>N>のEE。 もののような意思決定の樹状図で、上では、深さの基本的な第1縦断アプローチが経路建築の過程で明白な非能率を導入します。 これを補うために、経路を造るモジュールは、おそらく、有効な経路をもたらすためにまた、木を横断するどの指示だけではなく、木の枝がどれであるかを決める必要があります。
The path-building algorithm then ideally becomes a tree traversal algorithm with weights or priorities assigned to each branch point to guide the decision making. If properly designed, such an approach would effectively yield the "best path first" more often than not. (The terminology "best path first" is quoted because the definition of the "best" path may differ from PKI to PKI. That is ultimately to be determined by the developer, not by this document.) Finding the "best path first" is an effort to make the implementation efficient, which is one of our criteria as stated in Section 2.2.
そして、重りかプライオリティが意志決定を誘導するためにそれぞれのブランチポイントに割り当てられている状態で、経路を造るアルゴリズムは理想的に木の縦断アルゴリズムになります。 適切に設計されるなら、事実上、そのようなアプローチがもたらされるだろう、しばしば「最初に、経路を負かしてください。」 (用語は「最初に、経路を負かします」。「最も良い」経路の定義がPKIからPKIまで異なるかもしれないので、引用されます。 それはこのドキュメントではなく、開発者によって結局決定されることになっています。) 調査結果、「最初に経路を負かしてください、」 実現を効率的にするための努力(中で述べられるとしての私たちの評価基準の1つである)はセクション2.2ですか?
So how would a developer go about finding the best path first? Given the simplifying idea of addressing path building as a tree traversal, path building could be structured as a depth first search. A simple example of depth first tree traversal path building is depicted in Figure 12, with no preference given to sort order.
それで、開発者は、最初に最も良い経路を見つけながら、どのように動き回りますか? 木の縦断として経路ビルを記述するという簡素化考えを考えて、深さ第1検索として経路ビルを構造化できました。 深さ第1木の縦断経路ビルの簡単な例は図12に表現されます、オーダーが分類させられた優先なしで。
Note: The arrows in the lower portion of the figure do not indicate the direction of certificate issuance; they indicate the direction of the tree traversal from the target certificate (EE).
以下に注意してください。 図の下位部の矢は証明書発行の指示を示しません。 彼らは目標証明書(EE)から木の縦断の指示を示します。
Cooper, et al. Informational [Page 27] RFC 4158 Certification Path Building September 2005
クーパー、他 [27ページ]情報のRFC4158証明経路ビル2005年9月
+----+ +----+ +----+
| TA | | TA | | TA |
+----+ +----+ +----+
/ \ ^ ^
/ \ | |
v v +---+ +---+
+---+ +---+ | A | | C |
| A |<->| C | +---+ +---+
+---+ +---+ ^ ^
^ ^ +----+ | | +----+
\ / | TA | | | | TA |
v v +----+ | | +----+
+---+ ^ | | ^
| B | \ | | /
+---+ \ | | /
/ \ +---+ +---+
/ \ | C | | A |
v v +---+ +---+
+---+ +---+ ^ ^
| E | | D | | /
+---+ +---+ | /
+---+
Infrastructure | B |
+---+
^
|
+----+
| EE |
+----+
+----+ +----+ +----+ | バイバイ| | バイバイ| | バイバイ| +----+ +----+ +----+ / \ ^ ^ / \ | | v対+---+ +---+ +---+ +---+ | A| | C| | A| <->| C| +---+ +---+ +---+ +---+ ^ ^ ^ ^ +----+ | | +----+ \ / | バイバイ| | | | バイバイ| v対+----+ | | +----+ +---+ ^ | | ^ | B| \ | | / +---+ \ | | / / \ +---+ +---+ / \ | C| | A| v対+---+ +---+ +---+ +---+ ^ ^ | E| | D| | / +---+ +---+ | / +---+ インフラストラクチャ| B| +---+ ^ | +----+ | EE| +----+
The Same Infrastructure
Represented as a Tree
木として表された同じインフラストラクチャ
Cooper, et al. Informational [Page 28] RFC 4158 Certification Path Building September 2005
クーパー、他 [28ページ]情報のRFC4158証明経路ビル2005年9月
+----+ +----+
| TA | | TA |
+----+ +----+
^ ^
| |
+---+ +---+
| A | | C |
+---+ +---+
+----+ ^ ^ +----+
| TA | | | | TA |
+----+ | | +----+
^ | | ^
\ | | /
+---+ +---+ +---+ +---+
| C | | C | | A | | A |
+---+ +---+ +---+ +---+
^ ^ ^ ^
| | / /
| | / /
+---+ +---+ +---+ +---+
| B | | B | | B | | B |
+---+ +---+ +---+ +---+
^ ^ ^ ^
| | | |
| | | |
+----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+
+----+ +----+ | バイバイ| | バイバイ| +----+ +----+ ^ ^ | | +---+ +---+ | A| | C| +---+ +---+ +----+ ^ ^ +----+ | バイバイ| | | | バイバイ| +----+ | | +----+ ^ | | ^ \ | | / +---+ +---+ +---+ +---+ | C| | C| | A| | A| +---+ +---+ +---+ +---+ ^ ^ ^ ^ | | / / | | / / +---+ +---+ +---+ +---+ | B| | B| | B| | B| +---+ +---+ +---+ +---+ ^ ^ ^ ^ | | | | | | | | +----+ +----+ +----+ +----+ | EE| | EE| | EE| | EE| +----+ +----+ +----+ +----+
All possible paths from EE to TA
using a depth first decision tree traversal
すべての可能なEEから深さ第1意思決定の樹状図縦断を使用するTAまでの経路
Figure 12 - Path Building Using a Depth First Tree Traversal
図12--深さ最初の木の縦断を使用する経路ビル
Figure 12 illustrates that four possible paths exist for this example. Suppose that the last path (TA->A->B->EE) is the only path that will validate. This could be for any combination of reasons such as name constraints, policy processing, validity periods, or path length constraints. The goal of an efficient path-building component is to select the fourth path first by testing properties of the certificates as the tree is traversed. For example, when the path-building software is at entity B in the graph, it should examine both choices A and C to determine which certificate is the most likely best choice. An efficient module would conclude that A is the more likely correct path. Then, at A, the module compares terminating the path at TA, or moving to C. Again, an efficient module will make the better choice (TA) and thereby find the "best path first".
図12は、4つの可能な経路がこの例のために存在するのを例証します。 それが最後の経路であると仮定してください、(TA>A>B、-、>EE) それが有効にする唯一の経路がそうですか? これは名前規制、方針処理、有効期間、または経路長さの規制などの理由のどんな組み合わせのためのものであるかもしれません。 効率的な経路建築部材の目標は最初に、木が横断されるので証明書の特性をテストすることによって4番目の経路を選択することです。 実体Bに経路を造るソフトウェアがグラフにあるとき、例えば、それは、どの証明書が最もありそうな最も良い選択であるかを決定するために選択AとCの両方を調べるべきです。 効率的なモジュールは、Aが、よりありそうな正しい経路であると結論を下すでしょう。 効率的なモジュールは次に、Aでは、モジュールがTAで経路を終えるか、またはC.Againに動きながら比較されて、より良い選択(TA)をして、その結果、掘り出し物をする、「最初に、経路を負かしてください。」
Cooper, et al. Informational [Page 29] RFC 4158 Certification Path Building September 2005
クーパー、他 [29ページ]情報のRFC4158証明経路ビル2005年9月
What if the choice between CA certificates is not binary as it was in the previous example? What if the path-building software encounters a branch point with some arbitrary number of CA certificates thereby creating the same arbitrary number of tree branches? (This would be typical in a mesh style PKI CA, or at a Bridge CA directory entry, as each will have multiple certificates issued to itself from other CAs.) This situation actually does not change the algorithm at all, if it is structured properly. In our example, rather than treating each decision as binary (i.e., choosing A or C), the path-building software should sort all the available possibilities at any given branch point, and then select the best choice from the list. In the event the path could not be built through the first choice, then the second choice should be tried next upon traversing back to that point in the tree. Continue following this pattern until a path is found or all CA nodes in the tree have been traversed. Note that the certificates at any given point in the tree should only be sorted at the time a decision is first made. Specifically, in the example, the sorting of A and C is done when the algorithm reached B. There is no memory resident representation of the entire tree. Just like any other recursive depth first search algorithm, the only information the algorithm needs to keep track of is what nodes (entities) in the tree lie behind it on the current path, and for each of those nodes, which arcs (certificates) have already been tried.
それが前の例にあったときカリフォルニア証明書の選択が2進でないなら、どうなるでしょうか? 経路を造るソフトウェアがその結果、カリフォルニア証明書の何らかの特殊活字の数字が木の枝の同じ特殊活字の数字を作成しているブランチポイントに遭遇すると、どうなるでしょうか? (これはメッシュスタイルPKI CAか、Bridgeカリフォルニアディレクトリエントリにおいて典型でしょう、それぞれが他のCAsから複数の証明書をそれ自体に発行させるとき。) それが適切に構造化されるなら、この状況は実際に全くアルゴリズムを変えません。 バイナリー(すなわち、AかCを選ぶ)として各決定を扱うよりむしろ私たちの例では、経路を造るソフトウェアは、ブランチポイントを考えて、いずれでもすべての利用可能な可能性を分類して、次に、リストから最も良い選択を選択するはずです。 イベントでは、最初の選択で経路を造ることができないで、後部を横断するとき、次に、第二希望は次に、木でそのポイントまで試みられるべきです。 経路が見つけられるか、または木のすべてのカリフォルニアノードが横断されるまでこのパターンに従い続けてください。 最初に決定をするとき木の任意な与えられた点の証明書を分類するだけであるべきであることに注意してください。 アルゴリズムの達しているB.Thereが全体の木のメモリ常駐の表現でないときに、明確に、例では、AとCのソーティングをします。 まさしくいかなる他の深さの再帰的な第1検索アルゴリズムのようにも、アルゴリズムが動向をおさえる必要がある唯一の情報はそれの後ろに木のどんなノード(実体)が現在の経路、およびそれぞれのそれらのノードのためにあるかということです。既に、それのアーク(証明書)をそれを試みました。
2.5. Building Certification Paths for Revocation Signer Certificates
2.5. 取消し署名者証明書のために証明経路を造ります。
Special consideration is given to building a certification path for the Revocation Signer certificate because it may or may not be the same as the Certification Authority certificate. For example, after a CA performs a key rollover, the new CA certificate will be the CRL Signer certificate, whereas the old CA certificate is the Certification Authority certificate for previously issued certificates. In the case of indirect CRLs, the CRL Signer certificate will contain a different name and key than the Certification Authority certificate. In the case of OCSP, the Revocation Signer certificate may represent an OCSP Responder that is not the same entity as the Certification Authority.
それが認証局証明書と同じであるかもしれないのでRevocation Signer証明書のために証明経路を造るのに特別の配慮を与えます。 例えば、カリフォルニアが主要なロールオーバーを実行した後に新しいカリフォルニア証明書はCRL Signer証明書になるでしょうが、古いカリフォルニア証明書は以前に発行された証明書のための認証局証明書です。 間接的なCRLsの場合では、CRL Signer証明書は認証局証明書より異なった名前とキーを含むでしょう。 OCSPの場合では、Revocation Signer証明書は認証局と同じ実体でないOCSP Responderを表すかもしれません。
When the Revocation Signer certificate and the Certification Authority certificate are identical, no additional consideration is required from a certification path-building standpoint. That is, the certification path built (and validated) for the Certification Authority certificate can also be used as the certification path for the Revocation Signer certificate. In this case, the signature on the revocation data (e.g., CRL or OCSP response) is verified using the same certificate, and no other certification path building is required. An efficient certification path validation algorithm should first try all possible CRLs issued by the Certification
Revocation Signer証明書と認証局証明書が同じであるときに、追加的約因は全く経路を造る証明見地から必要ではありません。 また、Revocation Signer証明書に証明経路としてすなわち、認証局証明書のために造られた(そして、有効にされます)証明経路は使用できます。 この場合、取消しデータ(例えば、CRLかOCSP応答)における署名は同じ証明書を使用しますが、他のどんな証明も使用しないことで確かめられて、経路ビルが必要であるということです。 効率的な証明経路合法化アルゴリズムは最初に、Certificationによって発行されたすべての可能なCRLsを試みるべきです。
Cooper, et al. Informational [Page 30] RFC 4158 Certification Path Building September 2005
クーパー、他 [30ページ]情報のRFC4158証明経路ビル2005年9月
Authority to determine if any of the CRLs (a) cover the certificate in question, (b) are current, and (c) are signed using the same key used to sign the certificate.
証明書に署名するのに使用される同じキーを使用することでCRLs(a)のどれかが問題の証明書をカバーしているなら、(b)がよく見られることを決定する権威、および(c)は署名されます。
When the Revocation Signer certificate is not identical to the Certification Authority certificate, a certification path must be built (and validated) for the Revocation Signer certificate. In general, the certification path-building software may build the path as it would for any other certificate. However, this document also outlines methods in later sections for greatly improving path building efficiency for Revocation Signer certificate case.
Revocation Signer証明書が認証局証明書と同じでないときに、Revocation Signer証明書のために証明経路を造らなければなりません(そして、有効にされます)。 一般に、経路を造る証明ソフトウェアはいかなる他の証明書のためにも造るように経路を造るかもしれません。 しかしながら、また、このドキュメントは、Revocation Signer証明書ケースのために経路ビル効率を大いに高めるために後のセクションのメソッドを概説します。
2.6. Suggested Path-Building Software Components
2.6. 提案された経路を造るソフトウェアコンポーネント
There is no single way to define an interface to a path-building module. It is not the intent of this document to prescribe a particular method or semantic; rather, it is up to the implementer to decide. There are many ways this could be done. For example, a path-building module could build every conceivable path and return the entire list to the caller. Or, the module could build until it finds just one that validates and then terminate the procedure. Or, it could build paths in an iterative fashion, depending on validation outside of the builder and successive calls to the builder to get more paths until one valid path is found or all possible paths have been found. All of these are possible approaches, and each of these may offer different benefits to a particular environment or application.
経路を造るモジュールとインタフェースを定義するどんなただ一つの方法もありません。 それはこのドキュメントが特定のメソッドか意味的に時効になる意図ではありません。 むしろ、決めるのは、implementer次第です。 これができた多くの方法があります。 例えば、経路を造るモジュールは、想像できるあらゆる経路を造って、全体のリストを訪問者に返すかもしれません。 または、モジュールは、ちょうどそれが有効にする1つを見つけるまで建てて、次に、手順を終えるかもしれません。 または、繰り返しのファッションで経路を造るかもしれません、1つの有効な経路が見つけられるか、またはすべての可能な経路が見つけられるまで、より多くの経路を得るためにビルダーへのビルダーと連続した呼び出しの外で合法化によって。 これらのすべてが可能なアプローチです、そして、それぞれのこれらは特定の環境かアプリケーションへの異なった利益を提供するかもしれません。
Regardless of semantics, a path-building module needs to contain the following components:
意味論にかかわらず、経路を造るモジュールは、以下のコンポーネントを含む必要があります:
1) The logic for building and traversing the certificate graph.
1) 証明書グラフを築き上げて、横断するための論理。
2) Logic for retrieving the necessary certificates (and CRLs and/or
other revocation status information if the path is to be
validated) from the available source(s).
2) 利用可能なソースから必要な証明書を検索する(CRLsの、そして/または、他の取消し状態情報は経路であるなら有効にされることである)ための論理。
Assuming a more efficient and agile path-building module is desired, the following is a good starting point and will tie into the remainder of this document. For a path-building module to take full advantage of all the suggested optimizations listed in this document, it will need all of the components listed below.
より多くの効率的でアジャイルの経路を造るモジュールが望まれていると仮定すると、以下は、良い出発点であり、このドキュメントの残りを激しく攻撃するでしょう。 経路を造るモジュールが本書では記載されたすべての提案された最適化を最大限に利用するように、それは、以下にコンポーネントのすべてを記載する必要があるでしょう。
1) A local certificate and CRL cache.
1) ローカルの証明書とCRLキャッシュ。
a. This may be used by all certificate-using components; it does
not need to be specific to the path-building software. A local
cache could be memory resident, stored in an operating system
a。 これはすべての証明書を使用するコンポーネントによって使用されるかもしれません。 具体的に言うと、それは経路ビルにソフトウェアを必要としません。 ローカルなキャッシュは、オペレーティングシステムでメモリ常駐で、保存できるでしょう。
Cooper, et al. Informational [Page 31] RFC 4158 Certification Path Building September 2005
クーパー、他 [31ページ]情報のRFC4158証明経路ビル2005年9月
or application certificate store, stored in a database, or even
stored in individual files on the hard disk. While the
implementation of this cache is beyond the scope of this
document, some design considerations are listed below.
または、データベースに保存されるか、またはハードディスクに個々のファイルに保存さえされたアプリケーション証明書店。 このキャッシュの実装がこのドキュメントの範囲を超えている間、いくつかのデザイン問題が以下に記載されています。
2) The logic for building and traversing the certificate graph/tree.
2) 証明書グラフ/木を建てて、横断するための論理。
a. This performs sorting functionality for prioritizing
certificates (thereby optimizing path building) while
traversing the tree.
a。 これは、木を横断している間、証明書を最優先させるための機能性を分類しながら(その結果、経路ビルを最適化します)、働きます。
b. There is no need to build a complete graph prior to commencing
path building. Since path building can be implemented as a
depth first tree traversal, the path builder only needs to
store the current location in the tree along with the points
traversed to the current location. All completed branches can
be discarded from memory and future branches are discovered as
the tree is traversed.
b。 経路ビルを始める前に完全なグラフを築き上げる必要は全くありません。 深さ第1木の縦断として経路ビルを実装することができるので、経路ビルダーは、現在の位置に横断されたポイントに伴う木に現在の位置を保存する必要があるだけです。 メモリからすべての完成したブランチを捨てることができます、そして、木が横断されるとき、将来のブランチは発見されます。
3) Logic for retrieving the necessary certificates from the available
certificate source(s):
3) 手があいている証明書ソースからの必要な証明書を検索するための論理:
a. Local cache.
a。 ローカルなキャッシュ。
i. Be able to retrieve all certificates for an entity by
subject name, as well as individual certificates by
issuer and serial number tuple.
i。 対象の名前の実体のためのすべての証明書を検索できてください、発行人による個々の証明書と通し番号tupleと同様に。
ii. Tracking which directory attribute (including
issuedToThisCA <forward> and issuedByThisCA <reverse>
for split crossCertificatePair attributes) each
certificate was found in may be useful. This allows for
functionality such as retrieving only forward cross-
certificates, etc.
ii。 各証明書がどのディレクトリ属性(分裂crossCertificatePair属性のためのissuedToThisCAの<の前進の>とissuedByThisCAの<の逆の>を含んでいる)に見つけられたかを追跡するのは役に立つかもしれません。 これは前進の十字証明書だけを検索などなどの機能性などを考慮します。
iii. A "freshness" timestamp (cache expiry time) can be used
to determine when the directory should be searched
again.
iii。 ディレクトリがいつ再び捜されるべきであるかを決定するのに、「新しさ」タイムスタンプ(キャッシュ満期時間)を使用できます。
b. LDAPv3 directory for certificates and CRLs.
b。 証明書とCRLsのためのLDAPv3ディレクトリ。
i. Consider supporting multiple directories for general
queries.
i。 一般的な質問のための複数のディレクトリを支えると考えてください。
ii. Consider supporting dynamic LDAP connections for
retrieving CRLs using an LDAP URI [RFC3986] in the CRL
distribution point certificate extension.
ii。 CRL分配ポイント証明書拡張子にLDAP URI[RFC3986]を使用することでCRLsを検索するためのダイナミックなLDAP接続をサポートすると考えてください。
Cooper, et al. Informational [Page 32] RFC 4158 Certification Path Building September 2005
クーパー、他 [32ページ]情報のRFC4158証明経路ビル2005年9月
iii. Support LDAP referrals. This is typically only a matter
of activating the appropriate flag in the LDAP API.
iii。 LDAPに紹介をサポートしてください。 通常、これはLDAP APIで適切なフラグを動かす問題にすぎません。
c. HTTP support for CRL distribution points and authority
information access (AIA) support.
c。 CRL分配ポイントのHTTPサポートと権威情報は(AIA)サポートにアクセスします。
i. Consider HTTPS support, but be aware that this may create
an unbounded recursion when the implementation tries to
build a certification path for the server's certificate if
this in turn requires an additional HTTPS lookup.
i。 HTTPSがサポートであると考えなさい、ただし、これが順番に追加HTTPSルックアップを必要とするなら実装がサーバの証明書のために証明経路を造ろうとするとき、これが限りない再帰を作成するかもしれないのを意識してください。
4) A certification path cache that stores previously validated
relationships between certificates. This cache should include:
4) それが以前に保存する証明経路キャッシュは証明書の間の関係を有効にしました。 このキャッシュは以下を含むべきです。
a. A configurable expiration date for each entry. This date can
be configured based upon factors such as the expiry of the
information used to determine the validity of an entry,
bandwidth, assurance level, storage space, etc.
a。 各エントリーへの構成可能な有効期限。 エントリー、帯域幅、保証レベル、集積スペースなどの正当性を決定するのに使用される情報の満期などの要素に基づいた状態でこの日付を構成できます。
b. Support to store previously verified issuer certificate to
subject certificate relationships.
b。 以前に保存するサポートは対象の証明書関係に発行人証明書について確かめました。
i. Since the issuer DN and serial number tuple uniquely
identifies a certificate, a pair of these tuples (one for
both the issuer and subject) is an effective method of
storing this relationship.
i。 発行人DNと通し番号tupleが唯一証明書を特定するので、これらのtuples(発行人と対象の両方のためのもの)の1組はこの関係を保存する有効な手段です。
c. Support for storing "known bad" paths and certificates. Once a
certificate is determined to be invalid, implementations can
decide not to retry path development and validation.
c。 「悪い状態で知られている」保存のために、経路と証明書を支えます。 証明書がいったん無効であることを決定するようになると、実装は、経路開発と合法化を再試行しないと決めることができます。
2.7. Inputs to the Path-Building Module
2.7. 経路を造るモジュールへの入力
[X.509] specifically addresses the list of inputs required for path validation but makes no specific suggestions concerning useful inputs to path building. However, given that the goal of path building is to find certification paths that will validate, it follows that the same inputs used for validation could be used to optimize path building.
[X.509]は、明確に経路合法化に必要である入力のリストを扱いますが、役に立つ入力に関してどんな特定の提案も経路ビルにしません。 しかしながら、経路ビルの目標がそれが有効にする証明経路を見つけることであるなら、経路ビルを最適化するのが、合法化に使用される同じ入力は使用できたのに続きます。
2.7.1. Required Inputs
2.7.1. 必要な入力
Setting aside configuration information such as repository or cache locations, the following are required inputs to the certification path-building process:
倉庫などの設定情報をかたわらに置いて、キャッシュ位置であり↓これは証明経路建築の過程への必要な入力です:
1) The Target Certificate: The certificate that is to be validated.
This is one endpoint for the path. (It is also possible to
1) 目標証明書: 有効にされることになっている証明書。 これは経路への1つの終点です。 (また、それも可能です。
Cooper, et al. Informational [Page 33] RFC 4158 Certification Path Building September 2005
クーパー、他 [33ページ]情報のRFC4158証明経路ビル2005年9月
provide information used to retrieve a certificate for a target,
rather than the certificate itself.)
証明書よりむしろ目標自体のための証明書を検索するのに使用される情報を提供してください。)
2) Trust List: This is the other endpoint of the path, and can
consist of either:
2) 信頼は記載します: これは、経路のもう片方の終点であり、どちらかから成ることができます:
a. Trusted CA certificates
a。 信じられたカリフォルニア証明書
b. Trusted keys and DNs; a certificate is not necessarily required
b。 キーとDNsは信じました。 証明書が必ず必要であるというわけではありません。
2.7.2. Optional Inputs
2.7.2. 任意の入力
In addition to the inputs listed in Section 2.7.1, the following optional inputs can also be useful for optimizing path building. However, if the path-building software takes advantage of all of the optimization methods described later in this document, all of the following optional inputs will be required.
また、セクション2.7.1でリストアップされた入力に加えて、以下の任意の入力も経路ビルを最適化することの役に立つ場合があります。 しかしながら、経路を造るソフトウェアが後で本書では説明された最適化メソッドのすべてを利用すると、以下の任意の入力のすべてが必要でしょう。
1) Time (T): The time for which the certificate is to be validated
(e.g., if validating a historical signature from one year ago, T
is needed to build a valid path)
1) 時間(T): 有効にされる証明書がことである時間(例えば、1年前から歴史的な署名を有効にするなら、Tが有効な経路を造るのに必要です)
a. If not included as an input, the path-building software should
always build for T equal to the current system time.
a。 入力として含まれていないなら、経路を造るソフトウェアはT同輩のために現在のシステム時間までいつも建てられるはずです。
2) Initial-inhibit-policy-mapping indicator
2) イニシャルが方針マッピングを禁止しているインディケータ
3) Initial-require-explicit-policy indicator
3) インディケータイニシャルが明白な方針が必要な
4) Initial-any-policy-inhibit indicator
4) 方針が禁止する初期のいずれもインディケータ
5) Initial user acceptable policy set
5) 初期のユーザ許容できる方針セット
6) Error handlers (call backs or virtual classes)
6) 誤り操作者(呼び出し後部か仮想のクラス)
7) Handlers for custom certificate extensions
7) 税関証明書拡張子のための操作者
8) Is-revocation-provider indicator
8) 取消しがプロバイダーであるインディケータ
a. IMPORTANT: When building a certification path for an OCSP
Responder certificate specified as part of the local
configuration, this flag should not be set. It is set when
building a certification path for a CRL Signer certificate or
for an OCSP Responder Signer certificate discovered using the
information asserted in an authorityInformationAccess
certificate extension.
a。 重要: 地方の構成の一部として指定されたOCSP Responder証明書のために証明経路を造るとき、この旗を設定するべきではありません。 CRL Signer証明書かauthorityInformationAccess証明書拡張子で断言された情報を使用していると発見されたOCSP Responder Signer証明書のために証明経路を造るとき、それは設定されます。
Cooper, et al. Informational [Page 34] RFC 4158 Certification Path Building September 2005
クーパー、他 [34ページ]情報のRFC4158証明経路ビル2005年9月
9) The complete certification path for the Certification Authority
(if Is-revocation-provider is set)
9) 認証局のための完全な証明経路(Is取消しプロバイダーが設定されるなら)
10) Collection of certificates that may be useful in building the
path
10) 経路を造る際に役に立つかもしれない証明書の収集
11) Collection of certificate revocation lists and/or other
revocation data
11) 証明書失効リスト、そして/または、他の取消しデータの収集
The last two items are a matter of convenience. Alternately, certificates and revocation information could be placed in a local cache accessible to the path-building module prior to attempting to build a path.
最後の2つの項目が便利の問題です。 交互に、経路を造るのを試みる前に経路を造るモジュールにアクセスしやすいローカルなキャッシュに証明書と取消し情報を置くことができました。
3. Optimizing Path Building
3. 最適化している経路ビル
This section recommends methods for optimizing path-building processes.
このセクションは経路建築の過程を最適化するためのメソッドを推薦します。
3.1. Optimized Path Building
3.1. 最適化された経路ビル
Path building can be optimized by sorting the certificates at every decision point (at every node in the tree) and then selecting the most promising certificate not yet selected as described in Section 2.4.2. This process continues until the path terminates. This is roughly equivalent to the concept of creating a weighted edge tree, where the edges are represented by certificates and nodes represent subject DNs. However, unlike the weighted edge graph concept, a certification path builder need not have the entire graph available in order to function efficiently. In addition, the path builder can be stateless with respect to nodes of the graph not present in the current path, so the working data set can be relatively small.
あらゆる決定ポイント(木のあらゆるノードの)で証明書を分類して、次に、セクション2.4.2で説明されるようにまだ選択されていなかった中で最も有望な証明書を選択することによって、経路ビルを最適化できます。 経路が終わるまで、このプロセスは持続します。 これはおよそ荷重している縁の木を作成する概念に同等です。そこでは、縁が証明書によって表されて、ノードは対象のDNsを表します。 しかしながら、荷重している縁のグラフ概念と異なって、証明経路ビルダーには利用可能な全体のグラフが、効率的に機能するようにある必要はありません。 さらに、経路ビルダーが現在の経路の現在でないグラフのノードに関して状態がない場合があるので、作業用データセットは比較的小さい場合があります。
The concept of statelessness with respect to nodes not in the current path is instrumental to using the sorting optimizations listed in this document. Initially, it may seem that sorting a given group of certificates for a CA once and then preserving that sorted order for later use would be an efficient way to write the path builder. However, maintaining this state can quickly eliminate the efficiency that sorting provides. Consider the following diagram:
現在の経路でないところのノードに関する国がないことの概念は本書では記載されたソーティング最適化を使用するのに手段になっています。 初めは、一度カリフォルニアのための証明書の与えられたグループを分類して、次に、後の使用のその分類された注文を保存するのが、経路ビルダーに書く効率的な方法であるように思えるかもしれません。 しかしながら、この状態を維持すると、すぐに、ソーティングが提供する効率を排除できます。 以下のダイヤグラムを考えてください:
Cooper, et al. Informational [Page 35] RFC 4158 Certification Path Building September 2005
クーパー、他 [35ページ]情報のRFC4158証明経路ビル2005年9月
+---+
| R |
+---+
^
/
v
+---+ +---+ +---+ +---+ +----+
| A |<----->| E |<---->| D |--->| Z |--->| EE |
+---+ +---+ +---+ +---+ +----+
^ ^ ^ ^
\ / \ /
\ / \ /
v v v v
+---+ +---+
| B |<----->| C |
+---+ +---+
+---+ | R| +---+ ^ / v +---+ +---+ +---+ +---+ +----+ | A| <、-、-、-、--、>| E| <、-、-、--、>| D|、-、--、>| Z|、-、--、>| EE| +---+ +---+ +---+ +---+ +----+ ^ ^ ^ ^ \ / \ / \ / \ / v v v v +---+ +---+ | B| <、-、-、-、--、>| C| +---+ +---+
Figure 13 - Example of Path-Building Optimization
図13--経路を造る最適化に関する例
In this example, the path builder is building in the forward (from target) direction for a path between R and EE. The path builder has also opted to allow subject name and key to repeat. (This will allow multiple traversals through any of the cross-certified CAs, creating enough complexity in this small example to illustrate proper state maintenance. Note that a similarly complex example could be designed by using multiple keys for each entity and prohibiting repetition.)
この例では、経路ビルダーはRとEEの間の経路のために前進(目標からの)の方向に建てています。 また、経路ビルダーは、対象の名前とキーが繰り返されるのを許容するために選びました。 (これは十字で公認されたCAsのどれかに複数の縦断の通ることを許すでしょう、この小さい例における適切な州のメインテナンスを例証できるくらいの複雑さを作成して。 各実体に複数のキーを使用して、反復を禁止することによって同様に複雑な例を設計できるだろうことに注意してください。)
The first step is simple; the builder builds the path Z(D)->EE(Z). Next the builder adds D and faces a decision between two certificates. (Choose between D(C) or D(E)). The builder now sorts the two choices in order of priority. The sorting is partially based upon what is currently in the path.
第一歩は簡単です。 ビルダーはEE(Z)を経路Z(D)->に造ります。 次に、ビルダーは、2通の証明書の間でDを加えて、決定に直面しています。 (D(C)かD(E))を選んでください。 ビルダーは現在、優先権の順に2つの選択を分類します。 ソーティングは現在、経路にあるものに部分的に基づいています。
Suppose the order the builder selects is [D(E), D(C)]. The current path is now D(E)->Z(D)->EE(Z). Currently the builder has three nodes in the graph (EE, Z, and D) and should maintain the state, including sort order of the certificates at D, when adding the next node, E. When E is added, the builder now has four certificates to sort: E(A), E(B), E(C), and E(D). In this case, the example builder opts for the order [E(C), E(B), E(A), E(D)]. The current path is now E(C)->D(E)-> Z(D)->EE(Z) and the path has four nodes; EE, Z, D, and E.
ビルダーが選択するオーダーがそうであると仮定してください。[D(E)、D(C)]。 現在のD(E)->はZ(D)->です。現在の経路、EE(Z)。 ビルダーには、現在の、ビルダーは、グラフ(EE、Z、およびD)による3つのノードを持って、状態を維持するべきです、Dに証明書に関するソート順序を含んでいて次のノードを加えるとき、E.When Eは加えられて、現在、分類する4通の証明書があります: E(A)、ユーロ(B)、ユーロ(C)、およびユーロ(D)。 この場合、例のビルダーはオーダーを選びます。[E(C)、E(B)、E(A)、E(D)]。 現在の経路、現在のE(C)->がD(E)->である、Z(D)、->EE(Z)と経路には、4つのノードがあります。 EE、Z、D、およびE。
Upon adding the fifth node, C, the builder sorts the certificates (C(B), C(D), and C(E)) at C, and selects C(E). The path is now C(E)->E(C)->D(E)->Z(D)->EE(Z) and the path has five nodes: EE, Z, D, E, and C.
そして、5番目のノード、Cを加えるときビルダーが証明書を分類する、(C(B)、C(D)、およびCのC(E))、C(E)を選択します。 経路、現在のC(E)->がE(C)->である、D(E)->、Z(D)、->EE(Z)と経路には、5つのノードがあります: EE、Z、D、E、およびC。
Cooper, et al. Informational [Page 36] RFC 4158 Certification Path Building September 2005
クーパー、他 [36ページ]情報のRFC4158証明経路ビル2005年9月
Now the builder finds itself back at node E with four certificates. If the builder were to use the prior sort order from the first encounter with E, it would have [E(C), E(B), E(A), E(D)]. In the current path's context, this ordering may be inappropriate. To begin with, the certificate E(C) is already in the path so it certainly does not deserve first place.
今、気付くと、ビルダーは4通の証明書でノードEに戻っています。 ビルダーがEとの最初の遭遇から先のソート順序を使用するつもりであったなら、それは使用したでしょう。[E(C)、E(B)、E(A)(E(D)])。 現在の経路の文脈では、この注文は不適当であるかもしれません。 初めに、証明書E(C)が経路に既にあるので、確かに、それは1位に値しません。
The best way to handle this situation is for the path builder to handle this instance of E as a new (sixth) node in the tree. In other words, there is no state information for this new instance of E - it is treated just as any other new node. The certificates at the new node are sorted based upon the current path content and the first certificate is then selected. For example, the builder may examine E(B) and note that it contains a name constraint prohibiting "C". At this point in the decision tree, E(B) could not be added to the path and produce a valid result since "C" is already in the path. As a result, the certificate E(B) should placed at the bottom of the prioritized list.
この状況を扱う最も良い方法は経路ビルダーが(6番目)の新しいノードとして木でEのこのインスタンスを扱うことです。 言い換えれば、Eのこの新しいインスタンスのための州の情報が全くありません--それはちょうどいかなる他の新しいノードとしても扱われます。 新しいノードの証明書は現在の経路内容に基づいた状態で分類されます、そして、次に、最初の証明書は選択されます。 例えば、ビルダーは、E(B)を調べて、「C」を禁止する名前規制を含むことに注意するかもしれません。 「C」が経路に既にあるので、E(B)は、ここに、意思決定の樹状図では、経路に加えられて、有効な結果を生むことができませんでした。 その結果、E(B)がそうするべきである証明書は最優先することの下部にリストを置きました。
Alternatively, E(B) could be eliminated from this new node in the tree. It is very important to see that this certificate is eliminated only at this node and only for the current path. If path building fails through C and traverses back up the tree to the first instance of E, E(B) could still produce a valid path that does not include C; specifically R->A->B->E->D->Z->EE. Thus the state at any node should not alter the state of previous or subsequent nodes. (Except for prioritizing certificates in the subsequent nodes.)
あるいはまた、木のこの新しいノードからE(B)を排除できました。 この証明書がこのノードにおいてだけ現在の経路だけに排除されるのがわかるのは非常に重要です。 Cと横断で経路ビルがEの最初のインスタンスへの木に失敗して戻るなら、E(B)はまだCを含んでいない有効な経路を生産しているかもしれません。 明確にR>A>B>E>D>Z>、EE。 したがって、どんなノードの州も前の、または、その後のノードの事情を変更するべきではありません。 (その後のノードの証明書を最優先させるのを除いた。)
In this example, the builder should also note that E(C) is already in the path and should make it last or eliminate it from this node since certificates cannot be repeated in a path.
この例では、ビルダーは、経路で証明書を繰り返すことができないので、また、E(C)が経路に既にあることに注意するべきであり、最後にそれを作るべきであるか、またはこのノードからそれを排除するべきです。
If the builder eliminates both certificates E(B) and E(C) at this node, it is now only left to select between E(A) and E(D). Now the path has six nodes: EE, Z, D, E(1), C, and E(2). E(1) has four certificates, and E(2) has two, which the builder sorts to yield [E(A), E(D)]. The current path is now E(A)->C(E)->E(C)->D(E)-> Z(D)->EE(Z). A(R) will be found when the seventh node is added to the path and the path terminated because one of the trust anchors has been found.
ビルダーがこのノードで証明書ユーロ(B)とユーロ(C)の両方を排除するなら、今、それがE(A)とE(D)の間で選択するのが残されるだけです。 今、経路には、6つのノードがあります: EE、Z、D、ユーロ(1)、C、およびユーロ(2)。 E(1)には、4通の証明書があります、そして、E(2)には、2があります。(ビルダーは、もたらすために2を分類します)。[E(A)、E(D)]。 現在の経路、現在のE(A)->がC(E)>Eである、(C)->、D(E)、-、>Z(D)->、EE(Z)。 7番目のノードがいつ経路に加えられるか、そして、信頼アンカーのひとりが見つけられたので終えられた経路はA(R)に見つけられるでしょう。
In the event the first path fails to validate, the path builder will still have the seven nodes and associated state information to work with. On the next iteration, the path builder is able to traverse back up the tree to a working decision point, such as A, and select the next certificate in the sorted list at A. In this example, that would be A(B). (A(R) has already been tested.) This would dead end, and the builder traverse back up to the next decision point, E(2)
最初の経路が有効にしないイベントでは、それでも、経路ビルダーは働いている7つのノードと準国家情報を持つでしょう。 次の繰り返しのときに経路ビルダーは木でAなどの働く決定ポイントに後部を横断できます、そして、分類で次の証明書を選択してください。A.Inにこの例をリストアップしてください、そして、それはA(B)でしょう。 (A(R)は既にテストされました。) これ、行き止まり、およびビルダーはポイント、Eを次の決定まで横断して戻すでしょう。(2)
Cooper, et al. Informational [Page 37] RFC 4158 Certification Path Building September 2005
クーパー、他 [37ページ]情報のRFC4158証明経路ビル2005年9月
where it would try D(E). This process repeats until the traversal backs all the way up to EE or a valid path is found. If the tree traversal returns to EE, all possible paths have been exhausted and the builder can conclude no valid path exists.
それがD(E)を試みるところ。 縦断がEEにいっぱいに戻るか、または有効な経路が当たられるまで、このプロセスは繰り返されます。 木の縦断がEEに戻るなら、すべての可能な経路が消耗しました、そして、ビルダーはどんな有効な経路も存在しないと結論づけることができます。
This approach of sorting certificates in order to optimize path building will yield better results than not optimizing the tree traversal. However, the path-building process can be further streamlined by eliminating certificates, and entire branches of the tree as a result, as paths are built.
経路ビルを最適化するために証明書を分類するこのアプローチは木の縦断を最適化しないより良い結果をもたらすでしょう。 しかしながら、証明書、およびその結果木の全体の枝を排除することによって、経路建築の過程をさらに合理化されることができます、経路が組立しているとき。
3.2. Sorting vs. Elimination
3.2. ソーティング対除去
Consider a situation when building a path in which three CA certificates are found for a given target certificate and must be prioritized. When the certificates are examined, as in the previous example, one of the three has a name constraint present that will invalidate the path built thus far. When sorting the three certificates, that one would certainly go to the back of the line. However, the path-building software could decide that this condition eliminates the certificate from consideration at this point in the graph, thereby reducing the number of certificate choices by 33% at this point.
3通のカリフォルニア証明書が与えられた目標証明書に関して見つけられて、最優先しなければならない経路を造るときには状況を考えてください。 証明書が前の例のように調べられるとき、3つのものの1つには、これまでのところ造られた経路を無効にする現在の名前規制があります。 3通の証明書を分類するとき、確かに、それは系列の後部まで行くでしょう。 しかしながら、経路を造るソフトウェアは、この状態がここにグラフで考慮から証明書を排除すると決めるかもしれません、その結果、ここに証明書選択の数を33%減少させます。
NOTE: It is important to understand that the elimination of a certificate only applies to a single decision point during the tree traversal. The same certificate may appear again at another point in the tree; at that point it may or may not be eliminated. The previous section details an example of this behavior.
以下に注意してください。 証明書の除去が木の縦断の間単一の決定ポイントに適用されるだけであるのを理解しているのは重要です。 同じ証明書は再び木にもう1ポイントに現れるかもしれません。 その時、それは排除されるかもしれません。 前項はこの振舞いに関する例を詳しく述べます。
Elimination of certificates could potentially eliminate the traversal of a large, time-consuming infrastructure that will never lead to a valid path. The question of whether to sort or eliminate is one that pits the flexibility of the software interface against efficiency.
証明書の除去は潜在的に有効な経路に決してつながらない大きくて、手間がかかったインフラストラクチャの縦断を排除するかもしれません。 質問、分類するか、または排除する、ソフトウェア・インタフェースの柔軟性を効率に対抗させるものはそうです。
To be clear, if one eliminates invalid paths as they are built, returning only likely valid paths, the end result will be an efficient path-building module. The drawback to this is that unless the software makes allowances for it, the calling application will not be able to see what went wrong. The user may only see the unrevealing error message: "No certification path found."
明確に、なるように、ありそうな有効な経路だけを返して、それらが組立しているので1つが無効の経路を排除するなら、結末は効率的な経路を造るモジュールになるでしょう。 これへの欠点はソフトウェアがそれを考慮に入れないと、呼ぶアプリケーションが、何が支障をきたしたかわかることができないということです。 ユーザは非啓示エラーメッセージを見るだけであるかもしれません: 「見つけられなかった証明経路。全く」
On the other hand, the path-building module could opt to not rule out any certification paths. The path-building software could then return any and all paths it can build from the certificate graph. It is then up to the validation engine to determine which are valid and which are invalid. The user or calling application can then have complete details on why each and every path fails to validate. The
他方では、経路を造るモジュールは、どんな証明経路も除外しないように選ばれることができました。 そして、経路を造るソフトウェアはそれが証明書グラフから造ることができるありとあらゆる経路を返すかもしれません。 どれが有効であるか、そして、どれが無効であるかを決定するのは、そして、合法化エンジン次第です。 次にアプリケーションでそれぞれ理由とあらゆる経路に詳細を完成できるユーザか呼ぶのが有効にしません。 The
Cooper, et al. Informational [Page 38] RFC 4158 Certification Path Building September 2005
クーパー、他 [38ページ]情報のRFC4158証明経路ビル2005年9月
drawback is obviously one of performance, as an application or end user may wait for an extended period of time while cross-certified PKIs are navigated in order to build paths that will never validate.
十字で公認されたPKIsがそれが決して有効にしない経路を造るためにナビゲートされますが、アプリケーションかエンドユーザが性能時間の長期間の間待つかもしれないので、欠点は明らかに1です。
Neither option is a very desirable approach. One option provides good performance for users, which is beneficial. The other option though allows administrators to diagnose problems with the PKI, directory, or software. Below are some recommendations to reach a middle ground on this issue.
どちらのオプションも非常に望ましいアプローチではありません。 1つのオプションがユーザのための望ましい市場成果を提供します。(それは、有益です)。 もっとも、他がゆだねる、管理者がPKI、ディレクトリ、またはソフトウェアに関する問題を診断するのを許容します。 以下に、この問題には妥協点に達するといういくつかの推薦があります。
First, developers are strongly encouraged to output detailed log information from the path-building software. The log should explicitly indicate every choice the builder makes and why. It should clearly identify which certificates are found and used at each step in building the path. If care is taken to produce a useful log, PKI administrators and help desk personnel will have ample information to diagnose a problem with the PKI. Ideally, there would be a mechanism for turning this logging on and off, so that it is not running all the time. Additionally, it is recommended that the log contain information so that a developer or tester can recreate the paths tried by the path-building software, to assist with diagnostics and testing.
まず最初に、開発者が経路を造るソフトウェアから詳細な航海日誌情報を出力するよう強く奨励されます。 ログは明らかにビルダーがするあらゆる選択と理由を示すべきです。 それは、どの証明書が各ステップで経路を造る際に見つけられて、使用されるかを明確に特定するべきです。 役に立つログを作り出すために注意すると、PKI管理者とヘルプデスク人員には、PKIに関する問題を診断する十分な情報があるでしょう。 理想的に、断続的にこの伐採をターンするためのメカニズムがあるでしょう、絶えず稼働していないように。 さらに、開発者かテスターが経路を造るソフトウェアによって試みられた経路を休養させることができるようにログが情報を含むのは、病気の特徴とテストを助けるためにお勧めです。
Secondly, it is desirable to return something useful to the user. The easiest approach is probably to implement a "dual mode" path- building module. In the first mode [mode 1], the software eliminates any and all paths that will not validate, making it very efficient. In the second mode [mode 2], all the sorting methods are still applied, but no paths are eliminated based upon the sorting methods. Having this dual mode allows the module to first fail to find a valid path, but still return one invalid path (assuming one exists) by switching over to the second mode long enough to generate a single path. This provides a middle ground -- the software is very fast, but still returns something that gives the user a more specific error than "no path found".
第二に、使い物をユーザに返すのは望ましいです。 最も簡単なアプローチはたぶん「デュアル・モード」経路ビルモジュールを実装することです。 最初のモード[モード1]で、ソフトウェアはそれが有効にしないありとあらゆる経路を排除します、それを非常に効率的にして。 2番目のモード[モード2]で、すべてのソーティングメソッドがまだ適用されていますが、経路は全くソーティングメソッドに基づいた状態で排除されません。 モジュールは最初に、このデュアル・モードを持っているのに有効な経路を見つけることができませんが、それでも、生成することができるくらい長い2番目のモードにただ一つの経路を転換することによって、1つの無効の経路(1つが存在すると仮定する)を返してください。 これは妥協点を提供します--ソフトウェアは、非常に速いのですが、まだ「どんな経路も見つけなかった」より特定の誤りをユーザに与える何かを返しています。
Third, it may be useful to not rule out any paths, but instead limit the number of paths that may be built given a particular input. Assuming the path-building module is designed to return the "best path first", the paths most likely to validate would be returned before this limit is reached. Once the limit is reached the module can stop building paths, providing a more rapid response to the caller than one which builds all possible paths.
3番目に、どんな経路も除外しないのが役に立つかもしれませんが、代わりに特定の入力を考えて、築き上げられるかもしれないパスの数を制限してください。 「最初に、経路を負かしてください」、たぶん有効にする経路。経路を造るモジュールを仮定するのが戻るように設計されている、この限界に達する前に返すでしょう。 限界にいったん達していると、モジュールは、経路を造るのを止めることができます、訪問者への、より急速な応答を提供してすべての可能な経路を造るものより。
Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information. A developer could choose the middle ground by opting to implement some optimizations as elimination rules and others as not. A developer could validate
結局、開発者は効率と情報提供の間のトレードオフを扱う方法を決心しています。 開発者は除去規則と他のものとしていくつかの最適化を実装するために選ばれる妥協点を選ぶことができました。 開発者は有効にすることができました。
Cooper, et al. Informational [Page 39] RFC 4158 Certification Path Building September 2005
クーパー、他 [39ページ]情報のRFC4158証明経路ビル2005年9月
certificate signatures, or even check revocation status while building the path, and then make decisions based upon the outcome of those checks as to whether to eliminate the certificate in question.
署名を証明するか、経路を造っている間、取消し状態をチェックさえしてください、そして、または次に、証明書を排除するかどうかに関してそれらのチェックの結果に基づいた決定を問題にしてください。
This document suggests the following approach:
このドキュメントは以下のアプローチを示します:
1) While building paths, eliminate any and all certificates that do
not satisfy all path validation requirements with the following
exceptions:
1) 経路を造っている間、すべての経路合法化要件を以下の例外に満たすというわけではないありとあらゆる証明書を排除してください:
a. Do not check revocation status if it requires a directory
lookup or network access
a。 ディレクトリルックアップかネットワークアクセスを必要とするなら、取消し状態をチェックしないでください。
b. Do not check digital signatures (see Section 8.1, General
Considerations for Building A Certification Path, for
additional considerations).
b。 デジタル署名をチェックしないでください(ビルA Certification Path、追加問題に関してセクション8.1、Considerations司令官を見てください)。
c. Do not check anything that cannot be checked as part of the
iterative process of traversing the tree.
c。 木を横断する繰り返し作業の一部としてチェックできないものは何もチェックしないでください。
d. Create a detailed log, if this feature is enabled.
d。 この特徴が可能にされるなら、詳細な航海日誌を作成してください。
e. If a path cannot be found, the path builder shifts to "mode 2"
and allows the building of a single bad path.
e。 経路がそうすることができないなら、備え付けてください、ビルダーが移行する経路、「モード2インチ、ただ一つの悪い経路のビルを許容する、」
i. Return the path with a failure indicator, as well as
error information detailing why the path is bad.
i。 経路がなぜ悪いかを詳しく述べるエラー情報と同様に失敗インディケータで経路を返してください。
2) If path building succeeds, validate the path in accordance with
[X.509] and [RFC3280] with the following recommendations:
2) 経路ビルが成功するなら、以下の推薦がある[X.509]と[RFC3280]に従って、経路を有効にしてください:
a. For a performance boost, do not re-check items already checked
by the path builder. (Note: if pre-populated paths are supplied
to the path-building system, the entire path has to be fully
re-validated.)
a。 パフォーマンスブーストのために、経路ビルダーによって既にチェックされた項目を再確認しないでください。 (注意: 前もって置いておかれた経路を経路システム構築に供給するなら、全体の経路を完全に再有効にしなければなりません。)
b. If the path validation failed, call the path builder again to
build another path.
b。 経路合法化が失敗したなら、経路ビルダーにもう一度電話をして、別の経路を造ってください。
i. Always store the error information and path from the
first iteration and return this to the user in the event
that no valid path is found. Since the path-building
software was designed to return the "best path first",
this path should be shown to the user.
i。 最初の繰り返しからエラー情報と経路をいつも保存してください、そして、どんな有効な経路も見つけられない場合、これをユーザに返してください。 以来経路を造るソフトウェアが戻るように設計された、この経路は「最初に、経路を負かしてください。」がユーザに示されるべきです。
As stated above, this document recommends that developers do not validate digital signatures or check revocation status as part of the path-building process. This recommendation is based on two
上に述べられているように、このドキュメントは、開発者が経路建築の過程の一部としてデジタル署名を有効にもしませんし、取消し状態をチェックもしないことを勧めます。 この推薦は2に基づいています。
Cooper, et al. Informational [Page 40] RFC 4158 Certification Path Building September 2005
クーパー、他 [40ページ]情報のRFC4158証明経路ビル2005年9月
assumptions about PKI and its usage. First, signatures in a working PKI are usually good. Since signature validation is costly in terms of processor time, it is better to delay signature checking until a complete path is found and then check the signatures on each certificate in the certification path starting with the trust anchor (see Section 8.1). Second, it is fairly uncommon in typical application environments to encounter a revoked certificate; therefore, most certificates validated will not be revoked. As a result, it is better to delay retrieving CRLs or other revocation status information until a complete path has been found. This reduces the probability of retrieving unneeded revocation status information while building paths.
PKIに関する仮定とその用法。 まず最初に、通常、働くPKIの署名は良いです。 署名合法化がプロセッサ時間で高価であるので、それは完全な経路が見つけられるまでチェックする署名を遅らせて、次に、信頼アンカーから始めて、証明経路の各証明書の上に署名をチェックするために、より良いです(セクション8.1を見てください)。 2番目に、取り消された証明書に遭遇するのは主用途環境でかなり珍しいです。 したがって、有効にされたほとんどの証明書は取り消されないでしょう。 その結果、完全な経路が見つけられるまでCRLsか他の取消し状態情報を検索するのを遅らせるほうがよいです。 これは経路を造っている間、不要な取消し状態情報を検索するという確率を減少させます。
3.3. Representing the Decision Tree
3.3. 意思決定の樹状図を表します。
There are a multitude of ways to implement certification path building and as many ways to represent the decision tree in memory.
証明経路ビルを実装する方法とメモリに意思決定の樹状図を表す同じくらい多くの方法の多数があります。
The method described below is an approach that will work well with the optimization methods listed later in this document. Although this approach is the best the authors of this document have implemented, it is by no means the only way to implement it. Developers should tailor this approach to their own requirements or may find that another approach suits their environment, programming language, or programming style.
以下で説明されたメソッドは最適化メソッドが後で本書では記載されている状態でうまくいくアプローチです。 このアプローチはこのドキュメントの作者が実装した中で最も良いものですが、それは決してそれを実装する唯一の方法ではありません。 開発者は、それら自身の要件へのこのアプローチを合わせるべきであるか、または別のアプローチが彼らの環境に合うのがわかるかもしれません、言語をプログラムするか、またはスタイルをプログラムして。
3.3.1. Node Representation for CA Entities
3.3.1. カリフォルニア実体のノード表現
A "node" in the certification graph is a collection of CA certificates with identical subject DNs. Minimally, for each node, in order to fully implement the optimizations to follow, the path- building module will need to be able to keep track of the following information:
証明グラフによる「ノード」は同じ対象のDNsとのカリフォルニア証明書の収集です。 各ノードに、最少量で、続くように最適化を完全に実装する経路ビルモジュールは、以下の情報の動向をおさえることができる必要があるでしょう:
1. Certificates contained in the node
1. ノードに含まれた証明書
2. Sorted order of the certificates
2. 証明書の分類された注文
3. "Current" certificate indicator
3. 「現在」の証明書インディケータ
4. The current policy set (It may be split into authority and user
constrained sets, if desired.)
4. 通貨政策はセットしました。(それは権威に分けられたかもしれなくて、望まれているなら、ユーザはセットを抑制しました。)
- It is suggested that encapsulating the policy set in an object
with logic for manipulating the set such as performing
intersections, mappings, etc., will simplify implementation.
- オブジェクトでセットを操作するための交差点、マッピングなどを実行などなどの論理で方針セットをカプセル化すると実装が簡略化することが提案されます。
Cooper, et al. Informational [Page 41] RFC 4158 Certification Path Building September 2005
クーパー、他 [41ページ]情報のRFC4158証明経路ビル2005年9月
5. Indicators (requireExplicitPolicy, inhibitPolicyMapping,
anyPolicyInhibit) and corresponding skipCert values
5. インディケータ(requireExplicitPolicy、inhibitPolicyMapping、anyPolicyInhibit)と対応するskipCert値
6. A method for indicating which certificates are eliminated or
removing them from the node.
6. どの証明書が排除されるかを示すか、またはノードからそれらを取り除くためのメソッド。
- If nodes are recreated from the cache on demand, it may be
simpler to remove eliminated certificates from the node.
- ノードがオンデマンドのキャッシュから再作成されるなら、ノードから排除された証明書を取り外すのは、より簡単であるかもしれません。
7. A "next" indicator that points to the next node in the current
path
7. 現在の経路に次のノードを示している「次」の指標
8. A "previous" indicator that points to the previous node in the
current path
8. 現在の経路に前のノードを示している「前」の指標
3.3.2. Using Nodes to Iterate Over All Paths
3.3.2. すべての経路にわたって繰り返すノードを使用します。
In simplest form, a node is created, the certificates are sorted, the next subject DN required is determined from the first certificate, and a new node is attached to the certification path via the next indicator (Number 7 above). This process continues until the path terminates. (Note: end entity certificates may not contain subject DNs as allowed by [RFC3280]. Since end entity certificates by definition do not issue certificates, this has no impact on the process.)
最も簡単なフォームでは、ノードは作成されます、そして、証明書は分類されます、そして、DNが必要とした次の対象は最初の証明書から決定しています、そして、次のインディケータ(上のNo.7)で新しいノードは証明経路に添付されます。 経路が終わるまで、このプロセスは持続します。 [RFC3280]によって許容されているように終わりの実体証明書は対象のDNsを含まないかもしれません。(注意: 定義上終わりの実体証明書が証明書を発行しないので、これはプロセスの上に影響力を全く持っていません。)
Keeping in mind that the following algorithm is designed to be implemented using recursion, consider the example in Figure 12 and assume that the only path in the diagram is valid for E is TA->A-> B->E:
以下のアルゴリズムが再帰を使用することで実装されて、図12の例を考えて、Eに、ダイヤグラムにおける唯一の経路が有効であると仮定するように設計されているのを覚えておくのは、TA>A>B>Eです:
If our path-building module is building a path in the forward direction for E, a node is first created for E. There are no certificates to sort because only one certificate exists, so all initial values are loaded into the node from E. For example, the policy set is extracted from the certificate and stored in the node.
私たちの経路を造るモジュールが経路をEに関する順方向に造ることであるなら、ノードは最初にE.Thereのために作成されているのが、1通の証明書だけが存在していて、したがって、すべての初期の値がE.Forの例からのノードにロードされて、方針セットが証明書から抽出されて、ノードに保存されるので分類しない証明書であるという全くことです。
Next, the issuer DN (B) is read from E, and new node is created for B containing both certificates issued to B -- B(A) and B(C). The sorting rules are applied to these two certificates and the sorting algorithm returns B(C);B(A). This sorted order is stored and the current indicator is set to B(C). Indicators are set and the policy sets are calculated to the extent possible with respect to B(C). The following diagram illustrates the current state with the current certificate indicated with a "*".
Bに発行された両方の証明書を含んでいて、新しいノードはBのために作成されます--次に、発行人DN(B)がEから読まれて、B(A)とB(C)。 ソーティングアルゴリズムはB(C)を返します; ソーティング規則はこれらの2通の証明書に適用されます、そして、B(A)。 この分類されたオーダーは保存されます、そして、現在のインディケータはB(C)に設定されます。 インディケータは設定されます、そして、方針セットは可能な範囲内でB(C)に関して計算されます。 以下のダイヤグラムは「*」で示された現在の証明書を現状に入れます。
Cooper, et al. Informational [Page 42] RFC 4158 Certification Path Building September 2005
クーパー、他 [42ページ]情報のRFC4158証明経路ビル2005年9月
+-------------+ +---------------+ | Node 1 | | Node 2 | | Subject: E |--->| Subject: B | | Issuers: B* | | Issuers: C*,A | +-------------+ +---------------+
+-------------+ +---------------+ | ノード1| | ノード2| | Subject: E|、-、--、>| Subject: B| | 発行人: B*| | 発行人: C*、A| +-------------+ +---------------+
Next, a node is created for C and all three certificates are added to it. The sorting algorithm happens to return the certificates sorted in the following order: C(TA);C(A);C(B)
次に、ノードはCのために作成されます、そして、すべての3通の証明書がそれに加えられます。 ソーティングアルゴリズムはたまたま以下のオーダーで分類された証明書を返します: C(バイバイ); C(A); C(B)
+-------------+ +---------------+ +------------------+ | Node 1 | | Node 2 | | Node 3 | | Subject: E |--->| Subject: B |--->| Subject: C | | Issuers: B | | Issuers: C*,A | | Issuers: TA*,A,B | +-------------+ +---------------+ +------------------+
+-------------+ +---------------+ +------------------+ | ノード1| | ノード2| | ノード3| | Subject: E|、-、--、>| Subject: B|、-、--、>| Subject: C| | 発行人: B| | 発行人: C*、A| | 発行人: バイバイ、*、A、B| +-------------+ +---------------+ +------------------+
Recognizing that the trust anchor has been found, the path (TA->C->B->E) is validated but fails. (Remember that the only valid path happens to be TA->A->B->E.) The path-building module now moves the current certificate indicator in node 3 to C(A), and adds the node for A.
信頼アンカーが見つけられたと認めて、経路(TA>C>B>E)は、有効にされますが、失敗します。 (唯一の有効な経路がたまたまTA>A>B>E.であることを覚えています) 経路を造るモジュールは、今ノード3の現在の証明書インディケータをC(A)に動かして、Aのためにノードを加えます。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA*,C,B |
+------------------+
+-------------+ +---------------+ +------------------+ | ノード1| | ノード2| | ノード3| | Subject: E|、-、--、>| Subject: B|、-、--、>| Subject: C| | 発行人: B| | 発行人: C*、A| | 発行人: バイバイ、*、B| +-------------+ +---------------+ +------------------+ | +に対して------------------+ | ノード4| | Subject: A| | 発行人: バイバイ、*、C、B| +------------------+
The path TA->A->C->B->E is validated and it fails. The path-building module now moves the current indicator in node 4 to A(C) and adds a node for C.
経路TA>A>C>B>Eは有効にされます、そして、それは失敗します。 経路を造るモジュールは、今、ノード4の現在のインディケータをA(C)に動かして、Cのためにノードを加えます。
Cooper, et al. Informational [Page 43] RFC 4158 Certification Path Building September 2005
クーパー、他 [43ページ]情報のRFC4158証明経路ビル2005年9月
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+ +------------------+
| Node 5 | | Node 4 |
| Subject: C |<---| Subject: A |
| Issuers: TA*,A,B | | Issuers: TA,C*,B |
+------------------+ +------------------+
+-------------+ +---------------+ +------------------+ | ノード1| | ノード2| | ノード3| | Subject: E|、-、--、>| Subject: B|、-、--、>| Subject: C| | 発行人: B| | 発行人: C*、A| | 発行人: バイバイ、*、B| +-------------+ +---------------+ +------------------+ | +に対して------------------+ +------------------+ | ノード5| | ノード4| | Subject: C| <、-、--、| Subject: A| | 発行人: バイバイ、*、A、B| | 発行人: バイバイ、C*、B| +------------------+ +------------------+
At this juncture, the decision of whether to allow repetition of name and key comes to the forefront. If the certification path-building module will NOT allow repetition of name and key, there are no certificates in node 5 that can be used. (C and the corresponding public key is already in the path at node 3.) At this point, node 5 is removed from the current path and the current certificate indicator on node 4 is moved to A(B).
この際、名前とキーの反復を許すかどうかに関する決定は世間の注目を浴びます。 経路を造る証明モジュールが名前とキーの反復を許さないなら、使用できるノード5には証明書が全くありません。 (Cと対応する公開鍵がノード3に経路に既にあります。) ここに、ノード5は現在の経路から取り除かれます、そして、ノード4の上の現在の証明書インディケータはA(B)に動かされます。
If instead, the module is only disallowing repetition of certificates, C(A) is eliminated from node 5 since it is in use in node 3, and path building continues by first validating TA->C->A-> C->B->E, and then continuing to try to build paths through C(B). After this also fails to provide a valid path, node 5 is removed from the current path and the current certificate indicator on node 4 is moved to A(B).
モジュールが代わりに証明書の複写を禁じだけであるいことであるなら、それがノード3で使用中であるので、C(A)はノード5から排除されます、そして、最初にTA>C>A>C>B>Eを有効にして、次に、C(B)を通して経路を造ろうとし続けていることによって、経路ビルは続きます。 これが有効な経路を提供しなかった後にも、ノード5は現在の経路から取り除かれます、そして、ノード4の上の現在の証明書インディケータはA(B)に動かされます。
+-------------+ +---------------+ +------------------+
| Node 1 | | Node 2 | | Node 3 |
| Subject: E |--->| Subject: B |--->| Subject: C |
| Issuers: B | | Issuers: C*,A | | Issuers: TA,A*,B |
+-------------+ +---------------+ +------------------+
|
v
+------------------+
| Node 4 |
| Subject: A |
| Issuers: TA,C,B* |
+------------------+
+-------------+ +---------------+ +------------------+ | ノード1| | ノード2| | ノード3| | Subject: E|、-、--、>| Subject: B|、-、--、>| Subject: C| | 発行人: B| | 発行人: C*、A| | 発行人: バイバイ、*、B| +-------------+ +---------------+ +------------------+ | +に対して------------------+ | ノード4| | Subject: A| | 発行人: バイバイ、C、B*| +------------------+
Now a new node 5 is created for B. Just as with the prior node 5, if not repeating name and key, B also offers no certificates that can be used (B and B's public key is in use in node 2) so the new node 5 is also removed from the path. At this point all certificates in node 4 have now been tried, so node 4 is removed from the path, and the current indicator on node 3 is moved to C(B).
今、新しいノード5はB.Justのために繰り返している先のノード5や、名前とキーのように作成されます、また、Bは使用できない証明書を全く提供します(Bとビーズ公開鍵はノード2で使用中です)、したがって、また、新しいノード5は経路から取り除かれます。 ここに、ノード4のすべての証明書が今試されました、そして、したがって、ノード4は経路から取り除かれます、そして、ノード3の上の現在のインディケータはC(B)に動かされます。
Cooper, et al. Informational [Page 44] RFC 4158 Certification Path Building September 2005
クーパー、他 [44ページ]情報のRFC4158証明経路ビル2005年9月
Also as above, if allowing repetition of name and key, B(C) is removed from the new node 5 (B(C) is already in use in node 3) and paths attempted through the remaining certificate B(A). After this fails, it will lead back to removing node 5 from the path. At this point all certificates in node 4 have now been tried, so node 4 is removed from the path, and the current indicator on node 3 is moved to C(B).
同じくらい上にも、名前とキーの反復を許すなら、B(C)は新しいノード5から取り外されました、そして、(B(C)はノード3で既に使用中です)経路は残っている証明書を通してB(A)を試みました。 これが失敗した後に、それは、経路からノード5を取り除くのに通じるでしょう。 ここに、ノード4のすべての証明書が今試されました、そして、したがって、ノード4は経路から取り除かれます、そして、ノード3の上の現在のインディケータはC(B)に動かされます。
This process continues until all certificates in node 1 (if there happened to be more than one) have been tried, or until a valid path has been found. Once the process ends and in the event no valid path was found, it may be concluded that no path can be found from E to TA.
ノード1(1つ以上がたまたまあったなら)のすべての証明書が試されたか、または有効な経路が見つけられるまで、このプロセスは持続します。 一度、プロセスは終わります、そして、どんな有効な経路も見つけられなかったイベントでは、EからTAまで経路を全く見つけることができないと結論づけられるかもしれません。
3.4. Implementing Path-Building Optimization
3.4. 経路を造る最適化を実装します。
The following section describes methods that may be used for optimizing the certification path-building process by sorting certificates. Optimization as described earlier seeks to prioritize a list of certificates, effectively prioritizing (weighting) branches of the graph/tree. The optimization methods can be used to assign a cumulative score to each certificate. The process of scoring the certificates amounts to testing each certificate against the optimization methods a developer chooses to implement, and then adding the score for each test to a cumulative score for each certificate. After this is completed for each certificate at a given branch point in the builder's decision tree, the certificates can be sorted so that the highest scoring certificate is selected first, the second highest is selected second, etc.
以下のセクションはソーティング証明書で証明経路建築の過程を最適化するのに使用されるかもしれないメソッドを説明します。 事実上、グラフ/木の枝を最優先させて(重みを加えます)、より早く説明される最適化は証明書のリストを最優先させようとします。 累積しているスコアを各証明書に割り当てるのに最適化メソッドを使用できます。 証明書を得るプロセスは開発者が実装するのを選ぶ最適化メソッドに対して各証明書をテストして、次に、各テストのために各証明書のための累積しているスコアにスコアを加えるのに等しいです。 最も高い得点証明書はこれが各証明書のためにビルダーの意思決定の樹状図で与えられたブランチポイントで完成した後に、証明書を分類できるので、最初に選択されて、2番目に高いのは、選択された2番目ですなど。
For example, suppose the path builder has only these two simple sorting methods:
例えば、経路ビルダーにはこれらの2つの簡単なソーティングメソッドしかないと仮定してください:
1) If the certificate has a subject key ID, +5 to score. 2) If the certificate has an authority key ID, +10 to score.
1) 証明書に対象の主要なIDがあるなら、得点する+5です。 2) 証明書に権威の主要なIDがあるなら、得点する+10です。
And it then examined three certificates:
そして、次に、3通の証明書を調べました:
1) Issued by CA 1; has authority key ID; score is 10.
2) Issued by CA 2; has subject key ID; score is 5.
3) Issued by CA 1; has subject key ID and authority key ID; score is
15.
1) カリフォルニア1によって発行されます。 権威の主要なIDを持っています。 スコアは10です。 2) カリフォルニア2によって発行されます。 対象の主要なIDを持っています。 スコアは5です。 3) カリフォルニア1によって発行されます。 対象の主要なIDと権威の主要なIDを持っています。 スコアは15です。
The three certificates are sorted in descending order starting with the highest score: 3, 1, and 2. The path-building software should first try building the path through certificate 3. Failing that, it should try certificate 1. Lastly, it should try building a path through certificate 2.
降順に最も高いスコアから始まって、3通の証明書が分類されます: 3、1、および2。 経路を造るソフトウェアは最初に、証明書3を通して経路を造ってみるはずです。 それに失敗して、それは証明書1を試すべきです。 最後に、それは証明書2を通して経路を造ってみるべきです。
Cooper, et al. Informational [Page 45] RFC 4158 Certification Path Building September 2005
クーパー、他 [45ページ]情報のRFC4158証明経路ビル2005年9月
The following optimization methods specify tests developers may choose to perform, but does not suggest scores for any of the methods. Rather, developers should evaluate each method with respect to the environment in which the application will operate, and assign weights to each accordingly in the path-building software. Additionally, many of the optimization methods are not binary in nature. Some are tri-valued, and some may be well suited to sliding or exponential scales. Ultimately, the implementer decides the relative merits of each optimization with respect to his or her own software or infrastructure.
メソッドのいずれのためにもスコアを示さないのを除いて、以下の最適化メソッドは開発者が実行するのを選ぶかもしれないテストを指定します。 むしろ、開発者はアプリケーションが経路を造るソフトウェアでそれに従って、重りをそれぞれに操作して、割り当てる環境に関して各メソッドを評価するべきです。 さらに、最適化メソッドの多くが現実に2進ではありません。 或るものは3評価されています、そして、或るものは滑りか指数のスケールによく適するかもしれません。 結局、implementerはその人の自身のソフトウェアかインフラストラクチャに関してそれぞれの最適化の優劣について決めます。
Over and above the scores for each method, many methods can be used to eliminate branches during the tree traversal rather than simply scoring and weighting them. All cases where certificates could be eliminated based upon an optimization method are noted with the method descriptions.
各メソッドのためのスコアよりスコアの上と上では、木の縦断の間、単にそれらを得て、重みを加えるよりむしろブランチを排除するのに多くのメソッドを使用できます。 最適化メソッドに基づいた状態で証明書を排除できたすべてのケースがメソッド記述で注意されます。
Many of the sorting methods described below are based upon what has been perceived by the authors as common in PKIs. Many of the methods are aimed at making path building for the common PKI fast, but there are cases where most any sorting method could lead to inefficient path building. The desired behavior is that although one method may lead the algorithm in the wrong direction for a given situation or configuration, the remaining methods will overcome the errant method(s) and send the path traversal down the correct branch of the tree more often than not. This certainly will not be true for every environment and configuration, and these methods may need to be tweaked for further optimization in the application's target operating environment.
以下で説明されたソーティングメソッドの多くがPKIsで一般的であるとして作者によって知覚されたことに基づいています。 メソッドの多くはメソッドが効率の悪い経路ビルに導くことができたどんなソーティングも断食しますが、ある一般的なPKIのために建てるのがだいたいであるところにケースに入れる経路にするのを目的とされます。 望まれた行動は残っているメソッドがしばしば1つのメソッドが与えられた状況か構成のためにアルゴリズムを間違った方向に導くかもしれませんが、誤ったメソッドを襲って、木の正しい枝の下側に経路縦断を送るということです。 確かに、これはあらゆる環境と構成に本当になるというわけではないでしょう、そして、これらのメソッドはアプリケーションの目標操作環境におけるさらなる最適化のためにひねられる必要があるかもしれません。
As a final note, the list contained in this document is not intended to be exhaustive. A developer may desire to define additional sorting methods if the operating environment dictates the need.
最後通達として、本書では含まれたリストが徹底的であることを意図しません。 操作環境が必要性を決めるなら、開発者は、追加ソーティングメソッドを定義することを望むかもしれません。
3.5. Selected Methods for Sorting Certificates
3.5. ソーティング証明書のための選択されたメソッド
The reader should draw no specific conclusions as to the relative merits or scores for each of the following methods based upon the order in which they appear. The relative merit of any sorting criteria is completely dependent on the specifics of the operating environment. For most any method, an example can be created to demonstrate the method is effective and a counter-example could be designed to demonstrate that it is ineffective.
読者はそれらが現れるオーダーに基づくそれぞれの以下のメソッドのために優劣かスコアに関してどんな特定の結論にも達するべきではありません。 どんなソーティング評価基準の相対的な長所も操作環境の詳細に完全に依存しています。 大部分に関して、どんなメソッド、例も作成できました。メソッドを示すのは有効です、そして、それが効力がないのを示すのを反証は設計できました。
Each sorting method is independent and may (or may not) be used to assign additional scores to each certificate tested. The implementer decides which methods to use and what weights to assign them. As noted previously, this list is also not exhaustive.
または、そして、それぞれのソーティングメソッドが独立している、()、使用されるかもしれなくて、テストされた各証明書に追加スコアを割り当ててください。 implementerはどのメソッドを使用するか、そして、どんな重りにそれらを割り当てるかを決めます。 また、以前に注意されるように、このリストも徹底的ではありません。
Cooper, et al. Informational [Page 46] RFC 4158 Certification Path Building September 2005
クーパー、他 [46ページ]情報のRFC4158証明経路ビル2005年9月
In addition, name chaining (meaning the subject name of the issuer certificate matches the issuer name of the issued certificate) is not addressed as a sorting method since adherence to this is required in order to build the decision tree to which these methods will be applied. Also, unaddressed in the sorting methods is the prevention of repeating certificates. Path builders should handle name chaining and certificate repetition irrespective of the optimization approach.
さらに、これへの固守がこれらのメソッドが適用される意思決定の樹状図を建てるのに必要であるので、名前推論(発行人証明書の対象の名前が発行された証明書の発行人名に合っていることを意味する)はソーティングメソッドとして扱われません。 また、ソーティングメソッドで宛名がないのは、繰り返している証明書の防止です。 経路ビルダーは最適化アプローチの如何にかかわらずハンドルネーム推論と証明書反復がそうするべきです。
Each sorting method description specifies whether the method may be used to eliminate certificates, the number of possible numeric values (sorting weights) for the method, components from Section 2.6 that are required for implementing the method, forward and reverse methods descriptions, and finally a justification for inclusion of the method.
それぞれのソーティングメソッド記述は、メソッドが証明書、メソッドのための可能な数値(ソーティング重り)の数、メソッドを実装するのに必要であるセクション2.6からのコンポーネント、前進の、そして、逆のメソッド記述、およびメソッドの包含のための最終的に正当化を排除するのに使用されるかもしれないかどうか指定します。
With regard to elimination of certificates, it is important to understand that certificates are eliminated only at a given decision point for many methods. For example, the path built up to certificate X may be invalidated due to name constraints by the addition of certificate Y. At this decision point only, Y could be eliminated from further consideration. At some future decision point, while building this same path, the addition of Y may not invalidate the path.
証明書の除去に関して、証明書が多くのメソッドのために与えられた決定ポイントだけで排除されるのを理解しているのは重要です。 さらなる考慮から例えば、証明書Y.Atの追加で規制を命名する無効にされた支払われるべきものがこの決定ポイントであったかもしれないなら証明書Xまで造られた経路だけ、Yを排除できました。 何らかの将来の決定ポイントでは、Yの追加はこの同じ経路を造っている間、経路を無効にしないかもしれません。
For some other sorting methods, certificates could be eliminated from the process entirely. For example, certificates with unsupported signature algorithms could not be included in any path and validated. Although the path builder may certainly be designed to operate in this fashion, it is sufficient to always discard certificates only for a given decision point regardless of cause.
ある他のソーティングメソッドにおいて、プロセスから証明書を完全に排除できました。 例えば、サポートされない署名アルゴリズムがある証明書をどんな経路にも含んで、有効にすることができませんでした。 経路ビルダーはこんなやり方で作動するように確かに設計されるかもしれませんが、原因にかかわらずいつも与えられた決定ポイントだけ証明書を捨てるのは十分です。
3.5.1. basicConstraints Is Present and cA Equals True
3.5.1. basicConstraintsは本当にプレゼントとcA同輩です。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: Certificates with basicConstraints present and cA=TRUE, or those designated as CA certificates out-of-band have priority. Certificates without basicConstraints, with basicConstraints and cA=FALSE, or those that are not designated as CA certificates out-of-band may be eliminated or have zero priority.
メソッドを進めてください: basicConstraintsが存在している証明書とcA=TRUE、またはバンドで出ているカリフォルニア証明書には優先権があるので指定されたもの。 カリフォルニア証明書としてバンドの外で指定されないで、排除されるかもしれないということであるか優先権を全く持っていないbasicConstraintsとcA=FALSEか、ものがあるbasicConstraintsのない証明書。
Reverse Method: Same as forward except with regard to end entity certificates at the terminus of the path.
メソッドを逆にしてください: 経路の終点の終わりの実体証明書を除いて、フォワードと同じです。
Justification: According to [RFC3280], basicConstraints is required to be present with cA=TRUE in all CA certificates, or must be
正当化: [RFC3280]に従って、basicConstraintsはすべてのカリフォルニア証明書のcA=TRUEについて存在しているのが必要であるに違いない、またはあるに違いありません。
Cooper, et al. Informational [Page 47] RFC 4158 Certification Path Building September 2005
クーパー、他 [47ページ]情報のRFC4158証明経路ビル2005年9月
verified via an out-of-band mechanism. A valid path cannot be built if this condition is not met.
バンドで出ているメカニズムで、確かめられます。 この条件が満たされないなら、有効な経路を造ることができません。
3.5.2. Recognized Signature Algorithms
3.5.2. 認識された署名アルゴリズム
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: Certificates containing recognized signature and public key algorithms [PKIXALGS] have priority.
メソッドを進めてください: 認識された署名を含む証明書と公開鍵アルゴリズム[PKIXALGS]には、優先権があります。
Reverse Method: Same as forward.
メソッドを逆にしてください: フォワードと同じです。
Justification: If the path-building software is not capable of processing the signatures associated with the certificate, the certification path cannot be validated.
正当化: 経路を造るソフトウェアは署名が証明書に関連づけた処理ができないなら、証明経路を有効にすることができません。
3.5.3. keyUsage Is Correct
3.5.3. keyUsageは正しいです。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: If keyUsage is present, certificates with keyCertSign set have 100% priority. If keyUsage is present and keyCertSign is not set, the certificate may be eliminated or have zero priority. All others have zero priority.
メソッドを進めてください: keyUsageが存在しているなら、keyCertSignがセットしたことでの証明書には、100%の優先権があります。 keyUsageが存在していて、keyCertSignが用意ができていないなら、証明書には、排除されないか、優先権が全くないかもしれません。 すべての他のものには、優先権が全くありません。
Reverse Method: Same as forward except with regard to end entity certificates at the terminus of the path.
メソッドを逆にしてください: 経路の終点の終わりの実体証明書を除いて、フォワードと同じです。
Justification: A valid certification path cannot be built through a CA certificate with inappropriate keyUsage. Note that digitalSignature is not required to be set in a CA certificate.
正当化: 不適当なkeyUsageと共にカリフォルニア証明書を通して有効な証明経路を造ることができません。 カリフォルニア証明書にdigitalSignatureが設定される必要はないことに注意してください。
3.5.4. Time (T) Falls within the Certificate Validity
3.5.4. 時間(T)は証明書の正当性の中に下がります。
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: Certificates that contain the required time (T) within their validity period have 100% priority. Otherwise, the certificate is eliminated or has priority zero.
メソッドを進めてください: 彼らの有効期間中に必要な時間(T)を含む証明書が100%の優先権を持っています。 さもなければ、証明書には、排除されるか、または優先権ゼロがあります。
Reverse Method: Same as forward.
メソッドを逆にしてください: フォワードと同じです。
Cooper, et al. Informational [Page 48] RFC 4158 Certification Path Building September 2005
クーパー、他 [48ページ]情報のRFC4158証明経路ビル2005年9月
Justification: A valid certification path cannot be built if T falls outside of the certificate validity period.
正当化: Tが証明書有効期間の外に落下するなら、有効な証明経路を造ることができません。
NOTE: Special care should be taken to return a meaningful error to the caller, especially in the event the target certificate does not meet this criterion, if this sorting method is used for elimination. (e.g., the certificate is expired or is not yet valid).
以下に注意してください。 特別な注意は重要な誤りを訪問者に返すために払われるべきであり、特にイベントでは、目標証明書はこの評価基準を満たしません、このソーティングメソッドが除去に使用されるなら。 (例えば、証明書は、満期である、またはまだ有効ではありません。)
3.5.5. Certificate Was Previously Validated
3.5.5. 証明書は以前に、有効にされました。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 証明経路キャッシュ
Forward Method: A certificate that is present in the certification path cache has priority.
メソッドを進めてください: 証明経路キャッシュで存在している証明書には、優先権があります。
Reverse Method: Does not apply. (The validity of a certificate vs. unknown validity does not infer anything about the correct direction in the decision tree. In other words, knowing the validity of a CA certificate does not indicate that the target is more likely found through that path than another.)
メソッドを逆にしてください: 適用しません。 (証明書対未知の正当性の正当性は意思決定の樹状図の正しい方向に関して何も推論しません。 言い換えれば、カリフォルニア証明書の正当性を知っているのは、目標が別のものよりその経路を通しておそらく見つけられるのを示しません。)
Justification: Certificates in the path cache have been validated previously. Assuming the initial constraints have not changed, it is highly likely that the path from that certificate to a trust anchor is still valid. (Changes to the initial constraints may cause a certificate previously considered valid to no longer be considered valid.)
正当化: 経路キャッシュにおける証明書は以前に、有効にされました。 初期の規制が変化していないと仮定して、その証明書から信頼アンカーまでの経路がまだ有効であることは、非常にありそうです。 (初期の規制への変化で、もう有効であると以前に有効であると考えられた証明書を考えないかもしれません。)
Note: It is important that items in the path cache have appropriate life times. For example, it could be inappropriate to cache a relationship beyond the period the related CRL will be trusted by the application. It is also critical to consider certificates and CRLs farther up the path when setting cache lifetimes. For example, if the issuer certificate expires in ten days, but the issued certificate is valid for 20 days, caching the relationship beyond 10 days would be inappropriate.
以下に注意してください。 経路キャッシュにおける項目が適切な寿命時を過すのは、重要です。 例えば、関連するCRLがアプリケーションで信じられる時代に関係をキャッシュするのは不適当であるかもしれません。 また、証明書を考えるのも重要であり、セットするとき、経路により遠いCRLsは生涯をキャッシュします。 例えば、発行人証明書が10日間後に期限が切れますが、発行された証明書が20日間有効であるなら、10日間に関係をキャッシュするのは不適当でしょう。
3.5.6. Previously Verified Signatures
3.5.6. 以前に確かめられた署名
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: Path Cache
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: 経路キャッシュ
Forward Method: If a previously verified relationship exists in the path cache between the subject certificate and a public key present in one or more issuer certificates, all the certificates containing
メソッドを進めてください: 以前に確かめられた関係が対象の証明書と公開鍵の間に経路キャッシュで存在するなら、1つ以上の発行人で証明書を提示してください、すべての証明書が含んでいて
Cooper, et al. Informational [Page 49] RFC 4158 Certification Path Building September 2005
クーパー、他 [49ページ]情報のRFC4158証明経路ビル2005年9月
said public key have higher priority. Other certificates may be eliminated or set to zero priority.
前述の公開鍵には、より高い優先度があります。 他の証明書は、優先権のゼロを合わせるように排除されるか、または設定されるかもしれません。
Reverse Method: If known bad signature relationships exist between certificates, these relationships can be used to eliminate potential certificates from the decision tree. Nothing can be concluded about the likelihood of finding a given target certificate down one branch versus another using known good signature relationships.
メソッドを逆にしてください: 知られている悪い署名関係が証明書の間に存在しているなら、意思決定の樹状図からの潜在的証明書を排除するのにこれらの関係を使用できます。 知られている良い署名関係を使用することで1つのブランチに対下側別のもの与えられた目標証明書を見つけるという見込みに関して何も結論づけることができません。
Justification: If the public key in a certificate (A) was previously used to verify a signature on a second certificate (B), any and all certificates containing the same key as (A) may be used to verify the signature on (B). Likewise, any certificates that do not contain the same key as (A) cannot be used to verify the signature on (B). This forward direction method is especially strong for multiply cross- certified CAs after a key rollover has occurred.
正当化: 証明書(A)の公開鍵が以前2番目の証明書(B)の上に署名について確かめるのにおいて使用されていたなら、(A)と同じキーを含むありとあらゆる証明書が、(B)で署名について確かめるのに使用されるかもしれません。 同様に、(B)で署名について確かめるのに(A)と同じキーを含まないどんな証明書も使用できません。 主要なロールオーバーが起こった後にメソッドが特に強いこの順方向は十字の公認されたCAsを掛けます。
3.5.7. Path Length Constraints
3.5.7. 経路長さの規制
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: Certificates with basic constraints present and containing a path length constraint that would invalidate the current path (the current length is known since the software is building from the target certificate) may be eliminated or set to zero priority. Otherwise, the priority is 100%.
メソッドを進めてください: 現在の経路(ソフトウェアが目標証明書から建てられているので、現在長は知られている)を無効にする現在の基本的な規制と経路長さの規制を含む証明書は、優先権のゼロを合わせるように排除されるか、または設定されるかもしれません。 さもなければ、優先権は100%です。
Reverse Method: This method may be applied in reverse. To apply it, the builder keeps a current path length constraint variable and then sets zero priority for (or eliminates) certificates that would violate the constraint.
メソッドを逆にしてください: このメソッドは逆であり適用されるかもしれません。 ビルダーは、それを適用するために、規制に違反する(または、排泄します)証明書に、現在の経路長さの規制を可変に保って、次に、優先権を全く設定しません。
Justification: A valid path cannot be built if the path length constraint has been violated.
正当化: 経路長さの規制に違反してあるなら、有効な経路を造ることができません。
3.5.8. Name Constraints
3.5.8. 名前規制
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: Certificates that contain nameConstraints that would be violated by certificates already in the path to this point are given zero priority or eliminated.
メソッドを進めてください: 既に経路の証明書によって違反されるnameConstraintsを含む証明書を、この位まで優先を全く与えないか、または排除します。
Cooper, et al. Informational [Page 50] RFC 4158 Certification Path Building September 2005
クーパー、他 [50ページ]情報のRFC4158証明経路ビル2005年9月
Reverse Method: Certificates that will allow successful processing of any name constraints present in the path to this point are given higher priority.
メソッドを逆にしてください: 経路の現在のどんな名前規制のうまくいっている処理も許す証明書がこの位まで優先しますより高い。
Justification: A valid path cannot be built if name constraints are violated.
正当化: 名前規制が違反されるなら、有効な経路を造ることができません。
3.5.9. Certificate Is Not Revoked
3.5.9. 証明書は取り消されません。
May be used to eliminate certificates: No Number of possible values: Three Components required: CRL Cache
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 3Componentsが必要です: CRLキャッシュ
Forward Method: If a current CRL for a certificate is present in the CRL cache, and the certificate serial number is not on the CRL, the certificate has priority. If the certificate serial number is present on the CRL, it has zero priority. If an (acceptably fresh) OCSP response is available for a certificate, and identifies the certificate as valid, the certificate has priority. If an OCSP response is available for a certificate, and identifies the certificate as invalid, the certificate has zero priority.
メソッドを進めてください: 証明書のための現在のCRLがCRLキャッシュで存在していて、証明書通し番号がCRLにないなら、証明書には、優先権があります。 証明書通し番号がCRLに存在しているなら、それには、優先権が全くありません。 (許容できて新鮮)のOCSP応答が、証明書に利用可能であり、証明書が有効であると認識するなら、証明書には、優先権があります。 OCSP応答が、証明書に利用可能であり、証明書が無効であると認識するなら、証明書には、優先権が全くありません。
Reverse Method: Same as Forward.
メソッドを逆にしてください: フォワードと同じです。
Alternately, the certificate may be eliminated if the CRL or OCSP response is verified. That is, fully verify the CRL or OCSP response signature and relationship to the certificate in question in accordance with [RFC3280]. While this is viable, the signature verification required makes it less attractive as an elimination method. It is suggested that this method only be used for sorting and that CRLs and OCSP responses are validated post path building.
交互に、CRLかOCSP応答が確かめられるなら、証明書は排除されるかもしれません。 すなわち、[RFC3280]に従って問題の証明書とのCRLかOCSP応答署名と関係について完全に確かめてください。 これは実行可能ですが、検証が必要とした署名で、それは消去法として、より魅力的でなくなります。 このメソッドがソーティングに使用されるだけであり、CRLsとOCSP応答が有効にされたポスト経路ビルであると示唆されます。
Justification: Certificates known to be not revoked can be considered more likely to be valid than certificates for which the revocation status is unknown. This is further justified if CRL or OCSP response validation is performed post path validation - CRLs or OCSP responses are only retrieved when complete paths are found.
正当化: 取消し状態が未知である証明書より有効であることがありそうであると取り消されないのが知られている証明書を考えることができます。 これはCRLかOCSP応答合法化が実行されたポスト経路合法化であるならさらに正当化されます--完全な経路が見つけられるときだけ、CRLsかOCSP応答が検索されます。
NOTE: Special care should be taken to allow meaningful errors to propagate to the caller, especially in cases where the target certificate is revoked. If a path builder eliminates certificates using CRLs or OCSP responses, some status information should be preserved so that a meaningful error may be returned in the event no path is found.
以下に注意してください。 特別な注意は重要な誤りが訪問者に伝播されるのを許容するために払われるべきです、特に目標証明書が取り消される場合で。 経路ビルダーがCRLsかOCSP応答を使用することで証明書を排除するなら、何らかの状態情報が保存されるべきであるので、経路が全く見つけられないイベントで重要な誤りを返すことができます。
Cooper, et al. Informational [Page 51] RFC 4158 Certification Path Building September 2005
クーパー、他 [51ページ]情報のRFC4158証明経路ビル2005年9月
3.5.10. Issuer Found in the Path Cache
3.5.10. 経路キャッシュで見つけられた発行人
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 証明経路キャッシュ
Forward Method: A certificate whose issuer has an entry (or entries) in the path cache has priority.
メソッドを進めてください: 発行人には経路キャッシュにおけるエントリー(または、エントリー)がある証明書は優先権を持っています。
Reverse Method: Does not apply.
メソッドを逆にしてください: 適用しません。
Justification: Since the path cache only contains entries for certificates that were previously validated back to a trust anchor, it is more likely than not that the same or a new path may be built from that point to the (or one of the) trust anchor(s). For certificates whose issuers are not found in the path cache, nothing can be concluded.
正当化: 経路キャッシュが以前に信頼アンカーに有効にして戻された証明書のためのエントリーを含むだけであるのでそれがそのポイントがその同じ経路かどんな新しい経路にも造られないかもしれないよりおそらく多い、(1、)、アンカーを信じてください。 発行人が経路キャッシュで見つけられない証明書に関しては、何も結論づけることができません。
NOTE: This method is not the same as the method named "Certificate Was Previously Validated". It is possible for this sorting method to evaluate to true while the other method could evaluate to zero.
以下に注意してください。 このメソッドは「証明書は以前に、有効にされた」というメソッドと同じではありません。 それは、もう片方のメソッドがゼロに評価できましたが、本当に評価するこのソーティングメソッドに、可能です。
3.5.11. Issuer Found in the Application Protocol
3.5.11. アプリケーション・プロトコルで見つけられた発行人
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certification Path Cache
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 証明経路キャッシュ
Forward Method: If the issuer of a certificate sent by the target through the application protocol (SSL/TLS, S/MIME, etc.), matches the signer of the certificate you are looking at, then that certificate has priority.
メソッドを進めてください: その証明書には、証明書の発行人がアプリケーション・プロトコルを通って目標で発信したなら、(SSL/TLS、S/MIMEなど)はあなたが見ている証明書について署名者に合って、次に、優先権があります。
Reverse Method: If the subject of a certificate matches the issuer of a certificate sent by the target through the application protocol (SSL/TLS, S/MIME, etc.), then that certificate has priority.
メソッドを逆にしてください: 証明書の対象がアプリケーション・プロトコル(SSL/TLS、S/MIMEなど)を通して目標によって送られた証明書の発行人に合っているなら、その証明書には、優先権があります。
Justification: The application protocol may contain certificates that the sender considers valuable to certification path building, and are more likely to lead to a path to the target certificate.
正当化: アプリケーション・プロトコルは、送付者が証明経路ビルに貴重であると考える証明書を含むかもしれなくて、目標証明書への経路により通じそうです。
3.5.12. Matching Key Identifiers (KIDs)
3.5.12. 合っている主要な識別子(子供)
May be used to eliminate certificates: No Number of possible values: Three Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 3Componentsが必要です: なし
Forward Method: Certificates whose subject key identifier (SKID)
メソッドを進めてください: 証明書は対象の主要な識別子です。(滑り止め)
Cooper, et al. Informational [Page 52] RFC 4158 Certification Path Building September 2005
クーパー、他 [52ページ]情報のRFC4158証明経路ビル2005年9月
matches the current certificate's authority key identifier (AKID) have highest priority. Certificates without a SKID have medium priority. Certificates whose SKID does not match the current certificate's AKID (if both are present) have zero priority. If the current certificate expresses the issuer name and serial number in the AKID, certificates that match both these identifiers have highest priority. Certificates that match only the issuer name in the AKID have medium priority.
マッチ現在の証明書の権威の主要な識別子(AKID)には、最優先があります。 SKIDのない証明書には、中型の優先権があります。 SKIDが現在の証明書のAKID(両方が存在しているなら)に合っていない証明書は優先権を全く持っていません。 現在の証明書がAKIDの発行人名と通し番号を表すなら、これらの識別子の両方に合っている証明書が最優先を持っています。 AKIDの発行人名だけに合っている証明書が中型の優先権を持っています。
Reverse Method: Certificates whose AKID matches the current certificate's SKID have highest priority. Certificates without an AKID have medium priority. Certificates whose AKID does not match the current certificate's SKID (if both are present) have zero priority. If the certificate expresses the issuer name and serial number in the AKID, certificates that match both these identifiers in the current certificate have highest priority. Certificates that match only the issuer name in the AKID have medium priority.
メソッドを逆にしてください: AKIDが現在の証明書のSKIDに合っている証明書は最優先を持っています。 AKIDのない証明書には、中型の優先権があります。 AKIDが現在の証明書のSKID(両方が存在しているなら)に合っていない証明書は優先権を全く持っていません。 証明書がAKIDの発行人名と通し番号を表すなら、現在の証明書のこれらの識別子の両方に合っている証明書が最優先を持っています。 AKIDの発行人名だけに合っている証明書が中型の優先権を持っています。
Justification: Key Identifier (KID) matching is a very useful mechanism for guiding path building (that is their purpose in the certificate) and should therefore be assigned a heavy weight.
正当化: 主要なIdentifier(KID)マッチングは誘導している経路ビル(それは証明書のそれらの目的である)への非常に役に立つメカニズムであり、したがって、重い重りを割り当てられるべきです。
NOTE: Although required to be present by [RFC3280], it is extremely important that KIDs be used only as sorting criteria or as hints during certification path building. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion.
以下に注意してください。 [RFC3280]で存在しているのが必要ですが、KIDsが評価基準を分類することとして、または、だけ証明経路ビルの間のヒントとして使用されるのは、非常に重要です。 KIDsを証明経路合法化の間、合うのが必要でなく、証明書を排除するのに使用できません。 これはKIDsが同じファッションで計算されないかもしれないところのドメインとマルチベンダ実装の向こう側に共同利用するための決定的な重要性のものです。
3.5.13. Policy Processing
3.5.13. 方針処理
May be used to eliminate certificates: Yes Number of possible values: Three Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 3Componentsが必要です: なし
Forward Method: Certificates that satisfy Forward Policy Chaining have priority. (See Section 4 entitled "Forward Policy Chaining" for details.) If the caller provided an initial-policy-set and did not set the initial-require-explicit flag, the weight of this sorting method should be increased. If the initial-require-explicit-policy flag was set by the caller or by a certificate, certificates may be eliminated.
メソッドを進めてください: Forward Policy Chainingを満たす証明書が優先権を持っています。 (セクション4が詳細のための「前向きな方針推論」の権利を与えられるのを見てください。) 訪問者が初期の方針セットを提供して、セットしなかった、イニシャルが必要である、明白である、旗、このソーティングメソッドの重さは増強されるべきです。 旗がイニシャルが明白な方針が必要な訪問者か証明書によって設定されたなら、証明書は排除されるかもしれません。
Reverse Method: Certificates that contain policies/policy mappings that will allow successful policy processing of the path to this point have priority. If the caller provided an initial-policy-set and did not set the initial-require-explicit flag, the weight of this
メソッドを逆にしてください: それが経路のうまくいっている方針処理を許す方針/方針マッピングを含む証明書が優先権をこの位まで持っています。 訪問者が初期の方針セットを提供して、セットしなかった、イニシャルが必要である、明白である、旗、この重さ
Cooper, et al. Informational [Page 53] RFC 4158 Certification Path Building September 2005
クーパー、他 [53ページ]情報のRFC4158証明経路ビル2005年9月
sorting method should be increased. Certificates may be eliminated only if initial-require-explicit was set by the caller or if require-explicit-policy was set by a certificate in the path to this point.
ソーティングメソッドは増強されるべきです。 または、証明書が排除されるかもしれない、唯一、イニシャルが必要である、明白である、訪問者によって設定された、明白な方針を必要とするのは、経路の証明書によるこの位までセットでした。
Justification: In a policy-using environment, certificates that successfully propagate policies are more likely part of an intended certification path than those that do not.
正当化: 方針を使用する環境で、首尾よく方針を伝播する証明書は意図している証明経路のそうしないそれらよりありそうな地域です。
When building in the forward direction, it is always possible that a certificate closer to the trust anchor will set the require- explicit-policy indicator; so giving preference to certification paths that propagate policies may increase the probability of finding a valid path first. If the caller (or a certificate in the current path) has specified or set the initial-require-explicit-policy indicator as true, this sorting method can also be used to eliminate certificates when building in the forward direction.
順方向に建てるとき、信頼アンカーの証明書クローザーがセットするのが、いつも可能である、明白な方針インディケータを必要としてください。 それで、方針を伝播する証明経路に優先を与えると、最初に有効な経路を見つけるという確率は増強されるかもしれません。 また、訪問者(または、現在の経路の証明書)が本当であるとして指定するか、またはインディケータをイニシャルが明白な方針が必要な設定したなら、順方向に建てるとき、証明書を排除するのにこのソーティングメソッドを使用できます。
If building in reverse, it is always possible that a certificate farther along the path will set the require-explicit-policy indicator; so giving preference to those certificates that propagate policies will serve well in that case. In the case where require- explicit-policy is set by certificates or the caller, certificates can be eliminated with this method.
逆であり建てるなら、経路に沿って、より遠い証明書がインディケータを明白な方針が必要な設定するのは、いつも可能です。 それで、方針を伝播するそれらの証明書に優先を与えるのはその場合よく役立つでしょう。 場合では、どこが明白な方針を必要とするか。セットが証明書であるか、またはこのメソッドで訪問者、証明書は排除できます。
3.5.14. Policies Intersect the Sought Policy Set
3.5.14. 方針が交差している、探された方針はセットしました。
May be used to eliminate certificates: No Number of possible values: Additive Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 付加的なComponentsが必要です: なし
Forward Method: Certificates that assert policies found in the initial-acceptable-policy-set have priority. Each additional matching policy could have an additive affect on the total score.
メソッドを進めてください: 初期の許容できる方針セットで見つけられた方針を断言する証明書が優先権を持っています。 それぞれの追加合っている方針で、添加物は合計でスコアに影響するかもしれません。
Alternately, this could be binary; it matches 1 or more, or matches none.
交互に、これは2進であるかもしれません。 それは、1をさらに合わせるか、またはなにも合っていません。
Reverse Method: Certificates that assert policies found in the target certificate or map policies to those found in the target certificate have priority. Each additional matching policy could have an additive affect on the total score. Alternately, this could be binary; it matches 1 or more, or matches none.
メソッドを逆にしてください: 方針が目標証明書か地図で目標証明書で見つけられたものにおいて方針を見つけたと断言する証明書が優先権を持っています。 それぞれの追加合っている方針で、添加物は合計でスコアに影響するかもしれません。 交互に、これは2進であるかもしれません。 それは、1をさらに合わせるか、またはなにも合っていません。
Justification: In the forward direction, as the path draws near to the trust anchor in a cross-certified environment, the policies asserted in the CA certificates will match those in the caller's domain. Since the initial acceptable policy set is specified in the
正当化: 順方向と、経路が十字で公認された環境で信頼アンカーに近づくとき、カリフォルニア証明書で断言された方針は訪問者のドメインでそれらを合わせるでしょう。 以来、初期の許容できる方針セットでは、指定されます。
Cooper, et al. Informational [Page 54] RFC 4158 Certification Path Building September 2005
クーパー、他 [54ページ]情報のRFC4158証明経路ビル2005年9月
caller's domain, matches may indicate that the path building is drawing nearer to a desired trust anchor. In the reverse direction, finding policies that match those of the target certificate may indicate that the path is drawing near to the target's domain.
訪問者のドメインであり、マッチは、経路ビルが必要な信頼アンカーに近づく予定であるのを示すかもしれません。 反対の方向に、目標証明書のものに合っている方針を見つけるのは、経路が目標のドメインに近づいているのを示すかもしれません。
3.5.15. Endpoint Distinguished Name (DN) Matching
3.5.15. 終点分類名(DN)マッチング
May be used to eliminate certificates: No Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: なし
Forward Method: Certificates whose issuer exactly matches a trust anchor subject DN have priority.
メソッドを進めてください: 発行人がまさに信頼アンカーのために対象のDNに合っている証明書は優先権を持っています。
Reverse Method: Certificates whose subject exactly matches the target entity issuer DN have priority.
メソッドを逆にしてください: 対象がまさに目標実体発行人DNに合っている証明書は優先権を持っています。
Justification: In the forward direction, if a certificate's issuer DN matches a trust anchor's DN [X.501], then it may complete the path. In the reverse direction, if the certificate's subject DN matches the issuer DN of the target certificate, it may be the last certificate required to complete the path.
正当化: 順方向に、証明書の発行人DNが信頼アンカーのDN[X.501]に合っているなら、それは経路を完成するかもしれません。 反対の方向に、証明書の対象DNが目標証明書の発行人DNに合っているなら、それは経路を完成しなければならなかった最後の証明書であるかもしれません。
3.5.16. Relative Distinguished Name (RDN) Matching
3.5.16. 相対的な分類名(RDN)マッチング
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: Scale Componentsを滑らせるのが必要です: なし
Forward Method: Certificates that match more ordered RDNs between the issuer DN and a trust anchor DN have priority. When all the RDNs match, this yields the highest priority.
メソッドを進めてください: 発行人DNと信頼アンカーDNの間の、より命令されたRDNsに合っている証明書が優先権を持っています。 すべてのRDNsが合っているとき、これは最優先をもたらします。
Reverse Method: Certificates with subject DNs that match more RDNs with the target's issuer DN have higher priority. When all the RDNs match, this yields the highest priority.
メソッドを逆にしてください: 目標の発行人DNにより多くのRDNsを合わせる対象のDNsがある証明書には、より高い優先度があります。 すべてのRDNsが合っているとき、これは最優先をもたらします。
Justification: In PKIs the DNs are frequently constructed in a tree like fashion. Higher numbers of matches may indicate that the trust anchor is to be found in that direction within the tree. Note that in the case where all the RDNs match [X.501], this sorting method appears to mirror the preceding one. However, this sorting method should be capable of producing a 100% weight even if the issuer DN has more RDNs than the trust anchor. The Issuer DN need only contain all the RDNs (in order) of the trust anchor.
正当化: PKIsでは、DNsはファッションのような木で頻繁に組み立てられます。 より大きい数のマッチが、信頼アンカーがその方向に木の中で見つけられることになっているのを示すかもしれません。 すべてのRDNsが合っている場合[X.501]では、このソーティングメソッドが前のものを反映するように見えることに注意してください。 しかしながら、発行人DNに信頼アンカーより多くのRDNsがあっても、このソーティングメソッドは100%の重りを生産できるべきです。 Issuer DNは信頼アンカーのすべてのRDNs (in order)を含むだけでよいです。
NOTE: In the case where all RDNs match, this sorting method mirrors the functionality of the preceding one. This allows for partial
以下に注意してください。 すべてのRDNsが合っている場合では、このソーティングメソッドは前のものの機能性を反映します。 これが考慮する、部分的
Cooper, et al. Informational [Page 55] RFC 4158 Certification Path Building September 2005
クーパー、他 [55ページ]情報のRFC4158証明経路ビル2005年9月
matches to be weighted differently from exact matches. Additionally, this method can require a lot of processing if many trust anchors are present.
完全な一致と異なって重みを加えられるべきマッチ。 さらに、多くの信頼アンカーが出席しているなら、このメソッドは多くの処理を必要とすることができます。
3.5.17. Certificates are Retrieved from cACertificate Directory
Attribute
3.5.17. 証明書はcACertificateディレクトリAttributeからのRetrievedです。
May be used to eliminate certificates: No Number of possible values: Binary Components required: Certificate Cache with flags for the attribute from where the certificate was retrieved and Remote Certificate Storage/Retrieval using a directory
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 属性のための証明書が検索されたところからの旗とRemote Certificate Storage/検索がディレクトリを使用している証明書Cache
Forward Method: Certificates retrieved from the cACertificate directory attribute have priority over certificates retrieved from the crossCertificatePair attribute. (See [RFC2587].)
メソッドを進めてください: cACertificateディレクトリ属性から検索された証明書はcrossCertificatePair属性から検索された証明書より優先権を持っています。 ([RFC2587]を見てください。)
Reverse Method: Does not apply.
メソッドを逆にしてください: 適用しません。
Justification: The cACertificate directory attribute contains certificates issued from local sources and self issued certificates. By using the cACertificate directory attribute before the crossCertificatePair attribute, the path-building algorithm will (depending on the local PKI configuration) tend to demonstrate a preference for the local PKI before venturing to external cross- certified PKIs. Most of today's PKI applications spend most of their time processing information from the local (user's own) PKI, and the local PKI is usually very efficient to traverse due to proximity and network speed.
正当化: cACertificateディレクトリ属性は地元筋と証明書が発行された自己から発行された証明書を含んでいます。 crossCertificatePair属性の前にcACertificateディレクトリ属性を使用することによって、経路を造るアルゴリズムは、外部の十字公認されたPKIsに冒険する前に地方のPKIのために優先を示す傾向があるでしょう(地方のPKI構成に依存します)。 今日のPKIアプリケーションの大部分は地方(ユーザは自己である)のPKIからのそれらの時間処理情報の大部分を費やします、そして、通常、地方のPKIは、近接とネットワーク速度のため横断するために非常に効率的です。
3.5.18. Consistent Public Key and Signature Algorithms
3.5.18. 一貫した公開鍵と署名アルゴリズム
May be used to eliminate certificates: Yes Number of possible values: Binary Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のはいNumber: 2進のComponentsが必要です: なし
Forward Method: If the public key in the issuer certificate matches the algorithm used to sign the subject certificate, then it has priority. (Certificates with unmatched public key and signature algorithms may be eliminated.)
メソッドを進めてください: 発行人証明書の公開鍵が対象の証明書に署名するのに使用されるアルゴリズムに合っているなら、それには、優先権があります。 (優れた公開鍵と署名アルゴリズムがある証明書は排除されるかもしれません。)
Reverse Method: If the public key in the current certificate matches the algorithm used to sign the subject certificate, then it has priority. (Certificates with unmatched public key and signature algorithms may be eliminated.)
メソッドを逆にしてください: 現在の証明書の公開鍵が対象の証明書に署名するのに使用されるアルゴリズムに合っているなら、それには、優先権があります。 (優れた公開鍵と署名アルゴリズムがある証明書は排除されるかもしれません。)
Justification: Since the public key and signature algorithms are not consistent, the signature on the subject certificate will not verify
正当化: 対象の証明書における署名が、公開鍵と署名アルゴリズムが一貫していないことを確かめないので
Cooper, et al. Informational [Page 56] RFC 4158 Certification Path Building September 2005
クーパー、他 [56ページ]情報のRFC4158証明経路ビル2005年9月
successfully. For example, if the issuer certificate contains an RSA public key, then it could not have issued a subject certificate signed with the DSA-with-SHA-1 algorithm.
首尾よく。 例えば、発行人証明書がRSA公開鍵を含んでいるなら、それはSHA-1とDSAアルゴリズムを契約された対象の証明書を発行していないかもしれません。
3.5.19. Similar Issuer and Subject Names
3.5.19. 同様の発行人と対象の名前
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: None
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: Scale Componentsを滑らせるのが必要です: なし
Forward Method: Certificates encountered with a subject DN that matches more RDNs with the issuer DN of the target certificate have priority.
メソッドを進めてください: 目標証明書の発行人DNにより多くのRDNsを合わせる対象のDNと共に遭遇する証明書は優先権を持っています。
Reverse Method: Same as forward.
メソッドを逆にしてください: フォワードと同じです。
Justification: As it is generally more efficient to search the local domain prior to branching to cross-certified domains, using certificates with similar names first tends to make a more efficient path builder. Cross-certificates issued from external domains will generally match fewer RDNs (if any), whereas certificates in the local domain will frequently match multiple RDNs.
正当化: 十字で公認されたドメインに分岐する前に局所領域を捜すのが一般により効率的であるので、最初に同様の名前がある証明書を使用するのは、より有能な経路ビルダーを作る傾向があります。 外部のドメインから発行された交差している証明書は一般に、より少ないRDNs(もしあれば)に合うでしょうが、局所領域の証明書は頻繁に複数のRDNsに合うでしょう。
3.5.20. Certificates in the Certification Cache
3.5.20. 証明キャッシュにおける証明書
May be used to eliminate certificates: No Number of possible values: Three Components required: Local Certificate Cache and Remote Certificate Storage/Retrieval (e.g., LDAP directory as the repository)
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 3Componentsが必要です: ローカルな証明書キャッシュとリモート証明書ストレージ/検索(例えば、倉庫としてのLDAPディレクトリ)
Forward Method: A certificate whose issuer certificate is present in the certificate cache and populated with certificates has higher priority. A certificate whose issuer's entry is fully populated with current data (all certificate attributes have been searched within the timeout period) has higher priority.
メソッドを進めてください: 発行人証明書が証明書キャッシュで現在で証明書で居住されている証明書は、より高い優先度を持っています。 Aは現在でエントリーが完全に居住される発行人のものを証明します。データには、より高い優先度があります(タイムアウト時間中にすべての証明書属性を捜してあります)。
Reverse Method: If the subject of a certificate is present in the certificate cache and populated with certificates, then it has higher priority. If the entry is fully populated with current data (all certificate attributes have been searched within the timeout period) then it has higher priority.
メソッドを逆にしてください: 証明書の対象が証明書キャッシュで現在であって証明書で居住されているなら、それには、より高い優先度があります。 エントリーが現在のデータで完全に居住されるなら(タイムアウト時間中にすべての証明書属性を捜してあります)、それには、より高い優先度があります。
Justification: The presence of required directory values populated in the cache increases the likelihood that all the required certificates and CRLs needed to complete the path from this certificate to the trust anchor (or target if building in reverse) are present in the cache from a prior path being developed, thereby
正当化: キャッシュで居住した必要なディレクトリ値の存在はすべての必要な証明書とこの証明書から信頼アンカーまで経路を完成するのが必要であるCRLs(中に建てるなら、目標は逆になる)がその結果開発される先の経路からキャッシュで存在している可能性を広げます。
Cooper, et al. Informational [Page 57] RFC 4158 Certification Path Building September 2005
クーパー、他 [57ページ]情報のRFC4158証明経路ビル2005年9月
eliminating the need for directory access to complete the path. In the event no path can be found, the performance cost is low since the certificates were likely not retrieved from the network.
ディレクトリアクセスが経路を完成する必要性を排除します。 経路を全く見つけることができないイベントでは、証明書がネットワークからおそらく検索されなかったので、性能費用は低いです。
3.5.21. Current CRL Found in Local Cache
3.5.21. ローカルなキャッシュで見つけられた現在のCRL
May be used to eliminate certificates: No Number of possible values: Binary Components Required: CRL Cache
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のコンポーネントが必要です: CRLキャッシュ
Forward Method: Certificates have priority if the issuer's CRL entry exists and is populated with current data in the CRL cache.
メソッドを進めてください: 証明書には、発行人のCRLエントリーが存在していて、CRLキャッシュにおける現在のデータで居住されるなら、優先権があります。
Reverse Method: Certificates have priority if the subject's CRL entry exists and is populated with current data in the CRL cache.
メソッドを逆にしてください: 証明書には、対象のCRLエントリーが存在していて、CRLキャッシュにおける現在のデータで居住されるなら、優先権があります。
Justification: If revocation is checked only after a complete path has been found, this indicates that a complete path has been found through this entity at some past point, so a path still likely exists. This also helps reduce remote retrievals until necessary.
正当化: 完全な経路が見つけられた後にだけ取消しがチェックされるなら、これが、完全な経路が過去の何らかのポイントのこの実体を通して見つけられたのを示すので、経路はまだおそらく存在しています。 また、これは、リモートretrievalsを必要になるまで減少させるのを助けます。
3.6. Certificate Sorting Methods for Revocation Signer Certification
Paths
3.6. 取消し署名者証明経路への証明書ソーティングメソッド
Unless using a locally-configured OCSP responder or some other locally-configured trusted revocation status service, certificate revocation information is expected to be provided by the PKI that issued the certificate. It follows that when building a certification path for a Revocation Signer certificate, it is desirable to confine the building algorithm to the PKI that issued the certificate. The following sorting methods seek to order possible paths so that the intended Revocation Signer certification path is found first.
局所的に構成されたOCSP応答者かある他の局所的に構成された信じられた取消し状態サービスを利用しない場合、証明書取消し情報は証明書を発行したPKIによって提供されると予想されます。 それは、Revocation Signer証明書のために証明経路を造るとき、ビルアルゴリズムを証明書を発行したPKIに制限するのが望ましいのに続きます。 以下のソーティングメソッドが可能な経路を命令しようとするので、意図しているRevocation Signer証明経路は最初に、見つけられます。
These sorting methods are not intended to be used in lieu of the ones described in the previous section; they are most effective when used in conjunction with those in Section 3.5. Some sorting criteria below have identical names as those in the preceding section. This indicates that the sorting criteria described in the preceding section are modified slightly when building the Revocation Signer certification path.
前項で説明されたものの代わりにこれらのソーティングメソッドが使用されることを意図しません。 セクション3.5におけるそれらに関連して使用されると、それらは最も効果的です。 以下のいくつかのソーティング評価基準に、先行するセクションのそれらとして同じ名前があります。 これは、わずかにRevocation Signer証明経路を造るとき、先行するセクションで説明されたソーティング評価基準が変更されているのを示します。
3.6.1. Identical Trust Anchors
3.6.1. 同じ信頼アンカー
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 取消しが署名者であるインディケータと認証局の信頼アンカー
Cooper, et al. Informational [Page 58] RFC 4158 Certification Path Building September 2005
クーパー、他 [58ページ]情報のRFC4158証明経路ビル2005年9月
Forward Method: Not applicable.
メソッドを進めてください: 適切でない。
Reverse Method: Path building should begin from the same trust anchor used to validate the Certification Authority before trying any other trust anchors. If any trust anchors exist with a different public key but an identical subject DN to that of the Certification Authority's trust anchor, they should be tried prior to those with mismatched names.
メソッドを逆にしてください: 経路ビルはいかなる他の信頼アンカーも裁く前に認証局を有効にするのに使用される同じ信頼アンカーから始まるはずです。 どれか信頼アンカーが異なった公開鍵にもかかわらず、同じ対象のDNと共に認証局の信頼アンカーのものに存在するなら、それらはミスマッチしている名前があるそれらの前に試みられるべきです。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path from a different trust anchor than the Certification Authority's is not desirable.
正当化: 与えられた証明書のための取消し情報は証明書を発行するPKIによって作り出されるはずです。 したがって、異なった信頼から経路を造るのは認証局が望ましくないというよりも投錨されます。
3.6.2. Endpoint Distinguished Name (DN) Matching
3.6.2. 終点分類名(DN)マッチング
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 取消しが署名者であるインディケータと認証局の信頼アンカー
Forward Method: Operates identically to the sorting method described in 3.5.15, except that instead of performing the matching against all trust anchors, the DN matching is performed only against the trust anchor DN used to validate the CA certificate.
メソッドを進めてください: 同様に中で説明されたソーティングメソッドに作動する、3.5、.15、すべての信頼アンカーに対してマッチングを実行することの代わりにそれを除いたDNマッチングはアンカーDNがカリフォルニア証明書を有効にするのに使用した信頼だけに対して実行されます。
Reverse Method: No change for Revocation Signer's certification path.
メソッドを逆にしてください: Revocation Signerの証明経路への変化がありません。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path to a different trust anchor than the CA's is not desirable. This sorting method helps to guide forward direction path building toward the trust anchor used to validate the CA certificate.
正当化: 与えられた証明書のための取消し情報は証明書を発行するPKIによって作り出されるはずです。 したがって、経路を異なった信頼に造るのはCAが望ましくないというよりも投錨されます。 このソーティングメソッドは、カリフォルニア証明書を有効にするのに使用される信頼アンカーに向かって順方向経路ビルを動かすのを助けます。
3.6.3. Relative Distinguished Name (RDN) Matching
3.6.3. 相対的な分類名(RDN)マッチング
May be used to eliminate certificates: No Number of possible values: Sliding Scale Components required: Is-revocation-signer indicator and the Certification Authority's trust anchor
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: Scale Componentsを滑らせるのが必要です: 取消しが署名者であるインディケータと認証局の信頼アンカー
Forward Method: Operates identically to the sorting method described in 3.5.16 except that instead of performing the RDN matching against all trust anchors, the matching is performed only against the trust anchor DN used to validate the CA certificate.
メソッドを進めてください: 同様に中で説明されたソーティングメソッドに作動する、3.5、.16、RDNを実行することの代わりに信頼アンカー、すべてのマッチングに対して合うのが、そうを除いて、信頼だけに対して実行されて、アンカーDNは以前はよくカリフォルニア証明書を有効にしていました。
Cooper, et al. Informational [Page 59] RFC 4158 Certification Path Building September 2005
クーパー、他 [59ページ]情報のRFC4158証明経路ビル2005年9月
Reverse Method: No change for Revocation Signer's certification path.
メソッドを逆にしてください: Revocation Signerの証明経路への変化がありません。
Justification: The revocation information for a given certificate should be produced by the PKI that issues the certificate. Therefore, building a path to a different trust anchor than the CA's is not desirable. This sorting method helps to guide forward direction path building toward the trust anchor used to validate the CA certificate.
正当化: 与えられた証明書のための取消し情報は証明書を発行するPKIによって作り出されるはずです。 したがって、経路を異なった信頼に造るのはCAが望ましくないというよりも投錨されます。 このソーティングメソッドは、カリフォルニア証明書を有効にするのに使用される信頼アンカーに向かって順方向経路ビルを動かすのを助けます。
3.6.4. Identical Intermediate Names
3.6.4. 同じ中間的名前
May be used to eliminate certificates: No Number of possible values: Binary Components required: Is-revocation-signer indicator and the Certification Authority's complete certification path
証明書を排除するのに使用されるかもしれません: 可能な値のNumberがありません: 2進のComponentsが必要です: 取消しが署名者であるインディケータと認証局の完全な証明経路
Forward Method: If the issuer DN in the certificate matches the issuer DN of a certificate in the Certification Authority's path, it has higher priority.
メソッドを進めてください: 証明書の発行人DNが認証局の経路で証明書の発行人DNに合っているなら、それには、より高い優先度があります。
Reverse Method: If the subject DN in the certificate matches the subject DN of a certificate in the Certification Authority's path, it has higher priority.
メソッドを逆にしてください: 証明書の対象のDNが認証局の経路で証明書の対象のDNに合っているなら、それには、より高い優先度があります。
Justification: Following the same path as the Certificate should deter the path-building algorithm from wandering in an inappropriate direction. Note that this sorting method is indifferent to whether the certificate is self-issued. This is beneficial in this situation because it would be undesirable to lower the priority of a re-key certificate.
正当化: Certificateと同じ次の経路は、経路を造るアルゴリズムが不適当な方向に逸れるのを思いとどまらせるべきです。 このソーティングメソッドが自己に証明書を発行するかどうかに無関心であることに注意してください。 再主要な証明書の優先権を下ろすのは望ましくないでしょう、したがって、これがこの状況で有益です。
4. Forward Policy Chaining
4. 前向きな方針推論
It is tempting to jump to the conclusion that certificate policies offer little assistance to path building when building from the target certificate. It's easy to understand the "validate as you go" approach from the trust anchor, and much less obvious that any value can be derived in the other direction. However, since policy validation consists of the intersection of the issuer policy set with the subject policy set and the mapping of policies from the issuer set to the subject set, policy validation can be done while building a path in the forward direction as well as the reverse. It is simply a matter of reversing the procedure. That is not to say this is as ideal as policy validation when building from the trust anchor, but it does offer a method that can be used to mostly eliminate what has long been considered a weakness inherent to building in the forward (from the target certificate) direction.
それは目標証明書から建てるとき、証明書方針がほとんど経路ビルに対する支援を提供しないという結論までジャンプするのに誘惑しています。 それはどんな値ももう片方の方向に引き出すことができるのがそれほど明白でない信頼アンカー、およびいろいろな事からの「碁を有効にしてください」分かり易いアプローチです。 しかしながら、方針合法化が対象の方針セットで設定された発行人方針の交差点から成って、発行人セットから対象までの方針に関するマッピングがセットしたので、経路を逆と同様に順方向に造っている間、方針合法化ができます。 それは単に手順を逆にする問題です。 信頼アンカーから建てるとき、すなわち、これを言わないのは方針合法化と同じくらい理想的ですが、それは長い間前進(目標証明書からの)の方向に建てるのに固有の弱点であると考えられていることをほとんど排除するのに使用できるメソッドを提供します。
Cooper, et al. Informational [Page 60] RFC 4158 Certification Path Building September 2005
クーパー、他 [60ページ]情報のRFC4158証明経路ビル2005年9月
4.1. Simple Intersection
4.1. 簡単な交差点
The most basic form of policy processing is the intersection of the
policy sets from the first CA certificate through the target
certificate. Fortunately, the intersection of policy sets will
always yield the same final set regardless of the order of
intersection. This allows processing of policy set intersections in
either direction. For example, if the trust anchor issues a CA
certificate (A) with policies {X,Y,Z}, and that CA issues another CA
certificate (B) with policies {X,Y}, and CA B then issues a third CA
certificate (C) with policy set {Y,G}, one normally calculates the
policy set from the trust anchor as follows:
最も基本的な形式の方針処理は最初のカリフォルニア証明書から目標証明書の方針セットの交差点です。 幸い、方針セットの交差点は交差点の注文にかかわらずいつも同じファイナルセットをもたらすでしょう。 これは方針セット交差点のどちらかの方向への処理を許します。 例えば、カリフォルニア証明書(A)が方針X、Y、Zで発行して、カリフォルニアが方針X、Yで別のカリフォルニア証明書(B)を発行して、次にカリフォルニアBが方針で3番目のカリフォルニア証明書(C)を発行する信頼アンカーがY、Gを設定するなら、通常、人は、方針が以下の信頼アンカーからセットしたと見込みます:
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
1) 交差、A、X、Y、Z、B、X、セットをもたらすYX、Y
2) Intersect that result, {X,Y} with C{Y,G} to yield the final set
{Y}
2) 交差、その結果、X、Y、C、Y、ファイナルセットをもたらすGY
Now it has been shown that certificate C is good for policy Y.
現在、方針Yに、証明書Cが良いのが示されました。
The other direction is exactly the same procedure, only in reverse:
もう片方の方向は逆だけでまさに同じ手順です:
1) Intersect C{Y,G} with B{X,Y} to yield the set {Y}
1) 交差、C、Y、G、B、X、セットをもたらすYY
2) Intersect that result, {Y} with A{X,Y,Z} to yield the final set
{Y}
2) 交差、その結果、AがあるY、X、Y、ファイナルセットをもたらすZY
Just like in the reverse direction, it has been shown that certificate C is good for policy Y, but this time in the forward direction.
まさしく反対の方向などのように、証明書Cがしかし、方針Y、順方向へのこの時に良いのが示されました。
When building in the forward direction, policy processing is handled much like it is in reverse -- the software lends preference to certificates that propagate policies. Neither approach guarantees that a path with valid policies will be found, but rather both approaches help guide the path in the direction it should go in order for the policies to propagate.
順方向に建てるとき、方針処理は逆であるように扱われます--ソフトウェアは方針を伝播する証明書に好みを与えます。 どちらも有効な方針がある経路が見つけられるアプローチ保証ではなく、アプローチむしろの両方が、それが方針が伝播される命令に行かせるべきである方向に経路を誘導するのを助けます。
If the caller has supplied an initial-acceptable-policy set, there is less value in using it when building in the forward direction unless the caller also set inhibit-policy-mapping. In that case, the path builder can further constrain the path building to propagating policies that exist in the initial-acceptable-policy-set. However, even if the inhibit-policy-mapping is not set, the initial-policy-set can still be used to guide the path building toward the desired trust anchor.
訪問者が初期の許容できる方針セットを供給したなら、また、訪問者が方針マッピングを禁止していた状態でセットしなかったなら順方向に建てるときそれを使用するのにおいて、より少ない値があります。 その場合、経路ビルダーはさらに初期の許容できる方針セットで存在する伝播方針に経路ビルを抑制できます。 しかしながら、方針マッピングを禁止しているのが設定されないでも、必要な信頼アンカーに向かって経路ビルを動かすのにまだ初期の方針セットを使用できます。
Cooper, et al. Informational [Page 61] RFC 4158 Certification Path Building September 2005
クーパー、他 [61ページ]情報のRFC4158証明経路ビル2005年9月
4.2. Policy Mapping
4.2. 方針マッピング
When a CA issues a certificate into another domain, an environment with disparate policy identifiers to its own, the CA may make use of policy mappings to map equivalence from the local domain's policy to the non-local domain's policy. If in the prior example, A had included a policy mapping that mapped X to G in the certificate it issued to B, C would be good for X and Y:
カリフォルニアがいつ別のドメインへの証明書、それ自身のものへの異種の方針識別子がある環境にカリフォルニアを発行するかが局所領域の方針から非局所領域の方針まで等価性を写像するのに方針マッピングを利用するかもしれません。 AがそれがBに発行した証明書に先の例にXからGを写像した方針マッピングを含んでいたなら、XとYに、Cは良いでしょう:
1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
1) 交差、A、X、Y、Z、B、X、セットをもたらすYX、Y
2) Process Policy Mappings in B's certificate (X maps to G) to yield
{G,Y} (same as {Y,G})
2) ビーズにおけるプロセスPolicy Mappingsは、G、Yをもたらすために(GへのX地図)を証明します。(Y、Gと同じこと)
3) Intersect that result, {G,Y} with C{Y,G} to yield the final set
{G,Y}
3) 交差、その結果、G、Y、C、Y、ファイナルセットをもたらすGG、Y
Since policies are always expressed in the relying party's domain,
the certificate C is said to be good for {X, Y}, not {Y, G}. This is
because "G" doesn't mean anything in the context of the trust anchor
that issued A without the policy mapping.
方針が信用パーティーのドメインでいつも言い表されるので、証明書CはY、Gではなく、X、Yに良いと言われています。 これは「G」が方針マッピングなしでAを発行した信頼アンカーの文脈の何も意味しないからです。
When building in the forward direction, policies can be "unmapped" by reversing the mapping procedure. This procedure is limited by one important aspect: if policy mapping has occurred in the forward direction, there is no mechanism by which it can be known in advance whether or not a future addition to the current path will invalidate the policy chain (assuming one exists) by setting inhibit-policy- mapping. Fortunately, it is uncommon practice to set this flag. The following is the procedure for processing policy mapping in the forward direction:
順方向に建てるとき、方針は、マッピング手順を逆にすることによって、"非写像"であることができます。 この手順は1つの重要な一面によって制限されます: 方針マッピングが順方向に現れたなら、現在の経路への将来の追加が方針を禁止しているマッピングを設定することによって方針チェーン(1つが存在すると仮定する)を無効にするか否かに関係なく、あらかじめそれを知ることができるメカニズムが全くありません。 幸い、この旗を設定するのは、珍しい習慣です。 ↓これは順方向の処理方針マッピングのための手順です:
1) Begin with C's policy set {Y,G}
1) Cの方針セットで、始まってください。Y、G
2) Apply the policy mapping in B's certificate (X maps to G) in
reverse to yield {Y,X} (same as {X,Y})
2) Y、Xをもたらすためにビーズ証明書で逆であり(GへのX地図)を写像する方針を適用してください。(X、Yと同じこと)
3) Intersect the result {X,Y} with B{X,Y} to yield the set {X,Y}
3) 交差、結果、X、Y、B、X、セットをもたらすYX、Y
4) Intersect that result, {X,Y}, with A{X,Y,Z} to yield the final set
{X,Y}
4) 交差、その結果、X、AがあるY、X、Y、ファイナルセットをもたらすZX、Y
Just like in the reverse direction, it is determined in the forward
direction that certificate C is good for policies {X,Y}. If during
this procedure, an inhibit-policy-mapping flag was encountered, what
should be done? This is reasonably easy to keep track of as well.
The software simply maintains a flag on any policies that were
propagated as a result of a mapping; just a simple Boolean kept with
まさしく反対の方向などのように、方針X、Yに、証明書Cが良いことを順方向に決定します。 この手順の間、方針マッピングを禁止している旗に遭遇するなら、何をするでしょうか? また、これは合理的に動向をおさえやすいです。 ソフトウェアはマッピングの結果、伝播されたどんな方針でも単に旗を維持します。 aただ簡単である、ブール、保ちます。
Cooper, et al. Informational [Page 62] RFC 4158 Certification Path Building September 2005
クーパー、他 [62ページ]情報のRFC4158証明経路ビル2005年9月
the policies in the set. Imagine now that the certificate issued to A has the inhibit-policy-mapping constraint expressed with a skip certificates value of zero.
セットにおける方針。 今、Aに発行された証明書でゼロのスキップ証明書価値で方針マッピングを禁止している規制を言い表すと想像してください。
1) Begin with C's policy set {Y,G}
1) Cの方針セットで、始まってください。Y、G
2) Apply the policy mapping in B's certificate and mark X as
resulting from a mapping. (X maps to G) in reverse to yield {Y,Xm}
(same as {Xm,Y})
2) マッピングから生じるとしてビーズ証明書とマークXで方針マッピングを適用してください。 (GへのX地図) Y、Xmをもたらす逆で(Xm、Yと同じこと)
3) Intersect the result {Xm,Y} with B{X,Y} to yield the set {Xm,Y}
3) 交差、結果、Xm、Y、B、X、セットをもたらすYXm、Y
4) A's certificate expresses the inhibit policy mapping constraint,
so eliminate any policies in the current set that were propagated
due to mapping (which is Xm) to yield {Y}
4) Aの証明書が言い表す、方針マッピング規制を抑制してくださいので、マッピング(Xmである)のためもたらすために伝播された現在のセットにおけるあらゆる方針を排除してください。Y
5) Intersect that result, {Y} with A{X,Y,Z} to yield the final set
{Y}
5) 交差、その結果、AがあるY、X、Y、ファイナルセットをもたらすZY
If in our example, the policy set had gone to empty at any point (and require-explicit-policy was set), the path building would back up and try to traverse another branch of the tree. This is analogous to the path-building functionality utilized in the reverse direction when the policy set goes to empty.
方針セットが任意な点で空になりに私たちの例に行ったなら(明白な方針を必要とするのは、セットでした)、経路ビルは、木の別の枝を横断に支援して、試すでしょう。 これは方針セットが空になりに行くとき反対の方向に利用された経路を造る機能性に類似しています。
4.3. Assigning Scores for Forward Policy Chaining
4.3. 前向きな方針推論のためにスコアを割り当てます。
Assuming the path-building module is maintaining the current forward policy set, weights may be assigned using the following procedure:
経路を造るモジュールが現在の前進の方針がセットしたと主張することであると仮定する場合、重りは以下の手順を用いることで割り当てられるかもしれません:
1) For each CA certificate being scored:
1) 得られるそれぞれのカリフォルニア証明書のために:
a. Copy the current forward policy set.
a。 現在の前進の方針セットをコピーしてください。
b. Process policy mappings in the CA certificate in order to
"un-map" policies, if any.
b。 方針を「不-写像する」ためにもしあればカリフォルニア証明書の方針マッピングを処理してください。
c. Intersect the resulting set with CA certificate's policies.
c。 交差してください。結果になることはカリフォルニア証明書の方針でセットしました。
The larger the policy set yielded, the larger the score for that CA certificate.
セットがもたらした方針が大きければ大きいほど、そのカリフォルニア証明書のためのスコアは、より大きいです。
2) If an initial acceptable set was supplied, intersect this set with
the resulting set for each CA certificate from (1).
2) 初期の許容できるセットを供給したなら、(1)からのそれぞれのカリフォルニア証明書のために結果として起こるセットとこれほど設定していた状態で交差してください。
The larger the resultant set, the higher the score is for this certificate.
結果のセットが大きければ大きいほど、スコアは、より高くこの証明書のためのものです。
Cooper, et al. Informational [Page 63] RFC 4158 Certification Path Building September 2005
クーパー、他 [63ページ]情報のRFC4158証明経路ビル2005年9月
Other scoring schemes may work better if the operating environment dictates.
操作環境が命令するなら、他の得点体系はうまくいくかもしれません。
5. Avoiding Path-Building Errors
5. 経路を造る誤りを避けます。
This section defines some errors that may occur during the path- building process, as well as ways to avoid these errors when developing path-building functions.
このセクションは経路建築の過程の間に発生するかもしれないいくつかの誤りを定義します、経路を造る機能を開発するときこれらの誤りを避ける方法と同様に。
5.1. Dead Ends
5.1. 行き止まり
When building certification paths in a non-hierarchical PKI structure, a simple path-building algorithm could fail prematurely without finding an existing path due to a "dead end". Consider the example in Figure 14.
早まって非階層的なPKI構造に証明経路を造るとき、「行き止まり」のため既存の経路を見つけないで、簡単な経路を造るアルゴリズムは失敗できました。 図14の例を考えてください。
+----+ +---+
| TA | | Z |
+----+ +---+
| |
| |
V V
+---+ +---+
| C |<-----| Y |
+---+ +---+
|
|
V
+--------+
| Target |
+--------+
+----+ +---+ | バイバイ| | Z| +----+ +---+ | | | | +に対するV---+ +---+ | C| <、-、-、-、--、| Y| +---+ +---+ | | +に対して--------+ | 目標| +--------+
Figure 14 - Dead End Example
図14--行き止まりの例
Note that in the example, C has two certificates: one issued by Y, and the other issued by the Trust Anchor. Suppose that a simple "find issuer" algorithm is used, and the order in which the path builder found the certificates was Target(C), C(Y), Y(Z), Z(Z). In this case, Z has no certificates issued by any other entities, and so the simplistic path-building process stops. Since Z is not the relying party's trust anchor, the certification path is not complete, and will not validate. This example shows that in anything but the simplest PKI structure, additional path-building logic will need to handle the cases in which entities are issued multiple certificates from different issuers. The path-building algorithm will also need to have the ability to traverse back up the decision tree and try another path in order to be robust.
例では、Cが2通の証明書を持っていることに注意してください: Yによって発行された1つ、およびTrust Anchorによって発行されたもう片方。 簡単な「掘り出し物の発行人」アルゴリズムが使用されていて、経路ビルダーが証明書を見つけたオーダーがTarget(C)であったと仮定してください、C(Y)、Y(Z)、Z(Z)。 この場合いかなる他の実体でも証明書を全く発行しないので、Zで安易な経路建築の過程は止まります。 Zが信用パーティーの信頼アンカーでないので、証明経路はアンカーです。完成して、有効にするでしょう。 この例は、最も簡単なPKI構造以外の何においてでも、追加経路を造る論理が、異なった発行人からの複数の証明書が実体に発行される場合を扱う必要であるのを示します。 また、経路を造るアルゴリズムは、横断する能力を意思決定の樹状図に返してもらって、強健になるように別の経路を試みる必要があるでしょう。
Cooper, et al. Informational [Page 64] RFC 4158 Certification Path Building September 2005
クーパー、他 [64ページ]情報のRFC4158証明経路ビル2005年9月
5.2. Loop Detection
5.2. 輪の検出
In a non-hierarchical PKI structure, a path-building algorithm may become caught in a loop without finding an existing path. Consider the example below:
非階層的なPKI構造では、経路を造るアルゴリズムは輪で既存の経路を見つけないで引っかかるようになるかもしれません。 以下の例を考えてください:
+----+
| TA |
+----+
|
|
+---+ +---+
| A | ->| Z |
+---+ / +---+
| / |
| / |
V / V
+---+ +---+
| B |<-----| Y |
+---+ +---+
|
|
V
+--------+
| Target |
+--------+
+----+ | バイバイ| +----+ | | +---+ +---+ | A| ->| Z| +---+ / +---+ | / | | / | V/V+---+ +---+ | B| <、-、-、-、--、| Y| +---+ +---+ | | +に対して--------+ | 目標| +--------+
Figure 15 - Loop Example
図15--輪の例
Let us suppose that in this example the simplest "find issuer" algorithm is used, and the order in which certificates are retrieved is Target(B), B(Y), Y(Z), Z(B), B(Y), Y(Z), Z(B), B(Y), ... A loop has formed that will cause the correct path (Target, B, A) to never be found. The certificate processing system will need to recognize loops created by duplicate certificates (which are prohibited in a path by [X.509]) before they form to allow the certification path- building process to continue and find valid paths. The authors of this document recommend that the loop detection not only detect the repetition of a certificate in the path, but also detect the presence of the same subject name / subject alternative name/ subject public key combination occurring twice in the path. A name/key pair should only need to appear once in the path. (See Section 2.4.2 for more information on the reasoning behind this recommendation.)
この例では、最も簡単な「掘り出し物の発行人」アルゴリズムが使用されていて、証明書が検索されるオーダーがTarget(B)であると思いましょう、B(Y)、Y(Z)、Z(B)、B(Y)、Y(Z)、Z(B)、B(Y)… 正しい経路(目標、B、A)を決して、見つけない輪は形成されました。 証明書処理システムは、有効な経路を続けて、見つけるために証明経路に建築の過程を許容するために形成する前に写し証明書(経路で[X.509]によって禁止されている)によって作成された輪を認識する必要があるでしょう。 このドキュメントの作者は、輪の検出が、経路での証明書の複写を検出するだけではなく、経路に同じ対象の名前/対象の代替名/対象の公開鍵組み合わせの存在が二度起こるのを検出もすることを勧めます。 名前/主要な組は、経路に一度現れる必要があるだけであるべきです。 (この推薦の後ろで推理の詳しい情報に関してセクション2.4.2を見てください。)
Cooper, et al. Informational [Page 65] RFC 4158 Certification Path Building September 2005
クーパー、他 [65ページ]情報のRFC4158証明経路ビル2005年9月
5.3. Use of Key Identifiers
5.3. 主要な識別子の使用
Inconsistent and/or incompatible approaches to computing the subject key identifier and authority key identifier in public key certificates can cause failures in certification path-building algorithms that use those fields to identify certificates, even though otherwise valid certification paths may exist. Path-building implementations should use existing key identifiers and not attempt to re-compute subject key identifiers. It is extremely important that Key Identifiers be used only as sorting criteria or hints. KIDs are not required to match during certification path validation and cannot be used to eliminate certificates. This is of critical importance for interoperating across domains and multi-vendor implementations where the KIDs may not be calculated in the same fashion.
公開鍵証明書の対象の主要な識別子と権威の主要な識別子を計算することへの矛盾したそして/または、両立しないアプローチは証明書を特定するのにそれらの分野を使用する経路を造る証明アルゴリズムで失敗を引き起こす場合があります、そうでなければ、有効な証明経路が存在するかもしれませんが。 経路を造る実装は、既存の主要な識別子を使用して、対象の主要な識別子を再計算するのを試みるべきではありません。 Key Identifiersが単に評価基準かヒントを分類するとして使用されるのは、非常に重要です。 KIDsを証明経路合法化の間、合うのが必要でなく、証明書を排除するのに使用できません。 これはKIDsが同じファッションで計算されないかもしれないところのドメインとマルチベンダ実装の向こう側に共同利用するための決定的な重要性のものです。
Path-building and processing implementations should not rely on the form of authority key identifier that uses the authority DN and serial number as a restrictive matching rule, because cross- certification can lead to this value not being matched by the cross- certificates.
経路ビルと処理実装は制限している合っている規則として権威DNを使用する権威の主要な識別子と通し番号のフォームを当てにするべきではありません、十字証明が十字証明書によって合わせられていないこの値につながることができるので。
5.4. Distinguished Name Encoding
5.4. 分類名コード化
Certification path-building software should not rely on DNs being encoded as PrintableString. Although frequently encoded as PrintableString, DNs may also appear as other types, including BMPString or UTF8String. As a result, software systems that are unable to process BMPString and UTF8String encoded DNs may be unable to build and validate some certification paths.
経路を造る証明ソフトウェアはPrintableStringとしてコード化されるDNsを当てにするはずがありません。 PrintableStringとして頻繁にコード化されますが、また、DNsはBMPStringかUTF8Stringを含む他のタイプとして現れるかもしれません。 その結果、BMPStringとUTF8Stringのコード化されたDNsを処理できないソフトウェア・システムは、いくつかの証明経路を建てて、有効にすることができないかもしれません。
Furthermore, [RFC3280] compliant certificates are required to encode DNs as UTF8String as of January 1, 2004. Certification path-building software should be prepared to handle "name rollover" certificates as described in [RFC3280]. Note that the inclusion of a "name rollover" certificate in a certification path does not constitute repetition of a DN and key. Implementations that include the "name rollover" certificate in the path should ensure that the DNs with differing encoding are regarded as dissimilar. (Implementations may instead handle matching DNs of different encodings and will therefore not need to include "name rollover" certificates in the path.)
その上、[RFC3280]対応することの証明書は2004年1月1日現在、UTF8StringとしてDNsをコード化しなければなりません。 経路を造る証明ソフトウェアは[RFC3280]で説明されるように「名前ロールオーバー」証明書を扱うように準備されるべきです。 証明経路での「名前ロールオーバー」証明書の包含がDNとキーの反復を構成しないことに注意してください。 経路に「名前ロールオーバー」証明書を含んでいる実装は、異なったコード化があるDNsが異なると見なされるのを確実にするべきです。 (実装は、代わりに異なったencodingsの合っているDNsを扱うかもしれなくて、したがって、経路に「名前ロールオーバー」証明書を含む必要はないでしょう。)
Cooper, et al. Informational [Page 66] RFC 4158 Certification Path Building September 2005
クーパー、他 [66ページ]情報のRFC4158証明経路ビル2005年9月
6. Retrieval Methods
6. 検索メソッド
Building a certification path requires the availability of the certificates and CRLs that make up the path. There are many different methods for obtaining these certificates and CRLs. This section lists a few of the common ways to perform this retrieval, as well as some suggested approaches for improving performance. This section is not intended to provide a complete reference for certificate and CRL retrieval methods or optimizations that would be useful in certification path building.
証明経路を造るのは経路を作る証明書とCRLsの有用性を必要とします。 これらの証明書とCRLsを入手するための多くの異なったメソッドがあります。 このセクションはこの検索を実行する一般的な方法のいくつかを記載します、性能を向上させるためのいくつかの提案されたアプローチと同様に。 このセクションが証明書とCRL検索メソッドか証明経路ビルで役に立つ最適化の完全な参照を提供することを意図しません。
6.1. Directories Using LDAP
6.1. LDAPを使用するディレクトリ
Most applications utilize the Lightweight Directory Access Protocol (LDAP) when retrieving data from directories following the X.500 model. Applications may encounter directories which support either LDAP v2 [RFC1777] or LDAP v3 [RFC3377].
X.500モデルに従って、ディレクトリからのデータを検索するとき、ほとんどのアプリケーションがライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)を利用します。 アプリケーションはLDAP v2[RFC1777]かLDAP v3[RFC3377]のどちらかをサポートするディレクトリに遭遇するかもしれません。
The LDAP v3 specification defines one attribute retrieval option, the "binary" option. When specified in an LDAP retrieval request, this option was intended to force the directory to ignore any string-based representations of BER-encoded directory information, and send the requested attribute(s) in BER format. Since all PKI objects of concern are BER-encoded objects, the "binary" option should be used. However, not all directories support the "binary" option. Therefore, applications should be capable of requesting attributes with and without the "binary" option. For example, if an application wishes to retrieve the userCertificate attribute, the application should request "userCertificate;binary". If the desired information is not returned, robust implementations may opt to request "userCertificate" as well.
LDAP v3仕様は1つの属性検索オプション、「2進」のオプションを定義します。 LDAP検索要求で指定されたいつか、このオプションが、ディレクトリがBERによってコード化されたディレクトリ情報のどんなストリングベースの表現も無視して、BER形式における要求された属性を送るのを強制することを意図しました。 関心のすべてのPKI対象がBERによってコード化されたオブジェクトであるので、「2進」のオプションは使用されるべきです。 しかしながら、すべてのディレクトリが「2進」のオプションをサポートするというわけではありません。 したがって、アプリケーションは「2進」のオプションのあるなしにかかわらず属性を要求できるべきです。 例えば、アプリケーションがuserCertificate属性を検索したいなら、申込み書が要求されるべきである、「userCertificate;、2進、」 必要な情報が返されないなら、強健な実装は、また、"userCertificate"を要求するために選ばれるかもしれません。
The following attributes should be considered by PKI application developers when performing certificate retrieval from LDAP sources:
LDAPソースから証明書検索を実行するとき、以下の属性はPKIアプリケーション開発者によって考えられるべきです:
userCertificate: contains certificates issued by one or more
certification authorities with a subject DN that matches that of
the directory entry. This is a multi-valued attribute and all
values should be received and considered during path building.
Although typically it is expected that only end entity
certificates will be stored in this attribute, (e.g., this is the
attribute an application would request to find a person's
encryption certificate) implementers may opt to search this
attribute when looking in CA entries to make their path builder
more robust. If it is empty, the overhead added by including this
attribute when already requesting one or both of the two below is
marginal.
userCertificate: ディレクトリエントリのものに合っている対象のDNの1つ以上の証明当局によって発行された証明書を含んでいます。 これがマルチ評価された属性であり、すべての値が、経路ビルの間、受け取られて、考えられるべきです。 終わりの実体証明書だけがこの属性で保存されると通常予想されますが、(例えば、これはアプリケーションが人の暗号化証明書を見つけるよう要求する属性です)implementersは、彼らの経路ビルダーをより強健にするようにカリフォルニアのエントリーの中を見るとき、この属性を捜すために選ばれるかもしれません。 それが空であるなら、以下の既に1か2つのものの両方を要求するときこの属性を含んでいることによって加えられたオーバーヘッドはマージンです。
Cooper, et al. Informational [Page 67] RFC 4158 Certification Path Building September 2005
クーパー、他 [67ページ]情報のRFC4158証明経路ビル2005年9月
cACertificate: contains self-issued certificates (if any) and any
certificates issued to this certification authority by other
certification authorities in the same realm. (Realm is dependent
upon local policy.) This is a multi-valued attribute and all
values should be received and considered during path building.
cACertificate: (もしあれば)の自己によって発行された証明書と同じ分野で他の証明当局によってこの証明権威に発行されたどんな証明書も含んでいます。 (分野はローカルの方針に依存しています。) これがマルチ評価された属性であり、すべての値が、経路ビルの間、受け取られて、考えられるべきです。
crossCertificatePair: in conformant implementations, the
crossCertificatePair is used to contain all, except self-issued
certificates issued to this certification authority, as well as
certificates issued by this certification authority to other
certification authorities. Each attribute value is a structure
containing two elements. The issuedToThisCA element contains
certificates issued to this certification authority by other
certification authorities. The issuedByThisCA element contains
certificates issued by this certification authority to other
certification authorities. Both elements of the
crossCertificatePair are labeled optional in the ASN.1 definition.
If both elements are present in a single value, the issuer name in
one certificate is required to match the subject name in the other
and vice versa, and the subject public key in one certificate
shall be capable of verifying the digital signature on the other
certificate and vice versa. As this technology has evolved,
different standards have had differing requirements on where
information could be found. For example, the LDAP v2 schema
[RFC2587] states that the issuedToThisCA (once called 'forward')
element of the crossCertificatePair attribute is mandatory and the
issuedByThisCA (once called 'reverse') element is optional. In
contrast, Section 11.2.3 of [X.509] requires the issuedByThisCA
element to be present if the CA issues a certificate to another CA
if the subject is not a subordinate CA in a hierarchy. Conformant
directories behave as required by [X.509], but robust path-
building implementations may want to retrieve all certificates
from the cACertificate and crossCertificatePair attributes to
ensure all possible certification authority certificates are
obtained.
crossCertificatePair: conformant実装では、crossCertificatePairはすべてを含むのに使用されます、この証明権威に発行された自己によって発行された証明書を除いて、他の証明当局へのこの証明権威によって発行された証明書と同様に。 各属性値は2つの要素を含む構造です。 issuedToThisCA要素は他の証明当局によってこの証明権威に発行された証明書を含んでいます。 issuedByThisCA要素は他の証明当局へのこの証明権威によって発行された証明書を含んでいます。 crossCertificatePairの両方の要素はASN.1定義で任意であるとラベルされます。 両方の要素がただ一つの値で存在しているなら、1通の証明書の発行人名が逆もまた同様にもう片方における対象の名前を合わせるのに必要です、そして、1通の証明書の対象の公開鍵はもう片方の証明書の上に逆もまた同様にデジタル署名について確かめることができるでしょう。 この技術が発展したとき、異なった規格に、情報を見つけることができたところに関する異なった要件がありました。 例えば、LDAP v2図式[RFC2587]はcrossCertificatePair属性のissuedToThisCA(一度'前方'呼ばれる)要素が義務的であり、issuedByThisCA(一度'逆である'と呼ばれる)要素が任意であると述べます。 対照的に、カリフォルニアが対象が階層構造の下位のカリフォルニアでないなら別のカリフォルニアに証明書を下付するなら、.3セクション11.2[X.509]が、issuedByThisCA要素が現在であるのを必要とします。 Conformantディレクトリは必要に応じて[X.509]で反応しますが、強健な経路ビル実装は、すべての可能な証明権威証明書が入手されるのを保証するためにcACertificateとcrossCertificatePair属性からのすべての証明書を検索したがっているかもしれません。
certificateRevocationList: the certificateRevocationList attribute
contains a certificate revocation list (CRL). A CRL is defined in
[RFC3280] as a time stamped list identifying revoked certificates,
which is signed by a CA or CRL issuer and made freely available in
a public repository. Each revoked certificate is identified in a
CRL by its certificate serial number. There may be one or more
CRLs in this attribute, and the values should be processed in
accordance with [RFC3280].
certificateRevocationList: certificateRevocationList属性は証明書失効リスト(CRL)を含んでいます。 CRLは[RFC3280]で取り消された証明書を特定する時間の押し込まれたリストと定義されます。(それは、カリフォルニアかCRL発行人によって署名されて、公共の倉庫で自由に利用可能にされます)。 それぞれの取り消された証明書はCRLで証明書通し番号によって特定されます。 1CRLsがこの属性にあるかもしれません、そして、[RFC3280]に従って、値は処理されるべきです。
Cooper, et al. Informational [Page 68] RFC 4158 Certification Path Building September 2005
クーパー、他 [68ページ]情報のRFC4158証明経路ビル2005年9月
authorityRevocationList: the authorityRevocationList attribute also
contains CRLs. These CRLs contain revocation information
regarding certificates issued to other CAs. There may be one or
more CRLs in this attribute, and the values should be processed in
accordance with [RFC3280].
authorityRevocationList: また、authorityRevocationList属性はCRLsを含んでいます。 これらのCRLsは他のCAsに発行された証明書の取消し情報を含んでいます。 1CRLsがこの属性にあるかもしれません、そして、[RFC3280]に従って、値は処理されるべきです。
Certification path processing systems that plan to interoperate with varying PKI structures and directory designs should at a minimum be able to retrieve and process the userCertificate, cACertificate, crossCertificatePair, certificateRevocationList, and authorityRevocationList attributes from directory entries.
ディレクトリエントリーからuserCertificate、cACertificate、crossCertificatePair、certificateRevocationList、およびauthorityRevocationList属性を検索して、処理できる状態でPKI構造とディレクトリデザインが最小限でそうするべきである異なることで共同利用する計画があるシステムを処理する証明経路。
6.2. Certificate Store Access via HTTP
6.2. HTTPを通した証明書ストアAccess
Another possible method of certificate retrieval is using HTTP as an interface mechanism for retrieving certificates and CRLs from PKI repositories. A current PKIX document [CERTSTORE] provides a protocol for a general-purpose interface capability for retrieving certificates and CRLs from PKI repositories. Since the [CERTSTORE] document is a work in progress as of the writing of this document, no details are given here on how to utilize this mechanism for certificate and CRL retrieval. Instead, refer to the [CERTSTORE] document or its current version. Certification path processing systems may wish to implement support for this interface capability, especially if they will be used in environments that will provide HTTP-based access to certificates and CRLs.
証明書検索の別の可能なメソッドは、PKI倉庫から証明書とCRLsを検索するのにインタフェースメカニズムとしてHTTPを使用することです。 現在のPKIXドキュメント[CERTSTORE]は、PKI倉庫から証明書とCRLsを検索するために汎用インターフェース能力にプロトコルを提供します。 このドキュメントの書くこと付けで[CERTSTORE]ドキュメントが処理中の作業であるので、どんな詳細がここ、どう証明書とCRL検索にこのメカニズムを利用するかに関して明らかにされないか。 代わりに、[CERTSTORE]ドキュメントかその最新版を参照してください。 証明経路処理システムはこのインタフェース能力のサポートを実装したがっているかもしれません、特にそれらが証明書とCRLsへのHTTPベースのアクセスを提供する環境で使用されるなら。
6.3. Authority Information Access
6.3. 権威情報アクセス
The authority information access (AIA) extension, defined within [RFC3280], indicates how to access CA information and services for the issuer of the certificate in which the extension appears. If a certificate with an AIA extension contains an accessMethod defined with the id-ad-caIssuers OID, the AIA may be used to retrieve one or more certificates for the CA that issued the certificate containing the AIA extension. The AIA will provide a uniform resource identifier (URI) [RFC3986] when certificates can be retrieved via LDAP, HTTP, or FTP. The AIA will provide a directoryName when certificates can be retrieved via directory access protocol (DAP). The AIA will provide an rfc822Name when certificates can be retrieved via electronic mail. Additionally, the AIA may specify the location of an OCSP [RFC2560] responder that is able to provide revocation information for the certificate.
[RFC3280]の中で定義された権威情報アクセス(AIA)拡大は拡大が現れる証明書の発行人のためにカリフォルニア情報とサービスにアクセスする方法を示します。 AIA拡張子がある証明書が定義されたaccessMethodを含んでいる、イド広告caIssuers OID、AIAは、AIA拡張子を含む証明書を発行したカリフォルニアのための1通以上の証明書を検索するのに使用されるかもしれません。 LDAP、HTTP、またはFTPで証明書を検索できるとき、AIAは一定のリソース識別子(URI)[RFC3986]を提供するでしょう。 ディレクトリアクセス・プロトコル(DAP)で証明書を検索できるとき、AIAはdirectoryNameを提供するでしょう。 電子メールを通して証明書を検索できるとき、AIAはrfc822Nameを提供するでしょう。 さらに、AIAは証明書のための取消し情報を提供できるOCSP[RFC2560]応答者の位置を指定するかもしれません。
If present, AIA may provide forward path-building implementations with a direct link to a certificate for the issuer of a given certificate. Therefore, implementations may wish to provide support for decoding the AIA extension and processing the LDAP, HTTP, FTP,
存在しているなら、AIAは与えられた証明書の発行人のための証明書への直リンクを前進の経路を造る実装に提供するかもしれません。 したがって、実装はAIA拡張子を解読して、LDAP、HTTP、FTPを処理するサポートを提供したがっているかもしれません。
Cooper, et al. Informational [Page 69] RFC 4158 Certification Path Building September 2005
クーパー、他 [69ページ]情報のRFC4158証明経路ビル2005年9月
DAP, or e-mail locators. Support for AIA is optional; [RFC3280] compliant implementations are not required to populate the AIA extension. However, implementers of path-building and validation modules are strongly encouraged to support AIA, especially the HTTP transport; this will provide for usability and interoperability with many existing PKIs.
DAP、またはメールロケータ。 AIAのサポートは任意です。 [RFC3280]対応することの実装は、AIA拡張子に居住するのに必要ではありません。 しかしながら、経路ビルと合法化モジュールのimplementersがAIA、特にHTTPに輸送をサポートするよう強く奨励されます。 これは多くの既存のPKIsと共にユーザビリティと相互運用性に備えるでしょう。
6.4. Subject Information Access
6.4. 対象の情報アクセス
The subject information access (SIA) extension, defined within [RFC3280], indicates how to access information and services for the subject of the certificate in which the extension appears. If a certificate with an SIA extension contains an accessMethod defined with the id-ad-caRepository OID, the SIA may be used to locate one or more certificates (and possibly CRLs) for entities issued certificates by the subject. The SIA will provide a uniform resource identifier (URI) [RFC3986] when data can be retrieved via LDAP, HTTP, or FTP. The SIA will provide a directoryName when data can be retrieved via directory access protocol (DAP). The SIA will provide an rfc822Name when data can be retrieved via electronic mail.
[RFC3280]の中で定義された対象の情報アクセス(SIA)拡大は拡大が現れる証明書の対象のための情報とサービスにアクセスする方法を示します。 SIA拡張子がある証明書が定義されたaccessMethodを含んでいる、イド広告caRepository OID、SIAは、証明書が対象によって発行された実体のための1通以上の証明書(そして、ことによるとCRLs)の場所を見つけるのに使用されるかもしれません。 LDAP、HTTP、またはFTPでデータを検索できるとき、SIAは一定のリソース識別子(URI)[RFC3986]を提供するでしょう。 ディレクトリアクセス・プロトコル(DAP)でデータを検索できるとき、SIAはdirectoryNameを提供するでしょう。 電子メールを通してデータを検索できるとき、SIAはrfc822Nameを提供するでしょう。
If present, the SIA extension may provide reverse path-building implementations with the certificates required to continue building the path. Therefore, implementations may wish to provide support for decoding the SIA extension and processing the LDAP, HTTP, FTP, DAP, or e-mail locators. Support for SIA is optional; [RFC3280] compliant implementations are not required to populate the SIA extension. However, implementers of path-building and validation modules are strongly encouraged to support SIA, especially the HTTP transport; this will provide for usability and interoperability with many existing PKIs.
存在しているなら、SIA拡張子は経路を造り続けなければならなかった証明書を逆の経路を造る実装に提供するかもしれません。 したがって、実装は、SIA拡張子を解読するサポートに提供して、LDAP、HTTP、FTP、DAP、またはメールロケータを処理に提供したがっているかもしれません。 SIAのサポートは任意です。 [RFC3280]対応することの実装は、SIA拡張子に居住するのに必要ではありません。 しかしながら、経路ビルと合法化モジュールのimplementersがSIA、特にHTTPに輸送をサポートするよう強く奨励されます。 これは多くの既存のPKIsと共にユーザビリティと相互運用性に備えるでしょう。
6.5. CRL Distribution Points
6.5. CRL分配ポイント
The CRL distribution points (CRLDP) extension, defined within [RFC3280], indicates how to access CRL information. If a CRLDP extension appears within a certificate, the CRL(s) to which the CRLDP refer are generally the CRLs that would contain revocation information for the certificate. The CRLDP extension may point to multiple distribution points from which the CRL information may be obtained; the certificate processing system should process the CRLDP extension in accordance with [RFC3280]. The most common distribution points contain URIs from which the appropriate CRL may be downloaded, and directory names, which can be queried in a directory to retrieve the CRL attributes from the corresponding entry.
[RFC3280]の中で定義されたCRL分配ポイント(CRLDP)拡大はCRL情報にアクセスする方法を示します。 CRLDP拡張子が証明書の中に現れるなら、一般に、CRLDPが参照するCRL(s)は証明書のための取消し情報を含むCRLsです。 CRLDP拡張子はCRL情報が得られるかもしれないマルチ配線ポイントを示すかもしれません。 [RFC3280]に従って、証明書処理システムはCRLDP拡張子を処理するはずです。 最も一般的な分配ポイントは適切なCRLがダウンロードされるかもしれないURI、およびディレクトリ名を含んでいます。(対応するエントリーからCRL属性を検索するためにディレクトリでディレクトリ名について質問できます)。
Cooper, et al. Informational [Page 70] RFC 4158 Certification Path Building September 2005
クーパー、他 [70ページ]情報のRFC4158証明経路ビル2005年9月
If present, CRLDP can provide certificate processing implementations with a link to CRL information for a given certificate. Therefore, implementations may wish to provide support for decoding the CRLDP extension and using the information to retrieve CRLs. Support for CRLDP is optional and [RFC3280] compliant implementations need not populate the CRLDP extension. However, implementers of path-building and validation modules are strongly encouraged to support CRLDPs. At a minimum, developers are encouraged to consider supporting the LDAP and HTTP transports; this will provide for interoperability across a wide range of existing PKIs.
存在しているなら、CRLDPは与えられた証明書のためのCRL情報へのリンクを証明書処理実装に提供できます。 したがって、実装はCRLDP拡張子を解読して、CRLsを検索するのに情報を使用するサポートを提供したがっているかもしれません。 CRLDPのサポートは任意です、そして、[RFC3280]対応することの実装はCRLDP拡張子に居住する必要はありません。 しかしながら、経路ビルと合法化モジュールのimplementersがCRLDPsをサポートするよう強く奨励されます。 最小限では、開発者が、LDAPとHTTPが輸送であるとサポートすると考えるよう奨励されます。 これはさまざまな既存のPKIsの向こう側に相互運用性に備えるでしょう。
6.6. Data Obtained via Application Protocol
6.6. Applicationプロトコルを通したデータObtained
Many application protocols, such as SSL/TLS and S/MIME, allow one party to provide certificates and CRLs to another. Data provided in this method is generally very valuable to path-building software (will provide direction toward valid paths), and should be stored and used accordingly. Note: self-signed certificates obtained via application protocol are not trustworthy; implementations should only consider the relying party's trust anchors when building paths.
SSL/TLSやS/MIMEなどの多くのアプリケーション・プロトコルで、1回のパーティーが証明書とCRLsを別のものに提供できます。 このメソッドに提供されたデータは、それに従って、一般に、経路を造るソフトウェアに非常に貴重であり(有効な経路に向かって方向を提供するでしょう)、保存されて、使用されるべきです。 以下に注意してください。 アプリケーション・プロトコルで入手された自己署名入りの証書は信頼できません。 実装は経路を造るときパーティーの信頼が据えつける信用を考えるだけであるべきです。
6.7. Proprietary Mechanisms
6.7. 独占メカニズム
Some certificate issuing systems and certificate processing systems may utilize proprietary retrieval mechanisms, such as network mapped drives, databases, or other methods that are not directly referenced via the IETF standards. Certificate processing systems may wish to support other proprietary mechanisms, but should only do so in addition to supporting standard retrieval mechanisms such as LDAP, AIA, and CRLDP (unless functioning in a closed environment).
システムと証明書処理システムを支給する何らかの証明書が独占回収機構を利用するかもしれません。(回収機構はIETF規格で直接参照をつけられない写像しているドライブ、データベース、または他のメソッドをネットワークでつなぎます)。 LDAPや、AIAや、CRLDPなどの標準の回収機構をサポートすることに加えてそうするだけであるべきであるのを除いて、証明書処理システムは他の独占メカニズムをサポートしたがっているかもしれません(閉じている環境で機能しない場合)。
7. Improving Retrieval Performance
7. 検索性能を向上させます。
Retrieval performance can be improved through a few different mechanisms, including the use of caches and setting a specific retrieval order. This section discusses a few methods by which the performance of a certificate processing system may be improved during the retrieval of PKI objects. Certificate processing systems that are consistently very slow during processing will be disliked by users and will be slow to be adopted into organizations. Certificate processing systems are encouraged to do whatever possible to reduce the delays associated with requesting and retrieving data from external sources.
検索性能はいくつかの異なったメカニズムを通して向上できます、キャッシュの使用を含んで、特定の検索命令を設定して。 このセクションは証明書処理システムの性能がPKIオブジェクトの検索の間に向上するかもしれないいくつかのメソッドを論じます。 処理の間一貫して非常に遅い証明書処理システムは、ユーザが嫌であり、組織に採用されるために遅くなるためにことになるでしょう。 証明書処理システムが外部電源からのデータを要求して、検索すると関連している遅れを減少させるのにおいて可能な何でもするよう奨励されます。
Cooper, et al. Informational [Page 71] RFC 4158 Certification Path Building September 2005
クーパー、他 [71ページ]情報のRFC4158証明経路ビル2005年9月
7.1. Caching
7.1. キャッシュ
Certificate processing systems operating in a non-hierarchical PKI will often need to retrieve certificates and certificate revocation lists (CRLs) from a source outside the application protocol. Typically, these objects are retrieved from an X.500 or LDAP repository, an Internet URI [RFC3986], or some other non-local source. Due to the delays associated with establishing connections as well as network transfers, certificate processing systems ought to be as efficient as possible when retrieving data from external sources. Perhaps the best way to improve retrieval efficiency is by using a caching mechanism. Certificate processing systems can cache data retrieved from external sources for some period of time, but not to exceed the useful period of the data (i.e., an expired certificate need not be cached). Although this comes at a cost of increased memory/disk consumption by the system, the cost and performance benefit of reducing network transmissions is great. Also, CRLs are often issued and available in advance of the nextUpdate date in the CRL. Implementations may wish to obtain these "fresher" CRLs before the nextUpdate date has passed.
非階層的なPKIで作動する証明書処理システムは、しばしばアプリケーション・プロトコルの外でソースからの証明書と証明書失効リスト(CRLs)を検索する必要があるでしょう。 通常、これらのオブジェクトはX.500、LDAP倉庫、インターネットURI[RFC3986]、またはある他の非地元筋から検索されます。 接続をネットワークが移されるのと同じくらいよく確立すると関連している遅れのために、外部電源からのデータを検索するとき、証明書処理システムはできるだけ効率的であるべきです。 検索効率を高める恐らく最も良い方法はキャッシュメカニズムを使用することです。 証明書処理システムはしかしデータの役に立つ期間を超えないようにいつかの期間の間に外部電源から検索されたデータをキャッシュできます(すなわち、満期の証明書はキャッシュされる必要はありません)。 これはシステムで増強されたメモリ/ディスク消費の費用で来ますが、ネットワーク送信を抑える費用と性能利益は大きいです。 また、CRLsもCRLのnextUpdate日以前、しばしば発行されていて利用可能です。 nextUpdate日付が経過する前に実装はこれらの「より新鮮な」CRLsを入手したがっているかもしれません。
There are a number of different ways in which caching can be implemented; the specifics of these methods can be used as distinguishing characteristics between certificate processing systems. However, some things that implementers may wish to consider when developing caching systems are as follows:
キャッシュを実装することができる多くの異なった方法があります。 証明書処理システムの間の特性を区別するとしてこれらのメソッドの詳細を使用できます。しかしながら、システムをキャッシュしながら展開するときimplementersが考えたがっているかもしれないいくつかのものは以下の通りです:
- If PKI objects are cached, the certification path-building
mechanism should be able to examine and retrieve from the cache
during path building. This will allow the certificate
processing system to find or eliminate one or more paths quickly
without requiring external contact with a directory or other
retrieval mechanism.
- PKIオブジェクトがキャッシュされるなら、経路を造る証明メカニズムは、経路の間、キャッシュからビルを調べて、検索するためにできるべきです。 これで、ディレクトリか他の回収機構との外部の接触を必要としないで、証明書処理システムは、すぐに1つ以上の経路を当たるか、または排除するでしょう。
- Sharing caches between multiple users (via a local area network
or LAN) may be useful if many users in one organization
consistently perform PKI operations with another organization.
- 1つの組織の多くのユーザが別の組織と共にPKI操作を一貫して実行するなら、複数のユーザ(ローカル・エリア・ネットワークかLANを通した)の間のキャッシュを共有するのは役に立つかもしれません。
- Caching not only PKI objects (such as certificates and CRLs) but
also relationships between PKI objects (storing a link between a
certificate and the issuer's certificate) may be useful. This
linking may not always lead to the most correct or best
relationship, but could represent a linking that worked in
another scenario.
- PKIオブジェクト(証明書やCRLsなどの)だけではなく、PKIオブジェクトの間の関係(証明書と発行人の証明書とのリンクを保存する)もキャッシュするのは役に立つかもしれません。 このリンクは、いつも最も正しいか最も良い関係に通じるというわけではありませんが、別のシナリオで働いていたリンクを表すかもしれません。
- Previously built paths and partial paths are quite useful to
cache, because they will provide information on previous
successes or failures. Additionally, if the cache is safe from
- 以前、組立の経路と部分的な経路はキャッシュするためにかなり役に立ちます、前の成功か失敗の情報を提供するので。 さらに、キャッシュは安全です。
Cooper, et al. Informational [Page 72] RFC 4158 Certification Path Building September 2005
クーパー、他 [72ページ]情報のRFC4158証明経路ビル2005年9月
unauthorized modifications, caching validation and signature
checking status for certificates, CRLs, and paths can also be
stored.
また、権限のない変更、証明書のために合法化と署名照合状態をキャッシュする、CRLs、および経路を保存できます。
7.2. Retrieval Order
7.2. 検索命令
To optimize efficiency, certificate processing systems are encouraged to also consider the order in which different PKI objects are retrieved, as well as the mechanism from which they are retrieved. If caching is utilized, the caches can be consulted for PKI objects before attempting other retrieval mechanisms. If multiple caches are present (such as local disk and network), the caches can be consulted in the order in which they can be expected to return their result from fastest to slowest. For example, if a certificate processing system wishes to retrieve a certificate with a particular subject DN, the system might first consult the local cache, then the network cache, and then attempt directory retrieval. The specifics of the types of retrieval mechanisms and their relative costs are left to the implementer.
効率を最適化するために、また、証明書処理システムが異なったPKIオブジェクトが検索されるオーダーを考えるよう奨励されます、それらが検索されるメカニズムと同様に。 キャッシュが利用されているなら、他の回収機構を試みる前に、PKIオブジェクトのためにキャッシュに相談できます。複数のキャッシュが存在しているなら(ローカルディスクやネットワークなどの)、最も速いのから最も遅くなるまでそれらの結果を返すとそれらを予想できるオーダーでキャッシュに相談できます。 例えば、特定の対象のDN、システムで証明書を検索するというシステム願望を処理する証明書は最初に、ローカルなキャッシュに相談するかもしれないか、そして、次に、ネットワークキャッシュとそして、試みディレクトリ検索。 回収機構のタイプとそれらの相対的なコストの詳細はimplementerに残されます。
In addition to ordering retrieval mechanisms, the certificate processing system ought to order the relative merits of the different external sources from which a PKI object can be retrieved. If the AIA is present within a certificate, with a URI [RFC3986] for the issuer's certificate, the certificate processing system (if able) may wish to attempt to retrieve the certificate first from local cache and then by using that URI (because it is expected to point directly to the desired certificate) before attempting to retrieve the certificates that may exist within a directory.
回収機構を注文することに加えて、証明書処理システムはPKIオブジェクトを検索できる異なった外部電源の優劣を注文するべきです。 AIAが発行人の証明書のために証明書の中にURI[RFC3986]について存在しているなら、証明書処理システム(できるなら)は、ディレクトリの中に存在するかもしれない証明書を検索するのを試みる前に最初にローカルなキャッシュとそして、そのURIを使用することによって証明書を検索するのを(直接必要な証明書を示すと予想されるので)試みたがっているかもしれません。
If a directory is being consulted, it may be desirable to retrieve attributes in a particular order. A highly cross-certified PKI structure will lead to multiple possibilities for certification paths, which may mean multiple validation attempts before a successful path is retrieved. Therefore, cACertificate and userCertificate (which typically contain certificates from within the same 'realm') could be consulted before attempting to retrieve the crossCertificatePair values for an entry. Alternately, all three attributes could be retrieved in one query, but cross-certificates then tagged as such and used only after exhausting the possibilities from the cACertificate attribute. The best approach will depend on the nature of the application and PKI environment.
ディレクトリが参照されているなら、特定のオーダーにおける属性を検索するのは望ましいかもしれません。 十字で非常に公認されたPKI構造は証明経路への複数の可能性につながるでしょう。(検索される前に経路は複数の合法化試みを意味するかもしれません)。 したがって、crossCertificatePair値をエントリーに検索するのを試みる前に、cACertificateとuserCertificate(同じ'分野'からの証明書を通常含む)に相談できました。 交互に、すべての3つの属性が1つの質問、しかし、cACertificate属性から次に、そういうものとしてタグ付けをされて、可能性を消耗させた後にだけ使用された交差している証明書で検索されるかもしれません。 最も良いアプローチはアプリケーションとPKI環境の本質によるでしょう。
7.3. Parallel Fetching and Prefetching
7.3. 平行なとって来るのとPrefetching
Much of this document has focused on a path-building algorithm that minimizes the performance impact of network retrievals, by preventing those retrievals and utilization of caches. Another way to improve
このドキュメントの多くがネットワークretrievalsの性能影響を最小にする経路を造るアルゴリズムに焦点を合わせました、キャッシュのそれらのretrievalsと利用を防ぐことによって。 向上する別の方法
Cooper, et al. Informational [Page 73] RFC 4158 Certification Path Building September 2005
クーパー、他 [73ページ]情報のRFC4158証明経路ビル2005年9月
performance would be to allow network retrievals to be performed in advance (prefetching) or at the same time that other operations are performed (parallel fetching). For example, if an email application receives a signed email message, it could download the required certificates and CRLs prior to the recipient viewing (or attempting to verify) the message. Implementations that provide the capability of parallel fetching and/or prefetching, along with a robust cache, can lead to greatly improved performance or user experience.
性能はネットワークretrievalsがあらかじめ(「前-とって」来る)か他の操作が実行されるのと同時(平行なとって来る)に実行されるのを許容するだろうことです。 例えば、メールアプリケーションが署名しているメールメッセージを受け取るなら、それはメッセージを見ている(または、確かめる試み)受取人の前で必要な証明書とCRLsをダウンロードするかもしれません。 強健なキャッシュと共に平行なとって来る、そして/または、「前-とって」来ることの能力を提供する実装は大いに向上した性能かユーザー・エクスペリエンスにつながることができます。
8. Security Considerations
8. セキュリティ問題
8.1. General Considerations for Building a Certification Path
8.1. 証明経路を造るための一般問題
Although certification path building deals directly with security relevant PKI data, the PKI data itself needs no special handling because its integrity is secured with the digital signature applied to it. The only exception to this is the appropriate protection of the trust anchor public keys. These are to be kept safe and obtained out of band (e.g., not from an electronic mail message or a directory) with respect to the path-building module.
証明経路ビルは直接セキュリティの関連PKIデータに対処しますが、PKIデータ自体は、デジタル署名がそれに適用されている状態で保全を保証するので、どんな特別な取り扱いも必要としません。 これへの唯一の例外は信頼アンカー公開鍵の適切な保護です。 これらは、経路を造るモジュールに関して、バンド(例えば、電子メールメッセージかディレクトリでないのからの)から安全に保たれて、得られることになっています。
The greatest security risks associated with this document revolve around performing certification path validation while certification paths are built. It is therefore noted here that fully implemented certification path validation in accordance with [RFC3280] and [X.509] is required in order for certification path building, certification path validation, and the certificate using application to be properly secured. All of the Security Considerations listed in Section 9 of [RFC3280] apply equally here.
このドキュメントに関連している最もすばらしいセキュリティ危険は、証明経路が組立している間、証明経路合法化を実行しながら、周囲を回ります。 したがって、ここに、[RFC3280]と[X.509]に従った完全に実装している証明経路合法化が適切に機密保護されるのに証明経路ビル、証明経路合法化、およびアプリケーションを使用する証明書の注文で必要であると述べられます。 [RFC3280]のセクション9に記載されたSecurity Considerationsのすべてが等しくここに適用されます。
In addition, as with any application that consumes data from potentially untrusted network locations, certification path-building components should be carefully implemented so as to reduce or eliminate the possibility of network based exploits. For example, a poorly implemented path-building module may not check the length of the CRLDP URI [RFC3986] before using the C language strcpy() function to place the address in a 1024 byte buffer. A hacker could use such a flaw to create a buffer overflow exploit by encoding malicious assembly code into the CRLDP of a certificate and then use the certificate to attempt an authentication. Such an attack could yield system level control to the attacker and expose the sensitive data the PKI was meant to protect.
さらに、潜在的に信頼されていないネットワークの位置からのデータを消費するどんなアプリケーションのようにも、経路建築部材がネットワークの可能性を減少するか、または排除するために慎重に実装されるべきである証明は功績を基礎づけました。 例えば、1024年のバイトのバッファにアドレスを置くのにC言語strcpy()機能を使用する前に、不十分に実装している経路を造るモジュールはCRLDP URI[RFC3986]の長さをチェックしないかもしれません。 ハッカーは、悪意があるアセンブリコードを証明書のCRLDPにコード化することによってバッファオーバーフロー功績を作成して、次に、認証を試みるのに証明書を使用するのにそのような欠点を使用できました。 そのような攻撃は、システムレベルコントロールを攻撃者に譲って、PKIが保護することになっていた極秘データを暴露するかもしれません。
Path building may be used to mount a denial of service (DOS) attack. This might occur if multiple simple requests could be performed that cause a server to perform a number of path developments, each taking time and resources from the server. Servers can help avoid this by limiting the resources they are willing to devote to path building,
経路ビルは、サービス(DOS)攻撃の否定を仕掛けるのに使用されるかもしれません。 サーバが多くの経路開発を実行することを引き起こしてください、サーバから時間とリソースがそれぞれかかって。サーバが、彼らが注いでも構わないと経路ビルと思っているリソースを制限することによってこれを避けるのを助けることができるという複数の簡単な要求を実行できるなら、これは起こるでしょうに。
Cooper, et al. Informational [Page 74] RFC 4158 Certification Path Building September 2005
クーパー、他 [74ページ]情報のRFC4158証明経路ビル2005年9月
and being able to further limit those resources when the load is heavy. Standard DOS protections such as systems that identify and block attackers can also be useful.
そして、さらに負荷が重いときにそれらのリソースを制限できること。 また、攻撃者を特定して、妨げるシステムなどの標準のDOS保護も役に立つ場合があります。
A DOS attack can be also created by presenting spurious CA certificates containing very large public keys. When the system attempts to use the large public key to verify the digital signature on additional certificates, a long processing delay may occur. This can be mitigated by either of two strategies. The first strategy is to perform signature verifications only after a complete path is built, starting from the trust anchor. This will eliminate the spurious CA certificate from consideration before the large public key is used. The second strategy is to recognize and simply reject keys longer than a certain size.
また、非常に大きい公開鍵を含む偽物のカリフォルニア証明書を提示することによって、DOS攻撃を作成できます。 システムが、追加証明書の上にデジタル署名について確かめるのに大きい公開鍵を使用するのを試みるとき、長い処理遅れは起こるかもしれません。 2つの戦略のどちらかはこれを緩和できます。 最初の戦略は信頼アンカーから始めて、完全な経路が組立していた後にだけ署名照合を実行することです。 大きい公開鍵が使用されている前にこれは考慮から偽物のカリフォルニア証明書を排除するでしょう。 2番目の戦略は、あるサイズより長い間キーを認識して、単に拒絶することです。
A similar DOS attack can occur with very large public keys in end entity certificates. If a system uses the public key in a certificate before building and validating that certificate's certification path, long processing delays may occur. To mitigate this threat, the public key in an end entity certificate should not be used for any purpose until a complete certification path for that certificate is built and validated.
非常に大きい公開鍵が終わりの実体証明書にある状態で、同様のDOS攻撃は起こることができます。 その証明書の証明経路を建てて、有効にする前にシステムが証明書で公開鍵を使用するなら、長い処理遅れは起こるかもしれません。 この脅威を緩和するために、その証明書のための完全な証明経路が建てられて、有効にされるまで、どんな目的にも終わりの実体証明書の公開鍵を使用するべきではありません。
8.2. Specific Considerations for Building Revocation Signer
Certification Paths
8.2. ビル取消し署名者証明経路への特定の問題
If the CRL Signer certificate (and certification path) is not identical to the Certification Authority certificate (and certification path), special care should be exercised when building the CRL Signer certification path.
CRL Signer証明経路を造るとき、CRL Signer証明書(そして、証明経路)が認証局証明書(そして、証明経路)と同じでないなら、特別な注意が行われるべきです。
If special consideration is not given to building a CRL Signer certification path, that path could be constructed such that it terminates with a different root or through a different certification path to the same root. If this behavior is not prevented, the relying party may end up checking the wrong revocation data, or even maliciously substituted data, resulting in denial of service or security breach.
特別の配慮がCRL Signer証明経路を造るのに与えられないなら、その経路は、それが異なった根で終える組み立てられたそのようなものであるか同じくらいへの異なった証明経路を通して捜すかもしれません。 この振舞いが防がれないなら、信用パーティーは結局、間違った取消しデータ、陰湿に代入されたデータ、サービスの否定をもたらすか、または機密保護違反さえチェックするかもしれません。
For example, suppose the following certification path is built for E and is valid for an example "high assurance" policy.
例えば、以下の証明経路がEで建てられて、例の「高い保証」方針に、有効であると仮定してください。
A->B->C->E
>B>C>E
When the building/validation routine attempts to verify that E is not revoked, C is referred to as the Certification Authority certificate. The path builder finds that the CRL for checking the revocation status of E is issued by C2; a certificate with the subject name "C",
ビル/合法化ルーチンが、Eが取り消されないことを確かめるのを試みると、Cは認証局証明書と呼ばれます。 経路ビルダーは、Eの取消し状態をチェックするためのCRLがC2によって発行されるのがわかります。 対象の名前「C」がある証明書
Cooper, et al. Informational [Page 75] RFC 4158 Certification Path Building September 2005
クーパー、他 [75ページ]情報のRFC4158証明経路ビル2005年9月
but with a different key than the key that was used to sign E. C2 is referred to as the CRL Signer. An unrestrictive certification path builder might then build a path such as the following for the CRL Signer C2 certificate:
E. C2に署名するのに使用されたキーがCRL Signerと呼ばれるのと異なったキー、。 次に、「非-限定語」証明経路ビルダーはCRL Signer C2証明書のための以下として経路にそのようなものを建てるかもしれません:
X->Y->Z->C2
X>Y>Z>、C2
If a path such as the one above is permitted, nothing can be concluded about the revocation status of E since C2 is a different CA from C.
上のものなどの経路が受入れられるなら、C2がCからの異なったカリフォルニアであるので、Eの取消し状態で何も結論づけることができません。
Fortunately, preventing this security problem is not difficult and the solution also makes building CRL Signer certification paths very efficient. In the event the CRL Signer certificate is identical to the Certification Authority certificate, the Certification Authority certification path should be used to verify the CRL; no additional path building is required. If the CRL Signer certificate is not identical to the Certification Authority certificate, a second path should be built for the CRL Signer certificate in exactly the same fashion as for any certificate, but with the following additional guidelines:
幸い、この警備上の問題を防ぐのは難しくはありません、そして、また、ソリューションで、ビルCRL Signer証明経路は非常に効率的になります。 イベントが、CRL Signer証明書は認証局証明書と同じである、認証局証明経路はCRLについて確かめるのに使用されるべきです。 どんな追加経路ビルも必要ではありません。 CRL Signer証明書が認証局証明書と同じでないなら、2番目の経路はまさに同じファッションによるCRL Signer証明書のためにどんな証明書のようにも建てられますが、以下の別途ガイドラインで建てられるべきです:
1. Trust Anchor: The CRL Signer's certification path should start
with the same trust anchor as the Certification Authority's
certification path. Any trust anchor certificate with a subject
DN matching that of the Certification Authority's trust anchor
should be considered acceptable though lower in priority than the
one with a matching public key and subject DN. While different
trust anchor public keys are acceptable at the beginning of the
CRL signer's certification path and the Certification Authority's
certification path, both keys must be trusted by the relying
party per the recommendations in Section 8.1.
1. 信頼は投錨されます: CRL Signerの証明経路は認証局の証明経路と同じ信頼アンカーから始まるべきです。 優先権で合っている公開鍵と対象のDNがあるものより低いのですが、対象のDNが認証局の信頼アンカーのものに合っているどんな信頼アンカー証明書も許容できると考えられるべきです。 異なった信頼アンカー公開鍵がCRL署名者の証明経路と認証局の証明経路の始めに許容できる間、1推薦あたりの信用パーティーはセクション8.1で両方のキーを信じなければなりません。
2. CA Name Matching: The subject DNs for all CA certificates in the
two certification paths should match on a one-to-one basis
(ignoring self-issued certificates) for the entire length of the
shorter of the two paths.
2. カリフォルニアの名前マッチング: 2つの証明経路のすべてのカリフォルニア証明書のための対象のDNsは二人のうち背が低い方経路の全長の1〜1個のベース(自己によって発行された証明書を無視する)で合っているはずです。
3. CRL Signer Certification Path Length: The length of the CRL
Signer certification path (ignoring self-issued certificates)
should be equal to or less than the length of the Certification
Authority certification path plus (+) one. This allows a given
Certification Authority to issue a certificate to a
delegated/subordinate CRL Signer. The latter configuration
represents the maximum certification path length for a CRL Signer
certificate.
3. CRL署名者証明経路の長さ: CRL Signer証明経路(自己によって発行された証明書を無視する)の長さは認証局証明経路プラス(+)の長さより等しいか少ない1であるべきです。 これで、与えられた認証局は代表として派遣されたか下位のCRL Signerに証明書を下付します。 後者の構成はCRL Signer証明書のために最大の証明経路の長さを表します。
Cooper, et al. Informational [Page 76] RFC 4158 Certification Path Building September 2005
クーパー、他 [76ページ]情報のRFC4158証明経路ビル2005年9月
The reasoning behind the first guideline is readily apparent. Lacking this and the second guideline, any trusted CA could issue CRLs for any other CA, even if the PKIs are not related in any fashion. For example, one company could revoke certificates issued by another company if the relying party trusted the trust anchors from both companies. The two guidelines also prevent erroneous CRL checks since Global uniqueness of names is not guaranteed.
最初のガイドラインの後ろの推理は容易に明らかです。 これを欠いて、2番目のガイドライン、どんな信じられたカリフォルニアもいかなる他のカリフォルニアにもCRLsを発行できました、PKIsがどんなファッションでも関係づけられないでも。 例えば、1つの会社が信用パーティーが両社から信頼アンカーを信じたなら別の会社によって発行された証明書を取り消すことができました。 また、名前のGlobalのユニークさが保証されないので、2つのガイドラインが誤ったCRLチェックを防ぎます。
The second guideline prevents roaming certification paths such as the previously described example CRL Signer certification path for A->B->C->E. It is especially important that the "ignoring self- issued certificates" is implemented properly. Self-issued certificates are cast out of the one-to-one name comparison in order to allow for key rollover. The path-building algorithm may be optimized to only consider certificates with the acceptable subject DN for the given point in the CRL Signer certification path while building the path.
2番目のガイドラインは、A>B>C>Eのための以前に説明された例のCRL Signer証明経路などの証明経路に移動するのを防ぎます。 「自己を無視証明書が発行されたすること」が適切に実装されるのは、特に重要です。 自己によって発行された証明書は、主要なロールオーバーを考慮するために比較という1〜1つの名前まで投げかけられます。経路を造るアルゴリズムは、経路を造っている間、証明書をCRL Signer証明経路の与えられたポイント単位で許容できる対象のDNと共に考えるだけであるために最適化されるかもしれません。
The third and final guideline ensures that the CRL used is the intended one. Without a restriction on the length of the CRL Signer certification path, the path could roam uncontrolled into another domain and still meet the first two guidelines. For example, again using the path A->B->C->E, the Certification Authority C, and a CRL Signer C2, a CRL Signer certification path such as the following could pass the first two guidelines:
3番目の、そして、最終的なガイドラインは、使用されるCRLが意図しているものであることを確実にします。 CRL Signer証明経路の長さにおける制限がなければ、経路は、別のドメインに非制御の状態で移動して、最初の2つのガイドラインをまだ満たしているかもしれません。 例えば、再び経路A>B>C>E、認証局C、およびCRL Signer C2を使用することでの以下が最初の2つのガイドラインを向かわせるかもしれないCRL Signer証明経路:
A->B->C->D->X->Y->RogueCA->C2
1>のB>C>D>X>Y>、RogueCA->、C2
In the preceding example, the trust anchor is identical for both paths and the one-to-one name matching test passes for A->B->C. However, accepting such a path has obvious security consequences, so the third guideline is used to prevent this situation. Applying the second and third guideline to the certification path above, the path builder could have immediately detected this path was not acceptable (prior to building it) by examining the issuer DN in C2. Given the length and name guidelines, the path builder could detect that "RogueCA" is not in the set of possible names by comparing it to the set of possible CRL Signer issuer DNs, specifically, A, B, or C.
前の例では、両方の経路に、信頼アンカーは同じです、そして、配偶法という1〜1つの名前がA>B>Cに適用します。 しかしながら、そのような経路を受け入れるのにおいて明白なセキュリティ結果があるので、3番目のガイドラインはこの状況を防ぐのに使用されます。 上では、経路ビルダーがすぐに検出したかもしれない証明経路に2番目と3番目のガイドラインを適用して、この経路が発行人DNを試験することによって許容できる(それを建てる前の)C2ではありませんでした。 ガイドラインという長さと名前を考えて、それを突き合わせて可能な名前のセットに明確に可能なCRL Signer発行人DNs、A、B、またはCのセットには"RogueCA"がいない経路ビルダーは検出できました。
Similar consideration should be given when building the path for the OCSP Responder certificate when the CA is the OCSP Response Signer or the CA has delegated the OCSP Response signing to another entity.
カリフォルニアがOCSP Response SignerであるかカリフォルニアがOCSP Response署名を別の実体へ代表として派遣したとき、OCSP Responder証明書のために経路を造るとき、同様の考慮を払うべきです。
Cooper, et al. Informational [Page 77] RFC 4158 Certification Path Building September 2005
クーパー、他 [77ページ]情報のRFC4158証明経路ビル2005年9月
9. Acknowledgements
9. 承認
The authors extend their appreciation to David Lemire for his efforts coauthoring "Managing Interoperability in Non-Hierarchical Public Key Infrastructures" from which material was borrowed heavily for use in the introductory sections.
作者は彼の取り組みのための「非階層的な公開鍵暗号基盤の相互運用性を管理します」について共同執筆する材料が使用に紹介しているセクションで大いに借りられたデヴィッドLemireに彼らの感謝を与えます。
This document has also greatly benefited from the review and additional technical insight provided by Dr. Santosh Chokhani, Carl Wallace, Denis Pinkas, Steve Hanna, Alice Sturgeon, Russ Housley, and Tim Polk.
また、このドキュメントは大いにSantosh Chokhani博士、カール・ウォレス、デニス・ピンカス、スティーブ・ハンナ、アリス・スタージャン、ラスHousley、およびティム・ポークによって提供されたレビューと追加技術的な洞察の利益を得ました。
10. Normative References
10. 引用規格
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
11. Informative References
11. 有益な参照
[MINHPKIS] Hesse, P., and D. Lemire, "Managing Interoperability in
Non-Hierarchical Public Key Infrastructures", 2002
Conference Proceedings of the Internet Society Network
and Distributed System Security Symposium, February 2002.
[MINHPKIS] ヘッセ、P.、およびD.Lemire、「非階層的な公開鍵暗号基盤で相互運用性を管理します」、インターネット協会ネットワークと分散システムセキュリティシンポジウムの2002の会議の議事録(2002年2月)。
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", RFC 1777, March 1995.
[RFC1777] YeongとW.とハウズ、T.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[RFC2587] Boeyen, S., Howes, T., and P. Richard, "Internet X.509
Public Key Infrastructure LDAPv2 Schema", RFC 2587, June
1999.
[RFC2587] BoeyenとS.とハウズ、T.とP.リチャード、「インターネットX.509公開鍵暗号基盤LDAPv2図式」、RFC2587、1999年6月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3377] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。
[RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M.
Thompson, "Internet X.509 Public Key Infrastructure (PKI)
Proxy Certificate Profile", RFC 3820, June 2004.
[RFC3820] Tuecke、S.、ウェルチ、V.、Engert、D.、パールマン、L.、およびM.トンプソン、「インターネットX.509公開鍵暗号基盤(PKI)プロキシ証明書プロフィール」、RFC3820(2004年6月)。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
Cooper, et al. Informational [Page 78] RFC 4158 Certification Path Building September 2005
クーパー、他 [78ページ]情報のRFC4158証明経路ビル2005年9月
[X.501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X.501]ITU-T推薦X.501: 情報技術--オープン・システム・インターコネクション--ディレクトリ: モデル、1993。
[X.509] ITU-T Recommendation X.509 (2000 E): Information
Technology - Open Systems Interconnection - The
Directory: Authentication Framework, March 2000.
[X.509]ITU-T推薦X.509(2000E): 情報技術--オープン・システム・インターコネクション--ディレクトリ: 2000年3月の認証フレームワーク。
[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Lists (CRL) Profile", RFC 3279, April 2002.
[PKIXALGS]Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤のためのアルゴリズムと識別子は、リスト(CRL)が輪郭を描く取消しを証明して、証明します」、RFC3279、2002年4月。
[CERTSTORE] P. Gutmann, "Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via
HTTP", Work in Progress, August 2004.
[CERTSTORE]P.ガットマン、「インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル:」 「HTTPを通した証明書ストアAccess」、Progress、2004年8月のWork。
Cooper, et al. Informational [Page 79] RFC 4158 Certification Path Building September 2005
クーパー、他 [79ページ]情報のRFC4158証明経路ビル2005年9月
Authors' Addresses
作者のアドレス
Matt Cooper Orion Security Solutions, Inc. 1489 Chain Bridge Rd, Ste. 300 McLean, VA 22101, USA
1489年のマット桶屋オリオンセキュリティソリューションInc.鎖吊橋、第Ste。 300 ヴァージニア 22101、マクリーン(米国)
Phone: +1-703-917-0060 EMail: mcooper@orionsec.com
以下に電話をしてください。 +1-703-917-0060 メールしてください: mcooper@orionsec.com
Yuriy Dzambasow A&N Associates, Inc. 999 Corporate Blvd Ste. 100 Linthicum, MD 21090, USA
ユーリーDzambasow A&NはInc.999の法人のBlvd Steを関連づけます。 100 Linthicum、MD 21090、米国
Phone: +1-410-859-5449 x107 EMail: yuriy@anassoc.com
以下に電話をしてください。 +1-410-859-5449 x107 EMail: yuriy@anassoc.com
Peter Hesse Gemini Security Solutions, Inc. 4451 Brookfield Corporate Dr. Ste. 200 Chantilly, VA 20151, USA
ピーターヘッセ双子座セキュリティソリューションInc.4451ブルックフィールドの法人のSte博士。 200 シャンティイ、ヴァージニア 20151、米国
Phone: +1-703-378-5808 x105 EMail: pmhesse@geminisecurity.com
以下に電話をしてください。 +1-703-378-5808 x105 EMail: pmhesse@geminisecurity.com
Susan Joseph Van Dyke Technologies 6716 Alexander Bell Drive Columbia, MD 21046
スーザンジョゼフヴァンダイクTechnologies6716アレキサンダー・グラハム・ベル・Driveコロンビア、MD 21046
EMail: susan.joseph@vdtg.com
メール: susan.joseph@vdtg.com
Richard Nicholas BAE Systems Information Technology 141 National Business Parkway, Ste. 210 Annapolis Junction, MD 20701, USA
リチャードニコラスBAE Systemsの情報技術141の国家のビジネスパークウェイ、Ste。 210アナポリス合流点、MD 20701、米国
Phone: +1-301-939-2722 EMail: richard.nicholas@it.baesystems.com
以下に電話をしてください。 +1-301-939-2722 メールしてください: richard.nicholas@it.baesystems.com
Cooper, et al. Informational [Page 80] RFC 4158 Certification Path Building September 2005
クーパー、他 [80ページ]情報のRFC4158証明経路ビル2005年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cooper, et al. Informational [Page 81]
クーパー、他 情報[81ページ]
一覧
スポンサーリンク
