Section 3 seems garbled

[nedmsmith]

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.

[dthaler]

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 1 defines what the title of section 3 means. Paragraph 3 is essential in allowing paragraph 4 to explain the difference. I haven't heard confusion from any other readers yet.

Paragraph 2 seems to give attention to immutable vs. immutable unnecessarily. It bans use of conditionally endorsed values that are immutable.

I think this came from @thomas-fossati. Personally I have no objection to removing this ban, but Thomas do you have any technical reason to keep this?

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.

I think the example is still useful (it certainly helped me understand it), but adding a second example like one you mention in this feedback is fine. I will try to do that.

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.

It does to me (I can't say whether it is clear to anyone else, so wordsmithing suggestions welcome. Thomas? Henk? It says that you conditionally add any appropriate claims before you determine trustworthiness based on their values.

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.

The conditional matching part is not appraisal policy per se. The intent of paragraphs 1 and 4 (taken together) are to say that.

In toto, section 3 should describe the concept of conditional endorsement

There's no "conditional endorsement" (so such term is defined or should be in my view). There are "conditionally endorsed values". The same endorsement might contain multiple conditionally endorsed values, with different conditions.

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+.

I am adding this example (in generic wording so as to not require a reference) in a pull request.

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

[nedmsmith]

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 1 defines what the title of section 3 means. Paragraph 3 is essential in allowing paragraph 4 to explain the difference. I haven't heard confusion from any other readers yet.

I don't agree that a conditional endorsement can't match Evidence directly or that it can't match other endorsements. Conditional "matching" can be applied more generally than to only claims that have matched reference values. For example, an Attester might sign a random challenge. A certificate might identify the key as belonging to Attester_X. An endorser might assert that there is an SVN for the key belonging to X in an endorsement. Since the random challenge is random, it can't be predicted by an RVP and hence can't expect to have RVs.

I don't think RATS WG wants to say that the above use case of off limits.

Other people may not have thought about how the Verifier will process the inputs it receives :-)

Paragraph 2 seems to give attention to immutable vs. immutable unnecessarily. It bans use of conditionally endorsed values that are immutable.

I think this came from @thomas-fossati. Personally I have no objection to removing this ban, but Thomas do you have any technical reason to keep this?

Since the premise in paragraph 1 is misguided, the statements in paragraph 2 may also be misguided.

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.

I think the example is still useful (it certainly helped me understand it), but adding a second example like one you mention in this feedback is fine. I will try to do that.

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.

It does to me (I can't say whether it is clear to anyone else, so wordsmithing suggestions welcome. Thomas? Henk? It says that you conditionally add any appropriate claims before you determine trustworthiness based on their values.

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.

The conditional matching part is not appraisal policy per se. The intent of paragraphs 1 and 4 (taken together) are to say that.

In toto, section 3 should describe the concept of conditional endorsement

I'm of the opinion that all endorsement is conditional.

There's no "conditional endorsement" (so such term is defined or should be in my view). There are "conditionally endorsed values". The same endorsement might contain multiple conditionally endorsed values, with different conditions.

I can't tell if saying "there's no conditional endorsement" and "There are conditionally endorsed values" is splitting hairs. I think it is.

I don't disagree with "The same endorsement might contain multiple conditionally endorsed values, with different conditions.". But I don't see how the last sentence has anything to do with the discussion on whether there is/isn't "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+.

I am adding this example (in generic wording so as to not require a reference) in a pull request.

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

[dthaler]

I don't agree that a conditional endorsement can't match Evidence directly or that it can't match other endorsements.

I wouldn't agree with that either, but I can't find anywhere that has such text to disagree with. Paragraph 1 says:

Some claims in Endorsements might be conditional. A claim is conditional if it only applies if actual state matches Reference Values, according to some matching policy.

Figure 1 shows that actual state is in both Evidence and Endorsements. So above already says it can match endorsements. So I'm confused as to what you disagree with :)

Conditional "matching" can be applied more generally than to only claims that have matched reference values. For example, an Attester might sign a random challenge. A certificate might identify the key as belonging to Attester_X. An endorser might assert that there is an SVN for the key belonging to X in an endorsement. Since the random challenge is random, it can't be predicted by an RVP and hence can't expect to have RVs.

In your example, the certificate is what identifies X, so I would think an identifier in the certificate (subject name or whatever else) is the thing being matched on, not the random challenge per se. The random challenge would presumably be used for freshness, not for matching. Otherwise, I'm not following you.

I don't think RATS WG wants to say that the above use case of off limits.

Agree, and I don't think the draft does.

[nedmsmith]

Some claims in Endorsements might be conditional. A claim is conditional if it only applies if actual state matches Reference Values, according to some matching policy.

Figure 1 shows that actual state is in both Evidence and Endorsements. So above already says it can match endorsements. So I'm confused as to what you disagree with :)

I'm trying to minimize the potential for misreading things. If the words are taken in isolation, they can be misinterpreted. If we are relying on the figure (and not the words) to tell the complete story, then the I-D inconsistently applies this philosophy because in figure 2 we said the figure wasn't confusing if you read the text in isolation.

The principle that should be explained, IMHO, is that conditional endorsement uses a matching condition to identify whether or not the endorsement claims to be added are relevant to an ACS (appraised claim set). Since the ACS contains only actual state, the condition is expressed in a way that expects to match only actual state (and not in a way that would match possible / reference state). Saying that "state matches Reference Values" leaves a lot up to the imagination of the reader to figure out how this works.

[dthaler]

The principle that should be explained, IMHO, is that conditional endorsement uses a matching condition to identify whether or not the endorsement claims to be added are relevant to an ACS (appraised claim set). Since the ACS contains only actual state, the condition is expressed in a way that expects to match only actual state (and not in a way that would match possible / reference state).

Got it, that makes sense. Thanks for the elaboration. Filed PR #31 to hopefully explain this better.

[dthaler]

Fixed in draft-02

[dthaler]

Also further updated in PR #36

[dthaler]

Fixed in draft-03

[dthaler]

I believe this is fixed in the latest draft. Please reopen (with explanation of what is remaining) if you disagree.