Goals
The Pseudonym Certificate Authority (PCA) is an intrinsically non-central component of the SCMS. It issues pseudonym, identification, and application certificates for End Entities (EEs). There may be multiple PCAs in the SCMS. Each PCA is associated with a single RA and a pair of LAs to perform its core functions. The PCA responds to requests from the MA to investigate potential misbehavior.
The figure shows that the PCA responds to requests from both the RA and the MA. It also requires shared symmetric encryption/decryption between the LAs and the PCA, although, there is no direct communication between them. The PCA also maintains a secure database containing all pre-linkage values, certificates, and a hash of the certificate request that it received from the RA.
Procedure
To add a new PCA to the SCMS, the local ICA Manager will select an RA and a pair of LAs to associate with the new PCA. It must then coordinate the generation and installation of the shared symmetric encryption/decryption key between the PCA and each of the LAs. It will also inform the RA and the central MA of the PCA's FQDN.
End States
After completing this use case, the PCA will be configured with the following values:
| PCA Value | Notes |
|---|---|
| LA1-PCA shared key | Symmetric encryption key shared with LA1 |
| LA1 ID | A globally unique identifier associated with LA1 |
| LA2-PCA shared key | Symmetric encryption key shared with LA2 |
| LA2 ID | A globally unique identifier associated with LA2 |
After completion of this use case, the designated RA will have the following information:
| RA Value | Notes |
|---|---|
| PCA FQDN | RA will use this address to send certificate signing requests to the PCA. RA signs each request. |
After completion of this use case, the MA will have the following information:
| MA Value | Notes |
|---|---|
| PCA FQDN | The MA must be able to contact the PCA to retrieve linkage values to support misbehavior investigation and blacklisting or revocation. |
After completion of this use case, the designated LAs will have the following information:
| LA1/2 Value | Notes |
|---|---|
| LA1/2-PCA shared key | Each LA (i.e., LA1 and LA2) stores the shared key that was exchanged with the PCA. |
Special Cases
The procedure described above shall be used when adding a new PCA to the SCMS. The following details define how to deal with special cases of replacing a previous PCA component.
- If the PCA's SCMS certificate has been retired and a new certificate is issued, there is no need for a special procedure to add the new certificate. The PCA can continue to use the same FQDN and TLS certificate as before. The RA and MA should be able to learn the new PCA certificate.
- If the PCA has been securely decommissioned and replaced, the local ICA Manager may transfer the contents of the PCA database to the new component. The replacement PCA may use the same network address as the decommissioned device. The RA and MA should be able to learn the new PCA certificate.
- If the PCA's SCMS certificate has been revoked, then in addition to adding the new PCA, all certificates that were previously issued by that PCA will need to be removed by the EEs to which they were issued. This process will be triggered by the presence of the PCA's certificate on the CRL, which is distributed to all EEs (see the Revoke PCA use case for details on how to revoke a PCA). EEs that become inoperative or are at risk of jeopardizing their privacy because of this action will need to contact their RA to request new certificates or take OEM specific action to recover.
- If an ICA in the PCA's certificate chain or the root CA has been revoked and replaced, then the PCA must generate a new key pair and receive a new SCMS certificate from a re-certified or replaced ICA. As in the case of PCA revocation, affected EEs will need to request new certificates or follow an OEM specified procedure to recover.