3 ms·
In this case it's definitely ASN.1; the problem is that "objects" are defined with OIDs, which are sequences of integers (called arcs numbers) like { 1 2 840 11
by alricb 11y ago
In this case it's definitely ASN.1; the problem is that "objects" are defined with OIDs, which are sequences of integers (called arcs numbers) like { 1 2 840 113549 1 }. The first integer is always 0, 1 or 2, and with 0 or 1, the second is between 0 and 39. But the other integers can be arbitrarily large, and it's important not to overflow: https://www.viathinksoft.de/~daniel-marschall/asn.1/oid_facts.html#chap7 https://www.viathinksoft.de/~daniel-marschall/asn.1/oid_fact...
You need to use some sort of bignum function if you want to display large arc numbers in decimal. Which is what OpenSSL and LibreSSL do, and that involves creating and destroying BIGNUM objects. The problem is that someone in LibreSSL moved the free() to outside the loop body handling the arc numbers while they were cleaning up. So only the last BIGNUM used gets freed.
Oh, did I tell you that arc numbers are encoded in base 128, with the first bit of every octet used to signal whether it's the last octet of that arc number? Because they are.
- masklinn 11y agoWell these are ASN.1 facts I did not need to know and I would like to not subscribe to that mailing list, but regardless thank you for the explanation.
- MichaelGG 11y agoWhy does ASN.1 allow such large arc numbers? Is this a result of being designed before a reasonable (32 bit) word size was common enough to depend on? Ie that everyone would have to implement "bignum" so might as well set no limit? It still seems questionable that they'd let any length be set, especially since you can just chain numbers together into a longer OID. Base128 encoding seems fair though; the other varint formats are more exotic and only work with many ints at once.
- masklinn 11y ago> Why does ASN.1 allow such large arc numbers? Is this a result of being designed before a reasonable (32 bit) word size was common enough to depend on? Ie that everyone would have to implement "bignum" so might as well set no limit? I assume that's because OID nodes are essentially namespaces, giving an arbitrary upper bound to node ids would artificially and "unnecessarily" limit the size of the corresponding namespace. That looks like a "correct versus realistic" debate which was won by the "correct" side.