Skip to main content

Entity credentials and their lifecycle

Every principal is issued material in three formats at once, and the interesting claim is not the issuance. It is that all three are carried through a complete lifecycle at operational parity: each of X.509, SSH and OpenPGP implements issue, sign, verify, revoke and rotate.

Most platforms have one real credential system and two adapters. Here the question "can you revoke an SSH certificate as reliably as an X.509 one" has the same answer for both.

The three formats​

FormatWhat it establishesLifecycle
X.509Transport and document identity, carrying entity ID and clearanceIssue, sign, verify, revoke, rotate
SSHSession identityIssue, sign, verify, revoke, rotate
OpenPGPSigned and encrypted artifactsIssue, sign, verify, revoke, rotate

There is no principal kind that holds one format and not the others, and there is no separate machine-identity system issuing a different sort of credential to a service or a device.

The OpenPGP implementation is real, and asymmetric on purpose​

It is a full OpenPGP implementation, not a shell around a binary: packet parsing, armor, keyrings, string-to-key, encryption, signing and verification.

It consumes two RFC generations, 4880 (v4) and 9580 (v6), and emits v4 only. That asymmetry is deliberate rather than unfinished: the platform is accept-before-emit on the newer generation, so a peer's v6 material verifies and decrypts here while nothing produced here forces a peer to understand v6 yet.

Revocation​

Revocation spans all three formats and is not a single table anyone can miss.

  • A gossip revocation bus propagates a revocation across peers rather than relying on every verifier to poll the same endpoint.
  • Pre-flight checks run before an operation rather than discovering the revocation afterward.
  • Typed reason codes, so a denial says which rule refused.
  • Per-format artifacts: X.509 CRL, SSH KRL with its own propagation path, and PGP revocation.
  • OCSP with a responder and a staple cache, so revocation is answered on the wire rather than in a side lookup.
  • A rehydrate path, so a verifier recovering from cold state rebuilds what it must not accept.

Rotation is an atomic, coordinated act​

Rotation is where most credential systems quietly become inconsistent: half the estate has the new material, half has the old, and nobody can say which.

Here rotation is discovered and coordinated as an atomic unit across peers, with:

  • a rotation distributor and phased rollout, so material moves in controlled waves;
  • a material registry recording what should be current;
  • gossip-based consistency checking that verifies every peer converged on the same material; and
  • rotation observability, so the operation is watchable rather than inferred.

That consistency check is the load-bearing part. Distributing new material is easy. Proving the estate agrees about what is current is the thing that keeps a rotation from becoming a partial outage.

Drift, compromise and inspection​

Three capabilities sit around the lifecycle and are worth naming separately because they are what turn a credential store into an operable one.

Drift detection. Certificate-lifecycle snapshots and a drift detector, a key-use drift detector, a baseline provider and an observation feed. Divergence from the intended crypto posture becomes a detected event rather than a thing someone notices during an audit.

Compromise response. A compromise log and event model, plus an orchestrator that cascades consequences to dependent material. Revoking a key that other material was derived from is not a single-row update, and treating it as one is how a compromise survives its own remediation. There is a bridge into the security event stream, so a compromise is visible to detection rather than only to the crypto plane.

Inspection and reporting. Read-only inspectors describe a certificate chain, a key, a PGP transferable key or a trust anchor, and render the result as a report, so an auditor can be handed an answer rather than database access.

Compartments and algorithm agility​

Compartments carry clearance labels with dominance comparison, a compartment registry, per-compartment key derivation, and typed refusal codes. Compartment separation is therefore cryptographic rather than a flag on a row.

Algorithm agility is the answer to "what happens when this curve is broken": an algorithm registry, peer capability negotiation, a policy resolver, and a migration planner for moving material off a deprecated algorithm. The plan exists before the emergency.

Verification on the receiving side​

Issuance without verification is theatre, so the verifying side is explicit.

Full RFC 5280 path validation walks the whole chain, enforcing signatures, validity intersection, revocation, and name and basic constraints at every hop, rather than checking the leaf and trusting the rest.

Certificate transparency maintains an RFC 6962 Merkle log for issued X.509 and SSH certificates with signed timestamps, a monitor, chain validation, an inventory, and a public-log submitter. The question it answers is was a certificate issued behind my back, which no amount of leaf validation can answer.

Threshold, escrow and external custody​

  • Shamir secret sharing with share management and an m-of-n signer, plus key ceremonies that collect approvals before a secret is reassembled.
  • Escrow with legal-hold records, so recovery needs a quorum rather than a single custodian.
  • Key exchange between cells: packaging, transport, delivery validation, key-encryption-key exchange and a witnessed ceremony.
  • External custody bridges to AWS KMS, Azure Key Vault, GCP KMS and HashiCorp Vault transit, with a bring-your-own-key registry, or material stays in-platform on TPM, PKCS#11 or YubiKey hardware.