Re: Binding HTTP signatures (RFC 9421) to TLS

Thank you Demi Marie,

Yes, I'm aware of these issues.  However, since Deterministically Encoded CBOR is 1-2 magnitudes simpler than XML canonicalization, implementation quality issues should (IMO) be manageable.

The following 300 lines (+test code) of fairly mundane JavaScript, shows a "feature-complete" CBOR encoder using deterministic encoding:
https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js

I may surely be biased, since this is my main (and only) IETF-related activity:
https://www.ietf.org/archive/id/draft-rundgren-cbor-core-15.html

The Embedded Signature (here coined CSF), counterpart to the XML signature "transform", can for validation be performed by a handful of lines like:

   let object = CBOR.decode(cborBinary);              // Decode CBOR object
   let csf = object.get(CSF_CONTAINER_LBL);           // Get CSF container (a map)
   let alg = csf.get(CSF_ALG_LBL).getInt32();         // Get COSE algorithm
   let readSig = csf.remove(CSF_SIG_LBL).getBytes();  // Get and REMOVE signature value
   let signedData = object.encode();                  // The original data (CBOR binary)

Cool stuff enabled by Deterministically Encoded CBOR:
https://cyberphone.github.io/doc/defensive-publications/partial-encryption-full-signature.pdf

Regards,
Anders


On 2025-11-01 02:54, Demi Marie Obenour wrote:
> On 10/31/25 07:23, Anders Rundgren wrote:
>> Hi Chris,
>> I have not evaluated your solution for replay protection, I have rather thought a bit about possible issues with bot security and signatures.
>>
>> HTTP Signatures (RFC 9412) are fine but lack one item: a serialization format.  Due to this I'm working with signature schemes that are more adapted for Embedding, Counter-signatures, Multi-hop, and Archival:
>> https://github.com/cyberphone/cbor-everywhere/tree/main?tab=readme-ov-file#signed-http-requests
> 
> It’s worth noting that trying to sign an abstract message
> massively increases the room for implementations to err, often in
> exploitable ways.  See the numerous vulnerabilities in XML signature
> implementations for examples, as well as various vulnerabilities in
> Hashicorp Vault.  Instead, one should sign the data as raw bytes,
> and encapsulate it in a form that will pass through intermediates
> unchanged.  In the case of HTTP, this would correspond to wrapping
> an HTTP request inside another.
> Is this something that could be used instead?

Received on Saturday, 1 November 2025 05:19:26 UTC