Hi Tom,
> From: Tom Petch, February 11, 2022 6:52 AM
>
> On 11/02/2022 10:37, tom petch wrote:
>
> Eric
>
> And following up on my other comments
>
> <CODE BEGINS> file "ietf-tpm-remote-attestation@xxxxxxxxxxxxxxx"
> interesting date
Both dates are now '2022-02-16' as per a pull request on the github site.
As with all the other changes below, approval, generation, and posting of a
v14 should come in the coming day(s).
> YANG 'import' must have a YANG 'reference' clause e.g.
> import ietf-inet-types {
> prefix inet;
> reference "RFC6991: Common YANG Data Types";
Added
> TLP in the YANG modules is out of date.
I just copied from the most recent drafts in the NETMOD WG.
> Copyright references 2021
Fixed
> >> "Defines a specific instance of an event log entry
> >> and corresponding to the information used to
> >> extended the PCR";
>
> / and corresponding to the information used to extended the PCR/
> corresponding to the information used to extend the PCR/ perhaps
Fixed
> My thinking on NACM was that the statement would actually appear in the
> YANG as you can see in draft-ietf-tcpm-yang-tcp
In your referenced draft, I can see the statement against the "action
reset". This mandates a MUST rather than a SHOULD, as is currently
documented in the security considerations. The current definition seems
cleaner as deviating away a perhaps unwanted MUST statement would be more
difficult than managing NACM permissions.
Eric
> Tom Petch
>
>
> > On 28/01/2022 20:56, Eric Voit (evoit) wrote:
> >> 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
> >>>> .
> >>>>
>
> _______________________________________________
> RATS mailing list
> RATS@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/rats
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
