[secdir] Re: draft-ietf-lamps-pq-composite-kem-18 ietf last call Secdir review

[Mike Ounsworth <[e-mail]>]

(@Deb Cooley <[e-mail]> -- to my knowledge, this clears all
outstanding reviews that would block you from telechat'ing this doc)


Hi Linda,

Thank you for the careful review of our very long document :)

About the split-vs-combined keygen text -- that was a careful balance
between people who felt strongly that the composite key should be a single
object all the way down into the HSM, people who wanted to continue using
their legacy HSM and simply add a PQ HSM next to it, and people who wanted
the hybrid KEMs defined in draft-irtf-cfrg-hybrid-kems to be considered
compatible and identical to this spec, which required allowing the
single-seed keygen. This text was much-bashed during WG and this text is
what resulted. As Russ says: "A compromise is successful when all parties
are equally unhappy". Specifically, I would be hesitant to add any KDF
guidance out of fear of subtly disallowing something that the CFRG draft
needs.

About:

That is useful realism, but it may read as permission.

Yeah. I also, personally, agree with that comment and would love to rip out
that text, but as a compromise to someone who told us point-blank that they
are going to do that bad thi, they wanted us to clearly document the
consequences of violating that normative requirement.

Thanks for pointing out all the typos. I'm about to publish -20 which fixes
all of those.


On Thu, 13 Aug 2026 at 20:16, Linda Dunbar via Datatracker <[e-mail]>
wrote:

> Document: draft-ietf-lamps-pq-composite-kem
> Title: Composite ML-KEM for use in X.509 Public Key Infrastructure
> Reviewer: Linda Dunbar
> Review result: Has Nits
>
> The document is well written, but has many typos.
>
> Minor Issues:
> - Section 3.1.1 allows a modified deterministic
> Composite-ML-KEM<OID>.KeyGen(seed) interface where one component may be
> generated from the seed and the other from random, or the input seed may be
> cryptographically expanded to produce seeds for both components. It then
> says
> the security analysis of such a modified process is outside the document’s
> scope. Given the strict requirement that both component keys be freshly
> generated and not reused, this seems like an important security-sensitive
> extension. It would be nice to add minimum guidance that seed expansion, if
> used, must provide domain separation between component algorithms and
> composite
> algorithm identifiers, and must use an approved KDF or DRBG suitable for
> generating independent component seeds.
>
> - The draft clearly states that component keys must be freshly generated
> and
> must not be reused in standalone or other composite contexts. However,
> Section
> 9.3 says designers are aware that some implementers may be forced to break
> this
> rule. That is useful realism, but it may read as permission.
>
> NITS:
>   s/pramater sets X25519 and X448/parameter sets X25519 and X448/
>
>   Need a space before "this": “mechanism.This generally means”
>
>   s/defined in in this specification/defined in this specification/
>
>   s/than an error occured/that an error occurred/?
>
>   s/cryptohraphically expanded/cryptographically expanded/
>
>   s/SHOULD NOT by applied/SHOULD NOT be applied/?
>
>   s/at least is principle/at least in principle/?
>
>   s/traditional compenent/traditional component/
>
>   What do you mean by saying "Generifying this construction"?
>
>   In Section 10.1.1, “Third” appears twice in the sequence of reasons. The
>   second one should probably be “Fourth.
>
>   s/ammendments/amendments/
>
>   In Appendix E.1, “indpendently is this is expected” appears to have
> multiple
>   typos.
>
> Best Regards,
> Linda Dunbar
>
>
> _______________________________________________
> secdir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> wiki: https://wiki.ietf.org/group/secdir/SecDirReview