[Web-bot-auth] Re: Signature Misbinding in httpsig-protocol-00

[Dennis Jackson <[e-mail]>]

On 22/07/2026 10:44, Max Gerber wrote:

> In Thibault's draft, the second signature covers the original request 
> data, as well as the first signature. So I am not sure if the attack 
> applies here, but am very open to hearing where my interpretation is 
> wrong.

This isn't required by the draft. The first signature and second 
signature can cover different fields and attacks are possible when 
there's fields in the first signature not also directly covered in the 
second signature.

The second signature is also going to need to cover the first signer's 
public key and other identifying information. But even then the property 
doesn't strictly follow if the second signer is not trusted. For 
example, if the key is only authenticated by TLS fetch, it can plausibly 
change between when the second signer fetches it and the recipient 
fetches it. Consequently a recipient can't distinguish between a 
dishonest second signer lying about the first signer's public key and 
normal key rotation.

Before trying to define the mechanism, I think it makes sense to clarify 
the exact security property this system needs when handling requests 
authenticated by multiple parties.

Best,
Dennis

>
> On Wed, Jul 22, 2026 at 10:13 AM Thibault Meunier 
> <ot-ietf=[e-mail]> wrote:
>
>
>
>
>
>     On Wednesday, July 22nd, 2026 at 10:05, Dennis Jackson
>     <ietf=[e-mail]> wrote:
>
>     > In 4.2.2 of draft-meunier-webbotauth-httpsig-protocol-00 [1],
>     the draft
>     > proposes signing signatures:
>     >
>     >  > A signer MAY cover selected members from another signature label,
>     >  > including "signature";key=..., "signature-input";key=..., and
>     >  > "signature-agent";key=.... This lets a signer preserve
>     evidence that
>     >  > another signer contributed to the request.
>     >
>     > I don't think this is correct.
>     >
>     > RFC 9421 7.3.7 'Signing Signature Values' [2] recommends against
>     what's
>     > described in the draft, because it doesn't bind the message that
>     > corresponds to the inner signature:
>     >
>     >  > While it would seem that this practice would transitively
>     cover the
>     >  > components under the original signature in a verifiable
>     fashion, the
>     > attacks
>     >  > described in [JACKSON2019] can be used to impersonate a
>     signature output
>     >  > value on an unrelated message.
>     >
>     > If you only want to preserve evidence that a message was signed by
>     > another, you don't need to sign their signature, you just need to
>     > preserve their signature, message and public key, so removing
>     this text
>     > and stating that verifiers should check each signature independently
>     > would work and avoid these footguns.
>     >
>     > If you want a stronger property, like 'Party A only signed this
>     message
>     > because Party B signed it first', that requires some more
>     careful handling.
>
>     The goal is Party A only signed because Party B signed first. I'll
>     check [JACKSON2019], but happy to get advice and pointers here.
>     I'll also correct the text to avoid going against RFC 9421 7.3.7
>
>     >
>     > Best,
>     > Dennis
>     >
>     > [1]
>     >
>     https://www.ietf.org/archive/id/draft-meunier-webbotauth-httpsig-protocol-00.html#name-multiple-signatures
>     >
>     > [2]
>     >
>     https://www.rfc-editor.org/rfc/rfc9421.html#name-signing-signature-values
>     >
>     >
>     > _______________________________________________
>     > Web-bot-auth mailing list -- [e-mail]
>     > To unsubscribe send an email to [e-mail]
>     >
>
>     _______________________________________________
>     Web-bot-auth mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Web-bot-auth mailing list [e-mail]
> To unsubscribe send an email [e-mail]