Re: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)

Carl Wallace <carl@redhoundsoftware.com> Wed, 26 September 2018 13:08 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD15130EBB for <eat@ietfa.amsl.com>; Wed, 26 Sep 2018 06:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_EAZ4M5E6Xp for <eat@ietfa.amsl.com>; Wed, 26 Sep 2018 06:08:12 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDABE130EDD for <eat@ietf.org>; Wed, 26 Sep 2018 06:08:11 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id b19-v6so15595685qkc.6 for <eat@ietf.org>; Wed, 26 Sep 2018 06:08:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=P931J1i42D7XkHN0dFgohuJX+aOzpWhgXI3CLPrZtUo=; b=F1Oukcqx2EO1VLfM6D+ZMC99uMCryaj3B+AjXAgT86oqdyrfzUoHkIC3WH7hFkBe9+ hI8SPj5+1sKTk3hcFfwLZkANRWWVPUSO5sIz36nZqSabvE0/E9yAaM+RFY09TC3NJQLm DkqbEOEb71BMaeEtUdXtYKoJggqAIHYwQId0A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=P931J1i42D7XkHN0dFgohuJX+aOzpWhgXI3CLPrZtUo=; b=f6CQ6LiKR9zA90qEMKfzdGlrS4fB7d16YANI6GXZwVJzYTvrl9169190VGP2ptUPrH WyJ3s6jzFmSTvyueDYHoh1ku0c5arfIbUUFSSENtqpbOhoWkx+DNh6iMGu4jVJNV/X15 Bs7B+TnFoIY06wfX8Z8B0rH9cvu23L051LUEkBNIm4KKaWByjEF0UjwOP+iTFZLY+g8V xRsfsGoJ0icziOS+huCXOdGUkfM3h2b/fhVwKSRBGmUcC9/wu1APqlTuVxfMYw+AkuJB MPkF7RumcWyiZ2LBhDdJIBdzwPsueohntIPK7vbpcntRI39fcIHPc0nK2UUBIG7iDaUa AZ/g==
X-Gm-Message-State: ABuFfogosU4M9DSp7dsGSh6Z9u0f8yXzk/MuAFigXLjn24CPFu4ReUmb 2gaq5KxTRM1dVLf44I0KoCWkfQHEFU84Xg==
X-Google-Smtp-Source: ACcGV62Dbq74X94a+gBCpEc2dVALAxE0uDXmYv+EbYCyLKfrcsIL6Y7YVHvD0JSyKICI2jPrPR60Lg==
X-Received: by 2002:a37:895:: with SMTP id 143-v6mr3941585qki.99.1537967290884; Wed, 26 Sep 2018 06:08:10 -0700 (PDT)
Received: from [192.168.2.27] (pool-108-28-91-61.washdc.fios.verizon.net. [108.28.91.61]) by smtp.googlemail.com with ESMTPSA id 15-v6sm4051117qtx.44.2018.09.26.06.08.07 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 26 Sep 2018 06:08:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Wed, 26 Sep 2018 09:08:07 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Laurence Lundblade <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Message-ID: <D7D0FABC.C1B77%carl@redhoundsoftware.com>
Thread-Topic: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <9DD41A8E-CE74-45EE-B969-F42DA130FC07@island-resort.com>
In-Reply-To: <9DD41A8E-CE74-45EE-B969-F42DA130FC07@island-resort.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3620797691_2740359"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/zjh3GdphYSJ_HOesHHhleUO9wqg>
Subject: Re: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 13:08:25 -0000


From:  EAT <eat-bounces@ietf.org> on behalf of Laurence Lundblade
<lgl@island-resort.com>
Date:  Tuesday, September 25, 2018 at 2:32 PM
To:  Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:  "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Subject:  [EAT] EAT additions to Charter (was Re:  Scope, Goals & Background
for RATS)

> <snip>
> Thus, the problems to be solved are:
> * Definition of a set of interoperable, cross-platform Claims that can be made
> by Entities (end-user devices, IoT devices, device subsystems and submodules)
> * Syntax for each Claim in CBOR, JSON and YANG
> * A framework for securing (e.g., signing) Claims Conveyed to the Relying
> Party 
> * The Claims and means to secure them should be general and interoperable and
> as platform and technology neutral as possible (e.g., minimally tied to TPM,
> TrustZone, JavaCard…).
> * The definition of the Claims should be largely independent of how they are
> secured. That is, it should be possible to secure each Claim in different ways
> without affecting the semantics of the Claim.
> * The definition of the Claims should be independent of the means of
> Conveyance (e.g., independent of the transport protocol)
> * Privacy and GDPR compliance should be considered for each Claim. While not
> possible for many, Claims should be defined to be privacy preserving.
I'd include defining of verification rules to the list of problems to solve.
The term verifier appears once in the charter text, but nothing is included
to inform how verification is performed. Maybe: A framework for securing
(e.g., signing) Claims Conveyed to the Relying Party and corresponding rules
for verifying attestations to establish trust in claims
> (5) It is often the case that the manufacturer of an Entity (e.g., a chip, a
> phone, a tablet) puts some base private key in each device they make. That
> base key material can then be used to establish key material for specific use
> cases. Some Entities will host a plethora of use cases and it will be very
> enabling and efficient to be able to reuse this base private key material over
> and over (e.g., the Android KeyStore). It is also very beneficial to receive
> detailed Claims about the Entity’s trustworthiness when establishing use case
> specific keys. The base private key mentioned here is the key material used to
> perform the attestation. They problem to be solved then is the definition of
> Claims that carry use case specific public keys, possibly including proof of
> possession of those keys (e.g., a Certificate Signing Request).
I'd include specification of attributes for use in certificate request
protocols as a standards track deliverable.
> <snip>