ISO15118-20 Canonical EXI support

[eroqefklj22234]

I know that ISO15118-20 protocol should use canonical exi.
I wonder if you support this.
I checked the code and it seems that the EXI encoding/decoding process does not include namespace and prefix data.
Isn't that why signing fails in this situation?

[jayharper]

Hi, I’ve got a concrete interop case where the canonical EXI output from cbexigen for ISO 15118-20 doesn’t match the DigestValue provided by a simulated EV, even though everything on my side is internally consistent.

On the EV side I’m using a Keysight SL1550A EVCC acting as the simulated vehicle.

On the SECC side I’m using cbexigen-generated codec (libcbv2g) for ISO 15118-20 CommonMessages inside a custom SECC implementation that verifies Plug & Charge AuthorizationReq signatures.

---

Setup

• EV side: Keysight SL1550A EVCC (simulated EV)
• SECC side: custom SECC codebase using cbv2g/cbexigen
• Schema: ISO 15118-20 CommonMessages
• libcbv2g version: 0.3.1

From the EV I capture a full AuthorizationReq EXI payload on the wire. In the XML signature:

• Reference/@URI is #aReq
• Transforms/Transform/@Algorithm is http://www.w3.org/TR/canonical-exi/
• DigestMethod/@Algorithm is the SHA-512 URI required by ISO 15118-20 for this profile
• DigestValue is a 64‑byte SHA‑512 value coming from the Keysight EVCC

I can provide the exact wire EXI and digest values if that’s helpful; I’ve left them out of this first draft to keep it readable.

---

What I do with libcbv2g

On the SECC side I do the following:

1. Decode wire EXI → iso20_exiDocument

   iso20_exiDocument doc;
   // decode_iso20_exiDocument(...) from cbv2g

2. Extract PnC_AReqAuthorizationMode into an iso20_exiFragment

   iso20_exiFragment frag;
   init_iso20_exiFragment(&frag);
   
   frag.PnC_AReqAuthorizationMode_isUsed = 1;
   frag.PnC_AReqAuthorizationMode       = doc.AuthorizationReq.PnC_AReqAuthorizationMode;

3. Encode the fragment with the libcbv2g fragment encoder (canonical EXI enabled???)

   exi_bitstream_t stream;
   uint8_t buffer[4096];
   size_t bit_pos = 0;
   
   exi_bitstream_init(&stream, buffer, sizeof(buffer), bit_pos, NULL);
   int rc = encode_iso20_exiFragment(&stream, &frag);
   // rc == 0, and exi_bitstream_get_length(&stream) gives the EXI length in bytes

4. Compute SHA‑512 over those EXI bytes

   That SHA‑512 digest is what I expect to match the EV’s DigestValue for #aReq.

I also log the canonical fragment bytes from the SECC at runtime and use those as a “golden” value in unit tests.

---

Tests I added

In my cbv2g test suite I added a few GoogleTest tests around this.

1. Local canonical fragment vs EV digest

• Take the golden canonical EXI fragment that I logged from my SECC (kGoldenCanonicalAReqHex).
• Compute SHA‑512 in the test.
• Compare against the Keysight EVCC’s DigestValue for #aReq.

Result: Fails. The digest over kGoldenCanonicalAReqHex does not match the EV’s DigestValue.

2. Local canonical fragment vs SECC‑logged digest

• Same kGoldenCanonicalAReqHex as above.
• Compute SHA‑512 in the test.
• Compare against the digest that my SECC logged at runtime for this same fragment.

Result: Passes. The test digest equals the SECC’s runtime digest byte‑for‑byte.

3. Wire EXI → doc → fragment → canonical EXI → digest

Another test starts from the wire AuthorizationReq EXI:

1. Decode wire EXI into iso20_exiDocument.
2. Extract AuthorizationReq.PnC_AReqAuthorizationMode into an iso20_exiFragment.
3. Encode it with encode_iso20_exiFragment (canonical EXI???).
4. Compute SHA‑512 over the result.

Result:

• This digest matches the digest over kGoldenCanonicalAReqHex.
• It also matches the SECC runtime digest.
• It still does not match the EV’s DigestValue.

