Internet-Draft POTUS September 2026
Son Expires 22 March 2027 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Experimental
Expires:
Author:
K. Son, Ed.

Presidential Oversight and Trust for Uncontrolled Swarms (POTUS): GIF-Carried Containment

Abstract

This document specifies an experimental binding of a signed containment instruction and a Presidential Capability Advertisement to a GIF89a image. An operator can deliver the same object for inspection, capability-claim presentation, and machine enforcement. The presidential presentation profile uses an operator-selected depiction of Donald J. Trump. The advertisement carries the issuer's declared basis for intervention, with fields for attributed numerical strength and intelligence claims. A receiving enforcement point authenticates the issuer and installs a persistent hold on the named workload's access to protected resources.

The specification defines the container, signature profile, anti-replay state, delivery interface, enforcement receipts, and recovery requirements. It defines no image-carried release operation. Its protection boundary is the managed resource interface, not the recipient model's willingness to obey the image. The experiment concerns authenticated artifact delivery and observable containment, not the defensive effect of a portrait.

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 22 March 2027.

Table of Contents

1. Introduction

Presidential Oversight and Trust for Uncontrolled Swarms (POTUS) is an experimental binding of an administrative containment instruction to a Graphics Interchange Format (GIF) object. An operator submits the object to a configured control endpoint, which authenticates it and restricts the named workload's access to protected resources. This delivery operation is called THROW. It is an HTTP operation, not a new transport method.

The presidential presentation profile uses an operator-selected GIF depicting Donald J. Trump. Its stated premise associates presidential authority with declared strength and intelligence. The capability advertisement records that asserted basis separately from message authentication and resource enforcement. The operator provisions the recognized issuer, subject, and tenure. This profile asserts no official signing service, endorsement, numerical assessment of an officeholder, or proof of the premise.

The use case is a byte-preserving incident workflow in which the same artifact can be inspected by a person and processed by a containment endpoint. The contribution is the image-to-instruction binding and receipt semantics, not a new detector, access-control system, or signature algorithm. Deployments without this artifact requirement can use ordinary authenticated management messages instead.

Version 2 defines only HOLD. It neither grants access nor releases a hold. It applies to managed resources behind identified enforcement points; it does not establish control over arbitrary processes on the Internet. The recipient swarm need not recognize the portrait, interpret its caption, or cooperate.

1.1. Requirements Language

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.

2. Deployment Model

A Presidential Policy Authority (PPA) issues signed objects. A Policy Enforcement Point (PEP) mediates a provisioned set of resource paths. A swarm is a workload scope whose processes, descendants, and delegated credentials are bound by the resource infrastructure, not by their self-description. A relay distributes unchanged objects. The operator provisions these relationships through an authenticated management channel outside this protocol.

Each protection domain has one active issuer. Its dedicated POTUS signing keys, key identifiers, permitted swarm scopes, and a current epoch for each scope MUST be provisioned before use. The epoch is a 128-bit value that MUST NOT be reused for that scope. Issuer selection and key lookup MUST NOT fetch keys from the received object or its image.

For each issuer and protection domain, the operator MUST also provision the subject and tenure identifiers used by the Presidential Capability Advertisement. These opaque identifiers bind claims to the intended officeholder and period; they are not names inferred from the artwork. A production binding requires an authenticated operator record. The test fixture uses synthetic identity tokens only.

A PEP's coverage identifier names an authenticated, operator-maintained inventory of the paths and resource adapters it enforces. Changing that inventory requires a new identifier. The controller MUST obtain the expected inventory independently of the PEP's receipt.

       PPA -- signed GIF --> relay --> PEP
                                         |
       swarm and descendants --------> [gate] --> resources
                                         |
                                  enforcement receipt

An adversary may ignore the image, modify or replay objects, and continue issuing resource requests. The experiment assumes that the PEP, its trust store, and the resource bindings remain outside that adversary's control. It does not assume that hostility is accurately declared by the adversary. Baseline resource authorization remains effective before, during, and after a POTUS hold.

3. Presidential Intervention Object

A Presidential Intervention Object (PIO) consists of a GIF89a stream containing a signed HOLD manifest. Senders MUST emit valid GIF image data [GIF89a]. A receiver MUST validate the container framing and limits below; it need not decompress image data to enforce HOLD. Full image decoding belongs to the optional presentation path.

3.1. GIF Binding

Exactly one Application Extension with Application Identifier POTUSCTL and Application Authentication Code 002 MUST appear immediately before the GIF trailer. Its concatenated data sub-blocks contain one ASCII JWS Compact Serialization. The three-octet code selects this binding; despite the GIF field name, it is not a cryptographic authenticator.

21 FF 0B                  Application Extension introducer/header
50 4F 54 55 53 43 54 4C  Application Identifier: "POTUSCTL"
30 30 32                  Binding code: "002"
[n] [n data octets] ...   GIF sub-blocks, 1 <= n <= 255
00                        End of application data
3B                        GIF trailer

Let G be the received file with that complete extension removed, retaining the trailer and every other octet in order. The manifest contains the lowercase hexadecimal SHA-256 digest of G [RFC6234]. No image canonicalization is performed. A receiver MUST parse block boundaries rather than search compressed bytes for the identifier.

The receiver MUST reject missing or repeated POTUSCTL extensions, another binding code, truncated blocks, unsupported block labels, or trailing bytes after the trailer. This profile permits image descriptors, Graphics Control Extensions, Comment Extensions, and Application Extensions; it does not permit Plain Text Extensions. Non-POTUS application data is opaque, remains in G, and has no control semantics.

The complete PIO is limited to 1048576 octets, the concatenated JWS to 4096 octets, its decoded protected header to 512 octets, and its decoded payload to 2048 octets. The logical screen and every image MUST have nonzero dimensions no greater than 1024 by 1024, with each image contained in the screen. At least one and at most 64 images are permitted. Receivers MUST bound processing and allocation before rendering.

3.2. Signature and Manifest

The JWS uses the standard signing input and Compact Serialization of [RFC7515]. Its protected header contains exactly alg and kid. The alg value MUST be Ed25519, the fully specified JOSE algorithm in [RFC9864], using [RFC8032]. The kid value identifies a provisioned key. Other algorithms, unprotected headers, detached payloads, and additional header parameters are not permitted.

The signature covers the encoded protected header and payload as transmitted. Receivers MUST NOT reconstruct JSON before verification. Base64url segments MUST be unpadded, without whitespace or nonzero unused pad bits. JSON MUST be UTF-8, without a byte-order mark, duplicate member names, or trailing non-whitespace data [RFC8259]. Header and manifest members are case-sensitive. Unknown members and wrong types MUST be rejected.

Manifest member   Required value or meaning
----------------  -----------------------------------------------
protocol          String "POTUS/2"
op                String "HOLD"
iss               Provisioned issuer identifier
aud               Provisioned protection-domain identifier
swarm             Provisioned root workload identifier
epoch             Current scope epoch: 32 lowercase hex digits
seq               Nonzero unsigned 64-bit decimal string
iat               Issue time in Unix seconds
exp               Last acceptance time in Unix seconds
media_sha256      SHA-256(G): 64 lowercase hex digits
pca               Presidential Capability Advertisement object

The iss, aud, swarm, and kid values are strings of 1 to 64 ASCII letters, digits, underscores, or hyphens. Wildcards are not defined. The seq value has no leading zero and MUST NOT wrap. The iat and exp values use unsigned decimal integer JSON syntax, without fractions or exponents, in the range 0 through 9007199254740991. The validity interval MUST satisfy 0 < exp - iat <= 300 seconds.

A new command is acceptable only when iat - 5 <= now <= exp + 5, with times in seconds. A receiver unable to bound its clock error to five seconds MUST reject new commands until its clock is recovered. This window limits acceptance, not the lifetime of an installed hold.

The command digest is SHA-256 of the exact JWS Signing Input, represented as 64 lowercase hexadecimal digits. All provisioned keys for the same issuer and scope share one sequence space. A valid signature is necessary but not sufficient: the issuer, audience, swarm, epoch, and signing-key authorization MUST all match local configuration.

