Skip to content

Initiative: Four-Eyes Principle (Multi-Party Approval) #346

Description

@isanmaz

Problem Statement

Sensitive key operations — especially L1 revocation and kill switch execution — can currently be performed by a single person. This violates separation of duties requirements for regulated industries and creates a single point of failure for the most irreversible operations.

Business Context

PCI-DSS dual control, NIST SP 800-57 M-of-N key custodianship, and eIDAS 2.0 all require that no single individual can execute a key destruction or root key revocation alone. Krypton already has the M-of-N quorum mechanism — CMK must configure which operations trigger it and provide the approval workflow and permanent audit record.

Note: Platform Mesh is building a policy operator (platform-mesh/backlog#268) that may provide a workflow UI layer. However, it cannot serve as the audit record (CRs are deleted after execution) — OpenKCM must capture its own permanent audit entry independently.

Scope

In scope:

  • Four-eyes enforcement for: L1 registration, L1 disable/revoke, kill switch execution (soft and hard)
  • Configurable M-of-N per account (default: 2 of N)
  • Permanent audit record of approvals — independent of any external workflow engine
  • Initiator cannot be the approver — enforced structurally
  • Configurable timeout: if approval not given within N minutes, operation is auto-cancelled

Out of scope:

  • Platform Mesh policy operator integration (referenced but not owned by this initiative)
  • Recovery from suspended state

Acceptance Criteria

  • L1 registration, L1 revocation, and kill switch execution require approval from at least one additional authenticated person before execution
  • The system structurally prevents the initiator from also being the approver
  • If approval is not given within the configured timeout, the pending operation is automatically cancelled and logged
  • A permanent, tamper-evident audit record is written at the moment of execution containing: initiator identity, approver identity, operation, key ID, timestamp, outcome
  • Pending approval requests are visible to eligible approvers in the OpenKCM UI

Success Metrics

  • Zero single-person L1 revocations or kill switch executions in production
  • Approval audit records present for 100% of sensitive operations

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

cmk: standaloneCMK delivered as a standalone portalinitiativeProduct initiative — business requirement with scope and acceptance criteria

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions