A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs.
Key Transparency (keytrans) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Shivan Sahib <shivankaulsa...@gmail.com> Orie Steele <orie@transmute.industries> Assigned Area Director: Roman Danyliw <r...@cert.org> Security Area Directors: Roman Danyliw <r...@cert.org> Paul Wouters <paul.wout...@aiven.io> Mailing list: Address: keytr...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/keytrans Archive: https://mailarchive.ietf.org/arch/browse/keytrans/ Group page: https://datatracker.ietf.org/group/keytrans/ Charter: https://datatracker.ietf.org/doc/charter-ietf-keytrans/ ## 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: Dec 2023 - Initial WG adoption of an architecture document Mar 2024 - Initial WG adoption of core transparent verifiability mechanism document Jul 2024 - Initial WG adoption of MLS integration document Mar 2025 - Submit architecture document to the IESG as Informational Nov 2025 - Submit core transparent verifiability mechanism document to IESG as Proposed Standard Nov 2025 - Submit MLS integration document to IESG as Proposed Standard _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
