[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         J. Yasskin
Internet-Draft                                                   K. Ueno
Intended status: Standards Track                                  Google
Expires: March 8, 2019                                September 04, 2018


            Signed HTTP Exchanges Implementation Checkpoints
         draft-yasskin-httpbis-origin-signed-exchanges-impl-02

Abstract

   This document describes checkpoints of draft-yasskin-http-origin-
   signed-responses to synchronize implementation between clients,
   intermediates, and publishers.

Note to Readers

   Discussion of this draft takes place on the HTTP working group
   mailing list (ietf-http-wg@w3.org), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].

   The source code and issues list for this draft can be found in
   https://github.com/WICG/webpackage [2].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 8, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Yasskin & Ueno            Expires March 8, 2019                 [Page 1]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Signing an exchange . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The Signature Header  . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  CBOR representation of exchange headers . . . . . . . . .   6
       3.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Loading a certificate chain . . . . . . . . . . . . . . .   7
     3.4.  Canonical CBOR serialization  . . . . . . . . . . . . . .   8
     3.5.  Signature validity  . . . . . . . . . . . . . . . . . . .   9
     3.6.  Updating signature validity . . . . . . . . . . . . . . .  12
       3.6.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  13
     3.7.  The Accept-Signature header . . . . . . . . . . . . . . .  14
       3.7.1.  Integrity identifiers . . . . . . . . . . . . . . . .  15
       3.7.2.  Key type identifiers  . . . . . . . . . . . . . . . .  15
       3.7.3.  Key value identifiers . . . . . . . . . . . . . . . .  16
       3.7.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  16
   4.  Cross-origin trust  . . . . . . . . . . . . . . . . . . . . .  17
     4.1.  Stateful header fields  . . . . . . . . . . . . . . . . .  18
     4.2.  Certificate Requirements  . . . . . . . . . . . . . . . .  19
   5.  Transferring a signed exchange  . . . . . . . . . . . . . . .  20
     5.1.  Same-origin response  . . . . . . . . . . . . . . . . . .  20
       5.1.1.  Serialized headers for a same-origin response . . . .  21
       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  21
     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  22
     5.3.  application/signed-exchange format  . . . . . . . . . . .  22
       5.3.1.  Cross-origin trust in application/signed-exchange . .  23
       5.3.2.  Example . . . . . . . . . . . . . . . . . . . . . . .  23
   6.  Security considerations . . . . . . . . . . . . . . . . . . .  24
   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  24
   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  25
     8.1.  Internet Media Type application/signed-exchange . . . . .  25
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  27
     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  29
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  31



Yasskin & Ueno            Expires March 8, 2019                 [Page 2]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1.  Introduction

   Each version of this document describes a checkpoint of
   [I-D.yasskin-http-origin-signed-responses] that can be implemented in
   sync by clients, intermediates, and publishers.  It defines a
   technique to detect which version each party has implemented so that
   mismatches can be detected up-front.

2.  Terminology

   Absolute URL  A string for which the URL parser [3] ([URL]), when run
      without a base URL, returns a URL rather than a failure, and for
      which that URL has a null fragment.  This is similar to the
      absolute-URL string [4] concept defined by ([URL]) but might not
      include exactly the same strings.

   Author  The entity that wrote the content in a particular resource.
      This specification deals with publishers rather than authors.

   Publisher  The entity that controls the server for a particular
      origin [RFC6454].  The publisher can get a CA to issue
      certificates for their private keys and can run a TLS server for
      their origin.

   Exchange (noun)  An HTTP request/response pair.  This can either be a
      request from a client and the matching response from a server or
      the request in a PUSH_PROMISE and its matching response stream.
      Defined by Section 8 of [RFC7540].

   Intermediate  An entity that fetches signed HTTP exchanges from a
      publisher or another intermediate and forwards them to another
      intermediate or a client.

   Client  An entity that uses a signed HTTP exchange and needs to be
      able to prove that the publisher vouched for it as coming from its
      claimed origin.

   Unix time  Defined by [POSIX] section 4.16 [5].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.





Yasskin & Ueno            Expires March 8, 2019                 [Page 3]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


3.  Signing an exchange

   In the response of an HTTP exchange the server MAY include a
   "Signature" header field (Section 3.1) holding a list of one or more
   parameterised signatures that vouch for the content of the exchange.
   Exactly which content the signature vouches for can depend on how the
   exchange is transferred (Section 5).

   The client categorizes each signature as "valid" or "invalid" by
   validating that signature with its certificate or public key and
   other metadata against the exchange's headers and content
   (Section 3.5).  This validity then informs higher-level protocols.

   Each signature is parameterised with information to let a client
   fetch assurance that a signed exchange is still valid, in the face of
   revoked certificates and newly-discovered vulnerabilities.  This
   assurance can be bundled back into the signed exchange and forwarded
   to another client, which won't have to re-fetch this validity
   information for some period of time.

3.1.  The Signature Header

   The "Signature" header field conveys a single signature for an
   exchange, accompanied by information about how to determine the
   authority of and refresh that signature.  Each signature directly
   signs the exchange's headers and identifies one of those headers that
   enforces the integrity of the exchange's payload.

   The "Signature" header is a Structured Header as defined by
   [I-D.ietf-httpbis-header-structure].  Its value MUST be a
   parameterised list (Section 3.3 of
   [I-D.ietf-httpbis-header-structure]), and the list MUST contain
   exactly one element.  Its ABNF is:

   Signature = sh-param-list

   The parameterised identifier in the list MUST have parameters named
   "sig", "integrity", "validity-url", "date", "expires", "cert-url",
   and "cert-sha256".  This specification gives no meaning to the
   identifier itself, which can be used as a human-readable identifier
   for the signature.  The present parameters MUST have the following
   values:

   "sig"  Binary content (Section 3.9 of
      [I-D.ietf-httpbis-header-structure]) holding the signature of most
      of these parameters and the exchange's headers.





Yasskin & Ueno            Expires March 8, 2019                 [Page 4]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   "integrity"  A string (Section 3.7 of
      [I-D.ietf-httpbis-header-structure]) containing a "/"-separated
      sequence of names starting with the lowercase name of the response
      header field that guards the response payload's integrity.  The
      meaning of subsequent names depends on the response header field,
      but for the "digest" header field, the single following name is
      the name of the digest algorithm that guards the payload's
      integrity.

   "cert-url"  A string (Section 3.7 of
      [I-D.ietf-httpbis-header-structure]) containing an absolute URL
      (Section 2) with a scheme of "https" or "data".

   "cert-sha256"  Binary content (Section 3.9 of
      [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of
      the first certificate found at "cert-url".

   "validity-url"  A string (Section 3.7 of
      [I-D.ietf-httpbis-header-structure]) containing an absolute URL
      (Section 2) with a scheme of "https".

   "date" and "expires"  An integer (Section 3.5 of
      [I-D.ietf-httpbis-header-structure]) representing a Unix time.

   The "cert-url" parameter is _not_ signed, so intermediates can update
   it with a pointer to a cached version.

3.1.1.  Examples

   The following header is included in the response for an exchange with
   effective request URI "https://example.com/resource.html".  Newlines
   are added for readability.

Signature:
 sig1;
  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*;
  integrity="digest/mi-sha256-03";
  validity-url="https://example.com/resource.validity.1511128380";
  cert-url="https://example.com/oldcerts";
  cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*;
  date=1511128380; expires=1511733180

   The signature uses a secp256r1 certificate within
   "https://example.com/".

   It relies on the "Digest" response header with the mi-sha256-03
   digest algorithm to guard the integrity of the response payload.




Yasskin & Ueno            Expires March 8, 2019                 [Page 5]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   The signature includes a "validity-url" that includes the first time
   the resource was seen.  This allows multiple versions of a resource
   at the same URL to be updated with new signatures, which allows
   clients to avoid transferring extra data while the old versions don't
   have known security bugs.

   The certificate at "https://example.com/certs" has a "subjectAltName"
   of "example.com", meaning that if it and its signature validate, the
   exchange can be trusted as having an origin of
   "https://example.com/".

3.2.  CBOR representation of exchange headers

   To sign an exchange's headers, they need to be serialized into a byte
   string.  Since intermediaries and distributors might rearrange, add,
   or just reserialize headers, we can't use the literal bytes of the
   headers as this serialization.  Instead, this section defines a CBOR
   representation that can be embedded into other CBOR, canonically
   serialized (Section 3.4), and then signed.

   The CBOR representation of a set of request and response metadata and
   headers is the CBOR ([RFC7049]) array with the following content:

   1.  The map mapping:

       *  The byte string ':method' to the byte string containing the
          request's method.

       *  For each request header field except for the "Host" header
          field, the header field's lowercase name as a byte string to
          the header field's value as a byte string.

          Note: "Host" is excluded because it is part of the effective
          request URI, which is represented outside of this map.

   2.  The map mapping:

       *  The byte string ':status' to the byte string containing the
          response's 3-digit status code, and

       *  For each response header field, the header field's lowercase
          name as a byte string to the header field's value as a byte
          string.








Yasskin & Ueno            Expires March 8, 2019                 [Page 6]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


3.2.1.  Example

   Given the HTTP exchange:

   GET / HTTP/1.1
   Host: example.com
   Accept: */*

   HTTP/1.1 200
   Content-Type: text/html
   Digest: mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=
   Signed-Headers: "content-type", "digest"

   <!doctype html>
   <html>
   ...

   The cbor representation consists of the following item, represented
   using the extended diagnostic notation from [I-D.ietf-cbor-cddl]
   appendix G:

[
  {
    'accept': '*/*',
    ':method': 'GET',
  },
  {
    'digest': 'mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=',
    ':status': '200',
    'content-type': 'text/html'
  }
]

3.3.  Loading a certificate chain

   The resource at a signature's "cert-url" MUST have the "application/
   cert-chain+cbor" content type, MUST be canonically-encoded CBOR
   (Section 3.4), and MUST match the following CDDL:

   cert-chain = [
     "&#128220;&#9939;", ; U+1F4DC U+26D3
     + {
       cert: bytes,
       ? ocsp: bytes,
       ? sct: bytes,
       * tstr => any,
     }
   ]



Yasskin & Ueno            Expires March 8, 2019                 [Page 7]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   The first map (second item) in the CBOR array is treated as the end-
   entity certificate, and the client will attempt to build a path
   ([RFC5280]) to it from a trusted root using the other certificates in
   the chain.

   1.  Each "cert" value MUST be a DER-encoded X.509v3 certificate
       ([RFC5280]).  Other key/value pairs in the same array item define
       properties of this certificate.

   2.  The first certificate's "ocsp" value MUST be a complete, DER-
       encoded OCSP response for that certificate (using the ASN.1 type
       "OCSPResponse" defined in [RFC6960]).  Subsequent certificates
       MUST NOT have an "ocsp" value.

   3.  Each certificate's "sct" value if any MUST be a
       "SignedCertificateTimestampList" for that certificate as defined
       by Section 3.3 of [RFC6962].

   Loading a "cert-url" takes a "forceFetch" flag.  The client MUST:

   1.  Let "raw-chain" be the result of fetching ([FETCH]) "cert-url".
       If "forceFetch" is _not_ set, the fetch can be fulfilled from a
       cache using normal HTTP semantics [RFC7234].  If this fetch
       fails, return "invalid".

   2.  Let "certificate-chain" be the array of certificates and
       properties produced by parsing "raw-chain" using the CDDL above.
       If any of the requirements above aren't satisfied, return
       "invalid".  Note that this validation requirement might be
       impractical to completely achieve due to certificate validation
       implementations that don't enforce DER encoding or other standard
       constraints.

   3.  Return "certificate-chain".

