The Universal Zero-Port Interconnect Framework (UZPIF): An Identity-Centric Architecture for Post-Port Networking

3.1. Motivation and Deployment Context

• Investment in perimeter defences (e.g., DDoS mitigation and application firewalls) can yield diminishing returns as attackers automate scanning and exploit discovery at Internet scale.¶

• Zero Trust Network Access (ZTNA) and SASE deployments indicate demand for identity-first networking, yet many approaches still expose TCP/UDP ingress and rely on perimeter constructs. [NIST-SP800-207]¶

• Post-quantum cryptography efforts provide a path to identity-first transport without prohibitive performance regression as key encapsulation and signature schemes mature. [NIST-PQC]¶

3.2. Relationship to VPN-Based Approaches

Conventional VPNs and overlay networks typically retain the assumption that services listen on IP:port tuples, even if those ports are only reachable within a private address space or through a gateway. QUIC [RFC9000], TLS 1.3 [RFC8446], HIP [RFC7401], and systems such as Tor [Tor] demonstrate that identity, encryption, and rendezvous can be decoupled from raw addressing semantics, but they generally retain listener-based service reachability.¶

• No listeners at endpoints.¶

• Identity-as-address via identities (e.g., canonical and ephemeral identities) rather than IP:port.¶

• Companion transport profiles define session and transport behaviour rather than inheriting a VPN tunnel abstraction.¶

• Pantheon policy plane encoding purpose, context, and validity into every session.¶

5.1. Canonical Serialisation and Signature Coverage

Producers and verifiers MUST use the JSON Canonicalization Scheme (JCS) defined in [RFC8785] over UTF-8 JSON text.¶

Object production and verification use two exact canonical preimages. First, the producer derives "object_id" from the JCS serialisation of {"body": body, "envelope": envelope_without_object_id}, where envelope_without_object_id is the final envelope with only the "object_id" member omitted. Second, after inserting the derived "object_id", the canonical signature input is exactly the UTF-8 octet string of the JCS serialisation of {"body": body, "envelope": envelope}. The top-level "signatures" member, any detached-signature container, and any transport wrapper are outside both canonical preimages.¶

The "object_id" value MUST be formatted as "urn:uzpif:obj:v1:sha256:<lowercase-hex>", where the digest is the SHA-256 hash of the object-id preimage described above. Verifiers MUST recompute and compare "object_id" before evaluating signatures. Adding, removing, or reordering signatures does not change "object_id". Any change to envelope or body content, including extensions, validity bounds, policy references, or sequence metadata, MUST produce a different "object_id".¶

Each accepted signature MUST cover the exact canonical signature input bytes and nothing else. Suite-interoperable signatures MUST NOT be computed over pretty-printed JSON, partially selected members, alternate canonicalisation schemes, XML renderings, CBOR transcodings, log wrappers, transport records, or presentation-layer containers.¶

If an object-specific schema admits optional defaults, producers MUST materialise the exact values to be signed before canonicalisation. Verifiers MUST recompute "object_id" and the signature input from the received values, not from locally inferred defaults or omitted aliases.¶

Non-finite numbers, duplicate member names, semantically equivalent but non-canonical encodings, or values that cannot be represented under [RFC8785] MUST cause rejection.¶

5.2. Envelope Members and Extensions

Every common signed artefact MUST include "version", "object_type", "object_id", "issuer_authority_id", "subject_id", "scope", "issued_at", "not_before", "not_after", "key_id", and at least one entry in "signatures". The "body" member MUST be a JSON object whose direct member set is closed by the declared "object_type": direct body members not defined for that object type, "extensions", or "critical_extensions" MUST cause rejection. "audience_id", "policy_id", "policy_version", "epoch", "sequence", "nonce", "prev_hash", and "log_ref" MUST be present when relevant to the object's semantics, replay model, or transparency linkage.¶

Authenticity alone is insufficient for reliance on a common signed artefact. A valid signature proves origin and integrity, but a relying party MUST also evaluate freshness, scope, supersession, audience binding where relevant, and policy eligibility before treating the artefact as current authority.¶

version

Identifies the envelope version so that parsers and relying parties can apply the correct validation rules. Suite-interoperable objects defined by this revision MUST set "version" to 1.¶

object_type

Classifies the artefact using the exact case-sensitive token registered in Section 5.3. For suite-interoperable exchange, aliases or profile-specific synonyms are invalid.¶

object_id

Provides the stable identifier for the logical signed object. Producers MUST derive it according to Section 5.1. The same envelope and body content MUST always produce the same object_id, regardless of signature count. Producers MUST NOT reuse an object_id for different envelope or body content.¶

issuer_authority_id

Identifies the authority context under which the object is issued. It MUST map to signed authority metadata or other locally trusted issuer metadata.¶

subject_id

Identifies the principal, resource set, or relationship primarily affected by the artefact.¶

audience_id

Identifies the intended relying party or recipient when the artefact is not intended for universal consumption.¶

scope

Defines the operational scope of the artefact, such as authorised actions, resource sets, tenant boundaries, RN context, or revocation domain.¶

policy_id / policy_version

Name the policy basis and version under which the artefact was issued when policy tracking matters.¶

issued_at / not_before / not_after

Define issuance time and validity bounds. Artefacts outside their validity window MUST be rejected.¶

epoch / sequence

Provide ordering and conflict-detection context. If both are present, "epoch" takes precedence for semantic supersession and "sequence" orders objects within the same epoch or append-only stream. A higher "epoch" supersedes any lower "epoch" regardless of "sequence". If "epoch" is equal, a higher "sequence" is newer. A lower-epoch object MUST NOT supersede a higher-epoch object merely because its "sequence" is larger.¶

nonce

Carries replay-unique entropy for replay-sensitive artefacts such as Grants, PoR evidence, or session-bound authorisations. Re-usable objects that are not replay-sensitive MAY omit it.¶

key_id

Identifies the primary issuer key used for key discovery. It MUST match the first embedded signature entry after signature-array sorting and MUST match at least one embedded signature entry.¶

prev_hash / log_ref

Link the artefact into an append-only sequence or an external transparency record when auditability or append-only verification is required.¶

body members

The direct members of "body" are defined by the registered object-type profile. Unknown direct body members MUST cause rejection unless they are carried under "body.extensions".¶

body.extensions / body.critical_extensions

Object-specific extension values MUST appear only under "body.extensions", which, if present, MUST be a JSON object. "body.critical_extensions", if present, MUST be an array of unique extension keys sorted in ascending lexicographic order, and each listed key MUST exist in "body.extensions". Extension keys MUST be unique namespaced ASCII strings. Unknown extension values MAY be ignored only if they are not listed in "body.critical_extensions". Unknown critical extensions MUST cause rejection. Unknown members in "envelope", in an embedded signature entry, or as direct body members MUST cause rejection.¶

5.3. Suite-wide object_type Registry

The "object_type" member is a case-sensitive lowercase ASCII token. For suite-interoperable exchange, it MUST use one of the exact values registered in Table 1. Companion drafts define only the body profile and additional validation for their registered object types; they MUST NOT rename, alias, or reinterpret a registered value. New suite-wide object types require an explicit update to this registry.¶

Detached signatures are not permitted for any registered object type in this revision. A future suite revision MAY change that only by updating both this registry and Section 5.5.¶

5.4. Signature Algorithm Identifiers

The "alg" member is a case-sensitive ASCII token that identifies the exact signature verification procedure applied to the signature bytes in "value". Comparison is byte-for-byte. Aliases, case folding, numeric registry codes, OIDs, or implicit translation between naming schemes MUST NOT be used for suite-interoperable verification.¶

Trusted issuer metadata MUST bind each signing key identifier to one or more exact "alg" tokens. A verifier MUST accept a signature only when the signature entry's "alg" exactly matches a token bound to that key and local policy permits that algorithm for the declared object_type and time interval.¶

Composite or hybrid constructions, if used, MUST have their own exact "alg" token and verification procedure. They MUST NOT be represented by multiple "alg" values within one signature entry or by guessing from key type alone.¶

5.5. Signature Entries, Ordering, and Detached Form

The "signatures" array MUST contain at least one embedded signature. Each embedded signature entry MUST contain exactly "key_id", "alg", and "value". The embedded-signature member set is closed.¶

The array order is significant for serialised interchange and MUST be sorted in ascending lexicographic order by "key_id", then "alg", then "value". Duplicate entries with the same "key_id" and "alg", or duplicate complete entries, MUST cause rejection. A received array that is not already in this order MUST cause rejection. The envelope "key_id" MUST identify the first embedded signature entry after sorting.¶

The "alg" value is mandatory and case-sensitive, and it is processed according to Section 5.4. A signature entry whose "alg" is absent, unknown, unsupported, mismatched to the key metadata, or forbidden by local policy MUST be treated as invalid. If the remaining valid signatures do not satisfy the required signature set, the object MUST be rejected.¶

