Re: [Rats] Call for adoption (after draft rename) for Yang module draft

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 12 November 2019 19:14 UTC

Return-Path: <evoit@cisco.com>
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 C1C24120845 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 11:14:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gWL3Q/uc; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=nt2gRSws
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 xCd3c_Te8iPp for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 11:14:49 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DB212004D for <rats@ietf.org>; Tue, 12 Nov 2019 11:14:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38128; q=dns/txt; s=iport; t=1573586088; x=1574795688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yVx5+0+DFZTvqc5ssp/06Qu4Rp/j2c7v0ZSrgqjFdbw=; b=gWL3Q/ucUgyboNOj4gSNjzX4X8qrAIqL1hrNzGuo25OeRZxjhZyQZVfc QoCTBjBg6VYdLMo+E6nYvJH6bEJX1szN8Q4sMVyTPBmgdlELpuTV5Us7Z 8SQiTrvU7PvRO8UG65vFBwCpIH3cvyBxIEx39LlHZJiznt5sap9wQL+XO 8=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A/DJXWRxLpBF4rzjXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF0r6MNbhbjcxG4JJU1o2t3w=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AABOBMtd/5FdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYEbLyknBWwrLSAECyoKhB+DRgO?= =?us-ascii?q?Kc4JemACCUgNUAgcBAQEJAwEBLQIBAYFMgnQCgh0kNwYOAgMLAQEEAQEBAgE?= =?us-ascii?q?FBG2FNwyFUQEBAQECARILBgoTAQE3AQQLAgEIEQQBASEBBgMCAgIwFAkIAgQ?= =?us-ascii?q?BDQUIBg0HgwGBeU0DDhEPAQKkVwKBOIhgdYEygn4BAQWFDBiCEAcJgTYBgVK?= =?us-ascii?q?KQRiBQD+BEUaCTD6EHikVH4JaMoIsjSUPIAORNY8ICoIlg0uCNI9gmXmNEoE?= =?us-ascii?q?1lhCDZgIEAgQFAg4BAQWBaCOBWHAVgydQERSQNgwXgQQBAYJKilN0AYEnjXa?= =?us-ascii?q?BMQGBDgEB?=
X-IronPort-AV: E=Sophos;i="5.68,297,1569283200"; d="p7s'?scan'208,217";a="657446293"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Nov 2019 19:14:24 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xACJEOwF027654 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2019 19:14:24 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 13:14:23 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 13:14:22 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Nov 2019 13:14:22 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FII3AXlL8z6TaagwsfQdEDp3hyC2KOofkGOnS46j7uB2V+0ZRLHvuz+Mp66mLTh9gjTvKphglXrXnTFFZJw70nnn/jTDt0P2D21ajxOCBaqVvQUtv3f5TSn3LorDME6ZvVCT91N9lFr3/J9VLsf98FKQznd5LYldp8jks5Ac3lC3CDYxYqfiRz3l+ySVdLanXp+RXYJ3DBTrt0sQ1/xuPu8cj32yGFZ+ZW5KVYdaV7MXUHkMeWgN6xjBkzgXi/UJv/BKGtknhvLkH99QEbe0shRonWbTvNteBF7eg4izZOKrMaaiBvT/9z2kyRBnE9uuci9w4ZYKRUI77HBbXv98gw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x6ioyvsNDyNEJHNwhdl1FECZLq3C7M+0Vd9dB9FxSsM=; b=CWuD+q5KGiYYjb+cS0dj1xMaZxHG9VBB7TN9mijUHj/9CoDGUrb6s/CFVwiMPRV1U3kcqptE0blMQUYibfbPyU7x7fRVhhgc2xMXKnSgXMuNY1SsO09ab7/fz/kEpL/jO6mWuDT9kaBcARH61bhYlZfRiDRIai48ITYjh/7/XAmtCKG5DGJZf0h4J6Ftv/PJD7PmN41HNXFKZ2SHexWJM0wwdadFZLjMMQ1GQka3TUDx1hjK1XIWEhqbEouATKr7/v0bEHdFPHH5uj5TvdMHT+7X9brJ6OaT5+1M+JLBcO+Q6Z2MBun9gFVUjU4hCskg6SDjyukxa5DiFuimROxhOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x6ioyvsNDyNEJHNwhdl1FECZLq3C7M+0Vd9dB9FxSsM=; b=nt2gRSwsFBDkPeRge/Zc1TRkPrBw0T1JU/88yX6h5dDL+8Gk2cqN35H4kx4QPSffyMo4CZ8JKPSf8U1T5WBWbks/0Gjl2kE/3PljRESR9uHtpyJ6Yh7i0vq3XHfAyMqmw4xY8JZB7UM7GXEWl8+oi2m5eULeSQv5uuQfMoxkM+M=
Received: from DM6PR11MB4154.namprd11.prod.outlook.com (20.176.126.215) by DM6PR11MB4012.namprd11.prod.outlook.com (20.176.125.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.26; Tue, 12 Nov 2019 19:14:21 +0000
Received: from DM6PR11MB4154.namprd11.prod.outlook.com ([fe80::64fd:c810:5c47:243f]) by DM6PR11MB4154.namprd11.prod.outlook.com ([fe80::64fd:c810:5c47:243f%3]) with mapi id 15.20.2430.027; Tue, 12 Nov 2019 19:14:21 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, "Smith, Ned" <ned.smith@intel.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, Laurence Lundblade <lgl@island-resort.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVlCwI8/lytau3hU+AhCwtIdg/0ad+jL2AgAAHhQCAAAO1AIAF46wAgACM2YCAAJAzgIAAtdsAgAB9XUCAASDm4A==
Date: Tue, 12 Nov 2019 19:14:21 +0000
Message-ID: <DM6PR11MB415482CA6DB46BAAAE15A00EA1770@DM6PR11MB4154.namprd11.prod.outlook.com>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
In-Reply-To: <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-12T01:43:10.0511305Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a49e9ecc-8e3e-4bf2-b759-08bb20f89aec; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 22c2229d-54c6-4065-9771-08d767a485fd
x-ms-traffictypediagnostic: DM6PR11MB4012:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR11MB4012B73CAA10074B07EBE8DBA1770@DM6PR11MB4012.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(15404003)(199004)(189003)(102836004)(74316002)(2906002)(81166006)(186003)(6436002)(5660300002)(33656002)(7696005)(55016002)(66574012)(6246003)(53546011)(52536014)(66066001)(8676002)(6506007)(4326008)(8936002)(7736002)(14444005)(256004)(86362001)(76176011)(790700001)(6116002)(3846002)(66446008)(26005)(76116006)(66476007)(66616009)(66556008)(64756008)(236005)(9686003)(446003)(54896002)(99286004)(81156014)(66946007)(6306002)(316002)(11346002)(25786009)(54906003)(229853002)(110136005)(14454004)(486006)(476003)(6636002)(71200400001)(478600001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4012; H:DM6PR11MB4154.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Ck+pxhmjgr4vz9bafwMuj9OSfxFmO5lieyYC++gVPA3JhTAuUY94nvBmhxtEcTX7TaVRkY26qLGwTL0239cm3aRVA5V1LtNWBW4rMHSAQGP4Nf1aPk8yu2+cDbvZu3dlnGNzJ+9q14j+xnW9ldpN2lCbx59Uopei1WiEuuQtJocBcmd3cT1D9yeQP4seaQSsmgSgxa8hDo12sADb/ZtHuNd4yAP/eEf9kJ6gOGxjCD/a3Jmtw/zVyqGE/GsuwnqW3t2WRM/yirqOZwLRjGaLPkKjMq9LRzoRGcfIInNBVIyjl7cU265TagoCdu1LKUSglzFVsgl+ZDJHLqQAnrlOkWLyUxFusex4zxjZzwWcPng8+FXyXZ7d8CzzdhfIQx6WKBCGfJXb5wlKlJntShcS5bcx1HI0nljaVX6cbV26BpbHNZi5FQjaDdtSoWZCEkL4
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0DC3_01D59963.78A79BC0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 22c2229d-54c6-4065-9771-08d767a485fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 19:14:21.5571 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Q3OQPhfLyjGsZ2qgh7B1dGdYhongPQXQYMTR4a8xbvTGsSLPwLbpFkoj2gaqhWex
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4012
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/fNJU8AxGuwZPp9wzdJAN_8umrcE>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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, 12 Nov 2019 19:14:52 -0000

As a network equipment vendor, TEEP environments and EAT format work highlight interesting futures.  And I support these works on that basis.

 

On the other hand, TPMs are embedded today in routers.  And they are integrated to existing network operations applications.  However we have no standardized based industry management model.  And therefore today we see no applications which span equipment vendor types.

 

So the TPM based YANG has immediate applicability, and should be adopted.  

 

Eric

 

From: RATS, November 11, 2019 8:43 PM



As far as I can understand from draft-birkholz-rats-basic-yang-module-01 and

draft-fedorkow-rats-network-device-attestation-01, they break down the use case

space as follows:

 

                        Requirements?

         +--------------+---------------+---------++---------------

         |  RoT         | Host Firewall | Privacy ||   Solution    

         |  Type        |   Enabled     | Needed  ||    Pieces     

         +--------------+---------------+---------++---------------

      1  |  SGX         | No            | No      ||

      2  |  SGX         | No            | Yes     ||

      3  |  SGX         | Yes           | No      ||

      4  |  SGX         | Yes           | Yes     ||

      5  |  TrustZone   | No            | No      ||

      6  |  TrustZone   | No            | Yes     ||

      7  |  TrustZone   | Yes           | No      ||

      8  |  TrustZone   | Yes           | Yes     ||

      9  |  TPM         | No            | No      || draft-birkholz-rats-basic-yang-module-01

     10  |  TPM         | No            | Yes     ||

     11  |  TPM         | Yes           | No      ||

     12  |  TPM         | Yes           | Yes     ||

     13  |SecureElement | No            | No      ||

     14  |SecureElement | No            | Yes     ||

     15  |SecureElement | Yes           | No      ||

     16  |SecureElement | Yes           | Yes     ||

     17  | Firmware     | No            | No      ||

     18  | Firmware     | No            | Yes     ||

     19  | Firmware     | Yes           | No      ||

     20  | Firmware     | Yes           | Yes     ||

     ... |   ...        |               |         ||

 

And draft-fedorkow-rats-network-device-attestation-01 further scopes itself down

by only being applicable to cases with "embedded" apps only = Yes, and where

the security policy is only an Exact match against reference values = Yes.

I believe that the yang draft doesn't have those two restrictions, from my reading.

However, the point is that both drafts are VERY narrow, and in the table shown above,

only address 1 out of 20 possibilies in that space.

 

In contrast, the TEEP WG decided that it was not interested in narrow scopings

(specifically something Global Platform specific), but instead wanted one general solution.

 

If the RATS WG spends effort on something that only addresses a single row out of 20+ rows,

then do we expect 19+ other solutions to also be done in the WG?  Or could we work on things

that are broader and happen to also work for row 9?

 

I've seen others commenting on the fact that the YANG module only supports TPMs and not

other things (EATs etc), which would just add support for a couple more rows, but still not

be general.

 

Personally, I would much rather see the WG spend effort on things that really are generic,

i.e., work with or without host firewalls, work with multiple RoT/TEE types, etc., rather

than seeing an explosion of point solutions.

 

Dave

 

From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> > On Behalf Of Smith, Ned
Sent: Monday, November 11, 2019 10:12 AM
To: Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com <mailto:ian.oliver@nokia-bell-labs.com> >; Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com> >; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com <mailto:ncamwing@cisco.com> >
Cc: rats@ietf.org <mailto:rats@ietf.org> ; Henk Birkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de> >
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

 

Right. This implies the RATS “token” should support existing “binary” formats as an encapsulation (signed by a second TA where the TPM is a first TA) or as a conveyance (unsigned?) token. Possibly, the only added value of the latter is a tag that identifies it as a TPM binary format?

 

 

On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - FI/Espoo)" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>  on behalf of ian.oliver@nokia-bell-labs.com <mailto:ian.oliver@nokia-bell-labs.com> > wrote:

 

> Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that > EAT will replace TPM attestations in the long run (maybe decades) because they are far more expressive. I know > others believe that too. 

 

I would disagree with the statement of "short run" ... TPM is practically the only existing standardised (hardware, software, firmware, measurement - x86 only etc) hardware root of trust in common use, ie: practically all x86 machines,  The attestation mechanisms provided are going to be around for a very long time.  

 

>From telco experience, 30 years ago we said SS7 would only be around in the short term.

 

> Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise > to add EAT to it.

 

Agree

 

Ian

 

-- 

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

 

  _____  

From: Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com> >
Sent: 11 November 2019 00:44
To: Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com <mailto:ncamwing@cisco.com> >
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de> >; rats@ietf..org <mailto:rats@ietf..org>  <rats@ietf.org <mailto:rats@ietf.org> >
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft 

 

 

On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com <mailto:ncamwing@cisco.com> > wrote:

 

So, Laurence, are you still OK with the adoption of the current draft with a rename for now?
Thanks, Nancy

 

I think the value add to the larger RATS effort of adding EAT support to this YANG protocol is really high. It a core thing to do that helps bring together the two attestation worlds and make the TPM and EAT work here less like ships in the night.

 

Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that EAT will replace TPM attestations in the long run (maybe decades) because they are far more expressive. I know others believe that too. 

 

If we don’t include EAT in the YANG mode it is sort of like defining HTTP to only convey HTML to the exclusion of PDF. We’re defining an attestation protocol that can only move one kind of attestation even though we have consensus on what the other one looks like.

 

It seems relatively simple to add EAT support (or promise to add EAT support). Pretty sure I heard Henk agree to add it.

 

Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise to add EAT to it.

 

LL