3.4.  Canonical CBOR serialization

   Within this specification, the canonical serialization of a CBOR item
   uses the following rules derived from Section 3.9 of [RFC7049] with
   erratum 4964 applied:

   o  Integers and the lengths of arrays, maps, and strings MUST use the
      smallest possible encoding.

   o  Items MUST NOT be encoded with indefinite length.






Yasskin & Ueno            Expires March 8, 2019                 [Page 8]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   o  The keys in every map MUST be sorted in the bytewise lexicographic
      order of their canonical encodings.  For example, the following
      keys are correctly sorted:

      1.  10, encoded as 0A.

      2.  100, encoded as 18 64.

      3.  -1, encoded as 20.

      4.  "z", encoded as 61 7A.

      5.  "aa", encoded as 62 61 61.

      6.  [100], encoded as 81 18 64.

      7.  [-1], encoded as 81 20.

      8.  false, encoded as F4.

   Note: this specification does not use floating point, tags, or other
   more complex data types, so it doesn't need rules to canonicalize
   those.

3.5.  Signature validity

   The client MUST parse the "Signature" header field as the
   parameterised list (Section 4.2.3 of
   [I-D.ietf-httpbis-header-structure]) described in Section 3.1.  If an
   error is thrown during this parsing or any of the requirements
   described there aren't satisfied, the exchange has no valid
   signatures.  Otherwise, each member of this list represents a
   signature with parameters.

   The client MUST use the following algorithm to determine whether each
   signature with parameters is invalid or potentially-valid for an
   exchange's

   o  "requestUrl", a byte sequence that can be parsed into the
      exchange's effective request URI (Section 5.5 of [RFC7230]),

   o  "headers", a byte sequence holding the canonical serialization
      (Section 3.4) of the CBOR representation (Section 3.2) of the
      exchange's request and response metadata and headers, and

   o  "payload", a stream of bytes constituting the exchange's payload
      body (Section 3.3 of [RFC7230]).  Note that the payload body is
      the message body with any transfer encodings removed.



Yasskin & Ueno            Expires March 8, 2019                 [Page 9]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   Potentially-valid results include:

   o  The signed headers of the exchange so that higher-level protocols
      can avoid relying on unsigned headers, and

   o  Either a certificate chain or a public key so that a higher-level
      protocol can determine whether it's actually valid.

   This algorithm accepts a "forceFetch" flag that avoids the cache when
   fetching URLs.  A client that determines that a potentially-valid
   certificate chain is actually invalid due to an expired OCSP response
   MAY retry with "forceFetch" set to retrieve an updated OCSP from the
   original server.

   1.   Let "payload" be the payload body (Section 3.3 of [RFC7230]) of
        "exchange".  Note that the payload body is the message body with
        any transfer encodings removed.

   2.   Let:

        *  "signature" be the signature (binary content in the
           parameterised identifier's "sig" parameter).

        *  "integrity" be the signature's "integrity" parameter.

        *  "validity-url" be the signature's "validity-url" parameter.

        *  "cert-url" be the signature's "cert-url" parameter, if any.

        *  "cert-sha256" be the signature's "cert-sha256" parameter, if
           any.

        *  "date" be the signature's "date" parameter, interpreted as a
           Unix time.

        *  "expires" be the signature's "expires" parameter, interpreted
           as a Unix time.

   3.   Set "publicKey" and "signing-alg" depending on which key fields
        are present:

        1.  Assert: "cert-url" is present.

            1.  Let "certificate-chain" be the result of loading the
                certificate chain at "cert-url" passing the "forceFetch"
                flag (Section 3.3).  If this returns "invalid", return
                "invalid".




Yasskin & Ueno            Expires March 8, 2019                [Page 10]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


            2.  Let "main-certificate" be the first certificate in
                "certificate-chain".

            3.  Set "publicKey" to "main-certificate"'s public key.

            4.  If "publicKey" is an RSA key, return "invalid".

            5.  If "publicKey" is a key using the secp256r1 elliptic
                curve, set "signing-alg" to ecdsa_secp256r1_sha256 as
                defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

            6.  Otherwise, return "invalid".

   4.   If "expires" is more than 7 days (604800 seconds) after "date",
        return "invalid".

   5.   If the current time is before "date" or after "expires", return
        "invalid".

   6.   Let "message" be the concatenation of the following byte
        strings.  This matches the [I-D.ietf-tls-tls13] format to avoid
        cross-protocol attacks if anyone uses the same key in a TLS
        certificate and an exchange-signing certificate.

        1.  A string that consists of octet 32 (0x20) repeated 64 times.

        2.  A context string: the ASCII encoding of "HTTP Exchange 1
            b2".

            Note: As this is a snapshot of a draft of
            [I-D.yasskin-http-origin-signed-responses], it uses a
            distinct context string.

        3.  A single 0 byte which serves as a separator.

        4.  If "cert-sha256" is set, a byte holding the value 32
            followed by the 32 bytes of the value of "cert-sha256".
            Otherwise a 0 byte.

        5.  The 8-byte big-endian encoding of the length in bytes of
            "validity-url", followed by the bytes of "validity-url".

        6.  The 8-byte big-endian encoding of "date".

        7.  The 8-byte big-endian encoding of "expires".

        8.  The 8-byte big-endian encoding of the length in bytes of
            "requestUrl", followed by the bytes of "requestUrl".



Yasskin & Ueno            Expires March 8, 2019                [Page 11]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


        9.  The 8-byte big-endian encoding of the length in bytes of
            "headers", followed by the bytes of "headers".

   7.   If "cert-url" is present and the SHA-256 hash of "main-
        certificate"'s "cert_data" is not equal to "cert-sha256" (whose
        presence was checked when the "Signature" header field was
        parsed), return "invalid".

        Note that this intentionally differs from TLS 1.3, which signs
        the entire certificate chain in its Certificate Verify
        (Section 4.4.3 of [I-D.ietf-tls-tls13]), in order to allow
        updating the stapled OCSP response without updating signatures
        at the same time.

   8.   If "signature" is not a valid signature of "message" by
        "publicKey" using "signing-alg", return "invalid".

   9.   If "integrity" does not match "digest/mi-sha256-03", return
        "invalid".

   10.  If "payload" doesn't match the integrity information in the
        header described by "integrity", return "invalid".

   Note that the above algorithm can determine that an exchange's
   headers are potentially-valid before the exchange's payload is
   received.  Similarly, if "integrity" identifies a header field and
   parameter like "Digest: mi-sha256-03" ([I-D.thomson-http-mice]) that
   can incrementally validate the payload, early parts of the payload
   can be determined to be potentially-valid before later parts of the
   payload.  Higher-level protocols MAY process parts of the exchange
   that have been determined to be potentially-valid as soon as that
   determination is made but MUST NOT process parts of the exchange that
   are not yet potentially-valid.  Similarly, as the higher-level
   protocol determines that parts of the exchange are actually valid,
   the client MAY process those parts of the exchange and MUST wait to
   process other parts of the exchange until they too are determined to
   be valid.

