-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Support for UUID OIDs in X509v3 extensions #11338
Comments
As you noted, we've come across this before. We actually widened arc support up to 63-bits, but we've so far chosen not to support the UUID arcs. Are they seeing adoption in a standard somewhere? What do people do in (very large) ecosystems like Go where 28-bit arc limits are enforced? |
Is this 63-bit support implemented in a version that is yet to be released? In version 43.0.0 I'm still seeing the following behavior on anything exceeding 32 bits:
My research didn't really turn up a whole lot beyond what I already shared in my previous post. An organization named IHE seems to be recommending their use in the medical sphere, but perhaps not in an X509 context. Other than that, they're convenient when you need an OID and going through the IANA PEN application is either inconvenient or impossible, e.g. when dynamically generating CAs/certificates on behalf of customers (the case we find ourselves in).
I wouldn't be able to say. We just came across the first integration issue, and the customer organization happens to be using Python. I guess that if we come across a Go integration problem, I'll go to their GitHub page and try my "pretty please" approach there too 😀 |
Just out of curiosity: is there a reason you can't go through the PEN application once, and then assign sequential/bucket-delegated OIDs to your customers under your PEN arc? (Edit: I ask because I went through it once, and it took them ~5 days to allocate me an arc. From there, I believe there are no sub-arc restrictions 🙂) |
My mistake, we do still limit to 32-bit values. 63 bytes is the limit of a serialized DER representation. |
Yeah, we're considering that option. Just needs a fair bit of refactoring and paperwork. (The paperwork mostly due to my employer's requirements...) |
Previously discussed in #6573 -- given other implementations have similar limitations, I'm disinclined towards supporting these. |
After discussing with @reaperhulk, we'd be willing to take a PR (which would go to rust-asn1 in the first instance) which added support for 128-bit OID arcs. |
There seems to have been a regression in
cryptography
38.0.0 where OIDs with a bit length exceeding 32 bits are no longer supported. More specifically, using a UUID OID (subtree 2.25) in a certificate's SAN extension causes parsing errors that were not present in version 37.0.4 and lower.For comparison, this worked in version 37.0.4:
While it fails in version 38.0.0:
To paraphrase this related issue, OID maximum length is a messy topic. There is no real maximum depth/length limit for OIDs in general, but the X509v3 specification seems to only require support of OID arc lengths up to 28 bits.
In that sense, the current issue falls somewhere between a regression bug and a feature request: it would be nice if
cryptography
could again support OID arcs up to 128 bits, as this would allow support for OID subtree 2.25. Since OpenSSL supports these OIDs, and rust has a nativeu128
datatype, it seems doable, but I'm not equipped to perform an actual impact analysis.For what it's worth, I also came across this study comparing UUID OID support across various implementations.
Version information (all packages installed in a virtual environment):
python
3.10.12cryptography
43.0.0 (same issue going back to 38.0.0)cffi
1.16.0setuptools
59.6.0The text was updated successfully, but these errors were encountered: