[COSE] Murray Kucherawy's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Tue, 16 June 2020 05:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: cose@ietf.org
Delivered-To: cose@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 891AA3A104C; Mon, 15 Jun 2020 22:18:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller <linuxwolf+ietf@outer-planes.net>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <159228470597.14028.11707324528215657516@ietfa.amsl.com>
Date: Mon, 15 Jun 2020 22:18:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/a-c7i6M308KdlyisIY3wtnc-oSc>
Subject: [COSE] Murray Kucherawy's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 16 Jun 2020 05:18:27 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-cose-rfc8152bis-struct-10: 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-rfc8152bis-struct/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In the interests of brevity, my review focused on the diff between this
document and RFC 8152.

Major points:

I agree with Benjamin's concern that we seem to be leaving the Designated
Experts for the IANA registries described here with advice in RFC 8152, which
this document renders obsolete.   I think that prose should be copied to this
document so that it lives someplace current.  I was originally tempted to
DISCUSS this but I'm hesitating, so I'll just say I hope this is resolved
appropriately.

Some nits:

Section 1:
* "... structure for the CBOR objects which are ..." -- s/which/that/
* "... or offline protocols, different solutions ..." -- "different" should
start a new sentence * "Any application which uses COSE for security ..." --
s/which/that/

Section 5:
* The last sentence in the first paragraph:
OLD:
   It needs to be noted that the counter
   signature needs to be treated as a separate operation from the
   initial operation even if it is applied by the same user as is done
   in [I-D.ietf-core-groupcomm-bis].
NEW:
   It needs to be noted that the counter
   signature is to be treated as a separate operation from the
   initial operation, even if it is applied by the same user, as is done
   in [I-D.ietf-core-groupcomm-bis].
* "This is same structure ..." -- s/same/the same/
* "That is the counter signature ..." -- comma after "is"
* "... existence of the encrypted data is attested to." -- maybe "asserted"
instead of "attested to"?

Section 9:
* "New algorithms will be created which will not fit ..." -- s/which/that/

Section 9.5.5:
* In the final bullet, why aren't these MUSTs?  Or in the alternative, when
would one legitimately deviate from those SHOULDs?