Re: [Secdispatch] [dispatch] HTTP Request Signing

That's roughly what I was going to say. :) I'd like to avoid the scope
creep of having WPACK take on request signing in addition to, effectively,
response signing. It's *possible* that we could define an HTTP header in a
general enough way that it would work for both purposes, and
https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 attempts
to do that, but the problem spaces seem to be different enough that we
should have separate groups write down the requirements for each side's
signatures before deciding that a single header will work. It's not even
clear to me that WPACK is going to end up defining an HTTP header, even
though my draft currently does so.

I'll be sure to attend the request-signing sessions in case they
establish that I'm wrong about this.

Jeffrey

On Sat, Nov 2, 2019 at 3:39 PM Justin Richer <jricher@mit.edu> wrote:

> Thanks for the pointer to the BoF, I hadn’t seen that one. I am familiar
> with the draft you linked though: The main difference is that the draft in
> question is for a signed response, whereas the draft(s) I’ve pointed at are
> for a signed request. Yes, they ought to be aligned, but the WG in question
> seems to be much more focused on packaging responses together than dealing
> with requests. If that new group also wants to take on request signing,
> then by all means let’s do it there. But it’s not as clean a match as it
> might seem on the surface, I think.
>
>  — Justin
>
> > On Nov 2, 2019, at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > Hi Justin,
> >
> > It's worth noting that there's a Working Group forming BoF, wpack, being
> held in Singapore about a draft with similar goals:
> >
> https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07
> >
> > In particular, both this draft and Jeffrey's propose the Signature HTTP
> header field, and seem to have at least partially overlapping use cases.
> >
> > If possible, it'd be good to avoid duplication of effort -- especially
> in terms of evaluating security properties and "fit" into HTTP by the
> security and HTTP communities, respectively. So, I'd suggest bringing it up
> there instead.
> >
> > Cheers,
> >
> >
> >> On 2 Nov 2019, at 8:59 am, Justin Richer <jricher@mit.edu> wrote:
> >>
> >> I would like to present and discuss HTTP Request signing at both the
> DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has
> been floating around for years now and has been adopted by a number of
> different external groups and efforts:
> >>
> >> https://tools.ietf.org/html/draft-cavage-http-signatures
> >>
> >> I’ve spoken with the authors of the draft and we’d like to find out how
> to bring this forward to publication within the IETF. I’m targeting both
> dispatch groups because this represents the intersection of both areas, and
> I think we’d get different perspectives from each side that we should
> consider.
> >>
> >> There have been a number of other drafts that have approached HTTP
> request signing as well (I’ve written two of them myself), but none has
> caught on to date and none have made it to RFC. Lately, though, I’ve been
> seeing a lot of renewed effort in different sectors, and in particular the
> financial sector and cloud services, to have a general purpose HTTP message
> signing capability. As such, I think it’s time to push something forward.
> >>
> >> I’ve reached out to the chairs for both DISPATCH and SECDISPATCH to
> request a presentation slot.
> >>
> >> Thank you, and I’ll see you all in Singapore!
> >> — Justin
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>