Complete independent security review of the new ES256 verification built-in

[logbie]

Required review

Track the independent security review required by testing.md for the R3 verify_es256 change before merge/release. This is a review task; it does not assert a discovered vulnerability in the new function.

Candidate and scope

The implementation is currently local on branch codex/es256-verification and has not been pushed, merged into main, installed system-wide or deployed.

• Red test-only commit: 79ab8be4ca602a54b11152cf0a3e3f0854db3f61.
• Green implementation: 68d66b93.
• Source candidate aligned with WFL 26.9.16 (23c1a457): 5126ccca.
• Verification record commit: 9bf3fa48.

Review the actual published candidate/PR once available; the hashes above identify the local evidence and are not currently public review links.

The new three-Text-to-Boolean built-in uses RustCrypto p256 to verify P-256/SHA-256 signatures over exact UTF-8 messages. It accepts hex-encoded 64-byte P1363 signatures and 65-byte uncompressed SEC1 public keys, with a 1 MiB message limit. It does not implement JWT/DPoP validation, key trust, authorization, replay prevention, revocation or executable attestation.

Review checklist

• Verify exact-byte/hash-once semantics and signature/key format interoperability.
• Check strict input parsing, malformed points/scalars, failure behavior, resource bounds and diagnostic redaction.
• Review dependency configuration and ECDSA signature malleability assumptions in downstream protocols.
• Confirm additive built-in registration, static/runtime contracts and preservation of existing identifiers/actions.
• Evaluate independently generated fixtures, negative tests and missing adversarial cases.
• Check documentation makes trust/protocol responsibilities explicit and does not overclaim authentication or executable identity.

Evidence and completion criteria

Local evidence includes 9 ES256 tests, 19 name-compatibility tests, 17 typechecker-contract tests, the real WFL test program and a validated documentation example. Full workspace, Clippy, formatting, documentation and HTTP/HTTPS checks passed. A separate database transaction integration timeout remains unresolved; a fuzz workspace compile check was performed, not a fuzz campaign.

• Make the candidate available to a reviewer independent of the implementation author.
• Record reviewer identity, exact reviewed revision, findings and resolution evidence.
• Add regression tests for any defects found, rerun affected gates, and obtain explicit approval.
• Retain the review record with the change and complete all other release gates.

Follow SECURITY.md for any vulnerability discovered during review; report such details privately.