Network Working Group J. Yasskin Internet-Draft Google Intended status: Standards Track 22 September 2021 Expires: 26 March 2022 Web Bundles draft-ietf-wpack-bundled-responses-latest Abstract Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs that produced them, to transmit or store together. They can include multiple top-level resources, provide random access to their component exchanges, and efficiently store 8-bit resources. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Packaging Working Group mailing list (wpack@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wpack/. Source for this draft and an issue tracker can be found at https://github.com/wpack-wg/bundled-responses. 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 26 March 2022. Copyright Notice Copyright (c) 2021 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 (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 1.1. Terminology and Conventions 2. Semantics 2.1. Operations 2.2. Naming a representation 3. Expected performance 3.1. Random access 3.2. Streaming 4. Format 4.1. Top-level structure 4.1.1. Trailing length 4.1.2. Draft version numbers 4.2. Bundle sections 4.2.1. The index section 4.2.2. The critical section 4.3. Responses 4.4. Serving constraints 5. Security Considerations 5.1. Version skew 5.2. Content sniffing 6. IANA considerations 6.1. Internet Media Type Registration 6.2. Web Bundle Section Name Registry 7. References 7.1. Normative References 7.2. Informative References Appendix A. Web bundle Format A.1. Bundle format A.1.1. Type: "bundle" A.1.2. Type: "section-length" A.2. Core sections A.2.1. The "index" section A.2.2. The "critical" section A.2.3. The "responses" section Appendix B. Change Log Appendix C. Acknowledgements Author's Address 1. Introduction To satisfy the use cases in [I-D.yasskin-wpack-use-cases], this document proposes a new bundling format to group HTTP resources. The format is structured as an initial table of "sections" within the bundle followed by the content of those sections. 1.1. Terminology and Conventions 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. This specification uses the conventions and terminology defined in the Infra Standard ([INFRA]). 2. Semantics A bundle is logically a set of HTTP representations (Section 3.2 of [I-D.ietf-httpbis-semantics]), themselves represented by HTTP response messages (Section 3.4 of [I-D.ietf-httpbis-semantics]). The bundle can include optional metadata, which may be required by particular applications. While the order of the representations is not semantically meaningful, it can significantly affect performance when the bundle is loaded from a network stream. 2.1. Operations Bundle parsers support two primary operations: 1. They can load the bundle's metadata given a prefix of the bundle. 2. They can find a representation within the bundle given that representation's URL (Section 2.2). 2.2. Naming a representation Representations within a bundle are named by their "Content-Location" (Section 8.7 of [I-D.ietf-httpbis-semantics]). This is also known as the representation's URL. It is either an absolute-URI or a partial- URI (Section 2.7 of [RFC7230]). In the latter case, the referenced URL is relative to the bundle's URL unless an additional section in the bundle specifies a different base URL. This identifying information for each representation is stored in an index (Section 4.2.1) rather than in that representation's HTTP response message. 3. Expected performance Bundles can be used in two different situations: they can be loaded from storage that provides O(1) access to any byte within the bundle, or they can be sent across a stream that provides bytes incrementally. An implementation MAY prefer either or both situations and SHOULD provide the following performance characteristics in its preferred situations: 3.1. Random access To load a resource when seeing a bundle for the first time, the implementation reads O(size of the metadata and resource index) before starting to return bytes of the resource. TODO: Is big-O notation the right way to express expectations here? 3.2. Streaming When sending a bundle over a stream, the implementation will need to wait until it has the sizes of all contained resources before starting to send the resource index. When reading a bundle from a stream, the implementation starts returning bytes of a resource after receiving O(1) bytes of that resource, which comes after the O(# of resources) bytes of the index. 4. Format 4.1. Top-level structure A bundle is a CBOR array ([CBORbis]) with the following CDDL ([CDDL]) schema: webbundle = [ magic: h'F0 9F 8C 90 F0 9F 93 A6', version: bytes .size 4, section-lengths: bytes .cbor section-lengths, sections: [* any ], length: bytes .size 8, ; Big-endian number of bytes in the bundle. ] whatwg-url = tstr When serialized, the bundle MUST satisfy the core deterministic encoding requirements from Section 4.2.1 of [CBORbis]. This format does not use floating point values or tags, so this specification does not add any deterministic encoding rules for them. If an item doesn't follow these requirements, or a byte-sequence being decoded as a CBOR item contains extra bytes, the parser MUST signal an error instead of any data it can extract from that item. High-level fields in the bundle format are designed to provide their length-in-bytes before the field starts so that a recipient trying to stream a bundle from the network can always wait for a known number of bytes instead of needing to implement a streaming CBOR parser. The "magic" number is "🌐📦" (U+1F310 U+1F4E6) encoded in UTF-8. With the CBOR initial bytes for the array and bytestring, this makes the format identifiable by looking for "8? 48" (in base 16) followed by that UTF-8 encoding. Parsers MUST only check the initial nibble of the initial "8?" byte in order to accommodate any future version's change in the number of array elements (up to 15). The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII "1" followed by 3 0s) for this version of bundles. If the recipient doesn't support the version in this field, it MUST ignore the bundle. The "section-lengths" and "sections" arrays contain the actual content of the bundle and are defined in Section 4.2. The "section- lengths" array is embedded in a byte string to facilitate reading it from a network. This byte string MUST be less than 8192 (8*1024) bytes long, and parsers MUST NOT load any data from a "section- lengths" item longer than this. The bundle ends with an 8-byte integer holding the length of the whole bundle. 4.1.1. Trailing length A bundle ends with an 8-byte CBOR byte string holding a big-endian integer that represents the byte-length of the whole bundle. +------------+-----+----+----+----+----+----+----+----+----+----+ | first byte | ... | 48 | 00 | 00 | 00 | 00 | 00 | BC | 61 | 4E | +------------+-----+----+----+----+----+----+----+----+----+----+ / \ 0xBC614E-10=12345668 omitted bytes Figure 1: Example trailing bytes Recipients loading the bundle in a random-access context SHOULD start by reading the last 8 bytes and seeking backwards by that many bytes to find the start of the bundle, instead of assuming that the start of the file is also the start of the bundle. This allows the bundle to be appended to another format such as a generic self-extracting executable. 4.1.2. Draft version numbers This section is to be removed before publishing as an RFC. Implementations of drafts of this specification MUST NOT use a "version" string of "31 00 00 00" (base 16). They MUST instead define an implementation-specific 4-byte string starting with "62" ("b") to identify which draft is implemented. 4.2. Bundle sections A bundle's content is in a series of sections, which can be accessed randomly using the information in the "section-lengths" CBOR item: section-lengths = [* (section-name: tstr, length: uint) ], This field lists the named sections in the bundle in the order they appear, with each section name followed by the length in bytes of the corresponding CBOR item in the "sections" array. This allows a random-access parser (Section 3) to jump directly to the section it needs. This specification defines the following sections: * ""index"" (Section 4.2.1) * ""critical"" (Section 4.2.2) * ""responses"" (Section 4.3) Future specifications can register new section names as described in Section 6.2, in order to extend the format without incrementing its version number. The ""responses"" section MUST appear after the other three sections defined here, and parsers MUST NOT load any data if that is not the case. The "sections" array contains the sections' content. The length of this array MUST be exactly half the length of the "section-lengths" array, and parsers MUST NOT load any data if that is not the case. The bundle MUST contain the ""index"" and ""responses"" sections. All other sections are optional. 4.2.1. The index section index = {* whatwg-url => [ location-in-responses ] } location-in-responses = (offset: uint, length: uint) The ""index"" section defines the set of HTTP representations in the bundle and identifies their locations in the ""responses"" section. It consists of a CBOR map whose keys are the URLs of the representations in the bundle (Section 2.2). The value of an index entry is an offset/length pair. The offset is relative to the start of the ""responses"" section, with an offset of 0 referring to the head of the CBOR "responses" array itself. The length is the length in bytes of the "response" CBOR item holding this representation (Section 4.3). 4.2.2. The critical section critical = [*tstr] The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the bundle correctly. Other sections are assumed to be optional. If the client has not implemented a section named by one of the items in this list, the client MUST fail to parse the bundle as a whole. 4.3. Responses responses = [*response] response = [headers: bstr .cbor headers, payload: bstr] headers = {* bstr => bstr} The "responses" section holds the HTTP responses that represent the HTTP representations in the bundle. It consists of a CBOR array of responses, each of which is pointed to by one or more entries in the "index" section (Section 4.2.1). The length of the "headers" byte string in a response MUST be less than 524288 (512*1024) bytes, and recipients MUST fail to load a response with longer headers. When receiving a bundle in a stream, the recipient MAY process the headers before the payload has been received and MAY start processing the beginning of the payload before the end of the payload has been received. The keys of the headers map MUST consist of lowercase ASCII as described in Section 8.1.2 of [RFC7540]. Response pseudo-headers (Section 8.1.2.4 of [RFC7540] are included in this headers map. Each response's headers MUST include a ":status" pseudo-header with exactly 3 ASCII decimal digits and MUST NOT include any other pseudo- headers. If a response's payload is not empty, its headers MUST include a "Content-Type" header (Section 8.3 of [I-D.ietf-httpbis-semantics]). The client MUST interpret the following payload as this specified media type instead of trying to sniff a media type from the bytes of the payload, for example by appending an artificial "X-Content-Type- Options: nosniff" header field ([FETCH]) to downstream protocols. 4.4. Serving constraints When served over HTTP, a response containing an "application/ webbundle" payload MUST include at least the following response header fields, to reduce content sniffing vulnerabilities (Section 5.2): * Content-Type: application/webbundle * X-Content-Type-Options: nosniff 5. Security Considerations 5.1. Version skew Bundles currently have no mechanism for ensuring that any signed exchanges they contain constitute a consistent version of those resources. Even if a website never has a security vulnerability when resources are fetched at a single time, an attacker might be able to combine a set of resources pulled from different versions of the website to build a vulnerable site. While the vulnerable site could have occurred by chance on a client's machine due to normal HTTP caching, bundling allows an attacker to guarantee that it happens. Future work in this specification might allow a bundle to constrain its resources to come from a consistent version. 5.2. Content sniffing While modern browsers tend to trust the "Content-Type" header sent with a resource, especially when accompanied by "X-Content-Type- Options: nosniff", plugins will sometimes search for executable content buried inside a resource and execute it in the context of the origin that served the resource, leading to XSS vulnerabilities. For example, some PDF reader plugins look for "%PDF" anywhere in the first 1kB and execute the code that follows it. The "application/webbundle" format defined above includes URLs and request headers early in the format, which an attacker could use to cause these plugins to sniff a bad content type. To avoid vulnerabilities, in addition to the response header requirements in Section 4.4, servers are advised to only serve an "application/webbundle" resource from a domain if it would also be safe for that domain to serve the bundle's content directly, and to follow at least one of the following strategies: 1. Only serve bundles from dedicated domains that don't have access to sensitive cookies or user storage. 2. Generate bundles "offline", that is, in response to a trusted author submitting content or existing signatures reaching a certain age, rather than in response to untrusted-reader queries. 3. Do all of: 1. If the bundle's contained URLs (e.g. in the index) are derived from the request for the bundle, percent-encode (https://url.spec.whatwg.org/#percent-encode) ([URL]) any bytes that are greater than 0x7E or are not URL code points (https://url.spec.whatwg.org/#url-code-points) ([URL]) in these URLs. It is particularly important to make sure no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E) appear. 2. Similarly, if the request headers for any contained resource are based on the headers sent while requesting the bundle, only include request header field names *and values* that appear in a static allowlist. Keep the set of allowed request header fields smaller than 24 elements to prevent attackers from controlling a whole CBOR length byte. 3. Restrict the number of items a request can direct the server to include in a bundle to less than 12, again to prevent attackers from controlling a whole CBOR length byte. 4. Do not reflect request header fields into the set of response headers. If the server serves responses that are written by a potential attacker but then escaped, the "application/webbundle" format allows the attacker to use the length of the response to control a few bytes before the start of the response. Any existing mechanisms that prevent polyglot documents probably keep working in the face of this new attack, but we don't have a guarantee of that. To encourage servers to include the "X-Content-Type-Options: nosniff" header field, clients SHOULD reject bundles served without it. 6. IANA considerations 6.1. Internet Media Type Registration IANA is requested to register the MIME media type ([IANA.media-types]) for web bundles, application/webbundle, as follows: * Type name: application * Subtype name: webbundle * Required parameters: - v: A string denoting the version of the file format. ([RFC5234] ABNF: "version = 1*(DIGIT/%x61-7A)") The version defined in this specification is "1". Note: RFC EDITOR PLEASE DELETE THIS NOTE; Implementations of drafts of this specification MUST NOT use simple integers to describe their versions, and MUST instead define implementation-specific strings to identify which draft is implemented. * Optional parameters: N/A * Encoding considerations: binary * Security considerations: See Section 5 of this document. * Interoperability considerations: N/A * Published specification: This document * Applications that use this media type: None yet, but it is expected that web browsers will use this format. * Fragment identifier considerations: N/A * Additional information: - Deprecated alias names for this type: N/A - Magic number(s): 86 48 F0 9F 8C 90 F0 9F 93 A6 - File extension(s): .wbn - Macintosh file type code(s): N/A * Person & email address to contact for further information: See the Author's Address section of this specification. * Intended usage: COMMON * Restrictions on usage: N/A * Author: See the Author's Address section of this specification. * Change controller: The IESG iesg@ietf.org (mailto:iesg@ietf.org) * Provisional registration? Yes. 6.2. Web Bundle Section Name Registry IANA is directed to create a new registry with the following attributes: Name: Web Bundle Section Names Review Process: Specification Required Initial Assignments: +==============+===============+ | Section Name | Specification | +==============+===============+ | "index" | Section 4.2.1 | +--------------+---------------+ | "critical" | Section 4.2.2 | +--------------+---------------+ | "responses" | Section 4.3 | +--------------+---------------+ Table 1 Requirements on new assignments: Section Names MUST be encoded in UTF-8. A section's specification MAY say that, if it is present, another section is not processed. 7. References 7.1. Normative References [CBORbis] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [FETCH] WHATWG, "Fetch", September 2021, . [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, . [I-D.ietf-httpbis-semantics] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, . [IANA.media-types] IANA, "Media Types", . [INFRA] WHATWG, "Infra", September 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [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, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [URL] WHATWG, "URL", September 2021, . 7.2. Informative References [I-D.ietf-httpbis-variants] Nottingham, M., "HTTP Representation Variants", Work in Progress, Internet-Draft, draft-ietf-httpbis-variants-06, 3 November 2019, . [I-D.yasskin-wpack-use-cases] Yasskin, J., "Use Cases and Requirements for Web Packages", Work in Progress, Internet-Draft, draft- yasskin-wpack-use-cases-02, 13 April 2021, . Appendix A. Web bundle Format This appendix summarises the Web bundle format. Web bundles are defined in CDDL ([CDDL]), a language for expressing grammars over CBOR ([CBORbis]) binary data formats. Please refer to ([CDDL]) and ([CBORbis]) for the exact definition of the types used in this specification. To maintain compatibility across versions and environments, a Web bundle begins with a magic number (file signature) followed by a version number, and ends with the bundle's length. The version number is expected to not change, except as a last resort. At the top level of their binary format, Web bundles are defined as a series of named sections, each with a length. The "section-lengths" field contains a table of contents, and the sections are found in the main "sections" field. The bundle MUST contain the ""index"" and ""responses"" sections. All other sections are optional. Even though this format starts out with just three core sections, its architecture ensures that the format is extensible. Over time, more sections could be defined and used without causing a breaking change. Other binary formats such as WebAssembly bytecode (https://webassembly.github.io/spec/core/binary/ modules.html#sections) have made a similar design decision. A.1. Bundle format A.1.1. Type: "bundle" +=================+=======+==========+===========================+ | name | type | size | description | +=================+=======+==========+===========================+ | magic | bytes | 64 bits | "F0 9F 8C 90 F0 9F 93 A6" | | | | | (hexadecimal) | +-----------------+-------+----------+---------------------------+ | version | bytes | 32 bits | the version of the | | | | | specification | +-----------------+-------+----------+---------------------------+ | section-lengths | array | variable | array of _section-length_ | | | | | (Appendix A.1.2) | +-----------------+-------+----------+---------------------------+ | sections | array | variable | see _core sections_ | | | | | (Appendix A.2) | +-----------------+-------+----------+---------------------------+ | length | bytes | 64 bits | the length of the bundle | | | | | in bytes | +-----------------+-------+----------+---------------------------+ Table 2 CDDL spec: webbundle = [ magic: h'F0 9F 8C 90 F0 9F 93 A6', version: bytes .size 4, section-lengths: bytes .cbor section-lengths, sections: [* any ], length: bytes .size 8, ; Big-endian number of bytes in the bundle. ] Note: the basic type "bytes" (alternatively named "bstr"), defined as Major type 2 in the [CBORbis] specification, represents a byte string. A.1.2. Type: "section-length" +==============+======+==========+=========================+ | name | type | size | description | +==============+======+==========+=========================+ | section-name | tstr | variable | The name of the section | +--------------+------+----------+-------------------------+ | length | uint | variable | The length of the | | | | | section in bytes | +--------------+------+----------+-------------------------+ Table 3 CDDL spec: section-lengths = [* (section-name: tstr, length: uint) ] Note: the basic type "tstr", defined as Major type 3 in the [CBORbis] specification, represents a text string encoded as UTF-8. A.2. Core sections A.2.1. The "index" section The "index" section maps URLs ([URL]) to offset/length pairs in the "responses" (Appendix A.2.3) section. A.2.1.1. Type: "index" +=======+=======================+==========+=============+ | name | type | size | description | +=======+=======================+==========+=============+ | index | map (whatwg-url | variable | A map from | | | (Appendix A.2.1.2) => | | a URL to a | | | location-in-responses | | location | | | (Appendix A.2.1.3)) | | | +-------+-----------------------+----------+-------------+ Table 4 A.2.1.2. Type: "whatwg-url" +============+======+==========+===============================+ | name | type | size | description | +============+======+==========+===============================+ | whatwg-url | tstr | variable | A URL stored as a text string | +------------+------+----------+-------------------------------+ Table 5 A.2.1.3. Type: "location-in-responses" +========+======+==========+================================+ | name | type | size | description | +========+======+==========+================================+ | offset | uint | variable | An offset within the responses | | | | | (Appendix A.2.3) section | +--------+------+----------+--------------------------------+ | length | uint | variable | The size of the response in | | | | | bytes | +--------+------+----------+--------------------------------+ Table 6 CDDL spec: index = {* whatwg-url => [ location-in-responses ] } whatwg-url = tstr location-in-responses = (offset: uint, length: uint) Note: the basic type "uint", defined as Major type 0 in the [CBORbis] specification, represents an unsigned integer. A.2.2. The "critical" section The "critical" section contains the names of additional sections of the bundle that the client needs to understand in order to load the bundle correctly. The rest of the sections are assumed to be optional. If the client has not implemented a section named by one of the items in this list, the client MUST fail to parse the bundle as a whole. The "critical" section itself is optional. CDDL spec: critical = [*tstr] A.2.3. The "responses" section The "responses" section contains an array of HTTP responses ([HTTP]). Each response contains the response headers and the response body. A.2.3.1. Type: "response" +=========+=============+==========+===========================+ | name | type | size | description | +=========+=============+==========+===========================+ | headers | map ("bstr" | variable | A map of field name to | | | => "bstr") | | field value | +---------+-------------+----------+---------------------------+ | payload | bstr | variable | The content of the HTTP | | | | | response as a byte string | +---------+-------------+----------+---------------------------+ Table 7 CDDL spec: responses = [*response] response = [headers: bstr .cbor headers, payload: bstr] headers = {* bstr => bstr} Appendix B. Change Log This section is to be removed before publishing as an RFC. draft-02 * Removed primary URL, manifest and content negotiation. * Added bundle format appendix. draft-01 * Turned the top-level primary URL into an optional section. draft-00 * No changes from draft-yasskin-wpack-bundled-exchanges-04. draft-yasskin-wpack-bundled-exchanges-04 * Rewrite to be more declarative and less algorithmic. * Make a bundle represent a set of HTTP Representations, with the Content-Location replacing what was the request URL, and the Variants information, as before, driving content negotiation. * Make the primary URL optional. * Remove the signatures section. * Update Variants examples for the latest Variants draft. * Removed the distinction between "metadata" and non-metadata sections. draft-yasskin-wpack-bundled-exchanges-03 * Make the manifest optional. * Update the reference to draft-yasskin-wpack-use-cases. * Retitle to "web bundles". draft-yasskin-wpack-bundled-exchanges-02 * Fix the initial bytes of the format. * Allow empty responses to omit their content type. * Provisionally register application/webbundle. draft-yasskin-wpack-bundled-exchanges-01 * Include only section lengths in the section index, requiring sections to be listed in order. * Have the "index" section map URLs to sets of responses negotiated using the Variants system ([I-D.ietf-httpbis-variants]). * Require the "manifest" to be embedded into the bundle. * Add a content sniffing security consideration. * Add a version string to the format and its mime type. * Add a fallback URL in a fixed location in the format, and use that fallback URL as the primary URL of the bundle. * Add a "signatures" section to let authorities (like domain-trusted X.509 certificates) vouch for subsets of a bundle. * Use the CBORbis "deterministic encoding" requirements instead of "canonicalization" requirements. Appendix C. Acknowledgements Thanks to the Chrome loading team, especially Kinuko Yasuda and Kouhei Ueno for making the format work well when streamed. Author's Address Jeffrey Yasskin Google Email: jyasskin@chromium.org