Roles in a public key infrastructure

Author Uwe GradeneggerPosted on Categories BasicsTags , , ,

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

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

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:

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:

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.

Related links:

External sources

References

  • Security without Obscurity: A Guide to PKI Operations. Jeff Stapleton and W. Clay Epstein, 2016. ISBN-10: 036765864X
en_USEnglish
de_DEDeutsch en_USEnglish