WDIFF

draft-ietf-pkix-proxy-01.txt --> draft-ietf-pkix-proxy-02.txt

Internet Draft S. Tuecke
Document: draft-ietf-pkix-proxy-01.txt draft-ietf-pkix-proxy-02.txt D. Engert
I. Foster
ANL
V. Welch
U. Chicago
M. Thompson
LBNL
L. Pearlman
C. Kesselman
USC/ISI
Expires: August 2002 February 2002 August 2001

Internet X.509 Public Key Infrastructure
Proxy Certificate Profile

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, 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 and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

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

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

Abstract

This document forms a certificate profile for Proxy Certificates,
based on X.509 PKI certificates as defined in draft-ietf-pkix-new-
part1-08.txt
part1-12.txt (the draft update to RFC 2459), 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 impersonation within a PKI
based authentication system.

Tuecke, et. al. Expires February 2002 1
Internet Draft X.509 Proxy Certificate Profile August 2001 March 2002

Table of Contents

Internet X.509 Public Key Infrastructure Proxy Certificate Profile.1
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1 Introduction....................................................3 Introduction...................................................4
2 Overview of Approach............................................4 Approach...........................................5
2.1 Terminology...................................................4 Terminology..................................................5
2.2 Background....................................................4 Background...................................................5
2.3 Motivation for Impersonation..................................5 Impersonation.................................6
2.4 Motivation for Proxy Restrictions............................8
2.5 Motivation for Proxy Groups..................................8
2.6 Description Of Approach.......................................7
2.5 Approach......................................9
2.7 Proxy Authority, Issuer, not Certificate Authority....................8
2.6 Authority.....................10
2.8 Names Versus Subjects.........................................9
2.7 Subjects.......................................11
2.9 Features Of This Approach....................................10 Approach...................................11
3 Certificate and Certificate Extensions Profile.................11 Profile................13
3.1 Issuer & Issuer Alternative Name.............................11 Name............................13
3.2 Serial Number...............................................13
3.3 Subject & Subject Alternative Name...........................11
3.3 Key Usage....................................................12 Name..........................13
3.4 Extended Key Usage...........................................12 Usage...................................................14
3.5 Basic Constraints............................................13 Extended Key Usage..........................................14
3.6 Basic Constraints...........................................15
3.7 Proxy Certificate Information................................13
3.6.1 Information...............................15
3.7.1 The ProxyCertInfo Extension................................13
3.6.2 Extension................................15
3.7.2 The DelegationTrace Extension..............................16 Extension..............................19
4 Certificate Path Validation....................................18 Validation...................................21
5 Relationship to Attribute Certificates.........................21 Certificates........................24
5.1 Types of Attribute Authorities...............................21 Authorities..............................25
5.2 Delegation Using Attribute Certificates......................22 Certificates.....................25
5.3 Propagation of Authorization Information.....................23 Information....................26
5.4 Proxy Certificate as Attribute Certificate Holder............24 Holder...........27
6 Commentary.....................................................24 Commentary....................................................27
6.1 keyCertSign Bit in the Key Usage Basic Extension.............24 Extension............27
6.2 nonRepudiate Bit in the Key Usage Basic Extension............24 Extension...........28
6.3 Subject Name of a Proxy Certificate..........................24
6.4 Carrying Along the End Entity Subject........................25
6.5 Subject.......................28
6.4 Specifying Proxy Restrictions................................26
6.6 Restrictions...............................29
6.5 Proxy Restrictions vs. Proxy Rights..........................26
6.7 Rights.........................29
6.6 Site Information in Delegation Tracing.......................27
6.8 Tracing......................29
6.7 Delegation Tracing vs. Usage Tracing.........................27
6.9 Tracing........................30
6.8 Contents of X509AcceptorInfo.................................28
6.10 X509AcceptorInfo................................30
6.9 Certificate Policies Extension.............................28
6.11 Extension..............................31
6.10 Kerberos 5 Tickets.........................................28 Tickets.........................................31
6.11 Examples of usage of Proxy Groups and Restrictions.........32
6.11.1 Example One: Use of proxies without Groups or Restrictions32
6.11.2 Example Two: Use of proxies with Groups..................32
6.11.3 Example Three: Use of proxies with Groups and Restrictions33
7 Security Considerations........................................29 Considerations.......................................33
8 References.....................................................30 References....................................................34
9 Acknowledgments................................................31 Acknowledgments...............................................35
10 Change Log...................................................31 Log..................................................35
11 Contact Information..........................................32 Information.........................................37

Tuecke, et. al. Expires February 2002 2
Internet Draft X.509 Proxy Certificate Profile August 2001 March 2002

Tuecke, et. al. Expires February 2002 3
Internet Draft X.509 Proxy Certificate Profile March 2002

1 Introduction

Use of a proxy credential for impersonation is a common technique
used in security systems to allow entity A to grant to another
entity B the right for B to authenticate with others as if it were
A. In other words, entity B is impersonating entity A. This
document forms a certificate profile for Proxy Certificates, based
on the draft update to RFC 2459, "Internet X.509 Public Key
Infrastructure Certificate and CRL Profile" [7].

In addition to simple, unrestricted impersonation, this profile
defines a framework for carrying restriction policies in Proxy
Certificates, thus allowing a restriction of the rights an
impersonating entity is given. Further, when delegating a Proxy
Certificate from one entity to another, this profile defines
information that can be optionally included in a Proxy Certificate
to allow for tracing of the delegation path.

Section 2 provides an 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 Authority, Issuer, as distinct from a Certificate Authority, to describe
how end entity signing of a Proxy Certificate is different from end
entity signing of another end entity certificate, and therefore why
this approach does not violate the end entity signing restrictions
contained in the X.509 keyCertSign field of the keyUsage extension.
It then continues with discussions of how subject names are used by
this impersonation 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. One Two new
certificate extensions, Proxy Certificate Information, is Information and Delegation
Trace, are introduced.

Section 4 defines path validation rules for Proxy Certificates.

Section 5 discusses the relationship of Proxy Certificates to
Attribute Certificates.

Section 6 provides commentary on various design choices, open
issues, related work, and future directions.

Section 7 discusses security considerations relating to Proxy
Certificates.

Section 8 contains the references.

Section 9 contains acknowledgements.

Tuecke, et. al. Expires February 2002 3 4
Internet Draft X.509 Proxy Certificate Profile August 2001 March 2002

Section 10 contains a log of changes made in each version of this
draft.

Section 11 contains contact information for the authors.

This document was written under the auspices of the Global Grid
Forum Grid Security Infrastructure Working Group. For more
information on this and other related work, see
http://www.gridforum.org/security.

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

2 Overview of Approach

The goal of this specification is to develop a X.509 Proxy
Certificate profile, to facilitate their use within Internet
applications for those communities wishing to make use of restricted
impersonation within an X.509 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 [7].

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

* PA: PI: A "Proxy Authority" Issuer" is the issuer of End Entity Certificate or Proxy
Certificate that issued a Proxy Certificate, as defined below.

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

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

2.2 Background

Computational and Data "Grids" have emerged as a common approach to
constructing dynamic, inter-domain, distributed computing
environments. As explained in [6], large research and development
efforts starting around 1995 have focused on the question of what

Tuecke, et. al. Expires February 2002 4 5
Internet Draft X.509 Proxy Certificate Profile August 2001 March 2002

protocols, services, and APIs are required for effective,
coordinated use of resources in these Grid environments.

In 1997, the Globus Project (www.globus.org) introduced the Grid
Security Infrastructure (GSI) [5]. 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 [3], 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 [2].
GSI has emerged as the dominant security solution used by Grid
efforts worldwide.

This experience with GSI has proven the viability of impersonation
as a basis for authentication and 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 impersonation.
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 Impersonation

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

Steve is an engineer, who wants to run use a set reliable file transfer
service to manage the movement of simulation jobs on
idle workstations a number of large files around
between various hosts on his company's Intranet based Intranet-based Grid. From his
laptop he wants to invoke submit a number of transfer requests to the jobs,
service, and then have an agent process
running on his desktop workstation monitor the jobs files transferred while he is
traveling to a conference. As the jobs complete, offline. The
transfer service may queue the agent should
automatically archive requests for some time (e.g. until
after hours or a period of low resource usage) before initiating the results
transfers. The transfer service will then, for each file, connect to
each of the company's mass storage
system, source and after all the jobs are complete it should run destination hosts, and instruct them initiate
a post-
processing job which summarizes the simulation results data connection directly from all of the archived data sets. source to the destination in
order to transfer the file. Later, Steve will reconnect to the agent
service to
get verify the results for inclusion in a report. transfers succeeded. 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 variety of
places:

* Steve needs to be able to mutually authenticate with several
remote workstations to start the simulation jobs.

* Steve needs to be able to mutually authenticate with his desktop
workstation remote
file transfer service to start submit the agent running. transfer request.

* That agent The file transfer service needs to be delegated the rights to
mutually authenticate with the various workstations, hosts involved directly in
the file transfer, in order to monitor initiate the progress file transfer.

* The source and destination hosts of a particular transfer must be
able to mutual authenticate with each other, to ensure the simulations. file

Tuecke, et. al. Expires February 2002 5 6
Internet Draft X.509 Proxy Certificate Profile August 2001

* As simulations complete, the agent needs to move the resulting
data from the workstations to the company's mass storage system.
In order to perform this move efficiently, it needs March 2002

is being transferred to
orchestrate a third party data transfer directly between the
workstation and the mass storage system. This requires mutual
authentication between the agent and the workstations and mass
storage system, as well as mutual authentication between the
workstations and from the mass storage system.

* The agent needs to start the post-processing job, which must be
delegated rights to mutually authenticate with the mass storage
system in order to retrieve the data. proper parties.

* When Steve later reconnects his laptop to the network, a program
running on the laptop must mutually authenticate with the agent file
transfer service in order to retrieve check the summary result of results. the transfers.

Impersonation 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 start submit all of the
simulation jobs and file
transfer requests to the remote agent. transfer service. 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 agent file
transfer service needs to be able to authenticate on Steve's
behalf with the various
workstations source and the mass storage system, destination hosts, and must in turn
delegate rights to the post-processing job to those hosts so that they can authenticate on
Steve's behalf with the mass storage system.
each other.

Impersonation can be used to secure all of these interactions:

* Impersonation allows for the private key stored on the smartcard
to be accessed just once, in order to create the necessary
impersonation credential, which allows the starter client program to
impersonate Steve (that is, authenticate as Steve) when starting
submitting the various jobs and requests to the agent. transfer service. Access to the
smartcard and Steve's password is not required after the initial
creation of the impersonation credential.

* The starter client program on the laptop can delegate to the agent file
transfer service the right to impersonate Steve. This, in turn,
allows the agent service to authenticate to the workstations hosts as if it were
Steve in order to start the simulation jobs, and to the mass storage system to
archive the data as if it were Steve. file transfers.

* When the agent starts transfer service authenticates to hosts to start the post-processing job,
file transfer, the agent service can delegate to it the hosts the right to
impersonate Steve. This allows the
post-processing job to authenticate as Steve to the mass storage

Tuecke, et. al. Expires February 2002 6
Internet Draft X.509 Proxy Certificate Profile August 2001

system so that each pair of hosts involved in order to gain access a file
transfer can mutually authenticate to ensure the data sets. file is securely
transferred.

* When the laptop reconnects to the agent file transfer service to get verify
the final results, transfers succeeded, it can perform mutual authentication.
The agent will use its
delegated impersonation credential in this interaction. The
laptop may laptop may use a newly generated impersonation credential,
which is just created anew using the smartcard.

This scenario, and others similar to it, is already being built
today within the Grid community. The Grid Security Infrastructure's
single sign-on and delegation capabilities, built on X.509 Proxy

Tuecke, et. al. Expires February 2002 7
Internet Draft X.509 Proxy Certificate Profile March 2002

Certificates, are being employed to provide authentication services
to these applications.

2.4 Motivation for Proxy Restrictions

One concern that arises in such a scenario is what happens if one of
the machines a machine that has been given
delegated the right to impersonate Steve 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 impersonation. For example, the machine running the post-processing job reliable
file transfer service in the above example might only be given the
right to impersonate Steve for the purpose of reading the
simulation output source
files from and writing the mass storage system. destination files. Therefore, if that host file
transfer service is compromised, raw simulation data cannot be changed on the mass storage system, new jobs attacker cannot be started, modify source
files, cannot create or modify other files to which Steve has
access, cannot start jobs on behalf of Steve, etc.

While this example may seem somewhat contrived, similar applications
are already being built today within All that an
attacker would be able to do is read the Grid community. The Grid
Security Infrastructure's single sign-on specific files to which the
file transfer service has been delegated read access, and delegation
capabilities, built on X.509 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.

2.5 Motivation for Proxy Certificates, are being employed Groups

A user will often wish to provide authentication services delegate authority to these applications.

2.4 Description Of Approach

This document defines an X.509 "Proxy Certificate" many tasks running on
his or "PC" her behalf, which may in turn delegate authority to subtasks,
and so forth. These tasks will then use the delegated credentials to
authenticate to each other for purposes of control, synchronization,
data transfer, etc. However, the user may wish to limit potential
interactions between subsets of these tasks, so as a
means to mitigate the
potential effects of providing for impersonation accidental or malicious misuse of the delegated
credentials. For example, one group of tasks performing a
distributed computation should be able to securely interact with an X.509 PKI based
authentication system.

A Proxy Certificate is an X.509 public key certificate each
other using their delegated credentials from the user, but should not
be able to interact with tasks involved in an unrelated file transfer
of the
following properties:

1) It is signed by either same user. Thus, if an X.509 End Entity Certificate (EEC), or
by another PC.

2) It can sign only another PC.

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

4) It has no distinct identity attacker compromises one of its own. After a PC is used for
authentication, the identity that is used for authorization is
that tasks
of the EEC distributed computation, only that signed the PC. distributed computation can
be affected. The PC effectively inherits attacker would not be able to use the subject or subjectAltName compromised
credential from its signing EEC.

5) It contains a new X.509 extension the distributed computation to identify attack the file
transfer.

While it as is in theory possible to implement this functionality using
Proxy Restrictions, the complexity of interactions of processes in a PC
task often makes enumerating a list of restrictions cumbersome and
potentially impossible beforehand due to
place restrictions on the PC. This new extension, along with
other X.509 fields and extensions, are used to enable proper path
validation and use of the PC.

The process lack of creating a PC complete knowledge.
A solution is as follows: to allow delegated proxy credentials to be assigned to
groups, and then limit interactions between processes based on these
proxy groups.

Tuecke, et. al. Expires February 2002 7 8
Internet Draft X.509 Proxy Certificate Profile August 2001

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

2) That key pair is used to create March 2002

For example, in the example in section 2.3, a request for host involved in
transferring a Proxy Certificate
that conforms single file needs to be able to securely interact with
the profile described other host involved in this document.

3) A Proxy Certificate, signed by the private key of transfer. However, the EEC or by
another PC, is created host does not
need to, and hence should not be able to, interact with other hosts
involved in response to other transfers. By putting the request. During this
process, proxies delegated to
each pair of hosts involved in a transfer into their own unique
group, the PC request transfer service is verified able to limit these hosts to only be
able to interact with each other. Thus, an attacker who is able to
gain access to ensure that the requested
PC delegated credential on one of these hosts is valid (e.g. it only
able to affect that one transfer, but is not prevented from interfering
with other transfers by that same user.

2.6 Description Of Approach

This document defines an EEC, the PC fields are
appropriately set, etc).

When a PC is created X.509 "Proxy Certificate" or "PC" as part of a delegation from entity
means of providing for restricted impersonation within an X.509 PKI
based authentication system.

A to entity
B, this process is modified by performing steps #1 and #2 within
entity B, then passing the PC request from entity B to entity A over Proxy Certificate is an authenticated, integrity checked channel, then entity A performs
step #3 and passes 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 back to entity B. (Note: There is a
related draft that describes how this delegation approach can be
incorporated into referred to as the TLS protocol [8].)

Path validation Proxy Issuer
(PI).

2) It can sign only another PC.

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

4) It has no distinct identity of its own. After a PC is very similar to normal path validation,
with a few additional checks to ensure, used for example, proper PC
signing constraints. In order to make
authentication, the appropriate PC(s) and
EEC available identity that is used for path validation, authorization is
that of the authentication protocol using EEC that signed the PC. The PC (e.g. TLS) may pass effectively inherits
the entire subject and/or subjectAltName from its signing EEC.

5) It contains a new X.509 extension to identify it as a PC and EEC chain as part of to
place restrictions on the authentication protocol.

2.5 Proxy Authority, not Certificate Authority

A common initial reaction against use of the approach described in this
document is, "You PC. This new extension,
along with other X.509 fields and extensions, are using used to enable
proper path validation and use of the end entity certificate (EEC) as a
CA!" However, this is not the case. To understand why, one must
first understand what a CA does.

In issuing an EEC, a CA performs two primary functions:

1) Naming: PC.

The CA assigns process of creating a (generally unique) "Name" to the end
entity to which it issues an EEC. This Name PC is contained in the
subject or subjectAltName field of the issued EEC.

2) Key to Name binding: By singing an EEC with the CA's as follows:

1) A new public and private key,
the CA key pair is providing a means to allow an authenticating party to
verify that the holder of a particular private generated.

2) That key should be
associated with (bound to) pair is used to create a particular Name.

In addition, request for a CA usually has an associated Registration Authority,
which performs the checks necessary Proxy Certificate
that conforms to bind the Name to profile described in this document.

3) A Proxy Certificate, signed by the real
world entity (e.g. person, computer, etc) that private key of the EEC or by
another PC, is created in response to be the bearer
of that Name.

The reason for doing all of request. During this
process, the PC request is verified to allow for authorization
decisions to be made, based at least in part on these CA issued
Names. In other words, after the public key authentication
operation has determined ensure that the Name of requested
PC is valid (e.g. it is not an EEC, the authenticating party, then PC fields are
appropriately set, etc).

Tuecke, et. al. Expires February 2002 8 9
Internet Draft X.509 Proxy Certificate Profile August 2001

that Name can be used March 2002

When a PC is created as the basis for deciding what the entity is
allowed to do. (Note: Attribute certificates are discussed below.)

The critical difference between using an EEC to sign a Proxy
Certificate, versus using an EEC to sign another EEC, is that a
Proxy Certificate does NOT define a new Name. Rather, part of a Proxy
Certificate inherits the name delegation from the EEC that signs it. The next
section describes entity A to entity
B, this inheritance in more detail.

In effect, process is modified by performing steps #1 and #2 within
entity B, then passing the PC simply provides another route to validating the
Key request from entity B to Name binding that the CA has established with entity A over
an EEC. authenticated, integrity checked channel, then entity A performs
step #3 and passes the PC
allow an alternate Key' back to bind entity B.

Path validation of a PC is very similar to the same Name, optionally with
restrictions, normal path validation,
with this Key' a few additional checks to Name binding vouched ensure, for by the
holder of example, proper PC
signing constraints. In order to make the appropriate PC(s) and
EEC private key. This allows entity A to give to
entity B available for path validation, the ability to establish this binding, authentication protocol using
the PC (e.g. TLS) may pass the entire PC and thus allows B to
establish itself EEC chain as a proper bearer part of A's Name.

For this reason, we use the term "Proxy Authority", rather than
"Certificate Authority", to refer to
the issuer of a Proxy
Certificates. A authentication protocol.

2.7 Proxy Authority does Issuer, not perform the Naming
function of a Certificate Authority, but rather just a Key to Name
binding.

2.6 Names Versus Subjects

In X.509 certificates, the subject (or subjectAltName) is used for
two distinct purposes:

1) In an End Entity Certificate, the subject is the Name that Authority

A common initial reaction against the CA
has issued, as approach described in this
document is, "You are using the previous section. This Name end entity certificate (EEC) as a
CA!" However, this is
typically used for authorization purposes.

2) not the case. To understand why, one must
first understand what a CA does.

In issuing an EEC, a CA Certificate, performs two primary functions:

1) Naming: The CA assigns a (generally unique) "Name" to the subject end
entity to which it issues an EEC. This Name is also used for path validation.
That is, the issuer field contained in an EEC or CA Certificate must match the
subject or subjectAltName field of a CA Certificate, in order for the signing
path issued EEC.

2) Key to be established.

As stated previously, a PC does not have its own Name, but rather it
inherits its Name from its signing EEC (or more accurately, from the binding: By singing an EEC that signed with the first PC in CA's private key,
the PC chain). In practice what
this means CA is providing a means to allow an authenticating party to
verify that the subject field holder of a PC is only used for
purpose #2. The only purpose of the subject field of particular private key should be
associated with (bound to) a PC is particular Name.

In addition, a CA usually has an associated Registration Authority,
which performs the checks necessary to
establish bind the signing path Name to the real
world entity (e.g. person, computer, etc) that eventually leads is to an EEC. be the bearer
of that Name.

The implication reason for doing all of this is that after a PC is used to allow for
authentication, the PC subject should not authorization
decisions to be used for authorization.
Instead, made, based at least in part on these CA issued
Names. In other words, after the PC signing chain should be followed to find public key authentication
operation has determined the EEC
that signed this PC chain, and Name of the subject from authenticating party, then
that EEC should Name can be used as the identity (or Name) basis for authorization purposes.

To discourage mistakes in this area, this deciding what the entity is
allowed to do. (Note: Attribute certificates are discussed below.)

The critical difference between using an EEC to sign a Proxy
Certificate, versus using an EEC to sign another EEC, is that a
Proxy Certificate profile
defines does NOT define a new Name. Rather, a Proxy
Certificate inherits the name from the EEC that signs it. The next
section describes this inheritance in more detail.

In effect, the PC subject (actually its subjectAltName) is just a
pseudo-randomly generated string. Further, simply provides another route to validating the subject
Key to Name binding that the CA has established with an EEC. A PC
allow an alternate Key' to bind to the same Name, optionally with
restrictions, with this Key' to Name binding vouched for by the
holder of the EEC private key. This allows entity A to give to

Tuecke, et. al. Expires February 2002 9 10
Internet Draft X.509 Proxy Certificate Profile August 2001

is not maintained anywhere in the PC, which forces March 2002

entity B the
authenticating party ability to properly retrieve establish this binding, and thus allows B to
establish itself as a proper bearer of A's Name.

For this reason, we use the subject from term "Proxy Issuer", rather than
"Certificate Authority", to refer to the EEC.

2.7 Features Of This Approach

Using issuer of a Proxy Certificates to
Certificates. A Proxy Issuer does not perform delegation has several features
that make it attractive:

* Ease the Naming function
of integration

* Because a PC requires only Certificate Authority, but rather just a minimal change Key to path validation,
it Name binding.

2.8 Names Versus Subjects

In X.509 certificates, the subject (or subjectAltName) is very easy to incorporate support used for Proxy Certificates
into existing X.509 based software. For example, SSL/TLS
requires no protocol changes to support authentication using a
PC, and only small changes to support delegation of a PC [8].
Further,
two distinct purposes:

1) In an SSL/TLS implementation requires only minor changes
to support PC path validation, and to retrieve End Entity Certificate, the
authenticated subject of is the signing EEC instead of Name that the subject
of CA
has issued, as described in the PC.

* Many existing previous section. This Name is
typically used for authorization systems use purposes.

2) In a CA Certificate, the X.509 subject name
as is also used for path validation.
That is, the basis issuer field in an EEC or CA Certificate must match
the subject field of a CA Certificate, in order for access control. Proxy Certificates require no
change the signing
path to such authorization systems, since be established.

As stated previously, a PC does not have its own Name, but rather it
inherits its
name Name from the EEC its signing EEC (or more accurately, from the
EEC that signed it.

* Ease the first PC in the PC chain). In practice what
this means is that the subject field of use

* Using a PC is only used for single sign-on helps make X.509 PKI authentication
easier
purpose #2. The only purpose of the subject field of a PC is to use, by allowing users
establish the signing path that eventually leads to "login" once and then
perform various operations securely.

* For many users, properly managing their own EEC private key an EEC.

