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