d2i_X509 rejects certificates with NameConstraints minimum/maximum >= 128

[afldl]

Bug

d2i_X509() returns NULL on any certificate whose NameConstraints extension has a minimum or maximum field value of 128 or higher.

Cause

DecodeSubtree() in wolfcrypt/src/asn.c decodes these BaseDistance INTEGERs with GetASN_Int8Bit(), which only accepts single-byte DER encoding (len == 1). Values 0–127 encode in one byte; values 128+ need two bytes (leading 00 sign octet), triggering ASN_PARSE_E.

Reproduction

minimum=0   (DER: 80 01 00)      → d2i_X509 succeeds
minimum=1   (DER: 80 01 01)      → d2i_X509 succeeds
minimum=127 (DER: 80 01 7f)      → d2i_X509 succeeds
minimum=128 (DER: 80 02 00 80)   → d2i_X509 returns NULL
minimum=255 (DER: 80 02 00 ff)   → d2i_X509 returns NULL
maximum=128 (DER: 81 02 00 80)   → d2i_X509 returns NULL

I can provide test certificates (DER) and a minimal harness if helpful.

Fix

GetASN_Int8Bit → GetASN_Int16Bit, byte → word16 for minVal/maxVal. Same GetASN_Int16Bit pattern is already used for BasicConstraints pathLength in the same file. The decoded values are not consumed by NC matching anyway, so this is purely a parsing fix.

-        byte minVal = 0;
-        byte maxVal = 0;
+        word16 minVal = 0;
+        word16 maxVal = 0;
...
-        GetASN_Int8Bit(&dataASN[SUBTREEASN_IDX_MIN], &minVal);
-        GetASN_Int8Bit(&dataASN[SUBTREEASN_IDX_MAX], &maxVal);
+        GetASN_Int16Bit(&dataASN[SUBTREEASN_IDX_MIN], &minVal);
+        GetASN_Int16Bit(&dataASN[SUBTREEASN_IDX_MAX], &maxVal);

Notes

• wolfSSL version: 5.9.1 (also present on master as of today)
• RFC 5280 §4.2.1.10 says conforming CAs MUST NOT issue certs with min/max, but a parser should still accept valid DER
• No crash or security impact — graceful ASN_PARSE_E return
• Not marking as security issue since the failure rejects rather than accepts