Embedded signatures are the only interoperable signature form for the registered object types in Table 1. For those object types, detached signatures MUST NOT be used and MUST NOT count toward policy satisfaction. If a future suite revision explicitly permits detached signatures for a specific object type, each detached signature MUST cover the same canonical signature input as the embedded form and MUST carry "object_id", "key_id", "alg", and "signed_object_hash", where "signed_object_hash" is "sha256:<lowercase-hex>" over the canonical signature input. If both embedded and detached signatures are present for such a future object type, every signature MUST verify against the same canonical signature input and object_id; any mismatch MUST cause rejection.¶

5.6. Validation Rules

Relying parties validating a common signed artefact MUST verify at least the following:¶

• the top-level member set, envelope member set, embedded-signature member set, and object-type-specific direct body member set are well-formed and contain no unknown members except under "body.extensions";¶

• the envelope version is supported for the declared object_type, and registered suite-wide object types defined by this revision use "version" equal to 1;¶

• the declared object_type is an exact registered suite-wide token when interoperable suite exchange is claimed;¶

• object_id recomputation succeeds;¶

• issuer_authority_id is locally trusted, validly delegated, or otherwise accepted under the applicable federation policy;¶

• the signing key identified by key_id is valid for the object_type and time interval, and the envelope key_id matches the first embedded signature entry after sorting;¶

• signature ordering and duplicate checks succeed, and every accepted signature verifies over the exact canonical signature input;¶

• each "alg" value exactly matches trusted key metadata and a locally permitted signature verification procedure for the declared object_type;¶

• the required signature set satisfies local policy, including any threshold or quorum rule;¶

• the current time falls within the declared validity interval;¶

• audience_id matches the relying party when the object is audience-bound;¶

• nonce uniqueness and epoch or sequence freshness checks succeed when replay resistance or state ordering matter;¶

• the artefact has not been superseded, rendered stale under local policy, or made policy-ineligible for the relevant scope and decision;¶

• prev_hash or log_ref, when present, are consistent with the relevant append-only or transparency evidence; and¶

• body.critical_extensions, when present, is unique, sorted, references only keys present in body.extensions, and contains no unsupported critical extension names.¶

Objects sharing the same issuer_authority_id, object_type, subject_id, scope, and applicable epoch or sequence state, but with incompatible canonical signature inputs, MUST be treated as conflicting artefacts and processed according to Section 10.7.¶

6.1. High-Level Flow: EP to RN to EP (Informative)

In UZPIF, both peers initiate outbound sessions towards an RN. After policy evaluation and authorisation, the RN stitches the two sessions into a tunnel (ZPIT) that carries end-to-end protected application data.¶

EP A (Initiator)        RN        EP B (Responder)
    |---- outbound ----->|              |
    |                    |<---- outbound|
    |<==== end-to-end encrypted ZPIT (stitched via RN) ====>|

This figure shows both endpoints initiating outbound sessions to the RN, which stitches them into a single ZPIT.¶

The labels in this figure are illustrative only; this document does not define authoritative wire messages or handshake ordering for the transport steps shown.¶

6.2. Pantheon Grant Verification (Informative)

Prior to stitching, an EP is expected to obtain a signed authorisation ("Grant") from Pantheon, as defined in Section 10.3. Grants bind identity to purpose and validity constraints, enabling RNs to make consistent policy decisions. The authoritative Grant format and interoperability requirements are defined in Section 10.3 and Section 5.¶

 EP             Pantheon             RN
  |-- Grant Request -->|              |
  |<- Signed Grant ----|              |
  |----------- Grant + CID/EID ----------------->|

This figure illustrates the basic grant request and issuance exchange between an EP and Pantheon.¶

The message labels are illustrative only. Authoritative Grant object semantics are defined in Section 10.3, and authoritative transport or handshake sequencing is defined in companion drafts.¶

6.3. Flow Stitching by the RN (Informative)

The RN establishes a stitched tunnel only if both peers present acceptable identities and authorisations. The exact transport, stitching, failover, and protected-traffic semantics are defined in the companion UZP and TLS-DPA drafts.¶

EP A                 RN                  EP B
 |-- Join Request -->|                    |
 |<-- Stitch OK -----|                    |
 |                    |<-- Join Request --|
 |                    |-- Stitch OK ----->|
 |
 |<====== end-to-end encrypted ZPIT (SessionID-bound) ==========>|

This figure shows the RN joining two authorised sessions into a stitched tunnel without learning plaintext.¶

The message names and sequencing in this figure are illustrative only. Authoritative stitching, failover, and session semantics are defined in the companion UZP and TLS-DPA drafts.¶

