[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3820

 Internet Draft                                             S. Tuecke
 Document: draft-ietf-pkix-proxy-10                               ANL
 Expires May 2004                                            V. Welch
                                                                 NCSA
                                                            D. Engert
                                                                  ANL
                                                          L. Pearlman
                                                              USC/ISI
                                                          M. Thompson
                                                                 LBNL
                                                     19 December 2003
 
                Internet X.509 Public Key Infrastructure
                       Proxy Certificate Profile
 
 
 Status of this Memo
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as "work in
    progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
    This document provides information to the community regarding the
    profile of the X.509 Proxy Certificate. It defines a standard for
    implementing X.509 Proxy Certificates.
 
 
 
 
 
 Tuecke, et al.                                                        1 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 Abstract
    This document forms a certificate profile for Proxy Certificates,
    based on X.509 Public Key Infrastructure (PKI) certificates as
    defined in RFC 3280, for use in the Internet.  The term Proxy
    Certificate is used to describe a certificate that is derived from,
    and signed by, a normal X.509 Public Key End Entity Certificate or
    by another Proxy Certificate for the purpose of providing
    restricted proxying and delegation within a PKI based
    authentication system.
 
 Table of Contents
    1  Introduction...................................................3
    2  Overview of Approach...........................................4
    2.1  Terminology..................................................5
    2.2  Background...................................................5
    2.3  Motivation for Proxying......................................6
    2.4  Motivation for Restricted Proxies............................8
    2.5  Motivation for Unique Proxy Name.............................9
    2.6  Description Of Approach.....................................10
    2.7  Features Of This Approach...................................11
    3  Certificate and Certificate Extensions Profile................13
    3.1  Issuer......................................................14
    3.2  Issuer Alternative Name.....................................14
    3.3  Serial Number...............................................14
    3.4  Subject.....................................................14
    3.5  Subject Alternative Name....................................15
    3.6  Key Usage and Extended Key Usage............................15
    3.7  Basic Constraints...........................................15
    3.8  The ProxyCertInfo Extension.................................15
    4  Proxy Certificate Path Validation.............................20
    4.1  Basic Proxy Certificate Path Validation.....................21
    4.2  Using the Path Validation Algorithm.........................25
    5  Commentary....................................................27
    5.1  Relationship to Attribute Certificates......................27
    5.2  Kerberos 5 Tickets..........................................31
    5.3  Examples of usage of Proxy Restrictions.....................32
    5.4  Delegation Tracing..........................................33
    6  Security Considerations.......................................34
    6.1  Compromise of a Proxy Certificate...........................34
    6.2  Restricting Proxy Certificates..............................35
    6.3  Relying Party Trust of Proxy Certificates...................35
    6.4  Protecting Against Denial of Service with Key Generation....36
 
 
 
 Tuecke, et al.                                                        2 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    6.5  Use of Proxy Certificates in a Central Repository...........36
    7  IANA Considerations...........................................37
    8  Normative References..........................................37
    9  Informational References......................................37
    10   Acknowledgments.............................................38
    11   Contact Information.........................................39
    12   Copyright Notice............................................39
    13   Intellectual Property Statement.............................40
    Appendix A. 1988 ASN.1 Module....................................41
    Appendix B. Change Log (To be removed prior to publication)......42
 
 1  Introduction
 
    Use of a proxy credential [i8] is a common technique used in
    security systems to allow entity A to grant to another entity B the
    right for B to be authorized with others as if it were A.  In other
    words, entity B is acting as a proxy on behalf of entity A.  This
    document forms a certificate profile for Proxy Certificates, based
    on the RFC 3280, "Internet X.509 Public Key Infrastructure
    Certificate and CRL Profile" [n2].
 
    In addition to simple, unrestricted proxying, this profile defines:
 
    *  A framework for carrying policies in Proxy Certificates that
       allows proxying to be limited (perhaps completely disallowed)
       through either restrictions or enumeration of rights.
 
    *  Proxy Certificates with unique names, derived from the name of
       the end entity certificate name.  This allows the Proxy
       Certificates to be used in conjunction with attribute assertion
       approaches such as Attribute Certificates [i3] and have their
       own rights independent of their issuer.
 
    Section 2 provides a non-normative overview of the approach.  It
    begins by defining terminology, motivating Proxy Certificates, and
    giving a brief overview of the approach.  It then introduces the
    notion of a Proxy Issuer, as distinct from a Certificate Authority,
    to describe how end entity signing of a Proxy Certificate is
    different from end entity signing of another end entity
    certificate, and therefore why this approach does not violate the
    end entity signing restrictions contained in the X.509 keyCertSign
    field of the keyUsage extension.  It then continues with
 
 
 
 
 Tuecke, et al.                                                        3 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    discussions of how subject names are used by this proxying
    approach, and features of this approach.
 
    Section 3 defines requirements on information content in Proxy
    Certificates.  This profile addresses two fields in the basic
    certificate as well as five certificate extensions.  The
    certificate fields are the subject and issuer fields.  The
    certificate extensions are subject alternative name, issuer
    alternative name, key usage, basic constraints, and extended key
    usage.  A new certificate extension, Proxy Certificate Information,
    is introduced.
 
    Section 4 defines path validation rules for Proxy Certificates.
 
    Section 5 provides non-normative commentary on Proxy Certificates.
 
    Section 6 discusses security considerations relating to Proxy
    Certificates.
 
    References in this document are sorted into normative and
    information references.  Normative references, listed in Section 8,
    are in the form [nXX].  Informative references, listed in Section
    9, are in the form [iXX].
 
    Section 10 contains acknowledgements.
 
    Section 11 contains contact information for the authors.
 
    Section 12 contains the copyright information for this document.
 
    Section 13 contains the intellectual property information for this
    document.
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in RFC-2119 [n1].
 
 2  Overview of Approach
 
    This section provides non-normative commentary on Proxy
    Certificates.
 
 
 
 
 
 Tuecke, et al.                                                        4 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    The goal of this specification is to develop a X.509 Proxy
    Certificate profile and to facilitate their use within Internet
    applications for those communities wishing to make use of
    restricted proxying and delegation within an X.509 Public Key
    Infrastructure (PKI) authentication based system.
 
    This section provides relevant background, motivation, an overview
    of the approach, and related work.
 
 2.1 Terminology
 
    This document uses the following terms:
 
    *  CA: A "Certificate Authority", as defined by X.509 [n2].
 
    *  EEC: An "End Entity Certificate", as defined by X.509.  That is,
       it is an X.509 Public Key Certificate issued to an end entity,
       such as a user or a service, by a CA.
 
    *  PKC: An end entity "Public Key Certificate".  This is synonymous
       with an EEC.
 
    *  PC: A "Proxy Certificate", the profile of which is defined by
       this document.
 
    *  PI: A "Proxy Issuer" is an entity with an End Entity Certificate
       or Proxy Certificate that issues a Proxy Certificate. The Proxy
       Certificate is signed using the private key associated with the
       public key in the Proxy Issuer's certificate.
 
    *  AC: An "Attribute Certificate", as defined by "An Internet
       Attribute Certificate Profile for Authorization" [i3].
 
    *  AA: An "Attribute Authority", as defined in [i3].
 
 2.2 Background
 
    Computational and Data "Grids" have emerged as a common approach to
    constructing dynamic, inter-domain, distributed computing
    environments.  As explained in [i5], large research and development
    efforts starting around 1995 have focused on the question of what
    protocols, services, and APIs are required for effective,
    coordinated use of resources in these Grid environments.
 
 
 
 Tuecke, et al.                                                        5 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 
    In 1997, the Globus Project (www.globus.org) introduced the Grid
    Security Infrastructure (GSI) [i4].  This library provides for
    public key based authentication and message protection, based on
    standard X.509 certificates and public key infrastructure, the
    SSL/TLS protocol [i2], and delegation using proxy certificates
    similar to those profiled in this document.  GSI has been used, in
    turn, to build numerous middleware libraries and applications,
    which have been deployed in large-scale production and experimental
    Grids [i1].  GSI has emerged as the dominant security solution used
    by Grid efforts worldwide.
 
    This experience with GSI has proven the viability of restricted
    proxying as a basis for authorization within Grids, and has further
    proven the viability of using X.509 Proxy Certificates, as defined
    in this document, as the basis for that proxying.  This document is
    one part of an effort to migrate this experience with GSI into
    standards, and in the process clean up the approach and better
    reconcile it with existing and recent standards.
 
 2.3 Motivation for Proxying
 
    A motivating example will assist in understanding the role proxying
    can play in building Internet based applications.
 
    Steve is an engineer who wants to use a reliable file transfer
    service to manage the movement of a number of large files around
    between various hosts on his company's Intranet-based Grid.  From
    his laptop he wants to submit a number of transfer requests to the
    service and have the files transferred while he is doing other
    things, including being offline.  The transfer service may queue
    the requests for some time (e.g. until after hours or a period of
    low resource usage) before initiating the transfers.  The transfer
    service will then, for each file, connect to each of the source and
    destination hosts, and instruct them initiate a data connection
    directly from the source to the destination in order to transfer
    the file.  Steve will leave an agent running on his laptop that
    will periodically check on progress of the transfer by contacts the
    transfer service.  Of course, he wants all of this to happen
    securely on his company's resources, which requires that he
    initiate all of this using his PKI smartcard.
 
 
 
 
 
 Tuecke, et al.                                                        6 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    This scenario requires authentication and delegation in a variety
    of places:
 
    *  Steve needs to be able to mutually authenticate with the remote
       file transfer service to submit the transfer request.
 
    *  Since the storage hosts know nothing about the file transfer
       service, the file transfer service needs to be delegated the
       rights to mutually authenticate with the various storage hosts
       involved directly in the file transfer, in order to initiate the
       file transfer.
 
    *  The source and destination hosts of a particular transfer must
       be able to mutual authenticate with each other, to ensure the
       file is being transferred to and from the proper parties.
 
    *  The agent running on Steve's laptop must mutually authenticate
       with the file transfer service in order to check the result of
       the transfers.
 
    Proxying is a viable approach to solving two (related) problems in
    this scenario:
 
    *  Single sign-on: Steve wants to enter his smartcard password (or
       pin) once, and then run a program that will submit all the file
       transfer requests to the transfer service, and then periodically
       check on the status of the transfer.  This program needs to be
       given the rights to be able to perform all of these operations
       securely, without requiring repeated access to the smartcard or
       Steve's password.
 
    *  Delegation: Various remote processes in this scenario need to
       perform secure operations on Steve's behalf, and therefore must
       be delegated the necessary rights.  For example, the file
       transfer service needs to be able to authenticate on Steve's
       behalf with the source and destination hosts, and must in turn
       delegate rights to those hosts so that they can authenticate
       with each other.
 
    Proxying can be used to secure all of these interactions:
 
    *  Proxying allows for the private key stored on the smartcard to
       be accessed just once, in order to create the necessary proxy
 
 
 
 Tuecke, et al.                                                        7 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       credential, which allows the client/agent program to be
       authorized as Steve when submitting the requests to the transfer
       service.  Access to the smartcard and Steve's password is not
       required after the initial creation of the proxy credential.
 
    *  The client program on the laptop can delegate to the file
       transfer service the right to act on Steve's behalf.  This, in
       turn, allows the service to authenticate to the storage hosts
       and inherit Steve's privileges in order to start the file
       transfers.
 
    *  When the transfer service authenticates to hosts to start the
       file transfer, the service can delegate to the hosts the right
       to act on Steve's behalf so that each pair of hosts involved in
       a file transfer can mutually authenticate to ensure the file is
       securely transferred.
 
    *  When the agent on the laptop reconnects to the file transfer
       service to check on the status of the transfer, it can perform
       mutual authentication.  The laptop may use a newly generated
       proxy credential, which is just created anew using the
       smartcard.
 
    This scenario, and others similar to it, is being built today
    within the Grid community.  The Grid Security Infrastructure's
    single sign-on and delegation capabilities, built on X.509 Proxy
    Certificates, are being employed to provide authentication services
    to these applications.
 
 2.4 Motivation for Restricted Proxies
 
    One concern that arises is what happens if a machine that has been
    delegated the right to inherit Steve's privileges has been
    compromised?  For example, in the above scenario, what if the
    machine running the file transfer service is compromised, such that
    the attacker can gain access to the credential that Steve delegated
    to that service?  Can the attacker now do everything that Steve is
    allowed to do?
 
    A solution to this problem is to allow for restrictions to be
    placed on the proxy by means of policies on the proxy certificates.
    For example, the machine running the reliable file transfer service
    in the above example might only be given Steve's right for the
 
 
 
 Tuecke, et al.                                                        8 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    purpose of reading the source files and writing the destination
    files.  Therefore, if that file transfer service is compromised,
    the attacker cannot modify source files, cannot create or modify
    other files to which Steve has access, cannot start jobs on behalf
    of Steve, etc.  All that an attacker would be able to do is read
    the specific files to which the file transfer service has been
    delegated read access, and write bogus files in place of those that
    the file transfer service has been delegated write access.
    Further, by limiting the lifetime of the credential that is
    delegated to the file transfer service, the effects of a compromise
    can be further mitigated.
 
    Other potential uses for restricted proxy credentials are discussed
    in [i8].
 
 2.5 Motivation for Unique Proxy Name
 
    The dynamic creation of entities (e.g. processes and services) is
    an essential part of Grid computing.  These entities will require
    rights in order to securely perform their function. While it is
    possible to obtain rights solely through proxying as described in
    previous sections, this has limitations.  For example what if an
    entity should have rights that are granted not just from the proxy
    issuer but from a third party as well?  While it is possible in
    this case for the entity to obtain and hold two proxy
    certifications, in practice it is simpler for subsequent
    credentials to take the form of attribute certificates.
 
    It is also desirable for these entities to have a unique identity
    so that they can be explicitly discussed in policy statements. For
    example, a user initiating a third-party FTP transfer could grant
    each FTP server a PC with a unique identity and inform each server
    of the identity of the other, then when the two servers connected
    they could authenticate themselves and know they are connected to
    the proper party.
 
    In order for a party to have rights of it's own it requires a
    unique identity.  Possible options for obtaining an unique identity
    are:
 
    1) Obtain an identity from a traditional Certification Authority
      (CA).
 
 
 
 
 Tuecke, et al.                                                        9 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    2) Obtain a new identity independently - for example by using the
      generated public key and a self-signed certificate.
 
    3) Derive the new identity from an existing identity.
 
    In this document we describe an approach to option #3, because:
 
    *  It is reasonably light-weight, as it can be done without
       interacting with a third party.  This is important when creating
       identities dynamically.
 
    *  As described in the previous section, a common use for PCs is
       for restricted proxying, so deriving their identity from the
       identity of the EEC makes this straightforward.  Nonetheless
       there are circumstances where the creator does not wish to
       delegate all or any of its rights to a new entity.  Since the
       name is unique, this is easily accomplished by #3 as well, by
       allowing the application of a policy to limit proxying.
 
 2.6 Description Of Approach
 
    This document defines an X.509 "Proxy Certificate" or "PC" as a
    means of providing for restricted proxying within an (extended)
    X.509 PKI based authentication system.
 
    A Proxy Certificate is an X.509 public key certificate with the
    following properties:
 
    1) It is signed by either an X.509 End Entity Certificate (EEC), or
       by another PC.  This EEC or PC is referred to as the Proxy
       Issuer (PI).
 
    2) It can sign only another PC.  It cannot sign an EEC.
 
    3) It has its own public and private key pair, distinct from any
       other EEC or PC.
 
    4) It has an identity derived from the identity of the EEC that
       signed the PC.  When a PC is used for authentication, in may
       inherit rights of the EEC that signed the PC, subject to the
       restrictions that are placed on that PC by the EEC.
 
 
 
 
 
 Tuecke, et al.                                                       10 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    5) Although its identity is derived from the EEC's identity, it is
       also unique.  This allows this identity to be used for
       authorization as an independent identity from the identity of
       the issuing EEC, for example in conjunction with attribute
       assertions as defined in [i3].
 
    6) It contains a new X.509 extension to identify it as a PC and to
       place policies on the use of the PC.  This new extension, along
       with other X.509 fields and extensions, are used to enable
       proper path validation and use of the PC.
 
    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).
 
    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.
 
 2.7 Features Of This Approach
 
    Using Proxy Certificates to perform delegation has several features
    that make it attractive:
 
    *  Ease of integration
 
       .  Because a PC requires only a minimal change to path
          validation, it is very easy to incorporate support for Proxy
 
 
 
 Tuecke, et al.                                                       11 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
          Certificates into existing X.509 based software.  For
          example, SSL/TLS requires no protocol changes to support
          authentication using a PC.  Further, an SSL/TLS
          implementation requires only minor changes to support PC path
          validation, and to retrieve the authenticated subject of the
          signing EEC instead of the subject of the PC for
          authorization purposes.
 
       .  Many existing authorization systems use the X.509 subject
          name as the basis for access control.  Proxy Certificates can
          be used with such authorization systems without modification,
          since such a PC inherits its name and rights from the EEC
          that signed it and the EEC name can be used in place of the
          PC name for authorization decisions.
 
    *  Ease of use
 
       .  Using PC for single sign-on helps make X.509 PKI
          authentication easier to use, by allowing users to "login"
          once and then perform various operations securely.
 
       .  For many users, properly managing their own EEC private key
          is a nuisance at best, and a security risk at worst.  One
          option easily enabled with a PC is to manage the EEC private
          keys and certificates in a centrally managed repository.
          When a user needs a PKI credential, the user can login to the
          repository using name/password, one time password, etc.  Then
          the repository can delegate a PC to the user with proxy
          rights, but continue to protect the EEC private key in the
          repository.
 
    *  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 of the newly delegated PC held by
          entity B.  In other words, private keys never need to be
          shared or communicated by the entities participating in a
          delegation of a PC.
 
       .  When implementing single sign-on, using a PC helps protect
          the private key of the EEC, because it minimizes the exposure
 
 
 
 Tuecke, et al.                                                       12 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
          and use of that private key.  For example, when an EEC
          private key is password protected on disk, the password and
          unencrypted private key need only be available during the
          creation of the PC.  That PC can then be used for the
          remainder of its valid lifetime, without requiring access to
          the EEC password or private key.  Similarly, when the EEC
          private key lives on a smartcard, the smartcard need only be
          present in the machine during the creation of the PC.
 
    *  Limiting consequences of a compromised key
 
       .  When creating a PC, the PI can limit the validity period of
          the PC, the depth of the PC path that can be created by that
          PC, and key usage of the PC and its descendents.  Further,
          fine-grained policies can be carried by a PC to even further
          restrict the operations that can be performed using the PC.
          These restrictions permit the PI to limit damage that could
          be done by the bearer of the PC, either accidentally or
          maliciously.
 
       .  A compromised PC private key does NOT compromise the EEC
          private key.  This makes a short term, or an otherwise
          restricted PC attractive for day-to-day use, since a
          compromised PC does not require the user to go through the
          usually cumbersome and time consuming process of having the
          EEC with a new private key reissued by the CA.
 
    See Section 5 below for more discussion on how Proxy Certificates
    relate to Attribute Certificates.
 
 3  Certificate and Certificate Extensions Profile
 
    This section defines the usage of X.509 certificate fields and
    extensions in Proxy Certificates, and defines one new extension for
    Proxy Certificate Information.
 
    All Proxy Certificates MUST include the Proxy Certificate
    Information (ProxyCertInfo) extension defined in this section and
    the extension MUST be critical.
 
 
 
 
 
 
 
 Tuecke, et al.                                                       13 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 3.1 Issuer
 
    The Proxy Issuer of a Proxy Certificate MUST be either an End
    Entity Certificate, or another Proxy Certificate.
 
    The Proxy Issuer MUST NOT have an empty subject field.
 
    The issuer field of a Proxy Certificate MUST contain the subject
    field of its Proxy Issuer.
 
    If the Proxy Issuer certificate has the KeyUsage extension, the
    Digital Signature bit MUST be asserted.
 
 3.2 Issuer Alternative Name
 
    The issuerAltName extension MUST NOT be present in a Proxy
    Certificate.
 
 3.3 Serial Number
 
    The serial number of a Proxy Certificate (PC) SHOULD be unique
    amongst all Proxy Certificates issued by a particular Proxy Issuer.
    However, a Proxy Issuer MAY use an approach to assigning serial
    numbers that merely ensures a high probability of uniqueness.
 
    For example, a Proxy Issuer MAY use a sequentially assigned integer
    or a UUID to assign a unique serial number to a PC it issues.  Or a
    Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a
    serial number with a high probability of uniqueness.
 
 3.4 Subject
 
    The subject field of a Proxy Certificate MUST be the issuer field
    (that is the subject of the Proxy Issuer) appended with a single
    Common Name component.
 
    The value of the Common Name SHOULD be unique to each Proxy
    Certificate bearer amongst all Proxy Certificates with the same
    issuer.
 
    If a Proxy Issuer issues two proxy certificates to the same bearer,
    the Proxy Issuer MAY choose to use the same Common Name for both.
    Examples of this include Proxy Certificates for different uses
 
 
 
 Tuecke, et al.                                                       14 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    (e.g. signing vs encryption) or the re-issuance of an expired Proxy
    Certificate.
 
    The Proxy Issuer MAY use an approach to assigning Common Name
    values that merely ensures a high probability of uniqueness. This
    value MAY be the same value used for the serial number.
 
    The result of this approach is that all subject names of Proxy
    Certificates are derived from the name of the issuing EEC (it will
    be the first part of the subject name appended with one or more CN
    components) and are unique to each bearer.
 
 3.5 Subject Alternative Name
 
    The subjectAltName extension MUST NOT be present in a Proxy
    Certificate.
 
 3.6 Key Usage and Extended Key Usage
 
    If the Proxy Issuer certificate has a Key Usage extension, the
    Digital Signature bit MUST be asserted.
 
    This draft places no constraints on the presence or contents of the
    key usage and extended key usage extension.  However, section 4.2
    explains what functions should be allowed a proxy certificate by a
    relying party.
 
 3.7 Basic Constraints
 
    The cA field in the basic constraints extension MUST NOT be TRUE.
 
 3.8 The ProxyCertInfo Extension
 
    A new extension, ProxyCertInfo, is defined in this subsection.
    Presence of the ProxyCertInfo extension indicates that a
    certificate is a Proxy Certificate and whether or not the issuer of
    the certificate has placed any restrictions on its use.
 
    id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
 
    id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
 
 
 
 
 Tuecke, et al.                                                       15 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
 
    ProxyCertInfo ::= SEQUENCE {
         pCPathLenConstraint   INTEGER (0..MAX) OPTIONAL,
         proxyPolicy           ProxyPolicy }
 
 
    ProxyPolicy ::= SEQUENCE {
         policyLanguage        OBJECT IDENTIFIER,
         policy          OCTET STRING OPTIONAL }
 
    If a certificate is a Proxy Certificate, then the proxyCertInfo
    extension MUST be present, and this extension MUST be marked as
    critical.
 
    If a certificate is not a Proxy Certificate, then the proxyCertInfo
    extension MUST be absent.
 
    The ProxyCertInfo extension consists of one required and two
    optional fields, which are described in detail in the following
    subsections.
 
 3.8.1 pCPathLenConstraint
 
    The pCPathLenConstraint field, if present, specifies the maximum
    depth of the path of Proxy Certificates that can be signed by this
    Proxy Certificate.  A pCPathLenConstraint of 0 means that this
    certificate MUST NOT be used to sign a Proxy Certificate.  If the
    pCPathLenConstraint field is not present then the maximum proxy
    path length is unlimited. End entity certificates have unlimited
    maximum proxy path lengths.
 
 3.8.2 proxyPolicy
 
    The proxyPolicy field specifies a policy on the use of this
    certificate for the purposes of authorization.  Within the
    proxyPolicy, the policy field is an expression of policy, and the
    policyLanguage field indicates the language in which the policy is
    expressed.
 
    The proxyPolicy field in the proxyCertInfo extension does not
    define a policy language to be used for proxy restrictions; rather,
    it places the burden on those parties using that extension to
 
 
 
 Tuecke, et al.                                                       16 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    define an appropriate language, and to acquire an OID for that
    language (or to select an appropriate previously-defined
    language/OID).  Because it is essential for the PI that issues a
    certificate with a proxyPolicy field and the relying party that
    interprets that field to agree on its meaning, the policy language
    OID must correspond to a policy language (including semantics), not
    just a policy grammar.
 
    The policyLanguage field has two values of special importance,
    defined in Appendix A, that MUST be understood by all parties
    accepting Proxy Certificates:
 
    *  id-ppl-inheritAll indicates that this is an unrestricted proxy
       that inherits all rights from the issuing PI. An unrestricted
       proxy is a statement that the Proxy Issuer wishes to delegate
       all of its authority to the bearer (i.e., to anyone who has that
       proxy certificate and can prove possession of the associated
       private key).  For purposes of authorization, this an
       unrestricted proxy effectively impersonates the issuing PI.
 
    *  id-ppl-independent indicates that this is an independent proxy
       that inherits no rights from the issuing PI.  This PC MUST be
       treated as an independent identity by relying parties. The only
       rights this PC has are those granted explicitly to it.
 
    For either of the policyLanguage values listed above, the policy
    field MUST NOT be present.
 
    Other values for the policyLanguage field indicates that this is a
    restricted proxy certification and have some other policy limiting
    its ability to do proxying.  In this case the policy field MAY be
    present and it MUST contain information expressing the policy.  If
    the policy field is not present the policy MUST be implicit in the
    value of the policyLanguage field itself.  Authors of additional
    policy languages are encouraged to publicly document their policy
    language and list it in the IANA registry (see Section Error!
    Reference source not found.).
 
    Proxy policies are used to limit the amount of authority delegated,
    for example to assert that the proxy certificate may be used only
    to make requests to a specific server, or only to authorize
    specific operations on specific resources.  This document is
    agnostic to the policies that can be placed in the policy field.
 
 
 
 Tuecke, et al.                                                       17 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 
    Proxy policies impose additional requirements on the relying party,
    because only the relying party is in a position to ensure that
    those policies are enforced.  When making an authorization decision
    based on a proxy certificate based on rights that proxy certificate
    inherited from its issuer, it is the relying party's responsibility
    to verify that the requested authority is compatible with all
    policies in the PC's certificate path.  In other words, the relying
    party MUST verify that the following three conditions are all met:
 
   1) The relying party MUST know how to interpret the proxy policy and
      the request is allowed under that policy.
 
   2) If the Proxy Issuer is an EEC then the relying party's local
      policies MUST authorize the request for the entity named in the
      EEC.
 
   3) If the Proxy Issuer is another PC, then one of the following MUST
      be true:
 
        a. The relying party's local policies authorize the Proxy
           Issuer to perform the request.
 
        b. The Proxy Issuer inherits the right to perform the request
           from its issuer by means of its proxy policy. This must be
           verified by verifying these three conditions on the Proxy
           Issuer in a recursive manner.
 
    If these conditions are not met, the relying party MUST either deny
    authorization, or ignore the PC and the whole certificate chain
    including the EEC entirely when making its authorization decision
    (i.e., make the same decision that it would have made had the PC
    and it's certificate chain never been presented).
 
    The relying party MAY impose additional restrictions as to which
    proxy certificates it accepts.  For example, a relying party MAY
    choose to reject all proxy certificates, or MAY choose to accept
    proxy certificates only for certain operations, etc.
 
    Note that since a proxy certificate has a unique identity it MAY
    also have rights granted to it by means other than inheritance from
    it's issuer via its proxy policy. The rights granted to the bearer
    of a PC are the union of the rights granted to the PC identity and
 
 
 
 Tuecke, et al.                                                       18 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    the inherited rights.  The inherited rights consist of the
    intersection of the rights granted to the PI identity intersected
    with the proxy policy in the PC.
 
    For example, imagine that Steve is authorized to read and write
    files A and B on a file server, and that he uses his EEC to create
    a PC that includes the policy that it can be used only to read or
    write files A and C.  Then a trusted attribute authority grants an
    Attribute Certificate granting the PC the right to read file D.
    This would make the rights of the PC equal to the union of the
    rights granted to the PC identity (right to read file D) with the
    intersection of the rights granted to Steve, the PI, (right to read
    files A and B) with the policy in the PC (can only read files A and
    C).  This would mean the PC would have the following rights:
 
    *  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
    path is validated.  For example, if a certificate is used to
    authenticate a connection to some server, that certificate is
    typically validated during that authentication step, before any
    requests have been made of the server.  In that case, the relying
    party MUST either have some authorization mechanism in place that
    will check the proxy policies, or reject any certificate that
    contains proxy policies (or that has a parent certificate that
    contains proxy policies).
 
 
 
 
 
 
 
 Tuecke, et al.                                                       19 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 4  Proxy Certificate Path Validation
 
    Proxy Certification path processing verifies the binding between
    the proxy certificate distinguished name and proxy certificate
    public key.  The binding is limited by constraints which are
    specified in the certificates which comprise the path and inputs
    which are specified by the relying party.
 
    This section describes an algorithm for validating proxy
    certification paths.  Conforming implementations of this
    specification are not required to implement this algorithm, but
    MUST provide functionality equivalent to the external behavior
    resulting from this procedure.  Any algorithm may be used by a
    particular implementation so long as it derives the correct result.
 
    The algorithm presented in this section validates the proxy
    certificate with respect to the current date and time.  A
    conformant implementation MAY also support validation with respect
    to some point in the past.  Note that mechanisms are not available
    for validating a proxy certificate with respect to a time outside
    the certificate validity period.
 
    Valid paths begin with the end entity certificate (EEC) that has
    already been validated by public key certificate validation
    procedures in RFC 3280 [n2].  The algorithm requires the public key
    of the EEC and the EEC's subject distinguished name.
 
    To meet the goal of verifying the proxy certificate, the proxy
    certificate path validation process verifies, among other things,
    that a prospective certification path (a sequence of n
    certificates) satisfies the following conditions:
 
       (a) for all x in {1, ..., n-1}, the subject of certificate x is
       the issuer of proxy certificate x+1 and the subject
       distinguished name of certificate x+1 is a legal subject
       distinguished name to have been issued by certificate x;
 
       (b) certificate 1 is valid proxy certificate issued by the end
       entity certificate whose information is given as input to the
       proxy certificate path validation process;
 
       (c) certificate n is the proxy certificate to be validated;
 
 
 
 
 Tuecke, et al.                                                       20 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       (d) for all x in {1, ..., n}, the certificate was valid at the
       time in question; and
 
       (e) for all certificates in the path with a pCPathLenConstraint
       field, the number of certificates in the path following that
       certificate does not exceed the length specified in that field.
 
    At this point there is no mechanism defined for revoking proxy
    certificates.
 
 4.1 Basic Proxy Certificate Path Validation
 
    This section presents the algorithm in four basic steps to mirror
    the description of public key certificate path validation in RFC
    3280: (1) initialization, (2) basic proxy certificate processing,
    (3) preparation for the next proxy certificate, and (4) wrap-up.
    Steps (1) and (4) are performed exactly once.  Step (2) is
    performed for all proxy certificates in the path.  Step (3) is
    performed for all proxy certificates in the path except the final
    proxy certificate.
 
    Certificate path validation as described in RFC 3280 MUST have been
    done prior to using this algorithm to validate the end entity
    certificate.  This algorithm then processes the proxy certificate
    chain using the end entity certificate information produced by RFC
    3280 path validation.
 
 4.1.1 Inputs
 
    This algorithm assumes the following inputs are provided to the
    path processing logic:
 
       (a) information about the entity certificate already verified
       using RFC 3280 path validation.  This information includes:
 
          (1) the end entity name,
 
          (2) the working_public_key output from RFC 3280 path
          validation,
 
          (3) the working_public_key_algorithm output from RFC 3280,
 
 
 
 
 
 Tuecke, et al.                                                       21 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
          (4) and the working_public_key_parameters output from RFC
          3280 path validation.
 
       (b) prospective proxy certificate path of length n.
 
       (c) acceptable-pc-policy-language-set: A set of proxy
       certificate policy languages understood by the policy evaluation
       code.  The acceptable-pc-policy-language-set MAY contain the
       special value id-ppl-anyLanguage (as defined in Appendix A) if
       the path validation code should not check the proxy certificate
       policy languages (typically because the set of known policy
       languages is not known yet and will be checked later in the
       authorization process).
 
       (d) the current date and time.
 
 4.1.2 Initialization
 
    This initialization phase establishes the following state variables
    based upon the inputs:
 
       (a) working_public_key_algorithm: the digital signature
       algorithm used to verify the signature of a proxy certificate.
       The working_public_key_algorithm is initialized from the input
       information provided from RFC 3280 path validation.
 
       (b) working_public_key: the public key used to verify the
       signature of a proxy certificate.  The  working_public_key is
       initialized from the input information provided from RFC 3280
       path validation.
 
       (c) working_public_key_parameters:  parameters associated with
       the current public key, that may be required to verify a
       signature (depending upon the algorithm).  The
       proxy_issuer_public_key_parameters variable is initialized from
       the input information provided from RFC 3280 path validation.
 
       (d) working_issuer_name: the issuer distinguished name  expected
       in the next proxy certificate in the chain.  The
       working_issuer_name is initialized to the distinguished name in
       the end entity certificate validated by RFC 3280 path
       validation.
 
 
 
 
 Tuecke, et al.                                                       22 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       (e) max_path_length: this integer is initialized to n, is
       decremented for each proxy certificate in the path. This value
       may also be reduced by the pcPathLenConstraint value of any
       proxy certificate in the chain.
 
       (f) proxy_policy_list: this list is empty to start and will be
       filled in with the key usage extensions, extended key usage
       extensions and proxy policies in the chain.
 
    Upon completion of the initialization steps, perform the basic
    certificate processing steps specified in 4.1.3.
 
 4.1.3 Basic Proxy Certificate Processing
 
    The basic path processing actions to be performed for proxy
    certificate i (for all i in [1..n]) are listed below.
 
       (a) Verify the basic certificate information.  The certificate
       MUST satisfy each of the following:
 
          (1) The certificate was signed with the
          working_public_key_algorithm using the working_public_key and
          the working_public_key_parameters.
 
          (2) The certificate validity period includes the current
          time.
 
          (3) The certificate issuer name is the working_issuer_name.
 
          (4) The certificate subject name is the working_issuer_name
          with a CN component appended.
 
       (b) The proxy certificate MUST have a ProxyCertInfo extension.
       Process the extension as follows:
 
          (1) If the pCPathLenConstraint field is present in the
          ProxyCertInfo field and the value it contains is less than
          max_path_length, set max_path_length to its value.
 
          (2) If acceptable-pc-policy-language-set is not id-ppl-
          anyLanguage, the OID in the policyLanguage field MUST be
          present in acceptable-pc-policy-language-set.
 
 
 
 
 Tuecke, et al.                                                       23 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       (c) The tuple containing the certificate subject name,
       policyPolicy, key usage extension (if present) and extended key
       usage extension (if present) must be appended to
       proxy_policy_list.
 
       (d) Process other certificate extensions, as described in [n2]:
 
          (1) Recognize and process any other critical extensions
          present in the proxy certificate.
 
          (2) Process any recognized non-critical extension present in
          the proxy certificate.
 
    If either step (a), (b) or (d) fails, the procedure terminates,
    returning a failure indication and an appropriate reason.
 
    If i is not equal to n, continue by performing the preparatory
    steps listed in 4.1.4.  If i is equal to n, perform the wrap-up
    steps listed in 4.1.5.
 
 4.1.4 Preparation for next Proxy Certificate
 
       (a) Verify max_path_length is greater than zero and decrement
       max_path_length.
 
       (b) Assign the certificate subject name to working_issuer_name.
 
       (c) Assign the certificate subjectPublicKey to
       working_public_key.
 
       (d) If the subjectPublicKeyInfo field of the certificate
       contains an algorithm field with non-null parameters, assign the
       parameters to the working_public_key_parameters variable.
 
       If the subjectPublicKeyInfo field of the certificate contains an
       algorithm field with null parameters or parameters are omitted,
       compare the certificate subjectPublicKey algorithm to the
       working_public_key_algorithm.  If the certificate
       subjectPublicKey algorithm and the working_public_key_algorithm
       are different, set the working_public_key_parameters to null.
 
       (e) Assign the certificate subjectPublicKey algorithm to the
       working_public_key_algorithm variable.
 
 
 
 Tuecke, et al.                                                       24 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 
       (f) If a key usage extension is present, verify that the
       digitalSignature bit is set.
 
    If either check (a) or (f) fails, the procedure terminates,
    returning a failure indication and an appropriate reason.
 
    If (a) and (f) complete successfully, increment i and perform the
    basic certificate processing specified in 4.1.3.
 
 4.1.5 Wrap-up Procedures
 
       (a) Assign the certificate subject name to working_issuer_name.
 
       (b) Assign the certificate subjectPublicKey to
       working_public_key.
 
       (c) If the subjectPublicKeyInfo field of the certificate
       contains an algorithm field with non-null parameters, assign the
       parameters to the proxy_issuer_public_key_parameters variable.
 
       If the subjectPublicKeyInfo field of the certificate contains an
       algorithm field with null parameters or parameters are omitted,
       compare the certificate subjectPublicKey algorithm to the
       proxy_issuer_public_key_algorithm.  If the certificate
       subjectPublicKey algorithm and the
       proxy_issuer_public_key_algorithm are different, set the
       proxy_issuer_public_key_parameters to null.
 
       (d) Assign the certificate subjectPublicKey algorithm to the
       proxy_issuer_public_key_algorithm variable.
 
 4.1.6 Outputs
 
    If path processing succeeds, the procedure terminates, returning a
    success indication together with final value of the
    working_public_key, the  working_public_key_algorithm, the
    working_public_key_parameters, and the proxy_policy_list.
 
 4.2 Using the Path Validation Algorithm
 
    Each Proxy Certificate contains a ProxyCertInfo extension, which
    always contains a policy language OID, and may also contain a
 
 
 
 Tuecke, et al.                                                       25 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    policy OCTET STRING. These policies serve to indicate the desire of
    each issuer in the proxy certificate chain, starting with the EEC,
    to delegate some subset of their rights to the issued proxy
    certificate.  This chain of policies is returned by the algorithm
    to the application.
 
    The application MAY make authorization decisions based on the
    subject distinguished name of the proxy certificate or on one of
    the proxy certificates in it's issuing chain or on the EEC that
    serves as the root of the chain.  If an application chooses to use
    the subject distinguished name of a proxy certificate in the
    issuing chain or the EEC it MUST use the returned policies to
    restrict the rights it grants to the proxy certificate.  If the
    application does not know how to parse any policy in the policy
    chain it MUST not use, for the purposes of making authorization
    decisions, the subject distinguished name of any certificate in the
    chain prior to the certificate in which the unrecognized policy
    appears.
 
    Application making authorization decisions based on the contents of
    the proxy certificate key usage or extended key usage extensions
    MUST examine the list of key usage, extended key usage and proxy
    policies resulting from proxy certificate path validation and
    determine the effective key usage functions of the proxy
    certificate as follows:
 
    *  If a certificate is a proxy certificate with a proxy policy of
       id-ppl-independent or an end entity certificate, the effective
       key usage functions of that certificate is as defined by the key
       usage and extended key usage extensions in that certificate. The
       key usage functionality of the issuer has no bearing on the
       effective key usage functionality.
 
    *  If a certificate is a proxy certificate with a policy other than
       id-ppl-independent, the effective key usage and extended key
       usage functionality of the proxy certificate is the intersection
       of the functionality of those extensions in the proxy
       certificate and the effective key usage functionality of the
       proxy issuer.
 
 
 
 
 
 
 
 Tuecke, et al.                                                       26 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 5  Commentary
 
    This section provides non-normative commentary on Proxy
    Certificates.
 
 5.1 Relationship to Attribute Certificates
 
    An Attribute Certificate [i3] can be used to grant to one identity,
    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
    either solution alone.  This section seeks to clarify some of the
    overlaps, differences, and synergies between Proxy Certificate and
    Attribute Certificates.
 
 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 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.
 
 
 
 Tuecke, et al.                                                       27 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 
    This second type of Attribute Authority, the third party AA, works
    equally well with an EEC or a PC.  For example, unrestricted Proxy
    Certificates can be used to delegate the EEC's identity to various
    other parties.  Then when one of those other parties uses the PC to
    authenticate with a service, that service will receive the EEC's
    identity via the PC, and can apply any ACs that bind that identity
    to attributes in order to determine authorization rights.
    Additionally PC with policies could be used to selectively deny the
    binding of ACs to a particular proxy. An AC could also be bound to
    a particular PC using the subject or issuer and serial number of
    the proxy certificate. There would appear to be great synergies
    between the use of Proxy Certificates and Attribute Certificates
    produced by third party Attribute Authorities.
 
    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.1.2 Delegation Using Attribute Certificates
 
    In the motivating example in Section 2, PCs are used to delegate
    Steve's identity to the various other jobs and entities that need
    to act on Steve's behalf.  This allows those other entities to
    authenticate as if they were Steve, for example to the mass storage
    system.
 
    A solution to this example could also be cast using Attribute
    Certificates that are signed by Steve's EEC, which grant to the
    other entities in this example the right to perform various
    operations on Steve's behalf.  In this example, the reliable file
    transfer service and all the hosts involved in file transfers, the
    starter program, the agent, the simulation jobs, and the post-
    processing job would each have their own EECs.  Steve's EEC would
    therefore issue ACs to bind each of those other EEC identities to
    attributes that grant the necessary privileges allow them to, for
    example, access the mass storage system.
 
 
 
 
 
 Tuecke, et al.                                                       28 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    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 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 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.1.3 Propagation of Authorization Information
 
    One possible use of Proxy Certificates is to carry authorization
    information associated with a particular identity.
 
    The merits of placing authorization information into End Entity
    Certificates (also called a Public Key Certificate or PKC) have
    been widely debated.  For example, Section 1 of "An Internet
    Attribute Certificate Profile for Authorization" [i3] 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
 
 
 
 Tuecke, et al.                                                       29 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       two reasons.  First, authorization information often does not
       have the same lifetime as the binding of the identity and the
       public key.  When authorization information is placed in a PKC
       extension, the general result is the shortening of the PKC
       useful lifetime.  Second, the PKC issuer is not usually
       authoritative for the authorization information.  This results
       in additional steps for the PKC issuer to obtain authorization
       information from the authoritative source.
 
       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."
 
    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.
 
    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.1.4 Proxy Certificate as Attribute Certificate Holder
 
    In a system that employs both PCs and ACs, one can imagine the
    utility of allowing a PC to be the holder of an AC.  This would
    allow for a particular delegated instance of an identity to be
    given an attribute, rather than all delegated instances of that
    identity being given the attribute.
 
 
 
 
 Tuecke, et al.                                                       30 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    However, the issue of how to specify a PC as the holder of an AC
    remains open.  An AC could be bound to a particular instance of a
    PC using the unique subject name of the PC, or it's issuer and
    serial number combination.
 
    Unrestricted PCs issued by that PC would then inherit those ACs and
    independent PCs would not.  PCs issued with a policy would depend
    on the policy as to whether or not they inherit the issuing PC's
    ACs (and potentially which ACs they inherit).
 
    While an AC can be bound to one PC by the AA, how can the AA
    restrict that PC from passing it on to a subsequently delegated PC?
    One possible solution would be to define an extension to attribute
    certificates that allows the attribute authority to state whether
    an issued AC is to apply only to the particular entity to which it
    is bound, or if it may apply to PCs issued by that entity.
 
    One issue that an AA in this circumstance would need to be aware of
    is that the PI of the PC that the AA bound the AC to, could issue
    another PC with the same name as the original PC to a different
    entity, effectively stealing the AC.  This implies that an AA
    issuing an AC to a PC need to not only trust the entity holding the
    PC, but the entity holding the PC's issuer as well.
 
 5.2 Kerberos 5 Tickets
 
    The Kerberos Network Authentication Protocol (RFC 1510 [i8]) is a
    widely used authentication system based on conventional (shared
    secret key) cryptography.  It provides support for single sign-on
    via creation of "Ticket Granting Tickets" or "TGT", and support for
    delegation of rights via "forwardable tickets".
 
    Kerberos 5 tickets have informed many of the ideas surrounding
    X.509 Proxy Certificates.  For example, the local creation of a
    short-lived PC can be used to provide single sign-on in an X.509
    PKI based system, just as creation of short-lived TGT allows for
    single sign-on in a Kerberos based system.  And just as a TGT can
    be forwarded (i.e. delegated) to another entity to allow for
    proxying in a Kerberos based system, so can a PC can be delegated
    to allow for proxying in an X.509 PKI based system.
 
    A major difference between a Kerberos TGT and an X.509 PC is that
    while creation and delegation of a TGT requires the involvement of
 
 
 
 Tuecke, et al.                                                       31 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    a third party (the Kerberos Domain Controller), a PC can be
    unilaterally created without the active involvement of a third
    party.  That is, a user can directly create a PC from an EEC for
    single sign-on capability, without requiring communication with a
    third party.  And an entity with a PC can delegate the PC to
    another entity (i.e. by creating a new PC, signed by the first)
    without requiring communication with a third party.
 
    The method used by Kerberos implementations to protect a TGT can
    also be used to protect the private key of a PC.  For example, some
    Unix implementations of Kerberos use standard Unix file system
    security to protect a user's TGT from compromise.  Similarly, the
    Globus Toolkit's Grid Security Infrastructure implementation of
    Proxy Certificates protects a user's PC private key using this same
    approach.
 
 5.3 Examples of usage of Proxy Restrictions
 
    This section gives some examples of Proxy Certificate usage and
    some examples of how the Proxy policy can be used to restrict Proxy
    Certificates.
 
 5.3.1  Example use of proxies without Restrictions
 
   Steve wishes to perform a third-party FTP transfer between two FTP
   servers.  Steve would use an existing PC to authenticate to both
   servers and delegate a PC to both hosts.  He would inform each host
   of the unique subject name of the PC given to the other host.  When
   the servers establish the data channel connection to each other,
   they use these delegated credentials to perform authentication and
   verify they are talking to the correct entity by checking the
   result of the authentication matches the name as provided by Steve.
 
 5.3.2  Example use of proxies with Restrictions
 
   Steve wishes to delegate to a process the right to perform a
   transfer of a file from host H1 to host H2 on his behalf.  Steve
   would delegate a PC to the process and he would use Proxy Policy to
   restrict the delegated PC to two rights - the right to read file F1
   on host H1 and the right to write file F2 on host H2.
 
   The process then uses this restricted PC to authenticate to servers
   H1 and H2.  The process would also delegate a PC to both servers.
 
 
 
 Tuecke, et al.                                                       32 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
   Note that these delegated PCs would inherit the restrictions of
   their parents, though this is not relevant to this example.  As in
   the example in the previous Section, each host would be provided
   with the unique name of the PC given to the other server.
 
   Now when the process issues the command to transfer the file F1 on
   H1 and to F2 on H2, these two servers perform an authorization
   check based on the restrictions in the PC that the process used to
   authenticate with them (in addition to any local policy they have).
   Namely H1 checks that the PC gives the user the right to read F1
   and H2 checks that the PC gives the user the right to write F2.
   When setting up the data channel the servers would again verify the
   names resulting from the authentication match the names provided by
   Steve as in the example in the previous Section.
 
   The extra security provided by these restrictions is that now if
   the PC delegated to the process by Steve is stolen, its use is
   greatly limited.
 
 5.4 Delegation Tracing
 
    A relying party accepting a Proxy Certificate may have an interest
    in knowing which parties issued earlier Proxy Certificates in the
    certificate chain and to whom they delegated them.  For example it
    may know that a particular service or resource is known to have
    been compromised and if any part of a Proxy Certificate's chain was
    issued to the compromised service a relying party may wish to
    disregard the chain.
 
    A delegation tracing mechanism was considered by the authors as
    additional information to be carried in the ProxyCertInfo
    extension.  However at this time agreement has not been reached as
    to what this information should include so it was left out of this
    document, and will instead be considered in future revisions.  The
    debate mainly centers on whether the tracing information should
    simply contain the identity of the issuer and receiver or it should
    also contain all the details of the delegated proxy and a signed
    statement from the receiver that the proxy was actually acceptable
    to it.
 
 
 
 
 
 
 
 Tuecke, et al.                                                       33 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 5.4.1 Site Information in Delegation Tracing
 
    In some cases, it may be desirable to know the hosts involved in a
    delegation transaction (for example, a relying party may wish to
    reject proxy certificates that were created on a specific host or
    domain).  An extension could be modified to include the PA's and
    Acceptor's IP addresses; however, IP addresses are typically easy
    to spoof, and in some cases the two parties to a transaction may
    not agree on the IP addresses being used (e.g., if the Acceptor is
    on a host that uses NAT, the Acceptor and the PA may disagree about
    the Acceptor's IP address).
 
    Another suggestion was, in those cases where domain information is
    needed, to require that the subject names of all End Entities
    involved (the Acceptor(s) and the End Entity that appears in a PC's
    certificate path) include domain information.
 
 6  Security Considerations
 
    In this Section we discuss security considerations related to the
    use of Proxy Certificates.
 
 6.1 Compromise of a Proxy Certificate
 
    A Proxy Certificate is generally less secure than the EEC that
    issued it.  This is due to the fact that the private key of a PC is
    generally not protected as rigorously as that of the EEC.  For
    example, the private key of a PC is often protected using only file
    system security, in order to allow that PC to be used for single
    sign-on purposes.  This makes the PC more susceptible to
    compromise.
 
    However, the risk of a compromised PC is only the misuse of a
    single user's privileges.  Due to the PC path validation checks, a
    PC cannot be used to sign an EEC or PC for another user.
 
    Further, a compromised PC can only be misused for the lifetime of
    the PC, and within the bound of the restriction policy carried by
    the PC.  Therefore, one common way to limit the misuse of a
    compromised PC is to limit its validity period to no longer than is
    needed, and/or to include a restriction policy in the PC that
    limits the use of the (compromised) PC.
 
 
 
 
 Tuecke, et al.                                                       34 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    In addition, if a PC is compromised, it does NOT compromise the EEC
    that created the PC.  This property is of great utility in
    protecting the highly valuable, and hard to replace, public key of
    the EEC.  In other words, the use of Proxy Certificates to provide
    single sign-on capabilities in an X.509 PKI environment can
    actually increase the security of the end entity certificates,
    because creation and use of the PCs for user authentication limits
    the exposure of the EEC private key to only the creation of the
    first level PC.
 
 6.2 Restricting Proxy Certificates
 
    The pCPathLenConstraint field of the proxyCertInfo extension can be
    used by an EEC to limit subsequent delegation of the PC.  A service
    may choose to only authorize a request if a valid PC can be
    delegated to it.  An example of such as service is a job starter,
    which may choose to reject a job start request if a valid PC cannot
    be delegated to it.  By limiting the pCPathLenConstraint, an EEC
    can ensure that a compromised PC of one job cannot be used to start
    additional jobs elsewhere.
 
    An EEC or PC can limit what a new PC can be used for by turning off
    bits in the Key Usage and Extended Key Usage extensions.  Once a
    key usage or extended key usage has been removed, the path
    validation algorithm ensures that it cannot be added back in a
    subsequent PC.  In other words, key usage can only be decreased in
    PC chains.
 
    The EEC could use the CRL Distribution Points extension and/or OCSP
    to take on the responsibility of revoking PCs that it had issued,
    if it felt that they were being misused.
 
 6.3 Relying Party Trust of Proxy Certificates
 
    The relying party that is going to authorize some actions on the
    basis of a PC will be aware that it has been presented with a PC,
    and can determine the depth of the delegation and the time that the
    delegation took place.  It may want to use this information in
    addition to the information from the signing EEC.  Thus a highly
    secure resource might refuse to accept a PC at all, or maybe only a
    single level of delegation, etc.
 
 
 
 
 
 Tuecke, et al.                                                       35 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    The relying party should also be aware that since the policy
    restricting the rights of a PC is the intersection of the policy of
    all the PCs in it's certificate chain, this means any change in the
    certificate chain can effect the policy of the PC. Since there is
    no mechanism in place to enforce unique subject names of PCs, if an
    issuer were two PCs with identical names and keys, but different
    rights this could allow the two PCs to be substituted for each
    other in path validation and effect the rights of a PC down the
    chain. Ultimately, this means the relying party places trust in the
    entities that are acting as Proxy Issuers in the chain to behave
    properly.
 
 6.4 Protecting Against Denial of Service with Key Generation
 
    As discussed in Section 2.3, one of the motivations for Proxy
    Certificates is to allow for dynamic delegation between parties.
    This delegation potentially requires, by the party receiving the
    delegation, the generation of a new key pair which is a potentially
    computationally expensive operation.  Care should be taken by such
    parties to prevent another entity from performing a denial of
    service attack by causing them to consume large amount of resource
    doing key generation.
 
    A general guideline would always to perform authentication of the
    delegating party to prevent such attacks from being performed
    anonymously.  Another guideline would be to maintain some state to
    detect and prevent such attacks.
 
 6.5 Use of Proxy Certificates with a Central Repository
 
    As discussed in Section 2.7, one potential use of Proxy
    Certificates is to ease certificate management for end users by
    storing the EEC private keys and certificates in a centrally
    managed repository.  When a user needs a PKI credential, the user
    can login to the repository using name/password, one time password,
    etc. and the repository would then delegate a PC to the user with
    proxy rights, but continue to protect the EEC private key in the
    repository.
 
    Care must be taken with this approach since compromise of the
    repository will potentially give the attacker access to the long-
    term private keys stored in the repository.  It is strongly
    suggested that some form of hardware module be used to store the
 
 
 
 Tuecke, et al.                                                       36 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    long-term private keys, which will serve to help prevent their
    direct threat though it may still allow a successful attacker to
    use the keys while the repository is compromised to sign arbitrary
    objects (including Proxy Certificates).
 
 7  IANA Considerations
 
    IANA should establish a registry for policy languages. Registration
    under IETF space is by IETF standards action as described in [i9].
    Private policy languages should be under organizational OIDs;
    policy language authors are encouraged to list such languages in
    the IANA registry, along with a pointer to a specification.
 
 8  Normative References
 
    [n1]    Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels," BCP 14, RFC 2119, March 1997.
    [n2]    Housley, R., W. Polk, W. Ford, and D. Solo, "Internet X.509
            Public Key Infrastructure Certificate and Certificate
            Revocation List (CRL) Profile," RFC 3280, April 2002.
 
 9  Informational References
 
    [i1]    Butler, R., D. Engert, I. Foster, C. Kesselman, and S.
            Tuecke, "A National-Scale Authentication Infrastructure,"
            IEEE Computer, vol. 33, pp. 60-66, 2000.
    [i2]    Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0,"
            RFC 2246, January 1999.
    [i3]    Farrell, S. and R. Housley, "An Internet Attribute
            Certificate Profile for Authorization," RFC 3281, April
            2002.
    [i4]    Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A
            Security Architecture for Computational Grids," presented
            at Proceedings of the 5th ACM Conference on Computer and
            Communications Security, 1998.
    [i5]    Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy of
            the Grid: Enabling Scalable Virtual Organizations,"
            International Journal of Supercomputer Applications, 2001.
 
 
 
 
 
 
 Tuecke, et al.                                                       37 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    [i6]    Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation
            Protocol," Internet Draft draft-ietf-tls-delegation-00.txt,
            2001
    [i7]    Kohl, J. and C. Neuman, "The Kerberos Network
            Authentication Service (V5)," RFC 1510, September 1993.
    [i8]    B. Clifford Neuman. "Proxy-Based Authorization and
            Accounting for Distributed Systems." In Proceedings of the
            13th International Conference on Distributed Computing
            Systems, pages 283-291, May 1993.
 
    [i9]    Narten, T. and and H. Alvestrand. "Guidelines for Writing
            an IANA Considerations Section in RFC," RFC 2434, October
            1998.
 
 10 Acknowledgments
 
    We are pleased to acknowledge significant contributions to this
    document by David Chadwick, Ian Foster, Jarek Gawor, Carl
    Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist.
 
    We are grateful to numerous colleagues for discussions on the
    topics covered in this paper, in particular (in alphabetical order,
    with apologies to anybody we've missed): Carlisle Adams, Joe
    Bester, Randy Butler, Doug Engert, Keith Jackson, Steve Hanna, Russ
    Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang,
    Ellen McDermott, Clifford Neuman, Gene Tsudik.
 
    We are also grateful to members of the Global Grid Forum (GGF) Grid
    Security Infrastructure working group (GSI-WG), and the Internet
    Engineering Task Force (IETF) Public-Key Infrastructure (X.509)
    working group (PKIX) for feedback on this document.
 
    This work was supported in part by the Mathematical, Information,
    and Computational Sciences Division subprogram of the Office of
    Advanced Scientific Computing Research, U.S. Department of Energy,
    under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense
    Advanced Research Projects Agency under contract N66001-96-C-8523;
    by the National Science Foundation; and by the NASA Information
    Power Grid project.
 
 
 
 
 
 
 Tuecke, et al.                                                       38 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 11 Contact Information
 
    Steven Tuecke
    Distributed Systems Laboratory
    Mathematics and Computer Science Division
    Argonne National Laboratory
    Argonne, IL 60439
    Phone: 630-252-8711
    Email: tuecke@mcs.anl.gov
 
    Von Welch
    National Center for Supercomputing Applications
    University of Illinois
    Email: vwelch@ncsa.uiuc.edu
 
    Doug Engert
    Argonne National Laboratory
    Email: deengert@anl.gov
 
    Laura Pearlman
    University of Southern California, Information Sciences Institute
    Email: laura@isi.edu
 
    Mary Thompson
    Lawrence Berkeley National Laboratory
    Email: mrthompson@lbl.gov
 
 12 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
 
 
 
 Tuecke, et al.                                                       39 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    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.
 
 13 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.
 
 
 
 
 
 
 
 
 
 
 
 
 Tuecke, et al.                                                       40 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 Appendix A. 1988 ASN.1 Module
 
 PKIXproxy88 {iso(1) identified-organization(3) dod(6)
     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     proxy-cert-extns(25) }
 
 DEFINITIONS EXPLICIT TAGS ::=
 
 BEGIN
 
 -- EXPORTS ALL --
 
 -- IMPORTS NONE --
 
 -- PKIX specific OIDs
 
 id-pkix OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3)
              dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
 
 -- private certificate extensions
 id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
 
 -- Locally defined OIDs
 
 -- The proxy certificate extension
 id-pe-proxyCertInfo    OBJECT IDENTIFIER ::= { id-pe 14 }
 
 -- Proxy certificate policy languages
 id-ppl  OBJECT IDENTIFIER ::= { id-pkix 21 }
 
 -- Proxy certificate policies languages defined in draft
 id-ppl-anyLanguage     OBJECT IDENTIFIER ::= { id-ppl 0 }
 id-ppl-inheritAll      OBJECT IDENTIFIER ::= { id-ppl 1 }
 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 }
 
 -- The ProxyCertInfo Extension
 ProxyCertInfoExtension  ::= SEQUENCE {
       pCPathLenConstraint     ProxyCertPathLengthConstraint
                                     OPTIONAL,
       proxyPolicy             ProxyPolicy }
 
 ProxyCertPathLengthConstraint  ::= INTEGER
 
 
 
 Tuecke, et al.                                                       41 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 
 ProxyPolicy  ::= SEQUENCE {
       policyLanguage          OBJECT IDENTIFIER,
       policy                  OCTET STRING OPTIONAL }
 
 END
 
 Appendix B. Change Log (To be removed prior to publication)
 
    draft-ietf-pkix-impersonation-00 (February 2001)
 
       Initial submission.
 
    draft-ietf-pkix-proxy-00 (July 2001)
 
       Renamed to "Proxy Certificate", from "Impersonation
       Certificate", due to overwhelming feedback from IETF and GGF.
 
       Added proxyRestriction field to ProxyCertInfo extension.
 
       Added delegationTrace field to ProxyCertInfo extension.
 
       Updated to agree with draft-ietf-pkix-part1-08.
 
    draft-ietf-pkix-proxy-01 (August 2001)
 
       Changes related to delegation tracing:  removed delegationTrace
       field from ProxyCertInfo extension, created DelegationTrace
       extension, added and modified commentary sections related to
       delegation tracing.
 
       Added issuerCertHash to proxyCertInfo extension and to the path
       validation section.
 
    draft-ietf-pkix-proxy-02 (February 2002)
 
       Draft for Global Grid Forum 4 (Toronto)
 
       Added concept of proxy group.
 
       Updated section on keyCertSign bit to reflect draft-pkix-new-
       part1-07.
 
 
 
 
 Tuecke, et al.                                                       42 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
    draft-ietf-pkix-proxy-02 (March 2002)
 
       Draft for IETF.
 
       Same version number (-02) as February 2002 for GGF4 but with
       changes.
 
       Globally changed "Proxy Authority" to "Proxy Issuer".
 
       Changed example in Motivations section to use a reliable file
       transfer service.
 
       An EEC issuing a PC must have a non-empty subject name.
 
       Proxy subject names are now non-empty and contain a sequence of
       proxy identifiers. Changes to path validation to reflect this.
 
       subjectAltNames and issuerAltNames are now not present PCs.
 
       Renamed issuerCertHash to issuerCertSignature and similarly with
       it's contents.
 
       Added consideration to path validation for PC's with an infinite
       path length (i.e. no pCPathLenConstraint).
 
    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.
 
       Removed Internet Draft language from status section and replaced
       with current text.
 
       Added Copyright and Intellectual Property sections (12 & 13)
 
       Removed Section 3.7.2: DelegationTrace Extension. Renumbered
       subsections 3.7.1.x to 3.7.x. Removed subsections in Section 6
 
 
 
 
 Tuecke, et al.                                                       43 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       related to this extension and replaced with one subsection
       discussing it.
 
       Proxy Certificate subject name is now issuer name concatenated
       with a single unique component. Functional changes to Sections 3
       and 4 to reflect this, numerous changes throughout the document
       including removal of section 6.3.
 
       Removed text stating the Proxy subject name should only be used
       for path validation to leave door open for use with attribute
       certificates.
 
       Rewrote 2.6 so reflect that PCs now have unique identities.
 
       Added new section 2.5 (Motivation for Unique Proxy Name)
 
       Removed sections 2.7 (Proxy Issuer, not Certificate Authority)
       and 2.8 (Names versus Subjects)
 
       Renamed proxyRestrictions to proxyPolicy and made it a required
       field. Numerous changes elsewhere to reflect this change.
 
       Removed issuerCertSignature since it is no longer needed since
       PCs now have unique names.
 
       Added previously deleted (accidentally?) text in 6.1
       (keyCertSign Bit commentary).
 
       Cleaned up pCPathLenConstraint checking in section 4 by adding
       the max_pc_path_length variable.
 
       Removed the proxyGroup field to make document restriction policy
       agnostic.
 
       Added structure to Section 7 (Security Considerations) and added
       some text about a relying party trusting all issuers in a PC
       chain.
 
       Removed sections 6.1 and 6.2 from commentary since the PKIX
       draft is now an RFC and won't be changed.
 
       Moved text from 6.3 to 3.9.4 and removed section 6.3.
 
 
 
 
 Tuecke, et al.                                                       44 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       Moved 6.4 to end of Commentary section.
 
       Moved section 5 (Relationship to attribute certificate to be
       first section of commentary).
       Changed intro to commentary and added text to beginning of
       section 2 to indicate that these two sections are non-normative.
 
       Changed text in 2.7 to indicate ease of integration with
       existing authorization systems is true only in the case of
       impersonation PCs.
 
       Added text to 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 attempted inclusion as a PKIX WG document. Based
       on draft-ggf-gsi-proxy-04 with changes listed below.
       Changed reference from "draft update to RFC 2459" to RFC 3280.
 
 
    draft-ietf-pkix-proxy-04 (February 2003)
 
       Rewrote section 4, Path Validation, to be additions to RFC 3280
       path validation instead 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.
 
    draft-ietf-pkix-proxy-05 (April 2003)
 
 
 
 Tuecke, et al.                                                       45 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
 
       Removed version field from ProxyCertInfo extension
 
       Restrictions on contents of key usage and extended key usage
       removed and placed as burden to relying party(4.2 and 3.6).
 
       Path validation (4.1.3) now outputs proxy_policy_list as a list
       of tuples containing subject name, policy oid, policy field, key
       usage extension and extended key usage extension
 
       Number of fixes to ASN module from Jim Schaad.
 
       Changes policy language OID name from "id-ppl-impersonation" to
       "id-ppl-inheritall".
 
       Fixed discrepancy between ASN.1 module and 3.9.2: id-ppl-
       independent and id-ppl-inheritall now refer to the whole OID.
 
       Clarified that a proxy issuer must have digitalSignature
       asserted if its certificate includes the keyUsage extension.
 
       Accepted text from David Chadwick globally getting rid of the
       term "impersonation" and replacing with "proxying".
 
       Reformatted document to be less indented and be more in line
       with other IDs.
 
       Numerous clarifications to draft based on Jim Schaad's comments.
       Effected sections: 3, 3.1, 3.4, 3.7, 3.9.3, 4, 5.4.1
 
       Expanded PKI acronym in abstract and section 2.
 
       Shorten title of section 4.2 to allow it to fit in table of
       contents.
 
    draft-ietf-pkix-proxy-06 (May 2003)
 
       Renamed "id-ppl-inheritall" to "id-ppl-inheritAll" (capitalizing
       the "a") for consistency.
 
       In section 4, renamed "acceptable-pc-policy-set" to "acceptable-
       pc-policy-language-set" for clarity.
 
 
 
 
 Tuecke, et al.                                                       46 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       In section 4, renamed "any-policy" to "id-ppl-anyLanguage" for
       clarity.
 
       Added an OID for id-ppl-anyLanguage to Appendix A.
 
       Clarified text in 4.1.3 (c).
 
       Clarified Proxy Issuer definition in 2.1.
 
       Changed "MUST not be present" to "MUST be absent" second to last
       paragraph of section 3.8.
 
       Removed OID definitions from 3.8.2 and added pointer to Appendix
       A.
 
    draft-ietf-pkix-proxy-07 (July 2003)
 
       Non-normative change: Split references into normative and
       informative.
 
       Non-normative change: Moved change log to appendix B.
 
       Non-normative change: Reduced author count to 5. Added
       significant contributors list to acknowledgments.
 
    draft-ietf-pkix-proxy-08 (August 2003)
 
       Correction to 4.1.3: Failure of step(d) also causes process
       termination.
 
       Deleted following sentence from 3.8.2 since it no longer
       pertains: "Note that this verification MUST take place
       regardless of whether or not the PC itself contains a policy, as
       other PCs in the signing chain MAY contain conditions that MUST
       be verified."
 
       Clarification in 3.8.2: "interpret the policy" to "interpret the
       proxy policy"
 
       Clarified text in 3.8.1 regarding EECs.
 
    draft-ietf-pkix-proxy-09 (November 2003)
 
 
 
 
 Tuecke, et al.                                                       47 
 
 
 Internet Draft     X.509 Proxy Certificate Profile      December 2003
 
 
 
 
       Corrected object identifier for proxy cert extension in 3.8
 
       Improved phrasing of conditions 2 and 3 in 3.8.2
 
       Improved phrasing of (e) in 4 to make clear that any proxy
       certificate can limit length of path.
 
       Minor editorial changes in 4.1.1, 4.2, 5.1.3, 6.1
 
       Added reference to RFC 3280 in 4.1.3 step (d).
 
    draft-ietf-pkix-proxy-10 (December 2003)
 
       Minor corrections in 3.8.2, 4.1.5, and non-normative references.
 
       Marked Appendix B as "To be removed before publication"
 
       Updated contact information and institution for Von Welch.
 
       Added Section 7, IANA Considerations, and non-normative
       reference to RFC 2434.
 
       Section 3.8.1: Correction "If the proxyCertInfo extension is not
       present..." changed to "If the pCPathLenConstraint field is not
       present..."
 
       Section 3.8.2: Added encouragement for authors to publicly
       specific and list their policy languages with IANA.
 
       Added sections 6.4 and 6.5 to Security Considerations.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Tuecke, et al.                                                       48
 

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/