Draft: draft-ietf-rats-yang-tpm-charra

Commentary: Provides more context around the various elements of the model 
 Thanks a lot for your stab at Security Considerations ! Also the I - D was in dire need for some expositional english text . Reads straight forward and comprehensive .
This document defines a YANG RPC and a minimal datastore tree
required to retrieve attestation evidence about integrity
measurements from a composite device with one or more roots of trust
for reporting.  Complementary measurement logs are also provided by
the YANG RPC originating from one or more roots of trust of
measurement.  The module defined requires at least one TPM 1.2 or TPM
2.0 and corresponding Trusted Software Stack included in the device
components of the composite device the YANG server is running on.
This document is based on the terminology defined in the I-D.ietf-
rats-architecture and uses the interaction model and information
elements defined in the I-D.birkholz-rats-reference-interaction-model
document.  The currently supported hardware security modules (HWM) -
sometimes also referred to as an embedded secure element (eSE) - is
the Trusted Platform Module (TPM) version 1.2 and 2.0 specified by
the Trusted Computing Group (TCG).  One ore more TPMs embedded in the
components of a composite device - sometimes also referred to as an
aggregate device - are required in order to use the YANG module
defined in this document.  A TPM is used as a root of trust for
reporting (RTR) in order to retrieve attestation evidence from a
composite device (quote primitive operation).  Additionally, it is
used as a root of trust for storage (RTS) in order to retain shielded
secrets and store system measurements using a folding hash function
(extend primitive operation).
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 I-D.ietf-rats-
tpm-based-network-device-attest.  Complementary measurement logs are
also provided by the YANG RPC originating from one or more roots of
trust of measurement.  The module defined requires at least one TPM
1.2 or TPM 2.0 and corresponding Trusted Software Stack included in
the device components of the composite device the YANG server is
running on.
This document is based on the terminology defined in the I-D.ietf-
rats-architecture and uses the operational context defined in I-
D.ietf-rats-tpm-based-network-device-attest as well as the
interaction model and information elements defined in I-D.birkholz-
rats-reference-interaction-model.  The currently supported hardware
security modules (HWM) are the Trusted Platform Module (TPM) TPM1.2
and TPM2.0 specified by the Trusted Computing Group (TCG).  One ore
more TPMs embedded in the components of a composite device -
sometimes also referred to as an aggregate device - are required in
order to use the YANG module defined in this document.  A TPM is used
as a root of trust for reporting (RTR) in order to retrieve
attestation evidence from a composite device (quote primitive
operation).  Additionally, it is used as a root of trust for storage
(RTS) in order to retain shielded secrets and store system
measurements using a folding hash function (extend primitive
operation).
This YANG module imports modules from RFC6991, RFC8348, I-D.ietf-
netconf-crypto-types, ietf-asymmetric-algs.yang.
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
WGLC.  Therefore a modified version of this draft is included here.
Perhaps someone will steward this list as a separate draft.
To be defined yet.
There are always some.
This YANG module imports modules from RFC6991, RFC8348, I-D.ietf-
netconf-keystore, ietf-tcg-algs.yang.
This module supports the following types of attestation event logs:
<ima>, <bios>, and <netequip_boot>.
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.
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
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.
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.
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.
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.
To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang
will be necessary.
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.
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.
Descriptive text added on model contents.