Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: grammatical changes

Scroll Ignore

Page properties

Target releaseRelease 1.0
Document owner


  • The goal of backend management is the addition and removal of SCMS components
  • The provisioning and initial setup requirements for all backend components is defined in Use Case 1: SCMS Component Setup

Background and Strategic Fit

As the SCMS system evolves, it is necessary that SCMS components can be added and removed.

This includes Root CAs. For the PoC, there will be only one Root CA. To manage Roots CAs, (e.g., to add and remove them) the SCMS will employ a multi-Elector system. In this scheme, there are a number of electors. These entities are trust anchors but also vote to manage Root CAs, i.e., to remove or add a new Root CA. The SCMS Manager coordinates the electors. An operation on a Root CA (addition or revocation) will require a message signed by some given number of electors. The exact number of electors needed to perform addition or revocation is a fixed quorum m. The public keys of the electors will be installed into the trust stores of every SCMS component, including the OBEs. In the PoC, electors will be implemented to be manual processes, and the Root Management messages signed by electors will be generated by manual means for testing the management of the Roots CAs.


  • SCMS components need to be added and revoked but not removed and rolled-over
  • More requirements specific to each operation and component will occur in the subsections


Scroll Title
titleUse Case 11 - Requirements

jqlQueryproject = SCMS AND issuetype = Requirement AND labels = UseCase11 ORDER BY key ASC


Scroll Title
titleSCMS Architecture

Summary Showing Trust Anchor Relationships Only

Scroll Title
titleSCMS Root CA Trust Anchor Relationships - Overview

Typical SCMS Operations

Day 1: Typical SCMS System Operations

Scroll Title
titleSCMS Root CA & Elector Trust Relationships

Scenario 1:  Life Cycle of Elector (Level 0) Revocation and Replacement

Scenario 1, Day 2: Process to Revoke an Elector while Maintaining Functionality

Scroll Title
titleElector A Revocation Process

Scenario 1, Day 3: System Functional for Period of Time with Two Root Endorsers

Scroll Title
titleSCMS Operational with Electors B & C Only

Scenario 1, Day 4: Introduction of Replacement Elector

Scroll Title
titleIntroduce Elector D

Scenario 1, Day 5: Steady State Operations after the Introduction of Replacement Elector

Scroll Title
titleSCMS Trust Relationships with Elector D

Scenario 2:  Life Cycle of Root CA (Level 1) Revocation and Replacement

 Scenario 2, Day 2: Prepare New Root CA

Scroll Title
titleCreate Replacement Root CA & Distribute to SCMS Servers

Scenario 2, Day 3: Generate New Certificates for all SCMS Components & Distribute

Scroll Title
titleIntroduce Replacement Root CA before Revoking Current Root CA

Scenario 2, Day 4: Revoke Root CA

Scroll Title
titleRevoke Root CA

Scenario 2, Day 5: Condition of SCMS while Root CA is Revoked

Scroll Title
titleRoot Revoked - System Non-functional

Scenario 2, Day 6: EEs Updated with New Root Certificate, New Enrollment Certificate and New Pseudonym Certificates

Scroll Title
titleUpdate EEs with New Certificates