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
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 <noreply@xxxxxxxx> 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
