When the number of enrolled entities is increasing, to scale while keeping manageability, it is necessary to introduce hierarchical levels for the certification authority functions. The role and functions of the CA become distributed to multiple sub-CAs.
Role and Functions
The roles and functions of a sub-CA are exactly the same as the ones of a CA:
■ Act as trusted authority
■ Verify identities of requesters
■ Issue certificates
The only difference is that although a CA can be seen as an autonomous, or top of struc- ture, PKI component, a sub-CA is always a child of a CA.
Hierarchies
Hierarchical PKIs are created to answer scalability and management challenges. They use a tree model with the root CA at the top and sub-CAs at intermediate levels. The top CA (also called the root CA) stays the central point of aggregation; however, it can now dele- gate some of its responsibilities to the subordinate CAs so that scalability is restored. Figure 2-1 shows a typical enterprise hierarchical PKI. The central security department owns and operates the root CA. It then creates a subordinate CA for each department in the company that will be operated by the department itself. Now each department can use it according to its needs: The network department uses it to enroll network devices, and the computer department generates certificates for servers and user laptops. It was mentioned previously that one of the roles of the CA is to establish the trust rela- tionship between two enrolled entities. What’s happening now within a hierarchical PKI? Now look deeper at the example.
Imagine that you would like to connect a user laptop through a VPN service using cer- tificates for authentication. Focus on the trust relationships, not on the technical details of the VPN.
The following components are part of the infrastructure:
■ Root CA: CA at the top of the hierarchy.
ptg
Chapter 2: Understanding PKI Building Blocks 25
Root CA
SubCA-network SubCA-computer
Router Laptop
Figure 2-1 PKI Hierarchy Example
The laptop certificate has been issued by SubCA-computers; therefore, the laptop trusts the SubCA-computers sub-CA. But SubCA-computers has been issued by the Root CA, so the laptop also trusts the Root CA.
The router certificate has been issued by SubCA-network; therefore the router trusts the SubCA-network sub-CA. But the SubCA-network has been issued by the Root CA, so the router also trusts the Root CA.
The common point between the two trust branches is the Root CA, which is trusted by both the laptop and the router. As a result, all other children of Root CA will be trusted by the router and laptop. Therefore, using the entire chain back to the common point (Root CA in this case), the laptop can verify and potentially trust the certificate installed on the router, using the intermediate step of verifying the SubCA-network certificate before trusting it. The same is valid in the reverse direction. (The router can trust the cer- tificate installed on the laptop.)
You are not limited to a single level of subordination: It is quite common to have several layers of sub-CAs, as shown in Figure 2-2.
In addition, the different branches do not have to be symmetric in any way: Both the number of horizontal and vertical levels can be different in each branch. Another good reason to build your PKI using hierarchical sub-CAs is that it enables you to put the root CA offline, hence increasing its security. If a sub-CA is compromised, only the underly- ing subtree would be impacted. A good approach is therefore to align your PKI topology to the administrative responsibility of your organization.
■ SubCA-computers: Sub-CA administered by the computer department
■ Laptop: Certificate installed (with the corresponding key pair) on the laptop
ptg Country Root CA State subCA: State-A City subsubCA: City-A Citizens State subCA: State-B National IT SubCA City subsubCA: City-B Citizens City subsubCA: City-C Citizens City subsubCA: City-D Router Laptop Citizens
Figure 2-2 PKI Hierarchy with Multiple Levels
Registration Authority (RA)
A Registration Authority (RA) is also a child in the hierarchy of a CA (or sub-CA); how- ever, its roles and functions are more limited.
Role and Functions
Although a sub-CA has the same roles, responsibilities, and functions as a root CA, an RA receives delegation only for the administrative tasks:
■ Receive certificate requests
■ Verify requester identity
After those have been performed, the RA contacts its parent CA (or sub-CA) to have the certificate created and issued. The new certificate will then be returned to the RA first, that then handles the final distribution to the requester. Figure 2-3 shows the enrollment process involving an RA.
An RA is only a frontend to the actual CA. Except to authenticate the transaction with the RA, the requester does not need to establish a trust relationship with the RA because the registration authority does not actually sign any certificate. That means that several RAs can work for the same CA, or that the RA can be replaced easily by another one. The main purpose of the RA is to reduce the load on the CA by delegating some of the admin- istrative tasks: You can see the RA as the front-facing agent, working for the CA.
ptg Root CA 3 2 Cert Req. Registration Authority Requester 4 1 Cert Req. • • • •
Figure 2-3 Enrollment Using an RA
Chapter 2: Understanding PKI Building Blocks 27
A trust relationship does exist between the RA and the CA because the CA must rely on the requester identity verification performed by the RA on its behalf.