- Certificates
- Certificate Policies
- Certification Authority
- Registration Authority
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Certificate Policies
As indicated earlier, a number of policy-related extensions may be present in a given certificate. The policy-related extensions are extremely important in the sense that they help govern the acceptable use of the certificate in terms of policy compliance, potentially across multiple PKI domains.
The policy-related extensions refer either directly or indirectly to a certificate policy. The X.509 Recommendation [X.509–00] defines a Certificate Policy 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. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.
The Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [RFC2527] also adopts this definition.
This can be contrasted with the definition of a Certification Practice Statement (CPS):
a statement of the practices which a certification authority employs in issuing certificates [ABA].
In general, it is agreed that (1) a Certificate Policy is a high-level statement of requirements and restrictions associated with the intended use of the certificates issued under that policy and (2) a CPS is an extremely detailed (and potentially extremely sensitive) document that describes the internal operating procedures of the CA and/or PKI that issues those certificates. What is not universally accepted is the role that these documents have with respect to end-user notice and multidomain cross-certification arrangements.
Interesting sources of information related to Certificate Policies and CPSs include the following:
"The Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework" [RFC2527]
CARAT Guidelines [CARAT] sponsored by the National Automated Clearing House Association (NACHA)
The American Bar Association (ABA), Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce [ABA]
The Automotive Network eXchange (ANX) Certificate Policy [ANX]
The Government of Canada Certificate Policy [GOCCP]
The U.S. Federal PKI "Model Certificate Policy" [MCP]
From a high-level perspective, most of this documentation reflects the common theme noted earlier. In particular, a Certificate Policy is expected to be a higher-level document than a CPS, and it is typically concerned with what will be supported rather than how it will be supported. (See Box 6.3.) Conversely, a CPS is expected to be a fairly detailed and comprehensive technical and procedural document regarding the operation of the supporting infrastructure. For example RFC2527 points out that CPSs
may be quite comprehensive, robust documents providing a description of the precise service offerings, detailed procedures of the life-cycle management of certificates, and more—a level of detail which weds the CPS to a particular (proprietary) implementation of a service offering.
Object Identifiers
To easily distinguish one Certificate Policy from another, each Certificate Policy is assigned a globally unique OID. One or more OIDs can be specified in the Certificate Policies certificate extension, which can be further qualified as appropriate. For example, RFC3280 defines two optional Certificate Policy qualifiers: a User Notice and a pointer to a CPS. Certificate Policies can be placed in end-entity certificates as well as CA certificates. Cross-certificates (as described in Chapter 9) may also contain the Policy Mappings extension, which permits a policy OID in one domain to be designated equivalent to a policy OID in another domain. Thus, if two PKI domains have each defined a Certificate Policy for the exchange of their own internal e-mail and the two policies are deemed to be equivalent by each domain, defining yet a third policy OID to allow e-mail exchanges between the two domains is not needed.
Policy Authorities
Policy authorities (sometimes referred to as policy management authorities) establish Certificate Policies. The policy authority itself may vary from one organization to another. For example, each organization may establish its own policies under the authority of the internal Information Technology Security (ITS) department or equivalent. Alternatively, this authority may emanate from a policy advisory board made up of members from each major department in an organization. In concert with the internal authority (or perhaps in lieu of such an authority), an external policy authority may establish the Certificate Policies for a number of PKI domains that belong to the same community of interest. In any event, the applicable policy authority is responsible for registering Certificate Policies with the appropriate registration authority (for example, a national registration authority) so that the Certificate Policy OIDs can be assigned appropriately.
Box 6.3 The Role of Certificate Policies and CPSsThe role that Certificate Policies and CPSs may have is not universally agreed upon and, to a large extent, depends on the type of PKI domain in question. For example, the model we see in the Web environment demonstrates that suppliers of Web server and end-user certificates (such as Verisign) publish their CPS on their Web site, and the certificates that they issue point to their on-line CPS. The CPS contains a great deal of information, including warranties and obligations meant to be conveyed to the end user. Thus, the CPS is a public-domain document, subject to the scrutiny of many. On the other hand, an enterprise PKI domain typically considers the CPS to be extremely sensitive, usually reserved for internal audit purposes. The CPS is rarely a public-domain document in these cases, nor is it used to convey information to the end users in the enterprise domain. The role these documents have in forging cross-certification arrangements (cross-certification is described in Chapter 9) can also vary. One school of thought suggests that the CPS of one domain should be scrutinized against the CPS of another. On the other hand, the CPS may not form a suitable basis for establishing cross-certification (or more generally, interoperability arrangements) for a number of reasons. First, as noted earlier, the CPS tends to be an extremely detailed and voluminous document, which would make CPS comparisons tedious and labor intensive (barring standardized markup languages and automated tools, of course). Second, terminology variations from one CPS to another that make equivalency comparisons problematic may be present [PAG]. Third, a given organization may consider their CPS to be too sensitive to be released externally, even for the purposes of establishing a cross-certification agreement with another enterprise. It can therefore be argued that Certificate Policies form a much more suitable basis for establishing cross-certification agreements. In the future, we may even see the use of PKI Disclosure Statements for establishing interoperability agreements between enterprise domains. See http://www.verisign.com/repository/disclosure.html for an example of a PKI Disclosure Statement. Given the above, some would suggest that only a CPS is required for a CA service provider and only a Certificate Policy is required for an organization. However, it has been our experience that a CPS is typically used in an enterprise context to document the internal operating procedures of the organization's PKI and that the CPS is often used for internal audit purposes. It is also possible for an organization to adopt the CPS of a third-party service provider when that third party supplies some or all of that organization's PKI services. |