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

[Behcet Sarikaya <[e-mail]>]

Hi Mike,


On Tue, Aug 11, 2026 at 10:01 AM Mike Ounsworth <[e-mail]>
wrote:

>
> 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?
>
>
> Fine.

>
> expand at first use: PQC post quantum cryptography  (PQC)
>
> [MikeO]: Good catch.
>
>
>
> in in this
>    specification; this is discussed further
>
> Here there were two "in" s.

PKIX-related Public Key Infrastructure X.509
>
> Fine

> [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.
>
> Fine


> 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?
>
> No.

>
> 9. Security Considerations
> dual algorithm security
>
> [MikeO]: I don't understand these comments. Can you explain further what
> change you are looking for here?
>
> Fine

>
> 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.
>
>
So your fixes above are OK, just add one more and then publish it.

Behcet

> 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]
>>
>