SCMS CV Pilots Documentation : Step 20.1: EE Enrollment Certificate Rollover

Goals

Define a procedure to securely re-enroll a non-revoked EE when its enrollment certificate is about to expire.

During the bootstrap process, an EE is issued an enrollment certificate by an Enrollment CA (ECA) via a DCM in a secure environment, which is used to authenticate communication between an EE and the RA. When an enrollment certificate approaches its expiration date, it must be rolled over to a new certificate so that the EE can continue to authenticate with the RA. This process does not take place in a secure environment, and no trusted DCM is available. Instead, the existing enrollment certificate is used to facilitate secure communication with the RA performing a similar task to the DCM.

Some EEs may not have reliable network access, so the request to re-enroll and the retrieval of the new enrollment certificate are separated into two individual transactions. This separation also allows the RA to choose the timing for when it will forward the request to the Enrollment CA. This time delay may be needed to ensure that the RA has access to an ECA with an expiration time that will allow for the validity period of the new enrollment certificate. When an EE requests re-enrollment, the RA will return a time estimate for when the new certificate will be ready for download. This procedures is similar to the process of requesting and downloading pseudonym certificates.

An EE may request re-enrollment at any time, if it has a currently valid enrollment certificate and the EE has not been added to the RA's blacklist. The RA for the EE’s current enrollment certificate will accept only one request for re-enrollment. The new enrollment certificate will have a validity period that begins when the current enrollment certificate expires (there is no overlap in the validity period for enrollment certificates).

Assumptions

• The EE possesses a valid enrollment certificate that has not been blacklisted by the RA.

• The EE has not previously requested re-enrollment using the currently valid enrollment certificate.

• An ECA is available to sign re-enrollment requests.

• The ECA’s certificate will be valid for the entire duration of any re-enrollment request that it signs.

• For any EE, only one enrollment certificate may be issued for a particular PSID/SSP combination at a time (see Certificate Types for details).

• • An EE should only be allowed to initiate one re-enrollment request for a particular PSID/SSP combination.

  • The new enrollment certificate will have the same PSID/SSP, and will have a validity period starting at the expiry date of the old enrollment certificate (there is no overlap in the validity period for enrollment certificates).

  • EEs have the ability to generate a new verification key pair for the new enrollment certificate (no key injection).

• Some EEs have limited network connectivity, therefore the steps of initiating a re-enrollment request, downloading the new enrollment certificate, and validating the new enrollment certificate shall be completed as asynchronous process. 

• An EE may request re-enrollment at any time
• An EE will only possess one valid enrollment certificate at a time, and may only make a single re-enrollment request using its currently valid enrollment certificate.
• The RA can store at least two enrollment certificates for each EE: The current enrollment certificate and the new enrollment certificate. 
  
  • The existence, or lack thereof, of a stored new enrollment certificate provides a mechanism to track the current stage of re-enrollment.

Design

Due to the fact that some EEs may have limited network connectivity, the re-enrollment process takes place in two phases:

1. The EE contacts the RA to initiate a re-enrollment request. If the RA accepts the request, it will inform the EE of a time when it may come back to download the new enrollment certificate.
2. The EE returns to the RA to download a new enrollment certificate

This approach is meant to match the process used to request and download pseudonym certificates (see Use Case 3: OBE Pseudonym Certificates Provisioning). In practice, a re-enrollment request can be sent and the new enrollment certificate retrieved at the same time the EE is requesting, downloading, or topping off its pseudonym certificates. Note that, as described in Step 3.1: Request for Pseudonym Certificates, an EE must update its LPF and LCCF files any time it connects to the RA. If multiple transactions are performed during the same session, then this step only needs to be performed once.

The following sections outline these steps in detail.

EE Initiates the Re-enrollment Request

If an EE possesses a valid enrollment certificate and has not yet requested re-enrollment, then it may perform the following during its next transaction with the RA:

1. Create a new verification key pair and use it to construct an enrollment certificate request with the same properties (same PSID/SSP) used in the original enrollment certificate.
   
   1. The only changes allowed in the the new CSR is the validity period for the certificate, with the start time of the new certificate being set to the expiry time of the existing certificate. See Use Case 2: OBE Bootstrapping (Manual) for details on formatting the CSR.
   2. The enrollment certificate request is signed using the new verification key.
