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

Dan Romascanu <dromasca@gmail.com> Mon, 26 February 2018 21:19 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 8B329127241; Mon, 26 Feb 2018 13:19:08 -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 TcBtUyxqZxAZ; Mon, 26 Feb 2018 13:19:06 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 8B266126DFB; Mon, 26 Feb 2018 13:19:06 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id s198so20888152qke.5; Mon, 26 Feb 2018 13:19:06 -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=7oWoNaeXW2A9zLOu2KUJCHncuprZIc58JgcxcWKclW4=; b=qQLxYNK+U3IJmwoJjLNG4u5rKkHCVieEY1/U0aaPxBFLRtS0Qge7Hfg0Cagp5xqpeE kbbAW7xKJuzCTW6clZ1J3K6TreQCAoLCpo6qqxxjeDam3PrmfeFTluAPH9NEdvMuYiLP BVO7s3qBYm+oR0VoESq54l7+tQQDE1jKG0qmGaMaBp5++ICoyNRP7cpf7Oq8TTZTIcbv V5I+6erVCkKU8EVbGYHqdCyxKf70LBJHckwekgfPjzlTBjaMB7ea9ktsYxxD7iily+dq zSdSjuodIkPmFbLcHEzjALEqfGsG+17+u/3zw14mRgL2D43UtrquthcWpZ5RIUOSeEBy PDng==
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=7oWoNaeXW2A9zLOu2KUJCHncuprZIc58JgcxcWKclW4=; b=soWwyr8Sc1IyZpgR8xPAiZElg5wUwQ5J/2RdGQ/XhTE2g3NYoe0suTPWWhc+mVk7X4 s68cGPHiLN3AddI8QlEq6KjM2JWGyEcaoMZzcvZmzz4OYwrcYrRb2I3xylEoOT0fujNy uq0XFCc6++kZ09RC3PCr0F3LbxV4g7Lu9g/W3R5BXBlhcunGMJABHurzcohk0vJuuQgg otdPbA09GOTOPe/2jtLczoJjJNFCDM0FIKKbo3uJmxyL1ibUaXasyhQMsOx2sB6Vgppl YXZ6xsgID5wYEp+YQ+Q31iu+HxiX+qTgQH4PWwifxtKmqVikWGBDtqt95MT9nWTkJ+Bl DqfA==
X-Gm-Message-State: APf1xPDa9p9WCIpCoCWNZqP/4EK/ayD4JM5oxBNFoLYJODUO68n3Xn6b QQLg/GXqoSIJqL3zw26x3V2BZ8gzkz8dtox4eJA=
X-Google-Smtp-Source: AG47ELv/eIwKvrKl8p9CylAL9QYp+s1Mv0XrLSmJFf4FtdKzwTd4389hcGsiWaenEl1qX7sNwMcU0p4epyUt2j1hfcM=
X-Received: by 10.55.79.78 with SMTP id d75mr18013291qkb.20.1519679945698; Mon, 26 Feb 2018 13:19:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.23.200 with HTTP; Mon, 26 Feb 2018 13:19:04 -0800 (PST)
In-Reply-To: <021201d3af3e$1f204cc0$5d60e640$@augustcellars.com>
References: <151967178760.21771.14005895812023525211@ietfa.amsl.com> <021201d3af3e$1f204cc0$5d60e640$@augustcellars.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Mon, 26 Feb 2018 23:19:04 +0200
Message-ID: <CAFgnS4USoaMrDSbvOZj4Pwg3DprMNNxrHoPn+DK-YjVNB-Jrog@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="001a1148868255f61b0566240faa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/97qixBpc6ph3169mmveELYdafwU>
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: Mon, 26 Feb 2018 21:19:09 -0000

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.

Regards,

Dan