# Capability Spec Delta: slsa (restore-crypto-keychain-packer)

**Package**: `@suaveplan/slsa`
**Status**: PROPOSED

> Every requirement below carries a `**Verified by:**` line at authoring time.

## MODIFIED Requirements

### Requirement: Builder identity is constructed via Authority, not raw secret keys

The package SHALL construct a SLSA builder identity as a `ServerIdentity` (from `@suaveplan/crypto`) issued under a SLSA-builder root. Provenance signing SHALL go through `Authority.sign(DOMAIN_SLSA_BUILDER_V1, "sign", payload)`; raw `ed25519.sign(secretKey, …)` calls and direct imports of cryptographic signing primitives from `@suaveplan/crypto-core` are removed.

The DSSE envelope wire format is unchanged — only the construction path changes. Existing provenance verifiers (Rekor, third-party SLSA tooling) MUST still accept envelopes produced by the new path; this is asserted by a round-trip test against the previous fixture.

The `@suaveplan/crypto-hash` and `@suaveplan/crypto-utils` imports are retained — pure hashing (`sha256`) and encoding helpers (`toHex`, `toBase64`) are not gated by the import allowlist.

#### Scenario: provenance signing goes through Authority

- **WHEN** `generateProvenance(buildMetadata, builderAuthority)` is called
- **THEN** the resulting DSSE envelope's signature is byte-equal to one produced by the previous direct `ed25519.sign` path against the same inputs (asserted via fixed `Clock` and seeded `Rng` in the test)

#### Scenario: no direct primitive signing imports remain

- **WHEN** the import-allowlist conformance gate runs against `@suaveplan/slsa`
- **THEN** the package passes — `@suaveplan/crypto-core` is not imported for signing operations; `@suaveplan/crypto-hash` and `@suaveplan/crypto-utils` are imported only for hashing and encoding, which are explicitly open

#### Scenario: builder identity can be revoked

- **WHEN** the SLSA builder's `ServerIdentity` is revoked via `revokeServer` and a verifier checks a provenance envelope signed by that builder against the active CRL
- **THEN** the verification fails with `CryptoError` code `AUTHORITY.REVOKED` and the SLSA package surfaces this as a structured provenance-verification failure with the prior builder identity referenced

**Verified by:** `src/builder/builder-identity.test.ts::"provenance signing goes through Authority"` AND `src/builder/builder-identity.test.ts::"DSSE output is byte-equal to legacy direct-sign path"` AND `tests/no-direct-crypto-core.test.ts::"slsa does not import crypto-core for signing"` AND `src/verification/verify.test.ts::"revoked builder identity fails verification"`

---

### Requirement: SLSA-builder trust anchor

The package SHALL document the SLSA-builder root's distribution path. v1 ships the public sign key as a compiled-in pinned constant at `src/trust-anchors/slsa-builder.ts`, loaded via `@suaveplan/crypto`'s `loadTrustAnchor("slsa-builder")`. The fixture is committed at `test-fixtures/trust-anchors/slsa-builder.pub` and is reviewed in PR.

Network-fetched anchors are out of scope per the cross-cutting `TRUST_ANCHOR` requirement in `specs/crypto/spec.md`.

#### Scenario: pinned anchor loads and verifies

- **WHEN** `loadTrustAnchor("slsa-builder")` is called
- **THEN** the call returns a verified public bundle whose sign-slot key matches the committed fixture

**Verified by:** `src/trust-anchors/slsa-builder.test.ts::"pinned slsa-builder anchor loads and verifies"`