7.4 Certification practice statement 183
for a root certificate in common, because then the bad dude can
access your servers. The bad dude can then access any resource or
database that does not have any restrictions (aka "anonymous"). If
you have access restrictions, the bad dude will not be able to access
those resources for the following reasons: the bogus name is Bad Boy
Jim; the access list is David Smith and Maria Jones; and authorization
to the resource is controlled via the public keys of each user name.
Remember that in this example, the bad dude did not have write
access to the directory source, so he or she cannot get the needed
public keys into the directory to gain access to an authorized
resource. Get it? If not, read it again.
Now let's modify the scenario. What if the bad dude has write access to
your directory? In that case, you will need to do the following: update your
resume; place it on www.monster.com; start to interview; and consider a
job flipping burgers.
We are teasing a bit, but having write access is even worse; now the user
can modify the public keys, he or she can intercept encrypted mail, and
can, for the most part, grant access to any resource. Get it? If not, reread
this section until your head hurts. This is important!
So what are the rules? (This is clearly a "man-in-the-middle attack"~
public key substitution. It is not practical for an outsider to pull this off but
more likely for an insider or former insider who has had access into critical
systems such as PKI and/or e-mail.)
1. Don't lose control of your CA(s).
2. Don't grant write access to your directory resource, or, at least,
control it and audit it.
7.4 Certification practice statement
We have seen the importance of a CA; now we need to discuss the services
that the CA provides, which apply to both open and closed systems. We
need to look at the practices of the CA, including the actual services, the
legality of the CA, and the trustworthiness of the CA. The concept that
drives this is the "Certification Practice Statement," or CPS. 1
This term originated in the American Bar Association Digital Signature Guidelines (http://www.abanet.org/scitech/
home.html). Another source of information is RFC 2527.
I Chapter 7
184 7.4 Certification practice statement
This document presents a framework to assist the writers of certificate
policies or certification practice statements for certification authorities and
public key infrastructures. In particular, the framework provides a com-
prehensive list of topics that potentially (at the writer's discretion) need
to be covered in a certificate policy definition or a certification practice
A CPS is valuable for most CAs. You can see the importance of having
one for a public CA. Using the CPS from a public CA, your company
could review the practices and then determine if you "trust" the CA to
manage your PKI. The CPS should also dictate legal responsibilities, roles,
policies, and procedures. Following is a list of what should be covered in
most any CPS:
2. What is a certification practice statement? (or, What is a CPS in
3. Legal obligations (the company and CAs)
4. Detailed practice specifications
6. Confidence and reliability (including nonrepudiation)
7. Statement regarding trustworthiness
8. Statement regarding audits
Statement regarding root key certificate
Statement regarding identification and authentication practices
Statement regarding certificate revocation
Management of the certificate life cycle
Let's look at each item.
The introduction should include the scope and basic responsibilities of the