From nobody Thu Nov  1 06:22:55 2018
Return-Path: <kaduk@mit.edu>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BF11277BB for <rats@ietfa.amsl.com>; Thu,  1 Nov 2018 06:22:52 -0700 (PDT)
X-Quarantine-ID: <kqLbo67UzOl2>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 kqLbo67UzOl2 for <rats@ietfa.amsl.com>; Thu,  1 Nov 2018 06:22:50 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D66129AB8 for <rats@ietf.org>; Thu,  1 Nov 2018 06:22:09 -0700 (PDT)
X-AuditID: 1209190c-791ff70000001b9d-4f-5bdafdffbcaf
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.AB.07069.00EFADB5; Thu,  1 Nov 2018 09:22:08 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wA1DM3MK006579; Thu, 1 Nov 2018 09:22:05 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA1DLvq8023564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Nov 2018 09:22:02 -0400
Date: Thu, 1 Nov 2018 08:21:57 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Roman Danyliw <rdd@cert.org>
Cc: "rats@ietf.org" <rats@ietf.org>
Message-ID: <20181101132157.GV45914@kduck.kaduk.org>
References: <359EC4B99E040048A7131E0F4E113AFC0181A32A81@marathon>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0181A32A81@marathon>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUixG6nrsvw71a0wdRb0hbLlu9it/jcxubA 5DFjg4/HkiU/mQKYorhsUlJzMstSi/TtErgybrxIK9ioUfFtwgqmBsZbCl2MnBwSAiYSDe/O sHUxcnEICaxhkvj84TorhLOBUWLL3o9QmTtMEo1//zCBtLAIqEg0fWplBrHZgOyG7stgtoiA gsT99ftZuhg5OJgFlCW23c0ACQsLWElsOnaSFcTmBdr2dRnITE6gmY4Sn39uYIOIC0qcnPmE BcRmFtCSuPHvJRPEGGmJ5f84QMKcAk4Si3sug40RBZq+t+8Q+wRGgVlIumch6Z6F0L2AkXkV o2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZGUHhySvLsYDzzxusQowAHoxIPr4bU rWgh1sSy4srcQ4ySHExKorzfrgCF+JLyUyozEosz4otKc1KLDzFKcDArifBOvgCU401JrKxK LcqHSUlzsCiJ805oWRwtJJCeWJKanZpakFoEk5Xh4FCS4G35A9QoWJSanlqRlplTgpBm4uAE Gc4DNDwBpIa3uCAxtzgzHSJ/ilFRSpx3zW+ghABIIqM0D64XlD4ksvfXvGIUB3pFmHcFSDsP MPXAdb8CGswENJiL/QbI4JJEhJRUA+OGdfObtFfVvuNPjInmtbv/Ss5ma75E6zLbAwFy38S5 5c6Fv3r/ryg/MfL83sALponxwcwfylOfCywMmdnZYby2kSch4MmPlhun/5ee2lunFbEsyfPz vzl5lpvKzhy993va252RF02+7jd1lC85+/y9U/mM5FVuyQwJ1/OSeqc+nRXB/Da3W1qJpTgj 0VCLuag4EQBf7qWx+gIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/rfOuGcQbRiIJg_VPwcLiVqpeJtg>
Subject: Re: [Rats] Feedback on the RC3 draft charter text
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2018 13:22:53 -0000

Hi all,

On Fri, Oct 26, 2018 at 07:54:52PM +0000, Roman Danyliw wrote:
> Hello!
> 
> I reviewed the v3 draft charter text at https://github.com/ietf-rats/charter/blob/RC3/ietf-rats-charter.md, and had the following feedback/recommendations/questions:

Dropping off some slightly scattered thoughts on the RC3 charter text
before I get on a plane ... sorry that they are not more well-formed.

I think we need to establish early on in the text (and use uniformly)
"systems and entities" as being the hardware of interest, and "roots of
trust or trust anchors" as the (crypto) mechanism to which attestation
claims will chain in order to be trustable.  This will help avoid ambiguous
parsings of later text as "(systems) and (entities that ...)"