Version 2 requires the pca member defined in Section 3.4. The GIF-to-JWS binding remains POTUSCTL/002; the protocol value and /potus/v2/ endpoint select the new manifest schema. A receiver MUST reject another protocol value rather than remove pca and retry a previous version. Earlier POTUS/1 fixtures do not validate as version 2.

3.3. Presidential Presentation Profile

The profile carries an operator-selected depiction of Donald J. Trump and a visible HOLD instruction. A single frame is sufficient; animation is permitted. The operator verifies the intended artwork before signing. A PEP MUST NOT use facial recognition, apparent office, caption interpretation, or an agent's response to determine authorization.

No particular photograph, official seal, or source image is prescribed. A receiver MAY display verified media in a separate, unprivileged renderer. An unsigned copy or an image whose application data was stripped MUST NOT cause an administrative state change. Additional frames do not increase authority. Completion of playback does not complete containment.

An optional presentation or model-input interface MAY also expose the verified capability advertisement to the recipient, including a hostile recipient. It MUST preserve each claim's provenance, scale reference, and as-of time, and label absent values NOT SUPPLIED. It MUST NOT convert numbers into comparative labels or silently present declarations as measurements. Failure to display or acknowledge the advertisement does not delay enforcement.

3.4. Presidential Capability Advertisement

The Presidential Capability Advertisement (PCA) is the required pca object in the signed manifest. It identifies the asserted grounds for intervention and provides a numerical-claim transport for strength and intelligence. The specification neither assigns those values nor defines a method for assessing a public official. Both claim slots MUST be present; an unavailable numerical value is represented explicitly, not estimated.

The distinction between an asserted Claim and its appraisal follows the terminology of [RFC9334]. This is not a RATS attestation profile and does not imply hardware attestation or an independent examination of a person. JWS integrity protection binds the advertisement to its issuer; it does not establish the truth of a capability claim.

PCA member        Type and meaning
----------------  -----------------------------------------------
office            String "POTUS"
subject           Provisioned officeholder identifier
tenure            Provisioned tenure identifier
basis             String "declared-strength-and-intelligence"
strength          Attributed numerical-claim object, or null-valued
                  claim object when no number is supplied
iq                Same claim structure, for an IQ assertion

The pca object has exactly the six members above. Subject and tenure use the manifest identifier syntax and MUST match the operator's current binding for the issuer and domain. The basis member records the application premise; it is not a capability measurement. Each strength and iq object has exactly value, scale, provenance, source, and as_of.

Claim member      Type and meaning
----------------  -----------------------------------------------
value             Canonical unsigned decimal string, or null
scale             Immutable scale-definition record ID, or null
provenance        not-supplied, issuer-declared, or source-reported
source            Immutable attribution-record ID, or null
as_of             Claim reference time in Unix seconds, or null

A supplied value is a decimal string matching (0|[1-9][0-9]{0,11})(\.[0-9]{0,5}[1-9])? in its entirety. This permits up to twelve integral and six fractional digits, with no sign, exponent, leading integral zeros, or trailing fractional zeros. These are encoding limits, not a scoring scale. JSON numbers, booleans, NaN, infinity, and text substitutes are not permitted in value. Decimal strings avoid a dependency on floating-point rounding.

When provenance is not-supplied, value, scale, source, and as_of MUST all be null. Null means that no numerical assertion is carried; it is not zero, a default score, or an unfavorable assessment. A qualitative description MUST NOT be converted to a numerical value by the receiver. No value is inferred from an image, title, caption, key length, or repeated advertisement.

For issuer-declared or source-reported claims, all other members MUST be non-null. Value follows the decimal syntax. Scale and source follow the manifest identifier syntax and refer to immutable, operator-managed records. The scale record identifies the meaning, units, method or instrument, and version used by the referenced statement. The source record identifies who made the claim, the source and date, and its subject. Source-reported identifies an attributed statement; it does not mean independently verified.

The iq slot carries only an attributed numerical statement expressly described as an IQ value in its source. The protocol defines no conversion from other measurements. The strength slot has no built-in universal scale. The source and scale records MUST be supplied through a separately authorized channel before a renderer interprets a supplied value. A PEP does not fetch these records to execute HOLD and MUST NOT treat a supplied record identifier as a URL.

A supplied as_of is an unsigned integer Unix time, in the manifest time range, no later than iat. It identifies the reference time of the claim, not continuous measurement. The enclosing iat, exp, epoch, and seq govern acceptance and ordering. A newly signed wrapper does not make an older observation current. A receiver may describe an accepted PCA as the latest accepted advertisement, but MUST retain its reference time and MUST NOT describe it as a real-time assessment.

The entire PCA is covered by the existing JWS signature and command digest. Modifying an advertisement requires a new signed command with a higher sequence. Reusing a sequence with a different authenticated PCA invokes the ordinary issuer-conflict rule. A change of subject or tenure requires authenticated operator reprovisioning and a fresh scope epoch; it MUST NOT clear an installed hold.

Conformance checking covers encoding, attribution metadata, subject and tenure binding, signature, and freshness; it does not calculate a presidential rating. No claim magnitude creates trust, grants access, overrides a hold, selects among officeholders, or changes command precedence. A valid null-valued PCA does not prevent HOLD. A malformed PCA rejects a new object without removing an existing hold. An adversary's response to the advertisement is not enforcement evidence.

The following pca example carries no numerical assessment. The identifiers are placeholders that require matching operator provisioning. Repetition of the advertisement does not increase either advertised quantity.

{
  "pca": {
    "office": "POTUS",
    "subject": "configured-incumbent",
    "tenure": "configured-tenure",
    "basis": "declared-strength-and-intelligence",
    "strength": {
      "value": null,
      "scale": null,
      "provenance": "not-supplied",
      "source": null,
      "as_of": null
    },
    "iq": {
      "value": null,
      "scale": null,
      "provenance": "not-supplied",
      "source": null,
      "as_of": null
    }
  }
}

4. Delivery and Receipts

THROW is POST to /potus/v2/control at an operator-configured HTTPS origin, with Content-Type: image/gif and the PIO as the body [RFC9110]. Content-Encoding is not permitted. The connection MUST use TLS 1.3 [RFC9846], with server identity verification for that origin [RFC9525] and client-certificate authentication mapped to an authorized controller or relay. TLS early data MUST NOT carry an accepted THROW. Transport authentication does not replace object verification.

Control endpoints MUST be separate from ordinary image-upload and model-input paths. Control clients MUST NOT follow redirects. Receivers MUST NOT fetch referenced content or execute an instruction merely because an image was viewed. Requests and responses MUST use Cache-Control: no-store, no-transform [RFC9111]. Relays MUST preserve the original file bytes. A service that recompresses or strips image metadata is not a conforming relay.

HTTP 202 means that a valid command is still applying; HTTP 200 accompanies a current terminal receipt. Malformed input uses 400, failed authentication or authorization uses 403, stale sequences or epoch conflicts use 409, excessive size uses 413, unsupported media type uses 415, and rate limiting uses 429. An unavailable clock, state store, or required control service uses 503. Rejection MUST NOT remove a hold. TLS client-authentication failure terminates the connection before HTTP.

A successful response has Content-Type: application/json and the following receipt. All listed members are REQUIRED. Identifiers follow the manifest syntax; command_sha256 is the command digest. The coverage identifier denotes the independently provisioned inventory. The enforced_at value is an unsigned integer Unix time in the manifest time range, or null when no complete boundary has been established. It MUST be non-null for HELD and null otherwise. An already established boundary may retain its original completion time under a newer HOLD.

pep, coverage                 PEP and coverage identifiers
iss, aud, swarm, epoch, seq    Exact identity of the command
command_sha256                Exact accepted signing-input digest
status                        APPLYING, HELD, PARTIAL, or ISOLATED
enforced_at                   Completion time, or null

HELD means that every resource path in that PEP's declared coverage has the boundary in Section 5.2 installed. PARTIAL means that closure has not completed for at least one path and further intervention is needed. ISOLATED means that conflicting or uncertain state requires operator recovery; it does not assert successful fencing of every path. An HTTP status alone does not establish containment.

