Add Mutable and Immutable Metadata #17
Conversation
Adds support for GroupContextExtensions proposals. The relevant validation has been added both to the code and the documentation. Co-authored-by: Jan Winkelmann (keks) <jan@cryspen.com>
This is similar to the ProtectedMetadata extension, with the exception that the payload is not signed. Whether and how the payload should be processed is up to the application.
# Conflicts: # openmls/src/extensions/test_extensions.rs
|
|
||
| ## Unknown extensions | ||
|
|
||
| Some extensions carry data, but don't alter the behaviour of the protocol (e.g. the application_id extension). OpenMLS allows the use of arbitrary such extensions in the group context, key packages and leaf nodes. Such extensions can be instantiated and retrieved through the use of the `UnknownExtension` struct and the `ExtensionType::Unknown` extension type. Such "unknown" extensions are handled transparently by OpenMLS, but can be used by the application, e.g. to have a group agree on pieces of data. |
There was a problem hiding this comment.
Supporting arbitrary extensions in the GroupContext is not RFC compliant. Extensions in the GroupContext need to be supported by every member (ie, also have an indication of support in their capabilities field).
There was a problem hiding this comment.
Why do you think that's not RFC compliant?
Indicating support in capabilities if of course required. But MLS does not restrict extensions. In the contrary, implementations are supposed to handle any (unknown) extension gracefully. That's what the grease mechanisms tries to ensure.
There was a problem hiding this comment.
It says in section 13.4:
- Clients must verify they support every extension in a GroupContext. Otherwise, it must refuse to join a group
- Clients must verify every other client supports extensions in the GroupContext
There was a problem hiding this comment.
Is the documentation a mis-statement, or does openmls actually allow arbitrary GroupContext extensions?
There was a problem hiding this comment.
It allows arbitrary group context extension, as long as all members support them.
As such, it is compliant with the RFC. The difference to other extensions is that the MLS implementation isn't aware of them. But it doesn't need to be as long as they are only relevant for the application. This way using especially private extension (0xF000 - 0xFFFF) becomes much easier, because the protocol implementation doesn't need to be made aware of them.
That said, @keks found an issue in the validation check for this (see openmls#1487). This is part of the larger effort of getting all validation checks into OpeMLS (see the validation label for some of them).
Note: This PR sits on top of PR #16
This PR adds support for metadata and immutable metadata extensions.