[Secdispatch] HTTP Request Signing

Justin Richer <jricher@mit.edu> Fri, 01 November 2019 21:59 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 403A212083A; Fri, 1 Nov 2019 14:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TX4eAuHq79Ro; Fri, 1 Nov 2019 14:59:52 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DBD12082F; Fri, 1 Nov 2019 14:59:52 -0700 (PDT)
Received: from [] (static-71-174-62-56.bstnma.fios.verizon.net []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA1Lxoh4020181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 17:59:51 -0400
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6934B8F4-D23B-4D24-B018-73C87428BBDE"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <E53D0610-2A30-483E-9BF5-BC83E7BC2CBF@mit.edu>
Date: Fri, 1 Nov 2019 17:59:50 -0400
To: dispatch@ietf.org, secdispatch@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/JtS8KbMoxGdij9YvXXgS_Tv36yM>
Subject: [Secdispatch] 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: Fri, 01 Nov 2019 21:59:54 -0000

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 <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