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

[Henk Birkholz <[e-mail]>]

On 12.11.19 10:44, Michael Richardson wrote:
>>>> 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
> 
> Those aren't EATs, those are attributes of claims that an EAT could include.
> If you are saying that we could write a YANG module describing those
> claims, and that they could be used to describe both claims of an EAT,
> but also results from a TPM 1.2/2.0 call, then I understand finally.

Yes, that is basically a way to phrase the question, I think.

Specialized questions are: do we need to do that? Do we want to do that? 
Is it technically okay to instead convey opaque EAT blobs via a YANG 
statement?

And yes, those are not EATs :-) I was referring to the information 
elements and their serialization (statements & Claims) above.

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