Implicit trust

draft-ietf-rats-architecture.md

@@ -697,6 +697,13 @@ for by hardware or by ROM code, especially if such hardware is
 physically resistant to hardware tampering.  The component that is
 implicitly trusted is often referred to as a Root of Trust.
 
+A conveyance protocol that is authenticated and integrity protected can be used
+to convey unprotected Evidence, assuming the following properties exists:
+
+   1. The key used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected claims about the Target Environment(s).
+   2. All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key that protects the conveyance channel
+   3. The Root of Trust protects both the conveyance channel key and the Attesting Environment with equivalent strength protections.
+
 In some scenarios, Evidence might contain sensitive information such as
 Personally Identifiable Information.
 Thus, an Attester must trust entities to which it conveys Evidence, to not
@@ -940,7 +947,7 @@ Carsten Bormann provided many of the motivational building blocks with respect t
 
 The table below defines a number of relevant events, with an ID that
 is used in subsequent diagrams.  The times of said events might be
-defined in terms of an absolute clock time such as Coordinated Universal Time, 
+defined in terms of an absolute clock time such as Coordinated Universal Time,
 or might be defined relative to some other timestamp or timeticks counter.
 
 | ID | Event                       | Explanation of event
@@ -1006,7 +1013,7 @@ the Verifier and the Attester.
 The Relying Party can check whether the Attestation Result is fresh
 when appraising it at time(RA) by checking `time(RA) - time(RG) < Threshold`,
 where the Relying Party's threshold is large enough to account for the
-maximum permitted clock skew between the Relying Party and the Verifier.  
+maximum permitted clock skew between the Relying Party and the Verifier.
 The result might then be used for some time (e.g., throughout the lifetime
 of a connection established at time(RA)).  The Relying Party must be
 careful, however, to not allow continued use beyond the period for which
@@ -1060,14 +1067,14 @@ by checking `time(RG)-time(NS) + time(EG)-time(VG) < Threshold`.
 Similarly if, based on an Attestation Result from a Verifier it trusts,
 the Relying Party decides that the Attester can be trusted to correctly
 provide time deltas, then it can determine whether the Attestation
-Result is fresh by checking 
+Result is fresh by checking
 `time(OP) - time(NS') + time(RR)-time(EG) < Threshold`.
 Although the Nonce2 and time(RR)-time(EG) values cannot be inside
 the Attestation Result, they might be signed by the Attester such
 that the Attestation Result vouches for the Attester's signing
 capability.
 
-The Relying Party must still be careful, however, to not allow continued 
+The Relying Party must still be careful, however, to not allow continued
 use beyond the period for which it deems the Attestation Result to remain
 valid.  Thus, if the Attestation Result sends a validity lifetime
 in terms of time(RX)-time(RG), then the Relying Party can check
@@ -1091,7 +1098,7 @@ clocks between the Attester, Verifier, and Relying Party.
         |----Evidence------->|                           |
         |    {time(EG)}   time(ER)--Evidence{time(EG)}-->|
         |                    |                        time(RG)
-        |                 time(RA)<-Attestation Result---|    
+        |                 time(RA)<-Attestation Result---|
         |                    |        {time(RX)}         |
         ~                    ~                           ~
         |                    |                           |
@@ -1123,7 +1130,7 @@ the Relying Party needs to send one to an Attester.
      |----Evidence{Nonce}--->|                           |
      |                    time(ER)--Evidence{Nonce}----->|
      |                       |                        time(RG)
-     |                    time(RA)<-Attestation Result---|    
+     |                    time(RA)<-Attestation Result---|
      |                       |      {time(RX)-time(RG)}  |
      ~                       ~                           ~
      |                       |                           |
@@ -1137,7 +1144,7 @@ However, unlike in Example 2, the Relying Party can use the Nonce to
 determine whether the Attestation Result is fresh, by verifying that
 `time(OP) - time(NR) < Threshold`.
 
-The Relying Party must still be careful, however, to not allow continued 
+The Relying Party must still be careful, however, to not allow continued
 use beyond the period for which it deems the Attestation Result to remain
 valid.  Thus, if the Attestation Result sends a validity lifetime
 in terms of time(RX)-time(RG), then the Relying Party can check