From 9f8d5cbe53b0435a33b057f9ebb297f40425c857 Mon Sep 17 00:00:00 2001 From: Franziskus Kiefer Date: Wed, 1 Dec 2021 09:55:00 +0100 Subject: [PATCH] main idea from https://github.com/mlswg/mls-protocol/issues/499 --- ...hbrok-mls-implementation-considerations.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/draft-kohbrok-mls-implementation-considerations.md b/draft-kohbrok-mls-implementation-considerations.md index eb32bf2..56482ef 100644 --- a/draft-kohbrok-mls-implementation-considerations.md +++ b/draft-kohbrok-mls-implementation-considerations.md @@ -45,6 +45,37 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", document are to be interpreted as described in BCP 14 {{RFC2119}} {{!RFC8174}} when, and only when, they appear in all capitals, as shown here. +# Typed structs +In many places, MLS uses a typed pattern of structs, where we have a type `uint`, +followed by a `select` statement that decides the type of the following field based on the preceding type `uint`. +For example the Credential struct: + +``` +struct { + CredentialType credential_type; + select (Credential.credential_type) { + case basic: + BasicCredential; + + case x509: + Certificate chain<1..2^32-1>; + }; +} Credential; +``` + +Other examples are `Content`/`ContentType`, `PSKType` in `PreSharedKey`, `Sender`/`SenderType` and `Proposal`/`ProposalType`. + +We can generalise this into a typed struct as follows: + +``` +struct { + T type; + select(typed.type) { + T.variant1: + Variant1 + } +} typed +``` # Security Considerations