Skip to content

MIP-05: enforce kind:446 content decoded length is a multiple of 280 bytes #35

@alltheseas

Description

@alltheseas

Context

MIP-05 kind:446 (Notification Request) content is a base64-encoded concatenation of one or more 280-byte EncryptedToken values. The spec requires (MIP-05 line 447):

Reject the rumor if the decoded byte length is not a multiple of 280.

Problem

JSON Schema cannot enforce "decoded base64 length is a multiple of N". The valid base64 string lengths for multiples of 280 bytes are: 376, 748, 1120, 1496, ... — an unbounded sequence with no single minLength/maxLength/pattern that captures it.

The schemata schema (mips/mip-05/kind-446/schema.yaml) correctly validates:

  • Base64 format (pattern)
  • At least one token (minLength: 376)

But it cannot reject payloads of 281 or 282 decoded bytes (which also produce 376-char base64 strings with different padding).

Proposed fix

In schemata-codegen generated validators for kind:446, add a check after base64 pattern validation:

decoded_length = base64_decoded_length(content)
if decoded_length == 0 || decoded_length % 280 != 0:
    reject

This could be:

  1. A new ValidatorAction type (e.g., check_base64_decoded_multiple) in the planner
  2. Or a kind-specific post-validation hook

The check applies to all 13 language emitters.

Related

Cross-field limitation (informational)

A similar JSON Schema limitation exists for MIP-00's i tag: the KeyPackageRef hash length (64/96/128 hex chars) depends on the mls_ciphersuite tag value (SHA-256/384/512). JSON Schema contains constraints are independent and cannot cross-reference. This could also be enforced in codegen validators if desired.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions