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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 12 November 2019 08:21 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 5B71F12018D for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 00:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8N2ku65fefHV for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 00:21:16 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 823B4120169 for <rats@ietf.org>; Tue, 12 Nov 2019 00:21:14 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xAC8LCVq020877 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 12 Nov 2019 09:21:13 +0100
Received: from [134.102.157.164] (134.102.157.164) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 12 Nov 2019 09:21:07 +0100
To: Dave Thaler <dthaler@microsoft.com>, "Smith, Ned" <ned.smith@intel.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
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> <ba12a686-1b34-21a3-388c-bbe01c01a408@sandelman.ca> <1DFA7D52-7294-4705-9407-C34F5BC82EA6@cisco.com> <5f57dd25-f561-e07d-4b24-fef05627bac9@sit.fraunhofer.de> <c61b3ccd-6427-5801-c149-4e93af5c9fb1@sandelman.ca> <0eb003f7-34c3-af36-74ac-097841d2ac6c@sit.fraunhofer.de> <D6CA54EA-67F1-4BE6-8D11-32C6597D58E0@intel.com> <MWHPR21MB078487DA04C7C17F2019E7E6A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <29e641b7-3077-2b7d-8029-631698012c74@sit.fraunhofer.de>
Date: Tue, 12 Nov 2019 09:21:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <MWHPR21MB078487DA04C7C17F2019E7E6A3770@MWHPR21MB0784.namprd21.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.157.164]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ZbH7PRNqI7qob_uS5ZxGYq-Zr-o>
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 08:21:19 -0000

Hi Dave,
hi all,

is it correct that the intent of tokens - in general - is that they have 
a life-span and are somehow like... certificates, but with a smaller 
life-cycle? The claims defined by the Web Token RFCs are indicating as 
such, I'd assume.

Having said that, the features we use are the object / tagged map 
structure, the continuous list of defined Claims & corresponding 
registry, and the imperative guidance how to use {C|J}OSE. In 
combination with the fact that all Web Token Claims are optional, we can 
use these features for purposes other than the original intent of tokens 
and that is okay. Simply calling them tokens, though, might be confusing 
to readers that already use tokens?

In conveyance protocols for RATS I would like to see at least three 
things defined and differentiated:

* the Interaction Models the protocols use, most prominent, 
challenge/response, time-based, and subscription,
* the Message (Content) that is conveyed, most prominent Evidence, 
Endorsements, Reference Values (aka Known Good Values), and Attestation 
Results, and
* the Roles between which Messages are conveyed via protocols, most 
prominent .

This is applicable to EAT (specific claim set serializations) and YANG 
(specific statements serializations, APIs, and conveyance protocols) or 
others - and unless there are really good reasons against this, I'd 
consider these definitions/categorizations a MUST.

After the discussions we had, I am a bit at a loss how to deal with "the 
same information elements used in different message types and content" 
or "how to not use the same term as something else" (aka the Information 
Model), I have to admit. I do not see a viable solution at the moment.

Viele Grüße,

Henk


On 12.11.19 05:19, 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.
> 
>  > 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
>