Re: [COSE] AD review of draft-ietf-cose-rfc8152bis-struct-08 — THE REST OF THE REVIEW

Jim Schaad <ietf@augustcellars.com> Thu, 14 May 2020 23:47 UTC

Return-Path: <ietf@augustcellars.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 8C4413A0736; Thu, 14 May 2020 16:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 EJj5vhBjx0Z1; Thu, 14 May 2020 16:47:27 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FD83A067A; Thu, 14 May 2020 16:47:26 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 May 2020 16:47:19 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Barry Leiba' <barryleiba@computer.org>, draft-ietf-cose-rfc8152bis-struct.all@ietf.org
CC: cose@ietf.org
References: <CALaySJKRQehPKCU6-jmeOdBG_QyhP+au7MzFTTNdO7YqdPNxjg@mail.gmail.com>
In-Reply-To: <CALaySJKRQehPKCU6-jmeOdBG_QyhP+au7MzFTTNdO7YqdPNxjg@mail.gmail.com>
Date: Thu, 14 May 2020 16:47:19 -0700
Message-ID: <024501d62a4a$01da7990$058f6cb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0246_01D62A0F.557CB300"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIOESST3HhtW8rbYCGuShPKr6FjB6g4aX6Q
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/XL0gUg7rGcqZhxf4bejH9NWZrqE>
Subject: Re: [COSE] AD review of draft-ietf-cose-rfc8152bis-struct-08 — THE REST OF THE REVIEW
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: Thu, 14 May 2020 23:47:31 -0000

I’ll post both at the same time

 

From: Barry Leiba <barryleiba@computer.org> 
Sent: Wednesday, May 13, 2020 10:18 PM
To: draft-ietf-cose-rfc8152bis-struct.all@ietf.org
Cc: cose@ietf.org
Subject: AD review of draft-ietf-cose-rfc8152bis-struct-08 — THE REST OF THE REVIEW

 

This review mostly includes comments about text that was NOT changed in 8152bis, and is all minor editorial things.

 

— Section 1 —

 

   CBOR was designed specifically to be both small in terms

   of messages transport and implementation size and be a schema-free

   decoder.

 

A couple of nits fixed here, “messages transport” and “be both ... and be”:

 

NEW

CBOR was designed specifically both to be small in terms of messages transported and implementation size, and to be a schema-free decoder.

END

[JLS] looks fine - done

 

   The JOSE working group produced a set of documents [RFC7515]

   [RFC7516] [RFC7517] [RFC7518] using JSON that specified how to

   process encryption, signatures, and Message Authentication Code (MAC)

   operations and how to encode keys using JSON.

 

There’s a redundancy with “using JSON” twice in that sentence.  I would remove the first instance and change the second to “, all using JSON.”

[JLS] Looks fine – the first one is now gone.

 

— Section 1.3 —

 

   *  Use binary encodings for binary data rather than base64url

      encodings.

 

As written, that says that the document uses binary encodings for binary data, rather than using binary encodings for base64url encodings.

 

NEW

   *  Use binary encodings, rather than base64url encodings,

      to encode binary data.

END

[JLS] Reasonable - done

 

— Section 1.5 —

 

   The presence of a label in a CBOR map that is not a text string or an

   integer is an error.

 

I think you mean this:

 

NEW

   The presence in a CBOR map of a label that is not a text string or an

   integer is an error.

END

[JLS] Looks fine – done.

 

— Section 1.6 —

 

   context' header parameter defined in [RFC8613], or identified by a

   protocol specific identifier.

 

Nit: hyphenate “protocol-specific”.

[JLS] I guess I need to learn rules on this - done

 

   Context should generally be included

   in the cryptographic configuration, for more details see Section 4.3.

 

Comma splice: change the comma to a semicolon.

[JLS] done

 

— Section 4.1 —

 

   An example of

   header a parameter about the content is the content type.  Examples

   of a header parameters about the signature would be

 

Nits: “of a header parameter” and “of header parameters”

[JLS] done

 

— Section 6.1 —

 

   The same techniques and nearly the same structure is used for

   encrypting both the plaintext and the keys.

 

Nit: the subject is plural, so “are used”.  Or to avoid the awkward “structure are used”, recast the sentence: “Both the plaintext and they keys are encrypted using the same techniques and nearly the same structure.”

[JLS] Just changed to plural.  I think it stresses what I want to stress better.

 

— Section 10 —

Same comment as in the algs doc:

 

   There has been an attempt to limit the number of places where the

   document needs to impose restrictions on how the CBOR Encoder needs

   to work.

 

Both instances of “needs to” seem odd.  For that matter, so does

“there has been an attempt”.  Maybe this, or something like it?:

 

NEW

This document limits the restrictions it imposes on how the CBOR

Encoder can work.

END

[JLS] Yes that reads better - done

 

— Appendix A —

 

   The first set of

   recommendations apply to having an implicit algorithm identified for

   a single layer of a COSE object.  The second set of recommendations

   apply to having multiple implicit algorithms identified for multiple

   layers of a COSE object.  The third set of recommendations apply to

   having implicit algorithms for multiple COSE object constructs.

 

Nits: For all three sentences, “set of recommendations” is a singular subject (“set” is singular), so it needs “applies”, not “apply”.  (And it’s correct two paragraphs later.)

[JLS] that looks right – done.

 

— 

Barry