By curl 8.22.0 shipped September 2, 2026. It fixed 302 bugs and made six changes. Most developers saw the changelog and moved on. One of those changes matters: experimental support for RFC 9421 HTTP Message Signatures — four new CLI flags that let you cryptographically sign outgoing HTTP requests. It requires a custom build. It is not production-ready. You should understand it anyway.
Why TLS Alone Is Not Enough
TLS secures the channel. It does not secure the message. When your request passes through a load balancer, a CDN edge node, or a reverse proxy, the TLS session terminates there. The intermediary decrypts, inspects, and re-encrypts. The upstream server has no way to verify the request body and headers are exactly what the original client sent.
RFC 9421 solves this at the application layer. The client selects specific HTTP request components — method, authority, path, query, chosen headers — and signs them with a private key before sending. The signature travels inside the request as two new headers: Signature-Input (declaring what was signed and the algorithm) and Signature (the cryptographic value). The server verifies the signature using the public key. Proxies in the middle can forward the request; they cannot silently modify the signed components without the signature failing.
This matters for AI agents making autonomous API calls, B2B financial integrations that require non-repudiation, and any webhook receiver tired of maintaining four different HMAC verification libraries for four different vendors.
The Four New curl Options
curl 8.22.0 adds four command-line flags and their libcurl equivalents:
--httpsig-algo— signing algorithm; defaults toed25519; currently also acceptshmac-sha256--httpsig-key— path to the signing key file--httpsig-keyid— string identifier sent in the headers so the server knows which key to use for verification--httpsig-headers— which components to include in the signature; defaults to method + authority + path + query
The libcurl equivalents — CURLOPT_HTTPSIG_ALGORITHM, CURLOPT_HTTPSIG_KEY, CURLOPT_HTTPSIG_KEYID, CURLOPT_HTTPSIG_HEADERS — let you sign requests programmatically from any language with curl bindings.
Here is what a signed request looks like in practice:
# Generate an ed25519 key pair
openssl genpkey -algorithm Ed25519 -out private.pem
openssl pkey -in private.pem -pubout -out public.pem
# Sign the request (requires --enable-httpsig build)
curl --httpsig-algo ed25519 --httpsig-key private.pem --httpsig-keyid my-service-key https://api.example.com/dataThe resulting request carries Signature-Input and Signature headers that a server implementing RFC 9421 verification can validate.
Read This Before You Deploy Anything
This feature is experimental. That word has a specific meaning in the curl project: it must be compiled in explicitly with --enable-httpsig, it is absent from all standard distribution packages, and the team explicitly reserves the right to change the API. There is no backward compatibility guarantee. The curl experimental docs are clear on this.
Daniel Stenberg, curl’s creator, put it plainly in his July 2026 blog post: “strongly discourage use in production.” Do not ship this. Watch it.
ed25519 or HMAC-SHA256?
The choice depends on your threat model and existing infrastructure.
ed25519 is the default and the right choice for most new integrations. It is asymmetric — the verifier only needs the public key. A compromised public key reveals nothing sensitive. It produces small signatures, is fast, and is considered state-of-the-art for digital signatures. Use this for agent-to-API authentication and public-facing integrations.
HMAC-SHA256 is the shared secret model — the same approach GitHub, Stripe, and Shopify use for their webhook signatures. If you are migrating from an existing setup using shared secrets, HMAC-SHA256 keeps the mental model familiar. Both sides must hold the secret, making it better suited for integrations you fully control on both ends.
Why curl Shipping This Matters
curl runs on an estimated 22 billion devices. When curl adds experimental support for a protocol feature, it is the loudest signal the ecosystem gets that a standard is worth implementing. Per-vendor HMAC webhook signatures — GitHub’s X-Hub-Signature-256, Stripe’s Stripe-Signature, Twilio’s X-Twilio-Signature — all solve the same problem with incompatible implementations. RFC 9421 is the standard that eventually replaces all of them, and curl’s implementation — even experimental — accelerates that.
Spring Security, the ActivityPub community, and browser spec groups have all opened RFC 9421 implementation issues in 2026. The standard is gaining traction. Once curl stabilizes the API and distribution packages bundle it, adoption will accelerate quickly.
Getting curl 8.22.0
# macOS
brew update && brew upgrade curl
# Ubuntu / Debian
sudo apt update && sudo apt upgrade curl libcurl4
# Verify
curl --versionStandard packages do not include the httpsig feature yet. To experiment, build from source with ./configure --enable-httpsig && make && make install.
The Verdict
Do not replace your webhook verification stack with this today. Do understand what RFC 9421 solves — because it will become the standard way to sign HTTP requests, and curl just made that future slightly more real.
