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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 13 November 2019 11:15 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 3B40F12003F for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 03:15:16 -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 4Z0c6u8MVwRh for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 03:15:14 -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 8CC8B120013 for <rats@ietf.org>; Wed, 13 Nov 2019 03:15:14 -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 1260D3897A; Wed, 13 Nov 2019 06:12:04 -0500 (EST)
To: "Eric Voit (evoit)" <evoit@cisco.com>, Laurence Lundblade <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>, "Smith, Ned" <ned.smith@intel.com>, "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> <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> <DM6PR11MB4154E1339B3970802FF140C9A1770@DM6PR11MB4154.namprd11.prod.outlook.com>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <ac601d4b-225b-8f57-954c-903e305ca72d@sandelman.ca>
Date: Wed, 13 Nov 2019 19:15:08 +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: <DM6PR11MB4154E1339B3970802FF140C9A1770@DM6PR11MB4154.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/RFRsupDUTGQvhXrLwCLeHz3UfVk>
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:15:16 -0000


On 2019-11-13 3:41 a.m., Eric Voit (evoit) wrote:
>
> 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.
>

Where is the EAT token in this case?
Remember that's it's opaque binary.