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

[Denis <[e-mail]>]

Hello Jeremy,

In your reply, you have deleted many of my sentences, in particular you 
have deleted:

    The simplest cases should also be part of the framework.

I don't deny that complex cases may need to be taken into consideration, 
but simple cases should also be taken into consideration.

You wrote:

    having the entity creator/manufacturer provide a set of claims which
    can be verified is more flexible than requiring a certificate.

May be it might be "more flexible", but certainly more complex to check. 
The provenance of the device is not the most important information to get.
The most important information to get is a guarantee of the support of a 
set of required functions and features.

Denis


> On 12 Oct 2018, at 14:33, Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>> 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.
>>
> This is indeed a possible way to address the problem, but suffers from 
> challenges which come down to:
>
> - Who issues such certificates. An option is that there is some form 
> of security certification behind this issuance otherwise it is of very 
> limited value.
> - In order to capture the wide variety of different devices (I prefer 
> "entity" here as it is more general than "device"), many different 
> forms of such certificates would be required. This ends up being much 
> the same thing as a set of claims.
>
> Given the multiplicity of entities for which attestation might be 
> useful, it seems to me that having the entity creator/manufacturer 
> provide a set of claims which can be verified is more flexible than 
> requiring a certificate. It seems likely to me that where a formal 
> security certification is needed there will be a certificate issued by 
> the Certifying Body as one of the claims about an entity, but I can 
> think of many cases (supply chain management, to take just one 
> example) where provenance is by far the most useful information.
>
> I'm not in favour of changes to the charter in this direction.
>>
>> 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"
>>> <[e-mail] on behalf of [e-mail]>  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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rats
>>> _______________________________________________
>>> EAT mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/eat
>>
>>
>> _______________________________________________
>> EAT mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/eat
>