Signed-JAR trust boundary

Scope: classloading/src/jar_signer.rs and the signature/manifest paths of classloading/src/class_path.rs. Companion: crypto-failure-contract.md — the same rule applied one layer down, in native-builtins-crypto.

---

0. Verdict

Signed JARs are not a trust boundary in this VM. Do not use Class.getCodeSource().getCertificates() as an authorisation input.

The reason is not, as the P0 report assumed, that certification-path validation is absent. It is largely present, and this audit deliberately does not blanket-reject working functionality. The residual reasons are narrower and are enumerated in §4:

1. No revocation checking at all. No CRL, no OCSP. A signer certificate that its issuer revoked this morning still validates. This is the single biggest gap and it is unconditional.
2. No name-constraint or certificate-policy processing.
3. Only the first SignerInfo of a signer block is examined — a multi-signer JAR collapses to "the first signer verified".
4. Anchor provenance is only as good as the host. With no JAVA_HOME/lib/security/cacerts, no javax.net.ssl.trustStore and no CRATONVM_TRUST_PEM, the process trust store has zero anchors and every JAR is reported unsigned. That is fail-closed and safe, but it means the presence or absence of a signer says as much about host configuration as about the JAR.

What is complete is stated just as precisely, because refusing to say so would be its own kind of dishonesty: the CMS walk, the .SF binding, the SignerInfo public-key check, path construction to an anchor with per-link signature verification, validity windows, the RFC 5280 BasicConstraints / KeyUsage / ExtendedKeyUsage / unknown-critical rules, the manifest→entry digest chain, and the per-entry gate that stops an entry absent from the manifest from inheriting the signer's identity. Those checks are real and are worth keeping.

---

1. Audit table

Every API by which a caller could conclude "this JAR/entry is signed by a trusted party". T = trust-establishing, I = integrity-only.

1.1 classloading/src/jar_signer.rs

1.2 classloading/src/class_path.rs

---

2. The three-valued result contract

The core fix. jar_signer.rs:1665 called verify_rsa_pkcs1_v15, a bool wrapper, and mapped false onto SigVerify::Bad.

A bool cannot express the difference between:

• "we checked and the answer is no" — the padded digest did not match. This is a security decision, and it is what a forgery looks like.
• "we never checked" — the key was rejected before any RSA operation ran.

The backend rejects an even exponent, e < 2, e > 2³³−1, and any modulus over RsaPublicKey::MAX_SIZE (4096 bits). A JAR signed with an entirely legitimate 8192-bit key therefore came back false and was reported as "SignerInfo signature does not verify against signer public key" — an accusation of tampering levelled at a JAR nobody had examined.

The contract

SigVerify (jar_signer.rs:1424) is the three-valued result. It is private to the module; every call site matches all three arms explicitly, and there is no _ => arm that a future fourth state could default into.

Unsupported now covers every "no verification happened" cause:

• algorithm OID not recognised (sig_alg_digest → None);
• algorithm recognised, key type/curve not carried (P-521, Brainpool, explicit ECParameters, DSA with a digest other than SHA-1/256, key/family mismatch);
• SubjectPublicKeyInfo will not parse (was Bad);
• the backend rejected the key — including the legitimate >4096-bit case (was Bad);
• the signature encoding is malformed — wrong length for the modulus, or an undecodable DER SEQUENCE { r, s } (was Bad).

Both Bad and Unsupported refuse. They are propagated as distinct outcomes all the way out — TrustError::BadSignature vs TrustError::NotImplemented, and two different parse_signed_data messages — so no caller can conflate them, and a diagnostic never claims a verdict that was not reached.

Sites changed

Did the migration change any accept/reject decision? No. Every affected path already refused, and still refuses. What changed is that the refusal now names the right reason, and an over-large-but-legitimate signer key is diagnosable instead of looking like a tampered JAR. This is the "safe today, imprecise today" item closed from crypto-failure-contract.md §4.2 / gap 5.

---

3. Other trust-boundary changes in this pass

3.1 chain is now the validated path, not the CMS bag

verify_chain returned Result<(), TrustError>, so verify_signer_block had nothing to narrow with and passed the entire CMS certificates set out as VerifiedSigner.chain. class_path::extract_jar_signer_blocks pushed every element of that into the CodeSource certificate array.

The CMS certificates field is attacker-supplied. An attacker could append a certificate of their choosing to an otherwise legitimately signed JAR: path construction ignores it (correctly), but it was still surfaced through Class.getCodeSource().getCertificates() as one of the signer's certificates — enough to fool a policy signedBy filter that scans the array rather than looking only at element 0.

verify_chain_path (:3074) now returns the certificates that actually formed the path, leaf first and anchor last, appending each only after its link signature, validity window and extension checks have passed. verify_chain delegates to it and is behaviourally identical, so the fuzz_signed_jar oracle (zero-anchor store ⇒ verify_signer_block returns None, verify_chain returns Err) is untouched. verify_signer_block narrows vs.chain to that path.

