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
(a) Assign the certificate subject name to working_issuer_name.
(b) Assign the certificate subjectPublicKey to working_public_key.
(c) If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with non-null parameters, assign the parameters
to the proxy_issuer_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the
proxy_issuer_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
proxy_issuer_public_key_algorithm are different, set the
proxy_issuer_public_key_parameters to null.
(d) Assign the certificate subjectPublicKey algorithm to the
proxy_issuer_public_key_algorithm variable.
4.1.6. Outputs
If path processing succeeds, the procedure terminates, returning a
success indication together with final value of the
working_public_key, the working_public_key_algorithm, the
working_public_key_parameters, and the proxy_policy_list.
4.2. Using the Path Validation Algorithm
Each Proxy Certificate contains a ProxyCertInfo extension, which
always contains a policy language OID, and may also contain a policy
OCTET STRING. These policies serve to indicate the desire of each
issuer in the proxy certificate chain, starting with the EEC, to
delegate some subset of their rights to the issued proxy certificate.
This chain of policies is returned by the algorithm to the
application.
The application MAY make authorization decisions based on the subject
distinguished name of the proxy certificate or on one of the proxy
certificates in it’s issuing chain or on the EEC that serves as the
root of the chain. If an application chooses to use the subject
distinguished name of a proxy certificate in the issuing chain or the
EEC it MUST use the returned policies to restrict the rights it
grants to the proxy certificate. If the application does not know
how to parse any policy in the policy chain it MUST not use, for the
purposes of making authorization decisions, the subject distinguished
name of any certificate in the chain prior to the certificate in
which the unrecognized policy appears.
Application making authorization decisions based on the contents of
the proxy certificate key usage or extended key usage extensions MUST
examine the list of key usage, extended key usage and proxy policies
resulting from proxy certificate path validation and determine the
effective key usage functions of the proxy certificate as follows:
* If a certificate is a proxy certificate with a proxy policy of
id-ppl-independent or an end entity certificate, the effective key
usage functions of that certificate is as defined by the key usage
and extended key usage extensions in that certificate. The key
usage functionality of the issuer has no bearing on the effective
key usage functionality.
* If a certificate is a proxy certificate with a policy other than
id-ppl-independent, the effective key usage and extended key usage
functionality of the proxy certificate is the intersection of the
functionality of those extensions in the proxy certificate and the
effective key usage functionality of the proxy issuer.
5. Commentary
This section provides non-normative commentary on Proxy Certificates.
5.1. Relationship to Attribute Certificates
An Attribute Certificate [i3] can be used to grant to one identity,
the holder, some attribute such as a role, clearance level, or
alternative identity such as "charging identity" or "audit identity".
This is accomplished by way of a trusted Attribute Authority (AA),
which issues signed Attribute Certificates (AC), each of which binds
an identity to a particular set of attributes. Authorization
decisions can then be made by combining information from the
authenticated End Entity Certificate providing the identity, with the
signed Attribute Certificates providing binding of that identity to
attributes.
There is clearly some overlap between the capabilities provided by
Proxy Certificates and Attribute Certificates. However, the
combination of the two approaches together provides a broader
spectrum of solutions to authorization in X.509 based systems, than
either solution alone. This section seeks to clarify some of the
overlaps, differences, and synergies between Proxy Certificate and
Attribute Certificates.
5.1.1. Types of Attribute Authorities
For the purposes of this discussion, Attribute Authorities, and the
uses of the Attribute Certificates that they produce, can be broken
down into two broad classes:
1) End entity AA: An End Entity Certificate may be used to sign an
AC. This can be used, for example, to allow an end entity to
delegate some of its privileges to another entity.
2) Third party AA: A separate entity, aside from the end entity
involved in an authenticated interaction, may sign ACs in order to
bind the authenticated identity with additional attributes, such
as role, group, etc. For example, when a client authenticates
with a server, the third party AA may provide an AC that binds the
client identity to a particular group, which the server then uses
for authorization purposes.
This second type of Attribute Authority, the third party AA, works
equally well with an EEC or a PC. For example, unrestricted Proxy
Certificates can be used to delegate the EEC’s identity to various
other parties. Then when one of those other parties uses the PC to
authenticate with a service, that service will receive the EEC’s
identity via the PC, and can apply any ACs that bind that identity to
attributes in order to determine authorization rights. Additionally
PC with policies could be used to selectively deny the binding of ACs
to a particular proxy. An AC could also be bound to a particular PC
using the subject or issuer and serial number of the proxy
certificate. There would appear to be great synergies between the
use of Proxy Certificates and Attribute Certificates produced by
third party Attribute Authorities.
However, the uses of Attribute Certificates that are granted by the
first type of Attribute Authority, the end entity AA, overlap
considerably with the uses of Proxy Certificates as described in the
previous sections. Such Attribute Certificates are generally used
for delegation of rights from one end entity to others, which clearly
overlaps with the stated purpose of Proxy Certificates, namely single
sign-on and delegation.
5.1.2. Delegation Using Attribute Certificates
In the motivating example in Section 2, PCs are used to delegate
Steve’s identity to the various other jobs and entities that need to
act on Steve’s behalf. This allows those other entities to
authenticate as if they were Steve, for example to the mass storage
system.
A solution to this example could also be cast using Attribute
Certificates that are signed by Steve’s EEC, which grant to the other
entities in this example the right to perform various operations on
Steve’s behalf. In this example, the reliable file transfer service
and all the hosts involved in file transfers, the starter program,
the agent, the simulation jobs, and the post-processing job would
each have their own EECs. Steve’s EEC would therefore issue ACs to
bind each of those other EEC identities to attributes that grant the
necessary privileges allow them to, for example, access the mass
storage system.
However, this AC based solution to delegation has some disadvantages
as compared to the PC based solution:
* All protocols, authentication code, and identity based
authorization services must be modified to understand ACs. With
the PC solution, protocols (e.g., TLS) likely need no
modification, authentication code needs minimal modification
(e.g., to perform PC aware path validation), and identity based
authorization services need minimal modification (e.g., possibly
to find the EEC name and to check for any proxy policies).
* ACs need to be created by Steve’s EEC, which bind attributes to
each of the other identities involved in the distributed
application (i.e., the agent, simulation jobs, and post-processing
job the file transfer service, the hosts transferring files).
This implies that Steve must know in advance which other
identities may be involved in this distributed application, in
order to generate the appropriate ACs which are signed by Steve’s
ECC. On the other hand, the PC solution allows for much more
flexibility, since parties can further delegate a PC without a
priori knowledge by the originating EEC.
There are many unexplored tradeoffs and implications in this
discussion of delegation. However, reasonable arguments can be made
in favor of either an AC based solution to delegation or a PC based
solution to delegation. The choice of which approach should be taken
in a given instance may depend on factors such as the software that
it needs to be integrated into, the type of delegation required, and
other factors.
5.1.3. Propagation of Authorization Information
One possible use of Proxy Certificates is to carry authorization
information associated with a particular identity.
The merits of placing authorization information into End Entity
Certificates (also called a Public Key Certificate or PKC) have been
widely debated. For example, Section 1 of "An Internet Attribute
Certificate Profile for Authorization" [i3] states:
"Authorization information may be placed in a PKC extension or
placed in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have the
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the
general result is the shortening of the PKC useful lifetime.
Second, the PKC issuer is not usually authoritative for the
authorization information. This results in additional steps for
the PKC issuer to obtain authorization information from the
authoritative source.
For these reasons, it is often better to separate authorization
information from the PKC. Yet, authorization information also
needs to be bound to an identity. An AC provides this binding; it
is simply a digitally signed (or certified) identity and set of
attributes."
Placing authorization information in a PC mitigates the first
undesirable property cited above. Since a PC has a lifetime that is
mostly independent of (always shorter than) its signing EEC, a PC
becomes a viable approach for carrying authorization information for
the purpose of delegation.
The second undesirable property cited above is true. If a third
party AA is authoritative, then using ACs issued by that third party
AA is a natural approach to disseminating authorization information.
However, this is true whether the identity being bound by these ACs
comes from an EEC (PKC), or from a PC.
There is one case, however, that the above text does not consider.
When performing delegation, it is usually the EEC itself that is
authoritative (not the EEC issuer, or any third party AA). That is,
it is up to the EEC to decide what authorization rights it is willing
to grant to another party. In this situation, including such
authorization information into PCs that are generated by the EEC
seems a reasonable approach to disseminating such information.
5.1.4. Proxy Certificate as Attribute Certificate Holder
In a system that employs both PCs and ACs, one can imagine the
utility of allowing a PC to be the holder of an AC. This would allow
for a particular delegated instance of an identity to be given an
attribute, rather than all delegated instances of that identity being
given the attribute.
However, the issue of how to specify a PC as the holder of an AC
remains open. An AC could be bound to a particular instance of a PC
using the unique subject name of the PC, or it’s issuer and serial
number combination.
Unrestricted PCs issued by that PC would then inherit those ACs and
independent PCs would not. PCs issued with a policy would depend on
the policy as to whether or not they inherit the issuing PC’s ACs
(and potentially which ACs they inherit).
While an AC can be bound to one PC by the AA, how can the AA restrict
that PC from passing it on to a subsequently delegated PC? One
possible solution would be to define an extension to attribute
certificates that allows the attribute authority to state whether an
issued AC is to apply only to the particular entity to which it is
bound, or if it may apply to PCs issued by that entity.
One issue that an AA in this circumstance would need to be aware of
is that the PI of the PC that the AA bound the AC to, could issue
another PC with the same name as the original PC to a different
entity, effectively stealing the AC. This implies that an AA issuing
an AC to a PC need to not only trust the entity holding the PC, but
the entity holding the PC’s issuer as well.
5.2. Kerberos 5 Tickets
The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a
widely used authentication system based on conventional (shared
secret key) cryptography. It provides support for single sign-on via
creation of "Ticket Granting Tickets" or "TGT", and support for
delegation of rights via "forwardable tickets".
Kerberos 5 tickets have informed many of the ideas surrounding X.509
Proxy Certificates. For example, the local creation of a short-lived
PC can be used to provide single sign-on in an X.509 PKI based
system, just as creation of short-lived TGT allows for single sign-on
in a Kerberos based system. And just as a TGT can be forwarded
(i.e., delegated) to another entity to allow for proxying in a
Kerberos based system, so can a PC can be delegated to allow for
proxying in an X.509 PKI based system.
A major difference between a Kerberos TGT and an X.509 PC is that
while creation and delegation of a TGT requires the involvement of a
third party (Key Distribution Center), a PC can be unilaterally
created without the active involvement of a third party. That is, a
user can directly create a PC from an EEC for single sign-on
capability, without requiring communication with a third party. And
an entity with a PC can delegate the PC to another entity (i.e., by
creating a new PC, signed by the first) without requiring
communication with a third party.
The method used by Kerberos implementations to protect a TGT can also
be used to protect the private key of a PC. For example, some Unix
implementations of Kerberos use standard Unix file system security to
protect a user’s TGT from compromise. Similarly, the Globus
Toolkit’s Grid Security Infrastructure implementation of Proxy
Certificates protects a user’s PC private key using this same
approach.
5.3. Examples of usage of Proxy Restrictions
This section gives some examples of Proxy Certificate usage and some
examples of how the Proxy policy can be used to restrict Proxy
Certificates.
5.3.1. Example use of proxies without Restrictions
Steve wishes to perform a third-party FTP transfer between two FTP
servers. Steve would use an existing PC to authenticate to both
servers and delegate a PC to both hosts. He would inform each host
of the unique subject name of the PC given to the other host. When
the servers establish the data channel connection to each other, they
use these delegated credentials to perform authentication and verify
they are talking to the correct entity by checking the result of the
authentication matches the name as provided by Steve.
5.3.2. Example use of proxies with Restrictions
Steve wishes to delegate to a process the right to perform a transfer
of a file from host H1 to host H2 on his behalf. Steve would
delegate a PC to the process and he would use Proxy Policy to
restrict the delegated PC to two rights - the right to read file F1
on host H1 and the right to write file F2 on host H2.
The process then uses this restricted PC to authenticate to servers
H1 and H2. The process would also delegate a PC to both servers.
Note that these delegated PCs would inherit the restrictions of their
parents, though this is not relevant to this example. As in the
example in the previous Section, each host would be provided with the
unique name of the PC given to the other server.
Now when the process issues the command to transfer the file F1 on H1
and to F2 on H2, these two servers perform an authorization check
based on the restrictions in the PC that the process used to
authenticate with them (in addition to any local policy they have).
Namely H1 checks that the PC gives the user the right to read F1 and
H2 checks that the PC gives the user the right to write F2. When
setting up the data channel the servers would again verify the names
resulting from the authentication match the names provided by Steve
as in the example in the previous Section.
The extra security provided by these restrictions is that now if the
PC delegated to the process by Steve is stolen, its use is greatly
limited.
5.4. Delegation Tracing
A relying party accepting a Proxy Certificate may have an interest in
knowing which parties issued earlier Proxy Certificates in the
certificate chain and to whom they delegated them. For example it
may know that a particular service or resource is known to have been
compromised and if any part of a Proxy Certificate’s chain was issued
to the compromised service a relying party may wish to disregard the
chain.
A delegation tracing mechanism was considered by the authors as
additional information to be carried in the ProxyCertInfo extension.
However at this time agreement has not been reached as to what this
information should include so it was left out of this document, and
will instead be considered in future revisions. The debate mainly
centers on whether the tracing information should simply contain the
identity of the issuer and receiver or it should also contain all the
details of the delegated proxy and a signed statement from the
receiver that the proxy was actually acceptable to it.
5.4.1. Site Information in Delegation Tracing
In some cases, it may be desirable to know the hosts involved in a
delegation transaction (for example, a relying party may wish to
reject proxy certificates that were created on a specific host or
domain). An extension could be modified to include the PA’s and
Acceptor’s IP addresses; however, IP addresses are typically easy to
spoof, and in some cases the two parties to a transaction may not
agree on the IP addresses being used (e.g., if the Acceptor is on a
host that uses NAT, the Acceptor and the PA may disagree about the
Acceptor’s IP address).
Another suggestion was, in those cases where domain information is
needed, to require that the subject names of all End Entities
involved (the Acceptor(s) and the End Entity that appears in a PC’s
certificate path) include domain information.
6. Security Considerations
In this Section we discuss security considerations related to the use
of Proxy Certificates.
6.1. Compromise of a Proxy Certificate
A Proxy Certificate is generally less secure than the EEC that issued
it. This is due to the fact that the private key of a PC is
generally not protected as rigorously as that of the EEC. For
example, the private key of a PC is often protected using only file
system security, in order to allow that PC to be used for single
sign-on purposes. This makes the PC more susceptible to compromise.
However, the risk of a compromised PC is only the misuse of a single
user’s privileges. Due to the PC path validation checks, a PC cannot
be used to sign an EEC or PC for another user.
Further, a compromised PC can only be misused for the lifetime of the
PC, and within the bound of the restriction policy carried by the PC.
Therefore, one common way to limit the misuse of a compromised PC is
to limit its validity period to no longer than is needed, and/or to
include a restriction policy in the PC that limits the use of the
(compromised) PC.
In addition, if a PC is compromised, it does NOT compromise the EEC
that created the PC. This property is of great utility in protecting
the highly valuable, and hard to replace, public key of the EEC. In
other words, the use of Proxy Certificates to provide single sign-on
capabilities in an X.509 PKI environment can actually increase the
security of the end entity certificates, because creation and use of
the PCs for user authentication limits the exposure of the EEC
private key to only the creation of the first level PC.
6.2. Restricting Proxy Certificates
The pCPathLenConstraint field of the proxyCertInfo extension can be
used by an EEC to limit subsequent delegation of the PC. A service
may choose to only authorize a request if a valid PC can be delegated
to it. An example of such as service is a job starter, which may
choose to reject a job start request if a valid PC cannot be
delegated to it. By limiting the pCPathLenConstraint, an EEC can
ensure that a compromised PC of one job cannot be used to start
additional jobs elsewhere.
An EEC or PC can limit what a new PC can be used for by turning off
bits in the Key Usage and Extended Key Usage extensions. Once a key
usage or extended key usage has been removed, the path validation
algorithm ensures that it cannot be added back in a subsequent PC.
In other words, key usage can only be decreased in PC chains.
The EEC could use the CRL Distribution Points extension and/or OCSP
to take on the responsibility of revoking PCs that it had issued, if
it felt that they were being misused.
6.3. Relying Party Trust of Proxy Certificates
The relying party that is going to authorize some actions on the
basis of a PC will be aware that it has been presented with a PC, and
can determine the depth of the delegation and the time that the
delegation took place. It may want to use this information in
addition to the information from the signing EEC. Thus a highly
secure resource might refuse to accept a PC at all, or maybe only a
single level of delegation, etc.
The relying party should also be aware that since the policy
restricting the rights of a PC is the intersection of the policy of
all the PCs in it’s certificate chain, this means any change in the
certificate chain can effect the policy of the PC. Since there is no
mechanism in place to enforce unique subject names of PCs, if an
issuer were 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 effect the rights of a PC down the
chain. Ultimately, this means the relying party places trust in the
entities that are acting as Proxy Issuers in the chain to behave