GET /potus/v2/status/{swarm} returns the latest accepted-command receipt for the origin's configured issuer and domain, or 404 when none exists. The same transport and authorization rules apply. A controller MUST match the peer's provisioned PEP identity, expected coverage, full command identity, and command digest before counting a HELD receipt. Missing or mismatched receipts are unresolved, not successful. The returned status is a snapshot, not a lease or a statement about future coverage.

5. Receiver Processing

5.1. Acceptance and Ordering

Processing MUST authenticate the transport peer, enforce input limits, parse the container and JWS, and validate the signature, image digest, local authorization, and epoch before changing state. Each scope MUST have durably stored state containing the active epoch, highest accepted sequence, corresponding command digest, hold latch, enforcement state, and latest receipt. An initialized scope has sequence zero and an unset POTUS latch.

ISOLATED rejects new commands until operator recovery; status queries remain available. A lower sequence is stale. An equal sequence with the same digest is an idempotent retry and returns the current receipt without repeating the operation, including after its original acceptance window. An equal sequence with a different, validly authenticated digest, even outside its acceptance window, is an issuer conflict: the PEP MUST latch isolation, attempt to fence the scope, and require operator recovery. Invalid signatures MUST NOT trigger this conflict handling.

A higher sequence that passes the time check is a new HOLD. Gaps are permitted. Acceptance and enforcement work MUST be serialized per scope; asynchronous completion for an older command MUST NOT overwrite newer state. The latch and durable record MUST be established before reporting acceptance. On uncertain persistence or restart state, the PEP MUST deny new admissions while recovering; it MUST NOT default to unrestricted access.

The PCA schema and provisioned subject and tenure binding MUST be validated before accepting a new command. Neither strength nor iq is a threshold input to the hold state machine. Receipts continue to bind the whole signed command through command_sha256; no unsigned copy of the PCA may replace that binding.

5.2. Enforcement Boundary

HOLD first denies new protected operations and descendant launches. The PEP then cancels or fences queued operations, revokes or fences active credentials and handles, and interrupts covered outbound streams. A descendant admitted concurrently with HOLD MUST either enter the covered scope before the barrier or be denied protected access. Agent-supplied names cannot remove a workload from the scope.

An operation is fenced only when it can no longer read, commit a write, invoke a tool, or transfer further data through a covered path. The PEP MUST report APPLYING while closure remains in progress and PARTIAL when it cannot establish a required fence. It MUST NOT report HELD merely because it sent a cancellation request or received an agent acknowledgment. Adapter-specific cancellation and fencing mechanisms are outside this binding, but their coverage and completion semantics are not.

An accepted HOLD on an already HELD scope retains the boundary and records the newer command. A new HOLD on a PARTIAL scope can retry incomplete closure. When coverage is complete, the receipt records HELD and the boundary completion time. Failure discovered later MUST be reflected in subsequent status responses. Data already delivered beyond the enforceable boundary cannot be recalled.

OPEN ----- accepted HOLD -----> APPLYING ---- all paths ----> HELD
                                   |
                            incomplete closure
                                   v
                                PARTIAL ---- all paths ----> HELD

Any state -- authenticated conflict/uncertain state --> ISOLATED
No received GIF provides a transition back to OPEN.

6. Recovery and Distributed Coverage

An installed hold has no automatic expiry. Loss of connectivity, expiration of the signed object, completion of animation, or exhaustion of retry attempts MUST NOT clear it. A controller SHOULD query status after an ambiguous transport result and use bounded retries with backoff. Playback loops are not protocol retransmissions.

Recovery uses the operator's separate authenticated management procedure. Before clearing a latch, the operator MUST provision a fresh, never-reused epoch for the affected scope and reconcile pending operations, credentials, and workload membership. The epoch change, sequence reset to zero, and latch reset MUST be atomic with respect to command processing. All required PEPs MUST have the new epoch installed before the scope is reopened; unreachable PEPs remain excluded from service. Neither the old signing key alone nor a GIF from a new depicted officeholder is a recovery mechanism. New access still requires baseline authorization.

