Re: [Rats] draft-ietf-rats-architecture-04

Hi Hannes,

we will most certainly take your comments into account and I will add an 
issue on "environments" definitions. Thanks!

In an ideal case, every message type (evidence, endorsement, attestation 
result, policies, and complementary documents) will be encoded the same. 
I'd assume that only "new" or very well-scoped or well-controlled 
domains will be able to do that, today. There is the "bow-tie" diagram 
in the architecture that illustrates potential mixes of "message 
formats", which are referred to encodings in the text. One target of the 
architecture is to explicitly not prescribe an encoding here.

Having said that, some things are easier, if the encoding is identical 
(aside from the typical suspects, such as cost, interoperability, or 
foot-print). One of these things is the composition of composite 
evidence that can also include attestation results and potentially even 
endorsements. In cases that build on composite evidence, attestation 
results might traverse other entities than relying parties. It is most 
certainly possible to augment the exemplary model "passport" as well as 
"background-check" to that extent.

Every "model" and the corresponding flow of conceptual messages (and 
their encodings) is never prescriptive but intended to be expositional.

Viele Grüße,

Henk

On 16.06.20 12:23, Hannes Tschofenig wrote:
> Hi Henk,
> 
> Reading through Section 8.1 I wonder whether the definition from the terminology should be replaced by how you define it in Section 8.1. FWIW you might want to add the term "Target Environment" to the terminology section as well since you use it in various places in the document.
> 
> Is there actually a difference in the message format between evidence and attestation result? For example, could an EAT token be used for encoding evidence and the attestation result? Evidence can travel from the attester to the verifier and to the relying party but the attestation result can only be omitted by the verifier. Maybe I missed it but I couldn't find a case where a message exchange is just between an attester and a relying party. Is this not possible?
> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
> Sent: Tuesday, June 16, 2020 11:14 AM
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Laurence Lundblade <lgl@island-resort.com>
> Cc: rats@ietf.org
> Subject: Re: [Rats] draft-ietf-rats-architecture-04
> 
> Hi Hannes,
> hi Laurence,
> 
> I think "evidence" vs. "information" is a very good example that shows why the text stabilized in the shape it is in now.
> 
> I am pretty sure that - and please speak up, if I am missing some vital point here - evidence is not simply information. At the very least there has to be a method to prevent (e.g. secure channel) or even detect (e.g. a signature) tampering with evidence. It also must originate from an attester, etc. So there are a lot of characteristics that are tied to evidence that make it at least a subclass of information.
> 
> This is only a small arbitrary example to illustrate how that minimal set of definitions came to be.
> 
> I totally agree that the definition of Evidence early on is not in alignment with the text (which I also think is better) anymore, but an issue about Evidence text is already in the tracker thanks to Kathleen and we will work on a more crisp description after the current open PR are settled.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> On 16.06.20 10:51, Hannes Tschofenig wrote:
>> Hi Laurence,
>>
>> as you explain below it might help to replace some of the terms with
>> others. I think the description does not make it easy to explain the
>> concepts to those who should actually be using them. I did the review
>> because I tried to explain the concept in a lecture to students.
>>
>> For example, the term “information” (or claims) sounds a lot simpler
>> to understand less sophisticated than “evidence”. Particularly, when
>> the term “evidence” is then described as “A set of information about
>> an Attester that is to be appraised by a Verifier”. (The definition
>> later provided in the text is actually better but does not match the
>> definition earlier in the document. Inconsistency likely caused by
>> duplicating text throughout the document.) I earlier description is
>> IMHO actually wrong. For example, why does the verifier needs to be
>> present in all scenarios? In fact the models in Section 5 suggest
>> otherwise. Why cannot a device send the claims to a relying party? The
>> case where you need a verifier to interpret the claims may be a corner
>> case in some environments. Why is the information about an attester?
>> It better describe the characteristics of the device, as it is said in Section 8.1.
>>
>> If you look at the whole exercise from a 10,000 foot view then we are
>> essentially using design patterns from the identity management space
>> and apply it here with slightly different information. That’s in a
>> nutshell where the models in Section 5 came from.
>>
>> Ciao
>>
>> Hannes
>>
>> *From:* Laurence Lundblade <lgl@island-resort.com>
>> *Sent:* Tuesday, June 16, 2020 3:37 AM
>> *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>
>> *Cc:* rats@ietf.org
>> *Subject:* Re: [Rats] draft-ietf-rats-architecture-04
>>
>> Hi Hannes,
>>
>> I think readability of the document could be improved and maybe some
>> simplification would be OK, but I generally think most of the core
>> entities and messages make sense.
>>
>>
>>
>>      On Jun 9, 2020, at 12:13 AM, Hannes Tschofenig
>>      <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>> wrote:
>>
>>      Hi all
>>
>>      I have re-read the architecture document and IMHO it is still far
>>      too complex. It makes the reader believe that attestation is some
>>      rocket-science concept, which it just isn’t. After such a long time
>>      the document is unnecessarily hard to read and understand.
>>
>>      Here is the story as I see it.
>>
>>      In the basic form a device puts a bunch of claims together and then
>>      signs them. The device is the attester.
>>
>>      Then, this information is sent to another party, the relying party,
>>      which uses this information for some kind of decision making.
>>
>> Evidence is just the name for “this information”.
>>
>>
>>
>>      Of course, there is some prior setup that has to happen
>>      (provisioning of keys during manufacturing) and some assumptions
>>      have to be made as well (attestation code on the device has to be
>>      well protected, code isolation being used, etc.).
>>
>> Endorsements are the mechanism by which this happens.
>>
>>
>>
>>      Then, there is the a complex case where the relying party cannot use
>>      the received information directly. This is most likely related to
>>      any form of software measurements. If you send a hash of a
>>      bootloader to some relying party you cannot really expect it to be
>>      used for anything. The reason the relying party cannot use that
>>      information directly is because it does not know what software the
>>      device is really supposed to be running. Hence, there is a need to
>>      consult another party (let’s call it the verifier). The assumption
>>      is that this party knows what the expected fingerprint is and hence
>>      what software is running on the device.
>>
>> Which is why the terms Verifier and Results are used.
>>
>>      That’s all. There is not much more complexity to this topic.
>>
>> I personally would be happy without the Owners and the Appraisal
>> Policies in the architecture as they seem obviously implied, but not
>> enough to ask they be removed.
>>
>>      So, where do all these terms come from? Appraisal policies,
>>      evidence, endorser, ...
>>
>>      I would delete them and see whether the idea still gets across.
>>
>> I think more clear writing would help.
>>
>> (We could put text in https://www.scribens.com and look at the Flesch
>> and Gunning Fog indexes for readability under statistics)
>>
>> LL
>>
>>
>>
>>      Ciao
>>
>>      Hannes
>>
>>      IMPORTANT NOTICE: The contents of this email and any attachments are
>>      confidential and may also be privileged. If you are not the intended
>>      recipient, please notify the sender immediately and do not disclose
>>      the contents to any other person, use it for any purpose, or store
>>      or copy the information in any medium. Thank you.
>>      _______________________________________________
>>      RATS mailing list
>>      RATS@ietf.org <mailto:RATS@ietf.org>
>>      https://www.ietf.org/mailman/listinfo/rats
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose
>> the contents to any other person, use it for any purpose, or store or
>> copy the information in any medium. Thank you.
>>
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
>>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 