Verify that the credential in the LeafNode is valid, as described in Section 5.3.1.

• ref

search code

notes:

• This is about what leaf nodes get passed into OpenMLS rather than what we do with them. Therefore this is an application-level check.

Verify that the signature on the LeafNode is valid using signature_key.

• ref

search code

no notes.

Verify that the LeafNode is compatible with the group's parameters. If the GroupContext has a required_capabilities extension, then the required extensions, proposals, and credential types MUST be listed in the LeafNode's capabilities field.

• ref

search code

notes:

• reported in https://github.com/xmtp/openmls/pull/19
• We currently test this when an Add and Update proposal is being committed.

Verify that the credential type is supported by all members of the group, as specified by the capabilities field of each member's LeafNode, and that the capabilities field of this LeafNode indicates support for all the credential types currently in use by other members.

• ref

search code

no notes.

Verify the `lifetime` field: If the LeafNode appears in a message being sent by the client, e.g., a Proposal or a Commit, then the client MUST verify that the current time is within the range of the lifetime field.

• ref
• ref

search code

notes:

• probably only done for key packages, but these should be the only leaf nodes with lifetimes anyway

Verify the `lifetime` field: If instead the LeafNode appears in a message being received by the client, e.g., a Proposal, a Commit, or a ratchet tree of the group the client is joining, it is RECOMMENDED that the client verifies that the current time is within the range of the lifetime field. (This check is not mandatory because the LeafNode might have expired in the time between when the message was sent and when it was received.)

• ref
• ref

search code

no notes.

Verify that the extensions in the LeafNode are supported by checking that the ID for each extension in the extensions field is listed in the capabilities.extensions field of the LeafNode.

• ref

search code

no notes.

Verify the `leaf_node_source` field: If the LeafNode appears in a KeyPackage, verify that leaf_node_source is set to key_package.

• ref
• ref

search code

no notes.

Verify the `leaf_node_source` field: If the LeafNode appears in an Update proposal, verify that leaf_node_source is set to update and that encryption_key represents a different public key than the encryption_key in the leaf node being replaced by the Update proposal.

• ref
• ref

search code

no notes.

Verify the `leaf_node_source` field: If the LeafNode appears in the leaf_node value of the UpdatePath in a Commit, verify that leaf_node_source is set to commit.

• ref
• ref

search code

no notes.

Verify that the following fields are unique among the members of the group: `signature_key`

• ref
• ref

search code

no notes.

Verify that the following fields are unique among the members of the group: `encryption_key`

• ref
• ref

search code

no notes.

Verify that the credential type used in the LeafNode is included in the credentials field of the capabilities field.

• ref

search code

no notes.

Verify that the cipher suite and protocol version of the KeyPackage match those in the GroupContext.

• ref

search code

no notes.

Verify that the leaf_node of the KeyPackage is valid for a KeyPackage according to Section 7.3.

• ref

search code

notes:

• This is checked when processing adds in commit messages. It is the responsibility of the caller to validate key packages before using them in Add proposals.

Verify that the signature on the KeyPackage is valid using the public key in `leaf_node.credential`.

• ref

search code

notes:

• this looks like a bug in the RFC. It should be signed using leaf_node.signature_key, but the credential can have opinions on whether that key is valid.

Verify that the value of `leaf_node.encryption_key` is different from the value of the `init_key` field.

• ref

search code

no notes.

If a client receives a KeyPackage carried within an MLSMessage object, then it MUST verify that the version field of the KeyPackage has the same value as the version field of the MLSMessage.

• ref

search code

no notes.

It contains an individual proposal that is invalid as specified invalid Section 12.1.

• ref

search code

no notes.

It contains an Update proposal generated by the committer.

• ref

search code

no notes.

It contains a Remove proposal that removes the committer.

• ref

search code

no notes.

It contains multiple Update and/or Remove proposals that apply to the same leaf. If the committer has received multiple such proposals they SHOULD prefer any Remove received, or the most recent Update if there are no Removes.

• ref

search code

no notes.

