Check wether all checks have been addded

[keks]

A lot of checks have been added, but we have to double-check that all the checks mandated in the RFC are in the database

[keks]

One approach could be to generate CSS that highlights elements of the RFC that are already captured, so we see whether something is the database or not, without leaving the RFC.

[keks]

That CSS exists. Already found some missing checks, but there are probably more:

• these are probably all in tls_codec, so not missing
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-2.1.1-1
    • "When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed."
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-2.1.2-4
    • "When decoding, values using more bits than necessary MUST be treated as malformed"
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-2.1.2-7
    • "Vectors that start with the prefix "11" are invalid and MUST be rejected."
• framed content
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-6.1-6
    • "Recipients of an MLSMessage MUST verify the signature with the key depending on the sender_type of the sender as described above."
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-6.2-6
    • "When decoding a PublicMessage into an AuthenticatedContent, the application MUST check membership_tag and MUST check that the FramedContentAuthData is valid."
• public message
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-6.2-6
    • "When decoding a PublicMessage into an AuthenticatedContent, the application MUST check membership_tag and MUST check that the FramedContentAuthData is valid."
• private message
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-6.3.1-3
    • "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. "
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-6.3.1-10
    • "When decoding a PrivateMessageContent, the application MUST check that the FramedContentAuthData is valid."
  • https://www.rfc-editor.org/rfc/rfc9420.html#section-6.3.2-9
    • "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."

[franziskuskiefer]

@keks what was the conclusion here last week?

[keks]

There was none, as I didn't get around to working on this. It's on my list for this week again.

[franziskuskiefer]

What's the state here @keks ?