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

[Jeremy O'Donoghue <[e-mail]>]

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]><mailto:[e-mail]@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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats



_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat



_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat