| # 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?** |
|
|
