Trust models involving multiple certification authorities

Many alternatives exist for organizing trust relationships between certification authorities (CAs) in public-key systems involving multiple CAs. These are called trust models or certification topologies, and are logically distinct from (although possibly coincident with) communications models. (In particular, a communications link does not imply a trust relationship.) Trust relationships between CAs determine how certificates issued by one CA may be utilized or verified by entities certified by distinct CAs (in other domains). Before discussing various trust models, certificate chains are first introduced.

(i) Certificate chains and certification paths

Public-key certificates provide a means for obtaining authenticated public keys, provided the verifier has a trusted verification public key of the CA which signed the certificate. In the case of multiple certification authorities, a verifier may wish to obtain an authentic public key by verifying a certificate signed by a CA other than one for which it (originally) possesses a trusted public key. In this case, the verifier may still do so provided a chain of certificates can be constructed which corresponds to an unbroken chain of trust from the CA public key which the verifier does trust, to the public key it wishes to obtain trust in.

Certificate chains correspond to directed paths in the graphical representation of a CA trust model (see Figure 13.9). The goal is to find a sequence of certificates corresponding to a directed path (certification path) starting at the node corresponding to the CA whose public key a verifier trusts a priori, and ending at the CA which has signed the certificate of the public key to be verified.

13.41 Example (illustration of certificate chain) Consider Figure 13.9(e) on page 574. Suppose an entity A in possession of the public key P5 of C'Ar> wishes to verify the certificate of an entity В signed by САЛ, and thereby obtain trust in Рц. A directed path (СА$, САЛ. СА$) exists. Let CAr, { САЛ} denote a certificate signed by CAr, binding the name CA4 to the pubhc key P4. Then the certificate chain (GAr,{CA4}, CA4{CA4}), along with initial tmst in Pr,, allows A to verify the signature on 674 5 { CA4} to extract a trusted copy of P4, use P4 to verify the signature on СА4{САз} to extract a trusted copy of P3> and then use P3 to verify the authenticity of (the certificate containing) Pp-

Given an initial trusted public key and a certificate to be verified, if a certificate chain is not provided to the verifier, a method is required to find (build) the appropriate chain from publicly available data, prior to actual cryptographic chain verification. This non- cryptograpliic task resembles that of routing in standard communications networks.

13.42 Example (building certificate chains using cross-certificate pairs) One search technique for finding the certification path given in Example 13.41 involves cross-certificate pans. In a public directory, in the directory entry for each CA X, for every CA Y that either cross-certifies X or that X cross-certifies, store the certificate pair (forward, reverse) = (CAy{ CAx}, CAx {CAy}), called a cross-certificate pair. Here notation is as in Example 13.41, the pair consists of the forward and reverse certificates of CAx (see page 575), and at least one of the two certificates is present. In the absence of more advanced techniques or routing tables, any existent certification path could be found by depth-first or breadth-first search of the reverse certificates in cross-certificate pans starting at the CA whose public key the verifier possesses initially. □

As part of signature verification with certificate chains, verification of cross-certificates requires checking they themselves have not been revoked (see §13.6.3).

(ii) Trust with separate domains

Figure 13.9 illustrates a number of possible trust models for certification, which are discussed below, beginning with the case of separated domains.

Simple public-key systems involve a single certification authority (CA). Larger systems involve two or more CAs. In this case, a trust relationship between CAs must be specified in order for users under different CAs to interoperate cryptographically. By default, two distinct CAs define separate security domains as in Figure 13.9(a), with no trust relationship between domains. Users in one domain are unable to verify the authenticity of certificates originating in a separate domain.

(iii) Strict hierarchical trust model

The first solution to the lack of cryptographic interoperability between separate domains is the idea of a strict hierarchy, illustrated by Figure 13.9(b). Each entity starts with the pubhc key of the root node - e.g., entity E{1) is now given CAr, ’s public key at registration, rather than that of CA as in figure (a). This model is called the rooted chain model, as all trust chains begin at the root. It is a centralized trust model.

Several such rooted trees, each being a strict hierarchy, may be combined in a trust model supporting multiple rooted trees as in Figure 13.9(c). In this case, a cross-certificate is allowed between the roots of the trees, illustrated by a bi-directional arrow between roots. The arrow directed from CAx to CAy denotes a certificate for the pubhc key of CAy created by CAx • This allows users in the tree under CAx to obtain trust in certificates under CAy through certificate chains which start at CAx and cross over to CAy.

