As one example, governments face the problem of enabling and managing cross-border travel and immigration. To address such requirements, government law and/or policy typically requires citizens crossing national boundaries to possess passports that establish citizenship and identity. A passport links or "binds" some information about the individual (photograph, height, weight, age) to a specially designed physical document having a unique issuing authority and control number.
The passport-issuing authority follows policies for issuing passports, which may require the applicant appear in person at a designated office, complete a paper application, present several forms of identification, and wait while all of this information is reviewed and verified. Countries where the passport is presented have their own policies governing its acceptance and may require further documentation before authorizing entry, in the form of a visa. Additionally, the issuing country has a method of revoking or withdrawing a passport when necessary - and passports have built-in expiration dates to allow for change in both the passport holder and the policies of the issuing authority.
At some point, the policies of the issuing authorities and those accepting the passport may intersect. For example, a particular country's immigration authority may not merely accept the passport at face value, but may conduct an online database check at the border. Others may not. Polices and processes are also at work in non-governmental environments, where identity credentials are issued by trusted third parties, such as financial institutions. Keeping all these policies and processes in mind helps in understanding how the same sorts of requirements apply to public key infrastructure (PKI).
Why Must PKI Place Such Importance On Policy?
PKI is most often discussed purely in terms of its component technologies (the use of public key cryptography and underlying systems to enable digital signatures, strong authentication, data integrity, non-repudiation and confidentiality). However, those supporting technologies require an infrastructure (the I in PKI), and that infrastructure encompasses much more than cryptographic technology and protocols. It includes the policies governing the use of PKI, and the risk management controls and business processes needed to enable PKI-supported systems and applications.
The distinguishing feature of PKI is the use of a certificate published by a certification authority (CA) to confirm the identity and other relevant information about the entity that holds the certificate. It is critical for a "relying party," that is, an application or another person who relies on the certificate, to be able to have confidence that the certificate correctly and accurately identifies the subject and the subject's key, and the credentials of the issuer of the certificate.
Given the importance of correctly establishing the strong linkage of a private/public key pair to a subject, and in some cases warranting the "binding," policies must be established. These policies must define the level of trust that can be placed in a certificate when it is presented to a relying party application (e.g., web server) - a level of trust that will be related directly to the assurances provided in the overall certificate issuance and management process. Policies must also define the rules and liabilities of the parties involved in issuing, managing, and processing certificates.
The role of policy in PKI is critical as it defines the level of risk for relying party applications in a given community of interest. However, PKI policies are in no way mysterious. They in fact are directly related to trust policies already in place in the traditional world (and often taken for granted because they are so common and so integral to our traditional way of conducting business).
The Parties Involved
In PKI-supported environments, as with the traditional business models, there are multiple parties directly involved in achieving the appropriate level of trust with respect to the creation and use of public key certificates:
- the individual or entity identified by the certificate (subject or subscriber);
- the issuer of the certificate, which includes identification and authentication of subject information contained in the certificate (certification authority/registration authority);
- the entity that provides certificate validation services in certain implementations (validation authority);
- the company, agency or individual relying on the certificate (relying party).
At a minimum, three of the parties identified above are required to support a PKI policy: certification authority, subject (or subscriber) and relying party. (From this point forward, the term subscriber will be used instead of subject, as the term subscriber is accepted in the legal and policy community.) To assist the CA, a registration authority and validation authority may be deployed to perform subject registration and certificate validation functions, respectively.
In either case, the responsibilities and liabilities of these parties are expressed in the PKI policy, and specifically, in a certificate policy. As a practical matter, it is the relying party who "creates value" by making use of the certificate, and so the relying party has considerable interest in the policy supporting the creation and use of the certificate.
As the value and/or sensitivity of the transaction increases, the strength of the underlying policy becomes more critical.
For example, a health care provider may establish policies regarding the issuance and management of certificates provided to physicians. Those requirements will differ greatly from requirements for issuing certificates to employees who do not prescribe controlled substances. The risk associated with each certificate's use must be addressed by the appropriate set of policy requirements.
Certification authorities play a major role in establishing certificate policies. For example, a CA may work with a group of companies or an industry in creating a certificate policy accepted as appropriate for use in that sector, and relying parties may simply write their individual policies to reflect this model.
The set of policy requirements governing the creation and use of public key certificates is known as a certificate policy (CP), and a guideline which defines aCP has been established by the Internet Engineering Task Force in the "Certificate Policy and Certification Practices Framework" (also referred to as the IETF Framework). By IETF Framework definition, a CP is "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."
Once established, a CA can identify a policy, including qualifying information about the policy, in a certificate. By doing so, the CA is declaring the intended use of the certificate to a relying party who may process the certificate. Similarly, a relying party can simply look for the appropriate policy identifier information in a certificate to assist in processing certificates that are acceptable to that relying party.
Certification Practice Statement
The IETF Framework defines the certification practice statement as the "statement of practices which a certification authority employs in issuing certificates."
A certification practice statement (CPS) is often confused with a certificate policy, but in fact reflects a CA's statement of practices which should establish conformance with the relevant requirements of one or more certificate policies, or enable relying parties and subscribers generally to assess the level of trust they may have in the CA and the certificates it issues. Generally it is understood that a CPS contains much greater detail than a certificate policy, and may in fact be used to support multiple CPs. In simple terms, one should view the certificate policy as the "what I need to do" document, and the certification practice statement as the "how I need to do it" document.
Agreements such as subscriber agreements, relying party agreements, privacy notices, etc. are also required to establish and maintain a complete infrastructure.
This is because the PKI policy has little value without explicit linkages to the existing legal, regulatory and business policy infrastructure which supports business and government transactions and other applications. For example, a policy may require a subscriber to accept certain responsibilities with respect to the use of the certificate or with respect to the protection of the private key corresponding to the public key contained in the certificate. But enforcement of these policy conditions may in turn require the establishment of a legally binding contract between the CA and the subscriber.
Likewise, other parties in the PKI may be bound together by agreements and other forms of contract, thus establishing a legal basis for their obligations and any liability in the use of the PKI. For example, the relying party agreement may specify a limit on the value of a transaction or the type of transaction for which the relying party will use a particular certificate. The privacy notice will specify the privacy policies observed by the CA, which in certain international jurisdictions, for example European Union countries or Canada, will be enforceable under law.
How Policy Is Managed
As noted in the above discussion, PKI reflects and supports existing business and governance models. We see three basic models for managing policy.
The first is an enterprise model, where a PKI is used to issue certificates that are used solely within the enterprise (e.g., a corporation), such as to control employee access to corporate resources.
The second is a trading partner model, for organizations that have a requirement to do business with the certificate issuing organization. An example of this is a wholesale electronic parts exchange PKI used by a limited set of business partners.
The third model is a community-of-interest (COI) model. In this model a PKI is used to issue certificates that are used by authorized relying parties (ARPs) within a large community of interest (e.g., healthcare, financial services). Examples of this include efforts such as GSA Access Certificate for Electronic Services (ACES), Identrus, American Bankers Association (ABA) TrustID, and products like the electronic ID cards issued by the Finnish Population Register Center and the Swedish Post.
In the extended world of e-commerce and e-business, either the trading partner or COI model needs to be used. In the trading partner model, disparate PKIs must determine a way to interact to allow business transactions to flow between various trading partner domains. For example, Ford Motor Co., General Motors Corp., and Chrysler Corp. may each deploy a PKI that issues certificates to their trading partners. Given many of these trading partners do business with all three manufacturers, the partners must either obtain a certificate from each issuer (Ford, GM and Chrysler), or a solution must be developed where Chrysler accepts a certificate issued by Ford. To date, the commonly accepted approach is for a relying party to trust multiple certificate issuers.
However, initiatives such as the U.S. Federal Bridge provide an alternative to trusting multiple certificate issuers. In this model, a bridge is established to govern and cross-certify individual root CAs used to issue certificates within their PKIs. This allows certificates issued by one organization to be used by other organizations for applications requiring equivalent levels of trust. Such cross-certification can also be done bi-laterally between any two organizations (e.g., Ford and Chrysler).
However, this poses a problem on certificate issuing organizations as the number of bilateral agreements increases over time.
In the COI model, a certificate issuer or set of certificate issuers is trusted by authorized relying parties (ARPs) to issue certificates to subscribers within a given community. This is accomplished through the establishment of a common certificate policy and a contract infrastructure. These define the rules (typically set by the ARPs, since they take on the most liability in accepting certificates) that bind all parties together: CA, subscriber and relying party. This model is very effective, as it eases the decision making process on relying parties, but it takes time to create, requiring a consolidated effort on the part of the relying parties that make up the COI.
Other PKI Policy Issues
There are a large number of PKI policy issues being addressed today, and it is likely the number of issues will grow as PKI becomes more widely adopted and as business and government applications increasingly interact. For example, a long-standing issue is the liability exposure for certificate authorities in instances where, despite policies limiting use of a certificate to a certain class of relying parties, a business or individual outside that class accepts and processes a certificate without authorization to do so. This issue has concerned some governments as well, who worry that government-issued certificates will become de facto requirements for non-governmental business.
From a legal perspective, the use of disclaimers and limits on reliance and liability in a CP may not be adequate protections for CAs. In some communities (e.g., the work of the American Bankers Association and Identrus), the concept of authorized relying party (ARP) has been developed to address this issue. An authorized relying party (ARP) is contractually bound to accept only certain types of certificates.
Other areas at issue include differing governmental requirements for electronic signatures versus PKI-based digital signatures, the need for more "human understandable" policy statements, the appropriate protection of personal information collected in the certificate registration process, and even the data incorporated in the certificate as an individual identifier.
The next two to three years should be interesting. With electronic signature legislation being enacted globally, it is expected that online agreements that hold legal effect will increase dramatically over the coming years. This should provide an impetus for PKI implementers and relying parties to develop solutions that take advantage of this newly signed legislation.
John Sabo is business manager, security, privacy and trust initiatives for Computer Associates (www.ca.com) and Yuriy A. Dzambasow is chief technology officer for Digital Signature Trust Co. (www.digsigtrust.com).
This article was written under the auspices of the PKI Forum (www.pkiforum.org), an international, not-for-profit, multi-vendor and end-user alliance whose purpose is to accelerate the adoption and use of public key infrastructure.