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.
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:
- The FQDN of the new ECA
- 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 Value | Notes |
|---|---|
| One or more DCM TLS certificates | The ECA requires a list of authorized DCMs that can send it signature requests. The ECA shall maintain a table of allowed DCM TLS certificates. |
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 Value | Notes |
|---|---|
| FQDN and TLS certificate of the ECA | Each DCM requires the FQDN and TLS Certificate of one (or more) ECA to process enrollment requests. |
After completion of this use case, the designated RA will have the following information:
| RA Value | Notes |
|---|---|
| SCMS certificate of the newly added ECA | One RA must be configured to accept enrollment certificates from the new ECA. |
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
Attachments:
tccv1.png (image/png)
Add_ECA.xml (application/drawio)
add_ECA_diagram (application/drawio)
add_ECA_diagram.png (image/png)
add_ECA_diagram.png (image/png)
add_ECA_diagram (application/drawio)