Certificate Transparency and PKI

Certificate Transparency (CT) systems introduced the concept of "stable" logs where certificate issuance events are recorded in append-only Merkle trees. Once an entry is included in a signed tree head (STH) that has been widely observed, it becomes stable—any attempt to remove or modify it would be detectable.

KERI builds on these concepts but applies them specifically to the domain of identifier control authority and key management.

KERI's Approach

Identifier Stability

In KERI, an Autonomic Identifier (AID) achieves stability when its associated event sequence has been:

1. Published by the controller: The inception event and any subsequent establishment events have been created and signed
2. Witnessed by sufficient witnesses: The configured threshold of witnesses (as specified by the Threshold of Accountable Duplicity or TOAD) have observed and receipted the events
3. Verified by watchers: A quorum of watchers (if configured) have independently verified the event sequence
4. Cryptographically validated: All signatures, digests, and pre-rotation commitments have been verified

The stability threshold for an identifier is reached when the KAACE (KERI's Agreement Algorithm for Control Establishment) consensus mechanism confirms that enough witnesses agree on the event sequence. This typically requires:

• At least M witnesses (where M >= N - F, with N being total witnesses and F being maximum faulty witnesses)
• Consistent event ordering across all confirming witnesses
• Valid cryptographic proofs for all events in the sequence

Key Rotation Stability

Key rotation events present a particularly important case for stability. After a controller issues a rotation event:

1. Pending State: The rotation event exists but has not been fully witnessed
2. Witnessing Phase: Witnesses observe the event and create receipts
3. Propagation Phase: Receipts are distributed and collected
4. Stable State: Sufficient receipts confirm the rotation, and the new keys are considered authoritative

During the transition from pending to stable, validators may encounter both the old and new key states. KERI's first-seen policy and duplicity detection mechanisms ensure that once a rotation achieves stability, any conflicting rotation attempts can be detected as duplicitous behavior.

The pre-rotation mechanism in KERI adds an additional layer of stability assurance: the commitment to next keys is made stable in the previous establishment event, creating a cryptographic chain that makes unauthorized rotations detectable even if they achieve witness consensus.

Event Log Stability

A Key Event Log (KEL) achieves stability when:

• All events in the log are internally consistent (proper hash chaining)
• All events have valid signatures from the authoritative keys at the time of signing
• The log has been witnessed according to the controller's witness configuration
• No duplicitous versions of the log have been detected

The Key Event Receipt Log (KERL), which includes witness receipts, provides stronger stability guarantees than a bare KEL because it includes cryptographic proof that designated witnesses observed the events.

Credential Stability

For ACDCs (Authentic Chained Data Containers), stability involves:

1. Issuance Stability: The credential's issuance event is anchored to a stable KEL event
2. Registry Stability: The credential's status in the Transaction Event Log (TEL) registry is stable
3. Schema Stability: The credential's schema SAID references a stable, immutable schema definition
4. Chain Stability: Any chained credentials (via edges) have achieved stability

A credential cannot be considered fully stable until all elements of its verification chain are stable, including the issuer's AID, any delegating AIDs in the authorization chain, and the registry tracking its issuance/revocation status.

Stability vs. Finality

KERI's concept of stability differs from blockchain finality in important ways:

• No Global Ordering Required: KERI events only need to be ordered within a single identifier's history, not globally across all identifiers
• Witness-Based Rather Than Consensus-Based: Stability depends on designated witnesses rather than network-wide consensus
• Duplicity Detection Rather Than Prevention: KERI allows duplicitous events to exist but makes them detectable, whereas blockchains prevent conflicting transactions
• Configurable Thresholds: Each identifier can have different stability requirements based on its witness configuration

Practical Stability Determination

Implementations determine stability through:

function isStable(event, witnesses, watchers) {
  // Check witness receipts
  receipts = getReceipts(event)
  if (receipts.count < threshold) {
    return false  // Insufficient witness confirmation
  }
  
  // Check for duplicity
  if (detectDuplicity(event, witnesses)) {
    return false  // Duplicitous event cannot be stable
  }
  
  // Check watcher confirmation (if configured)
  if (watchers.configured && !watchersConfirm(event)) {
    return false  // Watcher disagreement
  }
  
  return true  // Event is stable
}

Practical Implications

For Identifier Controllers

Controllers must understand that newly created identifiers or rotated keys are not immediately stable. There is a propagation period during which:

• Witnesses must observe and receipt events
• Receipts must be collected and verified
• Watchers (if used) must confirm consistency

During this period, verifiers may not yet recognize the new key state. Controllers should:

• Wait for stability before relying on new keys for critical operations
• Monitor witness receipt collection to ensure stability is achieved
• Configure appropriate witness thresholds for their security requirements

For Verifiers

Verifiers must check stability before trusting identifier key states:

• Query sufficient witnesses to confirm event consistency
• Check for duplicity by comparing event versions from multiple sources
• Respect the identifier's configured witness threshold
• Consider using watchers for additional verification

Verifying against unstable key states creates security vulnerabilities, as the key state may not yet be authoritative or may be subject to duplicity.

For Credential Issuers

Issuers should ensure stability before issuing credentials:

• Verify that the issuee's AID is stable
• Ensure the issuer's own AID is stable
• Confirm that any delegating AIDs in the authorization chain are stable
• Wait for registry anchoring events to achieve stability

Issuing credentials against unstable identifiers can result in credentials that cannot be verified or that reference key states that may change.

For Infrastructure Operators

Witness and watcher operators play a critical role in stability:

• Witnesses must promptly observe and receipt events to enable stability
• Watchers must maintain consistent views and detect duplicity
• Infrastructure must be reliable to avoid stability delays
• Operators should monitor for duplicity and alert controllers

Performance Considerations

Stability introduces latency into KERI operations:

• Identifier creation requires witness propagation time
• Key rotations cannot be used immediately
• Credential issuance depends on multiple stability checks

Systems must balance security requirements (higher witness thresholds, more watchers) against performance needs (faster stability achievement). The configurable nature of KERI's witness thresholds allows this trade-off to be tuned per identifier.

Security Trade-offs

Stability provides security guarantees but with trade-offs:

• Higher thresholds = stronger stability guarantees but slower achievement
• More witnesses = better duplicity detection but more infrastructure dependencies
• Watcher networks = additional verification but increased complexity

Controllers must choose stability parameters appropriate to their threat model and use case requirements.