SECDISPATCH ZTOP Research Group Internet-Draft Zero Trust Consortium Intended status: Standards Track 24 July 2026 Expires: 24 January 2027 Zero Trust Transfer Orchestration Protocol (ZTOP) draft-ztop-secdispatch-protocol-00 Abstract This document defines the Zero Trust Transfer Orchestration Protocol (ZTOP), a novel Application Layer (OSI Layer 7) protocol for orchestrating cryptographically authenticated, continuously attested peer-to-peer file transfer in Zero Trust Architectures (ZTA). ZTOP operates within a TLS 1.3 transport tunnel and introduces: a hardware-derived cryptographic Peer Identity using HKDF-SHA512 and Ed25519; a 5-layer X.509 certificate chain with custom OID-encoded Zero Trust metadata; a continuous 16-field Heartbeat attestation protocol; a 100-point Adaptive Tamper Resistance Score; a dual-signed 19-field Metadata Exchange Protocol preceding any payload; a 380-byte Cryptographic Execution Manifest (CEM) permanently bound to every transferred file; SHA-256 binary Merkle-tree chunk integrity with immediate per-chunk proof validation; protocol-native static pre-execution behavioral analysis; and a 7-Level non-repudiation Signature Chain. A transfer is considered complete only when all seven cryptographic signatures are present and verified. A Python reference implementation is available at: https://github.com/sripad2020/ztop-research/ Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . 4 3. Protocol Architecture . . . . . . . . . . . . . . . . . . . 5 3.1. OSI Layer Position . . . . . . . . . . . . . . . . . . . 5 3.2. Engine Components . . . . . . . . . . . . . . . . . . . . 6 4. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Frame Structure . . . . . . . . . . . . . . . . . . . . . 6 4.2. Flags Field . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Message OpCode Table . . . . . . . . . . . . . . . . . . 9 5. Session State Machine . . . . . . . . . . . . . . . . . . . 10 6. Cryptographic Peer Identity . . . . . . . . . . . . . . . . 11 6.1. Derivation Algorithm . . . . . . . . . . . . . . . . . . 11 6.2. Identity Challenge Protocol . . . . . . . . . . . . . . . 12 7. Certificate Architecture . . . . . . . . . . . . . . . . . 13 8. Trust Evaluation . . . . . . . . . . . . . . . . . . . . . 13 8.1. Device Posture Scoring . . . . . . . . . . . . . . . . . 13 8.2. Adaptive Tamper Resistance Score . . . . . . . . . . . . 14 9. Policy Engine . . . . . . . . . . . . . . . . . . . . . . . 15 10. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . 15 11. Metadata Exchange Protocol . . . . . . . . . . . . . . . . 16 12. Cryptographic Execution Manifest . . . . . . . . . . . . . 17 13. Chunk-Level Integrity: Merkle Trees . . . . . . . . . . . . 18 14. Pre-Execution Static Analysis . . . . . . . . . . . . . . . 19 15. 7-Level Signature Chain . . . . . . . . . . . . . . . . . . 20 16. Trust-Preserving Reconnection . . . . . . . . . . . . . . . 21 17. Security Considerations . . . . . . . . . . . . . . . . . . 22 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 19. Normative References . . . . . . . . . . . . . . . . . . . 24 20. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction File transfer protocols have not evolved with Zero Trust security principles [RFC7296]. Protocols such as SFTP [RFC4253] and FTP [RFC959] authenticate a user once via a static credential and subsequently establish an open, trusted channel. They have no awareness of device security posture, real-time behavioral analysis of the transferred content, or cryptographic non-repudiation of the transaction itself. Enterprises today solve this limitation by deploying five or more separate security products alongside a legacy file transfer protocol, resulting in fragmented, expensive, and operationally complex architectures. ZTOP defines a single, self-contained Application Layer protocol that natively integrates all of the following: * Cryptographic Peer Identity derived from hardware attestation * Continuous device posture evaluation and dynamic trust scoring * Declarative organizational policy enforcement * Pre-payload metadata negotiation with dual attestation signatures * File-level Cryptographic Execution Manifests (CEM) * Per-chunk Merkle tree integrity without requiring full-file arrival * Protocol-native static behavioral analysis of received files * A 7-Level non-repudiation signature chain * Trust-preserving session resumption after disconnection ZTOP does NOT replace TCP, IP, TLS, or QUIC. It operates within a TLS 1.3 tunnel and defines how endpoints behave before, during, and after a file transfer. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Peer ID: A cryptographically derived, hardware-bound identifier for a ZTOP endpoint, encoded as Base58(SHA3-256(Ed25519PublicKey)). Gateway: A ZTOP server enforcing policy and trust evaluation on behalf of an organization. Trust Score: A value 0-100 representing a device's computed security posture at a point in time. CEM: Cryptographic Execution Manifest. A 380-byte signed header permanently bound to every ZTOP-transferred file. Session Certificate: A short-lived (12-hour) X.509 certificate binding a device's identity and trust score to an active session. Merkle Root: The root hash of a binary SHA-256 Merkle tree constructed over all file chunks. Signature Chain: A sequence of seven Ed25519 signatures constituting cryptographic non-repudiation of a complete transfer. TRS: Tamper Resistance Score. A 100-point composite score evaluated across six security dimensions. 3. Protocol Architecture 3.1. OSI Layer Position ZTOP is an Application Layer (OSI Layer 7) protocol. It MUST operate within an encrypted transport tunnel. Implementations MUST support TLS 1.3 [RFC8446] as the transport. Implementations MAY additionally support QUIC [RFC9000]. +----------------------------------------------------------+ | Layer 7 - APPLICATION | | +-----------------------------------------------------+ | | | ZTOP PROTOCOL | | | | TrustEngine PolicyEngine CertEngine | | | | MerkleEngine CEMEngine HeartbeatEngine | | | | ExecutionAnalyzer SignatureChainEngine | | | | ReconnectManager AuditEngine | | | +-----------------------------------------------------+ | +----------------------------------------------------------+ | Layer 6 - PRESENTATION | | TLS 1.3 (AES-256-GCM / ChaCha20-Poly1305) | +----------------------------------------------------------+ | Layer 4 - TRANSPORT: TCP Port 7890 | +----------------------------------------------------------+ | Layers 1-3: IPv4 / IPv6 / Ethernet / Wi-Fi | +----------------------------------------------------------+ Figure 1: ZTOP OSI Layer Position 3.2. Engine Components The Gateway instantiates fifteen engines per active client session: PeerIDEngine, CertStore, CertEngine, TrustEngine, TamperScoreEngine, PolicyEngine, HeartbeatEngine, MerkleEngine, CEMEngine, MetadataEngine, ExecutionAnalyzer, SignatureChainEngine, ReconnectManager, IntegrityEngine, and AuditEngine. 4. Wire Format 4.1. Frame Structure All ZTOP messages SHALL be encoded as frames in Network Byte Order (Big-Endian). Every frame consists of three fixed headers, a variable TLV payload section, raw payload data, and two mandatory footers. The minimum frame size is 166 bytes. +----------------------------------------------+ | PROTOCOL HEADER (38 bytes, fixed) | +----+-------+--------+--------+--------------+ | |Mgc |Vers |MsgType |Flags |Sequence Num | | |'ZT'|0x01 |(1 byte)|(2 byte)|(4 bytes) | | +----+-------+--------+--------+--------------+ | |Timestamp (8 bytes, uint64, microseconds) | +------------------------------------------------+ |Session ID (16 bytes, UUID v4) | +------------------------------------------------+ |Payload Length (4 bytes, uint32) | +------------------------------------------------+ | SECURITY HEADER (48 bytes, fixed) | +------------------------------------------------+ |Nonce (12 bytes, random, fresh per-frame) | +------------------------------------------------+ |Transfer ID (16 bytes, UUID v4) | +------------------+----------+------+-----------+ |PolicyVersion (4) |TrustScore|EncSte|Reserved(8)| +------------------+----------+------+-----------+ | ROUTING HEADER (16 bytes, fixed) | +------------------------------------------------+ |Device ID Hash (8 bytes, truncated SHA-256) | +-------------------+------+------+----------+ | |OrgIDHash(4,CRC32) |Prio |Comp |ExtCount | | +-------------------+------+------+----------+ | | PAYLOAD HEADER (variable, TLV-encoded) | |[Type(2)|Length(2)|Value(N)] x ExtCount | +------------------------------------------------+ | RAW PAYLOAD DATA (variable) | +------------------------------------------------+ | INTEGRITY FOOTER (32 bytes) | |SHA-256(all preceding bytes) | +------------------------------------------------+ | AUTH FOOTER (32 bytes) | |HMAC-SHA256(session_key, body||integrity) | +------------------------------------------------+ | SIGNATURE FOOTER (96 bytes, conditional) | |ECDSA-P384 (present when SIGNED flag is set) | +------------------------------------------------+ Figure 2: ZTOP Frame Layout The AUTH FOOTER uses HMAC-SHA256 as defined in [RFC2104]. Session IDs and Transfer IDs are UUID version 4 values as defined in [RFC4122]. 4.2. Flags Field The 2-byte Flags field encodes eight independent Zero Trust control signals as a bitmask. A receiver that observes a TRANSFER_CHUNK packet without PAYLOAD_ENCRYPTED (0x0001) set MUST reject the packet with error code ENCRYPTION_REQUIRED and MAY terminate the session. Value Name Description ------ ------------------- -------------------------------- 0x0001 PAYLOAD_ENCRYPTED Data frames without this flag MUST be rejected. 0x0002 PAYLOAD_COMPRESSED Uses codec in Routing Header. 0x0004 REQUIRES_ACK Receiver MUST acknowledge. 0x0008 PRIORITY_BOOST Processed before standard frames. 0x0010 SIGNED 96-byte ECDSA-P384 footer added. 0x0020 LAST_CHUNK Final chunk of a transfer. 0x0040 RECOVERY_MODE Part of reconnect handshake. 0x0080 HEARTBEAT_EXPECTED Sender mandates HB from receiver. Figure 3: ZTOP Flags Field 4.3. TLV Encoding All metadata within a ZTOP frame is carried in TLV records: a 2-byte Type (Big-Endian uint16), a 2-byte Length (Big-Endian uint16), and a Value field of that many bytes. Mandatory TLV codes are in range 0x0000-0x7FFF; optional codes are in range 0x8000-0xFFFF. An unknown mandatory TLV type MUST cause the receiver to return an ERROR packet and close the session. An unknown optional TLV type MUST be silently ignored. 4.4. Message OpCode Table OpCode Name Direction ------ --------------------- ---------------- 0x01 HELLO Client to Server 0x02 DISCOVER Server to Client 0x03 REGISTER Client to Server 0x04 IDENTITY_REQUEST Server to Client 0x05 IDENTITY_RESPONSE Client to Server 0x06 TRUST_REQUEST Client to Server 0x07 TRUST_RESPONSE Server to Client 0x08 POLICY_REQUEST Client to Server 0x09 POLICY_RESPONSE Server to Client 0x0A CAPABILITY_NEGOTIATE Both 0x0B SESSION_CREATE Client to Server 0x0C SESSION_ACCEPT Server to Client 0x0E SESSION_RECOVER Client to Server 0x0F SESSION_CLOSE Either 0x10 HEARTBEAT Client to Server 0x20 TRANSFER_REQUEST Client to Server 0x21 TRANSFER_START Server to Client 0x22 TRANSFER_CHUNK Client to Server 0x23 TRANSFER_ACK Server to Client 0x27 TRANSFER_COMPLETE Client to Server 0x28 TRANSFER_REJECT_CHUNK Server to Client 0x33 AUDIT_COMMIT Server to Client 0xFF ERROR Either Figure 4: ZTOP Message OpCode Table 5. Session State Machine A ZTOP session MUST traverse the following states in order. Backward transitions are NOT permitted except for RECOVERING. A Gateway MUST reject any message with an invalid state transition and MUST respond with an ERROR packet containing code SESSION_STATE_INVALID. +INIT+ | <- HELLO received, magic 0x5A54 validated v +DISCOVERY+ | <- REGISTER received, Peer ID parsed v +REGISTERED+ | <- Ed25519 identity challenge signed and verified v +IDENTITY_VERIFIED+ | <- Device posture submitted, Trust Score >= threshold v +DEVICE_TRUSTED+ | <- PolicyEngine returns permitted=True (all 6 checks) v +POLICY_APPROVED+ | <- Session Certificate issued, capabilities negotiated v +SESSION_ACTIVE+ <-----------------------------+ | <- Transport disconnection detected | v | +RECOVERING+ -- Peer ID re-validated via HB ---+ | (7 retries exhausted) v +FAILED+ (terminal) | +TERMINATED+ (terminal) Figure 5: ZTOP Session State Machine (State names enclosed in + ... + delimiters) 6. Cryptographic Peer Identity 6.1. Derivation Algorithm Every ZTOP endpoint MUST derive a Peer ID using the following algorithm. Implementations MUST NOT use Fibonacci sequences or other deterministic mathematical sequences for Peer ID derivation or any cryptographic key generation. Input: device_uuid : Hardware device UUID string cpu_hash : SHA-256(CPU model string), hex os_hash : SHA-256(OS version string), hex motherboard_hash : SHA-256(board identifier), hex network_sig : Ed25519 signature over IP:Port policy_version : Active org policy version (integer) salt : os.urandom(32) [fresh each derivation] Step 1 - Canonical Encoding (UTF-8): IKM = "uuid={device_uuid}|cpu={cpu_hash}| os={os_hash}|mb={motherboard_hash}| policy={policy_version}|netsig={netsig.hex()}" Step 2 - SHA3-512: ikm = SHA3-512(IKM) [64 bytes] Step 3 - HKDF-SHA512 [RFC5869]: seed = HKDF-SHA512( ikm=ikm, salt=salt, info=b"ZTOP-PeerID-v1", length=32 ) Step 4 - Ed25519 Keypair [RFC8032]: private_key = Ed25519PrivateKey.from_private_bytes(seed) pub_raw = private_key.public_key().raw_bytes() [32 bytes] Step 5 - Peer ID Encoding: peer_id = "ZTOP-" || Base58(SHA3-256(pub_raw)) Figure 6: Peer ID Derivation Algorithm The salt MUST be stored in hardware-backed secure storage (e.g., TPM 2.0 or TEE) and MUST NOT be transmitted over the network. 6.2. Identity Challenge Protocol Server -> Client: IDENTITY_REQUEST TLV [CHALLENGE_NONCE] = os.urandom(16) Client: signature = Ed25519PrivateKey.sign(challenge_nonce) Client -> Server: IDENTITY_RESPONSE payload: signature(64 bytes) || public_key_raw(32 bytes) Server verification: 1. expected = "ZTOP-" || Base58(SHA3-256(pub_key_raw)) 2. Assert expected == claimed Peer ID from REGISTER 3. Ed25519PublicKey.verify(signature, challenge_nonce) 4. Both pass -> state: REGISTERED -> IDENTITY_VERIFIED 5. Either fails -> state: FAILED 7. Certificate Architecture ZTOP implements a five-layer X.509 [RFC5280] certificate hierarchy. All certificates use ECDSA-P384 or Ed25519 for signing. The five layers are: Root CA (10-year validity), Org CA (1-year), Device Certificate (30-day), Session Certificate (12-hour), and Transfer Receipt Certificate (1-year). Session Certificates MUST embed the following custom OID extensions: 1.3.6.1.4.1.99999.1 (Device ID), 1.3.6.1.4.1.99999.2 (Session ID), 1.3.6.1.4.1.99999.3 (Trust Score), 1.3.6.1.4.1.99999.4 (Policy Version), 1.3.6.1.4.1.99999.6 (Network Info). Transfer Receipt Certificates MUST embed 1.3.6.1.4.1.99999.8 (Transfer ID) and 1.3.6.1.4.1.99999.9 (File Hash). 8. Trust Evaluation 8.1. Device Posture Scoring The Client MUST submit PostureData in the TRUST_REQUEST message. The TrustEngine assigns weighted scores: Signal Weight Condition --------------------- ------ ------------------------------ EDR Active +30 EDR running TPM Attested +20 TPM 2.0 attestation present Firewall Active +15 Host-based firewall enabled OS Version Current +15 OS major version >= 10 Patch Level Fresh +10 Last patch within 30 days VPN Connected +5 Network posture includes VPN Antivirus OK +5 AV status is OK or ACTIVE Maximum: 100. Default threshold: 70. A Gateway MUST terminate any session where the score falls below the configured threshold. 8.2. Adaptive Tamper Resistance Score The TamperScoreEngine computes a 100-point composite score across six dimensions: Dimension Max Signals ----------------- --- ----------------------------------- Device Posture 20 OS patch, EDR, Firewall, TPM Certificate 20 Chain validity, Expiry, OCSP Heartbeat 15 Consecutive successes, Latency Policy Compliance 15 Version current, org rules, DLP File Integrity 20 Merkle root, chunk rate, CEM sig Network Signature 10 VPN, Geo-fence, IP reputation Trust bands and required Gateway actions: Score Band Required Action ------- ---------- -------------------------------- 95-100 TRUSTED Permit full transfer 80-94 LIMITED Permit with enhanced audit log 60-79 RESTRICTED Permit only via proxied analysis 0-59 DISCONNECT MUST terminate session A Gateway MUST re-evaluate TRS at every Heartbeat interval and after every chunk transfer event. 9. Policy Engine The PolicyEngine executes six independent checks before authorizing any transfer. All six checks MUST pass. A failure on any single check MUST result in a PolicyDecision with permitted=False. The session is then terminated. Check 1: Organization Authorization org_id MUST be in allowed_orgs. Check 2: Operation Authorization operation MUST be in allowed_operations. Check 3: File Size file_size MUST NOT exceed max_file_size (default 500 MB). Check 4: MIME Type mime_type MUST NOT be in blocked_mime_types. Blocked by default: application/x-msdownload, application/x-executable, application/x-sh. Check 5: DLP metadata.contains_pii MUST be False. Check 6: Trust Score trust_score MUST be >= policy.min_trust_score (70). 10. Heartbeat Protocol A Client MUST send a signed Heartbeat packet every 10 seconds while in SESSION_ACTIVE or RECOVERING state. The packet MUST contain 16 fields: peer_id, counter (monotonically increasing uint32), timestamp (microseconds, uint64), device_uuid, cert_fingerprint (SHA-256 of active Session Certificate DER, 32 bytes), current_ip, mac_hash (SHA-256 of MAC address, 32 bytes), port, network_signature (Ed25519 over IP:Port, 64 bytes), policy_version, session_token (SHA-256(session_id), 32 bytes), cpu_arch_hash (32 bytes), os_version_hash (32 bytes), nonce (fresh 16 random bytes), and digital_signature (Ed25519 over all 14 preceding fields, 64 bytes). A Gateway MUST validate each Heartbeat through eight sequential checks: (1) nonce uniqueness; (2) timestamp freshness within 30 seconds; (3) policy version match; (4) IP consistency; (5) digital signature verification; (6) certificate fingerprint match; (7) counter monotonicity; (8) session token match. Failure count states: 0-2=HEALTHY; 3-4=WARNING; 5+=SLEEP with backoff delays of (2, 5, 10, 30, 60, 120, 300) seconds respectively. After 7 retries: FAILED. 11. Metadata Exchange Protocol Before transmitting any file bytes, the Client MUST send a MetadataPacket containing 19 signed fields: sender_peer_id, receiver_peer_id, session_id, file_uuid, filename, file_extension, file_size, file_hash (SHA-256), merkle_root, compression codec, encryption method, expected_chunk_count, chunk_size, security_policy_id, sender_cert_hash, receiver_cert_hash, timestamp, nonce, device_signature (Ed25519 over file_hash||session_id), network_signature (Ed25519 over sender_id||timestamp), and digital_signature (Ed25519 over all preceding fields). The Gateway MUST NOT issue ACK_TRANSFER_READY until all nine validation steps pass: (1) cert on file; (2) correct recipient; (3) digital signature; (4) policy ID authorized; (5) timestamp freshness; (6) nonce anti-replay; (7) network signature; (8) device signature; (9) redundant integrity gate. 12. Cryptographic Execution Manifest Every file transferred via ZTOP MUST be prepended with a 380-byte Cryptographic Execution Manifest (CEM). Offset Size Field ------ ---- ---------------------------------------- 0 8 Magic: 'ZTOP-CEM' (0x5A544F502D43454D) 8 16 File UUID (UUID v4 bytes) 24 32 File Hash (SHA-256 of raw file data) 56 32 Merkle Root (Merkle tree root hash) 88 8 Creation Timestamp (uint64, microseconds) 96 2 Version (uint16, currently 0x0001) 98 64 Sender Peer ID (null-padded UTF-8) 162 64 Receiver Peer ID (null-padded UTF-8) 226 32 Certificate Fingerprint (SHA-256 of cert) 258 16 Security Policy ID (null-padded UTF-8) 274 4 Execution Policy Flags (uint32 bitmask) 278 32 Allowed Receiver Hash (SHA-256(recvr_id)) 310 6 Reserved (zeros) 316 64 Digital Signature (Ed25519 over bytes 8-315) ------ ---- Total: 380 bytes Figure 7: CEM Wire Format Execution Policy Flags: 0x0001 ALLOW_EXEC File is permitted for execution. 0x0002 SANDBOX_ONLY Execution MUST be in a sandbox. 0x0004 NO_NETWORK Execution MUST NOT access network. 0x0008 NO_SUBPROCESS MUST NOT spawn child processes. 0x0010 IMMUTABLE MUST NOT be modified after delivery. 0x0020 AUDIT_ON_EXEC Gateway notified upon execution. 13. Chunk-Level Integrity: Merkle Trees Files are split into chunks of the negotiated chunk_size. A binary SHA-256 Merkle tree is constructed bottom-up. When the number of chunks is odd, the last leaf MUST be duplicated. Each TRANSFER_CHUNK packet MUST include: chunk_id, sequence number, byte offset, length, SHA-256 chunk_hash, session_id, per-chunk nonce (12 bytes), Merkle proof (sibling hashes bottom-up), and raw chunk data. A Gateway MUST immediately verify each chunk upon receipt: (1) SHA-256(received_data) equals chunk_hash; (2) the Merkle proof ascent from chunk_hash reaches the pre-agreed Merkle Root; (3) sequence number is greater than the last accepted; (4) nonce is not in the seen_nonces cache (TTL 300 seconds). PASS: send TRANSFER_ACK. FAIL: send TRANSFER_REJECT_CHUNK, apply risk delta of -15, and after MAX_CHUNK_RETRIES (3) terminate the transfer. 14. Pre-Execution Static Analysis After complete file reassembly and before issuing AUDIT_COMMIT, the Gateway MUST perform static behavioral analysis. The Gateway MUST NOT deliver the file to destination storage until this analysis completes. The analysis pipeline MUST include: (1) File type detection via magic bytes: 0x4D5A = PE, 0x7F454C46 = ELF, .py extension = Python. (2) Shannon entropy H = -sum(p(x)*log2(p(x))) over first 64 KB. H > 7.5 adds 20 risk points. H > 7.0 adds 10. (3) For PE files, scan for dangerous API imports: CreateProcess, VirtualAlloc, WriteProcessMemory, ReadProcessMemory, CreateRemoteThread, VirtualProtect, LoadLibraryA, ShellExecute, WinExec, NtQueueApcThread. Each match: +8 risk points, max 50. (4) For ELF files, scan for dangerous syscall strings: execve, ptrace, clone, mprotect, prctl, process_vm_writev. Each match: +6 risk points, max 40. (5) For Python, regex match dangerous imports (+5 each) and dangerous calls: eval(), exec(), os.system(), pickle.loads(), marshal.loads(). Each call match: +10 risk points, max 40. Final risk_score = min(sum, 100). risk_score >= 60: MALICIOUS. File buffer MUST be wiped and transfer MUST be aborted. risk_score >= 25: SUSPICIOUS. Logged and flagged. risk_score < 25: CLEAN. Proceed to Signature Chain. 15. 7-Level Signature Chain A transfer is marked SYNC_COMPLETE only when seven independent Ed25519 signatures are present and verified. An AUDIT_COMMIT MUST NOT be issued until all seven levels pass. Failure of any level MUST result in rejection. L1 - File Hash Signature (Sender key) message = b"L1|" || SHA-256(file_data) L2 - Chunk Tree Root Signature (Sender key) message = b"L2|" || merkle_root L3 - Metadata Signature (Sender key) message = b"L3|" || SHA-256(serialized_metadata) L4 - Sender Completion Assertion (Sender key) message = b"L4|" || SHA-256( b"SEND_COMPLETE|" || transfer_id || timestamp) L5 - Receiver Acceptance Assertion (Receiver key) message = b"L5|" || SHA-256( b"RECV_ACCEPT|" || transfer_id || timestamp) L6 - Session Digest (Session key) combined = L1.hash||L2.hash||L3.hash||L4.hash||L5.hash message = b"L6|" || SHA-256(combined) L7 - Gateway Completion Seal (Gateway key) message = b"L7|" || SHA-256( L6.combined_digest || b"|GATEWAY_SEAL") Figure 8: 7-Level Signature Chain Construction 16. Trust-Preserving Reconnection If a transport disconnection occurs during an active transfer, the Gateway MUST save the session state to a ReconnectCache keyed by Session ID. Cache entries MUST expire after 3600 seconds. The cache MUST store: peer_id, last device_signature, cert_hash, chunk_offset, chunks_done, total_chunks, trust_score, merkle_root, and cem_uuid. Upon reconnection with RECOVERY_MODE flag set, the Client presents its cached session_key_id. The Gateway issues a fresh Heartbeat challenge. If the challenge passes and a valid unexpired cache entry exists, the transfer resumes from the last verified chunk without repeating Phases 1-10. The retry backoff schedule MUST be [2, 5, 10, 30, 60, 120, 300] seconds. After 7 failed attempts, a full new handshake is REQUIRED. 17. Security Considerations ZTOP assumes the adversary has full network access including the ability to observe, inject, delay, and replay packets, but does NOT have access to TLS session keys or endpoints' Ed25519 private keys. Anti-Replay: All ZTOP frames include a 12-byte Nonce field. Receivers MUST maintain a nonce cache with a TTL of 300 seconds. Any frame whose nonce appears in the cache MUST be rejected. Receivers MUST also reject frames with a Timestamp deviation greater than 300 seconds from local time. Key Compromise: The 12-hour Session Certificate TTL limits the blast radius of key compromise. In the event of Org CA key compromise, the Gateway MUST immediately revoke all issued certificates and MUST NOT accept new sessions until new CA material is provisioned. Implementations SHOULD implement OCSP stapling [RFC6960]. Transport: ZTOP MUST operate within a TLS 1.3 tunnel [RFC8446]. Implementations MUST NOT support TLS versions earlier than 1.3. Quantum Resistance: The current specification uses Ed25519 [RFC8032] and ECDSA-P384. These algorithms are not resistant to quantum computing attacks. Future versions of this specification SHOULD incorporate NIST-standardized post-quantum algorithms [NIST.FIPS.204] [NIST.FIPS.203] as they become widely deployed. 18. IANA Considerations IANA is requested to assign the following port number: Service Name: ztop Port Number: 7890 Transport Protocol: TCP Description: Zero Trust Transfer Orchestration Protocol Reference: This document IANA is requested to create a new registry "ZTOP OpCodes" with the initial assignments from Section 4.4. New entries require Standards Action [RFC8126]. IANA is requested to create a new registry "ZTOP TLV Types" with range 0x0000-0x7FFF (Standards Action) and 0x8000-0xFFFF (First Come First Served). IANA is requested to register the custom X.509 OIDs listed in Section 7. Interim assignments under 1.3.6.1.4.1.99999 SHALL be replaced upon formal IANA assignment. 19. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . 20. Informative References [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", RFC 959, DOI 10.17487/RFC0959, October 1985, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [NIST.FIPS.203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS PUB 203, August 2024. [NIST.FIPS.204] NIST, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, August 2024. Authors' Addresses ZTOP Research Group Zero Trust Consortium India Email: sripadkarthik@gmail.com URI: https://github.com/sripad2020/ztop-research/