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
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
Internet X.509公钥基础设施（PKI）代理证书配置文件
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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）证书，形成代理证书的证书配置文件，用于Internet。术语代理证书用于描述从普通X.509公钥终端实体证书或其他代理证书派生并由其签名的证书，以在基于PKI的身份验证系统中提供受限代理和委托。
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5
2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7
2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8
2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9
2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10
3. Certificate and Certificate Extensions Profile . . . . . . . . 12
3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13
3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13
3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19
4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23
5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Relationship to Attribute Certificates . . . . . . . . . 24
5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28
5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30
6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31
6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31
6.4. Protecting Against Denial of Service with Key Generation 32
6.5. Use of Proxy Certificates in a Central Repository. . . . 32
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37
Use of a proxy credential [i7] is a common technique used in security systems to allow entity A to grant to another entity B the right for B to be authorized with others as if it were A. In other words, entity B is acting as a proxy on behalf of entity A. This document forms a certificate profile for Proxy Certificates, based on the RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" [n2].
代理凭证的使用[i7]是安全系统中使用的一种常见技术，允许实体a向另一个实体B授予B与其他实体一起被授权的权利，就像它是a一样。换句话说，实体B代表实体a作为代理。本文档基于RFC 3280形成代理证书的证书配置文件，“Internet X.509公钥基础设施证书和CRL配置文件”[n2]。
In addition to simple, unrestricted proxying, this profile defines:
除了简单、无限制的代理之外，此配置文件还定义：
* A framework for carrying policies in Proxy Certificates that allows proxying to be limited (perhaps completely disallowed) through either restrictions or enumeration of rights.
* 在代理证书中承载策略的框架，允许通过限制或权限枚举限制代理（可能完全不允许）。
* Proxy Certificates with unique names, derived from the name of the end entity certificate name. This allows the Proxy Certificates to be used in conjunction with attribute assertion approaches such as Attribute Certificates [i3] and have their own rights independent of their issuer.
* 具有唯一名称的代理证书，从最终实体证书名称派生。这允许代理证书与属性断言方法（如属性证书[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节定义了代理证书中信息内容的要求。此配置文件处理基本证书中的两个字段以及五个证书扩展。证书字段是主题字段和颁发者字段。证书扩展包括使用者替代名称、颁发者替代名称、密钥使用、基本约束和扩展密钥使用。介绍了一种新的证书扩展，即代理证书信息。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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公钥基础设施（PKI）身份验证的系统中使用受限代理和委托的社区开发X.509代理证书配置文件，并促进其在Internet应用程序中的使用。
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定义的“最终实体证书”。也就是说，它是由CA颁发给终端实体（如用户或服务）的X.509公钥证书。
* PKC: An end entity "Public Key Certificate". This is synonymous with an EEC.
* PKC：一个终端实体“公钥证书”。这是EEC的同义词。
* PC: A "Proxy Certificate", the profile of which is defined by this document.
* PC：本文件定义的“代理证书”。
* PI: A "Proxy Issuer" is an entity with an End Entity Certificate or Proxy Certificate that issues a Proxy Certificate. The Proxy Certificate is signed using the private key associated with the public key in the Proxy Issuer's certificate.
* PI：“代理颁发者”是指具有最终实体证书或代理证书的实体，该证书颁发代理证书。代理证书使用与代理颁发者证书中的公钥关联的私钥进行签名。
* AC: An "Attribute Certificate", as defined by "An Internet Attribute Certificate Profile for Authorization" [i3].
* AC：由“授权的互联网属性证书配置文件”定义的“属性证书”[i3]。
* AA: An "Attribute Authority", as defined in [i3].
* AA：如[i3]所定义的“属性权限”。
Computational and Data "Grids" have emerged as a common approach to constructing dynamic, inter-domain, distributed computing environments. As explained in [i5], large research and development efforts starting around 1995 have focused on the question of what protocols, services, and APIs are required for effective, coordinated use of resources in these Grid environments.
计算和数据“网格”已成为构建动态、跨域、分布式计算环境的常用方法。正如[i5]中所解释的，1995年左右开始的大规模研究和开发工作集中于在这些网格环境中高效、协调地使用资源需要哪些协议、服务和API的问题。
In 1997, the Globus Project (www.globus.org) introduced the Grid Security Infrastructure (GSI) [i4]. This library provides for public key based authentication and message protection, based on standard X.509 certificates and public key infrastructure, the SSL/TLS protocol [i2], and delegation using proxy certificates similar to those profiled in this document. GSI has been used, in turn, to build numerous middleware libraries and applications, which have been deployed in large-scale production and experimental Grids [i1]. GSI has emerged as the dominant security solution used by Grid efforts worldwide.
1997年，Globus项目（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
Steve是一名工程师，他希望使用可靠的文件传输服务来管理大量大型文件在其公司基于Intranet的网格上的不同主机之间的移动。他想从他的笔记本电脑上向服务提交一系列传输请求，并在进行其他工作时传输文件
things, including being offline. The transfer service may queue the requests for some time (e.g., until after hours or a period of low resource usage) before initiating the transfers. The transfer service will then, for each file, connect to each of the source and destination hosts, and instruct them to initiate a data connection directly from the source to the destination in order to transfer the file. Steve will leave an agent running on his laptop that will periodically check on progress of the transfer by contacting the transfer service. Of course, he wants all of this to happen securely on his company's resources, which requires that he initiate all of this using his PKI smartcard.
事情，包括离线。传输服务可以在启动传输之前将请求排队一段时间（例如，直到数小时后或资源使用率较低的一段时间）。然后，传输服务将为每个文件连接到每个源主机和目标主机，并指示它们直接启动从源到目标的数据连接，以便传输文件。Steve将让一名代理在他的笔记本电脑上运行，该代理将通过联系转账服务定期检查转账进度。当然，他希望所有这些都能在公司的资源上安全地实现，这要求他使用他的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.
* Steve需要能够与可靠的文件传输服务相互验证以提交传输请求。
* Since the storage hosts know nothing about the file transfer service, the file transfer service needs to be delegated the rights to mutually authenticate with the various storage hosts involved directly in the file transfer, in order to initiate the file transfer.
* 由于存储主机对文件传输服务一无所知，因此需要向文件传输服务授予与直接参与文件传输的各种存储主机相互验证的权限，以便启动文件传输。
* The source and destination hosts of a particular transfer must be able to mutual authenticate with each other, to ensure the file is being transferred to and from the proper parties.
* 特定传输的源主机和目标主机必须能够相互进行身份验证，以确保文件在适当的各方之间传输。
* The agent running on Steve's laptop must mutually authenticate with the file transfer service in order to check the result of the transfers.
* 运行在Steve笔记本电脑上的代理必须与文件传输服务相互验证，以检查传输结果。
Proxying is a viable approach to solving two (related) problems in this scenario:
代理是解决此场景中两个（相关）问题的可行方法：
* Single sign-on: Steve wants to enter his smartcard password (or pin) once, and then run a program that will submit all the file transfer requests to the transfer service, and then periodically check on the status of the transfer. This program needs to be given the rights to be able to perform all of these operations securely, without requiring repeated access to the smartcard or Steve's password.
* 单点登录：Steve希望输入他的智能卡密码（或pin）一次，然后运行一个程序，将所有文件传输请求提交给传输服务，然后定期检查传输状态。该程序需要获得安全执行所有这些操作的权限，而无需重复访问智能卡或Steve的密码。
* Delegation: Various remote processes in this scenario need to perform secure operations on Steve's behalf, and therefore must be delegated the necessary rights. For example, the file transfer
* 委派：此场景中的各种远程进程需要代表Steve执行安全操作，因此必须委派必要的权限。例如，文件传输
service needs to be able to authenticate on Steve's behalf with the source and destination hosts, and must in turn delegate rights to those hosts so that they can authenticate with each other.
服务需要能够代表Steve对源主机和目标主机进行身份验证，并且必须反过来将权限委托给这些主机，以便它们能够相互进行身份验证。
Proxying can be used to secure all of these interactions:
代理可用于保护所有这些交互：
* Proxying allows for the private key stored on the smartcard to be accessed just once, in order to create the necessary proxy credential, which allows the client/agent program to be authorized as Steve when submitting the requests to the transfer service. Access to the smartcard and Steve's password is not required after the initial creation of the proxy credential.
* 代理允许仅访问一次存储在智能卡上的私钥，以创建必要的代理凭据，从而允许客户端/代理程序在向传输服务提交请求时被授权为Steve。初始创建代理凭据后，不需要访问智能卡和Steve的密码。
* The client program on the laptop can delegate to the file transfer service the right to act on Steve's behalf. This, in turn, allows the service to authenticate to the storage hosts and inherit Steve's privileges in order to start the file transfers.
* 笔记本电脑上的客户端程序可以将代表Steve行事的权利委托给文件传输服务。这反过来又允许服务向存储主机进行身份验证，并继承Steve的特权以启动文件传输。
* When the transfer service authenticates to hosts to start the file transfer, the service can delegate to the hosts the right to act on Steve's behalf so that each pair of hosts involved in a file transfer can mutually authenticate to ensure the file is securely transferred.
* 当传输服务向主机进行身份验证以启动文件传输时，该服务可以将代表Steve行事的权利委托给主机，以便文件传输中涉及的每对主机可以相互进行身份验证，以确保文件安全传输。
* 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?
出现的一个问题是，如果一台被授予继承Steve特权的机器受到损害，会发生什么？例如，在上述场景中，如果运行文件传输服务的计算机受到攻击，攻击者可以访问Steve委托给该服务的凭据，该怎么办？攻击者现在能做史蒂夫允许做的一切吗？
A solution to this problem is to allow for restrictions to be placed on the proxy by means of policies on the proxy certificates. For example, the machine running the reliable file transfer service in
此问题的解决方案是允许通过代理证书上的策略对代理施加限制。例如，在中运行可靠文件传输服务的计算机
the above example might only be given Steve's right for the purpose of reading the source files and writing the destination files. Therefore, if that file transfer service is compromised, the attacker cannot modify source files, cannot create or modify other files to which Steve has access, cannot start jobs on behalf of Steve, etc. All that an attacker would be able to do is read the specific files to which the file transfer service has been delegated read access, and write bogus files in place of those that the file transfer service has been delegated write access. Further, by limiting the lifetime of the credential that is delegated to the file transfer service, the effects of a compromise can be further mitigated.
上面的示例可能只是为了读取源文件和写入目标文件而授予Steve的权利。因此，如果该文件传输服务遭到破坏，攻击者将无法修改源文件，无法创建或修改Steve有权访问的其他文件，无法代表Steve启动作业等。攻击者所能做的就是读取文件传输服务已被授予读取访问权的特定文件，并写入伪造文件，以代替文件传输服务已被授予写入权限的文件。此外，通过限制委托给文件传输服务的凭证的生存期，可以进一步减轻妥协的影响。
Other potential uses for restricted proxy credentials are discussed in [i7].
[i7]中讨论了受限代理凭据的其他潜在用途。
The dynamic creation of entities (e.g., processes and services) is an essential part of Grid computing. These entities will require rights in order to securely perform their function. While it is possible to obtain rights solely through proxying as described in previous sections, this has limitations. For example what if an entity should have rights that are granted not just from the proxy issuer but from a third party as well? While it is possible in this case for the entity to obtain and hold two proxy certifications, in practice it is simpler for subsequent credentials to take the form of attribute certificates.
实体（如流程和服务）的动态创建是网格计算的重要组成部分。这些实体需要权限才能安全地执行其功能。虽然如前几节所述，可以仅通过代理获得权限，但这有局限性。例如，如果一个实体拥有的权利不仅来自代理发行人，还来自第三方，该怎么办？虽然在这种情况下，实体可以获得并持有两个代理证书，但实际上，后续凭证采用属性证书的形式更简单。
It is also desirable for these entities to have a unique identity so that they can be explicitly discussed in policy statements. For example, a user initiating a third-party FTP transfer could grant each FTP server a PC with a unique identity and inform each server of the identity of the other, then when the two servers connected they could authenticate themselves and know they are connected to the proper party.
还希望这些实体具有唯一的标识，以便可以在策略声明中明确讨论它们。例如，发起第三方FTP传输的用户可以向每台FTP服务器授予一台具有唯一标识的PC，并将另一台服务器的标识告知每台服务器，然后当两台服务器连接时，他们可以对自己进行身份验证，并知道他们已连接到正确的一方。
In order for a party to have rights of it's own it requires a unique identity. Possible options for obtaining an unique identity are:
为了让一方拥有自己的权利，它需要一个独特的身份。获取唯一标识的可能选项有：
1) Obtain an identity from a traditional Certification Authority (CA).
1) 从传统证书颁发机构（CA）获取身份。
2) Obtain a new identity independently - for example by using the generated public key and a self-signed certificate.
2) 独立获取新身份-例如，使用生成的公钥和自签名证书。
3) Derive the new identity from an existing identity.
3) 从现有标识派生新标识。
In this document we describe an approach to option #3, because:
在本文件中，我们描述了选项3的方法，因为：
* It is reasonably light-weight, as it can be done without interacting with a third party. This is important when creating identities dynamically.
* 它相当轻，因为它可以在不与第三方交互的情况下完成。这在动态创建标识时非常重要。
* As described in the previous section, a common use for PCs is for restricted proxying, so deriving their identity from the identity of the EEC makes this straightforward. Nonetheless there are circumstances where the creator does not wish to delegate all or any of its rights to a new entity. Since the name is unique, this is easily accomplished by #3 as well, by allowing the application of a policy to limit proxying.
* 如前一节所述，PCs的一个常见用途是限制代理，因此从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“代理证书”或“PC”定义为在（扩展的）X.509基于PKI的认证系统中提供受限代理的一种方式。
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用于认证时，年可能继承签署PC的EEC的权利，但受EEC对该PC的限制。
5) Although its identity is derived from the EEC's identity, it is also unique. This allows this identity to be used for authorization as an independent identity from the identity of the issuing EEC, for example in conjunction with attribute assertions as defined in [i3].
5) 虽然它的身份来源于欧洲经济共同体的身份，但它也是独一无二的。这允许该身份作为独立于发行EEC身份的身份用于授权，例如与[i3]中定义的属性断言结合使用。
6) It contains a new X.509 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509 fields and extensions, are used to enable proper path validation and use of the PC.
6) 它包含一个新的X.509扩展，用于将其标识为PC，并对PC的使用制定策略。此新扩展与其他X.509字段和扩展一起用于启用PC的正确路径验证和使用。
The process of creating a PC is as follows:
创建PC的过程如下所示：
1) A new public and private key pair is generated.
1) 生成新的公钥和私钥对。
2) That key pair is used to create a request for a Proxy Certificate that conforms to the profile described in this document.
2) 该密钥对用于创建符合本文档中描述的配置文件的代理证书请求。
3) A Proxy Certificate, signed by the private key of the EEC or by another PC, is created in response to the request. During this process, the PC request is verified to ensure that the requested PC is valid (e.g., it is not an EEC, the PC fields are appropriately set, etc).
3) 代理证书由EEC的私钥或另一台PC签名，以响应请求。在此过程中，验证PC请求，以确保请求的PC有效（例如，它不是EEC，PC字段设置正确等）。
When a PC is created as part of a delegation from entity A to entity B, this process is modified by performing steps #1 and #2 within entity B, then passing the PC request from entity B to entity A over an authenticated, integrity checked channel, then entity A performs step #3 and passes the PC back to entity B.
当PC作为从实体a到实体B的委托的一部分创建时，此过程通过在实体B内执行步骤1和步骤2进行修改，然后通过经过身份验证、完整性检查的通道将PC请求从实体B传递给实体a，然后实体a执行步骤3并将PC传递回实体B。
Path validation of a PC is very similar to normal path validation, with a few additional checks to ensure, for example, proper PC signing constraints.
PC的路径验证与普通路径验证非常相似，只需进行一些额外的检查，以确保（例如）正确的PC签名约束。
Using Proxy Certificates to perform delegation has several features that make it attractive:
使用代理证书执行委派具有以下几个特点：
* Ease of integration
* 易于集成
o Because a PC requires only a minimal change to path validation, it is very easy to incorporate support for Proxy Certificates into existing X.509 based software. For example, SSL/TLS requires no protocol changes to support authentication using a PC. Further, an SSL/TLS implementation requires only minor changes to support PC path validation, and to retrieve the authenticated subject of the signing EEC instead of the subject of the PC for authorization purposes.
o 因为PC只需要对路径验证进行最小的更改，所以很容易将代理证书支持合并到现有的基于X.509的软件中。例如，SSL/TLS不需要协议更改来支持使用PC的身份验证。此外，SSL/TLS实现只需要少量更改来支持PC路径验证，并检索签名EEC的已验证主题，而不是PC的主题以进行授权。
o Many existing authorization systems use the X.509 subject name as the basis for access control. Proxy Certificates can be used with such authorization systems without modification, since such a PC inherits its name and rights from the EEC that signed it and the EEC name can be used in place of the PC name for authorization decisions.
o 许多现有授权系统使用X.509使用者名称作为访问控制的基础。代理证书可与此类授权系统一起使用，无需修改，因为此类PC从签署它的EEC继承其名称和权利，并且EEC名称可代替PC名称用于授权决策。
* Ease of use
* 易用性
o Using PC for single sign-on helps make X.509 PKI authentication easier to use, by allowing users to "login" once and then perform various operations securely.
o 通过允许用户“登录”一次，然后安全地执行各种操作，使用PC进行单点登录有助于使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上轻松启用的一个选项是在集中管理的存储库中管理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可以将PC委派给实体B，实体B从未看到实体A的私钥，实体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.
o 创建PC时，PI可以限制PC的有效期、该PC可以创建的PC路径的深度以及PC及其子代的关键用法。此外，PC可以执行细粒度策略，以进一步限制可使用PC执行的操作。这些限制允许PI限制PC持有者可能意外或恶意造成的损坏。
o A compromised PC private key does NOT compromise the EEC private key. This makes a short term, or an otherwise restricted PC attractive for day-to-day use, since a compromised PC does not require the user to go through the usually cumbersome and time consuming process of having the EEC with a new private key reissued by the CA.
o 泄露的PC私钥不会泄露EEC私钥。这使得短期或其他受限PC对日常使用具有吸引力，因为受损PC不需要用户通过通常繁琐且耗时的过程让EEC使用CA重新颁发的新私钥。
See Section 5 below for more discussion on how Proxy Certificates relate to Attribute Certificates.
有关代理证书如何与属性证书相关的更多讨论，请参见下面的第5节。
This section defines the usage of X.509 certificate fields and extensions in Proxy Certificates, and defines one new extension for Proxy Certificate Information.
本节定义了X.509证书字段和扩展在代理证书中的用法，并为代理证书信息定义了一个新的扩展。
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.
代理证书中不得存在ISSUERATNAME扩展名。
The serial number of a Proxy Certificate (PC) SHOULD be unique amongst all Proxy Certificates issued by a particular Proxy Issuer. However, a Proxy Issuer MAY use an approach to assigning serial numbers that merely ensures a high probability of uniqueness.
代理证书（PC）的序列号在由特定代理颁发者颁发的所有代理证书中应是唯一的。然而，代理发行人可以使用一种分配序列号的方法，该方法仅确保高概率的唯一性。
For example, a Proxy Issuer MAY use a sequentially assigned integer or a UUID to assign a unique serial number to a PC it issues. Or a Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a serial number with a high probability of uniqueness.
例如，代理发行人可以使用顺序分配的整数或UUID为其发行的PC分配唯一的序列号。或者，代理发行人可以使用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.
代理证书的subject字段必须是issuer字段（即代理颁发者的subject），并附加一个通用名称组件。
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.
如果代理发行人向同一持有人发行两个代理证书，则代理发行人可选择对这两个持有人使用相同的通用名称。这方面的示例包括用于不同用途的代理证书（例如，签名与加密）或重新颁发过期的代理证书。
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的名称（它将是主体名称的第一部分，附加一个或多个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-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 OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
ProxyCertInfo ::= SEQUENCE {
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyCertInfo ::= SEQUENCE {
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
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扩展由一个必填字段和两个可选字段组成，在以下小节中详细介绍。
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字段（如果存在）指定可由该代理证书签名的代理证书路径的最大深度。pCPathLenConstraint为0表示此证书不得用于签署代理证书。如果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中，policy字段是policy的表达式，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中定义的两个特别重要的值，接受代理证书的各方必须理解这两个值：
* 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 independent表示这是一个独立代理，它不从发布PI继承任何权限。依赖方必须将此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证书路径中的所有策略兼容。换言之，依赖方必须验证以下三个条件是否全部满足：
1) The relying party MUST know how to interpret the proxy policy and the request is allowed under that policy.
1) 依赖方必须知道如何解释代理策略，并且该策略允许该请求。
2) If the Proxy Issuer is an EEC then the relying party's local policies MUST authorize the request for the entity named in the EEC.
2) 如果代理发行人是EEC，则依赖方的本地政策必须授权EEC中指定实体的请求。
3) If the Proxy Issuer is another PC, then one of the following MUST be true:
3) 如果代理发行人是另一台PC，则必须满足以下条件之一：
a. The relying party's local policies authorize the Proxy Issuer to perform the request.
a. 依赖方的本地政策授权代理发行人执行请求。
b. The Proxy Issuer inherits the right to perform the request from its issuer by means of its proxy policy. This must be verified by verifying these three conditions on the Proxy Issuer in a recursive manner.
b. 代理发行人通过其代理策略从其发行人处继承执行请求的权利。必须通过递归方式验证代理颁发者的这三个条件来验证这一点。
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.
继承的权利。继承的权利包括授予PI身份的权利与PC中的代理策略的交集。
For example, imagine that Steve is authorized to read and write files A and B on a file server, and that he uses his EEC to create a PC that includes the policy that it can be used only to read or write files A and C. Then a trusted attribute authority grants an Attribute Certificate granting the PC the right to read file D. This would make the rights of the PC equal to the union of the rights granted to the PC identity (right to read file D) with the intersection of the rights granted to Steve, the PI, (right to read files A and B) with the policy in the PC (can only read files A and C). This would mean the PC would have the following rights:
例如，假设Steve被授权在文件服务器上读写文件A和B，他使用他的EEC创建了一台PC，其中包括只能用于读取或写入文件a和C的策略。然后，受信任的属性机构授予属性证书，授予PC读取文件D的权利。这将使PC的权利等于授予PC身份的权利的联合（读取文件D的权利）与授予PI Steve的权利（读取文件A和B的权利）的交叉点，以及PC中的策略（只能读取文件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的权利：史蒂夫有这项权利，他发行了个人电脑，他的政策授予个人电脑这项权利。
* 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：虽然史蒂夫有这项权利，但他的个人电脑政策不包括这项权利。
* 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.
有效路径以终端实体证书（EEC）开始，该证书已通过RFC 3280[n2]中的公钥证书验证过程进行验证。该算法需要EEC的公钥和EEC的主题可分辨名称。
To meet the goal of verifying the proxy certificate, the proxy certificate path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
为了达到验证代理证书的目的，代理证书路径验证过程验证预期的证书路径（n个证书序列）是否满足以下条件：
(a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of proxy certificate x+1 and the subject distinguished name of certificate x+1 is a legal subject distinguished name to have been issued by certificate x;
(a) 对于{1，…，n-1}中的所有x，证书x的主体是代理证书x+1的颁发者，证书x+1的主体可分辨名称是由证书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
(d) 对于{1，…，n}中的所有x，证书在所述时间有效；和
(e) for all certificates in the path with a pCPathLenConstraint field, the number of certificates in the path following that certificate does not exceed the length specified in that field.
(e) 对于具有pCPathLenConstraint字段的路径中的所有证书，该证书后面路径中的证书数不超过该字段中指定的长度。
At this point there is no mechanism defined for revoking proxy certificates.
目前还没有定义用于撤销代理证书的机制。
This section presents the algorithm in four basic steps to mirror the description of public key certificate path validation in RFC 3280: (1) initialization, (2) basic proxy certificate processing, (3) preparation for the next proxy certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all proxy certificates in the path. Step (3) is performed for all proxy certificates in the path except the final proxy certificate.
本节以四个基本步骤介绍算法，以反映RFC 3280中公钥证书路径验证的描述：（1）初始化，（2）基本代理证书处理，（3）准备下一个代理证书，以及（4）总结。步骤（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中所述的证书路径验证。然后，该算法使用RFC3280路径验证生成的最终实体证书信息处理代理证书链。
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路径验证的工作公钥输出，
(3) the working_public_key_algorithm output from RFC 3280,
(3) RFC 3280输出的工作公钥算法，
(4) and the working_public_key_parameters output from RFC 3280 path validation.
(4) 以及RFC3280路径验证输出的工作密钥参数。
(b) prospective proxy certificate path of length n.
(b) 长度为n的预期代理证书路径。
(c) acceptable-pc-policy-language-set: A set of proxy certificate policy languages understood by the policy evaluation code. The acceptable-pc-policy-language-set MAY contain the special value id-ppl-anyLanguage (as defined in Appendix A) if the path validation code should not check the proxy certificate policy languages (typically because the set of known policy languages is not known yet and will be checked later in the authorization process).
(c) 可接受的pc策略语言集：策略评估代码可以理解的一组代理证书策略语言。如果路径验证代码不应检查代理证书策略语言，则可接受的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) 工作公钥算法：用于验证代理证书签名的数字签名算法。根据RFC3280路径验证提供的输入信息初始化工作的\u public\u key\u算法。
(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) 工作公钥：用于验证代理证书签名的公钥。根据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) 工作\u公钥\u参数：与当前公钥关联的参数，验证签名可能需要这些参数（取决于算法）。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) 工作颁发者名称：链中下一个代理证书中预期的颁发者可分辨名称。工作\u颁发者\u名称初始化为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（对于[1..n]中的所有i）要执行的基本路径处理操作。
(a) Verify the basic certificate information. The certificate MUST satisfy each of the following:
(a) 验证基本证书信息。证书必须满足以下各项要求：
(1) The certificate was signed with the working_public_key_algorithm using the working_public_key and the working_public_key_parameters.
(1) 使用工作公钥和工作公钥参数，使用工作公钥算法对证书进行签名。
(2) The certificate validity period includes the current time.
(2) 证书有效期包括当前时间。
(3) The certificate issuer name is the working_issuer_name.
(3) 证书颁发者名称是工作颁发者名称。
(4) The certificate subject name is the working_issuer_name with a CN component appended.
(4) 证书使用者名称是附加了CN组件的工作颁发者名称。
(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) 如果ProxyCertInfo字段中存在pCPathLenConstraint字段，并且该字段包含的值小于最大路径长度，请将最大路径长度设置为其值。
(2) If acceptable-pc-policy-language-set is not id-ppl-anyLanguage, the OID in the policyLanguage field MUST be present in acceptable-pc-policy-language-set.
(2) 如果可接受的pc策略语言集不是id ppl anyLanguage，则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) 包含证书使用者名称、策略策略、密钥使用扩展（如果存在）和扩展密钥使用扩展（如果存在）的元组必须附加到代理策略列表。
(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) 验证“最大路径长度”是否大于零，并减小“最大路径长度”。
(b) Assign the certificate subject name to working_issuer_name.
(b) 将证书使用者名称分配给工作颁发者名称。
(c) Assign the certificate subjectPublicKey to working_public_key.
(c) 将证书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.
如果证书的subjectPublicKeyInfo字段包含带有空参数的算法字段或省略了参数，请将证书subjectPublicKey算法与工作的公钥算法进行比较。如果证书主题公钥算法和工作公钥算法不同，请将工作公钥参数设置为null。
(e) Assign the certificate subjectPublicKey algorithm to the working_public_key_algorithm variable.
(e) 将证书subjectPublicKey algorithm分配给working_public_key_algorithm变量。
(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) 将证书使用者名称分配给工作颁发者名称。
(b) Assign the certificate subjectPublicKey to working_public_key.
(b) 将证书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字段包含具有非空参数的算法字段，请将参数分配给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.
如果证书的subjectPublicKeyInfo字段包含带有空参数的算法字段或省略了参数，请将证书subjectPublicKey算法与代理\u颁发者\u公钥\u算法进行比较。如果证书主题公钥算法和代理颁发者公钥算法不同，请将代理颁发者公钥参数设置为null。
(d) Assign the certificate subjectPublicKey algorithm to the proxy_issuer_public_key_algorithm variable.
(d) 将证书主题公钥算法分配给代理颁发者公钥算法变量。
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.
如果路径处理成功，则过程终止，返回一个成功指示以及工作公钥、工作公钥算法、工作公钥参数和代理策略列表的最终值。
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.
每个代理证书都包含一个ProxyCertInfo扩展，该扩展始终包含一个策略语言OID，还可能包含一个策略八位字节字符串。这些策略用于表明代理证书链中的每个颁发者（从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 independent的代理证书或最终实体证书，则该证书的有效密钥使用功能由该证书中的密钥使用和扩展密钥使用扩展定义。发卡机构的密钥使用功能与有效的密钥使用功能无关。
* 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 independent之外的策略的代理证书，则代理证书的有效密钥使用和扩展密钥使用功能是代理证书中这些扩展的功能和代理颁发者的有效密钥使用功能的交叉点。
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]可用于向一个身份（持有者）授予某些属性，如角色、许可级别或替代身份，如“收费身份”或“审计身份”。这是通过可信属性机构（AA）实现的，该机构颁发签名属性证书（AC），每个证书将一个身份绑定到一组特定的属性。然后，可以通过组合来自提供身份的经过身份验证的最终实体证书的信息，以及提供该身份到属性的绑定的经过签名的属性证书来做出授权决策。
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.
代理证书和属性证书提供的功能之间显然存在一些重叠。然而，这两种方法的结合为基于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可以提供将客户机标识绑定到特定组的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
第二类属性权限，即第三方AA，同样适用于EEC或PC。例如，可以使用不受限制的代理证书将EEC的身份委托给其他各方。然后，当其中一方使用PC对服务进行身份验证时，该服务将收到EEC的
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.
身份，并可以应用任何将该身份绑定到属性的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用于将Steve的身份委托给需要代表Steve行事的各种其他工作和实体。这允许这些其他实体进行身份验证，就像它们是Steve一样，例如对大容量存储系统进行身份验证。
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.
本例的解决方案也可以使用由Steve的EEC签署的属性证书进行转换，该证书授予本例中的其他实体代表Steve执行各种操作的权利。在本例中，可靠的文件传输服务和文件传输中涉及的所有主机、启动程序、代理、模拟作业和后处理作业都有各自的EEC。因此，Steve的EEC将发布ACs，将其他EEC身份绑定到授予必要权限的属性，例如，允许他们访问海量存储系统。
However, this AC based solution to delegation has some disadvantages as compared to the PC based solution:
但是，与基于PC的解决方案相比，这种基于AC的委派解决方案有一些缺点：
* All protocols, authentication code, and identity based authorization services must be modified to understand ACs. With the PC solution, protocols (e.g., TLS) likely need no modification, authentication code needs minimal modification (e.g., to perform PC aware path validation), and identity based authorization services need minimal modification (e.g., possibly to find the EEC name and to check for any proxy policies).
* 必须修改所有协议、身份验证代码和基于身份的授权服务，以理解ACs。在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需要由Steve的EEC创建，它将属性绑定到分布式应用程序中涉及的每个其他身份（即代理、模拟作业和后处理作业文件传输服务、传输文件的主机）。这意味着Steve必须提前知道该分布式应用程序可能涉及哪些其他身份，以便生成由Steve的ECC签名的适当ACs。另一方面，PC解决方案允许更大的灵活性，因为各方可以进一步委托PC，而无需原始EEC的先验知识。
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.
代理证书的一种可能用途是携带与特定身份相关联的授权信息。
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）的优点已被广泛讨论。例如，“用于授权的Internet属性证书配置文件”[i3]的第1节说明：
"Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.
“授权信息可以放在PKC扩展中，也可以放在单独的属性证书（AC）中。在PKC中放置授权信息通常是不可取的，原因有两个。首先，授权信息通常与身份和公钥的绑定不具有相同的生存期。当将授权信息放置在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.
然而，有一种情况是，上述文本没有考虑。执行委托时，通常是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的唯一主题名或其发行者和序列号组合绑定到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绑定到一台PC，但机管局如何限制该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
在这种情况下，AA需要注意的一个问题是，AA将AC绑定到的PC的PI可能会将另一台与原始PC同名的PC发送到另一台计算机
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.
实体，有效地窃取AC。这意味着AA向PC发行AC不仅需要信任持有PC的实体，还需要信任持有PC发行人的实体。
The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a widely used authentication system based on conventional (shared secret key) cryptography. It provides support for single sign-on via creation of "Ticket Granting Tickets" or "TGT", and support for delegation of rights via "forwardable tickets".
Kerberos网络身份验证协议（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.
kerberos5票证提供了有关X.509代理证书的许多想法。例如，短期PC的本地创建可用于在基于X.509 PKI的系统中提供单点登录，正如短期TGT的创建允许在基于Kerberos的系统中进行单点登录一样。正如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.
Kerberos实现用于保护TGT的方法也可用于保护PC的私钥。例如，Kerberos的某些Unix实现使用标准Unix文件系统安全性来保护用户的TGT不受损害。类似地，Globus Toolkit的代理证书网格安全基础设施实现使用相同的方法保护用户的PC私钥。
This section gives some examples of Proxy Certificate usage and some examples of how the Proxy policy can be used to restrict Proxy Certificates.
本节给出了代理证书使用的一些示例，以及如何使用代理策略限制代理证书的一些示例。
Steve wishes to perform a third-party FTP transfer between two FTP servers. Steve would use an existing PC to authenticate to both servers and delegate a PC to both hosts. He would inform each host of the unique subject name of the PC given to the other host. When the servers establish the data channel connection to each other, they use these delegated credentials to perform authentication and verify they are talking to the correct entity by checking the result of the authentication matches the name as provided by Steve.
Steve希望在两台FTP服务器之间执行第三方FTP传输。Steve将使用现有PC对两台服务器进行身份验证，并将PC委派给两台主机。他会将电脑的唯一主题名称告知每一位主机，并告知另一位主机。当服务器彼此建立数据通道连接时，它们使用这些委派凭据执行身份验证，并通过检查身份验证结果是否与Steve提供的名称匹配来验证是否与正确的实体进行了对话。
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.
Steve希望将文件从主机H1传输到主机H2的权利委托给进程。Steve会将一台PC委托给该流程，他会使用代理策略将委托的PC限制为两种权限—在主机H1上读取文件F1的权限和在主机H2上写入文件F2的权限。
The process then uses this restricted PC to authenticate to servers H1 and H2. The process would also delegate a PC to both servers. Note that these delegated PCs would inherit the restrictions of their parents, though this is not relevant to this example. As in the example in the previous Section, each host would be provided with the unique name of the PC given to the other server.
然后，该过程使用此受限PC对服务器H1和H2进行身份验证。该过程还将把一台PC委派给两台服务器。请注意，这些委托PC将继承其父母的限制，尽管这与本例无关。如前一节中的示例所示，将为每个主机提供给另一台服务器的PC的唯一名称。
Now when the process issues the command to transfer the file F1 on H1 and to F2 on H2, these two servers perform an authorization check based on the restrictions in the PC that the process used to authenticate with them (in addition to any local policy they have). Namely H1 checks that the PC gives the user the right to read F1 and H2 checks that the PC gives the user the right to write F2. When setting up the data channel the servers would again verify the names resulting from the authentication match the names provided by Steve as in the example in the previous Section.
现在，当进程发出命令将文件F1传输到H1，将文件传输到H2上的F2时，这两个服务器根据进程用于向其进行身份验证的PC中的限制（以及它们拥有的任何本地策略）执行授权检查。即H1检查PC是否授予用户读取F1的权利，H2检查PC是否授予用户写入F2的权利。在设置数据通道时，服务器将再次验证身份验证产生的名称与Steve提供的名称是否匹配，如前一节中的示例所示。
The extra security provided by these restrictions is that now if the PC delegated to the process by Steve is stolen, its use is greatly limited.
这些限制提供的额外安全性是，如果Steve委托给进程的PC被盗，其使用将受到极大限制。
A relying party accepting a Proxy Certificate may have an interest in knowing which parties issued earlier Proxy Certificates in the certificate chain and to whom they delegated them. For example it may know that a particular service or resource is known to have been
接受代理证书的依赖方可能有兴趣知道证书链中的哪些方颁发了早期代理证书，以及他们将代理证书委托给了谁。例如，它可能知道某个特定的服务或资源已被激活
compromised and if any part of a Proxy Certificate's chain was issued to the compromised service a relying party may wish to disregard the chain.
泄露，如果代理证书链的任何部分被颁发给泄露的服务，依赖方可能希望忽略该链。
A delegation tracing mechanism was considered by the authors as additional information to be carried in the ProxyCertInfo extension. However at this time agreement has not been reached as to what this information should include so it was left out of this document, and will instead be considered in future revisions. The debate mainly centers on whether the tracing information should simply contain the identity of the issuer and receiver or it should also contain all the details of the delegated proxy and a signed statement from the receiver that the proxy was actually acceptable to it.
作者将委托跟踪机制视为ProxyCertInfo扩展中的附加信息。但是，目前尚未就这些信息应包括哪些内容达成一致意见，因此本文件中未包含这些信息，将在今后的修订中予以考虑。争论主要集中在追踪信息是否应仅包含发行人和接收人的身份，还是还应包含委托代理人的所有详细信息以及接收人签署的代理人实际可接受的声明。
In some cases, it may be desirable to know the hosts involved in a delegation transaction (for example, a relying party may wish to reject proxy certificates that were created on a specific host or domain). An extension could be modified to include the PA's and Acceptor's IP addresses; however, IP addresses are typically easy to spoof, and in some cases the two parties to a transaction may not agree on the IP addresses being used (e.g., if the Acceptor is on a host that uses NAT, the Acceptor and the PA may disagree about the Acceptor's IP address).
在某些情况下，可能希望了解委托事务中涉及的主机（例如，依赖方可能希望拒绝在特定主机或域上创建的代理证书）。可修改扩展以包括PA和接受者的IP地址；然而，IP地址通常很容易被欺骗，在某些情况下，交易双方可能不同意使用的IP地址（例如，如果接受方位于使用NAT的主机上，则接受方和PA可能对接受方的IP地址存在分歧）。
Another suggestion was, in those cases where domain information is needed, to require that the subject names of all End Entities involved (the Acceptor(s) and the End Entity that appears in a PC's certificate path) include domain information.
另一项建议是，在需要域信息的情况下，要求所有涉及的最终实体（接受者和出现在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的私钥通常仅使用文件系统安全性进行保护，以允许该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的一种常见方法是将其有效期限制在不超过需要的范围内，和/或在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的高价值且难以替换的公钥方面具有很大的实用价值。换句话说，使用代理证书在X.509 PKI环境中提供单点登录功能实际上可以提高最终实体证书的安全性，因为创建和使用PC进行用户身份验证将EEC私钥的公开限制为仅创建一级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字段可由EEC用于限制PC的后续授权。如果可以向服务授权有效的PC，则服务可以选择仅授权请求。此类服务的一个示例是job starter，如果无法向其委派有效的PC，它可以选择拒绝job start请求。通过限制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可以使用CRL分发点扩展和/或OCSP来承担撤销其已发布的PC的责任，如果它认为这些PC被滥用。
The relying party that is going to authorize some actions on the basis of a PC will be aware that it has been presented with a PC, and can determine the depth of the delegation and the time that the delegation took place. It may want to use this information in addition to the information from the signing EEC. Thus a highly secure resource might refuse to accept a PC at all, or maybe only a single level of delegation, etc.
将根据PC授权某些行动的依赖方将知道其已收到PC，并可确定授权的深度和授权发生的时间。除了来自签名EEC的信息外，它可能还想使用此信息。因此，一个高度安全的资源可能完全拒绝接受PC，或者可能只接受单一级别的委托，等等。
The relying party should also be aware that since the policy restricting the rights of a PC is the intersection of the policy of all the PCs in it's certificate chain, this means any change in the certificate chain can effect the policy of the PC. Since there is no mechanism in place to enforce unique subject names of PCs, if an issuer were to issue two PCs with identical names and keys, but different rights, this could allow the two PCs to be substituted for each other in path validation and effect the rights of a PC down the chain. Ultimately, this means the relying party places trust in the entities that are acting as Proxy Issuers in the chain to behave properly.
依赖方还应意识到，由于限制个人电脑权利的政策是其证书链中所有个人电脑政策的交叉点，这意味着证书链中的任何更改都可能影响个人电脑的政策。由于没有机制强制个人电脑的唯一主体名称，如果发行人发行两台具有相同名称和密钥但权限不同的PC，这将允许两台PC在路径验证中相互替换，并影响链下游PC的权限。最终，这意味着依赖方信任在链中充当代理发行人的实体，以确保其行为正常。
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已经为策略语言建立了一个注册表。IETF空间下的注册由IETF标准行动进行，如[i8]所述。私人政策语言应在组织框架下；鼓励策略语言作者在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
OID Description
--- -----------
1.3.6.1.5.5.7.21.1 id-ppl-inheritALL
1.3.6.1.5.5.7.21.2 id-ppl-independent
[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[n1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[n2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[n2] Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S. Tuecke, "A National-Scale Authentication Infrastructure", IEEE Computer, vol. 33, pp. 60-66, 2000.
[i1] Butler，R.，Engert，D.，Foster，I.，Kesselman，C.，和S.Tuecke，“国家级认证基础设施”，IEEE计算机，第33卷，第60-66页，2000年。
[i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[i2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[i3] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[i3] Farrell，S.和R.Housley，“用于授权的互联网属性证书配置文件”，RFC 3281，2002年4月。
[i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A Security Architecture for Computational Grids", presented at Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998.
[i4] Foster，I.，Kesselman，C.，Tsudik，G.，和S.Tuecke，“计算网格的安全架构”，在第五届ACM计算机和通信安全会议记录上发表，1998年。
[i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the Grid: Enabling Scalable Virtual Organizations", International Journal of Supercomputer Applications, 2001.
[i5] Foster，I.，Kesselman，C.，和S.Tuecke，“网格的解剖：实现可伸缩的虚拟组织”，国际超级计算机应用杂志，2001年。
[i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[i6] Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[i7] Neuman, B. Clifford, "Proxy-Based Authorization and Accounting for Distributed Systems", In Proceedings of the 13th International Conference on Distributed Computing Systems, pages 283-291, May 1993.
[i7] Neuman，B.Clifford，“分布式系统基于代理的授权和会计”，载于《第13届分布式计算系统国际会议论文集》，第283-291页，1993年5月。
[i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA Considerations Section in RFC", RFC 2434, October 1998.
[i8] Narten，T.和H.Alvestrand。“在RFC中编写IANA注意事项部分的指南”，RFC 2434，1998年10月。
We are pleased to acknowledge significant contributions to this document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist.
我们很高兴感谢David Chadwick、Ian Foster、Jarek Gawor、Carl Kesselman、Sam Meder、Jim Schaad和Frank Siebenlist对本文件的重要贡献。
We are grateful to numerous colleagues for discussions on the topics covered in this paper, in particular (in alphabetical order, with apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman, Gene Tsudik.
我们感谢众多同事就本文所涉及的主题进行讨论，特别是（按字母顺序，向我们错过的任何人道歉）：卡莱尔·亚当斯、乔·贝斯特、兰迪·巴特勒、基思·杰克逊、史蒂夫·汉纳、罗斯·霍斯利、斯蒂芬·肯特、比尔·约翰斯顿、马蒂·汉弗莱、山姆·朗、艾伦·麦克德莫特、克利福德·纽曼、，吉恩·祖迪克。
We are also grateful to members of the Global Grid Forum (GGF) Grid Security Infrastructure working group (GSI-WG), and the Internet Engineering Task Force (IETF) Public-Key Infrastructure (X.509) working group (PKIX) for feedback on this document.
我们还感谢全球网格论坛（GGF）网格安全基础设施工作组（GSI-WG）和互联网工程任务组（IETF）公钥基础设施（X.509）工作组（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-Eng-38和DE-AC03-76SF0098；由国防高级研究计划局根据合同N66001-96-C-8523提供；国家科学基金会；以及美国宇航局信息电网项目。
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) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
proxy-cert-extns(25) }
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
-- IMPORTS NONE --
--没有进口--
-- PKIX specific OIDs
--PKIX特定OID
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
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 }
-- 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 }
-- 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 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 }
-- 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 }
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
END
终止
Authors' Addresses
作者地址
Steven Tuecke Distributed Systems Laboratory Mathematics and Computer Science Division Argonne National Laboratory Argonne, IL 60439
Steven Tuecke分布式系统实验室数学和计算机科学部阿贡国家实验室，伊利诺伊州阿贡60439
Phone: 630-252-8711 EMail: tuecke@mcs.anl.gov
电话：630-252-8711电子邮件：tuecke@mcs.anl.gov
Von Welch National Center for Supercomputing Applications University of Illinois
韦尔奇国家超级计算应用中心伊利诺伊大学
EMail: vwelch@ncsa.uiuc.edu
EMail: vwelch@ncsa.uiuc.edu
Doug Engert Argonne National Laboratory
道格·恩格特·阿贡国家实验室
EMail: deengert@anl.gov
EMail: deengert@anl.gov
Laura Pearlman University of Southern California, Information Sciences Institute
劳拉，南加州大学信息科学研究所
EMail: laura@isi.edu
EMail: laura@isi.edu
Mary Thompson Lawrence Berkeley National Laboratory
玛丽·汤普森·劳伦斯·伯克利国家实验室
EMail: mrthompson@lbl.gov
EMail: mrthompson@lbl.gov
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。