Protocol Relationship Map
Secure Packet Transfer Integrity Stack v0.1
This branch is designed to sit around existing secure protocols as a systems-integrity and claim-boundary layer.
| Existing mechanism | Primary role | HIR/OAM relationship |
|---|---|---|
| TLS | Secure application transport | HIR/OAM reviews whether identity, payload fidelity, session integrity, and audit evidence survived the transfer boundary. |
| QUIC | Secure transport over UDP, often using TLS 1.3 semantics | HIR/OAM reviews transport degradation, session continuity, packet loss/retransmission pressure, and boundary claims. |
| WireGuard | VPN tunnel using modern cryptographic primitives | HIR/OAM reviews tunnel identity, endpoint boundary, route/session integrity, and audit-chain continuity. |
| IPsec | Network-layer secure communication | HIR/OAM reviews whether packet-transfer claims remain bounded to what was actually authenticated, encrypted, routed, and logged. |
| SSH | Secure remote shell / transfer channel | HIR/OAM reviews host identity, key state, session integrity, command/file transfer fidelity, and audit continuity. |
| Certificate authorities | Identity trust infrastructure | HIR/OAM treats stale, invalid, misissued, revoked, or unverified certificates as handshake and boundary pressure. |
| Cryptographic libraries | Implementation substrate | HIR/OAM does not replace cryptographic implementation; it governs claim boundaries, evidence logging, degradation flags, and review state. |
Summary
Existing protocols answer: How is the packet/session cryptographically protected?
HIR/OAM asks: Did the transfer preserve payload truth, route/session integrity, boundary conditions, authentication gates, and evidence continuity under pressure?