Goals
To produce the "Revoke Root CA" message, signed by at least the required number (m below) of non-revoked Electors, which SCMS components and EEs must receive and act on.
Assumptions
Root Management is performed according to the Elector scheme outlined in Elector-based Root Management.
Background and Strategic Fit
The SCMS Manager determines that a root CA is to be revoked. The SCMS Manager employs the non-revoked Electors to authenticate the revocation of a root CA. The SCMS Manager forms the bare message indicating the revocation of the root CA, including the root CA's certificate and has this message signed by at least m non-revoked Electors. The SCMS Manager instructs each Elector that it desires to sign this message, authenticating the removal of the root CA. These signatures on the message are accumulated into a final message. In this way, the SCMS Manager controls the production of the "Revoke root CA" message, signed by at least m non-revoked Electors of n. This message is delivered to all affected SCMS Components via the CRL and by proprietary messaging. To validate the "Revoke root CA" message, components or EEs must verify at least m non-revoked Electors signatures.
The MA, relevant CAs, RAs, and CRLG(s) are instructed to remove the affected root CA from their list of trusted roots. The OEMs will ensure that new end-entity devices will not be provisioned with the revoked root CA certificate.
All components and entities that receive the revocation notification also cease to trust any other affected certificate.
All end-entity devices whose certificates chain back to the revoked root CA should obtain new certificates as soon as possible (the SCMS Manager may set performance requirements for how quickly this must happen, and will coordinate).
All CAs, the MA, RAs, and CRLG(s), whose certificates chain back to the revoked root CA should cease issuing certificates with their old certificates immediately and obtain new certificates as quickly as possible (the SCMS Manager may set performance requirements for how quickly this must happen, and will coordinate). The SCMS Manager will manage the recovery from the root CA revocation and establishing a new trust hierarchy.
Procedure
To implement this process, an authorized agent of the SCMS manager will perform the following actions:
- Obtain a copy of the root CA certificate that is to be revoked. The SCMS Manager shall define procedures for validating that the correct certificate is being revoked.
- An agent of the SCMS Manager will present the root CA certificate to all existing, valid SCMS electors and request that they produce a digitally signed "removeRoot" ballot. The collection of all independent signed ballots from existing electors is then assembled into one root endorsement 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.
- The complete root 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 root removal messages included.
SCMS components (including EEs) that receive a composite CRL with one or more root removal message attached must check to see if they have already removed the root certificate from their trust store. If they have not, they must validate the root 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 root certificate from their trust store. When validating a root 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 removeRoot.
- When a root is removed from a device's trust store, the device must then cease to trust any new certificates that chain back to that root.
- When a root is removed from a device's trust store, the device must then cease to trust any certificates that chain back to that root. If a device finds that this action invalidates its own enrollment certificate or private key, it must cease operation.
Design
The design for the elector-based management system is described in the Elector-based Root Management section.
Diagrams
