Trust Model


Which certificate should you trust

How can trust be established

How can trust be controlled and limit

There are four trust model in general: Strict hierarchy of CAs, distributed
trust architecture, Web model, and user-centric trust

Org chart organization of trust model almost never works

Trust Overview

X.509 Specifiication: Entity "A" trusts entity "B" when "A" assumes that "B"
will behave exactly as "A" expects

So, trust deal with assumptions, expectations, and behavior (apply to human
will be difficult)

In PKI, an end-entity trusts a CA when the end-entity assumes that the CA will
establish and maintain an accurate binding of attributes to a public key

In other words, the CA represent the identity of an entity to whom it issues a

Trust public key: a public key is said to be "trusted" by Richard when Richard
is convinced that the public and private key pair validly belongs only to the
named entity (in the certificate)

Strict Hierarchy of Certificate Authorities

Inverted tree with the root at the top

X'mas tree like

root CA is the root of trust, or "trust anchor"

Follow by subordinate CAs or intermediate CAs

Leaves are end-entities or simply end-users

The root is not the starting point of a network, communication, subordination
archiecture, it is the starting point of trust

Strictly speaking, Root CA should only certify intermediate CAs following it.
But this rule are normally relax in implementation

Root CA

Zero or more levels of intermediate CA

Non-CA end-entities

Figure 1.

Each entity in the hierarchy (both intermediate CA and non-CA leaf) must be
supplied with a copy of the root CA's public key (by using the corresponding

CA public key with certificate should be distributed in a secure, out-of-band

Multi-level strict hierarchy: end-entities are certified (issued certificates)
by CA immediately above them, but their trust anchor is a different CA

Shadow hierarchies contains no subordinate CAs, the root and the certificate
issuer are identical for all end-entites: Trusted issuer hierarchies

Use chain up to verify end-entity public key CA->CA1->CA2->End-entity public

Distributed Trust Architecture

Single CA among the whole community is very difficult to achieve

DTA distributes trust among two or more (probably many) CAs

For pure shallow, trusted-issuer hierarchies, it results in a fully-peered

For pure multi-level hierarchy the result may be called a full-treed

Hybrid arises when deploying to existing deployment

Peer CAs

Intermediate CAs


Figure 2

The process of interconnecting the peer root CAs is commonly known as
cross-certification (some people called it PKI networking)

Two ways of doing cross-certification: Mesh and Hub-and-spoke

Mesh configuration

All root CAs potentially cross-certified with each other

Fully connected: full mesh (need n*n cross-certification agreements to be
established whenthere are n root CAs)

Partial mesh vs partial mesh hybrid distributed trust architecture

Hub-and-Spoke configuration

Each root CA cross certifies with a single central CA

This central CA facilitate such interconnection

Called hub CA with spokes out to the various root CAs

Also called bridge CA

Require n cross-certification for n root CAs

Hub-and-spoke is not a strict hierarchy

End-entities do not hold a hub CA key

Entities only hold a trusted copy of the key of a CA, through certificate path
processing, obtains the key of the hub CA, then a CA in another domain, and
finally the key of the target end-entity in that domain

Web Model

Used by WWW

Number of CA public keys are pre-installed in a browser

Keys in the browser will be the initial set of trusted source for verification

For practical purposes, each browser vendor has its own root, and it certifies
the "root" CAs that are embedded in the browser

CAs is not only "certified" but also physically embedded in software releases
as a means of effecting the secure binding between a CA name and its key

Convenience and simple interoperability

Potentially short falls:

"Bad" root CA might be there with the pre-installed public key

Impersonation can succeed since a user must just trust all the root
certificates in the browser ... in fact, only a few CA would be recognize by
the user (Similar problem would exist in other model)

If a CA becomes bad or there is a root private / public key compromised, there
is no way to discontinuethe use of the key in millions and millions of

No opportunity for any kind of legal agreement

No contract to be put in place between a user and the CAs

CA does not know who its replying parties are

Use cannot be expected to be aware enough of the potential issues to contact
the CA

User-Centric Trust

Build a user trust network

Each user directly and totally responsible for deciding which certificate to
reply on and which to reject

   "Friends and Family" network
    Richard's mother <-> Richard <-> Richard's co-worker <-> Richard's boss 
                        <-> My (Richard's friend)
                        <-> Carmen (Richard's wife) <-> Michelle (Carmen's
    Figure 3


Pretty Good Privacy (PGP) uses this trust model

PGP, users build web of trust

Accept or reject based on this trust model

Large community cannot use user model

There is no control on the root level