Re: [Secdispatch] [dispatch] HTTP Request Signing
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 05 November 2019 19:46 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85561208AB; Tue, 5 Nov 2019 11:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSKAKrZRZeve; Tue, 5 Nov 2019 11:46:32 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24371200F4; Tue, 5 Nov 2019 11:46:31 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id t4so7232100otr.1; Tue, 05 Nov 2019 11:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bgHWsI7fNrkOKyVIIFWWy2YB3IB/ZL3vpDSSARiGuoU=; b=H/+Q24SIA8JSSckojV32ZshrRSjshtJ6thGaJG/ddV0pURKOKAVgTMKsLINuRrm3gE 1PL9AeVfSD6fF4gpr1aKA4rk8n/DZoTC1J18lEAzGnvq0w2R56zBpi2nhoNmpzS0ghxA S1fVM5hmLHlWZUzIy9LUv58oVmb0YQ/wN9HtsJQxX0uozfxzADt3OZ4n6I8c6bv+YdNY ym8B7x8FbTfvkWN3GtNJPH1vSf+sgcrupv5NXsLg7eJGcN/mHXggD1ID1kPlhZegf9vQ nuoYWDcOzChtSycZu0vYw/hG5b3K0KfT4HwLMK8V2bdRHSySIp55g45viWc28nh2clMF xTPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bgHWsI7fNrkOKyVIIFWWy2YB3IB/ZL3vpDSSARiGuoU=; b=YI14aVz5z8VG7rlQXxQlVwasdEKi2NYQGnn2iziTMwER+LFOGBZyDSlpg5A3y8PYRG oCfrQd4Z63lxMU+N0uh4yRhUqhMPTcq5mnEL954LOPa6eOJ51BGDITZyPBrK85fazEW4 ZxNGBUTSaPrEXC9BV2VPbhGyF3t9KAtMf7Kbe0ZczDC3wUDuzxpKRon+FOo614bRZGB7 w31T/evh59BlRaXLXvCnTIlhEGVSO+1JNMt7axshCKMJj0/EToraesm57ZWYVkTteamI bKZ0AjgQkLc5yzbu8mUH0mSKASoSv8i7RLCyw6S4dtrpokm0rnpgh0L7mMe2tRPCEBgq 0QTw==
X-Gm-Message-State: APjAAAXdbwQAMV2Mf5qdsL8FfhdIx+sx9Qm1XojZAPbfsgVkQVaj5jbS PiNTX6+ZLLujr510mnc9oLFaBjullo+IXJHX/F8=
X-Google-Smtp-Source: APXvYqwDP23Tn2Zdpdo1r+gEbIh2L0asG4vWabF75sz7xvtw8FH7Bkhzc5vnTOV6y9uJXV6vGLH/DDeaxTlcQv3UC0E=
X-Received: by 2002:a9d:6a10:: with SMTP id g16mr3924387otn.224.1572983191160; Tue, 05 Nov 2019 11:46:31 -0800 (PST)
MIME-Version: 1.0
References: <E53D0610-2A30-483E-9BF5-BC83E7BC2CBF@mit.edu> <CAHBDyN5-Hj-Hsr_r7V4QWNBB7eeunSdN0YLAVROuq1LqJEERBA@mail.gmail.com> <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> <CAHbuEH5DQ7uRwe6=1dj80VLrkik6ceyGe+reeN+fmgVQmM9rcw@mail.gmail.com> <fe297381-a97f-21d7-899d-e387ce6e2f3c@nostrum.com>
In-Reply-To: <fe297381-a97f-21d7-899d-e387ce6e2f3c@nostrum.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 05 Nov 2019 14:45:54 -0500
Message-ID: <CAHbuEH4cDOYfyZAavpH8WuJVAXksKd_LejVce85LO4oXfv6Uqw@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Justin Richer <jricher@mit.edu>, DISPATCH <dispatch@ietf.org>, IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000058cc4a05969eb06e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/1Wu0NU1DwXmckTZ5tG_7XTzZ9Ag>
Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 19:46:35 -0000
OK, it's on the posted agenda. Best regards, Kathleen On Tue, Nov 5, 2019 at 2:43 PM Adam Roach <adam@nostrum.com> wrote: > Given that DISPATCH meets in the first Monday morning slot, I think this > plan makes the most sense. Justin (or the DISPATCH chairs) can give a very > short description of the purpose of the proposed mechanism, and let > interested parties know that the discussion will take place in SECDISPATCH. > > /a > > On 11/5/19 10:59 AM, Kathleen Moriarty wrote: > > We have the time at SecDispatch, so should I just add it > considering DISPATCH has a full agenda? > > Best regards, > Kathleen > > On Tue, Nov 5, 2019 at 11:56 AM Justin Richer <jricher@mit.edu> wrote: > >> A number of the people involved with implementing the drafts that I’d >> like to present are involved in IETF in different places, but none for >> pushing this draft to date. If this work finds a home, I think we’d be able >> to get a lot of that external community to participate in whatever list >> ends up hosting the work. >> >> I’m fine with presenting at only one of DISPATCH or SECDISPATCH instead >> of both, but since this sits squarely at the intersection of the two >> communities it might make sense for me to just introduce the concept (~1 >> min) at whatever meeting I’m not giving a full presentation at. >> >> — Justin >> >> >> On Nov 4, 2019, at 3:02 PM, Mary Barnes <mary.ietf.barnes@gmail.com> >> wrote: >> >> Personally, I'd rather not have the presentation twice, recognizing of >> course, that not everyone would be able to attend one or the other. But, we >> will have recordings and as is oft stated, ultimately decisions happen on >> mailing lists. And, I appreciate and agree with Jeffrey not wanting >> feature creep in WPACK. One objective of DISPATCH has been to ensure that >> work that is chartered is discrete enough to finish in a timely manner. >> >> You mention other communities that are interested in this. Will they be >> participating or have they participated in IETF? It's hard for chairs to >> judge consensus to work on something when the communities interested in the >> work are not participating in IETF. Mailing list participation is >> sufficient. >> >> DISPATCH agenda is pretty full right now, so this would have to fall into >> AOB at this juncture if ADs and my WG co-chair agree that we should discuss >> in DISPATCH. And, perhaps whether it gets a few minutes in SECdispatch >> might be informed on how it goes in DISPATCH, if we have a chance to >> discuss it, since you need the agreement that this is a problem IETF should >> solve from both areas. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> >> >> On Fri, Nov 1, 2019 at 5:00 PM 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 >>> >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > > > -- > > Best regards, > Kathleen > > _______________________________________________ > dispatch mailing listdispatch@ietf.orghttps://www.ietf.org/mailman/listinfo/dispatch > > > -- Best regards, Kathleen
- [Secdispatch] HTTP Request Signing Justin Richer
- Re: [Secdispatch] [dispatch] HTTP Request Signing Mark Nottingham
- Re: [Secdispatch] [dispatch] HTTP Request Signing Justin Richer
- Re: [Secdispatch] [dispatch] HTTP Request Signing Jeffrey Yasskin
- Re: [Secdispatch] [dispatch] HTTP Request Signing Mark Nottingham
- Re: [Secdispatch] [dispatch] HTTP Request Signing Phillip Hallam-Baker
- [Secdispatch] Updating/Replacing RFC 2660 ? (was … Dr. Pala
- Re: [Secdispatch] Updating/Replacing RFC 2660 ? (… Eric Rescorla
- Re: [Secdispatch] [dispatch] HTTP Request Signing Mary Barnes
- Re: [Secdispatch] [dispatch] HTTP Request Signing Kathleen Moriarty
- Re: [Secdispatch] [dispatch] HTTP Request Signing Justin Richer
- Re: [Secdispatch] [dispatch] HTTP Request Signing Justin Richer
- Re: [Secdispatch] [dispatch] HTTP Request Signing Adam Roach
- Re: [Secdispatch] [dispatch] HTTP Request Signing Kathleen Moriarty
- Re: [Secdispatch] [dispatch] HTTP Request Signing Justin Richer