Skip to content

HTTP Message Signing investigation

API Security is typically managed by issuing a token for authentication. Only requests that include a valid token are processed, any requests with an expired or missing token are rejected. HTTP code 401 Unauthorised error message is returned for rejected requests.

When dealing with very sensitive data and higher risk actions common in financial services, additional security mechanisms are required. So I have been looking at mTLS and HTTP Message Signatures (RFC9421) this week.

Not going to be a productive week as I am full of flu. Given the time of year its most likely a variant of Covid. So far I've only had a headache, congested chest / nose / ears and some fatigue. Taking lots of paracetamol and drinking lots of water to try keep the inflammation at bay.

Edit: I was mostly okay by the weekend, although still had a sore throat and coughing.

HTTP Message Signaturesλ︎

Investigating how to implements RFC9421 HTTP Message Signatures using Clojure.

One aspect is choosing an algorithm for the private public key pair used to sign and validate a message. The ED25519 algorithm is recommended by GitHub for creating private public SSH keys to access their service. This seems a reasonable choice for HTTP Message Signatures.

ED25519 is recommended as the safe choice for signing as it is a fast and efficient algorithm and has does not have the challenges of earlier algorithms.

A Clojure library for comparing an ED25519 signature against a public key would reduce the work required to check a signed HTTP message is valid.

If there are no other interesting libraries for validating signatures, then Bouncy Castle is a well known Java implementation and has some Clojure wrappers.

Wellbeingλ︎

Managed a cycle ride with the local club on Saturday, was pushing hard to shake the last of the flu symptoms. I may have pushed a little too hard as I was exhausted for the rest of the weekend.


Thank you.

🌐 Practical.li Website

Practical.li GitHub Org practicalli-johnny profile

@practicalli@clj.social @practical_li