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

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, June 16, 2020 3:37 AM
To: Hannes Tschofenig <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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.