Subject: Concrete format for signed responses

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 05 Dec 2017 21:19:43 +0000

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

---

From: Andy Green <[email-masked]>
Date: Wed, 6 Dec 2017 06:23:23 +0800

On 12/06/2017 05:19 AM, Jeffrey Yasskin wrote:
> https://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0385.html 
> with a concrete proposal for the Signature header.

Sorry if this was already discussed, but do you know about JWS / JWK?

https://tools.ietf.org/html/rfc7515
https://tools.ietf.org/html/rfc7517

ACME uses them

https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

So there are an increasing number of implementations of this.

There seems to be a lot of crossover with what you're trying to do there 
(encode key type and parameters).

It's B64url encoding but it will let you put everything in one header.

-Andy

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 05 Dec 2017 23:34:57 +0000

> https://tools.ietf.org/html/rfc7517

When I've asked Chrome's security folks about JWS (and CMS and COSE),
they've advised that I stay far away from the general formats. We want to
keep implementations simple in order to reduce their bug counts, so we'd
need to profile the general format, but then we don't get to take advantage
of existing implementations. At most, we take advantage of any security
thinking that went into the JWS spec itself, but there are enough mistakes
in JWS that this doesn't help.

ACME uses them

> (encode key type and parameters).

Kinda:
1. JWS makes the mistake of letting the attacker control the verification
algorithm. Since the key and its type are already known to the verifier,
there's no need to encode the type in the signature.
2. Only one or two parameters defined in JWS overlap with the ones I
need: x5t#S256 and possibly crit. x5u is close, but I believe it doesn't
include the SCT and OCSP stapling that we'll want before trusting the
certificates.

Jeffrey

---

From: Mike Bishop <[email-masked]>
Date: Wed, 6 Dec 2017 18:42:00 +0000

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:[email-masked]]
Sent: Tuesday, December 5, 2017 1:20 PM
To: HTTP Working Group <[email-masked]>
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.

* 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Dec 2017 23:15:54 +0200

> as you point out things I should change.

Looking at the draft some comments:

Section 3.4:

" Followed by the appended items from, for each response header field in

exchange, in order: "

Errant paragraph break?

Section 3.6:

"and parsing it as a TLS 1.3 Certificate message ([I-D.ietf-tls-tls13],
section 4.4.2) containing X.509v3 certificates."

Does this include four-byte TLS message header? I have seen some
confusion with this in case of exported authenticators.

Also, TLS 1.3 Certificate message contains a context field. How that
should be set? always empty string?

"1. The text string “certSha256”.
2. The byte string certSha256."

This field does not seem if raw Ed25519 key (ed25519Key) is used?

This section does not seem to clearly define signature format. The
signature format is the same as used by TLS 1.3 (JOSE and COSE have
different format for ECDSA signatures)?

Also, should mapping entries for Ed25519 and Ed448 keys be specified
(even if not MTI)?

Section 3.6.1:

"Validate that all certificates in path include “status_request” 
extensions with valid OCSP responses."

While CA certificates might have OCSP responses, in practice these
have unusuably long lifetime (months!).

Section 3.6.2:

"TLS 1.3 signs the entire certificate chain, but doing that here would
preclude updating the OCSP signatures without replacing all signatures
using that chain at the same time. What attack do I allow by hashing
only the end-entity certificate?"

That probably depends on if upper certificates can alter the
interpretation of the end-entity certificate, instead of just having
"pass or fail" effect.

X.509 has all sorts of extensions that have all sorts of odd
semantics. The computational complexity of X.509 chain validation
is unknown, and might not be solvable in polynomial time.

Section 4.1:

"The use of a single Signed-Headers header field prevents us from
signing aspects of the request other than its effective request URI
([RFC7230], section 5.5). For example, if an author signs both
Content-Encoding: br and Content-Encoding: gzip variants of a response,
what’s the impact if an attacker serves the brotli one for a request
with Accept-Encoding: gzip?"

Assuming receiver and all intermediates on path properly support
Content-Encoding, that would just be a busted response, no? However
if something does not get C-E right, things get a lot more complicated.

