path: root/docs/FOG-PKI.md

# FOG Public Key Infrastructure

Status: Draft 0.1

Date: 2026-08-08

## 1. Purpose

This document defines `FOG-PKI-1`, the normative directory, admission,
authority, consensus, revocation, topology, and transparency protocol for the
FOG network.

It refines the following baselines:

- `FOG-THREAT-MODEL.md`, especially `TM-NET-06`, `TM-PKI-01`,
  `TM-PKI-02`, `TM-PKI-03`, `TM-CRYPTO-01`, `TM-CRYPTO-02`, and
  `TM-AVAIL-01`;
- `FOG-ARCHITECTURE.md`, especially `ARC-005`, `ARC-007`, `ARC-008`,
  `ARC-009`, `IF-03`, `IF-04`, and `IF-05`.

FOG is not implemented. Requirements in this document are protocol targets,
not statements about deployed security.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY describe
normative requirements in the sense of BCP 14 when they appear in uppercase.

## 2. Security Goals

FOG-PKI MUST provide:

- one complete authenticated network view for a given epoch;
- M-of-N authority approval over identical canonical consensus bytes;
- public attribution of every authority signature;
- deterministic topology and parameter derivation from public inputs;
- permissioned admission and public role assignment;
- purpose-separated current and future node public keys;
- explicit validity, freshness, grace, and hard-expiry semantics;
- monotonic state that detects rollback and same-epoch forks;
- append-only consistency evidence for long-offline Composers;
- bounded key overlap, rotation, revocation, and authority replacement;
- public operator-family constraints for route selection;
- bounded deterministic parsing and offline verification;
- auditable evidence for authority, node, and checkpoint equivocation.

FOG-PKI does not provide:

- permissionless Sybil resistance;
- proof that nominally different operators are independent;
- availability after authority quorum loss;
- trusted time to an endpoint with no reliable clock;
- secrecy for public topology or node addresses;
- safety after compromise of the configured authority threshold;
- automatic recovery from loss of the pinned authority roots;
- anonymity by itself.

## 3. Protocol Invariants

### PKI-INV-01: Independent quorum signatures

A valid consensus carries at least M valid signatures from distinct active
authorities over one identical canonical body. `FOG-PKI-1` does not use one
shared threshold private key.

### PKI-INV-02: Sign once per epoch

An authority MUST sign at most one consensus body hash for one network and
epoch. It MUST durably record that body hash before releasing its signature.

### PKI-INV-03: Full view only

Consumers MUST validate a full consensus. They MUST NOT merge descriptors,
signatures, topology, parameters, or revocations from different consensus
bodies.

### PKI-INV-04: Monotonic acceptance

A consumer MUST persist the highest accepted authority-set version, consensus
epoch, consensus hash, and transparency checkpoint. Older or conflicting state
MUST NOT replace it through an ordinary update.

### PKI-INV-05: Offline roots, online voting keys

Long-term authority root keys certify bounded-lifetime online voting keys.
Online voting keys sign routine protocol objects. Root private keys MUST NOT be
present on an online authority service.

### PKI-INV-06: No self-authorized algorithms

The signature and hash suite used to authenticate an object MUST be pinned by
already trusted state. An object MUST NOT select the algorithm by which its own
authenticity is decided.

### PKI-INV-07: One node identity, one role

One node identity has exactly one effective online role in an epoch. Layer
assignment is made by consensus, not self-declared by a node.

### PKI-INV-08: Fail closed at hard expiry

After consensus hard expiry, consumers MUST stop constructing new routes and
nodes MUST stop accepting new work under that consensus. Only explicitly
bounded drain and packet-lifetime behavior may continue.

### PKI-INV-09: Public decisions, minimal personal data

Admissions, assignments, suspensions, revocations, authority transitions, and
equivocation evidence are public. Personal names, private contact details,
credentials, and sensitive supporting evidence MUST NOT enter public PKI
objects.

### PKI-INV-10: No trust on first use recovery

Unknown authority, node, operator, mirror, witness, or replacement keys MUST
NOT become trusted because they are the only reachable keys.

## 4. Roles and Trust

### 4.1 Authority root operator

The root operator controls one authority root key in an offline ceremony. The
root key certifies that authority's online vote keys and participates in
authority-set transitions.

### 4.2 Online authority

`fog-authority` accepts descriptors, exchanges protocol messages, constructs
deterministic proposals, signs one consensus body per epoch, and publishes
public artifacts. It has no privileged data-plane route.

### 4.3 Operator

An operator controls an operator identity and one or more separately keyed
nodes. The operator declares common control, infrastructure relationships, and
role requests. Admission does not prove honesty or independence.

### 4.4 Node

A node signs its descriptor and proves possession of its node identity. It
publishes only the role-specific public keys and endpoints needed by the
network.

### 4.5 Mirror

A mirror distributes immutable public objects. It is untrusted for
authenticity, freshness, completeness, and consistency.

### 4.6 Witness or monitor

A witness independently fetches, compares, archives, and republishes consensus
and transparency checkpoints. Witnesses improve detection but do not replace
the authority quorum.

### 4.7 Consumer

Consumers are Composers, blind relays, entries, mixes, couriers, storage
replicas, services, and observers. Each maintains role-appropriate monotonic
PKI state. The offline Composer is the final authority for user route
construction.

## 5. Authority Set and Quorum

An authority set contains:

- an exact authority-set version;
- an odd number N of authority roots;
- a quorum M where `floor(N / 2) + 1 <= M <= N`;
- one stable identifier and root public key per authority;
- the permitted online signing suites;
- activation and retirement epochs;
- the transparency-log identifier;
- the hash of the previous authority-set manifest.

The initial claim-bearing profile uses N = 3 and M = 2. A later preferred
profile uses N = 5 and M = 3. A local PoC MAY use a simulated smaller set, but
the resulting consensus is functional test data only.

Consensus signatures are independent signatures. A signature record names its
authority and certified online key. A verifier counts at most one valid
signature per active authority.

Signatures from unknown, duplicate, expired, revoked, not-yet-active, or
wrong-set keys do not count. Extra invalid signatures MUST make the envelope
invalid instead of being silently ignored, because inconsistent validation
would create implementation fingerprints.

## 6. `FOG-PKI-CBOR-1` Encoding

FOG-PKI objects use a restricted deterministic CBOR profile based on RFC 8949.
This profile is named `FOG-PKI-CBOR-1`.

Every signed object has the form:

```text
SignedObject = [
  magic,
  encoding_version,
  object_type,
  body
]
```

where:

- `magic` is the byte string `FOGPKI1`;
- `encoding_version` is unsigned integer `1`;
- `object_type` is a registered unsigned integer;
- `body` is an exact-length array defined by this specification.

An authenticated envelope has the form:

```text
SignedEnvelope = [
  signed_object_bytes,
  signatures
]

SignatureRecord = [
  authority_or_subject_id,
  key_id,
  signature_suite_id,
  signature_bytes
]
```

`signed_object_bytes` is a CBOR byte string containing the exact canonical
encoding of `SignedObject`. A verifier MUST parse it, enforce this profile,
re-encode it, and require byte-for-byte equality before checking signatures.

The profile permits only:

- unsigned integers in their shortest encoding;
- definite-length byte strings;
- definite-length UTF-8 text strings where a field explicitly permits text;
- definite-length arrays with exact schema length.

The profile forbids:

- negative integers;
- maps;
- floating-point values;
- tags;
- simple values, including `null`, `true`, and `false`;
- indefinite-length items;
- duplicate set elements;
- unsorted set-like arrays;
- trailing bytes or concatenated objects.

Boolean fields use unsigned integer `0` or `1`. Optional fields use an
explicit variant discriminator and exact variant array, never `null`.

Set-like arrays MUST be sorted by the canonical byte encoding of the complete
element and MUST contain no duplicate element. Ordered protocol sequences MUST
retain their specified order and MUST NOT be sorted.

Unknown object types, versions, fields, enum values, key purposes, signature
suites, hash suites, roles, parameters, or extensions are critical and MUST be
rejected in version 1.

## 7. Object Types

`FOG-PKI-1` reserves the following object types:

| Value | Object |
| --- | --- |
| 1 | `TrustAnchorManifest` |
| 2 | `AuthorityOnlineKeyCertificate` |
| 3 | `OperatorRecord` |
| 4 | `AdmissionDecision` |
| 5 | `NodeDescriptor` |
| 6 | `AuthorityCommit` |
| 7 | `AuthorityReveal` |
| 8 | `AuthorityProposal` |
| 9 | `ConsensusBody` |
| 10 | `RevocationStatement` |
| 11 | `AuthoritySetTransition` |
| 12 | `EpochArchive` |
| 13 | `LogCheckpoint` |
| 14 | `EquivocationEvidence` |
| 15 | `RecoveryManifest` |
| 16 | `ProfileTransition` |
| 17 | `AuthorityWireKeyCertificate` |
| 18 | `StorageReplicaManifest` |

Object type assignments never change meaning. Incompatible schemas require a
new encoding or object version.

## 8. Domain Separation and Identifiers

The trusted PKI suite defines one approved hash construction and its output
length. All hashes use a distinct ASCII domain string encoded as the first
element of a canonical CBOR array.

Examples:

```text
key_id            = HASH(["FOG-PKI-KEY-ID-1", algorithm_id, public_key])
authority_id      = HASH(["FOG-PKI-AUTHORITY-ID-1", root_key_id])
operator_id       = HASH(["FOG-PKI-OPERATOR-ID-1", operator_key_id])
node_id           = HASH(["FOG-PKI-NODE-ID-1", node_identity_key_id])
object_hash       = HASH(["FOG-PKI-OBJECT-1", signed_object_bytes])
consensus_hash    = HASH(["FOG-PKI-CONSENSUS-1", consensus_body_bytes])
descriptor_hash   = HASH(["FOG-PKI-DESCRIPTOR-1", descriptor_bytes])
storage_manifest_hash = HASH([
  "FOG-PKI-STORAGE-MANIFEST-1",
  storage_manifest_bytes
])
```

Signature input is the canonical encoding of:

```text
[
  "FOG-PKI-SIGNATURE-1",
  network_id,
  object_type,
  signature_suite_id,
  signed_object_bytes
]
```

The exact strings above are part of version 1 and are case-sensitive. Binding
`signature_suite_id` prevents a valid component from being rewrapped under a
different signature suite over otherwise identical object bytes.

`network_id` is a uniformly random 32-byte value created at genesis and pinned
in the initial trust-anchor manifest. It is not derived from a DNS name,
project title, mirror, or operator identity.

Identifiers are public correlation handles inside PKI. They MUST NOT be reused
as message identities, user accounts, storage capabilities, transport secrets,
or release identities.

## 9. Absolute Parser Limits

All implementations MUST enforce these absolute version-1 limits before
allocation proportional to attacker input:

| Item | Limit |
| --- | --- |
| Any `SignedEnvelope` | 8 MiB |
| One `PKIUpdateBundle` | 16 MiB |
| One `NodeDescriptor` envelope | 128 KiB |
| One `StorageReplicaManifest` envelope | 1 MiB |
| One proof bundle | 1 MiB |
| Nesting depth | 8 arrays |
| Authorities | 9 |
| Authority signatures | 9 |
| Operators | 512 |
| Nodes in one consensus | 1024 |
| Endpoints per node | 4 |
| Family or infrastructure groups per node | 16 |
| Epoch public keys per node | 24 |
| Active protocol profiles | 32 |
| Storage manifests per consensus | 3 |
| Replica records per storage manifest | 256 |
| Revocation entries per consensus | 4096 |
| Text field | 128 UTF-8 bytes |
| One public key or signature component | 128 KiB |

The initial deployment profile MAY set lower limits. Increasing an absolute
limit requires a new PKI version and parser review. FOG-PKI uses no compression
in version 1.

## 10. Trust Bootstrap

### 10.1 Genesis material

A new Composer or node begins with:

- the 32-byte `network_id`;
- one exact genesis `TrustAnchorManifest` hash;
- the full genesis manifest;
- the release-verification trust anchor used for the software image;
- the initial transparency checkpoint;
- the accepted PKI encoding and cryptographic suite identifiers.

The genesis manifest is a trust anchor. Self-signatures do not create its
trust. Its hash MUST be pinned in the verified software release and SHOULD be
available through at least one independent human-verifiable channel.

DNS, TLS, a mirror, the blind relay, a QR label, or a reachable authority MUST
NOT replace the pinned genesis hash.

### 10.2 `TrustAnchorManifest`

The manifest body is:

```text
[
  network_id,
  manifest_version,
  previous_manifest_hash,
  activation_epoch,
  retirement_epoch,
  quorum_m,
  authority_roots,
  pki_authentication_suite_id,
  allowed_object_suite_ids,
  transparency_log_id,
  epoch_origin,
  epoch_duration,
  schedule_profile_id,
  hard_limits_profile_id
]
```

`authority_roots` is a sorted array of:

```text
[
  authority_id,
  root_key_id,
  root_signature_algorithm_id,
  root_public_key,
  public_alias
]
```

`public_alias` is an informational pseudonymous label. It is not an identity
proof and MUST NOT contain private contact information. It is 1 to 64 bytes
from ASCII letters, digits, `.`, `_`, and `-`; it need not be globally unique
and MUST NOT be used in security decisions.

Genesis uses an all-zero `previous_manifest_hash`. Later manifests are
accepted only through the transition procedure in Section 22.

`manifest_version` is the `authority_set_version` used by certificates,
consensus, checkpoints, and transitions. The two terms describe the same
monotonic unsigned integer.

## 11. Authority Key Hierarchy

### 11.1 Authority root key

Each authority has one active offline root identity at a time. Its root private
key:

- certifies that authority's online voting keys;
- certifies that authority's dedicated online FOG-WIRE keys;
- signs authority-set transitions;
- signs root-key replacement or retirement;
- participates in authenticated disaster recovery.

It MUST NOT sign routine consensus, descriptor, commit, reveal, proposal,
checkpoint, or admission objects.

The root private key MUST be generated and used in an offline ceremony. Backup
material MUST be encrypted, authenticated, geographically separated where
appropriate, and stored separately from its decryption or recovery secret.

### 11.2 Online vote key

An online voting key signs routine authority protocol objects. It is certified
by its authority root in an `AuthorityOnlineKeyCertificate`:

```text
[
  network_id,
  authority_set_version,
  authority_id,
  online_key_generation,
  online_key_id,
  online_signature_suite_id,
  online_public_key,
  valid_from_epoch,
  valid_until_epoch,
  previous_certificate_hash
]
```

The certificate is signed by the matching authority root. An online key
certificate MUST cover no more than 32 epochs. One current and one next online
key certificate MAY overlap for at most two epochs.

Consensus validation uses the online key valid for the consensus epoch. A key
outside its certified interval cannot sign that epoch even if its certificate
has not been explicitly revoked.

### 11.3 Authority wire key

An authority uses a dedicated online wire key for mutually authenticated
`FOG-WIRE` links with peer authorities and admitted descriptor submitters. It
MUST NOT reuse the authority root key or online vote key for transport.

The wire key is certified by the matching authority root in an
`AuthorityWireKeyCertificate`:

```text
[
  network_id,
  authority_set_version,
  authority_id,
  wire_key_generation,
  wire_key_id,
  wire_algorithm_id,
  wire_public_key,
  supported_wire_profile_ids,
  valid_from_epoch,
  valid_until_epoch,
  previous_certificate_hash
]
```

`supported_wire_profile_ids` is sorted and duplicate-free. Every listed
profile MUST already be trusted and MUST require the declared key algorithm.
The certificate does not authorize its own algorithm or wire profile.

The certificate is signed by the matching offline authority root. It MUST
cover no more than 32 epochs. One current and one next authority wire-key
certificate MAY overlap for at most two epochs. There MUST be exactly one
valid wire key for one authority, profile, and epoch, unless one already
trusted profile defines a composite key as one key record.

An authority wire key authenticates only `NODE_AUTHORITY` and
`AUTHORITY_AUTHORITY` contexts from `FOG-WIRE-1`. It MUST NOT sign votes,
consensus, checkpoints, admission decisions, descriptors, releases, or user
objects.

### 11.4 Signature-suite composition

A suite MAY require more than one signature component, including a classical
and post-quantum component. A composite signature is valid only when every
mandatory component in the already trusted suite validates over the same
signature input.

Components from different signature records, objects, keys, or authorities
MUST NOT be combined to manufacture one valid composite signature.

`FOG-PKI-HASH-CANDIDATE-SHA3-256-1` and
`FOG-PKI-CANDIDATE-MLDSA65-ED25519-1` are the leading non-active candidates.
The latter requires independently generated ML-DSA-65 and Ed25519 keys and
requires both components over the exact suite-bound signature input. Their
encoding, vectors, separability analysis, implementation, side-channel review,
and numeric activation remain pre-PoC gates. Algorithm names or post-quantum
labels alone do not satisfy review.

## 12. Operator Identity and Family Records

An operator uses one dedicated signing identity that is separate from node,
authority, release, user, and infrastructure login keys.

An `OperatorRecord` contains:

```text
[
  network_id,
  operator_id,
  operator_key_id,
  operator_signature_algorithm_id,
  operator_public_key,
  public_alias,
  family_ids,
  infrastructure_group_ids,
  declared_provider_codes,
  declared_as_numbers,
  declared_country_codes,
  record_sequence,
  valid_from_epoch,
  valid_until_epoch
]
```

The operator signs the record, and admission authorities approve its hash.

`family_ids` describe known common control or cooperation across operator
identities. `infrastructure_group_ids` describe shared provider accounts,
orchestration, management, backup, monitoring, corporate ownership, or other
common compromise domains.

Authorities MAY conservatively merge family or infrastructure groups when
credible evidence indicates common control. They MUST NOT split an existing
group without an ordinary threshold decision and a public rationale code.

Provider, ASN, and country declarations are public routing inputs, not proof
of operator independence. Route selection MUST reject reuse of one operator,
family, or prohibited infrastructure group where the active profile requires
diversity.

Public records MUST NOT contain legal names, personal email addresses, phone
numbers, billing identifiers, street addresses, login names, or private abuse
reports. Authorities MAY maintain a separate access-controlled admission file,
but its content is outside consensus and MUST NOT be required by clients.

## 13. Permissioned Admission

### 13.1 Application

The initial network is permissioned. An operator applies with:

- its signed `OperatorRecord`;
- the node identity public key and proof of possession;
- requested role and capabilities;
- canonical endpoints;
- future role-specific public keys;
- declared family and infrastructure relationships;
- operational and policy evidence required by governance.

Private supporting evidence is not placed in the public application object.

### 13.2 Decision

An `AdmissionDecision` contains:

```text
[
  network_id,
  decision_sequence,
  subject_type,
  subject_id,
  operator_record_hash,
  requested_role,
  disposition,
  public_reason_code,
  constraints,
  effective_epoch,
  expiry_epoch
]
```

`disposition` is one of admit, deny, suspend, reinstate, or retire. It uses a
registered unsigned integer, not text.

Ordinary admission, role change, reinstatement, and retirement require M
independent authority signatures. A single authority cannot admit a node.

Admission binds one node identity to one operator and one eligible role. A
role change requires a new decision. Admission does not assign a mix layer;
the consensus topology does.

### 13.3 Reapplication and replacement

A revoked node identity MUST NOT be reused. A replacement generates a new node
identity and follows ordinary admission. A changed endpoint or role-specific
key does not require a new node identity if a valid monotonic descriptor and
the existing admission constraints permit the change.

## 14. Node Identity and Descriptor

### 14.1 Node identity

Every online node has one role-local node identity signing key. It signs
descriptors and proves continuity across epoch-key rotation. It MUST NOT be
used for Noise transport, KEMSphinx, entry capsules, storage envelopes,
metrics, release signing, or operator administration.

### 14.2 Descriptor body

A `NodeDescriptor` contains:

```text
[
  network_id,
  descriptor_version,
  descriptor_sequence,
  node_id,
  node_identity_key_id,
  node_identity_algorithm_id,
  node_identity_public_key,
  operator_id,
  operator_record_hash,
  admitted_role,
  capability_ids,
  endpoints,
  epoch_public_keys,
  supported_profile_ids,
  valid_from_epoch,
  valid_until_epoch,
  previous_descriptor_hash
]
```

It is signed independently by the node identity and operator identity. Both
signatures are required.

`descriptor_sequence` starts at zero and increases by exactly one for each
accepted replacement descriptor. A new descriptor names the previous accepted
descriptor hash. A gap, rollback, duplicate sequence with a different hash, or
broken chain is invalid.

One descriptor MUST cover no more than four consecutive epochs. It MUST carry
the public keys required for its current and next usable key periods without
extending private-key overlap beyond the owning protocol profile.

### 14.3 Endpoints

An endpoint is:

```text
[
  transport_profile_id,
  address_type,
  address_bytes,
  port,
  priority_class
]
```

Only endpoint forms explicitly permitted by the active wire profile are
valid. An endpoint MUST NOT contain a URL path, username, password, API token,
query string, fragment, or unauthenticated redirect target.

DNS-only identity is forbidden. If a profile permits DNS discovery, the
descriptor still binds the node identity and authenticated endpoint behavior;
DNS never authorizes a different node key.

### 14.4 Epoch public keys

Each public key entry is:

```text
[
  purpose_id,
  algorithm_id,
  key_id,
  public_key,
  valid_from_epoch,
  valid_until_epoch
]
```

Purpose IDs distinguish at least:

- node Noise transport;
- entry submission capsule;
- entry return KEMSphinx terminal processing where required;
- mix KEMSphinx transformation;
- courier or service terminal KEMSphinx processing;
- replica envelope protection;
- replica durable-result receipt authentication;
- aggregate signing.

A descriptor MUST contain exactly the key purposes required by its admitted
role and MUST NOT contain keys for another role. The current and next key
periods MUST be published before the descriptor deadline. More than one active
key for the same purpose and epoch is invalid unless the active suite defines
one composite key as a single key record.

Private keys never enter a descriptor, vote, consensus, proof, log, example,
fixture, or support artifact.

## 15. Epoch and Time Model

The genesis manifest pins:

- `epoch_origin`, an unsigned Unix-time second;
- `epoch_duration`, a whole number of seconds;
- one schedule profile;
- maximum clock uncertainty;
- consensus freshness and hard-expiry offsets;
- descriptor, commit, reveal, proposal, signature, and publication deadlines;
- packet and key grace constraints supplied by the owning protocol profiles.

Epoch number at time `t` is:

```text
floor((t - epoch_origin) / epoch_duration)
```

for `t >= epoch_origin`.

