fix(zvt_builder): decode EMV and 3 byte TLV tags - #61
Conversation
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..])); |
There was a problem hiding this comment.
we cannot represent the 3 bytes as u16 - maybe we should change the type of Tag to Tag(pub u32)
There was a problem hiding this comment.
or should we change that later on - and keep the 0x8000 encoding? - is that the idea?
There was a problem hiding this comment.
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.
Description
This change fixes how Default tag encoding reads and writes TLV/BMP tags so EMV fields like
0x9f5aand0x9f5bare 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 tags0x1f8000and0x1f8001, while keeping the existing two byte tag0x1f80behavior 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
0x8000and0x8001for round trip encode or decode, and new unit tests cover the single byte, 2 byte, EMV and 3 byte cases.Tests