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

Laurence Lundblade <> Fri, 15 November 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EA84120130 for <>; Fri, 15 Nov 2019 12:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ABy6KMhOu3Wv for <>; Fri, 15 Nov 2019 12:46:41 -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 E78A212006F for <>; Fri, 15 Nov 2019 12:46:40 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id ViUIiJ3y3BN3vViUJijvAN; Fri, 15 Nov 2019 13:46:39 -0700
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7363E08-7525-4573-BC49-ECCB7DAF3CD6"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 15 Nov 2019 12:46:38 -0800
In-Reply-To: <>
Cc: "Eric Voit (evoit)" <>, "Smith, Ned" <>, =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <>, "Nancy Cam-Winget (ncamwing)" <>, "Oliver, Ian (Nokia - FI/Espoo)" <>, Dave Thaler <>, "" <>
To: Henk Birkholz <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfLarWFX6ArrhIGeix+LfUZ40huJ4bepfw68Qs4ktIo2vuH2c1gcoeUeyh9DDhgmgMcbs6z41Wk4ynIWHvY35FEcizBLjuXwr+QhQBdQtB4csVnmlBqPx jAu8+D9C1PrfaVzipn92uTfm1AAxiNORLd0rEKhazB8HBS6k/NDoqdutsCVm7yczT1jTGghrUDt9kIm86kx+0VXXeea3pXVHoAsk+hJKJfYudBnJPpvTOvwH nAtoKwbCbyPT+nqCRKex7h8vkwHfcFSPpHSIIl4gB12pp8ykH0I7kA77HHNAZTBNfp38dECoIZoDFVEIbCi7GyEed0xV7hc2A3laaQAFH10tog74yMd2Lgln O1W0LGlDakj4N4PZw5pIvw9Cmuly/wPqdIkDhtuCnq/eYCez7VJrEv/kB+YswOSLzQ85oTH/
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: Fri, 15 Nov 2019 20:46:45 -0000

I want to do it like the current EAT document (current draft’s labeling of info and data model aside)
Normative definitional text per claim
CDDL per claim
Largely mechanical rules to go from CDDL to CBOR & JSON.

The subtleties of info vs data model escape me (and don’t seem that critical to me for the work at hand). The main thing I care about is that we one main definition of a claim that is not replicated and it can mechanically to go CBOR, JSON and maybe other serializations.

You can tell me how to label 1, 2, and 3 however you want and I’ll probably just use that in the EAT doc.

Also, by this I meant

>> I’d also like EAT to only use CDDL for the data model and nothing else

no YANG for the primal definition of claims and no YANG in the EAT document (see my other recent email with the X.509 analogy for suggestion on how to integrate with YANG expression of claims).


> On Nov 15, 2019, at 11:30 AM, Henk Birkholz <> wrote:
> Hi Laurence,
> I would like to highlight this quote:
>> I’d also like EAT to only use CDDL for the data model and nothing else
> This is a significant change of turn. I would like to get more background about why you are not intending to use CDDL as an information model anymore and also why you think using CDDL as a data model specification is helpful to define Claims.
> I can see the point that CDDL was not done when CWT was done. And I think that would be a good argument.
> Alas, I am more at a loss now how we intend to deal with the IM aspect in RATS now. The thing we tried to propose initially was an English description. That did not find consensus and CDDL seemed to be the new approach. What are we doing now, if you are proposing to down-level CDDL to data model again, creates a vacuum. Are we going back to English text es we initially proposed? In retrospect, why are you dropping the approach your were advocating for quite some time?
> My concern is that this accumulation of changes in a lot of places has the exact opposite effect of expedition - which was the primary incentive for the initial proposal, I think?
> Having said that, cddl is literally a data definition language. I just think it is hard to argue why we are changing horses do close to the finish line. I do not object on a technical level, I just want to highlight that is a significant change of direction.
> Viele Grüße,
> Henk
> On 15.11.19 20:13, Laurence Lundblade wrote:
>> Here’s a try at an analogy of EAT Tokens with X.509 Certificates.
>> For both the core of the definition is of the signed serialized data format. A set of fields / claims is defined in the core standard. That core standard is solely focused on the definition of those fields / claims and shouldn't get intertwined with other protocol definitions.
>> However, other protocols may decide to have fields that are the same as, maybe even defined in terms of the fields  / claims in the token / certificate. Those definitions are probably normative references to the fields / claims in the core token / certificate standard. TLS makes normative references to PKIX this way in section 4.2.5. I think this is perfectly reasonable things to do.
>> So, I have no trouble with some EAT claims being used in YANG designs, but I’d like it to be by reference to EAT. I’d also like EAT to only use CDDL for the data model and nothing else.
>> I think trying for a single information model that is common to EAT and YANG designs is too big, too much intertwining and is scary. It will lead to schedule interlocks between the documents.
>> Another reason is that I view router / YANG use of attestation as only one (well-represented) use case for EAT. YANG-based use cases shouldn’t be central to EAT's design. If we were to intertwine with YANG, maybe we should intertwine with JavaScript and a bunch of IoT protocols too.
>> LL
>>> On Nov 14, 2019, at 12:42 PM, Eric Voit (evoit) <> wrote:
>>> My belief is that a Relying Party will rarely want the full universe of signed claims coming from some Attester's chip.   We need ways to pre-filter the results.  How would we do this without a model?
>>> To fill this need, I always hoped that EAT claims could become leafs of some future YANG data model.  This would allow GET and SUBSCRIBE requests to be made to an Attester.  What would be returned to the Relying Party would be the signed results of interest from some chip within the Attester.
>>> I have no position on whether the WG wants to integrate GET and SUBSCRIBE requests so that they can provision claims are ultimately placed within the EAT token.
>>> Eric
>>>> @Eric Voit (evoit) Is this suggesting that RATS architecture should define a
>>>> token-like DM structure that is a *request* "token" having only tags
>>>> identifying interesting claims while a *response* "token" would have claims
>>>> with data values populated?
>>>> On 11/14/19, 8:02 AM, "Eric Voit (evoit)" <> wrote:
>>>>    Hi Jürgen,
>>>>    Hi Henk,
>>>>    What routers need is exactly what you said.
>>>>     - currently: the retrieval of TPM originated/signed quotes.
>>>>     - in the future: the retrieval EAT Tokens
>>>>    Knowing when to retrieve these items is a function of the value of specific
>>>> claims inside those structures.  For example, I might want to use RFC-8641 to
>>>> make a YANG Subscription to a router so that I will be pushed the latest TPM
>>>> quote when a specific PCR changes.  For this to work in the router world, we
>>>> must have the structures of Quotes/Tokens exposed by a YANG model.
>>>>    Eric
>>>>> Hi Jürgen,
>>>>> I think this is very useful input.
>>>>> On the list, Laurence and I already started to discuss Claims for "YANG
>>>>> modeled data" and Claims for "TPM modled data" (referred to as tpm
>>>> tokens
>>>>> recently).
>>>>> The remaining questions are about: What do you think is the
>>>> upcoming/TBD
>>>>> impact on the current YANG module for challenge-response RATS?
>>>>> Leveraging YANG modeled data comes up again and again. Maybe there
>>>> is
>>>>> good approach here.
>>>>> The TPM Interface based YANG Module does not simply convey native
>>>> TPM
>>>>> structure, but decomposes them down the values that are useful and
>>>>> common on the management plane because the building blocks
>>>> themselves
>>>>> have well defined semantics (always ensuring canonical re-composition).
>>>>> Viele Grüße,
>>>>> Henk
>>>>> On 14.11.19 15:06, Schönwälder, Jürgen 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
>>>>> _______________________________________________
>>>>> RATS mailing list
>>> _______________________________________________
>>> RATS mailing list