W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

Re: HTTP Signing

From: Roberto Polli <robipolli@gmail.com>
Date: Fri, 22 Nov 2019 13:43:51 +0100
Message-ID: <CAP9qbHU8wxrobYsV1sUsF9vdRAdetQ3Z8fcY-Y=sNdkLhHkYLw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC