Skip to content

Core Concepts: Approval Workflow

The approval workflow is a central security mechanism in the Cryptera Keyserver.
It ensures that sensitive signing keys cannot be used without explicit authorization from one or more human approvers. Even the number of times a key is used can be restricted.

This section explains how approvals work, why they exist, and how they fit into the overall signing process.

Why Approvals Are Required

Private signing keys are highly sensitive.
Even though keys never leave the HSM, malicious or accidental signing still poses risks:

  • Compromised CI pipelines could issue unauthorized firmware
  • Developers could sign code that has not passed review
  • Manufacturing tools could generate unauthorized device certificates
  • A single insider could abuse a high-value production key

Approvals introduce a human checkpoint before a signing operation is allowed to proceed.

With approvals:

  • Orderers request the ability to use a key and the number of times it is needed
  • Approvers authorize that request
  • The Keyserver only performs signing once the required number of approvals is met

This enforces the “four-eyes principle” (or more) for security-critical workflows.

Approval Requirements

Each signing key defines how many approvals are required before it can be used.

Typical configurations:

  • Development keys → 0 approver
  • Production firmware keys → 1-2+ approvers
  • CA keys → 1-2+ approvers Root keys are implicit used to sign CA certificates, but this process is protected by the administration session concept. Approval requirements are defined per key and enforced automatically.

Approval Workflow Overview

The approval workflow consists of four stages:

1. Operation Requested

A subject with an orderer role creates a new operation.

This includes:

  • The key(s) they want to use
  • Usage count for each key
  • A human-readable description
  • A validity window
  • A description of the context intended for the approver

The operation is now in pending state.

2. Operation Appears in Approver’s Queue

Approvers log in to the Keyserver UI and open the Approval page.

For each pending operation, they can see:

  • Who requested it
  • When it was requested
  • The keys involved
  • The requested usage counts
  • Who has already approved (if approver count is more than one)
  • The description provided by the orderer
  • Optional/Configurable JWT claims from access token (sometimes identifies pipelines etc.)

The UI lists only operations relevant to the approver’s roles.

The operation is visible until all approvers has approved.

3. Approver Reviews and Authorizes

Approvers may:

  • Approve the operation
  • Revoke the operation
  • Take no action (until expiry)

The number of required approvals is determined by the key configuration.

Once the required number of approvals is met, the operation becomes approved.

4. Operation Becomes Active

Once approved:

  • The client may submit sign orders (or create device certificates)
  • Each sign order consumes one usage count on the used key
  • If the count reaches zero, the key can no longer be used in this operation
  • When the validity window expires, the operation closes automatically

Approvals cannot be revoked once a sign order has been executed.

Approval Expiration

All operations include a validms field that defines how long the approval remains valid.

Reasons for expiration:

  • Prevent unattended operations from lingering
  • Enforce that signing happens close to the review time
  • Limit window for potential compromise
  • Require explicit approvals for each release cycle

Expired operations cannot be reactivated.

Revocation by Approvers or Administrators

Before any sign order is executed:

  • Approvers may reject their approval
  • Administrators may revoke the entire operation

Once a signature has been issued, the operation can be revoked so no more signings are possible within that operation..

Approvals in Multi-Key Operations

An operation may include multiple keys. Each key enforces its own approval requirements.

Example:

{
  "new-keyusagerestrictions": [
    { "keyid": "fw-dev", "maxusagecount": 1 },
    { "keyid": "fw-prod", "maxusagecount": 1 }
  ]
}

If:

  • fw-dev requires 0 approvers
  • fw-prod requires 2 approvers

Then the operation remains pending until both approvers for fw-prod have signed off.

This ensures that more sensitive keys retain stronger controls.

Note that signing using this operation is not possible for any key in the operartion before operation as a whole is approved. So fw-dev cannot be used until fw-prod is approved by two approvers. It's all or nothing.

Auditing Approvals

Every step in the approval workflow is logged:

  • Operation creation
  • Approval events (with user identity)
  • Rejections
  • Expirations
  • Sign orders executed

Auditing provides a complete trace of:

  • Who approved what
  • When approval occurred
  • What was signed
  • How many signatures were issued

This is essential for compliance, incident response, and root-cause analysis.

Note that approvals a not related to administration sessions even though it's found in the administration UI.

Summary

  • Approvals enforce human oversight for sensitive signing keys.
  • Each key defines its own approval count.
  • Orderers create operations; approvers authorize them. Orderers use operations for signing/certificate issue.
  • Operations remain pending until approval requirements are met.
  • Approvals are time-limited and fully audited.
  • No signature is issued until the operation becomes approved.

This workflow is a core part of the Keyserver’s security model, ensuring that cryptographic operations cannot occur without verified human intervention when required.