view Side-By-Side changes
Internet Draft S. Tuecke
Document: draft-ietf-pkix-proxy-02.txt draft-ietf-pkix-proxy-04 D. Engert
I. Foster
Initial Version March 2001 ANL
Revised October 2002 V. Welch
Expires April 2003 U. Chicago
M. Thompson
LBNL
L. Pearlman
C. Kesselman
USC/ISI
Expires: August 2002 February 2002
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.
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.
This document provides information to the community
regarding the profile of the X.509 Proxy Certificate. It
tuecke@mcs.anl.gov 1
X.509 Proxy Certificate Profile February 2003
Expires August 2003
defines a standard for implementing X.509 Proxy
Certificates.
Abstract
This document forms a certificate profile for Proxy
Certificates, based on X.509 PKI certificates as defined
in draft-ietf-pkix-new-
part1-12.txt (the draft update to RFC 2459), 3280, for use in the Internet. The term Proxy
Certificate is used to describe a certificate that is
derived from, and signed by, a normal X.509 Public Key End
Entity Certificate or by another Proxy Certificate for the
purpose of providing restricted impersonation within a PKI
based authentication system.
Tuecke, et. al. Expires February 2002 1
Internet Draft X.509 Proxy Certificate Profile 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...................................................4 Introduction.........................................3
2 Overview of Approach...........................................5 Approach.................................5
2.1 Terminology..................................................5 Terminology..........................................5
2.2 Background...................................................5 Background...........................................6
2.3 Motivation for Impersonation.................................6 Impersonation.........................7
2.4 Motivation for Proxy Restrictions............................8 Restricted Proxies....................9
2.5 Motivation for Unique Proxy Groups..................................8 Name....................10
2.6 Description Of Approach......................................9 Approach.............................11
2.7 Proxy Issuer, not Certificate Authority.....................10
2.8 Names Versus Subjects.......................................11
2.9 Features Of This Approach...................................11 Approach...........................13
3 Certificate and Certificate Extensions Profile................13 Profile......15
3.1 Issuer & Issuer..............................................15
3.2 Issuer Alternative Name............................13
3.2 Serial Number...............................................13 Name.............................15
3.3 Subject & Serial Number.......................................15
3.4 Subject.............................................16
3.5 Subject Alternative Name..........................13
3.4 Name............................16
3.6 Key Usage...................................................14
3.5 Usage...........................................16
3.7 Extended Key Usage..........................................14
3.6 Usage..................................17
3.8 Basic Constraints...........................................15
3.7 Proxy Certificate Information...............................15
3.7.1 Constraints...................................18
3.9 The ProxyCertInfo Extension................................15
3.7.2 The DelegationTrace Extension..............................19 Extension.........................18
4 Proxy Certificate Path Validation...................22
4.1 Basic Proxy Certificate Path Validation.............24
4.2 Using the Proxy Certificate Path Validation...................................21 Validation Algorithm29
5 Commentary..........................................30
5.1 Relationship to Attribute Certificates........................24
5.1 Types of Attribute Authorities..............................25 Certificates..............30
5.2 Delegation Using Attribute Certificates.....................25 Kerberos 5 Tickets..................................35
5.3 Propagation Examples of usage of Authorization Information....................26
5.4 Proxy Restrictions.............36
tuecke@mcs.anl.gov 2
X.509 Proxy Certificate as Attribute Certificate Holder...........27 Profile February 2003
Expires August 2003
5.4 Delegation Tracing..................................37
6 Commentary....................................................27 Security Considerations.............................38
6.1 keyCertSign Bit in the Key Usage Basic Extension............27
6.2 nonRepudiate Bit in the Key Usage Basic Extension...........28
6.3 Carrying Along the End Entity Subject.......................28
6.4 Specifying Proxy Restrictions...............................29
6.5 Compromise of a Proxy Restrictions vs. Certificate...................38
6.2 Restricting Proxy Rights.........................29
6.6 Site Information in Delegation Tracing......................29
6.7 Delegation Tracing vs. Usage Tracing........................30
6.8 Contents of X509AcceptorInfo................................30
6.9 Certificate Policies Extension..............................31
6.10 Kerberos 5 Tickets.........................................31
6.11 Examples of usage Certificates......................39
6.3 Relying Party Trust 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 Certificates...........40
7 Security Considerations.......................................33 References..........................................40
8 References....................................................34 Acknowledgments.....................................41
9 Acknowledgments...............................................35
10 Change Log..................................................35
11 Log..........................................42
10 Contact Information.........................................37
Tuecke, et. al. Expires February 2002 2
Internet Draft X.509 Proxy Certificate Profile March 2002
Tuecke, et. al. Expires February 2002 3
Internet Draft X.509 Proxy Certificate Profile March 2002 Information.................................46
11 Copyright Notice....................................47
12 Intellectual Property Statement.....................48
Appendix A. 1988 ASN.1 Module..........................48
1 Introduction
Use of a proxy credential credential[10] 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, 3280, "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile" [7].
In addition to simple, unrestricted impersonation, this
profile
defines a defines:
* A framework for carrying restriction policies in Proxy
Certificates, thus allowing a restriction Certificates
that allow impersonation to be limited (perhaps
completely disallowed) through either restrictions or
enumeration of the rights an
impersonating entity is given. Further, when delegating a rights.
* Proxy
Certificate Certificates with unique names, derived from one the
name of the end entity certificate name. This allows
the Proxy Certificates to another, this profile defines
information that can be optionally included used in a Proxy Certificate
to allow for tracing conjunction with
attribute assertion approaches such as Attribute
Certificates [4] and have their own rights independent
of the delegation path. their issuer.
Section 2 provides an a non-normative overview of the
approach. It begins by defining terminology, motivating
Proxy Certificates, and giving a brief overview of the
approach. It then introduces the notion of a Proxy
tuecke@mcs.anl.gov 3
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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. Two A new
certificate extensions, extension, Proxy Certificate Information and Delegation
Trace, are Information, is
introduced.
Section 4 defines path validation rules for Proxy
Certificates.
Section 5 discusses the relationship of Proxy Certificates to
Attribute Certificates.
Section 6 provides non-normative commentary on various design choices, open
issues, related work, and future directions. Proxy
Certificates.
Section 7 6 discusses security considerations relating to
Proxy Certificates.
Section 8 7 contains the references.
Section 9 8 contains acknowledgements.
Tuecke, et. al. Expires February 2002 4
Internet Draft X.509 Proxy Certificate Profile March 2002
Section 10 9 contains a log of changes made in each version
of this draft.
Section 11 10 contains contact information for the authors.
Section 11 contains the copyright information for this
document.
Section 12 contains the intellectual property information
for this document.
tuecke@mcs.anl.gov 4
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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.
http://www.gridforum.org/2_SEC/GSI.htm.
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
This section provides non-normative commentary on Proxy
Certificates.
The goal of this specification is to develop a X.509 Proxy
Certificate profile, profile and to facilitate their use within
Internet applications for those communities wishing to
make use of restricted impersonation and delegation 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.
tuecke@mcs.anl.gov 5
X.509 Proxy Certificate Profile February 2003
Expires August 2003
* PI: A "Proxy Issuer" is the End Entity Certificate or
Proxy Certificate that issued a Proxy Certificate, as defined below. Certificate.
* 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 5
Internet Draft X.509 Proxy Certificate Profile 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
restricted 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.
tuecke@mcs.anl.gov 6
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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, engineer who wants to use a reliable file
transfer service to manage the movement of a number of
large files around between various hosts on his company's
Intranet-based Grid. From his laptop he wants to submit a
number of transfer requests to the
service, service and have the
files transferred while he is doing other things,
including being offline. The transfer service may queue
the requests for some time (e.g. until after hours or a
period of low resource usage) before initiating the
transfers. The transfer service will then, for each file,
connect to each of the source and destination hosts, and
instruct them initiate a data connection directly from the
source to the destination in order to transfer the file. Later,
Steve will reconnect to leave an agent running on his laptop that will
periodically check on progress of the
service to verify transfer by contacts
the transfers succeeded. transfer service. Of course, he wants all of this to
happen securely on his company's resources, which requires
that he initiate all of this using his PKI smartcard.
This scenario requires authentication and delegation in a
variety of places:
* Steve needs to be able to mutually authenticate with
the remote file transfer service to submit the transfer
request.
* The Since the storage hosts know nothing about the file
transfer service, the file transfer service needs to be
delegated the rights to mutually authenticate with the
various storage hosts involved directly in the file
transfer, in order to initiate the file transfer.
* The source and destination hosts of a particular
transfer must be able to mutual authenticate with each
other, to ensure the file
Tuecke, et. al. Expires February 2002 6
Internet Draft X.509 Proxy Certificate Profile March 2002 is being transferred to and
from the proper parties.
tuecke@mcs.anl.gov 7
X.509 Proxy Certificate Profile February 2003
Expires August 2003
* When Steve later reconnects his laptop to the network, a program The agent running on the Steve's laptop must mutually
authenticate with the file transfer service in order to
check the result of 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 submit all the file transfer requests to the
transfer service. service, and then periodically check on the
status of the transfer. This program needs to be given
the rights to be able to perform all of these
operations securely, without requiring repeated access
to the smartcard or Steve's password.
* Delegation: Various remote processes in this scenario
need to perform secure operations on Steve's behalf,
and therefore must be delegated the necessary rights.
For example, the file transfer service needs to be able
to authenticate on Steve's behalf with the source and
destination hosts, and must in turn delegate rights to
those hosts so that they can authenticate with each
other.
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 client client/agent program to impersonate Steve (that is,
authenticate as Steve) when submitting the requests to
the transfer service. Access to the smartcard and
Steve's password is not required after the initial
creation of the impersonation credential.
* The client program on the laptop can delegate to the
file transfer service the right to impersonate Steve.
This, in turn, allows the service to authenticate to
the storage hosts as if it were Steve in order to start
the file transfers.
tuecke@mcs.anl.gov 8
X.509 Proxy Certificate Profile February 2003
Expires August 2003
* When the transfer service authenticates to hosts to
start the file transfer, the service can delegate to
the hosts the right to impersonate Steve so that each
pair of hosts involved in a file transfer can mutually
authenticate to ensure the file is securely
transferred.
* When the agent on the laptop reconnects to the file
transfer service to verify check on the status of the transfers succeeded,
transfer, it can perform mutual authentication. The
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 Restricted Proxies
One concern that arises is what happens if a machine that
has been 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. impersonation by means of policies on the
proxy certificates. For example, the machine running the
reliable file transfer service in the above example might
only be given the right to impersonate Steve for the
purpose of reading the source files and writing the
destination files. Therefore, if that file transfer
service is compromised, the attacker cannot modify source
files, cannot create or modify other files to which Steve
has access, cannot start jobs on behalf of Steve, etc.
All that an attacker would be able to do is read the
specific files to which the file transfer service has been
tuecke@mcs.anl.gov 9
X.509 Proxy Certificate Profile February 2003
Expires August 2003
delegated read access, and write bogus files in place of
those that the file transfer service has been delegated
write access. Further, by limiting the lifetime of the
credential that is delegated to the file transfer service,
the effects of a compromise can be further mitigated.
Other potential uses for restricted proxy credentials are
discussed in [10].
2.5 Motivation for Unique Proxy Groups
A user will often wish to delegate authority to many tasks running on
his or her behalf, which may in turn delegate authority to subtasks, Name
The dynamic creation of entities (e.g. processes and so forth.
services) is an essential part of Grid computing. These tasks
entities 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 to mitigate the
potential effects of accidental or malicious misuse of the delegated
credentials. For example, one group of tasks performing a
distributed computation should be able require rights in order to securely interact with each
other using perform
their delegated credentials from the user, but should not
be able function. While it is possible to interact with tasks involved obtain rights
solely through impersonation as described in an unrelated file transfer
of the same user. Thus, previous
sections, this has limitations. For example what if an attacker compromises one of the tasks
of the distributed computation, only
entity should have rights that distributed computation can
be affected. The attacker would are granted not be able to use the compromised
credential just from
the distributed computation to attack the file
transfer. proxy issuer but from a third party as well? While it
is in theory possible to implement in this functionality using
Proxy Restrictions, case for the complexity of interactions of processes in a
task often makes enumerating a list of restrictions cumbersome entity to obtain and
potentially impossible beforehand due hold
two proxy certifications, in practice it is simpler for
subsequent credentials to lack take the form of complete knowledge.
A solution attribute
certificates.
It is also desirable for these entities to allow delegated proxy credentials to have a unique
identity so that they can be assigned to
groups, and then limit interactions between processes based on these
proxy groups.
Tuecke, et. al. Expires February 2002 8
Internet Draft X.509 Proxy Certificate Profile March 2002 explicitly discussed in
policy statements. For example, in the example in section 2.3, a host involved in
transferring user initiating a single file needs to be able to securely interact third-
party FTP transfer could grant each FTP server a PC with a
unique identity and inform each server of the other host involved in identity of
the transfer. However, other, then when the host does not
need to, two servers connected they could
authenticate themselves and hence should not be able to, interact with other hosts
involved in other transfers. By putting know they are connected to the proxies delegated
proper party.
In order for a party to
each pair have rights of hosts involved in a transfer into their it's own it
requires a unique
group, identity. Possible options for obtaining
an unique identity are:
1) Obtain an identity from a traditional Certification
Authority (CA).
2) Obtain a new identity independently - for example by
using the transfer service generated public key.
tuecke@mcs.anl.gov 10
X.509 Proxy Certificate Profile February 2003
Expires August 2003
3) Derive the new identity from an existing identity.
In this document we use method #3, because:
* It is able to limit these hosts to only reasonably light-weight, as it can be
able to interact done
without interacting with each other. Thus, an attacker who a third party. This is able
important when creating identities dynamically.
* As described in the previous section, a common use for
PCs is for restricted impersonation, so deriving their
identity from the identity of the EEC makes this
straightforward. Nonetheless there are circumstances
where the creator does not wish to
gain access delegate all or any
of its rights to a new entity. Since the delegated credential on one of these hosts name is only
able to affect that one transfer, but
unique, this is prevented from interfering
with other transfers easily accomplished by that same user. #3 as well, by
allowing the application of a policy to limit
impersonation.
2.6 Description Of Approach
This document defines an X.509 "Proxy Certificate" or "PC"
as a means of providing for restricted impersonation
within an (extended) X.509 PKI based authentication
system.
A Proxy Certificate is an X.509 public key certificate
with the following properties:
1) It is signed by either an X.509 End Entity Certificate
(EEC), or by another PC. This EEC or PC is referred to
as the Proxy Issuer (PI).
2) It can sign only another PC. It cannot sign an EEC.
3) It has its own public and private key pair, distinct
from any other EEC or PC.
4) It has no distinct an identity derived from the identity of its own. After the EEC
that signed the PC. When a PC is used for
authentication, the identity that is used for authorization is
that in may inherit rights of the EEC that
signed the PC. The PC, subject to the restrictions that are
placed on that PC effectively inherits by the subject and/or subjectAltName from its signing EEC.
tuecke@mcs.anl.gov 11
X.509 Proxy Certificate Profile February 2003
Expires August 2003
5) Although its identity is derived from the EEC's
identity, it is also unique. This allows this identity
to be used for authorization as an independent identity
from the identity of the issuing EEC, for example in
conjunction with attribute assertions as defined in
[4].
6) It contains a new X.509 extension to identify it as a
PC and to place restrictions policies on the use of the PC. This
new extension, along with other X.509 fields and
extensions, are used to enable proper path validation
and use of the PC.
The process of creating a PC is as follows:
1) A new public and private key pair is generated.
2) That key pair is used to create a request for a Proxy
Certificate that conforms to the profile described in
this document.
3) A Proxy Certificate, signed by the private key of the
EEC or by another PC, is created in response to the
request. During this process, the PC request is
verified to ensure that the requested PC is valid (e.g.
it is not an EEC, the PC fields are appropriately set,
etc).
Tuecke, et. al. Expires February 2002 9
Internet Draft X.509 Proxy Certificate Profile March 2002
When a PC is created as part of a delegation from entity A
to entity B, this process is modified by performing steps
#1 and #2 within entity B, then passing the PC request
from entity B to entity A over an authenticated, integrity
checked channel, then entity A performs step #3 and passes
the PC back to entity B.
Path validation of a PC is very similar to normal path
validation, with a few additional checks to ensure, for
example, proper PC signing constraints. In order to make
the appropriate PC(s) and EEC available for path
validation, the authentication protocol using the PC (e.g.
TLS) may MAY pass the entire PC and EEC chain as part of the
authentication protocol.
2.7
tuecke@mcs.anl.gov 12
X.509 Proxy Issuer, not Certificate Authority
A common initial reaction against the approach described in this
document is, "You are using 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: The CA assigns a (generally unique) "Name" to the end
entity Profile February 2003
Expires August 2003
2.7 Features Of This Approach
Using Proxy Certificates to which perform delegation has several
features that make it issues an EEC. This Name is contained in the
subject or subjectAltName field attractive:
* Ease of the issued EEC.
2) Key integration
. Because a PC requires only a minimal change to Name binding: By singing an EEC with the CA's private key,
the CA path
validation, it is providing a means very easy to allow an authenticating party incorporate support
for Proxy Certificates into existing X.509 based
software. For example, SSL/TLS requires no protocol
changes to
verify that the holder of a particular private key should be
associated with (bound to) a particular Name.
In addition, support authentication using a CA usually has PC.
Further, an associated Registration Authority,
which performs the checks necessary SSL/TLS implementation requires only
minor changes to bind the Name support PC path validation, and to
retrieve the real
world entity (e.g. person, computer, etc) that is to be authenticated subject of the bearer signing
EEC instead of that Name.
The reason for doing all the subject of this is to allow the PC for
authorization
decisions to be made, based at least in part on these CA issued
Names. In other words, after purposes.
. Many existing authorization systems use the public key authentication
operation has determined X.509
subject name as the Name of basis for access control. Proxy
Certificates that perform impersonation can be used
with such authorization systems without
modification, since such a PC inherits its name and
rights from the authenticating party, then EEC that Name signed it and the EEC name
can be used as in place of the basis PC name for deciding what the entity is
allowed
authorization decisions.
* Ease of use
. Using PC for single sign-on helps make X.509 PKI
authentication easier to do. (Note: Attribute certificates are discussed below.)
The critical difference between using an EEC use, by allowing users to sign a Proxy
Certificate, versus using an
"login" once and then perform various operations
securely.
. For many users, properly managing their own EEC to sign another EEC,
private key is that a
Proxy Certificate does NOT define nuisance at best, and a new Name. Rather, security
risk at worst. One option easily enabled with a Proxy
Certificate inherits the name from PC
is to manage the EEC that signs it. The next
section describes this inheritance private keys and certificates
in more detail.
In effect, a centrally managed repository. When a user
needs a PKI credential, the PC simply provides another route user can login to validating the
Key to Name binding that
repository using name/password, one time password,
etc. Then the CA has established with an EEC. A repository can delegate a PC
allow an alternate Key' to bind to the same Name, optionally with
restrictions,
user with this Key' impersonation rights, but continue to Name binding vouched for by the
holder of
tuecke@mcs.anl.gov 13
X.509 Proxy Certificate Profile February 2003
Expires August 2003
protect the EEC private key. This allows key in the repository.
* Protection of private keys
. By using the remote delegation approach outlined
above, entity A can delegate a PC to give to
Tuecke, et. al. Expires February 2002 10
Internet Draft X.509 Proxy Certificate Profile March 2002 entity B,
without entity B ever seeing the ability to establish this binding, private key of
entity A, and thus allows B to
establish itself as a proper bearer without entity A ever seeing the
private key of A's Name.
For this reason, we use the term "Proxy Issuer", rather than
"Certificate Authority", to refer newly delegated PC held by entity
B. In other words, private keys never need to be
shared or communicated by the issuer of entities participating
in a Proxy
Certificates. A Proxy Issuer does not perform the Naming function delegation of a Certificate Authority, but rather just PC.
. When implementing single sign-on, using a Key to Name binding.
2.8 Names Versus Subjects
In X.509 certificates, PC helps
protect the subject (or subjectAltName) is used for
two distinct purposes:
1) In an End Entity Certificate, private key of the subject is EEC, because it
minimizes the Name exposure and use of that private key.
For example, when an EEC private key is password
protected on disk, the CA
has issued, as described in password and unencrypted
private key need only be available during the previous section. This Name is
typically used for authorization purposes.
2) In a CA Certificate,
creation of the subject is also PC. That PC can then be used for path validation.
That is, the issuer field in an EEC or CA Certificate must match
the subject field remainder of a CA Certificate, in order for the signing
path to be established.
As stated previously, a PC does not have its own Name, but rather it
inherits its Name from its signing valid lifetime, without
requiring access to the EEC (or more accurately, from password or private key.
Similarly, when the EEC that signed private key lives on a
smartcard, the first PC smartcard need only be present in the PC chain). In practice what
this means is that
machine during the subject field of a PC is only used for
purpose #2. The only purpose creation of the subject field PC.
* Limiting consequences of a PC is to
establish the signing path that eventually leads to an EEC.
The implication of this is that after compromised key
. When creating a PC is used for
authentication, PC, the PC subject should not be used for authorization.
Instead, PI can limit the validity
period of the PC, the depth of the PC signing chain should path that can
be followed to find the EEC created by that signed this PC, and key usage of the PC chain, and
its descendents. Further, fine-grained policies can
be carried by a PC to even further restrict the subject from
operations that EEC should can be
used as performed using the identity (or Name) for authorization purposes.
To discourage mistakes in this area, this Proxy Certificate profile
defines PC. These
restrictions permit the PI to limit damage that
could be done by the PC subject is just a set bearer of one or more unique
identifiers. Further, the subject of PC, either
accidentally or maliciously.
. A compromised PC private key does NOT compromise the
EEC is private key. This makes a short term, or an
otherwise restricted PC attractive for day-to-day
use, since a compromised PC does not maintained
anywhere in the PC, which forces require the authenticating party
user to
properly retrieve the subject from go through the EEC.
2.9 Features Of This Approach
Using usually cumbersome and time
tuecke@mcs.anl.gov 14
X.509 Proxy Certificates to perform delegation has several features
that make it attractive:
* Ease Certificate Profile February 2003
Expires August 2003
consuming process of integration
. Because a PC requires only having the EEC with a minimal change to path
validation, it is very easy to incorporate support new
private key reissued by the CA.
See Section 5 below for more discussion on how Proxy
Certificates into existing X.509 based software. For example,
SSL/TLS requires no protocol changes relate to support authentication
using a PC, Attribute Certificates.
3 Certificate and only small changes to support delegation of a
PC [8]. Further, an SSL/TLS implementation requires only
Tuecke, et. al. Expires February 2002 11
Internet Draft X.509 Proxy Certificate Extensions Profile March 2002
minor changes to support PC path validation, and to retrieve
This section defines the authenticated subject usage of the signing EEC instead X.509 certificate fields
and extensions in Proxy Certificates, and defines one new
extension for Proxy Certificate Information.
3.1 Issuer
The Proxy Issuer of the a Proxy Certificate MUST be either an
End Entity Certificate, or another Proxy Certificate.
The Proxy Issuer MUST NOT have an empty subject field.
The issuer field of a Proxy Certificate MUST contain the PC.
. Many existing authorization systems use the X.509
subject name
as the basis for access control. field of it's Proxy Certificates require
no change Issuer.
A Proxy Certificate MUST NOT be used to such authorization systems, since sign an End Entity
Certificate or a PC inherits
its name from the EEC that signed it.
* Ease CA Certificate.
3.2 Issuer Alternative Name
The issuerAltName extension MUST NOT be present in a Proxy
Certificate.
3.3 Serial Number
The serial number of use
. Using PC for single sign-on helps make X.509 PKI
authentication easier to use, a Proxy Certificate (PC) SHOULD be
unique amongst all Proxy Certificates issued 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
particular Proxy Issuer. However, a security risk at worst. One option
easily enabled with a PC is Proxy Issuer MAY use
an approach to manage the EEC private keys and
certificates in assigning serial numbers that merely
ensures a centrally managed repository. When high probability of uniqueness.
For example, a user
needs Proxy Issuer MAY use a PKI credential, the user can login to the repository
using name/password, one time password, etc. Then the
repository can delegate sequentially
assigned integer or a PC UUID to the user, but continue assign a unique serial
number to
protect the EEC private key in the repository.
* Protection of private keys
. By using the remote delegation approach outlined above, entity
A can delegate a PC to entity B, without entity B ever seeing
the private key of entity A, and without entity A ever seeing
the private key it issues. Or a Proxy Issuer MAY use a
SHA-1 hash of the newly delegated PC held by entity B.
In other words, private keys never need public key to be shared or
communicated by the entities participating in a delegation of assign a PC.
. When implementing single sign-on, using serial number
with a PC helps protect the
private key high probability of the EEC, because it minimizes the exposure and
use uniqueness.
tuecke@mcs.anl.gov 15
X.509 Proxy Certificate Profile February 2003
Expires August 2003
3.4 Subject
The subject field of that private key. For example, when an EEC private key a Proxy Certificate MUST be the
issuer field (that is password protected on disk, the password and unencrypted
private key need only be available during subject of the creation Proxy Issuer)
appended with a single Common Name component. The value
of the
PC. That PC can then Common Name SHOULD be unique amongst all Proxy
Certificates with the same issuer. However, the Proxy
Issuer MAY use an approach to assigning Common Name values
that merely ensures a high probability of uniqueness. This
value MAY be the same value used for the remainder serial number.
The result of its valid
lifetime, without requiring access to this approach is that all subject names of
Proxy Certificates should be derived from the EEC password or
private key. Similarly, when name of the
issuing EEC private key lives on a
smartcard, (it will be the smartcard need only first part of the subject name
appended with one or more CN components) and be unique.
3.5 Subject Alternative Name
The subjectAltName extension MUST NOT be present in a
Proxy Certificate.
3.6 Key Usage
If the machine
during issuer certificate includes the creation of keyUsage extension,
then the PC.
* Limiting consequences of a compromised key
. When creating Proxy Certificate MUST include a PC, keyUsage
extension, which MAY further restrict the PI can limit issuer's
keyUsage. The keyUsage extension MUST be critical if the validity period of
keyUsage extension in the PC, issuer certificate is marked
critical.
If the depth of issuer certificate does not include a keyUsage
extension, then the Proxy Certificate MAY include a
keyUsage extension to restrict 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 Proxy
Certificate.
If the keyUsage extension is present in a PC Proxy
Certificate, it MUST conform to
even further restrict the operations that can be performed
using the PC, and a set of PCs can following
restrictions:
. The keyCertSign bit MUST NOT be assigned to a proxy
group to limit interactions between that group and others.
Tuecke, et. al. Expires February 2002 12
Internet Draft asserted.
tuecke@mcs.anl.gov 16
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. February 2003
Expires August 2003
. A compromised PC private key does The nonRepudiate bit MUST 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 be asserted.
The following restriction applies to go through the
usually cumbersome and time consuming process each of having these
bits: digitalSignature, keyEncipherment,
dataEncipherment, keyAgreement, cRLSign,
encipherOnly, decipherOnly. If this bit in the
EEC with a new private key reissued by
issuer certificate is not asserted, then this bit in
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 MUST NOT be asserted. If this
bit in the usage of X.509 issuer certificate fields and
extensions in Proxy Certificates, and defines one new extension for
Proxy Certificate Information.
3.1 Issuer & Issuer Alternative Name
The Proxy Issuer of is asserted, or if the
issuer certificate does not include a keyUsage
extension, then this bit in the Proxy Certificate MUST
MAY be either an End Entity
Certificate, asserted or another Proxy Certificate.
An EEC acting as a Proxy Issuer must have a non-empty subject field.
The not asserted.
3.7 Extended Key Usage
If the issuer field of a certificate includes the extKeyUsage
extension, then:
The Proxy Certificate MUST contain the subject
field of it’s include an extKeyUsage
extension.
Any OID that is contained in the Proxy Issuer.
The issuerAltName Certificate's
extKeyUsage extension MUST NOT be present in a Proxy
Certificate.
3.2 Serial Number the issuer
certificate's extKeyUsage extension.
The serial number of a Proxy Certificate SHOULD be unique amongst
all Certificate's extKeyUsage extension MAY omit
any OID that is present in the issuer certificate's
extKeyUsage.
If the issuer certificate's extKeyUsage extension is
critical, then the Proxy Certificates issued by a particular Certificate's extKeyUsage MUST
be critical.
If the issuer certificate's extKeyUsage extension is
not critical, then the Proxy Issuer.
However, a Certificate's extKeyUsage
MAY be critical or non-critical.
If the issuer certificate does not include the extKeyUsage
extension, then the Proxy Issuer Certificate MAY use include an 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
extKeyUsage extension to a PC it issues. Or a PI MAY use
a SHA-1 hash of restrict the PC public key to assign a serial number with a
high probability of uniqueness.
3.3 Subject & Subject Alternative Name
The subject field usage of a the
Proxy Certificate. In this case, the extKeyUsage
extension MAY be critical or non-critical.
tuecke@mcs.anl.gov 17
X.509 Proxy Certificate Profile February 2003
Expires August 2003
3.8 Basic Constraints
The cA field in the basic constraints extension MUST NOT
be a sequence of one
or more proxy identifiers. TRUE.
3.9 The ProxyCertInfo Extension
A proxy identifier new extension, ProxyCertInfo, is a Common Name. The
value defined in this
subsection. Presence of the Common Name SHOULD be unique amongst all Proxy
Certificates issued by ProxyCertInfo extension
indicates that a certificate is a particular Proxy Issuer. However, Certificate and
whether or not the
Proxy Issuer MAY use an approach to assigning Common Name values
that merely ensures a high probability issuer of uniqueness. This value MAY
be the same value used for the serial number.
Tuecke, et. al. Expires February 2002 13
Internet Draft X.509 Proxy Certificate Profile March 2002 certificate has placed
any restrictions on its use.
id-ce-proxy-cert-info OBJECT IDENTIFIER ::= { id-ce ?? }
ProxyCertInfo ::= SEQUENCE {
version INTEGER (0..MAX),
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
If the Proxy Issuer of a PC certificate is an EEC, a Proxy Certificate, then the subject field
proxyCertInfo extension MUST be a
single proxy identifier. present, and this
extension MUST be marked as critical.
If the Proxy Issuer of a PC certificate is another PC, not a Proxy Certificate, then the subject field
proxyCertInfo extension MUST not be
the concatenation present.
The ProxyCertInfo extension consists of one required and
four optional fields, which are described in detail in the subject field
following subsections.
3.9.1 version
The version of the this specification that this PC conforms
to. Currently this value MUST be 1. Future revisions of
this specification MAY change this.
tuecke@mcs.anl.gov 18
X.509 Proxy Issuer, with Certificate Profile February 2003
Expires August 2003
If a proxy identifier unique certificate contains a version that is unknown
to a relying party the PC. relying party MUST disregard the PC
and it's chain when making authorization decisions.
3.9.2 pCPathLenConstraint
The subjectAltName extension pCPathLenConstraint field, if present, specifies the
maximum depth of the path of Proxy Certificates that can
be signed by this Proxy Certificate. A
pCPathLenConstraint of 0 means that this certificate MUST
NOT be present in used to sign a Proxy Certificate.
The subject of a Proxy Certificate SHOULD only be used for path
validation.
3.4 Key Usage If the issuer certificate includes
proxyCertInfo extension is not present, or if the keyUsage extension,
pCPathLenConstraint is not present, then the
Proxy Certificate MUST include proxy path
length is unlimited.
3.9.3 proxyPolicy
The proxyPolicy field specifies a keyUsage extension, which MAY
further restrict the issuer's keyUsage.
If policy on the issuer use of
this certificate does not include a keyUsage extension,
then the Proxy Certificate MAY include a keyUsage extension to
restrict for the key usage purposes of authorization. Within
the Proxy Certificate.
The keyUsage extension MUST be critical.
If proxyPolicy, the keyUsage extension policy field 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 an expression of these bits:
digitalSignature, nonRepudiate, keyEncipherment,
dataEncipherment, keyAgreement, cRLSign, encipherOnly,
decipherOnly. If this bit in
policy, and the issuer certificate is not
asserted, then this bit in policyLanguage field indicates the Proxy Certificate MUST NOT be
asserted. If this bit
language in which the issuer certificate policy is asserted, or
if expressed.
The proxyPolicy field in the issuer certificate proxyCertInfo extension does
not include define a keyUsage extension,
then this bit in the Proxy Certificate MAY policy language to be either asserted or
not asserted.
See the commentary in section 6 used for more information on proxy
restrictions; rather, it places the
keyCertSign burden on those
parties using that extension to define an appropriate
language, and nonRepudiate bits.
3.5 Extended Key Usage
If the issuer certificate includes the extKeyUsage extension, then:
The Proxy Certificate MUST include to acquire an extKeyUsage extension.
Any OID for that language (or to
select an appropriate previously-defined language/OID).
Because it 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.
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 essential for the issuer PI that issues a
certificate does not include the extKeyUsage
extension, then with a proxyPolicy field and the Proxy Certificate MAY include an extKeyUsage
extension relying party
that interprets that field to restrict the key usage of the Proxy Certificate. In
this case, agree on its meaning, the extKeyUsage extension MAY be critical or non-
critical.
3.6 Basic Constraints
policy language OID must correspond to a policy language
(including semantics), not just a policy grammar.
The cA policyLanguage field in the basic constraints extension has two values of special
importance that MUST NOT be TRUE.
3.7 understood by all parties
accepting Proxy Certificate Information
Two new extensions, ProxyCertInfo and DelegationTracing, are Certificates:
* Impersonation, as defined
in by the following subsections
3.7.1 The ProxyCertInfo Extension
The ProxyCertInfo extension oid value iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) ppl(21) id-ppl-
impersonation(1), indicates whether or not a certificate that this is a an
tuecke@mcs.anl.gov 19
X.509 Proxy Certificate and whether or not Profile February 2003
Expires August 2003
unrestricted proxy that inherits all rights from the issuer
issuing PI. An unrestricted proxy is a statement that
the Proxy Issuer wishes to delegate all of its
authority to the
certificate bearer (i.e., to anyone who 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,
proxyGroup ProxyGroup OPTIONAL,
issuerCertSignature Signature OPTIONAL }
ProxyRestriction ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
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 that
proxy certificate is a Proxy Certificate, then and can prove possession of the proxyCertInfo
extension MUST be present,
associated private key). For purposes of authorization,
this an unrestricted proxy effectively impersonates the pC field MUST be TRUE, and
issuing PI.
* Independent, as defined by the oid value iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) ppl(21) id-ppl-
independent(2), indicates that this
extension is an independent
proxy that inherits no rights from the issuing PI. This
PC MUST be marked treated as critical.
Otherwise an independent identity by
relying parties. The only rights this PC has are those
granted explicitly to it.
For either of the extension MAY be marked as critical.
A Proxy Certificate policyLanguage values listed above, the
policy field MUST NOT be used to sign an End Entity
Certificate or a CA Certificate.
If a certificate present.
Other values for the policyLanguage field indicates that
this is not a Proxy Certificate, then the proxyCertInfo
extension MAY be present, restricted proxy certification and MAY appear as a critical or non-
critical extension. have some
other policy limiting it's ability to do impersonation. In
this case, if this extension is present,
then case the pC policy field MUST MAY be FALSE. present and it MUST
contain information expressing the policy. If any of the pcPathLenConstraint, proxyRestricition, or proxyGroup
fields are policy
field is not present and non-empty then this extension the policy MUST be marked
as critical, regardless if implicit in the certificate is a
value of the policyLanguage field itself.
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.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.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 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.7.1.4 proxyRestriction
The proxyRestriction field, if present, specifies restrictions on
the use of this certificate. If this field is present the
proxyCertInfo extension MUST be 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 Proxy Issuer wishes to
delegate all its authority to the bearer (i.e., to anyone who has
that proxy certificate and can prove possession of the associated
private key). Proxy restrictions policies are used to limit the amount of authority
delegated, for example to assert that the proxy
certificate may be used only to make requests to a
specific server, or only to authorize specific operations
on specific resources.
Within the proxyRestriction, the policy field This document is an expression of
policy, and the policyLanguage field indicates agnostic to the language
policies that can be placed in which the policy is expressed. field.
Proxy restrictions policies impose additional requirements on the
relying party, because only the relying party is in a
position to ensure that those restrictions policies are met. enforced. 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
policies in the PC's certificate path. In other words,
tuecke@mcs.anl.gov 20
X.509 Proxy Certificate Profile February 2003
Expires August 2003
the relying party MUST verify that the following three
conditions are all met:
1) If the PC includes a proxy restriction, policy, then the relying
party knows how to interpret the policy expressed in the PC's
restriction, and the request
is allowed under that policy.
2) If the 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 Proxy Issuer is another PC, then conditions (1),
(2), and (3) are met for the PI. Proxy Issuer.
If these conditions are not met, the relying party MUST
either deny
authorization 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 it's certificate
chain never been presented). Note that this verification
MUST take place regardless of whether or not the PC itself
contains restrictions, a policy, as other PCs in the signing chain may MAY
contain conditions that must MUST be verified.
The relying party MAY impose additional restrictions as to what
which proxy certificates it accepts. For example, a
relying party may MAY choose to reject all proxy certificates,
or to accept only those
proxy certificates that include delegation tracing information, or MAY choose to accept proxy certificates only for
certain operations, etc.
The
Note that since a proxy certificate has a unique identity
it MAY also have rights granted to it from other sources
than it's issuer. This means that the rights granted to
the bearer of a PC will, then, be (at most) are the intersection union of the set of rights granted to
the entity named in PC identity with the EEC in intersection of the PC's certificate path, and rights
granted to the sets identity of PI of rights
authorized by the policies in each proxyRestriction that appears PC and the policy in
the certificate path. PC.
For example, imagine that Steve is authorized to read and
write files A and B on a file server, and that he uses his
EEC to create a PC that includes the restriction policy 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 Then a trusted
attribute authority grants an Attribute Certificate
tuecke@mcs.anl.gov 21
X.509 Proxy Certificate Profile March 2002
granted to February 2003
Expires August 2003
granting 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 D. This would be incompatible with make
the proxy restriction, and a
request to read file C would be rejected because rights of the file server's
local policies do not grant Steve any access to file C. If that PC
were then used equal to create a new PC that includes the restriction that
it can be used only union of the rights
granted to read files, then the bearer of that new PC
would have, at most, the right identity (right to read file A.
In many cases, D) with the relying party will
intersection of the rights granted to Steve, the PI,
(right to read files A and B) with the policy in the PC
(can only read files A and C). This would mean the PC
would have the following rights:
* Right to read file A: Steve has this right and he
issued the PC and his policy grants this right to the
PC.
* Right to read file D: This right is granted explicitly
to the PC by a trusted authority.
The PC would NOT have the following rights:
* Right to read file B: Although Steve has this right, it
is excluded by his policy on the PC.
* Right to read file C: Although Steve's policy grants
this right, he does not have this right himself.
In many cases, the relying party will not have enough
information to evaluate the above criteria at the time
that the certificate itself path is validated. For example, if a
certificate is used to authenticate a connection to some
server, that certificate is typically validated during
that authentication step, before any requests have been
made of the server. In that case, the relying party MUST
either have some authorization mechanism in place that
will check the proxy
restrictions, policies, or reject any certificate
that contains proxy
restrictions policies (or that has a parent
certificate that contains proxy
restrictions).
3.7.1.5 proxyGroup
The proxyGroup field provides a method of assigning a policies).
4 Proxy Certificate to a group, which serves as a method to limit a PC’s
ability to do self-authentication (authentication with entities
authenticating with a PC derived from the same EEC as the original
party). If Path Validation
Proxy Certification path processing verifies the proxyGroup field is present binding
between the proxyCertInfo
extension MUST be marked as critical. proxy certificate distinguished name and proxy
certificate public key. The proxyGroupAttached field indicates whether this subgroup is
attached to it’s parent group in terms of the trust model. If a
subgroup binding is attached, proxies in the subgroup (and it’s descendants)
are considered trusted for self-authentication limited by proxies
constraints which are specified in the
parent group (and it’s ancestors). If a subgroup is detached then
proxies in certificates which
comprise the subgroup (and it’s descendants) path and inputs which are considered
untrusted for self-authentication specified by proxies in the parent group (and
it’s ancestors).
The
relying party.
tuecke@mcs.anl.gov 22
X.509 Proxy Certificate group namespace is hierarchical, with the
namespace being defined by the End Entity Certificate. In other
words, two Proxy Certificates having the same group name is only
meaningful if they both have the same EEC at the root Profile February 2003
Expires August 2003
This section describes an algorithm for validating proxy
certification paths. Conforming implementations of their
signing chain.
The EEC is always considered this
specification are not required to implement this
algorithm, but MUST provide functionality equivalent to
the external behavior resulting from this procedure. Any
algorithm may be in used by a particular implementation so
long as it derives the group that is correct result.
The algorithm presented in this section validates the root of
proxy certificate with respect to the namespace. Each Proxy Certificate current date and
time. A conformant implementation MAY also support
validation with respect to some point in the past. Note
that mechanisms are not available for validating a chain can then be in proxy
certificate with respect to a
subgroup of time outside the PI certificate
validity period.
Valid paths begin with the end entity certificate (EEC)
that issued it. has already been validated by public key certificate
validation procedures in RFC 3280[7]. The full group name algorithm
requires the public key of a Proxy
Certificate is the sequence EEC and the EEC's subject
distinguished name.
To meet the goal of subgroup names in proxyCertInfo
extensions starting in verifying the signing chain starting with proxy certificate, the EEC.
If two parties are doing self-authentication, not only should they
verify
proxy certificate path validation process verifies, among
other things, that they each have a PC derived from prospective certification path (a
sequence of n certificates) satisfies the same EEC, but they
should make sure that following
conditions:
(a) for all x in {1, ..., n-1}, the groups subject of their PCs are compatible.
Compatibility
certificate x is defined as being in groups that are a direct
Tuecke, et. al. Expires February 2002 18
Internet Draft X.509 Proxy Certificate Profile March 2002
attached ancestors or descendants the issuer of each other. E.g. a parent proxy certificate x+1
and an
attached child group are compatible, but siblings groups are not.
3.7.1.6 issuerCertSignature
The issuerCertSignature field, if present, is used during path
validation to ensure that each Proxy Certificate Path (the subset of
a PC's certificate path that starts at an End Entity Certificate and
ends at the PC) is unique. In other words, if certificate N+1 in a subject distinguished name of certificate path x+1
is a Proxy Certificate, then issuerCertSignature is
used legal subject distinguished name to verify that have been
issued by certificate x;
(b) certificate N 1 is actually the PI that issued it
and not some other valid proxy certificate with issued by
the same name and public key.
Without this field, if a PI were end entity certificate whose information is given
as input to issue two different proxy
certificates (P1 and P2) with the same subject and public key but
different proxy restrictions or validity time constraints, then the certificate path validation algorithm would accept a path in which P2 appeared
as the issuer of a
process;
(c) certificate that had really been issued by P1.
This field consists of n is the following two subfields:
* signatureAlgorithm MUST be identical proxy certificate to the PI's
signatureAlgorithm.
* signatureValue MUST be identical to
validated;
tuecke@mcs.anl.gov 23
X.509 Proxy Certificate Profile February 2003
Expires August 2003
(d) for all x in {1, ..., n}, the PI's signatureValue.
This field MUST be present if certificate was
valid at 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 time in a future version of this
draft.]
The DelegationTrace extension is used to provide information about question; and
(e) the identity of certificate chain does not exceed the Acceptor of maximum
length specified by pCPathLenConstraint.
At this point we have no plans for a Proxy Certificate and, in some
cases, proxy issuer (that
is, an EEC or PC) to demonstrate that revoke the Acceptor PCs that it has agreed to accept the
Proxy Certificate. issued.
If a Proxy Certificate does not include policy
extensions, the Acceptor's agreement to "accept" that certificate this feature is
not an agreement to accept any additional responsibilities, such as
safeguarding needed in the Proxy Certificate's private key.
If future, the DelegationTrace CRL
Distribution Point extension is present, then the certificate
MUST can be used in the PI
certificates to locate a CRL.
4.1 Basic Proxy Certificate: Certificate Path Validation
This section presents the ProxyCertInfo extension MUST also
be present, and algorithm in four basic steps to
mirror the ProxyCertInfo.pC field MUST be TRUE. The
DelegationTrace extension MAY be present description of public key certificate path
validation in any RFC 3280: (1) initialization, (2) basic
proxy certificate processing, (3) preparation for the next
proxy certificate, and SHOULD be present in any Proxy Certificate whose issuer (4) wrap-up. Steps (1) and (4) are
performed exactly once. Step (2) is a
Proxy Certificate performed for all
proxy certificates in which the DelegationTrace extension path. Step (3) 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 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 information regarding the
certificate's Acceptor, in a format appropriate performed for
all proxy certificates in the mechanism
that was used by path except the Acceptor final proxy
certificate.
Certificate path validation as described in RFC 3280 MUST
have been done prior to authenticate using this algorithm to validate
the Proxy
Authority. Currently, end entity certificate. This algorithm then processes
the only format defined is
X509DelegationTrace, which is intended for use when that
authentication took place proxy certificate chain using X.509 certificates, or when the
Acceptor and the PA are the same entity.
The X509DelegationTrace structure is used end entity
certificate information produced by RFC 3280 path
validation.
4.1.1 Inputs
This algorithm assumes the following inputs are provided
to verify that, at the
time path processing logic:
(a) information about the entity certificate already
verified using RFC 3280 path validation. This
information includes:
(1) the end entity name,
tuecke@mcs.anl.gov 24
X.509 Proxy Certificate was issued, the Acceptor had agreed to
accept it. This structure consists of two required fields: Profile February 2003
Expires August 2003
(2) the
agreedCertInfo field, which contains hashes of some information
related to working_public_key output from RFC 3280 path
validation,
(3) the certificate, working_public_key_algorithm output from RFC
3280,
(4) and the acceptorInfo field, which working_public_key_parameters output
from RFC 3280 path validation.
(b) prospective proxy certificate path of length n.
(c) acceptable-pc-policy-set: A set of acceptable
proxy certificate policy languages. The acceptable-pc-
policy-set contains the Acceptor's signature of special value any-policy if the agreedCertInfo, plus
additional information that can be used by a relying party to verify
user is not concerned about the Acceptor's signature. These fields proxy certificate
policy languages being checked during path validation
(in this case it is assumed the proxy certificate
policies are described in detail in being checked at a later time before
authorization).
(d) the current time/date.
4.1.2 Initialization
This initialization phase establishes the following two subsections.
3.7.2.1 agreedCertInfo
The agreedCertInfo field is state
variables based upon the inputs:
(a) working_public_key_algorithm: the digital signature
algorithm used to describe verify the proxy certificates
that an Acceptor is willing to accept. It consists signature of these
subfields:
* ignoredExtensions: a list of OIDs. proxy
certificate. The presence of an OID in
this list working_public_key_algorithm is an indication that
initialized from the presence, absence, or value
of an extension with this OID in a certificate will not affect input information provided from
RFC 3280 path validation.
(b) working_public_key: the Acceptor's willingness public key used to accept verify
the certificate.
* certSubsetHash: a hash signature of a TBSCertificate structure representing
a certificate that the Acceptor proxy certificate. The
working_public_key is willing to accept.
When verifying this extension, the relying party should construct
a TBSCertificate structure identical to initialized from the input
information provided from RFC 3280 path validation.
(c) working_public_key_parameters: parameters
associated with the current certificate's
tbsCertificate field, minus public key, that may be
required to verify a signature (depending upon the DelegationTrace extension and any
Tuecke, et. al. Expires February 2002 20
Internet Draft
algorithm). The proxy_issuer_public_key_parameters
tuecke@mcs.anl.gov 25
X.509 Proxy Certificate Profile March 2002
extensions listed in ignoredExtensions; the hash of that structure
should be equal to certSubsetHash.
3.7.2.2 x509AcceptorInfo
The x509AcceptorInfo field consists of a signature, using February 2003
Expires August 2003
variable is initialized from the
private key associated with input information
provided from RFC 3280 path validation.
(d) working_issuer_name: the Acceptor's certificate, of issuer distinguished name
expected in the
agreedCertInfo field, plus additional information that next proxy certificate in the relying
party may use chain.
The working_issuer_name is initialized to identify the Acceptor.
Note that
distinguished name in the Acceptor's end entity certificate
validated by RFC 3280 path validation.
(e) max_path_length: this integer is not the newly-issued proxy
certificate; rather, it initialized to n,
is an X.509 decremented for each proxy certificate already held by in the
Acceptor at path.
This value may also be reduced by the time
pcPathLenConstraint value of delegation. If any proxy certificate in
the issuer chain.
(f) proxy_policy_list: this list is empty to start and Acceptor are
the same entity, then the Acceptor's certificate SHOULD
will be filled in with the
Issuer's certificate. If proxy policies in the Acceptor sent a certificate request to chain.
Upon completion of the issuer over a channel that was authenticated using an X.509
certificate, then initialization steps, perform the Acceptor's
basic certificate SHOULD processing steps specified in 4.1.3.
4.1.3 Basic Proxy Certificate Processing
The basic path processing actions to be the performed for
proxy certificate that the Acceptor used to authenticate to i (for all i in [1..n]) are listed
below.
(a) Verify the issuer. basic certificate information. The x509AcceptorInfo field consists
certificate MUST satisfy each of these subfields:
* acceptorSig is a signature, using the private key associated following:
(1) The certificate was signed with the Acceptor's certificate, of the agreedCertInfo field.
* acceptorName is
working_public_key_algorithm using the subject name from
working_public_key and the Acceptor's certificate.
* acceptorAltName is
working_public_key_parameters.
(2) The certificate validity period includes the subjectAltName from
current time.
(3) The certificate issuer name is the Acceptor's
certificate. If acceptorName
working_issuer_name.
(4) The certificate subject name is null, this the
working_issuer_name with a CN component appended.
tuecke@mcs.anl.gov 26
X.509 Proxy Certificate Profile February 2003
Expires August 2003
(b) The proxy certificate MUST have a ProxyCertInfo
extension. Process the extension as follows:
(1) The version field in the ProxyCertInfo extension
MUST be 1.
(2) If the pCPathLenConstraint field is present in
the ProxyCertInfo field and non-null.
* acceptorCertHash the value it contains is a copy of
less than max_path_length, set max_path_length to
it's value.
(3) The proxyPolicy field MUST be processed as
follows:
(i) If acceptable-pc-policy-set is not any-policy,
the signature from OID in the Acceptor's
certificate: acceptorHash.hashAlgorithm policyLanguage field MUST be
present in acceptable-pc-policy-set.
(ii) The policy field and
acceptorHash.hashValue the OID in the
policyLanguage field must be identical appended to the
signatureAlgorithm
proxy_policy_list.
(c) Recognize and signatureValue from process any other critical extension
present in the Acceptor's proxy certificate.
4 Certificate Path Validation
[Author’s note: Consider changing this section to add a second phase
to path validation for PC validation, rather than modifying Process any other
recognized non-critical extension present in the
existing path validation proxy
certificate.
If either step (a) or (b) fails, the procedure terminates,
returning a failure indication and an appropriate reason.
If i is not equal to accommodate n, continue by performing the entire chain.]
The Certificate Path Validation algorithm described
preparatory steps listed in Section 6 of
draft-ietf-pkix-new-part1-12 [7] must be modified 4.1.4. If i is equal to accommodate
Proxy Certificates. Changes are needed to:
1) check n,
perform the generalized signing chains involving CAs, End Entity
Certificates, and Proxy Certificates;
2) check for proper subject names wrap-up steps listed in 4.1.5.
4.1.4 Preparation for next Proxy Certificates;
3) handle the iCPathLenConstraint in the proxyCertInfo extension;
4) check the key usage Certificate
(a) Verify max_path_length is greater than zero and extended key usage extensions;
Tuecke, et. al. Expires February 2002 21
Internet Draft
decrement max_path_length.
(b) Assign the certificate subject name to
working_issuer_name.
tuecke@mcs.anl.gov 27
X.509 Proxy Certificate Profile March 2002
5) handle the issuerCertSignature in February 2003
Expires August 2003
(c) Assign the proxyCertInfo extension.
Changes certificate subjectPublicKey to section 6.1.2, Initialization:
(new) working_certificate_type: This can be one
working_public_key.
(d) If the subjectPublicKeyInfo field of CA, EEC, or
PC. A the
certificate type contains an algorithm field with non-null
parameters, assign the parameters to the
working_public_key_parameters variable.
If the subjectPublicKeyInfo field of CA is determined by the
basicConstraints extension certificate
contains an algorithm field with null parameters or as verified out-of-band. A
parameters are omitted, compare the certificate type of PC is determined by
subjectPublicKey algorithm to the proxyCertInfo
extension. Otherwise,
working_public_key_algorithm. If the certificate type is EEC.
(new) working_issuer_certificate_type: This can be one of EEC or
PC
subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to indicate null.
(e) Assign the type of certificate that acted as subjectPublicKey algorithm
to the Proxy
Issuer for working_public_key_algorithm variable.
If check (a) fails, the procedure terminates, returning a PC.
(new) valid_pc_key_usage & pc_key_usage_criticality: These are
used
failure indication and an appropriate reason.
If (a) completes successfully, increment i and perform the
basic certificate processing specified in 4.1.3.
4.1.5 Wrap-up Proceedures
(a) Assign the certificate subject name to verify that
working_issuer_name.
(b) Assign the key usage of a PC is a subset of certificate subjectPublicKey to
working_public_key.
(c) If the key
usage subjectPublicKeyInfo field of the
certificate that signed that PC, and that contains an algorithm field with non-null
parameters, assign the
criticality of this extension never diminishes. These variables
are not initialized or used until parameters to the first EEC or PC is
encountered in
proxy_issuer_public_key_parameters variable.
If the path validation subjectPublicKeyInfo field of the certificate
contains an algorithm field with this extension.
(new) valid_pc_ext_key_usage & pc_ext_key_usage_criticality:
These null parameters or
parameters are used to verify that omitted, compare the extended key usage OIDs of a PC
is a subset of certificate
subjectPublicKey algorithm to the extended key usage OIDs of
tuecke@mcs.anl.gov 28
X.509 Proxy Certificate Profile February 2003
Expires August 2003
proxy_issuer_public_key_algorithm. If the certificate
that signed that PC,
subjectPublicKey algorithm and that the criticality of this extension
never diminishes. These variables
proxy_issuer_public_key_algorithm are not initialized or used
until different, set
the first EEC or PC is encountered in proxy_issuer_public_key_parameters to null.
(d) Assign the path validation certificate subjectPublicKey algorithm with this extension.
(new) working_issuer_signature_algorithm &
working_issuer_signature_value: These are used
to verify that,
if certificate N+1 is a Proxy Certificate, then certificate N is
the certificate that issued that proxy. These variables are not
used until the first EEC or PC is encountered in the proxy_issuer_public_key_algorithm variable.
4.1.6 Outputs
If path
validation algorithm with the proxyCertInfo extension.
Changes to section 6.1.3, Basic Certificate Processing:
(a)(new) The certificate type is CA and processing succeeds, the
working_certificate_type is CA, or procedure terminates,
returning a success indication together with final value
of the certificate type is EEC
and working_public_key, the working_certificate_type is CA, or
working_public_key_algorithm, the certificate type
is PC
working_public_key_parameters, and the working_certificate_type is EEC or PC.
(b) & (c) This step checks the Name Constraints defined by proxy_policy_list.
4.2 Using the
CA. However, since Proxy Certificate Path Validation Algorithm
Each Proxy Certificate contains a PC does not define proxyPolicy field
containing a new Name, these checks
should be skipped if language identifier and policy. These
policies serve to indicate the certificate type is PC (as specified desire of each issuer in
a proxyCertInfo extension).
(new) If
the proxy certificate type is PC, chain, starting with the subject name should be
checked EEC, to make sure it is a valid subject name
delegate some subset of their rights to have been the issued proxy
certificate. This chain of policies is returned by it’s Proxy Issuer. If the
working_issuer_certificate_type is EEC then
algorithm to the application.
The application MAY make authorization decisions based off
of the subject distinguished name
should just contain a single CN component. If of the
Tuecke, et. al. Expires February 2002 22
Internet Draft X.509 Proxy Certificate Profile March 2002
working_issuer_certificate_type is PC then proxy certificate
or off of one of the subject name
should be proxy certificates in it's issuing
chain or off of the working_issuer_name with EEC that serves as the addition root of a single
CN component.
(new) the
chain. If an application chooses to use the subject
distinguished name of a proxy certificate type is PC, and valid_pc_key_usage has been
initialized, then verify that:
(1) all bits that are asserted in the keyUsage extension of
the certificate are also asserted in the valid_pc_key_usage;
(2) if pc_key_usage_criticality is true, then the keyUsage
extension is critical
(new) If certificate type is PC, and valid_pc_ext_key_usage has
been initialized, then verify that:
(1) all OIDs that are in the extKeyUsage extension in the
certificate are also in issuing
chain or the valid_pc_ext_key_usage;
(2) if pc_ext_key_usage_criticality is true, then EEC it MUST use the
extKeyUsage extension is critical.
(new) If certificate type is PC, then verify that:
(1) proxyCertInfo.issuerCertSignature is present.
(2) proxyCertInfo.issuerCertSignature.signatureAlgorithm is
equal to working_issuer_signature_algorithm.
(3) proxyCertInfo.issuerCertSignature.signatureValue is equal
to working_issuer_signature_value.
Changes returned policies to section 6.1.4, Preparation for Certificate i+1:
(k) This step verifies that
restrict the certificate is a CA certificate.
However, rights it is not general enough to support a PC. So change
this step grants to simply assign the certificate type to proxy certificate. If
the
working_certificate_type. The necessary CA, EEC, and PC signing
constraints check has been added application does not know how to the Basic Certificate
Processing section above.
(m) This step resets the max_path_length if pathLenConstraint is
present parse any policy in
the certificate. This needs to be generalized to
support pCPathLengthConstraint from policy chain it MUST not use, for the proxyCertInfo extension,
as follows:
Reset max_path_length as follows:
(1) If purposes of
making authorization decisions, the subject distinguished
name of any certificate type is CA, and pathLenConstraint is
present in the certificate and is less than max_path_length,
then set max_path_length chain prior to the value of pathLenConstraint.
(2) If
certificate type is EEC, and pCPathLenConstraint is not
present in which the certificate, then set max_path_length to n.
Tuecke, et. al. Expires February 2002 23
Internet Draft unrecognized policy appears.
tuecke@mcs.anl.gov 29
X.509 Proxy Certificate Profile March 2002
(3) If certificate type is EEC, and pCPathLenConstraint is
present in the certificate, then set max_path_length to the
value of pCPathLenConstraint.
(4) If certificate type is PC, and pCPathLenConstraint is
present in the 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 certificate, then set max_path_length to be
infinite.
(n) Since keyCertSign is currently defined to be equivalent to
being a CA, this check needs to be changed to accommodate PCs, as
follows: If certificate type is CA, and a key usage extension is
present and marked critical, verify that the keyCertSign bit is
set.
(new) If certificate type is EEC or PC, and the key usage
extension is present, then set valid_pc_key_usage to keyUsage,
and set pc_key_usage_criticality to the keyUsage criticality.
(new) If certificate type is EEC or PC, and the 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 CRL.
5 Relationship February 2003
Expires August 2003
5 Commentary
This section provides non-normative commentary on Proxy
Certificates.
5.1 Relationship to Attribute Certificates
An Attribute Certificate [4] can be used to grant to one
identity, the holder, some attribute such as a role,
clearance level, or alternative identity such as "charging
identity" or "audit identity". This is accomplished by
way of a trusted Attribute Authority (AA), which issues
signed Attribute Certificates (AC), each of which binds an
identity to a particular set of attributes. Authorization
decisions can then be made by combining information from
the authenticated End Entity Certificate providing the
identity, with the signed Attribute Certificates providing
binding of that identity to attributes.
There is clearly some overlap between the capabilities
provided by Proxy Certificates and Attribute Certificates.
However, the combination of the two approaches together
provides a broader spectrum of solutions to authorization
in X.509 based systems, than
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 Certificates.
5.1
5.1.1 Types of Attribute Authorities
For the purposes of this discussion, Attribute
Authorities, and the uses of the Attribute Certificates
that they produce, can be broken down into two broad
classes:
1) End entity AA: An End Entity Certificate may be used to
sign an AC. This can be used, for example, to allow an
end entity to delegate some of its privileges to another
entity.
2) Third party AA: A separate entity, aside from the end
entity involved in an authenticated interaction, may
tuecke@mcs.anl.gov 30
X.509 Proxy Certificate Profile February 2003
Expires August 2003
sign ACs in order to bind the authenticated identity
with additional attributes, such as role, group, etc.
For example, when a client authenticates with a server,
the third party AA may provide an AC that binds the
client identity to a particular group, which the server
then uses for authorization purposes.
This second type of Attribute Authority, the third party
AA, works equally well with an EEC or a PC. For example,
unrestricted Proxy Certificates can be used to delegate
the EEC's identity to various other parties. Then when
one of those other parties uses the PC to authenticate
with a service, that service will receive the EEC's
identity via the PC, and can apply any ACs that bind that
identity to attributes in order to determine authorization
rights. Additionally PC
restrictions with policies could be used do to
selectively deny the binding of an AC ACs to a particular proxy.
An AC could also be bound to a particular PC using the
subject or issuer and serial number of the proxy
certificate. There would appear to be great synergies
between the use of Proxy Certificates and Attribute
Certificates produced by third party Attribute
Authorities.
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
5.1.3 Delegation Using Attribute Certificates
In the motivating example above, in Section 2.3, PCs are used to
delegate Steve's identity to the various other jobs and
entities that need to act on Steve's behalf. This allows
those other entities to authenticate as if they were Steve.
Steve, for example to the mass storage system.
tuecke@mcs.anl.gov 31
X.509 Proxy Certificate Profile February 2003
Expires August 2003
A solution to this example could also be cast using
Attribute Certificates that are signed by Steve's EEC,
which grant to the other entities in this example the
right to perform various operations on Steve's behalf. In
this example, the reliable file
Tuecke, et. al. Expires February 2002 25
Internet Draft X.509 Proxy Certificate Profile March 2002 transfer service and all
the hosts involved in file transfers transfers, the starter program,
the agent, the simulation jobs, and the post-processing
job would each have their own EECs. Steve's EEC would
therefore issue ACs to bind each of those other EEC
identities to attributes that grant the necessary
privileges allow them to, for example, access the mass
storage system.
However, this AC based solution to delegation has some
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. minimal modification (e.g. possibly to find the
EEC name and to check for any proxy policies).
* ACs need to be created by Steve's EEC, which bind
attributes to each of the other identities involved in
the distributed application (i.e. the agent, simulation
jobs, and post-processing job the file transfer
service, the hosts transferring files). This implies
that Steve must know in advance which other identities
may be involved in this distributed application, in
order to generate the appropriate ACs which are signed
by Steve's ECC. On the other hand, the PC solution
allows for much more flexibility, since parties can
further delegate a PC without a priori knowledge by the
originating EEC.
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
tuecke@mcs.anl.gov 32
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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
5.1.4 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" (RFC 3281) 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
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 for the purpose of delegation.
delegation..
tuecke@mcs.anl.gov 33
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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.
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
5.1.5 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 to specify a PC as the holder of
an AC remains open.
An AC could be bound to a particular instance of a PC
using the unique subject name of the PC, or it’s it's issuer
and serial number combination.
Still open at this point is the issue if the AC would be inherited
by PC created
Unrestricted PCs issued by this that PC acting as would then inherit
those ACs and independent PCs would not. PCs issued with a PI.
6 Commentary
This section provides commentary
policy would depend 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 policy as to whether or not change
they inherit the definition of issuing PC's ACs (and potentially which
ACs they inherit).
While an AC can be bound to one PC by the
keyCertSign bit of AA, how can the keyUsage extension. draft-ietf-pkix-new-
part1-12 states:
Tuecke, et. al. Expires February 2002 27
Internet Draft
AA restrict that PC from passing it on to a subsequently
delegated PC? One possible solution would be to define an
extension to attribute certificates that allows the
tuecke@mcs.anl.gov 34
X.509 Proxy Certificate Profile March 2002
"The keyCertSign bit February 2003
Expires August 2003
attribute authority to state whether an issued AC is asserted when to
apply only to the subject public key particular entity to which it 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 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 bound,
or if 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
Another suggestion was to include the subject of the signing EEC as
a prefix may apply to the PC subject, or as PCs issued by that entity.
One issue that an informational field AA in the PC.
This this circumstance 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 be
aware of is that the subject PI of the EEC PC that the AA bound the AC
to, could issue another PC is derived from.
This approach was rejected for with the following reasons:
* It would be easy same name as the
original PC to spoof this informational field. For example, a PC with different entity, effectively stealing
the AC. This implies that an informational subject of "Steve" could be used AA issuing an AC to
create a PC with an informational subject set need
to "Doug". This
leaves us with two alternatives:
. We can augment not only trust the path validation to check that this
informational field of entity holding the PC is PC, but the same as in
entity holding the signing PC
or EEC. But this is not desirable, PC's issuer 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 well.
5.2 Kerberos 5 Tickets
The Kerberos Network Authentication Protocol (RFC 1510
[9]) is a lot of information in the
certificate chain that may be needed during authorization, such
as the number of levels of delegation, the CA (or multiple levels widely used authentication system based on
conventional (shared secret key) cryptography. It
provides support for single sign-on via creation of CAs) who signed the original EEC, the constraints
"Ticket Granting Tickets" or "TGT", and keyUsage
values support for
delegation of the signing EEC, possibly Certificate Policies
associated with CAs or IAs. All impersonation rights via "forwardable
tickets".
Kerberos 5 tickets have informed many of these require essentially the
same amount of work as retrieving ideas
surrounding X.509 Proxy Certificates. For example, the subject
local creation of the EEC that
signed the PC. So why threat the EEC subject specially by
including it a short-lived PC can be used to provide
single sign-on in an information field?
Tuecke, et. al. Expires February 2002 28
Internet Draft X.509 Proxy Certificate Profile March 2002
In the end, PKI based system, just including the EEC subject name does not seem to as
creation of short-lived TGT allows for single sign-on in a
Kerberos based system. And just as a TGT can be
sufficiently useful forwarded
(i.e. delegated) to justify the addition of another field and the
work of verifying that name during the path validation.
Therefore, entity to determine the identity of allow for
impersonation in a Kerberos based system, so can a PC for authorization
purposes, the subject of the EEC must can
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.4 Specifying Proxy Restrictions
The proxyRestriction field in the proxyCertInfo extension does not
define a policy language delegated to be used allow for proxy restrictions; rather,
it places the burden on those parties using that extension to define impersonation in an appropriate language, X.509 PKI
based system.
A major difference between a Kerberos TGT and to acquire an OID for that language (or
to select an appropriate previously-defined language/OID). Because
it X.509 PC
is essential for the PI that issues a certificate with a
proxyRestriction field while creation 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 delegation of a policy grammar.
Several different approaches were considered regarding how to limit TGT requires
the use involvement of a third party (the Kerberos Domain
Controller), a PC for specific authorization purposes. One can be unilaterally created without the
active involvement of these
approaches was to include a list the specific rights granted by the third party. That is, a user can
directly create a PC (perhaps along from an EEC for single sign-on
capability, without requiring communication with conditions associated a third
party. And an entity with those rights),
either as a separate extension or as part of proxyCertInfo. This
list of rights would define the subset of PC can delegate the issuer's rights to be
granted PC to
tuecke@mcs.anl.gov 35
X.509 Proxy Certificate Profile February 2003
Expires August 2003
another entity (i.e. by creating a new PC, signed by the PC holder. But the parties using that extension
would still
first) without requiring communication with a third party.
The method used by Kerberos implementations to protect a
TGT can also be responsible for ensuring that both the PI and relying
party agreed on the meanings of the access rights and conditions
appearing in the restriction.
Another possible approach is used to embed an Attribute Certificate
(signed by the EEC issuing protect the PC) within a PC, which would define private key of a
subset PC.
For example, some Unix implementations of the issuer's attributes Kerberos use
standard Unix file system security to be associated with protect a user's TGT
from compromise. Similarly, the Globus Toolkit's Grid
Security Infrastructure implementation of Proxy
Certificates protects a user's PC
holder.
6.5 private key using this
same approach.
5.3 Examples of usage of Proxy Restrictions vs.
This section gives some examples of Proxy Rights
The proxyRestriction field in the proxyCertInfo extension defines
restrictions on the use Certificate
usage and some examples of how the proxy certificate; if that field is
not present, the proxy is unrestricted.
Another approach would Proxy policy can be
used to require that each proxy certificate
explicitly list the rights that it grants.
6.6 Site Information in Delegation Tracing
In some cases, it may be desirable restrict Proxy Certificates.
5.3.1 Example use of proxies without Restrictions
Steve wishes to know the hosts involved in a
delegation transaction (for example, perform a relying party may wish third-party FTP transfer between
two FTP servers. Steve would use an existing PC to
reject proxy certificates that were created on
authenticate to both servers and delegate a specific host or
domain). The DelegationTrace extension could be modified PC to include both
hosts. He would inform each host of 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 unique subject
name of the two parties PC given to a
transaction may not agree on the IP addresses being used (e.g., if other host. When the Acceptor is on a host that uses NAT, servers
establish the Acceptor data channel connection to each other, they
use these delegated credentials to perform authentication
and verify they are talking to the PA may
disagree about correct entity by
checking the Acceptor's IP address).
Another suggestion was, in those cases where domain information is
needed, to require that result of the subject names authentication matches the name
as provided by Steve.
5.3.2 Example use of all End Entities
involved (the Acceptor(s) and proxies with Restrictions
Steve wishes to delegate to a process the End Entity that appears in right to perform
a PC's
certificate path) include domain information.
6.7 Delegation Tracing vs. Usage Tracing
Delegation tracing provides information about whom transfer of a certificate was
delegated to, but it does not provide any information about who
actually used the certificate. That is, if Entity A delegates file from host H1 to host H2 on his
behalf. Steve would delegate a
certificate PC to Entity B, and then Entity C somehow acquires the
certificate and private key process and delegates he
would use Proxy Policy to Entity D, and so on:
A delegates PC1 restrict the delegated PC to B
C delegates PC2 to D
E delegates PC3 two
rights - the right to read file F1 on host H1 and the
right to F
G write file F2 on host H2.
The process then uses PC3
In this diagram, A has used A's identity certificate restricted PC to create proxy
certificate PC1 and delegate it authenticate
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 servers H1 and H2. The process would also delegate PC3 to F. Finally, G has acquired a copy of PC3 and its
private key, and used it to authenticate PC
to some relying party.
If both servers. Note that these delegated PCs would
tuecke@mcs.anl.gov 36
X.509 Proxy Certificate Profile February 2003
Expires August 2003
inherit the relying party wishes restrictions of their parents, though this is
not relevant to audit who has been involved this example. As in the
use example in the
previous Section, each host would be provided with the
unique name of this certificate, it can determine A's identity (by using the
certificate chain), PC given to the other server.
Now when the process issues the command to transfer the
file F1 on H1 and G's identity (by requiring that anyone using
a proxy certificate also present to F2 on H2, these two servers perform
an identity certificate).
If each proxy certificate includes a DelegationTracing extension, authorization check based on the relying party has restrictions in the identities B, D, and F available PC
that the process used to it --
but it has no indication authenticate with them (in
addition to any local policy they have). Namely H1 checks
that C or E were involved. Another
approach towards auditing the usage of a certificate would be PC gives the user the right to
provide a usage tracing extension read F1 and H2
checks that would include the issuer's
signature of PC gives the certificate (using user the issuer's identity
certificate); this right to write F2.
When setting up the data channel the servers would make again
verify the identities C and E (but not B, D,
or F) available to names resulting from the relying party.
6.8 Contents of X509AcceptorInfo
The X509AcceptorInfo field contains a signature using authentication match
the Acceptor's
private key, plus some additional information that a relying party
can use to identify names provided by Steve as in the Acceptor's certificate. There have been
various suggestions about how much additional information should be
included example in this field, ranging from simply including the Acceptor's
subject name (or subjectAltName) to including all certificates used
previous Section.
The extra security provided by these restrictions is that
now if the issuer when doing path validation on PC delegated to the Acceptor's
certificate.
Tuecke, et. al. Expires February 2002 30
Internet Draft X.509 process by Steve is stolen,
its use is greatly limited.
5.4 Delegation Tracing
A relying party accepting a Proxy Certificate Profile March 2002
Currently, the X509AcceptorInfo field contains may have an
interest in knowing which parties issued earlier Proxy
Certificates in the Acceptor's name
(or subjectAltName) certificate chain and the signature from the Acceptor's
certificate. This is enough information to uniquely identify whom they
delegated them. For example it may know that a
certificate, but in itself does not necessarily convey any
meaningful information about the Acceptor's identity (especially if
the Acceptor certificate particular
service or resource is itself known to have been compromised and
if any part of a Proxy certificate). Another
approach would be Certificate's chain was issued to include
the sequence of names from compromised service a valid
certificate path for the Acceptor's certificate.
6.9 Certificate Policies Extension
One could imagine some interesting things relying party may wish to do with
disregard the Certificate
Policies extension. For example:
* One could define policies for creation of a Proxy Certificate.
For example, chain.
A delegation tracing mechanism was considered by the PC created locally or remotely?
* An alternate approach
authors as additional information to defining restricted Proxy Certificates
would be use carried in the Certificate Policies extension to carry the OIDs
ProxyCertInfo extension. However at this time agreement
has not been reached as to what this information should
include so it was left out of various Proxy Certificate Policies. For example, a Proxy
Certificate policy might state that the PC can only this document, and will
instead be used
within a limited scope of machines, or for a limited set of uses.
6.10 Kerberos 5 Tickets considered in future revisions. The Kerberos Network Authentication Protocol (RFC 1510 [9]) is a
widely used authentication system based debate
mainly centers 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 whether the tracing information should
simply contain the identity of the ideas surrounding X.509
Proxy Certificates. For example, issuer and receiver or
it should also contain all the local creation details of the delegated
proxy and a short-
lived PC can be used signed statement from the receiver that the
proxy was actually acceptable to provide single sign-on in an it.
tuecke@mcs.anl.gov 37
X.509 PKI based
system, just as creation of short-lived TGT allows for single sign-
on Proxy Certificate Profile February 2003
Expires August 2003
5.4.1 Site Information in a Kerberos based system. And just as a TGT can Delegation Tracing
In some cases, it may be forwarded
(i.e. delegated) to another entity desirable to allow for impersonation know the hosts
involved in a
Kerberos based system, so can delegation transaction (for example, a PC can be delegated
relying party may wish to allow for
impersonation in an X.509 PKI based system.
A major difference between a Kerberos TGT and an X.509 PC is reject proxy certificates that
while creation and delegation of a TGT requires the involvement of a
third party (the Kerberos Domain Controller),
were created on a PC can specific host or domain). The
DelegationTrace extension could be
unilaterally created without modified to include 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
PA's and Acceptor's IP addresses; however, IP addresses
are typically easy to spoof, and in some cases the two
parties to a
third party. And an entity with transaction may not agree on the IP addresses
being used (e.g., if the Acceptor is on a PC can delegate host that uses
NAT, the PC Acceptor and the PA may disagree about the
Acceptor's IP address).
Another suggestion was, in those cases where domain
information is needed, to another
entity (i.e. by creating a new PC, signed by require that the first) without
requiring communication with subject names
of all End Entities involved (the Acceptor(s) and the End
Entity that appears in a third party.
The method used by Kerberos implementations PC's certificate path) include
domain information.
6 Security Considerations
In this Section we discuss security considerations related
to protect the use of Proxy Certificates.
6.1 Compromise of a TGT can
also be used Proxy Certificate
A Proxy Certificate is generally less secure than the EEC
that issued it. This is due to protect the fact that the private
key of a PC. PC is generally not protected as rigorously as
that of the EEC. For example, some
Unix implementations the private key of Kerberos use standard Unix file system
Tuecke, et. al. Expires February 2002 31
Internet Draft X.509 Proxy Certificate Profile March 2002
security to protect a user's TGT from compromise. Similarly, the
Globus Toolkit's Grid Security Infrastructure implementation of
Proxy Certificates protects a user's PC private key is
often protected 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 have two simple mechanisms for allowing their
use only file system security, in order
to allow that PC to be restricted: a time period during which used for single sign-on purposes.
This makes the ticket is
valid (the "starttime" and "endtime" fields PC more susceptible to compromise.
However, the risk of a ticket), and a
host address which restricts the host on which compromised PC is only the ticket may be
used (the "caddr" field misuse
of a ticket). An X.509 PC also has single user's privileges. Due to the path validation
checks made on a
validity period, but does not have PC, a host restriction field,
though it could PC cannot be easily added via used to sign an X.509 extension. While
these particular restrictions have a variety of limitations and
problems, they points toward a future of more general restriction
policies that might be included in EEC or
PC for another user.
Further, a compromised PC and/or Kerberos 5 ticket.
* The Microsoft implementation can only be misused for the
lifetime of Kerberos 5 has (not without
controversy) used the "authorization-data" field in PC, and within the Kerberos
ticket to encode authorization information into bound of the ticket. A
similar approach could be taken with
tuecke@mcs.anl.gov 38
X.509 Proxy Certificates, Certificate Profile February 2003
Expires August 2003
restriction policy carried 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 Therefore, one
common way to be used to create a short-lived
authorization certificate that can be delegated as necessary.
Merits of this approach versus Attribute Certificates are
discussed in Section 5.
6.11 Examples of usage of Proxy Groups and Restrictions
This section gives some examples of Proxy Certificate usage and some
examples of how Proxy Restrictions and Proxy Groups can be used to
restrict Proxy Certificates.
6.11.1 Example One: Use limit the misuse of proxies without Groups or Restrictions
Steve wishes to perform a third-party FTP transfer between two FTP
servers. Steve would use an existing compromised PC is to authenticate
limit its validity period to both
servers and delegate a PC no longer than is needed,
and/or to both hosts. When include a restriction policy in the servers establish PC that
limits 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 the (compromised) PC.
In addition, if a third-party FTP transfer 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 he wants
hard to replace, public key of the EEC. In other words,
the use of Proxy Groups Certificates to provide extra security. As single sign-on
capabilities in an X.509 PKI environment can actually
increase the previous
example, Steve would security of the end entity certificates,
because creation and use his existing PC to authenticate to both
servers. However when he delegates PCs to of the servers he would assign
both PCs to for user
authentication limits the same, detached subgroup. The servers use these
delegated credentials exposure of the EEC private key
to authenticate each other over only the data
channel, each verifying creation of the other’s PC is in a compatible group.
Tuecke, et. al. Expires February 2002 32
Internet Draft X.509 first level PC.
6.2 Restricting Proxy Certificate Profile March 2002 Certificates
The proxy groups in the above example provide two forms pCPathLenConstraint field of
protection. First since each server verifies the Proxy Group proxyCertInfo
extension can be used by an EEC to limit subsequent
delegation of the
other server, they have assurance they are interacting with another
task that Steve has intended them PC. A service may choose to interact with. Second it
provides only
authorize a limited form of restriction in case one of the request if a valid PC can be delegated
PCs is stolen.
6.11.3 Example Three: Use of proxies with Groups and Restrictions
Steve wishes to delegate to it.
An example of such as service is a process the right job starter, which may
choose to perform a third-
party transfer of reject a file on his behalf. Steve would delegate job start request if a valid PC to
the process and he would use Proxy Restrictions to limit the cannot
be delegated PC to two rights – the right to read file F1 on host H1 and it. By limiting the right to write file F2 on host H2.
The process then uses this restricted pCPathLenConstraint,
an EEC can ensure that a compromised PC of one job cannot
be used to authenticate to servers
H1 and H2. The process would also delegate start additional jobs elsewhere.
An EEC or PC can limit what a new PC to both servers,
placing both PCs can be used for by
turning off bits in the same detached subgroup. Note that these
delegated PCs would inherit Key Usage and Extended Key Usage
extensions. Once a key usage or extended key usage has
been removed, the restrictions of 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 to F2 on H2, these two servers perform an authorization check, path validation algorithm ensures that
it cannot be added back in
addition to any local policy they have, based on the restrictions a subsequent PC. In other
words, key usage can only be decreased in
the PC that the process used to authenticate with them. Namely H1
checks that the PC gives the user chains.
The EEC could use the right CRL Distribution Points extension
and/or OCSP to read F1 and H2 checks
that the PC gives the user take on the right to write F2.
The extra security provided by these restrictions is responsibility of revoking PCs
that now it had issued, if it felt that they were being
misused.
The use of the
PC delegated proxyPolicy field to restrict the process by Steve is stolen, its use rights of
a Proxy Certificate is greatly
limited.
The servers would then check the proxy groups when setting up and
authenticating each over the data channel as explained shown in Example
Two.
7 Security Considerations
A Section 6.6.
tuecke@mcs.anl.gov 39
X.509 Proxy Certificate is generally less secure than the EEC Profile February 2003
Expires August 2003
6.3 Relying Party Trust of Proxy Certificates
The relying party that
issued it. This is due going to authorize some actions
on the fact that the private key basis of a PC is
generally not protected as rigorously as will be aware that it has been
presented with a PC, and can determine the depth of the EEC. For
example,
delegation and the private key of a PC is often protected using only file
system security, in order to allow time that PC to be used for single
sign-on purposes. This makes the PC more susceptible delegation took place.
It may want to use this information in addition to compromise.
However, the risk of a compromised PC is only
information from the misuse of signing EEC. Thus a single
user's privileges. Due highly secure
resource might refuse to the path validation checks made on a PC, accept a PC cannot be used to sign an EEC at all, or PC for another user.
Further, a compromised PC can maybe only be misused for the lifetime of
the PC, and within the bound
a single level of delegation, etc.
The relying party should also be aware that since the restriction
policy carried by
the PC. Therefore, one common way to limit restricting the misuse rights of a
compromised PC is to limit its validity period to no longer than is
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 intersection
of the use policy of all the (compromised) PC.
In addition, if a PC is compromised, it does NOT compromise PCs in it's certificate chain,
this means any change in the EEC
that created certificate chain can effect
the policy of the PC. This property Since there is of great utility no mechanism in
protecting the highly valuable, and hard place
to replace, public key enforce unique subject names of PCs, if an issuer were
two PCs with identical names and keys, but different
rights this could allow the EEC. In two PCs to be substituted for
each other words, in path validation and effect the use rights of Proxy Certificates to provide
single sign-on capabilities a
PC down the chain. Ultimately, this means the relying
party places trust in an X.509 PKI environment can actually
increase the security of entities that are acting as
Proxy Issuers in the end entity certificates, because
creation and chain to behave properly.
7 References
[1] Bradner, S., "Key words for use of the PCs 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.
[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 user authentication limits the
exposure Authorization," RFC 3281,
April 2002.
[5] Foster, I., C. Kesselman, G. Tsudik, and S.
Tuecke, "A Security Architecture for Computational
tuecke@mcs.anl.gov 40
X.509 Proxy Certificate Profile February 2003
Expires August 2003
Grids," presented at Proceedings of the EEC private key to only the creation 5th ACM
Conference on Computer and Communications
Security, 1998.
[6] Foster, I., C. Kesselman, and S. Tuecke, "The
Anatomy of the first
level PC.
The pCPathLenConstraint field Grid: Enabling Scalable Virtual
Organizations," International Journal of the proxyCertInfo extension can be
used by an EEC to limit subsequent delegation
Supercomputer Applications, 2001.
[7] Housley, R., W. Polk, W. Ford, and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile," RFC 3280, April 2002.
[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.
[10] B. Clifford Neuman. Proxy-Based Authorization and
Accounting for Distributed Systems. In Proceedings
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 13th International Conference on
Distributed Computing Systems, pages 283-291, May
1993.
8 Acknowledgments
We are grateful to start
additional jobs elsewhere.
An EEC or PC can limit what a new PC can be used numerous colleagues 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, discussions on
the path
validation algorithm ensures that it cannot be added back topics covered in a
subsequent PC. In other words, key usage can only be decreased this paper, in
PC chains.
The EEC could use the CRL Distribution Points extension and/or OCSP particular (in
alphabetical order, with apologies 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 anybody we've
missed): Joe Bester, Randy Butler, Jarek Gawor, Keith
Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill
Johnston, Marty Humphrey, Sam Lang, Sam Meder, Clifford
Neuman, Frank Siebenlist, Gene Tsudik.
We are also grateful 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 members of the delegation Global Grid Forum
(GGF) Grid Security Infrastructure working group (GSI-WG),
and the time that Internet Engineering Task Force (IETF) Public-Key
Infrastructure (X.509) working group (PKIX) for feedback
on this document.
tuecke@mcs.anl.gov 41
X.509 Proxy Certificate Profile February 2003
Expires August 2003
This work was supported in part by the
delegation took place Mathematical,
Information, and any entities through which Computational Sciences Division
subprogram of the PC was
delegated (if Office of Advanced Scientific Computing
Research, U.S. Department of Energy, under Contract W-31-
109-Eng-38 and DE-AC03-76SF0098; by the optional DelegationTrace extension is included in Defense Advanced
Research Projects Agency under contract N66001-96-C-8523;
by the PCs in National Science Foundation; and by the cert chain). It may want NASA
Information Power Grid project.
9 Change Log
draft-ietf-pkix-impersonation-00 (February 2001)
Initial submission.
draft-ietf-pkix-proxy-00 (July 2001)
Renamed to use this information in
addition "Proxy Certificate", from "Impersonation
Certificate", due to the information 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 signing EEC. Thus a highly
secure resource might refuse path validation section.
draft-ietf-pkix-proxy-02 (February 2002)
Draft for Global Grid Forum 4 (Toronto)
Added concept of proxy group.
tuecke@mcs.anl.gov 42
X.509 Proxy Certificate Profile February 2003
Expires August 2003
Updated section on keyCertSign bit to accept 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 at all, or maybe only must have a
single level of delegation, or maybe only non-empty subject name.
Proxy subject names are now non-empty and contain a PC that has
sequence of proxy identifiers. Changes to path
validation to reflect this.
subjectAltNames and issuerAltNames are now not been
delegated through a untrusted host, etc.
8 References
[1] Bradner, S., "Key words for use in RFCs present
PCs.
Renamed issuerCertHash to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.
[2] Butler, R., D. Engert, I. Foster, C. Kesselman, issuerCertSignature and S. Tuecke,
"A National-Scale Authentication Infrastructure," IEEE
Computer, vol. 33, pp. 60-66, 2000.
Tuecke, et. al. Expires February 2002 34
Internet
similarly with it's contents.
Added consideration to path validation for PC's with an
infinite path length (i.e. no pCPathLenConstraint).
draft-ggf-gsi-proxy-03 (July 2002)
Draft for GGF-5 (Edinburgh)
Renamed to draft-ggf-gsi-proxy-03
Changed formatting to meet GGF document format
requirements.
Added GGF copyright notice to beginning.
tuecke@mcs.anl.gov 43
X.509 Proxy Certificate Profile 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," February 2003
Expires August 2003
Removed Internet Draft draft-ietf-pkix-
ac509prof-06.txt, January 2001.
[5] Foster, I., C. Kesselman, G. Tsudik, language from status section and S. Tuecke, "A Security
Architecture for Computational Grids," presented at Proceedings
of the 5th ACM Conference on Computer
replaced with current text.
Added Copyright and Communications
Security, 1998.
[6] Foster, I., C. Kesselman, Intellectual Property sections (12
& 13)
Removed Section 3.7.2: DelegationTrace Extension.
Renumbered subsections 3.7.1.x to 3.7.x. Removed
subsections in Section 6 related to this extension and S. Tuecke, "The Anatomy of
replaced with one subsection discussing it.
Proxy Certificate subject name is now issuer name
concatenated with a single unique component. Functional
changes to Sections 3 and 4 to reflect this, numerous
changes throughout the
Grid: Enabling Scalable Virtual Organizations," International
Journal document including removal of Supercomputer Applications, 2001.
[7] Housley, R., W. Ford, W. Polk, and D. Solo, "Internet X.509
Public Key Infrastructure
section 6.3.
Removed text stating the Proxy subject name should only
be used for path validation to leave door open for use
with attribute certificates.
Rewrote 2.6 so reflect that PCs now have unique
identities.
Added new section 2.5 (Motivation for Unique Proxy
Name)
Removed sections 2.7 (Proxy Issuer, not Certificate
Authority) and CRL Profile,"
Internet Draft draft-ietf-pkik-new-part1-12.txt (update 2.8 (Names versus Subjects)
Renamed proxyRestrictions to RFC
2459), 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. proxyPolicy and C. Neuman, "The Kerberos Network Authentication
Service (V5)," RFC 1510, September 1993.
9 Acknowledgments
We are grateful made it a
required field. Numerous changes elsewhere to numerous colleagues for discussions on the topics
covered in reflect
this paper, change.
Removed issuerCertSignature since it is no longer
needed since PCs now have unique names.
Added previously deleted (accidentally?) text 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.
This work was supported 6.1
(keyCertSign Bit commentary).
Cleaned up pCPathLenConstraint checking 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 section 4 by
adding 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 35
Internet Draft max_pc_path_length variable.
tuecke@mcs.anl.gov 44
X.509 Proxy Certificate Profile March 2002
Renamed to "Proxy Certificate", from "Impersonation Certificate",
due to overwhelming feedback from IETF and GGF.
Added proxyRestriction February 2003
Expires August 2003
Removed the proxyGroup field to ProxyCertInfo extension. make document
restriction policy agnostic.
Added delegationTrace field to ProxyCertInfo extension.
Updated to agree with draft-ietf-pkix-part1-08.
draft-ietf-pkix-proxy-01 (August 2001)
Changes related structure to delegation tracing: removed delegationTrace
field from ProxyCertInfo extension, created DelegationTrace
extension, Section 7 (Security Considerations)
and added some text about a relying party trusting all
issuers in a PC chain.
Removed sections 6.1 and modified 6.2 from commentary sections related to
delegation tracing.
Added issuerCertHash since the
PKIX draft is now an RFC and won't be changed.
Moved text from 6.3 to proxyCertInfo extension 3.9.4 and removed section 6.3.
Moved 6.4 to the path
validation section.
draft-ietf-pkix-proxy-02 (February 2002)
Draft for Global Grid Forum 4 (Toronto)
Added concept end of proxy group.
Updated Commentary section.
Moved section on keyCertSign bit 5 (Relationship 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” attribute certificate
to “Proxy Issuer”.
Changed example in Motivations be first section of commentary).
Changed intro 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 commentary and contain a sequence of
proxy identifiers. Changes added text to path validation beginning
of section 2 to reflect this.
subjectAltNames and issuerAltNames indicate that these two sections are now not present PCs.
Renamed issuerCertHash
non-normative.
Changed text in 2.7 to issuerCertSignature and similarly indicate ease of integration
with
it’s contents. existing authorization systems is true only in the
case of impersonation PCs.
Added consideration text to path validation new section 5.1.4 to indicate that
binding ACs to PCs indicates a trust of the PI.
Removed the pC bit - any certificate with a
proxyCertInfo extensions is now a PC.
draft-ggf-gsi-proxy-04 (August 2002)
Minor non-normative editorial corrections.
draft-ietf-pkix-proxy-03 (October 2002)
Name change for PC’s attempted inclusion as a PKIX WG
document. Based on draft-ggf-gsi-proxy-04 with an infinite
path length (i.e. no pCPathLenConstraint).
Tuecke, et. al. Expires February 2002 36
Internet Draft changes
listed below.
Changed reference from "draft update to RFC 2459" to
RFC 3280.
tuecke@mcs.anl.gov 45
X.509 Proxy Certificate Profile March 2002
11 February 2003
Expires August 2003
draft-ietf-pkix-proxt-04 (February 2003)
Rewrote section 4, Path Validation, to be additions to
RFC 3280 path validation instead of changes.
Added Appendix A with ASN.1 module.
Added oids for Impersonation and Independent policy
languages to section 3.9.3.
In section 3.6: keyusage extension in a proxy
certificate only has to be marked critical if marked
critical in the issuer's certificate. Previously it
always had to be marked critical.
10 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
tuecke@mcs.anl.gov 46
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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.
11 Copyright Notice
Copyright (C) The Internet Society (September 23, 2002).
All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation
may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind,
provided that the above copyright notice and this
paragraph are included on all such copies and derivative
works. However, this document itself may not be modified
in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of
developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
tuecke@mcs.anl.gov 47
X.509 Proxy Certificate Profile February 2003
Expires August 2003
12 Intellectual Property Statement
The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to
which any license under such rights might or might not be
available; neither does it represent that it has made any
effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-
track and standards-related documentation can be found in
BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a
general license or permission for the use of such
proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology
that may be required to practice this standard. Please
address the information to the IETF Executive Director.
Appendix A. 1988 ASN.1 Module
PKIXproxy88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-proxy-cert-extns(25) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NONE --
-- PKIX specific OIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
tuecke@mcs.anl.gov 48
X.509 Proxy Certificate Profile February 2002 37 2003
Expires August 2003
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) }
-- modules
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- Locally defined OIDs
-- The proxy certificate extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
-- Proxy certificate policies languages defined in draft
id-ppl-impersonation OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
version Version,
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
-- Only one possible version now
Version ::= INTEGER { v1(1) }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
tuecke@mcs.anl.gov 49
----