Some thoughts about Intro - v1

[muhammad-usama-sardar]

General thoughts

In general, the problem statement is not yet clear to me. I think a figure in Sec. 1 and defining some terms in Sec. 2 would help.

In the scope of this document, I would like to understand:

• What is the need/motivation for attestation?
• Who is attesting to whom?
• Is it local attestation or remote attestation?
• Compliance is mentioned multiple times in the draft, and I believe there is no "global" compliance; compliance is with reference to a specific regulation. It remains unclear to me which regulation is intended.
• I am specifically concerned about protocols. Where in this whole assessment process do the protocols get checked?

Specific questions

Note: Emphasis in the quoted text is my own

By using policy and measurement sets that may be offered at various assurance levels, local assessment of evidence can be performed to continuously assess compliance.

• Which policy is this related to: policy for Evidence or Attestation Results?
• measurement sets: are these Claims or Reference Values? If the former, does it include runtime measurements or just loadtime measurements?
• local assessment of evidence: is the draft about local attestation or remote attestation?
• compliance: compliance with what?

this kind of compliance

compliance with what?

The local system or server host performs the assessment of posture and remediation.

Seems local attestation to me, I am not sure why remote attestation is mentioned in the draft.

This document describes a method to use existing remote attestation formats and protocols.

This was very interesting for me. But unfortunately, there is no other mention of protocols in the rest of the document.

[KME]

Usama,

Thank you for your thoughtful questions!

you are correct that there are 2 levels of attestation, local to assess policy and then an attestation that is remote to convey a set of results against a defined policy or configuration level. Today, this activity happens, but it does not scale and requires lots of resources. This is the same problem the Huawei proposal is trying to solve, but theirs is with a different architectural pattern. This pattern also considers scale, but factors in transparency required by auditors.

This is setting a general capability with a registry to allow for any defined policy or regulation to be attested using evidence and verification of evidence. Then for the remote attestation, the evidence is assessed to see if all of the conditions are met to fulfill the compliance requirements, verifying sets of local attestations, then attesting to the result. Conveying the smaller result in a way that can be understood due to the registry and defined expectations allows for a small message to be sent. It is not efficient to perform full assessments to a large policy on the wire for a data center with thousands of systems. Huawei approaches this by sending one result for many systems. This posture assessment draft instead sends a small message that links back to the local attestation evidence providing a transparent trail of evidence required for audits to meet both requirements.

Which protocols? Are you asking because of TLS Attestation?

For your question on measurements, yes, we will want to test both at load time and at runtime.

I hope this clarifies further and I'm happy to get on a call if helpful.

[aj-stein]

Re @muhammad-usama-sardar's framing questions and specific questions, perhaps we can make some incremental edits and send them to him and the list for review and consideration to ensure we better answer those questions, @KME? We can work on that together if you'd like.