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

Henk Birkholz <> Wed, 13 November 2019 11:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88C9C12001A for <>; Wed, 13 Nov 2019 03:39:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FQD1GgckVIfF for <>; Wed, 13 Nov 2019 03:39:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2999512013F for <>; Wed, 13 Nov 2019 03:39:25 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xADBdNc2019104 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 13 Nov 2019 12:39:24 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 13 Nov 2019 12:39:17 +0100
To: Michael Richardson <>, <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Wed, 13 Nov 2019 12:39:17 +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: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 11:39:29 -0000

For convenience of some readers, please find the reply at the bottom.

On 13.11.19 12:28, Michael Richardson wrote:
> 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)

Isn't that supposedly my job?

To the point. I meant: Is it okay to convey a binary serialization (say 
to CWT) of an EAT in a binary blog in a YANG model?

Why am I asking that? (well, actually now you did)

YANG modules thrive on well defined semantics for each statement. I just 
want to make sure that it is okay to convey an unknown composition of 
Claims (opaque semantics) via the web token format in a YANG module 

Laurence brought up a good example, I think. If "Identity Document" is 
good enough. Probably "Attestation Evidence" is good enough, too.

To comment on Michael's quote: Do "we need this in the same document 
(the same model?) as the TPM stuff?". I think "need" would be a very 
strong word here and therefore I would not recommend to make it 
mandatory and impose more code on YANG datastores/rpcs.

Viele Grüße,