So another lesson had been relearned from asn.1. I'm proud of working in this industry again! Next we will figure out to always put versions into the data too
I would say two problems with the asn.1 approach are: (1) it seems like too much cognitive overload for the OIDs to have semantic meaning, and it invites accidental reuse; I think it matters way more that the OIDs are unique, which randomness gets you without much effort; and (2) the OIDs aren't always serialized first, they are allowed to be inside the message, and there are failures that have resulted (https://nvd.nist.gov/vuln/detail/cve-2022-24771, https://nvd.nist.gov/vuln/detail/CVE-2025-12816)
(edit on where the OIDs can be, and added another CVE)
OIDs have to be unique just enough to not fall into the wrong parsing/validating path in the same system, which isn't that hard.
>Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.3.0, RSA PKCS#1 v1.5 signature verification code is lenient in checking the digest algorithm structure
That's on brand for the javascript world, yes.
With asn1 being a can of worms, at least it's a can of worms with a reputation, unlike this nice magic trick.
Disclaimer: there exists a PR filled under my name into an asn.1 parser that fixes a bug, which is not merged since October 2022.
Those CVEs seem a little more subtle than OID serialization issues. In the first example there are actually two distinct problems in concert that lead to the vulnerability, one of which is when a "low public exponent" is used.
It seems like in that PR, the fact that the OID wasn't checked is part of the problem. I think a better system wouldn't compile or would always fail to verify if the OID (domain separator) is wrong, and I think you'd get that behavior in the posted system.
This is Bleichenbacher's rump-session e=3 RSA attack. It's pretty straightforward, and is in Cryptopals if anyone wants to try it. If you don't check all the RSA padding, and you use e=3, you can just take an integer cube root.
(edit on where the OIDs can be, and added another CVE)