RFC 3820

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

📅 published June 2004, from ietf

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

okay bestie, this is RFC 3820 💖 It came out in June 2004 as a Standards Track doc in the Network Working Group, written by S. Tuecke (ANL), V. Welch (NCSA), D. Engert (ANL), L. Pearlman (USC/ISI), and M. Thompson (LBNL). The title block doesn't list anything it obsoletes or updates, so this one is doing its own thing 💅

Status of this Memo 📋

so this doc is an Internet standards track protocol spec for the Internet community, and it's basically asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol sits in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share the love 🌸

Copyright (C) The Internet Society (2004).

Abstract ✨

this doc is a certificate profile for Proxy Certificates 🦋 It's built on top of X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, and it's meant for use on the Internet. A Proxy Certificate is a certificate that's derived from, and signed by, either a normal X.509 Public Key End Entity Certificate or another Proxy Certificate. The whole point is to give you restricted proxying and delegation inside a PKI-based authentication system, and yes, that's iconic 👑

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of Approach . . . . . . . . . . . . . . . . . . . . .  4
       2.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  4
       2.2.  Background . . . . . . . . . . . . . . . . . . . . . . .  5
       2.3.  Motivation for Proxying. . . . . . . . . . . . . . . . .  5
       2.4.  Motivation for Restricted Proxies. . . . . . . . . . . .  7
       2.5.  Motivation for Unique Proxy Name . . . . . . . . . . . .  8
       2.6.  Description Of Approach. . . . . . . . . . . . . . . . .  9
       2.7.  Features Of This Approach. . . . . . . . . . . . . . . . 10
   3.  Certificate and Certificate Extensions Profile . . . . . . . . 12
       3.1.  Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.  Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
       3.3.  Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
       3.4.  Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.5.  Subject Alternative Name . . . . . . . . . . . . . . . . 13
       3.6.  Key Usage and Extended Key Usage . . . . . . . . . . . . 13
       3.7.  Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
       3.8.  The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
   4.  Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
       4.1.  Basic Proxy Certificate Path Validation. . . . . . . . . 19
       4.2.  Using the Path Validation Algorithm. . . . . . . . . . . 23
   5.  Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
       5.1.  Relationship to Attribute Certificates . . . . . . . . . 24
       5.2.  Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
       5.3.  Examples of usage of Proxy Restrictions. . . . . . . . . 28
       5.4.  Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 30
       6.1.  Compromise of a Proxy Certificate. . . . . . . . . . . . 30
       6.2.  Restricting Proxy Certificates . . . . . . . . . . . . . 31
       6.3.  Relying Party Trust of Proxy Certificates. . . . . . . . 31
       6.4.  Protecting Against Denial of Service with Key Generation 32
       6.5.  Use of Proxy Certificates in a Central Repository. . . . 32
   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 33
       8.2.  Informative References . . . . . . . . . . . . . . . . . 33
   9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
   Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37

1. Introduction 🧚

okay so a proxy credential [i7] is a super common trick in security systems 💅 It lets entity A give entity B the right to be authorized along with others as if B were A. Basically, B is acting as a proxy on behalf of A, and it's giving main character energy 👑

This document is a certificate profile for Proxy Certificates, based on the RFC 3280 "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" [n2].

Besides simple, unrestricted proxying, this profile also defines:

  • A framework for carrying policies in Proxy Certificates. This lets you limit proxying (or even completely disallow it) through restrictions or by listing out rights. 🔒
  • Proxy Certificates with unique names, derived from the name of the end entity certificate. This means they can work with attribute assertion approaches like Attribute Certificates [i3], and they can have their own rights, independent of their issuer. 🦋

Section 2 is a non-normative overview 🌸 It defines terminology, explains why Proxy Certificates are a thing, and gives a quick tour of the approach. It also introduces the Proxy Issuer, which is different from a Certificate Authority. This is how end entity signing of a Proxy Certificate is different from end entity signing of another end entity certificate, and it's the reason this approach doesn't break the end entity signing restrictions in the X.509 keyCertSign field of the keyUsage extension. Then it talks about how subject names get used by this approach, plus the features of the approach. Ngl, the Proxy Issuer distinction is the lore 🙈

Section 3 defines the requirements for the information in Proxy Certificates 💖 The profile covers two fields in the basic certificate and five certificate extensions. The fields are the subject and the issuer. The extensions are subject alternative name, issuer alternative name, key usage, basic constraints, and extended key usage. There's also a brand new certificate extension called Proxy Certificate Information 🎀

Section 4 sets out the path validation rules for Proxy Certificates ✨

Section 5 is non-normative commentary on Proxy Certificates 💜

Section 6 covers the security considerations for Proxy Certificates, and it's serious business 😭🔥

The References in Section 8 are sorted into normative and informative. Normative references are in Section 8.1 and look like [nXX]. Informative references are in Section 8.2 and look like [iXX] 📚

Section 9 has the acknowledgements 🫶

After Section 9 comes the Appendix, the authors' contact info, the intellectual property information, and the copyright info 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 BCP 14, RFC 2119 [n1]. 🍓

2. Overview of Approach 🌈

this section is non-normative commentary on Proxy Certificates 🦋

The goal here is to develop an X.509 Proxy Certificate profile and make it easy to use within Internet applications. It's for communities that want restricted proxying and delegation inside an X.509 Public Key Infrastructure (PKI) authentication based system. Slay 💅

This section gives you the relevant background, the motivation, an overview of the approach, and related work ✨

2.1. Terminology 📖

this doc uses these terms, bestie:

  • CA: A "Certification Authority", as defined by X.509 [n2].
  • EEC: An "End Entity Certificate", as defined by X.509. It's an X.509 Public Key Certificate issued to an end entity, like 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", whose profile 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 🌍

okay so Computational and Data "Grids" have become a go-to approach for building dynamic, inter-domain, distributed computing environments 🌐 As explained in [i5], big research and development efforts starting around 1995 focused on which protocols, services, and APIs are needed for effective, coordinated use of resources in these Grid environments. It's giving real infrastructure energy 🔥

In 1997, the Globus Project (www.globus.org) introduced the Grid Security Infrastructure (GSI) [i4] 🔐 This library does public key based authentication and message protection. It's built on standard X.509 certificates and public key infrastructure, the SSL/TLS protocol [i2], and delegation using proxy certificates similar to the ones profiled in this document. GSI got used to build tons of middleware libraries and applications, which were deployed in large-scale production and experimental Grids [i1]. Honestly, GSI became the dominant security solution used by Grid efforts worldwide, and that's iconic 👑

This experience with GSI proved that restricted proxying works as a basis for authorization within Grids. It also proved that X.509 Proxy Certificates, as defined in this document, work as the basis for that proxying 🦋 This document is one part of an effort to move this experience into standards, clean up the approach, and line it up better with existing and recent standards. Periodt 💖

2.3. Motivation for Proxying 🧚

okay so a motivating example is literally the best way to get why proxying matters 💅

Steve is an engineer (iconic, I know 🙈) who wants to use a reliable file transfer service to move a bunch of big files around between different hosts on his company's Intranet-based Grid. From his laptop he wants to submit a bunch of transfer requests and have the files move while he's doing other stuff, including being offline 😭. The transfer service might queue the requests for a while (like until after hours or when things are quiet) before it starts the transfers. Then, for each file, the service connects to the source and destination hosts and tells them to open a data connection straight from the source to the destination so the file can move 🦋. Steve leaves an agent running on his laptop that checks on progress by contacting the transfer service. And obviously he wants all of this to happen securely on his company's resources, which means he has to start it all with his PKI smartcard 🔐.

This scenario needs authentication and delegation in a bunch of places:

  • Steve needs to be able to mutually authenticate with the reliable 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 submits all the file transfer requests to the transfer service and then periodically checks on the status of the transfer. This program needs to be given the rights to do all of these operations securely, without needing 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, so they have to 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 it must in turn delegate rights to those hosts so they can authenticate with each other 👑.

Proxying can be used to secure all of these interactions:

  • Proxying lets the private key stored on the smartcard be accessed just once, in order to create the necessary proxy credential, which allows the client/agent program to be authorized as Steve when it submits the requests to the transfer service. Access to the smartcard and Steve's password isn't 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 lets the service 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 each pair of hosts involved in a file transfer can mutually authenticate to make sure the file is transferred securely.
  • 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 like 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 used to provide authentication services to these applications ✨.

2.4. Motivation for Restricted Proxies 🛡️

okay but this is the question that keeps me up at night 😭. What happens if a machine that's been delegated the right to inherit Steve's privileges gets compromised? Like, in the scenario above, what if the machine running the file transfer service gets hacked, so the attacker can grab the credential Steve delegated to that service? Can the attacker now do literally everything Steve is allowed to do? 💀

The fix is to let restrictions be placed on the proxy through policies on the proxy certificates 🌈. For example, the machine running the reliable file transfer service in the example above might only be given Steve's right to read the source files and write the destination files. So if that file transfer service gets compromised, the attacker can't modify source files, can't create or modify other files Steve has access to, can't start jobs on Steve's behalf, etc. All an attacker could do is read the specific files the service was delegated read access to, and write bogus files in place of the ones it was delegated write access to. And on top of that, limiting the lifetime of the credential delegated to the file transfer service can further reduce the damage from a compromise ⭐.

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

2.5. Motivation for Unique Proxy Name 🦋

