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

Russ Housley <housley@vigilsec.com> Wed, 04 December 2019 19:18 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DEF12095A for <cose@ietfa.amsl.com>; Wed, 4 Dec 2019 11:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmwFgIPnZ1zE for <cose@ietfa.amsl.com>; Wed, 4 Dec 2019 11:18:20 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C90A120961 for <cose@ietf.org>; Wed, 4 Dec 2019 11:18:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CAAF5300B35 for <cose@ietf.org>; Wed, 4 Dec 2019 14:09:56 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yiKdy9LQrJIU for <cose@ietf.org>; Wed, 4 Dec 2019 14:09:53 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 5D8B0300464; Wed, 4 Dec 2019 14:09:53 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com>
Date: Wed, 4 Dec 2019 14:09:53 -0500
Cc: IESG <iesg@ietf.org>, cose-chairs@ietf.org, Ivaylo Petrov <ivaylo@ackl.io>, cose <cose@ietf.org>, draft-ietf-cose-hash-sig@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4119C2E9-EFA8-4823-B6FF-F896CF97E8BE@vigilsec.com>
References: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/6IFInNPnBpxvPNbex66f3DZ43cc>
Subject: Re: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2019 19:18:21 -0000

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