Skip to content

legal-considerations.md

Latest commit

 

History

History
301 lines (235 loc) · 12.7 KB

legal-considerations.md

File metadata and controls

301 lines (235 loc) · 12.7 KB
Raw

Legal Considerations

This document analyzes how a DEPOSE .depo bundle interacts with the U.S. Federal Rules of Evidence (FRE), specifically Rules 901 and 902. It does not constitute legal advice. It is an engineering analysis of how the bundle's structure maps to evidentiary requirements, written so that an attorney can evaluate the bundle's admissibility without reverse-engineering the format.

The guiding principle: DEPOSE bundles are defensible, not automatic. No technology guarantees admission. A court always retains discretion under FRE 403 (prejudice, confusion, waste of time) and FRE 702 (expert testimony). What DEPOSE provides is a structural argument, a chain of verifiable facts that an opposing party can audit independently, not a black-box claim.

FRE 901, Authentication

Rule 901 requires evidence "sufficient to support a finding that the item is what the proponent claims it is." The rule lists examples, not exhaustive categories. DEPOSE bundles aim to satisfy 901(a)'s general standard and several specific illustrations.

901(a), General authentication

The bundle structurally supports authentication through:

  1. Hash chain continuity. Every event in events.jsonl is linked by chainHash[i] = SHA-256(chainHash[i-1] || payloadHash[i] || eventMetadata[i]). Removing, reordering, or modifying any event breaks the chain. The verifier replays this chain independently and reports any mismatch. This provides "evidence sufficient to support a finding" that the event sequence is intact since the root hash was signed.

  2. Cryptographic signature. The manifest's rootHash is signed with Ed25519 (or sigstore/Fulcio). An Ed25519 signature over the root hash binds the producer's key to the chain's terminal state. The verifier checks this signature against the public key embedded in attestations/signatures.json. Key ownership is a separate question (see "Key attribution" below), but the mathematical link between key, signature, and chain is not disputable.

  3. RFC 3161 timestamps. Each TSA token in attestations/rfc3161-timestamps/ is issued by a trusted third party (FreeTSA or DigiCert) and proves that the signed root hash existed at a specific time. The verifier validates the token's certificate chain and its signature over the hash. This addresses the "when was this created?" question independently of the producer's own clock.

  4. Deterministic rebuild. Starting from raw/ (verbatim source records), any party can re-run normalization, reconstruction, and chain computation to arrive at the same rootHash. If the rebuilt root hash matches the signed one, the producer's processing was deterministic and tamper-free.

901(b)(1), Testimony of a witness with knowledge

A human who was present during the session can testify that the events in the bundle correspond to what they observed. The bundle does not replace witness testimony; it augments it with tamper-evident structure.

901(b)(4), Distinctive characteristics

The hash chain and signature create a "distinctive characteristic" that a layperson cannot fabricate without the private key. The RFC 3161 timestamp creates a time-of-creation marker that (unlike a local clock) is countersigned by an independent authority. Together, these constitute distinctive characteristics "like a fingerprint" under 901(b)(4).

901(b)(9), Process or system producing an accurate result

DEPOSE's deterministic pipeline, normalization → reconstruction → hash chain → signature, is a "process" under 901(b)(9). The bundle includes the exact destructive ruleset used (rules/destructive.yaml, hashed in the manifest), so a reviewer can audit the rules that flagged specific operations. The open-source verifier allows anyone to confirm what the process checks, how it checks it, and whether it passes or fails without relying on the producer's representation.

FRE 902, Self-authentication

Rule 902 lists categories of evidence that require no extrinsic authentication. A DEPOSE bundle does not automatically fall into any 902 category by virtue of its format alone. However, the bundle structurally supports two specific provisions:

902(13), Certified records generated by an electronic process

If the bundle producer executes a certification (available via packages/narrative/src/rule-902.ts), the certifier attests that the bundle was generated by a defined electronic process and that the output has not been altered. The certification template references the verifier binary's published checksum (SHA256SUMS from the GitHub release, itself cosign-signed via GitHub Actions OIDC + Fulcio + Rekor, see .github/workflows/release.yml) and the bundle's root hash. A certifying party, typically the engineer or organization that ran depose package, takes on a legal obligation similar to a records custodian.

The bundle MUST be in signed mode for 902(13) to be on the table. A dev-unsigned bundle is structurally labelled NOT EVIDENCE (verify.txt and narrative.md carry a banner; the verifier refuses to print a plain "PASS"). See docs/threat-model.md §7 for the mode contract.

This is not automatic. The certification is a human act. The template makes the certifier's duty explicit: they are certifying that the process ran without modification and that the output has not been tampered with since production.

902(14), Certified data copied from an electronic device

If the bundle is produced on a specific machine and the certifier attests to that machine's identity and the integrity of the copy process, 902(14) may apply. The manifest includes producer.host (OS, arch, kernel), which anchors the certification to a specific environment.

What 902 does NOT do for a DEPOSE bundle

  • 902 does not waive hearsay objections (FRE 801–807).
  • 902 does not guarantee that the events are truthful; it guarantees that they have not been altered since the hash chain was computed.
  • 902 certification requires a human who accepts responsibility. The technology enables the certification; it does not substitute for it.

Key attribution and identity

