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

Carl Wallace <carl@redhoundsoftware.com> Tue, 23 October 2018 19:56 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 87F67130E9D for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 12:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham 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 6Glqn_UXCq-c for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 12:56:54 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 D44A6130E5C for <eat@ietf.org>; Tue, 23 Oct 2018 12:56:53 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id b14-v6so2588747qtr.11 for <eat@ietf.org>; Tue, 23 Oct 2018 12:56:53 -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=XqqgaFimMWI08cdkWVJVs/zZw9B3lZMN1ERRwwzzkVc=; b=HJCL7os4vrIbVKInVB3RhGWk1nVemHKDojhQ/pnQ1it0a6oNbhjM3yOeJs3i/A18qt AjoHtEvsDCBUGJl/6XvQDzd63utj0DV4wV5h375q32IMZfbGz9ojNLeXVDEI/h0FUqWJ GMufyaiRoSLQNZpR6GKwRNl3jzHxUt7CCJj30=
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=XqqgaFimMWI08cdkWVJVs/zZw9B3lZMN1ERRwwzzkVc=; b=FWtdrRD+3g+ejuDTjhjWvaz8yW47+bwSWhnM4STgSckvZbZKgR+X9mngFQy3qCudy5 f9lLN7nO3JykSHP4wLA5iXl3TmMqLmHkRST02FqwgNAjRDXe0scewn8d/qZZpkKdiwKm iRsXzMHdcb5CyOVYuo8IAP40jTf34Q+xLHezqjYMSl75fLRrViouLuzjlXiqnKJlpneh EHa3McxxfQmC1OjVj3ogDpYIHqp7NyA7KsQQUkCeczW+U5uKvcOL28bVtEaPFlEHDfRY aVuX30M4UooTFx0qbeCxpefZQwaSk7/14/dBpKPBHqCY9enNVgtfFSISAj1jlmagK1PK OD8Q==
X-Gm-Message-State: AGRZ1gLCGXWmewUJ7LCpVy1HtbJymojYz+RuTSlwl2knRvhvp6xaFXq8 mJ7EomO2XegzQOpSaVhL4NXzYg==
X-Google-Smtp-Source: ACcGV61JibX7aDUL96a3YPyRAmsnMO5XNwop5WyTYl28wazvrl6FJ8Ab9XT4kk5GWAZgbBqClCovjg==
X-Received: by 2002:ac8:191a:: with SMTP id t26-v6mr17010547qtj.327.1540324612805; Tue, 23 Oct 2018 12:56:52 -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 4-v6sm1902100qtx.46.2018.10.23.12.56.49 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 23 Oct 2018 12:56:52 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Tue, 23 Oct 2018 15:56:44 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Message-ID: <D7F4F507.C3DB6%carl@redhoundsoftware.com>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
References: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com> <e0c3f17f709140b7a546eeced55d522b@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <e0c3f17f709140b7a546eeced55d522b@NASANEXM01C.na.qualcomm.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623155011_17934164"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/r_lJMyQ3mXyTracXyLm5ELhUK5I>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
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: Tue, 23 Oct 2018 19:56:58 -0000

inline

From:  Giridhar Mandyam <mandyam@qti.qualcomm.com>
Date:  Tuesday, October 23, 2018 at 3:53 PM
To:  Carl Wallace <carl@redhoundsoftware.com>om>, Jeremy O'Donoghue
<jodonogh@qti.qualcomm.com>om>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc:  "rats@ietf.org" <rats@ietf.org>rg>, "eat@ietf.org" <eat@ietf.org>
Subject:  RE: [EAT] [Rats]    Attestation BoF charter updates?

> [CW] As noted before, I'd like to see binding to certificate enrollment
> protocols included here as well. This is something we are doing today, without
> standards grounding (as illustrated in pile of attestations shared via Github
> a few weeks back).
>  
> Why isn’t ACME applicable  (https://datatracker.ietf.org/wg/acme/about/)?
> Granted, it is optimized for the web currently.  But from a message format
> perspective I don’t think we need to re-invent the wheel.
[CW] I have not suggested defining new certificate management specs, just
codifying the binding of attestations to one or more certificate management
specs. In my case, I am using SCEP (for legacy installed base purposes).
>  

> -Giri Mandyam, Qualcomm
>  
> 
> From: EAT <eat-bounces@ietf.org> On Behalf Of Carl Wallace
> Sent: Tuesday, October 23, 2018 8:15 AM
> To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>om>; Michael Richardson
> <mcr+ietf@sandelman.ca>
> Cc: rats@ietf.org; eat@ietf.org
> Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
>  
>> 
>> 
>> <snip>
>> Work Items
>> ----------
>> The Working Group will develop specifications supporting the creation of
>> interoperable remote attestation procedures for entities which incorporate
>> Roots of Trust. The main deliverables are as follows.
>> - Produce a requirements document establishing a common vocabulary for remote
>>   attestation, identifying mechanisms which will be supported for
>> establishing
>>   trust between an entity and a remote party, and enumerating sample
>> use-cases
>>   for remote attestation.
>> - Produce specification text defining interoperable cross-platform claims
>> which
>>   provide information about an entity in support of the required use-cases,
>> and
>>   extending the set of claims defined in RFC7519 and RFC8392. The
>> specification
>>   will describe the syntax for each claim in at least the following formats:
>>     - CBOR [RFC7049]
>>     - JSON [RFC7159]
>>     - YANG [RFC6020]
> 
> [CW] ASN.1 is already player for a number of attestation formats. Any reason
> to exclude it?
> 
>  
>> 
>> - Produce specification text defining procedures and corresponding
>> architectures
>>   supporting verification of claims within an attestation based on measured
>> file
>>   execution procedures and supporting:
>>     - Explicit attestation wherein a set of claims is transported in the
>> attestation;
>>     - Implicit attestation wherein a set of claims is implied by possession
>> of a secret.
>> - Produce specification text defining procedures and corresponding
>> architectures
>>   supporting verification of claims encapsulated in:
>>     - CBOR Web Token structures [RFC8392]
>>     - JSON Web Token structures [RFC7519]
> 
> [CW] As noted before, I'd like to see binding to certificate enrollment
> protocols included here as well. This is something we are doing today, without
> standards grounding (as illustrated in pile of attestations shared via Github
> a few weeks back).
> 
>  
>> 
>> - Perform privacy analysis of both claims and the cryptographic procedures
>> used to
>>   establish trust. This information will be included as appropriate in the
>>   deliverable specifications, and may imply extension of procedures defined
>> in
>>   other specifications in support of privacy goals.
>> 
>>  
>> 
>> It seems to me that there are two ways to produce the main specification
>> deliverables. I have deliberately left the text above slightly vague on this.
>> * A claims specification common to RATS and EAT with separate RATS and EAT
>> procedure specifications.
>> * A claims specification also incorporating EAT procedures and a separate
>> RATS procedure specification. This would be my preferred option.
>>> * I believe there are very few procedures needed for EAT other than the
>>> possible need to support a nonce to ensure freshness
>>  
>> 
>> Jeremy
>>> 
>>> 
>>> Notice how by about the second paragraph (6tisch takes a bit longer), each
>>> gets into what the WG will do?
>>> 
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> _______________________________________________
>>> EAT mailing list
>>> EAT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eat
>>  
>> _______________________________________________ RATS mailing list
>> RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats