[COSE] Re: draft-ietf-cose-dilithium-08 ietf last call Genart review

[Orie <[e-mail]>]

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 <
[e-mail]> 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.
>
>
>