consolidation of some of the modules, localization fixes, product advisories work, qa work
This commit is contained in:
@@ -2660,4 +2660,92 @@ Meter: `StellaOps.Attestor.ProofChain.Receipts.Sidebar`
|
||||
null/empty/whitespace throws
|
||||
- DeriveVerificationStatus: single pass, single fail
|
||||
- Register: null throws
|
||||
- RegisterContext: null/empty/whitespace bundleId throws
|
||||
- RegisterContext: null/empty/whitespace bundleId throws
|
||||
|
||||
## Advisory Commitments (2026-02-26 Batch)
|
||||
|
||||
- `SPRINT_20260226_225_Attestor_signature_trust_and_verdict_api_hardening` governs:
|
||||
- DSSE signature verifier trust behavior (including deterministic failure reasons).
|
||||
- authority roster validation for verdict creation.
|
||||
- authenticated tenant context enforcement over header-only spoofable inputs.
|
||||
- deterministic verdict retrieval APIs for hash-based lookup.
|
||||
|
||||
- Rekor/tile verification commitments from `Deterministic tile verification with Rekor v2` are coordinated with Symbols sprint `SPRINT_20260226_226_Symbols_dsse_rekor_merkle_and_hash_integrity`.
|
||||
|
||||
---
|
||||
|
||||
## Trust Domain Model (Sprint 204 -- 2026-03-04)
|
||||
|
||||
### Overview
|
||||
|
||||
As of Sprint 204, the Attestor module directory (`src/Attestor/`) is the trust domain owner for three runtime services and their supporting libraries:
|
||||
|
||||
1. **Attestor** -- transparency log submission, inclusion proof verification, evidence caching
|
||||
2. **Signer** -- DSSE envelope creation, cryptographic signing (keyless/keyful/HSM), entitlement enforcement
|
||||
3. **Provenance** -- SLSA/DSSE attestation generation, Merkle tree construction, verification tooling
|
||||
|
||||
Source consolidation places all trust-domain code under a single directory for ownership clarity, while preserving runtime service identities and security boundaries.
|
||||
|
||||
### Trust Data Classification
|
||||
|
||||
| Data Category | Owner Service | Storage | Sensitivity |
|
||||
|---|---|---|---|
|
||||
| Attestation evidence (proofchain, inclusion proofs, Rekor entries) | Attestor | `attestor` PostgreSQL schema | High -- tamper-evident, integrity-critical |
|
||||
| Provenance evidence (SLSA predicates, build attestations, Merkle trees) | Provenance (library) | Consumed by Attestor/EvidenceLocker | High -- deterministic, reproducible |
|
||||
| Signer metadata (audit events, signing ceremony state, rate limits) | Signer | `signer` PostgreSQL schema | High -- operational security |
|
||||
| Signer key material (KMS/HSM refs, Fulcio certs, trust anchors, rotation state) | Signer (KeyManagement) | `key_management` PostgreSQL schema | Critical -- cryptographic trust root |
|
||||
|
||||
### PostgreSQL Schema Ownership
|
||||
|
||||
Each trust-domain service retains its own DbContext and dedicated PostgreSQL schema:
|
||||
|
||||
- **`attestor` schema** -- Owned by the Attestor service. Contains `entries`, `dedupe`, `audit` tables for transparency log state.
|
||||
- **`signer` schema** -- Owned by the Signer service. Contains signing ceremony audit, rate limit state, and operational metadata.
|
||||
- **`key_management` schema** -- Owned by the Signer KeyManagement library. Contains key rotation records, trust anchor configurations, and HSM/KMS binding metadata.
|
||||
|
||||
There is **no cross-schema merge**. Each service connects with its own connection string scoped to its own schema.
|
||||
|
||||
### Security Boundary: No-Merge Decision (ADR)
|
||||
|
||||
**Decision:** Signer key-material isolation from attestation evidence is a deliberate security boundary. The schemas will NOT be merged into a unified DbContext.
|
||||
|
||||
**Rationale:**
|
||||
- A merged DbContext would require a single connection string with access to both key material (signing keys, HSM/KMS bindings, trust anchors) and evidence stores (proofchain entries, Rekor logs).
|
||||
- This widens the blast radius of any credential compromise: an attacker gaining the Attestor database credential would also gain access to key rotation state and trust anchor configurations.
|
||||
- Schema isolation is a defense-in-depth measure. Each service authenticates to PostgreSQL independently, with schema-level `GRANT` restrictions.
|
||||
- The Signer's KeyManagement database contains material that, if compromised, could allow forging of signatures. This material must be isolated from the higher-volume, lower-privilege evidence store.
|
||||
|
||||
**Implications:**
|
||||
- No shared EF Core DbContext across trust services.
|
||||
- Each service manages its own migrations independently (`src/Attestor/__Libraries/StellaOps.Attestor.Persistence/` for Attestor; `src/Attestor/__Libraries/StellaOps.Signer.KeyManagement/` for Signer key management).
|
||||
- Cross-service queries (e.g., "find the signing identity for a given attestation entry") use API calls, not database joins.
|
||||
|
||||
### Source Layout (post-Sprint 204)
|
||||
|
||||
```
|
||||
src/Attestor/
|
||||
StellaOps.Attestation/ # DSSE envelope model library
|
||||
StellaOps.Attestation.Tests/
|
||||
StellaOps.Attestor/ # Attestor service (Core, Infrastructure, WebService, Tests)
|
||||
StellaOps.Attestor.Envelope/ # Envelope serialization
|
||||
StellaOps.Attestor.TileProxy/ # Rekor tile proxy
|
||||
StellaOps.Attestor.Types/ # Shared predicate types
|
||||
StellaOps.Attestor.Verify/ # Verification pipeline
|
||||
StellaOps.Signer/ # Signer service (Core, Infrastructure, WebService, Tests)
|
||||
StellaOps.Provenance.Attestation/ # Provenance attestation library
|
||||
StellaOps.Provenance.Attestation.Tool/ # Forensic verification CLI tool
|
||||
__Libraries/
|
||||
StellaOps.Attestor.*/ # Attestor domain libraries
|
||||
StellaOps.Signer.KeyManagement/ # Key rotation and trust anchor management
|
||||
StellaOps.Signer.Keyless/ # Keyless (Fulcio/Sigstore) signing support
|
||||
__Tests/
|
||||
StellaOps.Attestor.*/ # Attestor test projects
|
||||
StellaOps.Provenance.Attestation.Tests/ # Provenance test project
|
||||
```
|
||||
|
||||
### What Did NOT Change
|
||||
|
||||
- **Namespaces** -- All `StellaOps.Signer.*` and `StellaOps.Provenance.*` namespaces are preserved.
|
||||
- **Runtime service identities** -- Docker image names (`stellaops/signer`), container names, network aliases, and API base paths (`/api/v1/signer/`) are unchanged.
|
||||
- **Database schemas** -- No schema changes, no migrations, no data movement.
|
||||
- **API contracts** -- All endpoints including `/api/v1/signer/sign/dsse` remain stable.
|
||||
|
||||
@@ -123,3 +123,15 @@ stella bundle verify --bundle light-bundle/ --replay --blob-source https://regis
|
||||
- `docs/modules/attestor/guides/timestamp-policy.md`
|
||||
- `docs/modules/attestor/airgap.md`
|
||||
- `docs/modules/airgap/guides/staleness-and-time.md`
|
||||
|
||||
## 8. Deterministic Error Triage Guidance (Sprint 20260226_225)
|
||||
|
||||
Use stable error classes to route remediation:
|
||||
|
||||
- `signature_untrusted`: key not present in authority roster; refresh roster snapshot and retry.
|
||||
- `signature_revoked`: signing key revoked; rotate signer and regenerate attestation.
|
||||
- `tenant_mismatch`: authenticated tenant differs from verdict owner; re-run with correct principal context.
|
||||
- `verdict_not_found`: no verdict exists for requested hash; verify hash source and storage replication.
|
||||
|
||||
Operator rule:
|
||||
- Do not treat these as transient network faults unless the error class is explicitly retryable.
|
||||
|
||||
@@ -429,6 +429,7 @@ The 13-step verification algorithm:
|
||||
| 0501.6 | Database Schema Implementation | TODO |
|
||||
| 0501.7 | CLI Integration & Exit Codes | TODO |
|
||||
| 0501.8 | Key Rotation & Trust Anchors | TODO |
|
||||
| 20260226_225 | Signature trust + verdict API hardening | DONE |
|
||||
|
||||
## Related Documents
|
||||
|
||||
|
||||
Reference in New Issue
Block a user