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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 11 November 2019 12:14 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 DC30E120114 for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 04:14:02 -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 2SDOAuXJoX6e for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 04:14:00 -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 4A9211200FA for <rats@ietf.org>; Mon, 11 Nov 2019 04:13:59 -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 xABCDtLC024815 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 11 Nov 2019 13:13:56 +0100
Received: from [134.102.155.87] (134.102.155.87) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 11 Nov 2019 13:13:50 +0100
To: 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>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <0eb003f7-34c3-af36-74ac-097841d2ac6c@sit.fraunhofer.de>
Date: Mon, 11 Nov 2019 13:13:49 +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: <c61b3ccd-6427-5801-c149-4e93af5c9fb1@sandelman.ca>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.155.87]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/SnA2vkDUrQvwRdunnk7YJK3qYR8>
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: Mon, 11 Nov 2019 12:14:03 -0000

Hi Michael,

please see in-line.

On 11.11.19 12:37, Michael Richardson wrote:
> 
> 
> On 2019-11-11 5:57 p.m., Henk Birkholz wrote:
>> Hi all,
>>
>> on one hand, we have to address the overlap between YANG and EAT
>> information elements (statements & Claims) and how to deal with them
>> (one obvious issue, for example, would be potential redundant
>> information model content in two different drafts).
> 

Examples of the same information elements that are used in different 
data models via Claims or statements:

* EAT Time stamp / YANG clock info
* EAT Origination / YANG attestation key cert, or
* EAT Uptime / YANG tpm ticks

> Can you give me an example, but I'm not getting the issue.
> I think that we will be the first to attempt to use JOSE to sign a JSON
> serialized YANG object, resulting in a JWT.  Well, technically, it's
> probably not a JWT, because we aren't going to base64url it and put
> periods between the pieces, I think.  It's just JOSE, but I don't mind
> if we call it a JWT.

As far as I know, simply wrapping a "JSON serialized YANG object" in 
JOSE does not create a JWT. RFC 7951 is not based on RFC 7519. The 
Base64/Base64URL confusion is limited to value representation in JSON 
serialization, I think.

> 
> draft-ietf-anima-constrained-voucher does CBOR serialized YANG which is
> signed with COSE.

With CBOR serialization most things more straightforward and a tad bit 
simpler. I do not think that we have any issues on the binary side of 
things here. Or am I missing something obvious?

> 
> 
>> On the other hand, Laurence's original point was the payload of
>> conveyance protocols used by RATS. Specializations of this topic are
>> apparently:
>>
>> * Web Tokens via YANG Interfaces, and
>> * YANG modeled data via other conveyance protocols (other than *CONF)
>> that can transport Web Tokens.
>>
>> There are examples of how YANG modeled data is used outside of *CONF
>> protocols, for example MUD. We have to understand and agree about:
>>
>> * this is possible on a technical level, and
>> * this is useful wrt to protocol scope, intent & semantics, I think.
>>
> 
> MUD (RFC8520) does it, but so does ANIMA vouchers (RFC8366).
> Again, data-at-REST described by YANG.
> 
> But the document in question does not seem to be data-at-rest, but RPC
> access via *CONF protocols to TPM 2.0 objects, so I feel that you are
> further muddying this thread by asking the above question.
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>