I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.



The summary of the review is Ready with Nits.



This draft specifies how to do hybrid signatures with ML-DSA as the

post-quantum algorithm and various traditional algorithms.





Security Considerations

-----------------------



This draft does a good job of covering all the bases. It explains the

hybrid signature concept and motivation well. The Security Considerations
Section appears to be thorough and comprehensive.





Major/Minor Issues

------------------



None.





Nits

----



Should expand ML-DSA (Module-Lattice-Based Digital Signature Standard) on
first use in Abstract and Introduction. This is probably true of other
crypto acronyms. Consider including them in Section 1.1.



Section 5.2 extention -> extension



Should expand EUF-CMA and SUF-CMA and give reference to 9.2.1 and 9.2.2
respectively on first use of each.



Section 9.2: securtiy -> security

considiration -> consideration



In Sections 9.2.1 and 9.2.2, I think the difference between EUF-CMA and
SUF-CMA is not very clearly explained.



Section 9.2.2: The unusual sequence "=/=" is never defined.



Section 9.3: uses Foobar but does not include a reference to RFC 3092

which might be helpful to some readers



Section 9.5: "at least is principle," -> "at least in principle,"



Section 10.3: The sentence before the first "id-..." line needs to be
recast like all the following sentences in this Section. Otherwise, it is
not clear what it is talking about.



The nits checker says there are 5 lines that are too long.



References: RFC5758 appears in the references but not in the body of the
draft. BonehShoup appears in the references but not in the body of the
draft.



References: Obsolete reference RFC4210 is used rather than its replacements
RFC9810.



It seems odd to see an IPR disclosure called out in a draft as is done in
Appendix F. Usually the Datatracker indication of IPR is considered
adequate.





I did not review Sections 7 and 8, Appendices A through E, or Appendix G.



Thanks,

Donald

===============================

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)

 2386 Panoramic Circle, Apopka, FL 32703 USA

 d3e3e3@gmail.com