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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