Also, Signing Content-Encoding (and Content-Type) if any is a good
idea...

"Section 3.6 can succeed when some delivered headers aren’t included
in the signed set. This accommodates current TLS-terminating
intermediates and may be useful for SRI "

Nit: There are TLS-terminating intermediates that just terminate TLS
and pass the stream. Maybe you meant reverse proxies?

Section B.1.2:

The problem with RsaEncryption keys is not so much confusion with
non-TLS protocols. The problem arises if:

- Some server with private key supports TLS (or SSL) static RSA.
- That server does not properly hide decryption failures. This is
  hard, and the advice up to TLS 1.1 on this was flawed.

If those two conditions are met, then attacker can use the 
Bleichenbacher attack to forge signature for arbitrary message with the
relevant key.

Note that I said "Some server", not "the server". DROWN showed how
common shared keys are. And often they were shared with some pretty
badly configured servers.

There have been some wrong use security bugs with ECDSA keys as well,
but those did not let attacker forge signatures.

Section B.2:

Not signing accept-* does not seem to create worse problems than 
servers with busted negotiation (and there are probably a LOT of
those)?

Section B.2.1:

Again "TLS-terminating proxies". You mean reverse proxies?

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 06 Dec 2017 22:20:05 +0000

On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop <[email-masked]> wrote:

> 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.
>
>
>
>    - 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.
>
> https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-04#section-1
has a deep link written like ([RFC7540], Section 9.1.2), so it's not
primarily my syntax. I'm happy to use the 'of' syntax though if folks
prefer. https://github.com/WICG/webpackage/pull/92

>    - 3.1:  MUST not => MUST NOT
>
> Fixed in
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1
.

>    - 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.
>
> https://github.com/httpwg/http-extensions/issues/281 for others to follow
along.

>
>    - 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.
>
> Seems reasonable. Do you have any favorite extensions I could copy from?
Origin Frame is close, but it merely defines something that
https://tools.ietf.org/html/rfc7230#section-9.1 leaves vague, unlike this
extension that explicitly reverses a MUST from RFC7540.

> 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….
>
I was avoiding maps for two reasons, the second of which I think I've
mostly removed from the draft:

1) CBOR map canonicalization is a bit of a mess right now, with 3 errata
proposing different changes to the suggested canonical map ordering, and
the CBORbis effort not really sure which to pick:
https://www.ietf.org/mail-archive/web/cbor/current/msg00264.html. If I were
to pick a canonical order, I'd prefer
https://www.rfc-editor.org/errata_search.php?rfc=7049&eid=4964, pure
lexicographic order ignoring item lengths. Does that sound good to you?

2) I was thinking of a CBOR format for transmitting the exchange to the
client. For that, it's probably important to send the response headers
before the response payload, but 'response' sorts after 'payload' in either
canonical map ordering. This *may* also be useful for
https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html#cbor-representation,
where an implementation could stream the request and response into the
signature verifier before receiving the payload, with the current ordering,
but couldn't if it had to put the payload first. Do we want to 1) play
spelling games to put things in the right order, 2) use arrays in only the
places this matters, 3) use arrays everywhere, or 4) ignore this since it's
not in the current proposal?

> starting point for a way to get there.
Thanks (\o/)
Jeffrey

>
>
> *From:* Jeffrey Yasskin [mailto:[email-masked]]
> *Sent:* Tuesday, December 5, 2017 1:20 PM
> *To:* HTTP Working Group <[email-masked]>
> *Subject:* Concrete format for signed responses
>
>
>
> Hi all,
>
>
>
> I've published
> * 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.
>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 6 Dec 2017 22:45:08 +0000

Hm, then I’m not sure what sets up the deep links.  I’ll defer to those who know the tools better than I.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-00 requires the client to advertise support for the new frame types; you could steal the general structure from there.  I’d just say that servers MAY push signed resources for domains for which they aren’t authoritative only if the client has set the newly-defined setting.  Secondary Certs also defines new error codes, if you wanted to steal that.

