This section aims to show root management and disaster recovery in action. As a result, the revocation and replacement of an elector is described below:

  • Day 1: Typical SCMS Operations
  • Day 2: Revoking an Elector
  • Day 3: SCMS Operating with 2 Electors Only
  • Day 4: Replacing a Elector
  • Day 5: SCMS Returning to Typical Operation

The diagrams given below (and in sections above) are high-level summaries only, and do not contain all requirements for the SCMS components or the EEs.

Day 1: Typical SCMS Operations

Diagram of the relationship between electors and various Certificate Authorities
Day 1: Typical SCMS Operations

Day 2: Revoking an Elector

Diagram of Elector A certificate revocation
Day 2: Revoking an Elector

At Day 2, an elector has been revoked by votes from m electors (here m=2). These votes are included in the CRL. The CRL is distributed to all SCMS components and EEs. The SCMS is still operational.

Day 3: SCMS operating with two electors only

Diagram of the SCMS still working without the revoked elector
Day 3: SCMS Operating with Two Electors Only

In Day 3, the SCMS is operational with only two, non-revoked electors. Pseudonym certificates continue to validate and EEs to operate.

Day 4: Replacing an Elector

Diagram with the new elector D added to the SCMS through voting by remaining trusted electors
Day 4: Replacing an Elector

In Day 4, the SCMS Manager introduces a new elector through votes endorsing the new elector obtained from the two, remaining, non-revoked electors. Existing devices that do not recognize the new elector continue to operate. The SCMS Manager adds a new elector through a Ballot inserted into the Global Certificate Chain File (GCCF), which it then provides through the Policy Generator to RAs. The root management message includes votes from the electors, which the SCMS components and EEs will need to validated before performing the root management operation (adding the elector to the trust store). The SCMS Manager provides a new vote from the new elector for the existing root CA certificate and adds it to the GCCF as well. Even with the addition of the new elector, pseudonym certificates continue to validate and EEs to operate.

Day 5: SCMS Returning to Typical Operation

Diagram of the SCMS back in a steady state after the new elector D has been added
Day 5: SCMS Returning to Typical Operation

In Day 5, the SCMS has been returned to an equivalent of the Initial State of Day 1 with a replacement elector.

 

The following describes the revocation and replacement of a root CA certificate:

  • Day 1: Typical SCMS operations
  • Day 2: Standing up a new root CA certificate
  • Day 3: Putting the SCMS backend trust relationships in place for the new root CA certificate
  • Day 4: Revoking the existing and adding the new root CA certificate
  • Day 5: Revoked root CA certificate, system non-functional
  • Day 6: System functionality restored

Day 1: Typical SCMS operations

Diagram of normal SCMS operations and relationships
Day 1: Typical SCMS Operations

Day 2: Standing up a new root CA certificate

Diagram of new root CA being created and approved but not yet used by the SCMS
Day 2: Standing Up a New Root CA Certificate

In Day 2, the new root CA certificate is established and endorsed but is not used by the SCMS.

Day 3: Putting the SCMS backend trust relationships in place for the new root CA certificate

Diagram, of new certificates being created for SCMS components so the new Root CA can be introduced and replace the original root CA.
Day 3: Putting the SCMS Backend Trust Relationships in Place for the New Root CA Certificate

On Day 3, all of the background tasks of generating new certificates for SCMS components is performed, but these are not made active. The new root management operation, "Add Root CA," is distributed to all the authorized operators to prepare them for distribution.

Day 4: Revoking the existing and adding the new root CA certificate

Diagram of the original root CA being revoked and replaced with the new root CA. The new root CA is sent to all of the SCMS components
Day 4: Revoking the Existing and Adding the New Root CA Certificate

On Day 4, the old root CA is revoked and the new root CA is added simultaneously to all SCMS components (not EEs). The EEs only receive the revoke message. The GCCF needs to be reset with the new trust structure, which was created on Day 3. All the SCMS components start using the certificates, which chain to the new root CA certificate. 

Day 5: Revoked root CA certificate, system non-functional

Diagram showing that the SCMS is not finctional after the root CA is revoked since the pseudonym and enrollment certificates need to be replaced and the CRL needs to be reset
Day 5: Revoked Root CA, System Non-Functional

On Day 5, all of the existing pseudonym and enrollment certificates are no longer valid. This means that from an EE point of view, the SCMS is not functioning. The CRL also needs to be reset: any certificate without linkage values can be removed. The handling of the linkage values on the CRL will depend on if the linkage values are continued. Those that are continued will need to remain on the CRL.

Day 6: System functionality restored

Diagram showing the EEs receiving new enrollment certificates to restore functionality to the SCMS
Day 6: System Functionality Restored

On Day 6, the authorized operators will issue new enrollment certificates to the EEs. All EE certificates, including pseudonym certificates, are generated. The EEs require new enrollment certificates to authenticate themselves to their RA. The SCMS does not yet specify the mechanism used to provide new enrollment certificates to EEs; a later release will support this. Once an EE receives its new enrollment certificate, it can download the policy file, the GCCF, and new pseudonym Certificates. The EEs now become operational again.