Change:
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> <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

Discussion:
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 :-).