Internet-Draft | Signed HTTP Exchanges Implementation Che | May 2023 |
Yasskin & Sakamoto | Expires 13 November 2023 | [Page] |
This document describes checkpoints of draft-yasskin-http-origin-signed-responses to synchronize implementation between clients, intermediates, and publishers.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the WPACK 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/WICG/webpackage.¶
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 13 November 2023.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
A string for which the 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 absolute-URL string concept defined by ([URL]) but might not include exactly the same strings.¶
The entity that wrote the content in a particular resource. This specification deals with publishers rather than authors.¶
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.¶
An HTTP request URL, content negotiation information, and an HTTP response. This are encoded into the dedicated format in Section 5.3, which uses [I-D.ietf-httpbis-variants-05] 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.¶
An entity that fetches signed HTTP exchanges from a publisher or another intermediate and forwards them to another intermediate or a 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.¶
Defined by [POSIX] section 4.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.¶
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 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.¶
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 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-10]. Its value MUST be a parameterised list
(Section 3.4 of [I-D.ietf-httpbis-header-structure-10]), 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:¶
Byte sequence (Section 3.10 of [I-D.ietf-httpbis-header-structure-10]) holding the signature of most of these parameters and the exchange's URL and response headers.¶
A string (Section 3.8 of [I-D.ietf-httpbis-header-structure-10]) 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.¶
A string (Section 3.8 of [I-D.ietf-httpbis-header-structure-10]) containing an absolute URL (Section 2) with a scheme of "https" or "data".¶
Byte sequence (Section 3.10 of [I-D.ietf-httpbis-header-structure-10]) holding the SHA-256 hash of the first certificate found at "cert-url".¶
A string (Section 3.8 of [I-D.ietf-httpbis-header-structure-10]) containing an absolute URL (Section 2) with a scheme of "https".¶
An integer (Section 3.6 of [I-D.ietf-httpbis-header-structure-10]) representing a Unix time.¶
The "cert-url" parameter is not signed, so intermediates can update it with a pointer to a cached version.¶
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.¶
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/
.¶
To sign an exchange's response 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 response metadata and headers is the CBOR ([RFC7049]) map with the following mappings:¶
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 [CDDL] appendix G:¶
{ 'digest': 'mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=', ':status': '200', 'content-type': 'text/html' }¶
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 + { 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.¶
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.¶
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.¶
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:¶
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".¶
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.¶
certificate-chain
.¶
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:¶
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:¶
Note: this specification does not use floating point, tags, or other more complex data types, so it doesn't need rules to canonicalize those.¶
The client MUST parse the Signature
header field as the parameterised list
(Section 4.2.5 of [I-D.ietf-httpbis-header-structure-10]) 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:¶
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.¶
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.¶
date
be the signature's "date" parameter, interpreted as a Unix time.¶
expires
be the signature's "expires" parameter, interpreted as a Unix
time.¶
Set publicKey
and signing-alg
depending on which key fields are present:¶
Assert: cert-url
is present.¶
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".¶
main-certificate
be the first certificate in certificate-chain
.¶
publicKey
to main-certificate
's public key.¶
publicKey
is an RSA key, return "invalid".¶
publicKey
is a key using the secp256r1 elliptic curve, set
signing-alg
to ecdsa_secp256r1_sha256 as defined in Section 4.2.3 of
[TLS1.3].¶
expires
is more than 7 days (604800 seconds) after date
, return
"invalid".¶
date
or after expires
, return "invalid".¶
Let message
be the concatenation of the following byte strings. This
matches the [TLS1.3] format to avoid cross-protocol attacks if
anyone uses the same key in a TLS certificate and an exchange-signing
certificate.¶
A context string: the ASCII encoding of "HTTP Exchange 1 b3".¶
Note: As this is a snapshot of a draft of [I-D.yasskin-http-origin-signed-responses], it uses a distinct context string.¶
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.¶
validity-url
,
followed by the bytes of validity-url
.¶
date
.¶
expires
.¶
requestUrl
,
followed by the bytes of requestUrl
.¶
responseHeaders
,
followed by the bytes of responseHeaders
.¶
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 [TLS1.3]), in order to allow updating the stapled OCSP response without updating signatures at the same time.¶
signature
is not a valid signature of message
by publicKey
using
signing-alg
, return "invalid".¶
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.¶
integrity
does not match "digest/mi-sha256-03", return "invalid".¶
payload
doesn't match the integrity information in the header described
by integrity
, return "invalid".¶
certificate-chain
.¶
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.¶
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.¶
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-10]) 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.¶
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).¶
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¶
The Accept-Signature
request header is not used.¶
To determine whether to trust a cross-origin exchange, the client takes a
Signature
header field (Section 3.1) and the 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]).¶
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".¶
requestUrl
, return "invalid".¶
requestUrl
, responseHeaders
, and payload
, getting certificate-chain
back. If
this returned "invalid" or didn't return a certificate chain, return
"invalid".¶
response
be the response metadata and headers parsed out of
responseHeaders
.¶
response
,
return "invalid".¶
response
's headers contain an uncached header field, as defined in
Section 4.1, return "invalid".¶
authority
be the host component of requestUrl
.¶
Validate the certificate-chain
using the following substeps. If any of them
fail, re-run Section 3.5 once over the signature with the
forceFetch
flag set, and restart from step 2. If a substep fails again,
return "invalid".¶
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.¶
main-certificate
has the CanSignHttpExchanges extension
(Section 4.2).¶
main-certificate
has a Validity Period no longer
than 90 days, or that the current date is 2019-08-01 or before and
main-certificate
was issued on 2019-05-01 or before.¶
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.¶
Validate that valid SCTs from trusted logs are available from any of:¶
SignedCertificateTimestampList
in main-certificate
's sct
property (Section 3.3),¶
main-certificate
's ocsp
property, or¶
main-certificate
's cert
property,¶
Hop-by-hop and other uncached headers MUST NOT appear in a signed exchange. These will eventually be listed in [I-D.ietf-httpbis-cache], but for now they're listed here:¶
Header fields defined as hop-by-hop:¶
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 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:¶
Authentication-Control
, [RFC8053]¶
Authentication-Info
, [RFC7615]¶
Clear-Site-Data
, [W3C.WD-clear-site-data-20171130]¶
Optional-WWW-Authenticate
, [RFC8053]¶
Proxy-Authenticate
, [RFC7235]¶
Proxy-Authentication-Info
, [RFC7615]¶
Public-Key-Pins
, [RFC7469]¶
Sec-WebSocket-Accept
, [RFC6455]¶
Set-Cookie
, [RFC6265]¶
Set-Cookie2
, [RFC2965]¶
SetProfile
, [W3C.NOTE-OPS-OverHTTP]¶
Strict-Transport-Security
, [RFC6797]¶
WWW-Authenticate
, [RFC7235]¶
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.¶
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.¶
Starting 2019-05-01, certificates with this extension MUST have a Validity Period no greater than 90 days.¶
Conforming CAs MUST NOT mark this extension as critical.¶
Starting 2019-05-01, a conforming CA MUST NOT issue certificates with this extension unless, for each dNSName in the subjectAltName extension of the certificate to be issued:¶
Clients MUST NOT accept certificates with this extension in TLS connections (Section 4.4.2.2 of [TLS1.3]).¶
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.¶
Some certificates have already been issued with this extension and with validity periods longer than 90 days. These certificates will not immediately be treated as invalid. Instead:¶
A CAA parameter "cansignhttpexchanges" is defined for the "issue" and "issuewild" properties defined by [RFC6844]. The value of this parameter, if specified, MUST be "yes".¶
A signed exchange can be transferred in several ways, of which three are described here.¶
Same-origin responses are not implemented.¶
Cross origin push is not implemented.¶
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 a request URL, response metadata
and header fields, and a response payload.¶
When served over HTTP, a response containing an application/signed-exchange
payload MUST include at least the following response header fields, to reduce
content sniffing vulnerabilities:¶
This content type consists of the concatenation of the following items:¶
8 bytes consisting of the ASCII characters "sxg1-b3" 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, if they don't,
either stop parsing or redirect to the fallbackUrl
in the next two entries.¶
Note: As this is a snapshot of a draft of [I-D.yasskin-http-origin-signed-responses], it uses a distinct file signature.¶
fallbackUrlLength
.¶
fallbackUrlLength
bytes holding a fallbackUrl
, which MUST UTF-8 decode to
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.¶
sigLength
. If this is larger than
16384 (16*1024), parsing MUST fail.¶
headerLength
. If this is larger than
524288 (512*1024), parsing MUST fail.¶
sigLength
bytes holding the Signature
header field's value
(Section 3.1).¶
headerLength
bytes holding signedHeaders
, the canonical serialization
(Section 3.4) of the CBOR representation of the response
headers of the exchange represented by the application/signed-exchange
resource (Section 3.2), excluding the Signature
header field.¶
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.¶
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.¶
If the signed response headers include a Variants-04
header field, the client
MUST use the cache behavior algorithm in Section 4 of
[I-D.ietf-httpbis-variants-05] to check that the signed response is an
appropriate representation for the request the client is trying to fulfil. If
the response is not an appropriate representation, the client MUST treat the
signature as invalid. Note the mismatch between the name of the header field and
the version of the Variants draft.¶
An example application/signed-exchange
file representing a possible signed
exchange with https://example.com/ follows, with lengths represented by
descriptions in <>
s, CBOR represented in the extended diagnostic format
defined in Appendix G of [CDDL], and most of the Signature
header field and
payload elided with a ...:¶
sxg1-b3\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 map>sig1; sig=*...; integrity="digest/mi-sha256-03"; ...{ ':status': '200', 'content-type': 'text/html' }<!doctype html>\r\n<html>...¶
All of the security considerations from Section 6 of [I-D.yasskin-http-origin-signed-responses] apply.¶
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 ([TLS1.3]) or a
successor transport layer, and MUST NOT accept exchanges transferred over plain
HTTP without TLS.¶
This depends on the following IANA registrations in [I-D.yasskin-http-origin-signed-responses]:¶
This document also modifies the registration for:¶
Type name: application¶
Subtype name: signed-exchange¶
Required parameters:¶
v: A string denoting the version of the file format. ([RFC5234] ABNF:
version = DIGIT/%x61-7A
) The version defined in this specification is b3
.
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 33 00¶
The other fields are the same as the registration in [I-D.yasskin-http-origin-signed-responses].¶
draft-03¶
Vs. draft-02¶
Vs. [I-D.yasskin-http-origin-signed-responses-05]:¶
draft-02¶
Vs. draft-01:¶
application/signed-exchange
format, and remove ':url' key from the CBOR representation of the exchange's
request and response metadata and headers.¶
payload
integrity check
steps to after verifying header
.¶
draft-01¶
Vs. [I-D.yasskin-http-origin-signed-responses-04]:¶
draft-00¶
Vs. [I-D.yasskin-http-origin-signed-responses-03]:¶
Thanks to Andrew Ayer, Devin Mullins, Ilari Liusvaara, Justin Schuh, Mark Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for comments that improved this draft.¶