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
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）インターネット協会（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]の使用は、エンティティBは、として機能している、エンティティAは、別のエンティティBには、換言すればAをあたかもBが他と承認されるために権利を付与することを可能にするセキュリティシステムで使用される一般的な技術でありますこのドキュメントは、RFC 3280、「インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル」[N2]に基づいて、プロキシ証明書の証明書プロファイルを構成するエンティティA.に代わって代理。
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.
エンドエンティティ証明書の名前の名前に由来し、固有の名前を持つ*プロキシ証明書、。これは、プロキシ証明書は、属性証明書などの属性アサーションのアプローチと組み合わせて使用することができます[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節では、プロキシ証明書に記載されている情報の内容に関する要件を定義します。このプロファイルは、基本的な証明書では二つのフィールドだけでなく、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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で定義されています。それは、それはX.509公開鍵証明書は、CAによって、そのようなユーザーやサービスとして、エンドエンティティに発行されています
* 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：「プロキシ発行者は、」プロキシの証明書を発行したエンドエンティティ証明書またはプロキシ証明書を持つエンティティです。プロキシ証明書は、プロキシの発行者の証明書の公開鍵に関連付けられた秘密鍵を使って署名されています。
* 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年には、グローバス・プロジェクト（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.
スティーブは彼の会社のイントラネットベースのグリッド上の周りのさまざまなホスト間での大容量ファイルの数の動きを管理するために信頼性の高いファイル転送サービスを使用したいエンジニアです。彼のラップトップから彼はサービスに転送要求の数を提出し、彼がオフラインであることを含め、他のことをやっている間に転送されたファイルを持って望んでいます。転送サービスは、転送を開始する前に、（時間または低リソース使用量の期間後まで、例えば）いくつかの時間の要求を待機させることができます。転送サービスは、その後、各ファイルについて、送信元と宛先ホストのそれぞれに接続し、ファイルを転送するために、ソースから宛先への直接データ接続を開始するように指示します。スティーブは、定期的に転送サービスを接触させることにより、転送の進捗状況をチェックする彼のラップトップ上で実行中のエージェントを残すだろう。もちろん、彼は彼が彼のPKIスマートカードを使用して、このすべてを開始することを要求され、これのすべては彼の会社のリソースに安全に起こることを望んでいます。
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.
*スティーブは、相互に転送要求を提出する信頼性の高いファイル転送サービスで認証できるようにする必要があります。
* 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.
*シングルサインオン：スティーブは、かつて彼のスマートカードパスワード（またはピン）を入力し、[転送サービスへのすべてのファイル転送要求を提出した後、定期的に転送の状況を確認するプログラムを実行したいと考えています。このプログラムは、スマートカードやスティーブのパスワードを繰り返しアクセスを必要とせずに、安全にこれらの操作をすべて実行できるようにする権利を付与する必要があります。
* 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.
*委任：このシナリオでは様々なリモートプロセスはスティーブの代わりに安全な操作を実行する必要があるので、必要な権限を委任されている必要があります。たとえば、ファイル転送サービスは、送信元と送信先のホストとスティーブの代理で認証できるようにする必要があり、順番にそれらのホストへの委任権は、彼らがお互いに認証できる必要がありますように。
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.
*プロキシは、転送サービスに要求を提出するとき、クライアント/エージェントプログラムは、スティーブとして認可することができ、必要なプロキシ資格を作成するために、一度だけアクセスできるように、スマートカードに保存されている秘密鍵が可能になります。スマートカードとスティーブのパスワードへのアクセスは、プロキシ資格の初期作成後は必要ありません。
* 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.
*ラップトップ上のクライアントプログラムは、ファイル転送サービスへのスティーブのために行動する権限を委任することができます。これは、順番に、サービスは、ストレージホストに認証し、ファイル転送を開始するためにスティーブの権限を継承することができます。
* 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.
*ラップトップ上のエージェントが転送の状態をチェックするためにファイル転送サービスに再接続するときは、相互認証を実行することができます。ノートパソコンはただ、スマートカードを使用して新たに作成され、新しく生成されたプロキシ資格を使用することができます。
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.
この問題を解決するには、プロキシ証明書の方針により、プロキシ上に配置するための制限を可能にすることです。例えば、上記の例では信頼性の高いファイル転送サービスを実行しているマシンにのみ、宛先ファイルをソースファイルを読み書きする目的のためにスティーブの権利を与えている可能性があります。そのファイル転送サービスが侵害された場合そのため、攻撃者が読まれるスティーブがアクセス権を持っている、などのすべての攻撃者が行うことができるであろうことをスティーブの代理として、上のジョブを起動することはできませんし、他のファイルを作成または変更することはできません、ソースファイルを変更することはできませんファイル転送サービスを委任された前記特定のファイルは読み取りアクセスを、ファイル転送サービスが書き込みアクセス権を委任されているものの代わりに偽のファイルを書き込みます。さらに、ファイル転送サービスに委任された資格の有効期間を制限することで、妥協の効果がさらに緩和することができます。
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.
彼らは明示的ポリシーステートメントで議論できるように、これらのエンティティは、一意のIDを持っていることも望ましいです。たとえば、サードパーティ製のFTP転送を開始し、ユーザーが独自のアイデンティティと各FTPサーバにPCを付与し、他のアイデンティティの各サーバに通知することができ2台のサーバーが接続されている場合、彼らは自分自身を認証し、それらが接続されている知っている可能性があり適切なパーティー。
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:
それ自身の権利を持っているパーティーのためにためには、一意のIDが必要です。一意のIDを取得するための可能なオプションは次のとおりです。
1) Obtain an identity from a traditional Certification Authority (CA).
1）伝統的な認証局（CA）からIDを取得します。
2) Obtain a new identity independently - for example by using the generated public key and a self-signed certificate.
生成された公開鍵と自己署名証明書を使用することにより、例えば - 2）独立して新しいアイデンティティを取得します。
3) Derive the new identity from an existing identity.
3）既存のIDからの新しいアイデンティティを導出します。
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エンドエンティティ証明書（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がEECによってそのPC上に置かれている制限を受け、PCに署名したEECの権利を継承することで、認証のために使用されている場合。
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].
そのアイデンティティはEECのアイデンティティから派生しているが5）、それもユニークです。 【I3]で定義されるように、これは、属性アサーションに関連して、例えば、このIDが発行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）これはPCとしてそれを識別し、PCの使用にポリシーを配置するために、新しいX.509拡張が含まれています。この新しい拡張機能は、他の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.
PCがエンティティBへエンティティAからの代表団の一部として作成されたとき、このプロセスは、その後、認証、整合性チェックの上にエンティティAとエンティティBからPC要求を渡し、エンティティB内のステップ＃1及び＃2を実行することによって修正されますチャネルは、その後、エンティティAは、ステップ＃3を実行し、エンティティBに戻ってPCを渡し
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.
PCは、パスの検証にのみ最小限の変更を必要とするため、O、既存のX.509ベースのソフトウェアにプロキシ証明書のサポートを組み込むことは非常に簡単です。例えば、SSL / TLSは、PCを使用した認証をサポートするために、何のプロトコルを変更する必要はありません。さらに、SSL / TLSの実装では、PCのパス検証をサポートするために、代わりに認証目的のために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.
シングルサインオンのためにPCを使用してoをユーザーが一度「ログイン」して、安全にさまざまな操作を実行できるようにすることで、使用する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資格を必要とする場合、ユーザーが次にリポジトリがプロキシ権限を持つユーザーに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は、エンティティBはこれまで、エンティティAの秘密鍵を見ることなく、エンティティBにPCを委任することができ、かつ実体なしAはこれまでに、エンティティBが保持し、新たに委任PCの秘密鍵を見て換言すれば、秘密鍵は、共有または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秘密鍵の生活、スマートカードは、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.
PCを作成する場合は、O、PIはPC、そのPCで作成することができるPCのパスの深さ、およびPCやその子孫の鍵使用の有効期間を制限することができます。さらに、きめ細かなポリシーは、さらにPCを使用して実行できる操作を制限するためにPCで行うことができます。これらの制限は、いずれかの偶然または悪意を持って、PCの持参により行うことができる損傷を制限するためにPIを許可します。
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を持つの通常面倒で時間のかかるプロセスを通過するようにユーザーを必要としないので、これは、日々の使用のためにそれ以外の場合は制限されたPCが魅力的、短期的になりますか、 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.
プロキシ証明書の代理発行者は、エンドエンティティ証明書、または別のプロキシ証明書のいずれかでなければなりません。
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.
たとえば、プロキシ発行者は、発行PCに固有のシリアル番号を割り当てるために順次割り当てられる整数または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フィールドがTRUEにすることはできません。
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は、この証明書は、プロキシ証明書に署名するために使用してはならないことを意味します。 pCPathLenConstraintフィールドが存在しない場合、最大のプロキシパスの長さに制限はありません。エンドエンティティ証明書は、無制限の最大プロキシパスの長さを有しています。
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内、ポリシーフィールドは、ポリシーの表現であり、policyLanguageフィールドは、ポリシーが表現される言語を示します。
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拡張のproxyPolicyフィールドには、プロキシの制限のために使用されるポリシー言語を定義するものではありません。むしろ、それは適切な言語を定義するために、その言語のためのOIDを取得する（または適切な予め定義された言語/ OIDを選択するために）その拡張子を使用してこれらの当事者に負担をかけます。それはproxyPolicyフィールドを持つ証明書とその意味に同意し、そのフィールドを解釈する証明書利用者を出し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.
上記policyLanguage値のいずれかについて、ポリシーフィールドが存在してはなりません。
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フィールドの他の値は、これが制限されたプロキシ認証で、プロキシを実行する能力を制限する他のいくつかのポリシーを持っていることを示しています。この場合、ポリシーフィールドが存在してもよく、それは、ポリシーを表す情報を含まなければなりません。ポリシーフィールドが存在しない場合は、ポリシーpolicyLanguageフィールド自体の値で暗黙的でなければなりません。追加のポリシー言語の作者が公に彼らのポリシー言語を文書化し、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.
プロキシの発行者がEECの場合は2）その後、依存者のローカルポリシーは、EECに名前付きエンティティに対する要求を承認する必要があります。
3) If the Proxy Issuer is another PC, then one of the following MUST be true:
プロキシの発行者は、別のPCであれば3）、その後、次のいずれかが真でなければなりません：
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。プロキシの発行者は、そのプロキシポリシーによって、その発行者からの要求を実行する権限を継承します。これは、再帰的にプロキシ発行者にこれらの三つの条件を検証することによって検証されなければなりません。
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を持っていたし、それはだたであろうと同じ決断をする際、証明書利用者は、承認を拒否、または完全にEECを含む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.
プロキシ証明書は、独自のアイデンティティを持っているので、それはまた、そのプロキシポリシーを経由して発行者から相続以外の手段によってそれに付与された権利を持っているかもしれないことに注意してください。 PCのベアラに付与された権利は、PCのアイデンティティと継承された権利を付与された権利の労働組合です。継承された権利は、アイデンティティがPC内のプロキシポリシーと交差PIに付与された権利の交差点で構成されています。
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:
例えば、スティーブは、ファイルサーバー上のファイルAとBの読み取りと書き込みを許可されていること、そして彼は唯一のファイルAとCを読み書きするために使用することができることをポリシーが含まれてPCを作成するために、彼のEECを使用していることを想像しますそして、信頼できる属性認証局は、PCにD.これは、PCのIDに付与された権利の組合に等しいPCの権利になるだろう、ファイルを読み取る権限を付与する属性証明書を付与するの交差点で（右はファイルDを読み取るために）スティーブ、PI、PCでのポリシーに（ファイル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を読み取るために：スティーブはこの権利を持っており、彼は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を読み取る権限：スティーブはこの権利を持っているが、それは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）中のすべてのx {1、...、N-1}、証明書xの対象は、プロキシ証明書のx + 1の発行者であり、証明書のx + 1のサブジェクト識別名に法的サブジェクト識別名であります証明書xによって発行されています。
(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は、その情報をプロキシ証明書パス検証プロセスへの入力として与えられたエンドエンティティ証明書が発行した有効なプロキシ証明書です。
(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
内のすべてのxに対して（D）{1、...、n}は、証明書は問題の時に有効でした。そして
(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.
pCPathLenConstraintフィールドのパス内のすべての証明書（e）は、その証明書を次のパス内の証明書の数は、そのフィールドに指定された長さを超えません。
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.
（1）初期化、（2）基本的なプロキシ証明書処理、次のプロキシ証明書（3）の調製、及び（4）：このセクションでは、RFC 3280に公開鍵証明書パス検証の記述を反映するために四つの基本的な手順にアルゴリズムを示します要約。工程（1）及び（4）一度だけ行われます。 （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パス検証によって生成されるエンドエンティティ証明書情報を使用してプロキシ証明書チェーンを処理します。
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パス検証から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パス検証からworking_public_key_parameters出力。
(b) prospective proxy certificate path of length n.
長さnの（b）は、将来のプロキシ証明書パス。
(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-ポリシー言語設定：ポリシー評価コードによって理解プロキシ証明書ポリシー言語のセット。既知のポリシー言語のセットがあるため、パス検証コードは、典型的には、（プロキシ証明書ポリシー言語をチェックするべきではない場合に許容される-PC-ポリシー言語セットは、特別な値Id-PPL-anyLanguageを（付録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）working_public_key_algorithm：プロキシ証明書の署名を検証するために使用されるデジタル署名アルゴリズム。 working_public_key_algorithmは、RFC 3280パス検証から提供される入力情報から初期化されます。
(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パス検証から提供される入力情報から初期化されます。
(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パス検証から提供される入力情報から初期化されます。
(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）working_issuer_name：チェーン内の次のプロキシ証明書で予想される発行者識別名。 working_issuer_nameは、RFC 3280パス検証によって検証エンドエンティティ証明書の識別名に初期化されます。
(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（全てのi [1..nの]にするための）を以下に列挙する。
(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を用いworking_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）pCPathLenConstraintフィールドは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.
許容される-PC-ポリシー言語セットは、ID-PPL-anyLanguageない場合（2）、policyLanguageフィールドのOIDは、許容-PC-ポリシー言語セットに存在しなければなりません。
(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.
iがNに等しくない場合、4.1.4に記載されている準備手順を実行して続行。 iが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）working_issuer_nameに証明書のサブジェクト名を割り当てます。
(c) Assign the certificate subjectPublicKey to working_public_key.
（C）working_public_keyへの証明書のsubjectPublicKeyを割り当てます。
(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）証明書のSubjectPublicKeyInfoでフィールドが非NULLパラメータとアルゴリズムフィールドを含む場合、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.
(e) Assign the certificate subjectPublicKey algorithm to the working_public_key_algorithm variable.
（E）working_public_key_algorithm変数に証明書のsubjectPublicKeyアルゴリズムを割り当てます。
(f) If a key usage extension is present, verify that the digitalSignature bit is set.
鍵用途拡張が存在する場合（F）、デジタル署名ビットが設定されていることを確認。
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）working_issuer_nameに証明書のサブジェクト名を割り当てます。
(b) Assign the certificate subjectPublicKey to working_public_key.
（B）working_public_keyへの証明書のsubjectPublicKeyを割り当てます。
(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）証明書のSubjectPublicKeyInfoでフィールドが非NULLパラメータとアルゴリズムフィールドを含む場合、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.
(d) Assign the certificate subjectPublicKey algorithm to the proxy_issuer_public_key_algorithm variable.
（D）proxy_issuer_public_key_algorithm変数に証明書のsubjectPublicKeyアルゴリズムを割り当てます。
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の値、working_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-独立またはエンドエンティティ証明書は、その証明書の有効鍵使用関数は、その証明書内のキーの使用と拡張鍵使用拡張によって定義されるのプロキシポリシーとプロキシ証明書である場合。発行者の鍵使用機能は、効果的な鍵使用の機能とは関係ありません。
* 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、所有者、そのような「充電同一性」または「監査アイデンティティ」としての役割、クリアランスレベル、または代替身元など、いくつかの属性に付与するために使用することができます。これは問題が属性の特定のセットに同一の結合それぞれが属性証明書（AC）を、署名された信頼属性局（AA）の方法によって達成されます。承認の決定は、署名した属性証明書は、属性にそのアイデンティティの結合を提供するとともに、身元を提供する認証済みエンドエンティティ証明書からの情報を組み合わせることによって作製することができます。
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:
この議論の目的のために、彼らが作り出すことを当局、および属性証明書の使用属性、二つの広いクラスに分けることができます。
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）エンドエンティティAA：エンドエンティティ証明書は、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.
属性権限、サードパーティのAAのこの第二のタイプは、EECまたはPCと同様に動作します。例えば、無制限のプロキシ証明書は、他のさまざまな関係者にEECのアイデンティティを委任するために使用することができます。それらの他の当事者の一方がサービスを認証するためにPCを使用するときに、そのサービスは、PCを経由してEECのアイデンティティを受け取ることになりますし、承認権限を決定するために、属性にその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を持っているでしょう。スティーブの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).
*すべてのプロトコルは、認証コード、およびIDベースの認可サービスは、ACSを理解するように変更する必要があります。 PCソリューションでは、プロトコル（例えば、TLS）はおそらく何も変更を必要としない、認証コードは、最小限の変更（例えば、PCを意識パスの検証を実行するために）必要であり、アイデンティティベースの認証サービスは、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.
* ACSは、分散アプリケーション（つまり、エージェント、シミュレーション仕事、および後処理ジョブファイル転送サービス、ファイルを転送するホスト）に関与する他のアイデンティティのそれぞれに属性をバインドするスティーブのEEC、によって作成する必要があります。これは、スティーブが、他のアイデンティティはスティーブのECCによって署名され、適切なACSを生成するために、この分散アプリケーションに関与している可能性が事前に知っていなければならないことを意味します。一方、PCソリューションは、当事者が、さらに元のEECによって事前知識なしで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.
プロキシ証明書の一つの可能な用途は、特定の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:
（また、公開鍵証明書または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.
「認可情報は、PKCSに認可情報の配置は、2つの理由から、通常望ましくない。PKC拡張に配置され、または別個の属性証明書（AC）内に配置することができる。まず、認可情報は、多くの場合の結合と同じ寿命を有していませんアイデンティティと公開鍵。認証情報が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.
上記で引用第二の望ましくない特性は、真です。サードパーティの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の保持者であることを可能にするの有用性を想像することができます。これは、身元の特定の委任のインスタンスを可能にすると、そのアイデンティティのすべての委任のインスタンスが属性を与えられているのではなく、属性を与えられるべき。
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を継承（および潜在的に彼らが継承するACS）か否かの政策に依存するであろう。
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.
ACはAAで一台のPCにバインドすることができますが、どのようにAAはその後、委任PCに渡すからそのPCを制限することができますか？一つの可能な解決策は、属性認証局が発行した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は、異なるエンティティに、元のPCと同じ名前を持つ別のPCを発行することができるためにAC結合したPCのPIは、効果的に交流を盗むことです。これは、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".
ケルベロスネットワーク認証プロトコル（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プロキシ証明書を囲むアイデアの多くを伝えてきました。例えば、短命PCのローカル作成は、シングルサインオンのKerberosベースのシステムですることができますだけで短命TGTの作成など、X.509のPKIベースのシステムでシングルサインオンを提供するために使用することができます。そしてTGTは、Kerberosベースのシステムでプロキシを可能にするために別のエンティティに（すなわち、委任）に転送することができるので、PCはX.509 PKIベースのシステムにおけるプロキシを可能にするために委任することができることができるように。
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.
TGTを保護するためのKerberosの実装で使用される方法はまた、PCの秘密鍵を保護するために使用することができます。例えば、ケルベロスのいくつかのUnixの実装は妥協からユーザーのTGTを保護するために、標準のUnixファイルシステムのセキュリティを使用します。同様に、プロキシ証明書のの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.
スティーブは、2つのFTPサーバー間で、サードパーティ製のFTP転送を実行することを希望します。スティーブは、両方のサーバに認証し、両方のホストに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.
スティーブは、プロセスに彼に代わってH2をホストするためにホストH1からのファイルの転送を実行する権利を委任することを希望します。スティーブはプロセスにPCを委譲うと、彼は2つの権利に委任PCを制限するために、プロキシポリシーを使用する - ホストH1、ホストH2上のファイルF2を書き込むための右側のファイルF1を読み取る権限。
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.
プロセスは、その後、サーバH1とH2に認証するために、この制限されたPCを使用しています。このプロセスはまた、両方のサーバーに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.
プロセスがH2にH1上およびF2へのファイルF1を転送するためのコマンドを発行したときに今、これら2台のサーバが、彼らは任意のローカルポリシーに加えて、（プロセスは、彼らとの認証に使用されるPC上の制約に基づいて承認チェックを実行します持ってる）。すなわち、H1は、PCがユーザーにF1とH2は、PCがユーザーにF2を書く権利を与えることを確認読み取る権限を与えることを確認します。データチャネルを設定する際のサーバーが再び認証の試合から、前のセクションの例のように、スティーブが提供する名前を結果の名前を確認します。
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.
これらの制限により提供される追加のセキュリティはスティーブによってプロセスに委任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アドレスは通常、偽装が容易であり、いくつかのケースでは、取引の両当事者は、アクセプターがNATを使用するホスト上にある場合、アクセプターとPAが一致しないことがあり、例えば（使用されているIPアドレスに一致しないことアクセプターの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.
もう一つの提案は、関係するすべてのエンドエンティティ（アクセプター（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は、シングルサインオンの目的で使用することができるようにするために、専用のファイルシステムのセキュリティを使用して保護されています。これは妥協する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の非常に貴重な、と置き換えることは難しい、公開鍵を保護する際に非常に有用です。作成し、ユーザー認証のためのPCの使用はEECの露出を制限するので、他の言葉では、プロキシ証明書を使用するには、シングルサインオン、実際にエンドエンティティ証明書のセキュリティを高めることができX.509 PKI環境での機能を提供します最初のレベルの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延長のpCPathLenConstraintフィールドには、PCのその後の委任を制限するためにEECで使用することができます。サービスは、有効なPCがそれに委任することができる場合にのみ、要求を認可することもできます。そのようなサービスなどの例は、有効なPCがそれに委任することができない場合、ジョブ開始要求を拒否することもできますジョブスターター、です。 pCPathLenConstraintを制限することにより、EECは、一つの仕事の危険にさらさ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がキーと拡張キーの使用上の拡張でビットをオフにすることによってのために使用することができるものを制限することができます。キーの使用または拡張キー使用法が取り除かれた後、パス検証アルゴリズムは、それが、その後の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は、それは彼らが誤用されていたことを感じた場合には、発行されたPCを取り消すの責任を取るためにCRL配布ポイント拡張および/またはOCSPを使用することができます。
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の政策に影響を与えることができ、証明書チェーンのいずれかの変化を意味することに注意する必要があります。パソコンの独特な主題名を強制する代わりに機構がないので、発行者が同一の名前とキーが、異なる権限を持つ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節で述べたように、プロキシ証明書のための動機の一つは、当事者間の動的な委任を可能にすることです。この代表団は、潜在的に委任を受けた当事者、潜在的に計算コストの高い操作で新しい鍵ペアの生成により、必要となります。ケアは、鍵の生成を行うリソースを大量に消費するためにそれらを引き起こすことによって、サービス拒否攻撃を実行することから別のエンティティを防ぐために、このような当事者によって取られるべきです。
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は、ポリシー言語のレジストリを確立しています。 [I8]で説明したようにIETFスペースの下の登録は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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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]バトラー、R.、Engert、D.、フォスター、I.、Kesselman、C.、およびS. Tuecke、 "全国規模認証基盤"、IEEEコンピュータ、巻。 33頁60-66、2000。
[i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[I2]ダークス、T.とC.アレン、 "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]ファレル、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]フォスター、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の]フォスター、I.、Kesselman、C.、およびS. Tuecke、 "グリッドの解剖学：スケーラブルな仮想組織を有効にする"、スーパーコンピュータのアプリケーション、2001年の国際ジャーナル。
[i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
【I6]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（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の]ノイマン、B.クリフォード、「認可をプロキシベースの分散システムの会計処理」、分散コンピューティングシステム、ページ283-291、1993年5月の第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.
私たちはデビッド・チャドウィック、イアン・フォスター、Jarek Gawor、カール・ケッセルマン、サムMEDER、ジムSchaad、フランク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.
我々は（我々が見逃している誰にも謝罪して、アルファベット順に）特に、この論文で取り上げるトピックについての議論のための多数の同僚に感謝しています：カーライル・アダムス、ジョー・ベスター、ランディ・バトラー、キース・ジャクソン、スティーブ・ハンナ、ラスHousley 、スティーブン・ケント、ビル・ジョンストン、マーティ・ハンフリー、サム・ラング、エレン・マクダーモット、クリフォード・ニューマン、ジーン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）、およびInternet Engineering Task Force（IETF）の公開鍵基盤（X.509）ワーキンググループ（PKIX）のメンバーに感謝していますこの文書に。
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-工学-38およびDE-AC03-76SF0098。契約N66001-96-C-8523の下で国防高等研究計画庁によります。国立科学財団によって;そしてNASAインフォメーションパワーグリッドプロジェクトによって。
Appendix A. 1988 ASN.1 Module
付録A. 1988 ASN.1モジュール
PKIXproxy88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) proxy-cert-extns(25) }
PKIXproxy88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）プロキシCERT-extns（25）}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
- すべてのエクスポート -
-- IMPORTS NONE --
- 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
スティーブンTueckeは、システム研究所数学とコンピュータサイエンス部門アルゴンヌ国立研究所アルゴンヌ、IL 60439を分散しました
Phone: 630-252-8711 EMail: tuecke@mcs.anl.gov
電話：630-252-8711 Eメール：tuecke@mcs.anl.gov
Von Welch National Center for Supercomputing Applications University of Illinois
イリノイ州のスーパーコンピュータ応用のための大学・フォン・ウェルチナショナルセンター
EMail: vwelch@ncsa.uiuc.edu
メールアドレス：vwelch@ncsa.uiuc.edu
Doug Engert Argonne National Laboratory
ダグEngertアルゴンヌ国立研究所
EMail: deengert@anl.gov
メールアドレス：deengert@anl.gov
Laura Pearlman University of Southern California, Information Sciences Institute
南カリフォルニア、情報科学研究所のローラ・パールマン大学
EMail: laura@isi.edu
メールアドレス：laura@isi.edu
Mary Thompson Lawrence Berkeley National Laboratory
メアリー・トンプソンローレンス・バークレー国立研究所
EMail: mrthompson@lbl.gov
メールアドレス：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。