For the most part, there are two basic systems in current use for issuing certificates: a closed system (private hierarchy) and an open system (public hierarchy).
The closed system will have a certificate authority as part of one entity. In theory, you could have several organizations and organizational units. Also, in theory, you could distribute the responsibility of supporting and maintaining those organization certifiers. With a closed system, your company is in the business of being a CA. There are many reasons to do this. One situation might be that you have several bank branches and you want to encrypt data between each branch; in that case, you would be the CA and issue the certificates. In reality, you would place the certifier under lock and key and may even put a guard (an actual person) in charge of handing out the key via a very controlled mechanism. You might have a multinational company with several CAs, or in the same example, you might have a multinational company with only one CA.
You are the CA, so you control the certificates.
You also control the binding of the user to the certificate; in theory, you could physically look at each person and then issue the certificate.
You manage the certificate structure, naming, validation, and expiration.
You have control of your own destiny.
No one else can use certificates or impersonate yours (hang on for a second on this one).
You are the CA, so you control the certificates. Why is this a disadvantage? Now you need a support structure to accommodate this mess.
You will need the proper software and/or hardware to implement the solution.
You will need to have a support staff to manage the certificates. Remember that certificates expire. Guess what? People may need to change their name (such as in the case of marriages). You will need to figure that out too.
How will you handle issues about people quitting? (CRL later)
Now, in theory, if you are your own CA, then you control that CA and no one else will have it. This is true, but it can also be very false. The issue is that in order to create a certificate, someone or something will need to "touch" the CA i.e., act as a certifier. The CA certifier is a physical entity that exists somewhere (in a document, file, hard drive, floppy, etc.). As a result, you can lose control of the CA. Even if the CA file has a password, you can still lose control of it. Administrators do quit and move on to other companies. If you do become your own CA, then work with your software vendor and determine methods to protect the CA certificate.
Now let's talk about open public systems. A public system is one in which an individual or a company can go for certificates. The public CA is typically an independent entity that issues certificates. In some cases, this CA is known as a third-party CA.
Even though you are not the CA, you can set up a service via a public CA to provide certificates on your behalf. You still control the certificates, but you do not control the root certificate.
Again, you can control the binding of the user to the certificate; in theory, you could physically look at each person and then issue the certificate. (This does not scale very well.) Many vendors have automated systems that can register users and issue certificates. (The automated systems scale very well.)
By using a service from a public CA, you manage the certificate structure, naming, validation, and expiration, but as we mentioned, you cannot control the root certificate.
Overall, the cost of an open public system can be less expensive than an open system, because an existing infrastructure and people support the system.
Reliability of infrastructure is a benefit. Most "known" public systems have a proven track record. We have never heard of a case where a public infrastructure had an outage.
In this case, you would not be able to own the root of the certificate. So in theory, someone at the service could create an unauthorized certificate. Here we need to balance some of these issues. We would hope that if your company does any business with any type of service provider, you would look at the following: service levels; legal liability; legal responsibility; and code of ethics.
Each of these issues will need to be reviewed and agreed on. Also, define the consequences for breaches of any of these issues. In the end, you should have a service provider agreement. These agreements define the rights and obligations of the service provider and the company requesting or purchasing the services. The moral of the story: Consult your legal department before using a public CA.
Which is better, a closed private system or a public system? The "consulting" answer is, "It depends." You know the saying, "Ready, aim, fire"? Please don't select the technology before understanding the business problem that you are trying to solve. Following are the issues that you will need to review before making your decision:
What are the business requirements? (As always, what is the need, what is being supported?)
What are the user requirements?
What is the cost?
What is the cost of doing nothing? (This is very important.)
Are there other options? Is PKI really the answer?
What are the support requirements?
What user issues must be addressed (for example, number of users, location of users, user types office, roaming, remote and bandwidth)?
Based on the business requirements, can you use a public service provider?
What options do they provide to manage your users?
What are the training requirements (for example, users, administrators, and help desk)?
Who owns this project? Is there a person who can make decisions if the project gets stalled?
What is the cost if you need to be your own CA?
What happens if the root certificate CA is compromised? (This question needs to be asked for both public and private systems.)
Based on your decision, what is the per-user cost?
Can the technology be used on other applications or business services?
Will this be offered to the general public? What services are available for the general public from a public CA?
What service levels are required? (This question is for both public and private CAs.)
Depending on the solution, what process will be used to bind the user to the certificate?
Now you have an idea of how important the CA is. If the CA certificates fall into the hands of the "bad dudes," then they can create certificates that can impersonate a valid member of your organization. With that said, let's delve into what it really means to you and what the true risks are.
Let's start with an example, Figure 7.4, which shows an extract of a certificate taken from a browser. (Note: Serial numbers are 128 bits in length. The serial number shown in Figure 7.4 is not 128 bits.)
In Figure 7.4, the CA is "The Big Cert CA for BUBBA." Let's assume that a "bad dude" has obtained a copy of this cert. What can he do with it? One big issue is access to a directory source that would house public keys. Let's also make the assumption that it is available in read mode. Following are some things the bad dude could do:
First, he could create a bogus user with the stolen CA.
Then, with access to the public directory, he could send encrypted messages to those users, requesting certain actions, or that items be returned to him via e-mail.
He could also sign messages. There is a hitch in this one: If the targeted user's software validates the signature via the public directory, this could generate an alert condition to the targeted user. Therefore, signing may not work. But guess what? You could send a message to a remote user that may not have direct access to the public directory. Again, if the user were trained, he or she would know to check the fingerprint. Using the fingerprint, you can check for a signed message from the "real" Bubba instead of the "fake" Bubba. The targeted user could just call the real Bubba and say, "I just got this request from you for a billion dollars that you want sent to Cuba. Please read me your fingerprint for validation of this transaction."
The bad dude could possibly authenticate into your web servers with illegally obtained certificates. This is easily done if all you do is check 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 http://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.)
Don't lose control of your CA(s).
Don't grant write access to your directory resource, or, at least, control it and audit it.