Security model
What this proves, and what it does not.
Seven verification domains, checked independently and reported separately. Two of them do not pass today, and they are named here rather than averaged into a single green tick.
- Stage 0Working demo
- Gate 1Pilot-ready
- Gate 2Security-review-ready
- Gate 3Enterprise GA
The seven domains
A verdict per property, never a single tick.
A verifier that returns one boolean forces you to trust its weighting. This one reports each property separately, so you can decide which ones you actually need.
canonicalpassThe record serialises deterministically.
Re-encodes the core as CDE CBOR and compares bytes. Two implementations must agree exactly, or the digest below means nothing.
bindingpassThe digest matches the record.
SHA-256 over the canonical bytes. Alter one byte of the record and this fails.
signaturepassThe record was signed by the pinned key.
ML-DSA-65 (FIPS 204) and Ed25519, both required. A forger needs to break both, and one of them is post-quantum.
inclusionpassThe record is in the log at the position claimed.
RFC 6962 audit path recomputed to the signed tree head.
consistencypassThe log only ever grew.
Consistency proof between two tree heads. Catches a log that dropped or rewrote history between observations.
attestationsimulatedWhere the record was produced.
No TDX in the loop yet, so this domain reports simulated and can never report pass. The rule is in the verifier — nothing in any UI can reach it.
witnessesabsentAn independent party saw the same log.
Not built. A log signed only by our keys is not tamper-evident against us, and no amount of hardware substitutes for a second signer.
Full disclosure
The two that do not pass.
Both are enforced in the verifier rather than stated in copy. You can confirm that yourself in about thirty seconds.
We cannot prove where a record was produced.
The measurement and quote machinery is built and exercised against a simulator, but no Intel TDX root has signed anything. Until a real CVM does, this domain reports simulated.
Run the verifier with --require-hardware against a record this site sealed a minute ago and it refuses. That refusal is the most useful thing on the site: a demo that could only ever go green would prove nothing about the gate.
The log is signed only by us.
A transparency log signed solely by its operator is tamper-evident against outsiders and not against the operator. Against a determined insider at CooL, today, the log is not sufficient on its own.
The fix is an independent co-signer who is neither CooL nor our hardware vendor. It sits on Gate 2, it is not built, and a CooL self-signature is shown but never counted as a witness — that rule is in the verifier too.
Check it in thirty seconds
npm install -g cool-nwc
# seal something, then demand a hardware root
cool verify ./change-receipt.json --require-hardware
REFUSED attestation: simulated
policy: requireHardware is set and this receipt is
not backed by a verified hardware quoteTrust boundaries
Your evidence never crosses into our network.
Control plane is ours; data plane is yours. The split is architectural — there is no configuration flag that turns it off, because there is no code path that would honour one.
No signing key we hold
Keys are derived inside the enclave from the measurement. There is no key escrow, which is why we cannot forge your records even under legal compulsion.
Fail-open toward you
If CooL is unreachable your inference continues. Capture queues; what it cannot queue is counted and the count is itself signed.
Fail-closed toward the network
RA-TLS attests before it sends. A measurement mismatch means the channel never opens and nothing is transmitted.
Disclosure
Found something?
Tell us before you tell anyone else, and we will credit you. We do not run a paid bounty yet and we are not going to pretend otherwise.