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

Adam Roach <adam@nostrum.com> Wed, 04 December 2019 21:28 UTC

Return-Path: <adam@nostrum.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 1094E1200A3; Wed, 4 Dec 2019 13:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level:
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 3XmTBTjD8pZ4; Wed, 4 Dec 2019 13:28:15 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF9F120033; Wed, 4 Dec 2019 13:28:15 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xB4LS9lr023443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Dec 2019 15:28:11 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1575494892; bh=MM9nELHEMO2mieAAVBOILHzMUBcIdoQH30qrkYCptZs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=B2ypqnW8vFeV3GlCtcpKt3y9BJkx+/Vx+YpAIMQPyxGfGU8g1tCAs7tzWciJTNkRe DrtRh7j99ns80CADV3wXvKk8cgGEOtNgo1dRtqwuTRB74AozJCJQaQRH/HCYAwqNf9 wRi++3vk0ynEiDOABG4MGoWyH8MgDcNfv+odeJ5Q=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Russ Housley <housley@vigilsec.com>
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
References: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com> <4119C2E9-EFA8-4823-B6FF-F896CF97E8BE@vigilsec.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <6f2c8b6c-e637-6a8a-2848-fef926855ca7@nostrum.com>
Date: Wed, 4 Dec 2019 15:28:04 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <4119C2E9-EFA8-4823-B6FF-F896CF97E8BE@vigilsec.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/3b9EwvHHnl8xDW-t_SlTPODluHY>
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 21:28:16 -0000

On 12/4/19 1:09 PM, Russ Housley wrote:
>
>>>     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?


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.


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


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