It contains multiple Add proposals that contain KeyPackages that represent the same client according to the application (for example, identical signature keys).

• ref

search code

notes:

• We check that keys are unique. Beyond that it's an application-level concern.

It contains an Add proposal with a KeyPackage that represents a client already in the group according to the application, unless there is a Remove proposal in the list removing the matching client from the group.

• ref

search code

notes:

• We check that keys are unique. Beyond that it's an application-level concern.

It contains multiple PreSharedKey proposals that reference then same PreSharedKeyID.

• ref

search code

no notes.

It contains multiple GroupContextExtension proposals.

• ref

search code

no notes.

It contains a ReInit proposal together with any other proposal. If the committer has received other proposals during the epoch, they SHOULD prefer them over the ReInit proposal, allowing the ReInit to be resent and applied in a subsequent epoch.

• ref

search code

notes:

• We don't support ReInit yet (<a href="https://github.com/openmls/openmls/issues/1685">openmls#1685</a>)

It contains an ExternalInit proposal.

• ref

search code

no notes.

It contains a Proposal with a non-default proposal type that is not supported by some members of the group that will process the Commit (i.e., members being added or removed by the Commit do not need to support the proposal type).

• ref

search code

no notes.

After processing the Commit the ratchet tree is invalid, in particular, if it contains any leaf node that is invalid according to Section 7.3.

• ref

search code

notes:

• This is difficult to check, because at that point the state has already been changed. It would be nice if we instead could show before applying the diff, that applying the diff will result in a valid tree.

Exactly one ExternalInit

• ref

search code

no notes.

At most one Remove proposal, with which the joiner removes an old version of themselves. If a Remove proposal is present, then the LeafNode in the path field of the external Commit MUST meet the same criteria as would the LeafNode in an Update for the removed leaf (see Section 12.1.2). In particular, the credential in the LeafNode MUST present a set of identifiers that is acceptable to the application for the removed participant.

• ref

search code

notes:

• We are checking that there is not more than one Remove proposal in external commits, but the application has to ensure that the provided key package satisfies the requirements.

Zero or more PreSharedKey proposals

• ref

search code

notes:

• Since we can only include a non-negative integer number of proposals, it necessarily is "zero or more". There is no check required.

No other proposals

• ref

search code

no notes.

External Commits MUST contain a path field (and is therefore a "full" Commit). The joiner is added at the leftmost free leaf node (just as if they were added with an Add proposal), and the path is calculated relative to that leaf node.

• ref

search code

no notes.

The Commit MUST NOT include any proposals by reference, since an external joiner cannot determine the validity of proposals sent within the group.

• ref

search code

no notes.

External Commits MUST be signed by the new member. In particular, the signature on the enclosing AuthenticatedContent MUST verify using the public key for the credential in the leaf_node of the path field.

• ref

search code

no notes.

The sender type for the AuthenticatedContent encapsulating the external Commit MUST be new_member_commit.

• ref

search code

notes:

• This is implicit, because it's the value on which our decision how to process the message is based.

An Add proposal is invalid if the KeyPackage is invalid according to Section 10.1.

• ref

search code

no notes.

An Update proposal is invalid if the LeafNode is invalid for an Update proposal according to Section 7.3.

• ref

search code

no notes.

A Remove proposal is invalid if the removed field does not identify a non-blank leaf node.

• ref

search code

notes:

• the tests we have a are not great. The check and basic tests were added in PR https://github.com/openmls/openmls/pull/1655

The PreSharedKey proposal is not being processed as part of a reinitialization of the group (see Section 11.2), and the PreSharedKeyID has psktype set to resumption and usage set to reinit.

• ref

search code

notes:

• PSK support not implemented

The PreSharedKey proposal is not being processed as part of a subgroup branching operation (see Section 11.3), and the PreSharedKeyID has psktype set to resumption and usage set to branch.

• ref

search code

notes:

• PSK support not implemented

The psk_nonce is not of length KDF.Nh.

• ref

search code

no notes.

