Architectural Model and PKI Entities

Figure 1 shows a simplified view of the architectural model assumed by the PKI specification. This model is analogous to the credit card infrastructure. Even though the data is encrypted differently, the ways in which the entities in the two structures interact with each other are conceptually similar. Each PKI entity is like an entity in the credit card infrastructure.

 
Figure 1: PKI Entities and Their Relationships

We’ll now define the following PKI entities:

• End Entity User of PKI certificates and/or end-user system that is the subject of a certificate. Like a credit card reader in a retail store or restaurant, it reads a user certificate (credit card number) and queries the credit card company for the card holder’s legitimacy and credit limits.
• Certification Authority (CA) A system that issues PKI certificates. Think of credit card application processing, which checks an applicant’s credit history and issues a credit card.
• Registration Authority (RA) An optional system to which a CA delegates certain management functions.
• CRL issuer An optional system to which a CA delegates the publication of certificate revocation lists. This entity manages the equivalent of a stolen or lost credit card report and distributes certificate revocation information.
• Repository A system or collection of distributed systems that stores certificates and CRLs and that serves as a means of distributing these certificates and CRLs to end entities. An analogy would be a credit card holder database.

Operational protocols deliver certificates and CRLs (or status information) to client systems that use certificates. A variety of different ways to deliver certificates and CRLs are needed, including distribution procedures based on Lightweight Directory Access Protocol (LDAP), HTTP, File Transfer Protocol (FTP), and X.500.

Management protocols support online interactions between PKI user and management entities. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs that cross-certify each other. The set of functions potentially needing to be supported by management protocols include user registration, client initialization, user certification, periodic key pair update, revocation request, and cross-certification.