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.
Inline for the rest.
On Sat, Aug 23, 2025 at 8:01 AM Orie <orie@xxxxxxx> 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,
OSOn 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.
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).
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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
