[要約] RFC 3820は、インターネットX.509公開鍵基盤（PKI）プロキシ証明書プロファイルに関する規格です。このRFCの目的は、PKIプロキシ証明書の機能と要件を定義し、PKIプロキシのセキュリティと相互運用性を向上させることです。
Network Working Group S. Tuecke
Request for Comments: 3820 ANL
Category: Standards Track V. Welch
NCSA
D. Engert
ANL
L. Pearlman
USC/ISI
M. Thompson
LBNL
June 2004
Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile
インターネットX.509公開キーインフラストラクチャ（PKI）プロキシ証明書プロファイル
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system.
このドキュメントは、インターネットで使用するためにRFC 3280で定義されているX.509公開キーインフラストラクチャ（PKI）証明書に基づいて、プロキシ証明書の証明書プロファイルを形成します。プロキシ証明書という用語は、PKIベースの認証システム内で制限されたプロキシおよび委任を提供する目的で、通常のX.509公開キーエンドエンティティ証明書から派生し、署名された証明書または署名された証明書を記述するために使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5
2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7
2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8
2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9
2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10
3. Certificate and Certificate Extensions Profile . . . . . . . . 12
3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13
3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13
3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19
4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23
5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Relationship to Attribute Certificates . . . . . . . . . 24
5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28
5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30
6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31
6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31
6.4. Protecting Against Denial of Service with Key Generation 32
6.5. Use of Proxy Certificates in a Central Repository. . . . 32
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37
Use of a proxy credential [i7] is a common technique used in security systems to allow entity A to grant to another entity B the right for B to be authorized with others as if it were A. In other words, entity B is acting as a proxy on behalf of entity A. This document forms a certificate profile for Proxy Certificates, based on the RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" [n2].
プロキシ資格情報の使用[i7]は、セキュリティシステムで使用される一般的な手法であり、エンティティAが別のエンティティBに他のエンティティBを許可することを可能にします。エンティティAに代わってプロキシ。このドキュメントは、RFC 3280、「インターネットX.509公開キーインフラストラクチャ証明書とCRLプロファイル」に基づいて、プロキシ証明書の証明書プロファイルを形成します[N2]。
In addition to simple, unrestricted proxying, this profile defines:
シンプルで無制限のプロキシに加えて、このプロファイルは次のとおりです。
* A framework for carrying policies in Proxy Certificates that allows proxying to be limited (perhaps completely disallowed) through either restrictions or enumeration of rights.
* 制限または権利の列挙のいずれかを通じて、プロキシを制限する（おそらく完全に許可されていない）プロキシ証明書にポリシーを運ぶためのフレームワーク。
* Proxy Certificates with unique names, derived from the name of the end entity certificate name. This allows the Proxy Certificates to be used in conjunction with attribute assertion approaches such as Attribute Certificates [i3] and have their own rights independent of their issuer.
* End Entity証明書名の名前から派生した一意の名前を持つプロキシ証明書。これにより、プロキシ証明書を属性証明書[I3]などの属性アサーションアプローチと組み合わせて使用し、発行者とは独立した独自の権利を持つことができます。
Section 2 provides a non-normative overview of the approach. It begins by defining terminology, motivating Proxy Certificates, and giving a brief overview of the approach. It then introduces the notion of a Proxy Issuer, as distinct from a Certificate Authority, to describe how end entity signing of a Proxy Certificate is different from end entity signing of another end entity certificate, and therefore why this approach does not violate the end entity signing restrictions contained in the X.509 keyCertSign field of the keyUsage extension. It then continues with discussions of how subject names are used by this proxying approach, and features of this approach.
セクション2では、アプローチの非規範的な概要を説明します。それは、用語を定義し、プロキシ証明書を動機付け、アプローチの簡単な概要を示すことから始めます。次に、証明書の権限とは異なるプロキシ発行者の概念を導入して、プロキシ証明書の最終エンティティの署名が別の最終エンティティ証明書に署名する最終エンティティとどのように異なるかを説明します。したがって、このアプローチが最終エンティティに違反しない理由KeyUSAGE拡張のX.509 KeyCertSignフィールドに含まれる制限署名。次に、このプロキシアプローチとこのアプローチの特徴によって、サブジェクト名がどのように使用されるかについての議論を続けます。
Section 3 defines requirements on information content in Proxy Certificates. This profile addresses two fields in the basic certificate as well as five certificate extensions. The certificate fields are the subject and issuer fields. The certificate extensions are subject alternative name, issuer alternative name, key usage, basic constraints, and extended key usage. A new certificate extension, Proxy Certificate Information, is introduced.
セクション3では、プロキシ証明書の情報コンテンツに関する要件を定義します。このプロファイルは、基本証明書の2つのフィールドと5つの証明書拡張機能に対応しています。証明書フィールドは、主題および発行者フィールドです。証明書拡張は、対象の代替名、発行者の代替名、キー使用、基本的な制約、および拡張キー使用法です。新しい証明書延長、プロキシ証明書情報が導入されています。
Section 4 defines path validation rules for Proxy Certificates.
セクション4では、プロキシ証明書のパス検証ルールを定義します。
Section 5 provides non-normative commentary on Proxy Certificates.
セクション5では、プロキシ証明書に関する非規範的な解説を示します。
Section 6 discusses security considerations relating to Proxy Certificates.
セクション6では、プロキシ証明書に関連するセキュリティ上の考慮事項について説明します。
References, listed in Section 8, are sorted into normative and information references. Normative references, listed in Section 8.1, are in the form [nXX]. Informative references, listed in Section 8.2, are in the form [iXX].
セクション8にリストされている参照は、規範的および情報参照に分類されます。セクション8.1にリストされている規範的参照は、[nxx]の形式です。セクション8.2にリストされている有益な参照は、[IXX]の形式です。
Section 9 contains acknowledgements.
セクション9には謝辞が含まれています。
Following Section 9, contains the Appendix, the contact information for the authors, the intellectual property information, and the copyright information for this document.
セクション9に従って、付録、著者の連絡先情報、知的財産情報、およびこのドキュメントの著作権情報が含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [n1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [N1]に記載されているように解釈される。
This section provides non-normative commentary on Proxy Certificates.
このセクションでは、プロキシ証明書に関する非規範的な解説を提供します。
The goal of this specification is to develop a X.509 Proxy Certificate profile and to facilitate their use within Internet applications for those communities wishing to make use of restricted proxying and delegation within an X.509 Public Key Infrastructure (PKI) authentication based system.
この仕様の目標は、X.509プロキシ証明書プロファイルを開発し、X.509公開キーインフラストラクチャ（PKI）認証ベースのシステム内で制限されたプロキシおよび委任を使用したいコミュニティのインターネットアプリケーション内での使用を促進することです。
This section provides relevant background, motivation, an overview of the approach, and related work.
このセクションでは、関連する背景、動機付け、アプローチの概要、および関連する作業を提供します。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
* CA: A "Certification Authority", as defined by X.509 [n2]
* CA：X.509 [N2]で定義されている「認証機関」
* EEC: An "End Entity Certificate", as defined by X.509. That is, it is an X.509 Public Key Certificate issued to an end entity, such as a user or a service, by a CA.
* EEC：X.509で定義されている「End Entity証明書」。つまり、CAによって、ユーザーやサービスなどの最終エンティティに発行されたX.509公開証明書です。
* PKC: An end entity "Public Key Certificate". This is synonymous with an EEC.
* PKC：終了エンティティ「公開鍵証明書」。これはEECと同義です。
* PC: A "Proxy Certificate", the profile of which is defined by this document.
* PC：「プロキシ証明書」、そのプロファイルはこのドキュメントで定義されています。
* PI: A "Proxy Issuer" is an entity with an End Entity Certificate or Proxy Certificate that issues a Proxy Certificate. The Proxy Certificate is signed using the private key associated with the public key in the Proxy Issuer's certificate.
* PI：「プロキシ発行者」は、プロキシ証明書を発行するEnd Entity証明書またはプロキシ証明書を備えたエンティティです。プロキシ証明書は、プロキシ発行者の証明書の公開キーに関連付けられた秘密鍵を使用して署名されます。
* AC: An "Attribute Certificate", as defined by "An Internet Attribute Certificate Profile for Authorization" [i3].
* AC：「承認のためのインターネット属性証明書プロファイル」[I3]で定義されている「属性証明書」。
* AA: An "Attribute Authority", as defined in [i3].
* AA：[i3]で定義されている「属性権限」。
Computational and Data "Grids" have emerged as a common approach to constructing dynamic, inter-domain, distributed computing environments. As explained in [i5], large research and development efforts starting around 1995 have focused on the question of what protocols, services, and APIs are required for effective, coordinated use of resources in these Grid environments.
計算およびデータの「グリッド」は、動的なドメイン間分散コンピューティング環境を構築するための一般的なアプローチとして浮上しています。[i5]で説明されているように、1995年頃から始まる大規模な研究開発の取り組みは、これらのグリッド環境でのリソースの効果的で調整された使用に必要なプロトコル、サービス、およびAPIの問題に焦点を当てています。
In 1997, the Globus Project (www.globus.org) introduced the Grid Security Infrastructure (GSI) [i4]. This library provides for public key based authentication and message protection, based on standard X.509 certificates and public key infrastructure, the SSL/TLS protocol [i2], and delegation using proxy certificates similar to those profiled in this document. GSI has been used, in turn, to build numerous middleware libraries and applications, which have been deployed in large-scale production and experimental Grids [i1]. GSI has emerged as the dominant security solution used by Grid efforts worldwide.
1997年、Globus Project（www.globus.org）は、グリッドセキュリティインフラストラクチャ（GSI）[I4]を導入しました。このライブラリは、標準のX.509証明書と公開キーインフラストラクチャ、SSL/TLSプロトコル[I2]、およびこのドキュメントでプロファイルされたものと同様のプロキシ証明書を使用した代表団に基づいて、公開キーベースの認証とメッセージ保護を提供します。GSIは、大規模な生産および実験用グリッドで展開されている多数のミドルウェアライブラリとアプリケーションを構築するために使用されています[I1]。GSIは、世界中のグリッドの取り組みで使用される支配的なセキュリティソリューションとして浮上しています。
This experience with GSI has proven the viability of restricted proxying as a basis for authorization within Grids, and has further proven the viability of using X.509 Proxy Certificates, as defined in this document, as the basis for that proxying. This document is one part of an effort to migrate this experience with GSI into standards, and in the process clean up the approach and better reconcile it with existing and recent standards.
GSIのこの経験は、グリッド内の承認の基礎として制限されたプロキシの実行可能性を証明しており、このドキュメントで定義されているように、そのプロキシの基礎としてX.509プロキシ証明書を使用する可能性をさらに証明しています。このドキュメントは、この経験をGSIで標準に移行し、その過程でアプローチをクリーンアップし、既存および最近の標準とより適切に調整するための取り組みの一部です。
A motivating example will assist in understanding the role proxying can play in building Internet based applications.
やる気を起こさせる例は、インターネットベースのアプリケーションの構築においてプロキシが果たすことができる役割を理解するのに役立ちます。
Steve is an engineer who wants to use a reliable file transfer service to manage the movement of a number of large files around between various hosts on his company's Intranet-based Grid. From his laptop he wants to submit a number of transfer requests to the service and have the files transferred while he is doing other things, including being offline. The transfer service may queue the requests for some time (e.g., until after hours or a period of low resource usage) before initiating the transfers. The transfer service will then, for each file, connect to each of the source and destination hosts, and instruct them to initiate a data connection directly from the source to the destination in order to transfer the file. Steve will leave an agent running on his laptop that will periodically check on progress of the transfer by contacting the transfer service. Of course, he wants all of this to happen securely on his company's resources, which requires that he initiate all of this using his PKI smartcard.
Steveは、信頼できるファイル転送サービスを使用して、会社のイントラネットベースのグリッド上のさまざまなホスト間の多くの大きなファイルの動きを管理したいエンジニアです。彼のラップトップから、彼は多くの転送要求をサービスに送信し、オフラインであるなど、他のことをしている間にファイルを転送したいと考えています。転送サービスは、転送を開始する前に、しばらくの間（たとえば、リソース使用量が少ない時間まで）、リクエストをキューに誘うことができます。転送サービスは、各ファイルについて、各ファイルと宛先ホストに接続し、ファイルを転送するためにソースから宛先に直接データ接続を開始するように指示します。スティーブは、転送サービスに連絡して転送の進捗状況を定期的にチェックするラップトップを走っているエージェントを残します。もちろん、彼はこれらすべてが彼の会社のリソースでしっかりと起こることを望んでいます。
This scenario requires authentication and delegation in a variety of places:
このシナリオには、さまざまな場所での認証と委任が必要です。
* Steve needs to be able to mutually authenticate with the reliable file transfer service to submit the transfer request.
* Steveは、送金リクエストを送信するために、信頼できるファイル転送サービスで相互に認証できる必要があります。
* Since the storage hosts know nothing about the file transfer service, the file transfer service needs to be delegated the rights to mutually authenticate with the various storage hosts involved directly in the file transfer, in order to initiate the file transfer.
* ストレージホストはファイル転送サービスについて何も知らないため、ファイル転送を開始するために、ファイル転送に直接関係するさまざまなストレージホストと相互に認証する権利を委任する必要があります。
* The source and destination hosts of a particular transfer must be able to mutual authenticate with each other, to ensure the file is being transferred to and from the proper parties.
* 特定の転送のソースと宛先のホストは、ファイルが適切な関係者との間で転送されていることを確認するために、相互に認証することができなければなりません。
* The agent running on Steve's laptop must mutually authenticate with the file transfer service in order to check the result of the transfers.
* スティーブのラップトップで実行されているエージェントは、転送の結果を確認するために、ファイル転送サービスで相互に認証する必要があります。
Proxying is a viable approach to solving two (related) problems in this scenario:
プロキシは、このシナリオで2つの（関連）問題を解決するための実行可能なアプローチです。
* Single sign-on: Steve wants to enter his smartcard password (or pin) once, and then run a program that will submit all the file transfer requests to the transfer service, and then periodically check on the status of the transfer. This program needs to be given the rights to be able to perform all of these operations securely, without requiring repeated access to the smartcard or Steve's password.
* シングルサインオン：Steveは、スマートカードパスワード（またはPIN）を1回入力し、すべてのファイル転送リクエストを転送サービスに送信するプログラムを実行し、転送のステータスを定期的に確認したいと考えています。このプログラムには、SmartCardやSteveのパスワードへの繰り返しのアクセスを必要とせずに、これらすべての操作を安全に実行できる権利を与える必要があります。
* Delegation: Various remote processes in this scenario need to perform secure operations on Steve's behalf, and therefore must be delegated the necessary rights. For example, the file transfer service needs to be able to authenticate on Steve's behalf with the source and destination hosts, and must in turn delegate rights to those hosts so that they can authenticate with each other.
* 委任：このシナリオのさまざまなリモートプロセスは、スティーブに代わって安全な操作を実行する必要があるため、必要な権利を委任する必要があります。たとえば、ファイル転送サービスは、Steveに代わってソースおよび宛先ホストとともに認証できる必要があり、互いに認証できるように、それらのホストに権利を委任する必要があります。
Proxying can be used to secure all of these interactions:
プロキシを使用して、これらすべての相互作用を確保することができます。
* Proxying allows for the private key stored on the smartcard to be accessed just once, in order to create the necessary proxy credential, which allows the client/agent program to be authorized as Steve when submitting the requests to the transfer service. Access to the smartcard and Steve's password is not required after the initial creation of the proxy credential.
* プロキシを使用すると、スマートカードに保存されている秘密鍵を1回だけアクセスできます。これにより、必要なプロキシ資格情報を作成することができます。SmartCardとSteveのパスワードへのアクセスは、プロキシ資格情報の最初の作成後は必要ありません。
* The client program on the laptop can delegate to the file transfer service the right to act on Steve's behalf. This, in turn, allows the service to authenticate to the storage hosts and inherit Steve's privileges in order to start the file transfers.
* ラップトップ上のクライアントプログラムは、ファイル転送サービスに委任し、スティーブに代わって行動する権利を委任できます。これにより、ファイル転送を開始するために、サービスがストレージホストに認証され、Steveの特権を継承することができます。
* When the transfer service authenticates to hosts to start the file transfer, the service can delegate to the hosts the right to act on Steve's behalf so that each pair of hosts involved in a file transfer can mutually authenticate to ensure the file is securely transferred.
* 転送サービスがホストに認証されてファイル転送を開始すると、ファイル転送に関与する各ホストのペアが相互に認証できるように、ファイルが安全に転送されるように、サービスはスティーブに代わって行動する権利をホストに委任できます。
* When the agent on the laptop reconnects to the file transfer service to check on the status of the transfer, it can perform mutual authentication. The laptop may use a newly generated proxy credential, which is just created anew using the smartcard.
* ラップトップのエージェントがファイル転送サービスに再接続して転送のステータスを確認すると、相互認証を実行できます。ラップトップは、新しく生成されたプロキシ資格情報を使用する場合があります。これは、SmartCardを使用して新たに作成されたばかりです。
This scenario, and others similar to it, is being built today within the Grid community. The Grid Security Infrastructure's single sign-on and delegation capabilities, built on X.509 Proxy Certificates, are being employed to provide authentication services to these applications.
このシナリオ、およびそれに似た他のシナリオは、今日グリッドコミュニティ内で構築されています。X.509プロキシ証明書に基づいて構築されたグリッドセキュリティインフラストラクチャのシングルサインオンおよび委任機能は、これらのアプリケーションに認証サービスを提供するために採用されています。
One concern that arises is what happens if a machine that has been delegated the right to inherit Steve's privileges has been compromised? For example, in the above scenario, what if the machine running the file transfer service is compromised, such that the attacker can gain access to the credential that Steve delegated to that service? Can the attacker now do everything that Steve is allowed to do?
発生する懸念の1つは、スティーブの特権を継承する権利を委任されたマシンが妥協した場合に何が起こるかということです。たとえば、上記のシナリオでは、ファイル転送サービスを実行しているマシンが侵害され、攻撃者がスティーブがそのサービスに委任した資格情報にアクセスできるようにした場合はどうなりますか？攻撃者は今、スティーブが許可されていることすべてをすることができますか？
A solution to this problem is to allow for restrictions to be placed on the proxy by means of policies on the proxy certificates. For example, the machine running the reliable file transfer service in the above example might only be given Steve's right for the purpose of reading the source files and writing the destination files. Therefore, if that file transfer service is compromised, the attacker cannot modify source files, cannot create or modify other files to which Steve has access, cannot start jobs on behalf of Steve, etc. All that an attacker would be able to do is read the specific files to which the file transfer service has been delegated read access, and write bogus files in place of those that the file transfer service has been delegated write access. Further, by limiting the lifetime of the credential that is delegated to the file transfer service, the effects of a compromise can be further mitigated.
この問題の解決策は、プロキシ証明書のポリシーによってプロキシに制限を設定できるようにすることです。たとえば、上記の例で信頼できるファイル転送サービスを実行しているマシンには、ソースファイルを読み取り、宛先ファイルの書き込みを目的として、Steveの権利が与えられる場合があります。したがって、そのファイル転送サービスが侵害された場合、攻撃者はソースファイルを変更できず、Steveがアクセスできる他のファイルを作成または変更できず、Steveに代わってジョブを開始できません。攻撃者ができることはすべて読まれますファイル転送サービスが委任された特定のファイルは、アクセスを読み取り、ファイル転送サービスが委任された書き込みアクセスの代わりに偽のファイルを書き込みます。さらに、ファイル転送サービスに委任される資格情報の寿命を制限することにより、妥協の効果をさらに軽減できます。
Other potential uses for restricted proxy credentials are discussed in [i7].
制限されたプロキシ資格情報の他の潜在的な用途については、[i7]で説明されています。
The dynamic creation of entities (e.g., processes and services) is an essential part of Grid computing. These entities will require rights in order to securely perform their function. While it is possible to obtain rights solely through proxying as described in previous sections, this has limitations. For example what if an entity should have rights that are granted not just from the proxy issuer but from a third party as well? While it is possible in this case for the entity to obtain and hold two proxy certifications, in practice it is simpler for subsequent credentials to take the form of attribute certificates.
エンティティの動的な作成（プロセスやサービスなど）は、グリッドコンピューティングの重要な部分です。これらのエンティティは、機能を安全に実行するために権利を必要とします。前のセクションで説明されているように、プロキシのみを通じて権利を取得することは可能ですが、これには制限があります。たとえば、エンティティがプロキシ発行者だけでなく、サードパーティからも付与される権利を持つ必要がある場合はどうなりますか？この場合、エンティティは2つのプロキシ認定を取得して保持することが可能ですが、実際には、その後の資格情報が属性証明書の形を取得する方が簡単です。
It is also desirable for these entities to have a unique identity so that they can be explicitly discussed in policy statements. For example, a user initiating a third-party FTP transfer could grant each FTP server a PC with a unique identity and inform each server of the identity of the other, then when the two servers connected they could authenticate themselves and know they are connected to the proper party.
また、これらのエンティティは、ポリシーステートメントで明示的に議論できるように、独自のアイデンティティを持つことも望ましいです。たとえば、サードパーティのFTP転送を開始するユーザーは、各FTPサーバーに一意のIDを付与し、各サーバーに他のサーバーを通知することができます。適切なパーティー。
In order for a party to have rights of it's own it requires a unique identity. Possible options for obtaining an unique identity are:
当事者が独自の権利を持つためには、独自のアイデンティティが必要です。ユニークなアイデンティティを取得するための可能なオプションは次のとおりです。
1) Obtain an identity from a traditional Certification Authority (CA).
1) 従来の認証機関（CA）から身元を取得します。
2) Obtain a new identity independently - for example by using the generated public key and a self-signed certificate.
2) たとえば、生成された公開キーと自己署名証明書を使用して、独立して新しいIDを取得します。
3) Derive the new identity from an existing identity.
3) 既存のアイデンティティから新しいアイデンティティを導き出します。
In this document we describe an approach to option #3, because:
このドキュメントでは、オプション＃3へのアプローチについて説明します。
* It is reasonably light-weight, as it can be done without interacting with a third party. This is important when creating identities dynamically.
* サードパーティとやり取りすることなく行うことができるため、合理的に軽量です。これは、アイデンティティを動的に作成するときに重要です。
* As described in the previous section, a common use for PCs is for restricted proxying, so deriving their identity from the identity of the EEC makes this straightforward. Nonetheless there are circumstances where the creator does not wish to delegate all or any of its rights to a new entity. Since the name is unique, this is easily accomplished by #3 as well, by allowing the application of a policy to limit proxying.
* 前のセクションで説明したように、PCの一般的な使用は制限されたプロキシであるため、EECのアイデンティティから身元を導き出すことはこれを簡単にします。それにもかかわらず、作成者がそのすべてまたはその権利を新しいエンティティに委任したくない状況があります。名前は一意であるため、これは＃3によっても簡単に実現できます。ポリシーの適用がプロキシを制限することを許可します。
This document defines an X.509 "Proxy Certificate" or "PC" as a means of providing for restricted proxying within an (extended) X.509 PKI based authentication system.
このドキュメントでは、（拡張）X.509 PKIベースの認証システム内での制限されたプロキシを提供する手段として、X.509の「プロキシ証明書」または「PC」を定義しています。
A Proxy Certificate is an X.509 public key certificate with the following properties:
プロキシ証明書は、次のプロパティを備えたX.509公開鍵証明書です。
1) It is signed by either an X.509 End Entity Certificate (EEC), or by another PC. This EEC or PC is referred to as the Proxy Issuer (PI).
1) X.509 End Entity証明書（EEC）または別のPCによって署名されます。このEECまたはPCは、プロキシ発行者（PI）と呼ばれます。
2) It can sign only another PC. It cannot sign an EEC.
2) 別のPCのみに署名できます。EECに署名することはできません。
3) It has its own public and private key pair, distinct from any other EEC or PC.
3) 他のEECまたはPCとは異なる独自の公開キーペアがあります。
4) It has an identity derived from the identity of the EEC that signed the PC. When a PC is used for authentication, in may inherit rights of the EEC that signed the PC, subject to the restrictions that are placed on that PC by the EEC.
4) PCに署名したEECの身元から派生したアイデンティティがあります。PCが認証に使用される場合、5月にPCに署名したEECの権利を継承し、EECによってそのPCに配置されている制限を条件とします。
5) Although its identity is derived from the EEC's identity, it is also unique. This allows this identity to be used for authorization as an independent identity from the identity of the issuing EEC, for example in conjunction with attribute assertions as defined in [i3].
5) そのアイデンティティはEECのアイデンティティから派生していますが、ユニークです。これにより、このアイデンティティは、[i3]で定義されている属性アサーションと組み合わせて、発行EECのIDからの独立したアイデンティティとしての承認のために使用されることができます。
6) It contains a new X.509 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509 fields and extensions, are used to enable proper path validation and use of the PC.
6) 新しいX.509拡張機能が含まれており、PCとして識別し、PCの使用に関するポリシーを配置します。この新しい拡張機能は、他のX.509フィールドおよび拡張機能とともに、PCの適切なパス検証と使用を可能にするために使用されます。
The process of creating a PC is as follows:
PCを作成するプロセスは次のとおりです。
1) A new public and private key pair is generated.
1) 新しい公開および秘密のキーペアが生成されます。
2) That key pair is used to create a request for a Proxy Certificate that conforms to the profile described in this document.
2) このキーペアは、このドキュメントで説明されているプロファイルに準拠するプロキシ証明書のリクエストを作成するために使用されます。
3) A Proxy Certificate, signed by the private key of the EEC or by another PC, is created in response to the request. During this process, the PC request is verified to ensure that the requested PC is valid (e.g., it is not an EEC, the PC fields are appropriately set, etc).
3) EECの秘密鍵または別のPCによって署名されたプロキシ証明書は、リクエストに応じて作成されます。このプロセス中に、PCリクエストは、要求されたPCが有効であることを確認するために検証されます（たとえば、EECではなく、PCフィールドが適切に設定されています）。
When a PC is created as part of a delegation from entity A to entity B, this process is modified by performing steps #1 and #2 within entity B, then passing the PC request from entity B to entity A over an authenticated, integrity checked channel, then entity A performs step #3 and passes the PC back to entity B.
エンティティAからエンティティBへの代表団の一部としてPCが作成されると、このプロセスはエンティティB内でステップ＃1と＃2を実行することで変更され、エンティティBからエンティティAにPCリクエストを渡して、認証された整合性チェック済みでエンティティAに渡すチャネル、次にエンティティAはステップ＃3を実行し、PCをエンティティBに渡します。
Path validation of a PC is very similar to normal path validation, with a few additional checks to ensure, for example, proper PC signing constraints.
PCのパス検証は、通常のパス検証と非常に似ており、たとえば適切なPCの制約を確保するためのいくつかの追加チェックがあります。
Using Proxy Certificates to perform delegation has several features that make it attractive:
プロキシ証明書を使用して代表団を実行するには、魅力的な機能がいくつかあります。
* Ease of integration
* 統合の容易さ
o Because a PC requires only a minimal change to path validation, it is very easy to incorporate support for Proxy Certificates into existing X.509 based software. For example, SSL/TLS requires no protocol changes to support authentication using a PC. Further, an SSL/TLS implementation requires only minor changes to support PC path validation, and to retrieve the authenticated subject of the signing EEC instead of the subject of the PC for authorization purposes.
o PCはPATH検証の最小限の変更のみを必要とするため、既存のX.509ベースのソフトウェアにプロキシ証明書のサポートを組み込むことは非常に簡単です。たとえば、SSL/TLSは、PCを使用した認証をサポートするためにプロトコルの変更を必要としません。さらに、SSL/TLSの実装では、PC Path検証をサポートし、許可のためにPCの主題の代わりに署名EECの認証された主題を取得するために、わずかな変更のみが必要です。
o Many existing authorization systems use the X.509 subject name as the basis for access control. Proxy Certificates can be used with such authorization systems without modification, since such a PC inherits its name and rights from the EEC that signed it and the EEC name can be used in place of the PC name for authorization decisions.
o 多くの既存の承認システムは、アクセス制御の基礎としてX.509の件名を使用しています。そのようなPCは、それを署名したEECからその名前と権利を継承し、EEC名をPC名の代わりに許可決定のために使用できます。
* Ease of use
* 使いやすさ
o Using PC for single sign-on helps make X.509 PKI authentication easier to use, by allowing users to "login" once and then perform various operations securely.
o シングルサインオンにPCを使用すると、ユーザーが1回「ログイン」してからさまざまな操作を安全に実行できるようにすることで、X.509 PKI認証を使いやすくすることができます。
o For many users, properly managing their own EEC private key is a nuisance at best, and a security risk at worst. One option easily enabled with a PC is to manage the EEC private keys and certificates in a centrally managed repository. When a user needs a PKI credential, the user can login to the repository using name/password, one time password, etc. Then the repository can delegate a PC to the user with proxy rights, but continue to protect the EEC private key in the repository.
o 多くのユーザーにとって、独自のEEC秘密鍵を適切に管理することは、せいぜい迷惑であり、最悪の場合はセキュリティリスクです。PCで簡単に有効にできるオプションの1つは、中央管理リポジトリでEECプライベートキーと証明書を管理することです。ユーザーがPKI資格情報を必要とする場合、ユーザーは名前/パスワード、1回のパスワードなどを使用してリポジトリにログインできます。その場合、リポジトリはPCをプロキシの権利を持つユーザーに委任できますが、引き続きEECの秘密鍵を保護します。リポジトリ。
* Protection of private keys
* プライベートキーの保護
o By using the remote delegation approach outlined above, entity A can delegate a PC to entity B, without entity B ever seeing the private key of entity A, and without entity A ever seeing the private key of the newly delegated PC held by entity B. In other words, private keys never need to be shared or communicated by the entities participating in a delegation of a PC.
o 上記のリモート委任アプローチを使用することにより、エンティティAは、エンティティAの秘密鍵を見ることなく、エンティティBが保有している新しく委任されたPCの秘密鍵を見ることなく、エンティティBをエンティティBなしでエンティティBに委任できます。言い換えれば、プライベートキーは、PCの委任に参加しているエンティティによって共有または通信する必要はありません。
o When implementing single sign-on, using a PC helps protect the private key of the EEC, because it minimizes the exposure and use of that private key. For example, when an EEC private key is password protected on disk, the password and unencrypted private key need only be available during the creation of the PC. That PC can then be used for the remainder of its valid lifetime, without requiring access to the EEC password or private key. Similarly, when the EEC private key lives on a smartcard, the smartcard need only be present in the machine during the creation of the PC.
o シングルサインオンを実装するとき、PCを使用すると、EECの秘密鍵を保護するのに役立ちます。これは、その秘密鍵の露出と使用を最小限に抑えるためです。たとえば、EECの秘密キーがディスク上でパスワードで保護されている場合、PCの作成中にパスワードと暗号化されていない秘密キーの必要性は利用可能です。そのPCは、EECパスワードや秘密鍵にアクセスすることなく、有効な寿命の残りの時間に使用できます。同様に、EECの秘密鍵がスマートカードに住んでいる場合、SmartCardはPCの作成中にマシンにのみ存在する必要があります。
* Limiting consequences of a compromised key
* 侵害されたキーの結果を制限します
o When creating a PC, the PI can limit the validity period of the PC, the depth of the PC path that can be created by that PC, and key usage of the PC and its descendents. Further, fine-grained policies can be carried by a PC to even further restrict the operations that can be performed using the PC. These restrictions permit the PI to limit damage that could be done by the bearer of the PC, either accidentally or maliciously.
o PCを作成すると、PIはPCの有効期間、そのPCによって作成できるPCパスの深さ、およびPCとその子孫の主要な使用法を制限できます。さらに、PCを使用して実行できる操作をさらに制限するために、PCが細粒ポリシーを実行することができます。これらの制限により、PIはPCの担い手が偶然または悪意を持って行うことができる損傷を制限することができます。
o A compromised PC private key does NOT compromise the EEC private key. This makes a short term, or an otherwise restricted PC attractive for day-to-day use, since a compromised PC does not require the user to go through the usually cumbersome and time consuming process of having the EEC with a new private key reissued by the CA.
o 侵害されたPCの秘密鍵は、EECの秘密鍵を損なうことはありません。これにより、妥協したPCは、ユーザーが新しい秘密鍵を使用してEECを使用するという通常面倒で時間のかかるプロセスを通過する必要がないため、日々の使用に魅力的な短期になります。CA。
See Section 5 below for more discussion on how Proxy Certificates relate to Attribute Certificates.
プロキシ証明書が属性証明書にどのように関連するかについての詳細については、以下のセクション5を参照してください。
This section defines the usage of X.509 certificate fields and extensions in Proxy Certificates, and defines one new extension for Proxy Certificate Information.
このセクションでは、プロキシ証明書のX.509証明書フィールドと拡張機能の使用法を定義し、プロキシ証明書情報の1つの新しい拡張機能を定義します。
All Proxy Certificates MUST include the Proxy Certificate Information (ProxyCertInfo) extension defined in this section and the extension MUST be critical.
すべてのプロキシ証明書には、このセクションで定義されているプロキシ証明書情報（proxycertinfo）拡張機能を含める必要があり、拡張機能は重要でなければなりません。
The Proxy Issuer of a Proxy Certificate MUST be either an End Entity Certificate, or another Proxy Certificate.
プロキシ証明書のプロキシ発行者は、End Entity証明書または別のプロキシ証明書のいずれかでなければなりません。
The Proxy Issuer MUST NOT have an empty subject field.
プロキシ発行者は、空の件名フィールドを持っている必要があります。
The issuer field of a Proxy Certificate MUST contain the subject field of its Proxy Issuer.
プロキシ証明書の発行者フィールドには、プロキシ発行者の主題フィールドを含める必要があります。
If the Proxy Issuer certificate has the KeyUsage extension, the Digital Signature bit MUST be asserted.
プロキシ発行者証明書にKeyUSAGE拡張機能がある場合、デジタル署名ビットを主張する必要があります。
The issuerAltName extension MUST NOT be present in a Proxy Certificate.
IssueraltName拡張機能は、プロキシ証明書に存在しないでください。
The serial number of a Proxy Certificate (PC) SHOULD be unique amongst all Proxy Certificates issued by a particular Proxy Issuer. However, a Proxy Issuer MAY use an approach to assigning serial numbers that merely ensures a high probability of uniqueness.
プロキシ証明書（PC）のシリアル番号は、特定のプロキシ発行者によって発行されたすべてのプロキシ証明書の中で一意でなければなりません。ただし、プロキシ発行者は、単に一意性の確率を保証する単なるシリアル番号を割り当てるためにアプローチを使用する場合があります。
For example, a Proxy Issuer MAY use a sequentially assigned integer or a UUID to assign a unique serial number to a PC it issues. Or a Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a serial number with a high probability of uniqueness.
たとえば、プロキシ発行者は、順次割り当てられた整数またはUUIDを使用して、一意のシリアル番号を発行することができます。または、プロキシ発行者は、PCの公開キーのSHA-1ハッシュを使用して、一意性の可能性が高いシリアル番号を割り当てることができます。
The subject field of a Proxy Certificate MUST be the issuer field (that is the subject of the Proxy Issuer) appended with a single Common Name component.
プロキシ証明書の主題フィールドは、単一の共通名コンポーネントで追加された発行者フィールド（プロキシ発行者の主題）でなければなりません。
The value of the Common Name SHOULD be unique to each Proxy Certificate bearer amongst all Proxy Certificates with the same issuer.
共通名の値は、同じ発行者を持つすべてのプロキシ証明書の中で、各プロキシ証明書の担い手に固有のものでなければなりません。
If a Proxy Issuer issues two proxy certificates to the same bearer, the Proxy Issuer MAY choose to use the same Common Name for both. Examples of this include Proxy Certificates for different uses (e.g., signing vs encryption) or the re-issuance of an expired Proxy Certificate.
プロキシ発行者が同じベアラーに2つのプロキシ証明書を発行する場合、プロキシ発行者は両方に同じ共通名を使用することを選択できます。この例には、さまざまな用途のプロキシ証明書（例：署名対暗号化）または期限切れのプロキシ証明書の再発行が含まれます。
The Proxy Issuer MAY use an approach to assigning Common Name values that merely ensures a high probability of uniqueness. This value MAY be the same value used for the serial number.
プロキシ発行者は、単に高い確率の確実性を保証する一般名値を割り当てるためにアプローチを使用する場合があります。この値は、シリアル番号に使用される値と同じです。
The result of this approach is that all subject names of Proxy Certificates are derived from the name of the issuing EEC (it will be the first part of the subject name appended with one or more CN components) and are unique to each bearer.
このアプローチの結果、プロキシ証明書のすべてのサブジェクト名は、発行EEC（1つ以上のCNコンポーネントで追加されたサブジェクト名の最初の部分）から派生し、各ベアラーに固有のものです。
The subjectAltName extension MUST NOT be present in a Proxy Certificate.
subjectaltname拡張機能は、プロキシ証明書に存在しないでください。
If the Proxy Issuer certificate has a Key Usage extension, the Digital Signature bit MUST be asserted.
プロキシ発行者証明書にキー使用拡張機能がある場合、デジタル署名ビットを主張する必要があります。
This document places no constraints on the presence or contents of the key usage and extended key usage extension. However, section 4.2 explains what functions should be allowed a proxy certificate by a relying party.
このドキュメントは、主要な使用法の存在または内容に制約を課さず、主要な使用法の拡張を拡張します。ただし、セクション4.2では、どの機能が頼りの当事者によるプロキシ証明書を許可すべきかについて説明します。
The cA field in the basic constraints extension MUST NOT be TRUE.
基本的な制約拡張のCAフィールドが真でなければなりません。
A new extension, ProxyCertInfo, is defined in this subsection. Presence of the ProxyCertInfo extension indicates that a certificate is a Proxy Certificate and whether or not the issuer of the certificate has placed any restrictions on its use.
このサブセクションでは、新しい拡張機能であるProxycertinfoが定義されています。Proxycertinfo拡張機能の存在は、証明書がプロキシ証明書であり、証明書の発行者がその使用に制限を課しているかどうかを示します。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
ProxyCertInfo ::= SEQUENCE {
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
If a certificate is a Proxy Certificate, then the proxyCertInfo extension MUST be present, and this extension MUST be marked as critical.
証明書がプロキシ証明書の場合、ProxyCertinFO拡張機能が存在する必要があり、この拡張機能は重要であるとマークする必要があります。
If a certificate is not a Proxy Certificate, then the proxyCertInfo extension MUST be absent.
証明書がプロキシ証明書ではない場合、ProxyCertinFO拡張機能は存在しない必要があります。
The ProxyCertInfo extension consists of one required and two optional fields, which are described in detail in the following subsections.
Proxycertinfo拡張機能は、1つの必要なフィールドと2つのオプションのフィールドで構成されており、以下のサブセクションで詳細に説明されています。
The pCPathLenConstraint field, if present, specifies the maximum depth of the path of Proxy Certificates that can be signed by this Proxy Certificate. A pCPathLenConstraint of 0 means that this certificate MUST NOT be used to sign a Proxy Certificate. If the pCPathLenConstraint field is not present then the maximum proxy path length is unlimited. End entity certificates have unlimited maximum proxy path lengths.
PCPATHLENConstraintフィールドは、存在する場合、このプロキシ証明書で署名できるプロキシ証明書のパスの最大深度を指定します。0のPCPATHLENConstraintは、この証明書をプロキシ証明書に署名するために使用しないことを意味します。PCPATHLENCONSTRANTフィールドが存在しない場合、最大プロキシパスの長さは無制限です。End Entity証明書には、無制限の最大プロキシパス長があります。
The proxyPolicy field specifies a policy on the use of this certificate for the purposes of authorization. Within the proxyPolicy, the policy field is an expression of policy, and the policyLanguage field indicates the language in which the policy is expressed.
ProxyPolicyフィールドは、承認を目的としたこの証明書の使用に関するポリシーを指定します。ProxyPolicy内では、ポリシーフィールドはポリシーの表現であり、Policylaniongageフィールドはポリシーが表明される言語を示します。
The proxyPolicy field in the proxyCertInfo extension does not define a policy language to be used for proxy restrictions; rather, it places the burden on those parties using that extension to define an appropriate language, and to acquire an OID for that language (or to select an appropriate previously-defined language/OID). Because it is essential for the PI that issues a certificate with a proxyPolicy field and the relying party that interprets that field to agree on its meaning, the policy language OID must correspond to a policy language (including semantics), not just a policy grammar.
Proxycertinfo拡張のプロキシポリックフィールドは、プロキシ制限に使用するポリシー言語を定義していません。むしろ、適切な言語を定義するためにその拡張機能を使用して、その言語のOIDを取得する（または適切な以前に定義された言語/OIDを選択するため）、それらの関係者に負担をかけます。Piにとって、プロキシポリックフィールドと証明書を発行するPIにとって、そのフィールドがその意味に同意するためにそのフィールドを解釈する依存関係者に不可欠であるため、OIDは、政策文法だけでなく、ポリシー言語（セマンティクスを含む）に対応する必要があります。
The policyLanguage field has two values of special importance, defined in Appendix A, that MUST be understood by all parties accepting Proxy Certificates:
PolicyLanguageフィールドには、付録Aで定義されている2つの特に重要な値があります。これは、プロキシ証明書を受け入れるすべての当事者が理解する必要があります。
* id-ppl-inheritAll indicates that this is an unrestricted proxy that inherits all rights from the issuing PI. An unrestricted proxy is a statement that the Proxy Issuer wishes to delegate all of its authority to the bearer (i.e., to anyone who has that proxy certificate and can prove possession of the associated private key). For purposes of authorization, this an unrestricted proxy effectively impersonates the issuing PI.
* ID-PPL-Inheritallは、これが発行PIからすべての権利を継承する無制限のプロキシであることを示しています。無制限のプロキシとは、プロキシ発行者がそのすべての権限を担い手に委任したいという声明です（つまり、その代理証明書を持ち、関連する秘密鍵の所有を証明できる人に）。許可の目的のために、これは無制限のプロキシであり、発行PIに効果的になりすまします。
* id-ppl-independent indicates that this is an independent proxy that inherits no rights from the issuing PI. This PC MUST be treated as an independent identity by relying parties. The only rights this PC has are those granted explicitly to it.
* ID-PPL独立は、これが発行PIから権利を継承しない独立したプロキシであることを示しています。このPCは、当事者に依存することにより、独立したアイデンティティとして扱わなければなりません。このPCが持っている唯一の権利は、明示的に付与された権利です。
For either of the policyLanguage values listed above, the policy field MUST NOT be present.
上記のPolicylaniangage値のいずれかについて、ポリシーフィールドが存在してはなりません。
Other values for the policyLanguage field indicates that this is a restricted proxy certification and have some other policy limiting its ability to do proxying. In this case the policy field MAY be present and it MUST contain information expressing the policy. If the policy field is not present the policy MUST be implicit in the value of the policyLanguage field itself. Authors of additional policy languages are encouraged to publicly document their policy language and list it in the IANA registry (see Section 7).
Policylanguageフィールドのその他の値は、これが制限されたプロキシ認証であり、プロキシを行う能力を制限する他のポリシーを持っていることを示しています。この場合、ポリシーフィールドが存在する場合があり、ポリシーを表現する情報を含める必要があります。ポリシーフィールドが存在しない場合、ポリシーは、Policylanangageフィールド自体の価値に暗黙的でなければなりません。追加のポリシー言語の著者は、ポリシー言語を公開し、IANAレジストリにリストすることをお勧めします（セクション7を参照）。
Proxy policies are used to limit the amount of authority delegated, for example to assert that the proxy certificate may be used only to make requests to a specific server, or only to authorize specific operations on specific resources. This document is agnostic to the policies that can be placed in the policy field.
プロキシポリシーは、委任額を制限するために使用されます。たとえば、プロキシ証明書は特定のサーバーにリクエストを行うためにのみ使用されるか、特定のリソースで特定の操作を承認するために使用できることを主張します。この文書は、ポリシー分野に配置できるポリシーに不可知論されます。
Proxy policies impose additional requirements on the relying party, because only the relying party is in a position to ensure that those policies are enforced. When making an authorization decision based on a proxy certificate based on rights that proxy certificate inherited from its issuer, it is the relying party's responsibility to verify that the requested authority is compatible with all policies in the PC's certificate path. In other words, the relying party MUST verify that the following three conditions are all met:
頼る政策が施行されることを保証する立場にあるため、頼る当事者に追加の要件が課されます。発行者から継承されたプロキシ証明書に基づいてプロキシ証明書に基づいて認可決定を下す場合、要求された権限がPCの証明書パスのすべてのポリシーと互換性があることを確認することは、当事者の責任です。言い換えれば、頼る当事者は、次の3つの条件がすべて満たされていることを確認する必要があります。
1) The relying party MUST know how to interpret the proxy policy and the request is allowed under that policy.
1) 頼る当事者は、プロキシポリシーを解釈する方法を知っておく必要があり、そのポリシーの下で要求が許可されています。
2) If the Proxy Issuer is an EEC then the relying party's local policies MUST authorize the request for the entity named in the EEC.
2) プロキシ発行者がEECである場合、頼る当事者のローカルポリシーは、EECに名前が付けられたエンティティの要求を承認する必要があります。
3) If the Proxy Issuer is another PC, then one of the following MUST be true:
3) プロキシ発行者が別のPCである場合、次のいずれかが真でなければなりません。
a. The relying party's local policies authorize the Proxy Issuer to perform the request.
a. 頼る当事者の地方ポリシーは、プロキシ発行者がリクエストを実行することを許可します。
b. The Proxy Issuer inherits the right to perform the request from its issuer by means of its proxy policy. This must be verified by verifying these three conditions on the Proxy Issuer in a recursive manner.
b. プロキシ発行者は、プロキシポリシーによって発行者からリクエストを実行する権利を継承します。これは、プロキシ発行者のこれら3つの条件を再帰的に検証することで検証する必要があります。
If these conditions are not met, the relying party MUST either deny authorization, or ignore the PC and the whole certificate chain including the EEC entirely when making its authorization decision (i.e., make the same decision that it would have made had the PC and it's certificate chain never been presented).
これらの条件が満たされていない場合、依存する当事者は、許可を拒否するか、PCと証明書チェーン全体を無視する必要があります。証明書チェーンは提示されていません）。
The relying party MAY impose additional restrictions as to which proxy certificates it accepts. For example, a relying party MAY choose to reject all proxy certificates, or MAY choose to accept proxy certificates only for certain operations, etc.
依存している当事者は、どのプロキシ証明書を受け入れるかについて追加の制限を課す可能性があります。たとえば、頼っている当事者は、すべてのプロキシ証明書を拒否することを選択するか、特定の操作などに対してのみプロキシ証明書を受け入れることを選択できます。
Note that since a proxy certificate has a unique identity it MAY also have rights granted to it by means other than inheritance from it's issuer via its proxy policy. The rights granted to the bearer of a PC are the union of the rights granted to the PC identity and the inherited rights. The inherited rights consist of the intersection of the rights granted to the PI identity intersected with the proxy policy in the PC.
プロキシ証明書には一意のIDがあるため、プロキシポリシーを介して発行者からの継承以外の手段によって権利が付与される可能性もあります。PCの担い手に付与される権利は、PCのIDに付与された権利と相続権の連合です。継承された権利は、PCのプロキシポリシーと交差したPI IDに付与された権利の交差点で構成されています。
For example, imagine that Steve is authorized to read and write files A and B on a file server, and that he uses his EEC to create a PC that includes the policy that it can be used only to read or write files A and C. Then a trusted attribute authority grants an Attribute Certificate granting the PC the right to read file D. This would make the rights of the PC equal to the union of the rights granted to the PC identity (right to read file D) with the intersection of the rights granted to Steve, the PI, (right to read files A and B) with the policy in the PC (can only read files A and C). This would mean the PC would have the following rights:
たとえば、SteveはファイルサーバーでファイルAとBを読み取りおよび書き込みすることを許可されており、EECを使用してファイルAおよびCの読み取りまたは書き込みのみに使用できるポリシーを含むPCを作成することを想像してください。次に、信頼できる属性当局は、PCにファイルDを読む権利を付与する属性証明書を付与します。これにより、PCの権利は、PCのIDに付与された権利（ファイルdを読む権利）に等しくなります。PC内のポリシーを使用して、Steve、Pi（ファイルAおよびBを読み取る権利）に付与された権利（ファイルAとCのみを読み取ることができます）。これは、PCが次の権利を持つことを意味します。
* Right to read file A: Steve has this right and he issued the PC and his policy grants this right to the PC.
* ファイルAを読む権利：Steveにはこれが権利があり、彼はPCを発行し、彼のポリシーはこの権利をPCに付与します。
* Right to read file D: This right is granted explicitly to the PC by a trusted authority.
* ファイルDを読む権利：この権利は、信頼できる当局によってPCに明示的に付与されます。
The PC would NOT have the following rights:
PCには次の権利がありません。
* Right to read file B: Although Steve has this right, it is excluded by his policy on the PC.
* ファイルBを読む権利：Steveにはこれが権利がありますが、PCでの彼のポリシーによって除外されています。
* Right to read file C: Although Steve's policy grants this right, he does not have this right himself.
* ファイルcを読む権利：スティーブの政策はこの権利を与えていますが、彼は自分自身がこの権利を持っていません。
In many cases, the relying party will not have enough information to evaluate the above criteria at the time that the certificate path is validated. For example, if a certificate is used to authenticate a connection to some server, that certificate is typically validated during that authentication step, before any requests have been made of the server. In that case, the relying party MUST either have some authorization mechanism in place that will check the proxy policies, or reject any certificate that contains proxy policies (or that has a parent certificate that contains proxy policies).
多くの場合、頼る当事者は、証明書パスが検証された時点で上記の基準を評価するのに十分な情報を持っていません。たとえば、証明書が一部のサーバーへの接続を認証するために使用される場合、その証明書は通常、サーバーのリクエストが行われる前に、その認証ステップ中に検証されます。その場合、頼る当事者は、プロキシポリシーをチェックするいくつかの承認メカニズムを導入するか、プロキシポリシーを含む証明書（またはプロキシポリシーを含む親証明書がある）のいずれかを拒否する必要があります。
Proxy Certification path processing verifies the binding between the proxy certificate distinguished name and proxy certificate public key. The binding is limited by constraints which are specified in the certificates which comprise the path and inputs which are specified by the relying party.
プロキシ認証パス処理は、プロキシ証明書の著名な名前とプロキシ証明書の公開キーとの間のバインディングを検証します。この拘束力は、頼りの当事者によって指定されたパスと入力を含む証明書で指定された制約によって制限されます。
This section describes an algorithm for validating proxy certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
このセクションでは、プロキシ認証パスを検証するためのアルゴリズムについて説明します。この仕様の適合実装は、このアルゴリズムを実装するために必要ではなく、この手順に起因する外部動作に相当する機能を提供する必要があります。すべてのアルゴリズムは、正しい結果を導き出す限り、特定の実装で使用できます。
The algorithm presented in this section validates the proxy certificate with respect to the current date and time. A conformant implementation MAY also support validation with respect to some point in the past. Note that mechanisms are not available for validating a proxy certificate with respect to a time outside the certificate validity period.
このセクションで提示されたアルゴリズムは、現在の日付と時刻に関してプロキシ証明書を検証します。適合の実装は、過去のある時点に関する検証もサポートする場合があります。証明書の有効期間以外の時間に関して、プロキシ証明書を検証するためのメカニズムは利用できないことに注意してください。
Valid paths begin with the end entity certificate (EEC) that has already been validated by public key certificate validation procedures in RFC 3280 [n2]. The algorithm requires the public key of the EEC and the EEC's subject distinguished name.
有効なパスは、RFC 3280 [N2]の公開キー証明書の検証手順によってすでに検証されている最終エンティティ証明書（EEC）から始まります。アルゴリズムには、EECの公開鍵とEECの主題が著名な名前が必要です。
To meet the goal of verifying the proxy certificate, the proxy certificate path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
プロキシ証明書を確認するという目標を達成するために、プロキシ証明書のパス検証プロセスは、とりわけ、将来の認定パス（N証明書のシーケンス）が次の条件を満たすことを確認します。
(a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of proxy certificate x+1 and the subject distinguished name of certificate x+1 is a legal subject distinguished name to have been issued by certificate x;
(a) {1、...、n-1}のすべてのxの場合、証明書xの主題はプロキシ証明書x 1の発行者であり、証明書x 1の主題名は証明書によって発行された法的主題の著名な名前ですバツ;
(b) certificate 1 is valid proxy certificate issued by the end entity certificate whose information is given as input to the proxy certificate path validation process;
(b) 証明書1は、プロキシ証明書パス検証プロセスへの入力として情報が与えられるEnd Entity証明書によって発行された有効なプロキシ証明書です。
(c) certificate n is the proxy certificate to be validated;
(c) 証明書nは検証されるプロキシ証明書です。
(d) for all x in {1, ..., n}, the certificate was valid at the time in question; and
(d) {1、...、n}のすべてのxについて、証明書は問題の時点で有効でした。そして
(e) for all certificates in the path with a pCPathLenConstraint field, the number of certificates in the path following that certificate does not exceed the length specified in that field.
(e) PCPATHLENCONSTRANTフィールドを備えたパス内のすべての証明書について、その証明書に続くパスの証明書の数は、そのフィールドで指定された長さを超えません。
At this point there is no mechanism defined for revoking proxy certificates.
この時点で、プロキシ証明書を取り消すために定義されたメカニズムはありません。
This section presents the algorithm in four basic steps to mirror the description of public key certificate path validation in RFC 3280: (1) initialization, (2) basic proxy certificate processing, (3) preparation for the next proxy certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all proxy certificates in the path. Step (3) is performed for all proxy certificates in the path except the final proxy certificate.
このセクションでは、RFC 3280の公開キー証明書パス検証の説明を反映するための4つの基本手順でアルゴリズムを示します。まとめ。手順（1）および（4）は正確に1回実行されます。ステップ（2）は、パス内のすべてのプロキシ証明書に対して実行されます。ステップ（3）は、最終プロキシ証明書を除くパス内のすべてのプロキシ証明書に対して実行されます。
Certificate path validation as described in RFC 3280 MUST have been done prior to using this algorithm to validate the end entity certificate. This algorithm then processes the proxy certificate chain using the end entity certificate information produced by RFC 3280 path validation.
RFC 3280に記載されている証明書パス検証このアルゴリズムを使用して、最終エンティティ証明書を検証する前に実行された必要があります。このアルゴリズムは、RFC 3280 PATH検証によって作成されたEND ENTITY証明書情報を使用して、プロキシ証明書チェーンを処理します。
This algorithm assumes the following inputs are provided to the path processing logic:
このアルゴリズムは、次の入力がパス処理ロジックに提供されると想定しています。
(a) information about the entity certificate already verified using RFC 3280 path validation. This information includes:
(a) RFC 3280パス検証を使用して既に検証されているエンティティ証明書に関する情報。この情報には以下が含まれます。
(1) the end entity name,
(1) 最終エンティティ名、
(2) the working_public_key output from RFC 3280 path validation,
(2) RFC 3280 PATH検証からのworking_public_key出力、
(3) the working_public_key_algorithm output from RFC 3280,
(3) RFC 3280からのworking_public_key_algorithm出力、
(4) and the working_public_key_parameters output from RFC 3280 path validation.
(4) RFC 3280 PATH検証からのworking_public_key_parameters出力。
(b) prospective proxy certificate path of length n.
(b) 長さnの前向きプロキシ証明書パスパス。
(c) acceptable-pc-policy-language-set: A set of proxy certificate policy languages understood by the policy evaluation code. The acceptable-pc-policy-language-set MAY contain the special value id-ppl-anyLanguage (as defined in Appendix A) if the path validation code should not check the proxy certificate policy languages (typically because the set of known policy languages is not known yet and will be checked later in the authorization process).
(c) 許容可能なPC-Policy-Language-Set：ポリシー評価コードで理解されるプロキシ証明書のポリシー言語のセット。PATH検証コードがプロキシ証明書のポリシー言語を確認しないでください（通常、既知のポリシー言語のセットがあるため、特別な値ID-PPL-Anylanangage（付録Aで定義されています）が含まれている場合があります。まだ知られていないため、承認プロセスの後半で確認されます）。
(d) the current date and time.
(d) 現在の日付と時刻。
This initialization phase establishes the following state variables based upon the inputs:
この初期化フェーズは、入力に基づいて次の状態変数を確立します。
(a) working_public_key_algorithm: the digital signature algorithm used to verify the signature of a proxy certificate. The working_public_key_algorithm is initialized from the input information provided from RFC 3280 path validation.
(a) work_public_key_algorithm：プロキシ証明書の署名を検証するために使用されるデジタル署名アルゴリズム。working_public_key_algorithmは、RFC 3280 PATH検証から提供される入力情報から初期化されます。
(b) working_public_key: the public key used to verify the signature of a proxy certificate. The working_public_key is initialized from the input information provided from RFC 3280 path validation.
(b) working_public_key：プロキシ証明書の署名を確認するために使用される公開キー。working_public_keyは、RFC 3280 PATH検証から提供された入力情報から初期化されます。
(c) working_public_key_parameters: parameters associated with the current public key, that may be required to verify a signature (depending upon the algorithm). The proxy_issuer_public_key_parameters variable is initialized from the input information provided from RFC 3280 path validation.
(c) working_public_key_parameters：署名を検証するために必要な現在の公開キーに関連付けられているパラメーター（アルゴリズムに応じて）。proxy_issuer_public_key_parameters変数は、RFC 3280 PATH検証から提供される入力情報から初期化されます。
(d) working_issuer_name: the issuer distinguished name expected in the next proxy certificate in the chain. The working_issuer_name is initialized to the distinguished name in the end entity certificate validated by RFC 3280 path validation.
(d) work_issuer_name：チェーンの次のプロキシ証明書で予想される発行者の著名な名前。working_issuer_nameは、RFC 3280 PATH検証によって検証されたEnd Entity証明書の著名な名前に初期化されます。
(e) max_path_length: this integer is initialized to n, is decremented for each proxy certificate in the path. This value may also be reduced by the pcPathLenConstraint value of any proxy certificate in the chain.
(e) max_path_length：この整数はnに初期化され、パス内の各プロキシ証明書について減少します。この値は、チェーン内のプロキシ証明書のPCPATHLENCONSTRAINT値によっても削減される場合があります。
(f) proxy_policy_list: this list is empty to start and will be filled in with the key usage extensions, extended key usage extensions and proxy policies in the chain.
(f) proxy_policy_list：このリストは開始するのが空で、主要な使用法拡張機能、拡張キー使用量拡張機能、チェーン内のプロキシポリシーが記入されます。
Upon completion of the initialization steps, perform the basic certificate processing steps specified in 4.1.3.
初期化手順が完了すると、4.1.3で指定された基本的な証明書処理手順を実行します。
The basic path processing actions to be performed for proxy certificate i (for all i in [1..n]) are listed below.
プロキシ証明書I（[1..n]のすべてのIについて）で実行される基本的なパス処理アクションを以下に示します。
(a) Verify the basic certificate information. The certificate MUST satisfy each of the following:
(a) 基本的な証明書情報を確認します。証明書は次のそれぞれを満たす必要があります。
(1) The certificate was signed with the working_public_key_algorithm using the working_public_key and the working_public_key_parameters.
(1) 証明書は、working_public_keyおよびworking_public_key_parametersを使用して、work_public_key_algorithmと署名されました。
(2) The certificate validity period includes the current time.
(2) 証明書の有効期間には、現在の時刻が含まれます。
(3) The certificate issuer name is the working_issuer_name.
(3) 証明書発行者名はworking_issuer_nameです。
(4) The certificate subject name is the working_issuer_name with a CN component appended.
(4) 証明書の件名は、CNコンポーネントが追加されたworking_issuer_nameです。
(b) The proxy certificate MUST have a ProxyCertInfo extension. Process the extension as follows:
(b) プロキシ証明書には、proxycertinfo拡張機能が必要です。拡張機能を次のように処理します。
(1) If the pCPathLenConstraint field is present in the ProxyCertInfo field and the value it contains is less than max_path_length, set max_path_length to its value.
(1) PCPATHLENCONSTRANTフィールドがProxyCertinFOフィールドに存在し、それに含まれる値がmax_path_lengthよりも少ない場合、max_path_lengthをその値に設定します。
(2) If acceptable-pc-policy-language-set is not id-ppl-anyLanguage, the OID in the policyLanguage field MUST be present in acceptable-pc-policy-language-set.
(2) 許容可能なPC-Policy-Language-SetがID-PPL-Anylaniangageではない場合、PolicylanancageフィールドのOIDは、許容可能なPC-Policy-Language-Setに存在する必要があります。
(c) The tuple containing the certificate subject name, policyPolicy, key usage extension (if present) and extended key usage extension (if present) must be appended to proxy_policy_list.
(c) 証明書の件名名、PolicyPolicy、主要な使用法拡張機能（存在する場合）、および拡張されたキー使用拡張機能（存在する場合）を含むタプルは、proxy_policy_listに追加する必要があります。
(d) Process other certificate extensions, as described in [n2]:
(d) [n2]で説明されているように、他の証明書拡張機能を処理します。
(1) Recognize and process any other critical extensions present in the proxy certificate.
(1) プロキシ証明書に存在する他の重要な拡張機能を認識して処理します。
(2) Process any recognized non-critical extension present in the proxy certificate.
(2) プロキシ証明書に存在する認識されていない非批判的な拡張機能を処理します。
If either step (a), (b) or (d) fails, the procedure terminates, returning a failure indication and an appropriate reason.
ステップ（a）、（b）、または（d）のいずれかが失敗した場合、手順は終了し、障害表示と適切な理由を返します。
If i is not equal to n, continue by performing the preparatory steps listed in 4.1.4. If i is equal to n, perform the wrap-up steps listed in 4.1.5.
私がnに等しくない場合は、4.1.4にリストされている準備手順を実行して続行します。私がnに等しい場合は、4.1.5にリストされているラップアップ手順を実行します。
(a) Verify max_path_length is greater than zero and decrement max_path_length.
(a) max_path_lengthがゼロよりも大きいことを確認し、max_path_lengthを減少させます。
(b) Assign the certificate subject name to working_issuer_name.
(b) 証明書の件名をwork_issuer_nameに割り当てます。
(c) Assign the certificate subjectPublicKey to working_public_key.
(c) 証明書SubjectPublicKeyをwork_public_keyに割り当てます。
(d) If the subjectPublicKeyInfo field of the certificate contains an algorithm field with non-null parameters, assign the parameters to the working_public_key_parameters variable.
(d) 証明書の件名PublicKeyInfoフィールドに、非ヌルパラメーターを備えたアルゴリズムフィールドが含まれている場合、working_public_key_parameters変数にパラメーターを割り当てます。
If the subjectPublicKeyInfo field of the certificate contains an algorithm field with null parameters or parameters are omitted, compare the certificate subjectPublicKey algorithm to the working_public_key_algorithm. If the certificate subjectPublicKey algorithm and the working_public_key_algorithm are different, set the working_public_key_parameters to null.
証明書の件名PublicKeyInfoフィールドに、nullパラメーターまたはパラメーターを備えたアルゴリズムフィールドが含まれている場合は、証明書SubjectPublickeyアルゴリズムとWorking_public_key_algorithmを比較します。証明書SubjectPublicKey Algorithmとwork_public_key_algorithmが異なる場合は、work_public_key_parametersをnullに設定します。
(e) Assign the certificate subjectPublicKey algorithm to the working_public_key_algorithm variable.
(e) 証明書SubjectPublicKey Algorithmをwork_public_key_algorithm変数に割り当てます。
(f) If a key usage extension is present, verify that the digitalSignature bit is set.
(f) 主要な使用法が存在する場合は、DigitalSignatureビットが設定されていることを確認してください。
If either check (a) or (f) fails, the procedure terminates, returning a failure indication and an appropriate reason.
（a）または（f）のいずれかが故障した場合、手順は終了し、障害の表示と適切な理由を返します。
If (a) and (f) complete successfully, increment i and perform the basic certificate processing specified in 4.1.3.
（a）および（f）が正常に完了した場合、Iをインクリメントし、4.1.3で指定された基本的な証明書処理を実行します。
(a) Assign the certificate subject name to working_issuer_name.
(a) 証明書の件名をwork_issuer_nameに割り当てます。
(b) Assign the certificate subjectPublicKey to working_public_key.
(b) 証明書SubjectPublicKeyをwork_public_keyに割り当てます。
(c) If the subjectPublicKeyInfo field of the certificate contains an algorithm field with non-null parameters, assign the parameters to the proxy_issuer_public_key_parameters variable.
(c) 証明書の件名PublicKeyInfoフィールドに、非ヌルパラメーターを持つアルゴリズムフィールドが含まれている場合、proxy_issuer_public_key_parameters変数にパラメーターを割り当てます。
If the subjectPublicKeyInfo field of the certificate contains an algorithm field with null parameters or parameters are omitted, compare the certificate subjectPublicKey algorithm to the proxy_issuer_public_key_algorithm. If the certificate subjectPublicKey algorithm and the proxy_issuer_public_key_algorithm are different, set the proxy_issuer_public_key_parameters to null.
証明書の件名PublicKeyInfoフィールドに、nullパラメーターまたはパラメーターを備えたアルゴリズムフィールドが含まれている場合は、proxy_issuer_public_key_algorithmとproxy_issuer_public_key_algorithmと比較してください。証明書SubjectPublicKey Algorithmとproxy_issuer_public_key_algorithmが異なる場合、proxy_issuer_public_key_parametersをnullに設定します。
(d) Assign the certificate subjectPublicKey algorithm to the proxy_issuer_public_key_algorithm variable.
(d) 証明書SubjectPublicKeyアルゴリズムをproxy_issuer_public_key_algorithm変数に割り当てます。
If path processing succeeds, the procedure terminates, returning a success indication together with final value of the working_public_key, the working_public_key_algorithm, the working_public_key_parameters, and the proxy_policy_list.
パス処理が成功した場合、手順は終了し、Working_public_key、Work_public_key_algorithm、working_public_key_parameters、およびproxy_policy_listの最終的な値と一緒に成功の表示を返します。
Each Proxy Certificate contains a ProxyCertInfo extension, which always contains a policy language OID, and may also contain a policy OCTET STRING. These policies serve to indicate the desire of each issuer in the proxy certificate chain, starting with the EEC, to delegate some subset of their rights to the issued proxy certificate. This chain of policies is returned by the algorithm to the application.
各プロキシ証明書には、常にポリシー言語oidが含まれているproxycertinfo拡張機能が含まれており、ポリシーオクテット文字列も含まれる場合があります。これらのポリシーは、EECから始まるプロキシ証明書チェーンにおける各発行者の欲求を示し、彼らの権利の一部を発行されたプロキシ証明書に委任します。この一連のポリシーは、アルゴリズムによってアプリケーションに返されます。
The application MAY make authorization decisions based on the subject distinguished name of the proxy certificate or on one of the proxy certificates in it's issuing chain or on the EEC that serves as the root of the chain. If an application chooses to use the subject distinguished name of a proxy certificate in the issuing chain or the EEC it MUST use the returned policies to restrict the rights it grants to the proxy certificate. If the application does not know how to parse any policy in the policy chain it MUST not use, for the purposes of making authorization decisions, the subject distinguished name of any certificate in the chain prior to the certificate in which the unrecognized policy appears.
このアプリケーションは、プロキシ証明書の際立った名前の名前またはその発行チェーンのプロキシ証明書のいずれかまたはチェーンのルートとして機能するEECに基づいて認可決定を下す場合があります。アプリケーションが、発行チェーンまたはEECのプロキシ証明書の識別名の名前を使用することを選択した場合、返されたポリシーを使用して、プロキシ証明書に付与する権利を制限する必要があります。アプリケーションが、使用してはならないポリシーチェーンのポリシーを解析する方法を知らない場合、認可決定を下すために、認識されていないポリシーが表示される証明書の前に、チェーン内の証明書の任意の証明書の名前を識別します。
Application making authorization decisions based on the contents of the proxy certificate key usage or extended key usage extensions MUST examine the list of key usage, extended key usage and proxy policies resulting from proxy certificate path validation and determine the effective key usage functions of the proxy certificate as follows:
プロキシ証明書キーの使用法または拡張キー使用量の拡張のコンテンツに基づくアプリケーションの作成許可決定拡張機能は、プロキシ証明書のパス検証に起因する主要な使用法およびプロキシポリシーの拡張リストを調べ、プロキシ証明書の効果的なキー使用機能を決定する必要があります。次のように：
* If a certificate is a proxy certificate with a proxy policy of id-ppl-independent or an end entity certificate, the effective key usage functions of that certificate is as defined by the key usage and extended key usage extensions in that certificate. The key usage functionality of the issuer has no bearing on the effective key usage functionality.
* 証明書がID-PPL非依存性またはEnd Entity証明書のプロキシポリシーを備えたプロキシ証明書である場合、その証明書の有効な主要な使用機能は、主要な使用法とその証明書の主要な使用法拡張機能によって定義されています。発行者の主要な使用機能には、効果的なキー使用機能には関係ありません。
* If a certificate is a proxy certificate with a policy other than id-ppl-independent, the effective key usage and extended key usage functionality of the proxy certificate is the intersection of the functionality of those extensions in the proxy certificate and the effective key usage functionality of the proxy issuer.
* 証明書がID-PPL非依存以外のポリシーを備えたプロキシ証明書である場合、プロキシ証明書の有効な主要な使用法と拡張キー使用機能は、プロキシ証明書におけるそれらの拡張機能と効果的なキー使用機能の交差点です。プロキシ発行者の。
This section provides non-normative commentary on Proxy Certificates.
このセクションでは、プロキシ証明書に関する非規範的な解説を提供します。
An Attribute Certificate [i3] can be used to grant to one identity, the holder, some attribute such as a role, clearance level, or alternative identity such as "charging identity" or "audit identity". This is accomplished by way of a trusted Attribute Authority (AA), which issues signed Attribute Certificates (AC), each of which binds an identity to a particular set of attributes. Authorization decisions can then be made by combining information from the authenticated End Entity Certificate providing the identity, with the signed Attribute Certificates providing binding of that identity to attributes.
属性証明書[I3]を使用して、1つのID、所有者、役割、クリアランスレベルなどの属性、または「充電アイデンティティ」または「監査アイデンティティ」などの代替IDに付与できます。これは、署名された属性証明書（AC）を発行する信頼できる属性権限（AA）によって達成されます。その後、認証されたEnd Entity証明書から情報を組み合わせて、IDを提供する認証末端エンティティ証明書と、署名された属性証明書を属性に拘束する署名された属性証明書を組み合わせることにより、決定を行うことができます。
There is clearly some overlap between the capabilities provided by Proxy Certificates and Attribute Certificates. However, the combination of the two approaches together provides a broader spectrum of solutions to authorization in X.509 based systems, than either solution alone. This section seeks to clarify some of the overlaps, differences, and synergies between Proxy Certificate and Attribute Certificates.
プロキシ証明書と属性証明書によって提供される機能の間には、明らかにいくつかの重複があります。ただし、2つのアプローチの組み合わせは、どちらのソリューションだけでなく、X.509ベースのシステムでの承認に対するより広範なソリューションを提供します。このセクションでは、プロキシ証明書と属性証明書の間の重複、違い、および相乗効果の一部を明確にしようとしています。
For the purposes of this discussion, Attribute Authorities, and the uses of the Attribute Certificates that they produce, can be broken down into two broad classes:
この議論の目的のために、属性当局、およびそれらが生成する属性証明書の使用は、2つの広範なクラスに分類できます。
1) End entity AA: An End Entity Certificate may be used to sign an AC. This can be used, for example, to allow an end entity to delegate some of its privileges to another entity.
1) End Entity AA：End Entity証明書を使用してACに署名することができます。これは、たとえば、最終エンティティがその特権の一部を別のエンティティに委任できるようにするために使用できます。
2) Third party AA: A separate entity, aside from the end entity involved in an authenticated interaction, may sign ACs in order to bind the authenticated identity with additional attributes, such as role, group, etc. For example, when a client authenticates with a server, the third party AA may provide an AC that binds the client identity to a particular group, which the server then uses for authorization purposes.
2) サードパーティAA：認証された相互作用に関与する最終エンティティを除いて、別のエンティティは、認証されたアイデンティティを役割、グループなどの追加属性と結合するためにACSに署名する場合があります。たとえば、クライアントがクライアントが認証するときにサーバー、サードパーティAAは、クライアントのIDを特定のグループに結合するACを提供する場合があります。
This second type of Attribute Authority, the third party AA, works equally well with an EEC or a PC. For example, unrestricted Proxy Certificates can be used to delegate the EEC's identity to various other parties. Then when one of those other parties uses the PC to authenticate with a service, that service will receive the EEC's identity via the PC, and can apply any ACs that bind that identity to attributes in order to determine authorization rights. Additionally PC with policies could be used to selectively deny the binding of ACs to a particular proxy. An AC could also be bound to a particular PC using the subject or issuer and serial number of the proxy certificate. There would appear to be great synergies between the use of Proxy Certificates and Attribute Certificates produced by third party Attribute Authorities.
この2番目のタイプの属性権限であるサードパーティAAは、EECまたはPCで等しく機能します。たとえば、無制限のプロキシ証明書を使用して、EECの身元を他のさまざまな関係者に委任できます。次に、他の当事者のいずれかがPCを使用してサービスで認証すると、そのサービスはPCを介してEECのIDを受け取り、認可権を決定するためにそのIDを属性に結合するACSを適用できます。さらに、ポリシーを備えたPCを使用して、ACSの特定のプロキシへの拘束力を選択的に拒否できます。ACは、被験者または発行者、およびプロキシ証明書のシリアル番号を使用して、特定のPCにバインドすることもできます。プロキシ証明書の使用と、第三者属性当局によって作成された属性証明書の使用との間には、大きな相乗効果があるように思われます。
However, the uses of Attribute Certificates that are granted by the first type of Attribute Authority, the end entity AA, overlap considerably with the uses of Proxy Certificates as described in the previous sections. Such Attribute Certificates are generally used for delegation of rights from one end entity to others, which clearly overlaps with the stated purpose of Proxy Certificates, namely single sign-on and delegation.
ただし、前のセクションで説明されているように、プロキシ証明書の使用と大幅に重複して、属性権限の最初のタイプであるエンティティAAによって付与される属性証明書の使用法がかなり重複しています。このような属性証明書は、一般に、あるエンティティから他のエンティティへの権利の委任に使用されます。これは、プロキシ証明書の記載されている目的、つまりシングルサインオンと代表団と明らかに重複しています。
In the motivating example in Section 2, PCs are used to delegate Steve's identity to the various other jobs and entities that need to act on Steve's behalf. This allows those other entities to authenticate as if they were Steve, for example to the mass storage system.
セクション2の動機付けの例では、PCはスティーブのアイデンティティを、スティーブに代わって行動する必要がある他のさまざまなジョブやエンティティに委任するために使用されます。これにより、これらの他のエンティティは、たとえば大容量貯蔵システムのように、まるでそれらがスティーブであるかのように認証することができます。
A solution to this example could also be cast using Attribute Certificates that are signed by Steve's EEC, which grant to the other entities in this example the right to perform various operations on Steve's behalf. In this example, the reliable file transfer service and all the hosts involved in file transfers, the starter program, the agent, the simulation jobs, and the post-processing job would each have their own EECs. Steve's EEC would therefore issue ACs to bind each of those other EEC identities to attributes that grant the necessary privileges allow them to, for example, access the mass storage system.
この例の解決策は、スティーブのEECが署名する属性証明書を使用してキャストすることもできます。これは、この例の他のエンティティに、スティーブに代わってさまざまな操作を実行する権利を与えます。この例では、信頼できるファイル転送サービスとファイル転送に関与するすべてのホスト、スタータープログラム、エージェント、シミュレーションジョブ、および後処理ジョブにはそれぞれ独自のEECがあります。したがって、SteveのEECは、必要な特権を付与する属性に、他のEECのアイデンティティのそれぞれをバインドするためにACSを発行します。
However, this AC based solution to delegation has some disadvantages as compared to the PC based solution:
ただし、このACベースの代表団へのソリューションには、PCベースのソリューションと比較して、いくつかの欠点があります。
* All protocols, authentication code, and identity based authorization services must be modified to understand ACs. With the PC solution, protocols (e.g., TLS) likely need no modification, authentication code needs minimal modification (e.g., to perform PC aware path validation), and identity based authorization services need minimal modification (e.g., possibly to find the EEC name and to check for any proxy policies).
* ACSを理解するには、すべてのプロトコル、認証コード、およびIDベースの認証サービスを変更する必要があります。PCソリューションでは、プロトコル（TLSなど）は変更する必要がない可能性があります。認証コードは最小限の変更（PC認識パス検証を実行するため）、およびIDベースの認証サービスに最小限の変更（例えば、EEC名と見つけるために必要な変更が必要です。プロキシポリシーを確認するには）。
* ACs need to be created by Steve's EEC, which bind attributes to each of the other identities involved in the distributed application (i.e., the agent, simulation jobs, and post-processing job the file transfer service, the hosts transferring files). This implies that Steve must know in advance which other identities may be involved in this distributed application, in order to generate the appropriate ACs which are signed by Steve's ECC. On the other hand, the PC solution allows for much more flexibility, since parties can further delegate a PC without a priori knowledge by the originating EEC.
* ACは、SteveのEECによって作成される必要があります。これは、分散アプリケーションに関与する他の各アイデンティティ（つまり、エージェント、シミュレーションジョブ、およびファイル転送サービス、ホストファイルの転送サービス）に属する他の各アイデンティティに属性を結合する必要があります。これは、SteveのECCが署名する適切なACを生成するために、Steveがこの分散アプリケーションにどの他のアイデンティティが関与しているかを事前に知る必要があることを意味します。一方、PCソリューションは、発信されるEECによる先験的な知識なしにPCをさらに委任できるため、PCソリューションにより、はるかに柔軟性が可能になります。
There are many unexplored tradeoffs and implications in this discussion of delegation. However, reasonable arguments can be made in favor of either an AC based solution to delegation or a PC based solution to delegation. The choice of which approach should be taken in a given instance may depend on factors such as the software that it needs to be integrated into, the type of delegation required, and other factors.
この代表団の議論には、多くの未開拓のトレードオフと意味があります。ただし、代表団に対するACベースのソリューションまたは委任に対するPCベースのソリューションのいずれかを支持して、合理的な議論を行うことができます。特定のインスタンスでどのアプローチを取るべきかの選択は、統合する必要があるソフトウェア、必要な委任の種類、その他の要因などの要因に依存する場合があります。
One possible use of Proxy Certificates is to carry authorization information associated with a particular identity.
プロキシ証明書の使用の1つは、特定のIDに関連する認可情報を携帯することです。
The merits of placing authorization information into End Entity Certificates (also called a Public Key Certificate or PKC) have been widely debated. For example, Section 1 of "An Internet Attribute Certificate Profile for Authorization" [i3] states:
承認情報をEnd Entity証明書（公開鍵証明書またはPKCとも呼ばれる）に配置するメリットは、広く議論されています。たとえば、「承認のためのインターネット属性証明書プロファイル」のセクション1 [i3]は次のとおりです。
"Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.
「許可情報はPKC拡張機能に配置されるか、別の属性証明書（AC）に配置される場合があります。PKCSの許可情報の配置は通常、2つの理由で望ましくありません。まず、認可情報は、しばしばの拘束力と同じ寿命を持たないことがよくあります。IDと公開鍵。許可情報がPKC拡張機能に配置されている場合、一般的な結果はPKC有用な寿命の短縮です。次に、PKC発行者は通常、許可情報に対して権威がありません。これにより、追加の手順が追加されます。権威ある情報源から認可情報を取得するためのPKC発行者。
For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes."
これらの理由により、許可情報をPKCから分離する方が良いことがよくあります。しかし、認可情報もアイデンティティに拘束される必要があります。ACはこのバインディングを提供します。これは、単にデジタルで署名された（または認定された）アイデンティティと一連の属性です。」
Placing authorization information in a PC mitigates the first undesirable property cited above. Since a PC has a lifetime that is mostly independent of (always shorter than) its signing EEC, a PC becomes a viable approach for carrying authorization information for the purpose of delegation.
PCに許可情報を配置すると、上記の最初の望ましくないプロパティが軽減されます。PCには、署名EECからほとんど独立した（常に短い）寿命があるため、PCは委任を目的とした認可情報を実施するための実行可能なアプローチになります。
The second undesirable property cited above is true. If a third party AA is authoritative, then using ACs issued by that third party AA is a natural approach to disseminating authorization information. However, this is true whether the identity being bound by these ACs comes from an EEC (PKC), or from a PC.
上記の2番目の望ましくないプロパティは真実です。第三者AAが権威ある場合、その第三者AAが発行したACSを使用することは、認証情報を普及させるための自然なアプローチです。ただし、これは、これらのACSに拘束されているアイデンティティがEEC（PKC）からのものであろうとPCからのものであろうと、これは当てはまります。
There is one case, however, that the above text does not consider. When performing delegation, it is usually the EEC itself that is authoritative (not the EEC issuer, or any third party AA). That is, it is up to the EEC to decide what authorization rights it is willing to grant to another party. In this situation, including such authorization information into PCs that are generated by the EEC seems a reasonable approach to disseminating such information.
ただし、上記のテキストでは考慮されていないケースが1つあります。委任を行うとき、通常、権威あるのはEEC自体です（EEC発行者、または第三者AAではありません）。つまり、他の当事者にどのような認可権を与えるかを決定するのはEEC次第です。この状況では、EECによって生成されるPCへのそのような承認情報を含めて、そのような情報を広めるための合理的なアプローチのようです。
In a system that employs both PCs and ACs, one can imagine the utility of allowing a PC to be the holder of an AC. This would allow for a particular delegated instance of an identity to be given an attribute, rather than all delegated instances of that identity being given the attribute.
PCとACSの両方を採用するシステムでは、PCがACの所有者になることを許可するというユーティリティを想像できます。これにより、IDの特定の委任されたインスタンスに属性が与えられるようになります。
However, the issue of how to specify a PC as the holder of an AC remains open. An AC could be bound to a particular instance of a PC using the unique subject name of the PC, or it's issuer and serial number combination.
ただし、ACの所有者としてPCを指定する方法の問題は、開いたままです。ACは、PCの一意の件名名を使用してPCの特定のインスタンスにバインドできます。または、発行者とシリアル番号の組み合わせです。
Unrestricted PCs issued by that PC would then inherit those ACs and independent PCs would not. PCs issued with a policy would depend on the policy as to whether or not they inherit the issuing PC's ACs (and potentially which ACs they inherit).
そのPCによって発行された無制限のPCはそれらのACSを継承し、独立したPCはそうではありません。ポリシーで発行されたPCは、発行中のPCのACS（および潜在的にどのACが継承するか）を継承するかどうかについてのポリシーに依存します。
While an AC can be bound to one PC by the AA, how can the AA restrict that PC from passing it on to a subsequently delegated PC? One possible solution would be to define an extension to attribute certificates that allows the attribute authority to state whether an issued AC is to apply only to the particular entity to which it is bound, or if it may apply to PCs issued by that entity.
AAはAAによって1つのPCにバインドできますが、AAはそのPCをその後委任されたPCに渡すことをどのように制限できますか？考えられる解決策の1つは、属性権限が発行されたACがバインドされている特定のエンティティにのみ適用されるかどうか、またはそのエンティティが発行したPCに適用できるかどうかを述べる属性証明書の拡張機能を定義することです。
One issue that an AA in this circumstance would need to be aware of is that the PI of the PC that the AA bound the AC to, could issue another PC with the same name as the original PC to a different entity, effectively stealing the AC. This implies that an AA issuing an AC to a PC need to not only trust the entity holding the PC, but the entity holding the PC's issuer as well.
この状況でAAが認識する必要がある問題の1つは、AAがACに拘束するPCのPIが、元のPCと同じ名前の別のPCを別のエンティティに発行し、ACを効果的に盗むことができることです。。これは、PCにACを発行するAAがPCを保持しているエンティティだけでなく、PCの発行者も保有しているエンティティも信頼する必要があることを意味します。
The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a widely used authentication system based on conventional (shared secret key) cryptography. It provides support for single sign-on via creation of "Ticket Granting Tickets" or "TGT", and support for delegation of rights via "forwardable tickets".
Kerberos Network認証プロトコル（RFC 1510 [i6]）は、従来の（共有秘密鍵）暗号化に基づいた広く使用されている認証システムです。「チケット付与チケット」または「TGT」の作成を介したシングルサインオンのサポートと、「フォワーダブルチケット」を介した権利の委任のサポートを提供します。
Kerberos 5 tickets have informed many of the ideas surrounding X.509 Proxy Certificates. For example, the local creation of a short-lived PC can be used to provide single sign-on in an X.509 PKI based system, just as creation of short-lived TGT allows for single sign-on in a Kerberos based system. And just as a TGT can be forwarded (i.e., delegated) to another entity to allow for proxying in a Kerberos based system, so can a PC can be delegated to allow for proxying in an X.509 PKI based system.
Kerberos 5チケットは、X.509プロキシ証明書を取り巻くアイデアの多くを通知しています。たとえば、短命のTGTの作成によりKerberosベースのシステムでシングルサインオンを可能にするように、短命のPCのローカル作成を使用してX.509 PKIベースのシステムでシングルサインオンを提供できます。また、TGTを別のエンティティに転送（つまり、委任）してKerberosベースのシステムでのプロキシを可能にすることができるように、X.509 PKIベースのシステムでのプロキシを可能にするためにPCを委任できます。
A major difference between a Kerberos TGT and an X.509 PC is that while creation and delegation of a TGT requires the involvement of a third party (Key Distribution Center), a PC can be unilaterally created without the active involvement of a third party. That is, a user can directly create a PC from an EEC for single sign-on capability, without requiring communication with a third party. And an entity with a PC can delegate the PC to another entity (i.e., by creating a new PC, signed by the first) without requiring communication with a third party.
Kerberos TGTとX.509 PCの大きな違いは、TGTの作成と委任にはサードパーティ（キー流通センター）の関与が必要であるが、PCは第三者の積極的な関与なしに一方的に作成できることです。つまり、ユーザーは、サードパーティとの通信を必要とせずに、シングルサインオン機能のためにEECからPCを直接作成できます。また、PCを備えたエンティティは、第三者との通信を必要とせずに、PCを別のエンティティに委任することができます（つまり、最初のPCを作成することにより）。
The method used by Kerberos implementations to protect a TGT can also be used to protect the private key of a PC. For example, some Unix implementations of Kerberos use standard Unix file system security to protect a user's TGT from compromise. Similarly, the Globus Toolkit's Grid Security Infrastructure implementation of Proxy Certificates protects a user's PC private key using this same approach.
Kerberosの実装がTGTを保護するために使用する方法は、PCの秘密鍵を保護するために使用することもできます。たとえば、KerberosのUNIX実装には、標準のUNIXファイルシステムセキュリティを使用して、ユーザーのTGTを妥協から保護しています。同様に、Globus Toolkitのプロキシ証明書のグリッドセキュリティインフラストラクチャの実装は、この同じアプローチを使用してユーザーのPC秘密キーを保護します。
This section gives some examples of Proxy Certificate usage and some examples of how the Proxy policy can be used to restrict Proxy Certificates.
このセクションでは、プロキシ証明書の使用法とプロキシポリシーを使用してプロキシ証明書を制限する方法の例を示します。
Steve wishes to perform a third-party FTP transfer between two FTP servers. Steve would use an existing PC to authenticate to both servers and delegate a PC to both hosts. He would inform each host of the unique subject name of the PC given to the other host. When the servers establish the data channel connection to each other, they use these delegated credentials to perform authentication and verify they are talking to the correct entity by checking the result of the authentication matches the name as provided by Steve.
Steveは、2つのFTPサーバー間でサードパーティFTP転送を実行したいと考えています。Steveは、既存のPCを使用して、両方のサーバーに認証し、PCを両方のホストに委任します。彼は各ホストに、他のホストに与えられたPCのユニークな件名名を通知します。サーバーが互いにデータチャネル接続を確立すると、これらの委任された資格情報を使用して認証を実行し、スティーブが提供する名前と一致する認証の結果をチェックすることにより、正しいエンティティと話していることを確認します。
Steve wishes to delegate to a process the right to perform a transfer of a file from host H1 to host H2 on his behalf. Steve would delegate a PC to the process and he would use Proxy Policy to restrict the delegated PC to two rights - the right to read file F1 on host H1 and the right to write file F2 on host H2.
スティーブは、ホストH1からホストH2へのファイルの転送を彼に代わって実行する権利をプロセスに委任したいと考えています。SteveはPCをプロセスに委任し、プロキシポリシーを使用して委任されたPCを2つの権利に制限します - ホストH1のファイルF1とホストH2にファイルF2を記述する権利を読み取ります。
The process then uses this restricted PC to authenticate to servers H1 and H2. The process would also delegate a PC to both servers. Note that these delegated PCs would inherit the restrictions of their parents, though this is not relevant to this example. As in the example in the previous Section, each host would be provided with the unique name of the PC given to the other server.
このプロセスは、この制限されたPCを使用して、サーバーH1とH2に認証します。また、プロセスは両方のサーバーにPCを委任します。これらの委任されたPCは両親の制限を継承することに注意してくださいが、これはこの例には関係ありません。前のセクションの例のように、各ホストには他のサーバーに与えられたPCの一意の名前が提供されます。
Now when the process issues the command to transfer the file F1 on H1 and to F2 on H2, these two servers perform an authorization check based on the restrictions in the PC that the process used to authenticate with them (in addition to any local policy they have). Namely H1 checks that the PC gives the user the right to read F1 and H2 checks that the PC gives the user the right to write F2. When setting up the data channel the servers would again verify the names resulting from the authentication match the names provided by Steve as in the example in the previous Section.
プロセスがコマンドを発行してH1のファイルF1をH2でF2に転送すると、これら2つのサーバーは、プロセスがそれらを認証するために使用したPCの制限に基づいて認証チェックを実行します（ローカルポリシーに加えて、持っている）。つまり、H1は、PCがユーザーにF1を読み取る権利を提供することをチェックし、H2はPCがユーザーにF2を書き込む権利を与えることをチェックします。データチャネルをセットアップすると、サーバーは、前のセクションの例のように、Steveが提供する名前を認証と一致させる名前を再度確認します。
The extra security provided by these restrictions is that now if the PC delegated to the process by Steve is stolen, its use is greatly limited.
これらの制限によって提供される追加のセキュリティは、Steveによるプロセスに委任されたPCが盗まれた場合、その使用が大きく制限されていることです。
A relying party accepting a Proxy Certificate may have an interest in knowing which parties issued earlier Proxy Certificates in the certificate chain and to whom they delegated them. For example it may know that a particular service or resource is known to have been compromised and if any part of a Proxy Certificate's chain was issued to the compromised service a relying party may wish to disregard the chain.
代理証明書を受け入れる頼る当事者は、証明書チェーンで以前のプロキシ証明書を発行した当事者と、誰に委任したかを知ることに関心があるかもしれません。たとえば、特定のサービスまたはリソースが侵害されていることが知られていることがわかっている場合があり、プロキシ証明書のチェーンの一部が侵害されたサービスに発行された場合、頼る当事者はチェーンの無視を望むかもしれません。
A delegation tracing mechanism was considered by the authors as additional information to be carried in the ProxyCertInfo extension. However at this time agreement has not been reached as to what this information should include so it was left out of this document, and will instead be considered in future revisions. The debate mainly centers on whether the tracing information should simply contain the identity of the issuer and receiver or it should also contain all the details of the delegated proxy and a signed statement from the receiver that the proxy was actually acceptable to it.
著者は、Proxycertinfo拡張で実施される追加情報と委任されたトレースメカニズムを著者によって考慮しました。ただし、この時点で、この情報が何を含めるべきかに関して契約に達していないため、この文書から除外され、代わりに将来の改訂で検討されます。議論は主に、トレース情報が単に発行者と受信者の身元を単純に含めるべきか、それとも委任されたプロキシのすべての詳細と、プロキシが実際に受け入れられるという受信機からの署名された声明を含める必要があるかどうかに焦点を当てています。
In some cases, it may be desirable to know the hosts involved in a delegation transaction (for example, a relying party may wish to reject proxy certificates that were created on a specific host or domain). An extension could be modified to include the PA's and Acceptor's IP addresses; however, IP addresses are typically easy to spoof, and in some cases the two parties to a transaction may not agree on the IP addresses being used (e.g., if the Acceptor is on a host that uses NAT, the Acceptor and the PA may disagree about the Acceptor's IP address).
場合によっては、代表団の取引に関与するホストを知ることが望ましい場合があります（たとえば、頼る当事者は、特定のホストまたはドメインで作成された代理証明書を拒否したい場合があります）。拡張機能を変更して、PAおよびアクセプターのIPアドレスを含めることができます。ただし、IPアドレスは通常、スプーフィングが簡単であり、場合によっては、トランザクションの2つの関係者が使用されているIPアドレスについて同意しない場合があります（たとえば、AcceptorがNATを使用するホストにある場合、アクセプターとPAは同意しない場合があります。アクセプターのIPアドレスについて）。
Another suggestion was, in those cases where domain information is needed, to require that the subject names of all End Entities involved (the Acceptor(s) and the End Entity that appears in a PC's certificate path) include domain information.
別の提案は、ドメイン情報が必要な場合、関係するすべての最終エンティティの主題名（Acceptor（S）とPCの証明書パスに表示される最終エンティティ）にドメイン情報が含まれることを要求することでした。
In this Section we discuss security considerations related to the use of Proxy Certificates.
このセクションでは、プロキシ証明書の使用に関するセキュリティ上の考慮事項について説明します。
A Proxy Certificate is generally less secure than the EEC that issued it. This is due to the fact that the private key of a PC is generally not protected as rigorously as that of the EEC. For example, the private key of a PC is often protected using only file system security, in order to allow that PC to be used for single sign-on purposes. This makes the PC more susceptible to compromise.
通常、プロキシ証明書は、発行したEECよりも安全性が低くなります。これは、PCの秘密鍵が一般にEECほど厳密に保護されていないという事実によるものです。たとえば、PCの秘密鍵は、ファイルシステムセキュリティのみを使用して保護されます。これにより、PCは妥協の影響を受けやすくなります。
However, the risk of a compromised PC is only the misuse of a single user's privileges. Due to the PC path validation checks, a PC cannot be used to sign an EEC or PC for another user.
ただし、PCの侵害のリスクは、単一のユーザーの特権の誤用にすぎません。PCパス検証チェックのため、PCを使用して別のユーザーのEECまたはPCに署名することはできません。
Further, a compromised PC can only be misused for the lifetime of the PC, and within the bound of the restriction policy carried by the PC. Therefore, one common way to limit the misuse of a compromised PC is to limit its validity period to no longer than is needed, and/or to include a restriction policy in the PC that limits the use of the (compromised) PC.
さらに、侵害されたPCは、PCの寿命、およびPCが運ぶ制限ポリシーの境界内でのみ誤用することができます。したがって、侵害されたPCの誤用を制限する一般的な方法の1つは、その有効期間を必要以上に制限すること、および/または（侵害された）PCの使用を制限するPCに制限ポリシーを含めることです。
In addition, if a PC is compromised, it does NOT compromise the EEC that created the PC. This property is of great utility in protecting the highly valuable, and hard to replace, public key of the EEC. In other words, the use of Proxy Certificates to provide single sign-on capabilities in an X.509 PKI environment can actually increase the security of the end entity certificates, because creation and use of the PCs for user authentication limits the exposure of the EEC private key to only the creation of the first level PC.
さらに、PCが侵害された場合、PCを作成したEECを侵害しません。このプロパティは、非常に価値のある、交換が困難なEECの公開鍵を保護するのに非常に優れています。言い換えれば、ユーザー認証のためにPCSの作成と使用がEECの露出を制限するため、X.509 PKI環境で単一のサインオン機能を提供するためにプロキシ証明書を使用することで、ENDエンティティ証明書のセキュリティを増加させることができます。ファーストレベルのPCの作成のみの秘密鍵。
The pCPathLenConstraint field of the proxyCertInfo extension can be used by an EEC to limit subsequent delegation of the PC. A service may choose to only authorize a request if a valid PC can be delegated to it. An example of such as service is a job starter, which may choose to reject a job start request if a valid PC cannot be delegated to it. By limiting the pCPathLenConstraint, an EEC can ensure that a compromised PC of one job cannot be used to start additional jobs elsewhere.
Proxycertinfo拡張のPCPATHLENCONSTRANTフィールドは、EECによってPCの後続の委任を制限するために使用できます。サービスは、有効なPCを委任できる場合にのみリクエストを承認することを選択できます。サービスなどの例はジョブスターターです。これは、有効なPCを委任できない場合にジョブスタートリクエストを拒否することを選択する場合があります。PCPATHLENCONSTRAINTを制限することにより、EECは1つのジョブの侵害されたPCを使用して他の場所で追加のジョブを開始できないことを保証できます。
An EEC or PC can limit what a new PC can be used for by turning off bits in the Key Usage and Extended Key Usage extensions. Once a key usage or extended key usage has been removed, the path validation algorithm ensures that it cannot be added back in a subsequent PC. In other words, key usage can only be decreased in PC chains.
EECまたはPCは、主要な使用法でビットをオフにし、主要な使用法拡張機能を拡張することにより、新しいPCが使用できるものを制限できます。主要な使用法または拡張されたキー使用量が削除されると、PATH検証アルゴリズムにより、後続のPCに追加できないことが保証されます。言い換えれば、主要な使用法はPCチェーンでのみ減少する可能性があります。
The EEC could use the CRL Distribution Points extension and/or OCSP to take on the responsibility of revoking PCs that it had issued, if it felt that they were being misused.
EECは、CRLディストリビューションポイント拡張および/またはOCSPを使用して、発行したPCを取り消す責任を引き受けることができます。
The relying party that is going to authorize some actions on the basis of a PC will be aware that it has been presented with a PC, and can determine the depth of the delegation and the time that the delegation took place. It may want to use this information in addition to the information from the signing EEC. Thus a highly secure resource might refuse to accept a PC at all, or maybe only a single level of delegation, etc.
PCに基づいていくつかのアクションを承認する依存関係者は、PCが提示されていることを認識し、代表団の深さと委任が行われた時間を決定できます。署名EECの情報に加えて、この情報を使用することができます。したがって、非常に安全なリソースは、PCをまったく受け入れることを拒否したり、単一のレベルの代表団などを受け入れることを拒否する可能性があります。
The relying party should also be aware that since the policy restricting the rights of a PC is the intersection of the policy of all the PCs in it's certificate chain, this means any change in the certificate chain can effect the policy of the PC. Since there is no mechanism in place to enforce unique subject names of PCs, if an issuer were to issue two PCs with identical names and keys, but different rights, this could allow the two PCs to be substituted for each other in path validation and effect the rights of a PC down the chain. Ultimately, this means the relying party places trust in the entities that are acting as Proxy Issuers in the chain to behave properly.
また、頼る当事者は、PCの権利を制限するポリシーが証明書チェーン内のすべてのPCのポリシーの交差点であるため、証明書チェーンの変更がPCのポリシーに影響を与える可能性があることを認識する必要があります。PCの一意のサブジェクト名を実施するメカニズムが整っていないため、発行者が同一の名前とキーを持つ2つのPCを発行した場合、これにより2つのPCがパス検証と効果で相互に置き換えることができます。チェーンのPCの権利。最終的に、これは、頼る当事者が、適切に振る舞うためにチェーン内の代理発行者として行動しているエンティティに信頼を置くことを意味します。
As discussed in Section 2.3, one of the motivations for Proxy Certificates is to allow for dynamic delegation between parties. This delegation potentially requires, by the party receiving the delegation, the generation of a new key pair which is a potentially computationally expensive operation. Care should be taken by such parties to prevent another entity from performing a denial of service attack by causing them to consume large amount of resource doing key generation.
セクション2.3で説明したように、プロキシ証明書の動機の1つは、当事者間の動的な委任を可能にすることです。この代表団は、代表団を受け取る当事者によって、潜在的に計算上の高価な操作である新しいキーペアの生成を潜在的に要求しています。そのような当事者は、他のエンティティが主要生成を行う大量のリソースを消費することにより、サービス拒否攻撃を行うことを防ぐために注意する必要があります。
A general guideline would always to perform authentication of the delegating party to prevent such attacks from being performed anonymously. Another guideline would be to maintain some state to detect and prevent such attacks.
一般的なガイドラインは、そのような攻撃が匿名で実行されるのを防ぐために、委任当事者の認証を常に実行するために常に行われます。別のガイドラインは、そのような攻撃を検出および防止するために、ある状態を維持することです。
As discussed in Section 2.7, one potential use of Proxy Certificates is to ease certificate management for end users by storing the EEC private keys and certificates in a centrally managed repository. When a user needs a PKI credential, the user can login to the repository using name/password, one time password, etc. and the repository would then delegate a PC to the user with proxy rights, but continue to protect the EEC private key in the repository.
セクション2.7で説明したように、プロキシ証明書の潜在的な使用は、EECのプライベートキーと証明書を中央管理リポジトリに保存することにより、エンドユーザーの証明書管理を容易にすることです。ユーザーがPKI資格情報を必要とする場合、ユーザーは名前/パスワード、ワンタイムパスワードなどを使用してリポジトリにログインでき、リポジトリはPCをプロキシ権利を持つユーザーに委任しますが、EECプライベートキーを保護し続けます。リポジトリ。
Care must be taken with this approach since compromise of the repository will potentially give the attacker access to the long-term private keys stored in the repository. It is strongly suggested that some form of hardware module be used to store the long-term private keys, which will serve to help prevent their direct threat though it may still allow a successful attacker to use the keys while the repository is compromised to sign arbitrary objects (including Proxy Certificates).
リポジトリの妥協により、攻撃者がリポジトリに保存されている長期的なプライベートキーへのアクセスを可能にする可能性があるため、このアプローチには注意が必要です。何らかの形のハードウェアモジュールを使用して長期的なプライベートキーを保存することを強くお勧めします。これは、成功した攻撃者がキーを使用できるようにする可能性があります。オブジェクト（プロキシ証明書を含む）。
IANA has established a registry for policy languages. Registration under IETF space is by IETF standards action as described in [i8]. Private policy languages should be under organizational OIDs; policy language authors are encouraged to list such languages in the IANA registry, along with a pointer to a specification.
IANAは、ポリシー言語のレジストリを確立しました。IETFスペースに基づく登録は、[I8]で説明されているIETF標準アクションによるものです。民間の政策言語は、組織のOIDの下にある必要があります。ポリシー言語著者は、仕様へのポインターとともに、IANAレジストリにそのような言語をリストすることをお勧めします。
OID Description
--- -----------
1.3.6.1.5.5.7.21.1 id-ppl-inheritALL
1.3.6.1.5.5.7.21.2 id-ppl-independent
[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[n1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[n2] 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.
[n2] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S. Tuecke, "A National-Scale Authentication Infrastructure", IEEE Computer, vol. 33, pp. 60-66, 2000.
[i1] Butler、R.、Engert、D.、Foster、I.、Kesselman、C。、およびS. Tuecke、「全国規模の認証インフラストラクチャ」、IEEE Computer、vol。33、pp。60-66、2000。
[i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[i2] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[i3] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[i3] Farrell、S。およびR. Housley、「認証のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
[i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A Security Architecture for Computational Grids", presented at Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998.
[i4] Foster、I.、Kesselman、C.、Tsudik、G。、およびS. Tuecke、「計算グリッドのセキュリティアーキテクチャ」、1998年、コンピューターおよび通信セキュリティに関する第5回ACM会議の議事録で発表されました。
[i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the Grid: Enabling Scalable Virtual Organizations", International Journal of Supercomputer Applications, 2001.
[i5] Foster、I.、Kesselman、C。、およびS. Tuecke、「グリッドの解剖学：スケーラブルな仮想組織の有効化」、International Journal of SuperComputer Applications、2001。
[i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[i6] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[i7] Neuman, B. Clifford, "Proxy-Based Authorization and Accounting for Distributed Systems", In Proceedings of the 13th International Conference on Distributed Computing Systems, pages 283-291, May 1993.
[i7] Neuman、B。Clifford、「分散システムの代理ベースの承認と会計」、1993年5月283〜291ページの分散コンピューティングシステムに関する第13回国際会議の議事録。
[i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA Considerations Section in RFC", RFC 2434, October 1998.
[i8] Narten、T。およびH. Alvestrand。「RFCでIANA考慮事項セクションを作成するためのガイドライン」、RFC 2434、1998年10月。
We are pleased to acknowledge significant contributions to this document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist.
David Chadwick、Ian Foster、Jarek Gawor、Carl Kesselman、Sam Meder、Jim Schaad、およびFrank Siebenlistによるこの文書への多大な貢献を認めてうれしいです。
We are grateful to numerous colleagues for discussions on the topics covered in this paper, in particular (in alphabetical order, with apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman, Gene Tsudik.
この論文で説明されているトピックについての議論については、特に（アルファベット順に、私たちが見逃した人に謝罪します）：カーライルアダムス、ジョーベスター、ランディバトラー、キースジャクソン、スティーブハンナ、ラスハウリー、スティーブン・ケント、ビル・ジョンストン、マーティ・ハンフリー、サム・ラング、エレン・マクダーモット、クリフォード・ノイマン、ジーン・ツディク。
We are also grateful to members of the Global Grid Forum (GGF) Grid Security Infrastructure working group (GSI-WG), and the Internet Engineering Task Force (IETF) Public-Key Infrastructure (X.509) working group (PKIX) for feedback on this document.
また、グローバルグリッドフォーラム（GGF）グリッドセキュリティインフラストラクチャワーキンググループ（GSI-WG）、およびフィードバックについてはインターネットエンジニアリングタスクフォース（IETF）のパブリックキーインフラストラクチャ（X.509）ワーキンググループ（X.509）のメンバーにも感謝しています。このドキュメントで。
This work was supported in part by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, U.S. Department of Energy, under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense Advanced Research Projects Agency under contract N66001-96-C-8523; by the National Science Foundation; and by the NASA Information Power Grid project.
この作業は、契約W-31-109-ENG-38およびDE-AC03-76SF0098の下で、米国エネルギー省の高等科学コンピューティング研究局の数学、情報、および計算科学部門のサブプログラムによってサポートされていました。契約N66001-96-C-8523の下での防衛先進研究プロジェクト局。国立科学財団。NASA Information Power Grid Projectによって。
PKIXproxy88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
proxy-cert-extns(25) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL --
- すべてエクスポート -
-- IMPORTS NONE --
- 輸入なし -
-- PKIX specific OIDs
-PKIX固有のOID
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- Locally defined OIDs
- ローカルで定義されたOID
-- The proxy certificate extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
-- Proxy certificate policies languages defined in
id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
END
終わり
Authors' Addresses
著者のアドレス
Steven Tuecke Distributed Systems Laboratory Mathematics and Computer Science Division Argonne National Laboratory Argonne, IL 60439
Steven Tuecke分散システム研究所数学およびコンピューターサイエンス部門Argonne National Laboratory Argonne、IL 60439
Phone: 630-252-8711 EMail: tuecke@mcs.anl.gov
電話：630-252-8711メール：tuecke@mcs.anl.gov
Von Welch National Center for Supercomputing Applications University of Illinois
フォンウェルチ国立センタースーパーコンピューティングアプリケーション大学イリノイ大学
EMail: vwelch@ncsa.uiuc.edu
Doug Engert Argonne National Laboratory
Doug Engert Argonne National Laboratory
EMail: deengert@anl.gov
Laura Pearlman University of Southern California, Information Sciences Institute
南カリフォルニア大学ローラパールマン大学情報科学研究所
EMail: laura@isi.edu
Mary Thompson Lawrence Berkeley National Laboratory
メアリー・トンプソン・ローレンス・バークレー国立研究所
EMail: mrthompson@lbl.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。