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?