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

Commentary: Allows the YANG model changes I have suggested to be merged into the overall document 
 There are several issues with the current YANG model . I am grouping them as one as I have a single YANG model pull request to cover all of these . The issues I believe need to be addressed include : ( 1 ) PCR numbers should be their own type , not a UINT8 . PCRs should be limited to [ 0 .. 31 ] ( 2 ) We should use ENUMs instead of strings for TCG and IETF crypto algorithm types . Strings allow lots of errors to be introduced which we can protect using a larger , more detailed ENUM construct . ( 3 ) Most devices do not have multiple line cards . Because of that , we should not have nested keys of [ node i d ] [ tpm name ] . This adds unnecessary complexity for the vast majority of users . Instead the tpm should have a mandatory leafref back to node - id when compute - nodes is not null . ( 4 ) The YANG doctors will not let us have a TPM - Name of " ALL " . Instead of " ALL " we should be able to assume that an RPC means all hardware based TPMs if a specific TPM is not named in the RPC . Note that this means that we should not use TPM - name as a KEY in any RPC . ( 5 ) We should add leaf for a unique TPM - Path . It might be claimed this is irrelevant with the existing key structure , but likely the YANG model itself will learn the TPM this way after boot . You could add / remove / migrate new virtual TPMs , more easily only re - allocating an existing path when the new vTPM is activated . ( 6 ) We should have optional YANG features for TPM1.2 and  so that RPCs are not exposed when there are no such TPMs of that type are supported . ( 7 ) We should great new grouping for the log algorithm types . These groupings can be reused for a Telemetry / Subscription feed of individual log entries . Other log types like those proposed for " netequip boot " by   can then be merged . 
 I placed this as a separate issue from the Pull Request as almost all issues are addressed in the pull request . For ( 2 ) , I only some of the relevant ENUMs . Others will be should people agree with the direction of the pull request . 
 Based on some feedback , made the following changes : ( 8) Removed ' TPM - path ' as a unique identifier for RPCs . Instead ' certificate - name ' is used . This allows for a cleaner certificate migration path , and wo n't have issues with reboots . ( 9 ) Extracted into a group    issues included in latest proposal : ( 10 ) Separate out crypto - algorithm types into a separate draft ( 11 ) Not much reason in building choices for IETF algorithm types when the TPMs need to follow TCG types . ( 12 )  for certificate datastores should simplify the storage of this information should people not want to create separate structures . 
 We should separate 10 into its own issue . The current model does n't break it out into its own draft . Let 's publish the next charra version as including both within this draft . Doing so will allow us to ask the WG the question at the next IETF . 
 Because these TCG - defined algorithm types are only used by CHARRA now , so I think this strong relationship makes it OK that leaving the crypto - algorithm types in CHARRA . 
 Especially for the upcoming review phase this is fine . Long term , we have to understand how maintenance of the alg document will work . When the TCG registry changes , only the alg module in this doc has to be updated . Do we have to update the whole doc ? Do we split out only the alg module ? Maybe that is a reason to split it out now . I am not sure that we know today ( at least I do n't ) and we should find out . Let 's drive a thorough review cycle before the upcoming meeting and then bring this topic up in a discussion at the virtual meeting itself . 
 Thanks !
This YANG module imports modules from RFC6991, RFC8348, and I-D.ietf-
netconf-crypto-types.
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.