The implication of this is
a nuisance at best, and a security risk at worst. One option
easily enabled with that after a PC is used for
authentication, the PC subject should not be used for authorization.
Instead, the PC signing chain should be followed to manage find the EEC private keys
that signed this PC chain, and
certificates in a centrally managed repository. When a user
needs a PKI credential, the user can login to subject from that EEC should be
used as the repository
using name/password, one time password, etc. Then identity (or Name) for authorization purposes.

To discourage mistakes in this area, this Proxy Certificate profile
defines that the
repository can delegate a PC to subject is just a set of one or more unique
identifiers. Further, the user, but continue to
protect subject of the EEC private key is not maintained
anywhere in the repository.

* Protection of private keys

* By using PC, which forces the remote delegation approach outlined above, entity
A can delegate a PC authenticating party to entity B, without entity B ever seeing
properly retrieve the private key of entity A, and without entity A ever seeing
the private key of subject from the newly delegated PC held by entity B. In
other words, private keys never need EEC.

2.9 Features Of This Approach

Using Proxy Certificates to be shared or
communicated by the entities participating in a perform delegation of a
PC. has several features
that make it attractive:

* When implementing single sign-on, using Ease of integration

. Because a PC helps protect the
private key of the EEC, because requires only a minimal change to path
validation, it minimizes the exposure and
use of that private key. is very easy to incorporate support for Proxy
Certificates into existing X.509 based software. For example, when an EEC private key
is password protected on disk, the password
SSL/TLS requires no protocol changes to support authentication
using a PC, and unencrypted only small changes to support delegation of a
PC [8]. Further, an SSL/TLS implementation requires only

Tuecke, et. al. Expires February 2002 10 11
Internet Draft X.509 Proxy Certificate Profile August 2001

private key need only be available during the creation of the
PC. That March 2002

minor changes to support PC can then be used for path validation, and to retrieve
the remainder authenticated subject of its valid
lifetime, without requiring access to the signing EEC password or
private key. Similarly, when instead of the EEC private key lives on a
smartcard,
subject of the smartcard need only be present in PC.

. Many existing authorization systems use the machine
during X.509 subject name
as the creation of basis for access control. Proxy Certificates require
no change to such authorization systems, since a PC inherits
its name from the PC. EEC that signed it.

* Limiting consequences Ease of a compromised use

. Using PC for single sign-on helps make X.509 PKI
authentication easier to use, by allowing users to "login"
once and then perform various operations securely.

. For many users, properly managing their own EEC private key

* is
a nuisance at best, and a security risk at worst. One option
easily enabled with a PC is to manage the EEC private keys and
certificates in a centrally managed repository. When creating a PC, user
needs a PKI credential, the PA user can limit login to the validity period of repository
using name/password, one time password, etc. Then the
PC,
repository can delegate a PC to the depth of user, but continue to
protect the PC path that can be created by that PC,
and EEC private key usage in the repository.

* Protection of private keys

. By using the PC and its descendents. Further, fine
grained restriction policies remote delegation approach outlined above, entity
A can be carried by delegate a PC to even
further restrict entity B, without entity B ever seeing
the operations that can be performed using private key of entity A, and without entity A ever seeing
the
PC. This permits private key of the PA newly delegated PC held by entity B.
In other words, private keys never need to limit any damage that could be done shared or
communicated by the bearer entities participating in a delegation of the PC, either accidentally or maliciously.

* A compromised
a PC.

. When implementing single sign-on, using a PC helps protect the
private key does NOT compromise of the EEC EEC, because it minimizes the exposure and
use of that private key. This makes a short term, or For example, when an otherwise
restricted PC attractive for EEC private key
is password protected on disk, the password and unencrypted
private key need only be available during the creation of the
PC. That PC can then be used for the remainder of its valid
lifetime, without requiring access to the EEC password or
private key. Similarly, when the EEC private key lives on a
smartcard, the smartcard need only be present in the machine
during the creation of the PC.

* 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 by that
PC, and key usage of the PC and its descendents. Further,
fine-grained restriction policies can be carried by a PC to
even further restrict the operations that can be performed
using the PC, and a set of PCs can be assigned to a proxy
group to limit interactions between that group and others.

Tuecke, et. al. Expires February 2002 12
Internet Draft X.509 Proxy Certificate Profile March 2002

These restrictions permit the PI to limit any damage that
could be done by the bearer of the PC, either accidentally or
maliciously.

. A compromised PC private key does NOT compromise the EEC
private key. This makes a short term, or an otherwise
restricted PC attractive for day-to-day use, since a
compromised PC does not require the user to go through the
usually cumbersome and time consuming process of having the
EEC with a new private key reissued by the CA.

See Section 5 below for more discussion on how Proxy Certificates
relate to Attribute Certificates.

3 Certificate and Certificate Extensions Profile

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

3.1 Issuer & Issuer Alternative Name

The Proxy Authority (i.e. the issuer) Issuer of a Proxy Certificate MUST be either an End Entity
Certificate, or another Proxy Certificate.

If the

An EEC acting as a Proxy Authority Certificate has Issuer must have a non-empty subject field,
then the field.

The issuer field of the a Proxy Certificate MUST contain the subject
field of the it�s Proxy Issuer.

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

Otherwise, if the

3.2 Serial Number

The serial number of a Proxy Authority Certificate has an empty subject
field, but non-empty subjectAltName, then the issuer field of the
Proxy Certificate MUST SHOULD be unique amongst
all Proxy Certificates issued by a particular Proxy Issuer.
However, a Proxy Issuer MAY use an empty sequence, the issuerAltName MUST
be the subjectAltName approach to assigning serial
numbers that merely ensures a high probability of uniqueness.

For example, a PI MAY use a sequentially assigned integer or a UUID
to assign a unique serial number to a PC it issues. Or a PI MAY use
a SHA-1 hash of the Proxy Authority Certificate, and the
issueAltName MUST be critical.

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

3.3 Subject & Subject Alternative Name

The subject field of a Proxy Certificate MUST be a sequence of one
or more proxy identifiers. A proxy identifier is a Common Name. The
value of the Common Name SHOULD be unique amongst all Proxy
Certificates issued by a particular Proxy Issuer. However, the
Proxy Issuer MAY use an empty sequence. approach to assigning Common Name values
that merely ensures a high probability of uniqueness. This value MAY
be the same value used for the serial number.

Tuecke, et. al. Expires February 2002 11 13
Internet Draft X.509 Proxy Certificate Profile August 2001

The subjectAltName extension March 2002

If the Proxy Issuer of a PC is an EEC, the subject field MUST be a
single proxy identifier.

If the Proxy Certificate Issuer of a PC is another PC, the subject field MUST be an
otherName, using
the impersonationCertName OID (?) and an IA5String
(?) containing concatenation of the name subject field of the Proxy Certificate. Issuer, with a
proxy identifier unique to the PC.

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

The subjectAltName subject of a Proxy Certificate SHOULD only be used for path
validation. As such, the string chosen for the subjectAltName
of a Proxy Certificate is arbitrary, but SHOULD be (statistically)
unique in order to enable path validation.

3.3

3.4 Key Usage

If the issuer certificate includes the keyUsage extension, then the
Proxy Certificate MUST include a keyUsage extension, which MAY
further restrict the issuer's keyUsage.

If the issuer certificate does not include a keyUsage extension,
then the Proxy Certificate MAY include a keyUsage extension to
restrict the key usage of the Proxy Certificate.

The keyUsage extension MUST be critical.

If the keyUsage extension is present in a Proxy Certificate, it must
conform to the following restrictions:

The keyCertSign bit MUST NOT be asserted.

The following restriction applies to each of these bits:
digitalSignature, nonRepudiate, keyEncipherment,
dataEncipherment, keyAgreement, cRLSign, encipherOnly,
decipherOnly. If this bit in the issuer certificate is not
asserted, then this bit in the Proxy Certificate MUST NOT be
asserted. If this bit in the issuer certificate is asserted, or
if the issuer certificate does not include a keyUsage extension,
then this bit in the Proxy Certificate MAY be either asserted or
not asserted.

See the commentary in section 6 for more information on the
keyCertSign and nonRepudiate bits.

3.4

3.5 Extended Key Usage

If the issuer certificate includes the extKeyUsage extension, then:

The Proxy Certificate MUST include an extKeyUsage extension.

Any OID that is contained in the Proxy Certificate's extKeyUsage
extension MUST be present in the issuer certificate's extKeyUsage
extension.

Tuecke, et. al. Expires February 2002 14
Internet Draft X.509 Proxy Certificate Profile March 2002

The Proxy Certificate's extKeyUsage extension MAY omit any OID
that is present in the issuer certificate's extKeyUsage.

Tuecke, et. al. Expires February 2002 12
Internet Draft X.509 Proxy Certificate Profile August 2001

If the issuer certificate's extKeyUsage extension is critical,
then the Proxy Certificate's extKeyUsage MUST be critical.

If the issuer certificate's extKeyUsage extension is not
critical, then the Proxy Certificate's extKeyUsage MAY be
critical or non-critical.

If the issuer certificate does not include the extKeyUsage
extension, then the Proxy Certificate MAY include a an extKeyUsage
extension to restrict the key usage of the Proxy Certificate. In
this case, the extKeyUsage extension MAY be critical or non-
critical.

3.5

3.6 Basic Constraints

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

3.6

3.7 Proxy Certificate Information

Two new extensions, ProxyCertInfo and DelegationTracing, are defined
in the following subsections

3.6.1

3.7.1 The ProxyCertInfo Extension

The ProxyCertInfo extension indicates whether or not a certificate
is a Proxy Certificate and whether or not the issuer of the
certificate has placed any restrictions on its use.

id-ce-proxy-cert-info OBJECT IDENTIFIER ::= { id-ce ?? }

ProxyCertInfo ::= SEQUENCE {
version INTEGER (0..MAX),
pC BOOLEAN DEFAULT TRUE,
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyRestriction ProxyRestriction OPTIONAL,
issuerCertHash Hash
proxyGroup ProxyGroup OPTIONAL,
issuerCertSignature Signature OPTIONAL }

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

Hash

Signature ::= SEQUENCE {
hashAlgorithm
signatureAlgorithm AlgorithmIdentifier,
hashValue
SignatureValue BIT STRING }

ProxyGroup :: = SEQUENCE {
proxyGroupName OCTET STRING,
proxyGroupAttached BOOLEAN DEFAULT TRUE }

Tuecke, et. al. Expires February 2002 15
Internet Draft X.509 Proxy Certificate Profile March 2002

If a certificate is a Proxy Certificate, then the proxyCertInfo
extension MUST be present, the pC field MUST be TRUE, and this
extension MUST be marked as critical.

Otherwise the extension MAY be marked as critical.

A Proxy Certificate MUST NOT be used to sign an End Entity
Certificate or a CA Certificate.

If a certificate is not a Proxy Certificate, then the proxyCertInfo
extension MAY be present, and MAY appear as a critical or non-

Tuecke, et. al. Expires February 2002 13
Internet Draft X.509 Proxy Certificate Profile August 2001
critical extension. In this case, if this extension is present,
then the pC field MUST be FALSE.

If any of the pcPathLenConstraint, proxyRestricition, or proxyGroup
fields are present and non-empty then this extension MUST be marked
as critical, regardless if the certificate is a Proxy Certificate or
not.

The ProxyCertInfo extension consists of one required and four
optional fields, which are described in detail in the following
subsections.

3.6.1.1

3.7.1.1 version

The version this draft this PC conforms to. Currently this value
MUST be 1. Future drafts may change this. If a proxy certificate
contains a version that is unknown to a relying party the relying
party must disregard the PC and it�s chain when making authorization
decisions.

3.7.1.2 pC

As described above, the pC field indicates whether or not the
certificate is a proxy certificate: if the certificate is a proxy
certificate, the pC field MUST be TRUE; otherwise, the pC field MUST
be FALSE.

3.6.1.2

3.7.1.3 pCPathLenConstraint

The pCPathLenConstraint field, if present, specifies the maximum
depth of the path of Proxy Certificates that can be signed by this
End Entity Certificate or Proxy Certificate. A pCPathLenConstraint
of 0 means that this certificate MUST not NOT be used to sign a Proxy
Certificate. If the proxyCertInfo extension is not present, or if
the pCPathLenConstraint is not present, then the proxy path length
is unlimited.

