Although the registration function can be implemented directly with the CA component, it sometimes makes sense to off-load the registration function to a separate component referred to as a Registration Authority (RA). For example, as the number of end entities in a given PKI domain increases and/or the end entities are widely dispersed geographically, the notion of centralized registration becomes problematic. Judicious deployment of multiple RAs (sometimes referred to as Local Registration Authorities, or LRAs) helps solve this problem. The primary purpose of the RA is to off- load certain functions from the CA to enhance scalability and decrease operational costs.
Although the functions implemented by the RA may vary, it can be designed to support one or more of the following:
Establish and confirm the identity of an individual as part of the initialization process. (For example, the RA might verify the identify of an individual through a combination of physical presence and associated identification such as a driver's license, employee badge with picture, or a passport.)
Distribute shared secrets to end users for subsequent authentication during an on-line initialization process.
Initiate the certification process with a CA on behalf of individual end-users (including the registration of certain attributes to be associated with the end user).
Generate keying material on behalf of an end user.
Perform certain key/certificate life-cycle management functions, such as to initiate a revocation request or a key recovery operation on behalf of an end entity.
Regardless of the set of functions implemented in the RA, it should be noted that a RA is never allowed to issue certificates or CRLs. These functions rest solely with the CA.
End-entity registration requirements may vary significantly from one domain to another, between distinct applications in a given domain, or between distinct contexts in a given application in a given domain. (Chapter 7 discusses specific registration issues and procedures further.)5