Determine whether to use a single vs. multiple root CA based on operational and public interest objectives. An SCMS design allows for single or multiple roots. SCMS deployment could feature a single root, with the intent of expanding to multiple roots to help reduce the short-term governance and oversight costs. However, it’s important to consider that operating with a single root may limit future flexibility. If OBUs are designed with the assumption of a single root, it may not be possible to transition to a multiple root architecture. End entities must be capable of operating under multiple roots to ensure interoperability regardless the structure.
Considerations for adding root CAs include:
- At least one root CA is required.
- If a root CA is compromised, all devices are potentially affected. Therefore, each root CA certificate needs high security standards, defined by the SCMS Manager, regardless of the root CA’s size.
Understand the potential costs presented by the number of root certificates when considering operational models and the number of eventual roots. More root CAs will increase the overall cost of the system and create more opportunities for malicious actors attempting to compromise a root. The security risk is mitigated by applying high security standards for each root CA. When analyzing cost, one must consider the following:
- OBUs must have all root certificates. More roots add to the memory requirement, although at very small increments.
- Each root will have a Certificate Revocation List (CRL) – hopefully small, but there will be memory cost associated with each.
- A lot of roots may necessitate more issuing CAs (e.g., every OEM has its own root and issuing CA).
- Potential processing difference – all certificates chain through some issuing CA to a root, but root and issuing CA validity only need to be checked once each time CRLs are received. A lot of different chains would mean that there is a need to process each one and cache.
Manage root retirement /replacement to limit operational interference. All roots will eventually be forced to either:
- retire due to roots’ limited lifespan that prevents keys from being compromised
- be replaced as new requirements (e.g., increased key size) may necessitate standing up a new root.
The minimum and maximum lifetime of each certificate type will be defined and enforced by SCMS Manager policy. There must be an effective method to retire and replace roots without negatively impacting SCMS operations. The SCMS Manager and stakeholders will need to define the actual method to manage root retirement /replacement within the PKI policies.
Consider the appropriate number of electors that are necessary to make it very likely that a quorum can be achieved while keeping costs under control. The trust anchor management method within the current SCMS design is the elector concept, where electors have the power to change and manage the trust relationships of the system. Under this distributed management scheme, a new, self-signed root CA certificate must be endorsed by a quorum of valid electors to be trusted by devices and other SCMS components without the need of returning them to a secure environment.
However, each elector is essentially a specialized, stand-alone PKI that has a single certificate, so deploying an elector could cost as much as standing up a root. The SCMS Manager needs to consider the appropriate number of electors that are necessary to make it very unlikely that a quorum cannot be achieved while simultaneously constraining costs.
Establish certification requirements to ensure end entities can adequately protect keys. End entities will need to meet certain PKI requirements, and functional and performance requirements, for initial enrollment and to maintain enrollment status with the SCMS regardless of the model. Device certification ensures that end entities operate as per mandated (V2V) specifications, and possible local safety inspection regulations. The SCMS will likely need to consider whether re-enrollment certification criteria should require electronic proof that the end entity has met state and/or local safety inspection requirements.
(Our website has many links to other organizations. While we offer these electronic linkages for your convenience in accessing transportation-related information, please be aware that when you exit our website, the privacy and accessibility policies stated on our website may not be the same as that on other websites.)