2. Construct a new signed message containing the new enrollment certificate request and sign that message with the current enrollment certificate private key. This is a re-enrollment request. 
3. Send the re-enrollment request to the RA, using the current enrollment certificate to authenticate to the RA. The RA will validate the request (see below) and reply to the EE with a time indicating when the EE can return to download the new certificate and a hash of the request which must be used to retrieve the new certificate. This mirrors the process used to schedule pseudonym certificate downloads (Use Case 3: OBE Pseudonym Certificates Provisioning). Note that after reconstructing the new enrollment private key, the EE shall delete the ephemeral key pair that was used in the request.

RA Processes EE's Request and ECA's Response

Upon receiving a re-enrollment request from the EE, the RA performs the following steps:

1. Perform the following checks on the re-enrollment request:
   1. Validate that the EE's current enrollment certificate has not been blacklisted.
   2. Ensure that the RA database does not already contain a new enrollment certificate or scheduled re-enrollment request for the EE.
   3. Validate the "outer" signature on the re-enrollment request message using the public key in the currently valid enrollment certificate.
      1. Note: The ECA will validate the "inner" signature on the enrollment certificate request (the payload of the message) using the verification public key in the message. There is no need for the RA to check this signature.
   4. Verify that the requested start time in the re-enrollment request matches the expiration date of the currently active enrollment certificate.
   5. Verify that the re-enrollment request has the same PSID / SSP attributes as the current enrollment certificate.
2. Store the re-enrollment request in the database. The presence of a re-enrollment request in the database signifies that the EE has a re-enrollment request in progress.
3. Respond to the EE with a requestHash and eCertDLTime to schedule the download of the new enrollment certificate.
   1. The eCertDLTime may be any time that is less than three (3) years prior to the expiration date of the current enrollment certificate. This ensures that the currently active ECA used by the RA for re-enrollment will have a valid life span sufficient to generate a new enrollment certificate with a full life span. See PoC Certificate Expiration Timelines for details on the relationship of these certificate validity periods.
4. Schedule a time to activate the re-enrollment request shortly before the eCertDLTime that was calculated in step 3. 
   1. The amount of time allotted for this procedure is implementation dependent. It is recommended that the RA design account for the work load of the RA and the accompanying ECA to ensure that the new enrollment certificate is available when the EE returns to download.
5. Sign the re-enrollment request using the RA private key and forward the signed request to the ECA.
6. Upon receiving the EE's new enrollment certificate from the ECA, store it in the database (replacing or removing the pending re-enrollment request and storing the new enrollment certificate); or, if an error is returned, store the error message in place of the new certificate. Create a relation between the previous enrollment certificate and the new enrollment certificate for revocation and pseudonym certificate download purposes.
7. Once the current enrollment certificate has expired, the RA shall delete it from the database. After this happens, the RA will have only one enrollment certificate for the EE which makes it possible for the EE to request the next enrollment certificate.

ECA Processes New Enrollment Request

Upon receiving an enrollment certificate request from the RA, the ECA performs the following steps:

1. Validate the RA signature.
2. Verify the signature that was created by the EE using the validation private key on the validation public key.
   1. This step proves that the entity that generated the request was in possession of the validation private key.
3. Validate the validity period of the certificate request.
   
   1. Note: The ECA may be issued under a new Root CA and ICA than the EE's current enrollment certificate or the RA certificate. This is OK as long as the ECA can validate the RA signature and the validity periods of the new enrollment certificate are within the ECA's validity period.
4. Generate a new enrollment certificate and sends it back to the RA for delivery to the EE; or, return an error to the RA.
   

Diagrams

The figure below shows the relationship of the RA and ECA in the re-enrollment process. The next figure is a process diagram that outlines the overall re-enrollment procedure.

Attachments:

Re-Enrollment Flowchart (application/drawio)
Re-Enrollment Flowchart.png (image/png)
Re-Enrollment Diagram (application/drawio)
Re-Enrollment Diagram.png (image/png)
EE Re-Enrollment Process (application/drawio)
EE Re-Enrollment Process.png (image/png)