[Gen-art] Re: [lamps] draft-ietf-lamps-pq-composite-kem-18 ietf last call Genart review

[Mike Ounsworth <[e-mail]>]

Hi Behcet Sarikaya, thank you for the review.

I have made some fixes to address these comments here:
https://github.com/lamps-wg/draft-composite-kem/commit/c70e297a2c2458415388e00308e9cf0b8fa59753
but I will hold pushing to datatracker because I have a few clarifying
questions back to you below.



Section 1
RSA vs RSA-OAEP is not explained at all

[MikeO]: This spec references a pile of cryptographic algorithms, including
ML-KEM, RSA-OAEP, ECDH, X25519, X448, and SHA3. We don't really "explain"
any of them, but references to their specifications are included in
Appendix B.
The opining sentence of Section 1 does at least expand the acronym "OAEP"
and mention that this is a mode of RSA:
"traditional cryptographic key establishment algorithms in common use --
namely the Rivest–Shamir–Adleman cryptosystem in the Optimal Asymmetric
Encryption Padding mode (RSA-OAEP), and elliptic curve Diffie-Hellman
(ECDH) -- will become vulnerable to quantum attacks."

[MikeO]: If that's not sufficient, then maybe you could explain further
what level of explanation you feel is missing?



expand at first use: PQC post quantum cryptography  (PQC)

[MikeO]: Good catch.



in in this
   specification; this is discussed further

PKIX-related Public Key Infrastructure X.509

[MikeO]: I don't understand these comments. Can you explain further what
change you are looking for here?



Post-Quantum / Traditional (PQ/T) Hybrids
combined
idea seems to be central to this document
this gives stronger algorithms since
an attacker would need to break all of them
   simultaneously to compromise the protected data

[MikeO]: I added a forward link to the Security Considerations that discuss
the properties of PQ/T hybrids in more detail.

1.1
pramater sets

[MikeO]: Good catch.

2.2

KEM Encaps(pk) -> (ss, ct)  "." missing?

[MikeO]: Fixed.

Added complete test vectors in Version -07 of this document
contributing almost 60 pages

[MikeO]: This is true, are you asking for some kind of change here?


9. Security Considerations
dual algorithm security

[MikeO]: I don't understand these comments. Can you explain further what
change you are looking for here?


In Section 10 there is
10. Operational Considerations


calling for an Ops area review?

[MikeO]: These Operational Considerations are really quite
cryptography-specific, so I'm not sure that an OPS Dir review would add
much, but of course I would welcome more eyes.

On Mon, 27 Jul 2026 at 11:43, Behcet Sarikaya 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: Behcet Sarikaya
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-lamps-pq-composite-kem-18
> Reviewer: Behcet Sarikaya
> Review Date: 2026-07-27
> IETF LC End Date: 2026-07-27
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> This document defines combinations
> of US NIST Module-Lattice-based Key Encapsulation Mechanism i.e. ML-KEM in
> hybrid with
>    traditional algorithms RSA-OAEP, ECDH, X25519, and X448
> Major issues:
> None
> Minor issues:
>
> Nits/editorial comments:
>
> Section 1
> RSA vs RSA-OAEP is not explained at all
>
> expand at first use: PQC post quantum cryptography  (PQC)
>
> in in this
>    specification; this is discussed further
>
> PKIX-related Public Key Infrastructure X.509
>
>
> Post-Quantum / Traditional (PQ/T) Hybrids
> combined
> idea seems to be central to this document
> this gives stronger algorithms since
> an attacker would need to break all of them
>    simultaneously to compromise the protected data
>
> 1.1
> pramater sets
>
> 2.2
>
> KEM Encaps(pk) -> (ss, ct)  "." missing?
>
> Added complete test vectors in Version -07 of this document
> contributing almost 60 pages
>
>
> 9. Security Considerations
> dual algorithm security
>
> In Section 10 there is
> 10. Operational Considerations
>
>
> calling for an Ops area review?
>
>
>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>