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

"Smith, Ned" <ned.smith@intel.com> Tue, 12 November 2019 22:55 UTC

Return-Path: <ned.smith@intel.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 2F5EE1200B9 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 14:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 M8p2oIi4FP1b for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 14:55:46 -0800 (PST)
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 C99F0120018 for <rats@ietf.org>; Tue, 12 Nov 2019 14:55:46 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2019 14:55:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,298,1569308400"; d="scan'208,217";a="216186270"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga002.jf.intel.com with ESMTP; 12 Nov 2019 14:55:45 -0800
Received: from orsmsx126.amr.corp.intel.com (10.22.240.126) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 12 Nov 2019 14:55:45 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX126.amr.corp.intel.com ([169.254.4.116]) with mapi id 14.03.0439.000; Tue, 12 Nov 2019 14:55:45 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: 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/JbqfbFf0mfD9c0xlySNA==
Date: Tue, 12 Nov 2019 22:55:44 +0000
Message-ID: <229E0A72-4B44-4C9A-AD0A-142A13020C9A@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-originating-ip: [10.24.15.10]
Content-Type: multipart/alternative; boundary="_000_229E0A724B444C9AAD0A142A13020C9Aintelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/XsICQOOZQYd3WFD26lsADB-tUw0>
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 22:55:49 -0000

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