[COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 07 October 2020 05:33 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 BA5793A1620; Tue, 6 Oct 2020 22:33:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk 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>, linuxwolf+ietf@outer-planes.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160204883573.26847.11501294022082441021@ietfa.amsl.com>
Date: Tue, 06 Oct 2020 22:33:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/odLmrgS-n6Kx7WYJXOqYuK4dYt4>
Subject: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (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: Wed, 07 Oct 2020 05:33:56 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-14: Yes 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: ---------------------------------------------------------------------- Mostly just nits left, though the lingering errata report and the IANA updates seem somewhat significant. (It would probably be fine to leave the nits for the RFC Editor.) It seems that https://www.rfc-editor.org/errata/eid5066 needs to be incorporated still (and the report verified, presuming it is correct). Section 1 providing security services. The use of COSE, like JOSE and CMS, is only for use in store and forward or offline protocols. The use of nit: we probably can just start the sentence with "COSE", since the "use in" has moved to later in the sentence. additional data fields as part of the structure. A one such application-specific element would be to include a URI or other nit: s/A one/One/. Section 1.5 The presence a label that is neither a a text string or an integer, nit: s/a a/a/ Section 2 layer. The content layer contains the plaintext is encrypted and information about the encrypted message. The recipient layer contins nit: s/plaintext is encrypted/encrypted plaintext/ (or similar?) the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient. A single layer version of nit: s/content encryption key (CEK) is encrypted/encrypted content encryption key (CEK)/. Section 4.1 parameter. An examples of a header parameter about the signature nit: s/An examples/An example/ Note: When a signature with a message recovery algorithm is used (Section 8.1), the maximum number of bytes that can be recovered is the length of the original payload. The size of the encoded payload is reduced by the number of bytes that will be recovered. If all of the bytes of the original payload are consumed, then the transmitted payload is encoded as a zero-length byte string rather than as being absent. I guess this is where the difficulty that Jim mentioned comes in -- the signature recovery scheme gives you the intended recovered content but also some of the other framing and such that was added as input to the signature algorithm, and you have to properly figure out where the end of the actual payload is. (I'm not sure whether it would be useful to try to have text about the issue in this location, though.) Section 8.1 consume the same bytes of message content. This means that the mixing of the signature with message recovery and signature with appendix schemes in a single message is not supported, and if a recovery signature scheme is used. nit: this sentence just trails off .... I think it would be okay to just end the sentence after "is not supported", since we covered the "must recover the same [number of] bytes" previously. integrating message recovery signature algorithms. The first algorithm defined is going to need to make decisions about these issues and those decisions re likely to be binding on any further algorithms defined. nit: s/ re / are / Some of the issue2 that have already been identified are: nit: s/issue2/issues/ Section 8.5.2, 8.5.3, 8.5.4, 8.5.5 I see that a bunch of things were changed from COSE_Encrypt to COSE_Recipient, apparently prompted by my earlier review. I would feel more comfortable if someone confirmed that each change is correct, as I have lost some of the context here. Section 10 comparable for the desired security functionality. Additional guidence can be found in [BCP201]. nit: s/guidence/guidance/ Section 11 We lost the section about the "CBOR Tags" registry (where we were previously allocating a codepoint for COSE_Signature). I think we need to bring back a stub section with the directive to update the references from 8152 to this document. [Noting here for convenience that as of the -12 of -algs, the Header Algorithm Parameters registry has not been added as a target for reference updates; it still needs to be listed there.] Acknowledgments nit: Göran's name doesn't seem to have made it through some step of the process (eve in the native HTML output).
- [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rf… Benjamin Kaduk via Datatracker
- Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cos… Carsten Bormann
- Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cos… Matthew Miller
- Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cos… Benjamin Kaduk
- Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cos… Carsten Bormann