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

[Laurence Lundblade <[e-mail]>]

One more note on this. It seems wrong-headed to try express claims in YANG. To do that we’d need to invent a YANG signing standard (YOSE?). Seems like YANG should be thought of as RPC / conveyance / transport here, not as a way to format a signed attestation token. 

LL


> On Nov 11, 2019, at 11:47 AM, Laurence Lundblade <[e-mail]> wrote:
> 
> On Nov 10, 2019, at 9:20 PM, Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> 
>>> 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?
> 
> The EAT is an opaque chunk of data in YANG. I’m not a YANG expert, but maybe like this:
> 
> Server                               Device
> GetAttestationTypes —>
>                                 <- TYPE_TPM, TYPE_CWT /* bit flags */
> 
> GetAttestation(TYPE_CWT , nonce) —> 
>                                 <— CWT Token /* a full signed token */
> 
> I assume YANG can carry opaque binary data of moderate size.
> 
> The yang module information model would have an element for a nonce and for an opaque EAT. It would not describe any internals of the EAT. The information model for the EAT is separate in the EAT document.
> 
> LL
> 
>                                  
>