ietf-rats-wg / rats-endorsements Goto Github PK

• The following is NOT always applicable:

where actual state has a single value per claim per component applying to one device at one point in time, reference state has a set of values per claim per component (§2)

It may very well be the case that there is only one Reference Value per Claim per component (e.g., MRENCLAVE in SGX).

• The following is NOT always the case:

Actual state: Evidence, Endorsements, Attestation Results (§2.1)

As a counterexample, CPUSVN inside PCK cert (Endorsement) may be older than the one in Evidence (QE Report Body).

• I think the draft currently focuses on a very specific case rather than the goal stated in the abstract:

explains the purpose and role of Endorsements

One of the major purposes of Endorsements is to provide identity endorsement, which is never discussed in the draft.

• Clarify "group of claims" vs. "set of claims" (e.g., as used in §2)

• Clarify the definition of "Claim" and explain:

for our purposes we will treat such a list as a single unit (§2)

For example, I am thinking about attributes and Security Version Numbers in SGX/TDX. For instance, SGX TCB Security Version Number (SVN) has 16 components, so would each component be treated as a Claim, or would the SVN be treated as a single unit?

• Clarify "reference values" vs. "Reference Values"

Figure 2 describes the concept that endorsements can provide additional claims to those provided by evidence. The figure uses "claimset" to refer to the set of claims that are asserted by a particular entity (Attester, Hardware Endorseer, etc.). However, it isn't clear in the diagram that the "Hardware claimset" asserted by the Attester is different from the "hardware claimset" asserted by the Hardware Endorser. A simple terminology change could improve this. For example, the Hardware Endorser might assert "Additional Hardware Claims" while the Attester asserts "Hardware Claims". The Hardware "claimset" = "Hardware Claims" + "Additional Hardware Claims".

Section 5 states:
"The binding between Target Environment and Endorser might be part of the Appraisal Policy for Evidence"
This seems incorrect as the binding between Endorsements claims and Evidence claims is based on the matching condition found in the Endorsement claims.

I'm confused by "or might be specified as part of the Evidence itself, or some combination of the two"
because it isn't clear what the connection is between Evidence and Appraisal policy for Evidence that defines a binding between a TE and an Endorser. Use of the term "binding" seems overloaded with other uses within the same document. Wouldn't the TE be identified by its class / instance name? Wouldn't the Endorser and Attester developers have to agree on these names?

Section 6.2 first paragraph:
"We currently assume that Reference Value Providers and Endorsers typically provide the same information"
This sentence seems to contradict what is stated above since RVPs provide "reference" or "possible" state claimsets while Endorsers provide "actual" state claimsets.

This line: "clients ... are generally on devices that are not constrained nodes"
is not commonly agreed upon as there are many cases of embedded verifiers, BMCs and so forth. The conclusion that scalability of verifiers "is not a significant concern" to RATS is not true or that it is not "typical".

The following paragraph seems to reinforce my point.

This may be writing style. But the first paragraph should introduce what will be described in subsequent paragraphs, rather than contradict them.

The last two paragraphs seem more focused on complexity than scalability. Maybe they belong in section 6.1? BTW: If this is intended as a security considerations section it shouldn't be a subsection heading. Othewise, this section seems to be about complexity hence it's heading might be more reflective of this.

Section 6 isn't so much about formats as it is about complexity and scalability. It is possible to use different formats to encode simple things or a single format to encode complex things.

Section 2.1 describes appraisal policy as the source of comparison rules for relating actual state with reference (possible) state. However, there are significant comparison dynamics that can occur independent of appraisal policy. For example, a verifier can assume exact match semantics given the reference values are identical to the evidence values. No appraisal policy is required to instruct a verifier to apply exact match semantics.

Additionally, a profile such as https://datatracker.ietf.org/doc/draft-cds-rats-intel-corim-profile/ defines Reference Values that define actual value must be in the set of allowed Reference Values and actual value must be in a range where two Reference Values are the min and max.

This suggests that the RVP has insight on how best a verifier should apply matching rules.

The current text seems to ignore this important aspect.

Section 3 seems garbled. Paragraphs 1 and 3 describe reference values interactions (possible states) in a section on actual (endorsed) states. These should probably be removed from section 3.

