Stella Ops Signer Architecture

Verified against commit 942a18727c (2026-09-26, DOC-2 of SPRINT_20260926_001). Re-verify by reading the evidence paths listed in the Evidence section.

Signer is the key-custody and DSSE-signing service of the trust domain. It is a live, separate deployable (compose key signer) with its own database. Its source lives under src/Attestor/StellaOps.Signer/ (WebService, Core, Infrastructure, Contracts, Tests), with key rotation and trust-anchor logic in src/Attestor/__Libraries/StellaOps.Signer.KeyManagement/, keyless support in src/Attestor/__Libraries/StellaOps.Signer.Keyless/, and the database in src/Attestor/__Libraries/StellaOps.Signer.Persistence/. The src/Attestor/ placement is a source root only: the attestor deployable was retired on 2026-09-05 and its attestation capability runs in the Evidence family (../evidence/architecture.md).

Related: Signer README (HTTP contract detail), no-merge decision, cryptography.

Deployment

Runtime at a glance (source-grounded)

Verified against src/Attestor/StellaOps.Signer/ on this checkout.

• Docker image / base path: stellaops/signer; HTTP surface is rooted at /api/v1/signer/ (SignerEndpoints.MapSignerEndpoints).
• Authentication: Authority resource-server auth in live hosts (AddStellaOpsResourceServerAuthentication); a test bearer/scope handler is injected only in the Testing environment by the test harness (Program.cs).
• Database: Signer’s own PostgreSQL database stellaops_signer, schema signer, auto-migrated by StellaOps.Signer.Persistence. Its consolidated 001_signer_consolidated_baseline.sql replaces the legacy KeyManagement startup chain; 002_dsse_request_replays.sql is the forward idempotency store. Live tables: signer.key_history, signer.key_audit_log, signer.trust_anchors, signer.ceremonies, signer.ceremony_approvals, signer.ceremony_audit_log, signer.operator_decision_envelopes, and signer.dsse_request_replays. A live STELLAOPS_POSTGRES_SIGNER_CONNECTION (or Postgres:Signer:ConnectionString) is required outside the test host harness; EF InMemory key-management storage is rejected. (019 SGN-6, 2026-08-18: the former ConnectionStrings:KeyManagement key is retired and no longer accepted.)
• Audit retention window is applied, not only declared (retention-convergence RFC-14, 2026-09): signer.key_audit_log and signer.ceremony_audit_log are P13 append-audit with a seven-year window declared by signer.prune_key_audit_log(interval) and signer.prune_ceremony_audit_log(interval). Until RFC-14 nothing called them. SignerAuditRetentionService, registered only where Signer’s own connection is configured, now calls both with their declared default once a day after a five-minute start delay. Signer:AuditRetention:Enabled, SweepInterval and StartDelay control the schedule; there is no window setting, because the value lives in the baseline. The Doctor check doctor.signer.retention-window.p13 names the sweep and fails when a row outlives the window, which is what a disabled or failing sweep looks like.
• Ceremony-quorum trust evidence is durable (SPRINT_20260712_003 EVI-2): on quorum, CeremonyQuorumAttestor assembles the multi-signed operator-decision@v1 DSSE envelope and persists it through PostgresOperatorDecisionEnvelopeStore into signer.operator_decision_envelopes (idempotent on (tenant_id, envelope_digest)). InMemoryOperatorDecisionEnvelopeStore is now registered only when no Signer-owned connection is configured (the test host) and SignerRuntimeGuards rejects it outside Development/Testing. See operator-decision predicate — envelope persistence.

HTTP endpoints

Routes and policies as registered in Program.cs / the *Endpoints.cs files.

Notes:

