Re: [Rats] What's to EAT? - terminology clarification

Dave Thaler <dthaler@microsoft.com> Tue, 12 November 2019 23:33 UTC

Return-Path: <dthaler@microsoft.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 AF9B412011D for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 15:33:31 -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, 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_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=microsoft.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 XV7upKZmFB-B for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 15:33:28 -0800 (PST)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730103.outbound.protection.outlook.com [40.107.73.103]) (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 A5F3D1200B7 for <rats@ietf.org>; Tue, 12 Nov 2019 15:33:28 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YSGK8PzErUR627sE2jf/lsDUaW0a/8hb4k+DIFDCstpxHY8Bd5CRToNS1EOIqYSLG3GK511GzudRR0C4EVPddYruyFl2HVb3elTn5m0MhVSabRok/jC87eLtaly9zJwmPt5ybkyJSeg8HtTin09mMKEeIuSrQf5RUgWHcYw3Q16rl524yzyCcf+wBRXjgrIpP7aoeQmZNx4Lj4EFnF+v2BpOV5JGwUpJnLc0Hba302vEr3VzT5zmoDFnAePQBnYn0M0gJkD7lBuqdW1MxKYorANVSDaag+oS8L8Jc8TjK4MnZZDDCrvXc6S1jISptNrM+MKCxLlqNYAtCekp00LmhQ==
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=AFrXjmocKegkcDtZmjaVspDVOi3AcXB5jsM2wrhFtLQ=; b=X8uCIJFH4v72Yn6qkf1RIgtFRJWXc1zTz1d5GHvZp8IdkpTAMHbn7Z4CLOtbjA9ykDJWVjFQJqWzUkemdl0SXwWdp5DOJDlmyN0wMjJFl2fHHhfDAAQ6abMn3v7fleJbWK5qYLoPrKRURcK9rZgkccG1H+NeMBPiJRau1pI95VgQiEpl/fpxEMKMqWfeAXjztu2ptxI8BkWudFCGfzjcEmxHwRTO7GbDQ2lzXaFvylJO7eWmqR2KrA1APo0BDY6IgDQdgyog9dixYgff0dsqiwC0bZvYx6sonQ4kZYpVlRBQzK0WbhHCNp9CCBoiMPHyztCy8cl92X5LhEsSwV6S2A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AFrXjmocKegkcDtZmjaVspDVOi3AcXB5jsM2wrhFtLQ=; b=BSnrXEHXXZreMNvmqn1xZnIUS8ys0EWJLRC6vD2xZxo6yERnIjTxEFcWDsUUwFB47L5Fsbj8+M0BIrgCOy7LRde1j8K6x4ndDzdujAlzdzxmmm9BuiBWZZH24uSBgqIZUI/KnFJ0oL5+IMn+cUq64C7UesmQn6f4bV4VWzq/tV4=
Received: from MWHPR21MB0784.namprd21.prod.outlook.com (10.173.51.150) by MWHPR21MB0829.namprd21.prod.outlook.com (10.173.51.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.11; Tue, 12 Nov 2019 23:33:26 +0000
Received: from MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::8d41:8f86:8654:8439]) by MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::8d41:8f86:8654:8439%12]) with mapi id 15.20.2474.001; Tue, 12 Nov 2019 23:33:26 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "Smith, Ned" <ned.smith@intel.com>, Laurence Lundblade <lgl@island-resort.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] What's to EAT? - terminology clarification
Thread-Index: AQHVmaxQg/JbqfbFf0mfD9c0xlySNKeIK3rw
Date: Tue, 12 Nov 2019 23:33:26 +0000
Message-ID: <MWHPR21MB0784058F591C52EEB31E0736A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
References: <229E0A72-4B44-4C9A-AD0A-142A13020C9A@intel.com>
In-Reply-To: <229E0A72-4B44-4C9A-AD0A-142A13020C9A@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
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-12T23:33:26.3540800Z; 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=a7e8c754-18b3-4068-9621-248da0028d48; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2001:4898:80e8:b:f89a:16bc:386f:88f5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e5325a45-372d-4a42-6371-08d767c8b784
x-ms-traffictypediagnostic: MWHPR21MB0829:
x-microsoft-antispam-prvs: <MWHPR21MB0829875E44DE7CC76222746DA3770@MWHPR21MB0829.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:170;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(366004)(136003)(199004)(189003)(256004)(229853002)(86362001)(66476007)(64756008)(9686003)(22452003)(790700001)(71190400001)(99286004)(71200400001)(7696005)(10290500003)(186003)(11346002)(74316002)(14444005)(446003)(66556008)(8990500004)(478600001)(76116006)(236005)(486006)(66946007)(476003)(7736002)(66446008)(6116002)(10090500001)(54896002)(46003)(55016002)(6246003)(81166006)(6306002)(6506007)(81156014)(14454004)(4001150100001)(33656002)(6436002)(5660300002)(102836004)(4326008)(76176011)(8936002)(2906002)(110136005)(53546011)(316002)(25786009)(52536014)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0829; H:MWHPR21MB0784.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: H0tAUTW6cvqi4w9VM1xRM/8PcdBxt7UAJwt8/86mIBZbZrXD1M5U9DoffEOhjmr9KRvL56zAWPWsdlQUSxC9bTqDJnD/RlHPtIFdJjN4zLYLiYp7oCJUb4KjeX93sAPas/RFrBqxkS29pNuhk79Zvko5473gvo15UItAQS8DFx2tv3KwjrmTCMlztmIEFHIyyerPLM6l4K6cA47CgO5f4vecxlrTABuvi4UNNM+jRUy/9C0fzpOh7IqQetHB/ApobTQ9hm8KSlghV0VppWXIpGBuc2bzaNTLCoxpPHGs+qZJGFYjP4lI7g4n0uZd3dl48PiZ/qX1k3isBLLgaKToiW4lnB7zkU0Ltdqpmu8KYV3vz33EvSuzjWyxEkJ+/aawPSL9cMx3dJKHi4E1iOwBxwvfkid9woLz95ooYYUHQkG7Cy5P1H1+TAiq0/28utBU
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0784058F591C52EEB31E0736A3770MWHPR21MB0784namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5325a45-372d-4a42-6371-08d767c8b784
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 23:33:26.4871 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1jvD5h7nj3wWfIN8kmhoKsDdUw8ipfPTnui6TprM+KY2IfnaQlnfehTiE4PNiTvW7KdmDY6XlJaykFMeiPpfCSi3dNyOBG6xxO8d4AvMw3U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0829
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/bvlqhDdAc_9SS_sgL1Lt6secRGQ>
Subject: Re: [Rats] What's to EAT? - terminology clarification
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 23:33:32 -0000


From: RATS <rats-bounces@ietf.org> On Behalf Of Smith, Ned
Sent: Tuesday, November 12, 2019 2:56 PM
To: Laurence Lundblade <lgl@island-resort.com>; Michael Richardson <mcr+ietf@sandelman.ca>
Cc: rats@ietf.org
Subject: Re: [Rats] What's to EAT? - terminology clarification


Including Dave Thaler’s thread from forked subject line in [1].

The eat draft uses “Claim(s)” in the section heading for the Information Model. CDDL expressions are used. I think this is OK. We don’t need to change it to “Evidence” IMO. The architecture draft (birkholz) strongly implies that Evidence is signed (verifiable or provable). This suggests Evidence is in a serialized format (hence isn’t CDDL, YANG or ASN.1).



Sure, Evidence is certainly conveyed in a serialized format.



I don’t think “Evidence” would be as precise a way to talk about an information model object as “Claim(s)” would be.



YANG is not a serializable format hence it is more appropriately an information model language for the purposes of RATS (IMO).



Going back to the original question. A Token (EAT, CWT, JWT) is an example of something the architecture calls Evidence.



FYI, I (and others I’ve talked to) are far more interested in the use of a Token for what the architecture calls Attestation Format,

much less interested in standardizing what the architecture calls Evidence.



A Verifier can have multiple simultaneous purposes, as mentioned in my draft:

1)     To make policy decisions that include verifying Evidence that chains up to a manufacturer, and then generating an Attestation Result

whose security chains up to the Verifier (or their org) rather than every manufacturer of every Attester, so that the Relying Party’s policy

can be simple and just trust the Verifier.

2)     To allow heterogeneous Attesters, with different Evidence formats (including existing/proprietary/whatever ones), to talk to a common Verifier,
which can then provide a standard Attestation Format to Relying Parties, so that one need not have every Relying Party understand every

Evidence format, of which many already exist.



So I personally will argue against scoping EAT to only Evidence, and for keeping it generic and usable for Attestation Results.

(Others I’ve talked to both inside and outside Microsoft share this view, so I’m also relying it as a messenger, not just an advocate.)



If the WG chooses to only standardize what we now call Evidence and ignore Attestation Results, then I don’t believe it meets the needs

of either Microsoft or, I suspect, the TEEP WG use case.



Dave



CDDL, YANG are expressions of something that the architecture should call Claims. (agree?)

-Ned



[1] Dave Thaler wrote:
> So far the group has used the term "EAT" to refer to both the information model and data serialization expressions.

I would rather see the term EAT (and any other terms ending in Token, like JWT and CWT) only be used to refer to
data serialization expressions, not the information model.

> When extending information model to YANG or some other serialization (e.g. ASN.1). Given the possibility for an IM
> expression to be realized by different serializations, what term should we give to the IM description?

That’s a fine question, and I don’t have any strong preference right now, other than to not use the same term as something else.
Offhand, my preference would be to not define a term, and just use Evidence and Attestation Result as the terms for
format-independent discussion.  I think it is useful to distinguish between Evidence vs Attestation Results in many cases.
And if you need to refer to both, then we can always use both together, such as “Evidence and Attestation Results”.

> The term "Claim" has been used extensively. Do we want to agree to use "claim" to refer to anything that is an IM
> expression in RATS and "Token" for any serialization (realization) even if it isn't a JWT or CWT?

I would say no. To me, a claim is one particular piece of information, where a “Token” or whatever else has a set of claims.

Dave


On 11/12/19, 11:00 AM, "RATS on behalf of Laurence Lundblade" <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org> on behalf of lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:


On Nov 12, 2019, at 1:08 AM, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:


On 2019-11-12 12:19 p.m., Dave Thaler wrote:

Ned Smith wrote:

So far the group has used the term "EAT" to refer to both the
information model and data serialization expressions.



I would rather see the term EAT (and any other terms ending in Token,
like JWT and CWT) only be used to refer to

data serialization expressions, not the information model.
I concur.

I disagree with that.

I don’t think we want one information model for all of RATS.

EAT has an information model and data model for what it expresses.

The YANG Module has an information and data model for what it expresses.

The primary purpose for use of information models (plural!) is so we can described things like claims once and then have a largely mechanical way to serialize them in different ways, CBOR and JSON.

Note that CWT and JWT don’t use the information model concept. They are mostly two independently defined and loosely coordinated data models. We are trying to do different by having a common information model that covers both. One might argue that CWT and JWT should have done what we are doing in EAT.

LL