3.6.  Updating signature validity

   Both OCSP responses and signatures are designed to expire a short
   time after they're signed, so that revoked certificates and signed
   exchanges with known vulnerabilities are distrusted promptly.

   This specification provides no way to update OCSP responses by
   themselves.  Instead, clients need to re-fetch the "cert-url"
   (Section 3.5, Paragraph 6) to get a chain including a newer OCSP
   response.



Yasskin & Ueno            Expires March 8, 2019                [Page 12]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   The "validity-url" parameter (Paragraph 5) of the signatures provides
   a way to fetch new signatures or learn where to fetch a complete
   updated exchange.

   Each version of a signed exchange SHOULD have its own validity URLs,
   since each version needs different signatures and becomes obsolete at
   different times.

   The resource at a "validity-url" is "validity data", a CBOR map
   matching the following CDDL ([I-D.ietf-cbor-cddl]):

   validity = {
     ? signatures: [ + bytes ]
     ? update: {
       ? size: uint,
     }
   ]

   The elements of the "signatures" array are parameterised identifiers
   (Section 4.2.4 of [I-D.ietf-httpbis-header-structure]) meant to
   replace the signatures within the "Signature" header field pointing
   to this validity data.  If the signed exchange contains a bug severe
   enough that clients need to stop using the content, the "signatures"
   array MUST NOT be present.

   If the the "update" map is present, that indicates that a new version
   of the signed exchange is available at its effective request URI
   (Section 5.5 of [RFC7230]) and can give an estimate of the size of
   the updated exchange ("update.size").  If the signed exchange is
   currently the most recent version, the "update" SHOULD NOT be
   present.

   If both the "signatures" and "update" fields are present, clients can
   use the estimated size to decide whether to update the whole resource
   or just its signatures.

3.6.1.  Examples

   For example, say a signed exchange whose URL is "https://example.com/
   resource" has the following "Signature" header field (with line
   breaks included and irrelevant fields omitted for ease of reading).










Yasskin & Ueno            Expires March 8, 2019                [Page 13]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   Signature:
    sig1;
     sig=*MEUCIQ...*;
     ...
     validity-url="https://example.com/resource.validity.1511157180";
     cert-url="https://example.com/oldcerts";
     date=1511128380; expires=1511733180

   At 2017-11-27 11:02 UTC, "sig1" has expired, so the client needs to
   fetch "https://example.com/resource.validity.1511157180" (the
   "validity-url" of "sig1") if it wishes to update that signature.
   This URL might contain:

{
  "signatures": [
    'sig1; '
    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; '
    'validity-url="https://example.com/resource.validity.1511157180"; '
    'integrity="digest/mi-sha256-03"'
    'cert-url="https://example.com/newcerts"; '
    'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; '
    'date=1511733180; expires=1512337980'
  ],
  "update": {
    "size": 5557452
  }
}

   This indicates that the client could fetch a newer version at
   "https://example.com/resource" (the original URL of the exchange), or
   that the validity period of the old version can be extended by
   replacing the original signature with the new signature provided.
   The signature of the updated signed exchange would be:

   Signature:
    sig1;
     sig=*MEQCIC...*;
     ...
     validity-url="https://example.com/resource.validity.1511157180";
     cert-url="https://example.com/newcerts";
     date=1511733180; expires=1512337980

3.7.  The Accept-Signature header

   "Signature" header fields cost on the order of 300 bytes for ECDSA
   signatures, so servers might prefer to avoid sending them to clients
   that don't intend to use them.  A client can send the "Accept-
   Signature" header field to indicate that it does intend to take



