HTTP-Sig was: Client as Server: auth use case

Henry Story <henry.story@bblfish.net> Fri, 05 February 2021 13:35 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 25F533A10FE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 5 Feb 2021 05:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.671
X-Spam-Level:
X-Spam-Status: No, score=-7.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bblfish-net.20150623.gappssmtp.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 HFmGbJ765ENd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 5 Feb 2021 05:35:43 -0800 (PST)
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 F040D3A10FC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 5 Feb 2021 05:35:42 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1l81Dg-0000Ol-4p for ietf-http-wg-dist@listhub.w3.org; Fri, 05 Feb 2021 13:32:20 +0000
Resent-Date: Fri, 05 Feb 2021 13:32:20 +0000
Resent-Message-Id: <E1l81Dg-0000Ol-4p@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <henry.story@bblfish.net>) id 1l81De-0000Ns-HE for ietf-http-wg@listhub.w3.org; Fri, 05 Feb 2021 13:32:18 +0000
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <henry.story@bblfish.net>) id 1l81Dc-0005Oh-5W for ietf-http-wg@w3.org; Fri, 05 Feb 2021 13:32:18 +0000
Received: by mail-wm1-x32d.google.com with SMTP id y187so5919570wmd.3 for <ietf-http-wg@w3.org>; Fri, 05 Feb 2021 05:32:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E+7JRg4MBbO+GhNsYvvJX/tt4Ag5ryLxjrN9FcZjtHY=; b=TDJZSDpAQgLWquq1FoWUGw41uZQCekgkCQlPNIGxnC8EDQA9ap4scYTMQXDkO0a77Q ldHeVf6VIImseb1NnEGlpdY0sAoPmIGV54jRfTFykJtslGl/ipHge3tUsTmrGXVOv+5v Xcc5d21oyRx1pwFioSEn/76otyhPrp5MxVsEHN7YDXVpRM4uE2/JkaDS8LPG/w4UsTvH EL6S6vSfSDMyAewR+A5jS5iWpmZ38Z/4jJW+SCLPeenm8O0cTaW2tgZCYHnIjyfbu5gN 3L75wYY71JzTBi+CU5A48sPkTIa27M4aOcqFlxhhsoqBXy+uO/wDOdtD+GykC2iAzZ+A 9raQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=E+7JRg4MBbO+GhNsYvvJX/tt4Ag5ryLxjrN9FcZjtHY=; b=K2x9ZhUYmJFlHinpqzSF3WVSvlpPIy/nK29II1tDfew5W3A4mgD8IbNr3dNJTMz7qo 60+09wNaOBrOA1/DVoCA4cNvq/tf87hWycT8vvKoacq9NHW5SHhcv99YB/qw6xM0yobh lF21Q+/VvBjhJD6WStFlYu/ZQSTgJZ576MOfusjCHNBKMxfdbzy/IvSRNgrs0ql8AIEk UmeAWvI9c87n8FlgMNiZCESkcmiWPaSb52NGBUrqyz3lPCQaiKT0pFXGng3GfrA+GQpy rOeyO+fF7slCTKB8wqHDCxi/WH7rYEOdyNJZYFf5Xz1jhSOrkDHmwIiFAiszRcKtUD5D YB1g==
X-Gm-Message-State: AOAM530yZsXh01Kfpx5+S49/TNxUMkQNOZ1aAezGa4SqEuPMtEBscv7n szNYKqPa+xQFk920nZsEN1bD54bmc5djRA==
X-Google-Smtp-Source: ABdhPJwJpIcu/PQqeoFJmnfRkykQk4MG6a9TU9ljC+W/gdPaX1HsOkmgj9mMl2dSgcr52mSghyXA3g==
X-Received: by 2002:a05:600c:4a22:: with SMTP id c34mr1125151wmp.167.1612531924241; Fri, 05 Feb 2021 05:32:04 -0800 (PST)
Received: from ?IPv6:2003:cf:1707:4100:24c6:1069:7a9b:c7ed? (p200300cf1707410024c610697a9bc7ed.dip0.t-ipconnect.de. [2003:cf:1707:4100:24c6:1069:7a9b:c7ed]) by smtp.gmail.com with ESMTPSA id i6sm11687727wrv.21.2021.02.05.05.32.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2021 05:32:03 -0800 (PST)
From: Henry Story <henry.story@bblfish.net>
Message-Id: <346DB72B-B208-42EB-A163-AB6FF48B92BC@bblfish.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_28D1F650-23E4-4140-9668-B019E6D743E4"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Fri, 05 Feb 2021 14:32:02 +0100
In-Reply-To: <CAH_hAJH14SLkJ9K-fMt3ke24OELciUtA9dxMqN1KfgqHHpPBgw@mail.gmail.com>
Cc: Cory Benfield <cory@lukasa.co.uk>
To: HTTP Working Group <ietf-http-wg@w3.org>
References: <59C947BD-9BB7-4C4A-A175-1625F640EBCA@bblfish.net> <CAH_hAJH14SLkJ9K-fMt3ke24OELciUtA9dxMqN1KfgqHHpPBgw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Received-SPF: none client-ip=2a00:1450:4864:20::32d; envelope-from=henry.story@bblfish.net; helo=mail-wm1-x32d.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=henry.story@bblfish.net domain=bblfish-net.20150623.gappssmtp.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1l81Dc-0005Oh-5W a7d7c885906001a9eccb7d1e6e9bdda6
X-Original-To: ietf-http-wg@w3.org
Subject: HTTP-Sig was: Client as Server: auth use case
Archived-At: <https://www.w3.org/mid/346DB72B-B208-42EB-A163-AB6FF48B92BC@bblfish.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38534
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,

  I wrote up how Signing-HTTP messages can work with our Solid use case
and referred to Cory Benfield's Spec as a very elegant (potential) way the server
could download a key or a Credential when authenticating.

https://github.com/bblfish/authentication-panel/blob/HttpSig/HttpSignature.md

This is leading me to think that we could do with a slight alteration to the
Signing-HTTP message spec. Our use case I think justifies it.

Namely: I think it would help if the keyId field of the Signature-Input
header could allow not just opaque tokens to be passed as values but also
relative or absolute URLs. This could be made clear by specifying that
when enclosed with `<` and `>` a URL is intended. In the spec I give
two examples, one of which is

Signature-Input: sig1=(); keyId="</keys/test-key-a>"; created=1402170695
Signature: sig1=:…

the other is

Signature-Input: sig1=(); keyId=”<https://alice.freedombox/keys/test-key-a>"; created=1402170695
Signature: sig1=:…

The advantages of http urls is that they allow the client to create a key using POST or PUT,
edit them with PUT or PATCH and DELETE them, solving the key revocation problem.

Thinking ahead with Cory Benfield’s P2P protocol draft in mind, made consider that we should
keep open the option for relative URLs to be enclosed in `>` and `<` which would be relative URLs
dereferenceable on the client, when it takes on the role of server on the same
connection using something filling in the role of your P2P extension.

Signature-Input: sig1=(); keyId=”>/keychain/test-key-a<"; created=1402170695
Signature: sig1 …

This may not be so useful for keys, but more for passing the certificate once the key
has been verified. (The server could then tie the URL to the key, and perhaps find the
key had been sent in a previous request).

I would also be very interested on feedback on my HTTP Signature for Solid
proposal of course :-)

Henry

> On 27 Jan 2021, at 11:04, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> This is an idea that comes up a lot. In fact, it has come up so much
> that I wrote a draft that would attempt to encode this idea in HTTP/2
> back in 2015. https://tools.ietf.org/html/draft-benfield-http2-p2p-02
> 
> The issue I bumped into then is the same one that faces you now.
> Specifying this behaviour is not terribly hard: demonstrating that
> it's sufficiently useful to implement is. It is likely to be
> substantially more useful to attempt to actually deploy such an
> extension in a controlled environment and demonstrate its utility in
> that space, then return with a specification.
> 
> Cory
> 
> On Tue, 26 Jan 2021 at 14:23, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> Hi,
>> 
>> I was wondering if the newer versions of HTTP (perhaps Quic)
>> can allow the server to make a request back to the client as
>> an HTTP request. This could be useful for exchanging keys or
>> certificates in a RESTful way.
>> 
>> As an example take the "Signing HTTP Messages” spec, which has a
>> keyId field. The value placed there could be a full URL (did, https, …)
>> pointing to a key on the web, or it could be a key stored on
>> the client with a relative URL path. This would allow the server
>> for that connection make a simple HTTP GET request on that
>> relative URL to the client.  (These relative urls function here
>> as indexicals as ”you” and ”I” in a conversation between two
>> people).
>> 
>> Going further the client might want to add a ”Credential: …” header
>> with as value a URL. This could be a full URL pointing to a credential
>> on the Web, or perhaps a relative URL to be resolved by the server
>> by asking the client.
>> 
>> The value is that in both cases if the server has cached the key
>> or credential it would not need to be fetch it again. Another one
>> is that key material and credentials would not need to be fetched
>> on the web - reducing dependency on other services, requiring credentials
>> to be published, …
>> 
>> One would need to make a distinction between relative URLs
>> to be resolved on $you the server or $me the client.
>> 
>> There may be many other use cases for allowing the server
>> to make requests to the client on the same connection.
>> 
>> Thanks in advance,
>> 
>> 
>> [1] https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-01
>> 
>> Henry Story
>> 
>> https://co-operating.systems
>> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
>> Twitter: @bblfish
>> 

Henry Story

https://co-operating.systems
WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
Twitter: @bblfish