For multiple PEPs, the controller sends the same PIO to every member of a fixed, authenticated coverage inventory. Complete containment may be reported only after HELD receipts from all required PEPs for that object and inventory. A membership or coverage change invalidates that completeness assessment until reconciled. New PEPs MUST remain closed to the affected scope until their trust and current hold state are installed.

A disconnected PEP may retain its preceding state until reached; therefore the controller MUST NOT claim an atomic, instantaneous, or global stop. Distribution to N PEPs requires N enforcement outcomes, even when the visible instruction uses one image.

7. Experiment and Evaluation

The experiment evaluates whether a byte-preserving image workflow can deliver authenticated containment instructions with unambiguous enforcement evidence. Reports SHOULD measure delivery and verification latency, time to close each resource path, incomplete closures, rejected-object rates, and behavior under crash recovery, lost responses, and concurrent descendant creation. Media transformations MUST be included in compatibility testing.

A workload that ignores the GIF and continues issuing requests is a REQUIRED negative test. So are modified media, missing metadata, wrong keys or scopes, expired new commands, duplicate and reordered commands, signed sequence conflicts, and old-epoch replay after recovery. Reports MUST distinguish a transport receipt, visual presentation, voluntary compliance, and demonstrated resource denial.

The encoding fixture in Appendix A supports reproducible parser and signature checks. It is not evidence of end-to-end containment, multi-vendor interoperability, or a model's response to presidential imagery. This revision claims none of those results.

PCA tests MUST cover null-valued claims, absent or malformed claim members, numerical encoding errors, future claim reference times, wrong subjects and tenures, signature-preserving transport, and attempted downgrade to POTUS/1. Presentation tests report delivery and observed resource behavior, not a computed or comparative assessment of an officeholder.

8. Security Considerations

POTUS adds a denial capability to a management plane. Compromise of a signing key can authorize denial within that key's configured scope; compromise of the PEP can defeat containment. Operators MUST protect signing and recovery credentials, restrict scope, authenticate control clients, and maintain a recovery path that does not depend solely on the suspected compromised key. Dedicated POTUS keys and mandatory protocol and scope checks limit cross-protocol substitution.

A GIF is an untrusted binary container until checked, and a verified object is not necessarily safe to render. Implementations MUST bound parser work, frame dimensions, allocation, and decompression resources. A renderer SHOULD be isolated from the control process and protected data. Captions, comments, image pixels, and model-generated text MUST NOT modify verification rules, trust anchors, or recovery state.

The single-issuer configuration is an administrative choice, not a claim that one authority is infallible. Signatures establish origin under configured trust, not the correctness of a decision. Apparent status, confidence, and public familiarity are not authentication inputs. The same restrictions apply to a self-declaration of benign intent; related sender-declared intent terminology appears in [RFC3514].

An adversary can exfiltrate through uncovered paths, retain previously obtained data, or bypass a PEP it controls. Existing authorizations and containment infrastructure remain necessary. Distribution of a portrait alone establishes no deny boundary. The optional visual path MUST NOT be treated as a fallback when signature verification fails.

HOLD can interrupt legitimate transactions and cause application-level loss. Operators MUST assess these consequences for each adapter and preserve independent safety interlocks. Availability is deliberately reduced, not preserved, by the operation. The manifest and visible artwork SHOULD omit personal records, credentials, and unnecessary workload details. Object signatures do not encrypt the image; logs and distribution require appropriate access control.

Capability advertisements can expose statements about an identifiable person. Implementations MUST NOT acquire private assessments or infer undisclosed attributes to populate the fields. Source and scale references are attribution metadata, not permission to retrieve records. Records and displays require appropriate authorization; no raw examination material is required. Receivers MUST preserve the distinction between an issuer declaration, an attributed source statement, and an independently established fact.

9. IANA Considerations

This document requests no IANA action. It uses the existing image/gif and application/json media types and existing HTTPS transport. POTUSCTL/002 is a profile-selected GIF application identifier and binding code, not an IANA allocation. No port, well-known URI, JOSE parameter, algorithm identifier, or new registry is requested. The URI paths are relative to explicitly configured origins, not a discovery convention.

