Skip to main content

Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
RFC 8778

Yes

Roman Danyliw
(Alexey Melnikov)
(Barry Leiba)

No Objection

Alvaro Retana
Warren Kumari
Éric Vyncke
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 07 and is now closed.

Roman Danyliw Yes

Alvaro Retana No Objection

Warren Kumari No Objection

Éric Vyncke No Objection

(Alexey Melnikov; former steering group member) Yes

Yes (for -07)

                            

(Barry Leiba; former steering group member) Yes

Yes (for -07)

                            

(Benjamin Kaduk; former steering group member) (was Discuss) Yes

Yes (2019-12-04 for -08)
Thank you for addressing my Discuss and comment points!

(Adam Roach; former steering group member) No Objection

No Objection (2019-12-03 for -07)
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.

(Alissa Cooper; former steering group member) No Objection

No Objection (2019-12-03 for -07)
Please respond to the Gen-ART review. I agree with the Gen-ART reviewer that the reference to the SUIT working group in Section 1.1 should be removed.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -07)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -07)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -07)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -07)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -07)