Subject: Signed HTTP Exchanges use case

From: Phil Archer <[email-masked]>
Date: Wed, 13 Feb 2019 16:47:05 +0000

Dear Jeffrey,

My colleagues at GS1 and I have been looking at your Signed HTTP
Exchanges work which looks like a good fit for a use case we have - but
I need to do a sanity check, please. Here's a simple example of the kind
of use case we're tackling:

I scan a barcode on a product using a mobile phone app.

The app adds the scanned number (we call it the GTIN) into a template
URL https://example.com/gtin/{gtin}.

example.com is a server that conforms to a GS1 standard (that we're
writing at the moment) and redirects the request to a resource on the Web.

Given that anyone can build and operate a GS1 conformant resolver, we
need a method of distinguishing between a redirection link authorised by
the product manufacturer and any other link a resolver might offer.

Adding just a little complexity, actually we want resolvers to offer
multiple links with link relation types like "recipeWebsite" and
"instructionManual" - and those links will be exposed in an HTTP Link
header.

It looks as if your Internet Draft provides exactly the kind of thing we
need - the ability for a brand to sign that HTTP exchange, saying "yes,
we authorised these links" - even though they're not the ones operating
the resolver.

If it is the case that your I-D is a suitable method for achieving this,
would you consider adding a further use case to that effect in Appendix A?

Thanks

Phil

--
Phil Archer
Director, Web Solutions, GS1
https://www.gs1.org

http://philarcher.org
+44 (0)7887 767755
@philarcher1
Skype: philarcher

CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). 
If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it, and should inform the sender. 
GS1 disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone. 
GS1 may monitor communications. 
Third party rights acknowledged. 
(c) 2016.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 11:03:00 +1100

Hi Phil,

I don't see how a signed exchange is going to give you what you want here.

If I understand your scenario, the client has two things that are trustworthy: the (low entropy) number from the product, and a root CA store.  It also has an address of a resolver, but we don't necessarily trust that.

A signed exchange can be used by the operator of a site (any site) to produce information about its own origin.  But here the thing that the app is using is the combination of the resolver address and the number.  None of that establishes any expectation about the identity of the manufacturer.

If the identity of the manufacturer were known, then you might be able to do something about attesting to the relationship between a given page (this is recipes for this device) and the device itself, anchored in the identity of the manufacturer.

With the information you have, nothing can be signed except for content that the resolver controls.  And you've stated that the resolver is not necessarily trusted in this interaction.

--Martin

On Thu, Feb 14, 2019, at 03:47, Phil Archer wrote:
> CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  
> confidential and are not to be regarded as a contractual offer or 
> acceptance from GS1 (registered in Belgium). 
> If you are not the addressee, or if this has been copied or sent to you 
> in error, you must not use data herein for any purpose, you must delete 
> it, and should inform the sender.

---

From: Andy Green <[email-masked]>
Date: Thu, 14 Feb 2019 08:26:40 +0800

> With the information you have, nothing can be signed except for content that the resolver controls.  And you've stated that the resolver is not necessarily trusted in this interaction.

I think he's implying the client trusts a public root cert key for his 
servers, so he can verify signatures he gets.

As you say redirects aren't really the problem if the resolver could 
have pointed him to an attacker's server in the first place.

JWS / JOSE is good at this kind of thing, how about just don't try to 
bolt this on to http but do it as https application data containing JWS 
/ JSON with your protocol data signed by the server and just follow http 
redirects, perhaps checking the tls cert that gave them to you.

-Andy