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

Dan Romascanu <dromasca@gmail.com> Wed, 28 February 2018 07:23 UTC

Return-Path: <dromasca@gmail.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 C0FC112DA26; Tue, 27 Feb 2018 23:23:39 -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 5TvOcoVYiHP4; Tue, 27 Feb 2018 23:23:36 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 5A440120725; Tue, 27 Feb 2018 23:23:36 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id d206so1814137qkb.3; Tue, 27 Feb 2018 23:23:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5adbeJAvIK1L0FILvLQIT0A/VHb5RgWpqlDsY1v2+AY=; b=GBWzdNwA5vA7KIZl/HsaRmnzG5Iz1UT+DP/i1PSVMOxuLQnOyfmz8JFGFjy2H18PIb jYxw/GFapKb/+kYBrLUVCGJPKt+lPJbYcy6eHgAv0P1Q3I45NPuT3Q3eh2MSNvhkrp4W wYu3R0ONLRHVDbypd37ax6Jimw2BJMCSIGxXx6GhHwEVjJHyX+r4niJv8ipi/dfxqfFm i/omrYTYSNwWjx1df9Y9NazYjmCLDcKTGNMYa+qh8z/LxQo8qGcoKQG3iaZPoSyGVb7p 7fx2GWuEQxheD5T1hcgjbV+LZtcc34u4OJUqHehmmizN2bqtNu0HVrxHl07lG02SGqvM 4y1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5adbeJAvIK1L0FILvLQIT0A/VHb5RgWpqlDsY1v2+AY=; b=qOx3QH/U5QBpoSwf7EKk5GtUZB58ZsTgXOFgT3WIIOAcClwNaLbNw52fuHXQejJlGS yaYUEqW5a3jHbUn8EPbujC/yth3UcExqMZiP2+Iul9AXr2oLsrfsdCrZ37f4Dn6dSwk2 TdpuGGDMCpg3NiOGBugU0oOJAaMgVt5KnOx/2VhO9gU0ny/QPf95Eym7LssNfidtBCYu HY36XBvHR1P4vYD9PJ//n+TdFq4xDiK9YZHq1zDLxk33ZlNiSYe0iYNEhpx9iF/vDGY2 xTdbdFCHV4GWWwKDr1txed0Aok6GSED+VCirnI6HNKrtQEf6z5n4QiNA9/g3cx6W/PG/ ZLUA==
X-Gm-Message-State: APf1xPDXl2rd+F2FrTlvS2u0uXA2pboYfKOw0lPG+c70FhCGyPEKjCBQ eZ5EUVKo8J0rFvzLr0ZwTGhI0yrBPn19c3AJLX4=
X-Google-Smtp-Source: AG47ELv+esMNYBpVnXKtfxKYLUiTLFOPjzrMIY01HMIMvqGMD+vDDUj/AtkawndYRbvi4/xpDnhWOjTdFBIlMmMwDoo=
X-Received: by 10.55.19.76 with SMTP id d73mr25716198qkh.288.1519802615452; Tue, 27 Feb 2018 23:23:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.23.200 with HTTP; Tue, 27 Feb 2018 23:23:34 -0800 (PST)
In-Reply-To: <SN6PR2101MB09436CCA10FD477A41819B42F5C00@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> <CAFgnS4WrfRHPiMqETyOK=2g-bNKp66i-9NC9JLbbO6eh7brV6w@mail.gmail.com> <SN6PR2101MB09436CCA10FD477A41819B42F5C00@SN6PR2101MB0943.namprd21.prod.outlook.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Wed, 28 Feb 2018 09:23:34 +0200
Message-ID: <CAFgnS4Wn=S_PskHiZu2qBXf_sHY7asgsHqsHUvNSkF31gKX4Cg@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Jim Schaad <ietf@augustcellars.com>, gen-art <gen-art@ietf.org>, "ace@ietf.org" <ace@ietf.org>, ietf <ietf@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "draft-ietf-ace-cbor-web-token.all@ietf.org" <draft-ietf-ace-cbor-web-token.all@ietf.org>
Content-Type: multipart/alternative; boundary="001a11400d2005dbfa0566409fb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tpyH26il5cqE9GW1Me9F2F-lc1I>
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: Wed, 28 Feb 2018 07:23:40 -0000

Hi Mike,

The edits that you propose in #1 and #2 are good IMO and they would improve
the clarity of the document.

Concerning #3 - all the 'running code' examples that you provided are all
for one type of policy only - Specification Required. The case here seems a
little more complex, as the review and required advice refer to multiple
policies. Thanks to the discussion and information provided by you and Jim,
I believe that I better understand now how this works, and I defer to the
General Area and Security AD the decision whether the text is sufficiently
clear.

Thanks for addressing my comments.

Regards,

Dan


On Wed, Feb 28, 2018 at 12:52 AM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> Replies inline…
>
>
>
> *From:* Ace <ace-bounces@ietf.org> *On Behalf Of * Dan Romascanu
> *Sent:* Tuesday, February 27, 2018 2:23 PM
> *To:* Jim Schaad <ietf@augustcellars.com>
> *Cc:* gen-art <gen-art@ietf.org>; ace@ietf.org; ietf <ietf@ietf.org>;
> Benjamin Kaduk <kaduk@mit.edu>; draft-ietf-ace-cbor-web-token.all@ietf.org
> *Subject:* Re: [Ace] Genart telechat review of
> draft-ietf-ace-cbor-web-token-12
>
>
>
> Hi Jim,
>
> There are still a few problems:
>
>
>
> 1. The policies and mapping to the values ranges are hidden in the Claim
> Key field in the template (the comment also made by Kathleen)
>
>
>
> Per my earlier note, I will be making this language clearer when the next
> revision is published.
>
>
>
>
>
> 2. At least one incorrect policy name is used: Standards Track Required -
> do you mean Standards Action (?)
>
>
>
> Thanks – I’ll update the terminology when the next draft is published.
>
>
>
> 3. You describe a process that involves a mail list (
> cwt-reg-review@ietf.org) and Experts Review. This description is not
> clear. Usually IANA approaches one DE for advice and expects the advice
> from the same DE in a reasonable period of time. If I understand correctly
> the process described in Section 9.1 one or more DEs make a recommendation
> and run it with the mail list. Who establishes the consensus on the mail
> list? Assuming the mail list disagrees with the DE recommendation, who
> decides?
>
>
>
> This is the process used for the .well-known URI spec, the JSON Web Token
> (JWT) spec, the JOSE specs, many OAuth specs and it works well.  It allows
> interested parties to see and comment on registration requests.  The
> Designated Experts are still the ones to decide.  See these references for
> some uses of this kind of publicly-visible registration procedure:
>
>
>
> https://tools.ietf.org/html/rfc5785#section-5.1 (using
> wellknown-uri-review@ietf.org)
>
> https://tools.ietf.org/html/rfc6749#section-11.1 (using
> oauth-ext-review@ietf.org)
>
> https://tools.ietf.org/html/rfc7515#section-9 (using
> jose-reg-review@ietf.org)
>
> https://tools.ietf.org/html/rfc7800#section-6 (using
> jose-reg-review@ietf.org)
>
>
>
> I can find more examples of the use of this publicly-visible registration
> procedure if you like.
>
>
>
> Regards,
>
> Dan
>
>
>
>                                                           Thanks for the
> careful review, Dan,
>
>                                                           -- Mike
>
>
>
> On Tue, Feb 27, 2018 at 7:53 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> 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>
> *Cc:* Jim Schaad <ietf@augustcellars.com>; 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
>
>
>
> 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> 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>
> wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dan Romascanu [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 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
>
>
>
>
>