Original text:
a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences.  A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a <del> reference value, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check </del>  against values in other claims, or any other test. <del> Such reference values might be specified as part of the Appraisal Policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy. </del>  <del> The actual data format and semantics of any reference values are </del>  specific to claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. <del> 4.2. </del>  An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting capable of claims collection are referred to in this document as Attesting Environments. <del> 4.3. </del>  By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown in layered. <del> 4.4. </del>  A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal 7.5. <del> In some scenarios, the Endorser and Verifier Owner may need to trust the Verifier before giving the Endorsement and Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner- trust. </del>  8. Appraisal Policies that may not be specific to the device instance, but merely specific to the manufacturer providing the Endorsement. For example, an Appraisal Policy might simply check that devices from <del> a given manufacturer have information matching a set of known-good reference values, or an Appraisal Policy might have a set of more complex logic on how to appraise the validity of information. </del>  However, while an Appraisal Policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it Party's Appraisal Policy.  The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier.  A more complex policy might also <del> entail comparing information provided in the result against known- good reference values, or applying more complex logic on such information. </del>  Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical

Reviewer comments:
Need Peter to confirm he agrees, but I believe these changes are consistent with the points that Peter and I were both making during the last call. Signed-off-by: Dave Thaler
To complete this, a sub section for Reference Value Provider should be added to section 7 on the Trust Model. All other such entities are described there now.
Here's some possible text. Endorser The primary function of an Endorser is to endorse an Attester so that a Verifier can know to trust that Attester. The Endorser does this by creating an Endorsement and conveying it securely to the Verifier. The primary basis for a Verifier trusting an Attester is the Endorsement. There is thus an existential relationship between Attesters and Endorsers. An Attester with no Endorsement is not worth very much since there is no good basis by which a Verifier can trust it so every Attester needs an Endorser. The Endorser’s primary function is to endorse Attesters so an Endorser doesn’t have anything to do without some Attesters to endorse. A Verify cannot do its job without Endorsements. It must have an Endorsement for each Attester from which it received Attestation Evidence. Without this, the Attester is not trusted and there is no basis for trusting the Evidence it produces. There is a trust triangle between the Endorser, Attester and Verifier. The Endorser tells the Verifier that an Attester is trustworthy. Endorsement Ultimately an Endorsement must be realized as some input bytes to a Verifier and they must be conveyed securely from the Endorser to the Verifier. RATS architecture does not impose any limit or restriction on the formats of these bytes or the conveyance mechanism. In practice they are expected to vary quite widely. In most cases the Endorsement will include the key material that is used to verify signatures on the Evidence. Since the Evidence will contain a nonce, this signature verification serves to authenticate the attester. The Endorsement may also contain information about the Attester such as its type, version, manufacturer and such. In one example, the Endorser and the Verifier are the same legal organization, so secure conveyance is entirely an internal issue for the organization. It may consist of one employee copying a set of public keys from computer in the company to another. In another example, the Endorsement may take the form of a PKI hierarchy. The Endorser conveys a root certificate to the Verifier. The Endorser also creates per-attester certificates under that root. Those per-attester certificates are programmed into Attesters. The Attester sends them to the Verifier attached to the Evidence. There may be several levels of certificates in the PKI hierarchy. The Verifier walks the certificate chain to determine trust. Note in the case the abstract notion of Endorsement comes to the Verifier in two parts, one in an out-of-band secure conveyance or a root certificate and the other as the signed (self-securing) certificates from the Attester. Unendorsed Attesters The use of unendorsed Attesters is discouraged because there is no good basis for establishing trust in them. An unendorsed Attester may still have a signing key and produce signed evidence. A Verifier may choose to have some trust in the Evidence they produce by assuming they are trusted on first use (TOFU), building up trust over time after seeing a lot of presumably good attestation evidence, or because it is fed into a machine learning algorithm that correlates to known fraud. Rats architecture include any facilities, details or designs for this mode of use and explicitly considers it insecure.
Two updated proposal options from URL 1) Expand the notion of an Endorsement quite a lot. Endorsements are not longer just static documents like X.509 certs and/or COSE/CMS signed blobs. They are anything that conveys the attestation key material into the Verifier or allows Verification of the attester. They must support confidentiality. 2) Replace the term “Endorsement” with something like “Verifier Input” or “Attester Trust Criteria” in the architecture document as the means by which key material goes into the Verifier. Endorsements still exist, but are just one type of Verifier Input or Attester Trust Criteria just like EAT is one kind of Attestation Evidence. Laurence proposes to follow one of theses options and highlights a slight preference for his 2nd option.
PR was related to that, is this now addressed or what gaps remain?
We acted on Laurence's preference in . I presented this slide below the IETF 108 RATS meeting today. I believe it is critical that the RATS architecture allow for all uses case in the slide. In particular RATS architecture must allow for symmetric keys. TPMs and public-key based crypto is too expensive for low-cost, large-scale IoT. There are real use cases supported my multiple companies using symmetric keys. Symmetric keys can be made secure at the verifier — we secure keys for TLS at servers all the time using HSMs and such. I do NOT want to put this taxonomy into the RATS architecture document. I don’t think that is necessary. I created the taxonomy as background information and as illustrative examples of real world designs. I think there are options for adjusting the architecture document to accommodate this. Option 1) Expand the notion of an Endorsement quite a lot. Endorsements are not longer just static documents like X.509 certs and/or COSE/CMS signed blobs. They are anything that conveys the attestation key material into the Verifier or allows Verification of the attester. They must support confidentiality. Option 2) Replace the term “Endorsement” with something like “Verifier Input” or “Attester Trust Criteria” in the architecture document as the means by which key material goes into the Verifier. Endorsements still exist, but are just one type of Verifier Input or Attester Trust Criteria just like EAT is one kind of Attestation Evidence. I have a slight preference for Option 2). I’m interested in opinions of which option to choose. This is issue , opened in GitHub four months ago. It is not a last-minute/new issue. I believe it is in scope with the RATS charter as the charter explicitly mentions attestation key material in the Program of Work. LL My main point of this taxonomy was to affect the RATS architecture document. There was discussion today of it being a separate document perhaps outside of RATS. I’m happy for that to happen, but I don’t want to write it because I have enough RATS/EAT work to do. I’m very happy if other folks want to pick it up and use in other documents :-).

Revised text:
a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. <ins> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise the authenticity of Evidence. A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference Values are sometimes referred to in other documents as known-good values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of comparison. </ins> A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a  <ins> Reference Value, or a check for being in a range bounded by Reference Values, or membership in a set of Reference Values, or a check </ins> against values in other claims, or any other test.  <ins> 4.2. </ins>  <ins> Reference Values used in appraisal might be specified as part of the Appraisal Policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy. The actual data format and semantics of any Reference Values are </ins> specific to claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison.  <ins> 4.3. </ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting capable of claims collection are referred to in this document as Attesting Environments.  <ins> 4.4. </ins> By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown in layered.  <ins> 4.5. </ins> A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal 7.5.  <ins> In some scenarios, the Endorser, Reference Value Provider, and Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner-trust. </ins> 8. Appraisal Policies that may not be specific to the device instance, but merely specific to the manufacturer providing the Endorsement. For example, an Appraisal Policy might simply check that devices from  <ins> a given manufacturer have information matching a set of Reference Values, or an Appraisal Policy might have a set of more complex logic on how to appraise the validity of information. </ins> However, while an Appraisal Policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it Party's Appraisal Policy.  The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier.  A more complex policy might also  <ins> entail comparing information provided in the result against Reference Values, or applying more complex logic on such information. </ins> Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical