Network Working Group N. Ritz Internet-Draft Independent Intended status: Experimental 30 September 2025 Expires: 3 April 2026 Static Artifact Exchange (SAE) Protocol draft-ritz-sae-01 Abstract This document specifies the Static Artifact Exchange (SAE) protocol, an asynchronous transport pattern for exchanging cryptographic artifacts between two parties via a shared, stateless repository. SAE uses a "publish-then-poll," pull-only communication model where peers use the presence and size of immutable artifacts to coordinate a sequenced exchange. By enforcing a strict set of invariants, including a prohibition on parsing arbitrary content to drive the transport's state machine, SAE is designed to minimize common attack surfaces like injection and parser vulnerabilities. The pattern is transport-agnostic and is intended for use by higher-level cryptographic protocols, like Ephemeral Compute Attestation (ECA), that require a secure, minimal channel. 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 3 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Ritz Expires 3 April 2026 [Page 1] Internet-Draft SAE September 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Core Concepts . . . . . . . . . . . . . . . . 3 3. Protocol Requirements (Normative) . . . . . . . . . . . . . . 3 4. Protocol Mechanics . . . . . . . . . . . . . . . . . . . . . 4 4.1. Artifact Repository Structure . . . . . . . . . . . . . . 4 4.2. Phase Coordination . . . . . . . . . . . . . . . . . . . 4 4.3. Error Signaling . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Elimination of Processing Vulnerabilities . . . . . . . . 6 5.2. Prevention of Race Conditions . . . . . . . . . . . . . . 6 5.3. Resilience to Replay Attacks . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. SAE Error Codes Registry . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 7 Appendix A. HTTPS Profile (Normative) . . . . . . . . . . . . . 8 A.1. Example Exchange . . . . . . . . . . . . . . . . . . . . 8 Appendix B. Example Implementations (Informative) . . . . . . . 8 B.1. Generating an Error Signal (Bash) . . . . . . . . . . . . 8 B.2. Verifying an Error Signal (Bash) . . . . . . . . . . . . 9 Appendix C. Changes from -00 . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Many cryptographic protocols require a coordinated, multi-phase exchange of artifacts. Traditional request-response patterns often introduce security risks at the transport layer, including complex state management, parser vulnerabilities, and injection attacks. Ritz Expires 3 April 2026 [Page 2] Internet-Draft SAE September 2025 This document specifies the Static Artifact Exchange (SAE) protocol, an alternative model designed for security and simplicity. In SAE, parties do not communicate directly but interact asynchronously through a simple, stateless repository. One party publishes a set of immutable, pre-computed artifacts and then a status indicator to signal completion. The other party polls for this status indicator and, upon observing it, retrieves the artifacts. This "publish-then-poll" pattern, governed by a strict set of invariants, reduces the need for active listeners or dynamic request processing, limiting common attack surfaces. The security of the higher-level protocol relies on the cryptographic validity of the artifacts themselves, while the SAE transport provides a hardened, minimal-surface communication channel. SAE is intended as a reusable transport pattern for higher-level protocols, motivated by the requirements of Ephemeral Compute Attestation (ECA) [I-D.ritz-eca]. 2. Terminology and Core Concepts 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 An entity participating in the SAE protocol. Artifact An immutable blob of data published by a peer. Status Indicator A signal indicating the completion of a phase. A zero-byte artifact indicates success, while a non-zero-byte artifact contains an authenticated and encrypted error signal. Repository A durable, addressable, and immutable store for artifacts. Exchange Identifier A unique identifier for a specific exchange instance, used to construct artifact paths. 3. Protocol Requirements (Normative) SAE implementations MUST satisfy the following invariants: 1. *Static Artifact Model*: All communication MUST conform to a strict artifact exchange model where both peers operate as passive repositories of pre-computed, immutable artifacts. 2. *Pull-Only Communication*: Peers MUST NOT push data. All artifact retrieval MUST be initiated by the consuming peer through polling. Ritz Expires 3 April 2026 [Page 3] Internet-Draft SAE September 2025 3. *Phased Atomic Progression*: All artifacts for a phase MUST be published before its corresponding status indicator is published. 4. *Immutability*: Once a status indicator for a phase is published, all associated artifacts for that phase MUST NOT be changed or removed. 5. *Prohibited Processing (Transport Layer)*: The SAE transport- level state machine MUST be driven solely by the presence and size of artifacts. A non-zero size for a status indicator MUST be treated by the SAE layer as a terminal failure, ending the exchange. This invariant prevents the SAE layer from parsing arbitrary or variable-length content to determine its outcome. This rule does *not* prohibit the higher-level application protocol (e.g., ECA) from performing its own content-based validation, such as verifying a digital signature, as part of its own application-level logic after retrieving an artifact. 6. *Bounded Polling*: Polling for status indicators MUST use exponential backoff. 7. *Transport Simplicity*: The protocol logic MUST remain independent of transport-level features beyond basic artifact retrieval (e.g., HTTP GET/HEAD) and presence signaling (e.g., HTTP 200/404). 8. *Repository Consistency*: Any repository used to host artifacts MUST provide strong read-after-write consistency. 9. *Resilient Artifact Retrieval*: The peer's retrieval logic MUST be resilient to transient transport- or storage-layer delays. 4. Protocol Mechanics 4.1. Artifact Repository Structure Each peer MUST organize its repository using a consistent path structure based on the Exchange Identifier. *Recommended Structure*: // //.status 4.2. Phase Coordination The protocol progresses using a "publish-then-poll" pattern: Ritz Expires 3 April 2026 [Page 4] Internet-Draft SAE September 2025 1. *Publication*: A peer publishes all required artifacts for the current phase. 2. *Signaling*: After publication, the peer publishes the status indicator. * *Success*: The status indicator MUST be a zero-byte artifact. * *Failure*: The status indicator MUST be a non-zero-byte artifact containing an authenticated and encrypted error signal as defined in § 4.4 (#sec-error-signaling). 3. *Polling*: The counterpart peer polls for the status indicator. 4. *Retrieval and Interpretation*: Upon detecting the status indicator: * If the size is zero, the phase was successful; proceed to retrieve phase artifacts. * If the size is greater than zero, the SAE exchange has failed and MUST be terminated. Diagnosing the specific error by decrypting the artifact's content is an OPTIONAL step for the higher-level application. 4.3. Error Signaling When a peer encounters an error, it MUST publish a status indicator containing a fixed-length, authenticated ciphertext. This is generated by first hashing the canonical error string and then encrypting that hash using an AEAD scheme. * *Key (K)*: A secret key derived from a value shared between the peers out-of-band or established by the higher-layer protocol for this specific exchange_id. * *Plaintext*: The raw binary output of SHA- 256(canonical_error_string). * *AEAD*: An AEAD scheme such as AES-256-GCM is RECOMMENDED, with a fixed, zero-byte AAD and a randomly generated 12-byte nonce prepended to the ciphertext. This method conceals the error from passive observers and provides integrity, while allowing the recipient to perform an efficient O(1) lookup by hashing known error strings and comparing them to the decrypted hash. 5. Security Considerations Ritz Expires 3 April 2026 [Page 5] Internet-Draft SAE September 2025 5.1. Elimination of Processing Vulnerabilities The security benefits of SAE are not inherent to the static artifact model itself, but are a direct result of the strict invariants placed upon it. Specifically, the *Prohibited Processing (Transport Layer)* invariant, which forbids the SAE state machine from parsing content to determine its outcome, is what eliminates common attack vectors like parser vulnerabilities and injection flaws at the transport level. 5.2. Prevention of Race Conditions The atomic "publish-then-signal" model prevents Time-of-Check-to- Time- of-Use (TOCTOU) vulnerabilities. 5.3. Resilience to Replay Attacks Replay protection across exchanges MUST be provided by the higher- layer protocol (e.g., ECA’s accept-once semantics for eca_uuid). 6. IANA Considerations 6.1. SAE Error Codes Registry IANA is requested to establish a registry for SAE Error Codes. This registry defines the error code identifier and the canonical string that MUST be used as the input to the SHA-256 hash function when generating an error signal. +=================+===========================+ | Code | Canonical Content (UTF-8) | +=================+===========================+ | BAD_REQUEST | BAD_REQUEST | +-----------------+---------------------------+ | UNAUTHORIZED | UNAUTHORIZED | +-----------------+---------------------------+ | FORBIDDEN | FORBIDDEN | +-----------------+---------------------------+ | CONFLICT | CONFLICT | +-----------------+---------------------------+ | GATEWAY_TIMEOUT | GATEWAY_TIMEOUT | +-----------------+---------------------------+ Table 1 7. Normative References [I-D.ritz-eca] Ritz, N., "Ephemeral Compute Attestation (ECA) Ritz Expires 3 April 2026 [Page 6] Internet-Draft SAE September 2025 Protocol", Work in Progress, draf-ritz-eca-00, 16 September 2025. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, https://www.rfc-editor.org/info/ rfc6234 (https://www.rfc-editor.org/info/rfc6234). [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018. [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022. 8. Acknowledgements The author wishes to thank Eric Rescorla for his thorough review of the initial draft. His expert feedback led to significant improvements in the protocol's security claims, the clarification of a key normative invariant, and a more robust and efficient error signaling mechanism. 9. Informative References [I-D.ritz-eca] Ritz, N., "Ephemeral Compute Attestation (ECA) Protocol", Work in Progress, Internet-Draft, draft-ritz-eca-00, 28 September 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [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, . Ritz Expires 3 April 2026 [Page 7] Internet-Draft SAE September 2025 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . Appendix A. HTTPS Profile (Normative) This section provides a normative example of how the abstract SAE protocol can be implemented using standard HTTPS. A.1. Example Exchange *Error example:* If B encounters a timeout, it publishes an authenticated and encrypted error signal. # B derives the AEAD key (K) and a nonce # B computes the plaintext: HASH = SHA-256("GATEWAY_TIMEOUT") # B encrypts the hash: C = AEAD.Seal(K, nonce, HASH, nil) # B constructs the payload: nonce || C B: PUT /exchange-12345/response.status (content: ) A: HEAD /exchange-12345/response.status (polling until 200 OK) A: Observes Content-Length > 0 // Exchange is dead A: GET /exchange-12345/response.status (reads payload) // OPTIONAL A: Parses nonce and ciphertext from payload A: Decrypts hash: HASH' = AEAD.Open(K, nonce, C, nil) A: Looks up HASH' in a precomputed map of known error hashes A: Finds match for SHA-256("GATEWAY_TIMEOUT") -> aborts exchange Appendix B. Example Implementations (Informative) B.1. Generating an Error Signal (Bash) Ritz Expires 3 April 2026 [Page 8] Internet-Draft SAE September 2025 #!/bin/bash ERROR_CODE="GATEWAY_TIMEOUT" AEAD_KEY_HEX="deadbeef..." # 32-byte key, securely provided NONCE_HEX=$(openssl rand -hex 12) # Compute the hash of the error string ERROR_HASH=$(printf "%s" "$ERROR_CODE" | sha256sum | awk '{print $1}') # Encrypt the hash using AES-256-GCM and get ciphertext + tag # Note: This is a simplified example. Real implementations should # handle outputs carefully. ENCRYPTED_OUTPUT=$(echo -n "$ERROR_HASH" | openssl enc -aes-256-gcm \ -K "$AEAD_KEY_HEX" -iv "$NONCE_HEX" -A "" | xxd -p -c 256) CIPHERTEXT=${ENCRYPTED_OUTPUT::-32} TAG=${ENCRYPTED_OUTPUT: -32} # The final payload is nonce || ciphertext || tag printf "%s%s%s" "$NONCE_HEX" "$CIPHERTEXT" "$TAG" > error.status B.2. Verifying an Error Signal (Bash) #!/bin/bash RECEIVED_PAYLOAD=$(cat error.status | xxd -p -c 256) AEAD_KEY_HEX="deadbeef..." # 32-byte key, securely provided # Parse the payload NONCE_HEX=${RECEIVED_PAYLOAD:0:24} CIPHERTEXT_HEX=${RECEIVED_PAYLOAD:24:-32} TAG_HEX=${RECEIVED_PAYLOAD: -32} # Attempt to decrypt DECRYPTED_HASH=$(printf "%s" "$CIPHERTEXT_HEX" | xxd -r -p | openssl enc -d -aes-256-gcm -K "$AEAD_KEY_HEX" -iv "$NONCE_HEX" -A "" -T "$TAG_HEX") # Precompute known error hashes declare -A KNOWN_ERROR_HASHES KNOWN_ERROR_HASHES[$(printf "%s" "GATEWAY_TIMEOUT" | sha256sum | awk '{print $1}')]="GATEWAY_TIMEOUT" # ... add other known errors ... # Check if the decrypted hash is a known error if [[ -v KNOWN_ERROR_HASHES[$DECRYPTED_HASH] ]]; then echo "VERIFIED: The error code is '${KNOWN_ERROR_HASHES[$DECRYPTED_HASH]}'." else echo "UNKNOWN_ERROR or AUTHENTICATION_FAILURE." fi Appendix C. Changes from -00 Ritz Expires 3 April 2026 [Page 9] Internet-Draft SAE September 2025 * Refined the security claims in the Security Considerations section to more precisely attribute the protocol's security benefits to its strict invariants rather than the static artifact model itself. * Clarified the normative language for the "Prohibited Processing" invariant to resolve an ambiguity. The rule now explicitly applies to the SAE transport-level state machine and does not prohibit content validation by the higher-level application protocol. * Replaced the HMAC-based error signaling mechanism with a more efficient AEAD-based design, based on feedback from Eric Rescorla. This improves performance and conceals the error type from passive observers. * General editorial and language improvements for clarity. Author's Address Nathanael Ritz Independent Email: nathanritz@gmail.com Ritz Expires 3 April 2026 [Page 10]