Re: Serialization#draft-ietf-httpbis-message-signatures-00

Justin Richer <jricher@mit.edu> Thu, 23 July 2020 20:29 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 9C4443A0D6D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 23 Jul 2020 13:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Level:
X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y8-nra_XeVdX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 23 Jul 2020 13:29:05 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 1A7E33A0B54 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 23 Jul 2020 13:29:04 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jyhmZ-0005br-4J for ietf-http-wg-dist@listhub.w3.org; Thu, 23 Jul 2020 20:25:35 +0000
Resent-Date: Thu, 23 Jul 2020 20:25:35 +0000
Resent-Message-Id: <E1jyhmZ-0005br-4J@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <jricher@mit.edu>) id 1jyhmX-0005bE-LP for ietf-http-wg@listhub.w3.org; Thu, 23 Jul 2020 20:25:33 +0000
Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <jricher@mit.edu>) id 1jyhmT-0000wT-PJ for ietf-http-wg@w3.org; Thu, 23 Jul 2020 20:25:33 +0000
Received: from [192.168.1.3] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06NKPHlB013000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jul 2020 16:25:17 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <c8082fbf-56db-89d3-ac2e-921953416a78@gmail.com>
Date: Thu, 23 Jul 2020 16:25:17 -0400
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A38C51EF-E451-407B-89C8-DBDB68645981@mit.edu>
References: <c8082fbf-56db-89d3-ac2e-921953416a78@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-W3C-Hub-Spam-Status: No, score=-10.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jyhmT-0000wT-PJ fd7f03511c0e7eb46919d760b07002dd
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Serialization#draft-ietf-httpbis-message-signatures-00
Archived-At: <https://www.w3.org/mid/A38C51EF-E451-407B-89C8-DBDB68645981@mit.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37910
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>

Hi Anders,

Thanks for your feedback. 

The proposed approach in the draft is to have a signature that can be serialized into an HTTP header, defined within the specification. If another spec wants to use this normalization and signature method and package the results differently, then it’s free to do so, but I don’t think that’s going to be a concern here.

The editors are looking at different signing methods and how we can use them with this specification. There are a lot of different algorithms for signing content out there, with different keys and limitations, and we need to figure out what and how we can support different things. We’ve still got some foundational cleanup and deeper issues to get through first, but that topic will come back up in the future. The authors are very familiar with JWS and are looking ways it might fit with this work.

 — Justin

> On Jul 17, 2020, at 3:52 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Dear List,
> Making signed HTTP requests serializable (in a reasonable way) is as far as I can tell not a part of the current agenda.
> 
> FWIW, here is a [very] raw proposal for how this could be accomplished:
> - Build on JWS compact mode.
> - Put a hash and attributes of the of signed HTTP header data (you're the experts on this part) in the JWS Protected Header as an extension.
> - Put the payload in the JWS Payload element using the standard base64url encoding.
>   Optionally use the JWS "typ" Protected Header element to specify MIME type of the payload
> - Use the completed JWS compact string as the sole HTTP Body element
> 
> For JSON-formatted data there is yet another possibility: combine https://www.rfc-editor.org/rfc/rfc8785.html with "in-line/detached" JWS ( https://tools.ietf.org/html/rfc7515#appendix-F):
>   {
>      "anyJsonElement": "something",
>          .
>          .
>      "signature":"eyJblahblahblah..blahblahblah"
>   }
> 
> In both cases the HTTP Body element contains the serializable signed data.  Verifying signed HTTP header data is though not possible to perform after leaving the HTTP environment.  OTOH, for systems that actually depend on serialization, using HTTP headers as data carriers doesn't appear as a recommendable approach.  In my own work which heavily builds on counter-signatures for digital contracts, URL and current time are therefore represented in the JSON payload by "requestUrl" and "timeStamp" respectively.
> 
> Thanx,
> Anders
> 
> 
> 
>