The exact initial epoch duration and schedule offsets remain a pre-PoC
operational selection. They MUST be identical for all participants, encoded in
the trust manifest, and supported by fault-injection tests. Operators cannot
override them locally.

Changing epoch origin, duration, schedule, or maximum clock uncertainty
requires an authority-set manifest transition with at least two epochs of
advance notice. It is not an ordinary consensus parameter change.

Consumers MUST evaluate time with an explicit local uncertainty interval. A
relay-provided timestamp, mirror `Date` header, DNS response, or single time
server is not trusted time. If the uncertainty interval cannot establish
validity, the consumer fails closed for new work.

## 16. Authority Protocol State Machine

For target epoch E, each online authority executes these phases.

### 16.1 Collect

Authorities collect valid descriptors, operator records, admission decisions,
revocations, online key certificates, and announced transitions before the
descriptor deadline.

Inputs arriving after the deadline are considered only for a later epoch.
Authorities MUST NOT create different inclusion behavior based on requester
latency after the public deadline.

### 16.2 Commit

Each authority generates a fresh uniformly random secret for epoch E and
publishes a signed `AuthorityCommit`:

```text
[
  network_id,
  authority_set_version,
  epoch,
  authority_id,
  commitment,
  previous_consensus_epoch,
  previous_consensus_hash
]
```

The commitment is the suite hash of a domain-separated encoding containing
the network, epoch, authority, random secret, and previous consensus hash.

Exactly:

```text
commitment = HASH([
  "FOG-PKI-COMMIT-1",
  network_id,
  authority_set_version,
  epoch,
  authority_id,
  previous_consensus_epoch,
  previous_consensus_hash,
  random_secret
])
```

### 16.3 Reveal

After the commit deadline, each authority publishes a signed
`AuthorityReveal` containing the secret corresponding to its prior commitment.
Reveals without one valid timely commit, invalid reveals, duplicates, or early
reveals are excluded and recorded.

If fewer than M authorities provide valid commit/reveal pairs, no consensus is
produced.

The shared seed is derived from the previous consensus hash and the sorted
valid authority reveals using the pinned hash suite:

```text
shared_seed = HASH([
  "FOG-PKI-SHARED-SEED-1",
  network_id,
  authority_set_version,
  epoch,
  previous_consensus_epoch,
  previous_consensus_hash,
  sorted_reveals
])

sorted_reveals = [
  [authority_id, random_secret],
  ...
]
```

The complete commit and reveal hashes are included in the consensus audit
section. `sorted_reveals` is sorted by `authority_id` and contains no duplicate
authority.

Commit-reveal limits unilateral prediction but permits withholding and denial
of service by a last revealer. FOG-PKI does not claim bias-free randomness from
this construction. Topology stability and deterministic public auditing limit
where the seed is security-critical.

### 16.4 Propose

Each authority independently applies the exact deterministic rules in this
specification to the same eligible input set. It signs and exchanges an
`AuthorityProposal` containing the resulting consensus body hash and sorted
input object hashes.

Authorities MUST NOT average, merge, or majority-vote individual fields from
different proposals. A body is signable only when at least M authorities have
published identical proposal body and input hashes.

### 16.5 Sign

Before signing, an authority:

1. validates its active online key certificate;
2. recomputes the complete canonical consensus body;
3. verifies the previous consensus and authority-set chain;
4. persists `(network_id, epoch, consensus_hash)` in durable sign-once state;
5. refuses if any different hash is already stored for that epoch;
6. signs the canonical `ConsensusBody` object.

The sign-once record MUST survive restart, restore, and failover. Cloning an
authority database into two active signers is forbidden.

### 16.6 Publish

Authorities exchange detached signatures. Any publisher can assemble a valid
`ConsensusEnvelope` only by attaching at least M distinct valid signatures to
the exact body bytes.

Authorities publish the body, all signature records, relevant certificates,
input hashes, epoch archive, and transparency material. Mirrors may copy these
bytes but cannot modify them.

Signature collection closes at the public signature deadline. The final
sorted signature-record set is committed by the epoch archive before
`valid_after`. A later signature over the same body remains evidence of that
authority's statement but MUST NOT be inserted into the finalized consensus
envelope for that epoch.

## 17. Deterministic Eligibility and Topology

### 17.1 Eligibility filtering

A node is eligible for epoch E only if:

- its admission is active for E;
- its operator record is active and threshold-approved;
- its descriptor chain and both descriptor signatures validate;
- the descriptor covers E and has the required future key material;
- it is not suspended or revoked;
- every endpoint, key, capability, and profile is permitted;
- its role does not conflict with another identity or active assignment;
- its operator and infrastructure declarations meet the active profile.

All filtering operates on canonical public data and deterministic reason
codes. Private authority evidence may cause a signed public suspension or
revocation decision, but it MUST NOT silently change deterministic evaluation.

### 17.2 Effective roles

The consensus assigns each eligible node exactly one of:

- entry;
- mix layer 1;
- mix layer 2;
- mix layer 3;
- courier;
- storage replica;
- declared native service;
- observer.

The node requests an admitted role. Only mix layer number is assigned by the
consensus topology algorithm. A node cannot self-place into a layer.

### 17.3 Topology generation

Layer assignment remains stable within one `topology_generation`. A new
generation is created only for admission, removal, capacity change, diversity
repair, or deliberate rebalance. Routine epoch key rotation MUST NOT reshuffle
all mix layers.

For a new generation:

1. eligible nodes are grouped by role;
2. each group is sorted by `node_id`;
3. the shared seed drives a suite-defined deterministic pseudorandom shuffle
   using unbiased sampling;
4. mix nodes are assigned to three balanced layers;
5. deterministic constraints maximize operator, family, provider, ASN,
   country, and infrastructure-group diversity;
6. a validation pass proves that the profile has at least one allowed complete
   route and meets its minimum node counts;
7. failure to satisfy hard constraints makes the proposal invalid.

The exact deterministic shuffle and constraint solver require conformance
vectors before the PoC. Different implementations MUST produce byte-identical
topology from the same inputs and seed.

### 17.4 Route constraints

Consensus publishes the attributes needed by the Composer to reject routes
that repeat one operator, family, or prohibited infrastructure group. The
consensus MUST NOT precompute one user route or allow operators to choose user
paths.

## 18. Consensus Body

The canonical `ConsensusBody` is:

```text
[
  network_id,
  pki_version,
  authority_set_version,
  epoch,
  topology_generation,
  valid_after,
  fresh_until,
  valid_until,
  previous_consensus_epoch,
  previous_consensus_hash,
  trust_anchor_manifest_hash,
  commit_reveal_summary,
  operator_records,
  node_descriptors,
  topology,
  revocations,
  storage_manifests,
  active_profile_ids,
  network_parameters,
  announced_transition_hashes
]
```

`previous_consensus_epoch` and `previous_consensus_hash` identify the latest
prior epoch that produced a valid consensus. They may skip scheduled epochs
that ended without consensus. Each skipped epoch still receives a
no-consensus transparency archive under Section 24.

### 18.1 Validity times

`valid_after`, `fresh_until`, and `valid_until` are derived exactly from the
epoch schedule. Authorities do not choose them independently.

- Before `valid_after`, the consensus may be staged but not used for new work.
- After `fresh_until`, a consumer reports a stale-update condition but MAY
  continue only until `valid_until` under the same profile.
- At `valid_until`, new route construction and new work stop.

No mirror, relay, node, operator, or single authority can extend these times.

### 18.2 Full descriptors

Version 1 consensus contains the complete accepted operator records and node
descriptors needed for route and link validation. It does not use
state-dependent descriptor deltas or fetch-on-demand partial views.

