CC @golang/security.

From https://go-review.googlesource.com/c/crypto/+/365674 done for #49678 it follows that int element can not be greater than 2^31-1.
Interestingly that decoder was "fixed" but not the encoder.

Dupe of #30757, #36467, and #38737. By design asn1.ObjectIdentifier does not support OID components that are larger than 31 bits. Due to backwards compatibility constraints, there is no clear path forward to fix this.

It should be possible to support larger than 2^31 values on the platforms where sizeof(int) > 32 (https://pkg.go.dev/encoding/asn1#ObjectIdentifier is defined as []int) similar to Marshal that supports values up to maxInt.
The problem is that behavior would be different depending on the int size of the platform, i.e. large values would not work on 32 bit platforms (also not sure if Marshal errors in that case).

Right, we make a conscious choice to limit to the lower of the two possibilities so that there aren't certificates (or other ASN1 based protocols) which only work on 64 bit platforms.

We also run into the same issue with a user trying to parse a certificate from a Windows CA. Do you think it would be possible to add a asn1.ObjectIdentifier64 (or similar) which can handle those larger Oids? Maybe by switching the target certificate field (with the new field-type) explicitly using an "option" for x509.ParseCertificate...

When you say "Windows CA" do you mean a CA managed by Microsoft? Do you happen to know what the offending OID is?

Right, we make a conscious choice to limit to the lower of the two possibilities so that there aren't certificates (or other ASN1 based protocols) which only work on 64 bit platforms.

I've created a fix in case this decision changes
golang/crypto@master...AlexanderYastrebov:crypto:go58821

Thanks @AlexanderYastrebov for the effort.

I hope to reconsider the decision of // We don't want different behavior based on the architecture. (from the code comment) given that there are multiple issue reports like this. If we still keep current 32-bit golang programs' behavior by supporting larger Oid number on 64-bit platform, we don't break anything, we just make 64-bit programs not break in such cases.

@rolandshoemaker I linked the issue we have open in Telegraf influxdata/telegraf#12684. Citing @skinfrakkiirid:

I can't share the certificate due to where I work, however this certificate differs by being issued from a local Windows CA[...]

he also provided the policy section of the cert

X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:dnsserver1, DNS:dnsserver2 IP Address:address1, IP Address:address2
X509v3 Subject Key Identifier:
98:FF:66:3C:58:26:36:A1:F5:CB:C2:B3:BC:3C:33:90:3E:8A:5E:80
X509v3 Authority Key Identifier:
keyid:13:57:08:E7:5E:7E:92:45:E9:AF:CC:80:B2:D5:D2:A4:E2:30:8

I hope to reconsider the decision of // We don't want different behavior based on the architecture. (from the code comment) given that there are multiple issue reports like this. If we still keep current 32-bit golang programs' behavior by supporting larger Oid number on 64-bit platform, we don't break anything, we just make 64-bit programs not break in such cases.

Unfortunately, this solution won't support the 128 bit long 2.25 OID subtree (as mentioned in #30757) so you would end up with a bit more certificates working on 64 bit architecture but not all certificates.

I think this deserves a real solution where all certificates are supported by Go.

It's really sad that a 4 years old issue has still no clear solution forward. Also I don't understand why #39795 has been closed.

#60665 suggests a path forward on this.