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

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 12 November 2019 19:41 UTC

Return-Path: <evoit@cisco.com>
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 2EA9C120922 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 11:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=A+AH0Uix; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=BP4nrdee
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 QnlpWAj_fHn5 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 11:41:42 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F369B120A0F for <rats@ietf.org>; Tue, 12 Nov 2019 11:41:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40590; q=dns/txt; s=iport; t=1573587701; x=1574797301; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wotjzf3fYZ7er1cT0IPT4EYOXosrAwmhEPVreooCJPI=; b=A+AH0Uixha/lYj4mK+/tpYHdaM/AoJ6UBxrmdD8NCdeUSfIuNuiXzZvh 2NX6MlT6uCgvupSytDN5Mng5QZctFq+31Xw4U9H8HpY/4ZwpFnpP5DaUz IUEqiAJWymQR8EFNHWp536JEAgvLRSFqahTRFT/AAiRUy+ZIcW31BRx0e 4=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:dmCJcBZLh2rp3AQmX30eG63/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20Q+bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavncSs7AOxJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3AACOCstd/5xdJa1eBQMaAQEBAQEBAQEBAwEBAQERAQEBAgIBAQEBgW0CAQEBAQsBgRsvJCwFbCstIAQLKgqEH4NGA4pygl5/lwGBQoEQA1QCBwEBAQkDAQEYAQoKAgEBhEACgh0kNwYOAgMBAwIDAgEBBAEBAQIBBQRthQsGJgyFUQEBAQEDAQEQCwYKEwEBJQQDCwENAgIBBgIOAgIDIwEGAwICAhkMCxQDDgIEAQkEBQgGEQODAYF5TQMfDwECDJNfkGMCgTiIYHWBMoE7gUMBAQWFEBiCEAcDBgWBMQGBUopBGIFAP4ERRoIXNT6CYgEBgS4BCwIFAQkYBBEKDAkRgkkygiyNE0EBn1FuCoIlg0uCNIV4RIkkmXmOR5l2AgQCBAUCDgEBBYFoIyo9cXAVO4JsUBEUiEWHcQkag1AzhGGFP3QBgSeNdg8XgQsBgQ4BAQ
X-IronPort-AV: E=Sophos;i="5.68,297,1569283200"; d="p7s'?scan'208,217";a="378533430"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Nov 2019 19:41:39 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xACJfd76027726 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2019 19:41:39 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 13:41:38 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 14:41:36 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Nov 2019 13:41:36 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vy0GO2O07cUzlsvA+2xlCNJlWxgl31uAjJKJTgHA3opbTbl9peQaiSpy74QOQ7LFHgNDaQ7YqgGxPQMjii3jwTzM+l0fvhMDZ+c/2VgCzp1x01Pq1aDO+ADiQPh22lcNiM+pGPEC8478IDb3gpaYpZXJ6k7Sbh0BAOQ1djP2fFz/4JUY4gQ/fl+DYOieuQpIQ+Zf3Vg+5GJGGYEy0cOJbOjYHNvrJLsSS5kcf2ac8iyFBdY3Py9Kv9F2ZnSSkyllAa9ksex5rQiasLMphhS3x/2Ynxps+KmYin0CxmE0/YMxmuyWE6Td3+5H7SloJnhe0xKD8tFXyO7kGAv4R4ZCtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=INaJcrFFqXTqhJbGpD2Jaxn+Uxmye/APcyajSCId2mA=; b=Wm/1/EGAAxaHhL8X1PtwK4P1v47rk11A9UOtSJKzIiX+mezIYl/GwTEKxV+3RMnoiSG7T//xezY3ZxFCL+HzsjFU+I1wfH20IEJff6C/1AHkAXVaqmO2CI8DZGwkxBuf28z7Letzpz3vp70Qe5KLK1YdxSpR/iLgDxKNg3v7i7jkz92ogYL7XdZxSH9YWin+KgNqU+zMpHwlXzyHlL/OxiMpK8iP58cuHr5RtP6A/6zbqy+K0b3+T+DHDT4+4GBf1SAADMohvDE9NEdX1bQor5/MkfeffJQKnkuBjvxkGlb0F7GX/Y/Kt38EoaT+0R5J6XsEP9z7thuLxYAQ3kRiGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=INaJcrFFqXTqhJbGpD2Jaxn+Uxmye/APcyajSCId2mA=; b=BP4nrdeenLoVhtTMMI2i1x3Px4jIjP+D1JkocFj68PIA0qWD0H8to2GY0T5yp1piybb3iUxxpu8EnfetCbOStRzMdLK2gR6ZfsmnqoPuA+SZz0IzhGiXMZ8zYJaWtsjWQo3g8FnpPgxRyMADadMPVSoqzizQl1cvEDaE7owp7No=
Received: from DM6PR11MB4154.namprd11.prod.outlook.com (20.176.126.215) by DM6PR11MB3017.namprd11.prod.outlook.com (20.177.219.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Tue, 12 Nov 2019 19:41:35 +0000
Received: from DM6PR11MB4154.namprd11.prod.outlook.com ([fe80::64fd:c810:5c47:243f]) by DM6PR11MB4154.namprd11.prod.outlook.com ([fe80::64fd:c810:5c47:243f%3]) with mapi id 15.20.2430.027; Tue, 12 Nov 2019 19:41:35 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Laurence Lundblade <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "\"Schönwälder, Jürgen\"" <J.Schoenwaelder@jacobs-university.de>, "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Thread-Index: AQHVmYgL8/lytau3hU+AhCwtIdg/0aeH5+wg
Date: Tue, 12 Nov 2019 19:41:35 +0000
Message-ID: <DM6PR11MB4154E1339B3970802FF140C9A1770@DM6PR11MB4154.namprd11.prod.outlook.com>
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> <4A83CDF5-D29F-4279-8B03-E9D23299EB53@island-resort.com> <0C6940B0-E93F-4274-9D00-DEC4119B8F69@island-resort.com> <3310947D-EA31-4107-8FF0-B917A027C955@intel.com> <20191111213249.4p7z2ovkvqy2u5go@anna.jacobs.jacobs-university.de> <3C967A22-DBB0-4EA7-923D-B423920EB9BD@intel.com> <0AACCF7B-36A9-4AF9-B18A-BF18DC35986E@island-resort.com> <a72c6bb0-0f96-3d25-0faf-d5a1fe92a2c8@sit.fraunhofer.de> <2F3459F0-0063-4012-933F-F036E75A1331@island-resort.com>
In-Reply-To: <2F3459F0-0063-4012-933F-F036E75A1331@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e8554b71-e341-407a-ed79-08d767a853b5
x-ms-traffictypediagnostic: DM6PR11MB3017:
x-microsoft-antispam-prvs: <DM6PR11MB3017910DCB5EB4DFA3950FD8A1770@DM6PR11MB3017.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(189003)(199004)(66476007)(6116002)(66556008)(66446008)(64756008)(2906002)(66616009)(81166006)(229853002)(6436002)(8936002)(8676002)(790700001)(99286004)(3846002)(76116006)(110136005)(54906003)(6246003)(66574012)(316002)(52536014)(5660300002)(81156014)(66946007)(33656002)(561944003)(66066001)(966005)(14454004)(478600001)(7696005)(4326008)(606006)(71200400001)(76176011)(71190400001)(256004)(14444005)(25786009)(236005)(86362001)(9686003)(11346002)(446003)(54896002)(6306002)(74316002)(476003)(55016002)(7736002)(486006)(186003)(6506007)(102836004)(26005)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3017; H:DM6PR11MB4154.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pBeQTWYV6BdBRw9DT0GKt/Hca5nyZQFHAwQatYq8tiVuJ3/wJq9jX1hugDoxudGfEuXleZjt/GEJ1sTe5+bHrECIXUI3ExZhaD4SIkdVl8b89HN5OJ7pVMtVPsrRgTpIDgHMjOqGknEG90TBHHI1Z9+aTi1GtufVofM9uq/AwCw9nVWaDn88ZceTq69z9iz3ngM74aRRCBQLW8zaoPbnCVMdZIb/g10GxyioIJRWc8Rd0YnYcSZqEHEfOIRewi4677P7exkBQiqqPkXCB2sc2FYyVBNZHUOd5NWiuhPkK270jEEpc+IZ7Ky+KxXu9EDT1jf0YH7hjsrvYeKwgVFPOxxsG7LzzDrHBCsMmf8CD8eNUhRH3qO0Eyvaeyqh8XhzT+QImtpQZkeF9ab8auewM3WG+XUu+LJrq4avlj9uiC2ZKFuotoecb856U0EA92nq
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0DCA_01D59967.41BC0520"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e8554b71-e341-407a-ed79-08d767a853b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 19:41:35.2313 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MYWHePYl1MXfQscrumJmdF13zrPklbWIrvaVoc4fhSc3hgq6qEjA2DvO06T3+8wl
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3017
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/VrXH9D8nKhXN_j3ECj98xxPgjIY>
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 19:41:46 -0000

With YANG, it is possible to support both opaque transport of information, as well as extracting that opaque information from a chip contained within the attester.  We will need both supported.  

 

For an example of why, consider a local Wireless Access Point which gets signed GPS location from a chip: 

*	The Wireless Access Point will need to understand the GPS location because it might only legally be allowed to turn on various radio frequencies based on the country.
*	Remote devices might use YANG to ask the Wireless Access Point to only send signed proof of location if it turns out they are in a particular geography.

 

YANG models can support both opaque and explicitly typed data, even within the same model.  I expect that will be done in the cases described below.  It is also possible to have opaque data object with its internals YANG modeled and decipherable by the recipient of that opaque data.   If you want more details on how this can be done, check out: draft-ietf-netmod-yang-data-ext.

 

Thanks,
Eric

 

From: RATS, November 12, 2019 1:36 PM

 

An EAT would show up as a single statement in the RATS YANG module. The EAT would be opaque in the RATS YANG module. The RATS work group would not author any YANG to describe the claims described in the EAT document. 

 

The attester side implementation of this would:

*	Have code that creates CWT/COSE/CBOR formatted EAT tokens. This would probably be new code. Could also be JWT/JOSE/JSON.
*	Not need a TPM
*	Probably re use some existing libraries (JSON or XML or such) to implement what is described in the RATS YANG Module. That would not be anything to do with claims, so this part would exist primarily transport the opaque EAT.

I imagine if you were to use X.509 certificates with YANG, it would be really similar. The EAT is analogous to the X.509 certificate. There would be no YANG text authored to describe the internals of the X.509 certificate.

 

What I’ve described so far is what I want in the RATS YANG Module in order for it to be adopted.  The next paragraphs are about the idea of the TPM Token.

 

 

 

One way to describe my proposal is to split the current RATS YANG Module document into two.

 

A new TPM Token document would be created. It would describe a list of claims and a signature over those claims. This would be compatible with TPM signing. It would essentially be a serialization of the output of a TPM.

 

The RATS YANG Module document would have a large amount of its text replaced with a single statement that is for the transfer of either an EAT or a TPM Token.

 

LL

 

 

 

 

 

My thought is that EATs are opaque to the transport / conveyance protocol and that the YANG module should just describe a transport pr





On Nov 12, 2019, at 12:28 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de> > wrote:

 

Hi Laurence,

maybe I lack the required background knowledge about YANG here. My question is the following: Is it in-scope for a YANG modules (which typically have a well-defined semantic scope for each statement) to convey opaque EATs via a single statement. Or is it necessary to create YANG statements for each well-defined EAT Claim?

Viele Grüße,

Henk

On 12.11.19 05:16, Laurence Lundblade wrote:



What is most important for me is that the YANG document allow for EAT tokens as that seems like an important upgrade path / alternative given that EATs are much more capable.
But flip it around. In RATS maybe it should be possible for TPM-based attestations to go anywhere an EAT goes. You should be able move TPM attestations around by HTTP, or in TLS extension points or maybe even as an IMAP extension just like you can with EAT. To some degree FIDO has done it. It has a pluggable attestation architecture that allows several formats including TPM-based, Android SafetyNet (which is not Android key store) and some FIDO-specific schemes that are more EAT like.
That seems like it takes you to a clear demarcation between:
 * Self-securing signed attestation token
 * Token conveyance protocol
This seems very good in concept. We often separate like this in protocol design.
Then one way to look at the RATS work is in three:
1. EAT Attestation Token
2. TPM Token (that can be carried by HTTP and almost any conceivable
   protocol extension)
3. A very specific YANG-based conveyance protocol for routers because
   that’s how routers like it and it is important for the RATS work
   group constituency.
Maybe we’ll find another specific conveyance protocol we’ll want to address, but in general we don’t have to. All the web app, IoS app and Android app frameworks will be OK just like they are today for things like Android KeyStore.
If you look at it this way, 1) then EAT is fine as, 2) we need to define a new "TPM Token" format that is sort of an alternative to EAT, and 3) the YANG module has to be tweaked so it is a carrier of EATs and TPM Tokens. (I’m probably glossing over some of the complexity with YANG and TPMs).
TPM Token would not be a general claims carrier like EAT. TPM HW is super locked down and limited and TPM Token would just do what TPMs can do. Probably the “claims" amount to a few PCRs. Since the TPM signing format is fixed, the TPM Token signing format would be fixed. TPM Token is sort of a serialization of the output of a TPM. (It can’t be directly COSE as TPM’s can’t do RFC 8152 section 4.4, the COSE-specific creation of the to-be-signed bytes, when signing; probably similarly not JOSE). Since TPM Token is simple, will never change and won’t have extensions we don’t need all the weight of CDDL or YANG or such and can maybe go directly to JSON, XML or CBOR.
LL



On Nov 11, 2019, at 4:56 PM, Smith, Ned <ned.smith@intel.com <mailto:ned.smith@intel.com>  <mailto:ned.smith@intel.com>> wrote:

YANG I already being used to describe attestation flows and attestation related data. So the reason why is it is already deployed.

YANG has been used as an IM language but more commonly as a DML.

When trying to talk about attestation "Claims" it helps if we're speaking the same language.

On 11/11/19, 13:33 PM, "RATS on behalf of Schönwälder, Jürgen" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>  <mailto:rats-bounces@ietf.org> on behalf of J.Schoenwaelder@jacobs-university.de <mailto:J.Schoenwaelder@jacobs-university.de>  <mailto:J.Schoenwaelder@jacobs-university.de>> wrote:

   Hi,

   we commonly call YANG a data modeling language and not an information
   modeling language. Can someone explain why you want to use YANG?

   /js

   On Mon, Nov 11, 2019 at 09:27:09PM +0000, Smith, Ned wrote:



You’re saying YANG fills a gap that is similar to what OpenAPI/RAML fills?

It could be doing more than this as well, such as defining claims (as was suggested in a previous email by I think Michael). If RATS determined that the way to specify a Claim in the information model was via CDDL (only) and there is a YANG expression of it, then that implies a CDDL to YANG mapping is required. (Is that reasonable?).

Or RATS says that it is reasonable to use either/both CDDL and YANG for Claims expressions. This suggests there are CDDL and YANG mappings to whatever are the target DMLs (JOSE, COSE, DER, something else?). Does YANG support DML mappings to JOSE, COSE and DER or just to YANG? Does CDDL support mappings to DER and YANG (something else)?

Ideally CDDL can be mapped to other information modelling languages (e.g. YANG) so that only one normative expression needs to be canonized. However, that implies extra work on behalf of the YANG drafts to come up with the CDDL equivalent. Maybe that is unnecessary extra work for consistency sake? That would force the conversations around whether ‘time’ and ‘ticks’ are the same information model expression (for example).

-Ned

On 11/11/19, 11:52 AM, "RATS on behalf of Laurence Lundblade" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>  <mailto:rats-bounces@ietf.org><mailto:rats-bounces@ietf.org> on behalf of lgl@island-resort.com <mailto:lgl@island-resort.com>  <mailto:lgl@island-resort.com><mailto:lgl@island-resort.com>> wrote:

One more note on this. It seems wrong-headed to try express claims in YANG. To do that we’d need to invent a YANG signing standard (YOSE?). Seems like YANG should be thought of as RPC / conveyance / transport here, not as a way to format a signed attestation token.

LL



On Nov 11, 2019, at 11:47 AM, Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com>  <mailto:lgl@island-resort.com><mailto:lgl@island-resort.com>> wrote:

