Get this Security+ CertiGuide for your own computer.
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Also available: 300-question Security+ practice test!
Get It Here!

Custom Search







Table Of Contents  CertiGuide to Security+
 9  Chapter 4:  Basics of Cryptography (Domain 4.0; 15%)
      9  4.3  PKI (Public Key Infrastructure)

Previous Topic/Section
4.3.2  Revocation
Previous Page
Pages in Current Topic/Section
1
Next Page
Pop Quiz 4.1
Next Topic/Section

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 CA’s as “trustworthy” through participation in an association such as tScheme, which functions as a sort of Better Business Bureau for CA’s, approving CA’s, handling complaints, etc.

Different trust models exist to create a “chain of trust399”, which indicate how trust in one entity may affect one’s 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 don’t have firsthand knowledge of those people. Conversely, if you don’t 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 CA’s 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 CA’s 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.

[spacer]Policy Trust List Model

The Policy Trust List Model restricts access based on the policy under which the certificate is issued. This was recommended in X.509 V3 Certificate RFC, but has not been adapted, to date.

The Policy Trust List Model with OU is similar to Policy Trust but using Organizational Units for policy.

In the Cross-Certificate Model, each CA creates a certificate for the CA that has been confirmed to have an equivalent strength. There is only one root public key, however, the key is the local CA not the Root CA. The idea behind this is that each CA is in charge of determining who it trusts.

The Bridge CA is a trust bridge that is built with cross-certificate pairs; it is an emerging concept.



 __________________

399. http://www.e-government.govt.nz/docs/see-pki-paper-4/chapter3.html

400. http://www.hackinglinuxexposed.com/articles/20040414.html

Previous Topic/Section
4.3.2  Revocation
Previous Page
Pages in Current Topic/Section
1
Next Page
Pop Quiz 4.1
Next Topic/Section

If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.