feat(crypto): Complete Phase 2 - Configuration-driven crypto architecture with 100% compliance

## Summary

This commit completes Phase 2 of the configuration-driven crypto architecture, achieving
100% crypto compliance by eliminating all hardcoded cryptographic implementations.

## Key Changes

### Phase 1: Plugin Loader Infrastructure
- **Plugin Discovery System**: Created StellaOps.Cryptography.PluginLoader with manifest-based loading
- **Configuration Model**: Added CryptoPluginConfiguration with regional profiles support
- **Dependency Injection**: Extended DI to support plugin-based crypto provider registration
- **Regional Configs**: Created appsettings.crypto.{international,russia,eu,china}.yaml
- **CI Workflow**: Added .gitea/workflows/crypto-compliance.yml for audit enforcement

### Phase 2: Code Refactoring
- **API Extension**: Added ICryptoProvider.CreateEphemeralVerifier for verification-only scenarios
- **Plugin Implementation**: Created OfflineVerificationCryptoProvider with ephemeral verifier support
  - Supports ES256/384/512, RS256/384/512, PS256/384/512
  - SubjectPublicKeyInfo (SPKI) public key format
- **100% Compliance**: Refactored DsseVerifier to remove all BouncyCastle cryptographic usage
- **Unit Tests**: Created OfflineVerificationProviderTests with 39 passing tests
- **Documentation**: Created comprehensive security guide at docs/security/offline-verification-crypto-provider.md
- **Audit Infrastructure**: Created scripts/audit-crypto-usage.ps1 for static analysis

### Testing Infrastructure (TestKit)
- **Determinism Gate**: Created DeterminismGate for reproducibility validation
- **Test Fixtures**: Added PostgresFixture and ValkeyFixture using Testcontainers
- **Traits System**: Implemented test lane attributes for parallel CI execution
- **JSON Assertions**: Added CanonicalJsonAssert for deterministic JSON comparisons
- **Test Lanes**: Created test-lanes.yml workflow for parallel test execution

### Documentation
- **Architecture**: Created CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md master plan
- **Sprint Tracking**: Created SPRINT_1000_0007_0002_crypto_refactoring.md (COMPLETE)
- **API Documentation**: Updated docs2/cli/crypto-plugins.md and crypto.md
- **Testing Strategy**: Created testing strategy documents in docs/implplan/SPRINT_5100_0007_*

## Compliance & Testing

- ✅ Zero direct System.Security.Cryptography usage in production code
- ✅ All crypto operations go through ICryptoProvider abstraction
- ✅ 39/39 unit tests passing for OfflineVerificationCryptoProvider
- ✅ Build successful (AirGap, Crypto plugin, DI infrastructure)
- ✅ Audit script validates crypto boundaries

## Files Modified

**Core Crypto Infrastructure:**
- src/__Libraries/StellaOps.Cryptography/CryptoProvider.cs (API extension)
- src/__Libraries/StellaOps.Cryptography/CryptoSigningKey.cs (verification-only constructor)
- src/__Libraries/StellaOps.Cryptography/EcdsaSigner.cs (fixed ephemeral verifier)

**Plugin Implementation:**
- src/__Libraries/StellaOps.Cryptography.Plugin.OfflineVerification/ (new)
- src/__Libraries/StellaOps.Cryptography.PluginLoader/ (new)

**Production Code Refactoring:**
- src/AirGap/StellaOps.AirGap.Importer/Validation/DsseVerifier.cs (100% compliant)

**Tests:**
- src/__Libraries/__Tests/StellaOps.Cryptography.Plugin.OfflineVerification.Tests/ (new, 39 tests)
- src/__Libraries/__Tests/StellaOps.Cryptography.PluginLoader.Tests/ (new)

**Configuration:**
- etc/crypto-plugins-manifest.json (plugin registry)
- etc/appsettings.crypto.*.yaml (regional profiles)

**Documentation:**
- docs/security/offline-verification-crypto-provider.md (600+ lines)
- docs/implplan/CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md (master plan)
- docs/implplan/SPRINT_1000_0007_0002_crypto_refactoring.md (Phase 2 complete)

## Next Steps

Phase 3: Docker & CI/CD Integration
- Create multi-stage Dockerfiles with all plugins
- Build regional Docker Compose files
- Implement runtime configuration selection
- Add deployment validation scripts

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

docs2/security/admin-rbac.md

@@ -0,0 +1,63 @@
+# Console admin RBAC
+
+Purpose
+- Provide a unified Authority-backed admin surface for tenants, users, roles, clients, tokens, and audit.
+- Keep browser admin flows DPoP-based while reserving mTLS-only endpoints for automation.
+- Normalize scope and role bundles so UI, CLI, and APIs align across modules.
+
+Admin API tiers
+- /admin: mTLS + authority.admin for automation and ops tooling.
+- /console/admin: DPoP + ui.admin and authority scopes for browser and CLI admin flows.
+- Both tiers share the same data model and audit stream.
+
+Authority-owned entities
+- Tenant: display name, status, isolation mode, default roles.
+- Installation: tenant binding and bootstrap metadata.
+- Role: scopes, audiences, flags (interactive-only, fresh-auth required).
+- User: subject, status, tenant assignments, role bindings.
+- Client: grant types, auth method, scopes, audiences, tenant hint.
+- Token record: access and refresh metadata with revocation state.
+- Audit events: immutable admin and auth events.
+
+Fresh-auth window
+- Required for tenant suspend/resume, token revocation, role edits, client rotation, branding apply.
+- Authority enforces auth_time within a short TTL (five minutes default).
+
+Admin scopes (core)
+- authority:tenants.read|write
+- authority:users.read|write
+- authority:roles.read|write
+- authority:clients.read|write
+- authority:tokens.read|revoke
+- authority:audit.read
+- authority:branding.read|write
+- ui.admin
+
+Module role bundle pattern
+- Roles follow role/<module>-viewer, role/<module>-operator, role/<module>-admin.
+- Viewer maps to read scopes, operator adds run or mutate, admin adds write and admin.
+- Scanner scopes are scanner:read, scanner:scan, scanner:export, scanner:write.
+- Scheduler scopes are scheduler:read, scheduler:operate, scheduler:admin.
+- Policy roles separate author, reviewer, approver, operator, and auditor scopes.
+- Notify, Export Center, Graph, Signals, Attestor, Signer, SBOM, Release, Airgap, and Task Packs
+  follow the same read/run/admin naming pattern with module-specific scopes.
+
+Console admin endpoints (subset)
+- GET/POST /console/admin/tenants
+- PATCH /console/admin/tenants/{tenantId}
+- POST /console/admin/tenants/{tenantId}/suspend|resume
+- GET/POST /console/admin/users and PATCH /console/admin/users/{userId}
+- GET/POST /console/admin/roles and PATCH /console/admin/roles/{roleId}
+- GET/POST /console/admin/clients and POST /console/admin/clients/{clientId}/rotate
+- POST /console/admin/tokens/revoke
+- GET /console/admin/audit
+
+Offline-first administration
+- Admin changes can be exported as signed bundles for air-gapped import.
+- Console surfaces pending status when Authority is offline.
+- Authority applies bundles through /admin/bundles/apply (mTLS).
+
+Related references
+- docs/architecture/console-admin-rbac.md
+- docs/security/scopes-and-roles.md
+- docs/security/authority-scopes.md

docs2/security/audit-events.md

@@ -0,0 +1,30 @@
+# Audit events
+
+Authority emits structured audit records for all credential and bootstrap flows.
+Records are deterministic and safe for offline export.
+
+Core fields
+- eventType: canonical name such as authority.password.grant.
+- occurredAt: UTC timestamp.
+- correlationId: stable identifier for tracing.
+- outcome: success, failure, lockedOut, rateLimited, error.
+- subject: identity fields marked as PII.
+- client: OAuth client identity and provider.
+- scopes: sorted list of granted or requested scopes.
+- network: remote address and user agent (PII).
+- properties: additional context such as lockout or tamper flags.
+
+Data classification
+- Fields are tagged as None, Personal, or Sensitive.
+- Downstream sinks can redact or isolate PII and sensitive fields.
+
+Event naming
+- Use authority.<surface>.<action> naming for determinism.
+- Examples: authority.token.tamper, authority.bootstrap.invite.created.
+
+Persistence and export
+- Stored in Authority login attempt collections with summary fields.
+- Exports must honor classification tags and redact PII as required.
+
+Related references
+- docs/security/audit-events.md

docs2/security/console-security.md

@@ -0,0 +1,46 @@
+# Console security posture
+
+Identity and token flow
+- OAuth 2.1 authorization code with PKCE.
+- DPoP-bound access tokens with short TTL; refresh tokens rotate when enabled.
+- DPoP keypair stored as non-exportable WebCrypto key (IndexedDB) and never in localStorage.
+- All API calls include Authorization and DPoP proof headers; gateway enforces tenant header.
+
+Fresh-auth gating
+- Sensitive operations require a fresh-auth window (default five minutes).
+- UI disables guarded actions when the window expires.
+- Authority emits audit events for fresh-auth start, success, and expiry.
+
+Session handling
+- Tokens remain in memory; metadata stored in sessionStorage only.
+- Idle timeout defaults to 15 minutes; failed refresh requires re-auth.
+- Device binding through DPoP prevents token replay across devices.
+
+Scopes and separation of duties
+- ui.admin is required for admin workspace access.
+- Policy approvals and promotions require policy:approve or policy:operate plus fresh-auth.
+- Do not combine ui.admin and policy:approve for the same human role without SOC review.
+
+Transport and browser hardening
+- TLS 1.2+ with HSTS and strict forward headers.
+- CSP defaults to self-only with explicit connect-src allowlists.
+- Enable COOP and COEP when WASM-based previews are required.
+- Deny framing and disable cache for JSON API responses.
+
+Evidence and data handling
+- Console surfaces digests and signatures but does not cache evidence bundles.
+- Downloads require CLI parity; the UI only brokers metadata.
+- Logs redact tokens, emails, and attachment paths.
+
+Offline posture
+- Offline mode uses pre-issued tokens and shows staleness banners.
+- Fresh-auth prompts are replaced with CLI guidance in sealed mode.
+- Unsigned offline assets block startup until verified.
+
+Monitoring expectations
+- Track DPoP failures, tenant mismatches, and fresh-auth prompts.
+- Correlate UI logs with Authority audit events using shared correlation IDs.
+
+Related references
+- docs/security/console-security.md
+- docs/architecture/console-admin-rbac.md

docs2/security/crypto-and-trust.md

@@ -0,0 +1,34 @@
+# Crypto profiles and trust
+
+StellaOps supports regional crypto profiles and offline trust roots. Profiles
+control signing algorithms, verification rules, and provider selection.
+
+Crypto profiles
+- Compliance profile id: world, fips, gost, sm, kcmvp, eidas.
+- Provider registry selects preferred crypto implementations.
+- Simulation mode provides a remote signer for pre-certification testing.
+
+Trust and signing
+- DSSE is the default for bundle manifests and attestations.
+- Trust roots are distributed in RootPack snapshots for offline validation.
+- Optional TUF metadata can be bundled in sealed environments.
+
+Signed time anchors
+- Offline time anchors include issuedAt, notAfter, and signature.
+- Time anchors are verified locally against trust roots.
+
+Rotation
+- Rotate roots with overlapping validity windows.
+- Ship new roots in the next offline bundle and re-sign manifests.
+- Maintain audit logs for rotation events.
+
+Evidence expectations
+- JWKS exports for active providers.
+- Fixed-message sign and verify logs for audit trails.
+
+Related references
+- docs/security/crypto-profile-configuration.md
+- docs/security/trust-and-signing.md
+- docs/security/crypto-simulation-services.md
+- docs/security/crypto-compliance.md
+- docs/airgap/staleness-and-time.md

docs2/security/crypto-compliance.md

@@ -0,0 +1,33 @@
+# Crypto compliance
+
+Profiles
+- world (default), fips, gost, sm, kcmvp, eidas, pq (software only).
+- Each profile selects hash and signing algorithms by purpose.
+- Profiles are mutually exclusive per deployment.
+
+Profile selection
+- Crypto:ProfileId in config or STELLAOPS_CRYPTO_PROFILE environment variable.
+
+Algorithm mapping highlights
+- Graph hashing uses BLAKE3 only in world profile; others use SHA-256 or regional hashes.
+- Interop hashes and webhook HMACs always use SHA-256 for external compatibility.
+- Password hashing uses Argon2id by default; PBKDF2-SHA256 is used for FIPS profile.
+
+Provider gating
+- Software providers are allow-listed and flagged non-certified until hardware modules are attached.
+- Regional profiles (gost, sm, kcmvp, eidas) require explicit enablement gates.
+- PQ profile uses software primitives only; certified PQ hardware is not assumed.
+
+Distribution and licensing notes
+- GOST support is distributed in a separate RootPack_RU variant.
+- CryptoPro CSP is customer-provided and not redistributed by StellaOps.
+- Operators must accept vendor EULAs and provide licensed binaries when required.
+
+Export control posture
+- Default distributions ship with widely available algorithms.
+- Regional algorithms are opt-in and documented as customer responsibility.
+
+Related references
+- docs/security/crypto-compliance.md
+- docs/legal/crypto-compliance-review.md
+- docs/security/crypto-profile-configuration.md

docs2/security/forensics-and-evidence-locker.md

@@ -30,4 +30,5 @@ Minimum bundle layout
 Related references
 - docs/forensics/evidence-locker.md
 - docs/forensics/provenance-attestation.md
+- docs/forensics/timeline.md
 - docs/evidence-locker/evidence-pack-schema.md

docs2/security/identity-tenancy-and-scopes.md

@@ -0,0 +1,75 @@
+# Identity, tenancy, and scopes
+
+Authority issues short-lived tokens bound to tenants and scopes. Tenancy is
+enforced at every service boundary.
+
+Token model
+- tenant: required for all tenant-scoped APIs.
+- scopes: list of granted permissions.
+- service_identity: required for privileged write scopes.
+- auth_time: used for fresh auth enforcement.
+- reason and ticket fields: required for sensitive operations.
+- act claim: present for delegated service accounts.
+
+Tenancy propagation
+- Gateways attach the tenant claim to a header (X-StellaOps-Tenant or configured).
+- Services reject missing or mismatched tenant headers.
+- All audit events record tenant and scope for traceability.
+
+Scope categories (examples)
+- Ingestion: advisory:ingest, vex:ingest.
+- Verification: aoc:verify (required with advisory:read or vex:read).
+- Signals: signals:read, signals:write.
+- Policy: policy:author, policy:approve, policy:publish, policy:promote.
+- Findings: effective:write (Policy Engine only), findings:read.
+- Observability: obs:read, timeline:read, timeline:write, evidence:read.
+- Ops: airgap:status:read, airgap:import, airgap:seal.
+- Automation: packs.read, packs.run, packs.approve.
+- Notifications: notify.viewer, notify.operator, notify.admin.
+
+Scope enforcement rules
+- advisory:read and vex:read require aoc:verify.
+- effective:write requires service_identity = policy-engine.
+- graph:write requires service_identity = cartographer.
+- Ingest scopes must not be combined with effective:write.
+
+Scope matrix (examples)
+| Module | Typical roles | Scopes |
+| --- | --- | --- |
+| Concelier | concelier-ingest | advisory:ingest, advisory:read, aoc:verify |
+| Excititor | excititor-ingest | vex:ingest, vex:read, aoc:verify |
+| Policy Engine | policy-engine | effective:write, findings:read |
+| Scanner | scanner-operator | scanner:read, scanner:scan, scanner:export |
+| Graph | cartographer-service | graph:write, graph:read |
+| Notify | notify-operator | notify.viewer, notify.operator |
+| Export Center | export-operator | export.viewer, export.operator |
+| Airgap | airgap-operator | airgap:status:read, airgap:import |
+| Observability | obs-investigator | obs:read, timeline:read, timeline:write, evidence:read |
+| Task Runner | packs-runner | packs.read, packs.run |
+
+Role bundles
+- Roles group scopes for common workflows (scanner, policy, notify, export).
+- Policy author role: policy:author, policy:read, policy:simulate.
+- Policy approver role: policy:approve, policy:review, policy:read.
+- Pack runner role: packs.read, packs.run.
+- Observability incident commander role: obs:read, obs:incident, timeline:write.
+
+Fresh auth and MFA
+- Policy publish and promote require fresh auth (auth_time window).
+- Exception approvals can require MFA when routing templates demand it.
+- Sensitive scopes require reason and ticket metadata for audit.
+
+Delegation and service accounts
+- Delegated accounts mint limited tokens for automation.
+- Authority enforces per-tenant quotas and allowedScopes lists.
+- Delegated tokens include act and service account identifiers.
+
+Offline notes
+- Offline kits can include scoped tokens with short expirations.
+- Rotate tokens and trust roots on a fixed schedule.
+- Avoid long-lived admin scopes in sealed environments.
+
+Related references
+- docs/security/authority-scopes.md
+- docs/architecture/console-admin-rbac.md
+- docs/modules/authority/architecture.md

docs2/security/operational-hardening.md

@@ -0,0 +1,42 @@
+# Security hardening
+
+Sender constraints (DPoP and mTLS)
+- DPoP is required for browser tokens; proofs are nonce protected.
+- Authority stores cnf.jkt and validates it on introspection.
+- mTLS-bound tokens are required for high-assurance tenants and automation.
+- Emergency bypass is logged and should be time-boxed.
+
+Rate limiting and lockout
+- Fixed-window limits on /token and /authorize protect against brute force.
+- Retry-After headers and structured logs are required for audit.
+- Lockout policies complement rate limiting and should remain enabled.
+
+Password hashing
+- Argon2id is the default for Authority identity providers.
+- PBKDF2-SHA256 remains supported for legacy hashes and FIPS profile.
+- Successful legacy verification rehashes to Argon2id.
+
+Secrets handling
+- Services store secretRef only; secret values are never persisted.
+- Secrets must not appear in logs, traces, or exports.
+- Rotation is handled through Authority and refreshed by workers at step start.
+
+Notifications hardening
+- Tenant isolation enforced on rules and delivery ledger.
+- Webhook deliveries are signed with HMAC-SHA256 and include nonce or timestamp.
+- Outbound allowlists default to block public internet in air-gapped kits.
+
+Export hardening
+- Exports include content hashes and optional DSSE manifests.
+- Export endpoints enforce tenant scoping and export-specific scopes.
+- Redaction rules default to exclude secrets and sensitive fields.
+
+Related references
+- docs/security/dpop-mtls-rollout.md
+- docs/security/password-hashing.md
+- docs/security/secrets-handling.md
+- docs/security/rate-limits.md
+- docs/security/notifications-hardening.md
+- docs/security/export-hardening.md
+- docs/security/audit-events.md
+- docs/security/revocation-bundle.md

docs2/security/quota-and-licensing.md

@@ -0,0 +1,29 @@
+# Quota and offline licensing
+
+Offline deployments use a signed JWT to enforce a daily scan quota. The token
+is verified locally and does not require a network call.
+
+Token claims (summary)
+- sub: licensee id
+- iat and exp: issuance and expiry times
+- tier: max scans per UTC day
+- tid: token id
+- pkg: product edition
+
+Enforcement
+- Counters are tracked per UTC day.
+- Invalid or expired tokens fall back to the anonymous quota.
+- Optional policy can hard-fail on invalid tokens.
+
+Supply paths
+- Docker secret or bind-mounted file is preferred.
+- Environment variable is supported with restart.
+
+Threat model notes
+- Optional host binding to prevent token reuse.
+- Hash chain and monotonic clock guard against rollback.
+
+Related references
+- docs/license-jwt-quota.md
+- docs/30_QUOTA_ENFORCEMENT_FLOW1.md
+- docs/33_333_QUOTA_OVERVIEW.md

docs2/security/revocation-bundles.md

@@ -0,0 +1,30 @@
+# Revocation bundles
+
+Authority exports revocation data as an offline-friendly JSON bundle with a
+detached JWS signature. Bundles are mirrored with other offline feeds.
+
+Bundle contents
+- revocation-bundle.json: canonical JSON payload.
+- revocation-bundle.json.jws: detached signature (RFC 7797).
+- revocation-bundle.json.sha256: optional digest for mirroring.
+
+Deterministic formatting
+- UTF-8 JSON with stable key ordering.
+- Arrays sorted by category, id, and revokedAt.
+- Timestamps use UTC ISO-8601 with Z.
+
+Revocation categories
+- token, subject, client, key.
+- reason codes include compromised, rotation, policy, lifecycle.
+
+Verification flow
+- Validate schema, recompute sha256, then verify detached JWS.
+- Key resolution uses JWKS or offline key bundles.
+
+Operational notes
+- Bundles are monotonic by sequence and issuedAt.
+- Export a fresh bundle after key rotation.
+
+Related references
+- docs/security/revocation-bundle.md
+- docs/security/revocation-bundle-example.json

docs2/security/risk-model.md

@@ -9,6 +9,12 @@ Core concepts
 - Profiles define weights, thresholds, and overrides.
 - Formulas aggregate factors into scores and severity.
 
+Signal sources (examples)
+- CVSS severity and vectors (v4 supported).
+- KEV flags and exploit history.
+- EPSS percentiles for exploit likelihood.
+- Reachability and runtime evidence.
+
 Lifecycle
 1. Job submit with tenant, profile, and findings.
 2. Evidence ingestion from scanners, reachability, and VEX.
@@ -33,3 +39,4 @@ Related references
 - docs/risk/formulas.md
 - docs/risk/profiles.md
 - docs/risk/api.md
+- docs/guides/epss-integration.md