Roles in a public key infrastructure

Understanding the roles involved is essential for designing a public key infrastructure.

The term "public key infrastructure" encompasses much more than the technical components and is often misleadingly used.

In summary, a public key infrastructure is both an authentication technology and the totality of all the components involved.

For an introduction to the topic, see the article "Public Key Infrastructures (PKI) basics„.

Core roles in a public key infrastructure

Certification Authority

(engl. "Certification Authority", CA)

The certificate authority (one or more) is the core role in a public key infrastructure. Its tasks include:

Validate digital identities by issuing digital certificates to end entities (and, where applicable, certificate authorities).
Providing the data (usually certificate revocation lists and certificate serial numbers) for the validation authority.
Secure custody and use of the private key material of the certification authority systems.
Logging of performed cryprographic operations, especially certificate issuances.
If not explicitly present, it also assumes the tasks of the registration office.

Registration Office

(engl. "Registration Authority", RA)

The registration authority processes incoming certificate requests. If available, it represents the "frontend" vis-à-vis the applicants.

Their duties include:

Identification of the applicants (end entities) of certificate requests.
Decision on the issuance of a certificate or the rejection of certificate applications.
Enforce policies regarding certificate issuances.
Acceptance and processing of certificate revocation requests.

For this purpose, the RA role usually provides technical interfaces such as:

Simple Certificate Management Protocol (SCEP) (RFC 8894)
Enrollment over Secure Transport (EST) (RFC 7030)
Automatic Certificate Management Environment (ACME) (RFC 8555)
Certificate Management Protocol (CMP) (RFC 4210)
Certificate Enrollment Web Services (MS-XCEP/MS-WSTEP)
Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)
Representational State Transfer (REST)
User Self Service Portal (Web Interface)
E-mail box

A registration office can be set up centrally or decentrally. For example, decentralized company locations may have employees who perform the role of registrar. In the Microsoft world, for example, this would be the Certificate Enrollment Agent.

The Microsoft Active Directory Certificate Service violates this principle in that CA and RA are mapped to the same server-side role. The other way around, one could also argue more gently, that this clean separation of roles is not provided for by the concept.

In the Microsoft PKI world, it is often given over to the Network Device Registration Service (NDES) the function of a registration authority. Strictly speaking, however, the product does not fulfill the defined criteria; it is more of a protocol converter (SCEP to DCOM).

Renowned crypto expert Bruce Schneier is of the opinionthat separation of RA and CA is less certain than if both roles were exercised in Union.

Validation body

(English "Validation Authority", "VA")

The validation authority provides all the information required to validate digital certificates. This includes:

Brevocation list distribution points Certificate Revocation List Distribution Point (CDP or CRLDP)
Authority Information Access (AIA)
Optional Online Certificate Status Protocol (OCSP) (RFC 6960)
Optional Server-Based Certificate Validation Protocol (SCVP) (RFC 5055)

End entities

(engl. "End entity")

Alternative terms can be:

Applicant (English "Enrollee")
Certificate owner
Subscriber

These are the entities whose identities are confirmed by digital certificates. They can be persons, machines or abstract entities (e.g., a service account or a DNS name behind which several physical machines are located. Strictly speaking, in most cases it is not persons but their user accounts that are identified).

Trusting party

(English "Relying Party")

These are the entities that verify the certificates issued by the CA to the end entity, i.e., whose operation is based on a trust relationship with the certification authority.

Common operations performed here include:

Establishing a chain of trust with a root certification authority (CA).
Depending on the application, also direct establishment of an explicit position of trust with one or more issuing certification authorities.
Checking the validity period of certificates.
Checking the revocation status of certificates.
Verify the intended use of certificates.
Checking the conformity of certificates to defined guidelines (e.g. violation of certificate guidelines, the Path length or Name restrictions).

Important to understand here is that the scope of the certificate check depends on the particular application. For example most modern browsers do not check the revocation status of certificatesApple systems have long had no Name restrictions supported.

Other roles

Policy Authority

Policy Authority (PA)

This is a role in the company whose task is to define and maintain the necessary regulatory documents, such as the Certificate Policy (CP, RFC 3647) and their coordination with the stakeholders.

Duties of a policy authority include:

Create and extend the CP.
Deciding on operations with significant impact (e.g. revocation of a certification authority certificate)

As a rule, the PA is a body made up of a wide variety of stakeholders and knowledge carriers in the company.

Timestamp authority

Time Stamping Authority (TSA)

An optional role whose task is to provide attested timestamps. This is used, for example, in the context of Code- and document signatures are required.