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.
o 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
o 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.
o 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
o 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.
o When implementing single sign-on, using a PC helps protect the
private key of the EEC, because it minimizes the exposure 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
o 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.
o 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.
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 (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 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.
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 }
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 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 7).
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.
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 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).
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;
(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,
(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.
(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.
(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