4. Fragment round‑trip (sanity check)

To make sure the canonical fragment bytes are at least valid EXI:

• Decode kGoldenCanonicalAReqHex as iso20_exiFragment using decode_iso20_exiFragment.
• Re‑encode that fragment using encode_iso20_exiFragment.
• Compare the re‑encoded bytes to the original canonical bytes.

Result: Passes. The bytes are valid EXI for iso20_exiFragment and stable under decode → encode.

---

What this seems to show

From my side:

• The pipeline wire EXI → iso20_exiDocument → iso20_exiFragment (PnC_AReqAuthorizationMode) → encode_iso20_exiFragment → SHA‑512 is deterministic and self‑consistent.
• The “canonical” fragment bytes cbexigen produces:
  • Are valid EXI for iso20_exiFragment.
  • Round‑trip cleanly through decode → encode.
• The only mismatch is between:
  • SHA‑512 over cbexigen’s canonical EXI bytes for PnC_AReqAuthorizationMode, and
  • The Keysight SL1550A EVCC’s DigestValue for #aReq.

That suggests a gap in how canonical EXI is implemented (or configured) in cbexigen for this case, or possibly a non‑conformant behavior on the EV side. I don’t have a second canonical‑EXI implementation wired in to say which is wrong, but the tests above make me reasonably confident my use of the generated code is consistent.

---

What I can share / questions

If it’s useful, I can provide:

• The raw wire AuthorizationReq EXI (hex).
• The canonical fragment bytes for PnC_AReqAuthorizationMode as produced by cbexigen (hex).
• The EV’s DigestValue and my local SHA‑512 digest, side‑by‑side.

A couple of questions:

1. Is the ISO 15118‑20 canonical EXI implementation in cbexigen considered complete and spec‑accurate at this point, or still experimental?
2. Is there anything obvious I might be missing in how I construct or encode the iso20_exiFragment for PnC_AReqAuthorizationMode?

Happy to provide captures and help iterate on tests if this is helpful for closing out canonical EXI support.

Thanks!

[jayharper]

@barsnick any updates on a timeline for -20 Canonical EXI support?

[gaohtao]

This is an example message of my running the ISO15118 project. The specified digest algorithm in it is SHA256.
{ "AuthorizationReq": { "Header": { "SessionID": "70935E65512500C1", "TimeStamp": 1639832808, "Signature": { "SignedInfo": { "CanonicalizationMethod": { "Algorithm": "http://www.w3.org/TR/canonical-exi/" }, "SignatureMethod": { "Algorithm": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256" }, "Reference": [{ "Transforms": { "Transform": [{ "Algorithm": "http://www.w3.org/TR/canonical-exi/" }] }, "DigestMethod": { "Algorithm": "http://www.w3.org/2001/04/xmlenc#sha256" }, "DigestValue": "P6U8ChkeAUxbQWdsOZriEpMThk4uUltqqqJVmorg++M=", "URI": "#id1" }] }, "SignatureValue": { "value": "MEUCIQD1Xg56OX6ZeedOAkInAH+e8BQsjz6X+f66D1/rM7J7kAIgdRMcEqyf8GretUjgpdU3EOXGz8An+LYui4rGGD8YL8Q=" } } }, "SelectedAuthorizationService": "PnC", "PnC_AReqAuthorizationMode": { "Id": "id1", "GenChallenge": "ZLGnObuVpxTwIw2FpfoGJQ==", "ContractCertificateChain": { "Certificate": "MIIBwTCCAWagAwIBAgICMEQwCgYIKoZIzj0EAwIwRTERMA8GA1UEAwwITU9TdWJDQTIxDzANBgNVBAoMBlN3aXRjaDELMAkGA1UEBhMCVUsxEjAQBgoJkiaJk/IsZAEZFgJNTzAeFw0yMTEyMTMxNzUyMzFaFw0yMzEyMTMxNzUyMzFaMEwxGDAWBgNVBAMMD1VLU1dJMTIzNDU2Nzg5QTEPMA0GA1UECgwGU3dpdGNoMQswCQYDVQQGEwJVSzESMBAGCgmSJomT8ixkARkWAk1PMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEprEx34ScKqlhmDnxWpVr2gvGpkeYWYIcNhsB6bzRHv2q2GOAny3ZIKnGA7w6bAoFtUGcdv28zPEHdwDnPLD05KM/MD0wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCA+gwHQYDVR0OBBYEFPsqauDurRehZO07aEE400vi38Q/MAoGCCqGSM49BAMCA0kAMEYCIQC0GZIDJFPhl1T3+iv45eaqI1yU+VJQzRNXkJIhVvbGcQIhANe5U5DGrdpY/iQGzBaSoNYTaIaAubA2su6FlEh6jXqx", "SubCertificates": { "Certificate": ["MIIBvjCCAWWgAwIBAgICMEMwCgYIKoZIzj0EAwIwRTERMA8GA1UEAwwITU9TdWJDQTExDzANBgNVBAoMBlN3aXRjaDELMAkGA1UEBhMCVUsxEjAQBgoJkiaJk/IsZAEZFgJNTzAeFw0yMTEyMTMxNzUyMzFaFw0yNTEyMTIxNzUyMzFaMEUxETAPBgNVBAMMCE1PU3ViQ0EyMQ8wDQYDVQQKDAZTd2l0Y2gxCzAJBgNVBAYTAlVLMRIwEAYKCZImiZPyLGQBGRYCTU8wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQTxYYRxcZCjuVyPdmdBDOIN4XAIhLAEqU18nytJv9gKqK8qjAY9ZcJVt7luvVhFBqGmKV4q9+67z8teZiSU9aLo0UwQzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUdIJK+LExa2RWMMgaSogHspahESAwCgYIKoZIzj0EAwIDRwAwRAIgY2ELqUsiMijWn3rsbDzfTYtsRq5iF+m2gxN6axtNLsoCIGnRymAFGPxc09rJ1uCcFywddwfY3Hv3qv0KrbskN0rs", "MIIBvjCCAWWgAwIBAgICMEIwCgYIKoZIzj0EAwIwRTERMA8GA1UEAwwITU9Sb290Q0ExDzANBgNVBAoMBlN3aXRjaDELMAkGA1UEBhMCVUsxEjAQBgoJkiaJk/IsZAEZFgJNTzAeFw0yMTEyMTMxNzUyMzFaFw0yNTEyMTIxNzUyMzFaMEUxETAPBgNVBAMMCE1PU3ViQ0ExMQ8wDQYDVQQKDAZTd2l0Y2gxCzAJBgNVBAYTAlVLMRIwEAYKCZImiZPyLGQBGRYCTU8wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS3mnLj5pBH5uikDz069wdLVJu3nPQDag3go//W34EfXJxrrAGhom+28ENfJ3OnlpQoRXczWixmV1BP68fpld/eo0UwQzASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHmF60L1Yj4tOnL5EAp68IZuzIB4wCgYIKoZIzj0EAwIDRwAwRAIgaMEAvbdVh/+sgIVcvKOSGxfIVIUycWpnguaOEIQBG+MCIEJPkZLdBJeW7r3rhLv7fvdM16FRHAlh2fxEGgm1f9EP"] } } } } }

[jayharper]

Update and resolution.

Re-verifying against a fresh 2026-04-07 Keysight SL1550A capture tells a different story from my December report. Stock upstream cbexigen (libcbv2g 0.3.1, no patches) produces canonical EXI output that is byte-identical to what the Keysight EVCC's current firmware emits. The SHA-512 over cbexigen's encoded fragment matches the EV's DigestValue for #aReq. The original mismatch I documented appears to have been a Keysight firmware issue that has since been resolved on their side.

I verified this end-to-end: unit tests pass and live hardware tests pass with the fresh fixture.

Canonical EXI support in cbexigen for ISO 15118-20 appears to be working correctly as-is for at least this Plug & Charge AuthorizationReq path. I also closed #126, which was attempting to add canonical machinery that turned out to be unnecessary.

From my side this issue can be closed, though I'll defer to the maintainers on whether to keep it open as a reference for others.