MIME-Version: 1.0
References: 
 <178517046122.1199998.12607390288355121397@dt-datatracker-d4d6ff9d9-fsx7d>
In-Reply-To: 
 <178517046122.1199998.12607390288355121397@dt-datatracker-d4d6ff9d9-fsx7d>
From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Tue, 11 Aug 2026 10:00:42 -0500
Message-ID: 
 <CAKZgXHpnspEp=K2cKKniNwTZfxH=bbSKzqehec9jUQ=1xED7Sg@mail.gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Content-Type: multipart/alternative; boundary="000000000000ca10400658c6bc6a"
Message-ID-Hash: K57VECWMTNMEJ6CVGHDYDZQYASAXGVD7
CC: gen-art@ietf.org, draft-ietf-lamps-pq-composite-kem.all@ietf.org,
 last-call@ietf.org, spasm@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BGen-art=5D_Re=3A_=5Blamps=5D_draft-ietf-lamps-pq-composite-kem-?=
 =?utf-8?q?18_ietf_last_call_Genart_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/gen-art/mBdGy6l0MumEl5AhgCTECCbxasw>

--000000000000ca10400658c6bc6a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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/c70e297a2c2458415388=
e00308e9cf0b8fa59753
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=E2=80=93Shamir=E2=80=93Adleman cryptosystem in the Optima=
l 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 <
noreply@ietf.org> 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 i=
n
> 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 -- spasm@ietf.org
> To unsubscribe send an email to spasm-leave@ietf.org
>

--000000000000ca10400658c6bc6a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Hi Behcet Sarikaya, thank you for the review.<br><br>I=
 have made some fixes to address these comments here:<br><a href=3D"https:/=
/github.com/lamps-wg/draft-composite-kem/commit/c70e297a2c2458415388e00308e=
9cf0b8fa59753">https://github.com/lamps-wg/draft-composite-kem/commit/c70e2=
97a2c2458415388e00308e9cf0b8fa59753</a><br>but I will hold pushing to datat=
racker because I have a few clarifying questions back to you below.<br><br>=
<br><br>Section 1<br>RSA vs RSA-OAEP is not explained at all<br><br>[MikeO]=
: This spec references a pile of cryptographic algorithms, including ML-KEM=
, RSA-OAEP, ECDH, X25519, X448, and SHA3. We don&#39;t really &quot;explain=
&quot; any of them, but references to their specifications are included in =
Appendix B.<br>The opining sentence of Section 1 does at least expand the a=
cronym &quot;OAEP&quot; and mention that this is a mode of RSA:<br>&quot;tr=
aditional cryptographic key establishment algorithms in common use -- namel=
y the Rivest=E2=80=93Shamir=E2=80=93Adleman cryptosystem in the Optimal Asy=
mmetric Encryption Padding mode (RSA-OAEP), and elliptic curve Diffie-Hellm=
an (ECDH) -- will become vulnerable to quantum attacks.&quot;<br><br>[MikeO=
]: If that&#39;s not sufficient, then maybe you could explain further what =
level of explanation you feel is missing?<br><br><br><br>expand at first us=
e: PQC post quantum cryptography =C2=A0(PQC)<br><br>[MikeO]: Good catch.<br=
><br><br><br>in in this<br>=C2=A0 =C2=A0specification; this is discussed fu=
rther<br><br>PKIX-related Public Key Infrastructure X.509<br><br>[MikeO]: I=
 don&#39;t understand these comments. Can you explain further what change y=
ou are looking for here?<br><br><br><br>Post-Quantum / Traditional (PQ/T) H=
ybrids<br>combined<br>idea seems to be central to this document<br>this giv=
es stronger algorithms since<br>an attacker would need to break all of them=
<br>=C2=A0 =C2=A0simultaneously to compromise the protected data<br>=C2=A0 =
=C2=A0<br>[MikeO]: I added a forward link to the Security Considerations th=
at discuss the properties of PQ/T hybrids in more detail.<br><br>1.1<br>pra=
mater sets<br><br>[MikeO]: Good catch.<br><br>2.2<br><br>KEM Encaps(pk) -&g=
t; (ss, ct) =C2=A0&quot;.&quot; missing?<br><br>[MikeO]: Fixed.<br><br>Adde=
d complete test vectors in Version -07 of this document<br>contributing alm=
ost 60 pages<br><br>[MikeO]: This is true, are you asking for some kind of =
change here?<br><br><br>9. Security Considerations<br>dual algorithm securi=
ty<br><br>[MikeO]: I don&#39;t understand these comments. Can you explain f=
urther what change you are looking for here?<br><br><br>In Section 10 there=
 is<br>10. Operational Considerations<br><br><br>calling for an Ops area re=
view?<br><br>[MikeO]: These Operational Considerations are really quite cry=
ptography-specific, so I&#39;m not sure that an OPS Dir review would add mu=
ch, but of course I would welcome more eyes. </div><br><div class=3D"gmail_=
quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, =
27 Jul 2026 at 11:43, Behcet Sarikaya via Datatracker &lt;<a href=3D"mailto=
:noreply@ietf.org">noreply@ietf.org</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Document: draft-ietf-lamps-pq-composite-=
kem<br>
Title: Composite ML-KEM for use in X.509 Public Key Infrastructure<br>
Reviewer: Behcet Sarikaya<br>
Review result: Almost Ready<br>
<br>
I am the assigned Gen-ART reviewer for this draft. The General Area<br>
Review Team (Gen-ART) reviews all IETF documents being processed<br>
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just<br>
like any other last call comments.<br>
<br>
For more information, please see the FAQ at<br>
<br>
&lt;<a href=3D"https://wiki.ietf.org/en/group/gen/GenArtFAQ" rel=3D"norefer=
rer" target=3D"_blank">https://wiki.ietf.org/en/group/gen/GenArtFAQ</a>&gt;=
.<br>
<br>
Document: draft-ietf-lamps-pq-composite-kem-18<br>
Reviewer: Behcet Sarikaya<br>
Review Date: 2026-07-27<br>
IETF LC End Date: 2026-07-27<br>
IESG Telechat date: Not scheduled for a telechat<br>
<br>
Summary:<br>
This document defines combinations <br>
of US NIST Module-Lattice-based Key Encapsulation Mechanism i.e. ML-KEM in =
hybrid with<br>
=C2=A0 =C2=A0traditional algorithms RSA-OAEP, ECDH, X25519, and X448<br>
Major issues:<br>
None<br>
Minor issues:<br>
<br>
Nits/editorial comments:<br>
<br>
Section 1<br>
RSA vs RSA-OAEP is not explained at all<br>
<br>
expand at first use: PQC post quantum cryptography=C2=A0 (PQC)<br>
<br>
in in this<br>
=C2=A0 =C2=A0specification; this is discussed further <br>
<br>
PKIX-related Public Key Infrastructure X.509<br>
<br>
<br>
Post-Quantum / Traditional (PQ/T) Hybrids <br>
combined<br>
idea seems to be central to this document<br>
this gives stronger algorithms since <br>
an attacker would need to break all of them<br>
=C2=A0 =C2=A0simultaneously to compromise the protected data<br>
<br>
1.1<br>
pramater sets<br>
<br>
2.2<br>
<br>
KEM Encaps(pk) -&gt; (ss, ct)=C2=A0 &quot;.&quot; missing?<br>
<br>
Added complete test vectors in Version -07 of this document<br>
contributing almost 60 pages<br>
<br>
<br>
9. Security Considerations<br>
dual algorithm security<br>
<br>
In Section 10 there is <br>
10. Operational Considerations<br>
<br>
<br>
calling for an Ops area review?<br>
<br>
<br>
<br>
_______________________________________________<br>
Spasm mailing list -- <a href=3D"mailto:spasm@ietf.org" target=3D"_blank">s=
pasm@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:spasm-leave@ietf.org" tar=
get=3D"_blank">spasm-leave@ietf.org</a><br>
</blockquote></div>

--000000000000ca10400658c6bc6a--