Skip to content

[WIP] cms: test decoding of cms_ber.bin #1888

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Conversation

tarcieri
Copy link
Member

The files cms_ber.bin and cms_der.bin already checked into cms/tests contain test vectors showing a BER encoding with indefinite lengths and its DER equivalent.

The decoder now seems to be handling indefinite lengths, but can't handle decoding a constructed OCTET STRING with indefinite length (currently failing on the tag).

@tarcieri
Copy link
Member Author

@dishmaker looks like we now need something along the lines of #1821

The files `cms_ber.bin` and `cms_der.bin` already checked into
`cms/tests` contain test vectors showing a BER encoding with indefinite
lengths and its DER equivalent.

The decoder now seems to be handling indefinite lengths, but can't
handle decoding a constructed `OCTET STRING` with indefinite length
(currently failing on the tag).
@tarcieri
Copy link
Member Author

tarcieri commented Jun 22, 2025

I added basic handling of constructed OBJECT STRING tags which doesn't actually decode them but at least allows the existing implementation to get almost all of the way through the document:

Error { kind: Incomplete { expected_len: Length(10131), actual_len: Length(10130) }, position: Some(Length(10130)) }

I'm not sure why that would be happening exactly. It seems like some length is being miscomputed and it's trying to read too far into the message.

Edit: the total message is 10914 octets/bytes. Position 10130 appears to be a series of EOC markers, potentially implicating #1885 as being an incorrect solution

@tarcieri
Copy link
Member Author

tarcieri commented Jun 22, 2025

I tried effectively reverting #1885. That gave the following error:

Error { kind: TrailingData { decoded: Length(10910), remaining: Length(2) }, position: Some(Length(10910)) }

That's a little confusing because it seems to be longer than the total message length (10902)

The total message length is 10914, and the last 6 bytes are EOC markers. It seems we'll still need something (e.g. BerReader) to decode these constructed indefinite length fields and consume the EOC markers (as well as combining the segments of constructed string types into a single contiguous string).

That said, it's good to see it nearly getting to the end of the message.

@dishmaker
Copy link
Contributor

My implementation too almost go to the end. Im not an expert in BER, but the example payload might be wrong.

@tarcieri
Copy link
Member Author

@dishmaker I think the test vector is fine and the problem is the EOC markers aren’t being consumed.

My understanding is cms_ber.bin was created by Apple tooling, cms_der.bin is the same message converted from BER to DER, and cms has existing tests that can parse cms_der.bin

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