Paragraph 2 seems to give attention to immutable vs. immutable unnecessarily. It bans use of conditionally endorsed values that are immutable. But it is reasonable for an AE to have a serial# that is asserted by one AE while another AE asserts, say a model#. It isn't wrong if an endorsement asserts that a model# is X conditional on a serial# Y.

Paragraph 2 uses an example that isn't that intuitive as it assumes / asserts that CPU may support different features based on (mutable) firmware. This seems like an obscure example since there is no consistency across the industry regarding whether a CPU vendor's endorsement will differ based on which firmware happens to be loaded. Hence, it isn't providing intuition about the property of immutableness as it pertains to conditional endorsement.

The fourth paragraph seems to derive from the previous 3 but these all have issues, so it is unclear what property is derived. Paragraph 4 simply seems to weigh trade-offs without specifically stating the conditions being compared.

The fifth paragraph describes the relationship between conditional endorsements and policies. But there is no such thing as appraisal policy for endorsements. Hence, it is unclear what point the author is making.

In toto, section 3 should describe the concept of conditional endorsement as the idea that a second endorsement state may be entered (true) conditional on a first endorsement state being true.

For example, if an AE has the serial#_X, then the CC evaluation is EAL4+.

Appraisal policy for AR might determine whether or not CC evaluation claims are relevant. But appraisal policy would (should) not negate an endorsement claim.

In the IEFT 117 meeting, Laurence suggested not using the word "identity" but rather "key material for verifying evidence" or "attestation keys". He suggested there might be like 3 pages of stuff to talk about here. I asked if there were volunteers to contribute such text and the recording shows that two people raised their hands (Thomas Hardjono was one, and I think the other might have been Henk).

I find section 4 difficult to read. The heading "Endorsing Evidence Provenance" is not an intuitive concept. The authors must explain what it means first.

The first paragraph seems to describe that Evidence should be authenticated. This could be stated more plainly.

The second paragraph seems to make the same statement, but in a contra indicated way. There is a DICE example in Section 2, that could be referenced as it seems to describe layering. But it isn't clear how paragraph 2 (section 4) pertains to "provenance" or "endorsement".

For example: "Such a certificate need not be stored by the Verifier when the Endorsement can be resolved on demand or passed to the Verifier along with the Evidence"
The concept of "Endorsement resolution" is not described in the I-D. The reader is assumed to know what this entails. It's relevance to "provenance" is not obvious.
 
I believe the first sentence of the 3rd paragraph is actually incorrect:
"No particular algorithm or cryptographic protocol is assumed for the verification of the Attester."
A verifier must implement the algorithm/protocol that authenticates the Attester / AE otherwise the integrity of the evidence is suspect.

"Evidence typically contains an identifier for the Attester (e.g., [I-D.ietf-rats-eat] ueid) in a claim, sometimes termed an "identity claim", that can be used by the Verifier to look up its verification key for the Attester."
The 4th paragraph is not typical as Evidence often describes a class of devices rather than a specific instance of a device.
Instead, it is typical for a lead Attester to have authentication credentials that identifies an instance of a device. However, this is also is contradicted by I-D:daa-attestation where a group key maintains the class nature of evidence while also authenticating the evidence.

The fifth paragraph seems to take a circumlocutions approach to saying that Evidence must be authenticated (restating what the first paragraph is saying) and that Evidence authentication should be the first step before applying other appraisal steps. Maybe this could be said more directly?

The last paragraph seems to be summarizing the steps that a verifier might follow, but seems out of place in a section on evidence provenance.

It is still unclear to me if the goal of the section is to assert that Evidence provenance means Evidence should be authenticated, if this is giving general (cherry picked) advice to verifiers, or if this is aimed at Endorsers who may need to do something (???) in order to ensure Endorsements have "provenance" (e.g., sign endorsement claims?).

Maybe a different approach would be to explain that AE's have attestation keys that authenticate evidence and that provenance of attestation keys is needed to build trust in the AEs? This is what the PKIX Consortium refers to as "key attestation". Maybe the authors are saying that AEs' attestation keys should be backed by key attestation?

Multiple Endorsements should talk about this concept and draft -02 doesn't.
Discussed at IETF 117.

Kathleen Moriarty mentioned same concept is in attestation sets draft.

Henk Birkholz mentioned that corim 3.1.4.1.1 refers to multiple environments, for same reason.