Title: The Case for Standardization of Certificate Policies for the
Advancement of a Global PKI

**Abstract:** Public key infrastructures offer significant benefits in
any online environment where authentication, confidentiality, integrity
and non-repudiation are important. However, one of the major hurdles in
the widespread deployment of PKI in government as well as commercial
sectors has been the difficulty of two or more PKIs to interoperate with
one another because of their use of dissimilar and incomparable
certificate policies. The current practice of defining private
certificate policies by each organization that deploys its own PKI is
resulting in the proliferation of policy OIDs that are cumbersome to
compare and contrast. When the initial hurdles of interoperability in
the realm of compatible data and message formats are crossed, the policy
incompatibilities would pose the next significant challenge to the
adoption of PKI by organizations that need to interact securely with
their external business partners. In this paper, a case is made for the
standardization of a set of well-defined and accepted certificate
policies that can be adopted or used as a reference by organizations as
they deploy their public key infrastructure. The benefits of such policy
standardization, while preserving full flexibility with respect to an
organization's ability to control trust propagation across other policy
domains is described.

The Case for Standardization of Certificate Policies for the Advancement
of a Global PKI

# Background

A public key infrastructure comprises three types of entities: the
certificate user (or relying party), the certification authority (or
CA,) and the certificate subscriber (or end-entity). The Certificate
Authority issues certificates to the end-entity; the relying party uses
the certificate to authenticate the end-entity. A certification path
comprises zero or more CA certificates and a single end-entity
certificate. The X.509 standard \[1\] includes a certification path
processing procedure that can be applied to determine the validity of a
given certification path.

In all but the simplest of certification paths (comprising a single
end-entity certificate,) there are one or more CA certificates. The
relationships between the various CAs within a non-trivial certification
path is expressed by using one or more of the following certificate
extensions in the CA certificates within the path: name constraints,
certificate policies, policy constraints, and policy mappings. While the
name constraints extension expresses the allowed namespace that may be
used by a subject authority, the other three extensions express the
"trust" or policy relationships between the CAs.

A certificate policy is defined as "a named set of rules that indicates
the applicability of a certificate to a particular community and/or
class of application with common security requirements." [^1] It is also
defined as "the policy under which the certificate has been issued and
the purposes for which the certificate may be used."[^2]

Organizations that deploy private public key infrastructures as well as
service providers that deploy shared public key infrastructures
typically develop one or more certificate policy (CP) documents that
describe the policies applied in the issuance of the certificates within
that PKI. A certificate policy document is usually written in
plain-language, and is referenced by a unique identifier called an
Object Identifier (OID). The certificate policy identifier may be
included in the certificate policies extension of the certificate issued
by the certification authority to the end-entity. A certificate may be
issued in accordance with one or more policies, in which case, all
applicable policy identifiers may be included in the certificate
policies extension of the issued certificate.

Some certification paths may cross the boundaries between policy domains
through the use of cross certificates. One or more of the policies in
the issuing authority's policy domain may be equivalent to policies in
the subject authority's policy domain, even though the policies may be
associated with different policy identifiers. The equivalency may be
expressed within the cross certificates issued between the two CAs. In
the policy mappings extension, the issuing authority asserts the
equivalency relations between the policies in the issuing and subject
authority domains. Policy mapping allows the relying party to accept
policies in a foreign policy domain as equivalent to policies in its own
policy domain.

# Certificate Policy Usage within the X.509v3 Framework

Although the X.509 framework and the PKIX profiles support a rich set of
policy related features, current applications make limited use of these.
As the products in this sphere mature, it is expected that policy
processing will be included as an integral part of PKI enabled products.
When a relying party performs policy processing, they are trying to
answer the following types of questions:

Can I trust this public key belongs to the individual named in the
certificate?

Is this public key suitable for my needs?

Under what policies is this path valid?

What kind of assurances and warranties am I getting from the CA?

What are my obligations and liabilities when I use this certificate?

To answer these types of questions, the X.509 policy processing
algorithm is applied to the certificate path from the subscriber's
certificate to a root CA trusted by the relying party. The policy
related extensions and their usage are described below.

## Certificate extensions

The X.509 framework provides three standard certificate extensions that
are used for policy processing. These are the certificate policies
extension, the policy mappings extension, and the policy constraints
extension.

The Certificate Policies extension comprises a series of policy
identifiers that assert the policies under which the certificate was
issued, indicating the purposes for which it may be used. This extension
may be critical or non-critical. Optional policy qualifiers may be
present in this extension, although they do not affect the definition of
the policy. Policy qualifiers allow further qualification of each policy
asserted. IETF PKIX RFC 2459 \[2\] defines two qualifiers: the *CPS
Pointer* qualifier, which is an URI that points to the CPS published by
the CA, and the *User Notice* qualifier, which is intended for display
to a relying party when the certificate is used.

The Policy Mappings extension is used in CA certificates only. It
asserts equivalency relations between policy OIDs across disparate
policy domains. It may contain one or more policy equivalency mappings.
This extension must be non-critical.

The Policy Constraints extension is used in CA certificates only. It
asserts two types of policy related constraints: *Inhibit Policy
Mapping* indicates that policy mapping is to be inhibited while
processing subsequent certificates, while *Require Explicit Policy*
indicates that subsequent certificates need to include an acceptable
policy identifier. This extension may be critical or non-critical.

## Components of a certificate policy

The certificate policy for a CA governs its operational behavior as well
as the legal responsibilities between the CA, subscriber and the relying
party. The IETF Informational RFC 2527 \[4\] defines a framework for the
definition of a certificate policy. An alternate way of itemizing the
primary components of a certificate policy is the following. A
certificate policy defines:

-   *certificate usage* -- the application or usage scenarios that the
    certificate is targeted for

-   *quality of binding* -- the process by which the identity of the
    subscriber is authenticated and the subscriber's public key is
    verified as belonging to the subscriber

-   *CA operational security* -- the operational procedures that are
    used by the CA to protect its private key and the personnel security
    controls used

-   *CA liabilities* -- the legal liabilities accepted by the CA

-   *subscriber and relying party obligations* -- the responsibilities
    of the subscriber and relying party

The categorization above is important since it breaks up a complex
policy into some of the core constituent parts. If each of the
components is scrutinized, it is not difficult to realize that the
reasonable alternatives for each component are but a few. Although each
PKI deployed today tends to define its very own certificate policy,
chances are that the details of many of the components of these
apparently dissimilar policies are indeed very similar.

## Relying party acceptance of a certificate policy

When a relying party accepts a certificate policy for a given
certificate they need to determine the suitability of the certificate
policies (used by the issuing CA) for the usage scenario. To initialize
this process, the relying party has to determine what its policy
requirements are with respect to the application under question. Beyond
this point, for every certificate policy encountered within peer
certificates, the relying party has to undergo the following three
steps. First, the relying party has to obtain access to the details of
the certificate policy. Second, the policy details have to be analyzed
to determine whether it meets the requirements of the relying party.
Finally, the relying party has to have some assurance that the issuing
CA is indeed following the declared policy statements.

Making the policy details available to the relying party may be done in
one of several ways. The details of the policy may be available to the
relying party through prior negotiation between the CA and the relying
party. Alternately, the detailed policy may be available at the CA's
website. A third possibility is that the policy details are well known
and standardized and is available from trusted sources.

Analyzing the details of the certificate policy can seldom be done while
the certificate-based transaction is being processed. There exist no
automated procedures to analyze a certificate policy. As a result, such
analysis is typically done in an *ad hoc* fashion, and may involve
consultation with legal personnel. It is conceivable that a human
relying party can retrieve and analyze a CP, in the process of accepting
a certificate for a low value transaction. However, typically, the
analysis of a CP for a particular usage is a laborious process and needs
to be done prior to the actual certificate based transaction.

Finally, in order to accept a given certificate policy declared by a CA,
the relying party has to have some assurance that the CA is indeed
following the CP. This assurance may be achieved through organizational
guidelines, for relying parties within the same organization as the
issuing CA. When the relying party and issuing CA belong to different
organizations, this assurance has to be achieved through the existence
of a third party infrastructure. This infrastructure could take the form
of an independent audit agency that publishes the results of regular
audits of the CA. Another option may be the availability of legal
infrastructure that penalizes a CA that is not in compliance with its
published CP.

To summarize, the acceptance of a particular certificate policy for a
specific usage is by its very nature a non-trivial, multi-step process.
Any and all mechanisms that can help to simplify and streamline the
above steps would greatly facilitate the rapid adoption of interoperable
PKIs.

#  Proliferation of Certificate Policies -- Problem Scenario

Within and across public key infrastructures, the certificate policies
that are used by the various CAs are the handles used to determine the
"trust" that can be established between CAs. As more and more agencies
and organizations are embracing PKI technology and establishing their
own organizational PKI, the current trend is for each such organization
to develop their own custom certificate policy (CP) and certification
practice statement (CPS) documents. There exists a well-established
framework for the development of CP and CPS documents, namely RFC 2527
\[3\]. A large percentage of the individualized CP/CPS documents are
nearly identical in terms of features and functions, yet each such
"individualized" CP is allocated a unique Object Identifier (OID)
typically under the organization's ARC.

As described in the last section, in order to evaluate a certificate
policy for a specific usage, several steps need to be undertaken. When
policies are private to a domain, it is difficult for relying parties
outside the domain to have access to the policy details. It is even more
difficult to assess the contents of the policy against the policy
requirements levied by the usage domain. Finally, it is nearly
impossible to have faith that an external infrastructure will ensure
that a CA from an external domain is following the certificate policy
that it has published.

Within an organizational PKI, the subscribers implicitly know about (or
can find out) about the certificate policies in use and thereby are able
to determine which policies are to be trusted for which purposes and
applications. Any certificate that can be validated to the known root of
trust for that organization can therefore be "trusted" to be based upon
the certificate policy of the issuing CA.

Across organizations, it is cumbersome, if not impossible, for
subscribers in one organization, to determine the meaning and
implications of the "individualized" certificate policies from the other
organization. This is because policy OIDs carry no meaning whatsoever,
and it is very difficult to peruse a CP and CPS document to the level of
detail necessary to determine whether the policy is sufficient for any
given purpose.

Another negative impact of non-standardized certificate policies is the
cost involved in defining an appropriate certificate policy for each
PKI. Developing a customized certificate policy from scratch entails a
significant amount of effort and hence cost. There is also significant
cost involved in the analysis of policies to determine equivalencies for
purposes of cross certification between CAs.

## Implicit and explicit assertion of certificate policies

Certificate policies are relevant to certificate usage in at least one
of two ways. Sometimes, the certificate policy supported by a CA does
not explicitly appear in the body of the certificates issued by that CA.
Rather, the certificate policy is implicit in the certificates issued by
that CA. In this situation, the relying party does not perform
certificate path policy processing. The identity of the issuing CAs is
used to determine whether a given certificate may be trusted with the
assumption that the policies used by the issuing CAs are implicitly
known and accepted by the relying party.

Often, the certificate policies in use by a CA are asserted within the
issued certificates using the certificate policies extension. Mappings
between policies from other domains may also be asserted using the
policy mappings extension. In these situations, the relying party may
perform certificate path policy processing to determine whether the
asserted policies are acceptable. With the proliferation of certificate
policy OIDs from various isolated PKIs, it becomes difficult if not
impossible for a relying party to understand the implications of
accepting or rejecting specific certificate policies.

## Bridge Certification Authority

The Federal Public Key Infrastructure (PKI) is considering the
deployment of a Federal Bridge Certification Authority (FBCA) to
facilitate the unification of the PKIs operated by the various Federal
agencies, state and local governments, and businesses. Secure and
unclassified transactions will be enabled between these parties and the
general public over the public Internet.

The products and services used by the various Federal agencies, state
and local governments vary widely. The FBCA is envisioned to act as a
focal point for bridging the trust paths between the PKIs of various
organizations. It is important to note that the FBCA is not a root CA.
Rather, it may likened to the hub of a multi-spoked wheel, each spoke
establishing a pairwise trust relationship between the FBCA and an
agency PKI. Relying parties from each of the participating PKIs will
still use their own local root CA as the root of trust. The FBCA
provides a certificate path from any of the local roots to any
subscriber within the PKIs that are connected via the FBCA.

The root CA of each participating PKI will cross certify with the FBCA
resulting in a cross certificate pair being generated between the FBCA
and the participating CA. If the certificate policies of the CA and FBCA
are different, and then policy mapping relations need to be expressed
within the cross certificates to establish the equivalence of the CA's
policy and the FBCA's policy. Once these cross certificates are
established, relying parties within any of the PKIs can establish a
certificate path from their local root CA to any of the subscribers
within the other PKIs.

Conceptually, certificate policy mappings with the FBCA are easy to
comprehend. However, they are very difficult to establish in real life.
When two certificate policies that have been developed independently
from the ground up need to be compared and contrasted to determine
whether they are equivalent, the analysis process is extremely
cumbersome. Additionally, the legal ramifications of such policy
equivalence mappings pose a major roadblock to progress.

