You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Botan cannot store OIDs with large subidentifiers. The standard (ITU-T X.660, ITU-T X.680) does not limit the number range on any subidentifier other than the root arc and some secondary identifiers.
For example, 2.299.62133450347103072435436460230495464564354 is a valid OID, but cannot be stored by Botan. That is, because Botan stores the subidentifiers as uint32_t.
While the above example may be unrealistic, there's a valid use-case for 128bit numbers: Arc 2.25. allows for UUIDs to be embedded inside its OID (see ITU-T X.667 and http://oid-info.com/get/2.25).
TBH I had not heard of this 2.25 arc before for UUIDs. I'd be pretty inclined to go with "that's interesting but I doubt anyone uses it", especially as RFC 5280 only requires implementations support OID elements up to 2^28, but I see for example Go has recently introduced a new OID type to handle such UUIDs in certificate policies. :/
Botan cannot store OIDs with large subidentifiers. The standard (ITU-T X.660, ITU-T X.680) does not limit the number range on any subidentifier other than the root arc and some secondary identifiers.
For example,
2.299.62133450347103072435436460230495464564354
is a valid OID, but cannot be stored by Botan. That is, because Botan stores the subidentifiers asuint32_t
.While the above example may be unrealistic, there's a valid use-case for 128bit numbers: Arc
2.25.
allows for UUIDs to be embedded inside its OID (see ITU-T X.667 and http://oid-info.com/get/2.25).See also: https://misc.daniel-marschall.de/asn.1/oid_facts.html#chap4
The text was updated successfully, but these errors were encountered: