Loading
Security model
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.
The seven domains
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.
canonicalThe record serialises deterministically.
Re-encodes the core as CDE CBOR and compares bytes. Two implementations must agree exactly, or the digest below means nothing.
bindingThe digest matches the record.
SHA-256 over the canonical bytes. Alter one byte of the record and this fails.
signatureThe 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.
inclusionThe record is in the log at the position claimed.
RFC 6962 audit path recomputed to the signed tree head.
consistencyThe log only ever grew.
Consistency proof between two tree heads. Catches a log that dropped or rewrote history between observations.
attestationWhere 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.
witnessesAn 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
Both are enforced in the verifier rather than stated in copy. You can confirm that yourself in about thirty seconds.
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.
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
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.
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.
If CooL is unreachable your inference continues. Capture queues; what it cannot queue is counted and the count is itself signed.
RA-TLS attests before it sends. A measurement mismatch means the channel never opens and nothing is transmitted.
Disclosure
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.