Each embedded record or descriptor is a CBOR byte string containing its full
canonical signed envelope. Arrays are sorted by the corresponding stable
identifier, not by operator alias, endpoint, or arrival order. Consumers
independently validate the embedded operator and node signatures after the
authority quorum signature.

`storage_manifests` contains the complete canonical previous, current, and
announced next `StorageReplicaManifest` objects required by the active
FOG-STORAGE retention and transition windows. The objects are sorted by
storage epoch and manifest hash, duplicate-free, and validated under
`FOG-PKI-CBOR-1` and the authority quorum. Consumers MUST NOT merge replica
records or storage keys from different manifests. The exact object schema,
sign-once state, shard inputs, and key windows are defined by
`FOG-STORAGE.md`.

### 18.3 Profiles and parameters

`active_profile_ids` authorizes exact wire, packet, storage, entry, cover, and
application protocol profiles. `network_parameters` contains only registered
integer parameter IDs and bounded unsigned integer values.

For KEMSphinx packet processing, consensus and the applicable
`FOG-SPHINX-PROFILES` record MUST resolve exactly one packet profile for each
tuple `(epoch, link_context, packet_class)`. During a transition, old and new
packet profile IDs may both appear only with an unambiguous activation and
drain mapping. A consumer MUST reject a consensus that makes profile selection
ambiguous, requires packet-length detection, or maps one new-work tuple to
more than one packet profile.

Every node descriptor selected for a KEMSphinx route MUST contain the exact
epoch KEM key purpose, role, layer, and packet profile required by that route.
The consensus is invalid if its topology cannot supply a complete four-hop
forward and reply shape required by the active packet profile.

A parameter cannot select the suite used to authenticate its own consensus.
Security-critical profile transition requires a preannounced bounded overlap
and cannot silently downgrade an already accepted minimum.

A `ProfileTransition` contains:

```text
[
  network_id,
  transition_sequence,
  profile_class,
  old_profile_ids,
  new_profile_ids,
  announcement_epoch,
  activation_epoch,
  retirement_epoch,
  minimum_compatible_version
]
```

It requires M independent authority signatures, at least two epochs of advance
notice, a bounded old/new overlap, and inclusion of its hash in every
intervening consensus. Parameters classified as profile-bound change only
through this object. Parameters explicitly classified as dynamic MUST have
hard minimum, maximum, and per-epoch change bounds in the active profile.

### 18.4 Signature envelope

A `ConsensusEnvelope` is a `SignedEnvelope` whose signed object type is
`ConsensusBody`. Signature records are sorted by `authority_id` and contain no
duplicates.

The consensus hash covers the body bytes only. The valid consensus identity is
the pair `(epoch, consensus_hash)`. Adding a valid signature does not create a
different consensus identity.

## 19. Consumer Consensus Validation

A consumer MUST perform these checks in order:

1. enforce the outer byte limit before parsing;
2. decode one exact `SignedEnvelope` and reject trailing data;
3. validate `FOG-PKI-CBOR-1` and canonical byte equality;
4. require the pinned `network_id`, PKI version, and object type;
5. load the already trusted authority-set manifest for the declared version;
6. validate all required authority online vote-key and wire-key certificates
   and revocation state;
7. verify every included signature and require at least M distinct valid
   active authorities;
8. recompute the consensus hash;
9. require exact epoch schedule times and acceptable local clock uncertainty;
10. reject an epoch below the highest accepted epoch;
11. reject a different hash for an already accepted epoch;
12. verify the previous-consensus relationship or the offline consistency
    bundle described in Section 25;
13. validate all records, descriptors, key purposes, profile IDs, parameters,
    revocations, limits, topology assignments, and diversity constraints;
14. verify the epoch archive and transparency inclusion and consistency
    evidence;
15. atomically persist the new manifest version, epoch, consensus hash,
    checkpoint, and minimum accepted profile state;
16. only then expose the network view to route or link logic.

Signature verification MUST occur before expensive validation proportional to
the complete topology where practical, but canonical parsing and strict bounds
always occur first.

An implementation MUST NOT choose one of two valid-looking same-epoch bodies
by timestamp, signature count above M, mirror order, lexicographic hash, or
network reachability. It freezes and reports equivocation.

## 20. Node Consumption and Key Acceptance

Online nodes apply the same consensus authentication rules as Composers and
also MUST:

- confirm their own effective role and layer before serving traffic;
- bind peer eligibility to the active consensus and link profile;
- accept role-specific epoch keys only for their declared purpose;
- validate root-certified current or staged authority wire keys before
  `NODE_AUTHORITY` or `AUTHORITY_AUTHORITY` handshakes;
- stage next-epoch connections without forwarding next-epoch traffic early;
- close or reject peers removed by the next consensus at the specified
  boundary;
- retain previous packet-processing keys only for the exact bounded packet
  grace period;
- erase expired epoch private keys after all required replay and packet
  windows close;
- stop if local configuration attempts to activate a second role.

An operator configuration cannot add a peer, key, profile, or role absent from
consensus.

## 21. Revocation and Suspension

### 21.1 Scope

A `RevocationStatement` may target:

- one role-specific epoch key;
- one node identity and all its keys;
- one operator and all admitted nodes;
- one authority online voting key;
- one authority online wire key;
- one authority root through an authority-set transition;
- one protocol profile or suite through a preannounced transition.

### 21.2 Body

```text
[
  network_id,
  revocation_sequence,
  target_type,
  target_id,
  scope,
  public_reason_code,
  effective_epoch,
  effective_time,
  expiry_epoch,
  replacement_policy,
  previous_revocation_hash
]
```

Ordinary suspension, revocation, expiry change, and reinstatement require M
authority signatures.

### 21.3 Self-revocation

A node or operator MAY publish a self-revocation signed by the affected
identity. Consumers treat a valid self-revocation as an immediate denial-of-
service-safe removal of that identity. Self-revocation cannot authorize a
replacement key, identity, operator, role, or authority.

### 21.4 Emergency revocation

Between normal consensuses, M authorities MAY sign one emergency revocation
envelope. It MUST:

- use a monotonic revocation sequence;
- identify the last valid consensus hash;
- have a short explicit expiry no later than the next normal consensus hard
  expiry;
- be included in the next epoch archive;
- never add or reinstate an identity;
- never change quorum, authority roots, profiles, or topology except by
  removing the compromised subject.

A single authority warning is public evidence but is not an effective network
revocation.

### 21.5 Compromise response

After confirmed compromise:

- stop new use of the affected private key;
- publish self-revocation where safe;
- issue threshold suspension or revocation;
- remove affected objects from new consensus;
- generate purpose-separated replacement keys;
- use ordinary admission or transition for replacement;
- preserve public evidence without publishing secret forensic material;
- document which past and future properties may have failed.

Revocation does not erase previously recorded traffic, signatures, or
compromise effects.

## 22. Authority-Set Transition

Authority membership, quorum, root keys, PKI authentication suite, epoch
schedule, and transparency-log identity change only through an
`AuthoritySetTransition`.

The transition body contains:

```text
[
  network_id,
  old_manifest_version,
  old_manifest_hash,
  new_manifest_version,
  new_manifest_hash,
  announcement_epoch,
  activation_epoch,
  transition_reason_code
]
```

Acceptance requires:

1. versions increase by exactly one;
2. the old manifest is already trusted;
3. activation is announced at least two epochs in advance;
4. at least M old authority root signatures validate;
5. at least the new quorum of new authority root signatures validate;
6. the transition hash appears in every consensus during the overlap;
7. the new manifest chains to the old manifest hash;
8. the consumer persists the new manifest before its activation epoch;
9. old roots stop authorizing ordinary new state at activation;
10. a bounded verification overlap exists only for objects created before the
    boundary.

This dual-quorum procedure follows the principle that both the old trusted set
and the new set authorize a root transition.

The old quorum signs the exact new root keys and suite identifiers. A new
authentication suite MUST already be supported and explicitly authorized as a
transition suite by the old manifest during the overlap. A client MUST NOT
jump directly from an old suite to an object that can be verified only by an
algorithm named inside that object. Software support for a suite does not make
the suite trusted without this chained authorization.

If too many old roots are lost to reach the old quorum, the network has no
automatic in-protocol recovery. Recovery requires a separately authenticated
`RecoveryManifest`, explicit user or operator action, and a new trust anchor
obtained through independent channels. It MUST NOT resemble an ordinary
update or trust-on-first-use prompt.

## 23. Topology and Profile Revocation Effects

Removing one node MUST NOT cause consumers to bypass its layer. A new
consensus recomputes a valid complete topology or fails.

If revocation makes the minimum topology or operator diversity impossible:

- no stronger privacy profile is advertised;
- authorities may publish a lower claim profile only if it was already
  supported, explicitly authorized, and not a silent downgrade;
- consumers whose minimum accepted profile is stronger stop new work;
- the local PoC profile may continue only as functional test mode.

Profile removal is not a generic emergency revocation. It requires a
preannounced `ProfileTransition`, or an authority-set transition when the PKI
authentication suite itself changes, unless the profile already has an
authenticated hard retirement epoch.

## 24. Append-Only Transparency Log

### 24.1 Purpose and limitation

FOG-PKI maintains an append-only Merkle log so a long-offline Composer can
verify that a new accepted view extends its stored checkpoint with a proof
whose size grows logarithmically rather than linearly with missed epochs.

The log detects inconsistent signed history when views are compared. It does
not by itself guarantee that every client sees the same view. Independent
retrieval, witnesses, and checkpoint gossip remain necessary.

### 24.2 Epoch archive

For every scheduled epoch E, authorities create one canonical `EpochArchive`
once quorum can finalize either the successful or no-consensus outcome:

```text
[
  network_id,
  epoch,
  archive_status,
  failure_reason_code,
  consensus_hash,
  authority_manifest_hash,
  online_key_certificate_hashes,
  authority_wire_key_certificate_hashes,
  authority_protocol_object_hashes,
  consensus_signature_hashes,
  operator_record_hashes,
  admission_decision_hashes,
  node_descriptor_hashes,
  revocation_hashes,
  transition_hashes,
  equivocation_evidence_hashes
]
```

All set-like lists are sorted and duplicate-free. The archive commits to the
public protocol record without embedding private admission evidence.

The archive is a canonical `SignedObject` byte string but needs no individual
signature envelope. Its authenticity derives from inclusion in the Merkle tree
identified by an M-of-N signed checkpoint.

For a successful epoch, `archive_status` is unsigned integer `0`,
`failure_reason_code` is zero, and `consensus_hash` identifies the threshold-
valid consensus. For an epoch without consensus, `archive_status` is unsigned
integer `1`, `consensus_hash` is the all-zero hash, and the registered failure
code records the failed phase without private diagnostics.

`authority_protocol_object_hashes` commits to authority commits, reveals, and
proposals associated with the epoch.
`consensus_signature_hashes` commits to every published authority signature
in the finalized consensus envelope. A consumer requires the envelope's exact
sorted signature-record hash set to match the archive.

### 24.3 Merkle construction

Each canonical `EpochArchive` byte string is one log leaf in increasing epoch
order. There is exactly one leaf per scheduled epoch. Missing consensus is
represented by the canonical failure archive; leaf indices never shift or get
reused. If quorum loss temporarily prevents checkpointing a failure archive,
the gap MUST be filled before a later checkpoint can advance past it.

The Merkle tree, leaf hashing, node hashing, inclusion proofs, and consistency
proofs follow the RFC 9162 append-only construction with FOG-specific domain
separation and the hash suite pinned by the trust manifest.

The version-1 hashes are:

```text
empty_hash = HASH(["FOG-PKI-LOG-EMPTY-1", log_id])

leaf_hash = HASH([
  "FOG-PKI-LOG-LEAF-1",
  log_id,
  epoch_archive_bytes
])

node_hash = HASH([
  "FOG-PKI-LOG-NODE-1",
  log_id,
  left_child_hash,
  right_child_hash
])
```

Tree splitting, inclusion paths, and consistency paths follow RFC 9162. The
FOG domains above replace the RFC leaf and node prefixes; they do not change
tree ordering or proof traversal.

The log MUST NOT use commutative child hashing. Left and right position are
part of verification.

### 24.4 Checkpoint

A `LogCheckpoint` contains:

```text
[
  network_id,
  log_id,
  authority_set_version,
  tree_size,
  root_hash,
  first_epoch,
  last_epoch,
  checkpoint_time
]
```

It requires M independent online authority signatures. For a successful
consensus, its archive and checkpoint MUST be published before that
consensus's `valid_after`. If quorum cannot checkpoint it by then, consumers do
not use it for new work. Failure archives are checkpointed before the log can
advance to any later epoch.

`first_epoch`, `last_epoch`, and `tree_size` MUST describe one contiguous
epoch sequence with exactly one leaf per scheduled epoch.

### 24.5 Proofs

Mirrors provide:

- an inclusion proof that the target `EpochArchive` is in the new checkpoint;
- a consistency proof that the new checkpoint extends the consumer's stored
  checkpoint;
- the target archive and consensus envelope;
- any intervening authority-set transitions and online vote-key certificates;
- authority wire-key certificates required by an online consumer's selected
  FOG-WIRE contexts.

Proofs are not trusted objects and need no signature. Their validity derives
from the old stored root and new threshold-signed checkpoint.

### 24.6 Checkpoint comparison

The following are evidence of failure or equivocation:

- two threshold-signed checkpoints with the same `tree_size` and different
  roots;
- a newer threshold-signed checkpoint for which no valid consistency proof
  from an accepted older checkpoint exists;
- one epoch archive committing to a consensus hash different from the accepted
  threshold consensus;
- a checkpoint omitting a promised finalized epoch beyond the publication
  deadline.

Consumers freeze ordinary PKI updates on verified checkpoint inconsistency.
They do not reset their stored tree size to make a proof pass.

## 25. Offline Composer Update Bundle

The blind relay or controlled import medium supplies one bounded
`PKIUpdateBundle` containing:

- the target full consensus envelope;
- authority online-key certificates needed to verify it;
- current revocations and emergency revocations;
- every sequential authority-set transition since the stored manifest;
- the target epoch archive;
- a threshold-signed current log checkpoint;
- an inclusion proof for the target archive;
- a consistency proof from the Composer's stored checkpoint;
- independently fetched distinct checkpoints or witness statements where
  available;
- a coarse untrusted retrieval timestamp for diagnostics only.

The bundle is a transfer container, not a signed PKI object. Every contained
object is independently bounded and verified. Extra, duplicate, conflicting,
or unrelated objects make the bundle invalid.

The Composer MUST:

1. verify transitions sequentially from its stored manifest;
2. verify the new checkpoint quorum under the correct active authority set;
3. verify checkpoint consistency from its stored tree root;
4. verify inclusion of the target epoch archive;
5. verify the archive's consensus hash;
6. validate the consensus through Section 19;
7. compare all supplied distinct checkpoints and evidence;
8. atomically persist the entire new trusted state;
9. retain sufficient prior checkpoint and manifest metadata for recovery and
   equivocation evidence.

If the relay withholds newer data, it can cause freeze or denial of service.
It cannot make stale data satisfy hard expiry or monotonic checks.

If the Composer lacks its previous checkpoint or manifest state, it MUST NOT
silently bootstrap from the relay. It requires the explicit recovery process.

