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

[Henry Story <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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: [phone]‬
>>> Twitter: @bblfish
>>> 
> 
> Henry Story
> 
> https://co-operating.systems
> WhatsApp, Signal, Tel: [phone]‬
> Twitter: @bblfish
> 

Henry Story

https://co-operating.systems
WhatsApp, Signal, Tel: [phone]‬
Twitter: @bblfish