Re: [Rats] CWT and JWT are good enough?

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 17 September 2019 12:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235C2120831 for <rats@ietfa.amsl.com>; Tue, 17 Sep 2019 05:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7wAeY1COT43J for <rats@ietfa.amsl.com>; Tue, 17 Sep 2019 05:25:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A92F120020 for <rats@ietf.org>; Tue, 17 Sep 2019 05:25:19 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D50C13897A; Tue, 17 Sep 2019 08:23:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3C24A6A; Tue, 17 Sep 2019 08:25:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats@ietf.org" <rats@ietf.org>
cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
In-Reply-To: <VI1PR08MB5360F2D6930190A12F754B6AFA8C0@VI1PR08MB5360.eurprd08.prod.outlook.com>
References: <CDC992AE-B6DB-4BAE-975F-6E2BF9ED2C97@island-resort.com> <CAHbuEH4fisaDTKOzEY2ZEfxiVyfZ4wYibdRzQUYxq4i8a8G_WQ@mail.gmail.com> <7EA14733-B470-4365-B4FA-FF2B63695464@island-resort.com> <30242.1568655684@localhost> <VI1PR08MB5360F2D6930190A12F754B6AFA8C0@VI1PR08MB5360.eurprd08.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 17 Sep 2019 08:25:18 -0400
Message-ID: <8854.1568723118@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/aeHAE24Zb804QvsfFCEQ5S48Xgg>
Subject: Re: [Rats] CWT and JWT are good enough?
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2019 12:25:23 -0000

Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
    >>> - All EAT claims are Specification Required. No EAT claims and be just
    >>> Expert Review.

    >> I can live with that.


    > I am not OK with that. For JWTs we have been using an expert review
    > approach and that served the committee well.

I think we are not discussing the same things!
EAT claims that are standards need to be Specification Required, because
that's the "bigger" of the JWT (Specification Required) and CWT requirements.

    > We would like to register vendor-specific claims for use within EAT
    > tokens and I can hardly see why anyone should have problems with it.

Please distinguish between vendor-proprietary claims (private-use) ones from
standards!  You are not talking about the same thing now.

rfc7519 section 4.2 allows for claims based upon Public Names, which means
using a Collision-Resistant Name:

  Collision-Resistant Name
        A name in a namespace that enables names to be allocated in a
        manner such that they are highly unlikely to collide with other
        names.  Examples of collision-resistant namespaces include: Domain
        Names, Object Identifiers (OIDs) as defined in the ITU-T X.660
        and X.670 Recommendation series, and Universally Unique IDentifiers
        (UUIDs) [RFC4122].  When using an administratively
        delegated namespace, the definer of a name needs to take reasonable
        precautions to ensure they are in control of the portion of the
        namespace they use to define the name.

So any vendor-specific claim can be created by any vendor possessing a domain
name, a PEN, or who can run "uuidgen" (on a development system)

RFC8392 provides for: Integer values less than -65536 are marked as Private Use.
But,  Integer values greater than 65535 and strings of length
      greater than 2 are designated as Expert Review.

So it shouldn't be hard for a vendor-specific claim to get a number for CWT.
And within the space of "strings of length greater than 2" would be the
identical string used for JWT, if you like.  Yes, shorter is better.

The point of this thread was that for Standards Track *RATS* WG claims, that
we will have to go with Specification Required, because that's the minimum
common process for CWT and JWT.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-