RFC: Anchored evidence for SAFE

[imran-siddique]

Adds rfc-anchored-evidence.md, a proposed addition to the SAFE draft.

What it proposes

SAFE's Evidence Preservation section specifies what members must retain. It does not specify any property establishing when that evidence came into being. Every item on the list is produced by systems the reporting member owns, held in storage the member controls, and provided on a schedule running from four business days to ninety, during which the questions the review will ask become progressively clearer. A reviewer today cannot distinguish evidence recorded as an incident unfolded from evidence assembled afterwards.

The RFC proposes one property: a reviewer should be able to establish, without trusting the member under review, that an evidence item existed in its provided form at a stated time. It then describes an RFC 6962 (Certificate Transparency) construction that satisfies it, and proposes an anchored / unanchored / unavailable status field on Evidence Preservation. The requirement is that the status is stated, not that it is anchored, on the same logic the thread in #11 applied to declared gaps.

Why it fits SAFE rather than being a general transparency proposal

• The notification timeline is itself the window. Anchoring on day zero fixes evidence before the member can know what the review will focus on.
• A hash discloses nothing, so a member can anchor evidence during an incident they are legally barred from describing. SAFE's confidentiality model and independent verification stop being a tradeoff.
• Near misses, which the Reporting Compact requires and which have the weakest preservation incentive, become free to record.

Limits, stated in the RFC

Inclusion proves the exact bytes provided were recorded at that timestamp and cannot be quietly un-recorded. It does not validate signatures against a producer key, does not make the evidence true, does not establish completeness (the point @bobleer raised in #11), and does not authenticate the recording environment. It narrows the window in which evidence can be shaped rather than closing it.

Contribution offer

The reference registry exists and works, and its central weakness is that we operate it. Its own roadmap names the three gaps: production volume from a producer other than ours, a mirror operated by someone with no incentive to cover for us, and maintainers from outside the originating company. Those are things a consortium supplies and a vendor cannot.

The RFC therefore offers the registry to the alliance: anchor format specification, reference tooling, schema and CI validation, mirroring documentation, and the operational pipeline. Code is Apache-2.0, registry data is CC BY 4.0. We do not require that operation stay with us. If the working group would rather specify the requirement and have members implement it independently, that is also a good outcome.

Relationship to open issues

Builds on #11, which established the gap and converged on three determinations without a mechanism for the third. Complements #14 (provenance grades) and #6 (signed tool-trust verdicts), both of which produce evidence that can be anchored. Does not address #4; an anchored record of a fail-open verification is still a fail-open verification.

Raising as a PR rather than an issue since it adds a document, per CONTRIBUTING. Happy to move the discussion to an issue if the working group prefers that first. Commit is DCO signed off.

[lywinged]

This reads right to me, and asking for the status to be stated rather than requiring it be anchored is the part that makes it adoptable. Two things I got stuck on, both out of the canonicalization section.

The entry has ts, merkle_root, leaf_count, producer and batch_id, but nothing saying which canonicalization built its leaves. The RFC asks a verifier to use the rule declared for the context it is checking, and right now that is declared globally in docs/anchor-format.md, by revision. With one producer that is fine. With two, or after the format shifts, you can tell who produced a batch but not what rule they used, and entries from either side of the change are the same five fields meaning different things. A canonicalization field would cost one string. The repo is not public yet, so this may already be handled.

The other is excluding non-integer numbers. Since the leaf is the whole signed object, that is not really about how floats serialize, it means an evidence object containing one cannot be anchored. Evidence Preservation covers traces, tool calls and detection events, which carry latencies, costs and confidence scores, and the recommendations in From Lessons to Controls carry metrics. The workaround is rounding or stringifying before anchoring, and then the anchored bytes are not the bytes the reviewer holds.

On the reason given for it: RFC 8785 §3.2.2.3 does pin float serialization to ECMAScript Number::toString, and it is implementable. I have checked an implementation against a reference JCS library over a few hundred thousand values and they agree byte for byte, including where both refuse integers outside the safe range. Where it goes wrong is the exponent's leading zero and the thresholds where exponential form starts at each end. Happy to write those up as vectors if that is useful.

[zohebk8s]

Support this. The gap it names is real, and the sharpest version of it is the RFC's own reading of the Review Framework: the affected organization may correct factual errors but should not have veto power over learnings or recommendations, which assumes those facts can be established by someone other than the member holding them. Under the current draft they cannot be, and the proposal is scoped to that one property rather than to evidence handling in general.

Both points raised above look right to me, and I think they are the same point twice.

The RFC already says the two canonicalizations agree for records whose keys and strings are ASCII and whose numbers are integers, and that this is exactly what makes the divergence dangerous. Since the leaf is the whole signed object, putting the leaf on JCS as well follows that reasoning to its end: one rule instead of two, and the non-integer exclusion goes with it. That second part is the one that costs something today, because an evidence object carrying a latency or a confidence score cannot be anchored at all, and rounding or stringifying first breaks the property that the anchored bytes are the bytes the reviewer holds.

Naming the rule in the entry is worth doing whichever way that goes. A single rule still has revisions, and an entry cannot be reinterpreted after the fact, so the cheapest moment to record which rule built a batch is the moment the batch is written.