Giters
openmls
/
annotations
Annotation tool to support software development.
Geek Repo:
Geek Repo
Github PK Tool:
Github PK Tool
Stargazers:
Watchers:
3
Issues:
50
Forks:
1
openmls/annotations Issues
Escape HTML entities.
Updated
a year ago
[Annotation] Verify that the signature on the KeyPackage is valid using the public key in leaf_node.credential.
Updated
2 years ago
[Annotation] Verify that the leaf_node of the KeyPackage is valid for a KeyPackage according to Section 7.3.
Updated
2 years ago
[Annotation] Verify that the ciphersuite and protocol version of the KeyPackage match those in the GroupContext.
Updated
2 years ago
[Annotation] 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.
Updated
2 years ago
[Annotation] A KeyPackage object with an invalid signature field MUST be considered malformed.
Updated
2 years ago
[Annotation] Likewise, the leaf_node field MUST be valid for the ciphersuite, including both the encryption_key and signature_key fields.
Updated
2 years ago
[Annotation] The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite, and it MUST be unique among the set of KeyPackages created by this client.
Updated
2 years ago
[Annotation] KeyPackages are intended to be used only once and SHOULD NOT be reused except in the case of last resort (see Section 16.6).
Updated
2 years ago
[Annotation] Verify that the value of leaf_node.encryption_key is different from the value of the init_key field.
Updated
2 years ago
[Annotation] Extension included in the extensions or leaf_node.extensions fields MUST be included in the leaf_node.capabilities field.
Updated
2 years ago
[Annotation] The field leaf_node.leaf_node_source of the LeafNode in a KeyPackage MUST be set to key_package.
Updated
2 years ago
[Annotation] Proposal and extension types defined in this document are considered "default" and thus need not be listed, while any credential types the application wishes to use MUST be listed.
Updated
2 years ago
[ValSem / LeafNode / RequiredCapabilities] Check that leaf node supports all required capabilities.
Updated
2 years ago
[ValSem / LeafNode / Lifetime] Ensure that lifetimes are acceptable.
Updated
a year ago
[ValSem /LeafNode / Signature]: Ensure that `LeafNode`s always have a valid signature.
Closed
2 years ago
feat: Provide read-only mode and host document publicly.
Closed
2 years ago
Comments count
1
[Annotation] Each modification of LeafNode content MUST be reflected by a change in its signature.
Updated
a year ago
Comments count
1
[Annotation] Applications MUST define a maximum total lifetime that is acceptable for a LeafNode, and reject any LeafNode where the total lifetime is longer than this duration.
Updated
a year ago
[Annotation] Extensions that appear in the extensions field of a LeafNode MUST be included in the extensions field of the capabilities field, and the credential type used in the LeafNode MUST be included in the credentials field of the capabilities field.
Updated
2 years ago
[Annotation] The public key encoded in the subjectPublicKeyInfo of the end-entity certificate MUST be identical to the signature_key in the LeafNode containing this credential.
Updated
2 years ago
[Annotation] The sender MUST include the reuse guard in the reuse_guard field of the sender data object, so that the recipient of the message can use it to compute the nonce to be used for decryption.
Updated
2 years ago
[Annotation] To avoid this situation, the sender of a message MUST generate a fresh random four-byte "reuse guard" value and XOR it with the first four bytes of the nonce from the key schedule before using the nonce for encryption.
Updated
2 years ago
[Annotation] 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.
Updated
2 years ago
[Annotation] The padding field MUST be filled with all zero bytes.
Updated
2 years ago
[Annotation] When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed.
Updated
2 years ago
<deleted>
Closed
2 years ago
feat: Add a link to the rendered document.
Updated
2 years ago
feat: Reduce the annotation metadata to a minimum.
Updated
2 years ago
feat: Edit the annotation metadata only.
Closed
2 years ago
[Annotation] Verify that the credential's presented identifiers are correctly associated with the member's LeafNode (AS).
Updated
2 years ago
[Annotation] In cases where a member's credential is being replaced, such as Update and Commit cases above, the AS MUST also verify that the set of presented identifiers in the new credential is valid as a successor to the set of presented identifiers in the old credential, according to the application's policy.
Updated
2 years ago
[Annotation] Verify that signature_key and encryption_key are unique among the members of the group.
Updated
2 years ago
[Annotation] Verify the leaf_node_source field.
Updated
2 years ago
[Annotation] 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.
Updated
2 years ago
feat: Handle tagging.
Updated
2 years ago
feat: Implement some form of deletion.
Updated
2 years ago
[Annotation] Verify the lifetime field (receive).
Updated
2 years ago
[Annotation] Verify the lifetime field (send).
Updated
2 years ago
[Annotation] 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.
Updated
2 years ago
[Annotation] Verify that the LeafNode is compatible with the group's parameters.
Updated
2 years ago
[Annotation] Verify that the signature on the LeafNode is valid using signature_key.
Updated
a year ago
Comments count
1
[Annotation] Verify that the credential in the LeafNode is valid as described in Section 5.3.1.
Updated
2 years ago
[Annotation] When decoding, values using more bits than necessary MUST be treated as malformed.
Updated
2 years ago
Disable unused features such as "replies".
Updated
a year ago
Give `mode: "html"` with `<iframe>` a try.
Closed
2 years ago
Comments count
1
[Annotation] The encoded value MUST use the smallest number of bits required to represent the value.
Updated
2 years ago
<deleted>
Closed
2 years ago
<deleted>
Closed
2 years ago
Provide a config that replaces all hard-coded values.
Closed
2 years ago