SCMS CV Pilots Documentation : Step 11.2.3: Revoke Elector

Goals

To produce the "Revoke Elector" message, signed by at least the required number (a quorum as defined in the Global Policy File) of non-revoked Electors, which SCMS Components and EEs must receive through updates to the composite CRL and act on.

Background and Strategic Fit

The SCMS Manager determines that an elector is to be revoked. The SCMS Manager employs the non-revoked electors to authenticate the revocation of the impacted elector. The SCMS Manager creates the message indicating the revocation of the elector, including the elector's certificate and has this message signed by at least "quorum" (as defined in the GPF) of non-revoked electors. The SCMS Manager instructs each elector that it desires to sign this message, authenticating the removal of the impacted elector. These signatures on the message are accumulated into a final message. In this way the SCMS Manager controls the production of the "Revoke Elector" message, signed by at least m non-revoked electors. This message is delivered to all affected SCMS Components via the CRL (proprietary messaging may also be used for faster distribution). To validate the "Revoke Elector" message, components or EEs must verify at least "quorum" non-revoked electors signatures.

The TCotSCMSM will inform the PG to create a new GCCF, removing the impacted elector signature from the root endorsement. If this causes the Root CA to be endorsed by fewer than "quorum" electors, then the TCotSCMSM must establish a new elector and have it endorse the existing root CA. The only alternative is to publish a GCCF with an un-endorsed root, which would implicitly revoke the root and cause all operations to cease.

Assumptions

• Root Management is performed according to the Elector scheme outlined in Root Management and Revocation Recovery
• Elector revocation is communicated to all SCMS components through updates to the CRL

Procedure

To implement this process, an authorized agent of the SCMS manager will perform the following actions:

1. Obtain a copy of the elector certificate that is to be revoked. The SCMS Manager shall define procedures for validating that the correct certificate is being revoked.
2. An agent of the SCMS Manager will present the elector certificate to all existing, valid SCMS electors and request that they produce a digitally signed "removeElector" ballot. The collection of all independent signed ballots from existing electors is then assembled into one elector removal message with the sequence of 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. The complete elector removal message with signatures is then delivered to the CRLG for inclusion in an updated composite CRL file. Note that the CRLG signature is not necessary for the root removal to be validated by SCMS components. The role of the CRLG in this case is to assemble updates to the composite CRL with all active elector removal messages included.
4. SCMS components (including EEs) that receive a composite CRL with one or more elector removal messages attached must check to see if they have already removed the elector from their trust store. If they have not, they must validate the elector removal message by checking the attached signatures and confirming it has non-expired certificates for at least 'quorum' of the existing electors that signed the message. Once the message is validated, the SCMS component must remove the elector certificate from their trust store. When validating an elector removal message, an entity must check that the data, which is signed in each elector endorsement (specifically the TbsElectorEndorsement element) is identical and that the EndorsementType element of the data has the value removeElector.
5. When an elector is removed from a device's trust store, the device must then cease to trust any new messages endorsed by that elector.