A ReInit proposal is invalid if the version field is less than the version for the current group.

• ref

search code

notes:

• this feature is not implemented

A GroupContextExtensions proposal is invalid if it includes a required_capabilities extension and some members of the group do not support some of the required capabilities (including those added in the same Commit, and excluding those removed).

• ref

search code

notes:

• currently, we only test for missing supported extension types, not proposal or proposal types.

For each UpdatePathNode, the resolution of the corresponding copath node MUST exclude all new leaf nodes added as part of the current Commit. The length of the encrypted_path_secret vector MUST be equal to the length of the resolution of the copath node (excluding new leaf nodes), with each ciphertext being the encryption to the respective resolution node.

• ref

search code

no notes.

Verify that the epoch field of the enclosing FramedContent is equal to the epoch field of the current GroupContext object.

• ref

search code

no notes.

Unprotect the Commit using the keys from the current epoch: If the message is encoded as PublicMessage, verify the membership MAC using the membership_key.

• ref
• ref

search code

no notes.

Verify the signature on the FramedContent message as described in Section 6.1.

• ref

search code

no notes.

Verify that the proposals vector is valid according to the rules in Section 12.2.

• ref

search code

no notes.

Verify that all PreSharedKey proposals in the proposals vector are available.

• ref

search code

no notes.

Verify that the path value is populated if the proposals vector contains any Update or Remove proposals, or if it's empty. Otherwise, the path value MAY be omitted.

• ref

search code

no notes.

If the path value is populated, validate it and apply it to the tree: Validate the LeafNode as specified in Section 7.3. The leaf_node_source field MUST be set to commit.

• ref
• ref

search code

notes:

• This is done when parsing the update path

If the path value is populated, validate it and apply it to the tree: Verify that the encryption_key value in the LeafNode is different from the committer's current leaf node.

• ref
• ref

search code

notes:

• we check that it is different from the keys of _any_ current member. Still need to test this check.

If the path value is populated, validate it and apply it to the tree: Verify that none of the public keys in the UpdatePath appear in any node of the new ratchet tree.

• ref
• ref

search code

no notes.

Recipients of an MLSMessage MUST verify the signature with the key depending on the sender_type of the sender as described above.

• ref

search code

notes:

• NB: This is about picking the right key, not verifying the signature. That is done in valn1302 and valn1304.

When decoding a PublicMessage into an AuthenticatedContent, the application MUST check membership_tag and MUST check that the FramedContentAuthData is valid.

• ref

search code

no notes.

The padding field is set by the sender, by first encoding the content (via the select) and the auth field, and then appending the chosen number of zero bytes. A receiver identifies the padding field in a plaintext decoded from PrivateMessage.ciphertext by first decoding the content and the auth field; then the padding field comprises any remaining octets of plaintext. The padding field MUST be filled with all zero bytes. A receiver MUST verify that there are no non-zero bytes in the padding field, and if this check fails, the enclosing PrivateMessage MUST be rejected as malformed. This check ensures that the padding process is deterministic, so that, for example, padding cannot be used as a covert channel.

• ref

search code

no notes.

When decoding a PrivateMessageContent, the application MUST check that the FramedContentAuthData is valid.

• ref

search code

no notes.

When constructing a SenderData object from a Sender object, the sender MUST verify Sender.sender_type is member and use Sender.leaf_index for SenderData.leaf_index.

• ref

search code

no notes.

When parsing a SenderData struct as part of message decryption, the recipient MUST verify that the leaf index indicated in the leaf_index field identifies a non-blank node.

• ref

search code

no notes.

On receiving a FramedContent containing a Proposal, a client MUST verify the signature inside FramedContentAuthData and that the epoch field of the enclosing FramedContent is equal to the epoch field of the current GroupContext object. If the verification is successful, then the Proposal should be cached in such a way that it can be retrieved by hash (as a ProposalOrRef object) in a later Commit message.

• ref

search code

no notes.

If a PreSharedKeyID is part of the GroupSecrets and the client is not in possession of the corresponding PSK, return an error. Additionally, if a PreSharedKeyID has type resumption with usage reinit or branch, verify that it is the only such PSK.

• ref

search code

notes:

• reinit and branch are not implement so far

Verify the signature on the GroupInfo object. The signature input comprises all of the fields in the GroupInfo object except the signature field. The public key is taken from the LeafNode of the ratchet tree with leaf index signer. If the node is blank or if signature verification fails, return an error.

• ref

search code

no notes.

Verify that the group_id is unique among the groups that the client is currently participating in.

• ref

search code

notes:

• This is an application-level concern. We only handle individual groups

Verify that the cipher_suite in the GroupInfo matches the cipher_suite in the KeyPackage.

• ref

search code

notes:

• This one is a bit unclear. It does not clearly state which key package is meant (though we can guess it's the new member's key package), and also GroupInfo itself doesn't even have a cipher_suite (but the GroupContext in there does).
• And what about the cipher_suite of the Welcome message itself?
• The current status is that we do the check and compare the group context cipher suite with that of the key package of the new member. We also check that they match with the welcome message.

Verify the integrity of the ratchet tree: Verify that the tree hash of the ratchet tree matches the tree_hash field in GroupInfo.

• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: For each non-empty parent node, verify that it is "parent-hash valid", as described in Section 7.9.2.

• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: For each non-empty leaf node, validate the LeafNode as described in Section 7.3.

• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: For each non-empty parent node and each entry in the node's unmerged_leaves field: Verify that the entry represents a non-blank leaf node that is a descendant of the parent node.

• ref
• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: For each non-empty parent node and each entry in the node's unmerged_leaves field: Verify that every non-blank intermediate node between the leaf node and the parent node also has an entry for the leaf node in its unmerged_leaves.

• ref
• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: For each non-empty parent node and each entry in the node's unmerged_leaves field: Verify that the encryption key in the parent node does not appear in any other node of the tree.

• ref
• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: Verify the confirmation tag in the GroupInfo using the derived confirmation key and the confirmed_transcript_hash from the GroupInfo.

• ref
• ref

search code

no notes.

Verify the integrity of the ratchet tree: If a PreSharedKeyID was used that has type resumption with usage reinit or branch, verify that the epoch field in the GroupInfo is equal to 1.

• ref
• ref

search code

notes:

• reinit isn't currently implemented

Verify the integrity of the ratchet tree: For usage reinit, verify that the last Commit to the referenced group contains a ReInit proposal and that the group_id, version, cipher_suite, and group_context.extensions fields of the GroupInfo match the ReInit proposal. Additionally, verify that all the members of the old group are also members of the new group, according to the application.

• ref
• ref

search code

notes:

• reinit isn't currently implemented

Verify the integrity of the ratchet tree: For usage branch, verify that the version and cipher_suite of the new group match those of the old group, and that the members of the new group compose a subset of the members of the old group, according to the application.

• ref
• ref

search code

notes:

• branching isn't currently implemented

sender_type: external: The content_type of the message MUST be proposal.

• ref
• ref

search code

notes:

• This is implicit, because it's the value on which our decision how to process the message is based.

sender_type: external: the proposal_type MUST be a value that is allowed for external senders. Only the following types may be sent by an external sender: add, remove, psk, reinit, group_context_extensions.

• ref
• ref
• ref

search code

notes:

• Not all of the accepted proposal types are implemented yet.

sender_type: new_member_proposal: The content_type of the message MUST be proposal.

• ref
• ref

search code

notes:

• This is implicit, because it's the value on which our decision how to process the message is based.

sender_type: new_member_proposal: The proposal_type of the Proposal MUST be add.

• ref
• ref

search code

no notes.

LeafNode: application_id, GREASE

• ref
• ref

search code

no notes.

GroupInfo: ratchet_tree, external_pub, GREASE

• ref
• ref

search code

no notes.

GroupContext: required_capabilities, external_senders

• ref
• ref

search code

no notes.

KeyPackage: GREASE

• ref
• ref

search code

no notes.