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

[Henk Birkholz <[e-mail]>]

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) <[e-mail]> 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)" <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rats
>>>
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>