[lamps] Re: Mohamed Boucadair's No Objection on draft-ietf-lamps-cms-composite-kem-01: (with COMMENT)

[Daniel Van Geest <[e-mail]>]

Hi Mohamed, thank you for the review.

Your comments will be addressed in the next document version, except the parameter name comments. Thie document is a profile of RFC 9629 for Composite ML-KEM, so we are using the RFC 9629 function and parameter naming terminology.  The next version of the draft will add text with mapping between the RFC 9629 and Composite KEM terminology.  My other email [1] shows the state of the terminology across multiple RFCs and drafts, unfortunately the nice table I made is not showing up in the plaintext rendering in the link.

Thanks,
Daniel

[1] https://mailarchive.ietf.org/arch/msg/spasm/kYYsg_xpMenl-7wDH3VYtDmQ5Ik/
________________________________
From: Mohamed Boucadair via Datatracker <[e-mail]>
Sent: 10 September 2026 5:40 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Mohamed Boucadair's No Objection on draft-ietf-lamps-cms-composite-kem-01: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-lamps-cms-composite-kem-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-composite-kem/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Daniel, Mike, John, and Jan,

Thank you for the effort put into this specification.

FYI, I wanted to use the following for my review, but it seems this is not the
correct link:

CURRENT:
   Source for this draft and an issue tracker can be found at
   https://github.com/lamps-wg/draft-composite-kem.

Please find below some few comments:

# Add a reference to indicate where this is standardized

CURRENT:
   It was standardized with three parameter
   sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

# Same notations

Section 1.3 uses parameter names that are different from the ones in
I-D.ietf-lamps-pq-composite-kem. Nothing wrong here, but using the same names
would ease the mapping between the two specs.

# minimum desired security level

CURRENT:
   When Composite ML-KEM is employed in the CMS, the underlying
   components used within the KEMRecipientInfo structure SHOULD be
   consistent with a minimum desired security level.

At first read, I found the above (especially the “minimum desired security
level” part) not concrete enough. Seems some qualification is needed. I see
that same text is also present in RFC9936, though.

# Cite where the module is defined:

OLD:
   IANA is requested to allocate a value from the "SMI Security for S/
   MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry for the
   included ASN.1 module

NEW:
   IANA is requested to allocate a value from the "SMI Security for S/
   MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry for the
   ASN.1 module in Appendix A.

Cheers,
Med