Subject: [Rats] yang tpm defining a datastore?

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2021 14:21:37 +0100

draft-ietf-rats-yang-tpm-charra-05 says:

   This document defines a YANG RPC and a minimal datastore required to
   retrieve attestation evidence about integrity measurements from a
   device following the operational context defined in TPM-based Network
   Device Remote Integrity Verification.

Does it define a datastore? To me, it seems the document defines a
data model but not a datastore.

   [I-D.ietf-rats-reference-interaction-models] document.  A fresh nonce
   with an appropriate amount of entropy MUST be supplied by the YANG
   client in order to enable a proof-of-freshness with respect to the
   attestation evidence provided by the attester running the YANG
   datastore.

The "YANG datastore"?

  container rats-support-structures {
    description
      "The datastore definition enabling verifiers or relying
       parties to discover the information necessary to use the
       remote attestation RPCs appropriately.";

I guess this is all just sloppy wording, it does not seem like you are
defining a datastore. Note that a schema element like a container can
be instantiated in several datastores, not just one.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2021 16:47:41 +0000

Hi Juergen,

> Juergen Schoenwaelder, February 19, 2021 8:22 AM
> 
> Does it define a datastore? To me, it seems the document defines a data
model
> but not a datastore.

There is a small datastore within this model.  Section 2.1.1.6:

   container <attester-supported-algos> - Identifies which TCG
   algorithms are available for use the Attesting platform.  This allows
   an operator to limit algorithms available for use by RPCs to just a
   desired set from the universe of all allowed by TCG.

   +--rw attester-supported-algos
      +--rw tpm12-asymmetric-signing*   identityref {taa:TPM12}?
      +--rw tpm12-hash*                 identityref {taa:TPM12}?
      +--rw tpm20-asymmetric-signing*   identityref {taa:TPM20}?
      +--rw tpm20-hash*                 identityref {taa:TPM20}?

It is these populated nodes where we could really use your help.   Basically
there are XPATH statements embedded in the model which are intended to
enforce that RPCs only use the <attester-supported-algos>.  I.e., the RPCs
will only accept values which the operator says are available from the
platform.   

Would you be willing to help us ensure these are correct?

Thanks,
Eric

> I guess this is all just sloppy wording, it does not seem like you are
defining a
> datastore. Note that a schema element like a container can be instantiated
in
> several datastores, not just one.
> 
> /js
> 
> --
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2021 18:18:54 +0100

The text in the I-D makes me believe you are defining configuration,
not a new datastore. I assume you talk about the server side (which I
assume to be the attester) and you want to configure that certain
attestation requests are rejected. If so, this is all regular
configuration and not a new datastore. (But it might also be that I do
not understand things right. But defining a new datastore is most
likely now whay you want to do.)

Note that not everything must be defined using XPATH. What is
important here is likely that it is well defined how the server reacts
and which failure code it returns if there is a mismatch.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 19 Feb 2021 17:43:16 +0000

> The text in the I-D makes me believe you are defining configuration, not a
new
> datastore. I assume you talk about the server side (which I assume to be
the
> attester) and you want to configure that certain attestation requests are
> rejected. If so, this is all regular configuration and not a new
datastore. (But it
> might also be that I do not understand things right. But defining a new
datastore
> is most likely now whay you want to do.)

It is true that there is not a completely new datastore.   The draft intends
to say new managed objects within the configuration datastore.   I will
update the text.

> Note that not everything must be defined using XPATH. What is important
here
> is likely that it is well defined how the server reacts and which failure
code it
> returns if there is a mismatch.

Having less XPATH would ease the complexity of the model.  When this goes to
WGLC, we can close with the YANG Doctors on what must be covered.

Eric
 
> > > data
> > enforce that RPCs only use the <attester-supported-algos>.  I.e., the
> > RPCs will only accept values which the operator says are available from
the