Import the canonical IETF MLS test vectors from mlswg/mls-implementations
to verify wire-format compatibility with OpenMLS and mls-rs. These are
the same test vectors used by both Rust implementations for cross-
implementation interop validation.
Phase 1 (Foundations):
- crypto-basics.json: RefHash, ExpandWithLabel, DeriveSecret,
DeriveTreeSecret, SignWithLabel, EncryptWithLabel
- tree-math.json: Binary tree arithmetic for all tree sizes
- key-schedule.json: Full 12-secret epoch key derivation chain
- secret-tree.json: Per-sender handshake/application ratchet keys
Phase 2 (Wire Format):
- messages.json: Round-trip serialization of all MLS message types
- message-protection.json: PublicMessage/PrivateMessage framing
- transcript-hashes.json: Confirmed/interim transcript hash computation
Phase 3 (TreeKEM):
- treekem.json: UpdatePath processing, path secret derivation
- tree-validation.json: Tree hash and resolution verification
- tree-operations.json: Add/remove/update proposal application
- welcome.json: Welcome message deserialization
Phase 4 (End-to-End Protocol):
- passive-client-welcome.json: Join via Welcome, follow epochs
- passive-client-handling-commit.json: Process varied commit types
- passive-client-random.json: Randomized multi-epoch scenarios
Initial test results reveal ExpandWithLabel encoding discrepancy
in HkdfLabel context field that cascades to most crypto operations.
Tree math tests pass fully. These findings demonstrate the value of
importing standard interop vectors.
https://claude.ai/code/session_01NocQDWj2Y92FugjfgazzL3
Claude
fe505c2fb9