- From: Roberto Polli <robipolli@gmail.com>
- Date: Fri, 22 Nov 2019 13:43:51 +0100
- To: "Richard Backman, Annabelle" <richanna@amazon.com>
- Cc: Rob Sayre <sayrer@gmail.com>, Liam Dennehy <liam@wiemax.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi A. Il giorno ven 22 nov 2019 alle ore 12:10 Richard Backman, Annabelle <richanna@amazon.com> ha scritto: > [..] flexibility regarding what protocol elements are covered by the signature, > [..and ..] rigorous canonicalization language. > [..] these two concepts are the key to success here. Agree, though AWS4 serialization could avoid specifying payload serialization and delegate it to Digest (see https://github.com/martinthomson/http-mice and the resulting revision of https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html). Serializing the payload body brings the same problems that affected Content-MD5 https://github.com/httpwg/http-core/issues/93 > [..] produce a core signing specification that defines signature generation and validation > without getting prescriptive about what elements get signed. > That can then be profiled (here in http, in oauth, in OpenID FAPI, ...) as needed. My experience with pre-11 draft-cavage resulted in insecure implementations due to under-specification about which fields to sign. Please see https://github.com/w3c-dvcg/http-signatures/issues/35 between the others. While we can define the general procedures, we should provide a table or something of required fields thus avoiding to address issues in future docs (eg. see JWT and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/). > That core spec is what I am currently working on, starting from cavage. > I hope to have an I-D ready to present to the working group for adoption before the end of this year. It would be great to see your ongoing work! I'm following the draft-cavage implementation from some time now, and we should try to make some merge work. I think we should take into consideration all the work done by https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html. Thanks for sharing and have a nice day, R. > Here are a couple links, in case anyone is interested in learning more about SigV4: > - Public documentation: https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html > - Informational presentation I gave at IETF 105: https://www.youtube.com/watch?v=tUmT5qqlKik&feature=youtu.be&t=6400 > > – > Annabelle Richard Backman > AWS Identity > > > On 11/22/19, 4:52 PM, "Roberto Polli" <robipolli@gmail.com> wrote: > > Hi Rob & co, > > Il giorno ven 22 nov 2019 alle ore 07:05 Rob Sayre <sayrer@gmail.com> > ha scritto: > > I saw the "HTTP Signing" presentation in the SECDISPATCH meeting on YouTube[1], and it seems like it's going to end up in this WG. > Interesting thread: the video is at > https://www.youtube.com/watch?v=CYBhLQ0-fwE&t=3000 > > > I'd like to suggest adopting something very similar to AWSv4. > iiuc the approach of draft-cavage and signed-exchange is very similar > and the signed-exchange workgroup made a lot of progresses. > AWSv4 seems to me quite limited and IMHO if you expand it you'll > eventually end with > draft-cavage or http-signatures. > > > I've implemented the server side of AWSv4 [...] > > it's possible to use off-the-shelf AWSv4 client SDKs, make up your own "service" name, and implement the server side of the protocol > Understand, though AWS can change that sdk in the future as that's > tied to their infrastructure. > > > [1] https://www.youtube.com/watch?v=CYBhLQ0-fwE > > [2] https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html > > Regards, > R. > > >
Received on Friday, 22 November 2019 12:44:06 UTC