Network Working Group J. Yasskin Internet-Draft Google Intended status: Standards Track 27 July 2020 Expires: 28 January 2021 Signed HTTP Exchanges draft-yasskin-http-origin-signed-responses-09 Abstract This document specifies how a server can send an HTTP exchange--a request URL, content negotiation information, and a response--with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks. 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/ (https://lists.w3.org/Archives/Public/ietf-http-wg/). The source code and issues list for this draft can be found in https://github.com/WICG/webpackage (https://github.com/WICG/ webpackage). 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." Yasskin Expires 28 January 2021 [Page 1] Internet-Draft Signed HTTP Exchanges July 2020 This Internet-Draft will expire on 28 January 2021. Copyright Notice Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Signing an exchange . . . . . . . . . . . . . . . . . . . . . 5 3.1. The Signature Header . . . . . . . . . . . . . . . . . . 6 3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Open Questions . . . . . . . . . . . . . . . . . . . 9 3.2. CBOR representation of exchange response headers . . . . 9 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Loading a certificate chain . . . . . . . . . . . . . . . 10 3.4. Canonical CBOR serialization . . . . . . . . . . . . . . 11 3.5. Signature validity . . . . . . . . . . . . . . . . . . . 12 3.5.1. Open Questions . . . . . . . . . . . . . . . . . . . 16 3.6. Updating signature validity . . . . . . . . . . . . . . . 16 3.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 17 3.7. The Accept-Signature header . . . . . . . . . . . . . . . 19 3.7.1. Integrity identifiers . . . . . . . . . . . . . . . . 20 3.7.2. Key type identifiers . . . . . . . . . . . . . . . . 20 3.7.3. Key value identifiers . . . . . . . . . . . . . . . . 20 3.7.4. Examples . . . . . . . . . . . . . . . . . . . . . . 21 3.7.5. Open Questions . . . . . . . . . . . . . . . . . . . 21 4. Cross-origin trust . . . . . . . . . . . . . . . . . . . . . 22 4.1. Uncached header fields . . . . . . . . . . . . . . . . . 23 4.1.1. Stateful header fields . . . . . . . . . . . . . . . 24 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 25 4.2.1. Extensions to the CAA Record: cansignhttpexchanges Parameter . . . . . . . . . . . . . . . . . . . . . . 26 5. Transferring a signed exchange . . . . . . . . . . . . . . . 26 5.1. Same-origin response . . . . . . . . . . . . . . . . . . 27 5.1.1. Serialized headers for a same-origin response . . . . 27 5.1.2. The Signed-Headers Header . . . . . . . . . . . . . . 28 Yasskin Expires 28 January 2021 [Page 2] Internet-Draft Signed HTTP Exchanges July 2020 5.2. HTTP/2 extension for cross-origin Server Push . . . . . . 28 5.2.1. Indicating support for cross-origin Server Push . . . 28 5.2.2. NO_TRUSTED_EXCHANGE_SIGNATURE error code . . . . . . 29 5.2.3. Validating a cross-origin Push . . . . . . . . . . . 29 5.3. application/signed-exchange format . . . . . . . . . . . 30 5.3.1. Cross-origin trust in application/signed-exchange . . 31 5.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.3. Open Questions . . . . . . . . . . . . . . . . . . . 32 6. Security considerations . . . . . . . . . . . . . . . . . . . 32 6.1. Over-signing . . . . . . . . . . . . . . . . . . . . . . 32 6.1.1. Session fixation . . . . . . . . . . . . . . . . . . 33 6.1.2. Misleading content . . . . . . . . . . . . . . . . . 33 6.2. Off-path attackers . . . . . . . . . . . . . . . . . . . 33 6.2.1. Mis-issued certificates . . . . . . . . . . . . . . . 33 6.2.2. Stolen private keys . . . . . . . . . . . . . . . . . 34 6.3. Downgrades . . . . . . . . . . . . . . . . . . . . . . . 35 6.4. Signing oracles are permanent . . . . . . . . . . . . . . 35 6.5. Unsigned headers . . . . . . . . . . . . . . . . . . . . 35 6.6. application/signed-exchange . . . . . . . . . . . . . . . 36 6.7. Key re-use with TLS . . . . . . . . . . . . . . . . . . . 36 6.8. Content sniffing . . . . . . . . . . . . . . . . . . . . 36 7. Privacy considerations . . . . . . . . . . . . . . . . . . . 37 7.1. Visibility of resource requests . . . . . . . . . . . . . 38 7.2. User ID transfer . . . . . . . . . . . . . . . . . . . . 39 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 39 8.1. Signature Header Field Registration . . . . . . . . . . . 39 8.2. Accept-Signature Header Field Registration . . . . . . . 39 8.3. Signed-Headers Header Field Registration . . . . . . . . 40 8.4. HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . . 40 8.5. HTTP/2 Error code . . . . . . . . . . . . . . . . . . . . 40 8.6. Internet Media Type application/signed-exchange . . . . . 41 8.7. Internet Media Type application/cert-chain+cbor . . . . . 42 8.8. The cansignhttpexchanges CAA Parameter . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References . . . . . . . . . . . . . . . . . . 43 9.2. Informative References . . . . . . . . . . . . . . . . . 46 Appendix A. Use cases . . . . . . . . . . . . . . . . . . . . . 49 A.1. PUSHed subresources . . . . . . . . . . . . . . . . . . . 49 A.2. Explicit use of a content distributor for subresources . 49 A.3. Subresource Integrity . . . . . . . . . . . . . . . . . . 50 A.4. Binary Transparency . . . . . . . . . . . . . . . . . . . 50 A.5. Static Analysis . . . . . . . . . . . . . . . . . . . . . 51 A.6. Offline websites . . . . . . . . . . . . . . . . . . . . 51 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 51 B.1. Proof of origin . . . . . . . . . . . . . . . . . . . . . 51 B.1.1. Certificate constraints . . . . . . . . . . . . . . . 51 B.1.2. Signature constraints . . . . . . . . . . . . . . . . 52 B.1.3. Retrieving the certificate . . . . . . . . . . . . . 52 Yasskin Expires 28 January 2021 [Page 3] Internet-Draft Signed HTTP Exchanges July 2020 B.2. How much to sign . . . . . . . . . . . . . . . . . . . . 53 B.2.1. Conveying the signed headers . . . . . . . . . . . . 53 B.3. Response lifespan . . . . . . . . . . . . . . . . . . . . 54 B.3.1. Certificate revocation . . . . . . . . . . . . . . . 54 B.3.2. Response downgrade attacks . . . . . . . . . . . . . 54 B.4. Low implementation complexity . . . . . . . . . . . . . . 55 B.4.1. Limited choices . . . . . . . . . . . . . . . . . . . 55 B.4.2. Bounded-buffering integrity checking . . . . . . . . 55 Appendix C. Determining validity using cache control . . . . . . 56 C.1. Example of updating cache control . . . . . . . . . . . . 56 C.2. Downsides of updating cache control . . . . . . . . . . . 57 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 57 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60 1. Introduction Signed HTTP exchanges provide a way to prove the authenticity of a resource in cases where the transport layer isn't sufficient. This can be used in several ways: * When signed by a certificate ([RFC5280]) that's trusted for an origin, an exchange can be treated as authoritative for that origin, even if it was transferred over a connection that isn't authoritative (Section 9.1 of [RFC7230]) for that origin. See Appendix A.1 and Appendix A.2. * A top-level resource can use a public key to identify an expected publisher for particular subresources, a system known as Subresource Integrity ([SRI]). An exchange's signature provides the matching proof of authorship. See Appendix A.3. * A signature can vouch for the exchange in some way, for example that it appears in a transparency log or that static analysis indicates that it omits certain attacks. See Appendix A.4 and Appendix A.5. Subsequent work toward the use cases in [I-D.yasskin-wpack-use-cases] will provide a way to group signed exchanges into bundles that can be transmitted and stored together, but single signed exchanges are useful enough to standardize on their own. 2. Terminology Absolute URL A string for which the URL parser (https://url.spec.whatwg.org/#concept-url-parser) ([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 Yasskin Expires 28 January 2021 [Page 4] Internet-Draft Signed HTTP Exchanges July 2020 absolute-URL string (https://url.spec.whatwg.org/#absolute-url- string) 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 URL, content negotiation information, and an HTTP response. This can be encoded into a request message from a client with its matching response from a server, into the request in a PUSH_PROMISE with its matching response stream, or into the dedicated format in Section 5.3, which uses [I-D.ietf-httpbis-variants] to encode the content negotiation information. This is not quite the same meaning as defined by Section 8 of [RFC7540], which assumes the content negotiation information is embedded into HTTP request headers. 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 (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html#tag_04_16). 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. 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). Yasskin Expires 28 January 2021 [Page 5] Internet-Draft Signed HTTP Exchanges July 2020 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 URL, response 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 list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature. Each signature directly signs the exchange's URL and response 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.4 of [I-D.ietf-httpbis-header-structure]). Its ABNF is: Signature = sh-param-list Each parameterised identifier in the list MUST have parameters named "sig", "integrity", "validity-url", "date", and "expires". Each parameterised identifier MUST also have either "cert-url" and "cert- sha256" parameters or an "ed25519key" parameter. This specification gives no meaning to the identifier itself, which can be used as a human-readable identifier for the signature (however, this is likely to change soon; see Section 3.1.2, Paragraph 1). The present parameters MUST have the following values: "sig" Byte sequence (Section 3.10 of [I-D.ietf-httpbis-header-structure]) holding the signature of most of these parameters and the exchange's URL and response headers. "integrity" A string (Section 3.8 of Yasskin Expires 28 January 2021 [Page 6] Internet-Draft Signed HTTP Exchanges July 2020 [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.8 of [I-D.ietf-httpbis-header-structure]) containing an absolute URL (Section 2) with a scheme of "https" or "data". "cert-sha256" Byte sequence (Section 3.10 of [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of the first certificate found at "cert-url". "ed25519key" Byte sequence (Section 3.10 of [I-D.ietf-httpbis-header-structure]) holding an Ed25519 public key ([RFC8032]). "validity-url" A string (Section 3.8 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.6 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. Yasskin Expires 28 January 2021 [Page 7] Internet-Draft Signed HTTP Exchanges July 2020 Signature: sig1; sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*; integrity="digest/mi-sha256"; validity-url="https://example.com/resource.validity.1511128380"; cert-url="https://example.com/oldcerts"; cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*; date=1511128380; expires=1511733180, sig2; sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg==*; integrity="digest/mi-sha256"; validity-url="https://example.com/resource.validity.1511128380"; cert-url="https://example.com/newcerts"; cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; date=1511128380; expires=1511733180, srisig; sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA==*; integrity="digest/mi-sha256"; validity-url="https://example.com/resource.validity.1511128380"; ed25519key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8=* date=1511128380; expires=1511733180, thirdpartysig; sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+*; integrity="digest/mi-sha256"; validity-url="https://thirdparty.example.com/resource.validity.1511161860"; cert-url="https://thirdparty.example.com/certs"; cert-sha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc=*; date=1511133060; expires=1511478660, There are 4 signatures: 2 from different secp256r1 certificates within "https://example.com/", one using a raw ed25519 public key that's also controlled by "example.com", and a fourth using a secp256r1 certificate owned by "thirdparty.example.com". All 4 signatures rely on the "Digest" response header with the mi- sha256 digest algorithm to guard the integrity of the response payload. The signatures include 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 certificates at "https://example.com/oldcerts" and "https://example.com/newcerts" have "subjectAltName"s of "example.com", meaning that if they and their signatures validate, the exchange can be trusted as having an origin of Yasskin Expires 28 January 2021 [Page 8] Internet-Draft Signed HTTP Exchanges July 2020 "https://example.com/". The publisher might be using two certificates because their readers have disjoint sets of roots in their trust stores. The publisher signed with all three certificates at the same time, so they share a validity range: 7 days starting at 2017-11-19 21:53 UTC. The publisher then requested an additional signature from "thirdparty.example.com", which did some validation or processing and then signed the resource at 2017-11-19 23:11 UTC. "thirdparty.example.com" only grants 4-day signatures, so clients will need to re-validate more often. 3.1.2. Open Questions The next revision of [I-D.ietf-httpbis-header-structure] will provide a way to parameterise byte sequences, at which point the signature itself is likely to become the main list item. Should the cert-url and validity-url be lists so that intermediates can offer a cache without losing the original URLs? Putting lists in dictionary fields is more complex than [I-D.ietf-httpbis-header-structure] allows, so they're single items for now. 3.2. CBOR representation of exchange response headers To sign an exchange's response headers, they need to be serialized into a byte string. Since intermediaries and distributors (Appendix A.2) 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 response metadata and headers is the CBOR ([RFC7049]) map with the following mappings: * 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. 3.2.1. Example Given the HTTP exchange: Yasskin Expires 28 January 2021 [Page 9] Internet-Draft Signed HTTP Exchanges July 2020 GET / HTTP/1.1 Host: example.com Accept: */* HTTP/1.1 200 Content-Type: text/html Digest: mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs= Signed-Headers: "content-type", "digest" ... The cbor representation consists of the following item, represented using the extended diagnostic notation from [CDDL] appendix G: { 'digest': 'mi-sha256=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 = [ "📜⛓", ; U+1F4DC U+26D3 + augmented-certificate ] augmented-certificate = { cert: bytes, ? ocsp: bytes, ? sct: bytes, * tstr => any, } 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. Yasskin Expires 28 January 2021 [Page 10] Internet-Draft Signed HTTP Exchanges July 2020 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: * Integers and the lengths of arrays, maps, and strings MUST use the smallest possible encoding. * Items MUST NOT be encoded with indefinite length. * 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. Yasskin Expires 28 January 2021 [Page 11] Internet-Draft Signed HTTP Exchanges July 2020 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.5 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 * "requestUrl", a byte sequence that can be parsed into the exchange's effective request URI (Section 5.5 of [RFC7230]), * "responseHeaders", a byte sequence holding the canonical serialization (Section 3.4) of the CBOR representation (Section 3.2) of the exchange's response metadata and headers, and * "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. Potentially-valid results include: * The signed headers of the exchange so that higher-level protocols can avoid relying on unsigned headers, and * Either a certificate chain or a public key so that a higher-level protocol can determine whether it's actually valid. Yasskin Expires 28 January 2021 [Page 12] Internet-Draft Signed HTTP Exchanges July 2020 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: * "signature" be the signature (byte sequence 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. * "ed25519key" be the signature's "ed25519key" 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. 2. Set "publicKey" and "signing-alg" depending on which key fields are present: 1. If "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". 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". Yasskin Expires 28 January 2021 [Page 13] Internet-Draft Signed HTTP Exchanges July 2020 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 [RFC8446]. 6. Otherwise, either return "invalid" or set "signing-alg" to a non-legacy signing algorithm defined by TLS 1.3 or later ([RFC8446]). This choice MUST depend only on "publicKey"'s type and not on any other context. 2. If "ed25519key" is present, set "publicKey" to "ed25519key" and "signing-alg" to ed25519, as defined by [RFC8032] 3. If "expires" is more than 7 days (604800 seconds) after "date", return "invalid". 4. If the current time is before "date" or after "expires", return "invalid". 5. Let "message" be the concatenation of the following byte strings. This matches the [RFC8446] 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". Note: RFC EDITOR PLEASE DELETE THIS NOTE; The implementation of the final RFC MUST use this context string, but implementations of drafts MUST NOT use it and MUST use another draft-specific string beginning with "HTTP Exchange 1 " instead. This ensures that signers can predict how their signatures will be used. 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". Yasskin Expires 28 January 2021 [Page 14] Internet-Draft Signed HTTP Exchanges July 2020 8. The 8-byte big-endian encoding of the length in bytes of "requestUrl", followed by the bytes of "requestUrl". 9. The 8-byte big-endian encoding of the length in bytes of "responseHeaders", followed by the bytes of "responseHeaders". 6. 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 [RFC8446]), in order to allow updating the stapled OCSP response without updating signatures at the same time. 7. If "signature" is not a valid signature of "message" by "publicKey" using "signing-alg", return "invalid". 8. If "headers", interpreted according to Section 3.2, does not contain a "Content-Type" response header field (Section 3.1.1.5 of [RFC7231]), return "invalid". Clients MUST interpret the signed payload as this specified media type instead of trying to sniff a media type from the bytes of the payload, for example by attaching an "X-Content- Type-Options: nosniff" header field ([FETCH]) to the extracted response. 9. If "integrity" names a header field and parameter that is not present in "responseHeaders" or which the client cannot use to check the integrity of "payload" (for example, the header field is new and hasn't been implemented yet), then return "invalid". If the selected header field provides integrity guarantees weaker than SHA-256, return "invalid". If validating integrity using the selected header field requires the client to process records larger than 16384 bytes, return "invalid". Clients MUST implement at least the "Digest" header field with its "mi- sha256" digest algorithm (Section 3 of [I-D.thomson-http-mice]). Note: RFC EDITOR PLEASE DELETE THIS NOTE; Implementations of drafts of this RFC MUST recognize the draft spelling of the content encoding and digest algorithm specified by [I-D.thomson-http-mice] until that draft is published as an RFC. For example, implementations of draft-thomson-http-mice-03 would use "mi-sha256-03" and MUST NOT use "mi-sha256" itself. This Yasskin Expires 28 January 2021 [Page 15] Internet-Draft Signed HTTP Exchanges July 2020 ensures that final implementations don't need to handle compatibility with implementations of early drafts of that content encoding. If "payload" doesn't match the integrity information in the header described by "integrity", return "invalid". 10. Return "potentially-valid" with whichever is present of "certificate-chain" or "ed25519key". 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" ([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.5.1. Open Questions Should the signed message use the TLS format (with an initial 64 spaces) even though these certificates can't be used in TLS servers? 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. The "validity-url" parameter (Section 3.1) 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. Yasskin Expires 28 January 2021 [Page 16] Internet-Draft Signed HTTP Exchanges July 2020 The resource at a "validity-url" is "validity data", a CBOR map matching the following CDDL ([CDDL]): validity = { ? signatures: [ + bytes ] ? update: { ? size: uint, } ] The elements of the "signatures" array are parameterised identifiers (Section 4.2.6 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 Expires 28 January 2021 [Page 17] Internet-Draft Signed HTTP Exchanges July 2020 Signature: sig1; sig=*MEUCIQ...*; ... validity-url="https://example.com/resource.validity.1511157180"; cert-url="https://example.com/oldcerts"; date=1511128380; expires=1511733180, sig2; sig=*MEQCIG...*; ... validity-url="https://example.com/resource.validity.1511157180"; cert-url="https://example.com/newcerts"; date=1511128380; expires=1511733180, thirdpartysig; sig=*MEYCIQ...*; ... validity-url="https://thirdparty.example.com/resource.validity.1511161860"; cert-url="https://thirdparty.example.com/certs"; date=1511478660; expires=1511824260 At 2017-11-27 11:02 UTC, "sig1" and "sig2" have expired, but "thirdpartysig" doesn't exipire until 23:11 that night, so the client needs to fetch "https://example.com/resource.validity.1511157180" (the "validity-url" of "sig1" and "sig2") if it wishes to update those signatures. This URL might contain: { "signatures": [ 'sig1; ' 'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; ' 'validity-url="https://example.com/resource.validity.1511157180"; ' 'integrity="digest/mi-sha256"; ' 'cert-url="https://example.com/newcerts"; ' 'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; ' 'date=1511733180; expires=1512337980' ], "update": { "size": 5557452 } } Yasskin Expires 28 January 2021 [Page 18] Internet-Draft Signed HTTP Exchanges July 2020 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 first two of the original signatures (the ones with a validity-url of "https://example.com/resource.validity.1511157180") with the single new signature provided. (This might happen at the end of a migration to a new root certificate.) The signatures 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, thirdpartysig; sig=*MEYCIQ...*; ... validity-url="https://thirdparty.example.com/resource.validity.1511161860"; cert-url="https://thirdparty.example.com/certs"; date=1511478660; expires=1511824260 "https://example.com/resource.validity.1511157180" could also expand the set of signatures if its "signatures" array contained more than 2 elements. 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 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.4 of [I-D.ietf-httpbis-header-structure]). Its ABNF is: Yasskin Expires 28 January 2021 [Page 19] Internet-Draft Signed HTTP Exchanges July 2020 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 (https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml) 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" 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. 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 a byte sequence (Section 3.10 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 Yasskin Expires 28 January 2021 [Page 20] Internet-Draft Signed HTTP Exchanges July 2020 "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 a byte sequence. Note that "ed25519key; **" is an empty prefix, which matches all public keys, so it's useful in subresource integrity (Appendix A.3) cases like "" where the public key isn't known until the matching "