Re: [Last-Call] Last Call: <draft-ietf-rats-yang-tpm-charra-12.txt> (A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tom,
Hi Henk,

Tom: from your other thread, the requested references from the YANG model
have been updated throughout the document as requested.   We will post a new
version as soon as the other topics below are covered to your satisfaction.

Henk: there is one change I hope you can help with.  Search on **Henk.

> From: tom petch, January 19, 2022 6:24 AM
> 
> These comments are separate from my previous comments on references in the
> YANG modules.  That said,
> 
> 'import' in YANG module must have a YANG reference clause which must be a
> Normative Reference in the I-D Reference.

This has been updated as part of references fix from your other email.  And
new text inserted prior to each YANG model describes the embedded references
from the draft's Normative list.

> ietf-hardware must has a prefix of 'hw' as per RFC8348  throughout the I-D

Change made.

> /http:datatracker/https:/datatracker/
> in both modules

Change made.
 
>         reference
>           "draft-ietf-rats-yang-tpm-charra";
> perhaps
>         reference
>           "RFC XXXX: A YANG Data Model for Challenge-Response-based Remote
> Attestation Procedures using TPMs";

Change made.
 
>       identity attested_event_log_type {
>         description
>           "Base identity allowing categorization of the reasons why and
/and/an/ ?

Change made.

>         leaf TPMS_QUOTE_INFO {
> most YANG identifiers have been changed to lower case; should this one be?

Multiple review discussions have driven this to be upper case because there
is a 1:1 correspondence with an identical object defined by TCG.

>       grouping boot-event-log {
> could do with more explanation and/or references for this. 

I made the group description:
      "Defines a specific instance of an event log entry 
       and corresponding to the information used to 
       extended the PCR";

e.g. are there
> semantics for the uint32 event-type?

** Henk, can you improve this ietf-tpm-remote-attestation.yang leaf
description with a reference:

    leaf event-type {
        type uint32;
        description
          "log event type";
    }

> Security Considerations mention the use of NACM; should the RPC have a
> default deny-all?

Added "with a default setting of deny-all".
 
>             leaf physical-index {
> should this reference the YANG RFC8348 rather than the SMI equivalent?

It could.  The initial requirement was driven by someone who wanted to allow
operations to make an easy mapping to corresponding Entity MIB data they
currently used.  In the end the populated info will be the same.

>             leaf manufacturer {
> these are often modelled as Privat Enterprise Numbers as registered with
IANA -
> see e.g. draft-ietf-dots-telemetry

This could be done.  Nobody in the WG suggested a purpose for leveraging a
mechanized list of values here.  I expect the major use would be for manual
debugging / manual checking if something went wrong.  Certainly a formal
list could be maintained.  It just didn't seem important yet.

>         reference
>           "RFC XXXX: tbd";
> as above

Updated.

>       identity tpm20 {
>         if-feature "tpm12";
> looks odd - if correct then worth an explanatory note

Fixed.

Eric

> Tom Petch
> 
> On 14/01/2022 16:16, The IESG wrote:
> >
> > 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'
> >    <draft-ietf-rats-yang-tpm-charra-12.txt> 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@xxxxxxxx mailing lists by 2022-01-28. Exceptionally,
> > comments may be sent to iesg@xxxxxxxx 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))
> >
> >
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list
> > IETF-Announce@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > .
> >

<<attachment: smime.p7s>>

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux