Code change:
obtained via some other mechanism such as being configured in the Verifier by an administrator. <ins> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy

Related discussion:
text: possible text closing .
The architecture draft should say that known-good reference values can be either a part of an endorsement or part of an appraisal policy or both.
I would only want to mention "known-good reference values" at all if it comes with an explanation of why they're not sufficient in the real world. Not sure whether we want the arch doc to go there. We can discuss in a meeting.
I wouldn't say they are never sufficient. I would say KGVs serve a specific purpose. And this purpose is documenting the successful loading of well-known software on well-known Attester equipment, where the Attester equipment supports the signing of extended/hashed measurements. Adding Guy/Ned as they probably have better words for this based on their work with TCG & DICE. Eric
Hi Eric, Dave, I'd just add one more restriction to the list... if "known good values" means "if the measured hash in a PCR is exactly this value then we're good", the domain has to be narrowed to single-threaded well-known software instances, e.g., the components of a BIOS. The complexity of known-good-values comes with asynchronous threads such as IMA in Linux; in that case, the hash in the TPM PCR can only serve as a check on the (perhaps huge) number of individual hashes in the log file, each of which needs its own Known Good Value. Hence the SWID tags. I'm certainly not qualified to say how all this would work in EAT- or TEEP-land... /guy Juniper Business Use Only
Going back to Laurence’s original request. The observation he is making is that both the Endorser and the Appraisal Policy for Evidence Owner entities can say what is a ‘reference’ or ‘known good’ value. Presumably, an Owner entity did some due diligence to ensure the KGV is indeed ‘good’ given Owners may not have access to source code or other tools that the original vendor has access to. But ultimately, all appraisal decisions are qualified by the Owner’s wishes. There is complexity in ecosystems when a vendor (e.g. BIOS vendor) doesn’t give up ownership of the FW even though the computer is sold to the customer. The PC owner might have a policy that allows the BIOS vendor to supply an Appraisal policy for just the BIOS.