diff options
Diffstat (limited to 'docs/FOG-PKI.md')
| -rw-r--r-- | docs/FOG-PKI.md | 1814 |
1 files changed, 1814 insertions, 0 deletions
diff --git a/docs/FOG-PKI.md b/docs/FOG-PKI.md new file mode 100644 index 0000000..4bc0ebd --- /dev/null +++ b/docs/FOG-PKI.md @@ -0,0 +1,1814 @@ +# 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. |