Skip to content

Issues: openmls/annotations

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

42 Open 8 Closed
42 Open 8 Closed
Author
Filter by author
Loading
Label
Filter by label
Loading
Use alt + click/return to exclude labels
or ⇧ + click/return for logical OR
Projects
Filter by project
Loading
Milestones
Filter by milestone
Loading
Assignee
Filter by who’s assigned
Sort
Sort by
Newest Oldest Most commented Least commented Recently updated Least recently updated Best match
Most reactions
👍 👎 😄 🎉 😕 ❤️ 🚀 👀

Issues list

Escape HTML entities. bug Something isn't working
#50 opened Jan 31, 2023 by duesee
[Annotation] Verify that the signature on the KeyPackage is valid using the public key in leaf_node.credential. annotation key_package
#49 opened Jan 18, 2023 by duesee
[Annotation] Verify that the leaf_node of the KeyPackage is valid for a KeyPackage according to Section 7.3. annotation key_package
#48 opened Jan 18, 2023 by duesee
[Annotation] Verify that the ciphersuite and protocol version of the KeyPackage match those in the GroupContext. annotation key_package
#47 opened Jan 18, 2023 by duesee
[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. annotation key_package
#46 opened Jan 18, 2023 by duesee
[Annotation] A KeyPackage object with an invalid signature field MUST be considered malformed. annotation key_package
#45 opened Jan 18, 2023 by duesee
[Annotation] Likewise, the leaf_node field MUST be valid for the ciphersuite, including both the encryption_key and signature_key fields. annotation key_package leaf_node
#44 opened Jan 18, 2023 by duesee
[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. annotation key_package
#43 opened Jan 18, 2023 by duesee
[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). annotation key_package
#42 opened Jan 18, 2023 by duesee
[Annotation] Verify that the value of leaf_node.encryption_key is different from the value of the init_key field. annotation key_package
#41 opened Jan 17, 2023 by duesee
[Annotation] Extension included in the extensions or leaf_node.extensions fields MUST be included in the leaf_node.capabilities field. annotation key_package
#40 opened Jan 17, 2023 by duesee
[Annotation] The field leaf_node.leaf_node_source of the LeafNode in a KeyPackage MUST be set to key_package. annotation key_package leaf_node
#39 opened Jan 17, 2023 by duesee
[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. annotation leaf_node
#38 opened Jan 17, 2023 by duesee
[ValSem / LeafNode / RequiredCapabilities] Check that leaf node supports all required capabilities.
#37 opened Jan 16, 2023 by duesee
2 tasks
[ValSem / LeafNode / Lifetime] Ensure that lifetimes are acceptable. validation
#36 opened Jan 11, 2023 by duesee
3 tasks
[Annotation] Each modification of LeafNode content MUST be reflected by a change in its signature. annotation leaf_node
#33 opened Jan 10, 2023 by duesee
1
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. annotation leaf_node
#32 opened Jan 10, 2023 by duesee
[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. annotation credential leaf_node
#31 opened Jan 10, 2023 by duesee
[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. annotation leaf_node x509
#30 opened Jan 10, 2023 by duesee
[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. annotation
#29 opened Jan 10, 2023 by duesee
[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. annotation
#28 opened Jan 10, 2023 by duesee
[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. annotation codec Validation related to tls_codec, serialization, and deserialization.
#27 opened Jan 10, 2023 by duesee
[Annotation] The padding field MUST be filled with all zero bytes. annotation codec Validation related to tls_codec, serialization, and deserialization.
#26 opened Jan 10, 2023 by duesee
[Annotation] When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed. annotation codec Validation related to tls_codec, serialization, and deserialization.
#25 opened Jan 10, 2023 by duesee
feat: Add a link to the rendered document. enhancement New feature or request
#23 opened Jan 10, 2023 by duesee
1 task
ProTip! Updated in the last three days: updated:>2024-11-13.