]> Cloudflare Inc.

fisher@darling.dev

Cloudflare Inc.

ot-ietf@thibault.uk

Cloudflare Inc.

rfc@simonnewton.com

??? Internet Draft Publickey Key directory Key rotation Key cache Key ID This document defines recommendations for protocols that expose public keys over HTTP. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the ??? mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Multiple Internet protocols rely on public key cryptography. They require keys to be distributed by Origins to Clients. This can be done via certificates, software releases, or HTTP. This document focuses on this last mechanism. It aims to set recommendations on how to design a key directory that is served over HTTP. Distribution via HTTP allows for a more dynamic use of public keys, for rotation, or caching on intermediate mirrors or clients. This document specifies which cache directives origin should set, how clients and mirrors should consume cache directive set by origins, how origins should expose their key directory, and rotate them. This complements reccomendations provided by , narrowing them for key directories protocols. The document does not cover a specific directory format, as these needs vary from one protocol to the next.

Motivation and both define ways to structure key sets, but no way to serve them. This creates issues when serving these keys over HTTP because caching is not taken into account, and there is no standard way to derive an ID from a key. , , and are also defining their own public key directory, and are faced with similar issues. While Privacy Pass seems to have been the most thorough, even considering for instance, these seem to be duplicated efforts that would benefit from being consolidated into one specification.

Presentation Language This document uses the TLS presentation language to describe the structure of protocol messages. In addition to the base syntax, it uses two additional features: the ability for fields to be optional and the ability for vectors to have variable-size length headers.

Variable-Size Vector Length Headers In the TLS presentation language, vectors are encoded as a sequence of encoded elements prefixed with a length. The length field has a fixed size set by specifying the minimum and maximum lengths of the encoded sequence of elements. In this document, there are several vectors whose sizes vary over significant ranges. So instead of using a fixed-size length field, it uses a variable-size length using a variable-length integer encoding based on the one described in . They differ only in that the one here requires a minimum-size encoding. Instead of presenting min and max values, the vector description simply includes a V. For example: ; opaque variable; } StructWithVectors; ]]>

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 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document:

Client:

An entity using public key material.

Origin:

An entity exposing public key material via HTTP.

Mirror:

An intermediary entity between client and origin. May cache data, and act as a privacy proxy.

Key metadata:

Public data associated to a public key.

Key Directory:

Set of public keys.

Directory Metadata:

Public data associated to a key directory. This is protocol specific.

Architecture An Origin is exposing a key directory for Clients to fetch. Clients may fetch the directory from a Mirror, either to protect its privacy, or because the Origin wants to leverage a content delivery network. The endpoint and request pattern should be the same as if the fetch was to an Origin. This document focuses on the below interaction, which is triggered when the Client does not have valid key for the Origin. This can be because the Client is new, its cache is expired, or the Origin refuses requests with the current key set. | | | +--- GET Key Directory -->| | |<---- Key Directory -----+ | +---. | | | | cache | | |<--' | |<---- Key Directory -----+ | +---. | | | | cache | +---. |<--' | | | rotate | | |<--' | | | ]]>

Key ID Each key in the directory is associated with a unique Key ID. Key ID has to be derived from key material that is shared publicly. Protocols SHOULD provide the following blob of data: ; } PublicKeyMaterial; ]]> PublicKeyMaterial may be composed of both cryptographic material and metadata. Key ID is defined has follow: where

• PublicKeyMaterial is a length-prefix-encoded blob of data
• H is a hash function
• encode is some encoding function

TODO Open questions about H

• Should the draft provide specific H?
• Should the draft define an IANA registry and require protocols to register their H?

Key Selection The following is a deterministic algorithm for determining which Key a Client uses to fulfill their cryptographic needs. By using a deterministic algorithm, Origins can more easily predict the effects of a Key rotation and implement grace periods, soak times, etc. Protocols may place additional restrictions, or push these decision details to deployments.

Algorithm

1. Filter invalid keys: Exclude keys that:
   • Have a not-after field in the past.
   • Have a field in the future.
   • Do not meet required cryptographic properties.
2. Set missing activation times: If a key does not have a field, set it to either:
   • The Last-Modified header from the request as defined in , if available.
   • The Date header from the request as defined in , if available.
   • The client’s local time.
3. Sort by activation time: If a field exists, sort the remaining keys in descending order based on .
4. Select the first key: Choose the first key from the Key Directory, as ordered in the Key Directory format.

Clients should implement the Key Selection Algorithm. Origins should present the newest Keys first. For protocols which define a field, the above algorithm minimizes the chance that the Client uses a key that has expired between fetching the directory from the origin and its usage as part of the protocol. For protocols without a field, using the first key allows Origin to present their key directory so that the newest is always first, and the soon-to-be-removed key is last. This minimizes the chance of a client using an expired key. Expired key may be presented for completion, only if the protocol defines a not-after field.

Rotation Key directories are not permanent: they change over time. Origins SHOULD rotate keys on a schedule. Clients are going to fetch keys upon an immediate rotation for security reasons. This section goes over how an Origin rotates its keys, and how that interacts with scheduled and immediate rotations.

Algorithm We approach a public key generation by the following function (publickey, privatekey, metadata) ]]> At any point in time, all keys in the directory have a unique key id as defined in . When adding a key in the directory, that key has a unique key id. Generation looks as follows

Scheduled rotation Scheduled rotation happens at a time known to Origins, Clients, and Mirrors. This may be a regular interval (monthly, weekly, daily), or an ad-hoc schedule agreed between all parties. Scheduled rotations are communicated in one of the two mode below

Passive:

Origins rely on cache headers to inform Clients about key expiry. They stop advertising the key at time t, and delete it at time t_expiry=t+maxage. Origins may have to take intermediate mirrors into considerations, if they are aware these mirrors don't respect their cache headers.

Active:

Origins keep serving the key and add a not-after field. This field should be at least t+maxage.

With both modes, an Origin has to signal a key is not supported by sending a response with status code 400. For instance, the error can include a key ID as defined in .

Immediate Origins might have to rotate keys immediately. Existing keys may have to be invalidated and/or new keys be provisioned. Immediate key rotation can happen in the event of a key compromise, loss, or other imperious reason. Immediate key rotation will cause some client requests to the server to fail until the client and mirrors retrieve a new version of the directory. The key directory endpoint is going to be placed under a higher load.

1. Origins should consider introducing a random backoff to spread the load of key distribution over time. See
2. Clients on a scheduled rotation should be configured to distrust rotation outside a fixed window. Such policies should be defined by protocols.

Cache behaviour Caching the Key Directory lowers latency and reduces resource usage on Mirrors and the Origin. An optimal caching strategy should minimize resource usage for both the Client and Origin while preventing the client from using an invalid key. These two requirements, minimizing resource usage and never using an invalid key, are at odds with each other. In the event of an key rotation, a Client might use an invalid key. However, if a Client fetches an Origin key directory for every request, it would waste time and network resources. This section provides interaction with some cache directive. Deployments should also consider the recommendations laid out in .

not-before fields Protocols should define a not-before field. This field can be attached by Origins to each Key in the Directory. The not-before field allows Origins to signal to Clients when a Key is ready to use and reduces the chance a Client uses a key which is not yet available. not-before fields SHOULD be a Unix epoch timestamp in seconds.

Cache directives Origins responds with cache directives . These control when the Key Directory should be refreshed. For instance, Origins provides a Cache-Control: max-age header, or Expires header which is slightly less than the grace period given for a key about to rotate. Clients should respect the max-age cache directive or other directives. If an Origin provides a max-age header and a Mirror is used, an Origin should provide a s-maxage header that is equivalent to max-age. To prevent Clients refreshing their Key Directories at the same time (synchronization), Mirrors should provide to its clients a max-age cache directive with duration in the range [0, Origin s-maxage]. Origins should consider using Date () and Last-modified () headers to ease .

Client cache refresh The primary method a Client should use to determine when it refreshes its view of the Key Directory is through the delta seconds described in the max-age cache directive. The higher the delta, the less frequent a Client will update its cache. The lower the delta, the quicker clients will respond to unplanned key rotations. min-fresh could also be sent by Origins as defined in .

Well known URL It is recommended protocols register a URL and associated content-type. A key directory server should consider supporting both GET and HEAD request on that endpoint. HTTP/1.1 200 OK Cache-Control: max-age=, s-maxage= Content-Type: Last-Modified: ]]> HEAD requests can be used by Clients to cheaply determine if the directory has changed. The Origin server SHOULD issue a Last-Modified header with the date stamp of when the key directory resource was last modified. If issuing a Last-Modified header, the Origin server SHOULD support the correct response to a If-Modified-Since HTTP GET or HEAD request, returning the appropriate HTTP status codes . It is recommended that Mirrors support Last-Modified and If-Modified-Since .

Future considerations These considerations should be addressed in future drafts. Defining them now appears to be premature as the core of the draft does not have consensus.

Consistency Consistency allows client to prevent themselves from split view attack. A proposal that has been made for Privacy Pass is to use multiple mirrors . With a sufficiently high quorum, clients get more confident that they are not singled out. It presents scalability issues as you need multiple mirrors, and have one more requests from client per mirror in the quorum.

Key Transparency Key Directory over HTTP SHOULD integrate with transparency, once the protocol has been defined in . There are specific consideration as to what goes in the log: the full directory, keys individually, privacy considerations.

Privacy Considerations Clients fetching keys mean they reveal their IP, time, and other informations. When the key directory is provided by an Origin distinct from the Origin providing service, Clients SHOULD consider proxying their traffic through a Mirror server provided by the service they use. This may happen if the Origin service delegates key management to a third party for instance. Mirrors SHOULD NOT collide with the key server in an attempt to break Client privacy.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Informative References Mozilla Apple Inc. Google LLC Cloudflare Apple Inc. This document describes the mirror protocol, an HTTP-based protocol for fetching mirrored HTTP resources. The primary use case for the mirror protocol is to support HTTP resource consistency checks in protocols that require clients have a consistent view of some protocol-specific resource (typically, a public key) for security or privacy reasons, including Privacy Pass and Oblivious HTTP. To that end, this document also describes how to use the mirror protocol to implement these consistency checks. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. University of Applied Sciences Bonn-Rhein-Sieg Transmute bibital Security Theory LLC This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. ISRG Cloudflare ISRG Independent Cloudflare There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Nokia Nokia Transmute Self-Issued Consulting This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with JOSE. While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Test vectors Implementation may test the following scenarios 1. One key is provided on a normal basis, the key rotates: 1. does the directory has two entries or one? 2. what are the cache headers? 3. what are the keys as seen by a client? 4. does the new key has a unique key id?

1. Key has to be rotated immediately
2. How long does it take for client to notice
3. What is the backoff to avoid a thundering herd issue

Non normative proposals

For JOSE JOSE has a key directory in the form of JWK Set as defined in . However, it does not addhere to the best practices laid down here, despite being Web keys. This would be valuable as the group aims to integrates with all sort of cryptographic keys, as can be seen with the new HPKE proposal . Following these recommendations, JOSE may define:

• A well-known URI
• A deterministic Key ID
• Recommendations for caching and rotation, or leave it to implementations.

For COSE Same as the above, for COSE Key Set.

Use cases See existing key directory on https://key-directory-over-http.research.cloudflare.com/

DAP Defined in . ; struct { HpkeConfigId id; HpkeKemId kem_id; HpkeKdfId kdf_id; HpkeAeadId aead_id; HpkePublicKey public_key; } HpkeConfig; opaque HpkePublicKey<0..2^16-1>; uint16 HpkeAeadId; /* Defined in [HPKE] */ uint16 HpkeKemId; /* Defined in [HPKE] */ uint16 HpkeKdfId; /* Defined in [HPKE] */ ]]> Partially informed comments:

• HpkeConfigId could be removed
• Need not-before to handle early capture

OHTTP Defined in . Partially informed comments:

• Key Identifier could be removed/be deterministic
• No mention of not-before
• No mention of HTTP Caching for rotation

Privacy Pass Defined in Partially informed comments: * Not as flexible as HPKE * Has some protocol metadata (token-type, issuer-request-uri, rate-limit)

Acknowledgments The authors would like to thank Ethan Heilman, Michael Rosenberg, and Chris Wood for their knowledge of existing practices on key directories, and Mark Nottingham for helpful discussion on HTTP best practices.