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

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 03 Dec 2019 19:20:48 -0800

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]."

---------------------------------------------------------------------------

§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.

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.

---------------------------------------------------------------------------

§A.2:

Same comments as A.1, above.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 3 Dec 2019 20:25:22 -0800

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Adam Roach via Datatracker
Sent: Tuesday, December 3, 2019 7:21 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT)

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.)

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.

> 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:

[JLS] The 'kty' field occurs in a COSE_Key and not in a COSE signed message.  This is expected.

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.

§A.2:

_______________________________________________
COSE mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Dec 2019 14:09:53 -0500

> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/

Sure.  That works for me.

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

> [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…

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. }}}

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

Russ

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Dec 2019 15:28:04 -0600

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

Sorry, this was mostly me reading too quickly. You're probably fine with 
no change, although modifying the phrasing along the lines of "...the 
following checks are made on the key:" might be slightly clearer.

>     example needs to be regenerated. }}}

This sounds good to me. I've seen other i-ds do something like the 
following, which seems helpful (in addition to the note above):

       Value:  TBD (Value between -256 and 255 to be assigned by IANA, 
with -46 preferred)

/a