1. Establish a reasonable root certificate expiration period by shortening the EE Enrollment certificate expiration period from previous 30 years as mentioned in the Vehicle Safety Communications Security Studies Project (VSCS)
  2. Allow EE to use their existing enrollment certificate for authentication when requesting a rollover enrollment (Re-enrollment) certificate
  3. Minimize the number of root certificates that are valid at any time


  1. Vehicles have an estimated life of up to 30 years

  2. EEs may only have connectivity once every three years

  3. Initial EE enrollment certificates and rollover certificates are issued by the ECA
  4. Only one enrollment certificate for an EE shall be valid at a time
  5. EE must request and download the rollover certificate before the current certificate expires
  6. Re-enrollment certificates will not be generated or available for download until three years before the expiration of the current enrollment certificate

Factors Influencing Certificate Lifetimes

Certificate lifetimes affect the security of PKI infrastructures. The longer a public/private key pair is in use, the greater the chances are that the keys can be compromised. As computing power increases and technologies improve over time, cryptanalysis becomes a risk. For these reasons, excessively long-lived CA certificate lifetimes are undesirable.

The below diagram illustrates the calculation of the minimum lifetime of a typical CA certificate.

Some certificate authorities may issue certificates that are not valid until a significant time in the future. Examples of this within the SCMS are pseudonym certificates and rollover enrollment certificates. As a recommendation, the validity lag for these certificates can be up to 3 years. For example, a pseudonym certificate generated (issued) today may have a "Valid from" date that is up to 3 years from now. The below diagram illustrates the impact of the validity lag on the lifetime of the issuing CA certificate.


As additional layers are added to the certificate hierarchy, this process is repeated up to the root CA. When operational factors and the requirement to have the ability to issue new certificates at any time are considered, the required lifetime of each CA certificate in the trust chain is further increased.

It will be necessary to renew the enrollment certificate multiple times for an estimated vehicle lifetime of 30 years. An enrollment certificate lifetime of 6 years greatly reduces security concerns due to certificate longevity, but it requires an automatic renewal mechanism that can accommodate the EEs with infrequent network connectivity. As better and more frequent network connectivity becomes available to the EEs, it may be possible to further reduce these lifetimes.

The below diagram illustrates the impact of issued certificate lifetime, certificate validity lag and operational factors on the PKI hierarchy.


Establishing a fixed schedule for the expiration of elector certificates, root CA certificate(s), intermediate CA certificates and enrollment CA certificates is recommended to reduce operational complexities. For offline CAs, this procedure increases security by minimizing the frequency of required access. Certificates issued in the middle of this fixed schedule, due to revocation or new instances, will expire according to the defined schedule and will have a reduced overall lifetime due to a shorter in-use lifetime.

The following guidelines shall be followed when component certificates are issued mid-sequence:

To ensure the overall integrity of the SCMS, the minimum and maximum lifetime of each certificate type will be defined and enforced by the SCMS manager policy. Operators will have some amount of flexibility in defining the actual certificate lifetimes.

Certificate Lifetime Overview

The following table provides the certificate expiration and renewal periods to be used in a SCMS that supports EE enrollment certificate rollover.

Certificate Type
Issuing CA
In Use
Request for Renewal
Start of Validity for Renewal
Number of Concurrently Valid Certificates (In-Use [+ Legacy])
Example Size in Bytes (Certs are Not Fixed Size)
OBE Enrollment


6 years6 yearsAnytime (see notes)6 years1


Rollover certificate will be available no more than 3 years before start of validity.
OBE PseudonymPCA1 week + 1 hour1 weekAnytime1 week20 + 20 (for just 1 hour)


OBE IdentificationPCA1 month + 1 hour1 monthAnytime1 month1 + 1 (for just 1 hour)


RSE Enrollment


6 years6 yearsAnytime (see notes)6 years1


Rollover certificate will be available no more than 3 years before start of validity.
RSE ApplicationPCA1 week + 1 hour1 weekAnytime1 week1 + 1 (for just 1 hour)


DCMICA3 years + 1 week3 years3 months before end of In-Use3 years1 + 1 (for just 1 week)


ECAICA11 years2 years3 months before end of In-Use2 years1 + 5


RAICA3 years + 1 week3 years3 months before end of In-Use3 years1 + 1 (for just 1 week)217  
LAICA3 years + 1 week3 years3 months before end of In-Use3 years1 + 1 (for just 1 week)205 
PCAICA4 years1 year3 months before end of In-Use1 year1 + 3216  
ICARoot CA13 years4 years3 months before end of In-Use4 years1 + 3195 
MARoot CA4 years + 1 week4 years3 months before end of In-Use4 years1 + 1 (for just 1 week)205 
CRLGRoot CA4 years + 1 week4 years3 months before end of In-Use4 years1 + 1 (for just 1 week)190 
Policy Generator (PG)Root CA4 years + 1 week4 years3 months before end of In-Use4 years1 + 1 (for just 1 week)172 
Root CA (RCA)Self17 years8 years3 months before end of In-Use8 years1 + 2211 
ElectorSelf12 years12 years3 months before end of In-Use12 years3166The initial elector certificates have an expiration and "in use" time of 4, 8 and 12 years, respectively.

Expiration, In-use, and Overlap Requirements

Overview Diagrams

The following diagrams illustrate the expiration period of various certificate types. The diagrams show the specific duration of the certificate (valid from and to dates) only and do not account for setup time (request generation, signing ceremony, distribution, etc.). Each section shows the life of a single instance of a component under typical (non-compromised) conditions. If multiple instances exist, they would follow a similar pattern but the specific dates may be shifted within the validity period.