• The ceremony and anchor endpoints declare the canonical SignerPolicies.* constants (Signer.CeremonyRead, Signer.KeyManagement, …) registered in Program.cs; the pre-consolidation raw string aliases (ceremony:read, KeyManagement, …) were removed 2026-08-25 (P8-14).
• POST /verify/dsse verifies a complete Signer-produced bundle over DSSE PAE. The bundle carries the signer-selected provider and algorithm; IDsseVerifier resolves that registered provider and key id through ICryptoProviderRegistry. Raw-envelope input is retained only for the explicit Development/Testing HMAC signer, and that path is PAE-bound as well. This is Signer-key verification, not arbitrary Sigstore/certificate-chain/transparency-policy evaluation; the broader trust decision belongs to the attestation layer in the Evidence family.
• POST /sign/dsse accepts an optional Idempotency-Key. Signer binds it to tenant + authenticated subject + canonical operation, persists exact response bytes, and returns 409 for a different operation or 425 while another lease owns the same operation. Replays revalidate explicit tenant, subject, exact audience signer, signer:sign, and current PoE entitlement. A stale takeover may re-sign across the signed-before-completion crash boundary; the contract is not an exactly-once audit claim.
• Generated OpenAPI declares the body, optional idempotency header, and 200/400/403/409/425/429/500. Its current generator does not project the minimal-API authorization policy into a security scheme; generated “Auth: Not declared” text does not override source-enforced authorization or DPoP/PoE.
• In-toto statement version is selected from the normalized predicate type on every default signing backend. SLSA provenance v1 and stella.ops/* predicates use https://in-toto.io/Statement/v1; legacy SLSA v0.2 and the currently mapped CycloneDX/SPDX/OpenVEX families retain Statement v0.1. KMS, keyless, and the Development/Testing HMAC harness must not produce different statement contracts for the same predicate solely because the signer backend changed.
• GET /verify/referrers resolves release-integrity trust for a scanner image digest via IReleaseIntegrityVerifier and returns { trusted, releaseSigner }.

Scopes

The Signer scope constants live in StellaOps.Auth.Abstractions/StellaOpsScopes.cs:

• signer:read (SignerRead) — read Signer configuration/key metadata and perform DSSE verify / ceremony read.
• signer:sign (SignerSign) — create signatures, create/approve ceremonies.
• signer:rotate (SignerRotate) — key-rotation and trust-anchor management.
• signer:admin (SignerAdmin) — execute/cancel ceremonies; administrative control.

Configuration keys

Bound in Program.cs:

• Authority:ResourceServer (resource-server auth; audience signer).
• STELLAOPS_POSTGRES_SIGNER_CONNECTION (or Postgres:Signer:ConnectionString) (PostgreSQL, database stellaops_signer; required in live hosts. The legacy ConnectionStrings:KeyManagement key was retired by 019 SGN-6 and is no longer accepted).
• Signer:Entitlements, Signer:ReleaseVerification, Signer:Crypto, Signer:Dsse.
• Signer:Dsse:CadesBaselineBPfxPath — optional offline-only CAdES-B companion (PKCS#12/PFX). It does not provide qualified eIDAS/QSCD evidence and does not satisfy the T/LT/LTA profiles, which remain fail-closed (cadenced.cades.provider_pack_required).
• Router (Stella Router microservice registration; serviceName: "signer").

DSSE signing notes

• The DSSE sign endpoint runs ISignerPipeline.SignAsync, which validates the proof-of-entitlement (PoE), sender binding (DPoP for JWT PoE, mTLS client cert for mTLS PoE), predicate, release integrity, quota, and provider resolution before emitting the DSSE envelope and an audit id.
• The in-toto request predicate type must match the exact PredicateTypes allowlist and the predicate payload must be a JSON object. Unsupported types and null/array/scalar payloads fail as predicate_type_unsupported or predicate_invalid before entitlement, release-integrity, quota, provider, crypto, or audit side effects.
• Signing mode is kms (default) or keyless; primary signatures are algorithm-pinned by the active crypto profile before provider lookup.
• The CRA “cadenced” DSSE wrapper is opt-in via options.cadenced=true or a returnBundle token containing cadenced, with CAdES profiles BaselineB/BaselineT/BaselineLT/BaselineLTA.
• In local-runtime environments (Development/Testing) the pipeline is replaced with a deterministic HmacDsseSigner harness; live hosts reject it.
• Audit capture is body-disabled on the sign route. PoE values and signing payloads are not copied into Timeline audit, and rejected entitlement logging emits no token-derived length, name, or fingerprint.
• The direct endpoint currently performs structural, not cryptographic, DPoP validation. A live consumer must traverse a validating gateway or wait for a direct-endpoint htu/htm/iat/jti/ath/JWK-signature closure.

Evidence