Draft: draft-ietf-rats-architecture

Commentary: TLS authentication is sufficient for establishing trust in the various entities before sending them privacy sensitive data . TLS is also widely supported today and attestation between servers is not . Most likely TLS will be the mechanism . This PR adds mention to in addition to attestation . 
 Addresses 
 5 says that the way for an Endorser to trust and Verifier is to use attestation . While I wo n't categorically say this should never be done , it seems like this is overly complex and a somewhat misuse of attestation . I think of the Verifier as a service like a web site , not an implementation like a TEE , so TLS or similar , not attestations , seems like the more efficient and conventional way to do this . I think attestation is associated with actual HW and SW , for example the Dell server , Intel CPU and Web stack used to run the service . The operator of a Verifier gets to change those around without having to tell the people using the service . On the other hand , if a Verification Service changes owners , say from Chinese to American , then  concerned about confidential stuff in the Endorsements really wants to know . I also think that Verifier Owner should not be lumped in with  . The Verifier Owner is very likely to be tightly coupled organizationally with the Verifier , where the  is not likely to be . 
 PR addresses this well enough . 
 Reviewing the trust relationships described in the architecture document got me thinking about sharpening a distinction between device attestation ( e.g. , EAT for phone ) and service authenticity ( e.g. HTTPS for a web site ): Device   is on the implementation , the HW and SW The legal entity of interest is the device manufacturer The claims are about the HW and the SW , not the device owner Example : a mobile phone ( not its owner / user ) Example : integrity of a remote device Service Authenticity Focus is on the provider of the service , not the HW or SW The legal entity of interest is the service provider There is no equivalent of claims , but if there was they would be about the business or person operating the service Example : a web site Example : an email provider ( IMAP service ) Service providers ( e.g. , web sites ) use whatever HW and SW they want to use . As a user of the service we do n’t care what HW and SW they select . We trust the service provider to pick good HW and SW and to configure and operate it correctly . They might change the HW and the SW and as a user we wo n’t know . For example we trust Bank of Xxx to operate their banking web site correctly with little concern for their HW . This is why attestation of the HW and SW is not so useful to the user of a service . Users of mobile phones and IoT devices are not trustworthy to pick secure HW and SW . They are not professionals like the people running web sites . There is little accountability against them if they pick bad SW and HW . Therefor we want attestation for these usage scenarios . This is why EAT , FIDO and Android Attestation exist . I do n’t think the line between device attestation and service authenticity is completely black and white . In some use cases attestation may be bent to provide some service authenticity . But I do n’t think it makes sense to add attestation to the millions of web sites out there , add support for it to browsers and make attestation an extra layer of security for web browsing . I think it is fine for a service provider to use attestation inside their service to monitor integrity and such of the HW and SW providing the service . But usually that wo n’t be manifest outside the service . It could be awkward for the user to the service to have to re evaluate the service every time the service provider changes HW . Another way to look at this is from a certification / regulatory view . If the thing you 're looking at is a candidate for implementation certification such as   , FIPS , FIDO certification , then it probably lines up with device attestation . On the other hand , if the thing your are looking at lines up with regulation ( e.g. , banking regulation , GDPR , ... ) and to some degree OWASP , then it probably lines up with service authenticity . I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not , for example saying something like “ attestation is not a replacement or augmentation for HTTPS / TLS " 
 In the last editors session , the editor 's rough consensus was that  does not provide the authenticity but it provides a secure channel . Instead , authenticity is checked via successful authentication rooted in identity documents ( I hope I captured appropriately , please bash ) . Taking that into account , how does this effect this issue ? Looking at the last paragraph , " Remote attestation procedures are not a replacement for secure authentication , they are based on secure authentication . " might be missing vital parts . Does anything need to be or modified here ? 
 Note that is INCORRECTLY referenced here . Is the resolution of a different issue about HTTPS vs Attestation . 
 I think comments from do need to be taken into account when the text to address this issue is written . My text in opening the issue is not intended as the text to resolve the issue . Probably the text that resolves the issue needs to refer to " HTTPS plus the web certificate infrastructure that includes public CA 's and browsers and/or private CA 's used in B - to - B ... " or such . 
 I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not , for example saying something like “ attestation is not a replacement or augmentation for HTTPS / TLS " The design team disagrees with this . Every authentication ( including HTTPS ) can be said in terms of attestation . It is the verifier that allows the decoupling of the RP to know the expected state of the Attester .
Paragraph (version B):
As another example, the Relying Party can establish trust in the
Verifier by out of band establishment of key material, combined with
a protocol like TLS to communicate.  There is an assumption that
between the establishment of the trusted key material and the
creation of the Evidence, that the Verifier has not been compromised.
Paragraph (version A):
In some cases where Evidence contains sensitive information, an
Attester might even require that a Verifier first go through a remote
attestation procedure with it before the Attester will send the
sensitive Evidence.  This can be done by having the Attester first
act as a Verifier/Relying Party, and the Verifier act as its own
Attester, as discussed above.
Paragraph (version B):
In some cases where Evidence contains sensitive information, an
Attester might even require that a Verifier first go through a TLS
authentication or a remote attestation procedure with it before the
Attester will send the sensitive Evidence.  This can be done by
having the Attester first act as a Verifier/Relying Party, and the
Verifier act as its own Attester, as discussed above.
Paragraph (version A):
The Relying Party Owner might also require that the Relying Party
first act as an Attester, providing Evidence that the Owner can
appraise, before the Owner would give the Relying Party an updated
policy that might contain sensitive information.  In such a case,
mutual attestation might be needed, in which case typically one
side's Evidence must be considered safe to share with an untrusted
entity, in order to bootstrap the sequence.
Paragraph (version B):
The Relying Party Owner might also require that the Relying Party
first act as an Attester, providing Evidence that the Owner can
appraise, before the Owner would give the Relying Party an updated
policy that might contain sensitive information.  In such a case,
mutual authentication or attestation might be needed, in which case
typically one side's Evidence must be considered safe to share with
an untrusted entity, in order to bootstrap the sequence.
Paragraph (version A):
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 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
authentication or attestation might even be needed as discussed in
rpowner-trust.