The Policy Generator (PG) is an intrinsically central SCMS component that maintains and signs updates to the Global Policy File (GPF) and the Global Certificate Chain File (GCCF). In addition, the PG is required to sign Local Policy Files (LPFs) at the request of RAs who want to set local policy values or reduce the volume of information that they distribute to their EEs. When signing LPFs, the PG is responsible for validating that critical global information has not been removed and that all local policy adjustments comply with the global policy.
Figure 1 shows the request-response relationships of the PG. This diagram explicitly includes the TCotSCMSM, which is the only authority that is able to define changes to global policy, which in turn will be distributed through the GPF. The TCotSCMSM is also the conduit through which new PCA certificate chains can be communicated for addition to the GCCF. Updates to the CRL downloaded from the CRL store might trigger updates to the GCCF in case it contains a revoked certificate.
The PG is an intrinsically central component, so there will only be one instance of the PG in the SCMS. When adding or replacing the PG, the TCotSCMSM must ensure that all RAs are aware of the FQDN of the PG and that they are allowed to access to the PG. This will likely be done in cooperation with local ICA Managers who operate each RA.
Prior to initiating this process, the new PG must be set up according to the Setup Policy Generator use case.
After completing this use case, the PG will be configured with the following values:
|CRL Store FQDN|
The PG needs to download the latest CRL on a regular basis in order to remove revoked certificates from the GCCF.
After completing this use case, RAs will be configured with the following values:
|PG FQDN||Every RA in the SCMS must be able to contact the PG to request signatures on LPFs and to download the latest GPF and GCCF.|
The procedure defined above applies when a new PG is initially added to the SCMS. Changes required for replacing a PG are required based on the reason for the replacement.
- The PG's SCMS certificate has a useful life that is shorter than the certificate expiration date. When the PG's SCMS certificate is retired, the current private key must be deleted, a new key pair must be generated, and a new SCMS certificate can be installed in the PG. Other SCMS components can learn the new certificate by reading it from the signed updates to the GPF or GCCF and validating that the Root CA signed it. There is no need to communicate the new SCMS certificate directly to any other SCMS components.
- If the PG is securely decommissioned and replaced, the new component must be issued a new SCMS certificate, which can be learned as described above. The current state of the Global Policy and the current GCCF can be securely copied to the replacement component or it can load these files from the last signed copies that were published.
- If a PG is revoked, then it must be re-certified or replaced. The TCotSCMSM must determine if the latest published version of the GPF is reliable for loading into the new component or it can re-create a current Global Policy definition. Similarly, the TCotSCMSM can import a reliable copy of the GCCF or it can collect PCA cert chains and reproduce the GCCF.
- If the Root CA is revoked causing implicit revocation of the PG, the TCotSCMSM must re-create the Global Policy and replace or re-certify the PG. In this situation, the GCCF should be re-created by collecting PCA certificate chains to ensure consistency with all newly issued Root CA or ICA certificates (if an ICA has been revoked, validated certificate chains for PCAs that were not impacted may be copied from the previous GCCF).
- A new PG must be setup using the Setup Policy Generator use case.
- The interface between the TCotSCMSM and the PG is not defined. It is assumed that updates to the GPF or GCCF will be encoded using the same format as the published files (i.e., using the same ASN.1 message structure up to the "to be signed" structure).
- The method for the TCotSCMSM to authenticate to the PG is not defined. It is assumed that a secure process will manage and log updates to global policy and certificate chain files.