dthaler
commented
2 weeks ago 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".
In my view, the sentence right above the diagram makes it pretty clear. It says:
"Thus each Target Environment (application, OS, firmware, and hardware) has one set of claims in the Evidence, and an additional set of claims in the Endorsement from its manufacturer. A Verifier that trusts each Endorser would thus use claims from both conceptual messages when comparing against reference state for a given Target Environment."
I'm hesitant to use a very different term in the diagram since the now-approved EAT spec uses "claims set" for the set of claims in Evidence. We should, however, match that and use "claims set" instead of "claimset". (RFC 9334 uses "Claim set", so perhaps that would be better, but neither document uses "claimset" as one word now.)
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.
It is not incorrect. Basing the binding solely on a matching condition found in Endorsement claims would be a security vulnerability, as it would allow an Endorser to simply include claims about any other Target Environment in the Attester, rather than just the permitted one(s). In a secure system, Appraisal Policy must be able to control which Endorsers are believed for claims about which Target Environment and not just allow a free-for-all.
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?
As an example, claims from a Target Environment itself might contain a secure identifier of the Endorser that can provide additional claims about that Target Environment. I can add that example for clarity.
nedmsmith
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?