Creating entities dynamically (like processes and services) is a huge part of Grid computing ✨. These entities need rights so they can securely do their job. Proxying as described in the previous sections can get them rights, but it has limits. For example, what if an entity should have rights granted not just by the proxy issuer but by a third party too? It's possible for the entity to get and hold two proxy certifications in that case, but honestly it's simpler for the later credentials to take the form of attribute certificates 🧁.

It's also helpful for these entities to have a unique identity, so they can be explicitly named in policy statements 🫶. For example, a user starting a third-party FTP transfer could give each FTP server a PC with a unique identity and tell each server the identity of the other. Then, when the two servers connected, they could authenticate themselves and know they're connected to the proper party.

A party needs a unique identity before it can have rights of its own. There are three possible ways to get a unique identity:

  1. Obtain an identity from a traditional Certification Authority (CA).
  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.

This document describes an approach to option #3, and the reasons are:

  • It's pretty light-weight, since it can be done without interacting with a third party. That matters a lot when identities are being created dynamically 🚀.
  • As described in the previous section, a common use for PCs is restricted proxying, so deriving their identity from the identity of the EEC makes that straightforward. That said, there are situations where the creator doesn't want to delegate all or any of its rights to a new entity. Since the name is unique, this is easily handled by #3 as well, by allowing a policy to be applied to limit proxying 💅.

2.6. Description Of Approach 💜

This document defines an X.509 "Proxy Certificate" or "PC" as a way to provide 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, it may inherit rights of the EEC that signed the PC, subject to the restrictions placed on that PC by the EEC.
  5. Although its identity is derived from the EEC's identity, it is also unique. This allows the 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, is used to enable proper path validation and use of the PC 🧚.

The process of creating a PC goes like this:

  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 make sure 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. Steps #1 and #2 are performed within entity B, then the PC request is passed from entity B to entity A over an authenticated, integrity checked channel. 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 ✨

okay so using Proxy Certificates for delegation has a bunch of features that make it SO attractive 💖

  • Ease of integration 🔌
    • bestie, a PC only needs a minimal change to path validation, so it's super easy to add PC support to existing X.509 based software 🙌 For example, SSL/TLS needs no protocol changes to do authentication with a PC. It only needs minor changes for PC path validation, and then it grabs the authenticated subject of the signing EEC instead of the PC's subject for authorization stuff 💅
    • a LOT of existing authorization systems use the X.509 subject name for access control 🎀 A PC can be used with those systems without any modification, since it inherits its name and rights from the EEC that signed it. The EEC name can be used in place of the PC name for authorization decisions. no cap, that's so clean 🫶
  • Ease of use 🧚
    • using a PC for single sign-on makes X.509 PKI authentication way easier to live with, because users can "login" once and then do all kinds of operations securely 🌸
    • ngl, managing your own EEC private key is a nuisance at best and a security risk at worst 💀 A PC makes it easy to keep the EEC private keys and certificates in a centrally managed repository. When a user needs a PKI credential, they can log in to the repository with a name/password, a one time password, etc. Then the repository can delegate a PC to the user with proxy rights, while still protecting the EEC private key inside the repository 🔐
  • Protection of private keys 🔑
    • with the remote delegation approach from earlier, entity A can delegate a PC to entity B without entity B ever seeing entity A's private key 😤 And entity A never sees the private key of the newly delegated PC that entity B holds. private keys never need to be shared or communicated by anyone taking part in a PC delegation. iconic behavior honestly ✨
    • when you're doing single sign-on, a PC helps protect the EEC private key because it minimizes how much that key gets exposed and used 🛡️ For example, if an EEC private key is password protected on disk, the password and unencrypted private key only need to be around while the PC is being created. That PC can then be used for the rest of its valid lifetime without needing the EEC password or private key again. Same vibe with a smartcard: it only needs to be in the machine during the creation of the PC 💜
  • Limiting consequences of a compromised key 🚨
    • when creating a PC, the PI can limit the PC's validity period, the depth of the PC path that can be created by that PC, and the key usage of the PC and its descendants 📏 Fine-grained policies can also be carried by a PC to restrict the operations it can perform even more 🍓 These restrictions let the PI limit the damage the bearer of the PC could do, whether that's by accident or on purpose. main character restraint 👑
    • a compromised PC private key does NOT compromise the EEC private key 🙈 This is why a short term, or otherwise restricted, PC is so attractive for day-to-day use. A compromised PC doesn't force the user through the usually cumbersome and time consuming process of getting the EEC reissued with a new private key from the CA 😭

See Section 5 below for more discussion on how Proxy Certificates relate to Attribute Certificates. go check that one, it's giving context 🦋

3. Certificate and Certificate Extensions Profile 🎀

this section defines how X.509 certificate fields and extensions get used in Proxy Certificates 💅 It also defines one brand new extension, the Proxy Certificate Information for PCs 🌈

All Proxy Certificates MUST include the Proxy Certificate Information (ProxyCertInfo) extension defined in this section, and the extension MUST be critical. non-negotiable, periodt 🔥

