Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 18 November 2019 12:43 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 D35C31200F6 for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 04:43:31 -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_HELO_NONE=0.001, 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 N3FNnPaTTHGY for <rats@ietfa.amsl.com>; Mon, 18 Nov 2019 04:43:29 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::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 83BDC1200EB for <rats@ietf.org>; Mon, 18 Nov 2019 04:43:29 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id m193so15175747oig.0 for <rats@ietf.org>; Mon, 18 Nov 2019 04:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=77bxHGTSpqp7/XkxYH1XpEd1wlcr/Q8gK6BHik3Ju7c=; b=D5KeJK9z9RaW7b74lR5GFw4xyF/ebvqoqpYBaoc8d9eLpU6X+TlwnW1/jeVkorVpfp fgmj2yfo/+3g2O5LfXDoNp3D03cwvz3QTaW1JAxJOvI4yt1rb8r+6cWn8xHLqD+7D0hx LGHSk4UplfFnSGxhVnSlLQ6eLzNrfRoBxFk81W5ywDvAq++FHaAaQh/v03YWhCd1gieS ikJ1RnKAIOghyrx+SiHYBmGL14u2yYyp6PrQnHeBI8lxhMmtJlhAOkRNvDTsD71ftPE3 /0pWBwd4hyjFUgHPvzsPw7R98LicSJ2QkBxq1FSvHUlpDL+AmGXx72FK/vxRCETlTudl GNGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=77bxHGTSpqp7/XkxYH1XpEd1wlcr/Q8gK6BHik3Ju7c=; b=IfS7wUCZobNhDdZppolE7TLGrTPbp61wWoF19yNlgzHSNVPdbGR39mHaQ0Lu18hUoD /OhItOIufryY/lEn/d9Qoo1Ri/mO/vlIUM9aXSdQ1I+mu/a/wcR8t0rEu9G0pjivW51L IfIWsTHwUzLZVnXwhAfYHHnUMpt26Rs4AACUK5/d1paq0Fy5xuVYTAEEBpAtmOVF1xtS m9g031HxbnbwJtBztxv24PEBsJXAkVrckm54RWM8u/CsQuGCgMyuT8T01eW6eZ0Iim9p JM5p+11m/SxokFJFofy993eQEXnRugIqUmYlOkME0C10uTkk26aEPjJzfN68dxSnL7zg EACA==
X-Gm-Message-State: APjAAAVtc+uvdWHsbMCslzZHbVDDiDAEAgX3YYCjqRECv6zGc9AZZqNN J/P4d61v42NJP7WTREj+LkPMddxbh1kci0ldZzs=
X-Google-Smtp-Source: APXvYqw/ErDY3wJJcK+Tk6Gcfo07xKej4HuGPY8/XSohDbRKPct4088CA3kwNYxOTv0RvbXRBAz4rnHpDGTlSzR2iP0=
X-Received: by 2002:a54:400d:: with SMTP id x13mr10924247oie.119.1574081008859; Mon, 18 Nov 2019 04:43:28 -0800 (PST)
MIME-Version: 1.0
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <6E7D64B4-2049-4D0A-ADC5-CA3F0647779B@island-resort.com> <20191114140600.itrr5mjiysgutsj5@anna.jacobs.jacobs-university.de>
In-Reply-To: <20191114140600.itrr5mjiysgutsj5@anna.jacobs.jacobs-university.de>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 18 Nov 2019 07:42:52 -0500
Message-ID: <CAHbuEH7ntaqD28QXv90RUTrcdTmcvej8Hw0TN3jx=ABo6Er4Qw@mail.gmail.com>
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
Cc: Laurence Lundblade <lgl@island-resort.com>, "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, Dave Thaler <dthaler@microsoft.com>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000617cf405979e4b26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/3IoqR9fCoE1q8tgriii7io8CR3M>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Mon, 18 Nov 2019 12:43:32 -0000

In reading this thread, I do hope we don't spend a lot of time on the
definition of a token.  I think it's been stated pretty clearly in this
thread, so let's just get it down in a document and move on.  I did see one
place mention a set of claims is a token (the point in the thread argued
that and I agree as it's more than just claims).  A token is some data,
some claims, and a signature.  I think it was Jurgen's previous message to
this one that had a pretty good definition.

Also on the point of binary - when I present anything that has to do with
JOSE and COSE, this is one of the things I start out with as the
differences between the two as well as COSE being designed for constrained
devices, so it's more compact.  Perhaps stating a preference for CWT with
this justification makes sense to someone else's point about not supporting
multiple formats.  This would continue to support multiple formats for
EATs, but would set a recommendation.  I won't go as far as to say a
Mandatory to implement as that doesn't make sense in a full JSON
environment where you wouldn't want to introduce COSE.

Sorry for the top post.  This was a long thread to catch up on and the
other points from my thoughts were addressed.

Thanks,
Kathleen

On Thu, Nov 14, 2019 at 9:06 AM Schönwälder, Jürgen <
J.Schoenwaelder@jacobs-university.de> wrote:

> On Wed, Nov 13, 2019 at 10:07:02AM -0800, Laurence Lundblade wrote:
> >
> > I see EAT as applicable to all these worlds, where the YANG module is
> just for the smallish router world. So I mostly agree with Dave about
> proportions, however this is the IETF where YANG modules are created.
> (Maybe I should go join the W3C world and work on attestations APIs for
> browsers after RATS is done).
> >
>
> If EAT is the common format for "token", then it does not make sense
> to me to define a YANG version of it. It may make sense to carry EAT
> token over protocols such as NETCONF or RESTCONF and to have a YANG
> module defining this may make sense for the networking device world.
> This is then a definition of an interaction protocol, but not the
> token format itself.
>
> If EAT is the common format for "token", then it may make sense to be
> able to include "claims" that are YANG defined data. That may be an
> extension of the core EAT definition (but EAT would have to allow for
> such an extension to work). There is a lot of formally defined data in
> YANG modules that would be convenient to reuse as claims in a
> networking world.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>


-- 

Best regards,
Kathleen