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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 13 November 2019 11:28 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 C3A2712023E for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 03:28:05 -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 6U3kWycQSzm0 for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 03:28:04 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA40E12003F for <rats@ietf.org>; Wed, 13 Nov 2019 03:28:03 -0800 (PST)
Received: from [192.168.41.2] (unknown [58.212.133.150]) (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 A705A3897A; Wed, 13 Nov 2019 06:24:56 -0500 (EST)
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, 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> <c3b7d860-b3c2-e9ab-f349-4a73619d90f7@sandelman.ca> <23b47242-cb99-2e86-67b3-beb7e0e51599@sit.fraunhofer.de>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <330ab612-ab92-809e-4c22-ac3814ce117c@sandelman.ca>
Date: Wed, 13 Nov 2019 19:28:00 +0800
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: <23b47242-cb99-2e86-67b3-beb7e0e51599@sit.fraunhofer.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/FHzFtRuGMitSnOacFPTXP1iQ83w>
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: Wed, 13 Nov 2019 11:28:06 -0000


On 2019-11-12 6:10 p.m., Henk Birkholz wrote:
>
>
> On 12.11.19 10:44, Michael Richardson wrote:
>>>>> 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
>>
>> Those aren't EATs, those are attributes of claims that an EAT could
>> include.
>> If you are saying that we could write a YANG module describing those
>> claims, and that they could be used to describe both claims of an EAT,
>> but also results from a TPM 1.2/2.0 call, then I understand finally.
>
> Yes, that is basically a way to phrase the question, I think.
>
> Specialized questions are: do we need to do that? Do we want to do
> that? Is it technically okay to instead convey opaque EAT blobs via a
> YANG statement?

Sorry to be more pendantic.
Do you mean: Is it okay to convey attributes of claims that an EAT could
include as blobs in a YANG model?
Or you mean: Is it okay to convey a binary serialization (say to CWT) of
an EAT in a binary blog in a YANG model?

(The answer to both is yes.  I don't know if it's useful)