Skip to content

fix(zvt_builder): decode EMV and 3 byte TLV tags - #61

Open
0xmuon wants to merge 2 commits into
EVerest:mainfrom
0xmuon:fix3
Open

fix(zvt_builder): decode EMV and 3 byte TLV tags#61
0xmuon wants to merge 2 commits into
EVerest:mainfrom
0xmuon:fix3

Conversation

@0xmuon

@0xmuon 0xmuon commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Description

This change fixes how Default tag encoding reads and writes TLV/BMP tags so EMV fields like 0x9f5a and 0x9f5b are handled as proper two byte tags instead of being misread as a single byte tag with leftover bytes. It also adds support for the specs three byte tags 0x1f8000 and 0x1f8001, while keeping the existing two byte tag 0x1f80 behavior when the third byte is not one of those defined value.

The internal Tag type stays as u16 for now,with the 3byte wire forms mapped to 0x8000 and 0x8001 for round trip encode or decode, and new unit tests cover the single byte, 2 byte, EMV and 3 byte cases.

Tests

  • cargo test -p zvt_builder
  • cargo test --all

0xmuon added 2 commits August 11, 2026 14:57
Handle 0x9fxx two-byte tags and spec 0x1f8000/0x1f8001 three-byte tags
in Default Tag encoding per PA00P015 section 9.4.1.

Signed-off-by: Rudraksh Joshi <rudrakshjoshic@gmail.com>
Handle 0x9fxx two-byte tags and spec 0x1f8000/0x1f8001 three-byte tags
in Default Tag encoding per PA00P015 section 9.4.1.

Signed-off-by: Rudraksh Joshi <rudrakshjoshic@gmail.com>
&& (rest[1] == 0x00 || rest[1] == 0x01)
{
let tag = u32::from_be_bytes([first, rest[0], rest[1], 0]) >> 8;
return Ok((Tag(tag as u16), &rest[2..]));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we cannot represent the 3 bytes as u16 - maybe we should change the type of Tag to Tag(pub u32)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or should we change that later on - and keep the 0x8000 encoding? - is that the idea?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the 0x8000/0x8001 thing, I did that on purpose to keep this PR small and avoid breaking the API,but still parse those two 3 byte tags from the spec correctly on the wire. You are right though, it's not a great internal representation since the real tag values don't fit in a u16 anyway.

The important part of this change is really the 0x9fxx EMV tags, which work fine as 2 byte tags. For the 3 byte ones, I am fine either widening Tag to u32 in this PR or landing the EMV fix first and doing that as a follow-up whatever you prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants