Re: [Rats] What's to EAT? - terminology clarification

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 13 November 2019 19:39 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 AC8DD12084D for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 11:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 in8bRIbXgLXd for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 11:39:36 -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 30BD2120A7E for <rats@ietf.org>; Wed, 13 Nov 2019 11:39:30 -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 xADJdKw6011417 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 13 Nov 2019 20:39:21 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 13 Nov 2019 20:39:15 +0100
To: Laurence Lundblade <lgl@island-resort.com>
CC: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>, "Salz, Rich" <rsalz@akamai.com>, "rats@ietf.org" <rats@ietf.org>
References: <229E0A72-4B44-4C9A-AD0A-142A13020C9A@intel.com> <MWHPR21MB0784058F591C52EEB31E0736A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <4F586E15-9CF7-4824-87F2-8E2C20D1AF1D@intel.com> <MWHPR21MB078439E9EB07E3BB72E15137A3760@MWHPR21MB0784.namprd21.prod.outlook.com> <71173EC8-A167-47B9-B0F1-05759D59890B@akamai.com> <20191113071244.onqdgo2roqt7efb6@anna.jacobs.jacobs-university.de> <B555FC8E-FF3B-468A-B3DF-9F10DD6FBBF6@island-resort.com> <2be3acbe-c2a3-076c-63a2-b5d00a3ba4c2@sit.fraunhofer.de> <ACB7685F-54F8-465E-889F-E36CB1F5BAB0@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <bb37b124-0938-7b2f-7ae7-eb51bcdd1c82@sit.fraunhofer.de>
Date: Wed, 13 Nov 2019 20:39:14 +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: <ACB7685F-54F8-465E-889F-E36CB1F5BAB0@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/UCCM2CKuM-R8DaueOFYR-be4WRU>
Subject: Re: [Rats] What's to EAT? - terminology clarification
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 19:39:40 -0000

Up to today, I was looking at the CDDL fragments in the EAT I-D with 
some leniency, as I though the CDDL preludes would not be used, leaving 
the higher level tree composition features for use as a first draft to 
create IM statements in well-defined non-English (a good approach to 
peruse, I thought).

If you are using them now as actual CDDL specification fragments, I'll 
think I have to chime in and provide contribution on how to do that in a 
compliant manner that will result in a valid overall CDDL ROOT 
specification in the end.

We can talk about that in .sg. It will not take very long, if we do that 
in concert, I think.

Viele Grüße,

Henk

On 13.11.19 20:30, Laurence Lundblade wrote:
> One of the D’s in CDDL is for Data and I think someone told me that CDDL is for Data Models and that what is currently labeled as the Data Model in the EAT document is the Encoding.
> 
> It doesn’t matter much to me what we label the different parts of the EAT document. Happy to adjust the labeling. However having 1) the textual claim descriptions, 2) having CDDL as the next level of description and 3) being able to encode CDDL in JSON and CBOR (and maybe ASN.1) mechanically does matter to me.
> 
> LL
> 
> 
> 
> 
>> On Nov 13, 2019, at 9:51 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
>>
>> Now I am a bit confused. Didn't you attempt to use CDDL as an information model in the EAT I-D?
>>
>> On 13.11.19 18:49, Laurence Lundblade wrote:
>>>> On Nov 12, 2019, at 11:12 PM, Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de <mailto:J.Schoenwaelder@jacobs-university.de>> wrote:
>>>>
>>>> Concerning IMs and DMs, here is the (extended) RFC 3444 view that
>>>> is commonly used by some parts of the IETF:
>>>>
>>>>                  IM               --> conceptual/abstract model
>>>>                  |                    for designers and operators
>>>>       +----------+---------+
>>>>       |          |         |
>>>>       DM         DM        DM     --> concrete/detailed model
>>>>       |          |         |          for implementors
>>>>    +--+--+   +--+--+--+    |
>>>>    |     |   |  |  |  |    |
>>>>    EN    EN  EN EN EN EN   EN     --> encodings / representation formats
>>>>                                       for instance data
>>> In the EAT draft, the EAT claims information model is in the largely textual description of each claim.
>>> In the EAT draft there is just one EAT claims data model. It is the CDDL in the EAT draft.
>>> Currently there are two claims encodings, CBOR and JSON. Thanks to CDDL, we get from data model to encoding in a largely mechanical way and there is little text needed.
>>>                  IM: Text
>>>                  |
>>>                  +
>>>                  |
>>>                  DM: CDDL
>>>                  |
>>>              +---+--+
>>>              |      |
>>>             CBOR   JSON
>>> I think this is a good, simple and effective way to proceed.
>>> (There are a few things wrong with the way this is written up in the current EAT draft that need to be fixed:
>>> - The encodings are mis labeled as the data model
>>> - I’m not sure the CDDL is correct)
>>> Maybe one more encoding for X.509/ASN.1/DER is added to cover Dave’s use case. Hopefully it could be by saying how to encode the needed subset of CDDL into ASN.1/DER. Android Keystore also uses X.509 for attestations, so this might add motivation. To keep effort down, CDDL->ASN.1 should just be for EAT and a CDDL subset.
>>> I do not think we should try to bring YANG in here. So there is no YANG expression of EAT claims. (I did see Eric’s GPS use case, but don’t think it is mainstream enough to motivate the complexity and large effort to bring YANG into play here).
>>> This email is just about the “EAT claims information model”. There can be other separate information models for other parts of RATS. I don’t think there should be one global RATS information model that spans all the documents.
>>> The gap of sorts here is IANA registered claims, the existing ones and new ones. There’s no requirement to provide an information model or CDDL when you register new claims with IANA or even coordinate between JWT and CWT.
>>> LL
>>> _______________________________________________
>>> RATS mailing list
>>> RATS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>