Hi Orie,

Thanks for sharing those updates. I had a look at the PR and it looks good
to me and I'll clear my DISCUSS position once this version is posted.

Thanks,
Ketan


On Sat, Oct 11, 2025 at 7:17 PM Orie <[email protected]> wrote:

> Hi Ketan,
>
> I have addressed your review along with other IESG comments here:
> https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/26
>
> Please let me know if I missed anything.
>
> TLDR, I basically took all your suggestions, but I preserved the IANA URLs
> in the body of the document.
>
> Inline for the rest.
>
> On Tue, Oct 7, 2025 at 4:25 AM Ketan Talaulikar via Datatracker <
> [email protected]> wrote:
>
>> Ketan Talaulikar has entered the following ballot position for
>> draft-ietf-cose-dilithium-09: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Just some easy to address comments related to references that perhaps
>> rise to the level of DISCUSS.
>>
>> Sections 3 and 5:
>>
>> The URLs [IANA.jose] and [IANA.cose] are informative references?
>>
>> Section 8:
>>
>> Several RFCs here that should be normative or informative references?
>>
>
> I made these informative references, and moved the requests to the IANA
> considerations.
>
>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks to the authors and the WG for their work on this document. Please
>> find
>> below some comments and suggestions to improve the clarity of this
>> document.
>>
>> General:
>> s/NIST/US NIST and S/FIPS/US NIST FIPS - we want to be clear this is
>> coming
>> from an US entity
>>
>
> Done.
>
>
>>
>> Section 1:
>>
>> s/draft-ietf-cose-key-thumbprint/RFC9679
>>
>
> Done.
>
>
>>
>> Perhaps change "as described in [FIPS-204] with JOSE and COSE" to "as
>> described
>> in [FIPS-204], in conjunction with JOSE and COSE." ?
>>
>
> Excellent improvement, thank you.
>
>
>>
>> Perhaps "can be compared according the procedures..." should be "can be
>> compared according to the procedures..." ?
>>
>
> I took your suggestion.
>
>
>>
>> Section 3:
>>
>> Keep the actions for IANA in the IANA considerations sections alone.
>>
>> Perhaps instead of "This document requests the registration of the
>> following
>> key types in [IANA.jose]:", how about "This document introduces the
>> following
>> key types (see section 8.1.x for details):"
>>
>
> I took your suggestion.
>
>
>>
>> This can be done for other similar sentences (in this section as well as
>> section 5). The URLs [IANA.jose] are better placed in the respective IANA
>> consideration sub-sections?
>>
>
> I kept the links here, based on feedback from Paul.
>
>
>>
>> s/use of multiple key type/the use of multiple key type
>>
>
> Done.
>
>
>>
>> s/key parameters are base64url encoded/the key parameters are base64url
>> encoded
>>
>
> Done.
>
>
>>
>> Perhaps, instead of "Some algorithms might require or encourage additional
>> structure or length checks for associated key type parameters", would
>> this be
>> more clear - "Some algorithms may require or recommend additional
>> structure or
>> length checks for associated key type parameters." ? ... not sure what is
>> meant
>> by encourage here?
>>
>
>  Great catch, I took your proposed text.
>
>
>> Section 5:
>>
>> Suggest "See the ML-DSA Private Keys section of this document for more
>> details." change to "See Section 4, ML-DSA Private Keys, for further
>> details."
>>
>
> Done.
>
>
>> Perhaps instead of "ML-DSA might not be the best choice for use cases that
>> require small keys or signatures." it could be "ML-DSA may not be
>> suitable for
>> use cases requiring small keys or signatures." ?
>>
>
> Done.
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to