Re: [EAT] [Rats] Attestation BoF charter updates?

  A quick feedback about charter/ietf-rats-charter.md

  The introduction mentions:
  "In summary, RATS expose trusted claim sets to detailed Attestation
  Evidence enables a Verifying Party
               to retrace every step that led to its current Operational
  State.

  Such set of claims may be useful in some contexts, but not always. In
  many cases, it is sufficient to know that the device supports
  a set of operations/functionalities and that it operates as expected,
  does what is required and does not do other things (e.g. no back door
  is present).
  A typical example is a secure element, like a smart card.

  The "Problem Statement" is currently described as follows:

(1) Establishing a sufficient level of confidence that a communication 
partner is a trustworthy endpoint. This is a fundamental challenge.
      Currently, there are no agreed upon standards that define a 
minimal set of Reference Values and Attestation Evidence that distinguishes
      a trustworthy execution environment over one that isn't.

The question is not only whether the device has a trustworthy execution 
environment or not, but whether the device is capable to support a specific
set of functions (obviously using a trustworthy execution environment).

The "Problem Statement" (1)**should be rephrased as:

"Establishing a sufficient level of confidence that some data originates 
from a trustworthy device (e.g., an end-user device, platform or endpoint,
servers, IoT devices, device subsystems and sub-modules) designed to 
support a specific set of operations/functionalities and that it operates
as expected, does what is required and does not do other things that 
could impact the security of that set of operations/functionalities 
(e.g. no back
door is present).

The "Problem Statement" continues as follows:

(2) Today, there is no common, standard way for Relying Parties to know 
the provenance and characteristics of a device (e.g., an end-user device,
platform or endpoint, servers, IoT devices, device subsystems and 
sub-modules) that may be requesting services.

Knowing the provenance of the device is not always necessary. What is 
important is to know that a specific set of functions is (securely) 
supported by the device.
There already exists a common way to know the characteristics of a 
device by issuing to the device a public key certificate which will only 
be issued to the device
if it fulfills an expected set of functionalities. In such a case a 
syntax for a trusted claim sets**is not needed.

The simplest cases should also be part of the framework.

Note: I personally appreciate that privacy is an aspect that will/should 
be taken into consideration.

Denis

> As with the earlier draft, there are many references to verify and
> verifier in the lead up to the deliverable but no deliverables describing
> verification rules. I'd like to see rules in one of these documents and
> think it worth citing in the deliverables. Are bindings to certificate
> management protocols out of scope?
>
> On 10/11/18, 9:49 AM, "RATS on behalf of Henk Birkholz"
> <rats-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de> wrote:
>
>> Hi all,
>>
>> sorry for the delay. Please find an updated charter proposal here:
>>
>>> https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md
>> The BoF proponents tried to merge all comments and proposals on
>> keystores, existing solutions, provenance & device characteristics, etc
>> that were raised on the list - and align them in homogeneous fashion.
>>
>> This draft is intended to focus the discussion and improve the wording.
>>
>> Viele Grüße,
>>
>> Henk
>>
>> On 10/06/2018 08:23 AM, Laurence Lundblade wrote:
>>> Hi Henk,
>>>
>>> Bangkok IETF is getting close, will you be able to update the charter
>>> for the attestation BoF to properly include EAT?  I sent you some text
>>> that just needs to be pasted along with some comments. It doesn’t look
>>> like there’s been any updates.
>>>
>>> LL
>>>
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
>
> _______________________________________________
> EAT mailing list
> EAT@ietf.org
> https://www.ietf.org/mailman/listinfo/eat