Hi Russ, Thanks for your review.
I have raised this PR to address your comments: https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/22 Please let me know if you have any additional suggestions to improve the document. Regards, OS On Wed, Jul 9, 2025 at 2:45 PM Russ Housley via Datatracker < [email protected]> wrote: > Document: draft-ietf-cose-dilithium > Title: ML-DSA for JOSE and COSE > Reviewer: Russ Housley > Review result: Not 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-tcpm-prr-rfc6937bis-14 > Reviewer: Russ Housley > Review Date: 2025-07-09 > IETF LC End Date: 2025-07-28 > IESG Telechat date: Not scheduled for a telechat > > > Summary: Not Ready > > > Major Concerns: > > Section 3 says: > > The AKP key type and thumbprint computations are generic, and > suitable for use with algorithms other than ML-DSA. > > I do not understand this sentence. The "AKP key type" is a new term. > Perhaps you mean the "Algorithm Key Pair Type", but I do not see any > computations associated with the type. The types are just registered > string values (JOSE) and integers (COSE). Also, thumbprints have not > been introduced yet; they are not discussed until Section 6. > > Section 4 says: > > See Security Considerations of this document for details. > > The Security Considerations contains very little additional information. > It just saus that the seed needs the same protection as the private key. > It would be more helpful to say that the see and the private key that is > expanded from the seed require the same level of protection in Section 4. > > Minor Concerns: > > > Section 3 says: > > When AKP keys are expressed in JWK, key parameters are base64url > encoded. > > This begs for a parallel sentence about COSE that indicates no encoding > is needed. > > Section 5 says: > > When producing JSON Web Signatures, the signature bytestrings are > base64url encoded, and the encoded signature size is larger than > described in the table above. > > Once again, this begs for a parallel sentence about COSE that indicates > no encoding is needed. > > > Nits: > > Section 7.4: s/key compromise/private key compromise/ > > > Note: > > I did not make any attempt to verify the examples in Appendix A. > > >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
