Re: Signing HTTP messages was: Client as Server: auth use case

Here is an extra use case of allowing one to specify URI’s in
the keyId field of the Signing HTTP Messages spec proposal.

Let us say we have a key URN format which allows one to pass the key as a URN
directly, a bit like one can have data urls. This would allow one to send an
HTTP request using the HTTP Signatures spec  like this:

GET /protected/resource HTTP/2.0
Credential: >/creds/age<
Signature-Input: sig1=(); keyId="<key:rsa:dsf234....>"; created=1402170695
Signature: sig1=:cxieW5ZK...
And the server would then using P2P extension for HTTP/2 discussed below,
be able to take on the role of a client and on the same connection ask
for the relative URL

GET /creds/age HTTP/2.0

The server could on receipt of this credential (or proof) be able to save
it in its cache under <key:rsa:dsf234..../creds/age> so that when
the client the next time comes with that keyId the server could
immediately fetch the credential in its store, after verifying the signature,
without needing to make a request to the server. After all the server knows
nothing about the client other than it's public key and so it may as well name it as that.

I would not be surprised if there is already a key URN specified somewhere,
but it should be quite easy to do.


> On 5 Feb 2021, at 14:32, Henry Story <henry.story@bblfish.net> wrote:
> 
> 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
> 

Henry Story

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