2.2.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- <del> netconf-crypto-types, ietf-asymmetric-algs.yang. </del> <ins> netconf-keystore, ietf-tcg-algs.yang. </ins> <del> 2.3. </del> <ins> 2.2.1.1. This module supports the following types of attestation event logs: <ima>, <bios>, and <netequip_boot>. 2.2.1.2. <tpm12-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM1.2 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM1.2 compliant cryptoprocessors will respond. <tpm20-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM2.0 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM2.0 compliant cryptoprocessors will respond. <log-retrieval> - Allows a Verifier to acquire the evidence which was extended into specific PCRs. 2.2.1.3. container <rats-support-structures> - This exists when there are more than one TPM for a particular Attester.  This allows each specific TPM to identify on which <compute-node> it belongs. container <tpms> - Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status.  Of note is the certificates which are associated with that TPM.  As a certificate is associated with a single Attestation key, knowledge of the certificate allows a specific TPM to be identified. 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. 2.2.1.4. 2.2.2. </ins> Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang.  Unfortunately all this content including the algorithms needed here failed to make the -v15 used <del> WGLC.  Therefore a modified version of this draft is included here. Perhaps someone will steward this list as a separate draft. </del> <ins> WGLC.  As a result this document has encoded the TCG Algorithm definitions of TCG-Algos, revision 1.32.  By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. 2.2.2.1. There are two types of features supported <TPM12> and <TPM20>. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG API is present on an Attester.  Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.2.2.2. There are three types of identities in this model. The first are the cryptographic functions supportable by a TPM algorithm, these include: <asymmetric>, <symmetric>, <hash>, <signing>, <anonymous_signing>, <encryption_mode>, <method>, and <object_type>.  The definitions of each of these are in Table 2 of TCG-Algos. The second are API specifications for tpms: <tpm12> and <tpm2>. The third are 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. 2.2.2.3. Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang.  However the full definition of Table 3 of TCG-Algos will allow use by additional YANG specifications. </ins> 3. This document will include requests to IANA: <del> To be defined yet. </del> <ins> To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang will be necessary. </ins> 4. <del> There are always some. </del> <ins> The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF RFC6241 or RESTCONF RFC8040.  The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) RFC6242.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS RFC5246. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default).  These data nodes may be considered sensitive or vulnerable in some network environments.  Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes and their sensitivity/vulnerability: Container: </rats-support-structures/attester-supported-algos> <tpm12-asymmetric-signing>, <tpm12-hash>, <tpm20-asymmetric- signing>, and <tpm20-hash> all could be populated with algorithms which are not supported by the underlying physical TPM installed by the equipment vendor. Container: </rats-support-structures/tpms> <tpm-name> - Although shown as 'rw', it is system generated <tpm20-pcr-bank> - It is possible to configure PCRs for extraction which are not being extended by system software.  This could unnecessarily use TPM resources. <certificates> - It is possible to provision a certificate which does not correspond to a Attestation Identity Key (AIK) within the TPM. RPC: <tpm12-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <tpm20-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <log-retrieval> - Pulling lots of logs can chew up system resources. </ins> 5. <ins> Changes from version 02 to version 03: moved to tcg-algs cleaned up model to eliminate sources of errors removed key establishment RPC added lots of XPATH which must all be scrubbed still Descriptive text added on model contents. </ins> Changes from version 01 to version 02: Extracted Crypto-types into a separate YANG file