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

Dan Romascanu <dromasca@gmail.com> Tue, 27 February 2018 06:44 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 26A2E120454; Mon, 26 Feb 2018 22:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tyM9acDApepW; Mon, 26 Feb 2018 22:44:50 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 C3C151200B9; Mon, 26 Feb 2018 22:44:49 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id g60so21890833qtd.11; Mon, 26 Feb 2018 22:44:49 -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=BMdcixeBXdU/jSvReoYNsRtTMVCK4ItMyWNdgodxNzU=; b=ofOZFCvk8+BcsKNrEPaCwKkkQ8ne1ndsQV6NfFRxWTpPVb4zMNdjA+fysDKb+nu5/K 8DdUrMCb3Z65jU/4ISoyF6hwFNM1zBBq5nLXOUgO4AlkkZ9twA5dz6Xb+GEp/bsUzxXB FeJpUIt24vcGqQPXI6Tv2S2PWaz8gOzlYuC0sQWiwnqxSMZ947Ef5V31wi9OoXpmNCLh WVl/J0ZdMDJPs2Y45DU5QjxdzfKyU264YSyLumKBEHs0ZLwUfHv3SXE80TFLB0m591c5 gmBzCX9ZmPsx95Zbs+K2EGSwBndl9x/IBALFD4mOTtK+b1fT9Eqc7FJR16u9YWUqcIYG qESw==
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=BMdcixeBXdU/jSvReoYNsRtTMVCK4ItMyWNdgodxNzU=; b=ucjOM6UVBQbL3i1Vymw5KOB6haH/d3SMGkUOilBqpCEMc9kMqzxRbisvh8NViY96KF KXGe7d6NccTgr5GVGitAnfuxbIHac5dudJZX7HfWQz9SQ4dUxK2ReQCDkRkPrKMBcmhu 25Z/aSGrToJm4G/o+miCbyU9VU/DnnyOfSPCWweHi7axWS0Gvy4AhzdSVr+UiWEWTqqx n/HqpSwnbkR64byOzdXLE252LqGu6otG578LW++GlkP9vzZtC2Lbduf00JFrZAifoeuy m/uKYErIP7W5qQqyUeLmJ2zG8yydu+wp/nKdukEn8yQdhEbfa9DYbgH2oZ1i0iKn/9h6 rrlA==
X-Gm-Message-State: APf1xPBAU1gmqm2/0vsAP/13b3RE67PxHyk0DmMHaO3U/RfECXolPV8X mFD1eruaUFBY317DmFeuzMUbATWwVOxFFHIA+cA=
X-Google-Smtp-Source: AG47ELuv9pMYxgEzU0OCHYl3QsqVJHCyYzFeK137IMV5M3jZ3OxHSRfqi6Mbk0xedAoqhsCB8xdrQ9EyRPNZ3A16GxY=
X-Received: by 10.237.44.225 with SMTP id g88mr22292493qtd.339.1519713888925; Mon, 26 Feb 2018 22:44:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.23.200 with HTTP; Mon, 26 Feb 2018 22:44:48 -0800 (PST)
In-Reply-To: <022401d3af4b$69813600$3c83a200$@augustcellars.com>
References: <151967178760.21771.14005895812023525211@ietfa.amsl.com> <021201d3af3e$1f204cc0$5d60e640$@augustcellars.com> <CAFgnS4USoaMrDSbvOZj4Pwg3DprMNNxrHoPn+DK-YjVNB-Jrog@mail.gmail.com> <022401d3af4b$69813600$3c83a200$@augustcellars.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 27 Feb 2018 08:44:48 +0200
Message-ID: <CAFgnS4V_Mg4k8AVqz6j0yeR_g7sWqQwrWSTnOw0Z2h-Dqy37xw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: gen-art <gen-art@ietf.org>, ace@ietf.org, ietf <ietf@ietf.org>, draft-ietf-ace-cbor-web-token.all@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1256e2827d5005662bf644"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/kP3HYXxp6htihgcuW6hG4z5-xoM>
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 06:44:52 -0000

On Mon, Feb 26, 2018 at 11:47 PM, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
>
>
> *From:* Dan Romascanu [mailto:dromasca@gmail.com]
> *Sent:* Monday, February 26, 2018 1:19 PM
> *To:* Jim Schaad <ietf@augustcellars.com>
> *Cc:* gen-art <gen-art@ietf.org>; ace@ietf.org; ietf <ietf@ietf.org>;
> draft-ietf-ace-cbor-web-token.all@ietf.org
> *Subject:* Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12
>
>
>
> 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.
>
>
>
> [JLS] The policies look to be the same to me, but I may be missing
> something that you are seeing..  Remember that Specification Required
> implies Expert review.
>
>
>
> Hi Jim,

You seem to miss the exact definition of policies. Please see RFC 8126,
Section 4. Expert Review and Specification Required are two different
policies, even if one implies the other. Your document defines multiple
policies for the same registry, without making clear which is to be used
and when. This is unusual.

Regards,

Dan