Once you write your CP, you're ready to select the CAs that will include your CP's OID in certificates. A CA will do this either because you instruct it to do so--if it expects you to use its certificates--or if you permit a CA to simply assert its compliance to the CP based on its own review. Either way, you can use the OID as a trust access control for your users and applications.

The Certification Practice Statement Every CA needs a CPS. But only CAs with self-signed roots must write their own CPSes. A CA that is a delegated CA (that is, its root is signed by the root certificate of another CA) might be required to use its delegation CA's CPS. If you run your own CA, you will need to write a CPS. You should have a CPS no matter what CA software you use or for what purpose your certificates are used.

A CPS is very detailed, as opposed to a CP. A CP might merely state that a user needs to notify the CA operator if a private key is compromised, whereas the CPS supplies the steps for notification as well as the actions to be taken by the CA operator.

However, once again, writing a CPS need not be difficult. Guidelines for writing a CPS are provided in the draft-ietf-pkix-ipki-part4-01.txt document. The CPS provides the means of protecting the CA operator and positioning the CA's business relationships with subscribers and other entities. Thus you will need a CPS no matter what your plans are for digital certificates. Once you have your CP and a set of CPSes, you can begin selecting the CAs you will trust for your business.

The potential liabilities of running a CA are established by the rules set down in the CPS. Factors such as how the root private key is managed, how certificate requesters are validated and how revocation is handled can all impact on liability, and thus on liability insurance for running a CA. As with the CP, the two liability models for the CPS are regulator and contract law. If your certificates will only be used in a state that has passed a digital certificate law, such as Utah or California, you have a regulatory model to follow. Unfortunately, there is no national legislation yet. The legal community is working on federal enabling legislation, as well as developing a letter-of-credit model for CA liability that could significantly change the CA model.

Certificate Policies in Operation You have a choice of selecting which CAs can use your CP, or you can allow a CA simply to assert its conformance (and thus acceptance of warranty) to your CP. This should be a straightforward process of matching requirements specified in the CP with procedures defined in the CPS.

Once this is done, the CA can include the CP OID in certificates, and your applications can use the OIDs. This implies liabilities on the CA and acceptance by the certificate user, so commercial CAs will use a contract to bind the certificate owner to any terms in the CP.

In a private CA, there is still this need for a contract between, say, your employee and your CA. Even if you use general employment terminology, most legal authorities hold that employees must read the CP that regulates use of the certificate(s). Otherwise, you might be left with a liability claim.

Digital certificates are a trust vehicle for the electronic age, but they must fit within our legal framework. The CPS and CP specify this linkage. Meanwhile, the legal community is refining the interaction between our commerce laws and digital certificates, and there are enough guidelines in existence today to assist you in creating your own CP or CPS.

Once you have them in place, you can proceed with a reasonable assurance that your electronic business will have solid footing in your business practices.

Robert Moskowitz is a senior technical director at the International Computer Security Association and a member of the Internet Architecture Board. He can be reached at rgm@htt-consult.com.