4.4. Security Domains

A security domain is a registry of PKI services. PKI services, such as CAs, register information about themselves in these domains so users of PKI services can find other services by inspecting the registry. The security domain service in Certificate System manages both the registration of PKI services for Certificate System subsystems and a set of shared trust policies.

The registry provides a complete view of all PKI services provided by the subsystems within that domain. Each Certificate System subsystem must be either a host or a member of a security domain.

A CA subsystem is the only subsystem which can host a security domain. The security domain shares the CA internal database for privileged user and group information to determine which users can update the security domain, register new PKI services, and issue certificates.

4.4.1. The domain.xml File

The security domain registry is an XML file, domain.xml, which is hosted on a designated CA. The domain.xml file is created when the CA is configured as the security domain host, and every subsystem which is added to the domain is added as an entry to the registry. The domain.xml file looks like the following example:

<?xml version="1.0" encoding="UTF-8"?>
<DomainInfo><Name>Example Domain</Name>
        <KRAList>
                <KRA>
                        <SubsystemName>rhpki-kra</SubsystemName>
                        <Host>server.example.com</Host>
                        <SecurePort>10443</SecurePort>
                        <DomainManager>false</DomainManager>
                        <Clone>false</Clone>
                </KRA>
                <SubsystemCount>1</SubsystemCount>
        </KRAList>

        <TPSList>
                <SubsystemCount>0</SubsystemCount>
        </TPSList>

        <OCSPList>
                <OCSP>
                        <SubsystemName>rhpki-ocsp</SubsystemName>
                        <Host>server.example.com</Host>
                        <SecurePort>11443</SecurePort>
 <DomainManager>false</DomainManager>
                        <Clone>false</Clone>
                </OCSP>
                <SubsystemCount>1</SubsystemCount>
        </OCSPList>

        <RAList>
                <SubsystemCount>0</SubsystemCount>
        </RAList>

        <TKSList>
                <TKS>
                        <SubsystemName>rhpki-tks</SubsystemName>
                        <Host>server.example.com</Host>
                        <SecurePort>13443</SecurePort>
                        <DomainManager>false</DomainManager>
                                <Clone>false</Clone>
                </TKS>
                <SubsystemCount>1</SubsystemCount>
        </TKSList>

        <CAList>
                <CA>
                        <SubsystemName>rhpki-ca</SubsystemName>
                        <Host>server.example.com</Host>
                        <SecurePort>9543</SecurePort>
                        <DomainManager>true</DomainManager>
                        <Clone>false</Clone>
                </CA>
                <SubsystemCount>1</SubsystemCount>
        </CAList>
</DomainInfo>

The URL to the CA uniquely identifies the security domain. The security domain is also given a friendly name, such as Example Corp Intranet PKI. All other subsystems -- DRM, TPS, TKS, OCSP, and other CAs -- must become members of the security domain by supplying the security domain URL when configuring the subsystem.

The registration involves adding the following information to the security domain's subsystem registry file, domain.xml:

A user-friendly name such as Employee Certificate Authority
A service URL
The type of subsystem, either CA, OCSP, DRM, TKS, or TPS

Each subsystem within the security domain shares the same trust policies and trusted roots which can be retrieved from different servers and browsers.

The information available in the security domain is used during configuration of a new subsystem, which makes the configuration process streamlined and automated. For example, when a TPS needs to connect to a CA, it can consult the security domain to get a list of available CAs.

A subsystem retrieves information in the security domain through XML messages over HTTPS. The subsystem authenticates to the security domain using a subsystem certificate. To issue a certificate automatically during configuration, a security domain administrator must authenticate to the security domain using a UID and password. More information on security domain roles is given in Section 4.4.2, “Security Domain Roles”.

4.4.2. Security Domain Roles

The security domain allows the roles defined in Table 4.1, “Security Domain User Roles”.

Role	Description
Security Domain Administrators	Add and modify users in the security domain's user and group database. Manage the shared trust policies. Manage the access controls on the domain services. By default, the CA administrator of the CA hosting the domain is assigned as the security domain administrator.
Enterprise CA Administrators	Automatically approve any sub-CA, server, and subsystem certificate from any CA in the domain. Register and unregister CA subsystem information in the security domain.
Enterprise DRM Administrators	Automatically approve any transport, storage, server, and subsystem certificate from any CA in the domain. Register and unregister DRM subsystem information in the security domain. Push KRA connector information to any CA.
Enterprise OCSP Administrators	Automatically approve any OCSP, server, and subsystem certificate from any CA in the domain. Register and unregister OCSP subsystem information in the security domain. Push CRL publishing information to any CA.
Enterprise TKS Administrators	Automatically approve any server and subsystem certificate from any CA in the domain. Register and unregister TKS subsystem information in the security domain.
Enterprise TPS Administrators	Automatically approve any server and subsystem certificate from any CA in the domain. Register and unregister TPS subsystem information in the security domain.

Table 4.1. Security Domain User Roles

As necessary, the security domain administrator can manage access controls on the security domain and on the individual subsystems. For example, the security domain administrator can restrict access so that only finance department DRM administrators can set up finance department DRMs.

Enterprise subsystem administrators are given enough privileges to perform operations on the subsystems in the domain. For example, an enterprise CA administrator has the privileges to have sub-CA certificates approved automatically during configuration. Alternatively, a security domain administrator can restrict this right if necessary.

4.4.3. Creating a Security Domain

A security domain can be created during the CA configuration. During CA configuration, the wizard asks if a security domain should be created. If Yes is chosen, then a user-friendly name must be provided for the security domain. The name is used as the default Organization component in the issuer DN.

By default, the CA administrator is assigned as the security domain administrator, with the privileges to manage the domain.

A domain.xml file is created in the CA instance conf/ directory. This file contains all the important information about the domain. The user and group information is stored in the internal database of CA subsystem hosting the domain.

At the end of the configuration, the CA registers its information in the domain.

4.4.4. Joining a Security Domain

During configuration, if the Join an existing security domain option is selected, provide the service URL to the security domain. This URL usually has the form https://host:port and requires credentials such as a UID and password. (It is not necessary to give the exact URL to the domain.xml file). The UID and password must be previously obtained from a security domain administrator. The credential information must belong to a member of an enterprise subsystem administrator group.

The browser is then redirected to the security domain for authentication. If authentication is successful, an authentication token (cookie) is issued. The browser then transfers this cookie to the configuration wizard, which uses the token to manage multiple subsystems as necessary. Each subsystem contacts the security domain to validate the token before handling the request.

At the end of the configuration, the configuration registers the subsystem information to the security domain.

4.4.5. Additional Security Domain Information

The following information can be considered when planning the security domain:

The CA hosting the security domain can be signed by an external authority.
Multiple security domains can be set up within an organization. However, each subsystem can belong to only one security domain.
Subsystems within a domain can be cloned. Cloning subsystem instances distributes the system load and provides failover points.
The security domain streamlines configuration between the CA and DRM; the DRM can push its KRA connector information and transport certificates automatically to the CA instead of administrators having to manually copy the certificates over to the CA.
The Certificate System security domain allows an offline CA to be set up. In this scenario, the offline root has its own security domain. All online subordinate CAs belong to a different security domain.
The security domain streamlines configuration between the CA and OCSP. The OCSP can push its information to the CA for the CA to set up OCSP publishing and also retrieve the CA certificate chain from the CA and store it in the internal database.