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
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
certificate
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)
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
certificate)
CA public key with certificate should be distributed in a secure, out-of-band
fashion
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
key
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
architecture
For pure multi-level hierarchy the result may be called a full-treed
architecture
Hybrid arises when deploying to existing deployment
Peer CAs
Intermediate CAs
End-entities
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
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
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
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
browsers
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
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
co-worker)
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