Yasskin & Ueno            Expires March 8, 2019                [Page 14]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   advantage of any available signatures and to indicate what kinds of
   signatures it supports.

   When a server receives an "Accept-Signature" header field in a client
   request, it SHOULD reply with any available "Signature" header fields
   for its response that the "Accept-Signature" header field indicates
   the client supports.  However, if the "Accept-Signature" value
   violates a requirement in this section, the server MUST behave as if
   it hadn't received any "Accept-Signature" header at all.

   The "Accept-Signature" header field is a Structured Header as defined
   by [I-D.ietf-httpbis-header-structure].  Its value MUST be a
   parameterised list (Section 3.3 of
   [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

   Accept-Signature = sh-param-list

   The order of identifiers in the "Accept-Signature" list is not
   significant.  Identifiers, ignoring any initial "-" character, MUST
   NOT be duplicated.

   Each identifier in the "Accept-Signature" header field's value
   indicates that a feature of the "Signature" header field
   (Section 3.1) is supported.  If the identifier begins with a "-"
   character, it instead indicates that the feature named by the rest of
   the identifier is not supported.  Unknown identifiers and parameters
   MUST be ignored because new identifiers and new parameters on
   existing identifiers may be defined by future specifications.

3.7.1.  Integrity identifiers

   Identifiers starting with "digest/" indicate that the client supports
   the "Digest" header field ({{!RFC3230) with the parameter from the
   HTTP Digest Algorithm Values Registry [6] registry named in lower-
   case by the rest of the identifier.  For example, "digest/mi-blake2"
   indicates support for Merkle integrity with the as-yet-unspecified
   mi-blake2 parameter, and "-digest/mi-sha256" indicates non-support
   for Merkle integrity with the mi-sha256 content encoding.

   If the "Accept-Signature" header field is present, servers SHOULD
   assume support for "digest/mi-sha256-03" unless the header field
   states otherwise.

3.7.2.  Key type identifiers

   Identifiers starting with "ecdsa/" indicate that the client supports
   certificates holding ECDSA public keys on the curve named in lower-
   case by the rest of the identifier.



Yasskin & Ueno            Expires March 8, 2019                [Page 15]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   If the "Accept-Signature" header field is present, servers SHOULD
   assume support for "ecdsa/secp256r1" unless the header field states
   otherwise.

3.7.3.  Key value identifiers

   The "ed25519key" identifier has parameters indicating the public keys
   that will be used to validate the returned signature.  Each
   parameter's name is re-interpreted as binary content (Section 3.9 of
   [I-D.ietf-httpbis-header-structure]) encoding a prefix of the public
   key.  For example, if the client will validate signatures using the
   public key whose base64 encoding is
   "11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=", valid "Accept-
   Signature" header fields include:

Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=*
Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg==*
Accept-Signature: ..., ed25519key; *11qYAQ==*
Accept-Signature: ..., ed25519key; **

   but not

   Accept-Signature: ..., ed25519key; *11qYA===*

   because 5 bytes isn't a valid length for encoded base64, and not

   Accept-Signature: ..., ed25519key; 11qYAQ

   because it doesn't start or end with the "*"s that indicate binary
   content.

   Note that "ed25519key; **" is an empty prefix, which matches all
   public keys, so it's useful in subresource integrity cases like
   "<link rel=preload as=script href="...">" where the public key isn't
   known until the matching "<script src="..." integrity="...">" tag.

3.7.4.  Examples

   Accept-Signature: digest/mi-sha256-03

   states that the client will accept signatures with payload integrity
   assured by the "Digest" header and "mi-sha256-03" digest algorithm
   and implies that the client will accept signatures from ECDSA keys on
   the secp256r1 curve.

   Accept-Signature: -ecdsa/secp256r1, ecdsa/secp384r1





Yasskin & Ueno            Expires March 8, 2019                [Page 16]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   states that the client will accept ECDSA keys on the secp384r1 curve
   but not the secp256r1 curve and payload integrity assured with the
   "Digest: mi-sha256-03" header field.

4.  Cross-origin trust

   To determine whether to trust a cross-origin exchange, the client
   takes a "Signature" header field (Section 3.1) and the "exchange"'s

   o  "requestUrl", a byte sequence that can be parsed into the
      exchange's effective request URI (Section 5.5 of [RFC7230]),

   o  "headers", a byte sequence holding the canonical serialization
      (Section 3.4) of the CBOR representation (Section 3.2) of the
      exchange's request and response metadata and headers, and

   o  "payload", a stream of bytes constituting the exchange's payload
      body (Section 3.3 of [RFC7230]).

   The client MUST parse the "Signature" header into a list of
   signatures according to the instructions in Section 3.5, and run the
   following algorithm for each signature, stopping at the first one
   that returns "valid".  If any signature returns "valid", return
   "valid".  Otherwise, return "invalid".

   1.  If the signature's "validity-url" parameter (Paragraph 5) is not
       same-origin [7] with "requestUrl", return "invalid".

   2.  Use Section 3.5 to determine the signature's validity for
       "requestUrl", "headers", and "payload", getting "certificate-
       chain" back.  If this returned "invalid" or didn't return a
       certificate chain, return "invalid".

   3.  Let "exchange" be the exchange metadata and headers parsed out of
       "headers".

   4.  If "exchange"'s request method is not safe (Section 4.2.1 of
       [RFC7231]) or not cacheable (Section 4.2.3 of [RFC7231]), return
       "invalid".

   5.  If "exchange"'s headers contain a stateful header field, as
       defined in Section 4.1, return "invalid".

   6.  Let "authority" be the host component of "requestUrl".

   7.  Validate the "certificate-chain" using the following substeps.
       If any of them fail, re-run Section 3.5 once over the signature




Yasskin & Ueno            Expires March 8, 2019                [Page 17]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


       with the "forceFetch" flag set, and restart from step 2.  If a
       substep fails again, return "invalid".

       1.  Use "certificate-chain" to validate that its first entry,
           "main-certificate" is trusted as "authority"'s server
           certificate ([RFC5280] and other undocumented conventions).
           Let "path" be the path that was used from the "main-
           certificate" to a trusted root, including the "main-
           certificate" but excluding the root.

       2.  Validate that "main-certificate" has the CanSignHttpExchanges
           extension (Section 4.2).

       3.  Validate that "main-certificate" has an "ocsp" property
           (Section 3.3) with a valid OCSP response whose lifetime
           ("nextUpdate - thisUpdate") is less than 7 days ([RFC6960]).
           Note that this does not check for revocation of intermediate
           certificates, and clients SHOULD implement another mechanism
           for that.

       4.  Validate that valid SCTs from trusted logs are available from
           any of:

           +  The "SignedCertificateTimestampList" in "main-
              certificate"'s "sct" property (Section 3.3),

           +  An OCSP extension in the OCSP response in "main-
              certificate"'s "ocsp" property, or

           +  An X.509 extension in the certificate in "main-
              certificate"'s "cert" property,

           as described by Section 3.3 of [RFC6962].

   8.  Return "valid".

4.1.  Stateful header fields

   As described in Section 6.1 of
   [I-D.yasskin-http-origin-signed-responses], a publisher can cause
   problems if they sign an exchange that includes private information.
   There's no way for a client to be sure an exchange does or does not
   include private information, but header fields that store or convey
   stored state in the client are a good sign.

   A stateful request header field informs the server of per-client
   state.  These include but are not limited to:




Yasskin & Ueno            Expires March 8, 2019                [Page 18]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   o  "Authorization", [RFC7235]

   o  "Cookie", [RFC6265]

   o  "Cookie2", [RFC2965]

   o  "Proxy-Authorization", [RFC7235]

   o  "Sec-WebSocket-Key", [RFC6455]

   A stateful response header field modifies state, including
   authentication status, in the client.  The HTTP cache is not
   considered part of this state.  These include but are not limited to:

   o  "Authentication-Control", [RFC8053]

   o  "Authentication-Info", [RFC7615]

   o  "Optional-WWW-Authenticate", [RFC8053]

   o  "Proxy-Authenticate", [RFC7235]

   o  "Proxy-Authentication-Info", [RFC7615]

   o  "Sec-WebSocket-Accept", [RFC6455]

   o  "Set-Cookie", [RFC6265]

   o  "Set-Cookie2", [RFC2965]

   o  "SetProfile", [W3C.NOTE-OPS-OverHTTP]

   o  "WWW-Authenticate", [RFC7235]

4.2.  Certificate Requirements

   We define a new X.509 extension, CanSignHttpExchanges to be used in
   the certificate when the certificate permits the usage of signed
   exchanges.  When this extension is not present the client MUST NOT
   accept a signature from the certificate as proof that a signed
   exchange is authoritative for a domain covered by the certificate.
   When it is present, the client MUST follow the validation procedure
   in Section 4.

      CanSignHttpExchanges ::= NULL

   Note that this extension contains an ASN.1 NULL (bytes "05 00")
   because some implementations have bugs with empty extensions.



Yasskin & Ueno            Expires March 8, 2019                [Page 19]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   Leaf certificates without this extension need to be revoked if the
   private key is exposed to an unauthorized entity, but they generally
   don't need to be revoked if a signing oracle is exposed and then
   removed.

   CA certificates, by contrast, need to be revoked if an unauthorized
   entity is able to make even one unauthorized signature.

   Certificates with this extension MUST be revoked if an unauthorized
   entity is able to make even one unauthorized signature.

   Conforming CAs MUST NOT mark this extension as critical.

   Clients MUST NOT accept certificates with this extension in TLS
   connections (Section 4.4.2.2 of [I-D.ietf-tls-tls13]).

   This draft of the specification identifies the CanSignHttpExchanges
   extension with the id-ce-canSignHttpExchangesDraft OID:

   id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 }
   id-ce-canSignHttpExchangesDraft OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 }

   This OID might or might not be used as the final OID for the
   extension, so certificates including it might need to be reissued
   once the final RFC is published.

