WDIFF

draft-ietf-pkix-proxy-10.txt --> rfc3820.txt

Internet Draft

Network Working Group S. Tuecke
Document: draft-ietf-pkix-proxy-10
Request for Comments: 3820 ANL
Expires May 2004
Category: Standards Track V. Welch
NCSA
D. Engert
ANL
L. Pearlman
USC/ISI
M. Thompson
LBNL
19 December 2003
June 2004

Internet X.509 Public Key Infrastructure (PKI)
Proxy Certificate Profile

Status of this Memo

This document is specifies an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months requests discussion and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or suggestions for
improvements. Please refer to cite them other than as "work in
progress."

The list of the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list edition of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This document provides information to the community regarding "Internet
Official Protocol Standards" (STD 1) for the
profile standardization state
and status of the X.509 Proxy Certificate. It defines a standard for
implementing X.509 Proxy Certificates.

Tuecke, et al. 1 this protocol. Distribution of this memo is unlimited.

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.

Table of Contents
1 Introduction...................................................3
2 Overview of Approach...........................................4
2.1 Terminology..................................................5
2.2 Background...................................................5
2.3 Motivation for Proxying......................................6
2.4 Motivation for Restricted Proxies............................8
2.5 Motivation for Unique Proxy Name.............................9
2.6 Description Of Approach.....................................10
2.7 Features Of This Approach...................................11
3 Certificate and Certificate Extensions Profile................13
3.1 Issuer......................................................14
3.2 Issuer Alternative Name.....................................14
3.3 Serial Number...............................................14
3.4 Subject.....................................................14
3.5 Subject Alternative Name....................................15
3.6 Key Usage and Extended Key Usage............................15
3.7 Basic Constraints...........................................15
3.8 The ProxyCertInfo Extension.................................15
4 Proxy Certificate Path Validation.............................20
4.1 Basic Proxy Certificate Path Validation.....................21
4.2 Using the Path Validation Algorithm.........................25
5 Commentary....................................................27
5.1 Relationship to Attribute Certificates......................27
5.2 Kerberos 5 Tickets..........................................31
5.3 Examples of usage of Proxy Restrictions.....................32
5.4 Delegation Tracing..........................................33
6 Security Considerations.......................................34
6.1 Compromise of a Proxy Certificate...........................34
6.2 Restricting Proxy Certificates..............................35
6.3 Relying Party Trust of Proxy Certificates...................35
6.4 Protecting Against Denial of Service with Key Generation....36

Tuecke, et al. 2

Internet Draft Standards Track [Page 1]

RFC 3820 X.509 Proxy Certificate Profile December 2003

6.5 Use June 2004

Table of Proxy Certificates in a Central Repository...........36
7 IANA Considerations...........................................37
8 Normative References..........................................37
9 Informational References......................................37
10 Acknowledgments.............................................38
11 Contact Information.........................................39
12 Copyright Notice............................................39
13 Intellectual Property Statement.............................40
Appendix A. 1988 ASN.1 Module....................................41
Appendix B. Change Log (To be removed prior to publication)......42

1 Contents

1. Introduction

Use of a proxy credential [i8] 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of entity A. This
document forms a certificate profile 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 Certificates, based
on the RFC 3280, "Internet X.509 Public Key Infrastructure Name . . . . . . . . . . . . 8
2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9
2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10
3. Certificate and CRL Profile" [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.

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

Tuecke, et al. 3

Internet Draft X.509 Proxy Certificate Extensions Profile December 2003

discussions of how subject names are used by this proxying
approach, and features of this approach.

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.

Section 4 defines path validation rules for Proxy Certificates.

Section 5 provides non-normative commentary on Proxy Certificates.

Section 6 discusses security considerations relating to Proxy
Certificates.

References in this document are sorted into normative and
information references. Normative references, listed in Section 8,
are in the form [nXX]. Informative references, listed in Section
9, are in the form [iXX].

Section 10 contains acknowledgements.

Section 11 contains contact information for the authors.

Section . . . . . . . . 12 contains the copyright information for this document.

Section 13 contains the intellectual property information for this
document.

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 RFC-2119 [n1].

2 Overview of Approach

This section provides non-normative commentary on Proxy
Certificates.

Tuecke, et al. 4

Internet Draft X.509 Proxy Certificate Profile December 2003

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.

This section provides relevant background, motivation, an overview
of the approach, and related work.

2.1 Terminology

This document uses the following terms:

* CA: A "Certificate Authority", as defined by 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.

* PKC: An end entity "Public Key Certificate". This is synonymous
with an EEC.

* PC: A "Proxy Certificate", the profile of which is defined by
this document.

* 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.

* AC: An "Attribute Certificate", as defined by "An Internet
Attribute Certificate Profile for Authorization" [i3].

* AA: An "Attribute Authority", as defined in [i3].

2.2 Background

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.

Tuecke, et al. 5

Internet Draft X.509 Proxy Certificate Profile December 2003

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.

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.

2.3 Motivation for Proxying

A motivating example will assist in understanding the role proxying
can play in building Internet based applications.

Steve is an engineer who wants to use a reliable file transfer
service to manage the movement of a number of large files around
between various hosts on his company's Intranet-based Grid. From
his laptop he wants to submit a number of transfer requests to the
service and have the files transferred while he is doing other
things, including being offline. The transfer service may queue
the requests for some time (e.g. until after hours or a period of
low resource usage) before initiating the transfers. The transfer
service will then, for each file, connect to each of the source and
destination hosts, and instruct them 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 contacts 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.

Tuecke, et al. 6

Internet Draft X.509 Proxy Certificate Profile December 2003

This scenario requires authentication and delegation in a variety
of places:

* Steve needs to be able to mutually authenticate with the remote
file transfer service to submit the transfer request.

* Since the storage hosts know nothing about the file transfer
service, the file transfer service needs to be delegated the
rights to mutually authenticate with the various storage hosts
involved directly in the file transfer, in order to initiate the
file transfer.

* The source and destination hosts of a particular transfer must
be able to mutual authenticate with each other, to ensure the
file is being transferred to and from the proper parties.

* The agent running on Steve's laptop must mutually authenticate
with the file transfer service in order to check the result of
the transfers.

Proxying is a viable approach to solving two (related) problems in
this scenario:

* Single sign-on: Steve wants to enter his smartcard password (or
pin) once, and then run a program that will submit all the file
transfer requests to the transfer service, and then periodically
check on the status of the transfer. This program needs to be
given the rights to be able to perform all of these operations
securely, without requiring repeated access to the smartcard or
Steve's password.

* Delegation: Various remote processes in this scenario need to
perform secure operations on Steve's behalf, and therefore must
be delegated the necessary rights. For example, the file
transfer service needs to be able to authenticate on Steve's
behalf with the source and destination hosts, and must in turn
delegate rights to those hosts so that they can authenticate
with each other.

Proxying can be used to secure all of these interactions:

* Proxying allows for the private key stored on the smartcard to
be accessed just once, in order to create the necessary proxy

Tuecke, et al. 7

Internet Draft X.509 Proxy Certificate Profile December 2003

credential, which allows the client/agent program to be
authorized as Steve when submitting the requests to the transfer
service. Access to the smartcard and Steve's password is not
required after the initial creation of the proxy credential.

* The client program on the laptop can delegate to the file
transfer service the right to act on Steve's behalf. This, in
turn, allows the service to authenticate to the storage hosts
and inherit Steve's privileges in order to start the file
transfers.

* When the transfer service authenticates to hosts to start the
file transfer, the service can delegate to the hosts the right
to act on Steve's behalf so that each pair of hosts involved in
a file transfer can mutually authenticate to ensure the file is
securely transferred.

* When the agent on the laptop reconnects to the file transfer
service to check on the status of the transfer, it can perform
mutual authentication. The laptop may use a newly generated
proxy credential, which is just created anew using the
smartcard.

This scenario, and others similar to it, is being built today
within the Grid community. The Grid Security Infrastructure's
single sign-on and delegation capabilities, built on X.509 Proxy
Certificates, are being employed to provide authentication services
to these applications.

2.4 Motivation for Restricted Proxies

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?

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

Tuecke, et al. 8

Internet Draft X.509 Proxy Certificate Profile December 2003

purpose of reading the source files and writing the destination
files. Therefore, if that file transfer service is compromised,
the attacker cannot modify source files, cannot create or modify
other files to which Steve has access, cannot start jobs on behalf
of Steve, etc. All that an attacker would be able to do is read
the specific files to which the file transfer service has been
delegated read access, and write bogus files in place of those that
the file transfer service has been delegated write access.
Further, by limiting the lifetime of the credential that is
delegated to the file transfer service, the effects of a compromise
can be further mitigated.

Other potential uses for restricted proxy credentials are discussed
in [i8].

2.5 Motivation for Unique Proxy Name

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.

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).

Tuecke, et al. 9

Internet Draft X.509 Proxy Certificate Profile December 2003

2) Obtain a new identity independently - for example by using the
generated public key and a self-signed certificate.

3) Derive the new identity from an existing identity.

In this document we describe an approach to option #3, because:

* 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.

2.6 Description Of Approach

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.

A
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 is an X.509 public key certificate with the
following properties:

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).

2) It can sign only another PC. It cannot sign an EEC.

3) It has its own public and private key pair, distinct from any
other EEC or 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.

Tuecke, et al. 10

Internet Draft X.509 Path Validation. . . . . . . . . . . . . . . 17
4.1. Basic Proxy Certificate Profile December 2003

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 Path Validation. . . . . . . . . 19
4.2. Using the issuing EEC, for example in conjunction with attribute
assertions as defined in [i3].

6) It contains a new X.509 extension to identify it as a PC and Path Validation Algorithm. . . . . . . . . . . 23
5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Relationship to
place policies on the use Attribute Certificates . . . . . . . . . 24
5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
5.3. Examples of the PC. This new extension, along
with other X.509 fields and extensions, are used to enable
proper path validation and use usage of the PC.

The process Proxy Restrictions. . . . . . . . . 28
5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
6.1. Compromise of creating a PC is as follows:

1) A new public and private key pair is generated.

2) That key pair is used to create a request for a Proxy Certificate
that conforms to the profile described in this document.

3) A Certificate. . . . . . . . . . . . 30
6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31
6.3. Relying Party Trust of Proxy Certificate, signed by the private key Certificates. . . . . . . . 31
6.4. Protecting Against Denial of the EEC or by
another PC, is created Service with Key Generation 32
6.5. Use of Proxy Certificates 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).

When a PC 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

Tuecke, et al. Standards Track [Page 2]

RFC 3820 X.509 Proxy Certificate Profile June 2004

1. Introduction

Use of a proxy credential [i7] is created as part of a delegation from common technique used in security
systems to allow 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 grant to another entity A over an authenticated, integrity checked channel, then
entity A performs step #3 and passes B the PC back right for
B to be authorized with others as if it were A. In other words,
entity B.

Path validation of a PC B is very similar to normal path validation,
with acting as a few additional checks to ensure, for example, proper PC
signing constraints.

2.7 Features Of This Approach

Using Proxy Certificates to perform delegation has several features
that make it attractive:

* Ease proxy on behalf of integration

. Because a PC requires only entity A. This document
forms a minimal change to path
validation, it is very easy to incorporate support certificate profile for Proxy

Tuecke, et al. 11

Internet Draft Certificates, based on the RFC
3280, "Internet X.509 Proxy Public Key Infrastructure Certificate Profile December 2003

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 CRL
Profile" [n2].

In addition to simple, unrestricted proxying, this profile defines:

* A framework for carrying policies in Proxy Certificates that
allows proxying to retrieve the authenticated subject of the
signing EEC instead be limited (perhaps completely disallowed)
through either restrictions or enumeration of rights.

* Proxy Certificates with unique names, derived from the subject name of the PC for
authorization purposes.

. Many existing authorization systems use the X.509 subject
name as
end entity certificate name. This allows the basis for access control. Proxy Certificates can
to be used in conjunction with attribute assertion approaches such authorization systems without modification,
since such a PC inherits its name
as Attribute Certificates [i3] and have their own rights from
independent of their issuer.

Section 2 provides a non-normative overview of the EEC
that signed it approach. It
begins by defining terminology, motivating Proxy Certificates, and
giving a brief overview of the EEC name can be used 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 place the X.509 keyCertSign field of the
PC name for authorization decisions.

* Ease
keyUsage extension. It then continues with discussions of use

. Using PC for single sign-on helps make X.509 PKI
authentication easier to use, how
subject names are used by allowing users to "login"
once this proxying approach, and features of
this approach.

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 then perform various operations securely.

. For many users, properly managing their own EEC private extended key usage. A new certificate
extension, Proxy Certificate Information, is a nuisance at best, and a introduced.

Section 4 defines path validation rules for Proxy Certificates.

Section 5 provides non-normative commentary on Proxy Certificates.

Section 6 discusses security risk at worst. One
option easily enabled with a PC is considerations relating to manage the EEC private
keys Proxy
Certificates.

Tuecke, et al. Standards Track [Page 3]

RFC 3820 X.509 Proxy Certificate Profile June 2004

