SCMS CV Pilots Documentation : Step 11.1.1 - Add RA

Goals

The Registration Authority (RA) is an intrinsically, non-central component of the SCMS. There may be multiple RAs active at any given time in the SCMS.

The figure shows that each RA supports the following connections:

• The RA can receive and respond to requests from EEs through the LOP which masks the source IP address and route of the EE from the RA. Only EEs that have enrollment certificates from ECAs that are authorized to use the RA will be accepted. Each EE is configured to contact only one RA.
• The RA can initiate certificate requests to a PCA to generate certificates. Each PCA is associated with a pair of LAs (LA1 and LA2) that generate pre-linkage values for pseudonym certificates, which are used in EE revocation.
• The RA initiate requests to both LAs to obtain pre-linkage values

• The RA must respond to requests from the central MA to add EEs to its internal blacklist and to support misbehavior investigation

Not shown in Figure 1 is the association of the RA with one or more ECA. While there is no direct communication between an ECA and the RA, the RA must maintain a white list of ECA certificates such that only EEs with enrollment certificates signed by authorized ECAs can access the RA. In addition, the RA maintains extensive logs of transaction history and an internal blacklist, which identifies EEs that are disallowed to request or download new certificates.

Procedure

The addition of a new RA to the SCMS must begin with a certified RA component that has been setup according to the Setup RA use case.

The following actions are required to add the new RA:

• The MA must be updated with the Fully Qualified Domain Name (FQDN) of the new RA. This requires the local ICA Manager to inform the TCotSCMSM and request that the new RA be added to the MA.
• The RA must receive the FQDN of the PCA
• The RA must receive the FQDNs of both LAs and their LA IDs
• The RA must receive least one ECA certificate, which will be added to the RA's white list of authorized ECAs

All of these steps are manual processes that are carried out by the local ICA Manager.

End State

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

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

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

Special Cases

The general procedure described above applies when adding a new RA to the SCMS. There are variations to the process when a replacement RA is introduced.

• If the RA certificate has been retired and the same RA now has a new certificate, the RA may continue to operate using the same network address and internal storage status. All DCMs that are authorized to use the RA shall obtain the new RA certificate for use in configuring new EEs.
• If the RA hardware were securely decommissioned, the internal memory of the prior RA may be transferred to a new device. As in the previous case, all DCMs that are authorized to configure EEs for the RA shall receive the new RA certificate.  
• If the RA has been revoked and replaced, the local ICA Manager must decide if any pre-existing state information can be securely transferred to the replacement component.
• If a component in the RA's certificate chain (an ICA or the Root CA) is revoked and replaced, the RA will be implicitly revoked and need to be replaced. Here too, the local ICA manager may decide if any pre-linkage values from prior transactions can be saved. If not, then past values shall be purged.

Attachments:

Add_RA.xml (application/drawio)
add_RA_diagram (application/drawio)
add_RA_diagram.png (image/png)
add_RA_diagram.png (image/png)
add_RA_diagram (application/drawio)