3.6.1.3

3.7.1.4 proxyRestriction

The proxyRestriction field, if present, specifies restrictions on
the use of this certificate. If the certificate is not a Proxy
Certificate (i.e, if the pC this field is FALSE), then present the
proxyRestriction field
proxyCertInfo extension MUST NOT be present. marked as critical.

Tuecke, et. al. Expires February 2002 16
Internet Draft X.509 Proxy Certificate Profile March 2002

An unrestricted proxy is a statement that the PA Proxy Issuer wishes to
delegate all its authority to the bearer (i.e., to anyone who has
that proxy certificate and proof of can prove possession of the associated
private key). Proxy restrictions are used to limit the amount of
authority delegated, for example to assert that the proxy
certificate may be used only to make requests to a specific server,
or only to authorize specific operations on specific resources.

Within the proxyRestriction, the policy field is an expression of
policy, and the policyLanguage field indicates the language in which
the policy is expressed.

Proxy restrictions impose additional requirements on the relying
party, because only the relying party is in a position to ensure
that those restrictions are met. When making an authorization
decision based on a proxy certificate, it is the relying party's
responsibility to verify that the requested authority is compatible
with all restrictions in the PC's certificate path. In other words,
the relying party MUST verify that the following three conditions
are met:

1) If the PC includes a proxy restriction, then the relying party
knows how to interpret the policy expressed in the PC's
restriction, and the request is allowed under that policy.

Tuecke, et. al. Expires February 2002 14
Internet Draft X.509 Proxy Certificate Profile August 2001

2) If the PA Proxy Issuer is an EEC, then the relying party's local
policies authorize the request for the entity named in the EEC.

3) If the PA Proxy Issuer is another PC, then conditions (1), (2), and
(3) are met for the PA. PI.

If these conditions are not met, the relying party MUST either deny
authorization or ignore the PC and the whole certificate chain
including the EEC entirely when making its authorization decision
(i.e., make the same decision that it would have made had the PC and
it�s certificate chain never been presented). Note that this
verification MUST take place regardless of whether or not the PC
itself contains restrictions, as other PCs in the signing chain may
contain conditions that must be verified.

The relying party MAY impose additional restrictions as to what
proxy certificates it accepts. For example, a relying party may
choose to reject all proxy certificates, or to accept only those
proxy certificates that include delegation tracing information, or
to accept proxy certificates only for certain operations, etc.

The rights granted to the bearer of a PC will, then, be (at most)
the intersection of the set of rights granted to the entity named in
the EEC in the PC's certificate path, and the sets of rights
authorized by the policies in each proxyRestriction that appears in
the certificate path. For example, imagine that Steve is authorized
to read and write files A and B on a file server, and that he uses
his EEC to create a PC that includes the restriction that it can be
used only to read or write files A and C. At most, the rights

Tuecke, et. al. Expires February 2002 17
Internet Draft X.509 Proxy Certificate Profile March 2002

granted to the bearer of that PC will be the right to read and write
file A -- a request to read file B, for example, would be rejected
because it would be incompatible with the proxy restriction, and a
request to read file C would be rejected because the file server's
local policies do not grant Steve any access to file C. If that PC
were then used to create a new PC that includes the restriction that
it can be used only to read files, then the bearer of that new PC
would have, at most, the right to read file A.

In many cases, the relying party will not have enough information to
evaluate the above criteria at the time that the certificate itself
is validated. For example, if a certificate is used to authenticate
a connection to some server, that certificate is typically validated
during that authentication step, before any requests have been made
of the server. In that case, the relying party MUST either have
some authorization mechanism in place that will check the proxy
restrictions, or reject any certificate that contains proxy
restrictions (or that has a parent certificate that contains proxy
restrictions).

3.6.1.4 issuerCertHash

3.7.1.5 proxyGroup

The issuerCertHash field, if present, is used during path validation
to ensure that each Proxy Certificate Path (the subset proxyGroup field provides a method of assigning a PC's
certificate path that starts at an End Entity Certificate and ends

Tuecke, et. al. Expires February 2002 15
Internet Draft X.509 Proxy
Certificate Profile August 2001

at the PC) is unique. In other words, if certificate N+1 in to a
certificate path is group, which serves as a Proxy Certificate, then issuerCertHash is used method to verify that certificate N is actually the PA that issued it and
not some other certificate with the same name and public key.
Without this field, if limit a PA were PC�s
ability to issue two different proxy
certificates (P1 and P2) do self-authentication (authentication with entities
authenticating with a PC derived from the same subjectAltName and public key
but different proxy restrictions or validity time constraints, then
the path validation algorithm would accept a path in which P2
appeared EEC as the issuer of a certificate that had really been issued
by P1.

This field consists of the following two subfields:

* hashAlgorithm MUST be identical to the PA's signatureAlgorithm.
* hashValue MUST be identical to original
party). If the PA's signatureValue.

This proxyGroup field MUST be is present if the pC field is TRUE.

3.6.2 The DelegationTrace Extension

The DelegationTrace proxyCertInfo
extension MUST be marked as critical.

The proxyGroupAttached field indicates whether this subgroup is used
attached to provide information about
the identity it�s parent group in terms of the Acceptor of trust model. If a Proxy Certificate and,
subgroup is attached, proxies in some
cases, to demonstrate that the Acceptor has agreed to accept subgroup (and it�s descendants)
are considered trusted for self-authentication by proxies in the
Proxy Certificate.
parent group (and it�s ancestors). If a subgroup is detached then
proxies in the subgroup (and it�s descendants) are considered
untrusted for self-authentication by proxies in the parent group (and
it�s ancestors).

The Proxy Certificate does not include policy
extensions, the Acceptor's agreement to "accept" that certificate group namespace is
not an agreement to accept any additional responsibilities, such as
safeguarding hierarchical, with the
namespace being defined by the End Entity Certificate. In other
words, two Proxy Certificate's private key.

If Certificates having the DelegationTrace extension same group name is present, then the certificate
MUST be a Proxy Certificate: only
meaningful if they both have the ProxyCertInfo extension MUST also
be present, and same EEC at the ProxyCertInfo.pC field MUST be TRUE. root of their
signing chain.

The
DelegationTrace extension MAY be present in any proxy certificate,
and SHOULD EEC is always considered to be present in any the group that is the root of
the namespace. Each Proxy Certificate whose issuer is in a chain can then be in a
subgroup of the PI that issued it. The full group name of a Proxy
Certificate is the sequence of subgroup names in proxyCertInfo
extensions starting in which the DelegationTrace extension signing chain starting with the EEC.

If two parties are doing self-authentication, not only should they
verify that they each have a PC derived from the same EEC, but they
should make sure that the groups of their PCs are compatible.
Compatibility is present.
This extension SHOULD NOT be marked critical.

id-ce-delegation-trace OBJECT IDENTIFIER ::= { id-ce ?? }

DelegationTrace ::= CHOICE {
x509 [0] X509DelegationTrace }

X509DelegationTrace ::= SEQUENCE {
agreedCertInfo AgreedCertInfo,
x509AcceptorInfo X509AcceptorInfo }

AgreedCertInfo ::= SEQUENCE {
ignoredExtensions SEQUENCE OF OBJECT IDENTIFIER,
certSubsetHash Hash }

X509AcceptorInfo ::= SEQUENCE {
acceptorSig Signature,
acceptorName Name,
acceptorAltName GeneralName OPTIONAL,
acceptorCertHash Signature } defined as being in groups that are a direct

Tuecke, et. al. Expires February 2002 16 18
Internet Draft X.509 Proxy Certificate Profile August 2001

Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }

The DelegationTrace extension consists March 2002

attached ancestors or descendants of information regarding the
certificate's Acceptor, in each other. E.g. a format appropriate for the mechanism
that was parent and an
attached child group are compatible, but siblings groups are not.

3.7.1.6 issuerCertSignature

The issuerCertSignature field, if present, is used by the Acceptor to authenticate during path
validation to the ensure that each Proxy
Authority. Currently, the only format defined is
X509DelegationTrace, which is intended for use when Certificate Path (the subset of
a PC's certificate path that
authentication took place using X.509 certificates, or when the
Acceptor starts at an End Entity Certificate and
ends at the PA are the same entity.

The X509DelegationTrace structure PC) is unique. In other words, if certificate N+1 in a
certificate path is a Proxy Certificate, then issuerCertSignature is
used to verify that, at the
time the Proxy Certificate was issued, that certificate N is actually the Acceptor had agreed to
accept it. This structure consists of two required fields: PI that issued it
and not some other certificate with the
agreedCertInfo same name and public key.
Without this field, which contains hashes of some information
related if a PI were to issue two different proxy
certificates (P1 and P2) with the certificate, same subject and public key but
different proxy restrictions or validity time constraints, then the acceptorInfo field,
path validation algorithm would accept a path in which
contains P2 appeared
as the Acceptor's signature issuer of the agreedCertInfo, plus
additional information a certificate that can be used had really been issued by a relying party to verify
the Acceptor's signature. These fields are described in detail in P1.

This field consists of the following two subsections.

3.6.2.1 agreedCertInfo

The agreedCertInfo field is used subfields:

* signatureAlgorithm MUST be identical to describe the proxy certificates
that an Acceptor is willing to accept. It consists of these
subfields: PI's
signatureAlgorithm.
* ignoredExtensions: signatureValue MUST be identical to the PI's signatureValue.

This field MUST be present if the pC field is TRUE.

3.7.2 The DelegationTrace Extension

[Author�s note: The DelegationTrace extension is still undergoing
discussion and will very likely change in a list future version of OIDs. this
draft.]

The presence of an OID in
this list DelegationTrace extension is an indication that used to provide information about
the presence, absence, or value identity of an extension with this OID in a certificate will not affect
the Acceptor's willingness to accept the certificate.

* certSubsetHash: a hash Acceptor of a TBSCertificate structure representing
a certificate Proxy Certificate and, in some
cases, to demonstrate that the Acceptor is willing to accept.

When verifying this extension, the relying party should construct
a TBSCertificate structure identical has agreed to accept the current certificate's
tbsCertificate field, minus the DelegationTrace extension and any
extensions listed in ignoredExtensions; the hash of that structure
should be equal to certSubsetHash.

3.6.2.2 x509AcceptorInfo

The x509AcceptorInfo field consists of
Proxy Certificate. If a signature, using the
private key associated with Proxy Certificate does not include policy
extensions, the Acceptor's certificate, of the
agreedCertInfo field, plus additional information that the relying
party may use agreement to identify the Acceptor.

Note "accept" that the Acceptor's certificate is
not the newly-issued proxy
certificate; rather, it is an X.509 certificate already held by the
Acceptor at agreement to accept any additional responsibilities, such as
safeguarding the time of delegation. Proxy Certificate's private key.

If the issuer and Acceptor are
the same entity, DelegationTrace extension is present, then the Acceptor's certificate SHOULD
MUST be the

Tuecke, et. al. Expires February 2002 17
Internet Draft X.509 a Proxy Certificate Profile August 2001

Issuer's certificate. If Certificate: the Acceptor sent a certificate request to ProxyCertInfo extension MUST also
be present, and the issuer over a channel that was authenticated using an X.509 ProxyCertInfo.pC field MUST be TRUE. The
DelegationTrace extension MAY be present in any proxy certificate, then the Acceptor's certificate
and SHOULD be present in any Proxy Certificate whose issuer is a
Proxy Certificate in which the
certificate that the Acceptor used to authenticate to the issuer.

The DelegationTrace extension is present.
This extension SHOULD NOT be marked critical.

id-ce-delegation-trace OBJECT IDENTIFIER ::= { id-ce ?? }

DelegationTrace ::= CHOICE {
x509 [0] X509DelegationTrace }

X509DelegationTrace ::= SEQUENCE {

Tuecke, et. al. Expires February 2002 19
Internet Draft X.509 Proxy Certificate Profile March 2002

agreedCertInfo AgreedCertInfo,
x509AcceptorInfo field X509AcceptorInfo }

AgreedCertInfo ::= SEQUENCE {
ignoredExtensions SEQUENCE OF OBJECT IDENTIFIER,
certSubsetHash Hash }

X509AcceptorInfo ::= SEQUENCE {
acceptorSig Signature,
acceptorName Name,
acceptorAltName GeneralName OPTIONAL,
acceptorCertHash Signature }

Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }

The DelegationTrace extension consists of these subfields:

* acceptorSig is information regarding the
certificate's Acceptor, in a signature, using format appropriate for the private key associated with mechanism
that was used by the Acceptor's certificate, of Acceptor to authenticate to the agreedCertInfo field.

* acceptorName Proxy
Authority. Currently, the only format defined is
X509DelegationTrace, which is intended for use when that
authentication took place using X.509 certificates, or when the subject name from
Acceptor and the Acceptor's certificate.

* acceptorAltName PA are the same entity.

The X509DelegationTrace structure is used to verify that, at the subjectAltName from
time the Acceptor's
certificate. If acceptorName is null, this field MUST be present
and non-null.

* acceptorCertHash is a copy of Proxy Certificate was issued, the signature from Acceptor had agreed to
accept it. This structure consists of two required fields: the Acceptor's
certificate: acceptorHash.hashAlgorithm and acceptorHash.hashValue
must be identical
agreedCertInfo field, which contains hashes of some information
related to the signatureAlgorithm certificate, and signatureValue
from the acceptorInfo field, which
contains the Acceptor's certificate.

4 Certificate Path Validation

[TBD: Consider changing this section to add a second phase to path
validation for PC validation, rather than modifying signature of the existing
path validation agreedCertInfo, plus
additional information that can be used by a relying party to accommodate verify
the entire chain.]

The Certificate Path Validation algorithm Acceptor's signature. These fields are described in Section 6 of
draft-ietf-pkix-new-part1-08 [7] must be modified to accommodate
Proxy Certificates. Changes are needed to:

1) check the generalized signing chains involving CAs, End Entity
Certificates, and Proxy Certificates;

2) handle the use of subjectAltName and issuerAltName detail in
the
certificate path;

3) handle following two subsections.

3.7.2.1 agreedCertInfo

The agreedCertInfo field is used to describe the iCPathLenConstraint proxy certificates
that an Acceptor is willing to accept. It consists of these
subfields:

* ignoredExtensions: a list of OIDs. The presence of an OID in
this list is an indication that the proxyCertInfo extension.

4) check the key usage and extended key usage extensions.

5) handle the issuerCertHash presence, absence, or value
of an extension with this OID in a certificate will not affect
the proxyCertInfo extension.

Changes Acceptor's willingness to section 6.1.2, Initialization:

(j) This step defines accept the working_issuer_name to be certificate.

* certSubsetHash: a
distinguished name. However, because hash of a PC uses the
issuerAltName, TBSCertificate structure representing
a certificate that the working_issuer_name variable needs to be
generalized Acceptor is willing to accommodate not just accept.

When verifying this extension, the relying party should construct
a distinguished name, but any
of TBSCertificate structure identical to the valid issuerAltName/subjectAltName types.

(new) working_certificate_type: This can be one of CA, EEC, or
PC. A certificate type of CA is determined by current certificate's
tbsCertificate field, minus the
basicConstraints DelegationTrace extension or as verified out-of-band. A and any

Tuecke, et. al. Expires February 2002 18 20
Internet Draft X.509 Proxy Certificate Profile August 2001

certificate type of PC is determined by the proxyCertInfo
extension. Otherwise, March 2002

extensions listed in ignoredExtensions; the certificate type is EEC.

(new) valid_pc_key_usage & pc_key_usage_criticality: These are
used to verify hash of that the key usage structure
should be equal to certSubsetHash.

3.7.2.2 x509AcceptorInfo

The x509AcceptorInfo field consists of a PC is a subset of signature, using the
private key
usage associated with the Acceptor's certificate, of the certificate that signed
agreedCertInfo field, plus additional information that PC, and the relying
party may use to identify the Acceptor.

Note that the
criticality of this extension never diminishes. These variables
are Acceptor's certificate is not initialized or used until the first EEC or PC newly-issued proxy
certificate; rather, it is
encountered in the path validation algorithm with this extension.

(new) valid_pc_ext_key_usage & pc_ext_key_usage_criticality:
These are used to verify that an X.509 certificate already held by the extended key usage OIDs of a PC
is a subset of
Acceptor at the extended key usage OIDs time of delegation. If the certificate
that signed that PC, issuer and that the criticality of this extension
never diminishes. These variables Acceptor are not initialized or used
until
the first EEC or PC is encountered in same entity, then the path validation
algorithm with this extension.

(new) working_issuer_hash_algorithm & working_issuer_hash_value:
These are used to verify that, if Acceptor's certificate N+1 is SHOULD be the
Issuer's certificate. If the Acceptor sent a Proxy
Certificate, certificate request to
the issuer over a channel that was authenticated using an X.509
certificate, then the Acceptor's certificate N is SHOULD be the
certificate that issued
that proxy. These variables are not the Acceptor used until to authenticate to the first EEC or
PC is encountered in the path validation algorithm with the
proxyCertInfo extension.

Changes to section 6.1.3, Basic Certificate Processing:

(a)(4) issuer.

The comparison x509AcceptorInfo field consists of these subfields:

* acceptorSig is a signature, using the certificate issuer name private key associated with
the
working_issuer_name must be generalized to support comparison
between any Acceptor's certificate, of the valid issuerAltName types.

(a)(new) The certificate type agreedCertInfo field.

* acceptorName is CA and the
working_certificate_type is CA, or subject name from the certificate type Acceptor's certificate.

* acceptorAltName is EEC
and the working_certificate_type is CA, or subjectAltName from the certificate type Acceptor's
certificate. If acceptorName is PC null, this field MUST be present
and the working_certificate_type non-null.

* acceptorCertHash is EEC or PC.

(b) & (c) This step checks a copy of the Name Constraints defined by signature from the
CA. However, since a PC does not define a new Name, these checks
should Acceptor's
certificate: acceptorHash.hashAlgorithm and
acceptorHash.hashValue must be skipped if identical to the certificate type is
signatureAlgorithm and signatureValue from the Acceptor's
certificate.

4 Certificate Path Validation

[Author�s note: Consider changing this section to add a second phase
to path validation for PC (as specified validation, rather than modifying the
existing path validation to accommodate the entire chain.]

The Certificate Path Validation algorithm described in
a proxyCertInfo extension).

(new) If certificate type is PC, and valid_pc_key_usage has been
initialized, then verify that:

(1) all bits that Section 6 of
draft-ietf-pkix-new-part1-12 [7] must be modified to accommodate
Proxy Certificates. Changes are asserted needed to:

1) check the generalized signing chains involving CAs, End Entity
Certificates, and Proxy Certificates;

2) check for proper subject names in Proxy Certificates;

3) handle the keyUsage extension of iCPathLenConstraint in the certificate are also asserted in the valid_pc_key_usage;

(2) if pc_key_usage_criticality is true, then proxyCertInfo extension;

4) check the keyUsage
extension is critical

(new) If certificate type is PC, key usage and valid_pc_ext_key_usage has
been initialized, then verify that: extended key usage extensions;

Tuecke, et. al. Expires February 2002 19 21
Internet Draft X.509 Proxy Certificate Profile August 2001

(1) all OIDs that are in March 2002

5) handle the extKeyUsage extension issuerCertSignature in the proxyCertInfo extension.

Changes to section 6.1.2, Initialization:

(new) working_certificate_type: This can be one of CA, EEC, or
PC. A certificate are also in the valid_pc_ext_key_usage;

(2) if pc_ext_key_usage_criticality type of CA is true, then determined by the
extKeyUsage
basicConstraints extension is critical.

(new) If or as verified out-of-band. A
certificate type of PC is PC, then verify that:

(1) proxyCertInfo.issuerCertHash is present.

(2) proxyCertInfo.issuerCertHash.hashAlgorithm is equal to
working_issuer_hash_algorithm.

(3) proxyCertInfo.issuerCertHash.hashValue is equal to
working_issuer_hash_value.

Changes to section 6.1.4, Preparation for Certificate i+1:

(c) Adjust this to assign determined by the subjectAltName to
working_issuer_name, if proxyCertInfo
extension. Otherwise, the subject certificate type is empty. EEC.

(new) working_issuer_certificate_type: This is done can be one of EEC or
PC to
accommodate indicate the use type of subjectAltName and issuerAltName by PCs.

(k) This step verifies certificate that acted as the certificate is a CA certificate.
However, it is not general enough to support Proxy
Issuer for a PC. So change
this step to simply assign the certificate type

(new) valid_pc_key_usage & pc_key_usage_criticality: These are
used to verify that the
working_certificate_type. The necessary CA, EEC, and key usage of a PC signing
constraints check has been added to the Basic Certificate
Processing section above.

(m) This step resets the max_path_length if pathLenConstraint is
present in a subset of the certificate. This needs to be generalized to
support pCPathLengthConstraint from key
usage of the proxyCertInfo extension,
as follows:

Reset max_path_length as follows:

(1) If certificate type is CA, that signed that PC, and pathLenConstraint that the
criticality of this extension never diminishes. These variables
are not initialized or used until the first EEC or PC is
present
encountered in the certificate and is less than max_path_length,
then set max_path_length path validation algorithm with this extension.

(new) valid_pc_ext_key_usage & pc_ext_key_usage_criticality:
These are used to verify that the value extended key usage OIDs of pathLenConstraint.

(2) If certificate type a PC
is EEC, a subset of the extended key usage OIDs of the certificate
that signed that PC, and pCPathLenConstraint is that the criticality of this extension
never diminishes. These variables are not
present initialized or used
until the first EEC or PC is encountered in the certificate, then set max_path_length path validation
algorithm with this extension.

(new) working_issuer_signature_algorithm &
working_issuer_signature_value: These are used to n.

(3) If verify that,
if certificate type N+1 is EEC, and pCPathLenConstraint a Proxy Certificate, then certificate N is
present
the certificate that issued that proxy. These variables are not
used until the first EEC or PC is encountered in the certificate, then set max_path_length to path
validation algorithm with the
value of pCPathLenConstraint.

(4) If proxyCertInfo extension.

Changes to section 6.1.3, Basic Certificate Processing:

(a)(new) The certificate type is PC, CA and pCPathLenConstraint the
working_certificate_type is
present in CA, or the certificate type is EEC
and less than max_path_length, then
set max_path_length to the value of pCPathLenConstraint.

(n) Since keyCertSign working_certificate_type is currently defined to be equivalent to
being a CA, this check needs to be changed to accommodate PCs, as
follows: If or the certificate type
is CA, PC and a key usage extension the working_certificate_type is

Tuecke, et. al. Expires February 2002 20
Internet Draft X.509 Proxy Certificate Profile August 2001

present and marked critical, verify that EEC or PC.

(b) & (c) This step checks the keyCertSign bit Name Constraints defined by the
CA. However, since a PC does not define a new Name, these checks
should be skipped if the certificate type is
set. PC (as specified in
a proxyCertInfo extension).

(new) If certificate type is PC, the subject name should be
checked to make sure it is a valid subject name to have been
issued by it�s Proxy Issuer. If the
working_issuer_certificate_type is EEC or then the subject name
should just contain a single CN component. If the

Tuecke, et. al. Expires February 2002 22
Internet Draft X.509 Proxy Certificate Profile March 2002

working_issuer_certificate_type is PC then the subject name
should be the working_issuer_name with the addition of a single
CN component.

(new) If certificate type is PC, and valid_pc_key_usage has been
initialized, then verify that:

(1) all bits that are asserted in the key usage keyUsage extension of
the certificate are also asserted in the valid_pc_key_usage;

(2) if pc_key_usage_criticality is present, true, then set valid_pc_key_usage to keyUsage,
and set pc_key_usage_criticality to the keyUsage criticality.
extension is critical

(new) If certificate type is EEC or PC, and valid_pc_ext_key_usage has
been initialized, then verify that:

(1) all OIDs that are in the extended key
usage extKeyUsage extension in the
certificate are also in the valid_pc_ext_key_usage;

(2) if pc_ext_key_usage_criticality is present, true, then set valid_pc_ext_key_usage to
extKeyUsage, and set pc_ext_key_usage_criticality to the
extKeyUsage criticality. extension is critical.

(new) Assign the If certificate signatureAlgorithm type is PC, then verify that:

(1) proxyCertInfo.issuerCertSignature is present.

(2) proxyCertInfo.issuerCertSignature.signatureAlgorithm is
equal to
working_issuer_hash_algorithm, and assign the certificate
signatureValue working_issuer_signature_algorithm.

(3) proxyCertInfo.issuerCertSignature.signatureValue is equal
to working_issuer_hash_value.

At this point we have no plans working_issuer_signature_value.

Changes to section 6.1.4, Preparation for Certificate i+1:

(k) This step verifies that the certificate is a PA (that is, an EEC or PC) to
revoke the PCs that CA certificate.
However, it has issued. If this feature is needed in the
future, the CRL Distribution Point extension can be used in the PA
certificates not general enough to locate support a CRL.

5 Relationship PC. So change
this step to Attribute Certificates

An Attribute Certificate [4] can be used simply assign the certificate type to grant the
working_certificate_type. The necessary CA, EEC, and PC signing
constraints check has been added to one identity, the holder, some attribute such as a role, clearance level, or
alternative identity such as "charging identity" or "audit
identity". Basic Certificate
Processing section above.

(m) This step resets the max_path_length if pathLenConstraint is accomplished by way of a trusted Attribute
Authority (AA), which issues signed Attribute Certificates (AC),
each of which binds an identity
present in the certificate. This needs to a particular set of attributes.
Authorization decisions can then be made by combining information generalized to
support pCPathLengthConstraint from the authenticated End Entity Certificate providing the
identity, with the signed Attribute Certificates providing binding
of that identity to attributes.

There proxyCertInfo extension,
as follows:

Reset max_path_length as follows:

(1) If certificate type is clearly some overlap between CA, and pathLenConstraint is
present in the capabilities provided by
Proxy Certificates certificate and Attribute Certificates. However, is less than max_path_length,
then set max_path_length to the
combination value of pathLenConstraint.

(2) If certificate type is EEC, and pCPathLenConstraint is not
present in the two approaches together provides a broader
spectrum of solutions certificate, then set max_path_length to authorization in n.

Tuecke, et. al. Expires February 2002 23
Internet Draft X.509 based systems, than
either solution alone. This section seeks to clarify some of the
overlaps, differences, and synergies between Proxy Certificate Profile March 2002

(3) If certificate type is EEC, and
Attribute Certificates.

5.1 Types of Attribute Authorities

For pCPathLenConstraint is
present in the purposes certificate, then set max_path_length to the
value of this discussion, Attribute Authorities, pCPathLenConstraint.

(4) If certificate type is PC, and pCPathLenConstraint is
present in the
uses certificate and less than max_path_length, then
set max_path_length to the value of pCPathLenConstraint.

(5) If certificate type is PC, and pCPathLenConstraint is not
present in the Attribute Certificates that they produce, can be broken
down into two broad classes:

1) End entity AA: An End Entity Certificate may be used certificate, then set max_path_length to sign an
AC. This can be used, for example,
infinite.

(n) Since keyCertSign is currently defined to allow an end entity be equivalent to
delegate some of its privileges
being a CA, this check needs to another entity.

2) Third party AA: A separate entity, aside from the end entity
involved in an authenticated interaction, may sign ACs in order be changed to

Tuecke, et. al. Expires February 2002 21
Internet Draft X.509 Proxy Certificate Profile August 2001

bind the authenticated identity with additional attributes, such accommodate PCs, as role, group, etc. For example, when a client authenticates
with
follows: If certificate type is CA, and a server, the third party AA may provide an AC key usage extension is
present and marked critical, verify that binds the
client identity to a particular group, which keyCertSign bit is
set.

(new) If certificate type is EEC or PC, and the server key usage
extension is present, then uses
for authorization purposes.

This second set valid_pc_key_usage to keyUsage,
and set pc_key_usage_criticality to the keyUsage criticality.

(new) If certificate type of Attribute Authority, is EEC or PC, and the third party AA, works
equally well with extended key
usage extension is present, then set valid_pc_ext_key_usage to
extKeyUsage, and set pc_ext_key_usage_criticality to the
extKeyUsage criticality.

(new) Assign the certificate signatureAlgorithm to
working_issuer_signature_algorithm, and assign the certificate
signatureValue to working_issuer_signature_value.

At this point we have no plans for a PI (that is, an EEC or PC) to
revoke the PCs that it has issued. If this feature is needed in the
future, the CRL Distribution Point extension can be used in the PI
certificates to locate a PC. For example, Proxy CRL.

5 Relationship to Attribute Certificates

An Attribute Certificate [4] can be used to delegate the EEC's identity grant to various other parties.
Then when one of those other parties uses identity,
the PC holder, some attribute such as a role, clearance level, or
alternative identity such as "charging identity" or "audit
identity". This is accomplished by way of a trusted Attribute
Authority (AA), which issues signed Attribute Certificates (AC),
each of which binds an identity to authenticate
with a service, that service will receive particular set of attributes.
Authorization decisions can then be made by combining information
from the EEC's identity via authenticated End Entity Certificate providing the
PC, and can apply any ACs that bind
identity, with the signed Attribute Certificates providing binding
of that identity to attributes in
order to determine authorization rights. attributes.

There would appear to be
great synergies is clearly some overlap between the use of capabilities provided by
Proxy Certificates and Attribute
Certificates produced by third party Attribute Authorities. Certificates. However, the uses
combination of Attribute Certificates that are granted by the
first type two approaches together provides a broader
spectrum of solutions to authorization in X.509 based systems, than

Tuecke, et. al. Expires February 2002 24
Internet Draft X.509 Proxy Certificate Profile March 2002

either solution alone. This section seeks to clarify some of the
overlaps, differences, and synergies between Proxy Certificate and
Attribute Authority, Certificates.

5.1 Types of Attribute Authorities

For the end entity AA, overlap
considerably with purposes of this discussion, Attribute Authorities, and the
uses of Proxy Certificates as described in the
previous sections. Such Attribute Certificates are generally that they produce, can be broken
down into two broad classes:

1) End entity AA: An End Entity Certificate may be used to sign an
AC. This can be used, for delegation example, to allow an end entity to
delegate some of rights its privileges to another entity.

2) Third party AA: A separate entity, aside from one the end entity
involved in an authenticated interaction, may sign ACs in order to others, which
clearly overlaps
bind the authenticated identity with additional attributes, such
as role, group, etc. For example, when a client authenticates
with a server, the stated purpose third party AA may provide an AC that binds the
client identity to a particular group, which the server then uses
for authorization purposes.

This second type of Proxy Certificates,
namely single sign-on and delegation.

5.2 Delegation Using Attribute Certificates

In Authority, the motivating example above, PCs are third party AA, works
equally well with an EEC or a PC. For example, Proxy Certificates
can be used to delegate Steve's the EEC's identity to the various other jobs and agents that need to act on
Steve's behalf. This parties.
Then when one of those other parties uses the PC to authenticate
with a service, that service will receive the EEC's identity via the
PC, and can apply any ACs that bind that identity to attributes in
order to determine authorization rights. Additionally PC
restrictions could be used do deny the binding of an AC to a
particular proxy. An AC could also be bound to a particular PC using
the subject or issuer and serial number of the proxy certificate.
There would appear to be great synergies between the use of Proxy
Certificates and Attribute Certificates produced by third party
Attribute Authorities.

However, the uses of Attribute Certificates that are granted by the
first type of Attribute Authority, the end entity AA, overlap
considerably with the uses of Proxy Certificates as described in the
previous sections. Such Attribute Certificates are generally used
for delegation of rights from one end entity to others, which
clearly overlaps with the stated purpose of Proxy Certificates,
namely single sign-on and delegation.

5.2 Delegation Using Attribute Certificates

In the motivating example above, PCs are used to delegate Steve's
identity to other entities that need to act on Steve's behalf. This
allows those other entities to authenticate as if they were Steve, for example to the mass storage system. Steve.

A solution to this example could also be cast using Attribute
Certificates that are signed by Steve's EEC, which grant to the
other entities in this example the right to perform various
operations on Steve's behalf. In this example, the starter program,
the agent, the simulation jobs, reliable file

Tuecke, et. al. Expires February 2002 25
Internet Draft X.509 Proxy Certificate Profile March 2002

transfer service and all the post-processing job hosts involved in file transfers 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 disadvantages
as compared to the PC based solution:

* All protocols, authentication code, and identity based
authorization services must be modified to understand ACs. With
the PC solution, protocols (e.g. TLS) likely need no
modification, authentication code needs minimal modification
(e.g. to perform PC aware path validation), and identity based
authorization services need no modification.

* ACs need to be created by Steve's EEC, which bind attributes to
each of the other identities involved in the distributed
application (i.e. the agent, simulation jobs, and post-processing

Tuecke, et. al. Expires February 2002 22
Internet Draft X.509 Proxy Certificate Profile August 2001

job). file transfer service, the hosts
transferring files). This implies that Steve must know in
advance which other identities may be involved in this
distributed application, in order to generate the appropriate ACs
which are signed by Steve's ECC. On the other hand, the PC
solution allows for much more flexibility, since parties can
further delegate a PC without a priori knowledge by the
originating EEC.

There are many unexplored tradeoffs and implications in this
discussion of delegation. However, reasonable arguments can be made
in favor of either an AC based solution to delegation or a PC based
solution to delegation. The choice of which approach should be
taken in a given instance may depend on factors such as the software
that it needs to be integrated into, the type of delegation
required, and religion.

5.3 Propagation of Authorization Information

One possible use of Proxy Certificates is to carry authorization
information associated with a particular identity.

The merits of placing authorization information into End Entity
Certificates (also called a Public Key Certificate or PKC) have been
widely debated. For example, Section 1 of "An Internet Attribute
Certificate Profile for Authorization" states:

"Authorization information may be placed in a PKC extension or
placed in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have
the same lifetime as the binding of the identity and the public
key. When authorization information is placed in a PKC
extension, the general result is the shortening of the PKC useful
lifetime. Second, the PKC issuer is not usually authoritative
for the authorization information. This results in additional
steps for the PKC issuer to

Tuecke, et. al. Expires February 2002 26
Internet Draft X.509 Proxy Certificate Profile March 2002

steps for the PKC issuer to obtain authorization information from
the authoritative source.

For these reasons, it is often better to separate authorization
information from the PKC. Yet, authorization information also
needs to be bound to an identity. An AC provides this binding; it
is simply a digitally signed (or certified) identity and set of
attributes." ([4], Section 1)

Placing authorization information in a PC mitigates the first
undesirable property cited above. Since a PC has a lifetime that is
mostly independent of (always shorter than) its signing EEC, a PC
becomes a viable approach for carrying authorization information. information for
the purpose of delegation.

The second undesirable property cited above is true. If a third
party AA is authoritative, then using ACs issued by that third party
AA is a natural approach to disseminating authorization information.
However, this is true whether the identity being bound by these ACs
comes from an EEC (PKC), or from a PC.

Tuecke, et. al. Expires February 2002 23
Internet Draft X.509 Proxy Certificate Profile August 2001

There is one case, however, that the above text does not consider.
When performing delegation, it is usually the EEC itself that is
authoritative (not the EEC issuer, or any third party AA). That is,
it is up to the EEC to decide what authorization rights it is
willing to grant to another party. In this situation, including
such authorization information into PCs that are generated by the
EEC seems a reasonable approach to disseminating such information.

5.4 Proxy Certificate as Attribute Certificate Holder

In a system that employs both PCs and ACs, one can imagine the
utility of allowing a PC to be the holder of an AC. This would
allow for a particular delegated instance of an identity to be given
an attribute, rather than all delegated instances of that identity
being given the attribute.

However, the issue of how

An AC could be bound to specify a particular instance of a PC as using the holder
unique subject name of an the PC, or it�s issuer and serial number
combination.

Still open at this point is the issue if the AC
remains open. would be inherited
by PC created by this PC acting as a PI.

6 Commentary

