Re: [Secdispatch] [dispatch] HTTP Request Signing

Justin Richer <> Sat, 02 November 2019 22:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A8C4120020; Sat, 2 Nov 2019 15:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5rSe07WxTThn; Sat, 2 Nov 2019 15:38:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32A7F12003E; Sat, 2 Nov 2019 15:38:59 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id xA2Mcu0I011820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 2 Nov 2019 18:38:57 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer <>
In-Reply-To: <>
Date: Sat, 2 Nov 2019 18:38:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Nov 2019 22:39:01 -0000

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 <> 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:
> 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 <> 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:
>> 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
> --
> Mark Nottingham