Draft: draft-ietf-rats-architecture

Commentary:   to confirm he agrees , but I believe these changes are consistent with the points that  and I were both making during the last call . Signed - off - by :   
 To complete this , a sub section for Reference Value Provider should be 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  is to endorse an Attester so that a Verifier can know to trust that Attester . The  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  ’s primary function is to endorse Attesters so an Endorser does n’t have anything to do without some Attesters to endorse . A Verify can not 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  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  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  conveys a root certificate to the Verifier . The  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 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   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 .
Mailing list commentary: 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 do n’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 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 # 65 , 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 do n’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 :-) .
Paragraph (version B):
An entity (typically a manufacturer) whose Reference Values help
Verifiers appraise the authenticity of Evidence.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
An Attestation Result that indicates compliance can be used by a
Relying Party to make authorization decisions based on the Relying
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
entail comparing information provided in the result against known-
good reference values, or applying more complex logic on such
information.
Paragraph (version B):
An Attestation Result that indicates compliance can be used by a
Relying Party to make authorization decisions based on the Relying
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
entail comparing information provided in the result against Reference
Values, or applying more complex logic on such information.