Switch from Product to Target Environment

[aj-stein-nist]

I do find the explanation of Product approachable, but it is not a formally defined term in RFC9334 and is disjoint with the way RATS WG formally describes the entity and related roles. I would think we might want to consider this phrasing.

Note, I am drafting an email with other information about re-attestation and supportability re email, the next PR will propose other rewrites separate of Product->TE, but this is a specific change I thought worth reviewing separate of that.

[KME]

OK, I think PRODUCT may have been added by someone else as it was not a term I would have put in caps. My points, and the ones I think are more materially important was in the rest of the text I proposed. I'll include here and can propose the changes directly so they reflect as from me.
Current:

The remote attestation framework shall include provisions within the
system and attestation authority to allow for Product modification.

Over its lifecycle, the Product may experience modification due to:
maintenance, failures, upgrades, expansion, moves, etc..

The customer can chose to:

• Run remote attestation after product modification, or

• Not take action and remain un-protected

In the case of Re-Attestation:

• framework needs to invalidate previous TPM PCR values and tokens,

• framework needs to collect new measurements,

• framework needs to maintain history or allow for history to be
  logged to enable change traceability attestation, and

• framework needs to notify that the previous attestation has been
  invalidated

New:

The posture assessment process shall include provisions within the
system and attestation authority to allow for Product modification.

Over its lifecycle, the Product may experience modification due to:
maintenance, failures, upgrades, expansion, moves, changes in desired assurance levels, etc..

The administrator can choose to:

• Update the posture assurance policy (may be local) and re-assess posture with a local attestation process, summarizing with a remote attestation to the new policy or level, or

• Run remote attestation after product modification as an external validation, or

• Not take action and remain un-protected

In the case of Re-Attestation:

• framework needs to invalidate previous TPM PCR values and tokens,

Moriarty, et al. Expires 4 January 2025 [Page 6]
Internet-Draft RPASCA July 2024

• framework needs to collect new measurements,

• framework needs to maintain history or allow for history to be
  logged to enable change traceability attestation, and

• framework needs to notify that the previous attestation has been
  invalidated

[aj-stein-nist]

OK, I think PRODUCT may have been added by someone else as it was not a term I would have put in caps. My points, and the ones I think are more materially important was in the rest of the text I proposed.

Absolutely, I am about to send an email reply with how I would say we integrate those changes but use the WG terminology and arch concepts, if you/all of us agree. I just did things in a certain order. Email will point to #10, which I just opened to continue that discussion. Email reply coming in a minute!

[KME]

Hey A.J. I'd like to talk through your proposed changes. Scale is a big part of the purpose of this draft as is the architecture of what is actually being defined for the remote attestation, so I think there are some things that are misunderstood. How do I reject certain proposals in the new set of changes that don't align with the draft intent? Is it easier to talk through this? I think it may be. Thanks, Kathleen

…

On Fri, Jul 19, 2024 at 12:21 PM A.J. Stein ***@***.***> wrote: OK, I think PRODUCT may have been added by someone else as it was not a term I would have put in caps. My points, and the ones I think are more materially important was in the rest of the text I proposed. Absolutely, I am about to send an email reply with how I would say we integrate those changes but use the WG terminology and arch concepts, if you/all of us agree. I just did things in a certain order. Email will point to #10 <#10>, which I just opened to continue that discussion. Email reply coming in a minute! — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCRJGBQTDWG4WLEA6TXHB3ZNE4KFAVCNFSM6AAAAABLE3FHTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZZGU2DIMJWGA> . You are receiving this because your review was requested.Message ID: ***@***.***>

-- Best regards, Kathleen