References, listed in Section 8, are sorted into normative and certificates
information references. Normative references, listed in Section 8.1,
are in a centrally managed repository.
When a user needs a PKI credential, the user can login to form [nXX]. Informative references, listed in Section
8.2, are in the
repository using name/password, one time password, etc. Then form [iXX].

Section 9 contains acknowledgements.

Following Section 9, contains the repository can delegate a PC to Appendix, the user with proxy
rights, but continue to protect contact information
for the EEC private authors, the intellectual property information, and the
copyright information for this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
repository.

* Protection this
document are to be interpreted as described in BCP 14, RFC 2119 [n1].

2. Overview of private keys

. By using the remote delegation approach outlined above,
entity A can delegate Approach

This section provides non-normative commentary on Proxy Certificates.

The goal of this specification is to develop a PC X.509 Proxy
Certificate profile and to facilitate their use within Internet
applications for those communities wishing to entity B, without entity B ever
seeing the private key make use of entity A, restricted
proxying and without entity A ever
seeing the private key delegation within an X.509 Public Key Infrastructure
(PKI) authentication based system.

This section provides relevant background, motivation, an overview of
the newly delegated PC held approach, and related work.

2.1. Terminology

This document uses the following terms:

* CA: A "Certification Authority", as defined by
entity B. In other words, private keys never need to be
shared or communicated X.509 [n2]

* EEC: An "End Entity Certificate", as defined by the entities participating in X.509. That is,
it is an X.509 Public Key Certificate issued to an end entity,
such as a
delegation of user or a PC.

. When implementing single sign-on, using service, by a PC helps protect CA.

* PKC: An end entity "Public Key Certificate". This is synonymous
with an EEC.

* PC: A "Proxy Certificate", the private key profile of the EEC, because it minimizes the exposure which is defined by this
document.

Tuecke, et al. 12

Internet Draft Standards Track [Page 4]

RFC 3820 X.509 Proxy Certificate Profile December 2003

and use of that private key. For example, when an EEC
private key June 2004

* PI: A "Proxy Issuer" 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 an entity with an End Entity Certificate
or private key. Similarly, when Proxy Certificate that issues a Proxy Certificate. The Proxy
Certificate is signed using the EEC private key lives on a smartcard, associated with the smartcard need only be
present
public key in the machine during the creation of the PC. Proxy Issuer's certificate.

* Limiting consequences of a compromised key

. When creating a PC, the PI can limit the validity period of
the PC, the depth of the PC path that can be created AC: An "Attribute Certificate", as defined by that
PC, and key usage of the PC "An Internet
Attribute Certificate Profile for Authorization" [i3].

* AA: An "Attribute Authority", as defined in [i3].

2.2. Background

Computational and its descendents. Further,
fine-grained policies can be carried by Data "Grids" have emerged as a PC to even further
restrict the operations that can be performed using the PC.
These restrictions permit the PI common approach to limit damage that could
be done by
constructing dynamic, inter-domain, distributed computing
environments. As explained in [i5], large research and development
efforts starting around 1995 have focused on the bearer question of what
protocols, services, and APIs are required for effective, coordinated
use of resources in these Grid environments.

In 1997, the PC, either accidentally or
maliciously.

. A compromised PC private key does NOT compromise Globus Project (www.globus.org) introduced the EEC
private key. Grid
Security Infrastructure (GSI) [i4]. This makes a short term, or an otherwise
restricted PC attractive library provides for day-to-day use, since a
compromised PC does not require public
key based authentication and message protection, based on standard
X.509 certificates and public key infrastructure, the user SSL/TLS
protocol [i2], and delegation using proxy certificates similar to
those profiled in this document. GSI has been used, in turn, to go through the
usually cumbersome
build numerous middleware libraries and time consuming process of having applications, which have been
deployed in large-scale production and experimental Grids [i1]. GSI
has emerged as the
EEC with a new private key reissued dominant security solution used by Grid efforts
worldwide.

This experience with GSI has proven the CA.

See Section 5 below viability of restricted
proxying as a basis for more discussion on how Proxy Certificates
relate to Attribute Certificates.

3 Certificate authorization within Grids, and Certificate Extensions Profile

This section defines has further
proven the usage viability of using X.509 certificate fields and
extensions in Proxy Certificates, and defines one new extension for
Proxy Certificate Information.

All Proxy Certificates MUST include the Proxy Certificate
Information (ProxyCertInfo) extension as defined in
this section and document, as the extension MUST be critical.

Tuecke, et al. 13

Internet Draft X.509 Proxy Certificate Profile December 2003

3.1 Issuer

The Proxy Issuer basis for that proxying. This document is one
part 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.

3.2 Issuer Alternative Name

The issuerAltName extension MUST NOT be present effort to migrate this experience with GSI into standards,
and in a Proxy
Certificate.

3.3 Serial Number

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 the process clean up the approach and better reconcile it with
existing and recent standards.

2.3. Motivation for Proxying

A motivating example will assist in understanding the role proxying
can play in building Internet based applications.

Steve is an engineer who wants to assigning serial
numbers that merely ensures a high probability of uniqueness.

For example, a Proxy Issuer MAY use a sequentially assigned integer
or a UUID reliable file transfer
service to assign manage the movement of a unique serial number to a PC it issues. Or a
Proxy Issuer MAY use a SHA-1 hash of the PC public key large files around
between various hosts on his company's Intranet-based Grid. From his
laptop he wants to assign submit a
serial number with of transfer requests to the
service and have the files transferred while he is doing other

Tuecke, et al. Standards Track [Page 5]

RFC 3820 X.509 Proxy Certificate Profile June 2004

things, including being offline. The transfer service may queue the
requests for some time (e.g., until after hours or a high probability period of uniqueness.

3.4 Subject low
resource usage) before initiating the transfers. The subject field transfer
service will then, for each file, connect to each of the source and
destination hosts, and instruct them to initiate a Proxy Certificate MUST be data connection
directly from the issuer field
(that is source to the subject destination in order to transfer the
file. Steve will leave an agent running on his laptop that will
periodically check on progress of the Proxy Issuer) appended with 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.

This scenario requires authentication and delegation in a single
Common Name component.

The value variety of the Common Name SHOULD
places:

* Steve needs to be unique able to each Proxy
Certificate bearer amongst all Proxy Certificates mutually authenticate with the same
issuer.

If a Proxy Issuer issues two proxy certificates reliable
file transfer service to submit the same bearer, transfer request.

* Since the Proxy Issuer MAY choose to use storage hosts know nothing about the same Common Name for both.
Examples of this include Proxy Certificates for different uses

Tuecke, et al. 14

Internet Draft X.509 Proxy Certificate Profile December 2003

(e.g. signing vs encryption) or file transfer
service, the re-issuance of an expired Proxy
Certificate.

The Proxy Issuer MAY use an approach file transfer service needs to assigning Common Name
values that merely ensures a high probability of uniqueness. This
value MAY be delegated 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
rights to mutually authenticate with the issuing EEC (it will
be various storage hosts
involved directly in the first part of file transfer, in order to initiate the subject name appended with one or more CN
components)
file transfer.

* The source and are unique destination hosts of a particular transfer must be
able to mutual authenticate with each bearer.

3.5 Subject Alternative Name other, to ensure the file is
being transferred to and from the proper parties.

* The subjectAltName extension MUST NOT be present agent running on Steve's laptop must mutually authenticate
with the file transfer service in order to check the result of the
transfers.

Proxying is a Proxy
Certificate.

3.6 Key Usage viable approach to solving two (related) problems in
this scenario:

* Single sign-on: Steve wants to enter his smartcard password (or
pin) once, and Extended Key Usage

If the Proxy Issuer certificate has then run a Key Usage extension, program that will submit all the
Digital Signature bit MUST be asserted.

This draft places no constraints file
transfer requests to the transfer service, and then periodically
check on the presence or contents status of the
key usage and extended key usage extension. However, section 4.2
explains what functions should transfer. This program needs to be allowed a proxy certificate by a
relying party.

3.7 Basic Constraints

The cA field in
given the basic constraints extension MUST NOT rights to be TRUE.

3.8 The ProxyCertInfo Extension

A new extension, ProxyCertInfo, is defined in this subsection.
Presence able to perform all of these operations
securely, without requiring repeated access to the ProxyCertInfo extension indicates that a
certificate is a Proxy Certificate and whether smartcard or not the issuer of
the certificate has placed any restrictions
Steve's password.

* Delegation: Various remote processes in this scenario need to
perform secure operations on its use.

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 }

Tuecke, et al. 15

Internet Draft X.509 Proxy Certificate Profile December 2003

id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }

ProxyCertInfo ::= SEQUENCE {
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }

ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }

If a certificate is a Proxy Certificate, then Steve's behalf, and therefore must be
delegated the proxyCertInfo
extension MUST necessary rights. For example, the file transfer

Tuecke, et al. Standards Track [Page 6]

RFC 3820 X.509 Proxy Certificate Profile June 2004

service needs to be present, able to authenticate on Steve's behalf with
the source and this extension MUST destination hosts, and must in turn delegate rights
to those hosts so that they can authenticate with each other.

Proxying can be marked 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
critical.

If a certificate Steve when submitting the requests to the transfer service.
Access to the smartcard and Steve's password is not a Proxy Certificate, then required after
the proxyCertInfo
extension MUST be absent.

The ProxyCertInfo extension consists initial creation of one required the proxy credential.

* The client program on the laptop can delegate to the file transfer
service the right to act on Steve's behalf. This, in turn, allows
the service to authenticate to the storage hosts and two
optional fields, which are described inherit
Steve's privileges in detail order to start the file transfers.

* When the transfer service authenticates to hosts to start the file
transfer, the service can delegate to the hosts the right to act
on Steve's behalf so that each pair of hosts involved in a file
transfer can mutually authenticate to ensure the following
subsections.

3.8.1 pCPathLenConstraint

The pCPathLenConstraint field, if present, specifies file is securely
transferred.

* When the agent on the laptop reconnects to the file transfer
service to check on the maximum
depth status of the path of Proxy Certificates that transfer, it can be signed by this
Proxy Certificate. A pCPathLenConstraint of 0 means that this
certificate MUST NOT be used to sign perform
mutual authentication. The laptop may use a Proxy Certificate. If the
pCPathLenConstraint field newly generated proxy
credential, which is not present then just created anew using the maximum proxy
path length smartcard.

This scenario, and others similar to it, is unlimited. End entity certificates have unlimited
maximum proxy path lengths.

3.8.2 proxyPolicy being built today within
the Grid community. The proxyPolicy field specifies a policy Grid Security Infrastructure's single sign-
on the use of this
certificate and delegation capabilities, built on X.509 Proxy Certificates,
are being employed to provide authentication services to these
applications.

2.4. Motivation for Restricted Proxies

One concern that arises is what happens if a machine that has been
delegated the purposes of authorization. Within right to inherit Steve's privileges has been
compromised? For example, in the
proxyPolicy, above scenario, what if the policy field machine
running the file transfer service is an expression of policy, and compromised, such that the
policyLanguage field indicates
attacker can gain access to the language in which credential that Steve delegated to
that service? Can the policy attacker now do everything that Steve is
expressed.

The proxyPolicy field in the proxyCertInfo extension does not
define a policy language
allowed to be used do?

A solution to this problem is to allow for proxy restrictions; rather,
it places restrictions to be placed
on the burden proxy by means of policies on those parties using that extension to the proxy certificates. For
example, the machine running the reliable file transfer service in

Tuecke, et al. 16

Internet Draft Standards Track [Page 7]

RFC 3820 X.509 Proxy Certificate Profile December 2003

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 June 2004

the above example might only be given Steve's right for the PI that issues a
certificate with a proxyPolicy field purpose
of reading the source files and writing the relying party that
interprets destination files.
Therefore, if that field to agree on its meaning, file transfer service is compromised, the policy language
OID must correspond attacker
cannot modify source files, cannot create or modify other files to a policy language (including semantics), not
just a policy grammar.

The policyLanguage field
which Steve has two values access, cannot start jobs on behalf of special importance,
defined in Appendix A, that MUST be understood by all parties
accepting Proxy Certificates:

* id-ppl-inheritAll indicates Steve, etc.
All that this is an unrestricted proxy
that inherits all rights from the issuing PI. An unrestricted
proxy attacker would be able to do is a statement that read the Proxy Issuer wishes to delegate
all of its authority specific files
to which the bearer (i.e., to anyone who file transfer service has that
proxy certificate been delegated read access,
and can prove possession of the associated
private key). For purposes of authorization, this an
unrestricted proxy effectively impersonates the issuing 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.

For either write bogus files in place of those that the policyLanguage values listed above, file transfer
service has been delegated write access. Further, by limiting the policy
field MUST NOT be present.

Other values for
lifetime of the policyLanguage field indicates credential that this is delegated to the file transfer
service, the effects of a compromise can be further mitigated.

Other potential uses for restricted proxy certification credentials are discussed
in [i7].

2.5. Motivation for Unique Proxy Name

The dynamic creation of entities (e.g., processes and have some other policy limiting
its ability services) is an
essential part of Grid computing. These entities will require rights
in order to do proxying. In 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 policy field MAY be
present
entity to obtain and hold two proxy certifications, in practice it MUST contain information expressing the policy. If
the policy field is not present
simpler for subsequent credentials to take the policy MUST form of attribute
certificates.

It is also desirable for these entities to have a unique identity so
that they can be implicit explicitly discussed in the
value 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 policyLanguage field itself. Authors identity of additional
policy languages are encouraged to publicly document their policy
language and list it in the IANA registry (see Section Error!
Reference source not found.).

Proxy policies other, then when the two servers connected they
could authenticate themselves and know they are used connected to limit the amount
proper party.

In order for a party to have rights of authority delegated, 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).

2) Obtain a new identity independently - for example to assert that by using the proxy certificate may be used only
to make requests to
generated public key and a specific server, or only to authorize
specific operations on specific resources. This document is
agnostic to the policies that can be placed in self-signed certificate.

3) Derive the policy field. new identity from an existing identity.

Tuecke, et al. 17

Internet Draft Standards Track [Page 8]

RFC 3820 X.509 Proxy Certificate Profile December 2003

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 June 2004

In this document we describe 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 approach to verify that the requested authority option #3, because:

* It is compatible reasonably light-weight, as it can be done without
interacting 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:

1) The relying party MUST know how to interpret the proxy policy and
the request a third party. This is allowed under that policy.

2) If important when
creating identities dynamically.

* As described in the Proxy Issuer previous section, a common use for PCs is an EEC then the relying party's local
policies MUST authorize the request
for restricted proxying, so deriving their identity from the entity named in the
EEC.

3) If the Proxy Issuer is another PC, then one
identity of the following MUST
be true:

a. The relying party's local policies authorize EEC makes this straightforward. Nonetheless
there are circumstances where the Proxy
Issuer creator does not wish to perform the request.

b. The Proxy Issuer inherits the right
delegate all or any of its rights to perform a new entity. Since the request
from its issuer
name is unique, this is easily accomplished by means of its proxy policy. This must be
verified #3 as well, by verifying these three conditions on
allowing the Proxy
Issuer in application of a recursive manner.

If these conditions are not met, policy to limit proxying.

2.6. Description Of Approach

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.

A Proxy Certificate is an X.509 public key certificate with the relying party MUST
following properties:

1) It is signed by either deny
authorization, an X.509 End Entity Certificate (EEC), or
by another PC. This EEC or ignore the PC is referred to as the Proxy Issuer
(PI).

2) It can sign only another PC. It cannot sign an EEC.

3) It has its own public and private key pair, distinct from any
other EEC or PC.

4) It has an identity derived from the whole certificate chain
including identity of the EEC entirely when making its authorization decision
(i.e., make the same decision that it would have made had
signed the PC
and it's certificate chain never been presented).

The relying party MAY impose additional restrictions as to which
proxy certificates it accepts. For example, PC. When a relying party MAY
choose to reject all proxy certificates, or MAY choose to accept
proxy certificates only PC is used for certain operations, etc.

Note authentication, in may
inherit rights of the EEC that since a proxy certificate has a unique signed the PC, subject to the
restrictions that are placed on that PC by the EEC.

5) Although its identity is derived from the EEC's identity, it MAY is
also have rights granted unique. This allows this identity to it by means other than inheritance be used for
authorization as an independent identity from
it's issuer via its proxy policy. The rights granted to the bearer identity of the
issuing EEC, for example in conjunction with attribute assertions
as defined in [i3].

6) It contains a new X.509 extension to identify it as a PC are and to
place policies on the union use of the rights granted PC. This new extension, along
with other X.509 fields and extensions, are used to the PC identity enable proper
path validation and use of the PC.

Tuecke, et al. 18

Internet Draft Standards Track [Page 9]

RFC 3820 X.509 Proxy Certificate Profile December 2003

the inherited rights. June 2004

The inherited rights consist process of creating a PC is as follows:

1) A new public and private key pair is generated.

2) That key pair is used to create a request for a Proxy Certificate
that conforms to the profile described in this document.

3) A Proxy Certificate, signed by the
intersection private key of the rights granted EEC or by
another PC, is created in response to the PI identity intersected
with the proxy policy in request. During this
process, the PC.

For example, imagine PC request is verified to ensure that Steve the requested
PC is authorized valid (e.g., it is not an EEC, the PC fields are
appropriately set, etc).

When a PC is created as part of a delegation from entity A to read entity
B, this process is modified by performing steps #1 and write
files #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 B on passes the PC back to entity B.

Path validation of a file server, and that he uses his EEC PC is very similar to create normal path validation,
with a few additional checks to ensure, for example, proper PC
signing constraints.

2.7. Features Of This Approach

Using Proxy Certificates to perform delegation has several features
that includes the policy that make it can be used attractive:

* Ease of integration

o Because a PC requires only a minimal change to read or
write files A and C. Then 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 trusted attribute authority grants
PC. Further, an
Attribute Certificate granting the PC the right SSL/TLS implementation requires only minor
changes to read file D.
This would make the rights of the support PC equal path validation, and to retrieve the
authenticated subject of the union signing EEC instead of the
rights granted to subject
of the PC identity (right to read file D) with for authorization purposes.

o Many existing authorization systems use the
intersection of 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 granted to Steve, from the PI, (right to read
files A EEC that
signed it and B) with the policy EEC name can be used in place of the PC (can only read files A and
C). This would mean the PC would have the following rights: name
for authorization decisions.

Tuecke, et al. Standards Track [Page 10]

RFC 3820 X.509 Proxy Certificate Profile June 2004

* Right to read file A: Steve has this right and he issued the Ease of use

o Using PC
and his policy grants this right for single sign-on helps make X.509 PKI authentication
easier to the PC.

* Right use, by allowing users to read file D: This right "login" once and then
perform various operations securely.

o For many users, properly managing their own EEC private key is granted explicitly to the PC
by
a trusted authority.

The nuisance at best, and a security risk at worst. One option
easily enabled with a PC would NOT have the following rights:

* Right to read file B: Although Steve has this right, it is
excluded by his policy on the PC.

* Right to read file C: Although Steve's policy grants this right,
he does not have this right himself.

In many cases, manage the EEC private keys and
certificates in a centrally managed repository. When a user
needs a PKI credential, the relying party will not have enough information user can login to evaluate the above criteria at the repository
using name/password, one time that password, etc. Then the certificate
path is validated. For example, if
repository can delegate a certificate is used PC to
authenticate the user with proxy rights, but
continue to protect the EEC private key in the repository.

* Protection of private keys

o By using the remote delegation approach outlined above, entity
A can delegate a connection PC to some server, that certificate is
typically validated during that authentication step, before any
requests have been made entity B, without entity B ever seeing
the private key of entity A, and without entity A ever seeing
the private key of the server. newly delegated PC held by entity B. In that case,
other words, private keys never need to be shared or
communicated by the relying
party MUST either have some authorization mechanism entities participating 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).

Tuecke, et al. 19

Internet Draft X.509 Proxy Certificate Profile December 2003

4 Proxy Certificate Path Validation

Proxy Certification path processing verifies delegation of a
PC.

o When implementing single sign-on, using a PC helps protect the binding between
private key of the proxy certificate distinguished name EEC, because it minimizes the exposure and proxy certificate
public
use of that private key. The binding For example, when an EEC private key
is limited by constraints which are
specified in password protected on disk, the certificates which comprise password and unencrypted
private key need only be available during the path and inputs
which are specified by creation of the relying party.

This section describes an algorithm
PC. That PC can then be used for validating proxy
certification paths. Conforming implementations the remainder of this
specification are not required to implement this algorithm, but
MUST provide functionality equivalent its valid
lifetime, without requiring access to the external behavior
resulting from this procedure. Any algorithm may be used by EEC password or
private key. Similarly, when the EEC private key lives on a
particular implementation so long as it derives
smartcard, the correct result.

The algorithm presented smartcard need only be present in this section validates the proxy
certificate with respect to machine
during the current date and time. A
conformant implementation MAY also support validation with respect
to some point in creation of the past. Note that mechanisms are not available
for validating PC.

* Limiting consequences of a proxy certificate with respect to compromised key

o When creating a time outside PC, the PI can limit the certificate validity period.

Valid paths begin with period of the end entity certificate (EEC)
PC, the depth of the PC path that has
already been validated can be created by public that PC,
and key certificate validation
procedures in RFC 3280 [n2]. The algorithm requires usage of the public 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.

Tuecke, et al. Standards Track [Page 11]

RFC 3820 X.509 Proxy Certificate Profile June 2004

o A compromised PC private key
of does NOT compromise the EEC and
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 EEC's subject distinguished name.

To meet user to go through the goal
usually cumbersome and time consuming process of verifying the proxy certificate, having the proxy
certificate path validation process verifies, among other things,
that EEC
with a prospective certification path (a sequence of n
certificates) satisfies new private key reissued by the following conditions:

(a) CA.

See Section 5 below for all x in {1, ..., n-1}, more discussion on how Proxy Certificates
relate to Attribute Certificates.

3. Certificate and Certificate Extensions Profile

This section defines the subject usage of X.509 certificate x is fields and
extensions in Proxy Certificates, and defines one new extension for
Proxy Certificate Information.

All Proxy Certificates MUST include the issuer of proxy certificate x+1 Proxy Certificate Information
(ProxyCertInfo) extension defined in this section and the extension
MUST be critical.

3.1. Issuer

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
distinguished name field.

The issuer field of certificate x+1 is a legal Proxy Certificate MUST contain the subject
distinguished name to have been issued by certificate x;

(b) certificate 1 is valid proxy
field of its Proxy Issuer.

If the Proxy Issuer certificate has the KeyUsage extension, the
Digital Signature bit MUST be asserted.

3.2. Issuer Alternative Name

The issuerAltName extension MUST NOT be present in a Proxy
Certificate.

3.3. Serial Number

The serial number of a Proxy Certificate (PC) SHOULD be unique
amongst all Proxy Certificates issued by the end
entity certificate whose information is given as input to the
proxy certificate path validation process;

(c) certificate n is the proxy certificate a particular Proxy Issuer.
However, a Proxy Issuer MAY use an approach to be validated; assigning serial
numbers that merely ensures a high probability of uniqueness.

Tuecke, et al. 20

Internet Draft Standards Track [Page 12]

RFC 3820 X.509 Proxy Certificate Profile December 2003

(d) for all x in {1, ..., n}, the certificate was valid at the
time in question; and

(e) for all certificates in the path with June 2004

For example, a pCPathLenConstraint
field, the 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 certificates in the path following that
certificate does not exceed the length specified in that field.

At this point there is no mechanism defined for revoking proxy
certificates.

4.1 Basic PC public key to assign a
serial number with a high probability of uniqueness.

3.4. Subject

The subject field of a Proxy Certificate Path Validation

This section presents MUST be the algorithm in four basic steps to mirror issuer field
(that is the description subject 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 Proxy Issuer) appended with a single
Common Name component.

The value of the path. Step (3) is
performed for 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 in to the path except same bearer,
the final
proxy certificate.

Certificate path validation as described in RFC 3280 MUST have been
done prior Proxy Issuer MAY choose to using use the same Common Name for both.
Examples of this algorithm to validate include Proxy Certificates for different uses (e.g.,
signing vs encryption) or the end entity
certificate. 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 algorithm then processes value MAY
be the proxy certificate
chain using same value used for the end entity certificate information produced by RFC
3280 path validation.

4.1.1 Inputs

This algorithm assumes serial number.

The result of this approach is that all subject names of Proxy
Certificates are derived from the following inputs name of the issuing EEC (it will be
the first part of the subject name appended with one or more CN
components) and are provided unique to each bearer.

3.5. Subject Alternative Name

The subjectAltName extension MUST NOT be present in a Proxy
Certificate.

3.6. Key Usage and Extended Key Usage

If the
path processing logic:

(a) information about the entity Proxy Issuer certificate already verified
using RFC 3280 path validation. This information includes:

(1) has a Key Usage extension, the end entity name,

(2)
Digital Signature bit MUST be asserted.

This document places no constraints on the working_public_key output from RFC 3280 path
validation,

(3) presence or contents of
the working_public_key_algorithm output from RFC 3280, key usage and extended key usage extension. However, section 4.2
explains what functions should be allowed a proxy certificate by a
relying party.

Tuecke, et al. 21

Internet Draft Standards Track [Page 13]

RFC 3820 X.509 Proxy Certificate Profile December 2003

(4) and the working_public_key_parameters output from RFC
3280 path validation.

(b) prospective proxy certificate path of length n.

(c) acceptable-pc-policy-language-set: A set of proxy
certificate policy languages understood by the policy evaluation
code. June 2004

3.7. Basic Constraints

The acceptable-pc-policy-language-set MAY contain cA field in the
special value id-ppl-anyLanguage (as basic constraints extension MUST NOT be TRUE.

3.8. The ProxyCertInfo Extension

A new extension, ProxyCertInfo, is defined in Appendix A) if
the path validation code should not check this subsection.
Presence of the proxy ProxyCertInfo extension indicates that a certificate
policy languages (typically because
is a Proxy Certificate and whether or not the set issuer of known the
certificate has placed any restrictions on its use.

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }

ProxyCertInfo ::= SEQUENCE {
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }

ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy
languages OCTET STRING OPTIONAL }

If a certificate is not known yet a Proxy Certificate, then the proxyCertInfo
extension MUST be present, and will this extension MUST be checked later in the
authorization process).

(d) marked as
critical.

If a certificate is not a Proxy Certificate, then the current date proxyCertInfo
extension MUST be absent.

The ProxyCertInfo extension consists of one required and time.

4.1.2 Initialization

This initialization phase establishes the following state variables
based upon the inputs:

(a) working_public_key_algorithm: the digital signature
algorithm used to verify two optional
fields, which are described in detail in the signature of a proxy certificate. following subsections.

3.8.1. pCPathLenConstraint

The working_public_key_algorithm is initialized from the input
information provided from RFC 3280 path validation.

(b) working_public_key: the public key used to verify pCPathLenConstraint field, if present, specifies the
signature maximum
depth of a proxy certificate. The working_public_key is
initialized from the input information provided from RFC 3280 path validation.

(c) working_public_key_parameters: parameters associated with
the current public key, of Proxy Certificates that may can be required signed by this
Proxy Certificate. A pCPathLenConstraint of 0 means that this
certificate MUST NOT be used to verify sign a
signature (depending upon Proxy Certificate. If the algorithm). The
proxy_issuer_public_key_parameters variable
pCPathLenConstraint field is initialized from
the input information provided from RFC 3280 path validation.

(d) working_issuer_name: the issuer distinguished name expected
in not present then the next maximum proxy certificate in the chain. The
working_issuer_name path
length is initialized to the distinguished name in
the end unlimited. End entity certificate validated by RFC 3280 certificates have unlimited maximum
proxy path
validation. lengths.

Tuecke, et al. 22

Internet Draft Standards Track [Page 14]

RFC 3820 X.509 Proxy Certificate Profile December 2003

(e) max_path_length: June 2004

3.8.2. proxyPolicy

The proxyPolicy field specifies a policy on the use of this integer
certificate for the purposes of authorization. Within the
proxyPolicy, the policy field is initialized an expression of policy, and the
policyLanguage field indicates the language in which the policy is
expressed.

The proxyPolicy field in the proxyCertInfo extension does not define
a policy language to n, 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
decremented essential for each proxy the PI that issues a certificate in with a proxyPolicy
field and the path. This value
may also be reduced by relying party that interprets that field to agree on
its meaning, the pcPathLenConstraint value policy language OID must correspond to a policy
language (including semantics), not just a policy grammar.

The policyLanguage field has two values of any
proxy certificate special importance,
defined in the chain.

(f) proxy_policy_list: Appendix A, that MUST be understood by all parties
accepting Proxy Certificates:

* id-ppl-inheritAll indicates that this list is empty to start and will be
filled in with the key usage extensions, extended key usage
extensions and an unrestricted proxy policies in the chain.

Upon completion of
that inherits all rights from the initialization steps, perform issuing PI. An unrestricted
proxy is a statement that the basic
certificate processing steps specified in 4.1.3.

4.1.3 Basic Proxy Certificate Processing

The basic path processing actions Issuer wishes to be performed for proxy
certificate i (for delegate all i in [1..n]) are listed below.

(a) Verify
of its authority to the basic certificate information. The bearer (i.e., to anyone who has that proxy
certificate
MUST satisfy each and can prove possession of the following:

(1) The certificate was signed with associated private
key). For purposes of authorization, this an unrestricted proxy
effectively impersonates the
working_public_key_algorithm using issuing PI.

* id-ppl-independent indicates that this is an independent proxy
that inherits no rights from the working_public_key and 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.

For either of the working_public_key_parameters.

(2) The certificate validity period includes policyLanguage values listed above, the current
time.

(3) The certificate issuer name is policy
field MUST NOT be present.

Other values for the working_issuer_name.

(4) The certificate subject name policyLanguage field indicates that this is the working_issuer_name
with a CN component appended.

(b) The
restricted proxy certificate MUST certification and have a ProxyCertInfo extension.
Process the extension as follows:

(1) If some other policy limiting
its ability to do proxying. In this case the pCPathLenConstraint policy field is MAY be
present in the
ProxyCertInfo field and the value it contains is less than
max_path_length, set max_path_length to its value.

(2) MUST contain information expressing the policy. If acceptable-pc-policy-language-set
the policy field is not id-ppl-
anyLanguage, present the OID policy MUST be implicit in the
value of the policyLanguage field MUST be
present itself. Authors of additional
policy languages are encouraged to publicly document their policy
language and list it in acceptable-pc-policy-language-set. the IANA registry (see Section 7).

Tuecke, et al. 23

Internet Draft Standards Track [Page 15]

RFC 3820 X.509 Proxy Certificate Profile December 2003

Proxy policies are used to limit the amount of authority delegated,
for example to assert that the proxy certificate subject name,
policyPolicy, key usage extension (if present) and extended key
usage extension (if present) must may be appended used only to
proxy_policy_list.

(d) Process other
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 extensions, as described 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 [n2]:

(1) Recognize and process any the PC's certificate path. In other critical extensions
present in words, the proxy certificate.

(2) Process any recognized non-critical extension present in relying
party MUST verify that the proxy certificate.

If either step (a), (b) or (d) fails, following three conditions are all met:

1) The relying party MUST know how to interpret the procedure terminates,
returning a failure indication proxy policy and an appropriate reason.
the request is allowed under that policy.

2) If i the Proxy Issuer is not equal to n, continue by performing an EEC then the preparatory
steps listed relying party's local
policies MUST authorize the request for the entity named in 4.1.4. the
EEC.

3) If i is equal to n, perform the wrap-up
steps listed in 4.1.5.

4.1.4 Preparation for next Proxy Certificate

(a) Verify max_path_length Issuer is greater than zero and decrement
max_path_length.

(b) Assign another PC, then one of the certificate subject name following MUST
be true:

a. The relying party's local policies authorize the Proxy Issuer
to working_issuer_name.

b. The Proxy Issuer inherits the right to
working_public_key.

(d) If perform the subjectPublicKeyInfo field request from
its issuer by means of its proxy policy. This must be verified
by verifying these three conditions on the certificate
contains an algorithm field with non-null parameters, assign Proxy Issuer in a
recursive manner.

If these conditions are not met, the relying party MUST either deny
authorization, or ignore the
parameters to PC and the working_public_key_parameters variable.

If whole certificate chain
including the subjectPublicKeyInfo field of EEC entirely when making its authorization decision
(i.e., make the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare same decision that it would have made had the PC and
it's certificate subjectPublicKey algorithm chain never been presented).

The relying party MAY impose additional restrictions as to the
working_public_key_algorithm. If the 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
subjectPublicKey algorithm and 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 working_public_key_algorithm bearer of a
PC are different, set the working_public_key_parameters to null.

(e) Assign union of the certificate subjectPublicKey algorithm rights granted to the
working_public_key_algorithm variable. PC identity and the

Tuecke, et al. 24

Internet Draft Standards Track [Page 16]

RFC 3820 X.509 Proxy Certificate Profile December 2003

(f) If a key usage extension is present, verify that June 2004

inherited rights. The inherited rights consist of the
digitalSignature bit is set.

If either check (a) or (f) fails, intersection
of the procedure terminates,
returning a failure indication rights granted to the PI identity intersected with the proxy
policy in the PC.

For example, imagine that Steve is authorized to read and an appropriate reason.

If (a) write files
A and (f) complete successfully, increment i B on a file server, and perform the
basic certificate processing specified in 4.1.3.

4.1.5 Wrap-up Procedures

(a) Assign that he uses his EEC to create a PC
that includes the certificate subject name policy that it can be used only to working_issuer_name.

(b) Assign read or write
files A and C. Then a trusted attribute authority grants an
Attribute Certificate granting the certificate subjectPublicKey PC the right to
working_public_key.

(c) If read file D. This
would make the subjectPublicKeyInfo field rights of the certificate
contains an algorithm field with non-null parameters, assign the
parameters PC equal to the proxy_issuer_public_key_parameters variable.

If the subjectPublicKeyInfo field union of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm rights
granted to the
proxy_issuer_public_key_algorithm. If the certificate
subjectPublicKey algorithm and PC identity (right to read file D) with the
proxy_issuer_public_key_algorithm are different, set
intersection of the
proxy_issuer_public_key_parameters rights granted to null.

(d) Assign Steve, the certificate subjectPublicKey algorithm PI, (right to the
proxy_issuer_public_key_algorithm variable.

4.1.6 Outputs

If path processing succeeds, the procedure terminates, returning a
success indication together read
files A and B) with final value of the
working_public_key, the working_public_key_algorithm, policy in the
working_public_key_parameters, PC (can only read files A and
C). This would mean the proxy_policy_list.

4.2 Using PC would have the Path Validation Algorithm

Each Proxy Certificate contains a ProxyCertInfo extension, which
always contains a policy language OID, following rights:

* Right to read file A: Steve has this right and may also contain a

Tuecke, et al. 25

Internet Draft X.509 Proxy Certificate Profile December 2003 he issued the PC
and his policy OCTET STRING. These policies serve grants this right to indicate the desire of
each issuer in the proxy certificate chain, starting with the EEC,
to delegate some subset of their rights PC.

* Right to the issued proxy
certificate. read file D: This chain of policies right is returned by the algorithm granted explicitly to the application. PC
by a trusted authority.

The application MAY make authorization decisions based on the
subject distinguished name of PC would NOT have the proxy certificate or following rights:

* Right to read file B: Although Steve has this right, it is
excluded by his policy on one of the proxy certificates in it's issuing chain or on PC.

* Right to read file C: Although Steve's policy grants this right,
he does not have this right himself.

In many cases, the EEC that
serves as relying party will not have enough information to
evaluate the root of above criteria at the chain. If an application chooses to use time that the subject distinguished name of certificate path is
validated. For example, if a proxy certificate in the
issuing chain or the EEC it MUST use the returned policies to
restrict the rights it grants is used to the proxy certificate. If the
application does not know how authenticate a
connection to parse some server, that certificate is typically validated
during that authentication step, before any policy in requests have been made
of the policy
chain it MUST not use, for server. In that case, the purposes of making relying party MUST either have some
authorization
decisions, mechanism in place that will check the subject distinguished name of proxy policies,
or reject any certificate in the
chain prior to the that contains proxy policies (or that has a
parent certificate in which the unrecognized policy
appears.

Application making authorization decisions based on that contains proxy policies).

4. Proxy Certificate Path Validation

Proxy Certification path processing verifies the contents of binding between the
proxy certificate key usage or extended key usage extensions
MUST examine the list of key usage, extended key usage distinguished name and proxy
policies resulting from proxy certificate public
key. The binding is limited by constraints which are specified in
the certificates which comprise the path validation and
determine inputs which are
specified by the effective key usage functions relying party.

Tuecke, et al. Standards Track [Page 17]

RFC 3820 X.509 Proxy Certificate Profile June 2004

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 proxy
certificate as follows:

* If 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 is 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 proxy policy of
id-ppl-independent or an time outside the certificate
validity period.

Valid paths begin with the end entity certificate, the effective
key usage functions of that certificate is as defined (EEC) that has
already been validated by the key
usage and extended public key usage extensions certificate validation
procedures in that certificate. RFC 3280 [n2]. The
key usage functionality of the issuer has no bearing on algorithm requires the
effective public key usage functionality.

* If a certificate is a proxy certificate with a policy other than
id-ppl-independent,
of the effective key usage EEC and extended key
usage functionality the EEC's subject distinguished name.

To meet the goal of verifying the proxy certificate is certificate, the intersection proxy
certificate path validation process verifies, among other things,
that a prospective certification path (a sequence of n certificates)
satisfies the functionality of those extensions following conditions:

(a) for all x in {1, ..., n-1}, the proxy subject of certificate and x is the effective key usage functionality
issuer of the proxy issuer.

Tuecke, et al. 26

Internet Draft X.509 Proxy Certificate Profile December 2003

5 Commentary

This section provides non-normative commentary on Proxy
Certificates.

5.1 Relationship to Attribute Certificates

An Attribute Certificate [i3] can be used to grant to one identity, certificate x+1 and 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 subject distinguished
name of certificate x+1 is a trusted Attribute
Authority (AA), which issues signed Attribute Certificates (AC),
each of which binds an identity legal subject distinguished name to a particular set of attributes.
Authorization decisions can then be made
have been issued by certificate x;

(b) certificate 1 is valid proxy certificate issued by combining information
from the authenticated End Entity Certificate providing end entity
certificate whose information is given as input to the
identity, with proxy
certificate path validation process;

(c) certificate n is the signed Attribute Certificates providing binding
of that identity proxy certificate to attributes.

There is clearly some overlap between be validated;

(d) for all x in {1, ..., n}, the capabilities provided by
Proxy Certificates and Attribute Certificates. However, certificate was valid at the
combination of time
in question; and

(e) for all certificates in the two approaches together provides path with a broader
spectrum pCPathLenConstraint
field, the number of solutions to authorization certificates in the path following that
certificate does not exceed the length specified in that field.

At this point there is no mechanism defined for revoking proxy
certificates.

Tuecke, et al. Standards Track [Page 18]

RFC 3820 X.509 based systems, than
either solution alone. Proxy Certificate Profile June 2004

4.1. Basic Proxy Certificate Path Validation

This section seeks presents the algorithm in four basic steps to clarify some mirror the
description of public key certificate path validation in RFC 3280:
(1) initialization, (2) basic proxy certificate processing, (3)
preparation for the
overlaps, differences, next proxy certificate, and synergies between Proxy Certificate (4) wrap-up. Steps
(1) and
Attribute Certificates.

5.1.1 Types of Attribute Authorities

For (4) are performed exactly once. Step (2) is performed for
all proxy certificates in the purposes of this discussion, Attribute Authorities, and path. Step (3) is performed for all
proxy certificates in the
uses of path except the Attribute Certificates that they produce, can be broken
down into two broad classes:

1) End entity AA: An End Entity final proxy certificate.

