Repository navigation
Bind cross-signed trust anchors to the configured public key - #7
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A cross-signed top certificate with a configured root’s subject name could terminate the HTTPS Padlock trust walk even when its public key belonged to an attacker. Real signatures from that attacker’s key were enough to return
trusted: true, and the server-supplied certificate was falsely labeledfromStore.The alternate root termination now requires the configured subject and complete SubjectPublicKeyInfo identity (algorithm, parameters and key bytes). A mismatch stays untrusted and never receives the store provenance flag. Legitimate cross-signed certificates with the held key remain supported even when their certificate DER differs. The displayed root is the actual held certificate, with its own date state; an expired served cross-signed copy remains rejected under the lab’s existing date policy.
Six real ECDSA controls cover direct held-root acceptance, different-key cross-signed rejection, different-key self-issued rejection, same-key cross-signed acceptance and held-certificate provenance, expired served-copy rejection, and the configured anchor date policy. Before the implementation repair, three controls failed; afterward all six pass. The fixed public UI uses pinned captured/toy chains and does not accept arbitrary uploaded certificates or connect to TLS servers, so this is a validator/teaching defect rather than a claim of network-client exploitation.
Primary basis: RFC 5280 §6.1.1(d) defines the trust anchor as a trusted name and public key. The lab remains an explicitly limited teaching subset. Existing fixture keys, manifests, lockfile, workflow, claim registry, and all other source files are unchanged; the catalog’s ECDSA source anchor remains
src/pki/path.ts:86.Fleet work:
6fd45343-951d-4252-8735-27eaf5794aa9.Validation at
2c9a75c49b8c0329ce76e7ff26b50532059e44b0: 76 unit/KAT tests, production/typecheck build, 63 production verdict/coverage tests, and three full-state accessibility gates at 1280/390/320px pass. The full 20-mutation gate passed: all 20 real mutations compiled, changed the served bundle, were killed by their named assertions, and restored the original bundle. Local evidence is retained separately from the historical tracked mutation report; no fixture or cryptographic primitive was weakened.