Add WOLFSSL_X509_TINY minimal-extension profile + WOLFSSL_X509_VERIFY_ONLY

[aidangarske]

Two opt-in, macro-driven profiles for the template X.509 parser. WOLFSSL_X509_TINY strips optional extension/SAN decoding (with per-feature WOLFSSL_X509_TINY_* add-backs); WOLFSSL_X509_VERIFY_ONLY drives a verify-only footprint. Fail-closed on critical/nameConstraints, revocation locators forced when OCSP/CRL enabled. Default build byte-identical; includes a TINY cert test.

Saves ~3.4 KB off the reachable P-256 cert parser (asn.c __TEXT 59,673 -> 56,221 bytes, -Os; ~5.8%). with other size option we can get to aprox 18% down with WOLFSSL_X509_TINY, WOLFSSL_X509_VERIFY_ONLY, IGNORE_NAME_CONSTRAINTS, WOLFSSL_NO_ASN_STRICT

[github-actions]

retest this please

[github-actions]

MemBrowse Memory Report

stm32-sim-stm32h753

• FLASH: .text -64 B (-0.0%, 183,076 B / 2,097,152 B, total: 9% used)
  No memory changes detected for:
• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• linuxkm-standard

[dgarske]

Skoll Code Review

Scan type: reviewOverall recommendation: COMMENT
Findings: 5 total — 2 posted, 3 skipped
2 finding(s) posted as inline comments (see file-level comments below)

Posted findings

• [Info] Stale/misleading #endif comment on the reworked NAME_CONS_OID guard — wolfcrypt/src/asn.c:21278
• [Info] Inconsistent preprocessor-directive indentation in reworked extension guards — wolfcrypt/src/asn.c:21252-21310

Skipped findings

• [Medium] WOLFSSL_X509_VERIFY_ONLY silently undefines an explicit user WOLFSSL_KEY_GEN/WOLFSSL_CERT_GEN
• [Medium] TINY hard-rejects any certificate carrying nameConstraints, including trusted CA certs
• [Low] Test coverage: cert_x509_tiny_test does not exercise VERIFY_ONLY or SAN-stripping/add-back paths

Review generated by Skoll

[dgarske]

Config	__TEXT bytes	vs baseline
baseline (neither macro)	56,535	-
WOLFSSL_X509_VERIFY_ONLY	53,747	-2,788 (-4.9%)
WOLFSSL_X509_TINY	53,767	-2,768 (-4.9%)
both	50,979	-5,556 (-9.8%)

[dgarske]

These new ASN options need to be documented at top of asn.c:

• WOLFSSL_X509_VERIFY_ONLY - drops cert/key generation and forces WOLFSSL_NO_PEM unless a gen add-back (WOLFSSL_X509_CERT_GEN/WOLFSSL_X509_KEY_GEN) or WOLFSSL_X509_PEM is set.
• WOLFSSL_X509_TINY - compiles out optional X.509 extension decoders behind per-feature WOLFSSL_X509_TINY_<F> add-back macros. Requires WOLFSSL_ASN_TEMPLATE (enforced with #error).

[dgarske]

WOLFSSL_X509_VERIFY_ONLY forces WOLFSSL_NO_PEM, which disables WOLFSSL_PEM_TO_DER (confirmed in settings.h). A verify-only TLS client that loads its trust anchors in PEM (wolfSSL_CTX_load_verify_locations / ..._buffer with ..._FILETYPE_PEM) loses PEM decoding and can only load DER anchors. There is an escape hatch - define WOLFSSL_X509_PEM (or a gen add-back) to keep PEM - but it is opt-in and non-obvious. This is a functional footgun to document prominently, not a verification-logic hole.

[dgarske]

TINY + WOLFSSL_NO_ASN_STRICT can silently accept a critical stripped extension (low severity, but an inconsistency). The fully removed cases - CRL-DP, certificatePolicies, inhibitAnyPolicy, policyConstraints, Netscape, OCSP no-check - fall through to default:, and default: only rejects a critical-unknown extension inside #ifndef WOLFSSL_NO_ASN_STRICT. So under WOLFSSL_NO_ASN_STRICT, a critical policyConstraints/inhibitAnyPolicy/CRL-DP is ignored rather than rejected. By contrast AKI/SKI/AIA (explicit stubs) and NAME_CONS reject unconditionally. The practical security impact is limited: wolfSSL parses policyConstraints/inhibitAnyPolicy only into flags (extPolicyConstRxpSet etc.) and never enforces the RFC 5280 6.1 policy tree in the verify path, so what is lost is the RFC 5280 4.2 "MUST reject an unrecognized critical extension" strictness, not active enforcement. Still, the inconsistent fail-closed behavior across the stripped set is a rough edge. Suggest either a build-time #warning/#error on WOLFSSL_X509_TINY && WOLFSSL_NO_ASN_STRICT, or give the fully-removed cases the same unconditional critical-reject stub as AKI/SKI/AIA.

[aidangarske]

Fixed so when TINY is on, a critical extension it can't decode is always rejected with ASN_CRIT_EXT_E, regardless of NO_ASN_STRICT