Change:
3.6. <del> One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, because it allows a fleet of devices to be held hostage for ransom. </del> <ins> There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied.  This can be a significant problem, because it allows a fleet of devices to be held hostage for ransom. </ins> In the case, the Relying Party is the watchdog timer in the TPM/ secure enclave itself, as described in TCGarch section 43.3.  The

Discussion:
The remaining nit is one I disagree with. Signed-off-by: Dave Thaler
From URL Five separate trivial updates requested Section 2: Reference Value Provider Currently: ...Reference Values help Verifiers appraise the authenticity of Evidence Proposed: ...Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6: Currently: One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, Proposed: There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem, Section 4: Currently: pppraisal policy Proposed: appraisal policy Section 11: Currently: as well as any users the device is associated with. Proposed: as well as potentially any users of the device. Section 12.1 Currently: Key Material Proposed: key material
I disagree with the first nit: if only known and acceptable claims have been recorded by the Attester Reasons I disagree: 1) Evidence might be considered trustworthy even if additional (not "known" to the Verifier) claims are inserted. E.g. there may be vendor-specific claims whereas the Verifier might only care about standard claims. 2) The appraisal process is not just about claims and the proposed text narrows it to only be about claims. The rest of the process includes checks like whether the signature is valid, whether the signer chains to something in the Verifier's trust anchor store, etc. These are not claims. As such, the current text is more correct.
The issue I have with the current text is that it intertwines authenticity and Reference Values. Evidence can still be authentic even if Reference Values are not what is passed. As part of WGLC, I have reviewed draft-ietf-rats-architecture-07, and believe it an excellent document. Below are three minor comments and five nits which I believe are worth addressing. Major Comments None Minor Comments Section 4: General Comment (this comment could also apply to Section 12) It is up to the Relying Party to evaluate the Verifier. And not all Verifiers should be seen as equivalently trustworthy.

Additionally, any particular Verifier might be able to provide a consistent level of certainty in the "Attestation Results". This is because the capabilities of the Attesting Environment will vary. This section does not hint at the varying levels of certainty in the "Attestation Results" based on the varying quality and quantity of available Evidence of different types of Attesters. I am not sure if this truism belongs in this section. Or if this truism belongs in the document at all. But without having this nuance being described somewhere, it could leave the perception of a higher level of confidence in the Appraisals being from a deployable RATS architecture made than might necessarily be warranted. Note that this issue is also alluded to in Section 7.4 and Section 12. But neither address things like whether Attestation Result values should provide a minimum level of confidence regardless of the type of Attester being evaluated. In the end, I am fine if nothing changes in the document as a result of this comment, but I wanted to have the authors consider whether this is worth a statement or two. Section 5.1 Current Text: If the Attestation Result was a successful one, the Attester can then present the Attestation Result to a Relying Party, which then compares the Attestation Result against its own appraisal policy. Proposed Text: If the Attestation Result was a successful one, the Attester can then present the Attestation Result (and possibly additional Evidence) to a Relying Party, which then compares this information against its own appraisal policy. Alternative way to address comment: In Section 5.3 is a discussion on "Combinations". A final sentence or paragraph could be added on another example of a combination where the Attestation Result from a Passport Model can be a form of Evidence coming into a background check model. Rationale : There are multiple statements in Section 5.1, including the diagram which do not show additional Evidence allowed to be included as part of the passport model. We need at least one statement within Section 5 which shows this to be a valid scenario. I do not think Figure 7 covers this option sufficiently. (Note: this goes back to previous email list discussions showing that a even a government issued passport is stamped with supplemental information as people transit country borders.)

Rationale : Section 8.3 on Attestation Results do not reference "Combinations", nor that Attestation Results can be a type of Evidence. Rationale : Section 16.2 includes a Nonce2 as supplemental evidence as part of the passport model diagram. Section 16.3 The notational convention for the use of ' (i.e., prime) after timestamps is not described. E.g. time(HR'_v). I think its meaning can be figured out by the diagram. But it might be worth making it an explicit notification convention. And other subsequent documents might want '' as well. Nits: Section 2: Reference Value Provider Currently: ...Reference Values help Verifiers appraise the authenticity of Evidence Proposed: ...Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6: Currently: One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, Proposed: There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem, Section 4: Currently: pppraisal policy Proposed: appraisal policy Section 11: Currently: as well as any users the device is associated with. Proposed: as well as potentially any users of the device. Section 12.1 Currently: Key Material Proposed: key material Thanks, Eric