In the absence of the FBCA, each pair of PKI root CAs would need to do a
pairwise cross certification to enable interoperability between the two
domains. With the FBCA in existence, each participating root needs to
cross certify only with the FBCA. Thus, the FBCA concept theoretically
reduces cross certification between independent PKIs from a problem of
O(n^2^) to a problem of O(n). However, the technical problem of cross
certification between dissimilar PKIs is only one aspect of the overall
problem of propagating trust between and across PKIs. The political and
legal problems are the more difficult ones to solve in this space, and
the proliferation of unrelated certificate policies that are private to
each PKI serves to further complicate the situation.

Let us assume that each participating PKI that is to cross-certify with
the FBCA has its own set of certificate policies. The FBCA defines a set
of policies for its own use. As each root CA cross certifies with the
FBCA, the policies of that CA need to be compared with the policies of
the FBCA. When an equivalency relation can be agreed upon, the policy
mappings extension within the cross certificates will assert the
equivalence of one of more of the CA's policies with the FBCA's
policies. However, the problem does not end there. For each new root CA
that wants to cross certify with the FBCA, each currently participating
root CA needs to understand the new policies being introduced and their
relation to the policies in its own domain. Each current participant has
to agree to allow the newcomer into the fold. Thus, although
technically, only one new cross certificate pair is generated with the
introduction of the new root CA, the policy related analyses and
decisions are still of O(n^2^). Thus the benefits of the FBCA concept
are diminished considerably when operating in an environment where each
participating root CA defines its own set of certificate policies.

# Standardization of Certificate Policies

There are a large number of standardization efforts that are underway
within the realm of cryptography and PKI. Standardization is essential
in technical areas where the functionality is distributed in nature, or
involves entities from disparate domains or organizations. In these
situations, it is important to have a commonly understood set of
mechanisms, functions, protocols and data formats to facilitate
distributed processing. Standardization is also very useful when dealing
with technical areas that are very abstract or difficult in nature,
where the standardization process establishes a widely reviewed and
vetted specification that can be reused and reapplied in multiple
domains. Certificate policy definition and usage satisfies both of the
above criteria that justify the need for standardization. Yet, outside
of some government circles, there is limited activity in the
standardization of certificate policies. We would venture to predict
that the success of PKI will be severely and adversely impacted, unless
there is awareness and acceptance in the PKI community that
standardization of certificate policies is crucial to the success of
interoperable PKIs.

The obvious benefits of standardization of certificate policies are as
follows. An organization can select from a set of well-defined policies,
the subset that meets its own requirements. An organization can adopt
one or more of these standardized policies without the cost or
complication of developing the policies from the ground up. Since these
policies will have undergone an industry-wide review process, the
operational aspects of the policies will be well understood, and can be
readily implemented by the CA facility. The use of standardized policies
will significantly reduce PKI deployment startup time, as well as
deployment costs. Standardized policies will be highly available by
their very nature since they are public domain specifications.
Comparative analyses between these standard policies will be widely
available, thus relieving each organization or subscriber from having to
perform such analyses.

With the widespread adoption of standardized certificate policies, it is
conceivable that external auditing agencies will be able to offer their
services at a reasonable fee to assess compliance with these policies.
This will increase consumer confidence in the correct operation of PKI
technology and hence facilitate the acceptance of certificates from
external PKIs. An additional increase in consumer confidence will come
about if the legal system in various jurisdictions made it punishable to
declare conformance to one of these standard policies and failed to
comply. Conceivably, it is easier to enforce a small set of known
policies than enforce the potentially infinite set of proprietary
policies. It is also easier to enforce a publicly available policy
specification since a privately held one may be manipulated
appropriately at an opportune time to absolve the organization of any
malpractice charges.

The use of standardized certificate policies lends an immense helping
hand to the success of the FBCA. If the majority of agencies and
organizations choose to use one of the standard policies, and these
policies are easily auditable and legally enforceable, the cross
certification between the participating PKIs and the FBCA becomes almost
trivial in complexity.

## Trust propagation 

While standardization of certificate policies has obvious positive
impact as described above, there needs to be some analysis to determine
whether there is any negative impact. Can the standardization of
policies in any way result in the loss of control over the trust
propagation between different domains? In our analysis, the answer to
this question was a definite no. The use of standardized certificate
policies does not in any way affect the flexibility offered by the X.509
framework for control over propagation of trust.