6.4. Multi-RN Stitching for High-Assurance Tenants (Informative)

UZPIF can be extended to multi-hop stitching, for example where a tenant requires multiple independently operated RNs and attestation chains. End-to-end protection is expected to remain between endpoints.¶

EP A -> RN1 -> RN2 -> EP B

EP A <======== end-to-end AEAD protected traffic ========> EP B

This figure depicts a multi-hop RN chain while end-to-end AEAD protection remains between endpoints.¶

This subsection is a deployment sketch only and does not define authoritative multi-RN transport semantics.¶

7.1. HIL Requirements

A HIL used to bridge non-UZPIF-capable equipment:¶

• MUST be explicitly identified as a translation boundary;¶

• MUST terminate trust domains cleanly rather than representing legacy traffic as natively identity-bound;¶

• MUST enforce a narrow allow-listed protocol surface for the specific attached device or device class;¶

• MUST expose only the minimum necessary legacy port behaviour toward the attached equipment;¶

• MUST NOT elevate unauthenticated legacy assertions into Pantheon, Grant, or attestation truth without validation;¶

• SHOULD support one-way or brokered operation where possible rather than transparent raw pass-through; and¶

• MUST be auditable as a security-critical adapter.¶

When a HIL mediates an action into UZPIF, it SHOULD bind that action to auditable evidence including:¶

• the HIL identity;¶

• the attached device identity or slot or port identity;¶

• the translated protocol;¶

• the relevant time interval;¶

• the applicable policy or Grant; and¶

• an evidence-log reference or equivalent audit record.¶

7.2. Local Trust Boundary of HIL-Mediated Systems

A HIL secures the boundary between a UZPIF environment and a legacy device interface; it does not guarantee the integrity or confidentiality of the local physical segment behind that boundary. Deployments MUST treat the HIL-attached legacy domain as an independently exposed trust zone unless additional protections are present.¶

The HIL's protection applies to the mediated protocol boundary, not automatically to the local wire, serial line, bus, switch port, backplane, maintenance interface, or other attached legacy segment behind it. Compromise of that local segment may still permit false device input, spoofed local traffic, local firmware replacement, bus replay, serial-line manipulation, switch-port insertion, maintenance-port misuse, false sensor injection, or manipulation of translated events before they cross into the UZPIF-mediated side.¶

HIL containment therefore reduces and evidences legacy exposure, but it does not retroactively make the attached hardware domain cryptographically trustworthy. Where stronger assurance is required, deployments SHOULD consider physical controls, tamper detection, local attestation, secure serial or bus wrappers where available, and device-origin integrity checks where feasible.¶

7.3. HIL Software and Supply-Chain Integrity

A compromised HIL is especially dangerous because it sits at the boundary between legacy protocol behaviour and native identity-bound operation. A malicious or subverted HIL may spoof device status, fabricate translated events, widen the permitted legacy surface, create covert ingress, or launder insecure traffic into a deployment that appears to be operating under stronger trust assumptions.¶

HIL software manifests, configurations, policy bundles, and updates SHOULD be signed and auditable. No HIL software, configuration, or policy change SHALL become authoritative unless its manifest, version, signer set, scope, and policy eligibility validate successfully under the deployment's normal trust model.¶

HIL update, provisioning, and recovery channels MUST NOT become hidden sovereign authority paths. Local administrative overrides, emergency maintenance paths, or vendor tooling MUST NOT silently bypass the same validation model claimed for ordinary operation. This is aligned with the ICSD ([ICSD]) principle that privileged update or override paths must be modelled so that invalid states are rejected rather than normalised.¶

7.4. Legacy Compatibility Classes

This document distinguishes three compatibility classes for legacy integration so that deployments can state clearly whether a device is fully mediated, tightly brokered, or merely forwarded.¶

Class A - Full Mediation

The HIL terminates the legacy protocol and exposes a modelled, policy-bound interface into UZPIF. This is the RECOMMENDED integration model.¶

Class B - Brokered Pass-Through

The HIL permits tightly scoped transport bridging for a specific session under explicit Grant, time, scope, and evidence rules. This MAY be used where full mediation is not feasible, but it provides weaker containment than Class A.¶

Class C - Direct Forwarding Compatibility Mode

The HIL forwards arbitrary port traffic. This mode is outside the recommended security model, SHOULD NOT be used except as a bounded migration exception, and MUST NOT be represented as equivalent to native UZPIF participation or to Class A or Class B mediation.¶

8.1. Bootstrap Model Clarification

