Re: [Rats] Review of draft-ietf-rats-yang-tpm-charra-21

["Tschofenig, Hannes" <[e-mail]>]

Hi Eric,

a few additional remarks below.

> # Section 1
>
> rolling hash is the incorrect term for how PCR values are generated.
> See
> https://en.w/
> ikipedia.org%2Fwiki%2FRolling_hash&data=05%7C01%7Channes.tschofenig%40
> siemens.com%7C3242edddd4084109beee08dba7edfe77%7C38ae3bcd95794fd4addab
> 42e1495d55a%7C1%7C0%7C638288412848914945%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2FvLvBh7ZIyQ4NOW18K%2F7TrOgNramZLRZ0rWTfjqGDQ%3D&reserved=0 for a definition of how a rolling hash works. You would use a rolling hash in creating a transcript hash for TLS when you do not want to maintain a copy of the entire message exchange transcript.

Both are needed.  The sequential series of messages is recorded in the logs.
And the PCR (maintained in protected hardware) is the hash this sequential
series of entries.   It is this hash which allow you to verify the
completeness/accuracy of the log entries.


[Hannes] Thanks for the clarification.

> # Section 2 The YANG Module for Basic Remote Attestation Procedures
>
> What does "Basic" refer to? Is there a "sophisticated" or "advanced"
> version somewhere else? If not, omit the term "basic".

There are advanced versions.  For an example, see:
draft-voit-rats-trustworthy-path-routing
which is an instance of nested attestations as described in draft-ietf-rats-ar4si Section 3.2

[Hannes] A reader might not understand this distinction without this extra information.

> You write:
> "
> The method for communicating the relationship of each individual TPM
> to specific measured component within the Composite Device is out of
> the scope of this document.
> "
>
> Is this functionality described in some other document? If so, where
> is it described? If not, what is the implication: what am I unable to do?

You need an out-of-band provisioning mechanism which lets you know the type of cryptoprocessor, the equipment within which it sits, and its public key.
This document does not describe this because these elements of business context are inherited from the companion document:
draft-ietf-rats-tpm-based-network-device-attest

[Hannes] It could be useful for the reader to have a pointer to this other document.

> 2.1.1.3.2. 'tpm20-challenge-response-attestation'
>
> Example is not really an example. Here is a snippet:
>
>     <certificate-name
>         xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
>         (instance of Certificate name in the Keystore)
>     </certificate-name>
>
> Could you include an example with real values? Should be easy for you
> to copy-and-paste an example from one of your implementations. It
> would also be good to have examples for the other functionality as
> well. Readers, like me, like examples. In this specific case I am
> interested to see how the certificate identification looks like.

If you look at the authoritative YANG draft "draft-ietf-netconf-keystore"
instance data in Section 3 it would be "Manufacturer-Generated IDevID Cert"
which is less descriptive than what we have now.   This is because the
instance data is just a reference to the full set of key info described throughout "draft-ietf-netconf-keystore".  Trying to keep the documents as independent is traditional with yang models so that we don't have to worry about keeping instance data in synch across a large number of drafts.

[Hannes] Looking at the YANG draft "draft-ietf-netconf-keystore" I can see that the certificate-name is essentially a string without any structure.

> 2.1.1.5. Data Nodes
>
> You use the term "compute node" several times throughout the document
> but it is not defined. Is there a definition you can reference?

The compute node is defined in the YANG model, which itself references RFC6933

[Hannes] OK. I wasn't aware of this.

Thanks for responding to my comments.

Ciao
Hannes