From nobody Sun Aug 1 01:11:18 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2893A31CD for ; Sun, 1 Aug 2021 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SMH73T+h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OoK3kpxq 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 4Eb45kJhFWsG for ; Sun, 1 Aug 2021 01:11:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D93A31C9 for ; Sun, 1 Aug 2021 01:11:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E21B8320077A for ; Sun, 1 Aug 2021 03:34:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 01 Aug 2021 03:34:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=00j/jq/RXeU 5I5ZA7iKKXCaNBI/Dy6Ia/dKQhwFX8wk=; b=SMH73T+hjjUUrGKBEcBGIS9Ny7a WtmSAbKH46mwNMRK6u/K48ANVV9hMArbbmFM41ROYjfuBzS+CF0dK+uSbXv+kxUr yHJYrwDxN+tmvSIBcZ50Xfbw9zAfLtxwztyaN5Il2aMq9PiyfMR1rOyDTcWWjVVA A/gs5JfacGUOV/bMnruShOuQN/UaYO0qdq8Ny6Gk3FlZsa6Wkb7A/XvJZnVmCD29 q79xKLKJ5Nni2iwzucRfE1PW/KQYHlVcgMXf+3xV53TedevBjMswnZiCQF6Z6zaY g2ZR1l7P25za9VOl63uGwicnTxstxPjXZWx0nKo7uBnQWm2kOsJNvh6ZORQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=00j/jq/RXeU5I5ZA7iKKXCaNBI/Dy6Ia/dKQhwFX8wk=; b=OoK3kpxq dmQo88DUO/J6kCLCWLsSUaR21/uDcXLg8/VVXsDTJX8M7bvORezbbDWmrAA0sfJ5 fnbduV+sWDcqPGtujWjq2uJQialRZsuOXHIgSA+FmeZOLFC/cqshwZ5mU8eagWQ7 dpnl968rvh4KMwrRfTwFSp6hqLU2Sab5jChNmGX0Dj3tkKteaQIqP9aDk04EEcSP +Oc4UMrntNIX34OLS+Ts9hs8f551AP9pd8OBI/97CxXcZ5IIfRtaLSXurRIbBR9p Ud4aHveKQFKejZiwKjofBlFiSTZ0bQUYovvRKtwiFVddjSidvoTD/ac1XzeFfH+u f4UcVk7BEUB7pw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheelgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmnecujf gurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhihucet tghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeugfef hfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 1 Aug 2021 03:34:48 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0397769265019461632==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cose@ietf.org Message-Id: <20210801081108.CF6D93A31C9@ietfa.amsl.com> Date: Sun, 1 Aug 2021 01:11:08 -0700 (PDT) Archived-At: Subject: [COSE] Weekly github digest (COSE Activity Summary) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 08:11:15 -0000 --===============0397769265019461632== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cose-wg/X509 (+0/-0/=F0=9F=92=AC3) 1 issues received 3 new comments: - #36 Prefer just array for x5bag and x5chain (3 by cabo, laurencelundbla= de) https://github.com/cose-wg/X509/issues/36=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cose-wg/CBOR-certificates * https://github.com/cose-wg/Charter * https://github.com/cose-wg/cose-rfc8152bis * https://github.com/cose-wg/countersign * https://github.com/cose-wg/X509 --===============0397769265019461632== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (COSE Activity Summary)

Sunday August 01, 2021

Events without label "editorial"

Issues

cose-wg/X509 (+0/-0/=F0=9F=92=AC3)

1 issues received 3 new comments:

Repositories tracked by this digest:

