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.