nx_x509_emit.nx

nx_x509_emit.nx -- F103e RUNG 9: author a SELF-SIGNED X.509 v3 certificate. The cert that will carry our Secure Boot key. Real EDK2 with MS keys refuses our unsigned .efi (Access Denied) while the same secboot firmware in SETUP mode runs it, so the blocker is the enrolled key set (debt 1786237435). Enrolling means putting a CERT in db. ★OIDs ARE DERIVED, NOT RECALLED. An OID written as a byte string from memory is a fabricated constant. Here `der_oid_from_arcs` ENCODES the arc numbers (X.690 §8.19: first byte = 40*a1 + a2, then base-128 with continuation bits) -- and T1 validates that encoder against a known-good encoding the estate already ships: the SHA-256 OID sitting inside the incumbent's `rsa_pkcs1_sha256_di_byte` DigestInfo table. ★★★★★★**ONE VERIFIED ENCODER TURNS EVERY OTHER OID FROM A REMEMBERED BYTE STRING INTO A DERIVED RESULT — AND THE ARC NUMBERS ARE SPEC FACTS, WHICH THE ENCODER THEN PROVES.** ★THE ORACLE IS THE ESTATE'S OWN READER, END TO END: emit -> `x509_parse` must accept and report a tbs region -> our signer signs exactly that region -> the incumbent `rsa_pkcs1_v1_5_sha256_verify` must accept. Four independently written pieces agreeing. A cert that only round-trips through its own emitter proves nothing. Structure (RFC 5280): Certificate ::= SEQUENCE { tbsCertificate, signatureAlgorithm, signatureValue } TBSCertificate ::= SEQUENCE { [0] v3, serial, sigAlg, issuer, validity, subject, SPKI } ⚠extensions ([3] basicConstraints CA:TRUE) are NOT emitted yet -- named as owed rather than silently absent, because a db entry does not require them but a KEK/PK chain will. Usage: nx_x509_emit selftest Exit: 0 GREEN | 1 RED. Log -> knowledge/status/nishi_os.log, verdict= LAST. license_tier: ORIGINAL