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

Carl Wallace <carl@redhoundsoftware.com> Tue, 23 October 2018 15:15 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 C040B130E37 for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 08:15:08 -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=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 vPiEtN9AP884 for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 08:15:06 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 610EB130E3C for <eat@ietf.org>; Tue, 23 Oct 2018 08:15:06 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id z9-v6so1880281qto.7 for <eat@ietf.org>; Tue, 23 Oct 2018 08:15:06 -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 :mime-version; bh=kkX/B9wgrL2SC0yO2xZYuyq41YcNmm7McaLej38Jtgk=; b=Pgcas4f5HW6Jz5phcfdyRrtCUNfm8hlND0Pp2O5dYqMRxOjgkFe+ie8jizqwPB9+nL F+ILZUxlG2bcJSE/XJ6hIahBepZxD2TOdz8yKmD8CgTWELrtv5c22Tc8xXqbzAR7g3rS ZdVP+lnNCBt1Fq+UsyuQy/wnjRcx13Zbcb6Qo=
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:mime-version; bh=kkX/B9wgrL2SC0yO2xZYuyq41YcNmm7McaLej38Jtgk=; b=NeNKoPOgXDEuEDjcsnsb9i6NxXKFx8V7ajnAJpxC+//aQXWCCx98J8gpr4tadEcx7p YyAN/kJ81BTvDJQx8jXANimV/iO1OeU+T8G8fG4Fuq5xaQ44kcq2dWREn1fFhtGyO+YS ONFOAvIRUnlKBXDoWfaHBbjxmSRNHdSHtGznm3DIT6hERSrgCrHunjeH8qbJooBfMxc2 Ixux3GLvo8cC8ccFPwlUL0eMK1Ws89pzc/HJcfpXWxgHUz+Toj6d6KfiF3xlboIGTBFh /mwKheenAeF/W6sqNxyNB4XZYiKgfzpvgi4AS+8G0ObevHyBPca7qIdLoOWtANiRhlSt Zpww==
X-Gm-Message-State: AGRZ1gLzHBGlrYom6sr7Aj/qtGReeR6hP9zLhi+Z6+2UdJSCdcfsf2WO vphT5bDPG8KBRXfwcA94V5TY0g==
X-Google-Smtp-Source: AJdET5dznXA4PRp80iwVZDKPntTicvAJYwo1bZdFOjY7B3UNFOeiWss3aSe8Sf68WriB2VbBV3+CNA==
X-Received: by 2002:a0c:ed50:: with SMTP id v16mr1466321qvq.64.1540307705317; Tue, 23 Oct 2018 08:15:05 -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 m13-v6sm1267506qtm.20.2018.10.23.08.15.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 23 Oct 2018 08:15:04 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Tue, 23 Oct 2018 11:14:59 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: 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: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com>
Thread-Topic: [Rats] [EAT] Attestation BoF charter updates?
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623138104_16942883"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/mVhQm1XZs-ev5MjaijXEgUPGnkc>
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 15:15:09 -0000

> 
> <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