This section provides commentary on various design choices, open
issues, related work, and future directions for Proxy Certificates.

6.1 keyCertSign Bit in the Key Usage Basic Extension

This Proxy Certificate profile does not change the definition of the
keyCertSign bit of the keyUsage extension. draft-ietf-pkix-new-
part1-08
part1-12 states:

Tuecke, et. al. Expires February 2002 27
Internet Draft X.509 Proxy Certificate Profile March 2002

"The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If
the keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted."

Nor does this Proxy Certificate profile contradict this keyCertSign
definition, since a Proxy Certificate is not an end entity public
key certificates, certificate, as discussed in section 2 above.

6.2 nonRepudiate Bit in the Key Usage Basic Extension

One alternative for the nonRepudiate bit is that it MUST NOT be
asserted. It seems, on the surface, and impersonation and non-
repudiation are at odds with one another. However, this decision is
postponed until further discussion with others who are more familiar
with the use of this bit.

6.3 Carrying Along the End Entity Subject Name of a Proxy Certificate

The

Another suggestion was to include the subject name of the signing EEC as
a PC is only used for path validation. This PC
profile uses a randomly generated subjectAltName prefix to provide a
(statistically) unique subject name for the PC subject, or as an informational field in the PC.

Tuecke, et. al. Expires February 2002 24
Internet Draft X.509 Proxy Certificate Profile August 2001

Another possibility for naming
This would allow an authorizing process to use only information in
the final PC is in the chain to use a subject field that
is derived from determine identity, and not need to
walk the chain in order to find out the subject of the PA. In fact, this is EEC that the
PC is derived from.

This approach taken in was rejected for the current Grid Security Infrastructure
implementation. following reasons:

* It would be easy to spoof this informational field. For example, the
a PC with an informational subject field could be the EEC subject field,
extended with the addition of a new AttributeType and Value
component of proxyLevel:nnnn where proxyLevel is a new
AttributeType, and nnnn is the depth of the PC signing path. The
issuer field would contain the subject field of the PA that signed
the PC. In this scheme the path validation process would check that
the subject and issuer names match up the chain and the proxyLevel
values increase by one at each subsequent delegation.

One advantage of this approach is that some current implementations
of path validation, such as OpenSSL-0.9.6, do not support the use of
subjectAltName and issuerAltName. Thus for practical purposes it is
arguably better to use the subject name and the proxyLevel:nnnn
scheme.

A disadvantage of this approach is that it is reliant on the DN
convention used by the subject field. This limits Proxy
Certificates such that they can only be used for EECs that use the
subject field. If an EEC instead uses subjectAltName, with a null
subject field, then this approach does not work. For this reason,
this approach was rejected for this Proxy Certificate profile.

6.4 Carrying Along the End Entity Subject

Another suggestion was to include the subject of the signing EEC as
an informational field in the PC. This would allow an authorizing
process to use only information in the final PC in the chain to
determine identity, and not need to walk the chain in order to find
out the subject (or subjectAltName) of the EEC that the PC is
derived from.

This approach was rejected for the following reasons:

* It would be easy to spoof this informational field. For example,
a PC with an informational subject of "Steve" of "Steve" could be used to
create a PC with an informational subject set to "Doug". This
leaves us with two alternatives:

. We can augment the path validation to check that this
informational field of the PC is the same as in the signing PC
or EEC. But this is not desirable, as it complicates the path
validation.

. But if we do not validate this field, we cannot trust the
contents of this informational field. So then there is no
point in including this informational field.

* Upon closer examination, there is a lot of information in the
certificate chain that may be needed during authorization, such

Tuecke, et. al. Expires February 2002 25
Internet Draft X.509 Proxy Certificate Profile August 2001
as the number of levels of delegation, the CA (or multiple levels
of CAs) who signed the original EEC, the constraints and keyUsage
values of the signing EEC, possibly Certificate Policies
associated with CAs or IAs. All of these require essentially the
same amount of work as retrieving the subject of the EEC that
signed the PC. So why threat the EEC subject specially by
including it in an information field?

Tuecke, et. al. Expires February 2002 28
Internet Draft X.509 Proxy Certificate Profile March 2002

In the end, just including the EEC subject name does not seem to be
sufficiently useful to justify the addition of another field and the
work of verifying that name during the path validation.

Therefore, to determine the identity of a PC for authorization
purposes, the subject of the EEC must be retrieved directly from the
EEC in the signing chain. This approach also has the beneficial
side effect of further stressing that a Proxy Certificate has no
identity of its own, but rather inherits it from its signing EEC.

6.5

6.4 Specifying Proxy Restrictions

The proxyRestriction field in the proxyCertInfo extension does not
define a policy language to be used for proxy restrictions; rather,
it places the burden on those parties using that extension to define
an appropriate language, and to acquire an OID for that language (or
to select an appropriate previously-defined language/OID). Because
it is essential for the PA PI that issues a certificate with a
proxyRestriction field and the relying party that interprets that
field to agree on its meaning, the policy language OID must
correspond to a policy language, not just a policy grammar.

Several different approaches were considered regarding how to limit
the use of a PC for specific authorization purposes. One of these
approaches was to include a list the specific rights granted by the
PC (perhaps along with conditions associated with those rights),
either as a separate extension or as part of proxyCertInfo. This
list of rights would define the subset of the issuer's rights to be
granted to the PC holder. But the parties using that extension
would still be responsible for ensuring that both the PA PI and relying
party agreed on the meanings of the access rights and conditions
appearing in the restriction.

Another possible approach is to embed an Attribute Certificate
(signed by the EEC issuing the PC) within a PC, which would define a
subset of the issuer's attributes to be associated with the PC
holder.

6.6

6.5 Proxy Restrictions vs. Proxy Rights

The proxyRestriction field in the proxyCertInfo extension defines
restrictions on the use of the proxy certificate; if that field is
not present, the proxy is unrestricted.

Tuecke, et. al. Expires February 2002 26
Internet Draft X.509 Proxy Certificate Profile August 2001

Another approach would be to require that each proxy certificate
explicitly list the rights that it grants.

6.7

6.6 Site Information in Delegation Tracing

In some cases, it may be desirable to know the hosts involved in a
delegation transaction (for example, a relying party may wish to
reject proxy certificates that were created on a specific host or
domain). The DelegationTrace extension could be modified to include
the PA's and Acceptor's IP addresses; however, IP addresses are

Tuecke, et. al. Expires February 2002 29
Internet Draft X.509 Proxy Certificate Profile March 2002

typically easy to spoof, and in some cases the two parties to a
transaction may not agree on the IP addresses being used (e.g., if
the Acceptor is on a host that uses NAT, the Acceptor and the PA may
disagree about the Acceptor's IP address).

Another suggestion was, in those cases where domain information is
needed, to require that the subject names of all End Entities
involved (the Acceptor(s) and the End Entity that appears in a PC's
certificate path) include domain information.

6.8

6.7 Delegation Tracing vs. Usage Tracing

Delegation tracing provides information about whom a certificate was
delegated to, but it does not provide any information about who
actually used the certificate. That is, if Entity A delegates a
certificate to Entity B, and then Entity C somehow acquires the
certificate and private key and delegates to Entity D, and so on:

A delegates PC1 to B
C delegates PC2 to D
E delegates PC3 to F
G uses PC3

In this diagram, A has used A's identity certificate to create proxy
certificate PC1 and delegate it to B. C has (somehow) acquired PC1
and its private key, and used it to sign PC2 and delegate PC2 to D.
E has acquired PC2 and its private key, and used it to sign PC3 and
delegate PC3 to F. Finally, G has acquired a copy of PC3 and its
private key, and used it to authenticate to some relying party.

If the relying party wishes to audit who has been involved in the
use of this certificate, it can determine A's identity (by using the
certificate chain), and G's identity (by requirint requiring that anyone using
a proxy certificate also present proxy certificate also present an identity certificate).

If each proxy certificate includes a DelegationTracing extension,
the relying party has the identities B, D, and F available to it --
but it has no indication that C or E were involved. Another
approach towards auditing the usage of a certificate would be to
provide a usage tracing extension that would include the issuer's
signature of the certificate (using the issuer's identity
certificate); this would make the identities C and E (but not B, D,
or F) available to the relying party.

6.8 Contents of X509AcceptorInfo

The X509AcceptorInfo field contains a signature using the Acceptor's
private key, plus some additional information that a relying party
can use to identify the Acceptor's certificate. There have been
various suggestions about how much additional information should be
included in this field, ranging from simply including the Acceptor's
subject name (or subjectAltName) to including all certificates used
by the issuer when doing path validation on the Acceptor's
certificate.

Tuecke, et. al. Expires February 2002 30
Internet Draft X.509 Proxy Certificate Profile March 2002

Currently, the X509AcceptorInfo field contains the Acceptor's name
(or subjectAltName) and the signature from the Acceptor's
certificate. This is enough information to uniquely identify a
certificate, but in itself does not necessarily convey any
meaningful information about the Acceptor's identity (especially if
the Acceptor certificate is itself a Proxy certificate). Another
approach would be to include the sequence of names from a valid
certificate path for the Acceptor's certificate.

6.9 Certificate Policies Extension

One could imagine some interesting things to do with the Certificate
Policies extension. For example:

* One could define policies for creation of a Proxy Certificate.
For example, was the PC created locally or remotely?

* An alternate approach to defining restricted Proxy Certificates
would be use the Certificate Policies extension to carry the OIDs
of various Proxy Certificate Policies. For example, a Proxy
Certificate policy might state that the PC can only be used
within a limited scope of machines, or for a limited set of uses.

6.10 Kerberos 5 Tickets

The Kerberos Network Authentication Protocol (RFC 1510 [9]) 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 impersonation 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 can be used to provide single sign-on in an X.509 PKI based
system, just as creation of short-lived TGT allows for single sign-
on in a Kerberos based system. And just as a TGT can be forwarded
(i.e. delegated) to another entity to allow for impersonation in a
Kerberos based system, so can a PC can be delegated to allow for
impersonation in an X.509 PKI based system.

A major difference between a Kerberos TGT and an X.509 PC is that
while creation and delegation of a TGT requires the involvement of a
third party (the Kerberos Domain Controller), a PC can be
unilaterally created without the active involvement of a third
party. That is, a user can directly create a PC from an EEC for
single sign-on capability, without requiring communication with a
third party. And an identity certificate).

If each proxy certificate includes entity with a DelegationTracing extension,
the relying party has PC can delegate the identities B, D, and F available PC to it --
but it has no indication that C or E were involved. Another
approach towards auditing another
entity (i.e. by creating a new PC, signed by the usage of first) without
requiring communication with a certificate would be third party.

The method used by Kerberos implementations to
provide protect a usage tracing extension that would include the issuer's
signature of the certificate (using the issuer's identity
certificate); this would make the identities C and E (but not B, D,
or F) available TGT can
also be used to protect the relying party. private key of a PC. For example, some
Unix implementations of Kerberos use standard Unix file system

Tuecke, et. al. Expires February 2002 27 31
Internet Draft X.509 Proxy Certificate Profile August 2001

6.9 Contents of X509AcceptorInfo

The X509AcceptorInfo field contains March 2002

security to protect a signature using user's TGT from compromise. Similarly, the Acceptor's
private key, plus some additional information that
Globus Toolkit's Grid Security Infrastructure implementation of
Proxy Certificates protects a relying party user's PC private key using this same
approach.

Looking at developments with Kerberos 5 tickets also can use to identify the Acceptor's certificate. There have been
various suggestions inform us
about how much additional information should be
included in this field, ranging from simply including the Acceptor's
subject name (or subjectAltName) to including all certificates used
by the issuer when doing path validation on the Acceptor's
certificate.

Currently, the X509AcceptorInfo field contains potential future directions for Proxy Certificates. For
example:

* Kerberos tickets have two simple mechanisms for allowing their
use to be restricted: a time period during which the Acceptor's name
(or subjectAltName) ticket is
valid (the "starttime" and "endtime" fields of a ticket), and a
host address which restricts the signature from host on which the Acceptor's
certificate. This is enough information to uniquely identify ticket may be
used (the "caddr" field of a
certificate, ticket). An X.509 PC also has a
validity period, but in itself does not necessarily convey any
meaningful information about the Acceptor's identity (especially if
the Acceptor certificate is itself have a Proxy certificate). Another
approach would host restriction field,
though it could be to include the sequence easily added via an X.509 extension. While
these particular restrictions have a variety of names from limitations and
problems, they points toward a valid
certificate path for the Acceptor's certificate.

6.10 Certificate Policies Extension

One could imagine some interesting things to do with the Certificate
Policies extension. For example:

* One could define policies for creation future of more general restriction
policies that might be included in a Proxy Certificate.
For example, was the PC created locally or remotely? and/or Kerberos 5 ticket.

* An alternate approach to defining restricted Proxy Certificates
would be use The Microsoft implementation of Kerberos 5 has (not without
controversy) used the Certificate Policies extension "authorization-data" field in the Kerberos
ticket to carry encode authorization information into the OIDs
of various ticket. A
similar approach could be taken with X.509 Proxy Certificate Policies. For example, Certificates, by
encoding the authorization information into an X.509 extension in
a PC. This approach allows for a user's normal, long-lived
identity certificate to be used to create a Proxy
Certificate policy might state short-lived
authorization certificate that the PC can only be used
within a limited scope of machines, or for a limited set delegated as necessary.
Merits of uses. this approach versus Attribute Certificates are
discussed in Section 5.

6.11 Kerberos 5 Tickets

The Kerberos Network Authentication Protocol (RFC 1510 [9]) is a
widely used authentication system based on conventional (shared
secret key) cryptography. It provides support for single sign-on
via creation Examples of "Ticket Granting Tickets" or "TGT", and support for
delegation usage of impersonation rights via "forwardable tickets".

Kerberos 5 tickets have informed many Proxy Groups and Restrictions

This section gives some examples of the ideas surrounding X.509 Proxy Certificates. For example, the local creation Certificate usage and some
examples of a short-
lived PC how Proxy Restrictions and Proxy Groups can be used to provide single sign-on in an X.509 PKI based
system, just as creation
restrict Proxy Certificates.

6.11.1 Example One: Use of short-lived TGT allows for single sign-
on in a Kerberos based system. And just as proxies without Groups or Restrictions

Steve wishes to perform a TGT can be forwarded
(i.e. delegated) third-party FTP transfer between two FTP
servers. Steve would use an existing PC to another entity authenticate to allow for impersonation in both
servers and delegate a
Kerberos based system, so can PC to both hosts. When the servers establish
the data channel connection to each other, they use these delegated
credentials to perform self-authentication and secure the channel.

6.11.2 Example Two: Use of proxies with Groups

Steve wants to again perform a third-party FTP transfer and he wants
to use Proxy Groups to provide extra security. As in the previous
example, Steve would use his existing PC can be to authenticate to both
servers. However when he delegates PCs to the servers he would assign
both PCs to the same, detached subgroup. The servers use these
delegated credentials to allow for
impersonation in an X.509 PKI based system.

A major difference between a Kerberos TGT and an X.509 authenticate each other over the data
channel, each verifying the other�s PC is that
while creation and delegation of a TGT requires the involvement of a
third party (the Kerberos Domain Controller), in a PC can be compatible group.

Tuecke, et. al. Expires February 2002 28 32
Internet Draft X.509 Proxy Certificate Profile August 2001

unilaterally created without the active involvement of a third
party. That is, a user can directly create a PC from an EEC for
single sign-on capability, without requiring communication with a
third party. And an entity with a PC can delegate the PC to another
entity (i.e. by creating a new PC, signed by the first) without
requiring communication with a third party. March 2002

The method used by Kerberos implementations to protect a TGT can
also be used to protect proxy groups in the private key of a PC. For example, some
Unix implementations above example provide two forms of Kerberos use standard Unix file system
security to protect a user's TGT from compromise. Similarly,
protection. First since each server verifies the
Globus Toolkit's Grid Security Infrastructure implementation of
Proxy Certificates protects a user's PC private key using this same
approach.

Looking at developments with Kerberos 5 tickets also can inform us
about potential future directions for Proxy Certificates. For
example:

* Kerberos tickets Group of the
other server, they have two simple mechanisms for allowing their
use assurance they are interacting with another
task that Steve has intended them to be restricted: interact with. Second it
provides a time period during which limited form of restriction in case one of the ticket delegated
PCs is
valid (the "starttime" stolen.

6.11.3 Example Three: Use of proxies with Groups and "endtime" fields Restrictions

Steve wishes to delegate to a process the right to perform a third-
party transfer of a ticket), and file on his behalf. Steve would delegate a
host address which restricts PC to
the host process and he would use Proxy Restrictions to limit the
delegated PC to two rights � the right to read file F1 on which host H1 and
the ticket may be
used (the "caddr" field of a ticket). An X.509 right to write file F2 on host H2.

The process then uses this restricted PC to authenticate to servers
H1 and H2. The process would also has a
validity period, but does not have delegate a host restriction field,
though it could be easily added via an X.509 extension. While PC to both servers,
placing both PCs in the same detached subgroup. Note that these particular
delegated PCs would inherit the restrictions have a variety of limitations their parents, though
this is not relevant to this example.

Now when the process issues the command to transfer the file F1 on H1
and
problems, they points toward a future of more general restriction
policies that might be included to F2 on H2, these two servers perform an authorization check, in a PC and/or Kerberos 5 ticket.

* The Microsoft implementation of Kerberos 5 has (not without
controversy) used
addition to any local policy they have, based on the "authorization-data" field restrictions in
the Kerberos
ticket to encode authorization information into PC that the ticket. A
similar approach could be taken process used to authenticate with X.509 Proxy Certificates, by
encoding the authorization information into an X.509 extension in
a PC. This approach allows for a user's normal, long-lived
identity certificate them. Namely H1
checks that the PC gives the user the right to be used read F1 and H2 checks
that the PC gives the user the right to create a short-lived
authorization certificate write F2.

The extra security provided by these restrictions is that can be now if the
PC delegated to the process by Steve is stolen, its use is greatly
limited.

The servers would then check the proxy groups when setting up and
authenticating each over the data channel as necessary.
Merits of this approach versus Attribute Certificates are
discussed explained in Section 5. Example
Two.

7 Security Considerations

A Proxy Certificate is generally less secure than the EEC that
issued it. This is due to the fact that the private key of a PC is
generally not protected as rigorously as that of the EEC. For
example, the private key of a PC is often protected using only file
system security, in order to allow that PC to be used for single
sign-on purposes. This makes the PC more susceptible to compromise.

However, the risk of a compromised PC is only the misuse of a single
user's privileges. Due to the path validation checks made on a PC,
a PC cannot be used to sign an EEC or PC for another user.

Tuecke, et. al. Expires February 2002 29
Internet Draft X.509 Proxy Certificate Profile August 2001

Further, a compromised PC can only be misused for the lifetime of
the PC, and within the bound of the restriction policy carried by
the PC. Therefore, one common way to limit the misuse of a
compromised PC is to limit their its validity periods period to no longer than is needed.

Tuecke, et. al. Expires February 2002 33
Internet Draft X.509 Proxy Certificate Profile March 2002

needed, and/or to include a restriction policy in the PC that limits
the use of the (compromised) PC.

In addition, if a PC is compromised, it does NOT compromise the EEC
that created the PC. This property is of great utility in
protecting the highly valuable, and hard to replace, public key of
the EEC. In other words, the use of Proxy Certificates to provide
single sign-on capabilities in an X.509 PKI environment can actually
increase the security of the end entity certificates, because
creation and use of the PCs for user authentication limits the
exposure of the EEC private key to only the creation of the first
level PC.

The pCPathLenConstraint field of the proxyCertInfo extension can be
used by an EEC to limit subsequent delegation of the PC. A service
may choose to only authorize a request if a valid PC can be
delegated to it. An example of such as service is a job starter,
which may choose to reject a job start request if a valid PC cannot
be delegated to it. By limiting the pCPathLenConstraint, an EEC can
ensure that a compromised PC of one job cannot be used to start
additional jobs elsewhere.

An EEC or PC can limit what a new PC can be used for by turning off
bits in the Key Usage and Extended Key Usage extensions. However,
once a key usage or extended key usage has been removed, the path
validation algorithm ensures that it cannot be added back in a
subsequent PC. In other words, key usage can only be decreased in
PC chains.

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

The relying party that is going to authorize some actions on the
basis of a PC will be aware that it has been presented with a PC,
and can determine the depth of the delegation and the time that the
delegation took place and any entities through which the PC was
delegated (if the optional DelegationTrace extension is included in
the PCs in the cert chain). It may want to use this information in
addition to the information from the signing EEC. Thus a highly
secure resource might refuse to accept a PC at all, or maybe only a
single level of delegation, or maybe only a PC that has not been
delegated through a untrusted host, etc.

8 References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.

[2] Butler, R., D. Engert, I. Foster, C. Kesselman, and S. Tuecke,
"A National-Scale Authentication Infrastructure," IEEE
Computer, vol. 33, pp. 60-66, 2000.

Tuecke, et. al. Expires February 2002 30 34
Internet Draft X.509 Proxy Certificate Profile August 2001 March 2002

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

[4] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization," Internet Draft draft-ietf-pkix-
ac509prof-06.txt, January 2001.

[5] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A Security
Architecture for Computational Grids," presented at Proceedings
of the 5th ACM Conference on Computer and Communications
Security, 1998.

[6] Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy of the
Grid: Enabling Scalable Virtual Organizations," International
Journal of Supercomputer Applications, 2001.

[7] Housley, R., W. Ford, W. Polk, and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile,"
Internet Draft draft-ietf-pkik-new-part1-08.txt draft-ietf-pkik-new-part1-12.txt (update to RFC
2459), July 2001. January 2002.

[8] Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation
Protocol," Internet Draft draft-ietf-tls-delegation-00.txt,
2001.

[9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)," RFC 1510, September 1993.

9 Acknowledgments

We are grateful to numerous colleagues for discussions on the topics
covered in this paper, in particular (in alphabetical order, with
apologies to anybody we've missed): Joe Bester, Randy Butler, Keith
Jackson, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Meder,
Clifford Neuman, Gene Tsudik, Von Welch. Tsudik.

This work was supported in part by the Mathematical, Information,
and Computational Sciences Division subprogram of the Office of
Advanced Scientific Computing Research, U.S. Department of Energy,
under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense
Advanced Research Projects Agency under contract N66001-96-C-8523;
by the National Science Foundation; and by the NASA Information
Power Grid project.

10 Change Log

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

Initial submission.

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

Tuecke, et. al. Expires February 2002 31 35
Internet Draft X.509 Proxy Certificate Profile August 2001 March 2002

Renamed to "Proxy Certificate", from "Impersonation Certificate",
due to overwhelming feedback from IETF and GGF.

Added proxyRestriction field to ProxyCertInfo extension.

Added delegationTrace field to ProxyCertInfo extension.

Updated to agree with draft-ietf-pkix-part1-08.

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

Changes related to delegation tracing: removed delegationTrace
field from ProxyCertInfo extension, created DelegationTrace
extension, added and modified commentary sections related to
delegation tracing.

Added issuerCertHash to proxyCertInfo extension and to 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 to reflect draft-pkix-new-
part1-07.

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

Draft for IETF.

Same version number (-02) as February 2002 for GGF4 but with
changes.

Globally changed �Proxy Authority� to �Proxy Issuer�.

Changed example 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 are now not present PCs.

Renamed issuerCertHash to issuerCertSignature and similarly with
it�s contents.

Added consideration to path validation for PC�s with an infinite
path length (i.e. no pCPathLenConstraint).

Tuecke, et. al. Expires February 2002 36
Internet Draft X.509 Proxy Certificate Profile March 2002

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

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

Ian Foster
Argonne National Laboratory & University of Chicago
Email: foster@mcs.anl.gov

Von Welch
University of Chicago
Email: welch@mcs.anl.gov

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

Laura Pearlman
University of Southern California, Information Sciences Institute
Email: laura@isi.edu

Carl Kesselman
University of Southern California, Information Sciences Institute
Email: carl@isi.edu

Tuecke, et. al. Expires February 2002 32 37
----