Certificate Management Flows - CSMS Developer Guide

CSMS Receives: Get15118EVCertificateRequest

{
  "iso15118SchemaVersion": "urn:iso:15118:2:2013:MsgDef",
  "action": "Install",
  "exiRequest": "<Base64-encoded CertificateInstallationReq from EV>"
}

CSMS Must Do:

1. Parse the iso15118SchemaVersion to determine which ISO 15118 schema to use for decoding.
2. Forward the exiRequest (Base64-encoded EXI) to the Certificate Provisioning Service (CPS) backend.
3. Receive the signed CertificateInstallationRes from the CPS.
4. Return the response as Base64-encoded EXI in exiResponse.

CSMS Responds: Get15118EVCertificateResponse

{
  "status": "Accepted",
  "exiResponse": "<Base64-encoded CertificateInstallationRes for EV>"
}

Status values:

• Accepted - Request processed successfully, exiResponse contains valid response for EV.
• Failed - Could not process the request (e.g., CPS unreachable, invalid request).

Requirements (CSMS Perspective):

CSMS Receives: Get15118EVCertificateRequest

Same schema as M01. The only difference is the action field:

{
  "iso15118SchemaVersion": "urn:iso:15118:2:2013:MsgDef",
  "action": "Update",
  "exiRequest": "<Base64-encoded CertificateUpdateReq from EV>"
}

CSMS Must Do:

1. Same as M01, but route to the MO backend (or appropriate certificate update service).
2. The exiRequest contains a CertificateUpdateReq (not CertificateInstallationReq).
3. Return the CertificateUpdateRes as Base64 in exiResponse.

CSMS Responds: Get15118EVCertificateResponse

Identical schema to M01 response.

{
  "status": "Accepted",
  "exiResponse": "<Base64-encoded CertificateUpdateRes for EV>"
}

Requirements (CSMS Perspective):

CSMS Sends: GetInstalledCertificateIdsRequest

{
  "certificateType": ["V2GRootCertificate", "MORootCertificate"]
}

CSMS Receives: GetInstalledCertificateIdsResponse

{
  "status": "Accepted",
  "certificateHashDataChain": [
    {
      "certificateType": "V2GRootCertificate",
      "certificateHashData": {
        "hashAlgorithm": "SHA256",
        "issuerNameHash": "...",
        "issuerKeyHash": "...",
        "serialNumber": "..."
      },
      "childCertificateHashData": [
        {
          "hashAlgorithm": "SHA256",
          "issuerNameHash": "...",
          "issuerKeyHash": "...",
          "serialNumber": "..."
        }
      ]
    }
  ]
}

CSMS Implementation Notes:

• Send GetInstalledCertificateIdsRequest to audit installed certificates.
• Omit certificateType to retrieve ALL installed certificates.
• Use the returned CertificateHashDataType values for subsequent DeleteCertificateRequest calls (M04).
• The childCertificateHashData represents sub-CA certificates in the chain (max depth of 4).

Requirements (CSMS Perspective):

CSMS Sends: DeleteCertificateRequest

{
  "certificateHashData": {
    "hashAlgorithm": "SHA256",
    "issuerNameHash": "ABC123...",
    "issuerKeyHash": "DEF456...",
    "serialNumber": "1234567890"
  }
}

CSMS Receives: DeleteCertificateResponse

{
  "status": "Accepted"
}

Status values:

• Accepted - Certificate was deleted successfully.
• Failed - Certificate exists but could not be deleted (e.g., in use).
• NotFound - No certificate matching the hash data was found.

CSMS Implementation Notes:

• Always run M03 first to get the correct CertificateHashDataType for the certificate to delete.
• Handle all three status values (Accepted, Failed, NotFound).
• Use this to remove expired or compromised root certificates.
• Be careful not to delete certificates that are currently in use for active TLS connections or charging sessions.

Requirements (CSMS Perspective):

CSMS Sends: InstallCertificateRequest

{
  "certificateType": "V2GRootCertificate",
  "certificate": "-----BEGIN CERTIFICATE-----\nMIID...base64...==\n-----END CERTIFICATE-----"
}

InstallCertificateUseEnumType values:

• V2GRootCertificate - ISO 15118 V2G Root CA
• MORootCertificate - Mobility Operator Root CA
• CSMSRootCertificate - CSMS Root CA (for the CS to trust the CSMS)
• ManufacturerRootCertificate - Manufacturer Root CA (for firmware signature verification)

CSMS Receives: InstallCertificateResponse

{
  "status": "Accepted"
}

Status values:

• Accepted - Certificate was installed successfully.
• Rejected - Certificate was rejected (e.g., invalid format, policy violation).
• Failed - Installation failed (e.g., storage full, internal error).

CSMS Implementation Notes:

• The certificate MUST be PEM-encoded X.509 format.
• Only root/CA certificates are installed via this message - NOT leaf certificates or certificate chains.
• To install a V2G Charging Station leaf certificate (SECC), use the A02/A03 flows (SignCertificate + CertificateSigned).
• When installing a CSMSRootCertificate, be aware that the Charging Station will use it to verify the CSMS's TLS server certificate.
• When installing a V2GRootCertificate, the Charging Station needs this to derive its V2G Charging Station Certificate for ISO 15118 communication with EVs.
• Multiple V2G Root Certificates may be needed if the CS needs to support more than one V2G root.

Requirements (CSMS Perspective):

CSMS Receives: GetCertificateStatusRequest

{
  "ocspRequestData": {
    "hashAlgorithm": "SHA256",
    "issuerNameHash": "ABC123...",
    "issuerKeyHash": "DEF456...",
    "serialNumber": "1234567890",
    "responderURL": "https://ocsp.example.com/v2g"
  }
}

CSMS Must Do:

1. Extract the OCSP request data from the message.
2. Build an OCSP request using the provided hash algorithm, issuer name hash, issuer key hash, and serial number.
3. Send the OCSP request to the responderURL.
4. Return the DER-encoded OCSP response as Base64 in ocspResult.

CSMS Responds: GetCertificateStatusResponse

{
  "status": "Accepted",
  "ocspResult": "<Base64-encoded DER OCSP response per IETF RFC 6960>"
}

CSMS Implementation Notes:

• The CSMS acts as a proxy between the Charging Station and the OCSP responder.
• The CSMS SHOULD cache OCSP responses to reduce load on the OCSP responder.
• The ocspResult is DER-encoded per IETF RFC 6960, then Base64-encoded.
• When status = Accepted, ocspResult MUST be present.
• When status = Failed, ocspResult MAY be omitted.

Requirements (CSMS Perspective):