Re: HTTP Signatures Updates

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

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).
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
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.
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
5- Supporting intermediaries modification is a hard work: probably the
implementations
    will tell us if that's sustainable or not.

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 15:19:55 UTC