3.1. Issuer 👑

The Proxy Issuer of a Proxy Certificate MUST be either an End Entity Certificate or another Proxy Certificate. choose your parent wisely 🧚

The Proxy Issuer MUST NOT have an empty subject field. no empty subjects allowed, that's just rude 🙅

The issuer field of a Proxy Certificate MUST contain the subject field of its Proxy Issuer. it's basically a family tree situation 🌳

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. it's not invited to the party 🚫

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. so close enough is valid here 🤏

For example, a Proxy Issuer MAY use a sequentially assigned integer or a UUID to give a PC it issues a unique serial number 🍓 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. lots of options, bestie ✨

3.4. Subject 🫶

The subject field of a Proxy Certificate MUST be the issuer field (that is, the subject of the Proxy Issuer) with a single Common Name component appended to the end. it's the parent name plus one new bit 💖

The value of the Common Name SHOULD be unique to each Proxy Certificate bearer amongst all Proxy Certificates with the same issuer. 🪪

If a Proxy Issuer issues two proxy certificates to the same bearer, the Proxy Issuer MAY choose to use the same Common Name for both. Examples of this include Proxy Certificates for different uses (e.g., signing vs encryption) or the re-issuance of an expired Proxy Certificate. it's not a crime to reuse the name, lowkey 🙂

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 vibes are "close enough is fine" again 🌸

The result of this approach is that all subject names of Proxy Certificates are derived from the name of the issuing EEC. The first part of the subject name is the EEC's name, appended with one or more CN components, and each one is unique to each bearer. the naming is so organized it's giving librarian energy 📚✨

3.5. Subject Alternative Name 🌈

The subjectAltName extension MUST NOT be present in a Proxy Certificate. same energy as the issuerAltName, not invited 🙅‍♀️

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 document places no constraints on the presence or contents of the key usage and extended key usage extension. However, section 4.2 explains what functions should be allowed a proxy certificate by a relying party. so the rules for that live over in section 4.2 🧁

3.7. Basic Constraints 🧱

The cA field in the basic constraints extension MUST NOT be TRUE. a PC is not allowed to be a CA, bestie, it's not that deep 🙅‍♀️

3.8. The ProxyCertInfo Extension 🎁

A new extension, ProxyCertInfo, is defined in this subsection. If the ProxyCertInfo extension is present, that means the certificate is a Proxy Certificate, and it also shows whether the issuer has placed any restrictions on its use. it's the little label that tells everyone what this cert is about 🏷️

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

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

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

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


ProxyPolicy ::= SEQUENCE {
     policyLanguage        OBJECT IDENTIFIER,
     policy          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. no skipping this one 🫡

If a certificate is not a Proxy Certificate, then the proxyCertInfo extension MUST be absent. so only real PCs get to wear this extension 💅

The ProxyCertInfo extension consists of one required field and two optional fields, which get described in detail in the following subsections. it's a little package of three parts 🎀

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. so a 0 is basically "no kids allowed" 🙅 If the pCPathLenConstraint field is not present, then the maximum proxy path length is unlimited. End entity certificates have unlimited maximum proxy path lengths. the EECs get to go as deep as they want, lol 🌳✨

3.8.2. proxyPolicy ✨

okay so the proxyPolicy field is where the issuer spells out the rules for using a cert when it comes to authorization 💅. Inside it, the policy field is the actual rule, and policyLanguage tells you what language that rule is written in 🎀.

here's the tea: proxyPolicy doesn't come with its own policy language 🙅‍♀️. It's on whoever uses the extension to pick a language and get an OID for it (or grab one that already exists 🧚). And since the PI that issues the cert and the relying party reading it have to be on the same page, the policy language OID has to point to a whole language with its semantics, not just its grammar 🤓. iykyk, the meaning matters just as much as the syntax.

the policyLanguage field has two super important values, defined in Appendix A, that MUST be understood by all parties accepting Proxy Certificates 👑:

  • id-ppl-inheritAll means this is an unrestricted proxy that inherits all rights from the issuing PI 🦋. An unrestricted proxy is basically the Proxy Issuer saying, "I'm handing over all of my authority to the bearer" (aka anyone who has that proxy cert and can prove they hold the matching private key). For authorization purposes, an unrestricted proxy effectively impersonates the issuing PI. main character energy, but make it dangerous 😭.
  • id-ppl-independent means 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 it has are the ones granted to it explicitly.

for either of those two policyLanguage values, the policy field MUST NOT be present 🙅‍♀️.

other values for policyLanguage mean this is a restricted proxy certificate with some other policy limiting what it can do when it comes to proxying 🔒. In this case the policy field MAY be present, and if it is, it MUST contain information expressing the policy. If the policy field isn't there, the policy MUST be implicit in the value of the policyLanguage field itself. Authors of additional policy languages are encouraged to publicly document their language and list it in the IANA registry (see Section 7) 🍓.

proxy policies exist to limit how much authority gets delegated. For example, a policy could say the proxy cert can only make requests to one specific server, or only authorize certain operations on certain resources 🧚. This document doesn't care what goes in the policy field. That's totally up to you ✨.

proxy policies also add extra work for the relying party, because only the relying party is in a position to make sure those policies actually get enforced 🫶. When you're making an authorization decision based on a proxy cert, using rights it inherited from its issuer, it's on the relying party to check that the requested authority fits with every policy in the PC's certificate path. So the relying party MUST verify that all three of these conditions are 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 has to be verified by checking these three conditions on the Proxy Issuer, in a recursive way 🔁.

if any of these conditions aren't met, the relying party MUST either deny authorization, or ignore the PC and the whole certificate chain, including the EEC, completely when it makes its authorization decision. Basically it has to make the same call it would have made if the PC and its certificate chain had never been presented 🫠.

the relying party MAY impose extra restrictions on which proxy certs it accepts 🎀. For example, a relying party MAY choose to reject all proxy certificates, or MAY choose to accept them only for certain operations, and so on.

quick side note: since a proxy certificate has its own unique identity, it MAY also have rights granted to it by means other than inheritance from its issuer through the proxy policy 💜. The rights granted to the bearer of a PC are the union of the rights granted to the PC identity and the inherited rights. The inherited rights are the intersection of the rights granted to the PI identity with the proxy policy in the PC ✨.

let's do an example, because this part is so hard to picture without one 🙈. Imagine Steve is allowed to read and write files A and B on a file server. He uses his EEC to make a PC with a policy saying it can only be used to read or write files A and C. Then a trusted attribute authority hands the PC an Attribute Certificate giving it the right to read file D. That makes the PC's rights the union of two things: the rights granted to the PC identity (read file D), plus the intersection of Steve's rights as the PI (read files A and B) with the policy in the PC (only read files A and C) 🦋.

so the PC would have these rights:

  • Right to read file A: Steve has this right, 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.

and the PC would not have these rights:

  • Right to read file B: even though Steve has this right, his policy on the PC excludes it.
  • Right to read file C: even though Steve's policy grants this right, he doesn't have it himself 🙅‍♀️.

in a lot of cases, the relying party won't have enough info to check all of the above at the time the certificate path gets validated 😩. For example, if a cert is used to authenticate a connection to some server, it usually gets validated during that authentication step, before any requests have been made to 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 containing proxy policies) 🔥.

4. Proxy Certificate Path Validation ✨

Proxy certification path processing checks the binding between the proxy certificate distinguished name and the proxy certificate public key 🔍. That binding is limited by constraints specified in the certificates that make up the path, plus any inputs the relying party provides 🎀.

this section describes an algorithm for validating proxy certification paths. Conforming implementations of this specification aren't required to implement this algorithm, but they MUST provide functionality equivalent to the external behavior that comes out of this procedure 🫶. Any algorithm can be used by an implementation, as long as it derives the correct result 💅.

the algorithm in this section validates the proxy certificate against the current date and time. A conformant implementation MAY also support validation with respect to some point in the past 🕰️. Just note that there aren't any mechanisms for validating a proxy certificate at a time outside its certificate validity period 🙅‍♀️.

valid paths start with the end entity certificate (EEC), which has already been validated by public key certificate validation procedures in RFC 3280 [n2] 💖. The algorithm needs the public key of the EEC and the EEC's subject distinguished name.

to verify the proxy certificate, the proxy certificate path validation process checks, among other things, that a prospective certification path (a sequence of n certificates) satisfies these 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 a 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;
  • (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's 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 how public key certificate path validation is described 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 before you use this algorithm to validate the end entity certificate 🙌. Then this algorithm processes the proxy certificate chain using the end entity certificate information that RFC 3280 path validation produced.

4.1.1. Inputs 🎀

this algorithm assumes the following inputs are provided to the path processing logic:

  • (a) information about the entity certificate that was 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,
    • (4) and the working_public_key_parameters output from RFC 3280 path validation.
  • (b) a 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 shouldn't check the proxy certificate policy languages. That's typically because the set of known policy languages isn't known yet and will be checked later in the authorization process 🧐.
  • (d) the current date and time. ⏰

4.1.2. Initialization ✨

okay so this is the setup phase 🎀 before any checking happens, we fill in some state variables from the inputs. ngl it's giving "get your ducks in a row" energy 🦆

  • (a) working_public_key_algorithm: the digital signature algorithm used to verify the signature of a proxy certificate. It 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. It is initialized from the input information provided from RFC 3280 path validation.
  • (c) working_public_key_parameters: parameters associated with the current public key, which may be required to verify a signature (depending on 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.
  • (e) max_path_length: this integer is initialized to n and 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 it gets filled in with the key usage extensions, extended key usage extensions and proxy policies in the chain. 🍓

Once the initialization steps are done, perform the basic certificate processing steps specified in 4.1.3. 💜

4.1.3. Basic Proxy Certificate Processing

okay bestie, these are the basic path processing actions for proxy certificate i (for all i in [1..n]). 🧚

  • (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. 🙈
  • (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

okay so this is the prep work for the next cert in line 🎀

  • (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.
  • (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

it's the final cleanup for the last cert in the chain, periodt 👑

  • (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 and returns a success indication, together with the 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

okay so every Proxy Certificate has a ProxyCertInfo extension 🦋 it always includes a policy language OID and might also include a policy OCTET STRING. These policies show what each issuer in the chain, starting with the EEC, is willing to hand down to the proxy certificate they issue. The algorithm passes this chain of policies back to the application. ✨

The application MAY make authorization decisions based on the subject distinguished name of the proxy certificate, on one of the proxy certificates in its 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. 🙈

Applications 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 are 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. 🍓

5. Commentary 💬

this section is non-normative commentary on Proxy Certificates, so it's just vibes and context 🧚

5.1. Relationship to Attribute Certificates

okay so an Attribute Certificate [i3] can be used to give one identity, the holder, some attribute like a role, a clearance level, or an alternative identity such as "charging identity" or "audit identity". 🎀 A trusted Attribute Authority (AA) does this by issuing signed Attribute Certificates (AC), and each AC binds an identity to a particular set of attributes. Authorization decisions can then combine info from the authenticated End Entity Certificate that provides the identity with the signed Attribute Certificates that bind that identity to attributes. 🔥

ngl there's clearly some overlap between Proxy Certificates and Attribute Certificates 👀 but using both together gives a broader spectrum of authorization solutions in X.509 based systems than either one alone. This section is here to clarify the overlaps, differences, and synergies between the two. 💜

5.1.1. Types of Attribute Authorities

for this discussion, Attribute Authorities, and the Attribute Certificates they produce, can be sorted 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. 🦋

This second type, the third party AA, works just as 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 parties uses the PC to authenticate with a service, that service receives the EEC's identity via the PC and can apply any ACs that bind that identity to attributes to work out authorization rights. 🌈 Additionally, a 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 Proxy Certificates and Attribute Certificates produced by third party Attribute Authorities. 🫶

However, the uses of Attribute Certificates granted by the first type, the end entity AA, overlap considerably with the uses of Proxy Certificates described in the previous sections. These Attribute Certificates are generally used to delegate 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 ✨

okay so remember Steve from Section 2? 🎀 PCs are how Steve delegates his identity to all the other jobs and entities that need to act on his behalf, so they can authenticate as if they were him 💅, like when they hit the mass storage system.

ngl there's a whole other way to do this, and it's using Attribute Certificates signed by Steve's EEC. Each of those other entities gets an AC that grants it the rights to do stuff for Steve. In this example, the reliable file transfer service, every host doing 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 issue ACs to bind each of those other EEC identities to attributes that give them the privileges they need, like being able to access the mass storage system 🗄️✨

BUT (and it's a big but 😭) the AC approach has some downsides compared to the PC approach:

  • Every protocol, authentication code, and identity based authorization service has to 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). Main character energy for the PC route 👑
  • 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 means Steve has to know in advance which other identities might be involved in this distributed application, so he can generate the right ACs signed by Steve's ECC. On the other hand, the PC solution is way more flexible, since parties can further delegate a PC without the originating EEC knowing about it beforehand 🦋

there are so many unexplored tradeoffs in all this delegation talk 🫠 but honestly, reasonable arguments can be made for either the AC approach or the PC approach. Which one you pick might depend on the software it has to plug into, the type of delegation you need, and other stuff too 🌈

5.1.3. Propagation of Authorization Information 🌸

one possible use of Proxy Certificates is carrying authorization information tied to a particular identity 🧚

people have been debating whether authorization info should go in End Entity Certificates (also called a Public Key Certificate or PKC) for ages 🙈 like Section 1 of "An Internet Attribute Certificate Profile for Authorization" [i3] says:

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

so PCs fix the first problem. A PC has a lifetime that's mostly independent of its signing EEC (and it's always shorter than that EEC's), which makes it a solid way to carry authorization info for delegation. slay 💅

the second problem is still a real problem 😤 If a third party AA is the authoritative one, then ACs issued by that AA are the natural way to spread authorization info around. But that's true whether the identity being bound comes from an EEC (PKC) or from a PC.

and here's the plot twist the quote doesn't cover 👀 When you're doing delegation, the EEC itself is usually the authoritative one (not the EEC issuer, and not some third party AA). It's up to the EEC to decide what rights it's willing to hand to someone else. So putting that authorization info into the PCs the EEC generates makes total sense for spreading it around ✨

5.1.4. Proxy Certificate as Attribute Certificate Holder 🦋

in a system that uses both PCs and ACs, it'd be so useful to let a PC be the holder of an AC 🤩 That way one specific delegated instance of an identity could get an attribute, instead of every delegated instance of that identity getting it.

the catch is that how to specify a PC as the holder of an AC is still an open question 🫣 An AC could be bound to a particular PC instance using the PC's unique subject name, or its issuer and serial number combo.

unrestricted PCs issued by that PC would then inherit those ACs, and independent PCs wouldn't. PCs issued with a policy would depend on the policy to decide whether they inherit the issuing PC's ACs (and possibly which ACs they get) 📜

now, while an AA can bind an AC to one PC, how does it stop that PC from passing the AC along to a PC it delegates later? 🤔 One possible fix would be an extension to attribute certificates that lets the attribute authority say whether an issued AC should apply only to the entity it's bound to, or whether it can also apply to PCs that entity issues.

one thing an AA in this situation has to watch out for: the PI of the PC the AC got bound to could issue another PC with the same name as the original PC to a different entity 😱 That'd effectively steal the AC. So an AA issuing an AC to a PC needs to trust not just the entity holding that PC, but the entity holding the PC's issuer too 🔐

5.2. Kerberos 5 Tickets 🎫

the Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a super widely used authentication system based on conventional (shared secret key) cryptography 🔑 It supports single sign-on through "Ticket Granting Tickets" or "TGT", and delegation of rights through "forwardable tickets".

Kerberos 5 tickets basically inspired a lot of the ideas behind X.509 Proxy Certificates 🥹 For example, you can locally create a short-lived PC to get single sign-on in an X.509 PKI based system, just like creating a short-lived TGT gives you single sign-on in a Kerberos based system. And just like a TGT can be forwarded (i.e., delegated) to another entity for proxying in Kerberos, a PC can be delegated for proxying in an X.509 PKI based system too 💖

the big difference between a Kerberos TGT and an X.509 PC is that making and delegating a TGT needs a third party (the Key Distribution Center), but a PC can be made unilaterally without any third party getting involved 🙌 So a user can create a PC straight from an EEC for single sign-on, no third party chat needed. And an entity holding a PC can delegate it to another entity (by creating a new PC, signed by the first one) without talking to a third party either.

the way Kerberos implementations protect a TGT can also protect a PC's private key 🔒 For example, some Unix Kerberos implementations use standard Unix file system security to keep a user's TGT from getting compromised. The Globus Toolkit's Grid Security Infrastructure implementation of Proxy Certificates protects a user's PC private key the same way ✨

5.3. Examples of usage of Proxy Restrictions 📝

this section has some examples of Proxy Certificate usage, plus some examples of how the Proxy policy can restrict Proxy Certificates 🧁

5.3.1. Example use of proxies without Restrictions 🚚

Steve wants to do a third-party FTP transfer between two FTP servers 📂 He uses an existing PC to authenticate to both servers and delegates a PC to both hosts. He tells each host the unique subject name of the PC given to the other host. When the servers set up the data channel connection to each other, they use those delegated credentials to authenticate and make sure they're talking to the right entity, by checking that the authentication result matches the name Steve gave them 🫶

5.3.2. Example use of proxies with Restrictions 🔐

Steve wants to let a process do a file transfer from host H1 to host H2 on his behalf 🌈 He delegates a PC to the process and uses Proxy Policy to limit that 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. It also delegates a PC to both servers. These delegated PCs would inherit the restrictions of their parent, though that doesn't matter for this example. Just like in the last example, each host gets the unique name of the PC given to the other server 💜

now when the process asks for the transfer of F1 on H1 and F2 on H2, both servers do an authorization check based on the restrictions in the PC the process used to authenticate with them (on top of any local policy they have). 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 the data channel is set up, the servers again verify that the names from authentication match the names Steve provided, same as in the previous example 🦋

the extra security these restrictions give you is that if the PC Steve delegated to the process gets stolen, its use is greatly limited 😭🔥

5.4. Delegation Tracing 🔍

Okay so a relying party accepting a Proxy Certificate might be lowkey curious about which parties issued the earlier Proxy Certificates in the certificate chain, and who they handed them off to 👀. Say a particular service or resource is known to have been compromised. If any part of a Proxy Certificate's chain was issued to that compromised service, the relying party may wish to disregard the chain 💀.

The authors considered a delegation tracing mechanism as extra information to be carried in the ProxyCertInfo extension 🧚. But agreement hasn't been reached on what that information should include, so it was left out of this document and will be looked at again in future revisions. The debate mainly centers on whether the tracing information should just contain the identity of the issuer and receiver, or whether 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 🤔✨.

5.4.1. Site Information in Delegation Tracing

Sometimes it's useful to know which hosts were involved in a delegation transaction. For example, a relying party might want to reject Proxy Certificates that were created on a specific host or domain 🏠. An extension could be changed to include the PA's and Acceptor's IP addresses. But IP addresses are typically easy to spoof 🙈, and the two parties to a transaction may not even agree on which IP addresses are being used. For instance, 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 that, in cases where domain information is needed, the subject names of all End Entities involved (the Acceptor(s) and the End Entity that appears in a PC's certificate path) should include domain information 🌐💅.

6. Security Considerations 🔐

Okay, this section is serious business, so let's get into the security considerations for using Proxy Certificates 🫶.

6.1. Compromise of a Proxy Certificate

A Proxy Certificate is generally less secure than the EEC that issued it 😬. That's because the private key of a PC is generally not protected as rigorously as the EEC's key. For example, the private key of a PC is often protected using only file system security, so that the PC can be used for single sign-on purposes. This makes the PC more susceptible to compromise 🔓.

The good news is that the risk of a compromised PC is only the misuse of a single user's privileges. Thanks to the PC path validation checks, a PC cannot be used to sign an EEC or PC for another user 🙌.

A compromised PC can also only be misused for the lifetime of the PC, and within the bounds of the restriction policy carried by the PC ⏳. So 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 🧯.

Here's the iconic part: if a PC is compromised, it does NOT compromise the EEC that created the PC 👑. This is hugely useful for protecting the highly valuable, and hard to replace, public key of the EEC. In other words, using 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 creating and using PCs for user authentication limits the exposure of the EEC private key to just 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. A job starter is an example of this kind of service. It may choose to reject a job start request if a valid PC cannot be delegated to it 🧑‍💻. By limiting the pCPathLenConstraint, an EEC can make sure that a compromised PC of one job cannot be used to start additional jobs elsewhere 🛑.

An EEC or PC can also 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 makes sure 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 know that it has been presented with a PC. It can determine the depth of the delegation and the time the delegation took place 🕰️. It may want to use this information in addition to the information from the signing EEC. So a highly secure resource might refuse to accept a PC at all, or maybe accept only a single level of delegation, and so on 🔒.

The relying party should also be aware that the policy restricting the rights of a PC is the intersection of the policy of all the PCs in its certificate chain. That means any change in the certificate chain can affect the policy of the PC 🔄. There's no mechanism in place to enforce unique subject names of PCs. So if an issuer were to issue two PCs with identical names and keys but different rights, this could allow the two PCs to be substituted for each other in path validation and affect the rights of a PC down the chain 😵. Ultimately, this means the relying party places trust in the entities 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 dynamic delegation between parties 🔑. This delegation potentially requires the party receiving the delegation to generate a new key pair, which can be a computationally expensive operation 🥵. Parties in this position should take care to prevent another entity from performing a denial of service attack by causing them to consume large amounts of resources doing key generation 🚨.

A general guideline would always to perform authentication of the delegating party, so that such attacks can't be 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 log in to the repository using a name/password, a one time password, etc. The repository would then delegate a PC to the user with proxy rights, but continue to protect the EEC private key in the repository 🎀.

Be careful with this approach, because compromise of the repository could potentially give the attacker access to the long-term private keys stored in it 😱. It is strongly suggested that some form of hardware module be used to store the long-term private keys. This helps 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 has established a registry for policy languages 🗂️. Registration under IETF space is by IETF standards action, as described in [i8]. Private policy languages should be under organizational OIDs. Policy language authors are encouraged to list such languages in the IANA registry, along with a pointer to a specification 🦋.

OID                      Description
---                      -----------
1.3.6.1.5.5.7.21.1       id-ppl-inheritALL
1.3.6.1.5.5.7.21.2       id-ppl-independent

8. References 📚

8.1. Normative References

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

8.2. Informative References

  • [i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S. Tuecke, "A National-Scale Authentication Infrastructure", IEEE Computer, vol. 33, pp. 60-66, 2000.
  • [i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [i3] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
  • [i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A Security Architecture for Computational Grids", presented at Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998.
  • [i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the Grid: Enabling Scalable Virtual Organizations", International Journal of Supercomputer Applications, 2001.
  • [i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
  • [i7] Neuman, B. Clifford, "Proxy-Based Authorization and Accounting for Distributed Systems", In Proceedings of the 13th International Conference on Distributed Computing Systems, pages 283-291, May 1993.
  • [i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA Considerations Section in RFC", RFC 2434, October 1998.

9. 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, 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 🚀.

Appendix A. 1988 ASN.1 Module 📜✨

okay so this is the grammar bit, and it's giving pure structure 💅 the whole module is wrapped up in one little package with an OID address that tells you exactly where it lives in the big global tree of object identifiers 🌸

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
id-ppl-anyLanguage     OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll      OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 }

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

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

END

Authors' Addresses 💌

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

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.

Acknowledgement 🙏

Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from