nx_tls13_client.nx

nx_tls13_client.nx -- TLS 1.3 client state machine (Gap L sub-2). Phase 0b §L of the Nishi TLS 1.3 stack per docs/NISHI_TLS13_GAP_AUDIT.md. The dispatcher that walks the server's encrypted handshake records past ServerHello: each decrypted record body contains 1+ handshake messages, and this state machine consumes them in the order RFC 8446 §A.1 dictates: WAIT_EE -> EncryptedExtensions | WAIT_CERT -> Certificate | WAIT_CV -> CertificateVerify | WAIT_SF -> server Finished (verify MAC over transcript-before-SF) | CONNECTED At every stage the message goes into the transcript hash AFTER the stage-specific check passes -- except for server Finished, which verifies the MAC over the transcript-BEFORE-SF then feeds SF in. Getting that order wrong = MAC mismatch on a legitimate server (the bug that catches every from-scratch TLS impl). What it does today: - dispatch one decrypted handshake message per call - parse via shipped nx_tls13_auth + nx_tls13_finished - feed transcript in spec-ordered way - server_Finished MAC verify via constant-time compare - emit our client_Finished (36-byte handshake message: 4-byte header + 32-byte HMAC over transcript) - cert validation is INTENTIONALLY stubbed to "accept any" -- Gap I will replace the stub with real RFC 5280 path validation (chain build + signature chain verify + name constraints + SAN match + validity period) What it doesn't do yet: - signature verification on CertificateVerify (composes against nx_ed25519 / nx_ecdsa / nx_rsa_pss; Gap I) - CertificateRequest (mutual TLS client-auth; rare)