Certificate may be used path validation as described in RFC 3280 MUST have been
done prior to sign an
AC. This can be used, for example, using this algorithm to allow an 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.

4.1.1. Inputs

This algorithm assumes the following inputs are provided to
delegate some of its privileges to another entity.

2) Third party AA: A separate entity, aside from the path
processing logic:

(a) information about the entity certificate already verified using
RFC 3280 path validation. This information includes:

(1) the end entity
involved in an authenticated interaction, may sign ACs name,

(2) the working_public_key output from RFC 3280 path validation,

(3) the working_public_key_algorithm output from RFC 3280,

(4) and the working_public_key_parameters output from RFC 3280
path validation.

(b) prospective proxy certificate path of length 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 order
to bind Appendix A) if the authenticated identity with additional attributes,
such as role, group, etc. For example, when a client
authenticates with a server, path
validation code should not check the third party AA may provide an AC
that binds proxy certificate policy
languages (typically because the client identity to a particular group, which set of known policy languages is
not known yet and will be checked later in the
server then uses for authorization purposes.
process).

(d) the current date and time.

Tuecke, et al. 27

Internet Draft Standards Track [Page 19]

RFC 3820 X.509 Proxy Certificate Profile December 2003 June 2004

4.1.2. Initialization

This second type 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 Attribute Authority, a proxy certificate. The
working_public_key_algorithm is initialized from the third party AA, works
equally well with an EEC or input
information provided from RFC 3280 path validation.

(b) working_public_key: the public key used to verify the signature
of a PC. For example, unrestricted Proxy
Certificates can proxy certificate. The working_public_key is initialized
from the input information provided from RFC 3280 path
validation.

(c) working_public_key_parameters: parameters associated with the
current public key, that may be used required to delegate verify a signature
(depending upon the EEC's identity to various
other parties. Then when one of those other parties uses algorithm). The
proxy_issuer_public_key_parameters variable is initialized from
the PC to
authenticate with a service, that service will receive input information provided from RFC 3280 path validation.

(d) working_issuer_name: the EEC's
identity via issuer distinguished name expected in
the PC, and can apply any ACs that bind that identity next proxy certificate in the chain. The working_issuer_name
is initialized to attributes the distinguished name in order the end entity
certificate validated by RFC 3280 path validation.

(e) max_path_length: this integer is initialized to determine authorization rights.
Additionally PC with policies could n, is decremented
for each proxy certificate in the path. This value may also be used to selectively deny
reduced by the
binding pcPathLenConstraint value of ACs any proxy certificate
in the chain.

(f) proxy_policy_list: this list is empty to a particular proxy. An AC could also start and will be bound to
a particular PC using filled
in with the subject or issuer key usage extensions, extended key usage extensions
and serial number proxy policies in the chain.

Upon completion of the proxy certificate. There would appear initialization steps, perform the basic
certificate processing steps specified in 4.1.3.

4.1.3. Basic Proxy Certificate Processing

The basic path processing actions to be great synergies
between performed for proxy
certificate i (for all i in [1..n]) are listed below.

(a) Verify the basic certificate information. The certificate MUST
satisfy each of the following:

Tuecke, et al. Standards Track [Page 20]

RFC 3820 X.509 Proxy Certificate Profile June 2004

(1) The certificate was signed with the
working_public_key_algorithm using the use of Proxy Certificates working_public_key and Attribute Certificates
produced by third party Attribute Authorities.

However,
the uses of Attribute Certificates that are granted by working_public_key_parameters.

(2) The certificate validity period includes the
first type of Attribute Authority, current time.

(3) The certificate issuer name is the end entity AA, overlap
considerably working_issuer_name.

(4) The certificate subject name is the working_issuer_name with a
CN component appended.

(b) The proxy certificate MUST have a ProxyCertInfo extension.
Process the uses of Proxy Certificates extension as described in follows:

(1) If the previous sections. Such Attribute Certificates are generally
used for delegation of rights from one end entity to others, which
clearly overlaps with pCPathLenConstraint field is present in the stated purpose of Proxy Certificates,
namely single sign-on
ProxyCertInfo field and delegation.

5.1.2 Delegation Using Attribute Certificates

In the motivating example in Section 2, PCs are used to delegate
Steve's identity value it contains is less than
max_path_length, set max_path_length to its value.

(2) If acceptable-pc-policy-language-set is not id-ppl-
anyLanguage, 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 OID in the mass storage
system.

A solution to this example could also policyLanguage field MUST be cast using Attribute
Certificates that are signed by Steve's EEC, which grant to the
other entities
present in this example acceptable-pc-policy-language-set.

(c) The tuple containing the right certificate subject name, policyPolicy,
key usage extension (if present) and extended key usage extension
(if present) must be appended to perform various
operations on Steve's behalf. In this example, the reliable file
transfer service proxy_policy_list.

(d) Process other certificate extensions, as described in [n2]:

(1) Recognize and all the hosts involved process any other critical extensions present in file transfers,
the
starter program, proxy certificate.

(2) Process any recognized non-critical extension present in the agent,
proxy certificate.

If either step (a), (b) or (d) fails, the simulation jobs, procedure terminates,
returning a failure indication and the post-
processing job would each have their own EECs. Steve's EEC would
therefore issue ACs an appropriate reason.

If i is not equal to bind each of those other EEC identities n, continue by performing the preparatory steps
listed in 4.1.4. If i is equal to
attributes that grant n, perform the necessary privileges allow them to, wrap-up steps
listed in 4.1.5.

4.1.4. Preparation for
example, access next Proxy Certificate

(a) Verify max_path_length is greater than zero and decrement
max_path_length.

(b) Assign the mass storage system. certificate subject name to working_issuer_name.

Tuecke, et al. 28

Internet Draft Standards Track [Page 21]

RFC 3820 X.509 Proxy Certificate Profile December 2003

However, this AC based solution to delegation has some
disadvantages as compared to June 2004

* All protocols, authentication code, and identity based
authorization services must be modified certificate subjectPublicKey to understand ACs. With working_public_key.

(d) If the PC solution, protocols (e.g. TLS) likely need no
modification, authentication code needs minimal modification
(e.g. subjectPublicKeyInfo field of the certificate contains an
algorithm field with non-null parameters, assign the parameters
to perform PC aware path validation), and identity based
authorization services need minimal modification (e.g. possibly the working_public_key_parameters variable.

If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to find the EEC name
working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the working_public_key_algorithm
are different, set the working_public_key_parameters to check for any proxy policies).

* ACs need to be created by Steve's EEC, which bind attributes null.

(e) Assign the certificate subjectPublicKey algorithm to
each of the other identities involved in
working_public_key_algorithm variable.

(f) If a key usage extension is present, verify that the distributed
application (i.e.
digitalSignature bit is set.

If either check (a) or (f) fails, the agent, simulation jobs, procedure terminates, returning
a failure indication and an appropriate reason.

If (a) and (f) complete successfully, increment i and post- perform the
basic certificate processing job specified in 4.1.3.

4.1.5. Wrap-up Procedures

(a) Assign the file transfer service, certificate subject name to working_issuer_name.

(b) Assign the hosts transferring
files). This implies that Steve must know in advance which
other identities may be involved in this distributed
application, in order certificate subjectPublicKey to generate working_public_key.

(c) If the appropriate ACs which are
signed by Steve's ECC. On subjectPublicKeyInfo field of the other hand, certificate contains an
algorithm field with non-null parameters, assign the PC solution
allows for much more flexibility, since parties can further
delegate a PC without a priori knowledge by parameters
to the originating EEC.

There are many unexplored tradeoffs and implications in this
discussion of delegation. However, reasonable arguments can be
made in favor proxy_issuer_public_key_parameters variable.

If the subjectPublicKeyInfo field of either the certificate contains an AC based solution
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the
proxy_issuer_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
proxy_issuer_public_key_algorithm are different, set the
proxy_issuer_public_key_parameters to null.

(d) Assign the certificate subjectPublicKey algorithm to delegation or the
proxy_issuer_public_key_algorithm variable.

Tuecke, et al. Standards Track [Page 22]

RFC 3820 X.509 Proxy Certificate Profile June 2004

4.1.6. Outputs

If path processing succeeds, the procedure terminates, returning a PC
based solution to delegation. The choice
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.

4.2. Using the Path Validation Algorithm

Each Proxy Certificate contains a ProxyCertInfo extension, which approach should
be taken in
always contains a given instance policy language OID, and may depend on factors such as the
software that it needs also contain a policy
OCTET STRING. These policies serve to be integrated into, indicate the type desire of
delegation required, and religion.

5.1.3 Propagation each
issuer in the proxy certificate chain, starting with the EEC, to
delegate some subset of Authorization Information

One possible use their rights to the issued proxy certificate.
This chain of Proxy Certificates policies is returned by the algorithm to carry authorization
information associated with a particular identity. the
application.

The merits of placing application MAY make authorization information into End Entity
Certificates (also called a Public Key Certificate or PKC) have
been widely debated. For example, Section 1 decisions based on the subject
distinguished name of "An Internet
Attribute Certificate Profile for Authorization" [i3] states:

"Authorization information may be placed in a PKC extension or
placed in a separate attribute the proxy certificate (AC). The placement or on one of authorization information the proxy
certificates in PKCs is usually undesirable for

Tuecke, et al. 29

Internet Draft X.509 Proxy Certificate Profile December 2003

two reasons. First, authorization information often does not
have it's issuing chain or on the same lifetime EEC that serves as the binding
root of the chain. If an application chooses to use the subject
distinguished name of a proxy certificate in the identity and issuing chain or the
public key. When authorization information is placed in a PKC
extension,
EEC it MUST use the general result is returned policies to restrict the shortening of rights it
grants to the PKC
useful lifetime. Second, proxy certificate. If the PKC issuer is application does not usually
authoritative know
how to parse any policy in the policy chain it MUST not use, for the
purposes of making authorization information. This results decisions, the subject distinguished
name of any certificate in additional steps for the PKC issuer chain prior to obtain authorization
information from the authoritative source.

For these reasons, it is often better to separate authorization
information from certificate in
which the PKC. Yet, unrecognized policy appears.

Application making authorization information also
needs to be bound to an identity. An AC provides this binding;
it is simply a digitally signed (or certified) identity 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 set proxy policies
resulting from proxy certificate path validation and determine the
effective key usage functions of attributes."

Placing authorization information in a PC mitigates the first
undesirable property cited above. Since a PC has proxy certificate as follows:

* If a lifetime that certificate is mostly independent of (always shorter than) its signing EEC, a
PC becomes proxy certificate with a viable approach for carrying authorization information
for proxy policy of
id-ppl-independent or an end entity certificate, the effective key
usage functions of that certificate is as defined by the purpose of delegation. key usage
and extended key usage extensions in that certificate. The second undesirable property cited above is true. key
usage functionality of the issuer has no bearing on the effective
key usage functionality.

* If a third
party AA is authoritative, then using ACs issued by that third
party AA certificate 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 proxy certificate with a PC.

There is one case, however, that policy other than
id-ppl-independent, the above text does not consider.
When performing delegation, it is usually effective key usage and extended key usage
functionality of the EEC itself that proxy certificate is
authoritative (not the EEC issuer, or any third party AA). That
is, it is up to intersection of 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
functionality of those extensions in the
EEC seems a reasonable approach to disseminating such information.

5.1.4 proxy certificate and the
effective key usage functionality of the proxy issuer.

Tuecke, et al. Standards Track [Page 23]

RFC 3820 X.509 Proxy Certificate as Profile June 2004

5. Commentary

This section provides non-normative commentary on Proxy Certificates.

5.1. Relationship to Attribute Certificates

An Attribute Certificate Holder

In a system that employs both PCs and ACs, one [i3] can imagine the
utility of allowing a PC to be used to grant to one identity,
the holder of an AC. holder, some attribute such as a role, clearance level, or
alternative identity such as "charging identity" or "audit identity".
This would
allow for is accomplished by way of a particular delegated instance 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
given an attribute, rather than all delegated instances made by combining information from the
authenticated End Entity Certificate providing the identity, with the
signed Attribute Certificates providing binding of that identity being given to
attributes.

There is clearly some overlap between the attribute.

Tuecke, et al. 30

Internet Draft X.509 capabilities provided by
Proxy Certificate Profile December 2003 Certificates and Attribute Certificates. However, the issue
combination of how to specify a PC as the holder two approaches together provides a broader
spectrum of an AC
remains open. An AC could be bound solutions to a particular instance authorization in X.509 based systems, than
either solution alone. This section seeks to clarify some of a
PC using the unique subject name
overlaps, differences, and synergies between Proxy Certificate and
Attribute Certificates.

5.1.1. Types of Attribute Authorities

For the PC, or it's issuer and
serial number combination.

Unrestricted PCs issued by that PC would then inherit those ACs purposes of this discussion, Attribute Authorities, and
independent PCs would not. PCs issued with a policy would depend
on the policy as to whether or not they inherit
uses of the issuing PC's
ACs (and potentially which ACs Attribute Certificates that they inherit).

While an AC produce, 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 broken
down into two broad classes:

1) End entity AA: An End Entity Certificate may be used to define sign an extension to attribute
certificates that allows the attribute authority
AC. This can be used, for example, to state whether allow an issued AC is to apply only to the particular end entity to which it
is bound, or if it may apply
delegate some of its privileges to PCs issued by that another entity.

One issue that

2) Third party AA: A separate entity, aside from the end entity
involved in an AA authenticated interaction, may sign ACs in this circumstance would need order to be aware of
is that the PI of the PC that the AA bound
bind the AC to, could issue
another PC authenticated identity with the same name additional attributes, such
as the original PC to role, group, etc. For example, when a different
entity, effectively stealing client authenticates
with a server, the AC. This implies that an third party AA
issuing may provide an AC to a PC need to not only trust the entity holding the
PC, but the entity holding that binds the PC's issuer as well.

5.2 Kerberos 5 Tickets

The Kerberos Network Authentication Protocol (RFC 1510 [i8]) is
client identity to 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 5 tickets have informed many of the ideas surrounding
X.509 Proxy Certificates. For example, particular group, which 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 server then uses
for
single sign-on in a Kerberos based system. And just as authorization purposes.

This second type of Attribute Authority, the third party AA, works
equally well with an EEC or a TGT PC. For example, unrestricted Proxy
Certificates can be forwarded (i.e. delegated) used to another entity delegate the EEC's identity to allow for
proxying in a Kerberos based system, so can a various
other parties. Then when one of those other parties uses the PC can be delegated to allow for proxying in an X.509 PKI based system.

A major difference between
authenticate with a Kerberos TGT and an X.509 PC is service, that
while creation and delegation of a TGT requires service will receive the involvement of EEC's

Tuecke, et al. 31

Internet Draft Standards Track [Page 24]

RFC 3820 X.509 Proxy Certificate Profile December 2003

a third party (the Kerberos Domain Controller), a PC June 2004

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
unilaterally created without used to selectively deny the active involvement binding of ACs
to a third
party. That is, a user can directly create particular proxy. An AC could also be bound to a particular PC from an EEC for
single sign-on capability, without requiring communication with a
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. And an party Attribute Authorities.

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 a PC can the stated purpose of Proxy Certificates, namely single
sign-on and delegation.

5.1.2. Delegation Using Attribute Certificates

In the motivating example in Section 2, PCs are used to delegate
Steve's identity to the PC 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
another entity (i.e. by creating a new PC, signed by the first)
without requiring communication with a third party.

The method used by Kerberos implementations mass storage
system.

A solution to protect a TGT can this example could also be used cast using Attribute
Certificates that are signed by Steve's EEC, which grant to protect the private key of a PC. For other
entities in this example the right to perform various operations on
Steve's behalf. In this example, some
Unix implementations of Kerberos use standard Unix the reliable file system
security to protect a user's TGT from compromise. Similarly, transfer service
and all the
Globus Toolkit's Grid Security Infrastructure implementation of
Proxy Certificates protects a user's PC private key using this same
approach.

5.3 Examples of usage of Proxy Restrictions

This section gives some examples of Proxy Certificate usage 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.

However, this AC based solution to delegation has some examples of how disadvantages
as compared to the Proxy policy can PC based solution:

* All protocols, authentication code, and identity based
authorization services must be used modified to restrict Proxy
Certificates.

5.3.1 Example use of proxies without Restrictions

Steve wishes understand ACs. With
the PC solution, protocols (e.g., TLS) likely need no
modification, authentication code needs minimal modification
(e.g., to perform a third-party FTP transfer between two FTP
servers. Steve would use an existing PC to authenticate to both
servers aware path validation), and delegate a PC identity based
authorization services need minimal modification (e.g., possibly
to both hosts. He would inform each host
of find the unique subject EEC name of the PC given and to check for any proxy policies).

Tuecke, et al. Standards Track [Page 25]

RFC 3820 X.509 Proxy Certificate Profile June 2004