I think I agree with Roman that the enumerated points in the "High Level
Goals" section could be dropped (which is good, since I also had trouble
parsing them unambiguously).

In the "high level goals":

The use of "trust*" words is a bit confusing, especially as to what is
already done and what the WG would need to do.  Maybe reordering "remote
entities" and "trust relationships" would help?  (Something like "A goal
of the RATS WG is to allow interaction with remote entities in a way that
can bootstrap a trusted relationship with the remote peer, leveraging
existing roots of trust or trust anchors available to the peer.", perhaps?)

There is probably a giant minefield about the precise meanings of "trust",
"trusted", "trustworthy", "trustable", etc. that we don't want to spend too
much time on pre-chartering.  That said, it would still help to keep in
mind while writing that not everyone has to trust the same people or
things, and so "trustworthy"/"trusted" are going to be relative to some
specific observer/party.  I will try to refrain from putting my thoughts on
"trust" into this thread; perhaps they will be appropriate in a later
thread.

I also don't know how the "correspondingly" follows in this section, and it
seems like the full-device attestation will be using one trust relationship
to bootstrap another (from the root to the communication peer).

[begin potentially obsolete comments]
In:
    1. Standardized and interoperable mechanisms to establish a sufficient
    level of confidence that data originates from trustworthy systems designed
    to support a specific set of operations/functionalities.

Are the mechanisms designed to support [things], or the trustworthy
systems?

In:
    2. Standardized and interoperable mechanisms building on (1.) to allow relying
    parties to know the attestation provenance and characteristics with respect
    to systems from which it may request services, consume information or to
    which a relying party may provide information.

I am not sure I can parse it correctly.  Does the RP need (attestation
provenance) and ([something else]), or (attestation (provenance and
characteristics)) with respect to [something]?
The best parse I can come up with is that the [something] ends up being
"with respect to systems", and the final list being descriptions of
attributes of the particular systems in question.  But "with respect to
systems" doesn't seem to add any value, leaving me confused.
[end potentially obsolete comments]

In the Program of Work:

When I see "establishing trust relationships" my first thought is some form
of initial contact when I go from a vacuum to "I will trust this entity [in
scope X]".  What we're doing here (IIUC) is more of a trusted introduction,
in that I already trust something and am leveraging that existing trust to
get a relationship with a new device/entity.  So, looking back at what I
just wrote, maybe I'm just uncertain about the verb "establishing", since
the thing we are getting does feel like a "trust relationship".  Perhaps
that suggests using "bootstrapping" or "forming", or adding a qualifier
"via trusted introduction".

(2) talks about "required use cases", but (1) only provides "sample
use-cases".  How will the required use cases be determined?

I'm also apparently missing a step between the modeling languages and
specifying syntax for claims -- I don't know whether the bridge between
them necessarily needs to be in the charter, but I'm not really seeing how
YANG at least comes into play for the described work.

I wonder if (4) has more detail than we need in a charter -- do we have to
say "reference values" and "measured file execution" to convey the intended
work and scope?

For (5), I doubt that the service graph depends on CWT vs JWT; the
verification procedures probably don't differ much either, once you have
parsed the things.  So maybe this could be refactored to just say "specify
procedures ... or appraisal of evidence.  [CWT] and [JWT] formats will be
considered for this work."


Some wording nits as well:

"establish trust in the trustworthiness of devices and services" is strange
wording

"claims or specific evidence about" could be "about one or more of the
following" to avoid an awkward dangling ", or".

"in encapsulated in" is redundant

-Ben


From nobody Sun Nov  4 01:15:10 2018
Return-Path: <rdd@cert.org>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE89127332 for <rats@ietfa.amsl.com>; Sun,  4 Nov 2018 01:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 eC3sls35sGt2 for <rats@ietfa.amsl.com>; Sun,  4 Nov 2018 01:15:06 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76F2130DCF for <rats@ietf.org>; Sun,  4 Nov 2018 01:15:05 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wA48F2iX006637 for <rats@ietf.org>; Sun, 4 Nov 2018 03:15:02 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu wA48F2iX006637
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1541319302; bh=mCnRbNn8SI8b1E5U1X73FMQrz1JEhPBdUhsKOywVa+4=; h=From:To:Subject:Date:From; b=ArStSxBfdE39eqbTCgUf38P8Bt2r8XfTqX8uieglmQL1iLIZdTgb3XgYESDnE0jvo mm55bwWdJuYyux29DSvsdMyQlK7prq1ndhv8aNhDcuO15oKYllxGEGIYBdwt1ZRX6/ jWgd08MSi6baZOob0mECMfKmwPzv5SybbCZwimno=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wA48F1vQ012128 for <rats@ietf.org>; Sun, 4 Nov 2018 03:15:01 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Sun, 4 Nov 2018 03:15:01 -0500
From: Roman Danyliw <rdd@cert.org>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Updated draft charter language
Thread-Index: AdR0FeOJ/nP3IkNJTXiwuthGOc+qkg==
Date: Sun, 4 Nov 2018 08:15:00 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0181A3A371@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/bWdNzawt1A3E0Uyt2lOnMEZmRJw>
Subject: [Rats] Updated draft charter language
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 08:15:09 -0000

Hello!=0A=
=0A=
An update to the draft RATS charter can be found at:=0A=
https://github.com/ietf-rats/charter/blob/RC4/ietf-rats-charter.md=0A=
=0A=
Regards,=0A=
Roman and Nancy=


From nobody Sun Nov  4 06:01:39 2018
Return-Path: <kaduk@mit.edu>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14011200D7 for <rats@ietfa.amsl.com>; Sun,  4 Nov 2018 06:01:37 -0800 (PST)
X-Quarantine-ID: <c-BMMdzDdOQm>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 c-BMMdzDdOQm for <rats@ietfa.amsl.com>; Sun,  4 Nov 2018 06:01:36 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49B2120072 for <rats@ietf.org>; Sun,  4 Nov 2018 06:01:35 -0800 (PST)
X-AuditID: 1209190f-d81ff7000000704b-9f-5bdefbbd5314
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 26.5A.28747.EBBFEDB5; Sun,  4 Nov 2018 09:01:34 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wA4E1Tcp029477; Sun, 4 Nov 2018 09:01:30 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA4E1M2M014219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 4 Nov 2018 09:01:28 -0500
Date: Sun, 4 Nov 2018 08:01:22 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Roman Danyliw <rdd@cert.org>
Cc: "rats@ietf.org" <rats@ietf.org>
Message-ID: <20181104140122.GQ54966@kduck.kaduk.org>
References: <359EC4B99E040048A7131E0F4E113AFC0181A3A371@marathon>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0181A3A371@marathon>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUixG6norvv971og/N75SyWLd/FbvG5jc2B yWPGBh+PJUt+MgUwRXHZpKTmZJalFunbJXBlnH63iLHgH1vFv5N/mRoYb7J2MXJySAiYSLxb 2sAGYgsJrGGSePMxoouRC8jewCjxYGYfG4Rzh0nizqtvjCBVLAIqEn8fvgPrYAOyG7ovM4PY IgIKEvfX72fpYuTgYBZQlth2NwMkLCxgJPHl72ywcl6gZa92/maCWOYocfrZVyaIuKDEyZlP WEBsZgEtiRv/XjJBjJGWWP6PAyTMKeAk0dT7BuxmUaDpe/sOsU9gFJiFpHsWku5ZCN0LGJlX Mcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBIUnpyT/DsY5Dd6HGAU4GJV4eCf8 vBstxJpYVlyZe4hRkoNJSZTXmfdOtBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXrXee9FCvCmJ lVWpRfkwKWkOFiVx3gkti6OFBNITS1KzU1MLUotgsjIcHEoSvDa/gBoFi1LTUyvSMnNKENJM HJwgw3mAhquC1PAWFyTmFmemQ+RPMSpKifP++QmUEABJZJTmwfWC0odE9v6aV4ziQK8I84oD k4kQDzD1wHW/AhrMBDQ4+s9tkMEliQgpqQbGuXouk5j+32b1FJkm+tzMUD7CNEPgiNFWr3iZ znOqclL/VEr0df5HrVbQO+7ic131qEZ67ceg7kSFpqfvUup0dQ7qu7a3XEqVXxL5+v2yz58a ot9aLzimvUP1lqIjB9cDXvu/+e2buMr2Z85JfNSpvPaAsuCOe0/qjq52e3pX9/CUIwdPTQ1S YinOSDTUYi4qTgQApTZvk/oCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/AHJ-Easw6Y7xpzPRZm4lmY87BwA>
Subject: Re: [Rats] Updated draft charter language
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 14:01:38 -0000

On Sun, Nov 04, 2018 at 08:15:00AM +0000, Roman Danyliw wrote:
> Hello!
> 
> An update to the draft RATS charter can be found at:
> https://github.com/ietf-rats/charter/blob/RC4/ietf-rats-charter.md

Thanks to all who contributed; this seems to be shaping up nicely!  I only
have some nit-level comments (at least, at this late hour).

I might consider s/relied upon/trusted/ in the first paragraph of the
Scope/Problem Statement (but there are downsides to using "trust" and
derive words too much).

I might also s/These procedures include/These procedures can include/.

In the Program of Work, item 1, I think the grammar is a bit odd in
"identifying mechanisms how to form trust relationships between system
components and the relying parties via trusted introduction" (maybe just
remove the "how"?).

In item 3, s/in formats/in concrete formats/ (or similar).

-Ben


From nobody Mon Nov  5 20:26:55 2018
Return-Path: <rdd@cert.org>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6D12D4EA for <rats@ietfa.amsl.com>; Mon,  5 Nov 2018 20:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cert.org
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 mlVSS25L1Ubj for <rats@ietfa.amsl.com>; Mon,  5 Nov 2018 20:26:52 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59741294D0 for <rats@ietf.org>; Mon,  5 Nov 2018 20:26:51 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wA64Ql6F036036 for <rats@ietf.org>; Mon, 5 Nov 2018 23:26:48 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu wA64Ql6F036036
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1541478408; bh=v+cgeMFdob3r2tySye3X7ZXP1Xy7Dlr7CNW5WNilws0=; h=From:To:Subject:Date:From; b=h4hOScHbL0jVdj6mJmqx4jFJSugzaGlqFdpQYO1fiFu6Neuu6SLMCQ7QyR627+aLv g+idCeMA3ouuTddB5MyPoOd9aDD6Vva49aRHHtpZ6FoGiqfg33wSEFetHUkSJ6xmM+ LfoSdCXAO8sxbNBMbrT6djSLo8B4E4E/tWLkZ/Rs=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wA64Qhoi028725 for <rats@ietf.org>; Mon, 5 Nov 2018 23:26:44 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 23:26:43 -0500
From: Roman Danyliw <rdd@cert.org>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Draft Charter Language for BoF at IETF 103
Thread-Index: AdR1iOukOgYXtUWaTu6VbfT2WMUEAA==
Date: Tue, 6 Nov 2018 04:26:43 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0181A47FBB@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/puD1D421kFfaoAOhLpPhfLx--aY>
Subject: [Rats] Draft Charter Language for BoF at IETF 103
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 04:26:54 -0000

Hello!=0A=
=0A=
In advance of the discussion at the BoF, draft charter language has been pr=
epared by the chairs and can be found here:=0A=
=0A=
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-draft-ch=
arter-00=0A=
=0A=
Regards,=0A=
Nancy and Roman=0A=


From nobody Wed Nov 14 11:43:04 2018
Return-Path: <kaduk@mit.edu>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B30130EC6; Wed, 14 Nov 2018 11:43:01 -0800 (PST)
X-Quarantine-ID: <6Kwbz_TL4i9o>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6Kwbz_TL4i9o; Wed, 14 Nov 2018 11:42:59 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03A5130ED0; Wed, 14 Nov 2018 11:42:58 -0800 (PST)
X-AuditID: 12074423-b9bff70000006d71-20-5bec7abf1dfa
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 1D.CC.28017.0CA7CEB5; Wed, 14 Nov 2018 14:42:56 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAEJgpLj023204; Wed, 14 Nov 2018 14:42:53 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAEJgltE008310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Nov 2018 14:42:50 -0500
Date: Wed, 14 Nov 2018 13:42:47 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: rats@ietf.org
Message-ID: <20181114194247.GA99562@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUixG6nonug6k20wcRZlhY/+/YyWyxbvovd gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZh7ZPYyz4I1Sx+p1DA+Ny/i5GTg4JAROJXdsPs3Ux cnEICaxhklj95DIrhLORUWLVjI/MEM5dJonNX94ygbSwCKhKNLydAmazCahINHRfZgaxRQQE JRYe+whmCwsYStyY0swKYvMCrfj7vYMRwhaUODnzCQuIzSygJXHj30ugORxAtrTE8n8cIGFR AWWJvX2H2Ccw8s5C0jELSccshI4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJT SjcxgkPKRXkH48s+70OMAhyMSjy8J6zeRAuxJpYVV+YeYpTkYFIS5U0LexUtxJeUn1KZkVic EV9UmpNafIhRgoNZSYTX3wConDclsbIqtSgfJiXNwaIkzvtH5HG0kEB6YklqdmpqQWoRTFaG g0NJgvdAJVCjYFFqempFWmZOCUKaiYMTZDgP0PBTIDW8xQWJucWZ6RD5U4yKUuK8nyqAEgIg iYzSPLheUMxLZO+vecUoDvSKMMQKHmC6gOt+BTSYCWjwiamvQQaXJCKkpBoYnatLF/T93r/u Wv0L3X8JR5u2757zuIi/4uTJNcsVNfjOqGb/NBBVOfy7q8box8m6f/O4fqauXTy7v+lCQMDO ho5zmmxaV2JD7H7Oela9N6Lo+YMrBTFVBw7ki386tfzjwZiNv+WEPvJM31p37tXymFtvmRXW yHN3Hd+zTNksVP+R26evJmGmtUosxRmJhlrMRcWJAFe1yOXUAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/v4GfKVDIUHYYKqUAUocE6ZJgXdA>
Subject: [Rats] next steps after the RATS BoF in Bangkok
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2018 19:43:02 -0000

[bcc'd to eat@ietf.org]

Hi all,

Thanks to everyone for the productive BoF discussion in Bangkok, especially
to the chairs for organizing the session and adapting to keep us flowing
smoothly even as we deviated from the planned schedule.

During the session, I think we had broad support for work in the remote
attestation space, and some specific aspects within that space.  In
particular, I saw enough support to form a working group without
necessarily needing a second BoF.[1]  I see two likely candidates for
"minimum viable charterable work":

(1) the semantics of specific attestation claims and what preconditions
    must be present (i.e., provided by the higher level protocol) for them
    to be usable
(2) the protocol flow/structure for directly conveying an attestation
    request/response (i.e., just one bidirectional arrow of the diagram)

The initial scope could be expanded later as the WG's interests become
clear.

In order to know what starting point to use, we need to gauge the
community's level of interest: please let us know if you are interested in
working on either or both of these areas (or if you think it's the wrong
direction).

Proceeding with (2) would benefit from presenting a few concrete use cases
including all entities involved, to clarify which interaction is being
considered and which other interactions left as out of scope for the
initial work.  This could include cases like a mobile phone app (where the
phone is assumed to be powerful enough to apply policy and filter what
evidence/claims are presented to the apps' server) and measured boot (where
the device just presents measured values to an external server that must
determine validity and what information is to be conveyed to the relying
party), as well as others.  Hopefully we can keep up our momentum and get
some good discussions in the next few weeks before moving on to discussing
charter text.

In the interest of simplicity, I propose to use the rats@ietf.org list for
these discussions and close the eat@ietf.org list, since recent discussions
have been heavily overlapping and RATS was the BoF name.  (This of course
does not preclude much of anything, including reopening the eat@ietf.org
list and using a name other than RATS for the future WG.)

Thanks,

Ben

[1] This would still require the usual agreement on the mailing list,
IETF Last Call, etc.


From nobody Wed Nov 14 12:07:11 2018
Return-Path: <kaduk@mit.edu>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8E130F56 for <rats@ietfa.amsl.com>; Wed, 14 Nov 2018 12:07:06 -0800 (PST)
X-Quarantine-ID: <l5Xeg9wBXNMp>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 l5Xeg9wBXNMp for <rats@ietfa.amsl.com>; Wed, 14 Nov 2018 12:07:04 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3663130FA0 for <rats@ietf.org>; Wed, 14 Nov 2018 12:07:03 -0800 (PST)
X-AuditID: 12074425-ae1ff7000000160f-8f-5bec8064de4c
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 66.BE.05647.5608CEB5; Wed, 14 Nov 2018 15:07:01 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wAEK6x3j010075 for <rats@ietf.org>; Wed, 14 Nov 2018 15:06:59 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAEK6tOD018067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <rats@ietf.org>; Wed, 14 Nov 2018 15:06:58 -0500
Date: Wed, 14 Nov 2018 14:06:55 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: rats@ietf.org
Message-ID: <20181114200655.GC99562@kduck.kaduk.org>
References: <20181114194247.GA99562@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181114194247.GA99562@kduck.kaduk.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUixCmqrJva8CbaYPF3GYtly3exOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9PsAywFkyUqrqycwdLAuEK4i5GDQ0LAROLt/PguRi4OIYE1 TBKvln1khnCOMkrcW/uCEcL5yCQx4+UXti5GTg4WAVWJrX8b2EFsNgEViYbuy8wgtoiAoMTC Yx/BbGEBG4n5fR9ZQWxeoA17J7cwgWwTArKPtatChAUlTs58wgJiMwtoSdz49xKshFlAWmL5 Pw6QMKeAqcSuKdfBtooKKEvs7TvEPoGRfxaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFuc nJiXl1qka6GXm1mil5pSuokRFHbsLqo7GOf89TrEKMDBqMTDe8LqTbQQa2JZcWXuIUZJDiYl Ud60sFfRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4F9QAlfOmJFZWpRblw6SkOViUxHn/iDyO FhJITyxJzU5NLUgtgsnKcHAoSfBq1wM1ChalpqdWpGXmlCCkmTg4QYbzAA3/VAcyvLggMbc4 Mx0if4pRUUqcdwZIQgAkkVGaB9cLSgsS2ftrXjGKA70izPsepIoHmFLgul8BDWYCGnxi6muQ wSWJCCmpBkYt9weHj37/wGYnceTUTu/zW5q7Fx48K+Dw/2PkwVt/enndfvm+09rX8yud22VN S1byrl361SYKmkvmrclz2Xkkr0nLuTeGmz9Z4GnWWq++4n85TXLlh9Q7vdUVOjs2Fn2ql3kx VzVl7Y+VUnnLnL2qc+JtDz/9JBUYqWb7U5s3MCM8+venRCWW4oxEQy3mouJEAA6GRBHmAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/vYBCthw4dvXS6-YgNnpuUTTMaog>
Subject: Re: [Rats] next steps after the RATS BoF in Bangkok
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2018 20:07:10 -0000

On Wed, Nov 14, 2018 at 01:42:47PM -0600, Benjamin Kaduk wrote:
> 
> During the session, I think we had broad support for work in the remote
> attestation space, and some specific aspects within that space.  In
> particular, I saw enough support to form a working group without
> necessarily needing a second BoF.[1]  I see two likely candidates for
> "minimum viable charterable work":
> 
> (1) the semantics of specific attestation claims and what preconditions
>     must be present (i.e., provided by the higher level protocol) for them
>     to be usable
> (2) the protocol flow/structure for directly conveying an attestation
>     request/response (i.e., just one bidirectional arrow of the diagram)
> 
> The initial scope could be expanded later as the WG's interests become
> clear.
> 
> In order to know what starting point to use, we need to gauge the
> community's level of interest: please let us know if you are interested in
> working on either or both of these areas (or if you think it's the wrong
> direction).
> 
> Proceeding with (2) would benefit from presenting a few concrete use cases
> including all entities involved, to clarify which interaction is being
> considered and which other interactions left as out of scope for the
> initial work.  This could include cases like a mobile phone app (where the
> phone is assumed to be powerful enough to apply policy and filter what
> evidence/claims are presented to the apps' server) and measured boot (where
> the device just presents measured values to an external server that must
> determine validity and what information is to be conveyed to the relying
> party), as well as others.  [...]

I don't think I'm familiar enough with the material to present a full
use-case diagram for either of these cases, but I'll try to repeat some of
what I said at the mic line and expound a bit further on what I think I
understand so far.

Dave Thaler brought up the potential for an entity called the "attestation
server", which I (steeped in the prepared slides for the BoF) had a hard
time understanding at first; at the mic I think I characterized the
attestation server as an engine for applying policy and for potentially
reducing the initial evidence set from the device to a smaller or distinct
set of claims for conveyance to the RP.  (Dave/others, please correct me if
I've got that wrong!)  The original slides that were presented would then
have been assuming a sufficiently capable "device" entity that it would be
consolidated with the attestation server, making its own policy decisions
and choices about what claims to include in its response to the RP.

I think we probably also want to consider some concept of "owner" in at least
some of our use cases (noting that in the case of a mobile phone app this
might actually be the app author and not the device owner) -- the owner
would in my model be configuring what policy to use on an attestation
server or provisioning an ACL on a device for who is authorized to receive
evidence and/or claims.

-Ben


From nobody Fri Nov 30 07:48:55 2018
Return-Path: <rdd@cert.org>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB24128BCC for <rats@ietfa.amsl.com>; Fri, 30 Nov 2018 07:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cert.org
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 l7fV7wzqytBE for <rats@ietfa.amsl.com>; Fri, 30 Nov 2018 07:48:52 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAB3127598 for <rats@ietf.org>; Fri, 30 Nov 2018 07:48:51 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wAUFmmYq010699 for <rats@ietf.org>; Fri, 30 Nov 2018 10:48:48 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu wAUFmmYq010699
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1543592928; bh=3pXklsGq/rTbiS2Poqmys+Rtipkn/IZqsACjdGgPHtQ=; h=From:To:Subject:Date:From; b=IeUMLjd1AbsKcReU26bd8wEF4sfZ2flzv2BemixBH59fJwZ2Ryz8AnEF3iSFzZm/r f48GqzG/4MYCrsHQm6ekxvZDllVHz+uBySVz9g6aNrGgpGuPjPJKwbtjH5soHRTIrH kouRwACCi31RLSWLU3gTYe5yQRFbrKUOPw5M9C+M=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id wAUFmkUO048645 for <rats@ietf.org>; Fri, 30 Nov 2018 10:48:46 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 10:48:46 -0500
From: Roman Danyliw <rdd@cert.org>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Draft IETF 103 minutes available
Thread-Index: AdSIwzKQk9fyzz2LSA2AuLnZomAtbA==
Date: Fri, 30 Nov 2018 15:48:45 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0184C51403@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/6RVLt76L-O1CnneOb2AEFLa31r8>
Subject: [Rats] Draft IETF 103 minutes available
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Nov 2018 15:48:54 -0000

Hello!

A preliminary version of the minutes from the Bangkok meeting are available=
 at:

https://datatracker.ietf.org/meeting/103/materials/minutes-103-rats-00

If you have corrections or revisions, please provide them to the chairs.

Regards,
Roman and Nancy