What about omitting the tags entirely, and just have a two-element array with each element being a map?  [ request, response ].

From: Jeffrey Yasskin [mailto:[email-masked]]
Sent: Wednesday, December 6, 2017 2:20 PM
To: Mike Bishop <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Concrete format for signed responses

On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

  *   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.
https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-04#section-1 has a deep link written like ([RFC7540], Section 9.1.2), so it's not primarily my syntax. I'm happy to use the 'of' syntax though if folks prefer. https://github.com/WICG/webpackage/pull/92

  *   3.1:  MUST not => MUST NOT
Fixed in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1.

  *   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.
https://github.com/httpwg/http-extensions/issues/281 for others to follow along.

  *   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.
Seems reasonable. Do you have any favorite extensions I could copy from? Origin Frame is close, but it merely defines something that https://tools.ietf.org/html/rfc7230#section-9.1 leaves vague, unlike this extension that explicitly reverses a MUST from RFC7540.

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….
I was avoiding maps for two reasons, the second of which I think I've mostly removed from the draft:

1) CBOR map canonicalization is a bit of a mess right now, with 3 errata proposing different changes to the suggested canonical map ordering, and the CBORbis effort not really sure which to pick: https://www.ietf.org/mail-archive/web/cbor/current/msg00264.html. If I were to pick a canonical order, I'd prefer https://www.rfc-editor.org/errata_search.php?rfc=7049&eid=4964, pure lexicographic order ignoring item lengths. Does that sound good to you?

2) I was thinking of a CBOR format for transmitting the exchange to the client. For that, it's probably important to send the response headers before the response payload, but 'response' sorts after 'payload' in either canonical map ordering. This *may* also be useful for https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html#cbor-representation, where an implementation could stream the request and response into the signature verifier before receiving the payload, with the current ordering, but couldn't if it had to put the payload first. Do we want to 1) play spelling games to put things in the right order, 2) use arrays in only the places this matters, 3) use arrays everywhere, or 4) ignore this since it's not in the current proposal?

From: Jeffrey Yasskin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 5, 2017 1:20 PM
To: HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Concrete format for signed responses

Hi all,

Thanks,

Jeffrey

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 7 Dec 2017 09:30:50 +1000

On 7 December 2017 at 08:20, Jeffrey Yasskin <[email-masked]> wrote:
>> 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.
>

A while back I was working on an extension that adds a new flavour of
DATA frame[1], including changes to the state machine, flow control,
etc. and a setting to advertise support.  It might be useful as a
draft, even if it's not particularly useful as a H2 extension :)

[1]: https://tools.ietf.org/html/draft-kerwin-http2-encoded-data-09

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 6 Dec 2017 15:59:34 -0800

> " Followed by the appended items from, for each response header field in

Yes, but appears to be a problem with xml2rfc rather than my
kramdown-rfc2629 source. The XML is <t><list>...</list>Text
<spanx>exchange</spanx> Text<list>...</list></t>.

> confusion with this in case of exported authenticators.

I didn't think very hard about this, but if I wanted to include the
4-byte message header, I think I'd have to say that it's a Handshake
message containing a Certificate
(https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#handshake-protocol).
I'll add a note clarifying.

> should be set? always empty string?

I think so, since it's not in response to a CertificateRequest.

> This field does not seem if raw Ed25519 key (ed25519Key) is used?

Good catch.

> different format for ECDSA signatures)?

I do say that the signing algorithm is as defined by TLS 1.3 section
4.2.3. Is there something more I should say?

> Also, should mapping entries for Ed25519 and Ed448 keys be specified

("MTI"?) I believe that Ed25519 and Ed448 keys don't exist in the Web
PKI yet, although that could be out of date. Once they do, yes they
should have mandatory mapping entries.

> have unusuably long lifetime (months!).

Ah, so I need to set a maximum lifetime here. I'd vaguely heard that
Microsoft set a maximum lifetime for OCSP responses of 7 or 10 days.
Is that right? I'd like to match that.

> is unknown, and might not be solvable in polynomial time.

