Drop DER encoding for composite ML-KEM functions

[chris-wood]

Closes #88

I also moved content around in this PR to make it flow a bit better, e.g., by moving security-relevant stuff to the security considerations and keeping the main implementation details in the primary document.

[ounsworth]

Thanks @chris-wood lots of good changes. @johngray-dev we'll need to sync up the section re-arranging in composite-sigs to match.

Chris, ironically, I think the one thing you have not done in your PR is drop the DER encoding. The ASN.1 SEQUENCE wrapper is still there, so in fact this does not close #88

 CompositeKEMPublicKey ::= SEQUENCE SIZE (2) OF BIT STRING

What was your intention there?

[chris-wood]

The DER encoding is still present for those that want to use it. However, the outputs of the composite ML-KEM key generation function are distinctly not these CompositeKEMPublicKey values. They're internal, implementation-specific values. Callers can then invoke SerializePublicKey, which is the model for HPKE, to produce a simple, wire-format-encoded public key, or they can encode it using CompositeKEMPublicKey if they need to.

The point of this PR is to allow both encodings. Does that clarify?

[ounsworth]

The point of this PR is to allow both encodings. Does that clarify?

That sounds super confusing for implementers. Let's just do one encoding. Let's drop the DER entirely.

But that does mean that we're going to have to list out explicit byte cutoffs where the first ends and the next begins.

[chris-wood]

That sounds super confusing for implementers. Let's just do one encoding. Let's drop the DER entirely.

I would be pleased with this outcome. I'll update the PR to match.

But that does mean that we're going to have to list out explicit byte cutoffs where the first ends and the next begins.

No? These outputs are fixed-length. There's no need to encode the lengths.

[johngray-dev]

We are trying to keep the Composite Signatures and Composite KEM documents in similar alignment structurally. I have opened a similar issue for composite signatures (lamps-wg/draft-composite-sigs#85). We had planned to completely remove the ASN.1 wrapping and keep the similar document structure (where possible) and not have multiple encodings. It looks like you are okay with that Chris which is great. So Chris I'll use what you did in Composite KEM as a kind of template to update composite signatures, and then maybe add some tweaks into your branch (fully remove ASN.1) before final merging. I hope you are okay with that. I was thinking of adding a simple ML-KEM / ML-DSA size table for key reconstitution.

[chris-wood]

@johngray-dev that works for me -- do you want to take over this PR?

[johngray-dev]

Sure, I can take over this PR since I was just starting the same thing on composite sigs, and I like the way you specified the serialization process, so I'll replicate that in Signatures as well (since the composite key serialization procedures are basically the same thing)... :)