Page tree
Skip to end of metadata
Go to start of metadata
Target release

Release 1.0

Document owner
Reviewer

Goals

The Enrollment Certificate Authority (ECA) is an SCMS backend component that signs enrollment certificates for End Entity (EE) devices. In normal operation, the ECA receives and responds to requests from one or more Device Configuration Managers (DCMs). The addition of an ECA to the SCMS requires that the ECA is informed of the DCMs that will be sending requests and that the network is set up to enable those requests to reach the ECA.

ECA Messaging Diagram

The figure shows that the ECA will receive messages initiated by one or more DCM. It is recommended, but not required, that each DCM work with a single ECA.

The SCMS PoC design requires that each ECA maintain a list of DCMs that are authorized to send it enrollment requests. It does this by maintaining a list of authorized DCM TLS certificates.

Each ECA will be assigned to one RA, which will only trust this ECA’s enrollment certificates.

Process

To add an ECA to the SCMS, the local ICA Manager must provide a list of TLS certificates to the ECA for all DCMs that are authorized to send it requests. The ECA must also configure its network to allow communication from the DCMs to the ECA.

In order to access the new ECA, each DCM that will send it requests must be provided with the following:

  1. The FQDN of the new ECA
  2. The ECA's TLS certificate

The local ICA Manager must inform the designated RA of the newly added ECA's SCMS certificate.

End State

After completing this use case, the ECA will be configured with the following values:

ECA ValueNotes
One or more DCM TLS certificatesThe ECA requires a list of authorized DCMs that can send it signature requests. The ECA shall maintain a table of allowed DCM TLS certificates.
ECA Values

After completion of this use case, each DCM that is authorized to communicate with the newly added ECA will be configured with the following values:

DCM ValueNotes
FQDN and TLS certificate of the ECAEach DCM requires the FQDN and TLS Certificate of one (or more) ECA to process enrollment requests.
DCM Values

After completion of this use case, the designated RA will have the following information:

RA ValueNotes
SCMS certificate of the newly added ECAOne RA must be configured to accept enrollment certificates from the new ECA.
RA Values

Special Cases

The procedure described here can be used when adding a net-new ECA to the SCMS.

Other conditions must be managed as follows:

  • ECA SCMS Certificate Retired and Re-Issued - When this happens, the RA that the ECA is assigned to must be informed of the new ECA certificate. The local ICA Manager will perform this update. 
  • ECA Decommissioned and Replaced - If an ECA is securely decommissioned, enrollment certificates that were previously issued may continue to be trusted. The local ICA Manager must instruct all DCMs that they can no longer send requests to the decommissioned ECA. A new replacement ECA may be added using the procedure described here as if it were a net-new ECA to the SCMS.
  • ECA Revoked: see Step 11.2.1 - Revoke ECA

Assumptions

  • The ECA must be configured using the Setup ECA use case before it can be added
  • The ECA will support a mechanism for adding and removing authorized DCM certificates from its internal table. The method of updating this table is implementation specific and is not part of the SCMS design.
  • Each DCM will maintain a list of one (or more) active ECAs that it may use for signing enrollment certificates
  • Each RA will maintain a list of ECAs whose enrollment certificates it may trust
  • Each ECA will be assigned to a single RA

Requirements

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

Use Case 11.1. Add ECA - Requirements