Network Computingwww.networkcomputing.com

		our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

Previously in this column, I described the trees and meshes of digital certificates in a PKI (public key infrastructure) for establishing levels of trust. The level at which you can trust a user certificate in a PKI is directly related to the level of trust you place in the root certificates in the PKI. Root certificates are self-signed. In effect, they say, "Trust me." In business, trust is rarely implicit--somehow you have to learn to extend trust to something or someone.

At the Root A CA (certificate authority) that starts with a root certificate must have a CPS (certification practice statement), according to the X.509v3 specification. In the CPS, the operator of the CA states all its business practices so that another business can decide if it will trust a particular CA for issuing its certificates, and if it will accept other certificates issued by the CA. A CPS needs to be very detailed; it states the "how" of running a CA. However, a CPS does not state user requirements for a CA.

A CPS by itself is not enough for a PKI. There also must be a user certificate requirements statement. This is handled in the CP (certificate policy). A CPS is created by the CA operator, but a CP is created by those who rely on the digital certificates for their business. Thus there is the potential for a very large number of CPs within a PKI, compared with a handful of CPSes.

A CP is a set of rules that establishes the applicability of a digital certificate. This set of rules is named with an OID (object identifier).

The OID is issued to the certificate user and it becomes a reference for the rules for a particular community and/or class of application with common security requirements. An example of a class of application might be electronic funds transfer; a particular community might be automotive design engineers. A CP may have any one of a number of purposes. It might be the requirements device for the user stating the level of assurance or trust necessary for certificates. It can be used as an accreditation device, where only accredited CAs will be able to put the OID into their certificates. The CP can define the limits of use of the certificate or it can be a risk-assessment device.

CPs are written at a very high level. A CP might simply state that users must notify the CA if the private key for a certificate is lost or compromised. In effect, everyone who plans on using digital certificates needs at least one CP. Writing a CP need not be difficult. Specification X.509v3 states only that one is needed, while the IETF PKIX workgroup has supplied a guideline for writing a CP. This document is still an Internet draft at ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part4-01.txt, but it is nearing completion and any remaining changes will be editorial.

Also emerging are "model certificate policies." The federal PKI workgroup is writing a model CP for use by all federal agencies. This model will be made publicly available soon, and a large number of commercial and private users is expected to follow it.

CPs and Legalese The legal community does have one concern with certificate policies and the currently available models. The lawyers are looking for what is legally binding between the CP and its users. PKIX Part 4 and the federal model CP both assume a federal agency has the power to adopt regulations to enact this legal binding. They also assume the legally problematic approach envisioned in PEM (Privacy Enhanced Mail, RFCs 1421-1424) of making rules applicable through simple publication or notification. This might cause you a problem in your use of a CP, so check with your legal department.