RE: Concrete format for signed responses

Thanks, Jeffrey.  In parallel with other work that’s going on to make push actually usable, I’m excited about the ability to push non-authoritative resources in a secure way.

A few smaller points on the draft, most of which wind up being feedback on Structured Headers more than your doc:

  *   3.1:  The usual format is “section <foo> of [BAR]”; I think if you use that format, the html-ized copy will actually deep-link to the relevant section.  You’re following the format from draft-ietf-header-structure, so we should fix it there instead.
  *   3.1:  MUST not => MUST NOT
  *   3.2.1:  You’re not the first to ask about lists in Structured Headers; the resolution nine months ago was that there’s nothing in Structured Headers to support that.  You’re demonstrating that there probably needs to be.  My solution in HTTP/QUIC was to violate the prohibition on repeated keys, but we need to resolve this before either Structure Headers and HTTP/QUIC lock down.
  *   3.6.1:  If you’re saying a client MAY do something other than what it MUST do per RFC7540, you might want to frame this as an extension.  In that vein, an HTTP/2 setting advertising support for this from the client might be in order.  You could also define a more specific error code for invalid unauthoritative pushes.

In 3.4, the pseudo-map of arrays alternating keys and values feels odd.  I assume the reason you did this is so you have a normalized order for the signature, as CBOR “does not allow ascribing semantics to the order….”  However, “[a] CBOR-based protocol can prescribe a specific order of serialization, such as for canonicalization,” and you already are.  (You specifically call out that you’re not using CBOR maps, so I presume you’ve been down this road.)  The advantage of your current scheme is that you can preserve the original order of the headers in the signature, meaning a client could detect changes / reconstruct them.  I’m not sure how critical that is, but this is the right list to give feedback on the semantic content of header ordering….

On the whole, I’m really interested in this direction, and this is a solid starting point for a way to get there.

From: Jeffrey Yasskin [mailto:jyasskin@google.com]
Sent: Tuesday, December 5, 2017 1:20 PM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Concrete format for signed responses

Hi all,

I've published https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html to follow up on https://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0385.html with a concrete proposal for the Signature header.

I made several choices in this design where another tradeoff would be totally plausible. Let me know where you'd prefer something different.

Some interesting aspects of this update:

* The signature covers the URL, so it's really a signed "exchange" rather than just a signed response.
* To simplify the Signed-Headers header, it's not possible to customize which parts of the request are included in the signature. Exactly the method and effective request URI are included.
* The signing key can either be a certificate's key or a raw ed25519 public key. The first supports origin-trusted certificates and other complex forms of trust, while the second supports https://github.com/mikewest/signature-based-sri and other ways a public key might be trusted out-of-band. Attentive folks will notice that this means signed exchanges are no longer necessarily *origin*-signed.
* Certificate chains are fetched and cached from a URL rather than bundled into the Signature header. Normal use is likely to Push the chain for a group of signed exchanges.
* There's a way to update the signatures for a response without re-fetching the whole response.

I'll be updating https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html as you point out things I should change.

Thanks,
Jeffrey