]>

rohan.ietf@gmail.com

TLS PL TLS Presentation Language Extended Diagnostic Notation was designed as a superset of JSON to represent CBOR instance documents in human-readable format. This document describes how it can be used to represent instances encoded using the TLS Presentation Language. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Extended Diagnostic Notation (EDN) is a text format, that was originally described to represent CBOR messages as diagnostic notation in and then expanded in . It is a superset of JSON (all valid JSON is valid EDN) that can natively represent binary content, non-finite floating point values, and additional data types (tags and simple values). Since then it has been used to represent YAML messages, especially those that contain binary content or tags. This document defines a convention to represent instances of binary sequences--encoded using the TLS Presentation Language (TLS PL) defined in --using EDN. TLS encoding is used in several other protocols, for example in the Messaging Layer Security (MLS) protocol and the MIMI protocol . TLS PL has a very limited set of patterns. It deals primarily with structs and enums. As a result, it is relatively straightforward to represent TLS encoded data if the TLS PL definitions are available.

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.

Representation of TLS PL in EDN EDN Representations of TLS-encoded instance data always start with the following comment line: # ~~~ tls followed by the struct name, and end with the following comment line: # ~~~. This allows a processor that knows TLS to convert an EDN document back into TLS-encoded binary data. Instances of TLS-encoded structs are represented in EDN as maps with the keys equal to the names of the members. If an enum appears that contains only the values false (0) and true (1), its values are represented in EDN as the simple values false and true. Instances of other TLS-encoded enums are represented as their decimal integer values with an EDN end-of-line comment naming the enum name and the item name. Instances of the following predefined TLS numeric types: uint16, uint32, uint64, plus any variable-length integers (widely used, for example in MLS ) are represented as unsigned decimal integers in EDN. Likewise a single instance of uint8 is represented as an unsigned decimal integer in EDN. Vectors of uint8 (or the opaque type) are represented by byte strings in EDN. Likewise fixed-length arrays of uint8 are represented by byte strings in EDN. By default, they are presented as hex-encoded single-quoted strings. If such sequences consist entirely entirely or substantially of printable characters they are represented as (appropriately escaped) unprefixed single-quoted strings. Vectors of any other type are represented by an array of that type. For example given the FooBar struct defined below: ; opaque reason; } FooBar; ]]> an instance of that struct could be represented as follows in EDN:

Representation of Variants The optional keyword () is represented as a struct. For example given the following structs: component; } Foo; ]]> An instance of Foo which has an optional Component would be represented by the following snippet of EDN: When absent it would be represented as: In general, the presence of a select construction in TLS PL indicates the conditional presence of additional values in the struct. For example, the struct below: ; }; Extension extensions; } PartialLeafNode; ]]> would be represented as follows in EDN: The notation struct {} in TLS PL refers to the absense of a value. It is ignored in the representation of an EDN instance.

Examples

MLS LeafNode The following detailed example represents the LeafNode struct from and embedded structs. It includes additional types from , , and . Given the following TLS structures: ; }; Extension extensions; /* SignWithLabel(., "LeafNodeTBS", LeafNodeTBS) */ opaque signature; } LeafNode; enum { reserved(0), key_package(1), update(2), commit(3), (255) } LeafNodeSource; struct { ProtocolVersion versions; CipherSuite cipher_suites; ExtensionType extensions; ProposalType proposals; CredentialType credentials; } Capabilities; struct { uint64 not_before; uint64 not_after; } Lifetime; struct { ExtensionType extension_type; opaque extension_data; } Extension; struct { CredentialType credential_type; select (Credential.credential_type) { ... case sd_jwt: SdJwt sd_jwt; }; } Credential; struct { Bool compacted; select (compacted) { case true: opaque protected; opaque payload; opaque signature; SdJwtDisclosure disclosures; opaque sd_jwt_key_binding; case false: opaque sd_jwt_kb; }; } SdJwt; enum { false(0), true(1) } Bool; struct { ComponentID component_id; opaque data; } ComponentData; struct { ComponentData component_data; } AppDataDictionary; AppDataDictionary app_data_dictionary; opaque HPKEPublicKey; opaque SignaturePublicKey; /* See the "Messaging Layer Security (MLS)" IANA registries for values */ uint16 CipherSuite; uint16 ExtensionType; uint16 ProposalType; uint16 CredentialType; uint16 ComponentID; ]]> below is an example instance represented in EDN:

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References Universität Bremen TZI This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) -26 is intended to // address the May/June 2026 Working Group Last Call comments on -25 // and the ensuing WG discussions. Specifically, this update: • is // going further with the idea to entirely replace the non- backwards // compatible update considered for the RFC 8610/G.4 concatenation by // two new application extensions (temporarily named b1/t1), and to // add related application-oriented extensions that deprecate the // original streamstring syntax. • includes the float'' application- // extension so that the entire CBOR format can be covered. • now // uses rules closer to those of markdown for handling data // transparency in raw strings, simplifying their implementation. • // adds security considerations. • proactively reserves the // application-extension identifier "pragma" for potential future // standardization. • This update does not address certain comments // that propose some editorial restructuring requiring moving text // around; this is best done in a next revision after the technical // comments are addressed. 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. Informative References This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Cisco The Matrix.org Foundation C.I.C. Phoenix R&D Rohan Mahy Consulting Services The Matrix.org Foundation C.I.C. Phoenix R&D This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. Phoenix R&D The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. Rohan Mahy Consulting Services This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. Rohan Mahy Consulting Services The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types.

Acknowledgments TODO acknowledge.