Re: Call for Adoption: draft-richanna-http-message-signatures
Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 09 January 2020 21:59 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D75C12021C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 Jan 2020 13:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-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 Dgos7YmrmCW7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 Jan 2020 13:59:16 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 0222E120807 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 Jan 2020 13:59:16 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ipfno-0008S6-1i for ietf-http-wg-dist@listhub.w3.org; Thu, 09 Jan 2020 21:57:16 +0000
Resent-Date: Thu, 09 Jan 2020 21:57:16 +0000
Resent-Message-Id: <E1ipfno-0008S6-1i@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1ipfnm-0008RE-GI for ietf-http-wg@listhub.w3.org; Thu, 09 Jan 2020 21:57:14 +0000
Received: from mail-vk1-xa2c.google.com ([2607:f8b0:4864:20::a2c]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1ipfnk-0002s5-U4 for ietf-http-wg@w3.org; Thu, 09 Jan 2020 21:57:14 +0000
Received: by mail-vk1-xa2c.google.com with SMTP id c129so25673vkh.7 for <ietf-http-wg@w3.org>; Thu, 09 Jan 2020 13:57:12 -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=f681mKuL2HX2fAaol69hu1Zn4fQJLDXEakBno8E55/E=; b=jpPZRvipQ36fAofVpOOq06k0Blb0Q121+uORQicsX8hax5BFqjR/uhh/1tzq7Ueei3 XgdNMGJAsWs1Pesq8+vHENzgD7vHWV3yueu1cQeiW4VrdAhNn81EJhSCWZg3vD/SWtoa dPLCCGIb447NvcwmvseJCvXNETa8oFQBL7QJiqv85Su0IUc3WzazacnMkMcddUOK8f7o 4QdQ1p1s0B1sJJnVJAy7hiBFqKk91XQTZ+bQf38J7HKXkKPjSTASC/DO6wwwLYXVeIdJ ZrVWKkljCqQMxJcbGRopkQomOFNoAcU4hgCUdBtB6TTbOE8JVU/og3RBbneNHvzqOdQ9 y1pQ==
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=f681mKuL2HX2fAaol69hu1Zn4fQJLDXEakBno8E55/E=; b=dx9zq0LxDFNcsgsHAowuKMPRDxsSAg4QTqqTeUECPuSrkK2NlO8aZB74sBXBkKGFci NpO+KlivNryvr3qycm8+vIKQIxyc3MGd6OC/yqSOTsykfRWgSAzs/JYCiR4T0wvrzZQx feVDDk4ltVU4+vYTUrnalnO8OHehWDW+o/bMpxBzLdRGHCV6TXNvrDr+L1f5qQJiVhXS 0u9If4/m5Mo5sc/JaTvzIzhWFhylWJyG/s5d0aClR9Nqw6NF2IPNC2w57+6V/f563NsF Q0PtizQsm6ViiAuKdvn8605cYeEeAfcXB/0AZr1NwdPQ84sh4QnBbVEES6H1pqJExOzz AkaQ==
X-Gm-Message-State: APjAAAUuFwZXsYGMvFBRWp8dHfihClHx/iN79MwdepLkAxC9uP4Z3xoy UW/F4xJYox1Vzr3eiKR8r4CMuFe7RB5Y2JPA34yO6Q==
X-Google-Smtp-Source: APXvYqxgKMjmP2Z2ULv7ogkaoxRM8mQi6uptlT5zXncd7dEPDNDHEXexcz+5oOz0jwMAhz8+i7AbmvLK9CU87qC9CIM=
X-Received: by 2002:a1f:4d85:: with SMTP id a127mr8109733vkb.67.1578607031519; Thu, 09 Jan 2020 13:57:11 -0800 (PST)
MIME-Version: 1.0
References: <76565D7E-C7F5-4D5D-BE3A-6E686E096B14@mnot.net> <1bf9b1fb-10d0-4948-a7e6-a913e54b7828@www.fastmail.com> <CALGR9obRChNiPZN7O-pk3BxeeTKkgPoeXhCtU0UhLP3xbHFA7Q@mail.gmail.com> <D3099091-EEBD-46E0-8891-D799676BB63B@mit.edu>
In-Reply-To: <D3099091-EEBD-46E0-8891-D799676BB63B@mit.edu>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 09 Jan 2020 21:57:01 +0000
Message-ID: <CALGR9oY7+6fjkBW+_MP3ALkEmEWSx0+8-bb67Q6Ue23knM0Edw@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000005a8dfe059bbc17d5"
Received-SPF: pass client-ip=2607:f8b0:4864:20::a2c; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-vk1-xa2c.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ipfnk-0002s5-U4 6087aa3559dfbd221bf061d0a40472d9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: draft-richanna-http-message-signatures
Archived-At: <https://www.w3.org/mid/CALGR9oY7+6fjkBW+_MP3ALkEmEWSx0+8-bb67Q6Ue23knM0Edw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37244
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Thanks for the detailed background Justin. Lucas On Thu, 9 Jan 2020, 21:38 Justin Richer, <jricher@mit.edu> wrote: > Speaking as one of the editors of the proposed I-D and the speaker in the > linked video: > > The “drama” happened largely because a number of groups made direct > normative requirements on a document that they didn’t have input in — they > saw the I-D and that it solved their problem, and so used it as is. Some > breaking changes were introduced in -11, including some frightening intro > text that said, quote: > > WARNING: DO NOT IMPLEMENT THIS SPECIFICATION AND PUSH THE CODE INTO > PRODUCTION. THIS VERSION OF THE SPECIFICATION IS ONLY FOR > EXPERIMENTAL IMPLEMENTATIONS. > > That kind of intro is scary, especially to people who didn’t realize the > state of the I-D (which is to say, independent and potentially volatile). > Members of the wider internet community that had been using the draft took > that as a signal that it was too unstable to track over time, so they > pegged to -10. Managing this kind of expectation and churn is one of the > reasons we want to bring this document into a formal standard process > instead of the detached community that it’s been in for years. > > There will be some people who stay on Cavage-10 after this becomes a WG > draft, and even after this becomes an RFC. Just like there are those today > who are on pre-10 drafts of Cavage. They are working in their own silos, > and the old drafts solve their problem so there is little motivation to > move their code to something new right now. And that’s especially true if > it’s an I-D that can change at any time. But there’s a lot more weight > behind an RFC, and that is the kind of thing that can lead to > general-purpose libraries and support in general projects that developers > can leverage instead of custom internal code. After all, if you can turn on > an Apache module or a Java Servlet Filter that just implements > RFC-HTTP-Signatures, why wouldn’t you use that? > > The editors are seeing Cavage-12 as the starting point for work, not its > end state. Not everyone agreed with the changes in -11 (and -12), but it > would be disingenuous to have a starting document that didn’t at least > incorporate those even if we decide to back them out completely. There’s a > lot of discussion in the proposed I-D about that kind of thing, like the > hs2019 signature method and the way that it lets you canonicalize > differently from other signature mechanisms, and some alternatives to that. > So there’s also a good chance that a lot of the community that balked at > -11 and -12 will be interested in coming along with a new draft from this > group, especially once things start to stabilize. They didn’t pick > Cavage-10 because it was perfect, but because it was there, and kinda the > only thing there. > > The relationship between this and Digest is also important. My own use > cases require protection of the entity body, so being able to cover that in > the signature through Digest or something like that is vital to me. > > — Justin > > On Jan 9, 2020, at 6:27 AM, Lucas Pardue <lucaspardue.24.7@gmail.com> > wrote: > > Hi Mark, > > A video of the presentation at SECDISPATCH is also available on YouTube. > IETF106-SECDISPATCH-20191119-1710 at the 50 minute mark, direct link: > https://youtu.be/CYBhLQ0-fwE?t=3006 > > I think it makes sense to discuss in the HTTP WG, I would be willing to > review and contribute. I think its important to figure out how this > approach differs from other signing methods mentioned previously, and to > document/articulate that in a way that is accessible to the wider community. > > There is a relationship between Digest header and signatures, having some > way to discuss this coherently may be beneficial. > > From the presentation, slide 11 titled "Cavage Signature Drama": > > > * Editors of draft publish major updates in draft -11 > > * Everyone using it freaks out and pegs to draft -10 > > draft-richanna-http-message-signatures clearly states that it is based on > draft-cavage-http-signatures-12. Do we have a sense of the appetite for > implementers to pick up any evolution of this specification basis, or is > draft-cavage-http-signatures-10 too sticky? > > Cheers > Lucas > > > >
- Call for Adoption: draft-richanna-http-message-si… Mark Nottingham
- Re: Call for Adoption: draft-richanna-http-messag… Martin Thomson
- Re: Call for Adoption: draft-richanna-http-messag… Lucas Pardue
- Re: Call for Adoption: draft-richanna-http-messag… Justin Richer
- Re: Call for Adoption: draft-richanna-http-messag… Justin Richer
- Re: Call for Adoption: draft-richanna-http-messag… Lucas Pardue
- Re: Call for Adoption: draft-richanna-http-messag… Richard Backman, Annabelle
- Re: Call for Adoption: draft-richanna-http-messag… Martin Thomson
- Re: Call for Adoption: draft-richanna-http-messag… Rob Sayre
- Re: Call for Adoption: draft-richanna-http-messag… Roberto Polli
- Re: Call for Adoption: draft-richanna-http-messag… Richard Backman, Annabelle
- Re: Call for Adoption: draft-richanna-http-messag… Manu Sporny
- Re: Call for Adoption: draft-richanna-http-messag… Henry Story
- Re: Call for Adoption: draft-richanna-http-messag… Orie Steele
- A brief history of HTTP Message Signatures (was: … Manu Sporny
- Re: A brief history of HTTP Message Signatures (w… Justin Richer
- Re: Call for Adoption: draft-richanna-http-messag… Sebastien Rosset (serosset)
- Re: Call for Adoption: draft-richanna-http-messag… Jonathan Gallimore
- Re: Call for Adoption: draft-richanna-http-messag… Roberto Polli
- Re: Call for Adoption: draft-richanna-http-messag… Manu Sporny
- Re: Call for Adoption: draft-richanna-http-messag… Eric Rescorla
- Re: Call for Adoption: draft-richanna-http-messag… Rick van Rein
- Re: Call for Adoption: draft-richanna-http-messag… Richard Backman, Annabelle
- Re: Call for Adoption: draft-richanna-http-messag… Rob Sayre