Re: [Rats] yang tpm defining a datastore?

[Juergen Schoenwaelder <[e-mail]>]

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

On Fri, Feb 19, 2021 at 04:47:41PM +0000, Eric Voit (evoit) wrote:
> Hi Juergen,
> 
> > Juergen Schoenwaelder, February 19, 2021 8:22 AM
> > 
> > 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.
> 
> 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-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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > RATS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rats



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>