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> 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 <https://www.ietf.org/mailman/listinfo/rats>