Re: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT)
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 23 November 2016 18:50 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.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 F231212A359; Wed, 23 Nov 2016 10:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Bzzqz6eyJSYg; Wed, 23 Nov 2016 10:50:54 -0800 (PST)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 AFDB912A358; Wed, 23 Nov 2016 10:50:27 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id x186so13540197vkd.1; Wed, 23 Nov 2016 10:50:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kSIRRa+J4ucoxFCx/iLcY7FyQogfoVKHa8rGXr/c9As=; b=U0MUbm8XwoyjyqMHT8N756NpnVmPM2sO3yqtpscBEqP4nT1sXK2f9o/e7luMLs5vpS k+bRtRb0AI67Fx8dHW0UgzuHWmQ5RUSW2wsssa+34q+T2dvNBchfwb8tApZ+75JWbf0j HJ/y4/qGE7F0qZbvzjyTYktkhiUgcEIMwj/Iq+JJIt7uXfh2e0aPRdY1InFrHk74R8fn nT4i/+iezx3ZUI7UVce2XkNHm0KXxF/XIS0lcnFB70qh+C2el0LfufBB7/uOhzyMvH1o sy4Un/1w9q9r7Q3TgEFPmaD65X3dlmH55l+kAtsiHU7nvdVu1e0oWvLUhPqNqjilJKl+ Q+XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kSIRRa+J4ucoxFCx/iLcY7FyQogfoVKHa8rGXr/c9As=; b=l9y6ZZiB+JxmJ70WAWkNNbPf1DRNTdkRGi9OQg+t2leHfjRc9ivF3kpYhkQvDlWmsO ojPpMJHwpIIcnnlbBXGBBgcU5jRvoGWX7LMlJRzngHSU9/VmVuaouFqjfq+SqwqwYAqg m6yVYI+4t+4R6XpZY+Ob1bA3L7Hs9WNZrEStQSupRuJ8EDH0XxUth/SxhaXKG49v/gLB kJXcYQ8czK+bRW5dtPVkwBFgOahpHfkSApBEy49hol+eNJ/jBNNOViwFBEyVw/XB5nna OyzL7CrjTCw/wJ9MDO7lKmhcgLc8+IYPEcr9cLcHhzf1koEXWwwhfoRcMENcnUOFKE5V wl/w==
X-Gm-Message-State: AKaTC02PfqZAA0FYWZcRBjulC5lC9U0s09huUfmOGIuJJZhVhxPUsYYwrlu8Z040jwZ3xKA8q9xvDv2p3CvlHA==
X-Received: by 10.31.200.4 with SMTP id y4mr1790084vkf.115.1479927026835; Wed, 23 Nov 2016 10:50:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.82.143 with HTTP; Wed, 23 Nov 2016 10:50:26 -0800 (PST)
In-Reply-To: <049501d21a13$dcaa3a10$95feae30$@augustcellars.com>
References: <147503397650.11759.7571084980083889443.idtracker@ietfa.amsl.com> <049501d21a13$dcaa3a10$95feae30$@augustcellars.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 23 Nov 2016 13:50:26 -0500
Message-ID: <CAHbuEH5xgz_RSbQxx+a331JeSnFdZTxkAOiexAfy+X2EUDRxrw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="001a114dd558ba66b00541fc5cd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/7w7XJNJ8yWsga8_MTPLYWjPMKIA>
Cc: Ben Campbell <ben@nostrum.com>, cose-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-cose-msg@ietf.org, Göran Selander <goran.selander@ericsson.com>, "cose@ietf.org" <cose@ietf.org>
Subject: Re: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Nov 2016 18:50:57 -0000
Just going back through messages to check on things and noticed a question for me... On Thu, Sep 29, 2016 at 1:39 AM, Jim Schaad <ietf@augustcellars.com> wrote: > Changes are in https://github.com/cose-wg/cose-spec/pull/181 > > > > > -----Original Message----- > > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Ben Campbell > > Sent: Tuesday, September 27, 2016 8:40 PM > > To: The IESG <iesg@ietf.org> > > Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; > draft- > > ietf-cose-msg@ietf.org > > Subject: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: > (with > > COMMENT) > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-cose-msg-18: 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-msg/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > A few minor comments: > > > > Substantive: > > > > -1.3, definition of "int": Is that really _unsigned_ or negative? Or is > it a signed > > integer than can be negative or non-negative? (contrasting with uint?) > (Or is int > > merely a parent of nint and uint?) > > Using the terminology of CDDL, this is really unsigned or negative. > Specifically, it would be the union of uint (unsigned - 0 and above) and > nint (negative integer strictly less than 0). Both of these types have > different major types so they are coded differently. > > > > > -3: What is the scope of uniqueness for map labels? I expected it to be > the map, > > but the text immediately aftewards suggests the scope may be the whole > > message. Whatever the answer, it would help to be explicit. > > I kind of thought that it was sufficiently explicit. Does it work better > for you if the first sentence reads: > > If a label is used in one of the maps, it MUST appear only once in that map > and it MUST NOT appear in the other map. > > Then leave the rest of the text in the paragraph alone. > > > > > - Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm > references are > > normative. Why not this one? > > I plead the 5th. It would be because I pasted it in the wrong place and > missed the fact. I have been acting as if this was a normative reference. > Kathleen, is there a problem if I just move this reference? > Not a problem anymore as this one is ahead of COSE now in the RFC editor queue. I see it was moved and that's just fine. Thanks, Kathleen > > > > > Editorial: > > > > "Contributing to this Memo" section: Is this intended to stay in the > final > RFC? If > > not, it might be worth a note to the RFC editor. > > The not already exists in the XML. > > > > > -1, first paragraph, last sentence: Comma splice. > Changed in response to the Gen-Art review already. > > > > > -1, 2nd paragraph: MAC usually expands to Message Authentication _Code_. > Yeah, Changed in response to the Gen-Art review already > > > > > -2, 6th paragraph, last sentence: s/method/methods (assuming the > following > > list is a list of methods, and not steps in a method. > Should be plural - changed > > > > > -3, definition of protected: > Did you lose some text at this point? > > > > > -4.1, "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is > the > > comment intended as a note to the RFC editor? If so, it might be helpful > to label > > it as such. > Added as a note to the XML > > > > > -4.3, first bullet: "If multiple items are included, care needs to be > taken that data > > cannot bleed between the items." > > Is this talking about data framing, or something else? > > That is probably not the term that I would use for this, but it is similar. > The requirement is to make sure that data from one item is separated from > another item so that when the hash string is constructed the same hash > string cannot be constructed for two different pairs of items. > > Jim > > > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > -- Best regards, Kathleen
- [COSE] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
- Re: [COSE] Ben Campbell's No Objection on draft-i… Jim Schaad
- Re: [COSE] Ben Campbell's No Objection on draft-i… Carsten Bormann
- Re: [COSE] Ben Campbell's No Objection on draft-i… Kathleen Moriarty