## 26. Equivocation Evidence

An `EquivocationEvidence` object contains two or more complete independently
verifiable signed objects demonstrating one of:

- one authority signs two different consensus hashes for one epoch;
- two threshold-valid consensus bodies exist for one epoch;
- one node signs different descriptors with the same sequence and predecessor;
- one operator signs conflicting records with the same sequence;
- an authority signs two different storage manifest hashes for one storage
  epoch;
- one authority signs incompatible commits, reveals, or proposals;
- threshold-signed checkpoints conflict or fail append-only consistency;
- an authority-set transition conflicts at one manifest version.

Evidence objects MUST contain no secret randomness beyond a reveal already due
for publication and no private governance evidence.

Node or operator equivocation causes deterministic exclusion pending a
threshold decision. Authority or checkpoint equivocation freezes affected
consumers until a valid authority-set transition or explicit recovery
manifest resolves the trust state.

A consumer MUST NOT locally rewrite the authority set merely because it has
evidence against one authority. That would create a client-specific trust
view.

## 27. Distribution and Mirrors

Authorities and mirrors publish immutable objects addressed by object hash.
The latest pointer is an untrusted convenience and MUST return the complete
bytes needed for verification.

Publishers SHOULD support retrieval by:

- exact consensus epoch and hash;
- object hash;
- authority-set manifest version;
- transparency checkpoint tree size;
- inclusion and consistency proof parameters;
- revocation sequence.

HTTP, HTTPS, removable media, QR, FOG-SX-adjacent transfer tooling, or another
transport MAY carry public PKI objects. Transport security can improve
availability and privacy but does not create PKI authenticity.

Relays SHOULD fetch from at least two independently operated authorities or
mirrors and preserve distinct valid responses. They MUST NOT merge them. A
Composer import bundle includes conflicts as evidence rather than hiding them.

Mirrors MUST NOT receive authority private keys, admission credentials, user
identities, message traffic, or special consensus signing privilege.

## 28. Failure Behavior

| Condition | Required behavior |
| --- | --- |
| Fewer than M valid consensus signatures | reject |
| Signature from wrong authority set | reject |
| Any included malformed or invalid signature | reject envelope |
| Same authority listed twice | reject envelope |
| Non-canonical encoding | reject before signature acceptance |
| Unknown-critical value | reject |
| Wrong network ID | reject |
| Same epoch, different hash | freeze and retain evidence |
| Lower epoch or manifest version | reject as rollback |
| Broken descriptor chain | exclude descriptor; proposal must agree |
| Missing required future key | exclude node |
| Invalid topology or insufficient diversity | no consensus for that profile |
| Commit/reveal quorum failure | no consensus |
| Proposal body mismatch | do not sign |
| Consensus past `fresh_until` | report stale; continue only to hard expiry |
| Consensus past `valid_until` | stop new work |
| Checkpoint consistency failure | freeze ordinary update |
| Authority transition lacks dual quorum | reject transition |
| Lost local monotonic state | require explicit recovery |
| Clock uncertainty exceeds bound | stop time-sensitive acceptance |

Remote protocol errors MUST be coarse and non-amplifying. Local diagnostics
MAY identify deterministic validation stages but MUST NOT log private keys,
private admission material, unpublished random reveals, or credentials.

## 29. Key Lifecycle Table

| Key or secret | Generator | Authorized use | Lifetime and overlap | Compromise response | Backup |
| --- | --- | --- | --- | --- | --- |
| Network ID | genesis ceremony | domain and network separation | permanent | new network genesis | public, widely copied |
| Authority root private key | offline authority ceremony | online-key certificates and set transitions | long-term, one controlled transition overlap | root transition or explicit recovery | encrypted, separate recovery secret |
| Authority online vote private key | authority root ceremony or controlled online generation | commits, reveals, proposals, consensus, checkpoints | at most 32 epochs, at most 2-epoch overlap | threshold revoke certificate and rotate | SHOULD NOT be restored into concurrent signer |
| Authority wire private key | authority wire service OS CSPRNG or controlled ceremony | mutually authenticated `FOG-WIRE` authority and descriptor links | root-certified for at most 32 epochs, at most 2-epoch overlap | revoke certificate, stop new sessions, and rotate | SHOULD NOT be restored into concurrent service |
| Authority randomness secret | online authority CSPRNG | one epoch commit/reveal | one protocol run; erase after reveal and audit window | exclude invalid run; investigate RNG | no backup |
| Operator identity private key | operator ceremony | operator records and descriptor co-signing | long-term with admitted replacement | suspend operator, replace through admission | encrypted operator-controlled backup |
| Node identity private key | node enrollment | descriptor continuity | long-term for one node role | self-revoke and new admission | encrypted role-local backup if policy permits |
| Node epoch private key | owning node CSPRNG | one declared role purpose | current plus bounded grace; future key staged | revoke purpose or node; generate replacement | no routine backup |
| Replica receipt private key | one storage replica CSPRNG | authenticate one manifest-bounded local durable-result receipt | storage-manifest current plus bounded verification drain | stop receipts, revoke node or purpose, rotate through new manifest | no routine backup |
| Transparency checkpoint state | every authority | append-only root computation and sign-once tracking | permanent monotonic public history | freeze on inconsistency; recover from audited replicas | authenticated independent authority backups |
| Consumer monotonic state | each consumer | rollback and consistency detection | lifetime of installation or identity | explicit authenticated recovery | authenticated backup bound to consumer profile |

The networkless Composer refines the final row through the local commitment,
external-anchor, import, recovery, and update-consumer rules in
`FOG-COMPOSER.md`. A self-contained consumer backup does not provide complete
rollback detection.

No private key or randomness secret may appear in consensus, transparency
logs, test vectors, examples, command lines, environment templates, container
images, metrics, crash dumps, or support bundles. Tests generate ephemeral
fixtures at runtime.

## 30. Privacy and Operational Data

Public PKI necessarily reveals:

- node and authority public identities;
- endpoints and supported transports;
- effective roles and mix layers;
- declared operator, family, provider, ASN, country, and infrastructure groups;
- public key schedules, profiles, validity, admission, suspension, and
  revocation state;
- consensus timing and topology changes.

This enables targeting and operational correlation. FOG accepts that exposure
because clients need a common auditable view and route-diversity inputs.

FOG-PKI MUST NOT publish:

- user or contact identities;
- mailbox capabilities or packet identifiers;
- node traffic counts or fine-grained health events;
- operator legal identity unless voluntarily required by a separate public
  governance policy;
- private email, phone, billing, account, or management data;
- exact physical addresses;
- unpublished vulnerability or forensic details;
- authority or node private-key storage design beyond the public assurance
  profile.

Descriptor uploads, votes, and public objects SHOULD use fixed schedule
windows and bounded request behavior. Operational metrics belong to the
aggregate observer interface, not node descriptors.

## 31. Denial-of-Service and Resource Controls

Authorities MUST:

- accept descriptor uploads only for admitted identities;
- authenticate before expensive signature or policy work where possible;
- accept at most one selected descriptor chain head per node and epoch;
- bound connections, body size, signatures, records, keys, endpoints, and
  pending votes;
- rate-limit invalid uploads without creating different consensus views;
- persist protocol phase and sign-once state atomically;
- use bounded backoff for peer authority exchange;
- avoid error responses larger than the triggering request;
- keep publication serving separate from sensitive signing state;
- remain able to publish existing immutable objects during voting overload.

A malicious admitted node can consume review and descriptor resources. The
permissioned registry, bounds, expiry, suspension, and operator-wide actions
limit but do not eliminate this risk.

Authority quorum and transparency do not provide availability against a
sustained distributed attack or coordinated withholding.

