| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4.3.3 Trust Models Trust is the concept of confident reliance on an entity (person or organization). In the PKI world, it usually refers to the relationship between the user of a certificate, and the CA that issued that certificate. It revolves around the question, Does the user believe that certificates issued by the CA are valid? If so, normally the user will accept any certificates generated by that CA. If not, normally the user will not accept any certificates generated by that CA. Initiatives are under way today to set up a model for additional certification of CAs as trustworthy through participation in an association such as tScheme, which functions as a sort of Better Business Bureau for CAs, approving CAs, handling complaints, etc. Different trust models exist to create a chain of trust399, which indicate how trust in one entity may affect ones trust in another entity. For example, if you have a lot of faith in the judgment of a business associate, you may opt to trust anyone he trusts, even if you dont have firsthand knowledge of those people. Conversely, if you dont have much faith in his judgment, you may prefer NOT to automatically trust anyone he puts his stamp of approval on. Trust models describe these trust relationships. A Web-of-Trust is the simplest model. Each user creates and signs certificates for the people they know. There is no central authority. Trust decisions are made independently for each certificate user. (This is the model used by PGP). A series of articles on how PGP can be utilized can be found in the footnote400. The specific link points to Part 5, and just look in the upper right corner for previous installments. In the Single CA Model each person (or document, software, business or computer) is given a public key out-of-band (this means, the key is not sent the same way a message is). A single point of contact is used to check for revocation of a certificate. Generally, the single CA is trusted (it is often internal to the organization), and all certificates issued by it are trusted. The Hierarchical Model involves Multiple CAs with a Root CA at the top, using lower level CAs whose public key certificates are signed by the Root CA, for improved scalability. (The Root CAs certificate is signed by itself). The hierarchical model provides higher overall assurance than other models, however it may not work in a peer-to-peer role due to its reliance on a single root authority. It performs well in a large hierarchical environment like the military. The Browser Trust-List Model is sometimes called the CA list. Each user has a list of the public keys for all the CAs the user trusts. The good news is a different CA can be used for each application. The less than stellar news is there is no way to discern the strength of the PKI class the granularity is on the level of the CA only, not on the types of certificates it may issue. As we mentioned earlier, you can often opt for different levels of identity verification, and thus different levels of authentication, when purchasing a certificate. For example, VeriSign has 4 different classes, with different levels of identity verification. Not all certificates by the same CA are created equal.
__________________ 399. http://www.e-government.govt.nz/docs/see-pki-paper-4/chapter3.html 400. http://www.hackinglinuxexposed.com/articles/20040414.html
Home - Table Of Contents - Contact Us CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com Version 1.0 - Version Date: November 15, 2004 Adapted with permission from a work created by Tcat Houser et al. CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||