[Rats] Benjamin Kaduk's No Objection on draft-ietf-rats-yang-tpm-charra-17: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-rats-yang-tpm-charra-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I know that there is still a fair amount of editing effort underway, and
so am not concerned that some of my comments from the -16 remain
unaddressed.  I will try to repeat them here along with a handful of new
comments, while posting an updated ballot position with the primary goal
of removing my DISCUSS.

Many thanks for adding the appendices, they really help lay out how the
pieces fit together in a way that the external references used in the
-16 couldn't.

With regards to my previous discuss point (3), it seems that [ima-log]
still points ot the TCG "canonical event log" document with no mention
of Linux IMA.
Also, the string "netequip-boot-log" still appears in a YANG description
(where it can't be an xml2rfc reference) pointing to the linux IMA docs;
presumably we'd want it to point to Appendix B of [this RFC].

       leaf event-number {
         type uint32;
         description
           "Unique event number of this event which monotonically
            increases. [...]

I think we should say "within a given even log", maybe at the end of
this sentence.

       leaf-list event-data {
         type binary;
         description
           "The event data size determined by event-size. For more
            see ";

I think there was a botched edit here.

     grouping ima-event {
       description
         "Defines an hash log extend event for IMA measurements";
       reference
         "ima-log:
          https://www.trustedcomputinggroup.org/wp-content/uploads/
          TCG_IWG_CEL_v1_r0p30_13feb2021.pdf  Section 4.3";

Is section 4.3 the best section to reference?  I only see specifics
about,
e.g., the hash algorithm being encoded as a string later on, circa
§5.1.6.

       leaf filename-hint {
         type string;
         description
           "File that was measured";

Is this just the file name, a full path, either, ...?

     identity TPM_ALG_SYMCIPHER {
       if-feature "tpm20";
       base tpm20;
       base symmetric;
       description
         "Object type for a symmetric block cipher";

Thanks for adding "base symmetric".  Please confirm that "base
object_type" is not needed (as I thought I saw it in the TCG doc).

NITS

Section 1

   to retrieve attestation Evidence.  This is done by using a YANG RPC
   to request a quote which exposes a rolling hash the security
   measurements held internally within the TPM.

"rolling hash of"

  Appendix B.  IMA for Network Equipment Boot Logs

  Network equipment can generally implement similar IMA-protected
  functions to generate measurements (Claims) about the boot process of
  a device and enable corresponding remote attestation.  Network
  Equipment Boot Logs combine the measurement and logging of boot
  components and operating system components (executables and files)
  into a single log file in identical IMA format.

"single log file in a format identical to the IMA format"