Summary
REALITY.3's on-the-fly stolen-cert acceptor (bin/yip-rendezvous/src/reality_cert.rs) forges a leaf that copies the real dest leaf's subject, all SANs, validity, serial, keyUsage, EKU, basicConstraints, but does not copy AIA (Authority Information Access) or SCTs (Signed Certificate Timestamps). This is a deliberate, accepted scope cut in REALITY.3 — tracking it here so the fidelity gap is explicit and revisitable.
Why it was deferred
- AIA:
boring 4.22 exposes clean accessors for subject/SAN/validity/serial but not for the AIA extension. Copying it faithfully needs DER-level extension parsing (e.g. x509-parser on the leaf DER), which was out of scope for the initial server milestone.
- SCTs and the CA signature are fundamentally unreproducible: they are signatures made by the real CA / CT logs over the original cert+key. A forged leaf signed by our relay-ephemeral key cannot carry a valid SCT or the original CA signature — no amount of copying fixes that.
Why it's low-severity today
In TLS 1.3 the Certificate message is encrypted, and REALITY.3 pins the authed acceptor to TLS-1.3-only, so these extensions are never visible to passive DPI. The gap only matters to an adversary who already holds a valid REALITY key (a legitimate-client-turned-prober) and decrypts the Certificate to compare the forged cert against dest's live one — which is REALITY's accepted threat-model boundary (possessing the config already reveals the server).
Possible follow-up work
- Copy AIA (issuer/OCSP URLs) via DER-level extension extraction so the forged leaf carries the same AIA as dest.
- Copy any other cleanly-extractable extensions (e.g. certificate policies) for closer parity.
- Document explicitly (in code + spec) that SCTs and the original CA signature are intentionally, unavoidably absent.
References
- Spec §1 "Forge a leaf":
docs/superpowers/specs/2026-07-15-reality-3-server-cert-steal-design.md
- Code:
bin/yip-rendezvous/src/reality_cert.rs (extract_fields / forge_leaf)
- Deferred from the REALITY.3 PR (server stolen-cert authed path + anti-replay).
Summary
REALITY.3's on-the-fly stolen-cert acceptor (
bin/yip-rendezvous/src/reality_cert.rs) forges a leaf that copies the realdestleaf's subject, all SANs, validity, serial, keyUsage, EKU, basicConstraints, but does not copy AIA (Authority Information Access) or SCTs (Signed Certificate Timestamps). This is a deliberate, accepted scope cut in REALITY.3 — tracking it here so the fidelity gap is explicit and revisitable.Why it was deferred
boring4.22 exposes clean accessors for subject/SAN/validity/serial but not for the AIA extension. Copying it faithfully needs DER-level extension parsing (e.g.x509-parseron the leaf DER), which was out of scope for the initial server milestone.Why it's low-severity today
In TLS 1.3 the Certificate message is encrypted, and REALITY.3 pins the authed acceptor to TLS-1.3-only, so these extensions are never visible to passive DPI. The gap only matters to an adversary who already holds a valid REALITY key (a legitimate-client-turned-prober) and decrypts the Certificate to compare the forged cert against dest's live one — which is REALITY's accepted threat-model boundary (possessing the config already reveals the server).
Possible follow-up work
References
docs/superpowers/specs/2026-07-15-reality-3-server-cert-steal-design.mdbin/yip-rendezvous/src/reality_cert.rs(extract_fields/forge_leaf)