Page tree
Skip to end of metadata
Go to start of metadata
Target releaseRelease 0.1
Document owner
Reviewer

Goals

The goal of this use case is to define the messages and actions which allow a device to request new pseudonym certificates from the RA. An initial request is for 3,000 (3,120 to be exact) certificates and is assumed to be the default for a batch request. (20 pseudonym certificates per week x 52 weeks per year x 3 years). Note: 20 pseudonym certificates is minimum number of certificates per week. Each OEM can decide to have more certificates per week. The number of requested certificates per week changes the number of request towards PCA and, therefore, requires more computational and storage capacity at the PCA.

Background and Strategic Fit

Whenever the SCMS Manager decides to change technical policies for the SCMS, all participating devices must be updated. Therefore, the RA provides a Local Policy File (LPF) based on the Global Policy File (GPF) generated and signed by the Policy Generator. The Policy Generator as well signs the LPF. The OBE must download the LPF and Local Certificate Chain File (LCCF) before sending any subsequent request or any certificate download every time it connects to the RA.

The OBE must request pseudonym certificates from its RA within the overall policy set by the SCMS Manager in the LPF. The OBE will be preconfigured during Use Case 2: OBE Bootstrapping (Manual) with the FQDN of the RA to which it submits the certificate batch request.

Assumptions

OBE has successfully completed Use Case 2: OBE Bootstrapping (Manual).

Process Steps

The OBE should follow the steps outlined below to request pseudonym certificates. Neither order nor fulfillment of all steps is enforced, but highly recommended.

  1. The OBE downloads the Local Policy File (LPF) and the Local Certificate Chain File (LCCF) using the API documented in RA - Download local policy file and RA - Download Local Certificate Chain File
    1. The OBE applies all changes to its trust-store (necessary for PCA Certificate Validations) if there is an updated LCCF
    2. The OBE applies those changes if there is an updated LPF
  2. The OBE creates the request, signs it with the enrollment certificate, encrypts the signed request to the RA and sends it via LOP to the RA using the API documented in RA - Request Pseudonym Certificate Batch Provisioning
  3. The LOP strips any information that could be used to determine the OBE’s location and forwards it to the RA
  4. The RA ensures that the certificate batch request is correct and authorized before it starts Step 3.2: Pseudonym Certificate Generation

Error Handling 

  1. The OBE will abandon further interactions with the RA after a certain number of failed communication attempts resulted in errors
  2. The OBE will not attempt to execute the certificate provisioning process if it finds itself on the latest CRL (assumes that a willful violator has not compromised the device). The OBE will need to execute the certification/bootstrap process again to exit a revoked state.

Requirements

Key Status Summary Description justification notes Component/s
Loading...
Refresh

Use Case 3.1 - Requirements

Design

OBE-RA Communication

EE Request

EE initiates the certificate request message to provide the RA with critical information (key parameters, current time, etc.) necessary for certificate batch generation. New devices may experience some delay between the initial request and the time that the first certificate batches are available for download to accommodate provisioning processes such as shuffling, certificate generation, and certificate encryption. The RA will store information from the initial certificate provisioning request message and use it for ongoing certificate pre-generation until:

  • The device is blacklisted at the RA due to misbehavior or malfunction

The Certificate Provisioning Request message is sent only once for each unique request and no subsequent Certificate Provisioning Request is necessary to acquire new certificate batches.

Security / Privacy

The Certificate Provisioning Request message uses signing and encryption to ensure:

  • The request has not been modified in transit
  • The RA can verify the message came from EE
  • The request is shared confidentially between EE and RA

The EE signs the request with the Enrollment Certificate. The EE also encrypts the request using the RA certificate.

Message Contents

The EE uses the ASN.1 defined for creating the Request Certificate message. Details can be found at RA - Request Pseudonym Certificate Batch Provisioning. In order for a request to be validated by the RA, the EE includes the following information in the Certificate Provisioning Request message:

  • Version
  • EE enrollment certificate
  • Butterfly public seed / expansion function (see SCP1: Butterfly Keys for details) parameters for:
    • certificate signing key
    • response encryption key (to encrypt the created certificate towards EE)
  • Current device time: 32-bit denoting number of seconds since the Epoch (as defined in 1609.2)
  • Requested certificate start time: 32-bit denoting number of seconds since the Epoch (as defined in 1609.2)

RA Response

The RA response to the Certificate Provisioning Request message is either accept (indicated by a Request Acknowledgement) or reject (indicated by a HTTP 500). Specific error codes will be hidden from EEs in production to avoid providing useful information to malicious actors. RA logs the specific error for future investigation.

RA - EE Request Acknowledgement

The Request Acknowledge message is initiated by the RA in response to a Certificate Provisioning Request message successfully received from the EE. If the EE request is received and processed without triggering an error (invalid signature, blacklisted, etc.), the RA processes the certificate request and begins certificate pre-generation. The Request Acknowledge message provides the EE with the URL and the time where and at which the first certificates batches will be available for download.

Security / Privacy

The Request Acknowledge message use signing to ensure:

  • The request has not been modified in transit
  • The EE can verify the message came from the RA

The RA signs the Request Acknowledge message using the RA certificate. 

Message Contents

The RA uses the ASN.1 defined for creating the Request Acknowledge message, which can be found at RA - Request Pseudonym Certificate Batch Provisioning.

EE Response

If the RA provides a positive acknowledgement (accept) to a Certificate Provisioning Request, the EE moves forward with the certificate batch download process using the provided URL and time both given in the acknowledge message.

If the EE does not receive an acknowledgement from the RA in response to the request within defined time, EE should retry. Several conditions may necessitate the EE sending the request more than once. This may be due to:

  • Request lost in transit (no TCP ack)
  • RA offline, unavailable or RA network address has changed (EE must query DNS for latest RA network information)
  • EE possesses an invalid RA certificate and cannot establish secure communications
  • EE received HTTP-500 Error Code

The EE should not attempt to transmit the Request Certificate message without having completed the prerequisites.

ASN.1 Specification

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

1609dot2-schema.asn

1609dot2-base-types.asn