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

Dan Romascanu <dromasca@gmail.com> Tue, 27 February 2018 09:59 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 A478A1274D2; Tue, 27 Feb 2018 01:59:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, 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 56Y5mJhihtC0; Tue, 27 Feb 2018 01:59:51 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 58E64126BF6; Tue, 27 Feb 2018 01:59:51 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id z197so22747875qkb.6; Tue, 27 Feb 2018 01:59:51 -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=6BacxPEF5CIFjmRvD+waK342HO/eDpc0W1OGv5E844E=; b=jA/9nmkRsvfnGwF9r8RtJWHsuNO/3SmyeUvuA+o+5X0jL1S2I6uapQjaWYXSTCwmEv UtP1GrxUMoLLTkWOPWQw9xTV+hec8dfkxqz2+c3wAH9oeLe+sNhn/V/8PDIW4CrX1U/z pxhTU2jsCNhmdjDi0z71ms90lol9JBJeGBd5H0jRHDGNe7fE9UqkEDG7wCECjgOafqsL S58nJDshy175bC7gktHiQA2lPxR7afipTc9XXNlTxe+WdyzxhCRUm+pizqjPp+Qp44ph nO0OFDk8kjsnQFsHzxD+QGB07TYbdWhr4yYrveMSImngAHHwiexuefW3vB24ubV5Yqfr cGgw==
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=6BacxPEF5CIFjmRvD+waK342HO/eDpc0W1OGv5E844E=; b=TMXOBEkwh7FSPoRrpfkt05Z46h4xOok36zqTQk6K3+Zh4IjhNJO9B1GFVBSALCrVlL I78q+ngZr5TnwQA01RL8gan1eTly4Mqyu4rzz6j7seqALOQFVaniV5Cms7SGdTD+RFwW AEtF46Clgm0q9c5BxIoOygyOr/VhO81JUrAwy+1oPjZ2iHNWr5h9uk+rQvA2dsmEf+l7 fzHlUYQEnP0GENWNhqdnyPEXbi0a9PyqVWLnuKsoWmq8UQWYIZtDwsy9a87O5coB/8yF kTrsC9/PWV7DYr9UX6GoQWJ1YOfX93R8Q/n54oTNc4URrdYeI8uSYKixaJysLS8egt3y xUqA==
X-Gm-Message-State: APf1xPCKKAWEctoFFazld09S1e/5VFfxPFonmeZH9s+/1it6PvyfR2nS njhnsInwwmp4zprMQ2FYeNoWlJ7uiaUwUvzkeiVkvQ==
X-Google-Smtp-Source: AG47ELusNClNyByBaDnsENUA3eaZhZLjGSWOt9VFGF7Pd7af8xZw5roepVLVDmSj+9AM0KNC/dS8u8qwIR+Ddg5J2fE=
X-Received: by 10.55.195.79 with SMTP id a76mr21751847qkj.217.1519725590463; Tue, 27 Feb 2018 01:59:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.23.200 with HTTP; Tue, 27 Feb 2018 01:59:50 -0800 (PST)
In-Reply-To: <20180227034009.GT50954@kduck.kaduk.org>
References: <151967178760.21771.14005895812023525211@ietfa.amsl.com> <021201d3af3e$1f204cc0$5d60e640$@augustcellars.com> <CAFgnS4USoaMrDSbvOZj4Pwg3DprMNNxrHoPn+DK-YjVNB-Jrog@mail.gmail.com> <20180227034009.GT50954@kduck.kaduk.org>
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 27 Feb 2018 11:59:50 +0200
Message-ID: <CAFgnS4VJDs0Xm2zFG5jXQ3eTC0umNvLxBmkLzQKzbPARZq1RVA@mail.gmail.com>
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
Content-Type: multipart/alternative; boundary="001a11479b36f9caec05662eaf59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Wd3d3QUJqxAdIV0HRJLgNGYYNP0>
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 09:59:54 -0000

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
>