The Ed25519 signature proves that someone holding the private key signed the manifest. It does not prove who that someone is. Key attribution is an organizational and procedural matter. DEPOSE supports two flows (see docs/key-management.md):

  • Air-gapped fingerprint pin. The key at ~/.depose/keys/signing.key is generated locally and never transmitted. The producer publishes the SHA-256 fingerprint of their public key out-of-band (a .well-known page, a printed handshake, a published catalog). The manifest carries producer.keyFingerprint. A receiving party who knows what fingerprint to expect runs:

    depose-verify verify --expected-key-fingerprint <hex> <bundle>

    and the verifier rejects any bundle whose embedded fingerprint disagrees. Attribution still ultimately rests on testimony about who controls the key associated with that fingerprint, but pinning prevents an unrelated key from being substituted.

  • Sigstore keyless (preferred when OIDC is available). A producer running under OIDC signs with an ephemeral key bound to a short-lived Fulcio cert. There is no long-lived key to attribute, the binding is between the signature and the OIDC identity that requested the cert. The verifier accepts --signer-identity <regex> to pin to a specific identity (e.g. ^https://github.com/Aftermath-Technologies-Ltd/depose/).

A party challenging admissibility can ask: "Who controlled this key?" The bundle now answers more crisply than before: "The same key whose fingerprint is <hex> signed this manifest. That fingerprint matches the one this party published at <location> on <date>."

Gap events and the limits of completeness

DEPOSE emits explicit gap events wherever a tool result has no matching pre-execution capture, or where shell history or reflog entries have no corresponding JSONL event. This is a feature, not a defect. A gap event says: "Something happened here that we cannot fully reconstruct." It is more defensible to disclose a gap than to silently smooth it over.

An opposing party may argue that gaps undermine the bundle's reliability. The response: gaps make the bundle more reliable because they prevent false inferences. A reconstructed timeline that looks complete but silently omits events is far more dangerous than one that honestly marks its boundaries.

Chain of custody

The DEPOSE bundle serves as its own chain-of-custody record:

  1. Capture. The PreToolUse hook or shell shim writes a ShellCommandPrePayload record with wallTs, monoNs, cwd, argv, envSubset, fileArgs, parentProcessTree, and source (indicating which capture mechanism produced it).

  2. Normalization + reconstruction. These are deterministic processes. Given the same raw/ inputs, the same ruleset, and the same code version, they produce identical events.jsonl. The code is open source; the ruleset is shipped inside the bundle with its hash in the manifest.

  3. Integrity. The hash chain binds every event to every prior event. The Ed25519 signature binds the chain's terminal state. The RFC 3161 timestamp binds the signature to an independent clock.

  4. Verification. A third party with only the verifier binary and the .depo file can independently confirm all of the above.

This is not a substitute for physical chain-of-custody logs or organizational policies. It is a cryptographic chain of custody that complements them.

commentary.md exclusion

The bundle may contain a commentary.md file produced by depose explain. This file is explicitly non-evidentiary:

  • It is excluded from events.jsonl.
  • It is excluded from rootHash computation.
  • The verifier ignores it.
  • It carries the banner: "AI-GENERATED COMMENTARY, NOT EVIDENCE."
  • Modifying or deleting commentary.md does not affect bundle validity.

This exclusion exists because LLM-generated analysis is inherently non-deterministic and cannot be reproduced or audited the way the deterministic pipeline can. Including LLM output in the signed root would undermine the bundle's core value: verifiable, reproducible evidence with no model in the trust path.

An attorney should treat commentary.md the way they would treat any AI-generated summary: as potentially useful orientation, but never as evidence. The evidence lives in the signed events.

Practical admissibility considerations

  1. Foundation witness. Someone must testify that the bundle was produced from a real session on a real machine. The technology does not eliminate this requirement.

  2. Expert testimony may be needed. The verifier's output is designed to be readable by a layperson, but explaining hash chains, Ed25519, and RFC 3161 to a judge or jury may require an expert under FRE 702.

  3. Opposing party verification. Because the verifier is open source, statically linked, and requires no DEPOSE infrastructure to run, an opposing party can independently verify the bundle on their own machine. The verifier itself is distributed via signed GitHub Releases (cosign keyless + SLSA L3 provenance), so the opposing party can confirm that the binary they downloaded was built by this repository's release workflow:

    cosign verify-blob \
  --certificate SHA256SUMS.pem --signature SHA256SUMS.sig \
  --certificate-identity-regexp '^https://github.com/Aftermath-Technologies-Ltd/depose/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  SHA256SUMS

    This is a significant practical advantage over proprietary audit trails.

  4. Jurisdiction. This analysis is limited to U.S. federal evidence rules. State rules and foreign jurisdictions vary. The bundle's technical properties (hash chains, signatures, timestamps) are jurisdiction-agnostic, but the legal arguments that rely on them are not.

  5. Preservation obligations. A DEPOSE bundle is a snapshot of a session, not an ongoing record. Parties with preservation obligations should capture bundles promptly while raw source records (JSONL, shell history, reflog) are still available. The bundle's raw/ directory preserves verbatim source records, but only for the session it covers.

Summary

A DEPOSE bundle provides a cryptographic argument for authenticity and integrity that maps to multiple FRE 901 illustrations and structurally supports 902(13)/(14) certification. It does not automatically satisfy any evidentiary rule. The "defensible, not automatic" framing is intentional: the technology gives an attorney strong structural arguments, but admission always requires human judgment, witness testimony, and judicial discretion.