Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile
Extracted elements (29)
Delegation tracing information (identity of issuer and receiver at each delegation step) was considered for inclusion in ProxyCertInfo but was omitted because consensus was not reached on what information to include — specifically whether to record only issuer/receiver identities or also include the full delegated proxy details and a signed acceptance statement from the receiver.
PC subject names are derived from the issuing EEC's name by appending a single CN component (option 3 of three alternatives) rather than obtaining a name from a CA or using a self-signed certificate. This is lightweight (no third-party interaction required), enables dynamic identity creation, and makes the PC's relationship to its issuing EEC explicit while maintaining a unique identity for independent rights assignment.
Placing authorization information in Proxy Certificates (rather than purely in Attribute Certificates) is justified because PCs have a lifetime independent of and shorter than the signing EEC, mitigating the 'shortening of PKC useful lifetime' objection raised in RFC 3281 Section 1 against embedding authorization in public key certificates.
Proxy Certificates and Attribute Certificates (RFC 3281) are complementary. Third-party Attribute Authorities work equally well with EECs or PCs as the holder identity; however, an AA issuing an AC bound to a specific PC must also trust the PC's issuer, because the PI could re-issue a PC with the same name to a different entity, effectively stealing the AC.
Proxy Certificates require no protocol changes to SSL/TLS for authentication; only minor changes to path validation are needed (PC-aware validation and EEC subject name retrieval for authorization). Existing identity-based authorization systems that use X.509 subject names can use PCs without modification, since a PC inherits its name from the issuing EEC.
Unlike Kerberos 5 Ticket Granting Tickets, which require a third-party Key Distribution Center for both creation and delegation, Proxy Certificates can be created and delegated unilaterally without any third-party involvement. PC delegation is performed by creating a new PC signed by the delegating party's existing PC or EEC.
All Proxy Certificates MUST include the ProxyCertInfo extension, and that extension MUST be marked as critical. Conversely, if a certificate is not a Proxy Certificate, the proxyCertInfo extension MUST be absent.
If the application does not know how to parse any policy in the proxy policy chain, it MUST NOT use the subject distinguished name of any certificate in the chain prior to the certificate containing the unrecognized policy for authorization decisions.
If the Proxy Issuer certificate has a KeyUsage extension, the Digital Signature bit MUST be asserted. This applies both to the issuer's certificate (Section 3.1) and during path validation when processing intermediate proxy certificates (Section 4.1.4).
RFC 3280 certificate path validation MUST have been performed on the end entity certificate prior to executing the proxy certificate path validation algorithm. The proxy algorithm takes the EEC's working_public_key, working_public_key_algorithm, and subject name as inputs.
The cA field in the basicConstraints extension MUST NOT be TRUE in a Proxy Certificate, preventing proxy certificates from acting as certification authorities.
The issuerAltName extension MUST NOT be present in a Proxy Certificate, and the subjectAltName extension MUST NOT be present in a Proxy Certificate.
The policyLanguage values id-ppl-inheritAll and id-ppl-independent MUST be understood by all parties accepting Proxy Certificates. For either of these values, the optional policy OCTET STRING field MUST NOT be present.
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, and the issuer field of the Proxy Certificate MUST contain the subject field of its Proxy Issuer.
The subject field of a Proxy Certificate MUST be the issuer field (i.e., the subject of the Proxy Issuer) appended with a single Common Name component. The CN value SHOULD be unique to each Proxy Certificate bearer amongst all Proxy Certificates with the same issuer.
When making an authorization decision based on inherited rights, the relying party MUST verify: (1) it knows how to interpret the proxy policy and the request is allowed; (2) if the PI is an EEC, local policy authorizes the request for that EEC; (3) if the PI is a PC, either local policy authorizes the PI or the PI inherits the right recursively. If these conditions are not met, the relying party MUST deny authorization or ignore the PC chain entirely.
id-ppl-anyLanguage (OID 1.3.6.1.5.5.7.21.0) is a special value that may appear in the acceptable-pc-policy-language-set input to the path validation algorithm, indicating that policy language checking is deferred to the authorization layer rather than enforced during path validation.
id-ppl-inheritAll (OID 1.3.6.1.5.5.7.21.1) indicates an unrestricted proxy that inherits all rights from the issuing Proxy Issuer; for authorization purposes it effectively impersonates the PI. id-ppl-independent (OID 1.3.6.1.5.5.7.21.2) indicates a proxy that inherits no rights and must be treated as an independent identity.
The pCPathLenConstraint field, if present, specifies the maximum depth of the Proxy Certificate path that can be signed by this PC. A value of 0 means this certificate MUST NOT sign any further Proxy Certificate; absence means unlimited depth.
The ProxyCertInfo extension (OID id-pe-proxyCertInfo, { id-pe 14 }) is a SEQUENCE containing an optional pCPathLenConstraint INTEGER and a required proxyPolicy field. Presence of this extension identifies the certificate as a Proxy Certificate.
The ProxyPolicy structure is a SEQUENCE containing a required policyLanguage OBJECT IDENTIFIER and an optional policy OCTET STRING. The policyLanguage OID identifies the language semantics; the policy field carries the actual policy expression if needed.
IANA has established a registry for Proxy Certificate policy languages. Registration of policy languages in IETF OID space requires an IETF standards action; private policy languages should use organizational OIDs but authors are encouraged to list them in the IANA registry with a pointer to a specification. Pre-registered entries: id-ppl-inheritAll (1.3.6.1.5.5.7.21.1) and id-ppl-independent (1.3.6.1.5.5.7.21.2).
A Proxy Certificate private key is typically less rigorously protected than the EEC private key (often only file-system security). A compromised PC cannot sign EECs or PCs for other users, cannot be misused beyond its validity period, and does NOT compromise the issuing EEC private key. Limiting PC lifetime and including restriction policies mitigates the damage from a compromised PC.
Dynamic delegation requires the accepting party to generate a new key pair, which is computationally expensive. Implementors should authenticate the delegating party before generating keys and maintain state to detect and prevent denial-of-service attacks via repeated delegation requests.
Since no mechanism enforces unique PC subject names, a Proxy Issuer could issue two PCs with identical names and keys but different rights, allowing substitution attacks that affect the effective rights of downstream PCs. Relying parties ultimately must trust all Proxy Issuers in the chain to behave properly.
The pCPathLenConstraint field and Key Usage / Extended Key Usage extension bits in the ProxyCertInfo extension allow an EEC to limit subsequent delegation depth and permitted operations. Key usage bits can only be decreased along a PC chain; once removed by a PI they cannot be re-added by a subsequent PC.
When EEC private keys are stored in a central repository, compromise of the repository exposes all long-term private keys, potentially allowing an attacker to sign arbitrary Proxy Certificates. Use of hardware security modules is strongly recommended to store long-term private keys in such deployments.
Proxy certificate path validation proceeds in four phases: (1) initialization — load EEC public key and subject name from RFC 3280 output, set max_path_length = n; (2) basic processing for each certificate i — verify signature, validity period, issuer name, subject name structure, and ProxyCertInfo presence and policy language; (3) preparation for next certificate — verify max_path_length > 0, decrement it, update working keys; (4) wrap-up — finalize working keys. Failure at any step terminates with an error.
ProxyCertInfoExtension is encoded in DER as a SEQUENCE { pCPathLenConstraint INTEGER OPTIONAL, proxyPolicy SEQUENCE { policyLanguage OBJECT IDENTIFIER, policy OCTET STRING OPTIONAL } }, using EXPLICIT TAGS per the 1988 ASN.1 module PKIXproxy88.