Even when two independent public key infrastructures are using the same
set of certificate policies, there is no implicit trust relationship
between subscribers and relying parties between the two infrastructures.
The relying party still needs to establish a path of trust from a
subscriber certificate (possibly in a different domain) to one of the
locally trusted roots in order to accept the certificate for a
transaction. Cross certification between unconnected PKIs is simplified
(as discussed above) by the use of standard certificate policies,
however, each PKI is still able to make its own decision regarding the
issuance of the cross certificate and the policies that are asserted in
the extensions of that cross certificate. While cross certification
establishes trust propagation to secondary trust domains, an area of
concern is whether a cross certificate to a secondary domain can result
in further trust propagation into other tertiary policy domains. The
X.509 framework provides specific extensions (namely, the path length
constraints, name constraints, and policy constraints) to limit the
ability to establish verifiable certificate paths to such tertiary
domains. All of these constraints work as specified regardless of the
use or non-use of standardized certificate policies.

## Customizing certificate policies

In certain situations, a CA may wish to use specific customized
procedures that are dictated by its specific unique requirements, and it
may not be possible to identify a standardized certificate policy that
matches the requirements. In such cases, if interoperability with other
PKIs (that use standardized policies) is desirable, it is recommended
that the closest standardized policy is selected as a base policy. The
base policy may then be augmented with specific unique elements to
develop a custom policy. The policies asserted within certificates
issued by this CA may include the identifiers for the base policy as
well as the custom policy. The resulting certificate can then be used
easily by relying parties in other domains who only require the base
policy, and for whom the custom policy is of no relevance. Within the
domain of this CA however, the relying parties may require presence of
the custom policy for all certificates that are accepted for a
transaction.

In certain other situations, a CA may wish to establish a policy domain
where it is not desirable that the certificates in that domain be used
outside the domain. In such cases, a custom certificate policy should be
developed (perhaps based upon the template of a standard policy to make
maximal use of existing policy declarations). The identifier for this
custom policy should be asserted within certificates issued by that CA.
These certificates will thus be unusable to relying parties in other
domains.

## Certificate Policies - Standardization Paradigms

Standardization of certificate policies may be done based on a variety
of standardization paradigms. One possibility is that certificate
policies be defined for various classes of popular applications that
rely upon a PKI, namely, secure email, secure web access, virtual
private networks, etc. Thus one or more certificate policies may be
defined for each type of application. This standardization paradigm
allows the easy selection of policies for use within a certain class of
application. All public key infrastructures where a particular
application is relevant will adopt the appropriate standard policy for
that application and assert the policy within the certificates issued.

Another standardization paradigm may be based upon industry sectors,
such as banking, healthcare, automotive, etc. For certificates that are
used only within a particular sector, the appropriate sector-specific
policies may be adopted and asserted by the CAs. A third angle for
standardization may be based upon the quality of the user registration
process, resulting in various levels of assurance about the binding of
the subscriber name and the public key within the certificate. A fourth
option may be standardization based upon legal jurisdictions such as
individual countries (such as the US or Canada) or groups of countries
(such the European Union).

A completely different mechanism for standardization may be to define a
series of policies that specify different aspects or components of a
full certificate policy. For example, there may be policies that only
refer to the operational procedures for the CA, or policies that only
refer to the dollar amount of the liabilities accepted by the CA. Within
a PKI, a combination of multiple, standard, component policies may be
selected to describe the fully represent the policy adopted by the CA.

# Conclusions

The thesis of this paper is that the uncontrolled proliferation of
custom certificate policies will result in a situation of total anarchy.
Even after the fundamental hurdles of interoperability (namely, data
formats and protocols,) are resolved, the policy incompatibility
problems will take on a monstrous dimension, and introduce political and
legal problems that are far more difficult to resolve. It is recommended
that various standards bodies and industry consortia adopt charters that
include the standardization of certificate policies.

Some attempts at standardization of certificate policies are happening
at the time of this writing. However, the fundamental conclusion of this
paper is that there is not sufficient awareness of the potentially
crippling problems that will arise if certificate policies are not
developed and used in a controlled manner.

### References {#references .unnumbered}

1.  ITU-T Recommendation X.509, Information Technology - Open Systems
    Interconnection: The Directory: Public Key and Attribute Certificate
    Frameworks 5/2001.

2.  IETF RFC 2459, Internet X.509 Public Key Infrastructure Certificate
    and CRL Profile, <ftp://ftp.isi.edu/in-notes/rfc2459.txt>, January,
    1999.

3.  IETF RFC 2527, Internet X.509 Public Key Infrastructure Certificate
    Policy and Certification Practices Framework,
    <ftp://ftp.isi.edu/in-notes/rfc2527.txt>, March, 1999.

[^1]: X.509 Framework \[1\]

[^2]: IETF PKIX RFC 2459 \[2\]