[Rats] What's to EAT?

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 12 November 2019 09:22 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 58B9D120052 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 01:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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_HELO_NONE=0.001, SPF_PASS=-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 W7iFy7mXSXTH for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 01:22:22 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFDE120046 for <rats@ietf.org>; Tue, 12 Nov 2019 01:22:22 -0800 (PST)
Received: from [192.168.44.20] (unknown [209.171.88.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 610153897A for <rats@ietf.org>; Tue, 12 Nov 2019 04:18:59 -0500 (EST)
To: "rats@ietf.org" <rats@ietf.org>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <01bbbb92-9b99-7636-50a4-a1b4a37e0903@sandelman.ca>
Date: Tue, 12 Nov 2019 17:08:05 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/igrLa2VfdSauPtrGqMSiHJhIxFg>
Subject: [Rats] What's to EAT?
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 09:22:24 -0000

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'm completely perplexed by that thread about "Call for adoption", so
I've changed the subject line, and started a new thread. 


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

+1

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

I mostly agree.

I think that it's okay to say, "The uptime claim is forwarded to the
Flu-Flu Processor" rather than saying "The Token containing the uptime
claim is forwarded to the Flu-Flu Processor"