Bootstrap MAY use multiple Bootstrap Seed Bundles, mirrored distribution paths, offline media, local ceremony, and DNS or similar mechanisms as transports for seed distribution. The transport used to deliver seed material does not itself create trust; trust begins only after the device validates a Bootstrap Seed Bundle under local bootstrap policy.¶

Bootstrap mechanisms MUST be replaceable across deployments and over time. Bootstrap mechanisms MUST NOT depend on a single distribution source. No single seed source SHALL be mandatory.¶

8.2. Bootstrap, Recovery, and Re-Enrolment

Bootstrap, recovery, factory reset, re-enrolment, and emergency rekeying are privileged trust transitions. A deployment that appears decentralised during steady-state operation but depends on a singular bootstrap or recovery path has introduced a hidden trust anchor and does not satisfy the intended UZPIF sovereignty model.¶

New-node bootstrap, client recovery after state loss, RN rejoin after corruption, initial HIL enrolment, and emergency rekeying after compromise MUST NOT require a singular globally mandatory authority or delivery path. These workflows MUST NOT depend solely on one website, one operator, one Recovery / Re-Enrolment Bundle, one vendor endpoint, or one golden administrative key as the only path to valid trust state.¶

Recovery workflows MUST fail closed on missing, unsigned, expired, conflicting, or policy-ineligible recovery material. Recovered trust state MUST remain independently verifiable through the signed artefacts, authority metadata, and transparency or quorum evidence defined below before it becomes authoritative.¶

This document defines a minimal baseline model for those privileged transitions. Baseline-conformant bootstrap or recovery support consists of validated Bootstrap Seed Bundle input, explicit first-contact admission through a Bootstrap Admission Object, explicit continuity-sensitive return through a Recovery / Re-Enrolment Bundle when prior state existed, and issuance of only bounded initial or recovered identity and Grant state under policy.¶

Factory reset and re-enrolment MUST be treated as privileged trust transitions rather than convenience workflows. A reset or re-enrolled endpoint, RN, or HIL MUST re-establish trust as a new or explicitly recovered principal under local policy, and previous trust state MUST NOT be silently reinstated absent verifiable recovery artefacts.¶

Profiles MAY use multiple Bootstrap Seed Bundles, mirrored distribution paths, offline recovery packages, out-of-band provisioning, or quorum-approved rekey procedures. However, no single bootstrap or recovery source SHALL be mandatory for global protocol validity. This aligns with the invariant-closed design discipline described in ICSD ([ICSD]), where privileged recovery transitions are modelled so that invalid or unauthorised recovery states are rejected rather than normalised.¶

8.3. Key Custody and Signing-Role Separation

Cryptographic separation of keys is not, by itself, sufficient if the same actor, machine, or operational role can exercise all practically decisive signing and administrative powers. A deployment that concentrates issuance, policy, revocation, software-release, routing, and trust-bundle control into one custody domain has recreated a hidden sovereign control point even if each function uses a distinct key.¶

Deployments SHOULD separate, where practical, at least some of the following roles:¶

• identity issuance;¶

• Grant or policy signing;¶

• revocation quorum participation;¶

• software release or patch manifest signing;¶

• RN operational administration; and¶

• transparency witnessing or equivalent append-only verification roles.¶

This document does not mandate one governance structure. It does define the architectural principle that concentrated custody of all such roles SHOULD be avoided when stronger separation is practical, especially for deployments claiming high assurance, multi-party accountability, or resistance to unilateral control.¶

Where small or local deployments combine roles, that concentration SHOULD be explicit, auditable, and bounded by stronger local controls such as threshold approval, independent logging, external witnessing, or stricter operational review. Combined-role operation MUST NOT be treated as evidence that organisational separation is unnecessary at broader deployment scale.¶

8.4. Client Sovereignty Model

In UZPIF, clients are the ultimate trust arbiters at the edge.¶

Clients MUST:¶

• validate RN transparency logs;¶

• verify Proof-of-Reachability (PoR) responses as defined by UZP ([UZP]); and¶

• independently determine trust decisions using local policy and cryptographic evidence.¶

8.5. RN Controller Properties

An RN Controller is the control-plane implementation used to operate one or more RNs. The following requirements apply to RN Controller designs.¶

RN Controllers MUST:¶

• be self-hostable without external approval;¶

• publish signed transparency logs;¶

• support cryptographic verifiability of routing behaviour; and¶

• allow client-side trust evaluation.¶

RN Controllers MUST NOT:¶

• enforce global revocation unilaterally;¶

• depend on a single upstream authority; and¶

• possess unilateral kill-switch capability.¶