Re: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT)

[Russ Housley <[e-mail]>]

Adam:

> Adam Roach has entered the following ballot position for
> draft-ietf-cose-hash-sig-07: No Objection
> 
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the work that went into creating this document. I have no comments on its contents (the crypto is somewhat outside my area of expertise), although I have a few observations regarding the examples.
> 
> ---------------------------------------------------------------------------
> 
> Appendix A:
> 
>> This appendix provides a non-normative example of a COSE full message  
>> signature and an example of a COSE_Sign1 message.  This section  
>> follows the formatting used in [RFC8152].
> 
> I would suggest that RFC 8610 might be a better reference here, as it is the document that actually defines the extended CBOR diagnostic format.
> In particular my recommendation is:
> 
>  "This section is formatted according to the extended CBOR diagnostic
>   format defined by [RFC8610]."

Sure.  That works for me.

> 
> ---------------------------------------------------------------------------
> 
> §A.1:
> 
>> 98(
>>   [
>>     / protected / h'a10300' / {
>>         \ content type \ 3:0
>>       } / ,
>>     / unprotected / {},
>>     / payload / 'This is the content.',
>>     / signatures / [
>>       [
>>         / protected / h'a101382d' / {
>>             \ alg \ 1:-46 \ HSS-LMS \
>>           } / ,
>>         / unprotected / {
>>           / kid / 4:'ItsBig'
>>         },
>>         / signature / ...
>>       ]
>>     ]
>>   ]
>> )
> 
> I think there are two things here that need to be addressed.
> 
> First, section 3 of this document specifies:
> 
>>    o  The 'kty' field MUST be present, and it MUST be 'HSS-LMS'.
> 
> I can't find a 'kty' field in this example.
> 
> [JLS] The 'kty' field occurs in a COSE_Key and not in a COSE signed message.  This is expected.

Is there a phrase other than "When using a COSE key for this algorithm" that would be more helpful in Section 3?

> Also, this example uses '-46' as the identifier for HSS-LMS, while section 6.1 specifies the value as "TBD." This example needs a clear note added for the RFC editor that the "-46" needs to be replaced by the IANA-assigned value. A similar annotation will be required for the 'kty' field, regarding the value assigned for section 6.2.
> 
> [JLS]  The powers that be (me) have declared that -46 is going to be the IANA-assigned value.  Telling IANA to replace the "-46" with anything else would require that the example be re-generated or the signature would not verify.

I suggest the addition of:

   {{{ RFC Editor: This example assumes that -46 will be assigned for
   the HSS-LMS algorithm.  If another value is assigned, then the
   example needs to be regenerated. }}}

> 
> ---------------------------------------------------------------------------
> 
> §A.2:
> 
> Same comments as A.1, above.

And, I suggest the same note to the RFC Editor.

Russ