5.  Transferring a signed exchange

   A signed exchange can be transferred in several ways, of which three
   are described here.

5.1.  Same-origin response

   The signature for a signed exchange can be included in a normal HTTP
   response.  Because different clients send different request header
   fields, and intermediate servers add response header fields, it can
   be impossible to have a signature for the exact request and response
   that the client sees.  Therefore, when a client calls the validation
   procedure in Section 3.5) to validate the "Signature" header field
   for an exchange represented as a normal HTTP request/response pair,
   it MUST pass:

   o  The "Signature" header field,

   o  The effective request URI (Section 5.5 of [RFC7230]) of the
      request,

   o  The serialized headers defined by Section 5.1.1, and



Yasskin & Ueno            Expires March 8, 2019                [Page 20]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   o  The response's payload.

   If the client relies on signature validity for any aspect of its
   behavior, it MUST ignore any header fields that it didn't pass to the
   validation procedure.

5.1.1.  Serialized headers for a same-origin response

   The serialized headers of an exchange represented as a normal HTTP
   request/response pair (Section 2.1 of [RFC7230] or Section 8.1 of
   [RFC7540]) are the canonical serialization (Section 3.4) of the CBOR
   representation (Section 3.2) of the following request and response
   metadata and headers:

   o  The method (Section 4 of [RFC7231]) of the request.

   o  The response status code (Section 6 of [RFC7231]) and the response
      header fields whose names are listed in that exchange's "Signed-
      Headers" header field (Section 5.1.2).  If a response header field
      name from "Signed-Headers" does not appear in the exchange's
      response header fields, the exchange has no serialized headers.

   If the exchange's "Signed-Headers" header field is not present,
   doesn't parse as a Structured Header
   ([I-D.ietf-httpbis-header-structure]) or doesn't follow the
   constraints on its value described in Section 5.1.2, the exchange has
   no serialized headers.

