Update Trust Model with Implicit Trust Example

[gmandyam]

Starting point for #59

[William-PanWei]

evidence -> Evidence
the device -> Attester

[William-PanWei]

Are the Attester and Verifier different entities? If they are different, how can the Verifier know the Attester has a secure element?

[mcr]

Dave Thaler asks for rewording to make the Implicit Trust more clear, the secure session is necessary, but not sufficient for this. MCR asks for the example to not be parenthetical.

[William-PanWei]

So you mean the Evidence isn't signed or encrypted?

[nedmsmith]

Endorsements are signed (integrity protected and authenticated) by supply chain entity such as a vendor or manufacturer. Evidence is signed by an attestation key that is on the attesting device. The roles architecture distinguishes between Endorsers and Attesters for good reasons even though there can be cases where it isn't that clear that they are different. I don't think this section is trying to draw attention to one of those corner cases. Therefore, it appears the term Endorsement was used by mistake when Evidence was intended.

[gmandyam]

@nedmsmith

That wasn't really the intention behind the cited text. If the communications link is already trusted, then an endorsement may have been used in establishing the communications link. In that case, an additional endorsement for attestation evidence is not required.

[nedmsmith]

I agree with the three sentences above.

I think the text at line 616 may be what is the problem because it presumes knowledge of the secure element context is existential. The Verifier needs to be told that the root-of-trust / secure element environment exists. It can happen manually, such as an IT department physically issuing a smart card or smart device with a SE to a user, generating the key pair, update the Verifier to trust the public that was generated. Manual approaches work in IT environments where employees are subject to IT procedures. Manual processes may not scale to Internet ecosystems. Remote attestation is trying to go beyond manual processes by generating keys in devices by manufacturers and issuing machine certs that establish that a key is protected by a secure element. This seems like a basic idea that if it isn't clear might belong in the introduction?

[dthaler]

I don't think we should use the term "secure element" in lower case, as it's ambiguous whether we mean Secure Element (per GP) or something more generic

[gmandyam]

Changes to "enclave" as per RFC 4949

[dthaler]

I don't think the word endorsement is accurate here. Perhaps you mean signature? (Which is already after the "or") so recommend deleting the endorsement phrase.

[gmandyam]

The use of 'endorsement' is deliberate. Any endorsement would be applied to assertions associated with the communications link, not the attestation evidence.

[dthaler]

That wasn't obvious from "additional". Need to reword.

[thomas-fossati]

There's another bit that probably deserves a small paragraph here, related to the implication of session security being "ephemeral", i.e., what happens to the evidence once the secure session goes away?

[gmandyam]

Tried to address the comments in PR mod's:

a) @dthaler - separated out example and tried to make it better-defined
b) @thomas-fossati - added 2 sentences to discuss the transience of the communications link and associated trust
c) @William-PanWei - tried to better explain how a Verifier would obtain information about how the communications link was established. It makes me wonder if the baseline architecture would need to be extended to encompass delegated trust.
d) @nedmsmith - I may still have a misunderstanding of what an endorsement actually means in the RATS architecture. In this example, I felt that an endorsement may have been leveraged in establishment of the communications link. Therefore an additional attestation-specific endorsement may not be necessary.

[dthaler]

Need more explanation about what "anchored to a Root of Trust" means. To trust the evidence, you have to have some assurance that the evidence is correct, and wasn't just fed to the communication link endpoint by some untrusted party.

[gmandyam]

What about the following:

"... or may have received evidence that the communications link is anchored to a Root of Trust from an entity that established the communications link. In the latter case, anchoring the communications link to a Root of Trust would mean that this entity only established a communications link with the attesting device after verifying that the device had a Root of Trust."

[mcr]

Closed in favour of PR #82.