Deno platform gaps: the deltic targets' expected-fail ledger

[lann]

The deltic runner legs (runtime-linked on stock Deno; lann/deltic#14 migration) run both conformance suites against Deno's crypto.subtle, which cannot serve five case classes the wasmtime/jco targets serve. All five are adversarially verified as raw-platform refusals (pure crypto.subtle probes, no host-module code in the loop — see lann/deltic#40 for the port and methodology):

class	cases	raw-platform evidence
imported 8192-bit RSA public keys unusable for verify	299 (rsassa-pkcs1-v15-sha256-8192/wycheproof, whole row minus 2 refusal-expected)	importKey/verify → SPKI cryptographic key data malformed (ring); Deno-minted 8192 keys verify fine
AES-GCM IV window limited to 96/128 bits	30 (10 tcIds × 3 stream variants, IVs 120–1024 bits) + probe/gcm-nonce-window, probe/gcm-full-parameters	direct encrypt probes
AES-CTR counter width limited to 32/64/128 bits	probe/ctr-known-answers	direct probe
RSA-OAEP unusable at non-standard modulus sizes	34 (…-2688/4032/3104…wycheproof-misc rows, fully)	pkcs8 import/decrypt refused
valid Constructed+EncryptionWithLabel OAEP ciphertexts refused	50 (tc33+ pairs at standard sizes)	raw decrypt → OperationError; plain-label vectors (tc8-10) decrypt fine

These are capability gaps, not defects in the host module — the natural representation would be gated features (the sha1-checked precedent). That path is blocked by the census freeze: every affected row is cutover-frozen (census-fixture.lock pins names+features verbatim; census_test.rs forbids drift), so tagging them means amending the frozen fixture — a maintainer call, proposed below. Until then the deltic targets carry exact-match expected-fail entries referencing this issue; the aggregate's stale-detection fires loudly if a Deno/ring update starts serving any of them.

Proposal for the maintainer: bless a one-time, reviewed amendment of the two census fixtures adding capability tags to the whole-row classes (rsa-verify-8192, rsa-oaep-odd-modulus), converting those 333 entries to missing-features scheduling. The partial-row classes (GCM IV window, OAEP constructed+label) stay expected-fail either way, or need row splits.

Upstream candidates (operator's call to file): Deno/ring 8192 imported-key verify; Deno OAEP constructed-ciphertext refusal.

[lann]

Proposal executed — with a correction. PR #353 (auto-merge armed):

• rsa-verify-8192 delivered as blessed: whole-row gated capability, census fixtures amended (301 entries, zero inventory change, dated header note), 299 ledger entries deleted, !feature decline case added, probe snippet committed at the feature declaration.
• rsa-oaep-odd-modulus was falsified before implementation — this issue's own table was wrong about the cause. Direct Deno probes: the 2688/4032/3104-bit keys import fine and round-trip OAEP fine, including with labels; the misc rows fail entirely because they consist entirely of Constructed+EncryptionWithLabel vectors (and the OAEP-8192 groups pass, ruling out modulus size in both directions). So there is exactly one OAEP class: valid Constructed+labeled ciphertexts refused (OperationError), 84 cases. All 84 stay expected-fail with corrected reason strings; a class feature can't tag the 50 that live in partially-failing rows (row-uniform tags), and splitting the class across two mechanisms for the 3 wholly-affected rows would obscure it.

Upstream candidates, revised: (1) Deno/ring: 8192-bit RSA public-key import refused; (2) Deno: RSA-OAEP decrypt refuses Wycheproof Constructed encoded-message vectors (valid ciphertexts crafted with unusual em structure — small integer / extreme hamming weight) — labels alone are handled fine. If Deno fixes (2), all 84 entries go stale together and the aggregate forces the cleanup.