Covered by tb_unvalidated_certificates_are_not_surfaced_as_the_signers.

3.2 cert_dates_ok fails closed on an unreadable validity window

It previously returned true when parse_asn1_time could not read a bound — "conservatively treat the cert as valid on the date axis". That is the same did-not-check-reads-as-checked conflation as the bool above, one level up: it recorded in date for a certificate whose dates were never examined.

RFC 5280 §4.1.2.5 admits exactly two encodings and parse_asn1_time accepts both, so every conforming certificate still parses. What is now rejected is a certificate with a missing, truncated, or non-Time validity field — structurally tolerated by X509Cert::parse, emitted by no CA.

Covered by tb_unreadable_validity_window_rejects.

---

4. Residual gaps

Ordered by exposure. Until items 1 and 2 exist, §0's verdict stands.

1. Revocation (CRL / OCSP) is not implemented. RFC 5280 §6.3 is absent entirely. A certificate that chains and is in-validity is accepted even if its issuer revoked it. This matches stock HotSpot jarsigner absent an explicit -revCheck, and revocation needs network I/O the class loader deliberately avoids — but the consequence is unchanged: a compromised code-signing key cannot be un-trusted short of removing its anchor. Closing it needs a CRL/OCSP fetcher, a cache with a freshness policy, and a decision about soft-fail vs hard-fail (soft-fail would reintroduce exactly the "we did not check" ambiguity this document is about, so it must be hard-fail or configurable-and-loud).

2. NameConstraints, certificate policies, policy mapping, policy constraints. Not implemented. Partly mitigated: nameConstraints is marked critical by CAs, and an unrecognised critical extension is rejected outright (extract_ext_facts :2881, RFC 5280 §6.1.4(f)), so an unprocessed one cannot silently broaden trust. A non-critical nameConstraints is ignored.

3. Only the first SignerInfo is verified. A multi-signer JAR reports "first signer verified"; the others are neither verified nor reported.

4. Parent selection is by Subject/Issuer DN only. AuthorityKeyIdentifier is parsed as a recognised extension but not used to disambiguate, so with two certificates sharing a Subject DN the first in slice order wins. Both still have to pass the signature check, so this cannot create a forged path — it can only fail to find a valid one.

5. Anchor provenance and clock. Anchors come from host files (cacerts, javax.net.ssl.trustStore, CRATONVM_TRUST_PEM) or the extend_from_anchors seam. Validity windows are compared against SystemTime::now() — an attacker who controls the clock controls expiry.

6. native-builtins/src/crypto_impl.rs:2225 still calls the bool wrapper. Out of scope for this pass (that tree was not editable here). It is fail-closed, but it carries the same ambiguity this document removed from the class loader, and it should be migrated to verify_rsa_pkcs1_v15_checked.

7. DSA digests beyond SHA-1/SHA-256, and EC curves beyond P-256/P-384. Recognised and rejected as Unsupported — fail-closed, and correctly reported as unsupported since this pass.

8. OID_STUB_SIG remains a #[cfg(test)] backdoor. link_signature_ok and is_stub_sig_fixture compile it out of production builds, and production_trust_store_constructors_are_never_permissive guards the related permissive_legacy switch. No action needed; listed so it is not rediscovered as a finding.

What would have to be built, in order

1. Revocation: CRL distribution-point / OCSP responder fetch, a bounded cache, and an explicit hard-fail-or-configurable policy. (Gap 1.)
2. Full RFC 5280 §6.1 state machine: name constraints, certificatePolicies, policy mapping and policy constraints, with the initial-policy-set inputs. (Gap 2.)
3. Multi-SignerInfo dispatch, and a decision about what "signed by" means when signers disagree. (Gap 3.)
4. AKI/SKI-driven parent selection and multi-path search on ambiguity. (Gap 4.)
5. A trusted time source for validity evaluation, or signature timestamps (RFC 3161 signatureTimeStampToken), which would also make expired-signer JARs verifiable the way HotSpot does. (Gap 5.)

Only after 1 and 2 should any caller be allowed to treat getCodeSource().getCertificates() as an authorisation input, and even then the per-entry gate in §1.2 remains mandatory.

---

5. Test coverage for this contract

All #[cfg(test)] in classloading/src/jar_signer.rs. The fixtures use the real RSA test key and the production verification path, not the OID_STUB_SIG backdoor.

fuzz/fuzz_targets/fuzz_signed_jar.rs is unchanged and its load-bearing assertion — verify_signer_block against a zero-anchor TrustStore never returns Some — still holds: verify_chain delegates to verify_chain_path, which still terminates successfully only at find_anchor_by_subject.

---

6. Compatibility impact

No public item was removed or renamed. verify_chain_path is added; verify_chain keeps its signature and its behaviour.