Sorry to double post, but I realized I did not address your comments on the list, and not everyone will want to read a PR.
Inline for the rest. On Sat, Aug 23, 2025 at 8:01 AM Orie <[email protected]> wrote: > 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. >> > I've shuffled the order. The intention of the sentence is to advise the reader that the algorithm defined for AKP thumbprints is suitable for algorithm identifiers that may be registered in the future (like SLH-DSA). > >> 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. >> > I've added a section of private key compromise, and indicated that seed and expanded key both need to be protected. > >> 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. >> >> Great catch. > 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. >> >> I've added sentences for both cases. > >> Nits: >> >> Section 7.4: s/key compromise/private key compromise/ >> >> Thanks for the nit. > >> 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]
