Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
Jim Schaad <ietf@augustcellars.com> Thu, 08 March 2018 16:19 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65B127137; Thu, 8 Mar 2018 08:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FKO9j6cybA8u; Thu, 8 Mar 2018 08:19:24 -0800 (PST)
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 8C6E512711B; Thu, 8 Mar 2018 08:19:23 -0800 (PST)
Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 8 Mar 2018 08:17:09 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, 'Benjamin Kaduk' <kaduk@mit.edu>, 'Adam Roach' <adam@nostrum.com>
CC: 'The IESG' <iesg@ietf.org>, draft-ietf-ace-cbor-web-token@ietf.org, ace-chairs@ietf.org, ace@ietf.org
References: <152046753224.21454.8592401400498503627.idtracker@ietfa.amsl.com> <20180308042415.GA27850@mit.edu> <SN6PR2101MB094361203E6C9741F2511A7EF5DF0@SN6PR2101MB0943.namprd21.prod.outlook.com>
In-Reply-To: <SN6PR2101MB094361203E6C9741F2511A7EF5DF0@SN6PR2101MB0943.namprd21.prod.outlook.com>
Date: Thu, 08 Mar 2018 08:19:07 -0800
Message-ID: <044f01d3b6f9$314da380$93e8ea80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGfNF1TALmf+QT1ql9gEeobBacx2AGd03PcAe9np1CkEx+0oA==
X-Originating-IP: [192.168.1.162]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/whQMLB8qZb9ePzIeJ681Ts2UzdA>
Subject: Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 16:19:26 -0000
It might make more sense to prefix the JWT versions as not being what is here. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, March 7, 2018 9:47 PM > To: Benjamin Kaduk <kaduk@mit.edu>; Adam Roach <adam@nostrum.com> > Cc: The IESG <iesg@ietf.org>; draft-ietf-ace-cbor-web-token@ietf.org; ace- > chairs@ietf.org; ace@ietf.org > Subject: RE: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token- > 13: (with COMMENT) > > Thanks, Ben and Adam. I've recoded a note to address the improvements > below one the submission tool reopens. > > For what it's worth, I independently noticed the unintended overlap > between the Standards Action and Specification Required number ranges in > a conversation today with IANA. > > The point of including new CWT definitions for "StringOrURI" and > "NumericDate" was so that we could use them directly. Prefixing them with > "CWT" isn't necessary for the meaning to be clear in context. > > Thanks both for the attention to detail. > > -- Mike > > -----Original Message----- > From: Benjamin Kaduk <kaduk@mit.edu> > Sent: Wednesday, March 7, 2018 8:24 PM > To: Adam Roach <adam@nostrum.com> > Cc: The IESG <iesg@ietf.org>; draft-ietf-ace-cbor-web-token@ietf.org; ace- > chairs@ietf.org; ace@ietf.org > Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token- > 13: (with COMMENT) > > Hi Adam, > > With my shepherd hat... > > On Wed, Mar 07, 2018 at 04:05:32PM -0800, Adam Roach wrote: > > > > Thanks to the WG, chairs, and > > > > §3.1.1: > > > > > The "iss" (issuer) claim has the same meaning and processing rules > > > as the "iss" claim defined in Section 4.1.1 of [RFC7519], except > > > that the value is of type StringOrURI. The Claim Key 1 is used to > > > identify this claim. > > > > > > 1) Given that RFC 7159 defines "iss" to contain a "StringOrURI" value, it's > > not clear what the "except" clause is attempting to convey. > > I had to ask about this as well -- the crux is that the "StringOrURI" JWT type is > different from the CWT "StringOrURI" > type. IIRC there used to be an extra descriptor in here but it was removed as > redundant. > > > 2) Given the many uses of the word "type" in this context (including CBOR > > types and the JWT 'typ' field), and given that RFC 7519 never refers to > > "StringOrURI" as a "type," I think that the use of the word "type" here > > is likely to lead to reader confusion. > > In combination with the above, maybe we want "the value is a CWT > StringOrURI value". Authors? > > > This comment -- or a congruent form of it involving "NumericDate" > > rather than "StringOrURI" -- applies to §3.1.2 through §3.1.6. > > (Right.) > > > ---------------------------------------------------------------------- > > ----- > > > > §9.1: > > > > > Criteria that should be applied by the Designated Experts includes > > > determining whether the proposed registration duplicates existing > > > functionality, whether it is likely to be of general applicability > > > or whether it is useful only for a single application, and whether > > > the registration description is clear. Registrations for the > > > limited set of values between -256 and 255 and strings of length 1 > > > are to be restricted to claims with general applicability. > > > > Use of the word "between" without qualifying it as inclusive or > > exclusive of the endpoints is ambiguous. Suggest either "values from > > -256 to 255" or "values between -256 and 255 inclusive". > > Agreed, it should be qualified as inclusive. > > > ---------------------------------------------------------------------- > > ----- > > > > §9.1.1: > > > > > CBOR map key for the claim. Different ranges of values use > > > different registration policies [RFC8126]. Integer values between > > > -256 and 255 and strings of length 1 are designated as Standards > > > Action. Integer values from -65536 to 65535 and strings of length > > > 2 are designated as Specification Required > > > > Same comment as above. > > > > Also, please replace "from -65536 to 65535" with "from -65536 to -257 > > and from > > 256 to 65535". > > Good catch! > > Thanks, > > Ben
- [Ace] Adam Roach's No Objection on draft-ietf-ace… Adam Roach
- Re: [Ace] Adam Roach's No Objection on draft-ietf… Benjamin Kaduk
- Re: [Ace] Adam Roach's No Objection on draft-ietf… Mike Jones
- Re: [Ace] Adam Roach's No Objection on draft-ietf… Adam Roach
- Re: [Ace] Adam Roach's No Objection on draft-ietf… Mike Jones
- Re: [Ace] Adam Roach's No Objection on draft-ietf… Jim Schaad