On Nov 10, 2019, at 9:20 PM, Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca>  <mailto:mcr+ietf@sandelman.ca><mailto:mcr+ietf@sandelman.ca>> wrote:


I think the value add to the larger RATS effort of adding EAT support
to this YANG protocol is really high. It a core thing to do that helps
bring together the two attestation worlds and make the TPM and EAT
work here less like ships in the night.

Can you explain what it would mean to add EAT support for a YANG module?

The EAT is an opaque chunk of data in YANG. I’m not a YANG expert, but maybe like this:

Server                               Device
GetAttestationTypes —>
                               <- TYPE_TPM, TYPE_CWT /* bit flags */

GetAttestation(TYPE_CWT , nonce) —>
                               <— CWT Token /* a full signed token */

I assume YANG can carry opaque binary data of moderate size.

The yang module information model would have an element for a nonce and for an opaque EAT. It would not describe any internals of the EAT. The information model for the EAT is separate in the EAT document.

LL









_______________________________________________
RATS mailing list
RATS@ietf.org <mailto:RATS@ietf.org>  <mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats



   --
   Juergen Schoenwaelder           Jacobs University Bremen gGmbH
   Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
   Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
   _______________________________________________
   RATS mailing list
RATS@ietf.org <mailto:RATS@ietf.org>  <mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats



_______________________________________________
RATS mailing list
RATS@ietf.org <mailto:RATS@ietf.org> 
https://www.ietf.org/mailman/listinfo/rats