--===============0397769265019461632==-- From nobody Sun Aug 1 23:08:27 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A993A0BB2 for ; Sun, 1 Aug 2021 23:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mattrglobal242.onmicrosoft.com 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 QIPN_STTVeVA for ; Sun, 1 Aug 2021 23:08:20 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on2108.outbound.protection.outlook.com [40.107.108.108]) (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 69C8F3A0BB1 for ; Sun, 1 Aug 2021 23:08:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gYFKoJG3Ip5J8nZdh8q1PjykU1qrAVwI5pcxtFVVADeMBaDaH4Le8jHt6n8JvjXufrD80vK5OX8EYFiC6TdMbj+HGM1h6TrylonSQH/WL8GnUgd+XMAF4QiK8E1z43Jq2Lbsb1cRspXYREXXs1WAKsap9R+tWZMHQEL/SIvyhyV/GES38mmCd0VHRHBXrkt2bHpYxTwncqshIC7X6ozmVH4DDQyaifVl46Cbzq8pDYOOEr2F5YtppHafUyCVULuZvJ6jkNw6m1U3uk4W1yzq8FzaupUoK+PwfTgbcHtLq13UJsgCkluAgNKHxI4ozreuvd9DcK04aEYN0Sh+59oygg== 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=Ibfnvm3iVBDu7Ls5gFYJp8iOGSaoS/x1ac5sV0M1TFo=; b=HSLSVSRtZowOln+c4juH6C89xGOokxMKAaOta+nwpHvG7SATE3i4Km3RFMihXp6OH4lvCXsqhI3laFJZGxJe4hhznemLU/TNI6G8JFCSlq7MjMrOxN/pTfp/EU11Gd+mKNmIZ00hylPrcUdMUWvJ6U5KIP5eZuIwYxznBkJxedhuSPCQoWxnkL2M05G9m8EfwMFRBDTGLVuq5nc7CHrECOSiKCJqClHKQFkAl8VoCx71T9Wsxfv6QGrS+q2euZCOV1IfT2Hg+UJYWGYejHBvhaSX3hQUx6wHYGl+4Ew3teLNIMQHYshJx2wOn5Na8d4e85ibDRO47aLtWOkuLoo9og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mattr.global; dmarc=pass action=none header.from=mattr.global; dkim=pass header.d=mattr.global; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattrglobal242.onmicrosoft.com; s=selector1-mattrglobal242-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ibfnvm3iVBDu7Ls5gFYJp8iOGSaoS/x1ac5sV0M1TFo=; b=IGuOOmXQBUUhZzdq+b5RzuDSoiUUBb2qUbjQrfHsa018o8CSKN5qKZmkz59RhjtDNtFAnNx3OpqMwLJjOyoBgHVbyVL+SAHXLnAApE6Cwmn891UYOroQK3UT783GxXkJm4Rxyi4ZOlmc9hfAIUGYEjhKHd229UPF2FfUYqK3HCA= Received: from SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a9::8) by SYBP282MB0667.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:18::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.20; Mon, 2 Aug 2021 06:08:16 +0000 Received: from SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM ([fe80::1d34:fe2a:57a1:28e]) by SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM ([fe80::1d34:fe2a:57a1:28e%7]) with mapi id 15.20.4373.026; Mon, 2 Aug 2021 06:08:16 +0000 From: Kyle Den Hartog To: "cose@ietf.org" Thread-Topic: Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose Thread-Index: AQHXh14rDCNZ4UEEXka/UfIWuuJSyg== Date: Mon, 2 Aug 2021 06:08:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mattr.global; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c4492b6-b51b-4b53-b3ea-08d9557beb74 x-ms-traffictypediagnostic: SYBP282MB0667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BKS5BhyxKV6gThtqgmxIfaL9WoeTuJXQI9P3SWdTfON1YI0Ui8wxAUzqATVGFz5vho6JLq0sOcgnYqs2y87tGe1L+GhUtTDOyKYqIm3ICm4G2wffouXEtQOW3tNXf8U+hI/dGlD4pbZHE8Idn/SjvHvTe6h/rE/1Wq8L/NHvJES/ixuAoM501Z5E1BvrTr3T4kpNYTs6zrAvwxQ8K4YjOS2vby198CJxuku6jvjhXt4/AXRjn0h+cfpNG4OGI3y/K4EnK3NHI5qfzlOYbftJ59/gy/dw3xLWZBGjUc2L2hAEQDrvFm78QLetEvaZx/gmeQv5BJad+EpnZBVxyib75QxpIaQTH0SzfSGYXBT0uhaXBzrFf2YYySve65OdLU9xEuAa5xLGP+0T0JAlbbipkzk2pG4fDc2zWqCXHaM4ig1M7BTMuDbzG3ihGGOKsLRI3k93C5J7T6c6V0CjruMTsBUdNzkC+8RA6byvzFbei/b2NrXVqjDbJ7F6KS61To4QYrfcrYhARW6CUzwQ4t0qK6FPyJkQduas/euC5mJPs+x4We8xJ7rYQOSD/Ej9x1I7JOD1L2VGM+vFGmXRdNzDxMUEXTtR6m7enkOxtYipSc+F2Q4vNtMnHvGiajIPRTwfuph6jXs9ASK2egL2VwcAO29wORMJ/ResmWS7wY8N0AQlO9a3ZcDrVGv/6snxbfHTPg9PISnjBCKmFsMbQm5OcUWxGu9nhmD5KA+guy/bx2WOscVlOW5vZvCORKwaYJMf58JhcDJcbQ+nbPlKUzt5jA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(39830400003)(346002)(136003)(66476007)(186003)(66946007)(8936002)(478600001)(66446008)(64756008)(66556008)(71200400001)(76116006)(38070700005)(33656002)(6916009)(38100700002)(8676002)(2906002)(19627235002)(6506007)(55016002)(19627405001)(9686003)(166002)(7696005)(52536014)(966005)(83380400001)(122000001)(316002)(5660300002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?CK2eNYQJWx1hjzG/665cSPJl3BTVu4byc3KJ65KwrV8fsAHVEpTIOALGf4?= =?iso-8859-1?Q?mrhTkWzXvRA2cBjylK8aBq22Imk7ovyIoXBvIpefrffMflUbKiylMAPlK+?= =?iso-8859-1?Q?ZZoCRN/3Ap/wrzSrAg2qF0b4YhIQXerwq7i2bA2zXY/ogDXmftg876Vy8+?= =?iso-8859-1?Q?GpcQ0hAmPoZMI5OQAh+7YUqwzz/VA+JYgJiTjY8IH++r1O5a5PO8rMKxjb?= =?iso-8859-1?Q?DluXEN92zuINqGUtEcthSExZgz9/L1ki2RIloNX6/oheatksx2H4auVUx3?= =?iso-8859-1?Q?22Z3O6OLTwi0ArRr2UWY1u6Y+SJpEZOkDmaFNug1RhpwEd8WIDdgGLE/M8?= =?iso-8859-1?Q?9BGx/+N8l6jpT3rtTflWNJhRlYKpAtyMAP9l6hz5cs60jhBKY9eh5qK68h?= =?iso-8859-1?Q?zQdq0v8TqYCnJU7nmGSabII1DhUAMRb+iQXuUobpdOhZ60375w6wDv9mX1?= =?iso-8859-1?Q?5W6mBaMwl+B61+GyjPkkXQWrnwXdNtEP99VuWalu1cNDyURNuYgcjHFSQT?= =?iso-8859-1?Q?3NrZkDNlT14igg7Jcf+TWGe5dOkz2wQa+n6vAXDcBe/JXVWIYYR/FE69hr?= =?iso-8859-1?Q?M3+R3K/TbJXZ3gGk5thgXCSrC0RrhKacA7kqUupuQvER4bP6WYN8jaRj7H?= =?iso-8859-1?Q?MXsFfTavHEh4fDA5GBGy0y4L08Ppz6v38kS35agsrldmVKeYyAmDPyy246?= =?iso-8859-1?Q?/w4mSmRXkUTIjpd2BbqiAtdnsNyLfYbE/pFhU+kcdHQZJJeKD51Q9ujFv0?= =?iso-8859-1?Q?QaFDIlXc3e4kRn9HbiW1nrlnjf6Ax+VMMnoVTkuhJIX+VLj3SsTLipyXZ8?= =?iso-8859-1?Q?MKaJnqp6fmWD973WvmczbEd+e6wJuGv+gqxLSNodpYPgtJlReZKETGy011?= =?iso-8859-1?Q?YD3oQpfUj1zFUKgQL58hGyUnzmEUeUkpkM2SyvpcqN3yYnlytaTsf0WEln?= =?iso-8859-1?Q?k7sLD3I/jthx3bL/70BYW48/xKOIoX1K9NZWQeieS9L7JU7Yo7ebHhrbtZ?= =?iso-8859-1?Q?aPCCTAexYi5xqNRmd3QfQXMy9GtjhPYf9TAkLK05E+lQWqRy5b5K/dSeec?= =?iso-8859-1?Q?atwHuRQGDkC+qv/CPwqKju9MJaEEEledR/25LuRokJaQDN3q7H1EDQ2xPf?= =?iso-8859-1?Q?WRgHv1dDvlP+DS7LevrykkX45x8HGiyMpjJ2hWfCdaiXNMUUANT0zP0xH1?= =?iso-8859-1?Q?f5fPwfybxPJN++V+fLSZ90t3TB7gQ6E30Gi+I5+SZAR835S3GX6S+8dkjA?= =?iso-8859-1?Q?hPBgrJ2yi4GE3u33y7+YnrB9MMljpI7N8qKod0D8DCtK9pRFMR9g/l/aCy?= =?iso-8859-1?Q?TIBMJrmu3GOsPToZuiRgeeCC6gxbK00zaJI7K6il/gNuNw2FkCksoB7bb5?= =?iso-8859-1?Q?KiqdPa/L2H0lSxcigmvES7gbp2bKcTQXlKj1rTfSn712ZNEmh5OSU=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SY4P282MB079646C3E9D472CE7A34D233FCEF9SY4P282MB0796AUSP_" MIME-Version: 1.0 X-OriginatorOrg: mattr.global X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5c4492b6-b51b-4b53-b3ea-08d9557beb74 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2021 06:08:16.8730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c2c9cf73-6aae-4702-9844-02adab723771 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IYvvvGvv+swvp9sRgLUubcNWMSBAHtQKHaxXYj1WgfILHKIFfPQfrF7XTI/9JEo9PQDBaulbwhtaNXZ4F4YUVGls44v5x6GtkYM6pNCauZw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBP282MB0667 Archived-At: Subject: [COSE] Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 06:08:26 -0000 --_000_SY4P282MB079646C3E9D472CE7A34D233FCEF9SY4P282MB0796AUSP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First off thanks Mike Jones for jumping in and PowerPoint jockeying through= the slides for me. Sorry for missing the meeting I had a time zone mix up.= I was able to rewatch the portion of the recording afterwards and wanted t= o weigh in on a few questions I heard and had prompted on the slides. 1. Should we use EC2 vs OKP? * This is where I was going with this question. It was asked to me i= f SEC1 encoding was commonly in use today. I realize now that the draft doe= sn't accurately convey that when I referenced SEC1 that I was implying the = usage of SEC1 point compression which would then use OKP. I'll need to upda= te that. As far as I've seen it's mainly gone towards OKP (with a single co= mpressed point and a sign) so my take was that we follow that pattern as we= ll. However, the latest pairing-friendly-curves draft[1] references draft-i= etf-lwig-curve-representations[2] (note it's draft 08 while the latest draf= t it's now in Appendix I.5). In this case, my questions was trying to figur= e out if the draft should use the SEC1 compression serialization of the key= s which seems more common in JOSE and COSE or if it would be better to cont= inue in the serialization method described in section 2.5. In this case, I = didn't fully understand what was being described in the lwig-curve draft, s= o I opted to go with SEC1 compressions in the initial draft. I'd like to ge= t others to weigh in on if this is even possible first, and then for us to = consider what is the better direction. 2. Whether Bn256G1/G2 should be registered and prohibited? * The discussion hit the nail on the head here. Thank you, Jonathan = Hammell, for jumping in and explaining the background on the security issue= . My concern was that because the security has been reduced to 100 bits rat= her than 128 bits does this warrant the draft defining it and marking it as= prohibited. My take was "yes" hence the original question. 3. Regarding the G1/G2 question: * This was largely heading in the direction of trying to figure out = if it makes sense to recogonize these separate finite fields as independent= "curves" or would it make more sense to use a different way to differentia= te them. One suggestion on the github repo has been to use multicodec as an= alternative serialization to SEC1 and lwigs-curve and then use that as a w= ay to represent the sub groups. My general take is that this didn't align w= ell with the traditional approach COSE/JOSE have used and so it's going to = introduce some new dependencies in many implementations I'd suspect. For th= is reason I would prefer to not go this route, but am not necessarily certa= in if my "crv" route is the right way either. 4. Regarding defining these with signatures: * My general take would be that I'd prefer to not have to do this. S= ince we haven't implemented any of the signatures schemes that utilize thes= e curves in JOSE or COSE, it would be a bit of a yak shaving exercise for u= s and our primary goals at this point to have to also define those. I know = of some related proposals that are looking to define these signatures (BBS+= ) in JOSE in the very introductory stages which may pair well with this, bu= t for now I'm of the opinion we could just as easily separate the works. If= there is a desire to define at least one signature scheme with this, the I= RTF does have the BLS signatures[3] being worked on which would pair well w= ith this work if there's a desire to add threshold signatures to JOSE/COSE. Hopefully with this additional context to the slides, people may have a bet= ter understanding and some further opinions on the various questions to dat= e. [1]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly= -curves-10#section-2.5 [2]: https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representa= tions-08#appendix-J.4 [3]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04= / Thanks, Kyle Den Hartog --_000_SY4P282MB079646C3E9D472CE7A34D233FCEF9SY4P282MB0796AUSP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
First off thanks Mike Jones for jumping in and PowerPoint jockeying through= the slides for me. Sorry for missing the meeting I had a time zone mix up.= I was able to rewatch the portion of the recording afterwards and wanted t= o weigh in on a few questions I heard and had prompted on the slides.
  1. Should we use EC2 vs OKP?
    1. This is where I was going with this question. It was asked to me = if SEC1 encoding was commonly in use today. I realize now that the draft do= esn't accurately convey that when I referenced SEC1 that I was implying the= usage of SEC1 point compression which would then use OKP. I'll need to update that. As far as I've seen it= 's mainly gone towards OKP (with a single compressed point and a sign) so m= y take was that we follow that pattern as well. However, the latest pairing= -friendly-curves draft[1] references draft-ietf-lwig-curve-representations[2] (note it's draft 08 while the lat= est draft it's now in Appendix I.5). In this case, my questions was trying = to figure out if the draft should use the SEC1 compression serialization of= the keys which seems more common in JOSE and COSE or if it would be better to continue in the serialization= method described in section 2.5. In this case, I didn't fully understand w= hat was being described in the lwig-curve draft, so I opted to go with SEC1= compressions in the initial draft. I'd like to get others to weigh in on if this is even possible first, and = then for us to consider what is the better direction.
  2. Whether Bn256G1/G2 should be registered and prohibited?
    1. The discussion hit the nail on the head here. Thank you, Jonathan Hamme= ll, for jumping in and explaining the background on the security issue. My = concern was that because the security has been reduced to 100 bits rather t= han 128 bits does this warrant the draft defining it and marking it as prohibited. My take was "yes"= ; hence the original question.
  3. Regarding the G1/G2 question:
    1. This was largely heading in the direction of trying to figure out if it= makes sense to recogonize these separate finite fields as independent &quo= t;curves" or would it make more sense to use a different way to differ= entiate them. One suggestion on the github repo has been to use multicodec as an alternative serialization to SEC1 an= d lwigs-curve and then use that as a way to represent the sub groups. My ge= neral take is that this didn't align well with the traditional approach COS= E/JOSE have used and so it's going to introduce some new dependencies in many implementations I'd suspect. Fo= r this reason I would prefer to not go this route, but am not necessarily c= ertain if my "crv" route is the right way either.
  4. Regarding defining these with signatures:
    1. My general take would be that I'd prefer to not have to do this. Since = we haven't implemented any of the signatures schemes that utilize these cur= ves in JOSE or COSE, it would be a bit of a yak shaving exercise for us and= our primary goals at this point to have to also define those. I know of some related proposals that are lo= oking to define these signatures (BBS+) in JOSE in the very introductory st= ages which may pair well with this, but for now I'm of the opinion we could= just as easily separate the works. If there is a desire to define at least one signature scheme with this, th= e IRTF does have the BLS signatures[3] being worked on which would pair wel= l with this work if there's a desire to add threshold signatures to JOSE/CO= SE.
Hopefully with this additional context to the slides, people may have = a better understanding and some further opinions on the various questions t= o date.

--_000_SY4P282MB079646C3E9D472CE7A34D233FCEF9SY4P282MB0796AUSP_-- From nobody Thu Aug 5 03:48:38 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D948C3A094F for ; Thu, 5 Aug 2021 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 yy-cajzBl4cD for ; Thu, 5 Aug 2021 03:48:30 -0700 (PDT) Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.140.77]) (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 678763A0958 for ; Thu, 5 Aug 2021 03:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1628160504; x=1628765304; h=from:to:subject:date:message-id:mime-version; bh=CSTLizqSwvuK/yjO800G45V9/w8ETEiWqE27if0+zeE=; b=2HlLVzFuPhqk9yyTVj918IllnimKe8GXvAsRx/9BbSXmskpq9hSAw1WM bW9KVTNy60be+H4YEVlzqu+1AQCSOqYqCet7TrXKKJ18FMftL2sgjzSPx yaQSNK/WZwPttlGjY4bvCmVyc9g2Hk2VL70t1njodpn6bjsZzlhuS46nK M=; Received: from mail-bn1nam07lp2049.outbound.protection.outlook.com (HELO NAM02-BN1-obe.outbound.protection.outlook.com) ([104.47.51.49]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:48:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X8FRBhQRqFt4C7lryUvvBEJPo6Y/9l4R+lygmWiVx8VFViJ9VDrGbyIG9KwNX/XMcyM/2FJdFVKJ+/1UDxezlpHsZCYdkyjXRSv2lcybPMbSlFXvEIo8m7xeXgpJ3Ml9SiqJiEpy/QP7rQTrTQsofvZdKHXFgiYo99n5aO852kjm4kPQnxWbXAYfLwN9rhmzqG+3cInGNAf8I62mtEro35MKfDOhCA+zn1Wmex+ChyQZzdxeY+oo/s7Ne1DdW29qLGksgouwVPApY/PBT3gH2SdGaNaGAD8Sk89f6sve2nIhVGpD9Wb+jObVZnJXFX7uJdLZmXClKSptpIQqnxoFsA== 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=lhiRUj3sK6LDfkDir/1OOwVByDS883SZiXxxnELxHic=; b=k4CxspJWj/nem8CG3CRU+Dg2s99I07Mv95HXDAczG/Smo/DowxCK32qS+KMFsFjlwZvIrTRhk1RzEQKBTcl/xlEZijFow6J2njR/WAOJNA4gkz4xRTrksP0/mkWY+SvVpzgvUn3Dco/AHN1O+4sY3GdlNXZuFrgzxfXJ5ZEAfsp8SX1nspNAf4G2/Q0fvKtMKglNDALQAO23BD7iJVMDD1GHPYLkkOsjfMzfW8fNJsYGnMJZpvvzYWnb6iKQLYe8U4Ps9235pk+Aemv/ipqO14dgUOQ2Hj5ITjqoLS2ZOhFvrxfMUv9ULz2IAaRfI9YkSng7dbhsO6z7fE0lHd8D4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from SA1PR02MB8349.namprd02.prod.outlook.com (2603:10b6:806:1e4::19) by SN6PR02MB4016.namprd02.prod.outlook.com (2603:10b6:805:30::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Thu, 5 Aug 2021 10:48:17 +0000 Received: from SA1PR02MB8349.namprd02.prod.outlook.com ([fe80::b0de:4d7f:8026:700e]) by SA1PR02MB8349.namprd02.prod.outlook.com ([fe80::b0de:4d7f:8026:700e%7]) with mapi id 15.20.4394.018; Thu, 5 Aug 2021 10:48:17 +0000 From: Jeremy O'Donoghue To: "cose@ietf.org" Thread-Topic: [COSE] tstr values for kty, alg, crv, etc. Thread-Index: AQHXid+ArUTm21UMwU6Ubf7YloGzcA== Date: Thu, 5 Aug 2021 10:48:17 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=qti.qualcomm.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c9f1859-1ef6-4416-45d9-08d957fe88df x-ms-traffictypediagnostic: SN6PR02MB4016: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HNeQdOqiwz4mowHzsaWA/xmILSlayFDLLLGm5wZ4y+KcFPyoc9j6wuGDH69QdDks+7CLqCmawkeb7Kh5v9W3WsCEPf1KNiWFgqJ5f7BVhwcWmfmchB0q620MvT2kiBQyJB48yK+uaEdo4NKiWZKXLRa8RbNi7DirevCpRy1VldzHYYTdGu3M+mYQQde1FvdZCxLlh7UjqXZ7lmu897VkdUqDViqnOwfW563yXafw7Ix434dCsVKgm5UmXN4jq2T725AcUr2IMUFlrFzOXlKZAb2y3GP/90DgA9N7lqzRGTik77BCiYnGIMLlItgoKK/2HrLHSNMkeOHn4Ww65GDF6745aglUgejUoWzNlZ616Ql/hNcS1MYz0IbsbYDP9FMVcF5yhvmfVrMU/sLfo/ZvjgmvqiSE+B2cXRj47El1Bcd0aPxnt5zvcpu8i3QWsrxnAlBXtUwMJ9xiY/7Vs3m93k5BdjknH2fFHafAZ0fWHGPqblOfRyuyV7CLw6u1ZRecrI2ENR84b6+l4rIFHdPbKM571AS08g5m8hG+bDXa/Y2lJM3dgTjN7WvoU4dYQrZPFdl55VDN/ud8efGB6wFvYBOPSas1ken/njy7PhIg+c0tBgF36Uc5EIWkX1qY+C1BsvTYk5TCDxagxVPeK5jAa1sgVsNmDt2KMHRcM18ZbpYo6Yv4iLL/s6rgG8KXAqWEi0iGZKkbym9HX5oIeiWiMhAnfEcecHwtflNqxi4u6yH79EWblNS8vU662WP+fq2z//fjEAP2QwiK9znyNXl2TAD5yBTdrc1em642eUiPvvc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR02MB8349.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(33656002)(55016002)(5660300002)(9686003)(2906002)(508600001)(52536014)(166002)(91956017)(53546011)(316002)(6916009)(122000001)(6506007)(66446008)(38100700002)(64756008)(66476007)(76116006)(66556008)(7696005)(66946007)(966005)(83380400001)(186003)(8676002)(38070700005)(8936002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?4aYPwpobSwxP71fmy76a+I6UBQB9BbbIIS58mXzFV+wKxhPcEWWKdRSx?= =?Windows-1252?Q?pPNYIp6Mk0PASQcJZ6QX3miN4s0vTacjqqI6cZ6yvnj5JH3NCVR0eOAc?= =?Windows-1252?Q?YVpcZ1Yxusknk4UYmg7KZib5zoJ7x971nlV+pMCikuruhNXLEVh01t5M?= =?Windows-1252?Q?l+Vav8uJHnO7Bh9ZkDiZ0Ehba7dL6NH1tNmoMOBFIdh1/zOlQn9AT/tl?= =?Windows-1252?Q?3E5X0uKyYviwCLma93LJ/PbDQT1NcNMdaKUrxXgfsb5B2GtcuCaqopfa?= =?Windows-1252?Q?21MzZIKWjkGhCoSsvSewJgzQ2lukWpgQraF4ierkwMI+eb6OlnG9hIK/?= =?Windows-1252?Q?7Arow1PJ3H0UQ7FaviUsxepT59asR1EF8jJPS+Ob3u8ppbGrOvyKthsn?= =?Windows-1252?Q?MeBoKZJXIjfHkSa5wkve4upIvA1MGhkciw1mzi4LD0Y65IlomqrV3Kfa?= =?Windows-1252?Q?IA/6XilBDYYfJzyz5t5nkZl1D/dOQuqud0JH8XhCaFAbZC9rEQLmRnc+?= =?Windows-1252?Q?SQ+uNKZ9nM2C59ySVmQiEq4LquaTTdQBjJr242jauo/t6hyIPRVX8xLB?= =?Windows-1252?Q?ptIAqOL2U/1age6B8rUGG8MFnzc6C3zIG3IgydURl3vtUo2snhgSqRk/?= =?Windows-1252?Q?kIOxCv3qxS3Aa7AbzPQpQ1vZCP0d+xqxOnm6kwCzT1VOLPQ4MWWr+GjP?= =?Windows-1252?Q?g+uoHvYouL3cIDDqfNtT8vpOo5lc65Api3cOsHgbXDB86/pLZNuos26L?= =?Windows-1252?Q?yacxKueP6eh2j3lzIvftTbozoHSr/fAvQLsKa6pO8KwTs8l/eU+IGtHi?= =?Windows-1252?Q?ESr/KDUOllRyOS0sDpOf9wau/dv49taV7vgi2jpjoiYlImMYtFQF9D7T?= =?Windows-1252?Q?iq1RoeyHTEU/PRxY9imAzmtU3m63UFQjj7xIvOClX0y9b50++CXD2N9h?= =?Windows-1252?Q?x7xlEsJeNQyzKej0sU7FgR2kte30ifPhSFn2cCSN/xHnQbXpR36QxS0w?= =?Windows-1252?Q?30QKM+JFPZCKQ74nBXdtF5A+fgcTG0wXnnee+caGQPcn2bs1CShEyLor?= =?Windows-1252?Q?xx2t52+vk1LubLgn0GRvDPQEzGsX2LGUNMAY2uavea23nLLZ3RwmUsau?= =?Windows-1252?Q?/Lk9LoXFKL68GRZ3+9Ib2j7AjMlngG8kT0rRBhHzQ9M58C5L0UVMullF?= =?Windows-1252?Q?9WDe0qfaaa616nvrgZ2JMUrvIaD0KuyeSeVSTqwLUVJI/v5xBa7HiOX9?= =?Windows-1252?Q?mcSWvqpiVDgti/boCMYSC1okvoDyzYs6lWoUTba2zTb3giNAuAWPimQc?= =?Windows-1252?Q?kFBGZaimV/S5l0FHOPCPo2uhAalYQpEUP0lUz5z1Jz2zK89ZPAHcHWgk?= =?Windows-1252?Q?k8f/gxozZ7Y+TjnuuuQ4EcAuPwtCp0id9SwWOfYptnoxrWoVT6glRA0s?= =?Windows-1252?Q?iK03fKKSGuOYBo9Wyrk/TOQ70HJcNTaG61IAlRriHGERltkbX56Iiary?= =?Windows-1252?Q?wnBdIYvutg3wb3g/3htF42GSa0bIQg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA1PR02MB83491FC95E4DD2F9450645C5F2F29SA1PR02MB8349namp_" MIME-Version: 1.0 X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR02MB8349.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c9f1859-1ef6-4416-45d9-08d957fe88df X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2021 10:48:17.7905 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mpgSGTAIDvjwB7RT8GFWi1AelQKjRqTNx3B4/uahom8wVvez8zyOqIcAkhb0V9IdjSvXhCSy43iOzWC0FPbPw95qjd2CFerhfj9rh0BKlxY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4016 Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 10:48:36 -0000 --_000_SA1PR02MB83491FC95E4DD2F9450645C5F2F29SA1PR02MB8349namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi list, I agree with Laurence on this. I work on platform-related security standard= s at GlobalPlatform where we are using COSE quite extensively. A major use-= case is highly constrained embedded targets where the benefits from elimina= ting string handling are considerable =96 many such platforms do not have a= heap, and minimal code size is an important design goal. I prefer to see the option of `tstr` labels removed if possible. We do have= a 64bit integer space for algorithms which should suffice. If this is not = possible (e.g. for backward compatibility with proprietary implementations)= , at least a note to registrants that integer values are greatly preferred = in some implementations for reasons of code size would be helpful. Implemen= tations could then decide whether to not implement tstr support. Best regards Jeremy On Jul 28, 2021 at 20:50 UTC, Laurence Lundblade lgl@island-resort.com wrote: > Yes, I much prefer int labels for a small C implementation. Adding suppor= t for tstr labels would noticeably increase code size. > I hope no one registers a tstr label. It seems unlikely because algorith= ms are relatively hard to invent and vet. > LL > > On Jul 28, 2021, at 5:47 AM, Carsten Bormann wrote: > > > > Hi Daisuke, > > > >> On 2021-07-28, at 13:45, AJITOMI Daisuke > wrote: > >> > >> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is n= ot necessary because I think the major advantage of COSE is its compactness= ,but I would like to know what you are assuming as the value of tstr. > > > > The registrant gets the choice between a text string and an integer. > > > > https://www.iana.org/assignments/cose/cose.xhtml lists the registration procedures for certain = ranges, e.g.: > > > > https://www.iana.org/assignments/cose/cose.xhtml#algorithms > > > > Range Registration Procedures > > Strings of length 1 Standards Action With Expert Review > > Integer values between -256 and 255 Standards Action With Expert Revi= ew > > Strings of length 2 Specification Required > > Integer values from 256 to 65535 Specification Required > > Integer values from -65536 to -257 Specification Required > > Strings of length greater than 2 Expert Review > > Integer values greater than 65535 Expert Review > > > > So labels the representations of which would be 1+0 and 1+1 bytes long = require standards action, 1+2, specification required, and 1+>2, expert rev= iew. > > > > It doesn=92t look like anyone has felt a need to register a text string= label for an algorithm ID yet; there are still quite a few 1+1 (and even a= few 1+0!) values available for registration. > > > > I would expect that, until we run out of codepoints, the registration o= f text labels will remain an occurrence for special circumstances (which me= ans we might not be prepared for text labels when we finally actually need = them). P. S. Sorry for breaking the thread chain =96 have only just subscribed to = the list (planned to ask almost exactly this question, and found the thread= ) and thus could not =91reply all=92. -- Jeremy O=92Donoghue (he/him) Director, Secure Systems Engineering jodonogh@qti.qualcomm.com (Europe/London = timezone) --_000_SA1PR02MB83491FC95E4DD2F9450645C5F2F29SA1PR02MB8349namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi list,=

 

I agree with Lauren= ce on this. I work on platform-related security standards at GlobalPlatform= where we are using COSE quite extensively. A major use-case is highly cons= trained embedded targets where the benefits from eliminating string handling are considerable =96 many such platforms = do not have a heap, and minimal code size is an important design goal.=

 

I prefer to see the= option of `tstr` labels removed if possible. We do have a 64bit integer sp= ace for algorithms which should suffice. If this is not possible (e.g. for = backward compatibility with proprietary implementations), at least a note to registrants that integer values are g= reatly preferred in some implementations for reasons of code size would be = helpful. Implementations could then decide whether to not implement tstr su= pport.

 

Best regards

Jeremy

 

On Jul 28, 2021 at = 20:50 UTC, Laurence Lundblade lgl@island-resort.com wrote:

> Y=
es, I much prefer int labels for a small C implementation. Adding support f=
or tstr labels would noticeably increase code size.
> I=
 hope no one registers a tstr label.  It seems unlikely because algori=
thms are relatively hard to invent and vet.
&=
nbsp;
> L=
L
&=
nbsp;
&=
nbsp;
> &=
gt; On Jul 28, 2021, at 5:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
> &=
gt; 
> &=
gt; Hi Daisuke,
> &=
gt; 
> &=
gt;> On 2021-07-28, at 13:45, AJITOMI Daisuke <ajitomi@gmail.com <mailto:ajitomi@gmail.com>> wrote:
> &=
gt;> 
> &=
gt;> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' i=
s not necessary because I think the major advantage of COSE is its compactn=
ess,but I would like to know what you are assuming as the value of tstr.
> &=
gt; 
> &=
gt; The registrant gets the choice between a text string and an integer.
> &=
gt; 
> &=
gt; https://www.iana.org/assignments/cose/cose.xhtml=
 <https://www.iana.org/assignments/cose/cose.xhtml> lists the reg=
istration procedures for certain ranges, e.g.:
> &=
gt; 
> &=
gt; https://www.iana.org/assignments/cose/cose.x=
html#algorithms <https://www.iana.org/assignments/cose/cose.x=
html#algorithms>
> &=
gt; 
> &=
gt; Range <sort_none.gif> Registration Procedures <sort_up.gif>=
> &=
gt; Strings of length 1  Standards Action With Expert Review
> &=
gt; Integer values between -256 and 255   Standards Action With E=
xpert Review
> &=
gt; Strings of length 2  Specification Required
> &=
gt; Integer values from 256 to 65535       Sp=
ecification Required
> &=
gt; Integer values from -65536 to -257    Specification Requ=
ired
> &=
gt; Strings of length greater than 2       Ex=
pert Review
> &=
gt; Integer values greater than 65535      Expert =
Review
> &=
gt; 
> &=
gt; So labels the representations of which would be 1+0 and 1+1 bytes long =
require standards action, 1+2, specification required, and 1+>2, expert =
review.
> &=
gt; 
> &=
gt; It doesn=92t look like anyone has felt a need to register a text string=
 label for an algorithm ID yet; there are still quite a few 1+1 (and even a=
 few 1+0!) values available for registration.
> &=
gt; 
> &=
gt; I would expect that, until we run out of codepoints, the registration o=
f text labels will remain an occurrence for special circumstances (which me=
ans we might not be prepared for text labels when we finally actually need =
them).

 

P. S. Sorry for bre= aking the thread chain =96 have only just subscribed to the list (planned t= o ask almost exactly this question, and found the thread) and thus could no= t =91reply all=92.

 

-- 

Jeremy O=92Donoghue (he/him)

Director, Secure Systems Engineering

jodonogh@qti.qualcomm.com (Europe= /London timezone)

--_000_SA1PR02MB83491FC95E4DD2F9450645C5F2F29SA1PR02MB8349namp_-- From nobody Thu Aug 5 20:29:43 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2331A3A1A46 for ; Thu, 5 Aug 2021 20:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RPrOrG7It8vp for ; Thu, 5 Aug 2021 20:29:36 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1D13A1A44 for ; Thu, 5 Aug 2021 20:29:36 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id x7so7372659ilh.10 for ; Thu, 05 Aug 2021 20:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8UGcKq/SS3f0d76fBI9ZE6zqbhveUZpmvbDWtbqjcOU=; b=ajmMQquAQ7ubLEjIU+hIB+EAG6DEIA3Ha/Obfzq6kh4Z4iXefgTC/UlG+wpn8N9Wn1 k1TTdVPqzHQltwwPbCqRS54wwr48EQ9ELJ/9SwzCCteGjPazYwoNhw0BFUuZ3LZwnhTC FPJ3JuFcenKe225mdB4Y5VaSXsMa+58VmkOANhLeIKkHdGDktjaBIuoC408/o9oWpd9x GHi1OSuyFCNzZwPD6v3vHObKvB8cCxDXIyh9tPYjVustZc/pQIxPe3WMSBddPG8/9ar7 vihmc31E85syjhCLWsjIlWWZanfKHtx2MXKwmsihJ6YySFbcIR799cKUaCuP4UXxTKMa qfcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8UGcKq/SS3f0d76fBI9ZE6zqbhveUZpmvbDWtbqjcOU=; b=rkDqvE8HV/rCHLub4EcCk+dwjQcfSFdYEsiQ1p9mjPMdYj1k5UHqTNvnQ2HzvSrx8V EBVO7vaNaMYiGbQjtLSbAPoOZrE0BH+mM1GOLxCMqBaJv+eDDrHefhJwGVXhRm64eMpU PYIzgkGF5ADTz7sb9dBFQzasAu0SdGFO/39FdZeAQGJK74UpDUaawn2AJaDHbBbxHml+ MT5/YR09qCdbgVd/8+BUPq99yrai3K686pSmjGYTpycVCyQ7bvdbj1SfRqFj6J1XLdYx cZ11FGyArNqiGODZS/7sWvsjc3IiZQU5BbQJ8Q83j+nIzbUxnlGBOvOHvSgYIvt5PJ8g l/mA== X-Gm-Message-State: AOAM530y2op/R4vlFxq5rC069oPqMwES9Bt00GFlSs1ouxsl6X6+DWCF Tv+0gxm8HV/TmEnPxwHF2KQCnMac2iZE4IMz6g== X-Google-Smtp-Source: ABdhPJyubqdoosaxwPB7ma51C0+TUhTcadn0s37RdOCNq1QSgO5sy33zEbQudGD8UXBQ4ECF1kY0iKOcb3xgG5C3FqY= X-Received: by 2002:a92:ca48:: with SMTP id q8mr270830ilo.113.1628220573377; Thu, 05 Aug 2021 20:29:33 -0700 (PDT) MIME-Version: 1.0 References: <815DB7E9-555A-4A7D-B3DE-CC807DE3A222@tzi.org> <41E79CBD-04D1-4C0F-BEE3-4F63780D514E@island-resort.com> In-Reply-To: <41E79CBD-04D1-4C0F-BEE3-4F63780D514E@island-resort.com> From: AJITOMI Daisuke Date: Fri, 6 Aug 2021 12:29:22 +0900 Message-ID: To: Laurence Lundblade , cose@ietf.org, jodonogh@qti.qualcomm.com Cc: Carsten Bormann Content-Type: multipart/alternative; boundary="000000000000e46a2005c8dba461" Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 03:29:41 -0000 --000000000000e46a2005c8dba461 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi folks, > I prefer to see the option of `tstr` labels removed if possible. I'm glad to see that there are several people who agree with me. To remove the option of tstr labels from the spec, would a revised RFC be needed? Or would an errata enough for that? Anyway, I would like to hear from the key members in COSE whether this change is acceptable or not. If it is acceptable, I would like to support moving this effort forward. Best regards, Daisuke 2021=E5=B9=B48=E6=9C=885=E6=97=A5(=E6=9C=A8) 19:48 Jeremy O'Donoghue : > Hi list, > > > > I agree with Laurence on this. I work on platform-related security > standards at GlobalPlatform where we are using COSE quite extensively. A > major use-case is highly constrained embedded targets where the benefits > from eliminating string handling are considerable =E2=80=93 many such pla= tforms do > not have a heap, and minimal code size is an important design goal. > > > > I prefer to see the option of `tstr` labels removed if possible. We do > have a 64bit integer space for algorithms which should suffice. If this i= s > not possible (e.g. for backward compatibility with proprietary > implementations), at least a note to registrants that integer values are > greatly preferred in some implementations for reasons of code size would = be > helpful. Implementations could then decide whether to not implement tstr > support. > > > > Best regards > > Jeremy > 2021=E5=B9=B47=E6=9C=8829=E6=97=A5(=E6=9C=A8) 5:50 Laurence Lundblade : > Yes, I much prefer int labels for a small C implementation. Adding suppor= t > for tstr labels would noticeably increase code size. I hope no one > registers a tstr label. It seems unlikely because algorithms are > relatively hard to invent and vet. > > LL > > > On Jul 28, 2021, at 5:47 AM, Carsten Bormann wrote: > > Hi Daisuke, > > On 2021-07-28, at 13:45, AJITOMI Daisuke wrote: > > In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is not > necessary because I think the major advantage of COSE is its > compactness,but I would like to know what you are assuming as the value o= f > tstr. > > > The registrant gets the choice between a text string and an integer. > > https://www.iana.org/assignments/cose/cose.xhtml lists the registration > procedures for certain ranges, e.g.: > > https://www.iana.org/assignments/cose/cose.xhtml#algorithms > > Range Registration Procedures > Strings of length 1 Standards Action With Expert Review > Integer values between -256 and 255 Standards Action With Expert Review > Strings of length 2 Specification Required > Integer values from 256 to 65535 Specification Required > Integer values from -65536 to -257 Specification Required > Strings of length greater than 2 Expert Review > Integer values greater than 65535 Expert Review > > So labels the representations of which would be 1+0 and 1+1 bytes long > require standards action, 1+2, specification required, and 1+>2, expert > review. > > It doesn=E2=80=99t look like anyone has felt a need to register a text st= ring > label for an algorithm ID yet; there are still quite a few 1+1 (and even = a > few 1+0!) values available for registration. > > I would expect that, until we run out of codepoints, the registration of > text labels will remain an occurrence for special circumstances (which > means we might not be prepared for text labels when we finally actually > need them). > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > --000000000000e46a2005c8dba461 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

> I prefer t= o see the option of `tstr` labels removed if possible.

I'm glad = to see that there are several people who agree with me.

To remove th= e option of tstr labels from the spec, would a revised RFC be needed? Or wo= uld an errata enough for that?
Anyway, I would like to hear from the key= members in COSE whether this change is acceptable or not.

If it is = acceptable, I would like to support moving this effort forward.

Best= regards,
Daisuke

2021=E5=B9=B48=E6=9C=885=E6=97=A5(= =E6=9C=A8) 19:48 Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>:
=
=

Hi list,

= =C2=A0

I agree with Laurence on this. I work on platform-related security stand= ards at GlobalPlatform where we are using COSE quite extensively. A major u= se-case is highly constrained embedded targets where the benefits from elim= inating string handling are considerable =E2=80=93 many such platforms do n= ot have a heap, and minimal code size is an important design goal.

=C2=A0

I prefer to see the option of `tstr` labels removed if possible. We do= have a 64bit integer space for algorithms which should suffice. If this is= not possible (e.g. for backward compatibility with proprietary implementat= ions), at least a note to registrants that integer values are greatly prefe= rred in some implementations for reasons of code size would be helpful. Imp= lementations could then decide whether to not implement tstr support.

=C2=A0

Best regards

Jeremy


2021=E5=B9=B47= =E6=9C=8829=E6=97=A5(=E6=9C=A8) 5:50 Laurence Lundblade <lgl@island-resort.com>:<= br>
Yes, I much= prefer int labels for a small C implementation. Adding support for tstr la= bels would noticeably increase code size. I hope no one registers a tstr la= bel.=C2=A0 It seems unlikely because algorithms are relatively hard to inve= nt and vet.

LL


On Jul 28, 2021, at 5:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
Hi Daisuke,

On 2021-07-28, = at 13:45, AJITOMI Daisuke <ajitomi@gmail.com> wrote:

In my opinion, the tstr= type for 'kty', 'alg', 'crv' or 'key_ops' = is not necessary because I think the=C2=A0major advantage of COSE is its co= mpactness,but I would like to know what you are assuming as=C2=A0the value = of tstr.

The registrant gets the choice between a = text string and an integer.

https://www.iana.o= rg/assignments/cose/cose.xhtml lists the registration procedures for ce= rtain ranges, e.g.:


R= ange=C2=A0<= sort_none.gif> Regist= ration Procedures=C2=A0<sort_up.gif>
Strings of length 1 Standards Action With Expert Review
Integer = values between -256 and 255 Sta= ndards Action With Expert Review
Strings of length 2 Specification Required
Integer values from 256 = to 65535 Specification Required=
Integer values from -65536 to -257= Specification Required
Strings of length greater than 2 Expert Review
Integer values greater= than 65535 Expert Review
=

So labels the representations of which would be 1+0 and= 1+1 bytes long require standards action, 1+2, specification required, and = 1+>2, expert review.

It doesn=E2=80=99t look li= ke anyone has felt a need to register a text string label for an algorithm = ID yet; there are still quite a few 1+1 (and even a few 1+0!) values availa= ble for registration.

I would expect that, until w= e run out of codepoints, the registration of text labels will remain an occ= urrence for special circumstances (which means we might not be prepared for= text labels when we finally actually need them).

= Gr=C3=BC=C3=9Fe, Carsten

_______________________________= ________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/c= ose

--000000000000e46a2005c8dba461-- From nobody Thu Aug 5 21:57:01 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8060A3A1D20 for ; Thu, 5 Aug 2021 21:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 liWIBGiRo_sN for ; Thu, 5 Aug 2021 21:56:53 -0700 (PDT) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (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 74AFF3A1D1A for ; Thu, 5 Aug 2021 21:56:53 -0700 (PDT) Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id BrudmGb3480fFBruem2a4s; Thu, 05 Aug 2021 21:56:52 -0700 X-CMAE-Analysis: v=2.4 cv=VNQYI/DX c=1 sm=1 tr=0 ts=610cc114 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=pGLkceISAAAA:8 a=EUspDBNiAAAA:8 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=I0CVDw5ZAAAA:8 a=48vgC7mUAAAA:8 a=ACn1CSgZ6R2NMaNGxb8A:9 a=QEXdDO2ut3YA:10 a=ESmtXmZkP9PrlDvsfFwA:9 a=Dl2epPFCTMPGuf6m:21 a=_W_S_7VecoQA:10 a=rMCfJy6NHDicN4J276Yl:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=nnPW6aIcBuj1ljLj_o6Q:22 a=YdXdGVBxRxTCRzIkH2Jn:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <313B433A-ACCA-4D2E-AA20-53A6CAA4E92A@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5975ED46-7A31-4B20-AE8E-A0B580F50885" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 5 Aug 2021 21:56:51 -0700 In-Reply-To: Cc: cose@ietf.org, jodonogh@qti.qualcomm.com, Carsten Bormann To: AJITOMI Daisuke References: <815DB7E9-555A-4A7D-B3DE-CC807DE3A222@tzi.org> <41E79CBD-04D1-4C0F-BEE3-4F63780D514E@island-resort.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-CMAE-Envelope: MS4xfEReFWuB6RS2H+uPwyO/K6lPritTWaseMBI0/+qD1WQsNrA8BQ5OzwSV1ROzYdtSa9EQr1FfJ/zPg3FSfiki6W5/HVOJP27krf9JMerhNUn5sZ5AckFG VYL/7TyFcADRc6ouHH0KDVt0C2m7rm2szPRCsTc1caxGGKoL45nMCkPWLNRrp2Dv2+AXe52G4PPZTp/AzE6NF5meCrbSFi8UjBRfBT+QLDol1Btht2SbZ1XA mlgu9YRMZ4ncFoYUiFnT+vKEQx0H1xTE3vV/yFkLVb4= Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 04:56:59 -0000 --Apple-Mail=_5975ED46-7A31-4B20-AE8E-A0B580F50885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think tstr can be removed from the standard. That would = break backwards compatibility. Maybe a strong recommendation could be = added with the comment that many implementations don=E2=80=99t support = tstr. There is a revision of 8152 in process right now called 8152bis. That = seems like the place to do it. LL > On Aug 5, 2021, at 8:29 PM, AJITOMI Daisuke wrote: >=20 > Hi folks, >=20 > > I prefer to see the option of `tstr` labels removed if possible. >=20 > I'm glad to see that there are several people who agree with me. >=20 > To remove the option of tstr labels from the spec, would a revised RFC = be needed? Or would an errata enough for that? > Anyway, I would like to hear from the key members in COSE whether this = change is acceptable or not. >=20 > If it is acceptable, I would like to support moving this effort = forward. >=20 > Best regards, > Daisuke >=20 > 2021=E5=B9=B48=E6=9C=885=E6=97=A5(=E6=9C=A8) 19:48 Jeremy O'Donoghue = >: > Hi list, >=20 > =20 >=20 > I agree with Laurence on this. I work on platform-related security = standards at GlobalPlatform where we are using COSE quite extensively. A = major use-case is highly constrained embedded targets where the benefits = from eliminating string handling are considerable =E2=80=93 many such = platforms do not have a heap, and minimal code size is an important = design goal. >=20 > =20 >=20 > I prefer to see the option of `tstr` labels removed if possible. We do = have a 64bit integer space for algorithms which should suffice. If this = is not possible (e.g. for backward compatibility with proprietary = implementations), at least a note to registrants that integer values are = greatly preferred in some implementations for reasons of code size would = be helpful. Implementations could then decide whether to not implement = tstr support. >=20 > =20 >=20 > Best regards >=20 > Jeremy >=20 >=20 > 2021=E5=B9=B47=E6=9C=8829=E6=97=A5(=E6=9C=A8) 5:50 Laurence Lundblade = >: > Yes, I much prefer int labels for a small C implementation. Adding = support for tstr labels would noticeably increase code size. I hope no = one registers a tstr label. It seems unlikely because algorithms are = relatively hard to invent and vet. >=20 > LL >=20 >=20 >> On Jul 28, 2021, at 5:47 AM, Carsten Bormann > wrote: >>=20 >> Hi Daisuke, >>=20 >>> On 2021-07-28, at 13:45, AJITOMI Daisuke > wrote: >>>=20 >>> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is = not necessary because I think the major advantage of COSE is its = compactness,but I would like to know what you are assuming as the value = of tstr. >>=20 >> The registrant gets the choice between a text string and an integer. >>=20 >> https://www.iana.org/assignments/cose/cose.xhtml = lists the = registration procedures for certain ranges, e.g.: >>=20 >> https://www.iana.org/assignments/cose/cose.xhtml#algorithms = >>=20 >> Range Registration Procedures >> Strings of length 1 Standards Action With Expert Review >> Integer values between -256 and 255 Standards Action With Expert = Review >> Strings of length 2 Specification Required >> Integer values from 256 to 65535 Specification Required >> Integer values from -65536 to -257 Specification Required >> Strings of length greater than 2 Expert Review >> Integer values greater than 65535 Expert Review >>=20 >> So labels the representations of which would be 1+0 and 1+1 bytes = long require standards action, 1+2, specification required, and 1+>2, = expert review. >>=20 >> It doesn=E2=80=99t look like anyone has felt a need to register a = text string label for an algorithm ID yet; there are still quite a few = 1+1 (and even a few 1+0!) values available for registration. >>=20 >> I would expect that, until we run out of codepoints, the registration = of text labels will remain an occurrence for special circumstances = (which means we might not be prepared for text labels when we finally = actually need them). >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose = >=20 --Apple-Mail=_5975ED46-7A31-4B20-AE8E-A0B580F50885 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t think tstr can be removed from the standard. That would = break backwards compatibility. Maybe a strong recommendation could be = added with the comment that many implementations don=E2=80=99t support = tstr.

There is a = revision of 8152 in process right now called 8152bis. That seems like = the place to do it.

LL


On Aug 5, 2021, at 8:29 PM, AJITOMI Daisuke <ajitomi@gmail.com> = wrote:

Hi folks,

> I prefer to see the option of `tstr` = labels removed if possible.

I'm glad to see = that there are several people who agree with me.

To remove the option of tstr labels from the spec, would a = revised RFC be needed? Or would an errata enough for that?
Anyway, I would like to hear from the key members in COSE = whether this change is acceptable or not.

If = it is acceptable, I would like to support moving this effort forward.

Best regards,
Daisuke

2021=E5=B9=B48=E6=9C=885=E6=97=A5(=E6=9C=A8) 19:48 = Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>:

Hi list,

 

I agree = with Laurence on this. I work on platform-related security standards at = GlobalPlatform where we are using COSE quite extensively. A major = use-case is highly constrained embedded targets where the benefits from = eliminating string handling are considerable =E2=80=93 many such = platforms do not have a heap, and minimal code size is an important = design goal.

 

I prefer = to see the option of `tstr` labels removed if possible. We do have a = 64bit integer space for algorithms which should suffice. If this is not = possible (e.g. for backward compatibility with proprietary = implementations), at least a note to registrants that integer values are = greatly preferred in some implementations for reasons of code size would = be helpful. Implementations could then decide whether to not implement = tstr support.

 

Best = regards

Jeremy


2021=E5=B9=B47=E6=9C=8829=E6=97=A5(=E6=9C=A8) 5:50 = Laurence Lundblade <lgl@island-resort.com>:
Yes, I much prefer = int labels for a small C implementation. Adding support for tstr labels = would noticeably increase code size. I hope no one registers a tstr = label.  It seems unlikely because algorithms are relatively hard to = invent and vet.

LL


On Jul = 28, 2021, at 5:47 AM, Carsten Bormann <cabo@tzi.org> wrote:

Hi Daisuke,

On 2021-07-28, at 13:45, = AJITOMI Daisuke <ajitomi@gmail.com> wrote:

In my opinion, the tstr type for 'kty', 'alg', 'crv' or = 'key_ops' is not necessary because I think the major advantage of = COSE is its compactness,but I would like to know what you are assuming = as the value of tstr.

The registrant gets the choice between a text string and an = integer.

https://www.iana.org/assignments/cose/cose.xhtml lists = the registration procedures for certain ranges, e.g.:


Range <sort_none.gif> Registration = Procedures <sort_up.gif>
Strings of length = 1 Standards = Action With Expert Review
Integer values between -256 and = 255 Standards = Action With Expert Review
Strings of length 2 Specification = Required
Integer values from 256 to 65535 Specification = Required
Integer values from -65536 to -257 Specification = Required
Strings of length greater than 2 Expert Review
Integer values greater than 65535 Expert = Review

So = labels the representations of which would be 1+0 and 1+1 bytes long = require standards action, 1+2, specification required, and 1+>2, = expert review.

It doesn=E2=80=99t look like anyone has felt a need to = register a text string label for an algorithm ID yet; there are still = quite a few 1+1 (and even a few 1+0!) values available for = registration.

I = would expect that, until we run out of codepoints, the registration of = text labels will remain an occurrence for special circumstances (which = means we might not be prepared for text labels when we finally actually = need them).

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


= --Apple-Mail=_5975ED46-7A31-4B20-AE8E-A0B580F50885-- From nobody Fri Aug 6 00:04:38 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADB83A1F05 for ; Fri, 6 Aug 2021 00:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 hgU0jJF8qMp4 for ; Fri, 6 Aug 2021 00:04:32 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FF13A1F03 for ; Fri, 6 Aug 2021 00:04:30 -0700 (PDT) Received: from smtpclient.apple (ip5886a2c1.dynamic.kabel-deutschland.de [88.134.162.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GgxL42Nrfz31LH; Fri, 6 Aug 2021 09:04:28 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-4EB97873-4CC4-421F-A1FA-385F12B4E3EE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: <313B433A-ACCA-4D2E-AA20-53A6CAA4E92A@island-resort.com> Date: Fri, 6 Aug 2021 09:04:27 +0200 Cc: AJITOMI Daisuke , cose@ietf.org, jodonogh@qti.qualcomm.com Message-Id: <6A3CD698-DA46-4FBA-AC01-C4A7F392219D@tzi.org> References: <313B433A-ACCA-4D2E-AA20-53A6CAA4E92A@island-resort.com> To: Laurence Lundblade X-Mailer: iPhone Mail (18G82) Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 07:04:37 -0000 --Apple-Mail-4EB97873-4CC4-421F-A1FA-385F12B4E3EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from mobile, sorry for terse > On 6. Aug 2021, at 06:57, Laurence Lundblade wrote= : >=20 > There is a revision of 8152 in process right now called 8152bis. That seem= s like the place to do it. Well, rfc 9052/9053 are almost published. But I think we already diagnosed t= hat it would be good to have a document helping with registration, and that c= ould make the point.=20= --Apple-Mail-4EB97873-4CC4-421F-A1FA-385F12B4E3EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Sent from mobile, sorry for terse

On 6. Aug 2021, at 06:57, Laurence Lundblade <lgl@island-resort.com> wrote:

There is a revision of 8152 in process right now called 8152bis. That seems like the place to do it.

Well, rfc 9052/9053 are almost published. But I think we already diagnosed that it would be good to have a document helping with registration, and that could make the point. 
--Apple-Mail-4EB97873-4CC4-421F-A1FA-385F12B4E3EE-- From nobody Sat Aug 7 16:22:32 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA573A0BD3 for ; Sat, 7 Aug 2021 16:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uTqK9qGGEGAS for ; Sat, 7 Aug 2021 16:22:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AB93A0BD2 for ; Sat, 7 Aug 2021 16:22:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 22410389CF; Sat, 7 Aug 2021 19:26:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Rqct8_ArtraY; Sat, 7 Aug 2021 19:26:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 91282389BC; Sat, 7 Aug 2021 19:26:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8DE6925; Sat, 7 Aug 2021 19:22:18 -0400 (EDT) From: Michael Richardson To: Laurence Lundblade , AJITOMI Daisuke , Carsten Bormann , jodonogh@qti.qualcomm.com, cose@ietf.org In-Reply-To: <313B433A-ACCA-4D2E-AA20-53A6CAA4E92A@island-resort.com> References: <815DB7E9-555A-4A7D-B3DE-CC807DE3A222@tzi.org> <41E79CBD-04D1-4C0F-BEE3-4F63780D514E@island-resort.com> <313B433A-ACCA-4D2E-AA20-53A6CAA4E92A@island-resort.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2021 23:22:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Laurence Lundblade wrote: > I don=E2=80=99t think tstr can be removed from the standard. That wou= ld break > backwards compatibility. Maybe a strong recommendation could be added > with the comment that many implementations don=E2=80=99t support tstr. Any system built upon COSE that does not support tstr as a key is already broken if many implementations don't support it. We can deprecate tstr as key. We can say that no signer MUST NEVER emit this again. We can say that a verifier MAY accept tstr as a key. > There is a revision of 8152 in process right now called 8152bis. That > seems like the place to do it. It is pretty late to do this. 8152bis is in AUTH48, we need the proxy-auth= or and WG chairs to agree to this immediately. I agree that having two ways things is not a good thing. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEPFaoACgkQgItw+93Q 3WWr4gf/dNFLudTAM7ndEAR49dc2vrJObGrNqM6vT4p3HRqg6bEThtZs9ROuVvb0 ejEsUArsLX/UmcRVaoTQkbOWqb63nQW34oJqiA2dLF1N3Dp/XcudZutakKMXYfJq suUVf3ojBaeOZYMtCUxtHeucpE4htBWOzXewXrNQ6WUa5bossunftAoliTOtIatd s6YY2MFkbFBzvG86XFTF7nk29AqY4mfQJOyd6n+6m2QWcMKWO5p70EPa+ER8s+n6 M3reNVSwM2kd3koIsFKZLXpRj22h+IedbLFbUKpdLePjlmMbD+aaKJUv3nVeWorR 9F1PRi3UfVdy09iZLQBuGwvrkrp82w== =jsvV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 8 01:13:31 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C423A20C1 for ; Sun, 8 Aug 2021 01:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0vLalNLd4ZTm for ; Sun, 8 Aug 2021 01:13:25 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14C13A20BF for ; Sun, 8 Aug 2021 01:13:24 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id x10so11006727iop.13 for ; Sun, 08 Aug 2021 01:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rc8K4uu0QnksYYb06r8mYgpsxoDx+A1//tyD6O7ucI0=; b=cmAcCMRoYworly7l2PWl2mm6DUWAlxz5zfVd+Feo9Av9afFJ+wo1thbtiFCf0YDaAB vKt/dlNrszV00NdEPTh31nNOpBmcEUHFtC6BF73rJXwVlZEdzuRGY2lysqYJEwCjc4So Vrvq9xbE7O2DCsptbAWInIWtzJQEK/uBy1Lex9/wjMOrZtlx9JRS76ORdhWSDmeFpAgf Hm/lFRHjUhiFFKZUCQyPvZqZQccNN+e3uhI7/wKQrIs3J+Pe+rGxOXqa5tkZobrBJ220 ZSDijKvCu/6sSaJXpS3VfHDWmbApKA+zbY3elwGPHUIu0iuLMecCy78T+r55DkKqU14e Nu1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rc8K4uu0QnksYYb06r8mYgpsxoDx+A1//tyD6O7ucI0=; b=e8CBZAOD6ESzJfKW1kfH9j9fDCcE0dCrToA7huSSqW9VXHGQZAgDPXzT8v+ohBV2fq ZfOdjhQJY4oQkq/Uguhi/fjezMUOG6EnYwTS5PEuUOCkLNIwgYnc+EONZafVCJX7N8KM DDTRGJga95SnMpCaMd8M/5B+0hYEtDqq8uzvCBwqUfRh3jV0ekE8KDJO/qj1AsEdJeki Bvqh6/X8mydnFLMYkmS21w2m3WWa/vZc6g4Ab7R2PPuymEofWaqWxkBcyRecbr0n0Isk 0kU8yQn7AeKXC8HZtwsukEYyzeVFZlgTyxgpTx5YM95YPy+czNu4pQb1INcqoyM5ykE6 k3oQ== X-Gm-Message-State: AOAM530rCU39v5kpSZP0fpGICaS2OIDcfWc6GAR8S3ZU+f2B0mhY1lGY ws7DZVZkJily8KXOe5qemb5IK6UsdXTfL9VfpQ== X-Google-Smtp-Source: ABdhPJy0ivlHIUA/5AWaasWIvT+yj+mwLYaTI4YPWRJhuzHZBm7HAWv0bDw7UA6029R0b+9a+IDI3Z9ElAl3PXpYXfI= X-Received: by 2002:a92:d3d1:: with SMTP id c17mr571919ilh.86.1628410402950; Sun, 08 Aug 2021 01:13:22 -0700 (PDT) MIME-Version: 1.0 References: <815DB7E9-555A-4A7D-B3DE-CC807DE3A222@tzi.org> <41E79CBD-04D1-4C0F-BEE3-4F63780D514E@island-resort.com> <313B433A-ACCA-4D2E-AA20-53A6CAA4E92A@island-resort.com> <9734.1628378538@localhost> In-Reply-To: <9734.1628378538@localhost> From: AJITOMI Daisuke Date: Sun, 8 Aug 2021 17:13:10 +0900 Message-ID: To: Michael Richardson , cose@ietf.org Cc: Laurence Lundblade , Carsten Bormann , jodonogh@qti.qualcomm.com Content-Type: multipart/alternative; boundary="0000000000009dd50c05c907d75a" Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 08:13:30 -0000 --0000000000009dd50c05c907d75a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > We can deprecate tstr as key. > We can say that no signer MUST NEVER emit this again. > We can say that a verifier MAY accept tstr as a key. This sounds reasonable to me. Since any tstr labels are not registered in the IANA registry for now and there are no implementations that support the tstr labels as far as I know, I think there is room to make the tstr labels deprecated. Thanks, Daisuke 2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6=97=A5) 8:22 Michael Richardson : > > Laurence Lundblade wrote: > > I don=E2=80=99t think tstr can be removed from the standard. That w= ould break > > backwards compatibility. Maybe a strong recommendation could be add= ed > > with the comment that many implementations don=E2=80=99t support ts= tr. > > Any system built upon COSE that does not support tstr as a key is already > broken if many implementations don't support it. > > We can deprecate tstr as key. > We can say that no signer MUST NEVER emit this again. > We can say that a verifier MAY accept tstr as a key. > > > There is a revision of 8152 in process right now called 8152bis. Th= at > > seems like the place to do it. > > It is pretty late to do this. 8152bis is in AUTH48, we need the > proxy-author > and WG chairs to agree to this immediately. > > I agree that having two ways things is not a good thing. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > --0000000000009dd50c05c907d75a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> We can deprecate tstr as key.
> We= can say that no signer MUST NEVER emit this again.
> We can say that= a verifier MAY accept tstr as a key.

This sounds reasonab= le to me.

Since any tstr labels are not registered in the IANA regis= try for now and there are no implementations that support the tstr labels a= s far as I know,

I think there is room to make the tstr labels depre= cated.

Thanks,
Daisuke

=
2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6= =97=A5) 8:22 Michael Richardson <mcr+ietf@sandelman.ca>:
=
Laurence Lundblade <lgl@island-resort.com> wrote:
=C2=A0 =C2=A0 > I don=E2=80=99t think tstr can be removed from the stand= ard. That would break
=C2=A0 =C2=A0 > backwards compatibility. Maybe a strong recommendation c= ould be added
=C2=A0 =C2=A0 > with the comment that many implementations don=E2=80=99t= support tstr.

Any system built upon COSE that does not support tstr as a key is already broken if many implementations don't support it.

We can deprecate tstr as key.
We can say that no signer MUST NEVER emit this again.
We can say that a verifier MAY accept tstr as a key.

=C2=A0 =C2=A0 > There is a revision of 8152 in process right now called = 8152bis. That
=C2=A0 =C2=A0 > seems like the place to do it.

It is pretty late to do this.=C2=A0 8152bis is in AUTH48, we need the proxy= -author
and WG chairs to agree to this immediately.

I agree that having two ways things is not a good thing.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O= ( IPv6 I=C3=B8T consulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--0000000000009dd50c05c907d75a-- From nobody Sun Aug 8 04:48:48 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D33A26F2 for ; Sun, 8 Aug 2021 04:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 NoWKeUeC1sBd for ; Sun, 8 Aug 2021 04:48:40 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65633A26F1 for ; Sun, 8 Aug 2021 04:48:39 -0700 (PDT) Received: from smtpclient.apple (ip-109-42-115-93.web.vodafone.de [109.42.115.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GjHXy664kz2xKT; Sun, 8 Aug 2021 13:48:34 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-8D891DED-134B-4A5D-92ED-FE4531E3E7A7 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: Date: Sun, 8 Aug 2021 13:48:34 +0200 Cc: Michael Richardson , cose@ietf.org, Laurence Lundblade , jodonogh@qti.qualcomm.com Message-Id: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> References: To: AJITOMI Daisuke X-Mailer: iPhone Mail (18G82) Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 11:48:46 -0000 --Apple-Mail-8D891DED-134B-4A5D-92ED-FE4531E3E7A7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This discussion is all a bit short sighted to me. Sure, we can advise agains= t registering text labels now. But COSE has a long life with many applicatio= ns before it, some of which may be outside what you are thinking about now. W= hat=E2=80=99s the rush on disabling these? Sent from mobile, sorry for terse > On 8. Aug 2021, at 10:15, AJITOMI Daisuke wrote: >=20 > =EF=BB=BF > > We can deprecate tstr as key. > > We can say that no signer MUST NEVER emit this again. > > We can say that a verifier MAY accept tstr as a key. >=20 > This sounds reasonable to me. >=20 > Since any tstr labels are not registered in the IANA registry for now and t= here are no implementations that support the tstr labels as far as I know, >=20 > I think there is room to make the tstr labels deprecated. >=20 > Thanks, > Daisuke >=20 > 2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6=97=A5) 8:22 Michael Richardson : >>=20 >> Laurence Lundblade wrote: >> > I don=E2=80=99t think tstr can be removed from the standard. That w= ould break >> > backwards compatibility. Maybe a strong recommendation could be add= ed >> > with the comment that many implementations don=E2=80=99t support ts= tr. >>=20 >> Any system built upon COSE that does not support tstr as a key is already= >> broken if many implementations don't support it. >>=20 >> We can deprecate tstr as key. >> We can say that no signer MUST NEVER emit this again. >> We can say that a verifier MAY accept tstr as a key. >>=20 >> > There is a revision of 8152 in process right now called 8152bis. Th= at >> > seems like the place to do it. >>=20 >> It is pretty late to do this. 8152bis is in AUTH48, we need the proxy-au= thor >> and WG chairs to agree to this immediately. >>=20 >> I agree that having two ways things is not a good thing. >>=20 >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) >> Sandelman Software Works Inc, Ottawa and Worldwide --Apple-Mail-8D891DED-134B-4A5D-92ED-FE4531E3E7A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This discussion is all a bit short sighted t= o me. Sure, we can advise against registering text labels now. But COSE has a= long life with many applications before it, some of which may be outside wh= at you are thinking about now. What=E2=80=99s the rush on disabling these?
Sent from mobil= e, sorry for terse

On 8. Aug 2021, at 10:15, AJITOMI Daisuke <ajitomi@gmail.com> wrote:=

=EF=BB= =BF
> We can deprecate tstr as key.
> W= e can say that no signer MUST NEVER emit this again.
> We can say that= a verifier MAY accept tstr as a key.

This sounds reasonable= to me.

Since any tstr labels are not registered in the IANA registry= for now and there are no implementations that support the tstr labels as fa= r as I know,

I think there is room to make the tstr labels deprecated= .

Thanks,
Daisuke

2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6=97=A5)= 8:22 Michael Richardson <mcr+= ietf@sandelman.ca>:

Laurence Lundblade <lgl@island-resort.com> wrote:
    > I don=E2=80=99t think tstr can be removed from the standa= rd. That would break
    > backwards compatibility. Maybe a strong recommendation co= uld be added
    > with the comment that many implementations don=E2=80=99t s= upport tstr.

Any system built upon COSE that does not support tstr as a key is already broken if many implementations don't support it.

We can deprecate tstr as key.
We can say that no signer MUST NEVER emit this again.
We can say that a verifier MAY accept tstr as a key.

    > There is a revision of 8152 in process right now called 8= 152bis. That
    > seems like the place to do it.

It is pretty late to do this.  8152bis is in AUTH48, we need the proxy-= author
and WG chairs to agree to this immediately.

I agree that having two ways things is not a good thing.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O (= IPv6 I=C3=B8T consulting )
           Sandelman Software Works Inc, Ottaw= a and Worldwide
= --Apple-Mail-8D891DED-134B-4A5D-92ED-FE4531E3E7A7-- From nobody Sun Aug 8 06:49:53 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194243A2BAB for ; Sun, 8 Aug 2021 06:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 35DcNRM9of9A for ; Sun, 8 Aug 2021 06:49:46 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D773A2BAA for ; Sun, 8 Aug 2021 06:49:45 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id d22so23003436ioy.11 for ; Sun, 08 Aug 2021 06:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9x/HwebwbfxMLzzgcrmihp5OGpg4eLO/YPa8riVK3JE=; b=uAKonL4z8x6ydO3kHCCgPXhvz4slQzSwdU5dmFQ+eKpO8eiE8EKEUArskoCx2Pi+1R 4JgpzDf3+hmdCrbGepL5cFTf1q7knUlH9lFk5/QnWtTzjk3NnQRUDi6gni/sxEoanDij 6Vr6weL4LgERAsU8mt4z4cZIBIAdKigZ1++y/JWR4uUQ2B0OJZ8gwY8CYDqVg9DbWQAU uZZ8PHesADwBsos7dIr+Ln/VoidlJdga7l+S9drvPZmAbnIr+GP6giXe0xavCZscjt3R exNpPBu5lTLOXEFOuo2COtlJunUlJtu5U5dgHsFuV/MGIkVHOtU5Ydhrmr8x8kXjReGa 9/Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9x/HwebwbfxMLzzgcrmihp5OGpg4eLO/YPa8riVK3JE=; b=XYizysHvrKJfjJ1qarLLgNfU/pyvy0PDCjiRHjgZZRwVVe1EIiztHN2B6cz7NecJLq r7zAk47Ldh8ofx6eIfNX6oPhARgfoMUt3ak2gmFvUqKw6a2omPGRR3LjGHA6j0larrD7 DM5zWvZ8vzFTXMPC6FUTCczoR8rR8U14UKlAyWLUgmNYNUyuqE5m71t1rkIZgMEv4LZe SO8NU0mkvAdookDWJ0lPK5N7BEIcAzYypc3OukPN6r9exMGBVxOSVoMQxas5SjKLgEa3 T4DUDvv8MAVQhkroHt/BRSAZVkbYU4UtTSmN1posz8Hkn99rS4DHZLfO4hw42VbxC4N9 Or1g== X-Gm-Message-State: AOAM530alO6lEYQxmQ+VDnzb2FUFN/Q9625AbqVjJUAx5ytDENq3L+xR TLbAQjJQOi/UBcG0FFWcvQr22jLiWGVAiQziLg== X-Google-Smtp-Source: ABdhPJy4AOjBRjWxNFUtsFjVdC1MBw93tifh/QTJqwQNGuMMuveJ5Ic/tDw3HCV+cy1aK0zNETIsY9zVoJsD396CcTo= X-Received: by 2002:a92:d3d1:: with SMTP id c17mr203610ilh.86.1628430584341; Sun, 08 Aug 2021 06:49:44 -0700 (PDT) MIME-Version: 1.0 References: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> In-Reply-To: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> From: AJITOMI Daisuke Date: Sun, 8 Aug 2021 22:49:32 +0900 Message-ID: To: Carsten Bormann Cc: Michael Richardson , cose@ietf.org, Laurence Lundblade Content-Type: multipart/alternative; boundary="00000000000085677105c90c8ab9" Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 13:49:51 -0000 --00000000000085677105c90c8ab9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > What=E2=80=99s the rush on disabling these? You may indeed be right. At least, I think there may be no need to rush to apply the change to 8152bis (Maybe that's impossible in the first place though). Maybe we should discuss this more. I would be happy if you would consider this matter as the next step after 8152bis. Regards, Daisuke 2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6=97=A5) 20:48 Carsten Bormann : > This discussion is all a bit short sighted to me. Sure, we can advise > against registering text labels now. But COSE has a long life with many > applications before it, some of which may be outside what you are thinkin= g > about now. What=E2=80=99s the rush on disabling these? > > Sent from mobile, sorry for terse > > On 8. Aug 2021, at 10:15, AJITOMI Daisuke wrote: > > =EF=BB=BF > > We can deprecate tstr as key. > > We can say that no signer MUST NEVER emit this again. > > We can say that a verifier MAY accept tstr as a key. > > This sounds reasonable to me. > > Since any tstr labels are not registered in the IANA registry for now and > there are no implementations that support the tstr labels as far as I kno= w, > > I think there is room to make the tstr labels deprecated. > > Thanks, > Daisuke > > 2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6=97=A5) 8:22 Michael Richardson : > >> >> Laurence Lundblade wrote: >> > I don=E2=80=99t think tstr can be removed from the standard. That = would >> break >> > backwards compatibility. Maybe a strong recommendation could be >> added >> > with the comment that many implementations don=E2=80=99t support t= str. >> >> Any system built upon COSE that does not support tstr as a key is alread= y >> broken if many implementations don't support it. >> >> We can deprecate tstr as key. >> We can say that no signer MUST NEVER emit this again. >> We can say that a verifier MAY accept tstr as a key. >> >> > There is a revision of 8152 in process right now called 8152bis. >> That >> > seems like the place to do it. >> >> It is pretty late to do this. 8152bis is in AUTH48, we need the >> proxy-author >> and WG chairs to agree to this immediately. >> >> I agree that having two ways things is not a good thing. >> >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consu= lting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> > --00000000000085677105c90c8ab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> What=E2=80=99s the rush on disabling= these?

You may indeed be right.
At least, I t= hink there may be no need to rush to apply the change to=C2=A08152bis (Mayb= e that's impossible in the first place though).
<= br>
Maybe we should discuss this more. I would be hap= py if you would consider this matter as the next step after 8152bis.

Regards,
Daisuke

2021=E5=B9=B48= =E6=9C=888=E6=97=A5(=E6=97=A5) 20:48 Carsten Bormann <cabo@tzi.org>:
This discussion is all a bit short si= ghted to me. Sure, we can advise against registering text labels now. But C= OSE has a long life with many applications before it, some of which may be = outside what you are thinking about now. What=E2=80=99s the rush on disabli= ng these?

Sent from=C2=A0mobile, sorry for terse

On 8. Aug 2021, at 10:15, AJITOMI Daisuke <ajitomi@gmail.com> wrote:
=
=EF=BB=BF=
> We can deprecate tstr as key.
> We= can say that no signer MUST NEVER emit this again.
> We can say that= a verifier MAY accept tstr as a key.

This sounds reasonab= le to me.

Since any tstr labels are not registered in the IANA regis= try for now and there are no implementations that support the tstr labels a= s far as I know,

I think there is room to make the tstr labels depre= cated.

Thanks,
Daisuke

=
2021=E5=B9=B48=E6=9C=888=E6=97=A5(=E6= =97=A5) 8:22 Michael Richardson <mcr+ietf@sandelman.ca>:

Laurence Lundblade <lgl@island-resort.com> wrote:
=C2=A0 =C2=A0 > I don=E2=80=99t think tstr can be removed from the stand= ard. That would break
=C2=A0 =C2=A0 > backwards compatibility. Maybe a strong recommendation c= ould be added
=C2=A0 =C2=A0 > with the comment that many implementations don=E2=80=99t= support tstr.

Any system built upon COSE that does not support tstr as a key is already broken if many implementations don't support it.

We can deprecate tstr as key.
We can say that no signer MUST NEVER emit this again.
We can say that a verifier MAY accept tstr as a key.

=C2=A0 =C2=A0 > There is a revision of 8152 in process right now called = 8152bis. That
=C2=A0 =C2=A0 > seems like the place to do it.

It is pretty late to do this.=C2=A0 8152bis is in AUTH48, we need the proxy= -author
and WG chairs to agree to this immediately.

I agree that having two ways things is not a good thing.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O= ( IPv6 I=C3=B8T consulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--00000000000085677105c90c8ab9-- From nobody Sun Aug 8 20:39:05 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E792A3A2528 for ; Sun, 8 Aug 2021 20:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mattrglobal242.onmicrosoft.com 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 JnzRjvuxbqyg for ; Sun, 8 Aug 2021 20:38:59 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on2122.outbound.protection.outlook.com [40.107.108.122]) (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 DED273A2525 for ; Sun, 8 Aug 2021 20:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bUoA1weqZcM64yuelcou8WF96390irliXQPJDPdrCCsTvvOkBf/8lC78wCTC9Ih05Q7oFYEIduPbze68WJ22TW6SYgGoHNG1xMR1DNYz/BAodEqJOXAzLBn/3WA/H9x0mI0XeMxVjNN3lY1ueSgvBvgERLO5e2j1OPE345Oh6a4drXNrJB4ySjHlgM4OlRWtqOxOIq/P9Q6FUJa1ZmaSyHEJVPrTpa/OdvBH4J1CwTgVyKEF0s3XF6MvOD1tFmfJ2DD+OfuEsymZHHidDc3sFVWIIk2GzS/dUcSq9dZ8Xo+c4rKKXZzGfvbcju9+XX335bNMDB0rMl53QP4KMkUKGw== 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=3PcQr5omO3eSexVrUXoueHcMoN8/ryxqJncQmjNd/xo=; b=Sk/5SY+E/Oc6elLkHciMs0dNdMWfZR0ChQEjP1Ug3ODpAT0ENStyxbd4GL80T0ZuVYZoC2GkAafDZ/eSsGJW4YeeSvZCfIr6NH3nDZfih8zQDYSGbfOSPamlq8x44uhgly3j/5oeVztSByknPrVGorXyBKBQPiq4Wstf0reQ45ZUcCe+y+H8jWKc5KoLI1vQal6UDRkG4rjLu28zt92+fnKc3XHzXAfeUpsx0irXD9xwyyYokAth0gQtkGjggb6shqLXX9YO9cNHrn2gdKk1i/rDaSSInMwSYVoqQn6h3kIgMqsIq1oqqjwu+g5BqxDI7BwqAIjlxKVn/UbhccXrMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mattr.global; dmarc=pass action=none header.from=mattr.global; dkim=pass header.d=mattr.global; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattrglobal242.onmicrosoft.com; s=selector1-mattrglobal242-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3PcQr5omO3eSexVrUXoueHcMoN8/ryxqJncQmjNd/xo=; b=YsGmP5GxxqbXDzucjBrANB+YfyEz6Y8IoGf6fgdQL1ydTA4jFiRIeTnNmOg6nBFMMO+Ul+wRMCCCXAvmNRJh4FWl2xYh2Frjmv20pg6eyWZeDkbccJRMf+7YIBEhxKbPdWHAYcHIHDDAoaDi9ctk7EqfLwDLnFU7b713MjQwQ3g= Received: from SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a9::8) by SYBP282MB2446.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:11b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Mon, 9 Aug 2021 03:38:56 +0000 Received: from SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM ([fe80::1d34:fe2a:57a1:28e]) by SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM ([fe80::1d34:fe2a:57a1:28e%8]) with mapi id 15.20.4394.022; Mon, 9 Aug 2021 03:38:56 +0000 From: Kyle Den Hartog To: "cose@ietf.org" Thread-Topic: Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose Thread-Index: AQHXh14rDCNZ4UEEXka/UfIWuuJSyqtqiv/P Date: Mon, 9 Aug 2021 03:38:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mattr.global; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 620e9735-f66c-401f-4e11-08d95ae7373f x-ms-traffictypediagnostic: SYBP282MB2446: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5w7w3XwuoKakxmBxSs5ug1LzixPMUP5gPvqruvX/qgEVd509ieZUZ5lAtZ0a3ddcoL1GTpKv1QrBBT6PMaHq/EKPSSqYdXSg++2KHmJyuZduSGNGVTXdG7oMRe3VWQTqT5Gq9ljK3BmUuGLSKrG/7NdwgxZ1OqtuWEqwuzW2qsXbsET89SbKOMLRM8Bznm55YDtEFjKLtmCeDdNUjr2RwaP9+xbleQzzhH0niIC//GDgTP0ln/O74f82yQXZ+WfG9orw8PXa2rOPjiOyqK6PS6gR2PHR9fmyZvMt7VbAryIxlQLat9mJbT8jxR3Gu6gOKpBTCgdnpPlM7pOI8Xx6kRRtSPIc5ZqRM7/Rkuti5u47rQEptiEHpN6W/J/zklXn4IY58d6JJb08qyjBwqvpkIDCdj+yPdol6hGzIyKSUrxp/JryE8f9V65lq1jNk/ZHBMufw6nLSz6W9KtBFOg5ovLStEQsFe7j5PoJX0HyfXP1sTvD3aJLo0sMHgtg2So42NFjG3XdDclddPeGvOxolcJETDR9fuyYy95HQfwaLz9ztDaYIfXd75Cs8Kea4Ia0g05kQXqrCpiOO+tW0+yrx72be8752aGl6v2j5EfuXJPOvXSRWOuV7Js9xQcaBNvwzSdbrdSPs3wPovsalcoBmwyHZ3YEpzOdITNnJMdRob16oC7Nts6DyVv1ATTHrBU/xdOORemVSDMoCjy//7dcTJQo6bjdXSgJpEQvYncISfCQZRpCoRexwkESW8wLELMJlL4G96C21LALlCE8oI0BXdA/BCmirpU8072bW7+W0bIABo0neflMTqVpS/uyyRYviHNiZ0Y7zsKz0q9bZnqzWtTVdy9sa2deCbGma2322+I= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(136003)(39830400003)(376002)(316002)(166002)(33656002)(9686003)(966005)(7696005)(19627405001)(53546011)(6506007)(55016002)(478600001)(186003)(71200400001)(122000001)(66556008)(66476007)(8676002)(19627235002)(2906002)(6916009)(38070700005)(38100700002)(76116006)(83380400001)(66946007)(86362001)(66446008)(8936002)(52536014)(5660300002)(64756008)(15398625002)(43620500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/5MKYbXFBX+fsLbs3p39n5aiqqr9OF8EXCo+RwfVF4YkWrPK9SpB183vfW1p?= =?us-ascii?Q?sO98NjZqghtbaf1R8Tm91gV6qsUfVwPMx8F0dC5hK290/42g+ZXe2WFm7K5N?= =?us-ascii?Q?Q+SL7XYHhRAk4lXxTYL1GhLsZnMfIzHZxwLIMyNceo+FeX1uo32lyzcCTcNJ?= =?us-ascii?Q?kv2hXA2z4no66rJgOQD8YHjVoc934sPou+b/PcxKsdMK51p6fZ6pA+gnZJbX?= =?us-ascii?Q?yX//KHX1CoBOAULuHUsz5rNPVCx7YudmvCqaO34aCUVLC5/JOPAcpSrfgfM/?= =?us-ascii?Q?8EP2CeLRZ4RveAHQva4H53i9u4/YbZSDEHPAeTs8JJQzSSnGskDAnwoLb7P9?= =?us-ascii?Q?r5ZMaDwpFJgxIt5ir6fny3vRdsG65KW6AE65sSRI8NyEidQkt9BdVnctJogY?= =?us-ascii?Q?7Ikpuc+ToUI9EvP5/k4HytXpdX0i/pw9u8ZBH3t/Lz4eCGfgJ9qK9sd6UAMA?= =?us-ascii?Q?9RE3dP0xoa2s2VpXClF+hfnDuk5TeolVSW/wQrT26Zcb5av6GXmVAamlA6vi?= =?us-ascii?Q?NnNP90SSU6xmM/9MA/EWxQiBAQ/Uk7oQxiGypj7tugU4LSjUgqUs4Tgk4sgN?= =?us-ascii?Q?bz/HqYbmcz3eC22XLYQPfubLSF28bUzn5XPARMOLM0hRBTSVXlk5C3QVv5EW?= =?us-ascii?Q?M+3hsRH+NoOKO+jkltBvJDGGkEFsZnd667/ILfzumrICoIwGkfEGuG60Jga9?= =?us-ascii?Q?k/DDd+1dWdG3svq5UhuMez+WGb6GFMeL3mNDry8MSXZ7UKVPEfWQld3wBw/K?= =?us-ascii?Q?0HkJKQk7vaSQ81izARN2j7CNtNBiiMz6W43RsJqQHHHzhQe1aqq/rQfRb+ja?= =?us-ascii?Q?ztVvRktp8Z3xkU4rZ8LUU/BVu6VvaOqWL/P7SnlDMbEFVNIwNctepaxVDv8X?= =?us-ascii?Q?IevRP7Wy3ccQwyhF7w9PpcReZdxeJvIN1/5pomWAN4Bh8liPrqRANxX7kXb8?= =?us-ascii?Q?VqGZ3VdpsGk/hn/rKU2TQHYR8h50N6WJGyZICo5Gt02wmPID7Pp018dzHNgi?= =?us-ascii?Q?1x0bYnA1KC4Yql+djZYq1vHyNRMqECzSICQR3j4EEgri9AlZVDKaXXaewKS/?= =?us-ascii?Q?ZC6s1ZC8Z7+YsqtC80ostxMyEfMZVoTU7DDADQ35dkf/m9cQdBsrkDpwPrV5?= =?us-ascii?Q?NCWNEoRz88JdWqGk1EU4gFBZ0zi70vm5X2LndJNdoARavA53FutqKulJyzXa?= =?us-ascii?Q?0Z0yUbXrXatGL9Sq7zxJOFQ6U2K3TZt9J8pjwIZOzSopEDQZwI8SV59+7aAT?= =?us-ascii?Q?WenoZ98E7wf7o78A1z9i4T1BRnHEpMe6C+CJP5SoQU062KeZkumY5sfZirPP?= =?us-ascii?Q?zO7YdnddECO2y2a6ArIyBPe0grjzL9EdEde6YupmTG+p7uek+GaJfhaybhIB?= =?us-ascii?Q?NCZTgqE=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SY4P282MB0796EF8CB21A83AC9B1D0CE7FCF69SY4P282MB0796AUSP_" MIME-Version: 1.0 X-OriginatorOrg: mattr.global X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 620e9735-f66c-401f-4e11-08d95ae7373f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2021 03:38:55.9690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c2c9cf73-6aae-4702-9844-02adab723771 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B6a19t772C6KdUtWtPhcyg80otMUjHbaozJTz1GzeEo1+3C5FuZGwkBOqAxiuVSVNhJvuibyKlmP/JzVVanKQOSjHNq8HQwmu0Z/0IgiKUs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBP282MB2446 Archived-At: Subject: Re: [COSE] Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 03:39:04 -0000 --_000_SY4P282MB0796EF8CB21A83AC9B1D0CE7FCF69SY4P282MB0796AUSP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding question 2: "Whether Bn256G1/G2 should be registered and prohibit= ed?" I was just reading the TPM2.0 profile[1] and it looks like Bn256G1/G2 are u= sed by default for ECDAA signatures and are by default included in the TPM2= .0 profile. There's an additional BN638 Curve that's optionally supported a= s well. It looks like there were algorithms under "ED256" which has registr= ation entries included in the FIDO ECDAA Algorithm specification[2] (see se= ction 5.7). This raises 2 questions for me: 1. Do these algorithms still need to be registered in the COSE/JOSE regi= stries? Given I'm still quite new to the COSE WG I'm not sure about the bac= k history. I'll do some digging in the mailing list to see if I can find so= me discussion about the topic. 2. Interestingly, they didn't define and attempt to register how the key= s would be formatted in a JWK/CWK format. Is anyone aware of why that was? Given the case that Bn256 is actively in use within FIDO with ECDAA, I'm le= aning against prohibiting usage of this even though there's been attacks th= at have reduce the security entropy to be ~100 bits. From a practical persp= ective this is just to prevent confusion for implementors of FIDO. Are ther= e any experts on this list who want to weigh in on this given the new (to m= e) information? [1]: https://web.archive.org/web/20161031085411/https://www.trustedcomputin= ggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf [2]: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algori= thm-v2.0-id-20180227.html#iana-considerations -Kyle ________________________________ From: Kyle Den Hartog Sent: Monday, August 2, 2021 6:08 PM To: cose@ietf.org Subject: Response to IETF 111 Agenda questions for draft-denhartog-pairing-= curves-jose-cose First off thanks Mike Jones for jumping in and PowerPoint jockeying through= the slides for me. Sorry for missing the meeting I had a time zone mix up.= I was able to rewatch the portion of the recording afterwards and wanted t= o weigh in on a few questions I heard and had prompted on the slides. 1. Should we use EC2 vs OKP? * This is where I was going with this question. It was asked to me i= f SEC1 encoding was commonly in use today. I realize now that the draft doe= sn't accurately convey that when I referenced SEC1 that I was implying the = usage of SEC1 point compression which would then use OKP. I'll need to upda= te that. As far as I've seen it's mainly gone towards OKP (with a single co= mpressed point and a sign) so my take was that we follow that pattern as we= ll. However, the latest pairing-friendly-curves draft[1] references draft-i= etf-lwig-curve-representations[2] (note it's draft 08 while the latest draf= t it's now in Appendix I.5). In this case, my questions was trying to figur= e out if the draft should use the SEC1 compression serialization of the key= s which seems more common in JOSE and COSE or if it would be better to cont= inue in the serialization method described in section 2.5. In this case, I = didn't fully understand what was being described in the lwig-curve draft, s= o I opted to go with SEC1 compressions in the initial draft. I'd like to ge= t others to weigh in on if this is even possible first, and then for us to = consider what is the better direction. 2. Whether Bn256G1/G2 should be registered and prohibited? * The discussion hit the nail on the head here. Thank you, Jonathan = Hammell, for jumping in and explaining the background on the security issue= . My concern was that because the security has been reduced to 100 bits rat= her than 128 bits does this warrant the draft defining it and marking it as= prohibited. My take was "yes" hence the original question. 3. Regarding the G1/G2 question: * This was largely heading in the direction of trying to figure out = if it makes sense to recogonize these separate finite fields as independent= "curves" or would it make more sense to use a different way to differentia= te them. One suggestion on the github repo has been to use multicodec as an= alternative serialization to SEC1 and lwigs-curve and then use that as a w= ay to represent the sub groups. My general take is that this didn't align w= ell with the traditional approach COSE/JOSE have used and so it's going to = introduce some new dependencies in many implementations I'd suspect. For th= is reason I would prefer to not go this route, but am not necessarily certa= in if my "crv" route is the right way either. 4. Regarding defining these with signatures: * My general take would be that I'd prefer to not have to do this. S= ince we haven't implemented any of the signatures schemes that utilize thes= e curves in JOSE or COSE, it would be a bit of a yak shaving exercise for u= s and our primary goals at this point to have to also define those. I know = of some related proposals that are looking to define these signatures (BBS+= ) in JOSE in the very introductory stages which may pair well with this, bu= t for now I'm of the opinion we could just as easily separate the works. If= there is a desire to define at least one signature scheme with this, the I= RTF does have the BLS signatures[3] being worked on which would pair well w= ith this work if there's a desire to add threshold signatures to JOSE/COSE. Hopefully with this additional context to the slides, people may have a bet= ter understanding and some further opinions on the various questions to dat= e. [1]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly= -curves-10#section-2.5 [2]: https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representa= tions-08#appendix-J.4 [3]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04= / Thanks, Kyle Den Hartog --_000_SY4P282MB0796EF8CB21A83AC9B1D0CE7FCF69SY4P282MB0796AUSP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Regarding question 2: "Whether Bn256G1/G2 should be registered and prohibited?"

I was just reading the TPM2.0 profile[1] and it looks like Bn256G1/G2 are u= sed by default for ECDAA signatures and are by default included in the TPM2= .0 profile. There's an additional BN638 Curve that's optionally supported a= s well. It looks like there were algorithms under "ED256" which has registration entries included= in the FIDO ECDAA Algorithm specification[2] (see section 5.7). This raise= s 2 questions for me:

  1. Do these algorithms still need to be registered in the COSE/JOSE = registries? Given I'm still quite new to the COSE WG I'm not sure about the= back history. I'll do some digging in the mailing list to see if I can fin= d some discussion about the topic.
  2. Interestingly, they= didn't define and attempt to register how the keys would be formatted in a= JWK/CWK format. Is anyone aware of why that was?
Given the case that Bn256 is actively in use within FIDO with ECDAA, I= 'm leaning against prohibiting usage of this even though there's been attac= ks that have reduce the security entropy to be ~100 bits. From a practical = perspective this is just to prevent confusion for implementors of FIDO. Are there any experts on this list who= want to weigh in on this given the new (to me) information?

From: Kyle Den Hartog
Sent: Monday, August 2, 2021 6:08 PM
To: cose@ietf.org <cose@ietf.org>
Subject: Response to IETF 111 Agenda questions for draft-denhartog-p= airing-curves-jose-cose
 
First off thanks Mike Jones for jumping in and PowerPoint jockeying through= the slides for me. Sorry for missing the meeting I had a time zone mix up.= I was able to rewatch the portion of the recording afterwards and wanted t= o weigh in on a few questions I heard and had prompted on the slides.
  1. Should we use EC2 vs OKP?
    1. This is where I was going with this question. It was asked to me = if SEC1 encoding was commonly in use today. I realize now that the draft do= esn't accurately convey that when I referenced SEC1 that I was implying the= usage of SEC1 point compression which would then use OKP. I'll need to update that. As far as I've seen it= 's mainly gone towards OKP (with a single compressed point and a sign) so m= y take was that we follow that pattern as well. However, the latest pairing= -friendly-curves draft[1] references draft-ietf-lwig-curve-representations[2] (note it's draft 08 while the lat= est draft it's now in Appendix I.5). In this case, my questions was trying = to figure out if the draft should use the SEC1 compression serialization of= the keys which seems more common in JOSE and COSE or if it would be better to continue in the serialization= method described in section 2.5. In this case, I didn't fully understand w= hat was being described in the lwig-curve draft, so I opted to go with SEC1= compressions in the initial draft. I'd like to get others to weigh in on if this is even possible first, and = then for us to consider what is the better direction.
  2. Whether Bn256G1/G2 should be registered and prohibited?
    1. The discussion hit the nail on the head here. Thank you, Jonathan Hamme= ll, for jumping in and explaining the background on the security issue. My = concern was that because the security has been reduced to 100 bits rather t= han 128 bits does this warrant the draft defining it and marking it as prohibited. My take was "yes"= ; hence the original question.
  3. Regarding the G1/G2 question:
    1. This was largely heading in the direction of trying to figure out if it= makes sense to recogonize these separate finite fields as independent &quo= t;curves" or would it make more sense to use a different way to differ= entiate them. One suggestion on the github repo has been to use multicodec as an alternative serialization to SEC1 an= d lwigs-curve and then use that as a way to represent the sub groups. My ge= neral take is that this didn't align well with the traditional approach COS= E/JOSE have used and so it's going to introduce some new dependencies in many implementations I'd suspect. Fo= r this reason I would prefer to not go this route, but am not necessarily c= ertain if my "crv" route is the right way either.
  4. Regarding defining these with signatures:
    1. My general take would be that I'd prefer to not have to do this. Since = we haven't implemented any of the signatures schemes that utilize these cur= ves in JOSE or COSE, it would be a bit of a yak shaving exercise for us and= our primary goals at this point to have to also define those. I know of some related proposals that are lo= oking to define these signatures (BBS+) in JOSE in the very introductory st= ages which may pair well with this, but for now I'm of the opinion we could= just as easily separate the works. If there is a desire to define at least one signature scheme with this, th= e IRTF does have the BLS signatures[3] being worked on which would pair wel= l with this work if there's a desire to add threshold signatures to JOSE/CO= SE.
Hopefully with this additional context to the slides, people may have = a better understanding and some further opinions on the various questions t= o date.

--_000_SY4P282MB0796EF8CB21A83AC9B1D0CE7FCF69SY4P282MB0796AUSP_-- From nobody Sun Aug 8 21:23:30 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7F33A268F for ; Sun, 8 Aug 2021 21:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SBL=0.141, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com 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 G1xA5_Id3KEu for ; Sun, 8 Aug 2021 21:23:24 -0700 (PDT) Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8883A2692 for ; Sun, 8 Aug 2021 21:23:24 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 781E6205124; Mon, 9 Aug 2021 04:23:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1628483002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kmV4g8BlXD0cp5giRdgM/d2fsQ41UWrbVp7WxJ+/tGw=; b=m0z9NR67bzRP+3Ou427yygFqi4K4kjBGjdSdihQ7v7glzlz3DhxGnA4KEqMuXpDB6JBlM7 W+NM6LoL2kr+gMazBvmLOwB6ocuubqD8FV5fyWmPpy2lm3yUuMHDn4Pp8Phpaj29Lpcmbc O53OzwOJZN5U0H1rnmj/1EO5+NQLM2Y= From: David Waite Message-Id: <17B95B7A-93BA-4E3C-8EE9-492BC675C5D6@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AA137798-3244-45EE-8084-A43D68A8CFD7" Mime-Version: 1.0 Date: Sun, 8 Aug 2021 22:23:19 -0600 In-Reply-To: Cc: "cose@ietf.org" To: Kyle Den Hartog References: Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [COSE] Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 04:23:29 -0000 --Apple-Mail=_AA137798-3244-45EE-8084-A43D68A8CFD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii AFAIK BN curves are not actively in use with FIDO, and there are no = production authenticators producing ECDAA attestations. -DW > On Aug 8, 2021, at 9:38 PM, Kyle Den Hartog = wrote: >=20 > Regarding question 2: "Whether Bn256G1/G2 should be registered and = prohibited?" >=20 > I was just reading the TPM2.0 profile[1] and it looks like Bn256G1/G2 = are used by default for ECDAA signatures and are by default included in = the TPM2.0 profile. There's an additional BN638 Curve that's optionally = supported as well. It looks like there were algorithms under "ED256" = which has registration entries included in the FIDO ECDAA Algorithm = specification[2] (see section 5.7). This raises 2 questions for me: >=20 > Do these algorithms still need to be registered in the COSE/JOSE = registries? Given I'm still quite new to the COSE WG I'm not sure about = the back history. I'll do some digging in the mailing list to see if I = can find some discussion about the topic. > Interestingly, they didn't define and attempt to register how the keys = would be formatted in a JWK/CWK format. Is anyone aware of why that was? > Given the case that Bn256 is actively in use within FIDO with ECDAA, = I'm leaning against prohibiting usage of this even though there's been = attacks that have reduce the security entropy to be ~100 bits. =46rom a = practical perspective this is just to prevent confusion for implementors = of FIDO. Are there any experts on this list who want to weigh in on this = given the new (to me) information? >=20 > [1]: = https://web.archive.org/web/20161031085411/https://www.trustedcomputinggro= up.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf = > [2]: = https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-= v2.0-id-20180227.html#iana-considerations = >=20 > -Kyle > From: Kyle Den Hartog > Sent: Monday, August 2, 2021 6:08 PM > To: cose@ietf.org > Subject: Response to IETF 111 Agenda questions for = draft-denhartog-pairing-curves-jose-cose > =20 > First off thanks Mike Jones for jumping in and PowerPoint jockeying = through the slides for me. Sorry for missing the meeting I had a time = zone mix up. I was able to rewatch the portion of the recording = afterwards and wanted to weigh in on a few questions I heard and had = prompted on the slides. > Should we use EC2 vs OKP? > This is where I was going with this question. It was asked to me if = SEC1 encoding was commonly in use today. I realize now that the draft = doesn't accurately convey that when I referenced SEC1 that I was = implying the usage of SEC1 point compression which would then use OKP. = I'll need to update that. As far as I've seen it's mainly gone towards = OKP (with a single compressed point and a sign) so my take was that we = follow that pattern as well. However, the latest pairing-friendly-curves = draft[1] references draft-ietf-lwig-curve-representations[2] (note it's = draft 08 while the latest draft it's now in Appendix I.5). In this case, = my questions was trying to figure out if the draft should use the SEC1 = compression serialization of the keys which seems more common in JOSE = and COSE or if it would be better to continue in the serialization = method described in section 2.5. In this case, I didn't fully understand = what was being described in the lwig-curve draft, so I opted to go with = SEC1 compressions in the initial draft. I'd like to get others to weigh = in on if this is even possible first, and then for us to consider what = is the better direction. > Whether Bn256G1/G2 should be registered and prohibited? > The discussion hit the nail on the head here. Thank you, Jonathan = Hammell, for jumping in and explaining the background on the security = issue. My concern was that because the security has been reduced to 100 = bits rather than 128 bits does this warrant the draft defining it and = marking it as prohibited. My take was "yes" hence the original question. > Regarding the G1/G2 question: > This was largely heading in the direction of trying to figure out if = it makes sense to recogonize these separate finite fields as independent = "curves" or would it make more sense to use a different way to = differentiate them. One suggestion on the github repo has been to use = multicodec as an alternative serialization to SEC1 and lwigs-curve and = then use that as a way to represent the sub groups. My general take is = that this didn't align well with the traditional approach COSE/JOSE have = used and so it's going to introduce some new dependencies in many = implementations I'd suspect. For this reason I would prefer to not go = this route, but am not necessarily certain if my "crv" route is the = right way either. > Regarding defining these with signatures: > My general take would be that I'd prefer to not have to do this. Since = we haven't implemented any of the signatures schemes that utilize these = curves in JOSE or COSE, it would be a bit of a yak shaving exercise for = us and our primary goals at this point to have to also define those. I = know of some related proposals that are looking to define these = signatures (BBS+) in JOSE in the very introductory stages which may pair = well with this, but for now I'm of the opinion we could just as easily = separate the works. If there is a desire to define at least one = signature scheme with this, the IRTF does have the BLS signatures[3] = being worked on which would pair well with this work if there's a desire = to add threshold signatures to JOSE/COSE. > Hopefully with this additional context to the slides, people may have = a better understanding and some further opinions on the various = questions to date. >=20 > [1]: = https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-cur= ves-10#section-2.5 = > [2]: = https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representation= s-08#appendix-J.4 = > [3]: = https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04/ = >=20 > Thanks, > Kyle Den Hartog > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_AA137798-3244-45EE-8084-A43D68A8CFD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii AFAIK= BN curves are not actively in use with FIDO, and there are no = production authenticators producing ECDAA attestations.
-DW

On Aug = 8, 2021, at 9:38 PM, Kyle Den Hartog <kyle.denhartog@mattr.global> wrote:

Regarding question 2: = "Whether Bn256G1/G2 should be registered = and prohibited?"

I was just reading the = TPM2.0 profile[1] and it looks like Bn256G1/G2 are used by default for = ECDAA signatures and are by default included in the TPM2.0 profile. = There's an additional BN638 Curve that's optionally supported as well. = It looks like there were algorithms under "ED256" which has registration = entries included in the FIDO ECDAA Algorithm specification[2] (see = section 5.7). This raises 2 questions for me:

  1. Do = these algorithms still need to be registered in the COSE/JOSE = registries? Given I'm still quite new to the COSE WG I'm not sure about = the back history. I'll do some digging in the mailing list to see if I = can find some discussion about the topic.
  2. Interestingly, they didn't define and attempt to register how = the keys would be formatted in a JWK/CWK format. Is anyone aware of why = that was?
Given the case = that Bn256 is actively in use within FIDO with ECDAA, I'm leaning = against prohibiting usage of this even though there's been attacks that = have reduce the security entropy to be ~100 bits. =46rom a practical = perspective this is just to prevent confusion for implementors of FIDO. = Are there any experts on this list who want to weigh in on this given = the new (to me) information?

From: Kyle Den Hartog
Sent: Monday, August 2, 2021 6:08 = PM
To: cose@ietf.org <cose@ietf.org>
Subject: Response to IETF 111 Agenda = questions for draft-denhartog-pairing-curves-jose-cose
 
First off = thanks Mike Jones for jumping in and PowerPoint jockeying through the = slides for me. Sorry for missing the meeting I had a time zone mix up. I = was able to rewatch the portion of the recording afterwards and wanted = to weigh in on a few questions I heard and had prompted on the = slides.
  1. Should we use EC2 vs OKP?
    1. This is where I was going with this question. It was asked to = me if SEC1 encoding was commonly in use today. I realize now that the = draft doesn't accurately convey that when I referenced SEC1 that I was = implying the usage of SEC1 point compression which would then use OKP. = I'll need to update that. As far as I've seen it's mainly gone towards = OKP (with a single compressed point and a sign) so my take was that we = follow that pattern as well. However, the latest pairing-friendly-curves = draft[1] references draft-ietf-lwig-curve-representations[2] (note it's = draft 08 while the latest draft it's now in Appendix I.5). In this case, = my questions was trying to figure out if the draft should use the SEC1 = compression serialization of the keys which seems more common in JOSE = and COSE or if it would be better to continue in the serialization = method described in section 2.5. In this case, I didn't fully understand = what was being described in the lwig-curve draft, so I opted to go with = SEC1 compressions in the initial draft. I'd like to get others to weigh = in on if this is even possible first, and then for us to consider what = is the better direction.
  2. Whether Bn256G1/G2 should be registered and = prohibited?
    1. The discussion hit the nail on the head here. Thank you, = Jonathan Hammell, for jumping in and explaining the background on the = security issue. My concern was that because the security has been = reduced to 100 bits rather than 128 bits does this warrant the draft = defining it and marking it as prohibited. My take was "yes" hence the = original question.
  3. Regarding the = G1/G2 question:
    1. This was largely heading in the direction of = trying to figure out if it makes sense to recogonize these separate = finite fields as independent "curves" or would it make more sense to use = a different way to differentiate them. One suggestion on the github repo = has been to use multicodec as an alternative serialization to SEC1 and = lwigs-curve and then use that as a way to represent the sub groups. My = general take is that this didn't align well with the traditional = approach COSE/JOSE have used and so it's going to introduce some new = dependencies in many implementations I'd suspect. For this reason I = would prefer to not go this route, but am not necessarily certain if my = "crv" route is the right way either.
  4. Regarding = defining these with signatures:
    1. My general take would be that = I'd prefer to not have to do this. Since we haven't implemented any of = the signatures schemes that utilize these curves in JOSE or COSE, it = would be a bit of a yak shaving exercise for us and our primary goals at = this point to have to also define those. I know of some related = proposals that are looking to define these signatures (BBS+) in JOSE in = the very introductory stages which may pair well with this, but for now = I'm of the opinion we could just as easily separate the works. If there = is a desire to define at least one signature scheme with this, the IRTF = does have the BLS signatures[3] being worked on which would pair well = with this work if there's a desire to add threshold signatures to = JOSE/COSE.
Hopefully with = this additional context to the slides, people may have a better = understanding and some further opinions on the various questions to = date.

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_AA137798-3244-45EE-8084-A43D68A8CFD7-- From nobody Mon Aug 9 11:11:45 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2B3A0FD4 for ; Mon, 9 Aug 2021 11:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 On01o-2s4pb4 for ; Mon, 9 Aug 2021 11:11:27 -0700 (PDT) Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (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 C6C073A0FCA for ; Mon, 9 Aug 2021 11:10:53 -0700 (PDT) Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id D9jgmMMIqUzFJD9jgmD8wR; Mon, 09 Aug 2021 11:10:52 -0700 X-CMAE-Analysis: v=2.4 cv=KIyfsHJo c=1 sm=1 tr=0 ts=61116fac a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=48vgC7mUAAAA:8 a=QRmpseJC5sta6OmupOkA:9 a=QEXdDO2ut3YA:10 a=sPfqeAi7hdY48IWftZIA:9 a=DkXbxFwwOEzgUzWq:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_407C7130-4A3D-4855-A5FA-E3A863C64D01" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 9 Aug 2021 11:10:51 -0700 In-Reply-To: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> Cc: "cose@ietf.org" To: =?utf-8?Q?G=C3=B6ran_Selander?= References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-CMAE-Envelope: MS4xfLGEoO47RV0fjoB/YM3HQw5bRc7cBn/1hpxO2pPCn4lssrd+g7nADV1f/ZYc5L7sKi4vliq9hP74NpuUlsIm3WPRRNSgCdnLReJ1ZjX8UJhSxnrZo7UO fr6Vlaz00GbS1H8PYljEuRFO/Tc3gMoQFYIMxQgwF4SDaCzQI4WWWozYC0q/2dmcJwJZ1I+4Wm/I+AChmCeLIDXCPONC2MIxNtt0sqEhlfJJlHhLLLyC08I0 T1n/mi6S4sOryL6jhGeLzw== Archived-At: Subject: Re: [COSE] Key identifier of type bstr / int X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 18:11:33 -0000 --Apple-Mail=_407C7130-4A3D-4855-A5FA-E3A863C64D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A small comment on code size as the author of a commercial-quality COSE = implementation designed to have small code size. There is a bit of a trade-off between code size and bytes on the wire. = Reducing the bytes on the wire by one byte in this case will lead to an = increase in code size by a lot more than one byte, assuming both int and = bstr are supported. If both are not supported, then there is #ifdef = complexity and configuration work with general purpose COSE = implementations. Most of the code cost for me in implementing COSE is in the header = parameter decoding. This desire to save 1 CBOR byte here and there at the cost of code / = complexity shows up elsewhere. Here=E2=80=99s one from CoSWID one-or-more =3D T / [ 2* T ] This could just be an array. I don=E2=80=99t know the use cases, but I=E2=80=99m a little skeptical = these sorts of things are worth a byte or two on the wire. LL > On Jul 30, 2021, at 5:28 AM, G=C3=B6ran Selander = wrote: >=20 > Hi, >=20 > In LAKE yesterday we had a discussion on compact key identifiers. The = main candidate to use, 'kid', is specified as a CBOR bstr, which is = typically at least 2 bytes (exception: empty bstr which is 1 byte). We = therefore want to allow keys to be identified with CBOR ints which has = 48 1-byte values to allow for a larger number of optimally small = identifiers. >=20 > One solution would be to define a new COSE key common parameter and = COSE header parameter, say 'kid2', of type bstr / int. Another solution = would be to extend 'kid' to be bstr / int. >=20 > In the former case a 'kid2' can be used to reference keys identified = with either 'kid2' or 'kid', but 'kid' would not be able to reference = keys identified with 'kid2' having an int value. Not clear to me if that = is a problem.=20 >=20 > While the LAKE WG did not express any preference, one opinion I learnt = after the meeting was a preference of extending 'kid' to bstr / int. >=20 > What do folks in COSE think? >=20 > I'm familiar with the process of registering new COSE parameters, what = is the requirement for changing the value type of an existing = registration? Standards action with expert review? >=20 > Thanks > G=C3=B6ran >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_407C7130-4A3D-4855-A5FA-E3A863C64D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = small comment on code size as the author of a commercial-quality COSE = implementation designed to have small code size.

There is a bit of a trade-off between = code size and bytes on the wire. Reducing the bytes on the wire by one = byte in this case will lead to an increase in code size by a lot more = than one byte, assuming both int and bstr are supported. If both are not = supported, then there is #ifdef complexity and configuration work with = general purpose COSE implementations.

Most of the code cost for me in = implementing COSE is in the header parameter decoding.

This desire to save 1 = CBOR byte here and there at the cost of code / complexity shows up = elsewhere. Here=E2=80=99s one from CoSWID
one-or-more<T> =3D T / [ 2* T ]

This could just be an = array.

I = don=E2=80=99t know the use cases, but I=E2=80=99m a little skeptical = these sorts of things are worth a byte or two on the wire.

LL



On Jul 30, 2021, at 5:28 AM, G=C3=B6ran Selander <goran.selander=3D40ericsson.com@dmarc.ietf.org> = wrote:

Hi,

In LAKE yesterday we had a = discussion on compact key identifiers. The main candidate to use, 'kid', = is specified as a CBOR bstr, which is typically at least 2 bytes = (exception: empty bstr which is 1 byte). We therefore want to allow keys = to be identified with CBOR ints which has 48 1-byte values to allow for = a larger number of optimally small identifiers.

One solution would be to define a new COSE key common = parameter and COSE header parameter, say 'kid2', of type bstr / int. = Another solution would be to extend 'kid' to be bstr / int.

In the former case a 'kid2' can be used to = reference keys identified with either 'kid2' or 'kid', but 'kid' would = not be able to reference keys identified with 'kid2' having an int = value. Not clear to me if that is a problem.

While the LAKE WG did not express any preference, one opinion = I learnt after the meeting was a preference of extending 'kid' to bstr / = int.

What do folks in COSE think?

I'm familiar with the process of registering = new COSE parameters, what is the requirement for changing the value type = of an existing registration? Standards action with expert review?

Thanks
G=C3=B6ran


_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_407C7130-4A3D-4855-A5FA-E3A863C64D01-- From nobody Mon Aug 9 12:44:00 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61853A1433 for ; Mon, 9 Aug 2021 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fZMxgLQDjUCy for ; Mon, 9 Aug 2021 12:43:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F1D3A1430 for ; Mon, 9 Aug 2021 12:43:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B8777389BE; Mon, 9 Aug 2021 15:48:26 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AneqNHhPuzfJ; Mon, 9 Aug 2021 15:48:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5EF49389B8; Mon, 9 Aug 2021 15:48:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 95F8B622; Mon, 9 Aug 2021 15:43:45 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: AJITOMI Daisuke , cose@ietf.org, Laurence Lundblade , jodonogh@qti.qualcomm.com In-Reply-To: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> References: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 19:43:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > This discussion is all a bit short sighted to me. Sure, we can advise > against registering text labels now. But COSE has a long life with ma= ny > applications before it, some of which may be outside what you are > thinking about now. What=E2=80=99s the rush on disabling these? I understood that some people think that we can encode the map key for 'kty' as both 'kty' and also 1. (section 7 of RFC8152) [ditto alg and I think key_ops] I'm not convinced the document says that. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmERhXEACgkQgItw+93Q 3WXiEwgAtaTk/wC+1tRyAlpgGBedWo1jpL3Va7DddLoR9GfcGWoLmLyJ7xZ05QeR j8gyUM/Plfm783rTPi7AcVdW3oXPTcrDjvTBlCLJc6KCAuT80ca4AL7aZz72bGlf 4p5CryCSiTktGYhC/kvekxWqTK+mizN0GYsF1J85fSYmztoiMRbYZHhzcoiW2nbL 9XQA0L1SzMzYaS5WoG5pM2k32ZVotZOyA51zb/gQD62Eo3X1DjB+qnlBuQUODDCW Kg6/35FLeOQdm0Cd9Nz5O4PQpiV3JVY90piSoSdV4lHEpMzspdvpz2q8lnqGQM9e fsWlhkdjycWy3watGCd1P5YoEsZEIA== =rXl2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 9 13:21:43 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E196A3A15A6 for ; Mon, 9 Aug 2021 13:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 bsDvgDJSW867 for ; Mon, 9 Aug 2021 13:21:32 -0700 (PDT) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) (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 A8CA53A1597 for ; Mon, 9 Aug 2021 13:21:32 -0700 (PDT) Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id DBm5mBqvATJ8VDBm6msltj; Mon, 09 Aug 2021 13:21:31 -0700 X-CMAE-Analysis: v=2.4 cv=eIjWMFl1 c=1 sm=1 tr=0 ts=61118e4b a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=l70xHGcnAAAA:8 a=gKmFwSsBAAAA:8 a=3m2aLBOWVkK0B67FkycA:9 a=QEXdDO2ut3YA:10 a=Bifs-xScn1LMGr9p:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=nnPW6aIcBuj1ljLj_o6Q:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A3CE12AB-B14B-4173-B2FD-4327E8BFCE2F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 9 Aug 2021 13:21:29 -0700 In-Reply-To: <10529.1628538225@localhost> Cc: Carsten Bormann , AJITOMI Daisuke , cose@ietf.org, jodonogh@qti.qualcomm.com To: Michael Richardson References: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> <10529.1628538225@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-CMAE-Envelope: MS4xfEtOFw4qg41e0EG9/xrpyAa6baEMEhYMTPTmTzzqzs63uyq4ZMPSxwaB4uhYfyS1nYVZ2lQbuihYmqyygLxE/48nEhG/FT+pNeqwciYleWfTmahPcbea bKCdm44uihhWg3duVcFDhSFi7NKI/7eZHYibdPvAgKOOYY4azX5KbXqmu1CPdX+ZVRFZnFNa9GJ6Ly8LVwxeYHvE7cyFL2oj8S1IXpSBHdrYciETKYoWyGjt s3Bk8J2nCH7iAqDen8mDGZWIMt60T6o7ouufj62Icf4p3oQSwEhRwarp4I1qnjKID3VL2M0fQhgcgBJinIB5ew== Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 20:21:42 -0000 --Apple-Mail=_A3CE12AB-B14B-4173-B2FD-4327E8BFCE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 9, 2021, at 12:43 PM, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> This discussion is all a bit short sighted to me. Sure, we can advise >> against registering text labels now. But COSE has a long life with = many >> applications before it, some of which may be outside what you are >> thinking about now. What=E2=80=99s the rush on disabling these? >=20 > I understood that some people think that we can encode the map key for = 'kty' > as both 'kty' and also 1. >=20 > (section 7 of RFC8152) > [ditto alg and I think key_ops] >=20 > I'm not convinced the document says that. Agreed. The CDDL allows only 1, 2, 3,...for the params defined in COSE, but = allows tstr for future params. label =3D int / tstr COSE_Key =3D { 1 =3D> tstr / int, ; kty ? 2 =3D> bstr, ; kid ? 3 =3D> tstr / int, ; alg ? 4 =3D> [+ (tstr / int) ], ; key_ops ? 5 =3D> bstr, ; Base IV * label =3D> values } Essentially, I think anyone trying to register tstr COSE identifier or = label should be asked if they really want to do that, is it really = necessary to use a tstr instead of an int: Are you just doing it = because you are used to JSON? You know that most implementations don=E2=80= =99t support tstr, right? Also, to be clear, you don't register both a tstr and an int for a = particular item. There are two ways of doing this, but not for an = individual item. Having tstr =E2=80=98foo=E2=80=99 and int 42 both = referring to the same item would actually require two registrations and = would be the worst thing to do. LL= --Apple-Mail=_A3CE12AB-B14B-4173-B2FD-4327E8BFCE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Aug 9, 2021, at 12:43 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Carsten Bormann <cabo@tzi.org> wrote:
This discussion is all a bit short sighted to = me. Sure, we can advise
against registering text labels = now. But COSE has a long life with many
applications = before it, some of which may be outside what you are
thinking about now. What=E2=80=99s the rush on disabling = these?

I understood that some = people think that we can encode the map key for 'kty'
as = both 'kty' and also 1.

(section 7 of = RFC8152)
[ditto alg and I think key_ops]

I'm not convinced the document says that.

Agreed.

The = CDDL allows only 1, 2, 3,...for the params defined in COSE, but allows = tstr for future params.


   label =3D int / tstr


   COSE_Key =3D {
       1 =3D> tstr / int,          ; kty
       ? 2 =3D> bstr,              ; kid
       ? 3 =3D> tstr / int,        ; alg
       ? 4 =3D> [+ (tstr / int) ], ; key_ops
       ? 5 =3D> bstr,              ; Base IV
       * label =3D> values
   }

Essentially, I think anyone trying to register tstr COSE = identifier or label should be asked if they really want to do that, is = it really necessary to use a tstr instead of an int:  Are you just = doing it because you are used to JSON? You know that most = implementations don=E2=80=99t support tstr, right?

Also, to be clear, you = don't register both a tstr and an int for a particular item. There are = two ways of doing this, but not for an individual item. Having tstr = =E2=80=98foo=E2=80=99 and int 42 both referring to the same item would = actually require two registrations and would be the worst thing to = do.

LL
= --Apple-Mail=_A3CE12AB-B14B-4173-B2FD-4327E8BFCE2F-- From nobody Tue Aug 10 03:13:48 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6ED3A0CD0 for ; Tue, 10 Aug 2021 03:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 4TUM-zxRZQnn for ; Tue, 10 Aug 2021 03:13:40 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70073.outbound.protection.outlook.com [40.107.7.73]) (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 03A533A0CCE for ; Tue, 10 Aug 2021 03:13:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QWFPscWW6Bn1t6ACRbKLvjkl4tqvWxrPi5muI1qGCb9mgYjxI3jnwoDVcP7jUxCXWbNRUNv5UqUFjapbO8TOmwNF3LvGv0CkX1oA58TN/1lqcsV/58A5quO/cP8o9Q3nC0kWeeIhuNql8EUBxkL3p5csEn54hh/NORzHwp/dLuk69cmXu9xjacAEGtc1K9XO11Hs3JZljSubF/BwsYsM8ov7PspYinw8KlZhTRf57UpWXI5gzVKpjHrBr4RPWtxV/0aYnU+kNjVu3HIrz9kvifNFywLQx2YPpB0zHVoyVptZYuR9CaOz33nW3J2J9CJgQynuCFC1824j677395ZapA== 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=xweVs7m1gVqkGQkPmh423f9PMT2WvB+25JS9g1FbOV8=; b=OAj4kM/zIgUF4FZs3KGbTdX56aM1xZXvCIAlVQA+D94mR5+9PH5QJdqSGZryiznRqiqpNX5kudUD9e7T8Bn6xqiLfA5o2ydBhBTp7DiUSIDfJf/eP9X2lTPWlu7ZsWuHGrSkwO2CTN8gnum+KSD+nsT/hMyFhUS9qpykD0uB/x98HcCpdOkRCEQquqYy6jssJGYlME2OvfKjIlCKzFMPBzK5BGuxAR9Qtgd8/RX00sPvSCIhioM30o9m6CkRJWKZZanmcpuuRRLoiQ/artj+VbOgZCe9degEtARdwLrFWNJJlg7Bn7h+tF4NhwHHqBtDJrB4WyveNhwgf+8WmSDlWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xweVs7m1gVqkGQkPmh423f9PMT2WvB+25JS9g1FbOV8=; b=E0C+jFMQupgp6oKYO2p7FjYSbKc4dOKnnf/+2JUU4Z2U/NY8cWBtCA1sZrYauWA6UyV1nJwYFYjYs68eJW1E/P8bZIX8caO95OnNtgO9aLHsTbmkr4jivLGCtdQIxduNTsMVlskjRQJqVwrrogdbzVlASV0aEmyebSswkod44p4= Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0702MB3834.eurprd07.prod.outlook.com (2603:10a6:7:8c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.10; Tue, 10 Aug 2021 10:13:37 +0000 Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::7191:79ea:fa53:9014]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::7191:79ea:fa53:9014%4]) with mapi id 15.20.4415.014; Tue, 10 Aug 2021 10:13:36 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Laurence Lundblade CC: "cose@ietf.org" Thread-Topic: [COSE] Key identifier of type bstr / int Thread-Index: AQHXhT54TcPpMfWo3E61Id/NsrhJv6triUiAgAEuhQA= Date: Tue, 10 Aug 2021 10:13:36 +0000 Message-ID: References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> In-Reply-To: <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 48608447-0b22-481d-f209-08d95be7849a x-ms-traffictypediagnostic: HE1PR0702MB3834: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aNCHudAnBb1r4XvIkxT5XK+O77G7XzReLzK5REBuXsPQJbEcrEpvRfb04H0stOlS5klQZQ6dRf5qo8B74kqXC51ej/rup7PlBCfQ1mpWwBr3XkZuhFAUJ6htmmNOjqDbvXka3ocTm+nrCppV6F+lzuUBPQkIB8i6PP3dI2eBSFEqf6XAPBLVTX2WSDS9zon2NUgGzK8Esm+UJkG4E09BBwSbXkSyhc1oSVItwcYq+u1COwYwtMGCE3RHrILulAcpZD5ZLreTqBtCt9+uoIKfUvDPeBbWFg6norpkxijwQrm57dQFVV6xddf11N9K65JqIvuaXL1FqlrmdqUpwEVzMSxiFZl9jPhm2hlj92B9g3DNLVtXoY3hIU1/kk8x7OncIO5KmqZQFqGGGEzVOF+4Xok+Gr+fg/8qQzmb8Z2yLxD+0/1eM77pFKJOaDbRgW1rWKcVmMNsOJYcXb2mDIsX41faxNDKgf3ar657y6ELlLd8lo1hFNp7JsRcV3Oj6+4+TfPQpT4a4GeAiJq/V36Iz6cqVKGC01CW22qjg+ssuFOSkHkTo8ZNQgUp6snpx4lKhC9K7dJJhFcUOrBi1/oxv+CpdivuicCDsJOxXXUIX+s1bKiP765HYy7uAeTeFNeVwbKVA4NJSR4tFpMVlbpwa9Q0H0dHPkM0TvcoT4bVQFm3VcHK95zAcIm98Z37WNGNggeAzA+2sqTLNL8wix7kia7d2VhJ6ZpHmx9CA+Bre7+uDk6PuQn47ZVhk4gl9NzqCB8YclpHmVwql4X9oNRBCRqGkKLGohz8rsKo3rrNBg8eTWM25Gz3brl+L+yCKBGB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(2906002)(38070700005)(6486002)(6512007)(8676002)(2616005)(33656002)(36756003)(85202003)(26005)(71200400001)(53546011)(6506007)(76116006)(6916009)(83380400001)(122000001)(64756008)(4326008)(316002)(66446008)(66574015)(66476007)(966005)(8936002)(85182001)(5660300002)(508600001)(86362001)(66556008)(38100700002)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dWREOW1qSXRYY1kvbDFoVnRjREpiSmtNVE5BNG1odzlmKzdFR2ZuTEN6eVBy?= =?utf-8?B?RmlqdjZQMDhpbzJFOHlncjdCMUQ2bnR4Q2JHZzYrTWdFdis0c0tESmhqVExZ?= =?utf-8?B?Qno4b2EwU0MzK08rR0VRUVpQZ0NVT0JTQ0grNTBYOUNGL2lZcjZqNFZYSUJv?= =?utf-8?B?Tmt3SEdaUVRSTnl6ZTFYdlJFcTVwMC9kRlJmMmJjOG9JS0R1c2xsekE5djlC?= =?utf-8?B?TTZqcFVobjhBbkxaeitheVgzakF6M3dlZUo0RHo0YkMxQi9DT1VTNnk3NXBC?= =?utf-8?B?ZnhITzdmOXIzNExtTjdiV084NW85NlFLL0FROXkvQ08rbFJGUlRuZHkxc0JY?= =?utf-8?B?WERQbkdUVDd3VFI5K0lGbThsYXFua3VSRGZSQWhaQUZOM3Vxb1Q4L0tqV1JF?= =?utf-8?B?N3FrdTJxMTQzV1FGd3ZPL1hHM3kwMmNUNDJ1cVVPcGx3cGxQemZhb0tPWkRV?= =?utf-8?B?MHB5R1JxRDlMSkFEMWZDVnlRejVTWmRsb0g3SW1OeXJWMXVqUVZ2T3IrRlFy?= =?utf-8?B?a2M0bHVWdHo5eDlzSlYrNW9SdkpJbXpWNHorVVNwSlRHZ2VINVRCVlp2Y2Jv?= =?utf-8?B?Q0Rub3ZpTFVvZXZVN1BYekVoRFlENy9HcUhoSG15TTJRUU1uNWFUUW1LYzZY?= =?utf-8?B?NDJCRUl0dHJjSTVkWmlBMXhKYm4zRDZwYlFvQTV0ZEEvQUwrYXRLQnE3MGQ3?= =?utf-8?B?dDh1cW4veWtqQ0FpVm5UVnA4SE53M1FSQ081ekVqYnR0Zk5hZUtXemt2eVVs?= =?utf-8?B?ZFJuUGpmc3pOK2lTYTRRZFgrKy9FNEN4VFlOS3EyRkJqVXRCNnJGanNFN1ln?= =?utf-8?B?Sk5HM0ZDc2hubURtMy9rRHhoeW5sb3FlUG9nU2srdktyWDRTb2lKcFdmZldm?= =?utf-8?B?VDhiRWg5bFYxSGpjTC9mWUpuMjBzampCNk8reEJIeTJjOHd1bjFmNWd6TVFR?= =?utf-8?B?anZNWm5vZ25jbXI4ZHBTVEdZUklJOWt6dnRYUklIZTJITnZuTlNJbXhSNlBF?= =?utf-8?B?Uld1czhYZHlaV3FKRktPMDRGK1E1WUdjYVJoZHY1VWRHZFBOcHd4TzZmVitJ?= =?utf-8?B?SmFnUUFyQWZHb1pOWWpRMzhXOE50eFg0NEZjU2hxclJxYkxRTi91OUhQYm1M?= =?utf-8?B?ZmlFOFpiMXU0VDZ2Q25hUmVMZS82Qm9uY3cyM1JxQkY3QTJDcWM0OVNrdng0?= =?utf-8?B?Mzc4aEgrRTNHcndlMUlzZ2dpZHg1ZGM1U29Vd3NZaDNyWVR0STZTOW9WZ3ll?= =?utf-8?B?ZU1YaElxLzNaM29FTTBubCtIWEovcVp0UTlzcXlrdUlNN3pOWkY3RXFGeTlX?= =?utf-8?B?Y0RmMzArclBtNlRXWUlJNS80b1cyYzBVSTJmd1gyN2o4blE4OWJ6VnA3TVhl?= =?utf-8?B?bWdLbDhEelhEdUQrY2hlSEt5M1VvZiszcElnN1JCRGwzbTJjRitUQWN6Mnhs?= =?utf-8?B?bFY3b3hoRjgyQTVYOXg4VmJpWThTQ3ljSmRTNUxtQXVPeFNPOGNIaXpOMUo5?= =?utf-8?B?TU9GUElabEw0U280UUZubE1PUEd4TldjRzZCQks3SWx3ODNwd2paelVUajNw?= =?utf-8?B?ekF5ejB1Tlh4aUt2Y3ZYRms4STVJcCs3U1BHa2hHUXE1Yk9FejRZeStxTmhv?= =?utf-8?B?VW5oZWpvcVlmNU12VlY5K0hrZ1dNdWVvOGp5NmFibEVvZ2E4TEZpanNZQ0E2?= =?utf-8?B?QlIvUE55d2VZdDVxanp4dE82WThxY0YxMUdsZFF5YWtaOXlmWXh4ZTFjL0Z5?= =?utf-8?Q?oQp2BDF7KigPE9prFfuYzlJRu94cylSuBHnJ/r9?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_EDFDB6E42BDE4E2E9CF0D771E2DEF3C6ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48608447-0b22-481d-f209-08d95be7849a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 10:13:36.8876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TNHXePmO8aeb0VO11eEB3xLWcUHtP8l6PjUyoxJhk34G/f6gXu4Gw3efMgebzwG04BMb+xoCOQOtBWfs9WL9KJGbzHUN+RPqxDYeO6AVO1w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3834 Archived-At: Subject: Re: [COSE] Key identifier of type bstr / int X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 10:13:47 -0000 --_000_EDFDB6E42BDE4E2E9CF0D771E2DEF3C6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIExhdXJlbmNlLCB0aGVzZSB0cmFkZS1vZmZzIGFyZSBpbXBvcnRhbnQgdG8gY29uc2lk ZXIuIFRoZSBmaW5hbCBtZXNzYWdlIG9wdGltaXphdGlvbiBpcyBvbmUgb2YgdGhlIG9wZW4gaXNz dWVzICgjMTAzKSBvbiB0aGUgTEFLRSBnaXRodWIgYW5kIHlvdXIgY29tbWVudCBpcyBnb29kIGlu cHV0IHRvIHRoYXQgZGlzY3Vzc2lvbi4gVGhlIGJhY2tncm91bmQgZm9yIHRoaXMgaXMgdGhlIHJl cXVpcmVtZW50IGZvciB0aGUgTEFLRSBwcm90b2NvbCB0byBwZXJmb3JtIHdlbGwgaW4gY29uc3Ry YWluZWQgcmFkaW8gc2V0dGluZ3Mgd2l0aCBzbWFsbCBmcmFtZSBzaXplcyB3aGVyZSBwZXJmb3Jt YW5jZSBtYXkgYmUgc2lnbmlmaWNhbnRseSBkZWdyYWRlZCBieSBleGNlZWRpbmcgY2VydGFpbiBs aW1pdHMuIEZvciB0aGVzZSBzZXR0aW5ncywgZXZlcnkgYnl0ZSBjb3VudHMgYW5kIHNvbWUgYnl0 ZXMganVzdCBjYW5ub3QgYmUgYXZvaWRlZCwgbGlrZSBhIG1lc3NhZ2UgYXV0aGVudGljYXRpb24g Y29kZSBvciBhbiBlcGhlbWVyYWwgcHVibGljIGtleS4NCg0KQXNzdW1lIHRoYXQgd2UgZG8gd2Fu dCB0byBhbGxvdyBrZXkgaWRlbnRpZmllcnMgdG8gYmUgQ0JPUiBpbnRzIGluIGNlcnRhaW4gc2V0 dGluZ3MsICB3aGF0IGlzIHRoZSBiZXN0IChsZWFzdCBpbnRydXNpdmUpIHdheSB0byBhbGxvdyB0 aGlzIHdoaWxlIHN0aWxsIG1haW50YWluIGNvbXBhdGliaWxpdHkgd2l0aCAna2lkJ3Mgc3VwcG9y dGluZyB0aGUgdHlwZSBic3RyPyBBbm90aGVyIGFsdGVybmF0aXZlIHRvIHdoYXQgaGFzIGJlZW4g bGlzdGVkIGJlbG93IGlzIHRvIGRlZmluZSAna2lkMicgdG8gb25seSBiZSBvZiB0eXBlIGludCAt IGlzIHRoYXQgYSBiZXR0ZXIgb3B0aW9uPw0KDQpPdGhlciB0aG91Z2h0cz8NCg0KR8O2cmFuDQoN Cg0KRnJvbTogTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb20+DQpEYXRl OiBNb25kYXksIDkgQXVndXN0IDIwMjEgYXQgMjA6MTENClRvOiBHw7ZyYW4gU2VsYW5kZXIgPGdv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4NCkNjOiAiY29zZUBpZXRmLm9yZyIgPGNvc2VAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NPU0VdIEtleSBpZGVudGlmaWVyIG9mIHR5cGUgYnN0ciAv IGludA0KDQpBIHNtYWxsIGNvbW1lbnQgb24gY29kZSBzaXplIGFzIHRoZSBhdXRob3Igb2YgYSBj b21tZXJjaWFsLXF1YWxpdHkgQ09TRSBpbXBsZW1lbnRhdGlvbiBkZXNpZ25lZCB0byBoYXZlIHNt YWxsIGNvZGUgc2l6ZS4NCg0KVGhlcmUgaXMgYSBiaXQgb2YgYSB0cmFkZS1vZmYgYmV0d2VlbiBj b2RlIHNpemUgYW5kIGJ5dGVzIG9uIHRoZSB3aXJlLiBSZWR1Y2luZyB0aGUgYnl0ZXMgb24gdGhl IHdpcmUgYnkgb25lIGJ5dGUgaW4gdGhpcyBjYXNlIHdpbGwgbGVhZCB0byBhbiBpbmNyZWFzZSBp biBjb2RlIHNpemUgYnkgYSBsb3QgbW9yZSB0aGFuIG9uZSBieXRlLCBhc3N1bWluZyBib3RoIGlu dCBhbmQgYnN0ciBhcmUgc3VwcG9ydGVkLiBJZiBib3RoIGFyZSBub3Qgc3VwcG9ydGVkLCB0aGVu IHRoZXJlIGlzICNpZmRlZiBjb21wbGV4aXR5IGFuZCBjb25maWd1cmF0aW9uIHdvcmsgd2l0aCBn ZW5lcmFsIHB1cnBvc2UgQ09TRSBpbXBsZW1lbnRhdGlvbnMuDQoNCk1vc3Qgb2YgdGhlIGNvZGUg Y29zdCBmb3IgbWUgaW4gaW1wbGVtZW50aW5nIENPU0UgaXMgaW4gdGhlIGhlYWRlciBwYXJhbWV0 ZXIgZGVjb2RpbmcuDQoNClRoaXMgZGVzaXJlIHRvIHNhdmUgMSBDQk9SIGJ5dGUgaGVyZSBhbmQg dGhlcmUgYXQgdGhlIGNvc3Qgb2YgY29kZSAvIGNvbXBsZXhpdHkgc2hvd3MgdXAgZWxzZXdoZXJl LiBIZXJl4oCZcyBvbmUgZnJvbSBDb1NXSUQNCg0Kb25lLW9yLW1vcmU8VD4gPSBUIC8gWyAyKiBU IF0NCg0KVGhpcyBjb3VsZCBqdXN0IGJlIGFuIGFycmF5Lg0KDQpJIGRvbuKAmXQga25vdyB0aGUg dXNlIGNhc2VzLCBidXQgSeKAmW0gYSBsaXR0bGUgc2tlcHRpY2FsIHRoZXNlIHNvcnRzIG9mIHRo aW5ncyBhcmUgd29ydGggYSBieXRlIG9yIHR3byBvbiB0aGUgd2lyZS4NCg0KTEwNCg0KDQoNCg0K T24gSnVsIDMwLCAyMDIxLCBhdCA1OjI4IEFNLCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFu ZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpnb3Jhbi5zZWxhbmRlcj00 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpIaSwNCg0KSW4gTEFLRSB5 ZXN0ZXJkYXkgd2UgaGFkIGEgZGlzY3Vzc2lvbiBvbiBjb21wYWN0IGtleSBpZGVudGlmaWVycy4g VGhlIG1haW4gY2FuZGlkYXRlIHRvIHVzZSwgJ2tpZCcsIGlzIHNwZWNpZmllZCBhcyBhIENCT1Ig YnN0ciwgd2hpY2ggaXMgdHlwaWNhbGx5IGF0IGxlYXN0IDIgYnl0ZXMgKGV4Y2VwdGlvbjogZW1w dHkgYnN0ciB3aGljaCBpcyAxIGJ5dGUpLiBXZSB0aGVyZWZvcmUgd2FudCB0byBhbGxvdyBrZXlz IHRvIGJlIGlkZW50aWZpZWQgd2l0aCBDQk9SIGludHMgd2hpY2ggaGFzIDQ4IDEtYnl0ZSB2YWx1 ZXMgdG8gYWxsb3cgZm9yIGEgbGFyZ2VyIG51bWJlciBvZiBvcHRpbWFsbHkgc21hbGwgaWRlbnRp ZmllcnMuDQoNCk9uZSBzb2x1dGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgYSBuZXcgQ09TRSBrZXkg Y29tbW9uIHBhcmFtZXRlciBhbmQgQ09TRSBoZWFkZXIgcGFyYW1ldGVyLCBzYXkgJ2tpZDInLCBv ZiB0eXBlIGJzdHIgLyBpbnQuIEFub3RoZXIgc29sdXRpb24gd291bGQgYmUgdG8gZXh0ZW5kICdr aWQnIHRvIGJlIGJzdHIgLyBpbnQuDQoNCkluIHRoZSBmb3JtZXIgY2FzZSBhICdraWQyJyBjYW4g YmUgdXNlZCB0byByZWZlcmVuY2Uga2V5cyBpZGVudGlmaWVkIHdpdGggZWl0aGVyICdraWQyJyBv ciAna2lkJywgYnV0ICdraWQnIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHJlZmVyZW5jZSBrZXlzIGlk ZW50aWZpZWQgd2l0aCAna2lkMicgaGF2aW5nIGFuIGludCB2YWx1ZS4gTm90IGNsZWFyIHRvIG1l IGlmIHRoYXQgaXMgYSBwcm9ibGVtLg0KDQpXaGlsZSB0aGUgTEFLRSBXRyBkaWQgbm90IGV4cHJl c3MgYW55IHByZWZlcmVuY2UsIG9uZSBvcGluaW9uIEkgbGVhcm50IGFmdGVyIHRoZSBtZWV0aW5n IHdhcyBhIHByZWZlcmVuY2Ugb2YgZXh0ZW5kaW5nICdraWQnIHRvIGJzdHIgLyBpbnQuDQoNCldo YXQgZG8gZm9sa3MgaW4gQ09TRSB0aGluaz8NCg0KSSdtIGZhbWlsaWFyIHdpdGggdGhlIHByb2Nl c3Mgb2YgcmVnaXN0ZXJpbmcgbmV3IENPU0UgcGFyYW1ldGVycywgd2hhdCBpcyB0aGUgcmVxdWly ZW1lbnQgZm9yIGNoYW5naW5nIHRoZSB2YWx1ZSB0eXBlIG9mIGFuIGV4aXN0aW5nIHJlZ2lzdHJh dGlvbj8gU3RhbmRhcmRzIGFjdGlvbiB3aXRoIGV4cGVydCByZXZpZXc/DQoNClRoYW5rcw0KR8O2 cmFuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkNPU0UgbWFpbGluZyBsaXN0DQpDT1NFQGlldGYub3JnPG1haWx0bzpDT1NFQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== --_000_EDFDB6E42BDE4E2E9CF0D771E2DEF3C6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <59168BB5C34A2945B2A3689AFEA28D5C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLVNFIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl O2xpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBMYXVyZW5jZSwgdGhlc2UgdHJhZGUtb2ZmcyBh cmUgaW1wb3J0YW50IHRvIGNvbnNpZGVyLiBUaGUgZmluYWwgbWVzc2FnZSBvcHRpbWl6YXRpb24g aXMgb25lIG9mIHRoZSBvcGVuIGlzc3VlcyAoIzEwMykgb24gdGhlIExBS0UgZ2l0aHViIGFuZCB5 b3VyIGNvbW1lbnQgaXMgZ29vZCBpbnB1dCB0byB0aGF0DQogZGlzY3Vzc2lvbi4gVGhlIGJhY2tn cm91bmQgZm9yIHRoaXMgaXMgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUgTEFLRSBwcm90b2NvbCB0 byBwZXJmb3JtIHdlbGwgaW4gY29uc3RyYWluZWQgcmFkaW8gc2V0dGluZ3Mgd2l0aCBzbWFsbCBm cmFtZSBzaXplcyB3aGVyZSBwZXJmb3JtYW5jZSBtYXkgYmUgc2lnbmlmaWNhbnRseSBkZWdyYWRl ZCBieSBleGNlZWRpbmcgY2VydGFpbiBsaW1pdHMuIEZvciB0aGVzZSBzZXR0aW5ncywgZXZlcnkg Ynl0ZSBjb3VudHMNCiBhbmQgc29tZSBieXRlcyBqdXN0IGNhbm5vdCBiZSBhdm9pZGVkLCBsaWtl IGEgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlIG9yIGFuIGVwaGVtZXJhbCBwdWJsaWMga2V5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFzc3VtZSB0aGF0IHdlIGRvIHdhbnQg dG8gYWxsb3cga2V5IGlkZW50aWZpZXJzIHRvIGJlIENCT1IgaW50cyBpbiBjZXJ0YWluIHNldHRp bmdzLCAmbmJzcDt3aGF0IGlzIHRoZSBiZXN0IChsZWFzdCBpbnRydXNpdmUpIHdheSB0byBhbGxv dyB0aGlzIHdoaWxlIHN0aWxsIG1haW50YWluIGNvbXBhdGliaWxpdHkgd2l0aCAna2lkJ3MNCiBz dXBwb3J0aW5nIHRoZSB0eXBlIGJzdHI/IEFub3RoZXIgYWx0ZXJuYXRpdmUgdG8gd2hhdCBoYXMg YmVlbiBsaXN0ZWQgYmVsb3cgaXMgdG8gZGVmaW5lICdraWQyJyB0byBvbmx5IGJlIG9mIHR5cGUg aW50IC0gaXMgdGhhdCBhIGJldHRlciBvcHRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+T3RoZXIgdGhvdWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R8O2 cmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TGF1cmVuY2UgTHVuZGJsYWRlICZs dDtsZ2xAaXNsYW5kLXJlc29ydC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgOSBB dWd1c3QgMjAyMSBhdCAyMDoxMTxicj4NCjxiPlRvOiA8L2I+R8O2cmFuIFNlbGFuZGVyICZsdDtn b3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtjb3Nl QGlldGYub3JnJnF1b3Q7ICZsdDtjb3NlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW0NPU0VdIEtleSBpZGVudGlmaWVyIG9mIHR5cGUgYnN0ciAvIGludDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNtYWxsIGNvbW1l bnQgb24gY29kZSBzaXplIGFzIHRoZSBhdXRob3Igb2YgYSBjb21tZXJjaWFsLXF1YWxpdHkgQ09T RSBpbXBsZW1lbnRhdGlvbiBkZXNpZ25lZCB0byBoYXZlIHNtYWxsIGNvZGUgc2l6ZS48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGEgYml0IG9m IGEgdHJhZGUtb2ZmIGJldHdlZW4gY29kZSBzaXplIGFuZCBieXRlcyBvbiB0aGUgd2lyZS4gUmVk dWNpbmcgdGhlIGJ5dGVzIG9uIHRoZSB3aXJlIGJ5IG9uZSBieXRlIGluIHRoaXMgY2FzZSB3aWxs IGxlYWQgdG8gYW4gaW5jcmVhc2UgaW4gY29kZSBzaXplIGJ5IGEgbG90IG1vcmUgdGhhbiBvbmUg Ynl0ZSwgYXNzdW1pbmcgYm90aCBpbnQgYW5kIGJzdHIgYXJlIHN1cHBvcnRlZC4NCiBJZiBib3Ro IGFyZSBub3Qgc3VwcG9ydGVkLCB0aGVuIHRoZXJlIGlzICNpZmRlZiBjb21wbGV4aXR5IGFuZCBj b25maWd1cmF0aW9uIHdvcmsgd2l0aCBnZW5lcmFsIHB1cnBvc2UgQ09TRSBpbXBsZW1lbnRhdGlv bnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1vc3Qgb2YgdGhlIGNvZGUgY29zdCBmb3IgbWUgaW4gaW1wbGVtZW50aW5nIENPU0UgaXMgaW4g dGhlIGhlYWRlciBwYXJhbWV0ZXIgZGVjb2RpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZGVzaXJlIHRvIHNhdmUgMSBDQk9SIGJ5 dGUgaGVyZSBhbmQgdGhlcmUgYXQgdGhlIGNvc3Qgb2YgY29kZSAvIGNvbXBsZXhpdHkgc2hvd3Mg dXAgZWxzZXdoZXJlLiBIZXJl4oCZcyBvbmUgZnJvbSBDb1NXSUQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3Jk ZXI6c29saWQgI0VFRUVFRSAxLjBwdDtwYWRkaW5nOjEyLjBwdCAxMi4wcHQgMTIuMHB0IDEyLjBw dDtiYWNrZ3JvdW5kOiNGOUY5RjkiPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDouNHB0O2JhY2tn cm91bmQ6I0Y5RjlGOTtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbTtvdmVyZmxvdy14OiBhdXRvO21h eC13aWR0aDpjYWxjKDEwMCUgLSAyMnB4KTticmVhay1iZWZvcmU6IGF2b2lkLXBhZ2U7YnJlYWst YWZ0ZXI6IGF1dG87Y2FyZXQtY29sb3I6IHJnYigzNCwgMzQsIDM0KSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMyMjIyMjIiPm9uZS1vci1tb3JlJmx0O1QmZ3Q7ID0gVCAvIFsgMiogVCBdPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBjb3VsZCBqdXN0IGJlIGFuIGFycmF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQga25vdyB0aGUgdXNlIGNh c2VzLCBidXQgSeKAmW0gYSBsaXR0bGUgc2tlcHRpY2FsIHRoZXNlIHNvcnRzIG9mIHRoaW5ncyBh cmUgd29ydGggYSBieXRlIG9yIHR3byBvbiB0aGUgd2lyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TEw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMzAsIDIw MjEsIGF0IDU6MjggQU0sIEfDtnJhbiBTZWxhbmRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcmFu LnNlbGFuZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIj5nb3Jhbi5zZWxhbmRlcj00 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0KSW4gTEFLRSB5 ZXN0ZXJkYXkgd2UgaGFkIGEgZGlzY3Vzc2lvbiBvbiBjb21wYWN0IGtleSBpZGVudGlmaWVycy4g VGhlIG1haW4gY2FuZGlkYXRlIHRvIHVzZSwgJ2tpZCcsIGlzIHNwZWNpZmllZCBhcyBhIENCT1Ig YnN0ciwgd2hpY2ggaXMgdHlwaWNhbGx5IGF0IGxlYXN0IDIgYnl0ZXMgKGV4Y2VwdGlvbjogZW1w dHkgYnN0ciB3aGljaCBpcyAxIGJ5dGUpLiBXZSB0aGVyZWZvcmUgd2FudCB0byBhbGxvdyBrZXlz IHRvIGJlIGlkZW50aWZpZWQgd2l0aA0KIENCT1IgaW50cyB3aGljaCBoYXMgNDggMS1ieXRlIHZh bHVlcyB0byBhbGxvdyBmb3IgYSBsYXJnZXIgbnVtYmVyIG9mIG9wdGltYWxseSBzbWFsbCBpZGVu dGlmaWVycy48YnI+DQo8YnI+DQpPbmUgc29sdXRpb24gd291bGQgYmUgdG8gZGVmaW5lIGEgbmV3 IENPU0Uga2V5IGNvbW1vbiBwYXJhbWV0ZXIgYW5kIENPU0UgaGVhZGVyIHBhcmFtZXRlciwgc2F5 ICdraWQyJywgb2YgdHlwZSBic3RyIC8gaW50LiBBbm90aGVyIHNvbHV0aW9uIHdvdWxkIGJlIHRv IGV4dGVuZCAna2lkJyB0byBiZSBic3RyIC8gaW50Ljxicj4NCjxicj4NCkluIHRoZSBmb3JtZXIg Y2FzZSBhICdraWQyJyBjYW4gYmUgdXNlZCB0byByZWZlcmVuY2Uga2V5cyBpZGVudGlmaWVkIHdp dGggZWl0aGVyICdraWQyJyBvciAna2lkJywgYnV0ICdraWQnIHdvdWxkIG5vdCBiZSBhYmxlIHRv IHJlZmVyZW5jZSBrZXlzIGlkZW50aWZpZWQgd2l0aCAna2lkMicgaGF2aW5nIGFuIGludCB2YWx1 ZS4gTm90IGNsZWFyIHRvIG1lIGlmIHRoYXQgaXMgYSBwcm9ibGVtLg0KPGJyPg0KPGJyPg0KV2hp bGUgdGhlIExBS0UgV0cgZGlkIG5vdCBleHByZXNzIGFueSBwcmVmZXJlbmNlLCBvbmUgb3Bpbmlv biBJIGxlYXJudCBhZnRlciB0aGUgbWVldGluZyB3YXMgYSBwcmVmZXJlbmNlIG9mIGV4dGVuZGlu ZyAna2lkJyB0byBic3RyIC8gaW50Ljxicj4NCjxicj4NCldoYXQgZG8gZm9sa3MgaW4gQ09TRSB0 aGluaz88YnI+DQo8YnI+DQpJJ20gZmFtaWxpYXIgd2l0aCB0aGUgcHJvY2VzcyBvZiByZWdpc3Rl cmluZyBuZXcgQ09TRSBwYXJhbWV0ZXJzLCB3aGF0IGlzIHRoZSByZXF1aXJlbWVudCBmb3IgY2hh bmdpbmcgdGhlIHZhbHVlIHR5cGUgb2YgYW4gZXhpc3RpbmcgcmVnaXN0cmF0aW9uPyBTdGFuZGFy ZHMgYWN0aW9uIHdpdGggZXhwZXJ0IHJldmlldz88YnI+DQo8YnI+DQpUaGFua3M8YnI+DQpHw7Zy YW48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCkNPU0UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNP U0VAaWV0Zi5vcmciPkNPU0VAaWV0Zi5vcmc8L2E+PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3NlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EDFDB6E42BDE4E2E9CF0D771E2DEF3C6ericssoncom_-- From nobody Tue Aug 10 03:35:38 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838733A0DB6 for ; Tue, 10 Aug 2021 03:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 UdkJaoy24LLe for ; Tue, 10 Aug 2021 03:35:30 -0700 (PDT) Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.142.165]) (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 93C9C3A0DBF for ; Tue, 10 Aug 2021 03:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1628591730; x=1629196530; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zGCDd7l962U+RLXaJMRSl8s7KHIc9Fio1Tnb18fPX3c=; b=b+0YjaLv+Z2kEGXI/5XAsfJ0E1Tk96iQFYQZoAo6xvxiZ4sQ2kXEFHq6 iYjiBUYu5sHhRX2k7if4Cnr56zx1G8ucBkiKXU8bGxHhbhB95mG4rSEuH M+6te4EX0RiB2o/bEE0teZUl9GQHHBFeiAFR8535fsYRdQrmAVgC6jz9d g=; Received: from mail-bn1nam07lp2044.outbound.protection.outlook.com (HELO NAM02-BN1-obe.outbound.protection.outlook.com) ([104.47.51.44]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 10:35:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=APt97kfM8o/r9n1J1CLVZ/V0iE5dzJwvy74nlQZ31YB9mTUfDvldx0HWmPQJXVm2WllLnbIK8lJ6XNgpydmQUxTjwXEibwxBlKvyy/DTg/3ITbt848O10CPNJji1eKCjNmyr1Sq3YL+8KPgbWPpuce5ydMZj3DDpqRgmc8cOwHOAQgMQ4JebgGP8wEItfh7o/nDx+PBexPwNTdt3RdW3iDcEazTpHy2EihrL9feiP6uNF2zUVayDWaBLf4hL5wr906PaCvnSLYBstiqJTXLUv2GgVO8FpteN/FZYhCWTCbUoW8xAWNm5Oyh1s1KiUPYF1gW6tA0ykEjTwz/x1n7dQA== 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=zqwm89lk1+DYjIXBhKKjDKg5sMTzc/UVwsYMV3/aIfE=; b=eHCKqYNc2hFEafcydcysHHovo09zJrEnhKJPVn0+YSKJNH0G9RJZF5u7+PMMxoeF4EvlZ61ijCFhIbAxdeKKlczR7BDyVF55eHkAGEy7q3gnWIkR7+RD/+WY9h7+TPSxclRBZe8JQ3JL6oCn66jcVMwYGoo0ZPd2/b+IGQOvaHQsMawP6HMh2Fcn6Bxf67CssZxyJUsV17gKDK43i6/GH+WgGFV1q5Wp8hvMTklUXmaLCbtpK+noElxJd4PEandls61Z/JAcRDlar8WE7IuPRlFIk0aHkBAcfJAyzhRLwFPSTMj9pHS4LklENMDxDw5nj2d4iRBgyR+HqTVZtAMJYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from SA1PR02MB8349.namprd02.prod.outlook.com (2603:10b6:806:1e4::19) by SA2PR02MB7673.namprd02.prod.outlook.com (2603:10b6:806:143::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Tue, 10 Aug 2021 10:35:26 +0000 Received: from SA1PR02MB8349.namprd02.prod.outlook.com ([fe80::b0de:4d7f:8026:700e]) by SA1PR02MB8349.namprd02.prod.outlook.com ([fe80::b0de:4d7f:8026:700e%9]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 10:35:26 +0000 From: Jeremy O'Donoghue To: Laurence Lundblade , Michael Richardson CC: Carsten Bormann , AJITOMI Daisuke , "cose@ietf.org" Thread-Topic: [COSE] tstr values for kty, alg, crv, etc. Thread-Index: AQHXinNJ0EA1kX2PHkyA9AVXlK/fr6tl6gmAgALHMQCAAJRSAIAAPC8AgAIXGYCAAAqKgIAA4LEi Date: Tue, 10 Aug 2021 10:35:26 +0000 Message-ID: References: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> <10529.1628538225@localhost>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=qti.qualcomm.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7b8a4fbf-5935-4d7d-2f58-08d95bea9115 x-ms-traffictypediagnostic: SA2PR02MB7673: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rkqoaUYXmhaYvaQP0Wlp8AYRX1CKtlN7RMB4s08DL0AEMS+2khG3v9Mk6IEH5ByumYc+Vmw0fQAY3ji4u2S3qnXDa5PbX4I2eUXMU1Awm8kKwYUzbF7M+IN0z9MjHBhPCtGhCmBohDqiFROj0O+Y4Fgz3bESnZ+ce2kUFGunKGC5wI2LW8+akpXgO+/8LKDXvWZDY9vkkvy4kijC4SDBUgO/KTj+bXGzR9jDZHoCvHB8VSC1jPdYTXZblCVLHr492++nB/wgZIIu2dvcPilvKyvxBOp7IEO8QJSqcS/jUUkmNcRWurRKKIshha9qJ3q4tgYmAImZweHmgrT4PX1NNdKJlmkBD/EBo7vBAg2CT6HZd6FGMYN4sOedXxFtOMweJ6ZnMdzsJZbY5pkv910f39+JJG1IFy1UU/7PvvzIGwWRDz1nIE2mm1Om9920PZeSw6x3cvNbeQ59iduHpQSz+/27ARW007gLXQ1j+NoH768LJTuA+wCvGU1USMFXIvStTg8pe8UTzQQqjNlMZg7N3lEy2wCvLed+rBnZKmjKZAZCgh1YxcJBZV/pgVWJhI3zofsQDMx1eXxRxLpwPOjhG33K4Yag3oZaHZp7dfkMgOHg4JqdRRSeIJEQUuviavuAiDzvThzx5JxWbZzPaIyxJy3IbA1Oo+YJq8YqRMT43Xw6RI3jriPlss8Wlx/hqBBl7pImDfBsa3a15QlZIjX5JQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR02MB8349.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(66446008)(66556008)(64756008)(66476007)(91956017)(76116006)(66946007)(9686003)(478600001)(55016002)(2906002)(71200400001)(33656002)(4326008)(86362001)(38070700005)(5660300002)(6506007)(53546011)(8676002)(316002)(8936002)(110136005)(7696005)(54906003)(122000001)(38100700002)(52536014)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?3SEzBiyqN6H+TDs9BRf+ndOu6tb6UsCzIJ2WxmR7q2xpSiL9NJkrdO95?= =?Windows-1252?Q?93BdOGDZhHI21Rtn56zMYrHj9Eyo2zEmrjNanr9aaUUEaSAW4TfwQ9/R?= =?Windows-1252?Q?af2ngByxrvbjpRK4AIEG8ygh3u6VYg31zPbSJY8xwcOpb3oNhQGS1D4+?= =?Windows-1252?Q?sgzbk63dwF5F60LYAksvVw7sIvLU8urNBEc8v0uvOBk6rKI9iuujfRLz?= =?Windows-1252?Q?DnjEAAh9CMHgoxMEx3hIus+w6azMn8htoWHCodEU/O1Jcm1x0FXtgZqE?= =?Windows-1252?Q?/59EtHw3jrS9c877Trj7OAJiOkiIyZT8tAXCiaY+JO30LA7m3gjnGuhp?= =?Windows-1252?Q?r9gt9ANdXlqKo3jZ0Ae33Zny+Tf/CqsssPLaKhNlTtZYgRmu8NTHYngw?= =?Windows-1252?Q?MEIS60Xcc3cG69iFqjSNPBQJ/gydepThHBN61IduEt6Ae/YgQdfZXGFK?= =?Windows-1252?Q?EBVaO85u6yvhfmCWwZsxVCgv8R9l0F4t2S2NcEkHM7pxHMDW5KhoQgq9?= =?Windows-1252?Q?+dF+x87dzZzwBI7x6jhiSa01Fq1MKX0xr+ze0zZwBM7fFNRpJLDtzDe6?= =?Windows-1252?Q?Uvo0wb7kHmdxqRIk1foeB5WMSvJzFF1YHGdENOjfKHZJwDRc1g4LvKr/?= =?Windows-1252?Q?CkRxkKpzXoaUCxfg1mnLya4qcKhr7vscDYNSC94X+c7DbwjiFdGUkO0B?= =?Windows-1252?Q?kN+P/s3z3lA4SgmLrdmmT7bLtH56LrCxvjVyupqCJ3E/BYJDFf6+J69w?= =?Windows-1252?Q?Q54eO559fcqaC6p9vo456vdOuqQqzwwBU8GIqZHF6NUSPqvKqXwjs5uq?= =?Windows-1252?Q?lCSolpldx19KxBTa1LQhIx3Nnf80RzuVm+PwKuYB1aa6vEUDWMButi37?= =?Windows-1252?Q?JsKX8EJFQyO8z1PQZt5fxvEGg7YYX8lHV4GBnldeUmJi92OW4cLt+9lV?= =?Windows-1252?Q?LkISFbXf7r4snkCFBCUEGvqFuBoKHHX5LXPOKDdZoVWetf+HZx51F5iZ?= =?Windows-1252?Q?4FTk0aNdSny/hRPYD/dTI+VQ/Bkfe2TalVz/G9+tjt5xZEbC4QEUg4ct?= =?Windows-1252?Q?Zwcl0vSV0JbyEViMjt/HMT1vXyk1vp0EphFyWQUhGGnz0kujqKw8mEbU?= =?Windows-1252?Q?9MK8wD3jnjy4cuIliVeztg46TezKKI8O1LvQKxibd3WkCr3zVrxjfuXz?= =?Windows-1252?Q?V3dAlR2nbw42PBELjcrU3M83jsvzZBeuFrFMSce9NdHThdlHKM1m7dTO?= =?Windows-1252?Q?8CWJt5mr9axzwPg6BgNTFiPtl5BflS+bNn1+lvE3PrSCqLGXOZJ9dD7P?= =?Windows-1252?Q?U1VKj+1+wH0L9bOUjsPQk7rSLNZSjvdGemjQND+ycyDE7IoInmZIhGLA?= =?Windows-1252?Q?zWplYBNFzJK4SKwkBJvQxp7ZNTSaqRkIpQ3weMfVXUCwaVLxlQCPjsAt?= =?Windows-1252?Q?oJEoNsaP+tsb4eqpNuYNqfWfhACVI1UYvTa22FO+OP5kcCsd/8A8nzIk?= =?Windows-1252?Q?Ydvc65QcF8ytofcNJmz0R0uFlC8JBg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA1PR02MB83499E7A77BA35BC28D8DC53F2F79SA1PR02MB8349namp_" MIME-Version: 1.0 X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR02MB8349.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b8a4fbf-5935-4d7d-2f58-08d95bea9115 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 10:35:26.2502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: d0ZQrUNhdWRulJLOzo4JlLRKMRnCOSWZ+s9EM/qsf32WinWDeMk4H5nNqWL9cvWRGiFLysDLFLkDVZdfv2OhSRfVwiGr1u0YphYuHkVjShA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR02MB7673 Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 10:35:37 -0000 --_000_SA1PR02MB83499E7A77BA35BC28D8DC53F2F79SA1PR02MB8349namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 09/08/2021, 21:21, "Laurence Lundblade" wrote: On Aug 9, 2021, at 12:43 PM, Michael Richardson > wrote: Carsten Bormann > wrote: This discussion is all a bit short sighted to me. Sure, we can advise against registering text labels now. But COSE has a long life with many applications before it, some of which may be outside what you are thinking about now. What=92s the rush on disabling these? I understood that some people think that we can encode the map key for 'kty= ' as both 'kty' and also 1. (section 7 of RFC8152) [ditto alg and I think key_ops] I'm not convinced the document says that. [JOD] The document does not say that, but it requires careful reading to re= alise that this is not so. I can certainly say that *I* made an error in my effort to implement a COSE= library, and I am reasonably experienced in reading and interpreting stand= ards text, so I believe it is an error others might make. The error was not= =93encode the map key as =93kty=94 and also 1. That is completely clear fr= om the CDDL. It was that it was not apparent without careful reading that t= he =93Name=94 column in (for example) COSE Algorithms is descriptive only a= nd the =93value=94 column is the one containing allowed normative values. I am prepared to accept that a reasonable outcome here is that =93people sh= ould read the standards more carefully=94, or even that =93Jeremy should re= ad standards more carefully=94. It does seem that we are too late in docume= nt publishing process to do anything about this. Agreed. The CDDL allows only 1, 2, 3,...for the params defined in COSE, but allows = tstr for future params. label =3D int / tstr COSE_Key =3D { 1 =3D> tstr / int, ; kty ? 2 =3D> bstr, ; kid ? 3 =3D> tstr / int, ; alg ? 4 =3D> [+ (tstr / int) ], ; key_ops ? 5 =3D> bstr, ; Base IV * label =3D> values } Essentially, I think anyone trying to register tstr COSE identifier or labe= l should be asked if they really want to do that, is it really necessary to= use a tstr instead of an int: Are you just doing it because you are used = to JSON? You know that most implementations don=92t support tstr, right? Also, to be clear, you don't register both a tstr and an int for a particul= ar item. There are two ways of doing this, but not for an individual item. = Having tstr =91foo=92 and int 42 both referring to the same item would actu= ally require two registrations and would be the worst thing to do. [JOD] Document doesn=92t state that you do not register both a tstr and an = int value. I do agree that you should not. Perhaps a good way forward is Expert Review (whether with Standards Action = or not) does not approve tstr values unless there is a very compelling reas= on why use of an integer is unreasonable or impossible. This, as I understa= nd things, does not require any specification change, since it looks to be = exactly within the scope of the existing Expert Review instructions. Best regards Jeremy --_000_SA1PR02MB83499E7A77BA35BC28D8DC53F2F79SA1PR02MB8349namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On 09/08/2021, 21:21, &= quot;Laurence Lundblade" <lgl@island-resort.com> wrote:

On Aug 9, 2021, at 12:4= 3 PM, Michael Richardson <mcr+i= etf@sandelman.ca> wrote:

 


Carsten Bormann <cabo@tzi.org> wr= ote:

This discussion is all = a bit short sighted to me. Sure, we can advise
against registering text labels now. But COSE has a long life with many
applications before it, some of which may be outside what you are
thinking about now. What=92s the rush on disabling these?


I understood that some people think that we can encode the map key for 'kty= '
as both 'kty' and also 1.

(section 7 of RFC8152)
[ditto alg and I think key_ops]

I'm not convinced the document says that.

 

[JOD] The document does not say that, but it require= s careful reading to realise that this is not so.

 

I can certainly say that *I* made an error in= my effort to implement a COSE library, and I am reasonably experienced in = reading and interpreting standards text, so I believe it is an error others= might make. The error was not =93encode the map key as =93kty=94 and also 1. That is completely clear from the CDD= L. It was that it was not apparent without careful reading that the =93Name= =94 column in (for example) COSE Algorithms is descriptive only and the =93= value=94 column is the one containing allowed normative values.

 

I am prepared to accept that a reasonable outcome he= re is that =93people should read the standards more carefully=94, or even t= hat =93Jeremy should read standards more carefully=94. It does seem that we= are too late in document publishing process to do anything about this.

 

Agreed.

 

The CDDL allows only 1,= 2, 3,...for the params defined in COSE, but allows tstr for future params.=

 

 

   label =3D=
 int / tstr

 

 

   COSE_Key =
=3D {
       1 =
=3D> tstr / int,          ;=
 kty
       ? 2 =
=3D> bstr,          &n=
bsp;   ; kid
       ? 3 =
=3D> tstr / int,        ; alg
       ? 4 =
=3D> [+ (tstr / int) ], ; key_ops
       ? 5 =
=3D> bstr,          &n=
bsp;   ; Base IV
       * la=
bel =3D> values
   }

 

Essentially, I think an= yone trying to register tstr COSE identifier or label should be asked if th= ey really want to do that, is it really necessary to use a tstr instead of = an int:  Are you just doing it because you are used to JSON? You know that most implementations don=92t support t= str, right?

 

Also, to be clear, you = don't register both a tstr and an int for a particular item. There are two = ways of doing this, but not for an individual item. Having tstr =91foo=92 a= nd int 42 both referring to the same item would actually require two registrations and would be the worst thing to d= o.

 

[JOD] Document doesn=92t state that you do not regis= ter both a tstr and an int value. I do agree that you should not.

 

Perhaps a good way forward is Expert Review (whether= with Standards Action or not) does not approve tstr values unless there is= a very compelling reason why use of an integer is unreasonable or impossib= le. This, as I understand things, does not require any specification change, since it looks to be exactly wi= thin the scope of the existing Expert Review instructions.

 

Best regards

Jeremy

 

--_000_SA1PR02MB83499E7A77BA35BC28D8DC53F2F79SA1PR02MB8349namp_-- From nobody Tue Aug 10 07:46:57 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888303A0E2D for ; Tue, 10 Aug 2021 07:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ip3GodhZf1qD for ; Tue, 10 Aug 2021 07:46:39 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46103A0E09 for ; Tue, 10 Aug 2021 07:46:39 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id i7so26338390iow.1 for ; Tue, 10 Aug 2021 07:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yblDNKP1P7Ojnl145ylPlP3geISRPWHFW+P+R06iwyU=; b=Ux4Q+PJOpJq3mClhWa/xU8yO6kNMN8yJz3k5a8NbiR4NLLO4qI0nAXiPOyXee3Fkms 6KRXfSgkjvbZlcySSvtUpNtMO+Z7mKzrJL8fCNq0+W5CD90N3f3AxsKF5mYQI4n/LWqj k1k8OSUcm5nS4uaM6Hg/JrdZ5IMUyoxeiPY4uzmu/r15LXhEGu+oZRr1UmpQCIVrpoXf GOcN+2qgvQ9jbb6BUUfKIDdWgeP2Po4iWX0YG0tJef3k/lrQ1lsue9dlkKr1+c4D8C6a 4irVVsP8EgKVFB7NyhuvTEr5JCuJCWkYubIUfvQQ1SCSno23N85Dvly+lGAJkbbK6PB5 KrfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yblDNKP1P7Ojnl145ylPlP3geISRPWHFW+P+R06iwyU=; b=XP+2Vb00eayCXFFi9Hft3Bp3ucOYCWs8spcNB3mU1FdJcMenCeDuHOWqyp2yleA8qk z1+a6FiKjG1h6x03Qoe6iYLKCxwrAVslpY7nOw4j52itVM4lvoTc4NTy8tpjNSkcscB7 ruuigzC2GBKPJCaWVyxLVybxadQKRdtS0n0K4Weyzv7fH+WfMOOk86Zhus1IIBy+0goz p5NVAEa3K8Xf8y2ayCXLNB0qRFfRF0e4viJdmF3la8Vot+MldLQkwealrTSRF5hmzIxN yniqBbbh9k1E9B2Ska2YbjJQetdVW6BA+j8gqzazrcSUOkhk2ddOg+zB89V794Xg12X5 oo9A== X-Gm-Message-State: AOAM531rEwzbkmtpDChdWJz3jkz7AD+oakj3HJKjgVjwWA1VjOPWRpX2 yYpH9WYO2runlsBPqRVY9fU+Gf41DzuCE3WtqQ== X-Google-Smtp-Source: ABdhPJw5TTlV4iAxFDS/99DAYJ8QbPN/WF4EuK7Cmk1d3VwWqOcSsuO68CBQs5qVuU5tWtR6dZf3eq3A74GyX8u4/KY= X-Received: by 2002:a02:a409:: with SMTP id c9mr1398584jal.138.1628606797714; Tue, 10 Aug 2021 07:46:37 -0700 (PDT) MIME-Version: 1.0 References: <78EB5028-71BD-4034-A9B3-340E206F1F90@tzi.org> <10529.1628538225@localhost> In-Reply-To: From: AJITOMI Daisuke Date: Tue, 10 Aug 2021 23:46:25 +0900 Message-ID: To: "Jeremy O'Donoghue" Cc: Laurence Lundblade , Michael Richardson , Carsten Bormann , "cose@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a81a4c05c93591b9" Archived-At: Subject: Re: [COSE] tstr values for kty, alg, crv, etc. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 14:46:56 -0000 --000000000000a81a4c05c93591b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I understood that some people think that we can encode the map key for 'kty' > as both 'kty' and also 1. Perhaps my description has been misleading but, at least for me, it was very clear that we could NOT encode the map key as 'kty' and also 1 because the CDDL says that (as Jeremy mentioned). > It was that it was not apparent without careful reading that the =E2=80= =9CName=E2=80=9D column in (for example) COSE Algorithms is descriptive only and the =E2=80= =9Cvalue=E2=80=9D column is the one containing allowed normative values. Same as Jeremy, this is the point where I misunderstood. I think the problem is that the CDDL says "int | tstr", but any description of tstr is not included in RFC8152. > label =3D int / tstr I did not mention this issue in this thread so far but it is also one of the issues I wanted to address. As well as tstr values for kty, alg, crv, and key_ops, I think there is no need to use the tstr label. Regards, Daisuke 2021=E5=B9=B48=E6=9C=8810=E6=97=A5(=E7=81=AB) 19:35 Jeremy O'Donoghue : > On 09/08/2021, 21:21, "Laurence Lundblade" wrote: > > On Aug 9, 2021, at 12:43 PM, Michael Richardson > wrote: > > > > > Carsten Bormann wrote: > > This discussion is all a bit short sighted to me. Sure, we can advise > against registering text labels now. But COSE has a long life with many > applications before it, some of which may be outside what you are > thinking about now. What=E2=80=99s the rush on disabling these? > > > I understood that some people think that we can encode the map key for > 'kty' > as both 'kty' and also 1. > > (section 7 of RFC8152) > [ditto alg and I think key_ops] > > I'm not convinced the document says that. > > > > [JOD] The document does not say that, but it requires careful reading to > realise that this is not so. > > > > I can certainly say that **I** made an error in my effort to implement a > COSE library, and I am reasonably experienced in reading and interpreting > standards text, so I believe it is an error others might make. The error > was not =E2=80=9Cencode the map key as =E2=80=9Ckty=E2=80=9D and also 1. = That is completely clear > from the CDDL. It was that it was not apparent without careful reading th= at > the =E2=80=9CName=E2=80=9D column in (for example) COSE Algorithms is des= criptive only and > the =E2=80=9Cvalue=E2=80=9D column is the one containing allowed normativ= e values. > > > > I am prepared to accept that a reasonable outcome here is that =E2=80=9Cp= eople > should read the standards more carefully=E2=80=9D, or even that =E2=80=9C= Jeremy should read > standards more carefully=E2=80=9D. It does seem that we are too late in d= ocument > publishing process to do anything about this. > > > > Agreed. > > > > The CDDL allows only 1, 2, 3,...for the params defined in COSE, but allow= s > tstr for future params. > > > > > > label =3D int / tstr > > > > > > COSE_Key =3D { > > 1 =3D> tstr / int, ; kty > > ? 2 =3D> bstr, ; kid > > ? 3 =3D> tstr / int, ; alg > > ? 4 =3D> [+ (tstr / int) ], ; key_ops > > ? 5 =3D> bstr, ; Base IV > > * label =3D> values > > } > > > > Essentially, I think anyone trying to register tstr COSE identifier or > label should be asked if they really want to do that, is it really > necessary to use a tstr instead of an int: Are you just doing it because > you are used to JSON? You know that most implementations don=E2=80=99t su= pport > tstr, right? > > > > Also, to be clear, you don't register both a tstr and an int for a > particular item. There are two ways of doing this, but not for an > individual item. Having tstr =E2=80=98foo=E2=80=99 and int 42 both referr= ing to the same > item would actually require two registrations and would be the worst thin= g > to do. > > > > [JOD] Document doesn=E2=80=99t state that you do not register both a tstr= and an > int value. I do agree that you should not. > > > > Perhaps a good way forward is Expert Review (whether with Standards Actio= n > or not) does not approve tstr values unless there is a very compelling > reason why use of an integer is unreasonable or impossible. This, as I > understand things, does not require any specification change, since it > looks to be exactly within the scope of the existing Expert Review > instructions. > > > > Best regards > > Jeremy > > > --000000000000a81a4c05c93591b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I understood that some people think = that we can encode the map key for 'kty'
> as both 'kty&#= 39; and also 1.

Perhaps my description has bee= n misleading but, at least for me,=C2=A0it was very clear that we could NOT= encode the map key as 'kty' and also 1 because the CDDL says that = (as Jeremy mentioned).

> It was that it was= not apparent without careful reading that the =E2=80=9CName=E2=80=9D colum= n in (for example) COSE Algorithms is descriptive only and the =E2=80=9Cval= ue=E2=80=9D column is the one containing allowed normative values.

Same as Jeremy, this is the point where I misunderstoo= d. I think the problem is that the CDDL says "int | tstr", but an= y description of tstr is not included in RFC8152.

<= div>>=C2=A0 label =3D int / tstr
I did not mention this issue in this= thread so far but it is also one of the issues I wanted to address. As wel= l as tstr values for kty, alg, crv, and key_ops, I think there is no need t= o use the tstr label.

Regards,
Daisuke


2021=E5=B9=B48=E6=9C=8810=E6=97=A5(=E7=81=AB) 19:35 = Jeremy O'Donoghue <jodo= nogh@qti.qualcomm.com>:

On 09/08/2021, 21:21, &qu= ot;Laurence Lundblade" <lgl@island-resort.com> wrote:

On Aug 9, 2021, at 12:43 = PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

=C2=A0


Carsten Bormann <cabo@= tzi.org> wrote:

This discussion is all a = bit short sighted to me. Sure, we can advise
against registering text labels now. But COSE has a long life with many
applications before it, some of which may be outside what you are
thinking about now. What=E2=80=99s the rush on disabling these?


I understood that some people think that we can encode the map key for '= ;kty'
as both 'kty' and also 1.

(section 7 of RFC8152)
[ditto alg and I think key_ops]

I'm not convinced the document says that.

=C2=A0

[JOD] The document does not say that, but it require= s careful reading to realise that this is not so.

=C2=A0

I can certainly say that *I* made an error in= my effort to implement a COSE library, and I am reasonably experienced in = reading and interpreting standards text, so I believe it is an error others= might make. The error was not =E2=80=9Cencode the map key as =E2=80=9Ckty=E2=80=9D and also 1. That is completely clear = from the CDDL. It was that it was not apparent without careful reading that= the =E2=80=9CName=E2=80=9D column in (for example) COSE Algorithms is desc= riptive only and the =E2=80=9Cvalue=E2=80=9D column is the one containing a= llowed normative values.

=C2=A0

I am prepared to accept that a reasonable outcome he= re is that =E2=80=9Cpeople should read the standards more carefully=E2=80= =9D, or even that =E2=80=9CJeremy should read standards more carefully=E2= =80=9D. It does seem that we are too late in document publishing process to do anything about this.

=C2=A0

Agreed.

=C2=A0

The CDDL allows only 1, 2= , 3,...for the params defined in COSE, but allows tstr for future params.

=C2=A0

=C2=A0

=C2=A0=C2=A0 label =3D in=
t / tstr

=C2=A0

=C2=A0

=C2=A0=C2=A0 COSE_Key =3D=
 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 =3D&=
gt; tstr / int,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; kty=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ? 2 =
=3D> bstr,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 ; kid
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ? 3 =
=3D> tstr / int,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; alg<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ? 4 =
=3D> [+ (tstr / int) ], ; key_ops
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ? 5 =
=3D> bstr,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 ; Base IV
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * labe=
l =3D> values
=C2=A0=C2=A0 }

=C2=A0

Essentially, I think anyo= ne trying to register tstr COSE identifier or label should be asked if they= really want to do that, is it really necessary to use a tstr instead of an= int: =C2=A0Are you just doing it because you are used to JSON? You know that most implementations don=E2=80=99t sup= port tstr, right?

=C2=A0

Also, to be clear, you do= n't register both a tstr and an int for a particular item. There are tw= o ways of doing this, but not for an individual item. Having tstr =E2=80=98= foo=E2=80=99 and int 42 both referring to the same item would actually require two registrations and would be the worst thing to d= o.

=C2=A0

[JOD] Document doesn=E2=80=99t state that you do not= register both a tstr and an int value. I do agree that you should not.<= /u>

=C2=A0

Perhaps a good way forward is Expert Review (whether= with Standards Action or not) does not approve tstr values unless there is= a very compelling reason why use of an integer is unreasonable or impossib= le. This, as I understand things, does not require any specification change, since it looks to be exactly wi= thin the scope of the existing Expert Review instructions.

=C2=A0

Best regards

Jeremy

=C2=A0

--000000000000a81a4c05c93591b9-- From nobody Thu Aug 12 17:00:34 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6F3A0E15; Thu, 12 Aug 2021 17:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 41XSrhSNyR_U; Thu, 12 Aug 2021 17:00:26 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A07693A0E14; Thu, 12 Aug 2021 17:00:26 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17D00JaM000632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Aug 2021 20:00:24 -0400 Date: Thu, 12 Aug 2021 17:00:18 -0700 From: Benjamin Kaduk To: =?iso-8859-1?Q?G=F6ran?= Selander Cc: "cose@ietf.org" Message-ID: <20210813000018.GY50759@kduck.mit.edu> References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> Archived-At: Subject: Re: [COSE] Key identifier of type bstr / int X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 00:00:33 -0000 On Fri, Jul 30, 2021 at 12:28:58PM +0000, Gran Selander wrote: > Hi, > > In LAKE yesterday we had a discussion on compact key identifiers. The main candidate to use, 'kid', is specified as a CBOR bstr, which is typically at least 2 bytes (exception: empty bstr which is 1 byte). We therefore want to allow keys to be identified with CBOR ints which has 48 1-byte values to allow for a larger number of optimally small identifiers. > > One solution would be to define a new COSE key common parameter and COSE header parameter, say 'kid2', of type bstr / int. Another solution would be to extend 'kid' to be bstr / int. > > In the former case a 'kid2' can be used to reference keys identified with either 'kid2' or 'kid', but 'kid' would not be able to reference keys identified with 'kid2' having an int value. Not clear to me if that is a problem. > > While the LAKE WG did not express any preference, one opinion I learnt after the meeting was a preference of extending 'kid' to bstr / int. > > What do folks in COSE think? > > I'm familiar with the process of registering new COSE parameters, what is the requirement for changing the value type of an existing registration? Standards action with expert review? I think so. There's a decent case that just standards action would suffice, but I like ensuring that the experts also weigh in. >From the follow-up: > Another alternative to what has been listed below is to define 'kid2' to > only be of type int - is that a better option? That would avoid some of the decoder complexity that Laurence raised, but leaves the issue of needing logic to handle a message that sets both 'kid' and 'kid2'. For a long-term steady-state best outcome I don't see a huge difference between an expanded 'kid' and deprecating 'kid' entirely in favor of a 'kid2' that does both. I'm less sure how to compare that option against the one-parameter-per-type option (kid==bstr, kid2==int) that is easier to decode but has the possibility to provide both parameters. -Ben From nobody Thu Aug 12 17:17:09 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7C93A0FC5 for ; Thu, 12 Aug 2021 17:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mattrglobal242.onmicrosoft.com 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 GduFcJPG1uXk for ; Thu, 12 Aug 2021 17:17:00 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on2111.outbound.protection.outlook.com [40.107.108.111]) (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 73DDB3A0FC2 for ; Thu, 12 Aug 2021 17:16:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ld0r3aBYC+TXQco97K+C8ySUlHaERLzaCOQkhnQvPjGoLILTyepEmOm9kJDYCocwTQo2OQOgMvDmy4ihU76r/4+YStW7t3OCquULFK3fhjQhrkT7rE6OMEmf4UWJkpP6808MIUeLJSjuLHn2PBbcbvzhGi36LygVbnNG8TLJTObWUd48hhHuePbVQcHLa16PdL/hUq6JrgF4kKIZRJoFbG1wraFlaOkyqAIJ8WGmU1N8erTNthaIi9+ggkc2F7rK7W34LCjS8XPreY1TnlJRpK5UXtCtY5CyZV4BQo94CP6PzcMZN8zSTvMFphjb2M7WTKclpvWMNtktYxp6aHgIvA== 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=56K6EDByYpOocB3FNpckTPoEDLqEmfMclz0aw8QPyWc=; b=PqEKJlIm29/98ZMeeJ+XFp4B4zArxH3GXLlAhimpTWLDQRiE32BQAqCVDDXAMP0BZNHcAfjvSzWOvORmVOp15ot/lcJaYwgwv0bGsgYXiZv2kc4LIH0ttToN32tZE230USiTsELzXNUuDWW4HEcSIERKVkQ9OExMm23xSO3WxJ8dolReQP4Srys9HTzo9gv/38h3ZuEAVHz+HTzyEo+BjVqkfe2FQgAKrFv1cWvUK6g9REiHnN2q9TVd5DlqRa0tnUYnMOsIx9P/PySrcdMaEsS8dSN8akfFG6+JCI2eKhdVjN86flO9hkzb74SdxwF8o+xEVdCDVybezbMuCl7gXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mattr.global; dmarc=pass action=none header.from=mattr.global; dkim=pass header.d=mattr.global; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattrglobal242.onmicrosoft.com; s=selector1-mattrglobal242-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=56K6EDByYpOocB3FNpckTPoEDLqEmfMclz0aw8QPyWc=; b=ZPwo8nRamP0W8lvzid0ztK/jWjtyMjINBvFRUdxQc3u4+OgVNlA+y/hphGcqA/kdsiMW4kMyAQzMofSqI1i+gucWuQT9VOstex+x11PMmvCc6/JYtaXvKoEuQpeMAkuPOKOORj+kp9d4y3N0YX7hes2PfqkeLCulRUrBlKN6P4s= Received: from SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a9::8) by SY4P282MB0890.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.18; Fri, 13 Aug 2021 00:16:54 +0000 Received: from SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM ([fe80::1d34:fe2a:57a1:28e]) by SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM ([fe80::1d34:fe2a:57a1:28e%6]) with mapi id 15.20.4415.019; Fri, 13 Aug 2021 00:16:54 +0000 From: Kyle Den Hartog To: David Waite CC: "cose@ietf.org" Thread-Topic: EXTERNAL: Re: [COSE] Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose Thread-Index: AQHXh14rDCNZ4UEEXka/UfIWuuJSyqtqiv/PgAAS1ICABgQnbA== Date: Fri, 13 Aug 2021 00:16:54 +0000 Message-ID: References: <17B95B7A-93BA-4E3C-8EE9-492BC675C5D6@alkaline-solutions.com> In-Reply-To: <17B95B7A-93BA-4E3C-8EE9-492BC675C5D6@alkaline-solutions.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alkaline-solutions.com; dkim=none (message not signed) header.d=none; alkaline-solutions.com; dmarc=none action=none header.from=mattr.global; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b79a4c1-ba9c-4e9b-524c-08d95defa80f x-ms-traffictypediagnostic: SY4P282MB0890: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +L9WKx1q7qsPx1TBCFengJibLS/dHJTJJg7GGGYFA/NQVAFN4EeXqPkRVD8VazBGAldGDr4wV6SQTeoaBI8x97LnaT+/pgFpxMyZBCNx4vyeH6Ar05vxsKFMjJvwaQjC+CJO56H03/1zMHLXMmi/bejDaT6u4p8SDfAmWWCQkv5c63+Cdwgm6J29OXJz7pRRaN1HvDsRQcYILXnq3hmW8ogX2IQQthn+UJwraJxcy1px7q8dV10JeLGqzJW3chhqgzpRsMb0XhrHS2KIfTnP85bameoZWDeONChWDlVozeMPM71mldpQJjFLZiHxztqT1keXV90OlW0JfD1r4zxKVACuoQrdoA34NcosJfnQDK5sws8yIPu3qi1BD5F50jq2dYKHvm+JTuBny+ELPWWxDzI/PpI5W4KO5i9HRfvZBpxBrYiI//PL6GnICM+TpIRQocKho07gCK5SvKHC12FZc0TQJwejrbM9RiPHzXzz9pECTylOVRmL0P3MjTNai5i9LKjKqaaMdCeSCEaWdbVt2YUCgmUY63ULLWZEldTtY0oTRMdwit/vzos5EcotN63obH7KuoSvo+LBS/1HT/1vWncW6L5LafbiD48gJOCqZstQE0gt0Wy5Vy8IBA0T39qZahu9meK3CoxDV7mkqZ2yvxtoi/OeukbrrKGvYgLzHX6HBiJKgxTYoH+Ie610NK+TwmogiTItLdpvxHxODPWK0UflL3tQzTSD5GOfk1CGY98anTr+BFQk6fiToVjhEqtpG30js/sf6ondC1fHE++NWKqzvfPndFpTHqOOzSZouTUVBEnMr60JWXYqHZKxQwDs0zqnbh75V44s04Hmpcco2zXrP6fFw2BF8DBgBn4KJNE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(376002)(39830400003)(366004)(396003)(136003)(316002)(6506007)(8676002)(53546011)(8936002)(7696005)(66446008)(64756008)(66556008)(166002)(83380400001)(6916009)(66476007)(122000001)(38100700002)(86362001)(38070700005)(5660300002)(33656002)(4326008)(478600001)(71200400001)(9686003)(19627405001)(66946007)(966005)(186003)(55016002)(52536014)(2906002)(76116006)(15398625002)(43620500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?XLvwImbj0ENaGToLVx0RP6bQIpZgjX1hzZDvy3Y9dguw/0Rn+JAGgaiO/50j?= =?us-ascii?Q?L/7/l9zW7gW+M0Gg4wqq9Y9igtzkTrpaN0QAjrlQO5y8JeFTpGRzQ+P1XMSm?= =?us-ascii?Q?RRdcpcRXxTP5AKfxljkje/J+JKbasuyDeH197aqNh0n5HX/LZXk1XztwHXfY?= =?us-ascii?Q?syqYAzoclD/r+gVr4AujmiZmMCe6PzkR+ipCkjJPN6U6OqsxGZ3djZ7PSgWg?= =?us-ascii?Q?T08OKak+BpwIl+cQ6/xBKt4tqAAJY0YdgwmRC0k1qwkFwx/0d5Zk0L7/U1C6?= =?us-ascii?Q?xvqkuk0a0HkCu9XN2uuLkLEIak0b+nJoh8192gnDm9856ktmxgjsEqmAF4P4?= =?us-ascii?Q?XV2tdE3k3kCyZa7Bf2fLdRYAudCRm+nEvIKCx9UN5ZQvpYAs0/r9N6VIhdXn?= =?us-ascii?Q?+AjhBtSyfvQsR19I2Kw/xiOSkeXyKmHjWCwv8DmCXrERo/LofPB3Spz3QXem?= =?us-ascii?Q?LBrtVf4aD9HwCpDt2rU5mzfwQjimRknA8zgVkUjasdjr3gWFwMIdbwkIhyA+?= =?us-ascii?Q?/v7Petb1MqcX5Gv5Q1lVTFJKFepeTK/Nt8B+ZbD/po9xPR0hJfEwVMsv9fCi?= =?us-ascii?Q?DwIXygZPgaZK4CebrU1h69RedtIn55qgZop9tnXJEdD7yR1A1ZYJQznmyUj8?= =?us-ascii?Q?3Hdmvlwahw3M5nLZeMlYBb6mjLEFSfsyxo5Qa3Ynpy79V0cpS69GdyKySuLq?= =?us-ascii?Q?mic0RTQd8ECmn4pgaYq/Ht2TmxWnLiEdJdemB+Rq9Ih8CVtA0K+f8sXYzDQR?= =?us-ascii?Q?ygYBtaMoQMOULSGsyHNqLyMAvTVXSycgDLG/WT4Y4zwvgBRDpxq1bGvXkL53?= =?us-ascii?Q?a01Fx2HYSupdsJbwbwFAM7ZAnEvlH3AQ5TLQpZcZSaKVCkic2piNR51S/axg?= =?us-ascii?Q?0fo36UShXDD9vMfWjqpcLDT1tDnA22PTrPlRKU8aKEUw4FhcJWpXkzDQad7X?= =?us-ascii?Q?zWURIv5dwJO3AK2Gcryf3j4z9K8h7ucwYyC9lQx4Q3AhBMT6nYR4nKlAWQh6?= =?us-ascii?Q?6Q0jQGuGU+8vWk63ZS8PRX3UeKeAxMoRrX0Own4nn4lP9G+6HGALqCII1hZK?= =?us-ascii?Q?lcoT0+IGX4olbDhm7AXuvdhud1RL0VFTXX9bl3wXWYF7EhHQqJ8iU4T2F8q3?= =?us-ascii?Q?kTuzG46MZghWpQUphZDmWwng7xJplN3B9GNj2I9VUX/AIkqJ15/bSvbirju4?= =?us-ascii?Q?Xx6OKCnuZJYzJ47ER/n8XiowOX4scU2RKEXQjd0LygnKir9sr+zEAGXss+DY?= =?us-ascii?Q?D6eT4l5RA6HXMjrFB8FliUXBOgwC1syvNGKWes9lKAW4aH8N15IciNWzSZja?= =?us-ascii?Q?FNCufa+jpbJsrq74m6XkNqZBs/RwJd4IBFLspvE4cPMEDkh1VOwBBHOrAmb8?= =?us-ascii?Q?PA3mXlAaMalJHQ9aHIDM7hvL+xfr?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SY4P282MB079653653B9FBAF65FF44C67FCFA9SY4P282MB0796AUSP_" MIME-Version: 1.0 X-OriginatorOrg: mattr.global X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 2b79a4c1-ba9c-4e9b-524c-08d95defa80f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2021 00:16:54.6614 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c2c9cf73-6aae-4702-9844-02adab723771 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K8XZTPuL5kHTFUmaGfw0o+SVJ8VUqvG43CYYu7ioDx5WiIgdzGsRGDIDoi9/SyMurUG7v89oJq1D6iShQTZca4i8ev3x0a8UCy1Ojx9VNQE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4P282MB0890 Archived-At: Subject: Re: [COSE] EXTERNAL: Re: Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 00:17:07 -0000 --_000_SY4P282MB079653653B9FBAF65FF44C67FCFA9SY4P282MB0796AUSP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the update on that. In that case, it's probably worth sticking w= ith the original plan to prohibit it if it's not overly common to implement= ations that are already using these things in JOSE and COSE implementations= . -Kyle ________________________________ From: David Waite Sent: Monday, August 9, 2021 4:23 PM To: Kyle Den Hartog Cc: cose@ietf.org Subject: EXTERNAL: Re: [COSE] Response to IETF 111 Agenda questions for dra= ft-denhartog-pairing-curves-jose-cose AFAIK BN curves are not actively in use with FIDO, and there are no product= ion authenticators producing ECDAA attestations. -DW On Aug 8, 2021, at 9:38 PM, Kyle Den Hartog > wrote: Regarding question 2: "Whether Bn256G1/G2 should be registered and prohibit= ed?" I was just reading the TPM2.0 profile[1] and it looks like Bn256G1/G2 are u= sed by default for ECDAA signatures and are by default included in the TPM2= .0 profile. There's an additional BN638 Curve that's optionally supported a= s well. It looks like there were algorithms under "ED256" which has registr= ation entries included in the FIDO ECDAA Algorithm specification[2] (see se= ction 5.7). This raises 2 questions for me: 1. Do these algorithms still need to be registered in the COSE/JOSE regi= stries? Given I'm still quite new to the COSE WG I'm not sure about the bac= k history. I'll do some digging in the mailing list to see if I can find so= me discussion about the topic. 2. Interestingly, they didn't define and attempt to register how the key= s would be formatted in a JWK/CWK format. Is anyone aware of why that was? Given the case that Bn256 is actively in use within FIDO with ECDAA, I'm le= aning against prohibiting usage of this even though there's been attacks th= at have reduce the security entropy to be ~100 bits. From a practical persp= ective this is just to prevent confusion for implementors of FIDO. Are ther= e any experts on this list who want to weigh in on this given the new (to m= e) information? [1]: https://web.archive.org/web/20161031085411/https://www.trustedcomputin= ggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf [2]: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algori= thm-v2.0-id-20180227.html#iana-considerations -Kyle ________________________________ From: Kyle Den Hartog Sent: Monday, August 2, 2021 6:08 PM To: cose@ietf.org > Subject: Response to IETF 111 Agenda questions for draft-denhartog-pairing-= curves-jose-cose First off thanks Mike Jones for jumping in and PowerPoint jockeying through= the slides for me. Sorry for missing the meeting I had a time zone mix up.= I was able to rewatch the portion of the recording afterwards and wanted t= o weigh in on a few questions I heard and had prompted on the slides. 1. Should we use EC2 vs OKP? * This is where I was going with this question. It was asked to me i= f SEC1 encoding was commonly in use today. I realize now that the draft doe= sn't accurately convey that when I referenced SEC1 that I was implying the = usage of SEC1 point compression which would then use OKP. I'll need to upda= te that. As far as I've seen it's mainly gone towards OKP (with a single co= mpressed point and a sign) so my take was that we follow that pattern as we= ll. However, the latest pairing-friendly-curves draft[1] references draft-i= etf-lwig-curve-representations[2] (note it's draft 08 while the latest draf= t it's now in Appendix I.5). In this case, my questions was trying to figur= e out if the draft should use the SEC1 compression serialization of the key= s which seems more common in JOSE and COSE or if it would be better to cont= inue in the serialization method described in section 2.5. In this case, I = didn't fully understand what was being described in the lwig-curve draft, s= o I opted to go with SEC1 compressions in the initial draft. I'd like to ge= t others to weigh in on if this is even possible first, and then for us to = consider what is the better direction. 2. Whether Bn256G1/G2 should be registered and prohibited? * The discussion hit the nail on the head here. Thank you, Jonathan = Hammell, for jumping in and explaining the background on the security issue= . My concern was that because the security has been reduced to 100 bits rat= her than 128 bits does this warrant the draft defining it and marking it as= prohibited. My take was "yes" hence the original question. 3. Regarding the G1/G2 question: * This was largely heading in the direction of trying to figure out = if it makes sense to recogonize these separate finite fields as independent= "curves" or would it make more sense to use a different way to differentia= te them. One suggestion on the github repo has been to use multicodec as an= alternative serialization to SEC1 and lwigs-curve and then use that as a w= ay to represent the sub groups. My general take is that this didn't align w= ell with the traditional approach COSE/JOSE have used and so it's going to = introduce some new dependencies in many implementations I'd suspect. For th= is reason I would prefer to not go this route, but am not necessarily certa= in if my "crv" route is the right way either. 4. Regarding defining these with signatures: * My general take would be that I'd prefer to not have to do this. S= ince we haven't implemented any of the signatures schemes that utilize thes= e curves in JOSE or COSE, it would be a bit of a yak shaving exercise for u= s and our primary goals at this point to have to also define those. I know = of some related proposals that are looking to define these signatures (BBS+= ) in JOSE in the very introductory stages which may pair well with this, bu= t for now I'm of the opinion we could just as easily separate the works. If= there is a desire to define at least one signature scheme with this, the I= RTF does have the BLS signatures[3] being worked on which would pair well w= ith this work if there's a desire to add threshold signatures to JOSE/COSE. Hopefully with this additional context to the slides, people may have a bet= ter understanding and some further opinions on the various questions to dat= e. [1]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly= -curves-10#section-2.5 [2]: https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representa= tions-08#appendix-J.4 [3]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04= / Thanks, Kyle Den Hartog _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_SY4P282MB079653653B9FBAF65FF44C67FCFA9SY4P282MB0796AUSP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the update on that. In that case, it's probably worth sticking w= ith the original plan to prohibit it if it's not overly common to implement= ations that are already using these things in JOSE and COSE implementations= .

-Kyle

From: David Waite <david= @alkaline-solutions.com>
Sent: Monday, August 9, 2021 4:23 PM
To: Kyle Den Hartog <kyle.denhartog@mattr.global>
Cc: cose@ietf.org <cose@ietf.org>
Subject: EXTERNAL: Re: [COSE] Response to IETF 111 Agenda questions = for draft-denhartog-pairing-curves-jose-cose
 

-DW

On Aug 8, 2021, at 9:38 PM, Kyle Den Hartog <kyle.denhartog@mattr.global<= /a>> wrote:

Regarding question 2: "Whether=  Bn256G1/G2 should be re= gistered and prohibited?"

I was just reading the TPM2.0 profile[1] and it looks like Bn256G1/G2 are u= sed by default for ECDAA signatures and are by default included in the TPM2= .0 profile. There's an additional BN638 Curve that's optionally supported a= s well. It looks like there were algorithms under "ED256" which has registration entries included= in the FIDO ECDAA Algorithm specification[2] (see section 5.7). This raise= s 2 questions for me:

  1. Do these algorithms still need to be regist= ered in the COSE/JOSE registries? Given I'm still quite new to the COSE WG = I'm not sure about the back history. I'll do some digging in the mailing li= st to see if I can find some discussion about the topic.
  2. Interestingly,= they didn't define and attempt to register how the keys would be formatted= in a JWK/CWK format. Is anyone aware of why that was?
Given the case that Bn256 is actively in use within FIDO wi= th ECDAA, I'm leaning against prohibiting usage of this even though there's= been attacks that have reduce the security entropy to be ~100 bits. From a= practical perspective this is just to prevent confusion for implementors of FIDO. Are there any experts on th= is list who want to weigh in on this given the new (to me) information?

From: Kyl= e Den Hartog
Sent: Monday, August 2, 2021 6:08 PM
To: <= a href=3D"mailto:cose@ietf.org" class=3D"">cose@ietf.org <cose@ietf.org>
Subject: Response to IETF 111 Agenda questions for draft-denhartog-pairing-curve= s-jose-cose
 
First off thanks Mike Jones for jumping in and PowerPoint jockeying through= the slides for me. Sorry for missing the meeting I had a time zone mix up.= I was able to rewatch the portion of the recording afterwards and wanted t= o weigh in on a few questions I heard and had prompted on the slides.
  1. Should we use EC2 vs OKP?
    1. This is where I was going with this questio= n. It was asked to me if SEC1 encoding was commonly in use today. I realize= now that the draft doesn't accurately convey that when I referenced SEC1 t= hat I was implying the usage of SEC1 point compression which would then use OKP. I'll need to update that. As f= ar as I've seen it's mainly gone towards OKP (with a single compressed poin= t and a sign) so my take was that we follow that pattern as well. However, = the latest pairing-friendly-curves draft[1] references draft-ietf-lwig-curve-representations[2] (note it's dr= aft 08 while the latest draft it's now in Appendix I.5). In this case, my q= uestions was trying to figure out if the draft should use the SEC1 compress= ion serialization of the keys which seems more common in JOSE and COSE or if it would be better to continue in= the serialization method described in section 2.5. In this case, I didn't = fully understand what was being described in the lwig-curve draft, so I opt= ed to go with SEC1 compressions in the initial draft. I'd like to get others to weigh in on if this is eve= n possible first, and then for us to consider what is the better direction.=
  2. Whether Bn256G1/G2 should be registered and prohibited?
  3. =
    1. The discussion hit the nail on the head here. Thank you, Jon= athan Hammell, for jumping in and explaining the background on the security= issue. My concern was that because the security has been reduced to 100 bi= ts rather than 128 bits does this warrant the draft defining it and marking it as prohibited. My take was &q= uot;yes" hence the original question.
  4. Regarding the G1/G2 question:
    1. This was largely heading in the direction of trying to figur= e out if it makes sense to recogonize these separate finite fields as indep= endent "curves" or would it make more sense to use a different wa= y to differentiate them. One suggestion on the github repo has been to use multicodec as an alternative serialization to = SEC1 and lwigs-curve and then use that as a way to represent the sub groups= . My general take is that this didn't align well with the traditional appro= ach COSE/JOSE have used and so it's going to introduce some new dependencies in many implementations I'd suspe= ct. For this reason I would prefer to not go this route, but am not necessa= rily certain if my "crv" route is the right way either.
  5. Regarding defining these with signatures:
    1. My general take would be that I'd prefer to not have to do t= his. Since we haven't implemented any of the signatures schemes that utiliz= e these curves in JOSE or COSE, it would be a bit of a yak shaving exercise= for us and our primary goals at this point to have to also define those. I know of some related proposals that = are looking to define these signatures (BBS+) in JOSE in the very introduct= ory stages which may pair well with this, but for now I'm of the opinion we= could just as easily separate the works. If there is a desire to define at least one signature scheme with t= his, the IRTF does have the BLS signatures[3] being worked on which would p= air well with this work if there's a desire to add threshold signatures to = JOSE/COSE.
Hopefully with this additional context to the slides, peopl= e may have a better understanding and some further opinions on the various = questions to date.

[1]: https://datatracker.iet= f.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-10#section-2.5 [2]: https://datatracker.ietf.org/doc/html/dr= aft-ietf-lwig-curve-representations-08#appendix-J.4
[3]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-si= gnature-04/

Thanks,
Kyle Den Hartog
_______________________________________________
COSE mailing list
COSE@ietf.org=
ht= tps://www.ietf.org/mailman/listinfo/cose

--_000_SY4P282MB079653653B9FBAF65FF44C67FCFA9SY4P282MB0796AUSP_-- From nobody Thu Aug 12 18:01:49 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7497A3A128B for ; Thu, 12 Aug 2021 18:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2eZCV7H4xTAY for ; Thu, 12 Aug 2021 18:01:42 -0700 (PDT) Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) (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 1B4CD3A1287 for ; Thu, 12 Aug 2021 18:01:42 -0700 (PDT) Received: from [172.20.7.246] ([50.125.30.3]) by :SMTPAUTH: with ESMTPSA id ELZtmibiXWMe9ELZtmIsqP; Thu, 12 Aug 2021 18:01:41 -0700 X-CMAE-Analysis: v=2.4 cv=Uoumi88B c=1 sm=1 tr=0 ts=6115c475 a=HDq/oGp5D7QgKInbiSp5pw==:117 a=HDq/oGp5D7QgKInbiSp5pw==:17 a=48vgC7mUAAAA:8 a=gJzD2ls_7so3aXa4DcMA:9 a=QEXdDO2ut3YA:10 a=tTNzG0yJQaIKPBsoLDcA:9 a=vqm2CSZNjNgrqUyy:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <823C00C2-4F6C-4DF5-99B0-87D8524D4A9C@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D0334B4-2F79-4591-A85A-6CAE58F54778" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 12 Aug 2021 18:01:41 -0700 In-Reply-To: Cc: "cose@ietf.org" To: =?utf-8?Q?G=C3=B6ran_Selander?= References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-CMAE-Envelope: MS4xfOcyLOqI2XHhO4m8aG2xYW9Iqbje1N3IeaDwvzsIBJrqQ0nAgb3iTAvqEQTOydicbr4egvJdNfy/CT0X6jOl+DLIqY7MhOMUBeCi4IIh1+ShuR9+Ch7v fPHSNLyZtJftLxblK8JAxUN8QXbGpLifb59S1UPIgZO2hnw4DhZoMhdmFZhqsx4Vsd3NJX7Sxl4EUZ+geDRTtYe2nsrCx+2Z6ra5GBBR3BFCFTuCY54Y9g4P y0h3pm2n+MoymHwcGp5FcQ== Archived-At: Subject: Re: [COSE] Key identifier of type bstr / int X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 01:01:48 -0000 --Apple-Mail=_9D0334B4-2F79-4591-A85A-6CAE58F54778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Understood about the use case. Thx for the background. > On Aug 10, 2021, at 3:13 AM, G=C3=B6ran Selander = wrote: >=20 > Assume that we do want to allow key identifiers to be CBOR ints in = certain settings, what is the best (least intrusive) way to allow this = while still maintain compatibility with 'kid's supporting the type bstr? = Another alternative to what has been listed below is to define 'kid2' to = only be of type int - is that a better option? I didn=E2=80=99t write actual code to check, but they about the same to = me. =E2=80=98kid' as int/bstr seems less confusing to me than =E2=80=98kid2=E2= =80=99. It tells you it does exactly the same thing whether it is an int = or a bstr. So my pick is =E2=80=98kid=E2=80=99, but =E2=80=98kid2=E2=80=99 is OK = too. LL= --Apple-Mail=_9D0334B4-2F79-4591-A85A-6CAE58F54778 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Understood about the use case. Thx for the background.

On Aug 10, 2021, at 3:13 AM, G=C3=B6ran Selander <goran.selander=3D40ericsson.com@dmarc.ietf.org> = wrote:

Assume that = we do want to allow key identifiers to be CBOR ints in certain settings, =  what is the best (least intrusive) way to allow this while still = maintain compatibility with 'kid's supporting the type bstr? Another = alternative to what has been listed below is to define 'kid2' to only be = of type int - is that a better = option?

I = didn=E2=80=99t write actual code to check, but they about the same to = me.

=E2=80=98kid= ' as int/bstr seems less confusing to me than =E2=80=98kid2=E2=80=99. It = tells you it does exactly the same thing whether it is an int or a = bstr.

So my = pick is =E2=80=98kid=E2=80=99, but =E2=80=98kid2=E2=80=99 is OK = too.

LL
= --Apple-Mail=_9D0334B4-2F79-4591-A85A-6CAE58F54778-- From nobody Thu Aug 12 22:18:11 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7267E3A05AA for ; Thu, 12 Aug 2021 22:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 W4fFwNuNmLz5 for ; Thu, 12 Aug 2021 22:18:03 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60077.outbound.protection.outlook.com [40.107.6.77]) (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 177EF3A052C for ; Thu, 12 Aug 2021 22:18:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R8Dj+eXbtF8yX4dpme2mTkU9Kt5Tf9OSfBqqBvxCajXfb0eXFsXDmBkD0VOF2TZ5WfbXchHsu8fI+HmVUesnrseL2cB1imfFb+JL0a1Fb8v0vNNFl7Ye6OltyNKbTsf2j3YTDJXa8UmjyTAtOOn/5e9uP7lDmm18gUYSLZK3F6/yZKoZVhHa1SpPWpCkBCSxxjb6/Zf4aY1JwPeMrwmdCCxflmBq19l2e7D5FJGzuV5ZOrNDMDgtFTK55n8EG+SwUyu3nK1obwmWbQRYUPe0GQj9xmeqV4TST9RnzqvEp2iDdUrZ4JC2DEpOBGlOpKdRaxsrQVusrGchmVTA4EMVEg== 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=aP0URuXZxK7Vr30J3Qc2JG6NaaPv16a+x3ds+AAXsUY=; b=gWVajd91+vkW9WhBrIFE504ACt4mYhZ13hSfPls4yrQPNySFnDTV2lu71gjRqzJg3MBcX+hg4Bk4VI3sCZVSpO+GQIQWqOi2nX9y7RBuQzRC/DALI+U4hvjO1nwIoE2SCwLP7kdaHq6qLNL5dPUDkCbWioxbkgd24ZM9TqgW6xtPA8LYxa6xp/X5upwfKFZr4dlMlTcMIHFgpdhruBIJ4h+nwJc3uRdW6ETvROgPjHxbBLlQYSJUvN2lYMoi/RtevHQsXen1yIvxLL/SThmPUIkuVg7OcJQp6pZlix+8AAc+PwKqkugYhxtQLRC6IVKmbKkVyGWBtqtfrSsMzpiz/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aP0URuXZxK7Vr30J3Qc2JG6NaaPv16a+x3ds+AAXsUY=; b=IV/Pxv37vnOp8x8P3dDdjaQ2n4na4X7QQz+Lu05i0WDLoj473Pk/kDIaCa7hiRfZF5SBsES3X7ISMMVDr4ZwTx/PgTd3pFgxt2FzJUDTf2JjEp//PlwcKRyw2kqx1114tFnVnBpltovNUJwQe8SztxA0cMg3215FEJOupCOqB2c= Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR07MB3145.eurprd07.prod.outlook.com (2603:10a6:7:31::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.5; Fri, 13 Aug 2021 05:18:00 +0000 Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::7191:79ea:fa53:9014]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::7191:79ea:fa53:9014%4]) with mapi id 15.20.4436.009; Fri, 13 Aug 2021 05:18:00 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Laurence Lundblade , Benjamin Kaduk CC: "cose@ietf.org" Thread-Topic: [COSE] Key identifier of type bstr / int Thread-Index: AQHXhT54TcPpMfWo3E61Id/NsrhJv6triUiAgAEuhQCAA/tDgIAAaSOA Date: Fri, 13 Aug 2021 05:17:59 +0000 Message-ID: References: <95B75634-B147-4756-A950-C6B139CF3ADD@ericsson.com> <9DF382AC-12A8-47A5-AAE7-2B0D75EAA669@island-resort.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8652731d-e1ab-4866-1057-08d95e19b7de x-ms-traffictypediagnostic: HE1PR07MB3145: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GyHU3UM91E1PAKvuZevYSay1CiNiopL/m/2uVUzA21/OmW4CSgOCybSrJBc8r1IHK3UWGJdhum4ba9TZ+6tGFd0TIffpqDzN1oXO5n8HQ54ti1jF2cxO+fQakLYZq7me3W4C6yhbdYcvulhgL74TWHX003y5GHdAC+EzDn/HwfMu3X3G9Z72Y5FZXk/QkPVMA5XrAxL23B3ZQNBau4zgryCvua1HGcmH+C00rNWSC/f/1xs6+4/1qUsT0YD0mOxnVpNuRdAS0CyUmmD2MLYpySBL+pbhF8R33aHEKnWxSauuoVJ2ll077L6Kto8pTUYFMGFhyFE65EU/PH7pEAICOLRlNQrRslIOtPGm4VoP+WB1al4r9SfyLqy7z7U0gFXpxjuHa3JJ30WUJQOxR+b+OXJ/afa54z2SWQu2VKZML+gfjZROlSEDZbmjr9boCtLXumjARjiTbP1q+E9sb4v8AW/L/VWp8j8gaIP7/NZPFKg0oI1rn4RVx+HlUPFAZTsClwZ1jLJFbW1Ww75yHe55eN9i6I8lJUMkgjQIGfmSLgzGaitkhH3JuP+WdNrrtW7DqN4mf6cMT1ljCtvbObUlViy3g+zRhpUvw8ew19umEy7HUDKtslyQDYiFIhq0/JyDN/hOpEbuMc7QUbq1FODCo/o1eZnbnoVNkDG9jEt5PAUUP4uTcnhsgk2/pg49zYx5ZQ8F5W1FzIkPj7Wpvn2YPGkSSKBzI/rUc+WrYp8nDIFGJodGdRQwA6wOr/WhTUZq x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(39860400002)(136003)(376002)(366004)(110136005)(66556008)(66946007)(38070700005)(64756008)(66476007)(76116006)(66446008)(4326008)(2616005)(36756003)(316002)(6512007)(478600001)(86362001)(6506007)(85182001)(85202003)(6486002)(66574015)(53546011)(26005)(8936002)(8676002)(5660300002)(71200400001)(186003)(38100700002)(122000001)(2906002)(33656002)(83380400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TXlnM2I5Tk54NkJpby9vSnM1b3QzbTN2SFN4ZVh2OXR3a0ZadmhOTFdodlk3?= =?utf-8?B?RGNLWE9GbVdNcW14eHlpbVp6cjgrOTNENnVBZkZLUXBiTnptYTNoNkQ4ZTMw?= =?utf-8?B?K2xpNEtlMnQ2WHV4S2FNa2FQaWsrbi8wTW1sZmVnZ09nV1JhQXJXTUp0enBD?= =?utf-8?B?RVp2bGN5K1I0ZUsxc01WWlJ5L3g5cWJJUFNFZllNY3RoYXlaYUF6bnR1K1hj?= =?utf-8?B?a1ZRZUtKc2p4SWQ5Q0JqWVM3bGMyWEgrQTBkaHZRaE5ESzlIemVsUHJ5MWpt?= =?utf-8?B?SkJ1MzhxdWwzT3EwSVc5aWRrV2doakVNMW9jM3kzOFZCczM0TWROUmpvZjNY?= =?utf-8?B?cklpTE1jMFJKM2pHWnVOS1pHN3pQcGl4d01ua1dFdlhGSU52V1dEclMvMlM1?= =?utf-8?B?QlozUUhWUnBWKzJxYmZRbUJBV3ExYm5wS2h4S3hrNUVhSDAxSmp5a0hxSm9K?= =?utf-8?B?bVEyN0dRTU9mVWZvaGV3RE1TMTk0bFdRWi96Y2JSUGxYUDNxVzZJZXY1U1lh?= =?utf-8?B?clVKSG5WVStZYVdXeEV3VXZ3WVFkamtKMFVjQ3VCc1J5YlJKNktCYmlPYXh5?= =?utf-8?B?NVpHVWQ3WnYxWHJPT1M3MjRUTlVtQTJzZHphaGdVRXdDR3RVcGFNVEN0cUJZ?= =?utf-8?B?dzk4VjNRWDFqNUJSdXBUL1Z5aU4vYzUzU0YxUW1aR3kwNm8wZlVJdFpybjFv?= =?utf-8?B?ZkNpUG9tN0FRVE45WjN4dDMybnAxWW1yTTdPYjJSVGErTlo0d01wU1JyRTBW?= =?utf-8?B?Y2V3QzV2dTZKZW4xUDU1TFBmdnpvVGI0Rmo4TTdheTFvVlZGTmdKS0JlYUh0?= =?utf-8?B?allWVTRsaWwrZUsxOW5DVHpGN1FxK0FSa0VUMVYzZmVkUm1LdUp6K2tmZzZT?= =?utf-8?B?Sk1iWnJSbVErajhybGpxN3l3WkJxTGZpTUgyeGY3Rkp5U01DY3NOK2U0Q1dk?= =?utf-8?B?anlrYVpka3lET2VPa0pRU2tzY2FzTWVkbzJZL3VaWjAwN2tnM0dZZUlQdENp?= =?utf-8?B?SVVST1YwTTBpUVQ1RE9mVTdSdlV6VDhsV01rUFp0R1dEUmRObXczSXVnK3p2?= =?utf-8?B?Uk1EQ2YwUnZGM0p4V1AwWnFkOExrbDI4di9VRzdxQkdBR2UwNGtHSXlRNklC?= =?utf-8?B?dUZ6Rm03S3JHQXNFYlFkSExxSVRPUUlYZHBndVhDaGgwem5YWS9KY0YzZUUv?= =?utf-8?B?QjB3QzV4Skl6NmdnaWlKbE5FcEN1OHhjdTViYmNYaGhudUhuanUzVHFObW5P?= =?utf-8?B?UmprYlREbGlzOVh0bG1scXY5SC8yTjU4WHZTUGVpZHNqWUlwa3RsRUFSeFdD?= =?utf-8?B?YVgzWXVDNnQyMmZpMDIydGhLMjBJV1g5UDdHalE2dWMyN2ZHQnVtVmFuZ3RR?= =?utf-8?B?RmpRQVVvVkZ0WmxwRmNpb3R0QVMrYVJXTUNiZDY1Qmd4a05Tc3ZsODQvMnBv?= =?utf-8?B?K25IaEpDTHhLUGVzUlV4NzhrTGNZOFY1eXJZd05yeDAvNjNGcWRRZnJ2UHJW?= =?utf-8?B?V2RnbHdzWHNtb3hRVlhYTFVpeTlva20rSUtPWnRyU21KRGhoVVdMS2EyQzMx?= =?utf-8?B?VzB5MU9nRW5pWDlCb0czbDhlM08zejVXeG96QXl6ZmtVLzlNaDRxck1ISDlq?= =?utf-8?B?SHpnV2pIZDNwakNpK2xFZWJmUDV3WkQyVlpEb0ZqQTg5eEFqUUJHdUdJOVIz?= =?utf-8?B?U0t1bTVidFRWWHdCVWhRcWJIdVNLR2Z1SisrMTcyOU9OaDMyTCtQNlBCZFgw?= =?utf-8?B?QjZqTHp3WTU1MFRQNFVBR1B5MkMwaE1QYmVPb1A5ZUVFbGMyYk1xUVlRQjVu?= =?utf-8?B?V1duMXk0OWhycGx3eWN4QT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ADC229FF7E624B9CACD10289F9DE866Eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8652731d-e1ab-4866-1057-08d95e19b7de X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2021 05:17:59.9634 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7ZMjR01cgfcxohdIFStFEt3BbdyW+ZyBS+gVOTtWd4iHbEg82pTFnWMSwAFz8BFV33XY/MX9JO8cKN9wrMH0boIzq11gzYkxtLFSNxB5gAs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3145 Archived-At: Subject: Re: [COSE] Key identifier of type bstr / int X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 05:18:10 -0000 --_000_ADC229FF7E624B9CACD10289F9DE866Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIExhdXJlbmNlLCB0aGFua3MgQmVuIQ0KDQpTdW1tYXJpc2luZyB0aGUgZmVlZGJhY2sg c28gZmFyLCB0aGVyZSBzZWVtcyB0byBiZSBhIG1pbGQgcHJlZmVyZW5jZSBmb3IgZXh0ZW5kaW5n ICdraWQnIGFzIGludC9ic3RyIGRvY3VtZW50ZWQgaW4gYSBzdGFuZGFyZHMgdHJhY2sgUkZDIGFu ZCB3aXRoIGV4cGVydCByZXZpZXcuIChNb3JlIGNvbW1lbnRzIGFyZSB3ZWxjb21lLikNCg0KTmV4 dCBxdWVzdGlvbjogSXMgdGhlcmUgYSBwcmVmZXJlbmNlIGZvciBtYWtpbmcgdGhpcyBhIHN0YW5k LWFsb25lIGRyYWZ0IG9yIGNhbiB3ZSBpbmNsdWRlIHRoZSBleHRlbnNpb24gaW4gZHJhZnQtaWV0 Zi1sYWtlLWVkaG9jPyBEbyB3ZSBjb25zaWRlciB0aGlzIGFuIHVwZGF0ZSBvZiBSRkMtdG8tYmUg OTA1MiAoZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtc3RydWN0KT8NCg0KVGhhbmtzDQpHw7Zy YW4NCg0KDQoNCkZyb206IENPU0UgPGNvc2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IExhdXJlbmNlIEx1bmRibGFkZSA8bGdsQGlzbGFuZC1yZXNvcnQuY29tPg0KRGF0ZTogRnJpZGF5 LCAxMyBBdWd1c3QgMjAyMSBhdCAwMzowMg0KVG86IEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2Vs YW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogImNvc2VAaWV0Zi5vcmci IDxjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDT1NFXSBLZXkgaWRlbnRpZmllciBvZiB0 eXBlIGJzdHIgLyBpbnQNCg0KVW5kZXJzdG9vZCBhYm91dCB0aGUgdXNlIGNhc2UuIFRoeCBmb3Ig dGhlIGJhY2tncm91bmQuDQoNCg0KT24gQXVnIDEwLCAyMDIxLCBhdCAzOjEzIEFNLCBHw7ZyYW4g U2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzpnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KDQpBc3N1bWUgdGhhdCB3ZSBkbyB3YW50IHRvIGFsbG93IGtleSBpZGVudGlmaWVycyB0byBi ZSBDQk9SIGludHMgaW4gY2VydGFpbiBzZXR0aW5ncywgIHdoYXQgaXMgdGhlIGJlc3QgKGxlYXN0 IGludHJ1c2l2ZSkgd2F5IHRvIGFsbG93IHRoaXMgd2hpbGUgc3RpbGwgbWFpbnRhaW4gY29tcGF0 aWJpbGl0eSB3aXRoICdraWQncyBzdXBwb3J0aW5nIHRoZSB0eXBlIGJzdHI/IEFub3RoZXIgYWx0 ZXJuYXRpdmUgdG8gd2hhdCBoYXMgYmVlbiBsaXN0ZWQgYmVsb3cgaXMgdG8gZGVmaW5lICdraWQy JyB0byBvbmx5IGJlIG9mIHR5cGUgaW50IC0gaXMgdGhhdCBhIGJldHRlciBvcHRpb24/DQoNCkkg ZGlkbuKAmXQgd3JpdGUgYWN0dWFsIGNvZGUgdG8gY2hlY2ssIGJ1dCB0aGV5IGFib3V0IHRoZSBz YW1lIHRvIG1lLg0KDQrigJhraWQnIGFzIGludC9ic3RyIHNlZW1zIGxlc3MgY29uZnVzaW5nIHRv IG1lIHRoYW4g4oCYa2lkMuKAmS4gSXQgdGVsbHMgeW91IGl0IGRvZXMgZXhhY3RseSB0aGUgc2Ft ZSB0aGluZyB3aGV0aGVyIGl0IGlzIGFuIGludCBvciBhIGJzdHIuDQoNClNvIG15IHBpY2sgaXMg 4oCYa2lk4oCZLCBidXQg4oCYa2lkMuKAmSBpcyBPSyB0b28uDQoNCkxMDQo= --_000_ADC229FF7E624B9CACD10289F9DE866Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9060172BC4431C4B8678A18A6156317F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tU0UiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7bGluZS1icmVhazphZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzIExhdXJlbmNlLCB0aGFua3MgQmVuITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlN1bW1hcmlzaW5nIHRoZSBmZWVkYmFjayBzbyBm YXIsIHRoZXJlIHNlZW1zIHRvIGJlIGEgbWlsZCBwcmVmZXJlbmNlIGZvciBleHRlbmRpbmcgJ2tp ZCcgYXMgaW50L2JzdHIgZG9jdW1lbnRlZCBpbiBhIHN0YW5kYXJkcyB0cmFjayBSRkMgYW5kIHdp dGggZXhwZXJ0IHJldmlldy4gKE1vcmUgY29tbWVudHMgYXJlIHdlbGNvbWUuKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5leHQgcXVlc3Rpb246IElzIHRoZXJlIGEgcHJlZmVyZW5j ZSBmb3IgbWFraW5nIHRoaXMgYSBzdGFuZC1hbG9uZSBkcmFmdCBvciBjYW4gd2UgaW5jbHVkZSB0 aGUgZXh0ZW5zaW9uIGluIGRyYWZ0LWlldGYtbGFrZS1lZGhvYz8gRG8gd2UgY29uc2lkZXIgdGhp cyBhbiB1cGRhdGUgb2YgUkZDLXRvLWJlIDkwNTIgKGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlz LXN0cnVjdCk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R8O2cmFuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+Q09TRSAmbHQ7Y29zZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTGF1 cmVuY2UgTHVuZGJsYWRlICZsdDtsZ2xAaXNsYW5kLXJlc29ydC5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPkZyaWRheSwgMTMgQXVndXN0IDIwMjEgYXQgMDM6MDI8YnI+DQo8Yj5UbzogPC9iPkfD tnJhbiBTZWxhbmRlciAmbHQ7Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtjb3NlQGlldGYub3JnJnF1b3Q7ICZsdDtj b3NlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0NPU0VdIEtleSBpZGVu dGlmaWVyIG9mIHR5cGUgYnN0ciAvIGludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmRlcnN0b29kIGFib3V0IHRoZSB1c2UgY2FzZS4gVGh4 IGZvciB0aGUgYmFja2dyb3VuZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEF1ZyAxMCwgMjAyMSwgYXQgMzoxMyBBTSwgR8O2cmFuIFNlbGFuZGVyICZs dDs8YSBocmVmPSJtYWlsdG86Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmciPmdvcmFuLnNlbGFuZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzc3VtZSB0 aGF0IHdlIGRvIHdhbnQgdG8gYWxsb3cga2V5IGlkZW50aWZpZXJzIHRvIGJlIENCT1IgaW50cyBp biBjZXJ0YWluIHNldHRpbmdzLCAmbmJzcDt3aGF0IGlzIHRoZSBiZXN0IChsZWFzdCBpbnRydXNp dmUpIHdheSB0byBhbGxvdyB0aGlzIHdoaWxlIHN0aWxsIG1haW50YWluIGNvbXBhdGliaWxpdHkg d2l0aCAna2lkJ3Mgc3VwcG9ydGluZyB0aGUgdHlwZSBic3RyPyBBbm90aGVyIGFsdGVybmF0aXZl IHRvIHdoYXQNCiBoYXMgYmVlbiBsaXN0ZWQgYmVsb3cgaXMgdG8gZGVmaW5lICdraWQyJyB0byBv bmx5IGJlIG9mIHR5cGUgaW50IC0gaXMgdGhhdCBhIGJldHRlciBvcHRpb24/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaWRu 4oCZdCB3cml0ZSBhY3R1YWwgY29kZSB0byBjaGVjaywgYnV0IHRoZXkgYWJvdXQgdGhlIHNhbWUg dG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPuKAmGtpZCcgYXMgaW50L2JzdHIgc2VlbXMgbGVzcyBjb25mdXNpbmcgdG8gbWUgdGhhbiDi gJhraWQy4oCZLiBJdCB0ZWxscyB5b3UgaXQgZG9lcyBleGFjdGx5IHRoZSBzYW1lIHRoaW5nIHdo ZXRoZXIgaXQgaXMgYW4gaW50IG9yIGEgYnN0ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbXkgcGljayBpcyDigJhraWTigJksIGJ1dCDi gJhraWQy4oCZIGlzIE9LIHRvby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TEw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_ADC229FF7E624B9CACD10289F9DE866Eericssoncom_-- From nobody Tue Aug 24 00:35:30 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407A3A0ECB; Tue, 24 Aug 2021 00:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 9nlcT4Y53VOS; Tue, 24 Aug 2021 00:35:18 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130055.outbound.protection.outlook.com [40.107.13.55]) (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 4BCA63A0EAD; Tue, 24 Aug 2021 00:35:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QtUMc+kkBpQTqatxeHJIRma28M+0gEoj5D3066GHqPym3VTPs1hDSkygLjTG1XR0rk2nQoTwg0XPcGgCdVOkTAJ40tYMDpWjMzX/6df9AeEvQ93SnM9GA3cmBlyudMxQcoyK9nM0eNm0/W48V3w/GYjY5GNT6uYtNCTilhnCwY9minSL3bMht5zGldIEYpdzfdsUcpdLDSDTFoAFAv7Rke+yn+hiHT+mb7LM9MWtB8jgOPDHZ4/Il6r1mCiDoDoOPfId8UCs9TseuysacI1Am4DJlrkcC3+qAwxt+2Qvt88vrCzwlzOonYpY6KQTydcTAij3djCDPNuZL/XTHowa+A== 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=7/egEjKUKy1vEzD/LbT5VH0UMf0foARaNYohGzGvYkk=; b=HCcoihhBNM2tpGFsqg97drIlCJcBNGLIXpufHxbCFpFj4Y76CAxSP3Es7bDOWeMIWx0Vxkey6BFYoKJlXBaj5ZFwBUFTBaXW18NSAflVA75Yc1Z6Mn7ESJVC4NBR4HvIUmdjKglNtQK51dyZmzgra8fJKZ70qvvrmRWwdH3om8vhISOD1WHSAyt4+VeAOeFIm+tDShyLWYyI3g/xsR3GWK7axivP9DXzTRoKd6XoEz8bzdV0+Kd0tbIRnCZemwPhtIMd0Cbtk7X1aIFGO5WfUNN7iVi4O/cXzHp4Sm3Frnym8si4VTvKtZE1aWbtCptUPFXe+9Q36K6CyLZn96qVCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7/egEjKUKy1vEzD/LbT5VH0UMf0foARaNYohGzGvYkk=; b=bANjmLphBn2T8tV3LnLErbkxzWSUiCBzu9mCkKAUZS5s6HlZuxe2Ss2XtfqkbXdQFfZDeXH4xWpET6kYXui+71H28LWnzYqERSjZVGxBUUDIi4LFEDAf5G4Fcj7Uk56EQbGh9NGTRlHY7CbIr7k725EI3SuOHLujQQA1es7tNA0= Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0701MB2937.eurprd07.prod.outlook.com (2603:10a6:3:56::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.8; Tue, 24 Aug 2021 07:35:13 +0000 Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::a141:8e66:ce19:813d]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::a141:8e66:ce19:813d%7]) with mapi id 15.20.4457.012; Tue, 24 Aug 2021 07:35:13 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , Michael Richardson CC: "lake@ietf.org" , "cose@ietf.org" Thread-Topic: COSE IANA registrations in EDHOC (Was: [Lake] New Version Notification for draft-ietf-lake-edhoc-09.txt) Thread-Index: AQHXmLqTr445sxUxHESVhdcgjIzOkg== Date: Tue, 24 Aug 2021 07:35:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 290442ec-f230-423c-723c-08d966d1b5ab x-ms-traffictypediagnostic: HE1PR0701MB2937: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T34Kwmd5qC3EIaRkKV4ZLcTYylDwQJ1WcKnlvBAT+wkqbFqgyDODONYYoLoOLZltAM4V6P5L/zjKLZPkLqlxNv9P98tXAXb9m9b79Lu+MUNfL/Zf+mL1jf4N2JEMQ+YGqjfSgXAZxWv20kRWvGUjgoaMsRT5fQFbmAHsE1iFXf8srFjd+68UX0kjtOuBjjns5U3ksJxMnuGPquB8TmxDFmt7CWLXzEqOwPDVwc2h7f0jEyRI8kwF1Bq9sDz9gXe5ywT7Kh9+3rfHQkh8Ahk4NY9LfEGtrIMPq9aDLCP3514hDmvaXnOAvBpyt5gSOEbqVRJxHGhYU/rH6uRl8D8Mux6vmHAzijdeBmNd+zfhpNGSTbxqvooQY7DeEs5xTud9ybSxFpKU+M0K407/zaYWuHbi55yEmgGi6iCiT31vvvfR0LG7EoB4osWnOc8E3eyhGR9DqX4QEkNYM9eSHiTIacyUSsSYR7lkeCXCTv2ASOVzA01eiD41Ksj5ERjyHCd8gIF9J6tlQppc2KabhIhfvP1O+Tjo2bh46xIKaAscR9geDOtZmfOA8q7N9SHNXhzXqgEryK20bLp3UApIkxN0PcsuIwsfU90mD1gDTsDypB5Z96Wy545ThgShr7/KqIuu8yli65YwRaNMfBgyrB+kFuP8oq6I+F+ukPocVxT2jYZC4xbEV8Hv9XSYYzxNFky1aGCjLbwZG1sbEl7JufQAIpS5SrHZLX2WOaKmgAPHiq92wuWB7gQQ/f3WBg6Bf5XPBLT5VncbFIclGVPHDi/oEVsBiXNcRHjkYnQzEHf3pR1eouQFPDUj9b/7vZFso3c6 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(2616005)(122000001)(26005)(54906003)(38100700002)(8676002)(66556008)(508600001)(110136005)(966005)(8936002)(53546011)(6506007)(86362001)(6486002)(2906002)(33656002)(6512007)(36756003)(66574015)(15650500001)(71200400001)(316002)(76116006)(4326008)(85202003)(38070700005)(85182001)(66446008)(66476007)(66946007)(83380400001)(186003)(64756008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eDYxVWliaGZmM1NhRzdHb2ZkVno2dGQ5MTJod29vK2xaSDIrb1g2VE5UamZ4?= =?utf-8?B?RDdYa01BdHVJcEwxMFhtaXVHbjFyT3BOK3N2MHZXQkVFM3Eyc2RJSkFIN3Rz?= =?utf-8?B?SjAyMThnM0IrYVlZMWdYbms3QzJCSm5MNWdEYi84YjBqVHNOU3hoVEVNaVds?= =?utf-8?B?T3ArN214MzBGRWIwWEN1Q2RPck9jcEh6bWxOL052TjkrOXVDcVBQL0dvZ0JJ?= =?utf-8?B?VFRwS2REUGNlYWgrc002L3lvdno3WEhORnI0WHk1bzVUdmpzaHNjVFRhbUly?= =?utf-8?B?WWxYQTdGWVpBZHhKUWQ3Qk1UREhNOWtoL2M4K1EyWkpodVM1MkJ5azF5NHZj?= =?utf-8?B?UHhoUlpEcWJRT0VlaFRhVmRUYTBicWZqbmFUbG8wVjNuSElrQks1eldlWU9r?= =?utf-8?B?S1doSXh1aU1VTUhIYlkrenFobnMvOXQwMDBMeVpXSloxclphYnJpQlI1UTN5?= =?utf-8?B?c0k3c3NJUTN4U1Y1U0VDcm53Y0IrR0plY0V2emR6YU1ZRkV3VDEva2FpNWdj?= =?utf-8?B?Zm5YUE5yZTMwdm5kZ1ROOTBaRnErQVptUmgwU3J6enkvS0pYOU9GS01FZ3hq?= =?utf-8?B?MTl6WFBkRWt2WVpMaENrTHFqY2s5T2ZtcCtjUDJZZlk5N1kra0dkSTRnZkd3?= =?utf-8?B?dG5NaGd3WHkwaXdvZmlidVZjclJDUFBwZW1oam5sTkxrTXdYL0cvZlJzK21l?= =?utf-8?B?anhIK2lzbk5GMmRwSU03czAwK003RFN3SVgveTF2SWFPRlhvSmNuNXg2NnAx?= =?utf-8?B?WEYxMTMzNC9TeDJoZUQ4T0thMTM0SVM5N2pxKzNiMi9PODRQVUQ3Q1ZnTTBa?= =?utf-8?B?b1BkN0ZjK2x3MnQrS2NMMzZwS2J0Z3JuVmQyZS9oVlhQbDV6ekZjaC9Saitz?= =?utf-8?B?U0FBd1M4aDFMRlAvdEFTSHZ1RDVhaTdsSEpYRVJzMEFBSFR0T3JyM05DZEE3?= =?utf-8?B?ZmxHNmYwRmNQVnQ5Q1RQQVV3UjF0RlE1enhRcmgxYUloZ1BFdi84YjlleUo3?= =?utf-8?B?K3RzN0o2REZDdVZXREhyT016aWI5T1hKWjNNQ0dwMVJDOVBlY0FmVGFBcDNu?= =?utf-8?B?WTY1MEo5TFM5d1hkdjI2VjdDZGJWYUsrRHQ0NmJ5VVROVXA2aHFROUdvZitX?= =?utf-8?B?Tm1RSm13S0hRR2tqYjQ0aitkeXNZYmxNTVVUZU4rdXpVTHBrK3daWkVzVmNO?= =?utf-8?B?VHZ2Z1lXM3ZmT2tIM2R0aVhxR3lTNUZIQitSYzUxZmhzYTdJM3UzWXN1bTNo?= =?utf-8?B?eUNGZTl2eStXbEFkUW9rSDdZbndSRE50NlFaMFY5Wm95clZQb0hBRlJIR1Br?= =?utf-8?B?V0o4Qk9DRVN4VUliN0dHb1NJVW5GNGpTcll1WjNreFpiM0hUSmZteHBDUmln?= =?utf-8?B?ZEg1VHAzVEFZTDdUMkJveUttVUQzQ2g2U2ZEci9UVEtrdURpTTZGK2FRemo4?= =?utf-8?B?bHpJL0ZuVFEvM0VMY3ROaXF0N1RDN0FjYmhvV3hoelBDbXFYVXBvTGxaRTdI?= =?utf-8?B?UmNKSnJnRHp1V3o3dytFZjB0WFd5SzA1YVQzTDVLQ09FSWZhTEp0ZnJIR1VM?= =?utf-8?B?cFo3b3h2VWpnNkZabzdOU0QrVHNGcXI4ajZYNHFRelAzRXViWUtoaHRnRlZC?= =?utf-8?B?WUduZGJMT1RYeUxsSFlNMmFxaldDVHBBWVNSNVlsMzduMlZJblJhcFZyWEVs?= =?utf-8?B?ZDJkOHprcktkcGJLaERLc0hzOVNMTlRNQWp4R3UvajM5STJYTTJLTnRHRnM3?= =?utf-8?B?V2M2Rlh5N1prVXA2K1BZUWtHQ2owT3V2L2pQZjFZQXlld0hiYnZCbjZteXN6?= =?utf-8?B?MEdiczVMQ0phQlB1YkJyQT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 290442ec-f230-423c-723c-08d966d1b5ab X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2021 07:35:12.9677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t0OtGaPhPGGjtwd3Y1aRdVTLZ44v6MA4ztidqfUrzhzuKKGoDO4Slp/O8Abrf3L2cmroYTgEUlRCODNrwF597aoTDYQKOr1vc2nAF6lDgx8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2937 Archived-At: Subject: [COSE] COSE IANA registrations in EDHOC (Was: [Lake] New Version Notification for draft-ietf-lake-edhoc-09.txt) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 07:35:25 -0000 Q29tYmluaW5nIHRoZSByZXNwb25zZXMgZnJvbSBDYXJzdGVuIGFuZCBNaWNoYWVsLCBhbmQgaW5j bHVkaW5nIENPU0UuDQoNCj4gT24gMjAyMS0wOC0yMywgMTk6MTcsICJNaWNoYWVsIFJpY2hhcmRz b24iIDxtY3JAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4NCj4gICAgR8O2cmFuIFNlbGFuZGVyIHdy b3RlOg0KPiAgICAgICAgPiAqIFRoZSBrZXkgaWRlbnRpZmllciDigJhraWTigJkgaXMgZXh0ZW5k ZWQgdG8gYWxzbyBzdXBwb3J0IENCT1IgaW50cywNCj4gICAgICAgID4gbWFraW5nIOKAmGtpZDLi gJkgaW50cm9kdWNlZCBpbiAtMDggcmVkdW5kYW50LiBUaGlzIGNoYW5nZSB3YXMgYmFzZWQgb24N Cj4gICAgICAgID4gZmVlZGJhY2sgZnJvbSB0aGUgQ09TRSBXRyBbMV0uIE9uZSBwb3RlbnRpYWwg bmV4dCBzdGVwIGlzIHRvIG1vdmUgYWxsDQo+ICAgICAgICA+IENPU0UtcmVsYXRlZCBJQU5BIHJl Z2lzdHJhdGlvbnMgZnJvbSB0aGlzIGRyYWZ0IHRvIGEgc2VwYXJhdGUgQ09TRQ0KPiAgICAgICAg PiBkcmFmdCBhbmQgbWFrZSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UuDQo+DQo+ICAgICAgICA+ ICBbMV0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3NlL3FHbmdkdGU0 czNTRVpFS00teEJFb1hZVWdLYy8NCj4NCj4gICAgSSB1bmRlcnN0YW5kaW5nIHNwbGl0dGluZyB0 aGUgZG9jdW1lbnQgc28gdGhhdCBpdCBpcyBlYXNpZXIgdG8gdXBkYXRlLA0KPiAgICBidXQgSSB0 aGluayB0aGF0IHRoZSByZWZlcmVuY2Ugc2hvdWxkIGJlIG5vcm1hdGl2ZS4NCj4NCj4gICAgSSB0 aGluayB3ZSB3YW50IHRvIHB1Ymxpc2ggdGhlIGRvY3VtZW50cyB0b2dldGhlci4NCg0KDQrvu78+ IE9uIDIwMjEtMDgtMjMsIDIxOjQyLCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiB3 cm90ZToNCj4NCj4gID4gT25lIHBvdGVudGlhbCBuZXh0IHN0ZXAgaXMgdG8gbW92ZSBhbGwgQ09T RS1yZWxhdGVkIElBTkEgcmVnaXN0cmF0aW9ucyBmcm9tIHRoaXMgZHJhZnQNCj4gdG8gYSBzZXBh cmF0ZSBDT1NFIGRyYWZ0IGFuZCBtYWtlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZS4NCj4NCj4g ICAgV2h5Pw0KPg0KDQoNClRoZSByZWdpc3RyYXRpb25zIGluIHF1ZXN0aW9uIGFyZSBpbiBzZWN0 aW9uIDguNSAtICA4Ljcgb2YgZHJhZnQtaWV0Zi1sYWtlLWVkaG9jLTA5OiBUaGUgZXh0ZW5zaW9u IG9mICdraWQnIHRvIGludCAoYm90aCBhcyBhIHJlZmVyZW5jZSBhbmQgaW4gdGhlIHJlZmVyZW5j ZWQgb2JqZWN0KSBhbmQgdGhlIHJlZ2lzdHJhdGlvbiBvZiAnY3d0JyB0byBzaWduaWZ5IHRoYXQg dGhlIHZhbHVlIGlzIGEgQ1dUIG9yIFVDQ1MuDQoNCkEgZmV3IHJlYXNvbnMgaGF2ZSBiZWVuIG1l bnRpb25lZCBmb3IgbW92aW5nIHRoaXMgZnJvbSBFREhPQyB0byBhIENPU0UgZHJhZnQsIEkgZG9u J3Qga25vdyB3aGF0IGlzIG1vc3QgcmVsZXZhbnQsIGlmIGFueXRoaW5nOg0KDQoqIEluIGNhc2Ug b2YgJ2tpZCcsIHRoZXNlIHJlZ2lzdHJhdGlvbnMgd291bGQgbWFrZSBFREhPQyBhbiB1cGRhdGUg b2YgZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtc3RydWN0IChSRkMtdG8tYmUgOTA1MikuIEkg ZG9uJ3Qga25vdyBpZiBMQUtFIG9yIENPU0Ugd2FudHMgdGhhdC4gDQoNCiogVGhlc2UgcmVnaXN0 cmF0aW9ucyBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlIGJhc2UgRURIT0MgcHJvdG9jb2wsIGJ1dCBl bmFibGVzIHRoZSB1c2Ugb2YgQ1dUIGFuZCBVQ0NTIGFzIGNyZWRlbnRpYWxzLCBhbmQgbW9yZSBj b21wYWN0IGlkZW50aWZpY2F0aW9uIG9mIGNyZWRlbnRpYWxzLiBUaGVyZWZvcmUgdGhleSBjb3Vs ZCBpbnN0ZWFkIGJlIHJlZmVyZW5jZWQgZnJvbSBFREhPQy4gSSBkb24ndCBzZWUgd2h5IHRoZSBy ZWZlcmVuY2UgbmVlZHMgdG8gYmUgbm9ybWF0aXZlLg0KDQoqIFRoZXNlIHJlZ2lzdHJhdGlvbnMg YmVsb25nIHRvIHRoZSBDT1NFIGRvbWFpbiBhbmQgbWF5IGdhaW4gYmV0dGVyIGF3YXJlbmVzcyBh bmQgcmV2aWV3cyBpZiBwdXQgaW50byBhIENPU0UgZHJhZnQuDQoNCg0KR8O2cmFuDQoNCg0KDQoN Cg0KDQoNCg0K From nobody Tue Aug 24 01:05:33 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4FC3A1205; Tue, 24 Aug 2021 01:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eLPngu8jHJ6x; Tue, 24 Aug 2021 01:04:58 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A120E3A120B; Tue, 24 Aug 2021 01:04:57 -0700 (PDT) Received: from [192.168.217.118] (p548dc8d5.dip0.t-ipconnect.de [84.141.200.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Gv1qV3lzBz2xMf; Tue, 24 Aug 2021 10:04:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Tue, 24 Aug 2021 10:04:54 +0200 Cc: Michael Richardson , "lake@ietf.org" , "cose@ietf.org" X-Mao-Original-Outgoing-Id: 651485093.932134-fbcf59e2806a7dad65bb3ef6bd8cfe21 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [COSE] [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 08:05:06 -0000 I see. So, you are saying, this will be a =E2=80=9Cusing EDHOC in COSE=E2=80=9D = specification, still normative, but referenced from EDHOC as informative = as EDHOC works without COSE. Yes, it is always hard to position a =E2=80=9Cusing X in Y=E2=80=9D = draft between the X and Y working groups =E2=80=94 after all, the two = ends of this draft need to fit X and Y, respectively. If the EDHOC = specification truly doesn=E2=80=99t need the contents of this = specification, then I can see moving them into a COSE document. But I = think it is as expedient to keep them together in one document. The = only strong reason to split the document would be to avoid a long wait = while COSE is deciding on some controversial content of the extracted = spec. Do we foresee such a delay? Gr=C3=BC=C3=9Fe, Carsten > On 2021-08-24, at 09:35, G=C3=B6ran Selander = wrote: >=20 > Combining the responses from Carsten and Michael, and including COSE. >=20 >> On 2021-08-23, 19:17, "Michael Richardson" wrote: >>=20 >> G=C3=B6ran Selander wrote: >>> * The key identifier =E2=80=98kid=E2=80=99 is extended to also = support CBOR ints, >>> making =E2=80=98kid2=E2=80=99 introduced in -08 redundant. This = change was based on >>> feedback from the COSE WG [1]. One potential next step is to move = all >>> COSE-related IANA registrations from this draft to a separate COSE >>> draft and make an informative reference. >>=20 >>> [1] = https://mailarchive.ietf.org/arch/msg/cose/qGngdte4s3SEZEKM-xBEoXYUgKc/ >>=20 >> I understanding splitting the document so that it is easier to = update, >> but I think that the reference should be normative. >>=20 >> I think we want to publish the documents together. >=20 >=20 > =EF=BB=BF> On 2021-08-23, 21:42, "Carsten Bormann" = wrote: >>=20 >>> One potential next step is to move all COSE-related IANA = registrations from this draft >> to a separate COSE draft and make an informative reference. >>=20 >> Why? >>=20 >=20 >=20 > The registrations in question are in section 8.5 - 8.7 of = draft-ietf-lake-edhoc-09: The extension of 'kid' to int (both as a = reference and in the referenced object) and the registration of 'cwt' to = signify that the value is a CWT or UCCS. >=20 > A few reasons have been mentioned for moving this from EDHOC to a COSE = draft, I don't know what is most relevant, if anything: >=20 > * In case of 'kid', these registrations would make EDHOC an update of = draft-ietf-cose-rfc8152bis-struct (RFC-to-be 9052). I don't know if LAKE = or COSE wants that.=20 >=20 > * These registrations are independent of the base EDHOC protocol, but = enables the use of CWT and UCCS as credentials, and more compact = identification of credentials. Therefore they could instead be = referenced from EDHOC. I don't see why the reference needs to be = normative. >=20 > * These registrations belong to the COSE domain and may gain better = awareness and reviews if put into a COSE draft. >=20 >=20 > G=C3=B6ran >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Lake mailing list > Lake@ietf.org > https://www.ietf.org/mailman/listinfo/lake From nobody Tue Aug 24 04:44:00 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44D3A0976; Tue, 24 Aug 2021 04:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 3qAyb5ZOuxjl; Tue, 24 Aug 2021 04:43:46 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130088.outbound.protection.outlook.com [40.107.13.88]) (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 207503A0971; Tue, 24 Aug 2021 04:43:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hihIHUUrytR5wW/XMUD6PSftbq1ZULr8otyMg75iiyjif0Ok9Q1LJ08x3pRl2L23HBMU/Stu3ZqgWoObuGkIFX7b0K0PMTddD4M5173dutfJVXtvHe49C4mlQ3azXlAsCMy3w5xqRkGE6cQ3iFYeK4zYx4FpysuSIZVFZoCueH/UJqOWi5QDYsFahpMpbmxT8ER2d2C1/bqmODxK6/3/4qgOOa65VU++uultdG2Bh/kY7GmOpvRBpIcMtTox3BDJpAWtMzWvW8SqbJWFB6huoC0KNJyTni5/0DKFrN9AgXhacxD49e5opsF97HL7zRxyMqqUb+ZlyxybeaF+r+KdOA== 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=LBFqNGshbI9kyKAZTPhp8Qtk6REKxm68+tlMBp9ALx4=; b=QO9JogmKdvXQmzQzvc+Egx03WRagXcTJ1f1xZ093WCG1/TVwSRFFNPsD3iUy6AxQUk3OJ5Eutm24J+RtyN/54qW7FYrZo+cWrs8paq9Pydi9GSYp4RpSC+rsvYkJ+rWcfWR3BhsTlYQllUJxBsoaZyJVD/fHFsf/544JPCotIPU8yxrT/Bg3zj+VjPImmfKQ9kAuQdlup1oGsPfuJCJO1uVsD+ZXKuGI5US0/EkE3v4LIY+dkZyqmspL9rYSDzgMfv3huv6tOgJhvzu//ncFO2khlb3vB4GFvQb8VWkTaUgHy18Qw71qBPyR6lBl+TeLR/sYwvo2odyXEgJWbOs8JA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LBFqNGshbI9kyKAZTPhp8Qtk6REKxm68+tlMBp9ALx4=; b=azMdhYMd3Zm5nWGxnpACOSOT1EddV8Lo4yRIcXcUKMmd6z2AqIF1Ay+EjGj2wBlojE7tmk9u/sHTIlf3BV5Gt0CFN4hQx/jTMIUP7pkuYNnrA6d8gZbwd3qQtU6LQInOGgI3J3LsSo1FW7YwnTW4+M+cDcAO6QdI3ojB5WpIBZ4= Received: from HE1PR07MB3500.eurprd07.prod.outlook.com (2603:10a6:7:31::20) by HE1PR0701MB2873.eurprd07.prod.outlook.com (2603:10a6:3:57::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.16; Tue, 24 Aug 2021 11:43:42 +0000 Received: from HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::a141:8e66:ce19:813d]) by HE1PR07MB3500.eurprd07.prod.outlook.com ([fe80::a141:8e66:ce19:813d%7]) with mapi id 15.20.4457.012; Tue, 24 Aug 2021 11:43:42 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= CC: "lake@ietf.org" , Michael Richardson , "cose@ietf.org" Thread-Topic: [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt) Thread-Index: AQHXmL7KYK+58ihZ20OCTsJpG7tgCquCqpwA Date: Tue, 24 Aug 2021 11:43:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7729428e-7c9e-4a78-f6a0-08d966f46c84 x-ms-traffictypediagnostic: HE1PR0701MB2873: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hB9+FWxzPlZmlHumCW/9e8HHL7/3RnLN8exGS2ILe63z5cO+30t6LQiwUFZ6sBsPinYeooDfCVYwypqDK5V0lOYD/wThSosotFKj0hRyS1RFtila8DKzQeyIF6+H5ES2RppR4RLU2FeP5tFf+fPpn4iNHWz8Dp/qVx1RuLL79XyHp+xYT2/Z78fJHNmjWWsG6+fGoFwpu4OGSrjs7BmBfMgo0y/0gq5skNl1MmnXRz2PYBQfJzUdsKZpUiL4lGaMbNVFVpdppojMrJwP9hfz/ZnJ1eiEe03BGZ8Pj8qOvntfrcVX3bth+m7C2RFwS82E5KMIEkcYjyhum1cqMr8cXj5ezrGyN0nJsfAIB/4AXkd580HMO8b8ARGafDkcdTMZWptUrDFieQDb1lG8BEJJCzMXfSeVZfLeZZtNbAsjLMVkN7bmPXjEx4hwb11SBh4OFWoUsJccVDg242WcLmb7Drspm2HD/d+o/BLaXf1ByxJzioIpWpS5pvW2fdlpyPoDnTttSPdqq4grGsSM5XtRvmoESiHo6EnMb0t/CQX3++laqZOVgxaTzuYBqeh3NItV80YRgapFINf+IBUFb7P1SQv0B1AHgWNrT4U5UhkHQJfuwebrmIH8hOZbL1ktqegxTUqkyb2w5ZEJ3f4X73xnb6jWs95TwYLHAL+oc5h3v3R0MyAJCIo2DBfsix47qlJn+MWTpe1oSM3HglVjhunVL1gNtoZCYiRN/Ut58+N8FOQMNf60ialGioS3bgDZmkZ6cpF39Ci6P9UnJN9q4v66b9qYs8bf9pwtUrsfjhpalGaT5bfc6/jOrCY5/gR0IL54 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3500.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(83380400001)(38070700005)(64756008)(33656002)(508600001)(66446008)(66556008)(38100700002)(66946007)(15650500001)(6506007)(26005)(66574015)(5660300002)(71200400001)(4326008)(66476007)(186003)(53546011)(2906002)(85182001)(6486002)(110136005)(2616005)(36756003)(316002)(85202003)(54906003)(76116006)(122000001)(6512007)(8676002)(86362001)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OXFRZlhXdXluWWh3NGU0U2pVTXovSlh0K3c2ZWFGMC9hcEVaL3RtQlMwTUlP?= =?utf-8?B?MCtzL2poeXJCSGJ1ek5NRm8yQlBraFNUSzJlRnZQSHNwZGZoN3MwZU90d2tw?= =?utf-8?B?RlNWWStwNFErc2VhU1FEclpDelR3VTFTUmx4N1RYdWp6SmpOSE5WbnBhWG1E?= =?utf-8?B?V2d2bGo4NnhGbmptK2NqY3BweW5HRFhxdjBodU96RmxWcHhSL2lPcWtWU29H?= =?utf-8?B?N01xRGFxbkJFRU9ZVVZ3Q09XdkdrQ203NHdhQi95bS9Kc05scjBFSnBSNnV3?= =?utf-8?B?c1FnUStReWRPVDRoTmFZMWJQUXBzcjUvbWoxQkVsRGdjTEtra0FlNGoxSERa?= =?utf-8?B?YUVQM1lGVE94YjIwWFZ5Mzd2aVJIUXZXazg2bVBVWjhnTkl4TElKUmdGdktR?= =?utf-8?B?Y2kvQVpvUTFlM21Rby9GNis2WkpMS1hVTEQrb1BjbFpLUnV3NmIrLzB1Z1FY?= =?utf-8?B?c2VUOGt1ZXpLZUVDNENMOTZXT0dNSW5Yc0NTMW03bWZvUVFMMXhzSmhOVFFB?= =?utf-8?B?RVRJdDVrbjFHNEhrYjBzUTJEWUdaWmRONGhFaFVEREVFRHZhN1N0M1ptTmNH?= =?utf-8?B?ellaMUFYSVg4cHB5RTNlSTF1SGJnUzlYYlZ2c2dnMkZXVUsrY3Q2cnd0NDdC?= =?utf-8?B?QXhUaGlMeFhLbnY3Q2sveDJYS0hqd1lISk9MbXBmYm9RalI1VFJJd096czY1?= =?utf-8?B?NkdMbGxybURjMjJMS1k5SkJhZE5yZHl4QkZIbE1EZnRVMFpWNTY4TS80ZWU5?= =?utf-8?B?U2hEek1leFhreHVBZUFSS2xLMExYckZIWnhLUTFLdnM1dkZhUnhqVTFJQ3ds?= =?utf-8?B?WHJxZG9TYVVxMUppYTNjeDd2UVJLdnkwS0VjOHcwcFduazZ2alNKSG9IbUNZ?= =?utf-8?B?RzJyWDg5a3l0aXNXUDJ5TXlBcXBvbCtFMHhDSW9HOC9JWXdYNUdDZ055Ulls?= =?utf-8?B?WUJLY3Z2enBXZUlPME1qTysxTGkzOWlRNVE1T2JFSDhRZFBFS3cwd1c2bVp5?= =?utf-8?B?bGU0cTRYckhCVVlSdGkzQnBrSkVpbGZ0NnlHcUZoWC9LL3IyUWNXUGIzTHM3?= =?utf-8?B?ZlpqZ3l0OTcxcFpaY0p1eFJ2U0c3ZmtTS085S2pBa0toSXN1THdHOHZpQXR2?= =?utf-8?B?WS9uWnZUSXBtSUs5b3EwRHQ0R1o4Vi9GSXZFdjhNc2NBMGo2VUlPQnR6Ykxj?= =?utf-8?B?SDJ2Qm5RN1dtL1NzWDlHMEgzaFdyZHllczFRM2VZczgrbVB2OTNKUEE1ZFg4?= =?utf-8?B?M1cybGVQajJwNUVrN1Y1dzdUZWswRkx5VkoyLzI4ZkxDLzJPUmsvc1RBdWQw?= =?utf-8?B?c054SjZCZHk1YStRMW1SeTFxNEU1M050WkF0WlFRVjAwY21Za0d4blk3aTdo?= =?utf-8?B?YmNmRkltdXhiWkJjeSt1ZVV2djM5L1JLdTZHcU5ibVZ1TERGTGtaM3FFQ251?= =?utf-8?B?U1l3Kys1aklJSnNXaGdJcDFnTWhQNkc4aWMvK3BHZDY4MC9vVWRFQzFtWTBq?= =?utf-8?B?VnpES1ZvbE9pVWhaMEtvTTBtWVErQ28rbkFKVnphcDlUbGtldFNXSzJwQ25R?= =?utf-8?B?MzU3MUM0Q1lSWXlpZ3VBVFlyaDU0L3VuekM1cVdZOURjU0hZM0V5dHBsbldZ?= =?utf-8?B?VGNleTNJVW8wQXEwV21UalNpamxncmRBaWpGY1JCU0phSE5oVVNwc2phSi9h?= =?utf-8?B?SWFpUlludHd6SGNuUXdLREdGVlE0Nkx3S05XaTdLcGZVOUlweXdMWHhRWXlx?= =?utf-8?B?aE9tNGRSb0x3Wm4vZ1ZxUGZGbDhWODB5cTZ1aUFEZGhBZHZzNUcweW9QZmU5?= =?utf-8?B?ckpPeDdTL0FiOTNGdWQ4dz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1A42AEB31A31DE4BB1B50CB4B3A844B2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3500.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7729428e-7c9e-4a78-f6a0-08d966f46c84 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2021 11:43:42.6373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JdTf4SstYIdk0oCTJSi8XDH0mhcZZEnlZ7yTOinLy/5fNW3LsONhAXyJm27ZEntFYkgYnwQhy1LTvwgWURfAeXyVwX6nn99Nknm0EoFrmOs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2873 Archived-At: Subject: Re: [COSE] [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 11:43:53 -0000 DQoNCu+7vz4gT24gMjAyMS0wOC0yNCwgMTA6MDUsICJMYWtlIG9uIGJlaGFsZiBvZiBDYXJzdGVu IEJvcm1hbm4iIDxsYWtlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNhYm9AdHppLm9y Zz4gd3JvdGU6DQo+DQo+ICAgIEkgc2VlLg0KPg0KPiAgICBTbywgeW91IGFyZSBzYXlpbmcsIHRo aXMgd2lsbCBiZSBhIOKAnHVzaW5nIEVESE9DIGluIENPU0XigJ0gc3BlY2lmaWNhdGlvbiwgDQoN CldlbGwsIG90aGVycyBtYXkgYWxzbyBoYXZlIHVzZSBvZiB0aGUgQ09TRSBoZWFkZXIgZm9yIENX VC9VQ0NTLCBhbmQgdGhlIGludCB2YWx1ZSB0eXBlIG9mICdraWQnLg0KDQo+ICBzdGlsbCBub3Jt YXRpdmUsIGJ1dCByZWZlcmVuY2VkIGZyb20gRURIT0MgYXMgaW5mb3JtYXRpdmUgYXMgDQo+ICAg RURIT0Mgd29ya3Mgd2l0aG91dCBDT1NFLg0KDQpXZWxsLCBFREhPQyBpcyBkZWZpbml0ZWx5IGRl cGVuZGVudCBvbiBDT1NFLCBidXQgZG9lcyBub3QgcmVxdWlyZSB0aGVzZSBwYXJ0aWN1bGFyIGNy ZWRlbnRpYWxzIG9yIGlkZW50aWZpZXJzLg0KDQo+ICAgWWVzLCBpdCBpcyBhbHdheXMgaGFyZCB0 byBwb3NpdGlvbiBhIOKAnHVzaW5nIFggaW4gWeKAnSBkcmFmdCBiZXR3ZWVuIHRoZSBYIGFuZCBZ IHdvcmtpbmcgZ3JvdXBzIOKAlCBhZnRlciBhbGwsIHRoZSB0d28gZW5kcyBvZiB0aGlzIGRyYWZ0 IG5lZWQgDQo+ICAgdG8gZml0IFggYW5kIFksIHJlc3BlY3RpdmVseS4gIElmIHRoZSBFREhPQyBz cGVjaWZpY2F0aW9uIHRydWx5IGRvZXNu4oCZdCBuZWVkIHRoZSBjb250ZW50cyBvZiB0aGlzIHNw ZWNpZmljYXRpb24sIHRoZW4gSSBjYW4gc2VlIG1vdmluZyB0aGVtDQo+ICAgaW50byBhIENPU0Ug ZG9jdW1lbnQuICBCdXQgSSB0aGluayBpdCBpcyBhcyBleHBlZGllbnQgdG8ga2VlcCB0aGVtIHRv Z2V0aGVyIGluIG9uZSBkb2N1bWVudC4gIFRoZSBvbmx5IHN0cm9uZyByZWFzb24gdG8gc3BsaXQg dGhlIA0KPiAgZG9jdW1lbnQgd291bGQgYmUgdG8gYXZvaWQgYSBsb25nIHdhaXQgd2hpbGUgQ09T RSBpcyBkZWNpZGluZyBvbiBzb21lIGNvbnRyb3ZlcnNpYWwgY29udGVudCBvZiB0aGUgZXh0cmFj dGVkIHNwZWMuICBEbyB3ZSBmb3Jlc2VlIHN1Y2ggDQo+ICBhIGRlbGF5Pw0KDQpOb3QgdGhhdCBJ IGFtIGF3YXJlIG9mLiBQcmV2aW91cyBkaXNjdXNzaW9uIGluIENPU0UgaGFzIG5vdCBpbmRpY2F0 ZWQgdGhhdCB0aGlzIGlzIGNvbnRlbnRpb3VzLiBUaGUgbWFpbiB0aGluZyB3ZSBoYXZlbid0IGRp c2N1c3NlZCBpcyB0aGF0IEVESE9DIHdvdWxkIGJlIHVwZGF0aW5nIHJmYzgxNTJiaXMtc3RydWN0 Lg0KDQoNCkfDtnJhbg0KDQoNCiAgICA+IE9uIDIwMjEtMDgtMjQsIGF0IDA5OjM1LCBHw7ZyYW4g U2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCiAgICA+IA0KICAgID4gQ29tYmluaW5nIHRoZSByZXNwb25zZXMgZnJvbSBDYXJzdGVu IGFuZCBNaWNoYWVsLCBhbmQgaW5jbHVkaW5nIENPU0UuDQogICAgPiANCiAgICA+PiBPbiAyMDIx LTA4LTIzLCAxOToxNywgIk1pY2hhZWwgUmljaGFyZHNvbiIgPG1jckBzYW5kZWxtYW4uY2E+IHdy b3RlOg0KICAgID4+IA0KICAgID4+ICAgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KICAgID4+PiAq IFRoZSBrZXkgaWRlbnRpZmllciDigJhraWTigJkgaXMgZXh0ZW5kZWQgdG8gYWxzbyBzdXBwb3J0 IENCT1IgaW50cywNCiAgICA+Pj4gbWFraW5nIOKAmGtpZDLigJkgaW50cm9kdWNlZCBpbiAtMDgg cmVkdW5kYW50LiBUaGlzIGNoYW5nZSB3YXMgYmFzZWQgb24NCiAgICA+Pj4gZmVlZGJhY2sgZnJv bSB0aGUgQ09TRSBXRyBbMV0uIE9uZSBwb3RlbnRpYWwgbmV4dCBzdGVwIGlzIHRvIG1vdmUgYWxs DQogICAgPj4+IENPU0UtcmVsYXRlZCBJQU5BIHJlZ2lzdHJhdGlvbnMgZnJvbSB0aGlzIGRyYWZ0 IHRvIGEgc2VwYXJhdGUgQ09TRQ0KICAgID4+PiBkcmFmdCBhbmQgbWFrZSBhbiBpbmZvcm1hdGl2 ZSByZWZlcmVuY2UuDQogICAgPj4gDQogICAgPj4+IFsxXSBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL2Nvc2UvcUduZ2R0ZTRzM1NFWkVLTS14QkVvWFlVZ0tjLw0KICAgID4+ IA0KICAgID4+ICAgSSB1bmRlcnN0YW5kaW5nIHNwbGl0dGluZyB0aGUgZG9jdW1lbnQgc28gdGhh dCBpdCBpcyBlYXNpZXIgdG8gdXBkYXRlLA0KICAgID4+ICAgYnV0IEkgdGhpbmsgdGhhdCB0aGUg cmVmZXJlbmNlIHNob3VsZCBiZSBub3JtYXRpdmUuDQogICAgPj4gDQogICAgPj4gICBJIHRoaW5r IHdlIHdhbnQgdG8gcHVibGlzaCB0aGUgZG9jdW1lbnRzIHRvZ2V0aGVyLg0KICAgID4gDQogICAg PiANCiAgICA+ID4gT24gMjAyMS0wOC0yMywgMjE6NDIsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJv QHR6aS5vcmc+IHdyb3RlOg0KICAgID4+IA0KICAgID4+PiBPbmUgcG90ZW50aWFsIG5leHQgc3Rl cCBpcyB0byBtb3ZlIGFsbCBDT1NFLXJlbGF0ZWQgSUFOQSByZWdpc3RyYXRpb25zIGZyb20gdGhp cyBkcmFmdA0KICAgID4+IHRvIGEgc2VwYXJhdGUgQ09TRSBkcmFmdCBhbmQgbWFrZSBhbiBpbmZv cm1hdGl2ZSByZWZlcmVuY2UuDQogICAgPj4gDQogICAgPj4gICBXaHk/DQogICAgPj4gDQogICAg PiANCiAgICA+IA0KICAgID4gVGhlIHJlZ2lzdHJhdGlvbnMgaW4gcXVlc3Rpb24gYXJlIGluIHNl Y3Rpb24gOC41IC0gIDguNyBvZiBkcmFmdC1pZXRmLWxha2UtZWRob2MtMDk6IFRoZSBleHRlbnNp b24gb2YgJ2tpZCcgdG8gaW50IChib3RoIGFzIGEgcmVmZXJlbmNlIGFuZCBpbiB0aGUgcmVmZXJl bmNlZCBvYmplY3QpIGFuZCB0aGUgcmVnaXN0cmF0aW9uIG9mICdjd3QnIHRvIHNpZ25pZnkgdGhh dCB0aGUgdmFsdWUgaXMgYSBDV1Qgb3IgVUNDUy4NCiAgICA+IA0KICAgID4gQSBmZXcgcmVhc29u cyBoYXZlIGJlZW4gbWVudGlvbmVkIGZvciBtb3ZpbmcgdGhpcyBmcm9tIEVESE9DIHRvIGEgQ09T RSBkcmFmdCwgSSBkb24ndCBrbm93IHdoYXQgaXMgbW9zdCByZWxldmFudCwgaWYgYW55dGhpbmc6 DQogICAgPiANCiAgICA+ICogSW4gY2FzZSBvZiAna2lkJywgdGhlc2UgcmVnaXN0cmF0aW9ucyB3 b3VsZCBtYWtlIEVESE9DIGFuIHVwZGF0ZSBvZiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1z dHJ1Y3QgKFJGQy10by1iZSA5MDUyKS4gSSBkb24ndCBrbm93IGlmIExBS0Ugb3IgQ09TRSB3YW50 cyB0aGF0LiANCiAgICA+IA0KICAgID4gKiBUaGVzZSByZWdpc3RyYXRpb25zIGFyZSBpbmRlcGVu ZGVudCBvZiB0aGUgYmFzZSBFREhPQyBwcm90b2NvbCwgYnV0IGVuYWJsZXMgdGhlIHVzZSBvZiBD V1QgYW5kIFVDQ1MgYXMgY3JlZGVudGlhbHMsIGFuZCBtb3JlIGNvbXBhY3QgaWRlbnRpZmljYXRp b24gb2YgY3JlZGVudGlhbHMuIFRoZXJlZm9yZSB0aGV5IGNvdWxkIGluc3RlYWQgYmUgcmVmZXJl bmNlZCBmcm9tIEVESE9DLiBJIGRvbid0IHNlZSB3aHkgdGhlIHJlZmVyZW5jZSBuZWVkcyB0byBi ZSBub3JtYXRpdmUuDQogICAgPiANCiAgICA+ICogVGhlc2UgcmVnaXN0cmF0aW9ucyBiZWxvbmcg dG8gdGhlIENPU0UgZG9tYWluIGFuZCBtYXkgZ2FpbiBiZXR0ZXIgYXdhcmVuZXNzIGFuZCByZXZp ZXdzIGlmIHB1dCBpbnRvIGEgQ09TRSBkcmFmdC4NCiAgICA+IA0KICAgID4gDQogICAgPiBHw7Zy YW4NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+ IA0KICAgID4gDQogICAgPiAtLSANCiAgICA+IExha2UgbWFpbGluZyBsaXN0DQogICAgPiBMYWtl QGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xh a2UNCg0KICAgIC0tIA0KICAgIExha2UgbWFpbGluZyBsaXN0DQogICAgTGFrZUBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFrZQ0KDQo= From nobody Tue Aug 24 14:44:49 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CFC3A14DB; Tue, 24 Aug 2021 14:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se 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 rHtYRAMYfwff; Tue, 24 Aug 2021 14:44:32 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2064.outbound.protection.outlook.com [40.107.20.64]) (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 6E6053A14CA; Tue, 24 Aug 2021 14:44:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RWY6y+tCn5sODcs98kf8bpsDACNxKqJzScJDJDNPqK7RIhBshhWwY0uiCyh1OwyK9X80Q9HNkemQPBRV0640pJycI15AdfsmEY7O06GoQk6VQN2BUzS1JaYF8EA1t87xq+H17sNYY/RGDC7uGBRn6PiapgDGC7Joy3x2NRY3gw3ZNLmZn4qhlY0CWkU9jB0fwb5XHhTDna7ElWih4r/Nl8dRx+3T4EdlvBzYO1cTHe7kAIrLMQoy4XdZ/sFvPdXBJ0rHTu8tZSUlMUy+Vpseyvuskdep1ZRVOpc/D56jZUI84hOdY++9ay0RYOXUw4izN8eUd0j7SNXks9ICObjRXA== 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=OyPEKfUi/2yfWoUmFAIijvAed7wIPXY0n1W/15J4V5I=; b=T+tcMBtRFDwtLSdIhPpq13tgqEuq5uu1EoMlNhq7B1PZRSG9QS60MitYuLdV0vVgv+cErk0WPLqcQi563dDxybNPm8kHsYbnRP9W3CG5gDVnIH9hEzy5wMbRFLUJXq5PDuJKRXs1SpSaqk7kCenGOw7SgVGD2kbISNq2S7q5rIGc6p6ThTtpKUyDxGNFb0hY+34Qg0EeO3TaXL29d+Mg40JL2RbAmsuuse/0oiyr2pvuREeERGqyfoaq1qwma90GlzfimX/aStzNQcip4O6txzrqqcujYRhv+W5tangyUbUoh49UlgwGURoI6mjbdQY9cDmwc0lI5V2n3aWckQGPSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OyPEKfUi/2yfWoUmFAIijvAed7wIPXY0n1W/15J4V5I=; b=Dv2uqn0jRuMCQG9iH8lpZfuIPIbZ/6zf3Z1W0VsSjHoWQ/AELf6OqPSZ5q3WJwVtNraB3AhdhnUShCNxtR1BLAQhdsLrNpASCo6QEUSPuVU5zw45xjVpIqab7lh6PfV15ctUgi/KOdaVLB5fJNvnsSac7MEtELqA9GmnbZlitrg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0040.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Tue, 24 Aug 2021 21:44:27 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::b5dd:2dd6:3ef0:1f59]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::b5dd:2dd6:3ef0:1f59%6]) with mapi id 15.20.4457.017; Tue, 24 Aug 2021 21:44:26 +0000 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Carsten Bormann Cc: "lake@ietf.org" , Michael Richardson , "cose@ietf.org" References: From: Marco Tiloca Message-ID: Date: Tue, 24 Aug 2021 23:44:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KXGIma3IURjnTt0r7T6G5UG6cfkwfBZnr" X-ClientProxiedBy: HE1PR0901CA0048.eurprd09.prod.outlook.com (2603:10a6:3:45::16) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.7] (185.219.140.60) by HE1PR0901CA0048.eurprd09.prod.outlook.com (2603:10a6:3:45::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Tue, 24 Aug 2021 21:44:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 79003ab5-a741-4415-0759-08d967485810 X-MS-TrafficTypeDiagnostic: DB6P18901MB0040: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uJO6lH/pKLSxHeG6dPloqAND2xmdMGolvp3WQNZUOwQoOqfMNo+R7Ymqvj3riCiC/4NLqc6q442LQSIrV5cR5Af1LpKdITHfC0LrKlv+1kMeG4hYRU8ThLBQ/ORSKixb+o2dIBaHczv4pel4Ut6uCPCG2qot4t0GAcdDtdZWbh0ueCKkG2a5RoMviU98M/eeYGQJryrZtcA8yMjtYMRHqRVx+1SHkweXuj308zliVo0n+jstYVz89M8uf04bkXux3EmYLGtN+6cPcUFqqCTuuLAaA1AriRzXem4WRUxug1OK0VtLof9PXXmCjytbXVJXMU+msydPagMGis2xiquGe4/bl6zMTNiSSq5r4nmzsjzpAElypDANGdNl1EdkizoTZ1iHx5ADLrU6LTHhpQ8Q52xOi143WedueAM1rZoyRptLOgJmQy9wrD3qUv7z8oGZu6easa60OKV1Zy+YXOQv4J//dNgYraIbW7UFcILQNAnfBTnbC5cJ+p7U7OUdRR3zAD310jEj6BMfKu/hd208XHmLN90qRFpJdRv+WUVfUozEPdHnU68Hka4J/uF6KpkJQDhLHWvFNerGEq2C9rmlqGVPmngLwFFRcpvFr8ex63HKxKXQe0GXbTyhhC5v/HonUGlxw4nqN+crUO3FOZgeQcHXllm9pYGdWeNisGWMWML52P4qHc4ktOJ/5oDkYPTejDgR3VEl7BPF0gdmxcG1fL15dFEDLdvCcJojf9sacgHfo2sGvPGOXq6PSZZWbKuTYX6CUCTiWspHR9hX5wDHnkstUIYZVGCCng5WwcTYM2CrmBpI87eHK9Dq/rPnIpvQ X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(396003)(366004)(136003)(376002)(346002)(316002)(16576012)(66574015)(33964004)(31686004)(83380400001)(54906003)(36756003)(2906002)(110136005)(53546011)(5660300002)(235185007)(31696002)(66476007)(21480400003)(8676002)(966005)(186003)(6486002)(44832011)(38100700002)(66556008)(66946007)(26005)(478600001)(4326008)(15650500001)(45080400002)(8936002)(2616005)(956004)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a2tIMWNicjNqUkNDMjVwRFpWSjVabmZBS3ZDVVhDanM1KzZ3QkFwZmlrTlhM?= =?utf-8?B?TEgzc01QR0tCeHNudmtuTCtKL0JVSjRNRm9hQm1PQVl1dTlsS1MzbUxoK3pF?= =?utf-8?B?ZFp5MEJrU2dlV3IwR0Z5bzl4QUNST3BodnZaamNXRGphUUtBQndMUjBmNTg5?= =?utf-8?B?dVU3RXhpMmw3UlZFbjZsNStLVjdnRHhEZnZaQmVUU3VCMElzS0RMN1Qyd0pn?= =?utf-8?B?TkxvVFNSUkhUeVY0aWlsMDdDaXFoTm83aXNGRzJEVnBFc0FIZEk3aUFrdzFy?= =?utf-8?B?ZVhGTlg1cXhSMW4yUWpCQVYzU2gvckhUV1VxL0RxS1hBT1p6eFZSUnBLK0lF?= =?utf-8?B?c01qN2tTcGtScHJEY05laWZhMk1RR1cyaWVaeEludlN0cUJFTUlTR01hMjVT?= =?utf-8?B?MFNmR20wUzBMQjI4TWNwK29oS29IY3BCZXl2VkVUN1VhdjNoR2VSU2g4aUNk?= =?utf-8?B?cXNlcG5VQXpZWS9IWnZaZnVaeEd2SVVEYWJCRm5PbmNYVWd3NHFJeVR6RUlU?= =?utf-8?B?dU04YVhRMnFjZnp0MlBlek0zUE5ZditYbmw4S09kZUw5REdlWHZvTFpJNFdz?= =?utf-8?B?UER5cUdXdXYvUzg3d0MveXFIZjkyYkJEQWVnOWszQ2g2Y3JEQU43c3VhSmti?= =?utf-8?B?MlpkS2wwWnFtRkdoazgvTi9xK0FjbFBBN3BKM1VqRlhFOE91Qk9DaHpZU01M?= =?utf-8?B?Y0kyR0pwejNkTXdYanMxOEs0Yzlmd2pXNUhXZXVKbDE4NUxRZDB6KzQxdUEr?= =?utf-8?B?M3F6Q3JpMU15a0g1WW1CdHR1RHhhRnZsQTI5SXVrdlpoUjlMNmliaTJtci9t?= =?utf-8?B?VmhoakJ6WDJaTWQ1QVZQalg1d2ZNanUxbWFXWW5sZmFpY1YzbnNGaDBqaW03?= =?utf-8?B?clNWU2RzdzVDZnF2SWlrNkwxUVB4ZDdIejBmZEc4aUw2QlloWnp3RVZRODUx?= =?utf-8?B?Zlg4L3N0UmJ6TjF5MXM3azErMHBxMXB1U0tsVFpKdnFhM1pyTWNCSXRkYTIr?= =?utf-8?B?andubndGWWxDK2cxbFRzWU8rWVNKMjdoMWdxRzVpcHJPZjJYN0dqZGVrMWF0?= =?utf-8?B?cU1wUjRmSDFqQ1BHeDUwRllyejQ1L09uWFJBYldobkN5Wi9IZ0RoWDU1bVU5?= =?utf-8?B?S3p3Q0xqa0thVjBnU2hXODVpMnJLbTNtaDlxTnBkeXRtWkhOcE1UbTVvTmhE?= =?utf-8?B?bWZMdTlvSzlsaWFKZGpDT3JWR0hPWEJUUG9rMWxjampBSW5YM1VGN01VRXZZ?= =?utf-8?B?TERzR0NtcnZRYTM4dUJwczdPOVJheTZJRnRpMUhGSzdHKzlpazg4UDZ0YUpt?= =?utf-8?B?ZnBQUnRTeDlOWERPaVkwaEhvL3oraEZjUWQwNjR1dklybHZURG1qQUpPWUdr?= =?utf-8?B?VmZLcUllVVNpRi9pNlM4NVFzL0JaV1JJTmx2a3V5N2pQS1ZCVm03SU1ZRFFI?= =?utf-8?B?NDdHLzhsSGtiaXFWNVFsM0MvbWNZNkUyVXZOTXNVR24rOE8rbk1yNCtJY1ZR?= =?utf-8?B?bWdjK05MdXFZUUFCZjdBZlo4cEFKNmgzUEh6Tmk3VndHWlcrMEJ4QUFGOTJ4?= =?utf-8?B?ckN5bkR1cXVCdnp3MkpISFgrM2I3WFMxenV0U1BRcXNhWXZZVVVPVWtJTTlm?= =?utf-8?B?NkgwckNDWk5WRmUrVVVjQW14Ukk1bVM2LzJHQXE1eW9wRjdSOU0wbGVPbkt3?= =?utf-8?B?UVlTWmxUVERzTGp4dENtVElSTHNSWDd5L0ZKeXZjS1NkckExUmNzVWUzLzJI?= =?utf-8?Q?NztbyNDLT9WohJColfIzJxBBzSwduuJwKo4DmgH?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 79003ab5-a741-4415-0759-08d967485810 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2021 21:44:26.6230 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BtMksA/xIx+bXIif07ZaBDQmJiXLRrjutgMbAKiVowPgrWgSzkNDNbksZviayK7Eoy9JDdhrJ45f7AsmVBNNSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0040 Archived-At: Subject: Re: [COSE] [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 21:44:43 -0000 --KXGIma3IURjnTt0r7T6G5UG6cfkwfBZnr Content-Type: multipart/mixed; boundary="yg4EpaK4herK4YudmQlqARD3rCo5rHCCh"; protected-headers="v1" From: Marco Tiloca To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Carsten Bormann Cc: "lake@ietf.org" , Michael Richardson , "cose@ietf.org" Message-ID: Subject: Re: [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt) References: In-Reply-To: --yg4EpaK4herK4YudmQlqARD3rCo5rHCCh Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, On 2021-08-24 13:43, G=C3=B6ran Selander wrote: > > =EF=BB=BF> On 2021-08-24, 10:05, "Lake on behalf of Carsten Bormann" wrote: >> I see. >> >> So, you are saying, this will be a =E2=80=9Cusing EDHOC in COSE=E2= =80=9D specification, > Well, others may also have use of the COSE header for CWT/UCCS, and the= int value type of 'kid'. =3D=3D>MT Yes, the ACE KDC for group communication [1] and especially the ACE=20 Group Manager for Group OSCORE [2] now use (the Labels of) COSE Header=20 Parameters as values for the 'pub_key_enc' parameter. This parameter indicates the format of public keys used in the group.=20 The possible formats include also CWT/UCCS under pending registration;=20 see for instance the paragraphs about 'pub_key_enc' in Sections 6.1 and=20 6.4 of [2]. Best, /Marco [1] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ [2] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/= <=3D=3D > >> still normative, but referenced from EDHOC as informative as >> EDHOC works without COSE. > Well, EDHOC is definitely dependent on COSE, but does not require these= particular credentials or identifiers. > >> Yes, it is always hard to position a =E2=80=9Cusing X in Y=E2=80=9D= draft between the X and Y working groups =E2=80=94 after all, the two en= ds of this draft need >> to fit X and Y, respectively. If the EDHOC specification truly doe= sn=E2=80=99t need the contents of this specification, then I can see movi= ng them >> into a COSE document. But I think it is as expedient to keep them = together in one document. The only strong reason to split the >> document would be to avoid a long wait while COSE is deciding on som= e controversial content of the extracted spec. Do we foresee such >> a delay? > Not that I am aware of. Previous discussion in COSE has not indicated t= hat this is contentious. The main thing we haven't discussed is that EDHO= C would be updating rfc8152bis-struct. > > > G=C3=B6ran > > > > On 2021-08-24, at 09:35, G=C3=B6ran Selander wrote: > > > > Combining the responses from Carsten and Michael, and including = COSE. > > > >> On 2021-08-23, 19:17, "Michael Richardson" w= rote: > >> > >> G=C3=B6ran Selander wrote: > >>> * The key identifier =E2=80=98kid=E2=80=99 is extended to also= support CBOR ints, > >>> making =E2=80=98kid2=E2=80=99 introduced in -08 redundant. Thi= s change was based on > >>> feedback from the COSE WG [1]. One potential next step is to m= ove all > >>> COSE-related IANA registrations from this draft to a separate = COSE > >>> draft and make an informative reference. > >> > >>> [1] https://eur02.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcose%2FqGngdte4s3SEZEKM-xBE= oXYUgKc%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cfb94e5e14e9a419b9f= 1008d966f47a4b%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6376540224863= 32814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DTVx5osodCud2uoLxWalRjnpX3fH%2B= DexH0iXEhdYrsEw%3D&reserved=3D0 > >> > >> I understanding splitting the document so that it is easier t= o update, > >> but I think that the reference should be normative. > >> > >> I think we want to publish the documents together. > > > > > > > On 2021-08-23, 21:42, "Carsten Bormann" wrote: > >> > >>> One potential next step is to move all COSE-related IANA regis= trations from this draft > >> to a separate COSE draft and make an informative reference. > >> > >> Why? > >> > > > > > > The registrations in question are in section 8.5 - 8.7 of draft= -ietf-lake-edhoc-09: The extension of 'kid' to int (both as a reference a= nd in the referenced object) and the registration of 'cwt' to signify tha= t the value is a CWT or UCCS. > > > > A few reasons have been mentioned for moving this from EDHOC to = a COSE draft, I don't know what is most relevant, if anything: > > > > * In case of 'kid', these registrations would make EDHOC an upda= te of draft-ietf-cose-rfc8152bis-struct (RFC-to-be 9052). I don't know if= LAKE or COSE wants that. > > > > * These registrations are independent of the base EDHOC protocol= , but enables the use of CWT and UCCS as credentials, and more compact id= entification of credentials. Therefore they could instead be referenced f= rom EDHOC. I don't see why the reference needs to be normative. > > > > * These registrations belong to the COSE domain and may gain bet= ter awareness and reviews if put into a COSE draft. > > > > > > G=C3=B6ran > > > > > > > > > > > > > > > > > > -- > > Lake mailing list > > Lake@ietf.org > > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake&data=3D04%7C01%7Cmarco.t= iloca%40ri.se%7Cfb94e5e14e9a419b9f1008d966f47a4b%7C5a9809cf0bcb413a838a09= ecc40cc9e8%7C0%7C0%7C637654022486332814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat= a=3DLAdEidnDbp7NLyMG1ZWXU2PHFUoIn9Im2%2Bg9vQa50KI%3D&reserved=3D0 > > -- > Lake mailing list > Lake@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake&data=3D04%7C01%7Cmarco.til= oca%40ri.se%7Cfb94e5e14e9a419b9f1008d966f47a4b%7C5a9809cf0bcb413a838a09ec= c40cc9e8%7C0%7C0%7C637654022486332814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4= wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D= LAdEidnDbp7NLyMG1ZWXU2PHFUoIn9Im2%2Bg9vQa50KI%3D&reserved=3D0 > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --yg4EpaK4herK4YudmQlqARD3rCo5rHCCh-- --KXGIma3IURjnTt0r7T6G5UG6cfkwfBZnr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmElaDgFAwAAAAAACgkQ7iZktA5Y2kMj pQf/Rxo4zBPJc9Hp+znEUe2bYIKoiALq9lhb0830NmUqop9i/lvJcAQf7jELCCCBFdaY2TQvG1sY mA/0bYoeliHW6kznpCSthuW3ChvPLzlrblQVzCFSPeXS4tXzWvmaPLXSfgL+yMJQdU1XLXyzRFJW 9ONH+UF05dlbUTPqGbIOfgj7fJJzIZBgmkXnuZMv84fmMIfjdYSMkdxmeEiOXEUDuNSp6hu5FoMp ccKgDJqfElnMIWlhz2PPU5Pxkh8nK4ucuyccjBIx9ItVrPCcB54QBlo5DBAu+HNPr/8zaLY1d7X3 lTzkKNsNh/aRm0sAN07y3FbQiXH8m/6X5lKITOQXAg== =7xnw -----END PGP SIGNATURE----- --KXGIma3IURjnTt0r7T6G5UG6cfkwfBZnr-- From nobody Tue Aug 31 21:19:26 2021 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D113A11AD; Tue, 31 Aug 2021 21:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rPlKByI5oDUw; Tue, 31 Aug 2021 21:19:08 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4874C3A11A0; Tue, 31 Aug 2021 21:19:08 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1814IuRJ014879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Sep 2021 00:19:02 -0400 Date: Tue, 31 Aug 2021 21:18:55 -0700 From: Benjamin Kaduk To: =?iso-8859-1?Q?G=F6ran?= Selander Cc: Carsten Bormann , "lake@ietf.org" , Michael Richardson , "cose@ietf.org" Message-ID: <20210901041855.GI96301@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [COSE] [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 04:19:14 -0000 On Tue, Aug 24, 2021 at 11:43:42AM +0000, Göran Selander wrote: > > > > On 2021-08-24, 10:05, "Lake on behalf of Carsten Bormann" wrote: > > > > I see. > > > > So, you are saying, this will be a “using EDHOC in COSE” specification, > > Well, others may also have use of the COSE header for CWT/UCCS, and the int value type of 'kid'. > > > still normative, but referenced from EDHOC as informative as > > EDHOC works without COSE. > > Well, EDHOC is definitely dependent on COSE, but does not require these particular credentials or identifiers. > > > Yes, it is always hard to position a “using X in Y” draft between the X and Y working groups — after all, the two ends of this draft need > > to fit X and Y, respectively. If the EDHOC specification truly doesn’t need the contents of this specification, then I can see moving them > > into a COSE document. But I think it is as expedient to keep them together in one document. The only strong reason to split the > > document would be to avoid a long wait while COSE is deciding on some controversial content of the extracted spec. Do we foresee such > > a delay? > > Not that I am aware of. Previous discussion in COSE has not indicated that this is contentious. The main thing we haven't discussed is that EDHOC would be updating rfc8152bis-struct. I think it would invite questions of charter scope if a document from LAKE attempted to update rfc8152bis-struct; keeping that work in COSE seems likely to have an easier path, process-wise. -Ben