5.1.2.  The Signed-Headers Header

   The "Signed-Headers" header field identifies an ordered list of
   response header fields to include in a signature.  The request URL
   and response status are included unconditionally.  This allows a TLS-
   terminating intermediate to reorder headers without breaking the
   signature.  This _can_ also allow the intermediate to add headers
   that will be ignored by some higher-level protocols, but Section 3.5
   provides a hook to let other higher-level protocols reject such
   insecure headers.

   This header field appears once instead of being incorporated into the
   signatures' parameters because the signed header fields need to be
   consistent across all signatures of an exchange, to avoid forcing
   higher-level protocols to merge the header field lists of valid
   signatures.

   "Signed-Headers" is a Structured Header as defined by
   [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
   (Section 3.2 of [I-D.ietf-httpbis-header-structure]).  Its ABNF is:



Yasskin & Ueno            Expires March 8, 2019                [Page 21]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   Signed-Headers = sh-list

   Each element of the "Signed-Headers" list must be a lowercase string
   (Section 3.7 of [I-D.ietf-httpbis-header-structure]) naming an HTTP
   response header field.  Pseudo-header field names (Section 8.1.2.1 of
   [RFC7540]) MUST NOT appear in this list.

   Higher-level protocols SHOULD place requirements on the minimum set
   of headers to include in the "Signed-Headers" header field.

5.2.  HTTP/2 extension for cross-origin Server Push

   Cross origin push is not implemented.

5.3.  application/signed-exchange format

   To allow signed exchanges to be the targets of "<link rel=prefetch>"
   tags, we define the "application/signed-exchange" content type that
   represents a signed HTTP exchange, including request metadata and
   header fields, response metadata and header fields, and a response
   payload.

   This content type consists of the concatenation of the following
   items:

   1.  The ASCII characters "sxg1-b2" followed by a 0 byte, to serve as
       a file signature.  This is redundant with the MIME type, and
       recipients that receive both MUST check that they match and stop
       parsing if they don't.

       Note: As this is a snapshot of a draft of
       [I-D.yasskin-http-origin-signed-responses], it uses a distinct
       file signature.

   2.  2 bytes storing a big-endian integer "fallbackUrlLength".

   3.  "fallbackUrlLength" bytes holding a "fallbackUrl", which MUST be
       an absolute URL with a scheme of "https".

       Note: The byte location of the fallback URL is intended to remain
       invariant across versions of the "application/signed-exchange"
       format so that parsers encountering unknown versions can always
       find a URL to redirect to.

       Issue: Should this fallback information also include the method?

   4.  3 bytes storing a big-endian integer "sigLength".  If this is
       larger than 16384 (16*1024), parsing MUST fail.



Yasskin & Ueno            Expires March 8, 2019                [Page 22]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   5.  3 bytes storing a big-endian integer "headerLength".  If this is
       larger than 524288 (512*1024), parsing MUST fail.

   6.  "sigLength" bytes holding the "Signature" header field's value
       (Section 3.1).

   7.  "headerLength" bytes holding "signedHeaders", the canonical
       serialization (Section 3.4) of the CBOR representation of the
       request and response headers of the exchange represented by the
       "application/signed-exchange" resource (Section 3.2), excluding
       the "Signature" header field.

       Note that this is exactly the bytes used when checking signature
       validity in Section 3.5.

   8.  The payload body (Section 3.3 of [RFC7230]) of the exchange
       represented by the "application/signed-exchange" resource.

       Note that the use of the payload body here means that a
       "Transfer-Encoding" header field inside the "application/signed-
       exchange" header block has no effect.  A "Transfer-Encoding"
       header field on the outer HTTP response that transfers this
       resource still has its normal effect.

5.3.1.  Cross-origin trust in application/signed-exchange

   To determine whether to trust a cross-origin exchange stored in an
   "application/signed-exchange" resource, pass the "Signature" header
   field's value, "fallbackUrl" as the effective request URI,
   "signedHeaders", and the payload body to the algorithm in Section 4.

5.3.2.  Example

   An example "application/signed-exchange" file representing a possible
   signed exchange with https://example.com/ [8] follows, with lengths
   represented by descriptions in "<>"s, CBOR represented in the
   extended diagnostic format defined in Appendix G of
   [I-D.ietf-cbor-cddl], and most of the "Signature" header field and
   payload elided with a ...:












Yasskin & Ueno            Expires March 8, 2019                [Page 23]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   sxg1-b2\0<2-byte length of the following url string>
   https://example.com/<3-byte length of the following header
   value><3-byte length of the encoding of the
   following array>sig1; sig=*...; integrity="digest/mi-sha256-03"; ...[
     {
       ':method': 'GET',
       'accept', '*/*'
     },
     {
       ':status': '200',
       'content-type': 'text/html'
     }
   ]<!doctype html>\r\n<html>...

6.  Security considerations

   All of the security considerations from Section 6 of
   [I-D.yasskin-http-origin-signed-responses] apply.

7.  Privacy considerations

   Normally, when a client fetches "https://o1.com/resource.js",
   "o1.com" learns that the client is interested in the resource.  If
   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
   o1resource.js", and the client fetches it from there, then "o2.com"
   learns that the client is interested, and if the client executes the
   Javascript, that could also report the client's interest back to
   "o1.com".

   Often, "o2.com" already knew about the client's interest, because
   it's the entity that directed the client to "o1resource.js", but
   there may be cases where this leaks extra information.

   For non-executable resource types, a signed response can improve the
   privacy situation by hiding the client's interest from the original
   publisher.

   To prevent network operators other than "o1.com" or "o2.com" from
   learning which exchanges were read, clients SHOULD only load
   exchanges fetched over a transport that's protected from
   eavesdroppers.  This can be difficult to determine when the exchange
   is being loaded from local disk, but when the client itself requested
   the exchange over a network it SHOULD require TLS
   ([I-D.ietf-tls-tls13]) or a successor transport layer, and MUST NOT
   accept exchanges transferred over plain HTTP without TLS.






Yasskin & Ueno            Expires March 8, 2019                [Page 24]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


8.  IANA considerations

   This depends on the following IANA registrations in
   [I-D.yasskin-http-origin-signed-responses]:

   o  The "Signature" header field

   o  The "Accept-Signature" header field

   o  The "Signed-Headers" header field

   o  The application/cert-chain+cbor media type

   This document also modifies the registration for:

8.1.  Internet Media Type application/signed-exchange

   Type name: application

   Subtype name: signed-exchange

   Required parameters:

   o  v: A string denoting the version of the file format.  ([RFC5234]
      ABNF: "version = DIGIT/%x61-7A") The version defined in this
      specification is "b2".  When used with the "Accept" header field
      (Section 5.3.1 of [RFC7231]), this parameter can be a comma
      (,)-separated list of version strings.  ([RFC5234] ABNF: "version-
      list = version *( "," version )") The server is then expected to
      reply with a resource using a particular version from that list.

      Note: As this is a snapshot of a draft of
      [I-D.yasskin-http-origin-signed-responses], it uses a distinct
      version number.

   Magic number(s): 73 78 67 31 2D 62 32 00

   The other fields are the same as the registration in
   [I-D.yasskin-http-origin-signed-responses].

9.  References

9.1.  Normative References

   [FETCH]    WHATWG, "Fetch", September 2018,
              <https://fetch.spec.whatwg.org/>.





Yasskin & Ueno            Expires March 8, 2019                [Page 25]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   [I-D.ietf-cbor-cddl]
              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
              definition language (CDDL): a notational convention to
              express CBOR and JSON data structures", draft-ietf-cbor-
              cddl-05 (work in progress), August 2018.

   [I-D.ietf-httpbis-header-structure]
              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
              draft-ietf-httpbis-header-structure-07 (work in progress),
              July 2018.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
              March 2018.

   [I-D.yasskin-http-origin-signed-responses]
              Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http-
              origin-signed-responses-04 (work in progress), June 2018.

   [POSIX]    IEEE and The Open Group, "The Open Group Base
              Specifications Issue 7", name IEEE, value 1003.1-2008,
              2016 Edition, 2016,
              <http://pubs.opengroup.org/onlinepubs/9699919799/
              basedefs/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.




Yasskin & Ueno            Expires March 8, 2019                [Page 26]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,
              <https://www.rfc-editor.org/info/rfc7234>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [URL]      WHATWG, "URL", September 2018,
              <https://url.spec.whatwg.org/>.

9.2.  Informative References

   [I-D.thomson-http-mice]
              Thomson, M. and J. Yasskin, "Merkle Integrity Content
              Encoding", draft-thomson-http-mice-03 (work in progress),
              August 2018.

   [I-D.yasskin-http-origin-signed-responses-03]
              Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http-
              origin-signed-responses-03 (work in progress), March 2018,
              <https://tools.ietf.org/html/
              draft-yasskin-http-origin-signed-responses-03>.




Yasskin & Ueno            Expires March 8, 2019                [Page 27]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   [I-D.yasskin-http-origin-signed-responses-04]
              Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http-
              origin-signed-responses-04 (work in progress), June 2018,
              <https://tools.ietf.org/html/
              draft-yasskin-http-origin-signed-responses-04>.

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000,
              <https://www.rfc-editor.org/info/rfc2965>.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,
              <https://www.rfc-editor.org/info/rfc6265>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/info/rfc6455>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <https://www.rfc-editor.org/info/rfc7235>.

   [RFC7615]  Reschke, J., "HTTP Authentication-Info and Proxy-
              Authentication-Info Response Header Fields", RFC 7615,
              DOI 10.17487/RFC7615, September 2015,
              <https://www.rfc-editor.org/info/rfc7615>.

   [RFC8053]  Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
              T., and Y. Ioku, "HTTP Authentication Extensions for
              Interactive Clients", RFC 8053, DOI 10.17487/RFC8053,
              January 2017, <https://www.rfc-editor.org/info/rfc8053>.

   [W3C.NOTE-OPS-OverHTTP]
              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
              NOTE-OPS-OverHTTP, June 1997.

9.3.  URIs

   [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

   [2] https://github.com/WICG/webpackage




Yasskin & Ueno            Expires March 8, 2019                [Page 28]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   [3] https://url.spec.whatwg.org/#concept-url-parser

   [4] https://url.spec.whatwg.org/#absolute-url-string

   [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
       V1_chap04.html#tag_04_16

   [6] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml

   [7] https://html.spec.whatwg.org/multipage/origin.html#same-origin

   [8] https://example.com/

Appendix A.  Change Log

   draft-02

   Vs. draft-01:

   o  Define absolute URLs, and limit the schemes each instance can use.

   o  Update to mice-03 including the Digest header.

   o  Define the "integrity" field of the Signature header to include
      the digest algorithm.

   o  Put a fallback URL at the beginning of the "application/signed-
      exchange" format, and remove ':url' key from the CBOR
      representation of the exchange's request and response metadata and
      headers.

   o  The new signed message format which embeds the exact bytes of the
      CBOR representation of the exchange's request and response
      metadata and headers.

   o  When validating the signature validity, move the "payload"
      integrity check steps to after verifying "header".

   o  Versions in file signatures and context strings are "b2".

   draft-01

   Vs.  [I-D.yasskin-http-origin-signed-responses-04]:

   o  The MI header and mi-sha256 content-encoding are renamed to MI-
      Draft2 and mi-sha256-draft2 in case [I-D.thomson-http-mice]
      changes.




Yasskin & Ueno            Expires March 8, 2019                [Page 29]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   o  Signed exchanges cannot be transmitted using HTTP/2 Push.

   o  Removed non-normative sections.

   o  The mi-sha256 encoding must have records <= 16kB.

   o  The signature must be <=16kB long.

   o  The HTTP request and response headers together must be <=512kB.

   o  Versions in file signatures and context strings are "b1".

   o  Only 1 signature is supported.

   o  Removed support for ed25519 signatures.

   draft-00

   Vs.  [I-D.yasskin-http-origin-signed-responses-03]:

   o  Removed non-normative sections.

   o  Only 1 signature is supported.

   o  Only 2048-bit RSA keys are supported.

   o  The certificate chain resource uses the TLS 1.3 Certificate
      message format rather than a CBOR-based format.

   o  OCSP responses and SCTs are not checked.

   o  Certificates without the CanSignHttpExchanges extension are
      allowed.

   o  The signature string starts with 64 0x20 octets like the TLS 1.3
      signature format.

   o  The application/http-exchange+cbor format is replaced with a more
      specialized application/signed-exchange format.

   o  Signed exchanges can only be transmitted using the application/
      signed-exchange format, not HTTP/2 Push or plain HTTP request/
      response pairs.

   o  Only the MI payload-integrity header is supported.

   o  The mi-sha256 encoding must have records <= 16kB.




Yasskin & Ueno            Expires March 8, 2019                [Page 30]


Internet-DraftSigned HTTP Exchanges Implementation CheckpoSeptember 2018


   o  The Accept-Signature header isn't used.

   o  Require absolute URLs.

Appendix B.  Acknowledgements

   Thanks to Devin Mullins, Ilari Liusvaara, Justin Schuh, Mark
   Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for comments
   that improved this draft.

Authors' Addresses

   Jeffrey Yasskin
   Google

   Email: jyasskin@chromium.org


   Kouhei Ueno
   Google

   Email: kouhei@chromium.org





























Yasskin & Ueno            Expires March 8, 2019                [Page 31]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/