Skip to content
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

OID first two components encoded/decoded incorrectly #280

Closed
nealian opened this issue Aug 6, 2024 · 0 comments
Closed

OID first two components encoded/decoded incorrectly #280

nealian opened this issue Aug 6, 2024 · 0 comments

Comments

@nealian
Copy link

nealian commented Aug 6, 2024

I noticed what I believe to be an error in the ObjectIdentifier code for the first two components.

In the python-asn1 code, it seems like there is a (completely understandable) assumption that the first two OID components should each be <= 39.
It seems like the synopsis version on OSS's BER page is somewhat confusing.
However, going through to the actual specification, the rules are actually laid out somewhat clearer.

The specification for BER/DER are in ITU-T X.690, and specifically for OIDs in (02/2021) section 8.19.

The trick for the first "subidentifier" (series of octets encoding a single number) is that the separate (non-joint) roots for ITU-T and ISO (0.y and 1.y, respectively) only have immediate children with numerical value less than 40. However, this is not true for the joint root, 2.y.

The text of section 8.19.4 should then be read under this new light.

The numerical value of the first subidentifier is derived from the values of the first two object identifier components in the object identifier value being encoded, using the formula

$$ (X*40) + Y $$

where $X$ is the value of the first object identifier component and $Y$ is the value of the second object identifier component.

NOTE - This packing of the first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by $X = 0$ and $X = 1$.

My reading of this is that $X \le 2$, and, for $X = 2$, $Y$ can be arbitrarily large.

Indeed, they have an example in the following section (8.19.5), such that the example OID 2.999.3 (hey, it turns out that 2.999 is the OID you're supposed to be using for generic OID examples anyway!) is encoded into the decimal subidentifiers (1079, 3) and therefore bytes

b'\x06\x03\x88\x37\x03'

(This should address #279 as well, though the scope of this issue is a little larger.)

I am working on a PR to apply the necessary (and breaking) changes to the encoder, decoder, and tests.

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

No branches or pull requests

1 participant