Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 08 March 2018 04:24 UTC

Return-Path: <kaduk@mit.edu>
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 B1E0F126BF7; Wed, 7 Mar 2018 20:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6qpd40691uoM; Wed, 7 Mar 2018 20:24:23 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E714E126B72; Wed, 7 Mar 2018 20:24:22 -0800 (PST)
X-AuditID: 1209190f-d2bff70000002dcd-cd-5aa0baf54b39
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.31.11725.5FAB0AA5; Wed, 7 Mar 2018 23:24:21 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w284OKwc013688; Wed, 7 Mar 2018 23:24:20 -0500
Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w284OFAh016848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Mar 2018 23:24:18 -0500
Date: Wed, 07 Mar 2018 22:24:15 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
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
Message-ID: <20180308042415.GA27850@mit.edu>
References: <152046753224.21454.8592401400498503627.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <152046753224.21454.8592401400498503627.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixCmqrft114IogwmTLC2m3f3NavH9Ww+z xZ6/i9gtLu9uZLSY8WciswOrx5IlP5k8Zu18whLAFMVlk5Kak1mWWqRvl8CV0beij7ngiGjF 9IuvWRoYHwt0MXJySAiYSNw+PJG5i5GLQ0hgMZNE4++zTBDOBkaJyQdOs0M4Z5gkfq65zw7S wiKgItE4YSkLiM0GZDd0X2YGsUUEFCXaDt8Es5kFCiS+PX8NVM/BISwQI/FuuT1ImFdAR+LC 0uOMILaQgK/Eo113mCHighInZz5hgWjVkdi59Q4bSCuzgLTE8n8cEGF5ieats5lBwpwCfhK7 v4B1igooS+ztO8Q+gVFwFpJBs5AMmoUwaBaSQQsYWVYxyqbkVunmJmbmFKcm6xYnJ+blpRbp mujlZpbopaaUbmIEB7wk/w7GOQ3ehxgFOBiVeHgl/syPEmJNLCuuzD3EKMnBpCTK65u1IEqI Lyk/pTIjsTgjvqg0J7X4EKMEB7OSCC/XMqAcb0piZVVqUT5MSpqDRUmc191EO0pIID2xJDU7 NbUgtQgmK8PBoSTBGwCMbCHBotT01Iq0zJwShDQTByfIcB6g4Xt2ggwvLkjMLc5Mh8ifYtTl uPHidRuzEEtefl6qlDhvHsggAZCijNI8uDmgRCWRvb/mFaM40FvCEOt4gEkObtIroCVMQEvO 350DsqQkESEl1cBYn98aFZjZp3hwxeqAKL563stflionX+ITvR7bLTarsOvviY/Xg+sEG2+r LmJhjn2xQfjxzzf60y5dU5myWPYRW2vvZM0thzhbr1VKCORH7BUq/rjGTenj54CD++PfbSp4 tuBRtNVFvYlnjsyfv/u4sfL0pJobS+ScVM8u7fQ4xyAqZZ+u8f2+EktxRqKhFnNRcSIAdRYd lS8DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/DqZjoBMiBoQMHVfc08rwlbGaDUc>
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 04:24:25 -0000

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