nx_x509_leaf_check.nx

nx_x509_leaf_check.nx -- single-cert "leaf" orchestrator. Composes the three shipped X.509 primitives: - x509_parse (nx_x509.nx) - x509_validity_check (nx_x509_validity.nx) - x509_san_match_hostname (nx_x509_san.nx) into one call that callers (nx_https_client + future chain walker) use to validate a single leaf cert against a hostname + clock. What this DOES verify (today, this commit): - DER parses cleanly per RFC 5280 §4.1 - now_epoch_secs is within [notBefore, notAfter] - hostname matches a SAN dNSName entry (RFC 6125 §6.4) What this DOES NOT verify (separate primitives, queued): - signature_algorithm OID is one of the supported set (caller-driven via cert.sig_alg_off/_len + per-alg verifier) - signature value matches the cert's tbs under a trust-anchor pubkey (chain walk + ECDSA-P256 verify queued) - revocation status (OCSP / CRL -- separate primitives) - extension-criticality checks (every extension marked critical must be understood by the validator -- iterator queued) - certificatePolicies, basicConstraints, keyUsage, extendedKeyUsage (queued) The leaf-check verdict therefore answers "is this cert well-formed AND within its validity period AND covering the hostname I asked for" -- it does NOT answer "should I trust this cert". A chain walker that establishes trust calls nx_x509_leaf_check for every cert in the path PLUS its own signature verify. This split keeps single-responsibility (Cardinal 9) clean. license_tier: INDEPENDENT_REDERIVE genealogy_id: international-research-sources/ietf/rfc_5280 lineage_id: nishi_x509_leaf_check_q10