Page tree
Skip to end of metadata
Go to start of metadata
Target releaseRelease 1.1
Document owner
Reviewer

Goals

The goal is to define the procedures and requirements to add and manage root management electors in the SCMS.

Background and Strategic Fit

Electors are a collection of highly trusted backend components in the SCMS, which are used to certify root management messages. Specifically, a message that commands all SCMS components to add or remove a root CA certificate from their trust store will be trusted only if it is signed by a quorum of electors. The value of quorum is defined in the Global Policy File (GPF). Root management messages are distributed as part of the Global Certificate Chain File (GCCF) or a local copy of the chain file (an LCCF).

Procedure

Before a new elector can be added to the SCMS, it must first be setup using the process defined in the Setup Elector use case. The new elector must then be endorsed by a quorum of existing electors and the signed "add elector" message must be distributed to all SCMS 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:

  1. Command the new elector to create a self-signed certificate of the new elector (the elector certificate is created in the Setup Elector use case) in a secure environment.
  2. Present the new elector 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 elector endorsement message with the sequence of existing elector signatures attached. 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.
  3. Deliver the complete elector endorsement message with signatures to the PG for inclusion in future updates to the GCCF. Note that the PG signature is not necessary for the elector 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 elector endorsement messages included. RAs will be required to include all elector 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 elector endorsement message attached 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 elector certificate to their trust store. When validating an elector endorsement message, an entity must check that the signed data is identical in each elector signature and that the ballotType element of the signed data has the value "addElector."

Assumptions

  • An initial set of electors and self-signed elector certificates will be created as part of ceremony (or sequence of ceremonies) at the launch of an SCMS infrastructure. The SCMS Manager will define policies and procedures to ensure the integrity of this initial set of electors.
  • Once an SCMS is in operation and the initial set of electors has been installed in all existing SCMS components, new electors may be added using the process defined here.
  • The existing electors that sign an "add elector" message must have valid, non-expired SCMS certificates at the time when they sign the message. SCMS components that process an "add elector" message must confirm that the endorsing elector certificates are not expired at the time when the message is being processed. Once the message is validated, the SCMS components will add the new elector to their trust store and it will remain there even if one or more of the endorsing elector certificates expire. As long as that expiration happens after the message was validated and processed, the new elector remains trusted.
  • When the PG receives a valid, "add elector" 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 elector 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 "remove elector" message that removes the endorsed elector or removes the endorsing electors rendering the message invalid

Requirements

Key Status Summary Description justification notes Component/s
Loading...
Refresh

Use Case 11.1.3: Add Elector - Requirements

Design

The detailed design for the elector-based, root management process is described in the Elector-based Root Management section.