## 32. Conformance and Adversarial Tests

Before the local PoC, FOG-PKI MUST have deterministic fixtures for:

- every object type and exact canonical encoding;
- re-encoding equality and rejection of alternative CBOR encodings;
- every registered identifier and domain-separated hash;
- valid M-of-N consensus for 2-of-3 and 3-of-5 sets;
- duplicate, unknown, expired, revoked, and wrong-set signatures;
- composite signature all-component validation;
- authority online-key certification and overlap boundaries;
- authority wire-key certification, overlap, profile binding, and rejection of vote-key reuse;
- descriptor sequence, predecessor, node, and operator signatures;
- role-specific key-purpose acceptance and cross-purpose rejection;
- admission, denial, suspension, reinstatement, retirement, and self-revocation;
- commit, reveal, missing reveal, invalid reveal, and insufficient quorum;
- byte-identical topology generation from seed and inputs;
- operator, family, provider, ASN, country, and infrastructure constraints;
- same-epoch authority and node equivocation;
- storage-manifest canonical encoding, sign-once persistence, quorum,
  chaining, previous/current/next windows, receipt keys, and no cross-manifest
  replica merging;
- stale, expired, future, rolled-back, frozen, and split consensus;
- authority sign-once persistence across crash, restore, and failover;
- ordinary and emergency revocation;
- dual-quorum authority-set transition;
- loss of old-root quorum and explicit recovery refusal;
- RFC 9162 inclusion and consistency proofs, including edge tree sizes;
- conflicting checkpoints and missing archive leaves;
- long-offline Composer update from old checkpoint;
- interrupted atomic state update and recovery;
- maximum document, array, string, key, signature, and proof limits;
- parser mutation, fuzz, differential, and allocation tests;
- clock skew and uncertainty at every boundary;
- consensus publication and mirror corruption scenarios.

Independent implementations MUST consume the same conformance corpus before
interoperability is claimed.

## 33. Claim Gates

### 33.1 Functional PoC

The PoC may use simulated authorities but MUST exercise:

- independent signature records;
- canonical consensus construction;
- descriptor validation;
- three-layer topology assignment;
- current and next node keys;
- rollback state;
- revocation;
- sign-once behavior;
- transparency inclusion and consistency proofs;
- expired-consensus fail-closed behavior.

`FOG-LOCAL-POC.md` keeps the authority fixture networkless and explicitly
non-claim-bearing. Its fault plan requires insufficient-quorum, same-epoch
fork, stale-consensus, rollback-state, and clock-uncertainty cases before a
runnable fixture can pass.

### 33.2 Operator alpha

Alpha requires:

- three independently administered authority roots and online services;
- a 2-of-3 quorum;
- independent consensus mirrors;
- at least two independent checkpoint monitors or witnesses;
- rehearsed online-key compromise, node revocation, authority replacement,
  quorum loss, clock failure, and restore exercises;
- public admission, family, revocation, and residual-risk policy;
- confirmation that no shared provider account or management credential
  controls the authority quorum.

### 33.3 Production PKI claims

Production claims additionally require:

- independent protocol and implementation review;
- reviewed concrete classical and post-quantum policy;
- independently reproduced consensus and transparency roots;
- published conformance results and unresolved findings;
- demonstrated long-offline update and recovery ceremonies;
- ongoing operator-family and common-control auditing;
- explicit documentation that a compromised authority threshold can still
  authorize a malicious network view.

## 34. Requirements Traceability

| Requirement | FOG-PKI control |
| --- | --- |
| `TM-NET-06` | full canonical consensus, fixed profile IDs, no partial-view merge |
| `TM-PKI-01` | permissioned admission, operator records, family and infrastructure constraints |
| `TM-PKI-02` | monotonic epoch and hash state, hard expiry, Merkle inclusion and consistency |
| `TM-PKI-03` | independent M-of-N authorities, offline roots, bounded online keys, deterministic quorum failure |
| `TM-OPS-01` | minimal public fields, no user data or private governance evidence |
| `TM-SUPPLY-01` | pinned genesis, certified online keys, canonical objects, authenticated transitions |
| `TM-CRYPTO-01` | purpose-specific key hierarchy, bounded overlap, explicit compromise response |
| `TM-CRYPTO-02` | already-trusted authentication suite, composite all-component validation, no downgrade |
| `TM-AVAIL-01` | permissioned uploads, strict limits, non-amplification, explicit no-consensus state |
| `ARC-005` | Composer-validated complete authenticated network view |
| `ARC-007` | one owner and purpose for root, vote, operator, node, and epoch keys |
| `ARC-008` | restricted CBOR, exact schema, absolute limits, unknown-critical rejection |
| `ARC-009` | stale and hard-expiry states, no locally synthesized fallback consensus |
| `IF-03` | authenticated bounded node descriptor upload |
| `IF-04` | signed commit, reveal, proposal, signature, and checkpoint exchange |
| `IF-05` | immutable hash-addressed full consensus and offline update bundle |

## 35. Open Pre-Implementation Selections

The protocol structure is fixed, but these selections block implementation:

- exact encoding, vectors, implementation, artifact-separability analysis,
  side-channel evidence, and activation record for the non-active SHA3-256
  and ML-DSA-65 plus Ed25519 candidates;
- exact epoch duration, schedule offsets, freshness, hard expiry, and clock
  uncertainty;
- exact deterministic topology shuffle and diversity constraint algorithm;
- initial wire, KEMSphinx, entry, storage, cover, and application profile IDs;
- authority wire-key certificate issuance, storage, revocation, and rollover
  profile;
- initial lower operational document and node-count limits;
- hardware and ceremony profile for authority roots;
- monitor and witness operators for alpha;
- explicit `RecoveryManifest` ceremony and user interface;
- public governance reason-code registry and private evidence retention policy.

These values MUST be selected through reviewed profiles and conformance
vectors. Implementations MUST NOT invent local defaults.

## 36. References

- FOG threat model: `FOG-THREAT-MODEL.md`
- FOG architecture: `FOG-ARCHITECTURE.md`
- FOG wire protocol: `FOG-WIRE.md`
- FOG storage protocol: `FOG-STORAGE.md`
- FOG Composer protocol: `FOG-COMPOSER.md`
- FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md`
- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md`
- FOG local Podman PoC: `FOG-LOCAL-POC.md`
- NIST FIPS 204, Module-Lattice-Based Digital Signature Standard:
  <https://csrc.nist.gov/pubs/fips/204/final>
- RFC 9955, Hybrid Signature Spectrums:
  <https://www.rfc-editor.org/rfc/rfc9955.html>
- RFC 9980, Post-Quantum Cryptography in OpenPGP:
  <https://www.rfc-editor.org/rfc/rfc9980.html>
- Katzenpost public key infrastructure specification:
  <https://katzenpost.network/docs/specs/pki/>
- Katzenpost mix network specification:
  <https://katzenpost.network/docs/specs/mixnet/>
- Tor directory authority and consensus specifications:
  <https://spec.torproject.org/dir-spec/>
- Tor shared-random protocol:
  <https://spec.torproject.org/srv-spec/>
- RFC 8949, Concise Binary Object Representation:
  <https://www.rfc-editor.org/rfc/rfc8949.html>
- RFC 9162, Certificate Transparency Version 2.0:
  <https://www.rfc-editor.org/rfc/rfc9162.html>
- The Update Framework specification:
  <https://theupdateframework.github.io/specification/>

These references inform quorum operation, offline and online key separation,
deterministic encoding, append-only consistency proofs, root transitions,
rollback handling, and freeze detection. They do not make FOG-PKI secure by
inheritance. FOG requires its own concrete suites, test vectors,
implementations, operations, and independent review.