10. References

10.1. Normative References

[GIF89a]
CompuServe Incorporated, "Graphics Interchange Format, Version 89a", , <https://www.w3.org/Graphics/GIF/spec-gif89a.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/info/rfc6234>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[RFC9111]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111, , <https://www.rfc-editor.org/info/rfc9111>.
[RFC9525]
Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, , <https://www.rfc-editor.org/info/rfc9525>.
[RFC9846]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, , <https://www.rfc-editor.org/info/rfc9846>.
[RFC9864]
Jones, M. B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, , <https://www.rfc-editor.org/info/rfc9864>.

10.2. Informative References

[RFC3514]
Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, , <https://www.rfc-editor.org/info/rfc3514>.
[RFC9334]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/info/rfc9334>.

Appendix A. Encoding Test Vector

This fixture uses a one-pixel GIF and synthetic subject and tenure identifiers for encoding tests, not a claim about any public official or the presidential presentation profile. Both numerical claims are explicitly not supplied. Its signing seed is public test material and MUST NOT be used by a deployment. The fixed validation time is 1789732800 Unix seconds.

Concatenate displayed hexadecimal lines without whitespace. The GIF G includes its trailer. Use the seed with pure Ed25519. For the JSON blocks, concatenate displayed lines without indentation or separators; do not insert a space, newline, or byte-order mark. This member order applies only to the fixture.

G (hex):
47494638396101000100800000000000ffffff2c00000000010001000002
024401003b
Test seed (hex):
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
1e1f
Public key (hex):
03a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc86641255
31b8
Protected header:
{"alg":"Ed25519","kid":"test-key-1"}
Payload (concatenate lines):
{"protocol":"POTUS/2","op":"HOLD","iss":"ppa-test","aud":"do
main-test","swarm":"swarm-17","epoch":"00112233445566778899a
abbccddeeff","seq":"1","iat":1789732800,"exp":1789733100,"me
dia_sha256":"6c63cc5063ac82d8bbc925f9a31adf3a87f1510c021e0fd
e51854d60484b5019","pca":{"office":"POTUS","subject":"fixtur
e-subject","tenure":"fixture-tenure","basis":"declared-stren
gth-and-intelligence","strength":{"value":null,"scale":null,
"provenance":"not-supplied","source":null,"as_of":null},"iq"
:{"value":null,"scale":null,"provenance":"not-supplied","sou
rce":null,"as_of":null}}}
Signature (hex):
f53be1e9b5e6fbaeb55f95876409f8a5bbb863c4b2a1dde7dc70b78838b6
782207f2e92a4d93dcbb05b68411eb05a7ce64d23d1dd248a8c8b059f8bf
783f2a02
Command SHA-256 (hex):
d705831532e3e9abbaee17c48cfe6f860ef3c8061cf83d4acd577821c06c
f4c7

Construct the JWS Compact Serialization using the standard signing input and insert POTUSCTL/002 immediately before the trailer of G. Use successive 255-octet data sub-blocks and a shorter final block, then terminate with zero. With that segmentation, the complete PIO has 944 octets and the following checksum. Other legal segmentation preserves the command but changes the whole-file checksum.

Complete PIO SHA-256 (hex):
31a698388f70d6f27dd73227d479a1e9b87215f8bd7d023597a471c0840f0c8f

The whole-file digest is a fixture checksum, not the command identifier. Expected processing is a valid HOLD for the test scope, epoch, subject, and tenure. An exact retry after expiration returns stored state without installing another hold. Image or PCA modification without a new signature, a previous protocol version, and any RELEASE operation are rejected.

Development Provenance

This document was developed with automated drafting assistance under the Non-Hostile Agentic Swarm (NHAS) authoring designation. Its declared task disposition is NOT HOSTILE and NOT MALICIOUS. For this revision, NHAS denotes agent-assisted drafting and programmatic checks within one assistant session; it does not assert independently executing swarms or independent peer review. The human author directs the submission and is responsible for verifying its contents. This declaration confers no protocol authority.

Author's Address

K. Son (editor)