Goals
The goal is to define the procedures and requirements to add and manage root CA certificates in the SCMS.
Background and Strategic Fit
The SCMS root CA is the root of trust for all SCMS certificates and digital signatures. The root CA private key is stored in a high-integrity component that is accessed through offline messages and that are managed by the Technical Component of the SCMS Manager (TCotSCMSM). Adding a new root CA to the SCMS and distributing the CA's certificate is necessary to maintain the integrity of the SCMS certificate hierarchy when a previous root CA certificate expires or when a previous root CA is revoked or securely decommissioned.
There shall be only one active root CA in the SCMS at any time. Specifically, it is the responsibility of the TCotSCMSM to ensure that only one root CA can be used to sign new messages. However, the design allows SCMS components to continue to trust certificates signed by previous root CAs until their certificates expire. This mechanism allows older root CAs to be retired (i.e., cease to be used for signing new certificates) without invalidating or revoking all of the component certificates that they signed in the past. This use case describes the mechanism for introducing a new root CA to all SCMS components.
Procedure
Before a new root CA can be added to the SCMS, it must first be setup using the process defined in the Setup Root CA use case. The new root CA must then be endorsed by a quorum of existing electors and the signed root endorsement must be distributed to all SMCS components. The message will be distributed through inclusion in the Global Certificate Chain File (GCCF) and any local copies (LCCFs) that are created and distributed by an RA.
To implement this process, an authorized agent of the SCMS manager will perform the following actions:
- In a secure environment, command the root CA to create a self-signed certificate. See the Setup Root CA use case for details on the certificate parameters.
- Present the root CA certificate to all existing, valid SCMS electors and request that they produce a digitally signed copy of the certificate. The collection of all independent signatures from existing electors is then assembled into one root endorsement message with the sequence of elector signatures attached (note that each elector's signature contains a copy of the original message that was signed). The number of elector signatures must be greater than or equal to the value of 'quorum' defined in the current GPF. This is a manual process to be implemented by the TCotSCMSM.
- The complete root endorsement message with signatures is then delivered to the PG for inclusion in future updates to the GCCF. Note that the PG signature is not necessary for the root endorsement to be validated by SCMS components. The role of the PG in this case is to assemble updates to the GCCF with all active root endorsement messages included. The RAs will be required to include all root endorsement messages in any LCCF files that they derive from the GCCF.
- SCMS components (including EEs) that receive a GCCF or LCCF with one or more root endorsement messages attached must check to see if they have already added the new root to their trust store. If they have not, they must validate the message by checking the attached signatures and confirming it has non-expired certificates for at least a 'quorum' of the existing electors that signed the message. Once the message is validated, the SCMS component must add the new root CA certificate to their trust store. When validating a message to add a root, an entity must check that the signed data is identical in each elector signature and that the 'type' element of the signed data has the value "addRoot."
Special Cases
The procedure described above is sufficient to establish a new root CA distribute its certificate to SCMS components. The following special considerations must be applied based on the reason for adding a new root.
- If the current root CA certificate is due to be retired, then the defined procedure is sufficient to distribute a new replacement root. The activation time for the new root should be set such that it does not overlap with the active life of the current root's useful life. The private key associated with the current root certificate shall be securely deleted or destroyed when the new root certificate becomes active. There is no need to remove the previous root certificate or to re-certify components.
- If the current root CA is to be securely decommissioned and replaced, the same procedure can be used as described for root certificate retirement. There is no need to remove the previous root certificate or to re-certify components.
- If the current root CA has been compromised or otherwise needs to be revoked, then the TCotSCMSM may follow the procedure described above with the activation time for the new root, set the current time, or the activation time, defined in the current root removal message. In addition, the TCotSCMSM must initiate the process of re-certifying all components in the SCMS with the new root CA. Specifically, the MA, CRGL, PG, and all ICAs that were certified with the previous root, must be re-certified. See the component "add" use cases for details on how to cascade the impact of re-certification throughout all other SCMS components.
Assumptions
- The SCMS Manager has the power to set policies for what conditions a new root CA must fulfill in order to be an accredited part of the system
- The root CA went through the setup process defined in Step 1.8: Setup Root CA
- Root Management is performed according to the elector scheme outlined in: Elector-based Root Management
- The Global Policy File (GPF) will define the current value for root management quorum, which is the minimum number of valid electors that need to endorse a root management message for it to be accepted by SCMS components. The value of quorum may be set independent of the current number of electors defined. (For the PoC, the value of quorum will be set to 2, meaning that a minimum of two elector signatures are needed for a root management command to take effect.)
- When the PG receives a valid "add root" message, it will continue to include that message on all future GCCF files that it produces until one of the following conditions occur:
- The certificate of the root CA that is added in the message expires
- The certificates of the endorsing electors expire resulting in fewer than 'quorum' valid signatures on the message
- The value of 'quorum' is increased and distributed through an update to the GPF causing the "add elector" message to be invalid
- The PG receives a valid "remove root" message that removes the endorsed root (effectively revoking the root that was added in the original message)
- The PG receives a valid "remove elector" message that removes one of the endorsing electors reducing the number of valid electors to be less than the current value of quorum defined in the GPF, thereby rendering the message invalid
Design
The detailed design for the elector-based root management process is described in the Elector-based Root Management section.
Diagrams