Ryan Sleevi said that signing just the end-entity certificate was the
right thing to do: https://github.com/WICG/webpackage/pull/91.

> if something does not get C-E right, things get a lot more complicated.

Attacks usually consist of something not getting something else quite
right, and a goal here is to make attacks as difficult as possible
even in the face of some bugs.

> Also, Signing Content-Encoding (and Content-Type) if any is a good

Right now I say that "Higher-level protocols SHOULD place requirements
on the minimum set of headers to include in the Signed-Headers header
field." I think it would make sense to give an example of a particular
protocol's decision here, but I'd want that to be a complete set of
required headers and not just one or two that we happen to call out.

> and pass the stream. Maybe you meant reverse proxies?

I'd imagined that reverse proxies were just one kind of
TLS-terminating intermediary, and may not be the only kind that add
headers. If that's wrong, I can switch to the narrower term.

> but those did not let attacker forge signatures.

It seems like you're talking about accidental signing oracles here,
which are covered in
https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html#rfc.section.4.p.4.
Beyond that, I'm not sure what else to write in this section.

> servers with busted negotiation (and there are probably a LOT of

That is, you're comfortable signing only the URL?

> Again "TLS-terminating proxies". You mean reverse proxies?

See above.

Thanks for the comments! I've sent a PR at
https://github.com/WICG/webpackage/pull/93.

Jeffrey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 6 Dec 2017 16:40:57 -0800

On Wed, Dec 6, 2017 at 2:45 PM, Mike Bishop <[email-masked]> wrote:
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-00
> requires the client to advertise support for the new frame types; you could
> steal the general structure from there.  I’d just say that servers MAY push
> signed resources for domains for which they aren’t authoritative only if the
> client has set the newly-defined setting.  Secondary Certs also defines new
> error codes, if you wanted to steal that.

Thanks. I'll look at that and draft-kerwin-http2-encoded-data, and
send y'all a PR Friday.

> What about omitting the tags entirely, and just have a two-element array
> with each element being a map?  [ request, response ].

Positional arguments are definitely plausible. I avoided them in order
to make it easier to extend this in the future if we need to. For
example, are we totally sure that we'll never want to represent
request payloads or trailers in a signed exchange?

Jeffrey

> 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.
>
> https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-04#section-1 has
> a deep link written like ([RFC7540], Section 9.1.2), so it's not primarily
> my syntax. I'm happy to use the 'of' syntax though if folks prefer.
> https://github.com/WICG/webpackage/pull/92
>
>
>
> 3.1:  MUST not => MUST NOT
>
> Fixed in
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.1.
>
>
>
> 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.
>
> that is, but this is the right list to give feedback on the semantic content
> of header ordering….
>
> proposing different changes to the suggested canonical map ordering, and the
> CBORbis effort not really sure which to pick:
> which parts of the request are included in the signature. Exactly the method
> and effective request URI are included.
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 7 Dec 2017 11:42:06 +0000

I recently started an, as yet, unpublished extension document and found Patrick’s Websocket proposal quite a nice example to base mine on. It’s available at https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-02

Lucas

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 7 Dec 2017 19:18:26 +0200

> 4.2.3. Is there something more I should say?

Oh, good.
 
> should have mandatory mapping entries.

I think after curdle-pkix goes to RFC, CABForum will probably allow Ed*
keys for EE certificates (but not CA certificates due to issues with
key protection). And EE certificates are the one that matters here.

> Is that right? I'd like to match that.

That is EE certificates only. And it is 7 days.

Poking around a bit, it seems that the OCSP response on the native LE
X3 intermediate has lifetime of 1 year(!!!).

> right thing to do: https://github.com/WICG/webpackage/pull/91.

Well, it probably is OK if nothing can affect interpretation (only
validity) of the end entity certificates.

> even in the face of some bugs.

If something doesn't get C-E right, the impact is tring to decompress
brotli data as gzip data. It is possible that there exists some piece
of data that decompresses as both (obviously to something different).

> headers. If that's wrong, I can switch to the narrower term.

Well, there are really three kind of things here:

- Just terminate TLS, leave data alone in both directions.
- Terminate TLS, mangle inbound data but not outbound data (usually
  to insert source address markers).
- Reverse proxy, mangles inbound and outbound data.

> That is, you're comfortable signing only the URL?

Yes.

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Sat, 09 Dec 2017 00:36:15 +0000

On Wed, Dec 6, 2017 at 4:40 PM Jeffrey Yasskin <[email-masked]> wrote:

> > Hm, then I’m not sure what sets up the deep links.  I’ll defer to those
> who
> > know the tools better than I.
> >
> >
> >

Here you go: https://github.com/WICG/webpackage/pull/94. Thanks for the
example drafts.

Jeffrey

> > A few smaller points on the draft, most of which wind up being feedback
> on
> > Structured Headers more than your doc:
> >
> has
> the
> > On the whole, I’m really interested in this direction, and this is a
> solid
> > starting point for a way to get there.
> >
> > Thanks (\o/)
> >
> > Jeffrey
> >
> >
> >
> with
> public
> key

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 11 Dec 2017 22:45:47 +0000

On Thu, Dec 7, 2017 at 9:18 AM Ilari Liusvaara <[email-masked]>
wrote:

> > ("Mandatory To Implement"?) I believe that Ed25519 and Ed448 keys don't
> exist in the Web

Thanks for pointing out that curdle-pkix is now close to being published.
I've added those key types in https://github.com/WICG/webpackage/pull/96. I
picked the pre-hashed variant of the signing algorithms, but I'm happy to
hear if that's the wrong choice.

> X3 intermediate has lifetime of 1 year(!!!).

Ouch. I'll limit the check to the end-entity certificate, and assume that
systems like OneCRL can handle revoked intermediates without needing help
from the signature format.

https://github.com/WICG/webpackage/pull/93

Thanks,
Jeffrey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 19 Dec 2017 00:59:40 +0000

On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop <[email-masked]> wrote:

> ... 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….
>
>
Pulling this out to its own thread since it's more general than the
signed-exchange proposal:

Is the order of HTTP headers semantically significant? Should future
proposals be careful to preserve header order, or is it ok to do things
like sort headers while processing them?

Thanks,
Jeffrey

---

From: Eitan Adler <[email-masked]>
Date: Mon, 18 Dec 2017 20:07:57 -0800

On 18 December 2017 at 16:59, Jeffrey Yasskin <[email-masked]> wrote:
> proposals be careful to preserve header order, or is it ok to do things like
> sort headers while processing them?

>From RFC 7230:

   The order in which header fields with differing field names are
   received is not significant.  However, it is good practice to send
   header fields that contain control data first, such as Host on
   requests and Date on responses, so that implementations can decide
   when not to handle a message as early as possible.

Note that this is only true for "differing field names":

   A recipient MAY combine multiple header fields with the same field
   name into one "field-name: field-value" pair, without changing the
   semantics of the message, by appending each subsequent field value to
   the combined field value in order, separated by a comma.  The order
   in which header fields with the same field name are received is
   therefore significant to the interpretation of the combined field
   value; a proxy MUST NOT change the order of these field values when
   forwarding a message.

Set-Cookie is a special case.

https://tools.ietf.org/html/rfc7230#section-3.2.2

-- 
Eitan Adler

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 19 Dec 2017 17:26:00 +1300

On 19/12/17 13:59, Jeffrey Yasskin wrote:
> On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop wrote:
> 
>     ... 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
>     content of header ordering….____
> 
>     ____
> 
> 

RFC 7230 section 3.2.2:
"
    The order in which header fields with differing field names are
    received is not significant.
"

but also:
"
    name ... The order
"

So both yes and no. Depending on the particular message and headers 
involved.

That same section also has this advise on header ordering for 
applications that generate new messages, or do modifications:
"
    ... However, it is good practice to send
    header fields that contain control data first, such as Host on
    requests and Date on responses, so that implementations can decide
    when not to handle a message as early as possible.
"

Amos