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

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).

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.

This is one items of the 5 minutes slot I gave back. And I am happy to 
see this on the list.

Viele Grüße,

Henk

On 11.11.19 06:39, Nancy Cam-Winget (ncamwing) wrote:
> Hi Michael,
> See comments below:
> 
> On 11/10/19, 9:21 PM, "RATS on behalf of Michael Richardson" <rats-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
> 
>      
>      
>      On 2019-11-11 6:44 a.m., Laurence Lundblade wrote:
>      >
>      >> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing)
>      >> <ncamwing@cisco.com <mailto:ncamwing@cisco.com>> wrote:
>      >>
>      >> So, Laurence, are you still OK with the adoption of the current draft
>      >> with a rename for now?
>      >> Thanks, Nancy
>      
>      You suggested the name:
>      
>      “Yang Module for TPM based Remote Attestations”
>      
>      But, I think that it should say instead, "Yang Interface to TPM 2.0"
> [NCW] That is a fair point.....my point is that it should be named to reflect core of description which is based around TPMs.
>      
>      >
>      > I think the value add to the larger RATS effort of adding EAT support
>      > to this YANG protocol is really high. It a core thing to do that helps
>      > bring together the two attestation worlds and make the TPM and EAT
>      > work here less like ships in the night.
>      
>      Can you explain what it would mean to add EAT support for a YANG module?
>      Maybe I'm daft here.
> [NCW]. Hmmm, I did NOT state that?  I think that was Laurence.  I view EAT as defining claims that use  JWT/CWT data structures.
> If there are claims (not format) that can be represented in Yang, then yes (and I think some can).  But the "general EAT", I'm not
> sure how those structures map to the TPM interfaces...but they certainly could be represented in YANG.
>      
>      The current document is essentially a YANG wrapper around the TPM 2.0
>      specification.  It's RPC, data in motion.
>      
>      While EAT is primary a JWT/CWT object, which is data-at-rest.
>      I think that you are looking for a way to express non-TCG defined
>      evidence containers.
> [NCW] I'm not sure why these object would be data-at-rest?  I view them as claims represented in specific structures, e.g. JWT/CWT
> But can be transported using any transport (e.g. TLS, et al)....similar to YANG?
> While it is true that the YANG draft also exposes the TPM interface, it also contains the claims albeit that are TPM specific.
> So perhaps you are referring to the interface aspect?
> 
> Best, Nancy
>      
>      
>      
>      
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> 