hi the strict hierarchical model, all entities are effectively in a single domain (defined by the root). Despite the fact that, for example, CA signs the public-key certificate of

Trust models for certification

Figure 13.9: Trust models for certification.

El" trusts the root {CAE) directly but not CA. tnists CA only indirectly through the root. Potential drawbacks of this model include:

  • 1. all trust in the system is dependent on the root key
  • 2. certificate chains are required even for two entities under the same CA
  • 3. certificate chains become long in deep hierarchies
  • 4. a more natural model in some organizations is for trust to begin at a local node (the parent CA) rather than a distant node (the root).
  • (iv) Reverse certificates and the general digraph trust model

A more general hierarchical model, a hierarchy with reverse certificates, is illustrated in Figure 13.9(d). This resembles the strict hierarchy of Figure 13.9(b), but now each CA lower in the hierarchy also creates certificates certifying the public keys of its directly superior (parent) CA. Two types of certificates may then be distinguished in a hierarchy:

  • 1. forward certificate. A forward certificate (relative to CAx) is created by the CA directly above CAx signing the public key of CAx, and illustrated in the hierarchy by a downward arrow towards CAx-
  • 2. reverse certificate. A reverse certificate (relative to CAx) is created by CAx signing the public key of its immediately superior CA, and illustrated in the hierarchy by an upward arrow originating from CAx-

In this model, each entity starts not with the public key of the root, but rather with the public key of the CA which created its own certificate, i.e., its local CA (parent). All trust chains now begin at an entity’s local CA. The shortest trust chain from any entity A to any other entity В is now the path in the tree which travels upwards from A to the least-common- ancestor of A and B, and downwards from that node on to В.

A drawback of the hierarchical model with reverse certificates is that long certificate chains may arise between entities which are under distinct CAs even if these entities communicate frequently (e.g., consider entities under CA and 6’A] in Figure 13.9(d). This situation can be ameliorated by allowing CA to cross-certify CA4 directly, even though this edge is not in the hierarchy. This is the most general model, the directed graph (digraph) trust model as illustrated in Figure 13.9(e). The analogy to graph theory is as follows: CAs are represented by nodes or vertices in a graph, and trust relationships by directed edges. (The complete graph on n vertices, with a directed edge from each vertex to every other, corresponds to complete trust, with each CA cross-certifying every other directly.)

The digraph model is a distributed trust model. There is no central node or root, any CA may cross-certify any other, and each user-entity begins with the trusted public key of its local CA. The concept of a hierarchy remains useful as a reference for organizing trust relationships. This model may be used to implement the other trust models discussed above, including strict hierarchies if variation is permitted in the trusted public key(s) end-user entities are provided with initially.

  • 13.43 Remark (assigning end-users to CAs) In hierarchical models, one option is to specify that only CAs at the lowest level certify end-users, while internal CAs serve (only) to cross- certify other CAs. In the general digraph model, where all CAs are considered equal, it is more natural to allow every' CA to certify end-users.
  • (v) Constraints in trust models

Trust obtained through certificate chains requires successful verification of each certificate forming a link in the chain. Once a CA (CAx) cross-certifies the public key of another CA (CAy), in the absence of additional constraints, this trust extended by CAx is transitively granted to all authorities which may be reached by certificate chains originating from

CAy- To limit the scope of trust extended by a single cross-certificate, a CA may impose constraints on cross-certificates it signs. Such constraints would be enforced during verification of certificate chains, and might be recorded explicitly through additional certificate fields indicating specific policies, or through attribute certificates (§13.4.2). Examples of simple constraints on cross-certificates include:

  • 1. limiting chain length. A constraint may be imposed on the length of the certificate chain which may follow the cross-certificate in question. For example, a CA may limit the extent of trust granted to CAs which it directly cross-certifies by specifying, in all cross-certificates it signs, that that certificate must be the last CA-certificate in any trust chain.
  • 2. limiting the set of valid domains. A set of CAs (or domain names) may be specified as valid with respect to a given cross-certificate. All CAs in a certificate chain following the cross-certificate in question may be required to belong to this set.

Certification may also be earned out relative to a certification policy specifying the conditions under which certification took place, including e.g., the type of authentication carried out on the certificate subject before certifying a key, and the method used to guarantee unique subject names in certificates.

 
Source
< Prev   CONTENTS   Source   Next >