Re: HTTP Signatures Updates

Hi Roberto, thanks for the feedback! Some responses inline. 

> On May 21, 2021, at 1:04 PM, Roberto Polli <robipolli@gmail.com> wrote:
> 
> Hi Justin,
> 
> thanks for your work. It's a very good read, and I think that - while
> there's still some editorial work to be done
> the processing part is nearly complete.
> 
> Sorry for the late reply: here you can find a review of signatures-04.
> Please ask for permission to comment.
> 
> - https://docs.google.com/document/d/1Z4HhvuWLmPeK34An45l6qYLGrHGcUFf1NIDvxvc2QAM/edit

I’m not seeing any comments in the document — I have a feeling it’s just an access rights issue, though?

> 
> Briefly:
> 1- I'd adopt semantics-latest terminology because it will
> significantly help the readability of the doc; this
>    includes avoiding the term "content" because in HTTP it has a
> specific meaning (that is, the payload body of 7231).

I think this is a good suggestion and something we would need help aligning with — but that’s exactly why we’re here in this WG. :)

Though I do want to say that the readability of HTTP semantics terms, at the moment, is not as clear outside the working group.

> 2- Use the HTTP Semantics Message abstraction (control-data, headers,
> content, trailers) to identify covered-parts,
>    for example renaming @request-target to @control-data will work
> for both requests and responses. Moreover
>    control-data includes the method whereas request-target does not;
> The proposal is to have:
>    - Control-data identifiers (just @control-data)
>    - Header identifiers (the lowercase header name)
>    - Specialty identifiers (currently just @signature-params) with
> their registry

I am fine with aligning the terminology but the request-target/control-data are in the same category as the signature-params: they’re “not a header or trailer”, they’re set off with their own character, and they’re part of a set that will be expanded over time. We’ve got an action to revisit and expand what’s possible with @request-target, especially to help cover things like response codes and the like. If that ends up being called @control-data that’s fine, but it would be confusing for there to be three kinds of field.

What the goal here was to let developers look at an identifier and say, “it starts with @, I need to go look up how to process this; it doesn’t start with @, I look for the header/trailer/field value”. 

> 3- Some editorial work is needed to simplify the text, since some
> parts are hard to read.
>    I am trying to highlight stuff while I read the doc.

This would be very helpful! In the last few revisions we’ve moved around large chunks of the text to organize things better, so it doesn’t surprise me that the language might not always flow very well still. 

> 4- I really think that supporting single sf-items in a sf-dictionary
> or sf-list is not a good idea,
>    but I have told that so many times :D

I agree about list prefixes, and Annabelle and I have discussed dropping these in the next revision. However, dictionary keys are important to support for the multi-signature use case, and they are relatively easy to define using the structure field serialization rules for normalization purposes.

> 5- Supporting intermediaries modification is a hard work: probably the
> implementations
>    will tell us if that's sustainable or not.

I think we have to have this in the forefront of our minds. If we don’t, then we’ll end up with something too fragile to be used in reality. I say this as someone who’s written several takes on HTTP signing that did not take intermediaries in mind. :)

> 
> Have a nice day and thanks to you and Annabelle for all your work!
> R.
> 
> Il giorno mar 27 apr 2021 alle ore 18:57 Justin Richer
> <jricher@mit.edu> ha scritto:
>> 
>> The editors of the HTTP Message Signatures spec wanted to let the group know that with the recent publication of -04, we believe the major surgical changes from the input community drafts have been completed and it’s a newly stable base:
>> 
>> https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html
>> 
>> The major changes revolve around adopting structured fields as the basis for both signature base string creation as well as signature header contents. With these, we now have a way to discuss things in terms of structures with well-defined serializations, which is vital for good security. This has let us do things like cover signature parameters and pave the way for multiple signatures in a single request. We’ve also changed out the perspective of the protocol from something that was solely focused on a header format to something that deals with signatures and signing algorithms more holistically. Specifically, where there once was a required “algorithm” parameter that defined actions, there are now a set of requirements for defining algorithm and key resolution with the parameter as one input.
>> 
>> What does this mean? For one, we aren’t saying it’s done or that it’s perfect: there are still plenty of rough edges that need to be sanded, lots of language that isn’t quite fully accurate yet (headers vs fields, for instance), and I’m sure a few missing features. I’m sure we’ll still bike shed a few things and possibly tweak the syntax. But all that said, we don’t anticipate the kinds of major architectural changes. Now is the time for the working group to dig into it, try it out, figure out what the edges are, and define this more concretely.
>> 
>> So while we don’t think it’s ready for WGLC yet, we would like to get more eyes on the text and help keep pushing it forward. Please review the draft, help file issues (and/or PRs), and try to build the blasted thing. I’ve implemented the current draft myself on a couple platforms, and I’ve been seeing other implementers tracking it as well. It’s encouraging to see running code on this at this stage.
>> 
>> 
>> Thanks,
>> — Justin

Received on Friday, 21 May 2021 22:35:12 UTC