Re: HTTP Signatures Updates

Hi Justin,

sorry for the late reply.

Il giorno sab 22 mag 2021 alle ore 00:38 Justin Richer
<jricher@mit.edu> ha scritto:
> > - 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?
Can you see the comments now?

> > 1- I'd adopt semantics-latest terminology [...]
> I think this is a good suggestion  [... but ... ] the readability of HTTP semantics terms, at the moment, is not as clear outside the working group.
I agree wrt outside the working group: we have to raise awareness on
the new SEMANTICS.

> > 2- Use the HTTP Semantics Message abstraction (control-data, headers,
> > content, trailers) to identify covered-parts,
> > 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.
I thought a lot about that, but mimicking the semantics stuff is the
only way I thought to have a framework
which is independent from the http messaging.

> 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.
The name could be != @control-data, the point is that a message starts
with a "control data". Every messaging implementation
defines the control data for the request and responses, so it's easy
to know how to bake it.

> 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”.
It is clear, but I am not sure about mixing something that is a
message part (eg. the actual `@request-target`) with other
values; we could for example have a different prefix for
specialties... but for now I'd be happy to just tackle the
existing comments.

Thanks and have a nice day,
R.



>
> > 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
>
>
>


--
Roberto Polli
API Expert
M. +39 3406522736
MID
DIPARTIMENTO PER LA
TRASFORMAZIONE
DIGITALE
Presidenza del Consiglio dei Ministri - Ministro per l'innovazione
tecnologica e la digitalizzazione
https://innovazione.gov.it/

Il Dipartimento per la Trasformazione Digitale, salvo eccezioni,
comunica con le altre Amministrazioni via posta elettronica ordinaria
e non posta elettronica certificata, in conformità a quanto previsto
dall’art.47 del Codice dell’Amministrazione Digitale.

Received on Friday, 4 June 2021 08:44:59 UTC