crypto/x509: ParseOID is slow on very large textual OID components

[jvdprng]

Description

ParseOID accepts textual OID input and converts decimal components into DER. Very large decimal components can make parsing unexpectedly slow and allocation-heavy. No concrete remote trust boundary or security impact has been shown.

This is separate from binary DER OID parsing; it concerns textual OID APIs.

Specification or documentation

This is primarily a Go API robustness and performance edge case. The API does not document resource limits for unusually large textual OID components.

Code references

• go/src/crypto/x509/oid.go:27 defines ParseOID.
• go/src/crypto/x509/oid.go:92 through go/src/crypto/x509/oid.go:95 shows big-integer DER length handling used for large components.
• go/src/crypto/x509/oid.go:180 through go/src/crypto/x509/oid.go:184 appends base-128 big integer encodings into the OID DER buffer.

Test case

This should be a Go unit or fuzz regression test for ParseOID, using an input such as 1.2. followed by thousands of decimal digits. The expected behavior should be either successful parsing within reasonable bounds or a clear error without avoidable quadratic work.

It could be a parser fuzz-corpus seed for the OID text APIs.

[gabyhelp]

Related Issues

• crypto/x509: OIDFromInts can overflow the first subidentifier for large 2.x OIDs #79857
• crypto/x509: introduce new robust OID type & use it for certificate policies #60665 (closed)
• crypto/x509: parsers accept trailing DER inside several X.509 structures #79860
• encoding/asn1: ObjectIdentifier + crypto/x509.ParseCertificate does not support int > 28 bits #19933 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[jvdprng]

Playground reproducer: https://go.dev/play/p/xKfsqRvrHMb

The repro prints the DER output size and allocation growth for increasingly large decimal OID components. Larger inputs such as 20k or 30k digits amplify the effect further, but can hit Playground execution timeouts.

[cherrymui]

cc @golang/security

[rolandshoemaker]

Most of the complexity here comes from the fact that in order to parse OIDs we need to parse arbitrary length integers into the base 128 DER form. Because arbitrary length integers are annoying, we use the math/big package, which is allocation heavy. We could plausibly improve the performance of this by first converting the integer into packed binary words, and then converting that array of words into the base 128 DER form, but that still wont be particularly cheap (I implemented this, and it's faster, but its a lot of somewhat complex code).

Probably we should document that this function is not highly optimized and maybe is not intended to be used in hot paths for arbitrary OIDs and is mostly a helper function, but that is slightly complicated by the fact that we implemented UnmarshalText, so people reasonably could be doing this.