An Extensible Key Configuration Format for Oblivious HTTP
draft-schinazi-httpbis-ohttp-ext-key-config-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David Schinazi | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schinazi-httpbis-ohttp-ext-key-config-00
HTTP D. Schinazi
Internet-Draft Google LLC
Intended status: Standards Track 6 July 2026
Expires: 7 January 2027
An Extensible Key Configuration Format for Oblivious HTTP
draft-schinazi-httpbis-ohttp-ext-key-config-00
Abstract
Oblivious HTTP is a protocol for forwarding encrypted HTTP messages.
This requires communicating the gateway's key configuration to
clients. While a key configuration media type was defined for this
purpose, it has some limitations such as the inability to convey key
lifetimes and interoperability issues. This document defines a
similar extensible key configuration format that addresses those
issues.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://DavidSchinazi.github.io/draft-schinazi-httpbis-ohttp-ext-key-
config/draft-schinazi-httpbis-ohttp-ext-key-config.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-schinazi-httpbis-ohttp-ext-
key-config/.
Discussion of this document takes place on the HTTP Working Group
mailing list (mailto:ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/. Working Group
information can be found at https://httpwg.org/.
Source for this draft and an issue tracker can be found at
https://github.com/DavidSchinazi/draft-schinazi-httpbis-ohttp-ext-
key-config.
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/.
Schinazi Expires 7 January 2027 [Page 1]
Internet-Draft OHTTP Extended Key Configuration July 2026
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 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
1.1. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Interoperability Issues . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Extensible Format . . . . . . . . . . . . . . . . . . . . . . 4
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. OHTTP Key Configuration Extension Registry . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Oblivious HTTP ([OHTTP]) is a protocol for forwarding encrypted HTTP
messages. This requires communicating the gateway's key
configuration to clients. A key configuration media type was defined
for this purpose in Section 3 of [OHTTP]. That format has the
following limitations.
Schinazi Expires 7 January 2027 [Page 2]
Internet-Draft OHTTP Extended Key Configuration July 2026
1.1. Key Lifetimes
The security properties of OHTTP rely on periodic rotation of gateway
keys. Many gateways rotate their keys on a weekly cadence. However,
the original key configuration format has no way of informing the
client of the lifetime of the keys it contains. Clients then need to
assume an expiration time; if they didn't, they might keep using keys
past when the gateway forgot them, or worse: they might encrypt
sensitive data using a key that leaked after its expiration. Since
those bounds aim to be conservative, clients can end up marking a key
as expired even though it is still fresh on the gateway. This
reduces reliability when periodic key fetch operations fail due to
intermittent connectivity issues.
1.2. Interoperability Issues
During the development of [OHTTP], the authors discovered a forward
compatibility issue (https://github.com/ietf-wg-ohai/oblivious-http/
issues/285) with the key configuration format: parsing multiple keys
required explicit support for each included KEM because the length of
the HPKE public key was not encoded in the format. This would
prevent deploying new KEMs in a backwards-compatible way. The
authors resolved (https://github.com/ietf-wg-ohai/oblivious-
http/pull/284/changes) this by adding a length prefix to each
configuation entry. Unfortunately, they did not change the media
type when doing so. Since this change to the format was made after
the document's working group last call, there were already
implementations in production. At the time of writing, there are
multiple billions of devices in production that understand the
"application/ohttp-keys" media type as not including the length
prefix. Other client implementations support both formats by
attempting to parse with the length prefix and falling back to the
older format if that fails. This runs the risk of segregating
clients, as described in Section 3.2 of [OHTTP].
1.3. Conventions and Definitions
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.
Schinazi Expires 7 January 2027 [Page 3]
Internet-Draft OHTTP Extended Key Configuration July 2026
This document uses terminology from [QUIC]. Where this document
defines protocol types, the definition format uses the notation from
Section 1.3 of [QUIC]. This specification uses the variable-length
integer encoding from Section 16 of [QUIC]. Variable-length integer
values do not need to be encoded in the minimum number of bytes
necessary.
2. Extensible Format
This document defines a new media type (see Section 6.1 for its
value). It represents a list of key configurations. It has the
following format:
HPKE Symmetric Algorithms {
HPKE KDF ID (16),
HPKE AEAD ID (16),
}
Extension {
Extension ID (i),
Extension Length (i),
Extension Value (..),
}
Key Config {
Key Config Length (16),
Key Identifier (8),
HPKE KEM ID (16),
HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16) = 4..65532,
HPKE Symmetric Algorithms (32) ...,
Extensions (..) ...
}
Key Configs {
Key Config (..) ...
}
Figure 1: A List of Key Configurations
The "HPKE Symmetric Algorithms" struct consists of the following
fields:
HPKE KDF ID: A 16 bit HPKE KDF identifier as defined in Section 7.2
of [HPKE] or the HPKE KDF IANA registry
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kdf-ids).
HPKE AEAD ID: A 16 bit HPKE AEAD identifier as defined in
Schinazi Expires 7 January 2027 [Page 4]
Internet-Draft OHTTP Extended Key Configuration July 2026
Section 7.3 of [HPKE] or the HPKE AEAD IANA registry
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids).
The "Extension" struct consists of the following fields:
Extension ID: A 62 bit OHTTP Key Configuration Extension identifier
as defined in Section 3.
Extension Length: The length of the "Extension Value" field that
follows it.
Extension Value: Extension-specific information, with encoding rules
dependent on the value of the "Extension ID" field.
The "Key Config" struct consists of the following fields:
Key Config Length: A 16 bit integer in network byte order that
encodes the length, in bytes, of this "Key Config" struct, not
including this field.
Key Identifier: An 8 bit value that identifies the key used by the
Oblivious Gateway Resource.
HPKE KEM ID: A 16 bit value that identifies the Key Encapsulation
Method (KEM) used for the identified key as defined in Section 7.1
of [HPKE] or the HPKE KDF IANA registry
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids).
HPKE Public Key: The public key used by the gateway. The length of
the public key is Npk, which is determined by the choice of HPKE
KEM as defined in Section 4 of [HPKE].
HPKE Symmetric Algorithms Length: A 16 bit integer in network byte
order that encodes the length, in bytes, of the HPKE Symmetric
Algorithms field that follows.
HPKE Symmetric Algorithms: One or more "HPKE Symmetric Algorithms"
structs.
Extensions: Zero or more "Extension" structs. This field continues
until the end of this "Key Config" struct.
The new media type defined in this document represents a list of
concatenated "Key Config" structs.
Schinazi Expires 7 January 2027 [Page 5]
Internet-Draft OHTTP Extended Key Configuration July 2026
3. Extensions
In addition to providing an extensible format for OHTTP key
configurations, this document defines two extensions. The EXPIRATION
extension indicates the date/time after which the key can no longer
be used. The NOT_BEFORE extension indicates the date/time before
which the key cannot yet be used. Both are encoded as QUIC variable-
length integers representing UNIX timestamps (number of seconds since
January 1, 1970, UTC -- see Section 4.2.1 of [TIMESTAMP]).
The NOT_BEFORE extension allows a gateway to publish public keys in
advance of them being valid. Given that and the EXPIRATION
extension, the bounds can then be tightenned on the validity of keys,
increasing both security and reliability.
Gateways SHOULD provide some leeway between their stated times and
the actual times to account for a few minutes of clock skew.
4. Parsing
When parsing the list of key configurations, clients MUST silently
skip any key configuration that carries a KEM ID unknown to the
client. Clients MUST also silently skip over any extension for which
the extension ID is unknown.
As mentioned in Section 3.2 of [OHTTP], a client that receives an
list of key configuration object with encoding errors might be able
to recover one or more key configurations. Differences in how key
configurations are recovered might be exploited to segregate clients,
so clients MUST discard the entire list if they encounter any
encoding error in one of the key configurations or its extensions.
If an Extension Value field contains more data than expected for that
Extension ID, the client MUST treat it as an encoding error. If the
Extension Length field is such that the extension would extend past
the end of the Key Config struct, clients MUST treat it as an
encoding error.
5. Security Considerations
The security considerations described in Section 6 of [OHTTP] apply
to this document as well.
6. IANA Considerations
Schinazi Expires 7 January 2027 [Page 6]
Internet-Draft OHTTP Extended Key Configuration July 2026
6.1. Media Type
The "application/ohttp-keys-ext-00" media type identifies a key
configuration used by Oblivious HTTP. Note that the sybtype is
expected to be changed if non-backwards-compatible changes are made
to the format. If this document is approved, the "-NN" suffix will
be removed before publication.
Type name: application
Subtype name: ohttp-keys-ext-00
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: "binary"
Security considerations: see Section 5
Interoperability considerations: N/A
Published specification: this specification
Applications that use this media type: This type identifies a key
configuration as used by Oblivious HTTP and applications that use
Oblivious HTTP.
Fragment identifier considerations: N/A
Additional information: Magic number(s): N/A
Deprecated alias names for this type: N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: see
Authors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IETF
6.2. OHTTP Key Configuration Extension Registry
This document establishes a registry for extension IDs. The "OHTTP
Key Configuration Extensions" registry governs a 62-bit space and
operates under the QUIC registration policy documented in
Section 22.1 of [QUIC]. This new registry includes the common set of
fields listed in Section 22.1.1 of [QUIC]. In addition to those
common fields, all registrations in this registry MUST include a
"Name" field that contains a short name or label for the extension.
Permanent registrations in this registry are assigned using the
Specification Required policy (Section 4.6 of [IANA-POLICY]), except
for values between 0x00 and 0x3f (in hexadecimal; inclusive), which
are assigned using Standards Action or IESG Approval as defined in
Sections 4.9 and 4.10 of [IANA-POLICY].
Schinazi Expires 7 January 2027 [Page 7]
Internet-Draft OHTTP Extended Key Configuration July 2026
Extensions with a value of the form 0x29 * N + 0x17 for integer
values of N are reserved to exercise the requirement that unknown
Extension IDs be ignored. These extensions have no semantics and can
carry arbitrary values. These values MUST NOT be assigned by IANA
and MUST NOT appear in the listing of assigned values.
This registry initially contains the following entries:
+=======+============+
| Value | Name |
+=======+============+
| 0x00 | EXPIRATION |
+-------+------------+
| 0x01 | NOT_BEFORE |
+-------+------------+
Table 1: Extensions
All of these new entries use the following values for these fields:
Status: provisional (permanent if this document is approved)
Reference: This document
Change Controller: IETF
Contact: HTTPBIS Working Group ietf-http-wg@w3.org (mailto:ietf-
http-wg@w3.org)
Notes: None
7. References
7.1. Normative References
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[IANA-POLICY]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/rfc/rfc9458>.
Schinazi Expires 7 January 2027 [Page 8]
Internet-Draft OHTTP Extended Key Configuration July 2026
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[TIMESTAMP]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/rfc/rfc8877>.
7.2. Informative References
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
Acknowledgments
The "Not Before" and "Expiration" extensions were inspired by the
"nbf" and "exp" claims in JSON Web Keys ([JWT]).
Author's Address
David Schinazi
Google LLC
Email: dschinazi.ietf@gmail.com
Schinazi Expires 7 January 2027 [Page 9]