Trust model

Background

In typical Web PKI, a set of independent Certificate Authorities (CAs) are trusted by millions of clients across the world to assert identities (such as domain names) in certificates. As part of their responsibilities, they commit to only issuing certificates where they have independently validated the identity in that certificate. For example, a CA would typically need to verify that somebody requesting a certificate for the domain name example.com actually controls the said domain before they issue them a certificate. Since those CAs can issue certificates for millions of customers where they may not have an existing direct relationship, they are limited to asserting identities that are publicly verifiable, with a well-defined verification process that is consistently applied.

Unlike Web PKI, private PKI often involves a smaller CA hierarchy which is directly managed by an organization, where certificates are only sent to clients that inherently trust the organization to have the appropriate controls (for example, machines owned by that organization). Since the CA admins often have their own ways of validating identities for which they issue certificates (for example, issuing certificates to their own employees), they are not limited by the same requirements as Web PKI. This flexibility is one of the main advantages of private PKI over Web PKI, and it enables new use-cases such as securing internal websites with short domain names without requiring unique ownership of those names, or encoding alternative identities formats (such as SPIFFE IDs) into a certificate.

Certificate Authority Service aims to simplify the process of managing private PKI by allowing users to easily create and manage CAs. As such, CA Service does not currently define how identities in certificates must be validated. Instead, it allows the CA admin to choose a limited set of users who can issue certificates, and assumes that any requests coming from those users are trustworthy.

IAM Policies

IAM policies are used to limit who is permitted to perform certain operations on a CA, such as issuing a certificate, revoking a certificate, updating its issuance policy, and more. For example, if the Certificate Requester role is bound to the user alice@joonix.net on a CA, then that user will be able to request certificates from the same CA.

See Configuring IAM policies to learn how to use Identity and Access Management to control access to CA Service.

Issuance Policies

In addition to IAM policies, a CA admin can attach an Issuance Policy to a CA that defines restrictions on the kinds of certificates that the CA will issue. An Issuance Policy may define restrictions on certificate subjects, subject alternative names (SANs), certificate lifetimes, certificate request modes and reusable config values. In addition, the policy may contain a set of reusable config values that will be applied to all incoming certificate requests.

Issuance policies are a good way to add limitations on an entire CA. For example, a policy may enforce that all issued certificates have O=My organization in their subject, or that all DNS names end with .my-org-domain.com, or that only Server TLS certificates may be issued (but not code signing certs).

See Using an Issuance Policy to learn how to configure an Issuance Policy on a CA.

Limitations

Since Issuance Policies are applied to all certificate requests on the given CA, they are not a suitable way to define caller-specific policies. For example, an Issuance Policy cannot be used to put different constraints on certificates issued by alice@joonix.net than those issued by bob@joonix.net. To do that, consider adding a proxy service to enforce these limitations before forwarding the certificate issuance request to CA Service. Alternatively, you may consider using dedicated CAs for certificate requesters in trust boundaries.

Over time, CA Service may add support for additional authorization schemes. Stay tuned for any upcoming announcements in this space.

What's next