Skip to main content

Key Transparency (keytrans)

WG Name Key Transparency
Acronym keytrans
Area Security Area (sec)
State Active
Charter charter-ietf-keytrans-01 Approved
Document dependencies
Personnel Chairs Prachi Jain, Shivan Kaul Sahib
Area Director Deb Cooley
Mailing list Address keytrans@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/keytrans
Archive https://mailarchive.ietf.org/arch/browse/keytrans/
Chat Room address https://zulip.ietf.org/#narrow/stream/keytrans

Charter for Working Group

Background

Public keys used to provide end-to-end encrypted communication services are often authenticated solely by the assertion of the communications service provider (e.g., a video conferencing or instant messaging service providers). As a result, the underlying encryption protocols are left vulnerable to eavesdropping and impersonation by a service provider which distributes malicious public keys. To provide confidence to their users and to mitigate this attack, end-to-end encrypted communication service providers are increasingly looking to an authentication service to provide verifiability for identity-to-public-key bindings in the context of their service. A scheme for providing this verifiability of key bindings must be:

  • Transparent: All end users (applications or devices) receive a globally consistent view of the data associated with each identity.

  • User-friendly: Little (ideally zero) user action, or even awareness of the system, is required to verify a user’s key bindings.

  • Private: The authentication service used by the service provider only reveals information about specific users, such as what keys are associated with an identity, or even whether or not a specific identity is registered by the service provider, to clients authorized to ask about that user

  • Efficient: The computational requirements for the end user and the service provider should be practical to deploy for internet scale numbers of keys and for typical end-user devices.

Goals

The KEYTRANS working group will develop a standard for providing verifiability for identity-to-public-key bindings in an authentication service for an end-to-end encrypted communication service. This standard will:

  • Allow an end-user to search and download the public keys of themselves or for other end-users; and enable a process for updating their public key with the authentication service of the communication service provider

  • Allow end-users to verify on an ongoing basis that they have a globally consistent view of which public keys have been associated with which accounts, including their own.

  • Allow end-users to perform this verification of a globally consistent view via an out-of-band mechanism for small groups, or use an anonymous check with the communication service provider in-band for larger groups.

This standardized approach is not stand-alone and will need to be integrated into other, more complete end-to-end protocols and services. It is not the goal of this WG to enable interoperability between end-to-end encrypted services as full interoperability of an application would require alignment at many different layers beyond security.

Program of Work

The WG is expected to:

  • Specify an architecture for this public verifiability mechanism (as an informational status document(s))

  • Standardize the core scheme for providing verifiability for identity-to-public-key bindings in an authentication service for an end-to-end encrypted communication service (as a proposed standard document(s))

The WG may standardize integrations of this verifiability mechanism with other protocols (where the exact security guarantees provided will depend on the underlying encryption)

The WG will work collaboratively with the MIMI, MLS and SCITT WGs as appropriate.

Milestones

Date Milestone Associated documents
Nov 2025 Submit MLS integration document to IESG as Proposed Standard
Nov 2025 Submit core transparent verifiability mechanism document to IESG as Proposed Standard
Mar 2025 Submit architecture document to the IESG as Informational
Jul 2024 Initial WG adoption of MLS integration document
Mar 2024 Initial WG adoption of core transparent verifiability mechanism document
Dec 2023 Initial WG adoption of an architecture document