Re: #1207: Signature Negotiation and Want-Signature

[[e-mail]]

On 2021-07-24 08:52, Justin Richer wrote:
> The editors of the signatures draft are looking at what it would take
> to add a negotiation feature to the Message Signatures draft, as
> it’s been requested a number of times and tracked specifically in
> http-extensions issue #1207. I want to give our rough strawman here
> and gather feedback, which we’ll then incorporate into a more
> concrete PR. None of this is meant to be spec-level text, but we’re
> looking for feedback on the approach, applicability, and extent of
> this feature.
> 

FWIW, I support the spec containing this feature. It is always nice to 
have a spec to follow instead of having to deal with interoperability 
problems caused by ad-hoc developer ideas.


> 
> A few core open questions we aren’t sure on (or, quite frankly, the
> editors disagree on where to start):
> 
> - When multiple values are sent, is this an AND or an OR of
> parameters? Do I have to send something that fits only one, or one for
> each, or one for all of them, or … ?

I propose that the values are independent. So that an agent can require 
one signature, and offer to accept others for better cross-validation if 
provided.

I can forsee some corporate/national policy requiring algorithm A which 
is outdated/insecure trying to operate in a world that has migrated to 
some better algorithm B already. Giving developers and admin the ability 
to say "require A, also check B"


> - Could a signature response include additional fields as opposed to
> just what’s listed? So let’s say I ask for (a b c), is it OK if I
> get (a b c d) in response?

IMO that should be a clear MUST NOT.

Since (d) was not suggested to be part of the signature there is no way 
for intermediaries to know that they MUST NOT alter its value. One 
should thus expect (d) to be different in recipient and sender views of 
the world. As a result, any signature they try to calculate from their 
different values can only be expected to mismatch.


> Ordering of the signed elements isn’t an
> issue here with how signatures are generated, more an issue of set
> math.
>  - Similarly, what about parameters on the signed request? Can I fill
> in a “keyid" if none is specified? What about “alg”? I would
> assume “created” would always be added. Could I substitute a
> parameter value?
>  - How do we handle error conditions if the responder is unable to
> fulfill the parameters of the requested signature? Should this be
> handled with an all out error or could we reply “successfully” but
> have a separate signature that doesn’t meet parameters?
>  - Bikeshedding: should this be Want-Signature? Accept-Signature?
> Really-Need-You-To-Sign-This?
> 


I propose that it may be useful to define both Accept-* and Want-* 
header names (or whatever equivalents) to manage the optional vs 
mandatory difference in use-cases of security vs transmission 
correctness validation.

  * Accept-Signature being an OPTIONAL sign. Sender SHOULD/MAY/ought-to 
sign using this signature pattern, but recipient(s) will not reject 
messages that lack it simply because of that lack.
   As a bonus intermediaries can add these if they want validation across 
certain hops.

  * Want-Signature being MUST sign. Recipient MUST reject the message if 
the signature is not provided. MUST NOT be touched by intermediaries.





> And finally this brings up another higher-level question: how does
> this align with, or possibly subsume, the
> http-origin-signed-responses[3] work from WEBPACK? Now that Message
> Signatures more properly covers responses and has clearer algorithm
> and key identifiers, the kinds of signed exchange defined in that
> draft are more able to be expressed using Message Signatures. This
> “Want-Signature” element is perhaps the last missing piece, as the
> WEBPACK proposal defines an “Accept-Signature” header with similar
> functions.
> 
> Thanks,
> 
>  — Justin
> 
> [1] https://github.com/httpwg/http-extensions/issues/1207
> [2]
> https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-2.3.11
> [3]
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html


AYJ