Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Mike Jones <Michael.Jones@microsoft.com> Tue, 27 February 2018 18:02 UTC

Return-Path: <Michael.Jones@microsoft.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 C190C124E15; Tue, 27 Feb 2018 10:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 lJcfphTr9mPW; Tue, 27 Feb 2018 10:02:18 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0119.outbound.protection.outlook.com [104.47.33.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9CF127201; Tue, 27 Feb 2018 10:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fRrzwsaFq4lo06r7zzZ/RWfywPGWCEiApMjJ5aXHSw0=; b=avjuvV9nhC+W4sPZU5FnzFgdrkcuwbuzQJEHtpURYYbOVpZ4K/V4j3+Qdun9nLFBQuFPheB8wLz/19jvpTzHoOY3ciJt9oyVB2M8dvHH36c8BOBw/o5ypB3rg5UEgbCQkHNCKBbtjFyACLTsL7W8qNWBG1fyHXgLyTT7RrXD1mo=
Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB0974.namprd21.prod.outlook.com (52.132.114.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.3; Tue, 27 Feb 2018 18:02:15 +0000
Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0567.002; Tue, 27 Feb 2018 18:02:15 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Dan Romascanu' <dromasca@gmail.com>, 'Benjamin Kaduk' <kaduk@mit.edu>
CC: 'gen-art' <gen-art@ietf.org>, "draft-ietf-ace-cbor-web-token.all@ietf.org" <draft-ietf-ace-cbor-web-token.all@ietf.org>, 'ietf' <ietf@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12
Thread-Index: AQHTrzRyo8Mp7FBA1UOtbTCoMqPdBaO3HdCAgAASogCAAGp5gIAAahUAgACEUACAAAEd4A==
Date: Tue, 27 Feb 2018 18:02:15 +0000
Message-ID: <SN6PR2101MB09436C491513D7431A81FD0DF5C00@SN6PR2101MB0943.namprd21.prod.outlook.com>
References: <151967178760.21771.14005895812023525211@ietfa.amsl.com> <021201d3af3e$1f204cc0$5d60e640$@augustcellars.com> <CAFgnS4USoaMrDSbvOZj4Pwg3DprMNNxrHoPn+DK-YjVNB-Jrog@mail.gmail.com> <20180227034009.GT50954@kduck.kaduk.org> <CAFgnS4VJDs0Xm2zFG5jXQ3eTC0umNvLxBmkLzQKzbPARZq1RVA@mail.gmail.com> <028701d3aff3$df7ef6f0$9e7ce4d0$@augustcellars.com>
In-Reply-To: <028701d3aff3$df7ef6f0$9e7ce4d0$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-27T18:02:13.0391749Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:3::175]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR2101MB0974; 7:hXTr9H8mgbsdgZhUeSSYB8Pi4mN5rqM8A674vsF5oTHoh9oVwos8EP/xhj01DFNCq8ZkR16CJAKORlUThQ7M4XWH1Md5d/WxewiVSYCKFwiDaaHN+hqqu4p8MUE74vCrwJbwKfYenoWeGR/TAUVmMBFItS3zssB2K2liTBXng4XZHWtv6Oov/+14n8HrPhkOID7pG/6XLVoS58YXde4K/eKpA4si7UHoyOfx33bWkRXl0+ELgUv4hM/wxwFkHiN8
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 02ee8d10-f656-4863-865b-08d57e0c3be8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB0974;
x-ms-traffictypediagnostic: SN6PR2101MB0974:
x-microsoft-antispam-prvs: <SN6PR2101MB0974ADB3E9571112C322A67EF5C00@SN6PR2101MB0974.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(240460790083961)(1591387915157);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231220)(944501198)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:SN6PR2101MB0974; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB0974;
x-forefront-prvs: 05961EBAFC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(376002)(39380400002)(39860400002)(76104003)(54094003)(189003)(13464003)(199004)(14454004)(33656002)(86362001)(6116002)(68736007)(606006)(790700001)(345774005)(10290500003)(3660700001)(6306002)(25786009)(59450400001)(9686003)(102836004)(186003)(6506007)(6346003)(53546011)(105586002)(54896002)(236005)(6436002)(55016002)(966005)(53376002)(72206003)(22452003)(53936002)(2906002)(6246003)(478600001)(2171002)(10090500001)(97736004)(106356001)(39060400002)(3280700002)(8990500004)(99286004)(2950100002)(229853002)(8676002)(86612001)(7736002)(93886005)(74316002)(4326008)(5660300001)(5250100002)(2900100001)(81156014)(8936002)(76176011)(54906003)(7696005)(110136005)(81166006)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB0974; H:SN6PR2101MB0943.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-microsoft-antispam-message-info: /dNgEAJYbgz6T5GsGSYwFgXVAVwNBPCBzaByofdjpXGVozYFDEFUlV4G4sMTYxx7A9vahSMwf01/g7rC14U45biQ/a+KPH942BMoT3P/OGrJWYgfwTl5a6lWqgHfPxNbzEDSrDb7pqTlv+EhoEeKwtaBFqEm3x9KGNreI544egw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB09436C491513D7431A81FD0DF5C00SN6PR2101MB0943_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 02ee8d10-f656-4863-865b-08d57e0c3be8
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2018 18:02:15.1314 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB0974
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/mNTeYnkJcAA7cfjiy7HQW1jF1WI>
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12
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: Tue, 27 Feb 2018 18:02:26 -0000

I agree with Jim.  This information is in the registration template at https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12#section-9.1.1, as follows:



   Claim Key:

      CBOR map key for the claim.  Integer values between -256 and 255

      and strings of length 1 are designated as Standards Track

      Required.  Integer values from -65536 to 65535 and strings of

      length 2 are designated as Specification Required.  Integer values

      of greater than 65535 and strings of length greater than 2 are

      designated as Expert Review.  Integer values less than -65536 are

      marked as Private Use.


Note that I already took an action item based on Kathleen’s AD review to add a reference to this information in Section 9.1 where it talks about the different policies used – to avoid any possible confusion.  I will do this edit at the same time we address any other IETF Last Call feedback.

                                                                Cheers,
                                                                -- Mike

From: Jim Schaad <ietf@augustcellars.com>
Sent: Tuesday, February 27, 2018 9:53 AM
To: 'Dan Romascanu' <dromasca@gmail.com>; 'Benjamin Kaduk' <kaduk@mit.edu>
Cc: 'gen-art' <gen-art@ietf.org>; draft-ietf-ace-cbor-web-token.all@ietf.org; 'ietf' <ietf@ietf.org>; ace@ietf.org
Subject: RE: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Integer values between -256 and 255 and strings of length 1 are designated as Standards Track Required.

Integer values from -65536 to 65535 and strings of length 2 are designated as Specification Required.

Integer values of greater than 65535 and strings of length greater than 2 are designated as Expert Review.

Integer values less than -65536 are marked as Private Use.

So that says what IANA policy is to be used for each of the different items.  This defines the policies and the ranges for those policies.

There is not anything that is making a distinction on what the criteria to be used by the DE in the document which is separate, but I don’t think that is needed.  This is why they are DEs.

I still don’t see what you think is missing.

Jim


From: Dan Romascanu [mailto:dromasca@gmail.com]
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>>
Cc: Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; gen-art <gen-art@ietf.org<mailto:gen-art@ietf.org>>; draft-ietf-ace-cbor-web-token.all@ietf.org<mailto:draft-ietf-ace-cbor-web-token.all@ietf.org>; ietf <ietf@ietf.org<mailto:ietf@ietf.org>>; ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi,
See also my other notes.
I believe that what the document tries to say is:
Register R is divided into four different ranges R1, R2, R3, R4 (defining the value limits may be useful)
Values in range R1 are allocated according to policy P1 in the case that ...
Values in range R2 are allocated according to policy P2 in the case that ...
Values in range R3 are allocated according to policy P3 in the case that ...
Values in range R4 are allocated according to policy P4 in the case that ...
But it doesn't say it. Mentioning four concurrent policies for the same registry without separation of values range, and without providing clear instructions when each policy is recommended to be used, seems confusing to me, and may be confusing for users of this document in the future.
Regards,
Dan

On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Dan Romascanu [mailto:dromasca@gmail.com<mailto:dromasca@gmail.com>]
> > >
> >
> > ...
>
> > >
> > > 2. I am a little confused by the definition of policies in Section 9.1:
> > >
> > >    Depending upon the values being requested, registration requests are
> > >    evaluated on a Standards Track Required, Specification Required,
> > >    Expert Review, or Private Use basis [RFC8126] after a three-week
> > >    review period on the cwt-reg-review@ietf.org<mailto:cwt-reg-review@ietf.org> mailing list, on the
> > >    advice of one or more Designated Experts.
> > >
> > > How does this work? The request is forwarded to the designated expert,
> > > he/she make a recommendation concerning the policy on the mail list, and
> > > depending on the feedback received a policy is selected? Who establishes
> > > consensus?
> > >
> > > Frankly, I wonder if this can work at all. Are there other examples of
> > four
> > > different policies for the same registry, applied on a case-to-case
> > basis?
> >
> > This is the same approach that is being used for the COSE registries.  As
> > an example, you can look at https://www.iana.org/
> > assignments/cose/cose.xhtml#algorithms.
> >
> > Part of the issue about this is that the JOSE/JWT registries do have the
> > same different policies, but that differences are hidden from the IANA
> > registry.  Since they allow for a URI to be used as the identifier of a
> > field, only the plain text versions are registered.  Thus I can use "
> > http://augustcellars.com/JWT/My_Tag" as an identifier.  Since for CBOR
> > the set of tag values is closed and does not have this escape (nor would
> > one want the length of the tag) it is necessary to have this break down of
> > tag fields.
> >
> >
> >
> >
> This does not seem to be exactly the same approach. The COSE RFC 8152
> defines the registry policy in a different manner. There is only one policy
> that is proposed 'Expert Review' and than the Expert Review Instructions
> are used to define the cases when a Standards Track specification is
> required. No such text exists in the current I-D. There is no separation of
> the values space in the registry according to the type of assignment here,
> as  in RFC 8152.
The template in section 9.1.1 has the different policies for the
different integer ranges, under the 'Claim Key' section.  Kathleen
(IIRC) already noted that this should probably be repeated in the
introductory part of section 9.1 as well, and that will be done
before the document is sent to the IESG.

-Benjamin