Network Working Group J. Yasskin
Internet-Draft Google
Intended status: Standards Track 19 April 2024
Expires: 21 October 2024
Signed HTTP Exchanges
draft-yasskin-http-origin-signed-responses-latest
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.
Discussion Venues
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.
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 21 October 2024.
Copyright Notice
Copyright (c) 2024 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.
Table of Contents
1. Introduction
2. Terminology
3. Signing an exchange
3.1. The Signature Header
3.1.1. Examples
3.1.2. Open Questions
3.2. CBOR representation of exchange response headers
3.2.1. Example
3.3. Loading a certificate chain
3.4. Canonical CBOR serialization
3.5. Signature validity
3.5.1. Open Questions
3.6. Updating signature validity
3.6.1. Examples
3.7. The Accept-Signature header
3.7.1. Integrity identifiers
3.7.2. Key type identifiers
3.7.3. Key value identifiers
3.7.4. Examples
3.7.5. Open Questions
4. Cross-origin trust
4.1. Uncached header fields
4.1.1. Stateful header fields
4.2. Certificate Requirements
4.2.1. Extensions to the CAA Record: cansignhttpexchanges
Parameter
5. Transferring a signed exchange
5.1. Same-origin response
5.1.1. Serialized headers for a same-origin response
5.1.2. The Signed-Headers Header
5.2. HTTP/2 extension for cross-origin Server Push
5.2.1. Indicating support for cross-origin Server Push
5.2.2. NO_TRUSTED_EXCHANGE_SIGNATURE error code
5.2.3. Validating a cross-origin Push
5.3. application/signed-exchange format
5.3.1. Cross-origin trust in application/signed-exchange
5.3.2. Example
5.3.3. Open Questions
6. Security considerations
6.1. Over-signing
6.1.1. Session fixation
6.1.2. Misleading content
6.2. Off-path attackers
6.2.1. Mis-issued certificates
6.2.2. Stolen private keys
6.3. Downgrades
6.4. Signing oracles are permanent
6.5. Unsigned headers
6.6. application/signed-exchange
6.7. Key re-use with TLS
6.8. Content sniffing
7. Privacy considerations
7.1. Visibility of resource requests
7.2. User ID transfer
8. IANA considerations
8.1. Signature Header Field Registration
8.2. Accept-Signature Header Field Registration
8.3. Signed-Headers Header Field Registration
8.4. HTTP/2 Settings
8.5. HTTP/2 Error code
8.6. Internet Media Type application/signed-exchange
8.7. Internet Media Type application/cert-chain+cbor
8.8. The cansignhttpexchanges CAA Parameter
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Use cases
A.1. PUSHed subresources
A.2. Explicit use of a content distributor for subresources
A.3. Subresource Integrity
A.4. Binary Transparency
A.5. Static Analysis
A.6. Offline websites
Appendix B. Requirements
B.1. Proof of origin
B.1.1. Certificate constraints
B.1.2. Signature constraints
B.1.3. Retrieving the certificate
B.2. How much to sign
B.2.1. Conveying the signed headers
B.3. Response lifespan
B.3.1. Certificate revocation
B.3.2. Response downgrade attacks
B.4. Low implementation complexity
B.4.1. Limited choices
B.4.2. Bounded-buffering integrity checking
Appendix C. Determining validity using cache control
C.1. Example of updating cache control
C.2. Downsides of updating cache control
Appendix D. Change Log
Appendix E. Acknowledgements
Author's Address
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
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).
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
[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.
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 subjectAltNames of example.com,
meaning that if they and their signatures validate, the exchange can
be trusted as having an origin of 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:
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.
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.
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.
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".
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.
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
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.
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).
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
}
}
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:
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
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