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

"Smith, Ned" <> Mon, 11 November 2019 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BABE512092B for <>; Mon, 11 Nov 2019 08:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pMuN2uWklkVx for <>; Mon, 11 Nov 2019 08:26:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A6C2120921 for <>; Mon, 11 Nov 2019 08:26:38 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2019 08:26:38 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,293,1569308400"; d="scan'208";a="197715691"
Received: from ([]) by with ESMTP; 11 Nov 2019 08:26:37 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 11 Nov 2019 08:26:37 -0800
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Mon, 11 Nov 2019 08:26:37 -0800
From: "Smith, Ned" <>
To: Henk Birkholz <>, Michael Richardson <>, "" <>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVlCwI8/lytau3hU+AhCwtIdg/0ad/EtmAgAAHhgCAAAO0AIAGacyAgAAGuoCAAG6gAIAABXMAgABH9wCAABvLgIAACkiA///AhAA=
Date: Mon, 11 Nov 2019 16:26:36 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 16:26:41 -0000

So far the group has used the term "EAT" to refer to both the information model and data serialization expressions. When extending information model to YANG or some other serialization (e.g. ASN.1). Given the possibility for an IM expression to be realized by different serializations, what term should we give to the IM description? 

The term "Claim" has been used extensively. Do we want to agree to use "claim" to refer to anything that is an IM expression in RATS and "Token" for any serialization (realization) even if it isn't a JWT or CWT?  


On 11/11/19, 4:14 AM, "RATS on behalf of Henk Birkholz" < on behalf of> wrote:

    Hi Michael,
    please see in-line.
    On 11.11.19 12:37, Michael Richardson wrote:
    > On 2019-11-11 5:57 p.m., Henk Birkholz wrote:
    >> Hi all,
    >> on one hand, we have to address the overlap between YANG and EAT
    >> information elements (statements & Claims) and how to deal with them
    >> (one obvious issue, for example, would be potential redundant
    >> information model content in two different drafts).
    Examples of the same information elements that are used in different 
    data models via Claims or statements:
    * EAT Time stamp / YANG clock info
    * EAT Origination / YANG attestation key cert, or
    * EAT Uptime / YANG tpm ticks
    > Can you give me an example, but I'm not getting the issue.
    > I think that we will be the first to attempt to use JOSE to sign a JSON
    > serialized YANG object, resulting in a JWT.  Well, technically, it's
    > probably not a JWT, because we aren't going to base64url it and put
    > periods between the pieces, I think.  It's just JOSE, but I don't mind
    > if we call it a JWT.
    As far as I know, simply wrapping a "JSON serialized YANG object" in 
    JOSE does not create a JWT. RFC 7951 is not based on RFC 7519. The 
    Base64/Base64URL confusion is limited to value representation in JSON 
    serialization, I think.
    > draft-ietf-anima-constrained-voucher does CBOR serialized YANG which is
    > signed with COSE.
    With CBOR serialization most things more straightforward and a tad bit 
    simpler. I do not think that we have any issues on the binary side of 
    things here. Or am I missing something obvious?
    >> On the other hand, Laurence's original point was the payload of
    >> conveyance protocols used by RATS. Specializations of this topic are
    >> apparently:
    >> * Web Tokens via YANG Interfaces, and
    >> * YANG modeled data via other conveyance protocols (other than *CONF)
    >> that can transport Web Tokens.
    >> There are examples of how YANG modeled data is used outside of *CONF
    >> protocols, for example MUD. We have to understand and agree about:
    >> * this is possible on a technical level, and
    >> * this is useful wrt to protocol scope, intent & semantics, I think.
    > MUD (RFC8520) does it, but so does ANIMA vouchers (RFC8366).
    > Again, data-at-REST described by YANG.
    > But the document in question does not seem to be data-at-rest, but RPC
    > access via *CONF protocols to TPM 2.0 objects, so I feel that you are
    > further muddying this thread by asking the above question.
    > _______________________________________________
    > RATS mailing list
    RATS mailing list