A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs
draft-ietf-rats-yang-tpm-charra-22

Request for posting confirmation emailed to previous authors: Bill Sulzen , Eric Voit , Guy Fedorkow , Henk Birkholz , Liang Xia , Michael Eckel , Shwetha Bhandari , Tom Laffey , rats-chairs@ietf.org

[Ballot comment]
Discuss level issues resolved.

3 points to close on before final approval:
- I still need to close one of the issues with Eric regarding the config handling (just to ensure that the draft is clear).

- I would also like to check the YANG warnings that are being flagged to understand if they are tooling or model issues which need to be fixed.

- I would also like to see an ack from Jan if he hasn't already done so after his review, but can chase if needed.

[Ballot comment]
Discuss level issues resolved.

3 points to close on before final approval:
- I still need to close one of the issues with Eric regarding the config handling (just to ensure that the draft is clear).
- I would also like to check the YANG warnings that are being flagged to understand if they are tooling or model issues which need to be fixed.
- I would also like to see an ack from Jan if he hasn't already done so after his review, but can chase if needed.

[Ballot comment]
Discuss level issues resolved:

3 points to close on before final approval:
- I still need to close one of the issues with Eric regarding the config handling (just to ensure that the draft is clear).
- I would also like to check the YANG warnings that are being flagged to understand if they are tooling or model issues which need to be fixed.
- I would also like to see an ack from Jan if he hasn't already done so after his review, but can chase if needed.

[Ballot comment]
I will echo Lars' concern about the number of authors on this document.  The guideline is five; is there a good reason we need to list eight here?

I also concur with Francesca's points about "at this moment", etc. (specifically, her points 3, 7, and 10).

[Ballot 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"

Request for posting confirmation emailed to previous authors: Bill Sulzen , Eric Voit , Guy Fedorkow , Henk Birkholz , Liang Xia , Michael Eckel , Shwetha Bhandari , Tom Laffey , rats-chairs@ietf.org

[Ballot discuss]
Hi,

Thanks for the document, and apologies for the late discuss ballot.  I have a few discuss level concerns that I believe should be discussed, and if necessary addressed before publication:

(1) I would like to understand why some leaves (e.g., TPMS_QUOTE_INFO) are in all caps rather than following the YANG convention of being lowercase.  Please see section 4.3.1 of RFC 8407.

(2) I think that the "must" statements for tmp20-hash-algo and tpm12-hash-algo may not achieving what you want for two reasons:
(i) They never actually compare against the leaf value that is being set.
(ii) They require that tpm:rats-support-structures/tpm:attester-supported-algos/tpm:tpm12-hash is always populated in configuration, whereas the descriptive text is suggesting that the supported-algos is optional to provide and you should only be checking against it if is has been configured.
(iii) It was unclear to me if attester-supported-algos is only ever populated via configuration, or if no configuration has been provided then the platform will provide default operational values?  It is worth nothing that different trees of data (e.g., configuration vs operational) are available depending on whether the must statement is being evaluated in the context of a config operation (uses the config tree) or an RPC (which uses the state tree).

(3) To fix the YANG error mentioned in Warren's discuss, keystore-ref needs an if-feature "ks:asymmetric-keys".  I.e., because the leafref points to something that is conditional on an if-feature, the referring node must also be conditional on the same if-feature.

(4) I really dislike "last-entry-value", type binary, to act as an input parameter to specifying the starting point to return the logs from. Since structured YANG is defined/returned for these log entries, then I think that defining what this data is in binary is likely to be underspecified.  I would encourage you to just drop this as an option, given that every log message has a unique id and that can just as easily be provided, and probably more efficiently used.

[Ballot comment]
Reformatting the yang file (e.g., using pyang) would have slightly helped reviewing and readability (but the RFC editor will do this).  However, I'm not sure whether all of the tree diagrams are completely up to date and accurate, so it might be worth regenerating them after any markups to the YANG files are have been done to ensure that they are right.


  "This type is used to reference a hardware node.  It is quite
  possible this leafref will eventually point to another YANG
  module's node.";

Ben has already comment on this, but I presume that this description is now wrong?

  grouping tpm20-hash-algo {
    description
      "The cryptographic algorithm used to hash the TPM2 PCRs.  This
      must be from the list of platform supported options.";
    leaf tpm20-hash-algo {
      type identityref {
        base taa:hash;
      }
      must '/tpm:rats-support-structures/tpm:attester-supported-algos'
        + '/tpm:tpm20-hash' {

As per the discuss, I think that this "must" needs to look something more like:
    (. == ) or !)
    where  is /tpm:rats-support-structures/tpm:attester-supported-algos/tpm:tpm20-hash

I'm not a total expert on XPath, so it might be worth asking on NETMOD or YANG doctors to confirm that these expressions are correct, and it may depend on whether or not you expect default operational values to be provided by the system if it hasn't been configured.

        description
          "A cryptographically generated random number which should
            not be predictable prior to its issuance from a random
            number generation function. The random number MUST be
            derived from an entropy source external to the Attester.

            Note that a nonce sent into a TPM will typically be 160 or 256
            binary digits long.  (This is 20 or 32 bytes.) So if fewer
            binary are sent, this nonce object will be padded
            with leading zeros any in Quotes returned from the TPM.
            Additionally if more bytes are sent, the nonce will be trimmed
            to the most significant binary digits.";

Unclear what is meant by "any in Quotes".  Also "fewer binary" => "fewer binary digits".

            "Answers the question: is this TPM is a hardware based
            TPM?";

I think that this description could be worded more directly.

grouping ima-event-log {
    description
      "Measurement log created by IMA.";
    list ima-event-entry {
      key event-number;
      description
      "Ordered list of ima event logs by event-number";
      uses ima-event;
    }
  }

Formatting the file would help.

    leaf event-number {
      type uint32;
      description
        "Unique event number of this event";
    }
Is the event-number expected to be monotonically increasing, if so, should that be stated.  It is allowed to wrap, and if so what is the expected behaviour.  I also note that event-number is only uint32 for the BIOS logs, compared to uint64 the other logs, is that intentional?


  leaf-list event-data {
      type uint8;
      description
        "The event data size determined by event-size";
    }
  }

I think that Ben also raised this, but I wasn't sure why you are not just using a String, or binary here.  If it is binary, then what encoding is being used?

  'TPMs': Indicates that multiple TPMs on the device can support remote attestation. This feature is applicable in cases where multiple line cards are present, each with its own TPM.

I think that Ben has already recommended a better name for this feature (which I agree with).

      +---x log-retrieval
          +---w input
          |  +---w log-selector* []
          |  |  +---w name*                      string
          |  |  +---w (index-type)?
          |  |  |  +--:(last-entry)
          |  |  |  |  +---w last-entry-value?    binary
          |  |  |  +--:(index)
          |  |  |  |  +---w last-index-number?  uint64
          |  |  |  +--:(timestamp)
          |  |  |    +---w timestamp?          yang:date-and-time
          |  |  +---w log-entry-quantity?        uint16
          |  +---w log-type        identityref

I think that structure would be better if log-type was first, before the log-selector, but I actually think that it would be cleaner to model this as three separate RPCs for the three log types, and you can put each RPC under a different if-feature statement, which means that the choice statement for the returned data disappears.

I also think that the there should be more text about how multiple entries in the log-selector, each of which can specify multiple names play together.  I.e., I presume that for a request, a given name should only turn up once?

Regards,
Rob

[Ballot comment]
Thanks for this document.

I have also noticed similar reference anomalies in this document like Benjamin kaduk did. For example - I could not find "ietf-basic-remote-attestation" module. Hence supporting his discuss.

Don't we need to resolve the 2 YANG validation errors?

[Ballot discuss]
The YANG linter errors with:
err : Leafref is not conditional based on "asymmetric-keys" feature as its target. (/ietf-tpm-remote-attestation:rats-support-structures/tpms/tpm/certificates/certificate/keystore-ref)
err : Module "ietf-tpm-remote-attestation" parsing failed."

This appears to be a different error to what DISCUSSed in #1, and is also different to the lint errors in the Shepherd Writeup (https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/shepherdwriteup/)
I started trying to debug this, but ran out of time.

[Ballot comment]
Thank you for the work on this document

Thank you to Nancy Cam-Winget for noting in the shepherd write up that the YANG errors in the DT validation are a bug of the tool - however since the shepherd write up was last updated 6 months ago and the last YANG Doctors review was 9 versions ago, I'd like a confirmation from Roman and/or the authors that the bug is still actual and the two YANG validation errors are not relevant.

I have some minor comments below. I'll appreciate answers to them and I hope they help improve the document.

Francesca

1. -----

FP: Please expand TPM on first use.

2. -----

(_TPM Quote_ primitive operation)

FP: it is unclear where this terminology comes from ( _TPM Quote_ operation or primitive operation, but also _TPM PCR Extend_)

3. -----

At this point 0-31 is viable.

FP: I do not think "at this point" is a valid way to put that ranges could be expanded. It makes me wonder how and what's the motivation for the current restriction, as well as the process behind a possible expansion. If the community sees a need for a future range expansion, why not describe that here.

4. -----

          It is quite
          possible this leafref will eventually point to another YANG
          module's node.

FP: would this YANG module be updated in that case? I think that if this text stays, it needs to be more detailed.

5. -----

            with leading zeros any in Quotes returned from the TPM.

FP: the end of this sentence does not parse for me.

6. -----

            Note that a nonce sent into a TPM will typically be 160 or 256
            binary digits long.  (This is 20 or 32 bytes.) So if fewer
            binary are sent, this nonce object will be padded
            with leading zeros any in Quotes returned from the TPM.
            Additionally if more bytes are sent, the nonce will be trimmed
            to the most significant binary digits.";

FP: How is the length decided if the nonce is shorter than 20 bytes long? Will it always be padded to 20 bytes or can it be padded to 32 bytes? Maybe adding a sentence about how the length is established can be useful here.

7. -----

          "The numbers/indexes of the PCRs. At the moment this is limited
            to 32.  In addition, any selection of PCRs MUST verify that

FP: Same comment than 3. "at the moment"

8. -----

    'unsigned-pcr-values'.  By comparing this information to the
            what has previously been validated, it is possible for a

FP: s/to the what/to what

9. -----

        an unsigned PCR value is actually that that within a quote.

FP: s/that that/that

10. -----

          e.g. smart NICs, is still a TODO.";

FP: Also the same comment as 3. - "still a TODO" seems like the wrong terminology to mean something out of scope or to be extended later.

11. -----

                  "Content of an log event which matches 1:1 with a

FP: s/an/a

12. -----

      "This module defines a identities for asymmetric algorithms.

FP: remove "a"

[Ballot discuss]
(1) Section 2 references the "ietf-basic-remote-attestation YANG module",
but that appears to be an older name for what got renamed to the
"ietf-tpm-remote-attestation" module at time of WG adoption.

(2) There are some issues with references, either pointing to the wrong
document or to a draft version of a specification when there is a final
version available.

(2.1) The YANG reference stanza for "feature ima" (in the
ietf-tpm-remote-attestation module) still refers to a draft version of the
Canonical Event Log specification.

(2.2) The YANG reference stanza for "grouping ima-event" (in the same
module) does the same.

(2.3) The PDF link in the description of "feature tpm20" (in the
ietf-tcg-algs YANG module) appears to point to a draft version of the
specification.  Since the link is to a 2011 version, I trust that the
final version is already available, and the fix is just to update the
link.

(2.4) The PDF link in the descriptions of all three "enum" values of
"leaf type" in "container certificates" in the ietf-tpm-remote-attestation
module points to a draft version of the TCG specification.

(2.5) The PDF link in the description of "feature tpm20" in the
ietf-tcg-algs YANG module points to a draft version of the TCG
specification.

(2.6) The description for "identity TPM_ALG_HMAC" in the ietf-tcg-algs
YANG module points to RFC 2014 as one reference, but HMAC is RFC 2104.

(2.7) The reference for [TPM2.0-Arch] links to a draft version of the
TCG specification.

(2.8) The reference for [TPM2.0-Key] links to a draft version of the TCG
specification.

(3) Some of the references don't seem to match up with their slugs --
e.g., [ima-log] seems to point to the TCB "canonical event log format" and
[netequip-boot-log] (and the YANG reference stanza for "feature
netequip_boot") points to what looks like a Linux IMA document.  While the
description in "grouping network-equipment-boot-event-log" does give some
indication that [netequip-boot-log] is intended to be very similar to the
IMA format, I don't think we can reasonably just directly reference the
IMA spec and call it [netequip-boot-log] without some additional
clarification either in the reference entry or where it is used.

[Ballot comment]
Section 2.1.1.1

  *  'TPMs': Indicates that multiple TPMs on the device can support
      remote attestation.  This feature is applicable in cases where
      multiple line cards are present, each with its own TPM.

It sounds like this is intending to emphasize "TPMs" as opposed to "TPM"
singular; making the plural 's' have semantic value seems to risk
confusion, and perhaps a "multi-tpm" feature name would be less
risk-prone.

Section 2.1.1.5

  Container 'rats-support-structures':  This houses the set of
      information relating to a device's TPM(s).

  Container 'tpms':  Provides configuration and operational details for
      each supported TPM, including the tpm-firmware-version, PCRs which

I believe that in the current YANG module, "tpms" is a child of
"rats-support-structures" (along with "compute-nodes" and
"attester-supported-algos"), which does not really seem very commensurate
with the prose summary here.

  +--rw tpms
      +--rw tpm* [name]
      [...]
        +--rw firmware-version    identityref
        +--rw tpm12-hash-algo?    identityref
        +--rw tpm12-pcrs*        pcr
        +--rw tpm20-pcr-bank* [tpm20-hash-algo]

It's fairly surprising that the firmware-version is writable, and I'm not
really sure what it means to have the set of pcrs be writable, either.

Section 2.1.1.6

    typedef pcr {
      type uint8 {
        range "0..31";
      }
      description
        "Valid index number for a PCR.  At this point 0-31 is viable.";

That's a fairly surprising description to see in a Proposed Standard.
If we are not sure that the range restriction will always be valid, should
we be enforcing it as part of the module?

    typedef compute-node-ref {
      type leafref {
        path "/tpm:rats-support-structures/tpm:compute-nodes"
            + "/tpm:compute-node/tpm:node-name";
      }
      description
        "This type is used to reference a hardware node.  It is quite
          possible this leafref will eventually point to another YANG
          module's node.";

Similarly here, I might expect the statement to be a caution to the reader
that they need to handle the case where it points to another YANG module's
node, rather than "it is quite possible" that such an eventuality might
occur.

    grouping tpm20-hash-algo {
    [...]
        default "taa:TPM_ALG_SHA256";
        description
          "The hash scheme that is used to hash a TPM1.2 PCR. This
            must be one of those supported by a platform.";

Is this description with "TPM1.2" really correct in the "tpm20-hash-algo"
grouping?

        default "taa:TPM_ALG_SHA1";
        description
          "The hash scheme that is used to hash a TPM1.2 PCR. This
            MUST be one of those supported by a platform.  This assumes
            that an algorithm other than SHA1 can be supported on some
            TPM1.2 cryptoprocessor variant.";

What exactly assumes that?  Use of a non-default value, perhaps?

    grouping nonce {
      description
        "A random number intended to be used once to show freshness
          and to allow the detection of replay attacks.";

"Show freshness" makes sense and seems intuitive.  Detecting replay
attacks seems like it would require some additional infrastructure (a
"replay cache", perhaps, ideally with some time-based aging out), about
which we say nothing.  Is this replay protection expected to be part of
the TPM chip itself, or on the composite device hosting the YANG server,
or somewhere else entirely?  It seems a bit disingenuous to suggest that
such functionality is possible while providing no pointers at all for how
to achieve it.

    grouping tpm12-pcr-selection {
      description
        "A Verifier can request one or more PCR values using its
          individually created Attestation Key Certificate (AC).
          The corresponding selection filter is represented in this
          grouping.
          Requesting a PCR value that is not in scope of the AC used,
          detailed exposure via error msg should be avoided.";

This last sentence seems to be missing a few words that are vital to the
meaning.

    grouping tpm12-pcr-selection {
      [...]
      leaf-list pcr-index {
        [...]
        description
          "The numbers/indexes of the PCRs. At the moment this is limited
            to 32.  In addition, any selection of PCRs MUST verify that

(A similar comment as above regarding "at the moment" and future-proofing
what goes into a Proposed Standard.)

    grouping tpm20-pcr-selection {
      [...]
      list tpm20-pcr-selection {
        unique "tpm20-hash-algo";

I confess to being only a YANG amateur, but am not really sure why the
"unique" qualifier is preferable to the "key" one in this case (and
several others later on, but I'll just mention this one).

    grouping tpm-name {
      description
        "A unique TPM on a device.";
      leaf name {
        type string;
        description
          "Unique system generated name for a TPM on a device.";

If it's system-generated would that imply config false?

      uses node-uptime;
      list unsigned-pcr-values {
        description
          [...]
            significant processing.  There should never be a result where
            an unsigned PCR value is actually that that within a quote.
            If there is a difference, a signed result which has been
            verified from retrieved logs is considered definitive.";

I'm not sure I understand this part -- is there a missing negation in the
first sentence?

    grouping boot-event-log {
      description
        "Defines a specific instance of an event log entry
          and corresponding to the information used to
          extend the PCR";
      leaf event-number {
        type uint32;
        description
          "Unique event number of this event";

Should we mention what scope the uniqueness is within?  (At only 32 bits
it cannot be globally unique.)

      leaf pcr-index {
        type pcr;
        description
          "Defines the PCR index that this event extended";
      }

Why is this not mandatory?

      leaf-list event-data {
        type uint8;
        description
          "The event data size determined by event-size";

Is there some missing punctuation or something here?  Otherwise the focus
on size seems strange, given that there is a separate "leaf event-size".
(Also, why is a leaf-list of uint8 better than "type binary"?)

    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, ...?

      leaf signature {
        type binary;
        description
          "The file signature";

Both this description and the reference for ima-event seem pretty sparse
on what the signature actually covers.

    rpc tpm20-challenge-response-attestation {
      if-feature "taa:tpm20";
      description
        "This RPC accepts the input for TSS TPM 2.0 commands of the
          managed device. ComponentIndex from the hardware manager YANG
          module to refer to dedicated TPM in composite devices,
          e.g. smart NICs, is still a TODO.";

I would prefer to not see "is still a TODO" in a Proposed Standard.
"Out of the scope of this specification" is seen much more often (though
in some sense it conveys much the same meaning...)

      container compute-nodes {
        [...]
        list compute-node {
          key "node-id";

If we're going to use "leaf node-name" for leafrefs, does that require a
uniqueness constraint on "node-name" here?

      container tpms {
        [...]
          leaf path {
            type string;
            config false;
            description
              "Path to a unique TPM on a device.  This can change across
                reboots.";

Is this a ... device-tree path?  Surely it is not a filesystem path,
right?

          leaf firmware-version {
            type identityref {
              base taa:cryptoprocessor;
            }
            mandatory true;
            description
              "Identifies the cryptoprocessor API set supported.  This
                is automatically configured by the device and should not
                be changed.";

(Per my previous comment on the tree diagram, "should not be changed"
strongly implies that it should be "config false" to me.  When might that
not be the case?)

      container attester-supported-algos {
        description
          "Identifies which TPM algorithms are available for use on an
            attesting platform.";
        [...]

Just to confirm I'm reading this properly: the lists herein are not scoped
to specific TPM instances, but are rather global to the entire composite
device; the "when" constraints just say that each leaf-list is only
present if there are any TPMs of the corresponding TPM version present but
do not otherwise limit the scope of applicability for the algorithms in
question?  That seems rather surprising, especially if one considers a
scenario where there are multiple line cards on a given device and one
could be hot-replaced to a newer model with a TPM that supports more
algorithms.  But perhaps I'm missing something.

Section 2.1.2.2

  3.  Specific algorithm types: Each algorithm type defines what
      cryptographic functions may be supported, and on which type of
      API specification.  It is not required that an implementation of
      a specific TPM will support all algorithm types.  The contents of
      each specific algorithm mirrors what is in Table 3 of
      [TCG-Algos].

This phrasing implies a strong sense of consistency between the two
documents.  I did not attempt to perform a rigorous verification of each
element between the two documents, but I hope someone has done so.

Section 2.1.2.3

    contact
      "WG Web: 
        WG List: 
        Author:  Eric Voit ";

Just to confirm: it's correct for Eric to be the only listed author for
this module (vs ietf-tpm-remote-attestation, that includes what appears to
be the whole author list of the I-D)?

    identity signing {
      description
        "A TCG recognized signing algorithm";
      reference
        "TCG-Algos:TCG Algorithm Registry Rev1.32  Table 2";

I understand a desire to remain consistent with what the TCG says, but
would we consider mentioning that this also includes symmetric crypto
"signing" operations?

    identity method {
      description
        "A TCG recognized method such as a mask generation function.";

Perhaps we want "cryptographic method" here, in light of the way the TCG
spec frames things.

    identity TPM_ALG_XOR {
      if-feature "tpm12 or tpm20";
      base tpm12;
      base tpm20;
      base hash;
      base symmetric;

I didn't see in the TCG Algorithm Registry Rev1.32 doc that indicated that
the "XOR encryption algorithm" derived from a hash.  Please confirm that
"base hash" is correct.

    identity TPM_ALG_SYMCIPHER {
      if-feature "tpm20";
      base tpm20;
      description
        "Object type for a symmetric block cipher";
      reference
        "TCG-Algos:TCG Algorithm Registry Rev1.32  Table 3 and
          TCG TPM 2.0 library specification. ALG_ID: 0x0025";

Is the lack of "base symmetric" correct?  (The algorithm registry doc
seems to list is as an "object" as well as symmetric.)
Also, I guess this is a tolerable place to ask why the "AES" alg is
specific to TPM 1.2.  I found mention of (e.g.) "AES128" in at least one
TPM 2.0 spec, so presumably I'm just missing how those algorithms are
represented in the TPM 2.0 model (and why symmetric ciphers are treated
differently than the different output lengths of the SHA2 and SHA3 family
of hash functions, which do get individual algorithm identities in this
YAND module).  Perhaps they use this TPM_ALG_SYMCIPHER!

Section 4

The YANG security considerations template has a section about readable
data nodes that are considered sensitive.  Does that apply to any of the
nodes in the modules defined by this document?

  Container '/rats-support-structures/attester-supported-algos':  'tpm1
      2-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-signing',
      and 'tpm20-hash'.  All could be populated with algorithms that are
      not supported by the underlying physical TPM installed by the
      equipment vendor.

We should say what the impact of that configuration would be at runtime.

  Container: '/rats-support-structures/tpms':  'name': Although shown
      as 'rw', it is system generated.  Therefore it should not be

Why is it shown as 'rw', then?

Also, separately, if we're going to keep 'firmware-version' as writable,
there seems to be some consideration there, as telling a TPM 2.0-only chip
to use TPM 1.2 is going to be a DoS.

      'certificates': It is possible to provision a certificate which
      does not correspond to an Attestation Identity Key (AIK) within
      the TPM 1.2, or an Attestation Key (AK) within the TPM 2.0
      respectively.

Could we have a sentence about the runtime impact of such a
misconfiguration?

  RPC 'tpm12-challenge-response-attestation':  It must be verified that
  [...]
  RPC 'tpm20-challenge-response-attestation':  It must be verified that

Must be verified by whom?  In order to achieve what property?

Section 6.1

  [ISO-IEC-9797-2]
              "Message Authentication Codes (MACs) - ISO/IEC
              9797-2:2011", n.d.,
              .

Following the link indicates that there's a 2021 revision available; do we
need the older version specifically?


NITS

Section 2.1.1.1

  *  'TPMs': Indicates that multiple TPMs on the device can support
      remote attestation.  This feature is applicable in cases where
      multiple line cards are present, each with its own TPM.

An "e.g." or "for example" seems appropriate here.

Section 2.1.1.6

        description
          "Name of one or more unique TPMs on a device.  If this object
            exists, a selection should pull only the objects related to
            these TPM(s).  If it does not exist, all qualifying TPMs that
            are 'hardware-based' equals true on the device are selected.";

I think s/are/have/ would make sense.

    grouping tpm20-attestation {
      description
        "Contains an instance of TPM2 style signed cryptoprocessor
          measurements.  It is supplemented by unsigned Attester
          information.";
      leaf TPMS_QUOTE_INFO {
        type binary;
        mandatory true;
        description
          "A hash of the latest PCR values (and the hash algorithm used)
            which have been returned from a Verifier for the selected PCRs
            and Hash Algorithms.";
        reference
          "TPM2.0-Structures:
            https://www.trustedcomputinggroup.org/wp-content/uploads/
            TPM-Rev-2.0-Part-2-Structures-01.38.pdf  Section 10.12.1";

The reference appeears to include two sections marked 10.12.1(!), though
clearly we do not want the one entitled "introduction".

      leaf filedata-hash {
        type binary;
        description
          "Hash of filedata";

It is perhaps banal, but mentioning that the interpretation is controlled
by the filedata-hash-algorithm might be useful.

    rpc tpm12-challenge-response-attestation {
      [...]
      input {
        container tpm12-attestation-challenge {
          [...]
          leaf-list certificate-name {
            if-feature "tpm:tpms";
            type certificate-name-ref;
            must "/tpm:rats-support-structures/tpm:tpms"
                + "/tpm:tpm[tpm:firmware-version='taa:tpm12']"
                + "/tpm:certificates/"
                + "/tpm:certificate[name=current()]" {
              error-message "Not an available TPM1.2 AIK certificate.";

This is the first instance of "AIK" in the document (it does not appear in
the prose until the security considerations).  Perhaps it should get
mentioned in the Introduction as another term inported from TPM2.0-key?

    rpc tpm20-challenge-response-attestation {
      if-feature "taa:tpm20";
      description
        "This RPC accepts the input for TSS TPM 2.0 commands of the
          managed device. ComponentIndex from the hardware manager YANG
          module to refer to dedicated TPM in composite devices,
          e.g. smart NICs, is still a TODO.";

The second sentence seems to be missing a verb.

      output {
        list tpm20-attestation-response {
          unique "certificate-name";
          description
            "The binary output of TPM2b_Quote in one TPM chip of the
              node which identified by node-id. [...]

Does "chip" imply hardware chip, which is perhaps more specific than the
introductory materials indicated to be the scope of applicability?

    container rats-support-structures {
      container compute-nodes {
        if-feature "tpm:tpms";
        description
          "Holds the set device subsystems/components in this composite
            device that support TPM operations.";

"set of"

          leaf status {
            type enumeration {
              enum operational {
                value 0;
                description
                  "The TPM currently is currently running normally and
                    is ready to accept and process TPM quotes.";
                reference
                  "TPM2.0-Arch:
                    TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf
                    Section 12";

Huh, why is this not an https URI?

          container certificates {
            description
              "The TPM's certificates, including EK certificates
                and AK certificates.";

While we're expanded LAK and IAK previously, we haven't expanded just "AK"
itself yet.

Section 2.1.2.3

    organization
      "IETF RATS Working Group";

Do we want to use the same spelling as in the ietf-tpm-remote-attestation
module?

    identity tpm12 {
      if-feature "tpm12";
      base cryptoprocessor;
      description
        "Supportable by a TPM1.2.";
      reference
        "TPM1.2-Structures:
          https://trustedcomputinggroup.org/wp-content/uploads/
          TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
          TPM_ALGORITHM_ID values, page 18";

We referenced it as section 4.8 (vs page 18) for the YANG "feature"
stanza.

    identity tpm20 {
      if-feature "tpm20";
      base cryptoprocessor;
      description
        "Supportable by a TPM2.";
      reference
        "TPM2.0-Structures:
          https://trustedcomputinggroup.org/wp-content/uploads/
          TPM-Rev-2.0-Part-2-Structures-01.38.pdf
          The TCG Algorithm Registry. Table 9";

Is table 9 the right reference?

    identity TPM_ALG_SM4 {
      if-feature "tpm20";
      base tpm20;
      base symmetric;
      description
        "SM4 symmetric block cipher";
      reference
        "TCG-Algos:TCG Algorithm Registry Rev1.32  Table 3.
        ALG_ID: 0x0013";

Isn't SM4 an ISO standard now as well?

    identity TPM_ALG_RSASSA {
      if-feature "tpm20";
      base tpm20;
      base asymmetric;
      base signing;
      description
        "Signature algorithm defined in section 8.2 (RSASSAPKCS1-v1_5)";
      reference
        "TCG-Algos:TCG Algorithm Registry Rev1.32  Table 3 and
        RFC 8017.  ALG_ID: 0x0014";
    }

    identity TPM_ALG_RSAES {
      if-feature "tpm20";
      base tpm20;
      base asymmetric;
      base encryption_mode;
      description
        "Signature algorithm defined in section 7.2 (RSAES-PKCS1-v1_5)";

I think you need to say what document the section numbers are from, since
two references are listed in the reference stanza.

    identity TPM_ALG_ECDH {
      if-feature "tpm20";
      base tpm20;
      base asymmetric;
      base method;
      description
        "Secret sharing using ECC";
      reference
        "TCG-Algos:TCG Algorithm Registry Rev1.32  Table 3 and
          NIST SP800-56A and RFC 7748. ALG_ID: 0x0019";

RFC 7748 is specific to the so-called "CFRG curves"; is it really the
right reference for generic ECDH?

[Ballot comment]
The document has 8 authors, which exceeds the recommended author limit. I
assume the sponsoring AD has agreed that this is appropriate?

DOWNREF from this Standards Track doc to [netequip-boot-log].
[netequip-boot-log] seems to be a Linux kernel README, which I have
a hard time accepting as a non-IETF standards document.

DOWNREF from this Standards Track doc to [yang-parameters]. This could become
and informational reference, since the defining RFC6020 is normatively cited.

DOWNREF from this Standards Track doc to [xml-registry]. This could become
and informational reference, since the defining RFC3688 is normatively cited.

Thanks to Roni Even for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/LVJgDXJ4Bwr2DuJ2ytGxONSTSQ8).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

"RATS ", paragraph 1, nit:
> cument defines YANG RPCs and a small number of configuration nodes required
>                              ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some".

Section 2. , paragraph 2, nit:
> tion 2.1.2.3 with prefix 'taa'. Additionally references are made to [RFC8032
>                                ^^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Additionally".

Section 2.1.1.5. , paragraph 19, nit:
> n Quotes returned from the TPM. Additionally if more bytes are sent, the non
>                                ^^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Additionally".

Section 2.1.1.5. , paragraph 34, nit:
> By comparing this information to the what has previously been validated, it
>                                  ^^^^^^^^
Did you mean "what"?

Section 2.1.1.5. , paragraph 35, nit:
> an unsigned PCR value is actually that that within a quote. If there is a dif
>                                  ^^^^^^^^^
Possible typo: you repeated a word.

Section 2.1.1.5. , paragraph 36, nit:
> ing ima-event { description "Defines an hash log extend event for IMA measur
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.1.1.5. , paragraph 43, nit:
> type binary; description "Content of an log event which matches 1:1 with a u
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.1.1.5. , paragraph 43, nit:
> ned within the log. Log entries subsequent to this will be passed to the requ
>                                ^^^^^^^^^^^^^
Consider using "after".

Section 2.1.1.5. , paragraph 43, nit:
> e beginning of the log. Entries subsequent to this will be passed to the requ
>                                ^^^^^^^^^^^^^
Consider using "after".

Section 2.1.1.5. , paragraph 43, nit:
> extraction. The next log entry subsequent to this timestamp is to be sent.";
>                                ^^^^^^^^^^^^^
Consider using "after".

Section 2.1.1.5. , paragraph 44, nit:
> ue 0; description "The TPM currently is currently running normally and is re
>                            ^^^^^^^^^^^^^^^^^^^^^^
Adverb repetition.

Section 2.1.1.5. , paragraph 48, nit:
> escription "This module defines a identities for asymmetric algorithms. Copy
>                                ^^^^^^^^^^^^
The plural noun "identities" cannot be used with the article "a". Did you mean
"a identity" or "identities"?

Section 2.1.1.5. , paragraph 50, nit:
> ficient cryptographic protection. However it is still useful for hash algori
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 2.1.2.3. , paragraph 5, nit:
> ietf-tpm-remote-attestation.yang. However the full definition of Table 3 of
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 2.1.2.3. , paragraph 13, nit:
> as 'rw', it is system generated. Therefore it should not be possible for an
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 2.1.2.3. , paragraph 18, nit:
> ulnerabilities on those systems. Therefore RPCs should be protected by NACM
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

These URLs in the document can probably be converted to HTTPS:
* http://trustedcomputinggroup.org/resource/tcg-algorithm-registry/TCG-_Algorithm_Registry_r1p32_pub

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-rats-yang-tpm-charra-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-tpm-remote-attestation
URI: urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-tcg-algs
URI: urn:ietf:params:xml:ns:yang:ietf-tcg-algs
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-tpm-remote-attestation
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation
Prefix: tpm
Module:
Reference: [ RFC-to-be ]

Name: ietf-tcg-algs
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-tcg-algs
Prefix: taa
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-01-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-rats-yang-tpm-charra@ietf.org, nancy.winget@gmail.com, ncamwing@cisco.com, rats-chairs@ietf.org, rats@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs) to Proposed Standard


The IESG has received a request from the Remote ATtestation ProcedureS WG
(rats) to consider the following document: - 'A YANG Data Model for
Challenge-Response-based Remote Attestation
  Procedures using TPMs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-01-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines YANG RPCs and a small number of configuration
  nodes required to retrieve attestation evidence about integrity
  measurements from a device, following the operational context defined
  in TPM-based Network Device Remote Integrity Verification.
  Complementary measurement logs are also provided by the YANG RPCs,
  originating from one or more roots of trust for measurement (RTMs).
  The module defined requires at least one TPM 1.2 or TPM 2.0 as well
  as a corresponding TPM Software Stack (TSS), included in the device
  components of the composite device the YANG server is running on.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-rats-tpm-based-network-device-attest: TPM-based Network Device Remote Integrity Verification (None - Internet Engineering Task Force (IETF))
    draft-ietf-rats-architecture: Remote Attestation Procedures Architecture (None - Internet Engineering Task Force (IETF))

Shepherd writeup for draft-ietf-rats-yang-tpm-charra and draft-ietf-rats-tpm-based-network-device-attest

1. Summary
This publication request covers two related drafts for enabling Remote Attestations on devices that contain TPMs:
- draft-ietf-rats-tpm-based-network-device-attest: is submitted to be published as an informational RFC as it describes the profile or workflow for affecting a TPM based remote attestation
- draft-ietf-rats-yang-tpm-charra: is submitted to be published as a standards RFC as it defines the Yang Data model for enabling a challenge-response remote attestation using TPMs
As the draft-ietf-rats-tpm-based-network-device-attest provides an overview and guidance for affecting TPM based remote attestations it depends on the  draft-ietf-rats-yang-tpm-charra draft; as such, they are submitted together with their intended status also indicated in their title page headers.


2. Document Announcement Write-up

Technical Summary:

A Yang RPCs and configuration nodes are defined in draft-ietf-rats-yang-tpm-charra (aka “charra”) to facilitate the retrieval of attestation evidence about integrity measurements from a device on TPM based devices.  The workflow and guidance for enabling remote integrity verifications on these TPM based devices are further described in draft-ietf-rats-tpm-based-network-device-attest.

Working Group Summary:

These documents were one of the first set of adopted and working group documents, with salient discussions to mature both specifications.  In addition, the “charra” draft received both early and WGLC Yang doctor review to ensure it was following appropriate norms and conventions all comments received have been addressed.

Document Quality:
Both documents are well written and has gone through working group review as well as external (TCG participant) reviews.  The YANG module definitions have gone through both early and WGLC Yang doctor review.



Personnel:
Nancy Cam-Winget is the Document Shepherd
Roman Danyliw is the responsible Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I have reviewed both documents throughout the comment review period and reached out to the Yang Doctors mail list to solicit review and follow up.  At this time, both documents have received solid review with all comments addressed, some interoperability implementations have also occurred to mature the document to its current state.  I believe the documents are now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
The only review needed was for the Yang modules which has been reviewed by both the working group as well as the Yang Doctors representative (Mahesh Jethanandani).

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
All authors for draft-ietf-rats-tpm-based-network-device-attest have asserted no knowledge of IPR. The main authors for the draft-ietf-rats-yang-tpm-charra have disclosed that they are not aware of any IPR issues; one of the authors (Frank Xia) has since moved on from focusing on this document and has not responded.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No disclosures for either drafts have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
There was strong consensus that both of these drafts are ready for publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There are 4 warnings in draft-ietf-rats-tpm-based-network-device-attest-08 : these are due to document referencing an array that the idnits tool is confusing as a reference.  The document also includes informative references to drafts that are still under construction and thus the revisions are not updated.

There are 3 errors in draft-ietf-rats-yang-tpm-charra-10.txt : as the document includes references to the network device attestation draft that is being requested to publish at the same time.  It is also referencing an informational draft (the RATS Architecture) which is continuously being revised and has also completed WGLC and should be going to IESG for publication request soon.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The draft-ietf-rats-tpm-based-network-device-attest does not have any such requirements.
The draft-ietf-rats-yang-tpm-charra has undergone YANG Doctor review both prior to WGLC and as part of the WGLC, comments were received and addressed in both reviews.
The datatracker tools shows lint errors that is actually due to a bug in Yanglint itself for which a ticket was opened (https://github.com/CESNET/libyang/issues/1674) and resolved with the note that the yangvalidator is still using an older version of yanglint.


(13) Have all references within this document been identified as either normative or informative?
Yes. 

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
These two drafts are being packaged together as the “network device attestation” draft is a profile guide for affecting remote attestations using the “CHARRA” draft, so there are references to these drafts that can be addressed as they’re packaged together.
They also reference the draft-ietf-rats-architecture and draft-ietf-rats-reference-interaction-models which are informational drafts that may not push to publication until the standards based specifications (such as “CHARRA”) mature and publish first; this was the working group’s decision to ensure that the RATs overview for how components “fit” (e.g. in the architecture) and how they flow together (e.g. interaction model) go together.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are two drafts, one of which is interdependent and is packaged to publish at the same time (e.g. draft-ietf-rats-tpm-based-network-device-attest) .
The second draft, draft-ietf-rats-architecture has also completed WGLC and is expected to go to IESG request to publish sometime soon.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
I have reviewed the request for IANA assignments that they look to comply with both the XML (RFC3688) and Yang parameter registries (RFC 6020).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
The registry requests are for the XML namespace for TPM based remote attestation and its crypto algorithms.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
I have performed both the IDNits and the Yang verification tools and provided my findings.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The Yang Doctor (Mahesh) has done a thorough review, the “charra” draft actually found a bug in the lint tool for which a ticket was opened.  I have run  https://yangcatalog.org/yangvalidator/validator against the draft and see no errors.

Shepherd writeup for draft-ietf-rats-yang-tpm-charra and draft-ietf-rats-tpm-based-network-device-attest

1. Summary
This publication request covers two related drafts for enabling Remote Attestations on devices that contain TPMs:
- draft-ietf-rats-tpm-based-network-device-attest: is submitted to be published as an informational RFC as it describes the profile or workflow for affecting a TPM based remote attestation
- draft-ietf-rats-yang-tpm-charra: is submitted to be published as a standards RFC as it defines the Yang Data model for enabling a challenge-response remote attestation using TPMs
As the draft-ietf-rats-tpm-based-network-device-attest provides an overview and guidance for affecting TPM based remote attestations it depends on the  draft-ietf-rats-yang-tpm-charra draft; as such, they are submitted together with their intended status also indicated in their title page headers.


2. Document Announcement Write-up

Technical Summary:

A Yang RPCs and configuration nodes are defined in draft-ietf-rats-yang-tpm-charra (aka “charra”) to facilitate the retrieval of attestation evidence about integrity measurements from a device on TPM based devices.  The workflow and guidance for enabling remote integrity verifications on these TPM based devices are further described in draft-ietf-rats-tpm-based-network-device-attest.

Working Group Summary:

These documents were one of the first set of adopted and working group documents, with salient discussions to mature both specifications.  In addition, the “charra” draft received both early and WGLC Yang doctor review to ensure it was following appropriate norms and conventions all comments received have been addressed.

Document Quality:
Both documents are well written and has gone through working group review as well as external (TCG participant) reviews.  The YANG module definitions have gone through both early and WGLC Yang doctor review.



Personnel:
Nancy Cam-Winget is the Document Shepherd
Roman Danyliw is the responsible Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I have reviewed both documents throughout the comment review period and reached out to the Yang Doctors mail list to solicit review and follow up.  At this time, both documents have received solid review with all comments addressed, some interoperability implementations have also occurred to mature the document to its current state.  I believe the documents are now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
The only review needed was for the Yang modules which has been reviewed by both the working group as well as the Yang Doctors representative (Mahesh Jethanandani).

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
All authors for draft-ietf-rats-tpm-based-network-device-attest have asserted no knowledge of IPR. The main authors for the draft-ietf-rats-yang-tpm-charra have disclosed that they are not aware of any IPR issues; one of the authors (Frank Xia) has since moved on from focusing on this document and has not responded.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No disclosures for either drafts have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
There was strong consensus that both of these drafts are ready for publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There are 4 warnings in draft-ietf-rats-tpm-based-network-device-attest-08 : these are due to document referencing an array that the idnits tool is confusing as a reference.  The document also includes informative references to drafts that are still under construction and thus the revisions are not updated.

There are 3 errors in draft-ietf-rats-yang-tpm-charra-10.txt : as the document includes references to the network device attestation draft that is being requested to publish at the same time.  It is also referencing an informational draft (the RATS Architecture) which is continuously being revised and has also completed WGLC and should be going to IESG for publication request soon.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The draft-ietf-rats-tpm-based-network-device-attest does not have any such requirements.
The draft-ietf-rats-yang-tpm-charra has undergone YANG Doctor review both prior to WGLC and as part of the WGLC, comments were received and addressed in both reviews.
The datatracker tools shows lint errors that is actually due to a bug in Yanglint itself for which a ticket was opened (https://github.com/CESNET/libyang/issues/1674) and resolved with the note that the yangvalidator is still using an older version of yanglint.


(13) Have all references within this document been identified as either normative or informative?
Yes. 

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
These two drafts are being packaged together as the “network device attestation” draft is a profile guide for affecting remote attestations using the “CHARRA” draft, so there are references to these drafts that can be addressed as they’re packaged together.
They also reference the draft-ietf-rats-architecture and draft-ietf-rats-reference-interaction-models which are informational drafts that may not push to publication until the standards based specifications (such as “CHARRA”) mature and publish first; this was the working group’s decision to ensure that the RATs overview for how components “fit” (e.g. in the architecture) and how they flow together (e.g. interaction model) go together.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There are two drafts, one of which is interdependent and is packaged to publish at the same time (e.g. draft-ietf-rats-tpm-based-network-device-attest) .
The second draft, draft-ietf-rats-architecture has also completed WGLC and is expected to go to IESG request to publish sometime soon.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
I have reviewed the request for IANA assignments that they look to comply with both the XML (RFC3688) and Yang parameter registries (RFC 6020).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
The registry requests are for the XML namespace for TPM based remote attestation and its crypto algorithms.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
I have performed both the IDNits and the Yang verification tools and provided my findings.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
The Yang Doctor (Mahesh) has done a thorough review, the “charra” draft actually found a bug in the lint tool for which a ticket was opened.  I have run  https://yangcatalog.org/yangvalidator/validator against the draft and see no errors.

Request for posting confirmation emailed to previous authors: Michael Eckel , Henk Birkholz , rats-chairs@ietf.org, Shwetha Bhandari , Tom Laffey , Guy Fedorkow , Eric Voit , Liang Xia , Bill Sulzen