diff --git a/IETF-OCM-MLS.md b/IETF-OCM-MLS.md index e890671..abb33b6 100644 --- a/IETF-OCM-MLS.md +++ b/IETF-OCM-MLS.md @@ -137,6 +137,12 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. +Unless stated otherwise, every base64 encoded value this document, +including MLS wire-format messages, KeyPackages, `group_id` values, and +wrapped keys, is encoded using base64url (the URL- and filename-safe +alphabet defined in [RFC4648], Section 5) with padding omitted. A +decoder MUST accept such a value whether or not padding is present. + This document uses terminology from [OCM] and [RFC9420]. Additional definitions: @@ -402,8 +408,8 @@ Response: "keyPackages": [ { "mediaType": "message/mls", - "encoding": "base64", - "content": "" + "encoding": "base64url", + "content": "" } ] } @@ -671,7 +677,7 @@ that requirement: `providerId` is REQUIRED only for notification types that refer to a Share, and the MLS notification types omit it. All MLS-specific parameters are carried inside the `notification` object that [OCM] provides for type-specific parameters. The `mlsGroupId` -field carries the base64-encoded MLS `group_id` as advisory routing +field carries the base64url-encoded MLS `group_id` as advisory routing information, used to dispatch the message to the right group state without parsing the MLS message; the authoritative `group_id` is the one inside the MLS message itself, and a mismatch between the two MUST be @@ -704,9 +710,9 @@ added user. { "notificationType": "MLS_WELCOME", "notification": { - "mlsGroupId": "", + "mlsGroupId": "", "userId": "bob@othercloud.example.org", - "content": "" + "content": "" } } ~~~ @@ -744,8 +750,8 @@ act on it. { "notificationType": "MLS_PROPOSAL", "notification": { - "mlsGroupId": "", - "content": "" + "mlsGroupId": "", + "content": "" } } ~~~ @@ -772,9 +778,9 @@ data, per [RFC9420] Section 15.2. { "notificationType": "MLS_COMMIT", "notification": { - "mlsGroupId": "", - "proposals": [""], - "content": "" + "mlsGroupId": "", + "proposals": [""], + "content": "" } } ~~~ @@ -818,8 +824,8 @@ epoch ([RFC9420] Section 15). { "notificationType": "MLS_APPLICATION", "notification": { - "mlsGroupId": "", - "content": "" + "mlsGroupId": "", + "content": "" } } ~~~ @@ -859,13 +865,13 @@ by the KeyPackage endpoint. { "notificationType": "MLS_REJOIN", "notification": { - "mlsGroupId": "", + "mlsGroupId": "", "keyPackages": [ { "userId": "bob@othercloud.example.org", "mediaType": "message/mls", - "encoding": "base64", - "content": "" + "encoding": "base64url", + "content": "" } ] } @@ -1169,7 +1175,7 @@ array, and MAY also carry a `credentials` array ({{credential-update}}): { "resourceId": "3a02538b-aa54-42f2-8853-a38996e211b1", "groupId": "research-group@receiver.example.org", - "wrappedKey": "" + "wrappedKey": "" } ] } @@ -1916,6 +1922,10 @@ Work in Progress, Internet-Draft. Requirement Levels](https://datatracker.ietf.org/doc/html/rfc2119)", March 1997. +[RFC4648] Josefsson, S. "[The Base16, Base32, and Base64 Data +Encodings](https://datatracker.ietf.org/doc/html/rfc4648)", October +2006. + [RFC7517] Jones, M., "[JSON Web Key (JWK)](https://datatracker.ietf.org/doc/html/rfc7517)", May 2015. diff --git a/IETF-OCM.md b/IETF-OCM.md index 9a8bb50..f7ee1d9 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -124,8 +124,10 @@ related concepts from OAuth [RFC6749] and elsewhere: * __Invite Sender OCM Server__ - The server holding an address book used by the Invite Sender, to which details of the Invite Receiver are to be added. -* __Invite String__ - A base64 encoded string containing an Invite Token - and the FQDN of an Invite Sender OCM Server joined by an `@`-sign. +* __Invite String__ - An Invite Token and the FQDN of an Invite Sender + OCM Server joined by an `@`-sign, then encoded using base64url (the + URL- and filename-safe alphabet defined in [RFC4648], Section 5) with + padding omitted. * __Invite Token__ - A hard-to-guess string used in the Invite Flow, generated by the Invite Sender OCM Server and linked uniquely to the Invite Sender's OCM Address. @@ -472,19 +474,21 @@ To accept an invite, two pieces of information are required: a `token` and a `provider`. There are two recognized formats: * **Invite string format:** - A base64-encoded string containing the token and the provider’s FQDN, - joined by an `@` sign. Example: + The token and the provider’s FQDN, joined by an `@` sign and then + encoded using base64url (the URL- and filename-safe alphabet defined + in [RFC4648], Section 5) with padding omitted. Example: If the `token` is `a55a966e-15c1-4cb9-a39d-4e4c54399baf` and the `provider` is `cloud.example.org`, the combined string is `a55a966e-15c1-4cb9-a39d-4e4c54399baf@cloud.example.org`, - which when base64-encoded becomes - `YTU1YTk2NmUtMTVjMS00Y2I5LWEzOWQtNGU0YzU0Mzk5YmFmQG15LWNsb3VkLXN0b - 3JhZ2Uub3Jn`. + which when base64url-encoded becomes + `YTU1YTk2NmUtMTVjMS00Y2I5LWEzOWQtNGU0YzU0Mzk5YmFmQGNsb3VkLmV4YW1wbGUu + b3Jn`. - When parsing an invite string, implementors must base64-decode it, - then split on the last `@` sign, taking care to allow multiple `@` - characters in the token part. + When parsing an invite string, implementors MUST base64url-decode it + (accepting the string whether or not padding is present), then split + on the last `@` sign, taking care to allow multiple `@` characters in + the token part. * **Link format:** If the inviting OCM Server supports a WAYF page, the invite may be @@ -1734,6 +1738,10 @@ March 1997. "[Uniform Resource Identifier (URI): Generic Syntax ](https://datatracker.ietf.org/doc/html/rfc3986)", January 2005 +[RFC4648] Josefsson, S. "[The Base16, Base32, and Base64 Data +Encodings](https://datatracker.ietf.org/doc/html/rfc4648)", October +2006. + [RFC4918] Dusseault, L. M. "[HTTP Extensions for Web Distributed Authoring and Versioning](https://datatracker.ietf.org/html/rfc4918/)", June 2007. @@ -1777,13 +1785,13 @@ https://datatracker.ietf.org/doc/html/rfc9553), May 2024" ## Informative References -[OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "[Open -Cloud Mesh Integration +[OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "[Open Cloud Mesh +Integration Protocol](https://datatracker.ietf.org/doc/draft-nordin-ocm-integration-protocol/)", Work in Progress, Internet-Draft. -[OCM-MLS] Nordin, M., Lo Presti, G., and Baghbani, M. "[Federated -Groups in Open Cloud Mesh using Messaging Layer +[OCM-MLS] Nordin, M., Lo Presti, G., and Baghbani, M. "[Federated Groups +in Open Cloud Mesh using Messaging Layer Security](https://datatracker.ietf.org/doc/draft-nordin-ocm-mls-federated-groups/)", Work in Progress, Internet-Draft. diff --git a/diagrams/invitation-flow.md b/diagrams/invitation-flow.md index d261e2f..1b83aee 100644 --- a/diagrams/invitation-flow.md +++ b/diagrams/invitation-flow.md @@ -31,7 +31,7 @@ sequenceDiagram alt HTTPA ->> UserB: Send Email with Alice's Server FQDN and Token else - HTTPA ->> UserA: Raw or Base64 encoded "token@FQDN" + HTTPA ->> UserA: Raw or base64url encoded "token@FQDN" UserA ->> UserB: Aice passes token to Bob end