Socair acceptance

Shape

Envelope

An in-toto Statement v1 (https://in-toto.io/Statement/v1) in a DSSE envelope with payload type application/vnd.in-toto+json, signed with Ed25519. It verifies offline: no transparency log or certificate authority is involved.

Subject

One subject: the artifact by name and SHA-256, the same artifact as the reviewed report.

Predicate

reviewed_document_hash

The document hash of the withheld report the acceptor reviewed.

reviewed_document_id

That report’s document id.

accepted_surfaces

The report’s NOT_TESTED rows, all of them and only them.

accepted_by

The acceptor’s name as they wrote it. The key is the proof.

accepted_at

When they signed.

expires

When the acceptance stops counting.

rationale

Optional: why they accepted the gaps.

Sign and verify

socair accept --attestation report.dsse.json --key ciso.key \
  --by "Jane Doe, CISO" --expires <RFC 3339 time> \
  --trusted operator.pub
socair sign --key operator.key --attestation report.dsse.json \
  --acceptance report.acceptance.dsse.json \
  --trusted keys/ --acceptors acceptors/

What the signature means

• The flow is review, accept, re-issue. The operator re-issues the same report as authorized with conditions, with the acceptance embedded, so one attestation carries both signatures.
• An acceptance covers NOT_TESTED rows only. No acceptance clears a FAIL or a LEAD.
• The airlock checks the acceptor’s signature against its own acceptor keys, kept apart from the keys that sign attestations, so nobody accepts their own report.

Where it is defined

• The acceptance flow
• On an intake host

The other signed documents: Socair attestation, Socair reference feed, Socair inventory snapshot, Socair OCI binding, Socair derivation record.