* ACs need to be created by Steve's EEC, which bind attributes to
each of the other host. When identities involved in the servers establish distributed
application (i.e., the data channel connection to each other,
they use these delegated credentials to perform authentication agent, simulation jobs, and
verify they are talking 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 correct entity appropriate ACs which are signed by checking the
result of Steve's
ECC. On the authentication matches other hand, the name as provided by Steve.

5.3.2 Example use of proxies with Restrictions

Steve wishes to PC solution allows for much more
flexibility, since parties can further delegate to a process PC without a
priori knowledge by the right originating 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 perform delegation or a
transfer PC based
solution to delegation. The choice of which approach should be taken
in a file from host H1 to host H2 given instance may depend on his behalf. Steve
would delegate a PC factors such as the software that
it needs to be integrated into, the process type of delegation required, and he would
other factors.

5.1.3. Propagation of Authorization Information

One possible use of 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.

The process then uses this restricted PC to authenticate Certificates is to servers
H1 and H2. carry authorization
information associated with a particular identity.

The process would also delegate merits of placing authorization information into End Entity
Certificates (also called a PC to both servers.

Tuecke, et al. 32 Public Key Certificate or PKC) have been
widely debated. For example, Section 1 of "An Internet Draft X.509 Proxy Attribute
Certificate Profile December 2003

Note that these delegated PCs would inherit the restrictions for Authorization" [i3] states:

"Authorization information may be placed in a PKC extension or
placed in a separate attribute certificate (AC). The placement of
their parents, though this
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not relevant to this example. As in have the example
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the previous Section, each host would be provided
with
general result is the unique name shortening of the PC given to PKC useful lifetime.
Second, the other server.

Now when PKC issuer is not usually authoritative for the process issues
authorization information. This results in additional steps for
the command PKC issuer to transfer obtain authorization information from the file F1 on
H1 and to F2 on H2,
authoritative source.

For these two servers perform an reasons, it is often better to separate authorization
check based on the restrictions in the PC that
information from the process used PKC. Yet, authorization information also
needs to
authenticate with them (in addition be bound to any local policy they have).
Namely H1 checks that the an identity. An AC provides this binding; it
is simply a digitally signed (or certified) identity and set of
attributes."

Tuecke, et al. Standards Track [Page 26]

RFC 3820 X.509 Proxy Certificate Profile June 2004

Placing authorization information in a PC gives the user mitigates the right to read F1
and H2 checks first
undesirable property cited above. Since a PC has a lifetime that the is
mostly independent of (always shorter than) its signing EEC, a 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
becomes a viable approach for carrying authorization information for
the previous Section. purpose of delegation.

The extra security provided second undesirable property cited above is true. If a third
party AA is authoritative, then using ACs issued by these restrictions is that now if
the PC delegated third party
AA is a natural approach to disseminating authorization information.
However, this is true whether the process identity being bound by Steve is stolen, its use is
greatly limited.

5.4 Delegation Tracing

A relying party accepting a Proxy Certificate may have these ACs
comes from an interest
in knowing which parties issued earlier Proxy Certificates in EEC (PKC), or from a PC.

There is one case, however, that the
certificate chain and to whom they delegated them. For example above text does not consider.
When performing delegation, it
may know is usually the EEC itself 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
authoritative (not the compromised service a relying EEC issuer, or any third party may wish to
disregard the chain.

A delegation tracing mechanism was considered by the authors as
additional information AA). That is,
it is up to be carried in the ProxyCertInfo
extension. However at this time agreement has not been reached as EEC to decide what this information should include so authorization rights it was left out of is willing
to grant to another party. In this
document, and will instead be considered in future revisions. The
debate mainly centers on whether the tracing situation, including such
authorization 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 into PCs that are generated by the proxy was actually acceptable EEC
seems a reasonable approach to it.

Tuecke, et al. 33

Internet Draft X.509 disseminating such information.

5.1.4. Proxy Certificate Profile December 2003

5.4.1 Site Information in Delegation Tracing as Attribute Certificate Holder

In some cases, it may be desirable to know a system that employs both PCs and ACs, one can imagine the hosts involved in
utility of allowing a
delegation transaction (for example, PC to be the holder of an AC. This would allow
for a relying party may wish particular delegated instance of an identity to
reject proxy certificates be given an
attribute, rather than all delegated instances of that were created on identity being
given the attribute.

However, the issue of how to specify a specific host or
domain). PC as the holder of an AC
remains open. An extension AC could be modified bound to include a particular instance of a PC
using the PA's unique subject name of the PC, or it's issuer and
Acceptor's IP addresses; however, IP addresses are typically easy
to spoof, serial
number combination.

Unrestricted PCs issued by that PC would then inherit those ACs and in some cases
independent PCs would not. PCs issued with a policy would depend on
the two parties policy as to a transaction may whether or not agree on they inherit the IP addresses being used (e.g., if issuing PC's ACs
(and potentially which ACs they inherit).

While an AC can be bound to one PC by the Acceptor is AA, how can the AA restrict
that PC from passing it on to a host that uses NAT, the Acceptor and the PA may disagree about
the Acceptor's IP address).

Another suggestion was, in those cases where domain information is
needed, subsequently delegated PC? One
possible solution would be to require define an extension to attribute
certificates that allows the subject names of all End Entities
involved (the Acceptor(s) and attribute authority to state whether an
issued AC is to apply only to the End Entity particular entity to which it is
bound, or if it may apply to PCs issued by that appears entity.

One issue that an AA in a PC's
certificate path) include domain information.

6 Security Considerations

In this Section we discuss security considerations related circumstance would need to the
use be aware of Proxy Certificates.

6.1 Compromise
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

Tuecke, et al. Standards Track [Page 27]

RFC 3820 X.509 Proxy Certificate

A Proxy Certificate is generally less secure than Profile June 2004

entity, effectively stealing the EEC that
issued it. AC. This is due implies that an AA issuing
an AC to a PC need to not only trust the fact that entity holding the private key PC, but
the entity holding the PC's issuer as well.

5.2. Kerberos 5 Tickets

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 5 tickets have informed many of the ideas surrounding X.509
Proxy Certificates. For example, the local creation of a short-lived
PC is
generally not protected as rigorously can be used to provide single sign-on in an X.509 PKI based
system, just as that of the EEC. For
example, the private key creation of a PC is often protected using only file
system security, short-lived TGT allows for single sign-on
in order a Kerberos based system. And just as a TGT can be forwarded
(i.e., delegated) to another entity to allow that for proxying in a
Kerberos based system, so can a PC to can be used delegated to allow for single
sign-on purposes. This makes the
proxying in an X.509 PKI based system.

A major difference between a Kerberos TGT and an X.509 PC more susceptible to
compromise.

However, is that
while creation and delegation of a TGT requires the risk involvement of a compromised
third party (Key Distribution Center), a PC is only can be unilaterally
created without the misuse active involvement of a
single user's privileges. Due to the PC path validation checks, third party. That is, a
user can directly create a PC cannot be used to sign from an EEC or PC for another user.

Further, single sign-on
capability, without requiring communication with a third party. And
an entity with a compromised PC can only be misused for the lifetime of delegate the PC to another entity (i.e., by
creating a new PC, and within the bound of the restriction policy carried signed by the PC. Therefore, one common way first) without requiring
communication with a third party.

The method used by Kerberos implementations to limit protect a TGT can also
be used to protect the misuse private key of a
compromised PC is to limit its validity period to no longer than is
needed, and/or PC. For example, some Unix
implementations of Kerberos use standard Unix file system security to include
protect a restriction policy in user's TGT from compromise. Similarly, the Globus
Toolkit's Grid Security Infrastructure implementation of Proxy
Certificates protects a user's PC that
limits the use private key using this same
approach.

5.3. Examples of usage of Proxy Restrictions

This section gives some examples of Proxy Certificate usage and some
examples of how the (compromised) PC. Proxy policy can be used to restrict Proxy
Certificates.

Tuecke, et al. 34

Internet Draft Standards Track [Page 28]

RFC 3820 X.509 Proxy Certificate Profile December 2003

In addition, if June 2004

5.3.1. Example use of proxies without Restrictions

Steve wishes to perform a third-party FTP transfer between two FTP
servers. Steve would use an existing PC is compromised, it does NOT compromise the EEC
that created the PC. This property is of great utility in
protecting the highly valuable, to authenticate to both
servers and hard delegate a PC to replace, public key both hosts. He would inform each host
of the EEC. In other words, the use unique subject name of Proxy Certificates the PC given to provide
single sign-on capabilities in an X.509 PKI environment can
actually increase the security of other host. When
the end entity certificates,
because creation and use of servers establish the PCs for user data channel connection to each other, they
use these delegated credentials to perform authentication limits
the exposure of the EEC private key and verify
they are talking to only the creation of correct entity by checking the
first level PC.

6.2 Restricting Proxy Certificates

The pCPathLenConstraint field result of the proxyCertInfo extension can be
used by an EEC to limit subsequent delegation of
authentication matches the PC. A service
may choose to only authorize a request if a valid PC can be
delegated to it. An example name as provided by Steve.

5.3.2. Example use of such as service is a job starter,
which may choose proxies with Restrictions

Steve wishes to reject a job start request if a valid PC cannot
be delegated delegate to it. By limiting a process the pCPathLenConstraint, an EEC
can ensure that right to perform a compromised PC transfer
of one job cannot be used a file from host H1 to start
additional jobs elsewhere.

An EEC or PC can limit what host H2 on his behalf. Steve would
delegate a new PC can be used for by turning off
bits in to the Key Usage process and Extended Key Usage extensions. Once a
key usage or extended key usage has been removed, he would use Proxy Policy to
restrict 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 delegated PC chains.

The EEC could use to two rights - the CRL Distribution Points extension and/or OCSP right to take read file F1
on host H1 and the responsibility of revoking PCs that it had issued,
if it felt that they were being misused.

6.3 Relying Party Trust of Proxy Certificates

The relying party that is going right to authorize some actions write file F2 on the
basis of host H2.

The process then uses this restricted PC to authenticate to servers
H1 and H2. The process would also delegate a PC will be aware to both servers.
Note that it has been presented 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 a PC,
and can determine the depth
unique name of the delegation and PC given to the time that other server.

Now when the
delegation took place. It may want process issues the command to use this information in
addition transfer the file F1 on H1
and to F2 on H2, these two servers perform an authorization check
based on the information from restrictions in 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.

Tuecke, et al. 35

Internet Draft X.509 Proxy Certificate Profile December 2003

The relying party should also be aware that since the process used to
authenticate with them (in addition to any local policy
restricting they have).
Namely H1 checks that 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 gives the policy of user the PC. Since there is
no mechanism in place right to enforce unique subject names of PCs, if an
issuer were two PCs with identical names read F1 and keys, but different
rights this could allow
H2 checks that the two PCs PC gives the user the right to be substituted for each
other in path validation and effect write F2. When
setting up the rights of a PC down data channel the
chain. Ultimately, this means servers would again verify the relying party places trust in names
resulting from the
entities that are acting as Proxy Issuers in authentication match the chain to behave
properly.

6.4 Protecting Against Denial of Service with Key Generation

As discussed names provided by Steve
as in Section 2.3, one of the motivations for Proxy
Certificates example in the previous Section.

The extra security provided by these restrictions is that now if the
PC delegated to allow for dynamic delegation between parties.
This delegation potentially requires, by the process by Steve is stolen, its use is greatly
limited.

5.4. Delegation Tracing

A relying party receiving the
delegation, the generation of accepting a new key pair Proxy Certificate may have an interest in
knowing which is a potentially
computationally expensive operation. Care should be taken by such parties issued earlier Proxy Certificates in the
certificate chain and to prevent another entity from performing whom they delegated them. For example it
may know that a denial of particular service attack by causing them to consume large amount of or resource
doing key generation.

A general guideline would always is known to perform authentication have been

Tuecke, et al. Standards Track [Page 29]

RFC 3820 X.509 Proxy Certificate Profile June 2004

compromised and if any part of a Proxy Certificate's chain was issued
to the
delegating compromised service a relying party may wish to prevent such attacks from being performed
anonymously. Another guideline would be disregard the
chain.

A delegation tracing mechanism was considered by the authors as
additional information to maintain some state be carried in the ProxyCertInfo extension.
However at this time agreement has not been reached as to
detect what this
information should include so it was left out of this document, and prevent such attacks.

6.5 Use
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 Proxy Certificates with the delegated proxy and a Central Repository

As discussed signed statement from the
receiver that the proxy was actually acceptable to it.

5.4.1. Site Information in Section 2.7, one potential use of Proxy
Certificates is Delegation Tracing

In some cases, it may be desirable to ease certificate management for end users by
storing know the EEC private keys and certificates hosts involved in a centrally
managed repository. When
delegation transaction (for example, a user needs relying party may wish to
reject proxy certificates that were created on a PKI credential, the user
can login specific host or
domain). An extension could be modified to include the repository using name/password, one time password,
etc. PA's and the repository would then delegate a PC
Acceptor's IP addresses; however, IP addresses are typically easy to
spoof, and in some cases the user with
proxy rights, but continue two parties to protect a transaction may not
agree on the EEC private key in IP addresses being used (e.g., if the
repository.

Care must be taken with this approach since compromise of Acceptor is on a
host that uses NAT, the
repository will potentially give Acceptor and the attacker access to PA may disagree about the long-
term private keys stored
Acceptor's IP address).

Another suggestion was, in the repository. It those cases where domain information is strongly
suggested that some form of hardware module be used
needed, to store require that the

Tuecke, et al. 36

Internet Draft X.509 Proxy Certificate Profile December 2003

long-term private keys, which will serve to help prevent their
direct threat though it may still allow subject names of all End Entities
involved (the Acceptor(s) and the End Entity that appears in a successful attacker PC's
certificate path) include domain information.

6. Security Considerations

In this Section we discuss security considerations related to
use the keys while use
of Proxy Certificates.

6.1. Compromise of a Proxy Certificate

A Proxy Certificate is generally less secure than the repository EEC that issued
it. This is compromised due to sign arbitrary
objects (including Proxy Certificates).

7 IANA Considerations

IANA should establish the fact that the private key of a registry for policy languages. Registration
under IETF space PC is by IETF standards action
generally not protected as described in [i9].
Private policy languages should be under organizational OIDs;
policy language authors are encouraged to list such languages in rigorously as that of the IANA registry, along with a pointer to EEC. For
example, the private key of a specification.

8 Normative References

[n1] Bradner, S., "Key words for use PC is often protected using only file
system security, in RFCs order to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[n2] Housley, R., W. Polk, W. Ford, and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile," RFC 3280, April 2002.

9 Informational References

[i1] Butler, R., D. Engert, I. Foster, C. Kesselman, and S.
Tuecke, "A National-Scale Authentication Infrastructure,"
IEEE Computer, vol. 33, pp. 60-66, 2000.
[i2] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0,"
RFC 2246, January 1999.
[i3] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization," RFC 3281, April
2002.
[i4] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A
Security Architecture allow that PC to be used for Computational Grids," presented
at Proceedings of single
sign-on purposes. This makes the 5th ACM Conference on Computer and
Communications Security, 1998.
[i5] Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy PC more susceptible to compromise.

However, the risk of a compromised PC is only the Grid: Enabling Scalable Virtual Organizations,"
International Journal misuse of Supercomputer Applications, 2001. 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.

Tuecke, et al. 37

Internet Draft Standards Track [Page 30]

RFC 3820 X.509 Proxy Certificate Profile December 2003

[i6] Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation
Protocol," Internet Draft draft-ietf-tls-delegation-00.txt,
2001
[i7] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)," RFC 1510, September 1993.
[i8] B. Clifford Neuman. "Proxy-Based Authorization and
Accounting June 2004

Further, a compromised PC can only be misused for Distributed Systems." In Proceedings the lifetime of the
13th International Conference on Distributed Computing
Systems, pages 283-291, May 1993.

[i9] Narten, T. and
PC, and H. Alvestrand. "Guidelines for Writing
an IANA Considerations Section in RFC," RFC 2434, October
1998.

10 Acknowledgments

We are pleased to acknowledge significant contributions to this
document within the bound of the restriction policy carried by David Chadwick, Ian Foster, Jarek Gawor, Carl
Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist.

We are grateful the PC.
Therefore, one common way to numerous colleagues for discussions on limit the
topics covered in this paper, in particular (in alphabetical order,
with apologies misuse of a compromised PC is
to anybody we've missed): Carlisle Adams, Joe
Bester, Randy Butler, Doug Engert, Keith Jackson, Steve Hanna, Russ
Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang,
Ellen McDermott, Clifford Neuman, Gene Tsudik.

We are also grateful limit its validity period to members no longer than is needed, and/or to
include a restriction policy in the PC that limits the use of the Global Grid Forum (GGF) Grid
Security Infrastructure working group (GSI-WG), and
(compromised) PC.

In addition, if a PC is compromised, it does NOT compromise the Internet
Engineering Task Force (IETF) Public-Key Infrastructure (X.509)
working group (PKIX) for feedback on this document. EEC
that created the PC. This work was supported property is of great utility in part by protecting
the Mathematical, Information, highly valuable, and Computational Sciences Division subprogram hard to replace, public key of the Office of
Advanced Scientific Computing Research, U.S. Department EEC. In
other words, the use of Energy,
under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by Proxy Certificates to provide single sign-on
capabilities in an X.509 PKI environment can actually increase the Defense
Advanced Research Projects Agency under contract N66001-96-C-8523;
by
security of the National Science Foundation; end entity certificates, because creation and by use of
the NASA Information
Power Grid project.

Tuecke, et al. 38

Internet Draft X.509 Proxy Certificate Profile December 2003

11 Contact Information

Steven Tuecke
Distributed Systems Laboratory
Mathematics and Computer Science Division
Argonne National Laboratory
Argonne, IL 60439
Phone: 630-252-8711
Email: tuecke@mcs.anl.gov

Von Welch
National Center PCs for Supercomputing Applications
University user authentication limits the exposure of Illinois
Email: vwelch@ncsa.uiuc.edu

Doug Engert
Argonne National Laboratory
Email: deengert@anl.gov

Laura Pearlman
University the EEC
private key to only the creation of Southern California, Information Sciences Institute
Email: laura@isi.edu

Mary Thompson
Lawrence Berkeley National Laboratory
Email: mrthompson@lbl.gov

12 Copyright Notice

6.2. Restricting Proxy Certificates

This document and translations pCPathLenConstraint field of the proxyCertInfo extension can be
used by an EEC to limit subsequent delegation of it the PC. A service
may choose to only authorize a request if a valid PC can be copied and furnished delegated
to
others, and derivative works 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 comment on or otherwise explain
it a compromised PC of one job cannot be used to start
additional jobs elsewhere.

An EEC or assist in its implementation may PC can limit what a new PC can be prepared, copied,
published and distributed, used for by turning off
bits in whole 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 part, without restriction a subsequent PC.
In other words, key usage can only be decreased in PC chains.

The EEC could use the CRL Distribution Points extension and/or OCSP
to take on the responsibility of any kind, provided revoking PCs that it had issued, if
it felt that they were being misused.

6.3. Relying Party Trust of Proxy Certificates

The relying party that is going to authorize some actions on the above copyright notice
basis of a PC will be aware that it has been presented with a PC, and this
paragraph are included on all such copies
can determine the depth of the delegation and derivative works.
However, this document itself the time that the
delegation took place. It may not be modified want to use this information in any way, such
as by removing
addition to the information from the copyright notice or references signing EEC. Thus a highly
secure resource might refuse to the Internet
Society accept a PC at all, or other Internet organizations, except as needed for the
purpose maybe only a
single level of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process delegation, etc.

Tuecke, et al. 39

Internet Draft Standards Track [Page 31]

RFC 3820 X.509 Proxy Certificate Profile December 2003

must be followed, or as required to translate it into languages
other than English. June 2004

The limited permissions granted above are perpetual and will not relying party should also be
revoked by aware that since the Internet Society or its successors or assigns.

This document and policy
restricting the information contained herein rights of a PC is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

13 Intellectual Property Statement

The IETF takes no position regarding the validity or scope intersection of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use policy of
all the technology described PCs in it's certificate chain, this document or means any change in the extent
certificate chain can effect the policy of the PC. Since there is no
mechanism in place to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort enforce unique subject names of PCs, if an
issuer were to identify any such rights. Information on
the IETF's procedures issue two PCs with respect identical names and keys, but
different rights, this could allow the two PCs to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available substituted for publication
each other in path validation and any assurances
of licenses to be made available, or effect the result rights of an attempt made
to obtain a general license or permission for PC down the use of such
proprietary rights by implementers or users of
chain. Ultimately, this specification
can be obtained from means the IETF Secretariat.

The IETF invites any interested relying party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to places trust in the IETF
Executive Director.

Tuecke, et al. 40

Internet Draft X.509 Proxy Certificate Profile December 2003

Appendix A. 1988 ASN.1 Module

PKIXproxy88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
proxy-cert-extns(25) }

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

-- IMPORTS NONE --

-- PKIX specific OIDs

id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

-- Locally defined OIDs

-- The proxy certificate extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }

-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }

--
entities that are acting as Proxy certificate policies languages defined Issuers in draft
id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }

-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }

ProxyCertPathLengthConstraint ::= INTEGER

Tuecke, et al. 41

Internet Draft X.509 the chain to behave
properly.

6.4. Protecting Against Denial of Service with Key Generation

As discussed in Section 2.3, one of the motivations for Proxy Certificate Profile December 2003

ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }

END

Appendix B. Change Log (To be removed prior
Certificates is to publication)

draft-ietf-pkix-impersonation-00 (February 2001)

Initial submission.

draft-ietf-pkix-proxy-00 (July 2001)

Renamed 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 "Proxy Certificate", prevent another entity from "Impersonation
Certificate", due performing a denial of service
attack by causing them to overwhelming feedback consume large amount of resource doing key
generation.

A general guideline would always to perform authentication of the
delegating party to prevent such attacks from IETF being performed
anonymously. Another guideline would be to maintain some state to
detect and GGF.

Added proxyRestriction field prevent such attacks.

6.5. Use of Proxy Certificates with a Central Repository

As discussed in Section 2.7, one potential use of Proxy Certificates
is to ProxyCertInfo extension.

Added delegationTrace field 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 ProxyCertInfo extension.

Updated the
repository using name/password, one time password, etc. and the
repository would then delegate a PC to agree the user with draft-ietf-pkix-part1-08.

draft-ietf-pkix-proxy-01 (August 2001)

Changes related proxy rights,
but continue to delegation tracing: removed delegationTrace
field from ProxyCertInfo extension, created DelegationTrace
extension, added and modified commentary sections related protect the EEC private key in the repository.

Care must be taken with this approach since compromise of the
repository will potentially give the attacker access to
delegation tracing.

Added issuerCertHash the long-term
private keys stored in the repository. It is strongly suggested that
some form of hardware module be used to proxyCertInfo extension and 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 path
validation section.

draft-ietf-pkix-proxy-02 (February 2002)

Draft for Global Grid Forum 4 (Toronto)

Added concept of proxy group.

Updated section on keyCertSign bit keys while the
repository is compromised to reflect draft-pkix-new-
part1-07. sign arbitrary objects (including Proxy
Certificates).

Tuecke, et al. 42

Internet Draft Standards Track [Page 32]

RFC 3820 X.509 Proxy Certificate Profile December 2003

draft-ietf-pkix-proxy-02 (March 2002)

Draft June 2004

7. IANA Considerations

IANA has established a registry for IETF.

Same version number (-02) policy languages. Registration
under IETF space is by IETF standards action as February 2002 for GGF4 but with
changes.

Globally changed "Proxy Authority" to "Proxy Issuer".

Changed example described in Motivations section to use a reliable file
transfer service.

An EEC issuing a PC must have a non-empty subject name.

Proxy subject names are now non-empty and contain a sequence of
proxy identifiers. Changes to path validation to reflect this.

subjectAltNames and issuerAltNames [i8].
Private policy languages should be under organizational OIDs; policy
language authors are now not present PCs.

Renamed issuerCertHash encouraged to issuerCertSignature and similarly list such languages in the IANA
registry, along with
it's contents.

Added consideration a pointer to path validation a specification.

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

8. References

8.1. Normative References

[n1] Bradner, S., "Key words for PC's with an infinite
path length (i.e. no pCPathLenConstraint).

draft-ggf-gsi-proxy-03 (July 2002)

Draft for GGF-5 (Edinburgh)

Renamed to draft-ggf-gsi-proxy-03

Changed formatting to meet GGF document format requirements.

Added GGF copyright notice use in RFCs to beginning.

Removed Internet Draft language from status section Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[n2] Housley, R., Polk, W., Ford, W., and replaced
with current text.

Added Copyright D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.

8.2. Informative References

[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.

[i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.

[i3] Farrell, S. and Intellectual Property sections (12 & 13)

Removed Section 3.7.2: DelegationTrace Extension. Renumbered
subsections 3.7.1.x to 3.7.x. Removed subsections in Section 6

Tuecke, et al. 43 R. Housley, "An Internet Draft X.509 Proxy Attribute
Certificate Profile December 2003

related to this extension and replaced with one subsection
discussing it.

Proxy Certificate subject name is now issuer name concatenated
with a single unique component. Functional changes to Sections 3 for Authorization", RFC 3281, April 2002.

[i4] Foster, I., Kesselman, C., Tsudik, G., and 4 to reflect this, numerous changes throughout the document
including removal S. Tuecke, "A
Security Architecture for Computational Grids", presented at
Proceedings of section 6.3.

Removed text stating the Proxy subject name should only be used
for path validation to leave door open for use with attribute
certificates.

Rewrote 2.6 so reflect that PCs now have unique identities.

Added new section 2.5 (Motivation for Unique Proxy Name)

Removed sections 2.7 (Proxy Issuer, not Certificate Authority) 5th ACM Conference on Computer and 2.8 (Names versus Subjects)

Renamed proxyRestrictions to proxyPolicy
Communications Security, 1998.

[i5] Foster, I., Kesselman, C., and made it a required
field. Numerous changes elsewhere to reflect this change.

Removed issuerCertSignature since it is no longer needed since
PCs now have unique names.

Added previously deleted (accidentally?) text in 6.1
(keyCertSign Bit commentary).

Cleaned up pCPathLenConstraint checking in section 4 by adding
the max_pc_path_length variable.

Removed S. Tuecke, "The Anatomy of the proxyGroup field to make document restriction policy
agnostic.

Added structure to Section 7 (Security Considerations) and added
some text about a relying party trusting all issuers in a PC
chain.

Removed sections 6.1
Grid: Enabling Scalable Virtual Organizations", International
Journal of Supercomputer Applications, 2001.

[i6] Kohl, J. and 6.2 from commentary since the PKIX
draft is now an C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC and won't be changed.

Moved text from 6.3 to 3.9.4 and removed section 6.3. 1510, September 1993.

Tuecke, et al. 44

Internet Draft Standards Track [Page 33]

RFC 3820 X.509 Proxy Certificate Profile December 2003

Moved 6.4 to end of Commentary section.

Moved section 5 (Relationship to attribute certificate to be
first section June 2004

[i7] Neuman, B. Clifford, "Proxy-Based Authorization and
Accounting for Distributed Systems", In Proceedings of commentary).
Changed intro to commentary the
13th International Conference on Distributed Computing
Systems, pages 283-291, May 1993.

[i8] Narten, T. and added text H. Alvestrand. "Guidelines for Writing an IANA
Considerations Section in RFC", RFC 2434, October 1998.

9. Acknowledgments

We are pleased to beginning of
section 2 acknowledge significant contributions to indicate that these two sections this
document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman,
Sam Meder, Jim Schaad, and Frank Siebenlist.

We are non-normative.

Changed text in 2.7 grateful to indicate ease of integration with
existing authorization systems is true only in numerous colleagues for discussions on the case of
impersonation PCs.

Added text to new section 5.1.4 topics
covered in this paper, in particular (in alphabetical order, with
apologies to indicate that binding ACs 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
PCs indicates a trust members of the PI.

Removed Global Grid Forum (GGF) Grid
Security Infrastructure working group (GSI-WG), and the pC bit - any certificate with a proxyCertInfo
extensions is now a PC.

draft-ggf-gsi-proxy-04 (August 2002)

Minor non-normative editorial corrections.

draft-ietf-pkix-proxy-03 (October 2002)

Name change Internet
Engineering Task Force (IETF) Public-Key Infrastructure (X.509)
working group (PKIX) for attempted inclusion as a PKIX WG document. Based feedback on draft-ggf-gsi-proxy-04 with changes listed below.
Changed reference from "draft update to RFC 2459" to RFC 3280.

draft-ietf-pkix-proxy-04 (February 2003)

Rewrote section 4, Path Validation, to be additions to RFC 3280
path validation instead this document.

This work was supported in part by the Mathematical, Information, and
Computational Sciences Division subprogram of changes.

Added Appendix A with ASN.1 module.

Added oids for Impersonation 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 Independent policy languages to
section 3.9.3.

In section 3.6: keyusage extension in a proxy certificate only
has to be marked critical if marked critical in by the issuer's
certificate. Previously it always had to be marked critical.

draft-ietf-pkix-proxy-05 (April 2003) NASA Information Power
Grid project.

Tuecke, et al. 45

Internet Draft Standards Track [Page 34]

RFC 3820 X.509 Proxy Certificate Profile December 2003

Removed version field from ProxyCertInfo extension

Restrictions on contents of key usage and extended key usage
removed and placed as burden to relying party(4.2 and 3.6).

Path validation (4.1.3) now outputs proxy_policy_list as a list
of tuples containing subject name, policy oid, policy field, key
usage extension and extended key usage extension

Number of fixes to ASN module from Jim Schaad.

Changes policy language OID name from "id-ppl-impersonation" to
"id-ppl-inheritall".

Fixed discrepancy between June 2004

Appendix A. 1988 ASN.1 module and 3.9.2: id-ppl-
independent and id-ppl-inheritall now refer to the whole OID.

Clarified that a Module

PKIXproxy88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
proxy-cert-extns(25) }

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

-- IMPORTS NONE --

-- PKIX specific OIDs

id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

-- Locally defined OIDs

-- The proxy issuer must have digitalSignature
asserted if its certificate includes the keyUsage extension.

Accepted text from David Chadwick globally getting rid of the
term "impersonation" and replacing with "proxying".

Reformatted document to be less indented and be more in line
with other IDs.

Numerous clarifications to draft based on Jim Schaad's comments.
Effected sections: 3, 3.1, 3.4, 3.7, 3.9.3, 4, 5.4.1

Expanded PKI acronym extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }

-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }

-- Proxy certificate policies languages defined in abstract
id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }

-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }

ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }

END

Tuecke, et al. Standards Track [Page 35]

RFC 3820 X.509 Proxy Certificate Profile June 2004

Authors' Addresses

Steven Tuecke
Distributed Systems Laboratory
Mathematics and section 2.

Shorten title Computer Science Division
Argonne National Laboratory
Argonne, IL 60439

Phone: 630-252-8711
EMail: tuecke@mcs.anl.gov

Von Welch
National Center for Supercomputing Applications
University of section 4.2 to allow it to fit in table Illinois

EMail: vwelch@ncsa.uiuc.edu

Doug Engert
Argonne National Laboratory

EMail: deengert@anl.gov

Laura Pearlman
University of
contents.

draft-ietf-pkix-proxy-06 (May 2003)

Renamed "id-ppl-inheritall" to "id-ppl-inheritAll" (capitalizing
the "a") for consistency.

In section 4, renamed "acceptable-pc-policy-set" to "acceptable-
pc-policy-language-set" for clarity. Southern California, Information Sciences Institute

EMail: laura@isi.edu

Mary Thompson
Lawrence Berkeley National Laboratory

EMail: mrthompson@lbl.gov

Tuecke, et al. 46

Internet Draft Standards Track [Page 36]

RFC 3820 X.509 Proxy Certificate Profile December 2003

In section 4, renamed "any-policy" to "id-ppl-anyLanguage" for
clarity.

Added an OID for id-ppl-anyLanguage June 2004

Full Copyright Statement

Clarified text in 4.1.3 (c).

Clarified Proxy Issuer definition the rights, licenses and restrictions contained in 2.1.

Changed "MUST not be present" to "MUST be absent" second to last
paragraph of section 3.8.

Removed OID definitions from 3.8.2 BCP 78, and added pointer to Appendix
A.

draft-ietf-pkix-proxy-07 (July 2003)

Non-normative change: Split references into normative
except as set forth therein, the authors retain all their rights.

This document and
informative.

Non-normative change: Moved change log to appendix B.

Non-normative change: Reduced author count to 5. Added
significant contributors list to acknowledgments.

draft-ietf-pkix-proxy-08 (August 2003)

Correction to 4.1.3: Failure of step(d) also causes process
termination.

Deleted following sentence from 3.8.2 since it no longer
pertains: "Note that this verification MUST take place
regardless 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 whether any
Intellectual Property Rights or not the PC itself contains a policy, as other PCs in the signing chain MAY contain conditions rights that MUST might be verified."

Clarification claimed to
pertain to the implementation or use of the technology described in 3.8.2: "interpret
this document or the policy" 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 "interpret identify any such rights. Information
on the
proxy policy"

Clarified text procedures with respect to rights in 3.8.1 regarding EECs.

draft-ietf-pkix-proxy-09 (November 2003)

Tuecke, et al. 47

Internet Draft X.509 Proxy Certificate Profile December 2003

Corrected object identifier for proxy cert extension RFC documents can be
found in 3.8

Improved phrasing of conditions 2 BCP 78 and 3 in 3.8.2

Improved phrasing BCP 79.

Copies of (e) in 4 IPR disclosures made to make clear that the IETF Secretariat and any proxy
certificate can limit length
assurances of path.

Minor editorial changes in 4.1.1, 4.2, 5.1.3, 6.1

Added reference licenses to RFC 3280 in 4.1.3 step (d).

draft-ietf-pkix-proxy-10 (December 2003)

Minor corrections in 3.8.2, 4.1.5, and non-normative references.

Marked Appendix B as "To be removed before publication"

Updated contact information and institution made available, or the result of an
attempt made to obtain a general license or permission for Von Welch.

Added Section 7, IANA Considerations, and non-normative
reference 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.

The IETF invites any interested party to RFC 2434.

Section 3.8.1: Correction "If 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 proxyCertInfo extension is not
present..." changed information to "If the pCPathLenConstraint field is not
present..."

Section 3.8.2: Added encouragement IETF at ietf-
ipr@ietf.org.

Acknowledgement

Funding for authors to publicly
specific and list their policy languages with IANA.

Added sections 6.4 and 6.5 to Security Considerations. the RFC Editor function is currently provided by the
Internet Society.

Tuecke, et al. 48 Standards Track [Page 37]

----