Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 30 November 2020 17:19 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 73DF63A0F09 for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 09:19:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=JUpxZPO4; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=hz3q3vH1
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 W6lQ7hQSidYk for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 09:19:43 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2573A0FCA for <rats@ietf.org>; Mon, 30 Nov 2020 09:19:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11333; q=dns/txt; s=iport; t=1606756783; x=1607966383; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M+fwqQ7q577N1FgnCnoVloJ6yTUE9vqGp62eCm+xDos=; b=JUpxZPO4ZuS9xgr0srqKjKhlIrCTAJ/2wkLgs+PskzDsa7g34Z8eZqgv E1PwFEn371CykW/ytxh7PrjrqttFYA4DGX/d1ER+VTxUUfVl1es5w4Ulv QEkfCM8P+wzw2Ytb70a1u9h6lUHbl0+YHgNbQS9HggCW+2SEcc8l8jWTZ 0=;
X-Files: smime.p7s : 3975
X-IPAS-Result: =?us-ascii?q?A0DgCACrKMVffYoNJK1iHgEBCxIMg2FRfC0tLy4KhDODS?= =?us-ascii?q?QONWpkGgUKBEQNUCwEBAQoDAQEjCgIEAQGBVYJ1AoIpAiU4EwIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEFAEBhjwMhXIBAQEDARIRHQEBNwEECwIBCBUCJAcCAgIwH?= =?us-ascii?q?QgCBAENBQgGFIMFgX5XAw4RDwEOojMCgTyIaXaBMhOCcQEBBYEzAYNUGIIJB?= =?us-ascii?q?wMGgTiBU4Egg3aGVxuBQT+BEUOCJy4+gl0CgSoBEgEjgxUzgiyQU4Mph0ydJ?= =?us-ascii?q?gqCcIRUgmaBXZI3ohSGDI0FVIsHlWgCBAIEBQIOAQEFgW0haXBwFTuCNQEBM?= =?us-ascii?q?lAXAg2OIQsBFxSDOoUUhUR0NwIGAQkBAQMJfI1pAYEQAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AgEafQBRKnQwDANoH1xfaW5FTz9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB92J8PtCh+fStqnmH2cJst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8Wa76zIfHh?= =?us-ascii?q?D2M0x+L7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,382,1599523200"; d="p7s'?scan'208";a="641494521"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 17:19:42 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AUHJfId001620 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2020 17:19:41 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:19:41 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:19:40 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 12:19:40 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CKcr8bbZRiRJNa34wxhntzlxjODYTAcAEA/3HtrZxAJBTtMRPRisN57x+9vKNUTa4LwMGs2ae2Ot7NAZrfqhu0mQxnC9J6P8XOzDF3YvZLH2HDYXWuzSHk5/XaDfXseNiymSSOMDYoio3OilUk8cwxn2iU1zDwTS94EMMTn3t/TaAlwRagbJx01hRKF0qt8xSqCh+jL6z4m23MIw/gkT3IeTKC8Uz1nEqqtDsJpi4SWJLNv7YzEi4wgDRB3lJZtPSC4+YN/xdUA0bni97gvduWH8Fv6D9/+f7bPNWUkcgTxzlCO2ldHppc2vj+jmH+qVkUhAh8wWhjVxBCB7WtkKiw==
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=jwTljkyPpV5g/fRTQFDndftewUUgZ6BPPylym1ZFRAM=; b=gSI7YJJEKvDuaY3jj6v/9rzESZVeidgsEZhULS7ILb75//TFS3ss+G586BB4aH82On22/0+2MEKmgajfK7uiP7nUhuLvCn/kS+u1f3aZplO7RsHOeQ3FoZ+n/uWteebUnnYuCeSnM0iyulWIpO6YQbQ1myKlZcsJg9jYveeWtyMv6VQxgjp0HkW//X2DKrLiCbi2AtsX0TQWGcWOrnnMOJ1lz0WcKw/ipc5fYGhV9P3fRhlJL4j20osSZjCl3ZYQTxf0xD9f+1JGxa2i31cV6GE3PXgNZOAkpTYw4GRshRkVloMEGcWqiQ6jwjrlAX5kBPhm9V01PtIdy+7h9EP//g==
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=jwTljkyPpV5g/fRTQFDndftewUUgZ6BPPylym1ZFRAM=; b=hz3q3vH1/+EnhXDf/c7wYAgut7m+ZCz5VjMN6pxkdc6xybXKvwVOHsoWQmftgxeFANy1SHqZoNVfq74ps8kIcmyKDy9jRlnuqFx9HNfxQvRD40fp0s+auyBKoyTh8t5Sg/9msdVcV5JBZmcDo6yUPqcJF7VFRbb2LMT4GxBRIh4=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Mon, 30 Nov 2020 17:19:37 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::9851:12ed:f9df:af4f]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::9851:12ed:f9df:af4f%6]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 17:19:37 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Giri Mandyam <mandyam@qti.qualcomm.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
Thread-Index: AQHWxozTuKiYQWjnwEyQn7ccQdiVRqng59jw
Date: Mon, 30 Nov 2020 17:19:37 +0000
Message-ID: <BL0PR11MB312296BEFD428C6D9CE9A5DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <24519.1606681083@localhost>
In-Reply-To: <24519.1606681083@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [108.18.114.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 12b775b0-553d-47fb-94a6-08d895541d9e
x-ms-traffictypediagnostic: MN2PR11MB4351:
x-microsoft-antispam-prvs: <MN2PR11MB4351C0E237FAF5BAED95A8DCA1F50@MN2PR11MB4351.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2512;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: C+89IrURo6JlUT2l/uUn8cogSiA/6KjQ8fYNvwPMdvDU3clRlvxY9ymjwOKF4uxnI/gyptfM4YzB/sJuHTLyOWqV7KV9+FgY0pNmW6AEIGpAAgbnaWkImCPpGI0RVT6of/NZali7ALT29XIMlyYdZcbb75GA56DsXNX8CnQIpekGMOmp31kYXtH4hO8G4pp/a40p+C8fi8twv/298TAP1TLITpdQuKqi3q9Iu02HubTWlRWGvyZ1SXHbCDNiBxLmvMGnuYDcbFxldJ86KUaT2WwFcnnJvRXqza4v+FEvTHYc4ELqJ7y8Iaw4HWoUqvpCGI2Szc2gnWoryvvlubarnj5lB80LOXBUPCmcqmsCxeudN4obUgH0pCyX/iUscAWqC5ms/yw0mIV8v/uke205NA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(396003)(346002)(376002)(366004)(9686003)(316002)(66946007)(86362001)(66446008)(52536014)(6506007)(83380400001)(33656002)(478600001)(55016002)(110136005)(66616009)(76116006)(66476007)(66574015)(71200400001)(64756008)(66556008)(966005)(26005)(7696005)(2906002)(4326008)(99936003)(5660300002)(8936002)(8676002)(186003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?anBxK0dPRG1DR2V2SzRaRVh5Ui9KcytNck4vOTdodmE2U1RmNWNHYjJGak9j?= =?utf-8?B?Ni9uMERQOXZxeFB6QklYMWx1SHkybGxOVWVIdjRmVWpkQlVFY0pCZno2SlEw?= =?utf-8?B?THl1WkhndHBmQnpCSHFTd1VzdWNFUEVlTXdJbEhjbHg3dHV6bVVobUU3QWpT?= =?utf-8?B?eDY4M1cweHBybmhNUUVvTEZuSHBkMkU1K2FzSm4vWVpLdzZISkFabitIRU1X?= =?utf-8?B?K1ZqSHl5RVBtVlNiMGtNWDE4bnM1aStUQWt0OTZFMkQxVzlNUU1MOS8xQ3pB?= =?utf-8?B?cURidk15UGhjYlNvUDRibW92RUcvTzdXU2RCYmN5R3Y0QkVmTHh1aVJNajBk?= =?utf-8?B?amQydG1DTWpVNnI0VTQ0SGhmN2Zpam52NzB4ZFh1ZXRhdWxIUlgwdFVseU05?= =?utf-8?B?MFc5dStMVnFxakppUWl0Vzd1RWljWVd4dHhaS1Y3SUZQR2lwb0Z5Ry80ck8z?= =?utf-8?B?UllEK0t2Z3F0QzdaR25RK2V5RFA5OVlyYnBZV0t1WDFUeEMzcXllTVVwbWh6?= =?utf-8?B?T3FKUUhsckFkV0pjTTUvU3FaU0JSTjhvYzk1NHdNSnpta1NaVEw1MDB0SHpk?= =?utf-8?B?bHhDa09VL1Z6RlJkaHdkbzUvK3VHRWRHQjRod3psVWJIaVdtL0JVZlUzNldW?= =?utf-8?B?RHhqWmpublg0c0hsYWtwSkI3OWNWSDFQMVJoODR1YkZRSnk5UGZSMnFlWjh0?= =?utf-8?B?R2s2WUFoZVhNUU9iNTZrUU45c1JQeTdJV05zSDBVR0FraEhydWZLaWE0ZnBK?= =?utf-8?B?OTJqMkt5UXc2eVY4SHlzMzFicEpUY09vc0RHSTlDeXhNYjZxVit6dVVwdnJu?= =?utf-8?B?ZytBajJ0dDJMRDdEWVZ1blBYVkVaSUJnaTRvSDVWK1RGVGpHb2RoYlMvQWht?= =?utf-8?B?OE8yTXl1OXhUZklscEdPUWh1TUdGcnlTNmhzRzYwZHN0WEZabUhKWVhrWmFO?= =?utf-8?B?UFphd0pLYXV1Q01mSUcyVVNISHJYOVV0Wkk5WEpLMzd2MnNZMTRsRTRSZ0R1?= =?utf-8?B?Tzc3TU1DR2FuejAyNzJWSHhMR0xsd0FXYjZUcWJtbGdQbTg0ZDlzME1ySHVJ?= =?utf-8?B?SFZ5dEdiRVZaZFd3MEhQTGprSlI4NjFpUXljdEtRNnNPRlExL2xUVWF4dmhY?= =?utf-8?B?Z3BUNXhvL3BudjlCUTJMT21LKzBBRDJURW1OaUFIT21ySU5QUVV2VzJsM2tS?= =?utf-8?B?MFF3V0U4YUhtcEY5L3NKc24xNS84czhFUjJxdEhDS043VjRFNFlIdWFETCtD?= =?utf-8?B?TVZZNGRRSVZkcDdZSjkzQkV2cTdkRlkyYXY4MEtWYUJ5TDlJdGZYZ1pXamEr?= =?utf-8?Q?ascMxnAN1+UOc=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A9_01D6C713.0FCE9070"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 12b775b0-553d-47fb-94a6-08d895541d9e
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 17:19:37.8189 (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: uVTpPDP+6/BLzp5tU0Erw5M+F3MlHmJKM/JJSTSvyqr6J/mI4GY78a6KSpZYxVqn
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4351
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_lIwgrXbxNb64Ix0EJlLqvMaVug>
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
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: Mon, 30 Nov 2020 17:19:53 -0000

Hi Michael,

This thread reminds me of some of the EAT draft adoption discussions from May of 2019.   Some of the threads I remember from the discussion include:

https://mailarchive.ietf.org/arch/msg/rats/7Uzkd84plkQ_LJ6oUYTQ3iwkmws/
https://mailarchive.ietf.org/arch/msg/rats/KPU6WgiCGkT6mUTbf5Ga41KwSNc/
https://mailarchive.ietf.org/arch/msg/rats/jBCYPK2hly554HGYTXZXa2t_AGw/

At the time, there was general agreement that where object definitions existed, it would be good to re-use them.  That would reduce the mapping needed between IANA maintained object definitions between technology spaces.  

Below in your email you point to a list of YANG specifications named within draft-ietf-core-sid, section 7.5.3.  I think you are doing this for as a starting point for some object definition contents.  Am I interpreting this correctly?   If yes, this is exactly what I was hoping might happen.

Eric


> From: Michael Richardson, November 29, 2020 3:18 PM
> To: Giri Mandyam <mandyam@qti.qualcomm.com>om>; rats@ietf.org
> Subject: [Rats] challenges of building dependant specifications against Internet-
> Drafts -- a way forward for EAT
> 
> 
> Hi, sorry that I missed the RATS IETF109 meeting: I was engaged as co-chair
> of ASDF at the same time.   I watched the video.
> 
> I think that the many EAT concerns are now at the point where more
> conversation probably will make it worse rather than better.
> It's time to move on with the EAT framework: many of the issues discussed will
> become much clearer when it is used.
> That's why we have "PS" vs "Internet Standard".
> 
> I found Giri's presentation interesting: I scanned through the FIDO IoT
> Onboarding document, and I have no idea why FIDO needs to re-invent
> (Constrained) BRSKI.   But, I'm excited about it!
> 
> The more the manufacturers understand the need for device identities, and for a
> "home base" (A Registrar), the better our whole industry will be.
> When MS tried to do this with the XBOX-1 a decade ago, people cried foul, but
> maybe they weren't ready for this in the home yet.  We certainly need it to be
> standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.
> 
> The single reference to RFC8366 did not explain why that document did not
> adopt a semantically compatible voucher format.
> 
> draft-ietf-anima-constrained-voucher explains how to serialize the YANG to
> CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
> This is then signed with COSE.
> {Or CMS, but that option is going away}
> 
> The result is almost *syntactically* identical to an EAT (a map of stuff signed by
> COSE)!
> But the semantics are a fair bit different.
> Vouchers contain many things which I would not call claims, but embody
> essentially a single claim concerning ownership.
> 
> draft-ietf-core-sid establishes a registry for SID values, which as essentially map
> keys for CBOR.  It has been difficult to get the document to advance, and until it
> did, we couldn't figure out how we'd be able to do the IANA allocation process:
> hard to get an early allocation against a registry which does not yet exist.
> 
> What we did, and what Giri could ask the EAT authors and WG to do is to
> allocate some claims in the initial IANA Considerations section.
> That is, until such time as the document progresses through the IESG, the WG
> and the document authors essentially act as IANA.
> 
> Here is what it looks like from draft-ietf-core-sid:
> 
> section 7.5.3 (of sid-14):
> 
>    Initial entries in this registry are as follows:
> 
>    +-------+------+---------------------------+------------------------+
>    | Entry | Size | Module name               | Document reference     |
>    | Point |      |                           |                        |
>    +-------+------+---------------------------+------------------------+
>    |  1000 |  100 | ietf-coreconf             | [I-D.ietf-core-comi]   |
>    |  1100 |   50 | ietf-yang-types           | [RFC6991]              |
>    |  1150 |   50 | ietf-inet-types           | [RFC6991]              |
>    |  1200 |   50 | iana-crypt-hash           | [RFC7317]              |
>    |  1250 |   50 | ietf-netconf-acm          | [RFC8341]              |
>    |  1300 |   50 | ietf-sid-file             | RFCXXXX                |
>    |  1500 |  100 | ietf-interfaces           | [RFC8343]              |
>    |  1600 |  100 | ietf-ip                   | [RFC8344]              |
>    |  1700 |  100 | ietf-system               | [RFC7317]              |
>    |  1800 |  400 | iana-if-type              | [RFC7224]              |
>    |  2400 |   50 | ietf-voucher              | [RFC8366]              |
>    |  2450 |   50 | ietf-constrained-voucher  | [I-D.ietf-anima-constr |
>    |       |      |                           | ained-voucher]         |
>    |  2500 |   50 | ietf-constrained-voucher- | [I-D.ietf-anima-constr |
>    |       |      | request                   | ained-voucher]         |
>    +-------+------+---------------------------+------------------------+
> 
> 
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>