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

[Henk Birkholz <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>