From nobody Mon May 4 00:42:55 2020 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 049803A0D2B; Mon, 4 May 2020 00:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 fwTuqZqqjzLf; Mon, 4 May 2020 00:42:46 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2079.outbound.protection.outlook.com [40.107.21.79]) (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 232363A0D28; Mon, 4 May 2020 00:42:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GZ76euCQjoFKWuaNGmyhVjMS4VVjTNviEG2bFUX0N18/l1QLBwc+eqDKAduMZl3I6U3UsDKujLtkUaL2jOu4AMNFLo4WWaQYBlI5AF/68/KXO81ZEtaONPaGkiDU2sxiQiP5tCxypeB6kuO2tXgFm9Klj3bB3FOROY/xRtDN/CS9Eu2l+k7HXPTU6O/jb9P4EgMMEcwo7Cg74hO906MJLWT3EiBWDW3cAlDlF6clHQixNIgYLeE7AO+8PjU7k9lqvvq1cpLXSQG0EQ1H4RcYBVXcdRERY8gLlyuZJC6iseAp2e7rlmJvqxOnyYjI5R0Ct0sl9lWZalt6syIlebhXWQ== 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=5lTkkMs9964C0qrIjdMKZ/WCZWCGA9ZuGV92NMrUbcc=; b=b6b/etdva4YmSjxZRKnA9u1TrtstB095tXHZ7bqTdXw3MyKF0DJ9UM5dEeTMYH3tnAmxVSQkA+OwLrTfiJGd7KesktbObqC7VIfKgMbP3h9rilDCHN7MaUn3Ej3TUfm0QAsfT036/TGSed8sQxF4WPzhh5IKF0GyCyYjDwn84olqga5p2KYLdQ67CkNE9zl6EVkwwAnKCnq4A7y8IB+aglaZuIVHVP1W808+TsgbA2K0qMH00a3OYUHQoLKcFg5K+VsyPtJY7QwIwZjk+RB4zh7Bps8QMZt7bmRzuielJI1v8g8/l9dt7zmYrofRsaNx5/7ammH3GzYbN6kBs/iALQ== 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=5lTkkMs9964C0qrIjdMKZ/WCZWCGA9ZuGV92NMrUbcc=; b=QSj3AHAWkso0qTrcn25J4qzHl7DUekb2nxICRDg0abZ3ssA6Nee8Av+cG38CRWZF6m4AFd43ipRm9u3Gkn2A9ZyOxiTfXBbK0v+j3xjxXSY/SSkFKPUGxw+lLl/8LfrZ4Aca+XRsKYpiaczZZP1phSEd5+26fKb1vflVP0fzA70= Received: from AM7PR07MB6945.eurprd07.prod.outlook.com (2603:10a6:20b:1bf::11) by AM7PR07MB6945.eurprd07.prod.outlook.com (2603:10a6:20b:1bf::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Mon, 4 May 2020 07:42:42 +0000 Received: from AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931]) by AM7PR07MB6945.eurprd07.prod.outlook.com ([fe80::55ba:3006:67fc:f931%7]) with mapi id 15.20.2979.024; Mon, 4 May 2020 07:42:42 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Laurence Lundblade , "cose@ietf.org" , "ace@ietf.org" , "ace-chairs@ietf.org" , "cose-chairs@ietf.org" , Benjamin Kaduk CC: =?utf-8?B?Sm9lbCBIw7ZnbHVuZA==?= Thread-Topic: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt Thread-Index: AQHWHL9/AQkz8jksrU+IVD0bq1nzAqiOdicAgAN8fICABcSUAA== Date: Mon, 4 May 2020 07:42:42 +0000 Message-ID: References: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> <3BB4FFA8-AABD-4520-9B21-1F0B0CAFB08C@ericsson.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.36.20041300 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-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c58777e-8b71-4e00-888e-08d7effebaad x-ms-traffictypediagnostic: AM7PR07MB6945: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03932714EB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xVjQRVJwjWPwgvULWEiuH+XtKUy/iw1+xjpAMM70xhGjLmTn8vGK7fVamrxDfJ3UQATSHCaeW+jvUZDSXrjS5QqWMNWBItwVBK3sgK4vtlv/pgiMHpDzlskNBCqUw7L2r3rc9x9XQPlkK0v5ZywBIpTACh5D3zsl+D88qBIxEl4l+Qz7E3wiw9nm+LjcgzKnr2X/zJJOySuRZJKJc/C/Vm7FDZAs7uCrp2J3dDHbhnlV6naPxx58fVKjSYsz90yJ1w/+NKnVmchK5hMA8x3oySYvSelAsTfjtPsR08EGwAthjEyxBcsBNmHIjI6M1LAJ9dHF0KMJKE0CTZExuYKlxB8oqQUZ6wt7ABsvUM7MtBe2747+tWtacay774OB+SkklWs3eb+qoW3pr7ToidqaDxpcFirhu9FHCNAgaiogVUGqnYJCpAplh31TYFOCzl3mKtWoZ668BZ0b3bRDK2RwslhM+UZiUykBG5C0g8p5RlVa7Bzeb8mYHhurh43rd3SinTa6SgqJqphqYsavHKJfEw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6945.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(85182001)(36756003)(2906002)(186003)(85202003)(71200400001)(6486002)(53546011)(8936002)(8676002)(26005)(6506007)(316002)(110136005)(4326008)(6512007)(66946007)(966005)(478600001)(66574012)(33656002)(66556008)(66476007)(76116006)(5660300002)(66446008)(64756008)(86362001)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fzL3WARG+P3TJyofjCHtIk73LxdZRZ4CsXcd75k19MzdOpqYDazwP1Mn6C0WOlBBkUgSxVFkcvzfrGAIJYJLW8zZe/clGWNJaxYE4uZpQO+4f/LsKUC3sUSdYAyqgNas+niugEui95pYae3urbh4DhEamKzmULoBdJUNMJZrBPGYL6Kb27qd1zquf1jwfymHr8NG+lILVvyzmqXIycE9bumeadBo58bnQfgWBqPvn9TULjwLYBEVF1S0LC/fMHXHIB+Lacm+8PSuY5CAUVg9/RTDdNBTtkDVDSVdjSb/lZUVn5Usw+K9ZVSGRjKs896agJ29oRKXzYf4OPkPY/R+U/iYDyHv/K7f3zkowAl8X2f0vQHmhFEtC3rNPviPZ9nMFBFx5OBwPnu0/S/p2ScisU7lu+4XCoK14oqIpPrIUAkPkM/+aj8Cu0qeC5O0ILIuoEkz/TxRXQpXUt7uM2Qfel7ZheHobMCZtjPiid28NU7Ic65tjBL8s/hS/u0YEnhaf30HSVZErfv5aSWxUf7zXVQ6D/g2A9g+MirXLzGKx1GlPYdfk+H50bjz6jp61WBf0F++/J9WVbloynwzfYPuDXl0grEoKJ3+XRbljZ1TrlQiUTuAo02v3aZNHpS1yyblnmoV6jQUyvyj87UF7reovjaIPzMcNglAmL5Fjuu1fJbkByP51FAVjloQqYT4RDzYNMFAhqwaeGT2Z98/pHJtYSx8I0T6P47dWQOWoetPvr2MITs8dMrwwUxcctajx0kbT/q1dghbN+2Qhz8b93/C8URyIY3h3FDYf+ODElEHXGM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c58777e-8b71-4e00-888e-08d7effebaad X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 07:42:42.8204 (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: ovmrP30zwHWf9SWLqiDLkZVTBvHlwUem9z5Cefw/270aw9Kkt1lOm4twhftHoHxdoPR2Pbz94pb95gzA+7ec2dmtVvwchhP8BbEa6er95MQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6945 Archived-At: Subject: Re: [COSE] [Ace] draft-raza-ace-cbor-certificates-04.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: Mon, 04 May 2020 07:42:49 -0000 --_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVuY2UsIGFuZCBhbGwsDQoNClRoYW5rcyBmb3IgcHJvdmlkaW5nIGEgdGF4b25vbXku IEFzIG1lbnRpb25lZCwgdHlwZSAwIGlzIGNsZWFybHkgaW4gdGhlIGN1cnJlbnQgZHJhZnQgQ09T RSBjaGFydGVyLCBhbmQgd2Ugc2VlIGFsc28gdGhlIG5lZWQgZm9yIGEgcmVwcmVzZW50YXRpb24g b2YgdGhlIFguNTA5IHByb2ZpbGUgaW4gUkZDIDc5MjUgd2hpY2ggcmVsaWV2ZXMgY29uc3RyYWlu ZWQgZGV2aWNlcyBmcm9tIGltcGxlbWVudGluZyBERVIvQVNOLjEgZW5jb2RpbmcgYXMgd2VsbCBh cyByZS1lbmNvZGluZy9kZWNvbXByZXNzaW5nIGluIG9yZGVyIHRvIHZlcmlmeS4gV2hldGhlciB0 aGlzIGlzIHR5cGUgMSBhcyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQsIG9yIHR5cGUgMiBhcyB5b3Ug cHJvcG9zZSwgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbi4gSSBiZWxpZXZlIEkgc3BlYWsgb24gYmVo YWxmIG9mIHRoZSBhdXRob3JzIGhlcmUuDQoNCkEgcXVlc3Rpb24gZm9yIHRoZSBjaGFpcnMgYW5k IEFEOiBJcyBpdC9jYW4gaXQgYmUgaW4gdGhlIHNjb3BlIG9mIENPU0Ugb3IgQUNFIHRvIGRlZmlu ZSB0eXBlIDEvMj8gT3IgZG8geW91IG5lZWQgbW9yZSBzaG93IG9mIGludGVyZXN0IGZyb20gdGhl IGNvbW11bml0eSB0byBzZWUgaWYgdGhpcyBpcyB3b3J0aCBwdXJzdWluZyBhdCBhbGw/DQoNCkfD tnJhbg0KDQoNCg0KRnJvbTogTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5j b20+DQpEYXRlOiBUaHVyc2RheSwgMzAgQXByaWwgMjAyMCBhdCAxOTozOA0KVG86IEfDtnJhbiBT ZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPg0KQ2M6IEfDtnJhbiBTZWxhbmRl ciA8Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+LCBKb2VsIEjD tmdsdW5kIDxqb2VsLmhvZ2x1bmRAZ21haWwuY29tPiwgImNvc2VAaWV0Zi5vcmciIDxjb3NlQGll dGYub3JnPiwgImFjZUBpZXRmLm9yZyIgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWNl XSBbQ09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0DQoNCkhpIEfD tnJhbiwNCg0KSSB1bmRlcnN0YW5kIHlvdXIgdHdvIHR5cGVzIG9mIG5hdGl2ZSBDQk9SIGNlcnRz LCBhbmQgcmFpc2UgeW91IGJ5IG9uZS4gSeKAmXZlIGFzc3VtZWQgQ09TRSBiZWNhdXNlIGl0IHNl ZW1zIGEgY2xlYXIgY2hvaWNlIHRvIG1lIChubyBzaXplIGlzc3VlLCBjb2RlIHJlIHVzZSkuDQoN CjApIENvbXByZXNzZWQvcmUtZW5jb2RlZA0KLSBVc2VzIENCT1IgU2VxdWVuY2UgdGhhdCBleGFj dGx5IG1pcnJvcnMgWC41MDkgZnJvbSBSYXphIGRyYWZ0DQotIFJlZHVjZXMgc2l6ZSBvZiBjZXJ0 LCBidXQgaW5jcmVhc2VkIGNvZGUgY29tcGxleGl0eTsgYm90aCBDQk9SIGFuZCBERVIgZW5jb2Rp bmcgLyBkZWNvZGluZyBuZWVkZWQNCi0gQ2FuIHRyYW5zZm9ybSB0by9mcm9tIFguNTA5IG1lY2hh bmljYWxseSB3aXRob3V0IHRoZSBwcml2YXRlIGtleQ0KDQoxKSBDT1NFICsgTWlycm9yaW5nIHdp dGggQ0JPUiBTZXF1ZW5jZSBmcm9tIFJhemEgZHJhZnQNCi0gVXNlcyB0aGUgQ0JPUiBzZXF1ZW5j ZSB0aGF0IGV4YWN0bHkgbWlycm9ycyBYLjUwOQ0KLSBSZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQg bG93ZXJzIGNvZGUgY29tcGxleGl0eTsgbm8gREVSIGVuY29kaW5nIC8gZGVjb2RpbmcNCi0gTXVz dCBoYXZlIHByaXZhdGUga2V5IHRvIGdlbmVyYXRlOyBtdXN0IGJlIGdlbmVyYXRlZCBieSB0aGUg Q0ENCg0KMikgQ09TRSArIE1pcnJvcmluZyB3aXRoIENXVCBDbGFpbXMNCi0gQSBzZXQgb2YgQ1dU IGNsYWltcyBhcmUgZGVmaW5lZCB0aGF0IGV4YWN0bHkgbWlycm9yIFguNTA5IGZpZWxkcw0KLSBS ZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQgbG93ZXJzIGNvZGUgY29tcGxleGl0eTsgbm8gREVSIGVu Y29kaW5nIC8gZGVjb2Rpbmc7IGNhbiByZSB1c2Ugc29tZSBDV1QgY29kZQ0KLSBNdXN0IGhhdmUg cHJpdmF0ZSBrZXkgdG8gZ2VuZXJhdGU7IG11c3QgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBDQQ0KDQoz KSBDT1NFICsgSW1wcm92ZWQgQ1dUIENsYWltcw0KLSBBIHNldCBvZiBDV1QgY2xhaW1zIHRoYXQg ZG9u4oCZdCBuZWNlc3NhcmlseSBtaXJyb3IgWC41MDkgZXhhY3RseSwgYnV0IGdpdmUgc2ltaWxh ciBzZW1hbnRpY3MNCi0gUmVkdWNlcyBzaXplIG9mIGNlcnQgYW5kIGxvd2VycyBjb2RlIGNvbXBs ZXhpdHk7IG5vIERFUiBlbmNvZGluZyAvIGRlY29kaW5nOyBjYW4gcmUgdXNlIHNvbWUgQ1dUIGNv ZGUNCi0gTXVzdCBoYXZlIHByaXZhdGUga2V5IHRvIGdlbmVyYXRlOyBtdXN0IGJlIGdlbmVyYXRl ZCBieSB0aGUgQ0ENCg0KSSB3YXMgZGVmaW5pdGVseSB0YWxraW5nIGFib3V0IDMpIGluIG15IGxh c3QgZW1haWwuIEl0IGlzIGNsZWFybHkgbm90IGluIHRoZSBjaGFydGVyLg0KDQpTbyBtYXliZSB0 aGUgZGViYXRlIGlzIGJldHdlZW4gMSkgYW5kIDIpLiBCb3RoIGFyZSBpbiB0aGUgY2hhcnRlci4g U29tZSBhZHZhbnRhZ2VzIG9mIDIpIGFyZToNCi0gQ2FuIHJlIHVzZSBzb21lIG9mIHRoZSBDV1Qg Y29kZQ0KLSBDYW4gbW92ZSB0byAzKSBpbmNyZW1lbnRhbGx5IHdoZW4gdGhlIHRpbWUgY29tZXMN Ci0gQ2FuIGRyb3AgZmllbGRzIHRoYXQgYXJlIG5vdCB1c2VkIHBvc3NpYmx5IGdpdmluZyB0aGUg c21hbGxlc3QgY2VydCBzaXplIG9uIHRoZSB3aXJlIG9mIGFueSBvZiB0aGUgb3B0aW9ucw0KDQpM TA0KDQoNCg0KDQpPbiBBcHIgMjgsIDIwMjAsIGF0IDM6MjMgQU0sIEfDtnJhbiBTZWxhbmRlciA8 Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb20+PiB3cm90ZToNCg0KSGkgTGF1cmVuY2UsDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3Vy IHRob3VnaHRzLiBJdCBzZWVtcyB3ZSBhcmUgd29ya2luZyBvbiBzbGlnaHRseSBkaWZmZXJlbnQg cGF0aHMuDQoNClRoZSBwYXJ0IHlvdSBjYWxsZWQg4oCcQ29tcHJlc3NlZCBDZXJ0c+KAnSBpcyBh bHJlYWR5IGluIHRoZSBkcmFmdCBDT1NFIGNoYXJ0ZXIgd2hlcmUgaXQgaXMgcmVmZXJyZWQgdG8g YXMg4oCcQSBDQk9SIGVuY29kaW5nIG9mIHRoZSBjb21wcmVzc2VkIGNlcnRpZmljYXRlIHByb2Zp bGUgZGVmaW5lZCBpbiBSRkMgNzkyNeKAnSBzbyB3ZSBjYW4gbGVhdmUgdGhhdCBvdXQgZm9yIG5v dy4NCg0KTXkgY29tbWVudCB3YXMgYWJvdXQgdGhlIG90aGVyIHBhcnQsIHdoYXQgd2UgYm90aCBj YWxsIOKAnG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlc+KAnSBidXQgbWVhbiBkaWZmZXJlbnQgdGhp bmdzLiBXaGF0IGlzIGNhbGxlZCBuYXRpdmUgaW4NCmRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlm aWNhdGVzIGlzIG5vdCBpbnRlbmRlZCBhcyBhIGNlcnRpZmljYXRlIGZvcm1hdCBicmVha2luZyB3 aXRoIFguNTA5LiBXaGlsZSB0aGVyZSBhcmUgbWFueSBwb3RlbnRpYWwgaW1wcm92ZW1lbnRzIHRv IG1ha2Ugb24gWC41MDksIHRoZXJlIGlzIGEgcmVzaXN0YW5jZSBhZ2FpbnN0IG5ldyBjZXJ0aWZp Y2F0ZSBhcmNoaXRlY3R1cmVzIGFzIHdhcyBjbGVhciB3aGVuIHRoaXMgd2FzIGJyb3VnaHQgdXAg aW4gU2VjZGlzcGF0Y2ggYXQgSUVURiAxMDQgYSB5ZWFyIGFnby4gQXMgbWVudGlvbmVkIHByZXZp b3VzbHksIHdoYXQgd2UgbWVhbiBieSDigJxuYXRpdmUgQ0JPUuKAnSBpcyB0aGUgbG9zc2xlc3Mg Y29tcHJlc3Npb24gb2YgdGhlIGNlcnRpZmljYXRlIHByb2ZpbGUgb2YgWC41MDkgaW50byBhIENC T1IgZW5jb2RlZCBmb3JtYXQsIGJ1dCBzaWduaW5nIG92ZXIgdGhlIENCT1IgaW5zdGVhZCBvZiBv biB0aGUgdW5jb21wcmVzc2VkIGRhdGEuIEluIHRoaXMgd2F5IGl0IGlzIHBvc3NpYmxlIHRvIGRl ZmluZSBhIGJpamVjdGlvbiBiZXR3ZWVuIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBhbmQgcHJv ZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzIOKAkyB0aGUgcGF5bG9hZCBvZiB0aGUgY29tcHJlc3Nl ZCB2ZXJzaW9uIG9mIHRoZSBsYXR0ZXIgd291bGQgYmUgaWRlbnRpY2FsIHRvIHRoZSBmb3JtZXIu IFNvIHRoZSBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMgYXJlIGEgZmFpdGhmdWwgcmVwcmVzZW50 YXRpb24gb2YgdGhlc2UgcHJvZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzLCB1c2luZyB0aGUgc2Ft ZSBwYXlsb2FkIGFzIGluIHRoZSBDQk9SIGNvbXByZXNzaW9uIHNjaGVtZS4NCg0KSW4gY29udHJh c3QgdG8gdGhlIGNvbXByZXNzaW9uIHNjaGVtZSwgYSBjb252ZXJzaW9uIGJldHdlZW4gbmF0aXZl IENCT1IgYW5kIFguNTA5IHJlcHJlc2VudGF0aW9ucyByZXF1aXJlcyBhY2Nlc3MgdG8gdGhlIHBy aXZhdGUgc2lnbmF0dXJlIGtleS4NClRoZXJlZm9yZSBhIG1peCBvZiBYLjUwOSBhbmQgbmF0aXZl IENCT1Igd291bGQgcmVxdWlyZSBtdWx0aXBsZSBoYW5kbGVycyBhdCB0aGUgYmFja2VuZCAocGFy c2luZyB0aGUgcGF5bG9hZCB3b3VsZCBiZSB0aGUgc2FtZSkuIERlZGljYXRlZCBkZXBsb3ltZW50 cyBjb3VsZCBvZiBjb3Vyc2UgdXNlIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBleGNsdXNpdmVs eS4NCg0KSW4gdGhlIHNhbWUgd2F5IGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGluc3RlYWQgZGVm aW5lIGEgQ09TRV9TaWduMSBhbmQvb3IgYSBDV1QgcmVwcmVzZW50aW5nIHRoZXNlIHByb2ZpbGVk IFguNTA5IGNlcnRpZmljYXRlcywgdGhpcyBpcyB3aGF0IEkgdGhvdWdodCB5b3Ugd2VyZSBhc2tp bmcgYWJvdXQgYnV0IGFwcGFyZW50bHkgbm90LiBUaGF0IHdvdWxkIGJlIGFuIGFsdGVybmF0aXZl IGFzIGxvbmcgYXMgd2UgY2FuIGRlY2lkZSBvbiBleGFjdGx5IG9uZSBvZiB0aGVzZSByZXByZXNl bnRhdGlvbnMuDQoNClRoZXJlIGFyZSBhIGxvdCBvZiBmdW4gdGhpbmdzIHRvIGRvIGluIHRoaXMg c3BhY2UsIG15IGNvbmNlcm4gaXMgaG93IHRvIGdldCBvdXQgYSBzdGFuZGFyZC4gVHJ5aW5nIHRv IHJlcGxhY2UgWC41MDkgZG9lc27igJl0IHNlZW0gbGlrZSBhIHByb21pc2luZyB3YXkgZm9yd2Fy ZCBJ4oCZbSBhZnJhaWQgLiAuIC4NCg0KR8O2cmFuDQoNCg0KRnJvbTogQWNlIDxhY2UtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTGF1 cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb208bWFpbHRvOmxnbEBpc2xhbmQt cmVzb3J0LmNvbT4+DQpEYXRlOiBNb25kYXksIDI3IEFwcmlsIDIwMjAgYXQgMjA6MTMNClRvOiBH w7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzpnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+ DQpDYzogSm9lbCBIw7ZnbHVuZCA8am9lbC5ob2dsdW5kQGdtYWlsLmNvbTxtYWlsdG86am9lbC5o b2dsdW5kQGdtYWlsLmNvbT4+LCAiY29zZUBpZXRmLm9yZzxtYWlsdG86Y29zZUBpZXRmLm9yZz4i IDxjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPj4sICJhY2VAaWV0Zi5vcmc8bWFp bHRvOmFjZUBpZXRmLm9yZz4iIDxhY2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW0FjZV0gW0NPU0VdIGRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVz LTA0LnR4dA0KDQoNCk9uIEFwciAyNywgMjAyMCwgYXQgNTowMCBBTSwgR8O2cmFuIFNlbGFuZGVy IDxnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Z29y YW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KW0dT XSBUaGUgcmF0aW9uYWxlIGZvciBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMgaXMgdG8gcmV1c2Ug dGhlIHNhbWUgZW5jb2RpbmcgYXMgaW4gdGhlIGNvbXByZXNzaW9uIHNjaGVtZSBkZWZpbmVkIGZv ciBSRkMgNzkyNSwgYnV0IHNpZ25pbmcgdGhlIENCT1IgaW5zdGVhZCBvZiBzaWduaW5nIHRoZSB1 bmNvbXByZXNzZWQgZGF0YS4gVGhpcyBwcm92aWRlcyBhIHJvYWRtYXAgd2l0aCBtaW5pbWFsIGNo YW5nZXMgd2hlbiBtb3ZpbmcgZnJvbSBjb21wcmVzc2VkIHRvIG5hdGl2ZSBDQk9SIGNlcnRpZmlj YXRlcy4NCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBvdmVyaGVhZCBvZiBDT1NFX1NpZ24x IG9yIENXVCBpcyBub3QgbWFqb3IgYW5kIHRoZXNlIHBvaW50cyBhcmUgb3BlbiBmb3IgZGlzY3Vz c2lvbi4gVGhlIG1vcmUgaW1wb3J0YW50IHF1ZXN0aW9uIGlzIHdoZXJlIHRoaXMgc2hvdWxkIGJl IHN0YW5kYXJkaXplZC4gVGhlIGNvbXByZXNzaW9uIHNjaGVtZSBpcyBub3cgaW5jbHVkZWQgaW4g dGhlIG5ldyBkcmFmdCBjaGFydGVyIGZvciBDT1NFOg0KaHR0cHM6Ly9naXRodWIuY29tL2Nvc2Ut d2cvQ2hhcnRlci9ibG9iL21hc3Rlci9DaGFydGVyLm1kPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5 ZS5jb20vdjEvdXJsP2s9ZGQxMjc3MDktODE5YmQ4YzAtZGQxMjM3OTItMGNjNDdhZDkzZTFjLTVi NmJhZTg0YWJjNWM0YTAmcT0xJmU9NWJiNDEyZmEtZWMxZC00NGEwLThkYmEtYzY2ODQ0ZDFiNzk3 JnU9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGY29zZS13ZyUyRkNoYXJ0ZXIlMkZibG9iJTJG bWFzdGVyJTJGQ2hhcnRlci5tZD4NClRoZSBjaGFydGVyIGlzIGN1cnJlbnRseSBub3QgZXhwbGlj aXRseSBzdXBwb3J0aW5nIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcy4gSWYgeW91IHRoaW5rIGl0 IHNob3VsZCwgaW4gc29tZSB2YXJpYW50LCB0aGVuIHRoaXMgaXMgYSBnb29kIHRpbWUgdG8gcmFp c2UgeW91ciB2b2ljZS4NCg0KVG8gZ28gc3RyYWlnaHQgdG8gdGhlIGlzc3VlLCBJIHRoaW5rIGEg ZGVzaWduaW5nIGEgbmF0aXZlIENCT1IgY2VydCBzaG91bGQgYmUgYXBwcm9hY2hlZCBkaWZmZXJl bnRseSB0aGFuIGNvbXByZXNzaW5nIC8gcmUtZW5jb2RpbmcgYW4gWC41MDkgY2VydDoNCg0KUmUt ZW5jb2RpbmcNCi0gU2l6ZSBpcyBpbXBvcnRhbnQNCi0gRXhhY3QgY29tcGF0aWJpbGl0eSBpcyBy ZXF1aXJlZA0KLSBOZWFyIHplcm8gY2hhbmdlIHRvIGZpZWxkcyBhbmQgc2VtYW50aWNzDQoNCk5h dGl2ZSBDQk9SIENlcnQNCi0gQ2xlYW4gdXAgc29tZSBvZiB0aGUgbWVzcyBpbiBYLjUwOTsgaXQg aXMgYW4gb2xkIHN0YW5kYXJkIHdpdGggYSBsb3Qgb2YgY3J1ZnQgYW5kIGJhZ2dhZ2UNCi0gUmUg ZGVzaWduIGV4dGVuc2lvbnMgc28gdGhleSBhcmUgaW4gQ0JPUiBmb3JtYXQNCi0gTWFrZSBtYW55 IG9mIHRoZSBmaWVsZHMgb3B0aW9uYWwsIGZvciBleGFtcGxlIG5vdCBiZWZvcmUgY2FuIG9mdGVu IGJlIGxlZnQgb2ZmLCBtYXliZSBldmVuIHNlcmlhbCBudW1iZXINCi0gQXZvaWQgRE4gc3RydWN0 dXJlIGZvciBpc3N1ZXIgYW5kIHN1YmplY3QgZm9yIG1vc3QgdXNlIGNhc2VzDQotIFVzZSBtb2Rl cm4gZm9ybWF0cyBsaWtlIENPU0UgYW5kIENXVCBhbmQgQ09TRV9LZXkNCi0gU2l6ZSBpcyBpbXBv cnRhbnQsIGJ1dCBmYXIgZnJvbSB0aGUgb25seSBnb2FsIChzb21lIHNpemUgcmVkdWN0aW9ucywg bGlrZSBvcHRpb25hbCBmaWVsZHMgd2lsbCBiZSBwb3NzaWJsZSBoZXJlIHRoYXQgYXJlIG5vdCBw b3NzaWJsZSB3aXRoIHJlLWVuY29kaW5nKQ0KLSBDb21wYXRpYmlsaXR5IG1hdHRlcnMsIGJ1dCBu b3QgaW4gdGhlIHNhbWUgd2F5DQoNClNlZW1zIGxpa2UgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGhl cmUgaXMgdG8gcmVtb3ZlIG5hdGl2ZSBDQk9SIGNlcnRzIGZyb20gdGhpcyBkb2N1bWVudCBhbmQg anVzdCBmb2N1cyBvbiBjb21wcmVzc2lvbiBhbmQgcmUtZW5jb2RpbmcuIE1heWJlIGV2ZW4gY2Fs bCB0aGVtIOKAnENvbXByZXNzZWQgQ2VydHPigJ0gcmF0aGVyIHRoYW4g4oCcQ0JPUiBDZXJ0c+KA nS4uIFdoZXJlIHRoYXQgd29yayBzaG91bGQgZ28gaXMgYWJvdmUgbXkgcGF5IGdyYWRlLg0KDQoN CkJVVCwgbXkgbWFpbiBpbnRlcmVzdCBoZXJlIHJlbGF0ZXMgdG8gQ1dUIGFuZCBFQVQuIENXVCBz ZWVtcyBsaWtlIGEgcmVhbGx5IGdvb2QgY2hvaWNlIG9uIHdoaWNoIHRvIGJhc2UgYSBuYXRpdmUg Q0JPUiBjZXJ0LiBTb21lIG9mIHRoZSBmaWVsZHMgZm9yIGFuIFguNTA5IGNlcnQgYXJlIGFscmVh ZHkgZGVmaW5lZCBpbiBDV1QgKHN1YmplY3QsIGlzc3VlciwgZXhwaXJhdGlvbiwgbm90LWJlZm9y ZSkuIEl0IGhhcyBhbiBleHRlbnNpb24gbWVjaGFuaXNtIGJ1aWx0IGluIGFscmVhZHkgaW4gdGhl IENXVCBJQU5BIHJlZ2lzdHJ5LiBUaGUgY3J5cHRvIGFuZCBzaWduaW5nIGFyZSB3ZWxsLWhhbmRs ZWQgYnkgQ1dU4oCZcyB1c2Ugb2YgQ09TRS4NCg0KSW4gd29yayB0byBmaXQgRUFUPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhdHMtZWF0LTAzPiBpbiBhcyBhIENXVCwg YSBmZXcgaXNzdWVzIGhhdmUgY29tZSB1cCDigJQgaG93IGZpZWxkcyAvIGNsYWltcyBhcmUgbWFu YWdlZCBhbmQgcmVnaXN0ZXJlZCB3aXRoIElBTkEsIGxhYmVsIHNwYWNlcyBhbmQgb3RoZXIuICBB bGwgdGhlc2UgaXNzdWVzIHdvdWxkIGFwcGx5IHRvIENXVC9DT1NFL0NCT1ItYmFzZWQgY2VydGlm aWNhdGUgYXMgd2VsbC4NCg0KVG8gbmFtZSBqdXN0IG9uZSBpc3N1ZSwgaW4gQ1dUIHRoZSBleHBp cmF0aW9uIGRhdGUvdGltZSBjYW4gYmUgYSBmbG9hdGluZy1wb2ludCBudW1iZXIsIHdoaWNoIGlz IGJ1cmRlbnNvbWUsIG5vdCB1c2VmdWwuIFNob3VsZCB3ZSBjaGFuZ2UgQ1dUIHRvIGRpc2FsbG93 IG9yIHNob3VsZCBpdCBqdXN0IGJlIGRpc2FsbG93ZWQgd2hlbiBhIENXVCBpcyB1c2VkIGFzIGFu IEVBVCBhbmQgd2hlbiBpdCBpcyB1c2VkIGFzIGEgQ2VydD8NCg0KSeKAmW0gYWxzbyBleGNpdGVk IGF0IHRoZSBpZGVhIG9mIHJlIHVzaW5nIENXVCBpbiBhIHNpbXBsZSBmb3JtIHNvIHRoZXJlIGlz IHJlIHVzZSBvZiBjb2RlIGJldHdlZW4gQ1dULCBFQVQgYW5kIG5hdGl2ZSBDQk9SIGNlcnRzLiBJ 4oCZdmUgc3RhcnRlZCBwbGF5aW5nIHdpdGggYW4gaW1wbGVtZW50YXRpb24gbGlrZSB0aGlzLg0K DQpMTA0KDQoNCg== --_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9ImVuLVNFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBMYXVyZW5jZSwgYW5kIGFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgZm9yIHByb3ZpZGluZyBhIHRheG9ub215LiBB cyBtZW50aW9uZWQsIHR5cGUgMCBpcyBjbGVhcmx5IGluIHRoZSBjdXJyZW50IGRyYWZ0IENPU0Ug Y2hhcnRlciwgYW5kIHdlIHNlZSBhbHNvIHRoZSBuZWVkIGZvciBhIHJlcHJlc2VudGF0aW9uIG9m IHRoZSBYLjUwOSBwcm9maWxlIGluIFJGQyA3OTI1IHdoaWNoDQogcmVsaWV2ZXMgY29uc3RyYWlu ZWQgZGV2aWNlcyBmcm9tIGltcGxlbWVudGluZyBERVIvQVNOLjEgZW5jb2RpbmcgYXMgd2VsbCBh cyByZS1lbmNvZGluZy9kZWNvbXByZXNzaW5nIGluIG9yZGVyIHRvIHZlcmlmeS4gV2hldGhlciB0 aGlzIGlzIHR5cGUgMSBhcyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQsIG9yIHR5cGUgMiBhcyB5b3Ug cHJvcG9zZSwgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbi4gSSBiZWxpZXZlIEkgc3BlYWsgb24gYmVo YWxmIG9mIHRoZQ0KIGF1dGhvcnMgPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj5oZXJlLiA8L3NwYW4+DQo8L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gbGFuZz0iRU4tVVMiPkEgcXVlc3Rpb24gZm9yIHRoZSBjaGFpcnMgYW5kIEFEOiBJcyBpdC9j YW4gaXQgYmUgaW4gdGhlIHNjb3BlIG9mIENPU0Ugb3IgQUNFIHRvIGRlZmluZSB0eXBlIDEvMj8g T3IgZG8geW91IG5lZWQgbW9yZSBzaG93IG9mIGludGVyZXN0IGZyb20gdGhlIGNvbW11bml0eSB0 byBzZWUgaWYgdGhpcyBpcyB3b3J0aCBwdXJzdWluZw0KIGF0IGFsbD88bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+R8O2cmFuPG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5MYXVyZW5jZSBMdW5kYmxh ZGUgJmx0O2xnbEBpc2xhbmQtcmVzb3J0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNk YXksIDMwIEFwcmlsIDIwMjAgYXQgMTk6Mzg8YnI+DQo8Yj5UbzogPC9iPkfDtnJhbiBTZWxhbmRl ciAmbHQ7Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+R8O2 cmFuIFNlbGFuZGVyICZsdDtnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDssIEpvZWwgSMO2Z2x1bmQgJmx0O2pvZWwuaG9nbHVuZEBnbWFpbC5jb20mZ3Q7LCAm cXVvdDtjb3NlQGlldGYub3JnJnF1b3Q7ICZsdDtjb3NlQGlldGYub3JnJmd0OywgJnF1b3Q7YWNl QGlldGYub3JnJnF1b3Q7ICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbQWNlXSBbQ09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5IaSZuYnNwO0fDtnJhbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+SSB1bmRlcnN0YW5kIHlvdXIgdHdvIHR5cGVzIG9mIG5hdGl2ZSBDQk9SIGNl cnRzLCBhbmQgcmFpc2UgeW91IGJ5IG9uZS4gSeKAmXZlIGFzc3VtZWQgQ09TRSBiZWNhdXNlIGl0 IHNlZW1zIGEgY2xlYXIgY2hvaWNlIHRvIG1lIChubyBzaXplIGlzc3VlLCBjb2RlIHJlIHVzZSku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48dT4w KSBDb21wcmVzc2VkL3JlLWVuY29kZWQ8L3U+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIFVzZXMg Q0JPUiBTZXF1ZW5jZSB0aGF0IGV4YWN0bHkgbWlycm9ycyBYLjUwOSBmcm9tIFJhemEgZHJhZnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gUmVkdWNlcyBzaXplIG9mIGNlcnQsIGJ1dCBpbmNyZWFz ZWQgY29kZSBjb21wbGV4aXR5OyBib3RoIENCT1IgYW5kIERFUiBlbmNvZGluZyAvIGRlY29kaW5n IG5lZWRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBDYW4gdHJhbnNmb3JtIHRvL2Zyb20gWC41 MDkgbWVjaGFuaWNhbGx5IHdpdGhvdXQgdGhlIHByaXZhdGUga2V5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjx1PjEpIENPU0UgJiM0MzsgTWlycm9y aW5nIHdpdGggQ0JPUiBTZXF1ZW5jZSBmcm9tIFJhemEmbmJzcDtkcmFmdDwvdT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPi0gVXNlcyB0aGUgQ0JPUiBzZXF1ZW5jZSB0aGF0IGV4YWN0bHkgbWlycm9y cyBYLjUwOTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBSZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQg bG93ZXJzIGNvZGUgY29tcGxleGl0eTsgbm8gREVSIGVuY29kaW5nIC8gZGVjb2Rpbmc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPi0gTXVzdCBoYXZlIHByaXZhdGUga2V5IHRvIGdlbmVyYXRlOyBtdXN0 IGJlIGdlbmVyYXRlZCBieSB0aGUgQ0E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHU+MikgQ09TRSAmIzQzOyBNaXJyb3Jpbmcgd2l0aCBDV1QgQ2xh aW1zPC91PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBBIHNldCBvZiBDV1QgY2xhaW1zIGFyZSBk ZWZpbmVkIHRoYXQgZXhhY3RseSBtaXJyb3IgWC41MDkgZmllbGRzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+LSBSZWR1Y2VzIHNpemUgb2YgY2VydCBhbmQgbG93ZXJzIGNvZGUgY29tcGxl eGl0eTsgbm8gREVSIGVuY29kaW5nIC8gZGVjb2Rpbmc7IGNhbiByZSB1c2Ugc29tZSBDV1QgY29k ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBNdXN0IGhhdmUgcHJpdmF0 ZSBrZXkgdG8gZ2VuZXJhdGU7IG11c3QgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBDQTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 dT4zKSBDT1NFICYjNDM7IEltcHJvdmVkIENXVCBDbGFpbXM8L3U+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIEEgc2V0IG9mIENXVCBjbGFpbXMgdGhhdCBkb27igJl0IG5l Y2Vzc2FyaWx5IG1pcnJvciBYLjUwOSBleGFjdGx5LCBidXQgZ2l2ZSBzaW1pbGFyIHNlbWFudGlj czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gUmVkdWNlcyBz aXplIG9mIGNlcnQgYW5kIGxvd2VycyBjb2RlIGNvbXBsZXhpdHk7IG5vIERFUiBlbmNvZGluZyAv IGRlY29kaW5nOyBjYW4gcmUgdXNlIHNvbWUgQ1dUIGNvZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBNdXN0IGhhdmUgcHJpdmF0ZSBrZXkgdG8gZ2VuZXJh dGU7IG11c3QgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBDQTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd2FzIGRlZmluaXRlbHkgdGFsa2lu ZyBhYm91dCAzKSBpbiBteSBsYXN0IGVtYWlsLiBJdCBpcyBjbGVhcmx5IG5vdCBpbiB0aGUgY2hh cnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ U28gbWF5YmUgdGhlIGRlYmF0ZSBpcyBiZXR3ZWVuIDEpIGFuZCAyKS4gQm90aCBhcmUgaW4gdGhl IGNoYXJ0ZXIuIFNvbWUgYWR2YW50YWdlcyBvZiAyKSBhcmU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tIENhbiByZSB1c2Ugc29tZSBvZiB0aGUgQ1dUIGNvZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pi0gQ2FuIG1vdmUgdG8gMykgaW5jcmVtZW50YWxseSB3aGVuIHRoZSB0aW1lIGNvbWVzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tIENhbiBkcm9wIGZpZWxkcyB0aGF0IGFyZSBub3QgdXNlZCBwb3Nz aWJseSBnaXZpbmcgdGhlIHNtYWxsZXN0IGNlcnQgc2l6ZSBvbiB0aGUgd2lyZSBvZiBhbnkgb2Yg dGhlIG9wdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+TEw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPk9uIEFwciAyOCwgMjAyMCwgYXQgMzoyMyBBTSwgR8O2cmFuIFNlbGFuZGVyICZsdDs8YSBo cmVmPSJtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tIj5nb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBMYXVyZW5jZSw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBmb3Igc2hhcmluZyB5b3Vy IHRob3VnaHRzLiBJdCBzZWVtcyB3ZSBhcmUgd29ya2luZyBvbiBzbGlnaHRseSBkaWZmZXJlbnQg cGF0aHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg cGFydCB5b3UgY2FsbGVkIOKAnENvbXByZXNzZWQgQ2VydHPigJ0gaXMgYWxyZWFkeSBpbiB0aGUg ZHJhZnQgQ09TRSBjaGFydGVyIHdoZXJlIGl0IGlzIHJlZmVycmVkIHRvIGFzIOKAnDwvc3Bhbj5B IENCT1IgZW5jb2Rpbmcgb2YgdGhlIGNvbXByZXNzZWQgY2VydGlmaWNhdGUgcHJvZmlsZSBkZWZp bmVkIGluIFJGQyA3OTI1PHNwYW4gbGFuZz0iRU4tVVMiPuKAnQ0KIHNvIHdlIGNhbiBsZWF2ZSB0 aGF0IG91dCBmb3Igbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+TXkgY29tbWVudCB3YXMgYWJvdXQgdGhlIG90aGVyIHBhcnQsIHdoYXQgd2UgYm90aCBj YWxsIOKAnG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlc+KAnSBidXQgbWVhbiBkaWZmZXJlbnQgdGhp bmdzLiBXaGF0IGlzIGNhbGxlZCBuYXRpdmUgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5kcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlczxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+aXMgbm90IGludGVu ZGVkIGFzIGEgY2VydGlmaWNhdGUgZm9ybWF0IGJyZWFraW5nIHdpdGggWC41MDkuIFdoaWxlIHRo ZXJlIGFyZSBtYW55IHBvdGVudGlhbCBpbXByb3ZlbWVudHMgdG8gbWFrZSBvbg0KIFguNTA5LCB0 aGVyZSBpcyBhIHJlc2lzdGFuY2UgYWdhaW5zdCBuZXcgY2VydGlmaWNhdGUgYXJjaGl0ZWN0dXJl cyBhcyB3YXMgY2xlYXIgd2hlbiB0aGlzIHdhcyBicm91Z2h0IHVwIGluIFNlY2Rpc3BhdGNoIGF0 IElFVEYgMTA0IGEgeWVhciBhZ28uIEFzIG1lbnRpb25lZCBwcmV2aW91c2x5LCB3aGF0IHdlIG1l YW4gYnkg4oCcbmF0aXZlIENCT1LigJ0gaXMgdGhlIGxvc3NsZXNzIGNvbXByZXNzaW9uIG9mIHRo ZSBjZXJ0aWZpY2F0ZSBwcm9maWxlIG9mDQogWC41MDkgaW50byBhIENCT1IgZW5jb2RlZCBmb3Jt YXQsIGJ1dCBzaWduaW5nIG92ZXIgdGhlIENCT1IgaW5zdGVhZCBvZiBvbiB0aGUgdW5jb21wcmVz c2VkIGRhdGEuIEluIHRoaXMgd2F5IGl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIGJpamVjdGlv biBiZXR3ZWVuIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBhbmQgcHJvZmlsZWQgWC41MDkgY2Vy dGlmaWNhdGVzIOKAkyB0aGUgcGF5bG9hZCBvZiB0aGUgY29tcHJlc3NlZCB2ZXJzaW9uIG9mIHRo ZQ0KIGxhdHRlciB3b3VsZCBiZSBpZGVudGljYWwgdG8gdGhlIGZvcm1lci4gU28gdGhlIG5hdGl2 ZSBDQk9SIGNlcnRpZmljYXRlcyBhcmUgYSBmYWl0aGZ1bCByZXByZXNlbnRhdGlvbiBvZiB0aGVz ZSBwcm9maWxlZCBYLjUwOSBjZXJ0aWZpY2F0ZXMsIHVzaW5nIHRoZSBzYW1lIHBheWxvYWQgYXMg aW4gdGhlIENCT1IgY29tcHJlc3Npb24gc2NoZW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW4gY29udHJhc3QgdG8gdGhlIGNvbXByZXNzaW9uIHNjaGVt ZSwgYSBjb252ZXJzaW9uIGJldHdlZW4gbmF0aXZlIENCT1IgYW5kIFguNTA5IHJlcHJlc2VudGF0 aW9ucyByZXF1aXJlcyBhY2Nlc3MgdG8gdGhlIHByaXZhdGUgc2lnbmF0dXJlIGtleS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmVmb3JlIGEgbWl4 IG9mIFguNTA5IGFuZCBuYXRpdmUgQ0JPUiB3b3VsZCByZXF1aXJlIG11bHRpcGxlIGhhbmRsZXJz IGF0IHRoZSBiYWNrZW5kIChwYXJzaW5nIHRoZSBwYXlsb2FkIHdvdWxkIGJlIHRoZSBzYW1lKS4g RGVkaWNhdGVkIGRlcGxveW1lbnRzIGNvdWxkIG9mIGNvdXJzZSB1c2UgbmF0aXZlIENCT1IgY2Vy dGlmaWNhdGVzDQogZXhjbHVzaXZlbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5JbiB0aGUgc2FtZSB3YXkgaXQgd291bGQgYmUgcG9zc2libGUgdG8gaW5z dGVhZCBkZWZpbmUgYSBDT1NFX1NpZ24xIGFuZC9vciBhIENXVCByZXByZXNlbnRpbmcgdGhlc2Ug cHJvZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzLCB0aGlzIGlzIHdoYXQgSSB0aG91Z2h0IHlvdSB3 ZXJlIGFza2luZyBhYm91dCBidXQgYXBwYXJlbnRseSBub3QuDQogVGhhdCB3b3VsZCBiZSBhbiBh bHRlcm5hdGl2ZSBhcyBsb25nIGFzIHdlIGNhbiBkZWNpZGUgb24gZXhhY3RseSBvbmUgb2YgdGhl c2UgcmVwcmVzZW50YXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGhlcmUgYXJlIGEgbG90IG9mIGZ1biB0aGluZ3MgdG8gZG8gaW4gdGhpcyBzcGFj ZSwgbXkgY29uY2VybiBpcyBob3cgdG8gZ2V0IG91dCBhIHN0YW5kYXJkLiBUcnlpbmcgdG8gcmVw bGFjZSBYLjUwOSBkb2VzbuKAmXQgc2VlbSBsaWtlIGEgcHJvbWlzaW5nIHdheSBmb3J3YXJkIEni gJltIGFmcmFpZCAuIC4gLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+R8O2cmFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFjZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZS1ib3Vu Y2VzQGlldGYub3JnIj5hY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBM YXVyZW5jZQ0KIEx1bmRibGFkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxnbEBpc2xhbmQtcmVzb3J0 LmNvbSI+bGdsQGlzbGFuZC1yZXNvcnQuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9uZGF5LCAyNyBB cHJpbCAyMDIwIGF0IDIwOjEzPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Hw7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+Z29yYW4u c2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNj OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Sm9l bCBIw7ZnbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWwuaG9nbHVuZEBnbWFpbC5jb20iPmpv ZWwuaG9nbHVuZEBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvc2VA aWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29z ZUBpZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 YWNlQGlldGYub3JnIj5hY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0 bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbQWNl XSBbQ09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0PC9zcGFuPjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gQXByIDI3LCAyMDIwLCBhdCA1OjAw IEFNLCBHw7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlcj00 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5bR1NdIFRoZSByYXRpb25hbGUgZm9yIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBp cyB0byByZXVzZSB0aGUgc2FtZSBlbmNvZGluZyBhcyBpbiB0aGUgY29tcHJlc3Npb24gc2NoZW1l IGRlZmluZWQgZm9yIFJGQyA3OTI1LCBidXQgc2lnbmluZyB0aGUgQ0JPUiBpbnN0ZWFkIG9mIHNp Z25pbmcgdGhlIHVuY29tcHJlc3NlZCBkYXRhLg0KIFRoaXMgcHJvdmlkZXMgYSByb2FkbWFwIHdp dGggbWluaW1hbCBjaGFuZ2VzIHdoZW4gbW92aW5nIGZyb20gY29tcHJlc3NlZCB0byBuYXRpdmUg Q0JPUiBjZXJ0aWZpY2F0ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFncmVlIHdpdGggeW91IHRoYXQg dGhlIG92ZXJoZWFkIG9mIENPU0VfU2lnbjEgb3IgQ1dUIGlzIG5vdCBtYWpvciBhbmQgdGhlc2Ug cG9pbnRzIGFyZSBvcGVuIGZvciBkaXNjdXNzaW9uLiBUaGUgbW9yZSBpbXBvcnRhbnQgcXVlc3Rp b24gaXMgd2hlcmUgdGhpcyBzaG91bGQgYmUgc3RhbmRhcmRpemVkLiBUaGUgY29tcHJlc3Npb24N CiBzY2hlbWUgaXMgbm93IGluY2x1ZGVkIGluIHRoZSBuZXcgZHJhZnQgY2hhcnRlciBmb3IgQ09T RTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3Yx L3VybD9rPWRkMTI3NzA5LTgxOWJkOGMwLWRkMTIzNzkyLTBjYzQ3YWQ5M2UxYy01YjZiYWU4NGFi YzVjNGEwJmFtcDtxPTEmYW1wO2U9NWJiNDEyZmEtZWMxZC00NGEwLThkYmEtYzY2ODQ0ZDFiNzk3 JmFtcDt1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNvc2Utd2clMkZDaGFydGVyJTJGYmxv YiUyRm1hc3RlciUyRkNoYXJ0ZXIubWQiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL0NoYXJ0 ZXIvYmxvYi9tYXN0ZXIvQ2hhcnRlci5tZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgY2hhcnRlciBpcyBjdXJyZW50bHkgbm90IGV4cGxpY2l0bHkgc3VwcG9ydGluZyBuYXRpdmUg Q0JPUiBjZXJ0aWZpY2F0ZXMuIElmIHlvdSB0aGluayBpdCBzaG91bGQsIGluIHNvbWUgdmFyaWFu dCwgdGhlbiB0aGlzIGlzIGEgZ29vZCB0aW1lIHRvIHJhaXNlIHlvdXIgdm9pY2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VG8gZ28gc3RyYWlnaHQgdG8gdGhl IGlzc3VlLCBJIHRoaW5rIGEgZGVzaWduaW5nIGEgbmF0aXZlIENCT1IgY2VydCBzaG91bGQgYmUg YXBwcm9hY2hlZCBkaWZmZXJlbnRseSB0aGFuIGNvbXByZXNzaW5nIC8gcmUtZW5jb2RpbmcgYW4g WC41MDkgY2VydDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHU+UmUtZW5jb2Rpbmc8L3U+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4tIFNpemUgaXMgaW1wb3J0YW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIEV4YWN0IGNvbXBhdGliaWxpdHkgaXMgcmVx dWlyZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPi0gTmVhciB6ZXJvIGNoYW5nZSB0byBmaWVsZHMgYW5kIHNlbWFudGljczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48dT5OYXRpdmUgQ0JPUiBDZXJ0PC91PjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBDbGVh biB1cCBzb21lIG9mIHRoZSBtZXNzIGluIFguNTA5OyBpdCBpcyBhbiBvbGQgc3RhbmRhcmQgd2l0 aCBhIGxvdCBvZiBjcnVmdCBhbmQgYmFnZ2FnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBSZSBkZXNpZ24gZXh0ZW5zaW9u cyBzbyB0aGV5IGFyZSBpbiBDQk9SIGZvcm1hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBNYWtlIG1hbnkgb2YgdGhlIGZp ZWxkcyBvcHRpb25hbCwgZm9yIGV4YW1wbGUgbm90IGJlZm9yZSBjYW4gb2Z0ZW4gYmUgbGVmdCBv ZmYsIG1heWJlIGV2ZW4gc2VyaWFsIG51bWJlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBBdm9pZCBETiBzdHJ1Y3R1cmUg Zm9yIGlzc3VlciBhbmQgc3ViamVjdCBmb3IgbW9zdCB1c2UgY2FzZXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gVXNlIG1v ZGVybiBmb3JtYXRzIGxpa2UgQ09TRSBhbmQgQ1dUIGFuZCBDT1NFX0tleTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBTaXpl IGlzIGltcG9ydGFudCwgYnV0IGZhciBmcm9tIHRoZSBvbmx5IGdvYWwgKHNvbWUgc2l6ZSByZWR1 Y3Rpb25zLCBsaWtlIG9wdGlvbmFsIGZpZWxkcyB3aWxsIGJlIHBvc3NpYmxlIGhlcmUgdGhhdCBh cmUgbm90IHBvc3NpYmxlIHdpdGggcmUtZW5jb2RpbmcpPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIENvbXBhdGliaWxpdHkg bWF0dGVycywgYnV0IG5vdCBpbiB0aGUgc2FtZSB3YXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2Vl bXMgbGlrZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gaGVyZSBpcyB0byByZW1vdmUgbmF0aXZlIENC T1IgY2VydHMgZnJvbSB0aGlzIGRvY3VtZW50IGFuZCBqdXN0IGZvY3VzIG9uIGNvbXByZXNzaW9u IGFuZCByZS1lbmNvZGluZy4gTWF5YmUgZXZlbiBjYWxsIHRoZW0g4oCcQ29tcHJlc3NlZCBDZXJ0 c+KAnSByYXRoZXIgdGhhbiDigJxDQk9SIENlcnRz4oCdLi4gV2hlcmUgdGhhdA0KIHdvcmsgc2hv dWxkIGdvIGlzIGFib3ZlIG15IHBheSBncmFkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CVVQsIG15IG1haW4gaW50ZXJl c3QgaGVyZSByZWxhdGVzIHRvIENXVCBhbmQgRUFULiBDV1Qgc2VlbXMgbGlrZSBhIHJlYWxseSBn b29kIGNob2ljZSBvbiB3aGljaCB0byBiYXNlIGEgbmF0aXZlIENCT1IgY2VydC4gU29tZSBvZiB0 aGUgZmllbGRzIGZvciBhbiBYLjUwOSBjZXJ0IGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gQ1dUIChz dWJqZWN0LCBpc3N1ZXIsIGV4cGlyYXRpb24sDQogbm90LWJlZm9yZSkuIEl0IGhhcyBhbiBleHRl bnNpb24gbWVjaGFuaXNtIGJ1aWx0IGluIGFscmVhZHkgaW4gdGhlIENXVCBJQU5BIHJlZ2lzdHJ5 LiBUaGUgY3J5cHRvIGFuZCBzaWduaW5nIGFyZSB3ZWxsLWhhbmRsZWQgYnkgQ1dU4oCZcyB1c2Ug b2YgQ09TRS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW4gd29yayB0byBmaXQmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yYXRzLWVhdC0wMyI+RUFU PC9hPiZuYnNwO2luIGFzIGEgQ1dULCBhIGZldyBpc3N1ZXMgaGF2ZSBjb21lIHVwIOKAlCBob3cg ZmllbGRzIC8gY2xhaW1zIGFyZSBtYW5hZ2VkIGFuZCByZWdpc3RlcmVkIHdpdGggSUFOQSwgbGFi ZWwgc3BhY2VzIGFuZCBvdGhlci4gJm5ic3A7QWxsDQogdGhlc2UgaXNzdWVzIHdvdWxkIGFwcGx5 IHRvIENXVC9DT1NFL0NCT1ItYmFzZWQgY2VydGlmaWNhdGUgYXMgd2VsbC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+VG8gbmFtZSBqdXN0IG9uZSBpc3N1ZSwgaW4gQ1dUIHRoZSBleHBpcmF0 aW9uIGRhdGUvdGltZSBjYW4gYmUgYSBmbG9hdGluZy1wb2ludCBudW1iZXIsIHdoaWNoIGlzIGJ1 cmRlbnNvbWUsIG5vdCB1c2VmdWwuIFNob3VsZCB3ZSBjaGFuZ2UgQ1dUIHRvIGRpc2FsbG93IG9y IHNob3VsZCBpdCBqdXN0IGJlIGRpc2FsbG93ZWQgd2hlbiBhIENXVCBpcyB1c2VkIGFzIGFuDQog RUFUIGFuZCB3aGVuIGl0IGlzIHVzZWQgYXMgYSBDZXJ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J 4oCZbSBhbHNvIGV4Y2l0ZWQgYXQgdGhlIGlkZWEgb2YgcmUgdXNpbmcgQ1dUIGluIGEgc2ltcGxl IGZvcm0gc28gdGhlcmUgaXMgcmUgdXNlIG9mIGNvZGUgYmV0d2VlbiBDV1QsIEVBVCBhbmQgbmF0 aXZlIENCT1IgY2VydHMuIEnigJl2ZSBzdGFydGVkIHBsYXlpbmcgd2l0aCBhbiBpbXBsZW1lbnRh dGlvbiBsaWtlIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkxMPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE4654CA93F046F79768C3F67166A3FFericssoncom_-- From nobody Tue May 5 02:25:29 2020 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 5B3883A15F7; Tue, 5 May 2020 02:25:27 -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, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=myidemia.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 PkFUWpPQhjG4; Tue, 5 May 2020 02:25:26 -0700 (PDT) Received: from mx08-0018b601.pphosted.com (mx08-0018b601.pphosted.com [91.207.212.183]) (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 708013A1625; Tue, 5 May 2020 02:25:21 -0700 (PDT) Received: from pps.filterd (m0136513.ppops.net [127.0.0.1]) by mx08-0018b601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0459FBh7009220; Tue, 5 May 2020 09:25:18 GMT Received: from eur04-db3-obe.outbound.protection.outlook.com (mail-db3eur04lp2051.outbound.protection.outlook.com [104.47.12.51]) by mx08-0018b601.pphosted.com with ESMTP id 30sw783g3c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 May 2020 09:25:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g/KaBMjHZUyX/vrReCwWjADXK2j4pXoiD3qti/H3f6aS2PbQ4DYexkUDPPSObjCxCfYDrdDhcjb1H/Oz/1ac466RIOl7lIE6pBO5EUC+udgP16VjT6B7YcEKt3FssvQrJXgeDxyR8lK47OCXPHmzQybROMqowPAFTmHXBi1INchkxAkcn1IwGwfsuUBzCC6WZeYI2lSh2aGewWVQSvFyDzIWVZmAfdL5E6EmbzuucbyGtrSADqfoSoO/RdGjMcRHePNNHorOaSI1FjkC7lSlAuxy6h1tOrvze18Je2mPkTKkojfHat+ETPjY7X6EBDVD/mpZv3/R7bfTVV3Epp5wHg== 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=3KBGDm0wmE44YAdKlV9s3/IkjLbESj/tPqGTScFEvGU=; b=BfPwYtpF25egU0y7VF5NfW4RJXaBUffgWd5ypTHFWxx0lP2WphDDMv7uk6lZxPLXss7jpqIE4KtqsGpYSDFF4fOIon4biYWhQNWpOoZO6IFtmDPRIY80XF04sgFc3WAhapGlwS6WMkLlTkcXjCDcI9xmXM3eITC+QIfPaZy0awF4XzL42tMiVlfIHFKbcN4uAfnxsej0CH3WZRXUsrOLc4ARqPtP9JQIR5iR4g76ZPHpoYgsQlcIk6EFNFw21okkf7kxR/kIYIya/3CMGioB4KjdIG8Y7xw4/JHRM4slk9zljJtKufs/LCm+KwF08LOGjDMLBySr6AWsogmQKbvtGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=idemia.com; dmarc=pass action=none header.from=idemia.com; dkim=pass header.d=idemia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myidemia.onmicrosoft.com; s=selector1-myidemia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3KBGDm0wmE44YAdKlV9s3/IkjLbESj/tPqGTScFEvGU=; b=kazG8qVVI8ezDq/QqsvlnEOgD3LeIOacaFpZf8UoPbixbu3Wh06QsuaEBD9EY/3VvJ4kfp3g2kXhSZ8fdqaW4QaEgBjHnQ7eD83a7KGIkNmCxUx1KeXQWKX3cGRCSGAL3z6YiAVGCKJ6xmGGzvgd9W6wqHx8qlQkGYrldbqlGDQ= Received: from PR3P189MB1052.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:46::16) by PR3P189MB0970.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:48::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Tue, 5 May 2020 09:25:17 +0000 Received: from PR3P189MB1052.EURP189.PROD.OUTLOOK.COM ([fe80::cd98:1cb9:4acd:bb28]) by PR3P189MB1052.EURP189.PROD.OUTLOOK.COM ([fe80::cd98:1cb9:4acd:bb28%6]) with mapi id 15.20.2958.030; Tue, 5 May 2020 09:25:17 +0000 From: DESPERRIER Jean-Marc To: Ivaylo Petrov , cose CC: "draft-ietf-cose-x509.authors@ietf.org" Thread-Topic: [COSE] WGLC of draft-ietf-cose-x509 ENDED Thread-Index: AQHV6+pZOeKJcYMk5kWv0L8YDEIsw6iZpZww Date: Tue, 5 May 2020 09:25:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Enabled=True; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Name=Public authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=idemia.com; x-originating-ip: [165.225.77.148] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c9e46bac-1532-4093-dc1f-08d7f0d63972 x-ms-traffictypediagnostic: PR3P189MB0970: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PeCMNDhWADrWLXG6MGIxgvWS2ewcDlxSoaQvDRSIBZvZQE9flnh6M2W+o2mx3OdbSjYhXEggQF1l9HdHpwFSHyuePteNWpy+slX86lQ4WiFoPN2Mc3Ng+303qPajE8pPoYzjlJ+Mpvl0bSOg251Ihpr7rFRsm+QMjitDoYQxALJtcuzRa+pteE7JFTavEDi5f4fw4a8SUrNhVQkM9JkL2RbKsiOZ2W2JeM9IsDbKu+GrdOifTxn3X3ZFbY4Mj6ngblFMS7701a2TTb3BlYeIR55l50lwLFK/Tt5CKxGZS3EKG33gGHjDuwzXPFBnxTPoniN6fM4kHswpcckyYWyodvXxAuRgz+w9VVjDBSQHMHPhoII5kDDBOZtmPuuXDIRICL/YWaXB1q082XGN8N8hWjCEMh3GEvPJ9SRZCqDxp+HA9UlSpAeFaYDPWxH5PNwZUkGhaOwFnwqYn/cYNGP/GB5uZlegOACcfFe3gZbj4XL77dwiDLmj7rTOOdMo/j7fsghNNHCyfnGNytaWumoL/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P189MB1052.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(376002)(346002)(39860400002)(33430700001)(4326008)(26005)(86362001)(186003)(52536014)(7696005)(55016002)(71200400001)(33440700001)(66574012)(55236004)(5660300002)(9686003)(4744005)(6506007)(110136005)(316002)(8936002)(8676002)(66446008)(76116006)(66946007)(2906002)(33656002)(478600001)(64756008)(66476007)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: sLiJP65Thf1BsdSiePaA0zlt1LeJksEB0ErFAkn5l0bhb1wne01rTa/N3RNxEFkgIfPnYRPAmVbZFJDVvKvHmSJIRdX9yDfPHiWoaYULjqa9M2eOe8NUN8xl/7flxaiXww1uBkTkr7ieDSY89fDBNcwNAIWKQjLzggLFj9FG3lp7CNgob7mMEIOuuy3jBdQexNxJ4u4DederBr6VFJbFXgzeFcUCQIOeVpe6p+AFIWU8ZaRRKoYYas9jdyOmoRp6t+fEjfrbEBh57FLfs+z5y6gw8OUoEhHv/7dB8MZRCqQlaXriJV11683LPstoKYeWz2TitsxyzObZSruqpKZbWmoqZmYOiBZSnB8TaDKPjA431wOLyyNQs4i8F+hMJE29xxoHpWJ+bGeO+m094WD4omHXuxIdLYqsgnjfea22qxU1uCCCY6IHl9wbuIagdw2da+WVpAqZW2zD6qNhDdyodTbRAEaKFFWcQpMq2FDwUS/qXgvTzkgASibh6k2ItUo03h3fE6JOjwbXGuRPz43uTarOZC3omo/nDKNwYtso+JMYB3CLcQGUhZHeUbKvvQ+9HMGONMrkvdldaKTLuwGnNYiU3QedyZhXcKzBB1fq2d2rNEOmNt7+zOyhxC7UYJjvxyGktnXMgeHeP7E8EkqC3nW0Fk1gsWUgT/MWURlfmaHDvv3BJdHEbse8/aS9m2k8ITkn8AUdHKmH68u94tSLCe+98tJ36u/ZvVecJPa1g91Xhe23SCxG1o+FOiGFi2OxfLvpA2qx0lLpXviBeV045l+pABPiVrPBTUWCb1IG58M= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: idemia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9e46bac-1532-4093-dc1f-08d7f0d63972 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 09:25:17.2088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7694d41c-5504-43d9-9e40-cb254ad755ec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VKZmPSnL6crQcxlp4HGq4lQoAZL0x0OLMV7X6oWhcvzmgFwik44uR/JoTy1Fs70gyxnYhrhf63zLeiM/b2P9HQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P189MB0970 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9611 signatures=668687 X-Proofpoint-Spam-Details: rule=outbound_idemia_notspam policy=outbound_idemia score=0 phishscore=0 spamscore=0 priorityscore=1501 bulkscore=0 adultscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050075 Archived-At: Subject: Re: [COSE] WGLC of draft-ietf-cose-x509 ENDED 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, 05 May 2020 09:25:28 -0000 Hi, The updated version of the draft was published on the 9 march, but we're st= ill waiting for the shepherd writeup ? Best regards, Jean-Marc Desperrier -----Message d'origine----- De=A0: COSE De la part de Ivaylo Petrov Envoy=E9=A0: mardi 25 f=E9vrier 2020 15:46 =C0=A0: cose Cc=A0: draft-ietf-cose-x509.authors@ietf.org Objet=A0: [COSE] WGLC of draft-ietf-cose-x509 ENDED Dear all, The working group last call for [COSE-X509] has ended; thank you to everyon= e that commented. As no objections were raised, we believe there is consensus that after some= minor items are fixed, this document can move forward. Therefore, we will = be expecting an updated version of the draft, after which we will provide t= he shepherd writeup, which would then be followed by a request for publicat= ion. - Matthew and Ivaylo COSE Chairs=20 From nobody Tue May 5 02:47:19 2020 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 500E73A1601 for ; Tue, 5 May 2020 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 CMYsMbcqL4lE for ; Tue, 5 May 2020 02:47:14 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 976813A1600 for ; Tue, 5 May 2020 02:47:14 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id h9so1973982wrt.0 for ; Tue, 05 May 2020 02:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1dIG41KSgt0ZBijVwyM0rA0riV4eQlnelobZz4syyqY=; b=lgG7BdWe7vhDq29mpe5fM0QPZvLXl77K6O96bokpjAqUAUT0eAebWYpsCUzm0nhaSO on2wZn1AjDa0/+Otbs2qftK66hgqgQ/leiGAu2NVpIfMYKn2o+UsstIWGd6qPrTqJmkc 1Gsurc54306aqok4m7tw07bR8JEFBQjHptvvxWQbeSl+s6x8oE2LQKvbZBj97adFzzv9 p/TRjYbcj7hvx7gYIx2HBzyknYXh2lzZueCDjTOhbcV/3uebTq+/meUy5xJkLEdKQWCr qhN4n9MwkHC8Ak0g1RXmgTfCzXjTP6UZtgEU0HzS3rq1J5DFtA/y5tt78TqcFquiFico bmUg== 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=1dIG41KSgt0ZBijVwyM0rA0riV4eQlnelobZz4syyqY=; b=sB/oXIejKCTZcMGuxf0G2VDIN431MNqy06xiAvGot90ITA3dbItPNrfH/DNO0c503A O8YnykPjrnlR9KZySKh6BffEG3Yd2olEOtd6x8SN57+0lAPSS2lALRmj4V6Ljidfytve RtS50GEyW96dToL/rShoZP45kxZuGPRTh+mWr32e5p7dCBsQbCeArw7MfZaP9M5a8ZeL Ac2dvaw+Rkmkt1k0Xg3IfkTkYyhFNmGSmq0ZmqMP7Gv6gzZbhfvhfGT5QaSITgesXzr7 Gi4txZ8TqGxa0eSFOs+8y7bGPaUp3xo9fc41gRL81L4OvQ6f0PwOpHy3HRdlTVSRWNn0 Pd7w== X-Gm-Message-State: AGi0PuZ3mXl7AbB3IgnDAink1vnHDskeEqKFvWPkWetWnrdFuIo1zFba TZEhHJ9Y/MdA+qsZBT1Vtd+f5Ydo8XMTenJs4ibFb8Nx X-Google-Smtp-Source: APiQypLJcrj1K9eetLvpTchFoUeq194IgwYCRPWhuSETNBfS9lnlHG5JXfHb3GgW9/HszYPwWS2D42FacNzI4QGOc8s= X-Received: by 2002:adf:f8c1:: with SMTP id f1mr2652707wrq.171.1588672033111; Tue, 05 May 2020 02:47:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Tue, 5 May 2020 11:46:47 +0200 Message-ID: To: DESPERRIER Jean-Marc Cc: cose , "draft-ietf-cose-x509.authors@ietf.org" Content-Type: multipart/alternative; boundary="00000000000032d32805a4e3882f" Archived-At: Subject: Re: [COSE] WGLC of draft-ietf-cose-x509 ENDED 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, 05 May 2020 09:47:17 -0000 --00000000000032d32805a4e3882f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jean-Marc, Thank you for your email and apologies for the delay. Best regards, Ivaylo On Tue, May 5, 2020 at 11:25 AM DESPERRIER Jean-Marc < jean-marc.desperrier@idemia.com> wrote: > Hi, > > The updated version of the draft was published on the 9 march, but we're > still waiting for the shepherd writeup ? > > Best regards, > Jean-Marc Desperrier > > -----Message d'origine----- > De : COSE De la part de Ivaylo Petrov > Envoy=C3=A9 : mardi 25 f=C3=A9vrier 2020 15:46 > =C3=80 : cose > Cc : draft-ietf-cose-x509.authors@ietf.org > Objet : [COSE] WGLC of draft-ietf-cose-x509 ENDED > > Dear all, > > The working group last call for [COSE-X509] has ended; thank you to > everyone that commented. > > As no objections were raised, we believe there is consensus that after > some minor items are fixed, this document can move forward. Therefore, we > will be expecting an updated version of the draft, after which we will > provide the shepherd writeup, which would then be followed by a request f= or > publication. > > - Matthew and Ivaylo > COSE Chairs > --00000000000032d32805a4e3882f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jean-Marc,

Thank you for your email and apologies for the delay.

Best regards,
Ivaylo
<= div>
<= /div>


On Tue, May 5, 2020 at 11:25 AM DESPERRIER Jean-Marc &= lt;jea= n-marc.desperrier@idemia.com> wrote:
Hi,

The updated version of the draft was published on the 9 march, but we'r= e still waiting for the shepherd writeup ?

Best regards,
Jean-Marc Desperrier

-----Message d'origine-----
De=C2=A0: COSE <cose-bounces@ietf.org> De la part de Ivaylo Petrov
Envoy=C3=A9=C2=A0: mardi 25 f=C3=A9vrier 2020 15:46
=C3=80=C2=A0: cose <c= ose@ietf.org>
Cc=C2=A0: draft-ietf-cose-x509.authors@ietf.org
Objet=C2=A0: [COSE] WGLC of draft-ietf-cose-x509 ENDED

Dear all,

The working group last call for [COSE-X509] has ended; thank you to everyon= e that commented.

As no objections were raised, we believe there is consensus that after some= minor items are fixed, this document can move forward. Therefore, we will = be expecting an updated version of the draft, after which we will provide t= he shepherd writeup, which would then be followed by a request for publicat= ion.

- Matthew and Ivaylo
COSE Chairs
--00000000000032d32805a4e3882f-- From nobody Tue May 5 08:36:53 2020 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 DD29D3A0831 for ; Tue, 5 May 2020 08:36:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=outer-planes-net.20150623.gappssmtp.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 87H0YKEGm9jx for ; Tue, 5 May 2020 08:36:48 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 A1EEA3A0828 for ; Tue, 5 May 2020 08:36:48 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id j8so1748587iog.13 for ; Tue, 05 May 2020 08:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Cq6JoqFiUjoVYodq642AvKVYza7X3uj1gb3jIbmzYPk=; b=CQKgFvJX7Z1c2xIAJUHVfjtSWXFB7fGp/XEcM0mWNZzoNklKEblWiZ5HC//yIlhX1I T0CVZrx7tnnfYDxk6iix+2Acipse73Ow494Qvtnd2JVyT9/81jnsE4tTUh5p2F24mvDP CpVB1KDVQKe0Qq+01l0m2PmH6TJPSoORSN7Do6i/saO88/9cW10xjgQ/SaBvIb3/kM65 b8p83rJTrjAQxk4pCxQ142h3pocMTjMp+5QNENBLzap23kUrPGUgB9GMGTKv0zUR+Jmo w1kpagwQVRJpTB5WbWfG6nRKGaPz+VFgyHV8VLjyyr2b0QqQ8yNg0M/wFQLqpEmqbs6r z5EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Cq6JoqFiUjoVYodq642AvKVYza7X3uj1gb3jIbmzYPk=; b=gZEPsWEw/Zd4uPR5WufLyITTkCVZE6epep/KDhnWgZkemuB9AhZ+u9k3rp0rJULjBO oaW0pGK8c3OPG7a1IvT0rYq/VCS5i0zyNe9n6RmvyPJzK5P7Z/Wa7wd3t1FliEwV2VAx rSrYoh86eQohHhULgCluMbU1V6msBepS/0+Nvi3KfKikbTuk/A8lZvr1UyeaTy4zDuuI z0WSVnylnQVipTkAOSf9Y1RyuC52L8KJwCa1EW6GjQmjDuJk2r7WOse5++7khP6Wm6B4 pin0d1ogZjieDsy6oqrsXzITNHBSg9uUv1Yhk7zWBTUi9PxHWLegKapip0ftKzBbvfwn ri7A== X-Gm-Message-State: AGi0PuYPwmwum822tsRbQ56WOOtYRJTZ2doxRaSI7/13ig4GMqQN7aoy KYoXIX4Uv/NutdyUrAM27g+Tp5ptLKEduA== X-Google-Smtp-Source: APiQypImILRmVWulU/u7kHH0FLIlsr84dbYM4Rt16gTq9y/YH44jiLpDho9BPr8qBJDokmAoakZXxA== X-Received: by 2002:a5e:9705:: with SMTP id w5mr3900356ioj.86.1588693007679; Tue, 05 May 2020 08:36:47 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:5934:829a:4ef7:c075]) by smtp.gmail.com with ESMTPSA id y70sm1913809ilk.47.2020.05.05.08.36.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 08:36:47 -0700 (PDT) To: cose References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: Date: Tue, 5 May 2020 09:36:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158857581528.28405.17372040856513106617@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [COSE] Survey on planning for possible online IETF meetings 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, 05 May 2020 15:36:51 -0000 If you have not already done so, please fill out this survey to help with the planning of future IETF meetings. < https://www.surveymonkey.com/r/5328FFJ > On 20/05/04 01:03, IETF Executive Director wrote: > This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: > > https://www.surveymonkey.com/r/5328FFJ > > So far we have 114 responses and we would ideally like 500 or more. > > The survey contains the following pages and will take 15-20 minutes to complete: > > 1. Welcome > 2. Online IETF 107 and the subsequent virtual interims > 3. Replacing a cancelled in-person meeting > 4. Online meeting format and timezone > 5. Replicating humming > 6. Replicating the hallway environment > 7. Fees > 8. Thanks and anything else > > We run the survey in anonymous mode which means that we only see data that you explicitly provide. > > Thank you in advance for your help. > From nobody Tue May 12 05:42:09 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6625F3A0885; Tue, 12 May 2020 05:42:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ivaylo Petrov via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Cc: cose-chairs@ietf.org, iesg-secretary@ietf.org, ivaylo@ackl.io, cose@ietf.org, Ivaylo Petrov Message-ID: <158928732740.433.9667239105316625747@ietfa.amsl.com> Date: Tue, 12 May 2020 05:42:07 -0700 Archived-At: Subject: [COSE] Publication has been requested for draft-ietf-cose-x509-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 12:42:07 -0000 Ivaylo Petrov has requested publication of draft-ietf-cose-x509-06 as Informational on behalf of the COSE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ From nobody Tue May 12 08:26:37 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A3F3A0B2F; Tue, 12 May 2020 08:26:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk CC: Ivaylo Petrov , superuser@gmail.com, ivaylo@ackl.io, draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158929718086.30059.17314603450652106437@ietfa.amsl.com> Date: Tue, 12 May 2020 08:26:20 -0700 Archived-At: Subject: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 15:26:21 -0000 The IESG has received a request from the CBOR Object Signing and Encryption WG (cose) to consider the following document: - 'CBOR Object Signing and Encryption (COSE): Hash Algorithms' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are however circumstances where hash algorithms are used: Indirect signatures where the hash of one or more contents are signed. X.509 certificate or other object identification by the use of a fingerprint. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 12 08:31:10 2020 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 357CF3A0AC6; Tue, 12 May 2020 08:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IcJSQSq3hfmC; Tue, 12 May 2020 08:31:07 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 643263A0B26; Tue, 12 May 2020 08:31:04 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id d7so14418546ioq.5; Tue, 12 May 2020 08:31:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=iLj9dLqbimei8jl6N5LAhjB5zSdKCEpLmfzhKnVSxME=; b=Pz5Nx2o6AD4nXa2Pe0j7E9v1YJKs80Lo8xyo3G+bOhRF2+LlhGA3i0haInnAq5m68D VgX/mAGcgLxXT7GSr4dSscSMmsTHwJjNEZiVAa+JdVQozYzg2/AS0Gnbwp9X3VaHoY5K M/Qjs1YfpTmnQF+7kNo7RpQxHZLhkk4dMtcEhoAkKK0o84tNrtsT8oifua834FrJmUHI XVoH9g2Y0LSBaxU/6ETV0UdvP2BXjNcMM02YOdj+kJ6w/2RjSFMqgXm9gAG2WIzpeu1P vl2Vg7oJ67duT1ktu8NqVBMLaeq2KJo2psMbxhWKyXP5jigtYijrLfkBilM9LXRbVrmr oKdA== X-Gm-Message-State: AGi0PuacoXLZWUiYwdMFGorzEUHX2nPakxtWzV32Z/SB+wSJB805JugA 0ASYCBHYYCoDnXp+MFRESGlKSoOZO46/4eTldO5wp918M80= X-Google-Smtp-Source: APiQypJztflUbDvN2lCLwKCb5Lf/U0S8UEoD8fIC0JtcLB2/DwPkhvMUMquf4f03X0bVG7MzRI7/PjjBU9dEREzCsRg= X-Received: by 2002:a02:a1d8:: with SMTP id o24mr11749313jah.88.1589297463048; Tue, 12 May 2020 08:31:03 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Tue, 12 May 2020 11:30:51 -0400 Message-ID: To: draft-ietf-cose-rfc8152bis-struct.all@ietf.org Cc: cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_DIFF_CHECK?= 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, 12 May 2020 15:31:09 -0000 Hi, all. I've picked up the sponsorship of the two 8152bis drafts from Ben in order to help share the load and get the documents moving faster than Ben has time for just now. I've started AD review with a pass at the diffs between this document and 8152; I will follow with a closer review of this document to see if there are things that look like they should have been updated or clarified, but weren't (I don't expect to find much there, but I want to look). Here's the review of the diffs: Please be consistent about use of =E2=80=9Ccounter signature=E2=80=9D or =E2=80=9Ccountersignature=E2=80=9D. Consider, for example, the inconsisten= cy in the 4th and 5th paragraphs of Section 5.1, and the section title of 5 vs 5.1 and 5.2. (It looks like 8152 spelled it as two words and 8152bis spells it as one. I don't care which way the WG wants to go for the update, but it should be consistent throughout the document.) =E2=80=94 Section 3 =E2=80=94 the value is wrapped in the binary object. Recipients MUST accept both a zero-length binary value and a zero-length map encoded in Should this say =E2=80=9Czero-length byte string=E2=80=9D for consistency? =E2=80=94 Section 4.3 =E2=80=94 proxy, or an attacker, changes the set of accept values by including the field in the application supplied data. Nit: hyphenate =E2=80=9Capplication-supplied=E2=80=9D. * If multiple items are included, applications need to ensure that the same byte string cannot produced if there are different Nit: =E2=80=9Ccannot be produced=E2=80=9D =E2=80=94 Sections 4.4, 6.3, and 7.3 =E2=80=94 In bullets 2 and 3 in each, I think it=E2=80=99d be better to use =E2=80=9C= zero-length byte string=E2=80=9D for consistency in the text, rather than =E2=80=9Cbstr= of length zero=E2=80=9D or =E2=80=9Czero-length bstr=E2=80=9D sometimes. =E2=80=94 Section 5 =E2=80=94 It is always possible to construct cases where the decryption is successful, while providing completely different answers by using a different key. This situation is not detectable by a countersignature on the encrypted data. It took me a few readings of this to get what I think you mean. I don=E2=80=99t think I would refer to this as =E2=80=9Cthe decryption is suc= cessful.=E2=80=9D Might this be better said with something like this?: NEW It is always possible to construct cases where use of a different key appears to result in successful decryption, but provides completely different unencrypted data. This situation is not detectable by a countersignature on the encrypted data. END =E2=80=94 Section 5.1 =E2=80=94 The full countersignature structure can be encoded as either a tagged or untagged depending on the context it is used in. Nit: remove =E2=80=9Ca=E2=80=9D. =E2=80=94 Section 5.2 =E2=80=94 Abbreviated countersignatures were designed primarily to deal with the problem of having group encrypted messaging Would =E2=80=9Cencrypted group messaging=E2=80=9D be better? The MLS worki= ng group refers to "group messaging", and we're talking about making that encrypted. =E2=80=94 Section 7 =E2=80=94 COSE_MAC is used for all other cases. These include a requirement for multiple recipients, the key being unknown, or a recipient algorithm of other than direct. =E2=80=98Tis a total nit, but you changed =E2=80=9Cand=E2=80=9D to =E2=80= =9Cor=E2=80=9D here, and I think the change was incorrect, and the original =E2=80=9Cand=E2=80=9D was correct = =E2=80=94 the =E2=80=9Cother cases=E2=80=9D include all three of the examples. =E2=80=94 Section 9 =E2=80=94 This taxonomy should not be considered to be exhaustive as there are new algorithm structures that could be found or are not known to the author. This reads oddly to me: =E2=80=9Cthat could be found=E2=80=9D seems strange= , and =E2=80=9Cnot known to the author=E2=80=9D feels wrong in a working group document. Can = you try rewording this? =E2=80=94 Section 9.5.1 =E2=80=94 Should either or both instances of =E2=80=9Czero-length item=E2=80=9D here = be =E2=80=9Czero-length byte string=E2=80=9D or =E2=80=9Czero-length text stri= ng=E2=80=9D so as to be appropriately specific? --=20 Barry From nobody Tue May 12 10:07:08 2020 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 2FA2B3A0781; Tue, 12 May 2020 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UYGrv1mQT0Bj; Tue, 12 May 2020 10:07:05 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 0602B3A0400; Tue, 12 May 2020 10:07:01 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id 79so5626063iou.2; Tue, 12 May 2020 10:07:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=1EkwlkiWvss/SH56K2cgx4S5NnjKj7b0Hj3xnJbb6d0=; b=Fp9E6mA0HwVwQ9RldmL0yYd+2vuJ0FaZ7PoLzei+2hfVRSicBlhK+ZhX7AtF6bjmUU ajF/D09IGun8hCU0Wvq8mrJOwZqe3J95O+Oue9HUe8HQZpspgrCvALUlQLdVjrWBnV4q ABAwQda0eI9qL0p4+sLxBUYBdcVLAAfMbMubji8G6DgDGrRN+393cg/5x8uWO8v4uqUL +dN6AoCw848zTXNo9/CUqOeMvxPq+cu7gWRTh+q/PgiZgU7DTLdslKBbFtehZbriF+Fz 7oaXLt4iXnaPAySiU83wtRqf2N3bQ5TqiCMGzRHQhIvU2CcdPa+PUlLy0ekd8uuehWhj Iaww== X-Gm-Message-State: AGi0PuY6oud/VU9sbqA0noBLGSoFT7GFa7rDL8rtZFloeaLpgomAmb3S ic/blxn9EWeyoSPT5MzG8LhtieBjMdl6x1sJEza3ZiqoQ4c= X-Google-Smtp-Source: APiQypJRIX8DHZJXhlgnCteLdFJ2xthyQQcgrIQp14dMjRBESmZ1KZy/KZqXKjgj+vfuwKAgiDq2nh5vjENhbp0axWs= X-Received: by 2002:a05:6602:1695:: with SMTP id s21mr21732815iow.40.1589303220430; Tue, 12 May 2020 10:07:00 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Tue, 12 May 2020 13:06:49 -0400 Message-ID: To: draft-ietf-cose-rfc8152bis-algs.all@ietf.org Cc: cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [COSE] AD review of draft-ietf-cose-rfc8152bis-algs-07 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, 12 May 2020 17:07:06 -0000 Here=E2=80=99s my AD review of the 8152bis algorithms document. =E2=80=94 Section 8 =E2=80=94 There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location. I find that very hard to read. The passive =E2=80=9Cthere is a presumption= =E2=80=9D, the third =E2=80=9Cis=E2=80=9D (I think =E2=80=9Cis that=E2=80=9D is meant = to be =E2=80=9Cin that=E2=80=9D), and the unclear antecedents to =E2=80=9Cthis=E2=80=9D and =E2=80=9Cit=E2=80=9D make= it unclear. I would suggest a rephrasing, but I can=E2=80=99t follow it well enough to do that. Will you please rephrase it, perhaps starting with =E2=80=9CThe way is laid out presumes that the algorithm identifier does not need to be part of because .=E2=80=9D ? Thanks. Two different types of capabilities are defined: Capabilities for algorithms and capabilities for key structures. Nit: One capitalizes something after colon only if it=E2=80=99s a complete sentence, and this isn=E2=80=99t. So make it a lower-case =E2=80=9Cc=E2=80= =9D. Once defined by registration with IANA, the list capabilities is immutable. Nit: =E2=80=9Clist of capabilities=E2=80=9D, yes? algorithm specific header parameters or key parameters, but they do Nit: hyphenate =E2=80=9Calgorithm-specific=E2=80=9D. For a key, the first element should also be a key type value, while this means that this value will be duplicated if both an algorithm and key capability are used, the key type is needed in order to understand the rest of the values. I think this is two spliced sentences, and that it needs to be split after =E2=80=9Ckey type value=E2=80=9D. =E2=80=94 Section 8.2 =E2=80=94 the capabilities is set to the single entry of the key type =E2=80=9Ccapabilities is=E2=80=9D? What=E2=80=99s the correct fix for this= ? And what does =E2=80=9Citems=E2=80=9D refer to in the next sentence? =E2=80=94 Section 8.3 =E2=80=94 In this section a trio of examples are provided. He-he=E2=80=A6 =E2=80=9Cthree examples=E2=80=9D is plural, so =E2=80=9Care= =E2=80=9D is correct. But =E2=80=9Ca trio of examples=E2=80=9D is singular, so it needs =E2=80=9Cis=E2=80=9D. Please= pick one. In all three cases the pair of capabilities is always provided as the algorithm and then the key capabilities. That feels awkward and a little confusing. Maybe this?: NEW In each case, the pair of capabilities designates first the algorithm and then the key capabilities. END =E2=80=94 Section 9 =E2=80=94 There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. Both instances of =E2=80=9Cneeds to=E2=80=9D seem odd. For that matter, so= does =E2=80=9Cthere has been an attempt=E2=80=9D. Maybe this, or something like= it?: NEW This document limits the restrictions it imposes on how the CBOR Encoder can work. END =E2=80=94 Section 10.2 =E2=80=94 not done then the DE should be consulted final registration for this document is done. Is this missing the word =E2=80=9Cbefore=E2=80=9D? Or =E2=80=9Cwhen=E2=80= =9D? =E2=80=94 Section 10.3 =E2=80=94 IANA is required to modify the description to "Public Key" Change =E2=80=9Crequired=E2=80=9D to =E2=80=9Crequested=E2=80=9D. --=20 Barry From nobody Wed May 13 05:40:19 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 618CB3A10DA; Wed, 13 May 2020 05:40:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk CC: cose@ietf.org, superuser@gmail.com, cose-chairs@ietf.org, ivaylo@ackl.io, Ivaylo Petrov , draft-ietf-cose-webauthn-algorithms@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158937361695.30811.14534799425984840549@ietfa.amsl.com> Date: Wed, 13 May 2020 05:40:17 -0700 Archived-At: Subject: [COSE] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:40:18 -0000 The IESG has received a request from the CBOR Object Signing and Encryption WG (cose) to consider the following document: - 'COSE and JOSE Registrations for WebAuthn Algorithms' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6194: Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms (Informational - IETF stream) From nobody Wed May 13 11:48:45 2020 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 14F9C3A07A1; Wed, 13 May 2020 11:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 KV2sTGqbE9ee; Wed, 13 May 2020 11:48:42 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 EFE3A3A077E; Wed, 13 May 2020 11:48:41 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id j8so148990iog.13; Wed, 13 May 2020 11:48:41 -0700 (PDT) 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:content-transfer-encoding; bh=U4zo2J/8M1Ut1Pg1ms1XvzROww7XlF2r9sF9yXr1MRU=; b=SFHvyMmzEeL25TA3VKjN1U771am8ex2u53h0T9Lk9yrVktCfYMVLQbKZiyP9ri3c2n dTcW9M2Vfd6Jhwwm1d1cM4QHcN1l/vNQVwO8gSB7mPE5/I2wQNqIcTMA6O/hkr8q39dq I0tV56nk6+lg3k41VERr0P2uGElmIEFiNamwUdcyDbk7NZCRs5d/PNLtFD4Vocjk/Cd4 OKJIIcvXaClXQvMusxbEK1gyS+W7ILdE0R09IshkhiD4LmJgkWl4kR4+YUQd8mrwb1fs a3A9dVlLrG3wXy1TpCZ0rx5qONTs62C50/Mbyi7KmWfY2wuZEk+AUaiG6ZXW2jibLYrT 07IQ== X-Gm-Message-State: AOAM533VThtfT+tb4sW3z2s8sHZp9y3qYF+rxM9ZM/4FcWWPM480Wmbj 6KhgryCR68mPZMl48jA3Cvm6vdMD57qx9KZtXCU= X-Google-Smtp-Source: ABdhPJw8spdKVmAATWqPk9YDQy9+c93UuF9WQhW0VOE7nVRlm04ZDXnZR4IazDjOLxfVzL+EnGAWE03q39r2Rz6CjhU= X-Received: by 2002:a02:5807:: with SMTP id f7mr892920jab.118.1589395720267; Wed, 13 May 2020 11:48:40 -0700 (PDT) MIME-Version: 1.0 References: <018701d62951$84539bd0$8cfad370$@augustcellars.com> In-Reply-To: <018701d62951$84539bd0$8cfad370$@augustcellars.com> From: Barry Leiba Date: Wed, 13 May 2020 14:48:29 -0400 Message-ID: To: Jim Schaad Cc: draft-ietf-cose-rfc8152bis-struct.all@ietf.org, cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_DIFF_CHECK?= 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, 13 May 2020 18:48:43 -0000 Thanks for the quick response, Jim. We're good with all items, but hold off on a revised I-D until I finish the full review (tomorrow, I expect). > =E2=80=94 Section 7 =E2=80=94 > > COSE_MAC is used for all other cases. These > include a requirement for multiple recipients, the key being unknown, > or a recipient algorithm of other than direct. > > =E2=80=98Tis a total nit, but you changed =E2=80=9Cand=E2=80=9D to =E2=80= =9Cor=E2=80=9D here, and I think the change was incorrect, and the > original =E2=80=9Cand=E2=80=9D was correct =E2=80=94 the =E2=80=9Cother c= ases=E2=80=9D include all three of the examples. > > [JLS] This change was made in response to a WG comment. I believe that "= or" is correct here > as there are three different cases being listed rather than a combination= of the three cases. As I say, it's a total nit, so I'm not going to say more than this, but a container (here, "all other cases") contains the union of what's in it. My shopping list includes cauliflower and spinach (not "or"), and your vineyard grows (perhaps) Zinfandel and Pinot Noir (not "or"). And COSE_MAC is used for A and B and C, not "or", because it's used for all of them. Anyway, 'nuff said here. Barry From nobody Wed May 13 17:26:31 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 141FE3A085A; Wed, 13 May 2020 17:26:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <158941598895.17954.2465809014254646992@ietfa.amsl.com> Date: Wed, 13 May 2020 17:26:29 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-webauthn-algorithms-06.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 00:26:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : COSE and JOSE Registrations for WebAuthn Algorithms Author : Michael B. Jones Filename : draft-ietf-cose-webauthn-algorithms-06.txt Pages : 13 Date : 2020-05-13 Abstract: The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-06 https://datatracker.ietf.org/doc/html/draft-ietf-cose-webauthn-algorithms-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-webauthn-algorithms-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 22:18:33 2020 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 744373A0B5D; Wed, 13 May 2020 22:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 EIWL5KQpPUwp; Wed, 13 May 2020 22:18:27 -0700 (PDT) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (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 D9BF83A0B57; Wed, 13 May 2020 22:18:26 -0700 (PDT) Received: by mail-il1-f181.google.com with SMTP id j2so12170ilr.5; Wed, 13 May 2020 22:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NA+DuyHEK0cgzLCBEaE6GfxNgui5UMQvhXKieQt53G4=; b=ddx/DqfFjyp0czm0PXZLxeRWHbA1i5SHCLE1fCi0rCYpu2+PvDMJh3uNGyzJZItqPA CQ91pdGjrolS+ykNSICrVPe/llnXggVjAs0edKeVMx1ImjF1bx3hLV7rpG7imqwtD81m D1JezB02pN0FB+ajN5zuzMORMxuP9hcdAFhTrDllQ4w/vpzu5VrOk0BRPwqhFC8jUhxi L6vd2ff9CzScS3bZBwTVaXq+SYAAs4AyT5n4J5/gRpXW4n+r5EZok9vHdihpzCREgSNu QrYhMLyyyD3u3NpYzG5F8yvKZhYD9NqaM81fxxnMkIFMEqLbdyFDMgq+8FrDWUg1zbuw aHXA== X-Gm-Message-State: AOAM530cTS/dfYWNnaP7TfUi4ml13/x9e8HHdJSz4cH/w0HAdRqBly5e xZO0g/XwJlsYTg+sItwypECPTqtgr2uNgf2KSqPaBwOL X-Google-Smtp-Source: ABdhPJxH8sjfMY4lU5RXNe/m00SloMU1KMQEJhOVFcR5vwFQlR/cs2C11XDVCJsPl59EDw/NIi7lHr0lYlfwM4ukZd0= X-Received: by 2002:a92:d20a:: with SMTP id y10mr2886608ily.17.1589433505707; Wed, 13 May 2020 22:18:25 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Thu, 14 May 2020 01:18:14 -0400 Message-ID: To: "draft-ietf-cose-rfc8152bis-struct.all@ietf.org" Cc: "cose@ietf.org" Content-Type: multipart/alternative; boundary="000000000000807c8e05a594d324" Archived-At: Subject: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_THE_REST_OF_THE_REVIEW?= 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, 14 May 2020 05:18:29 -0000 --000000000000807c8e05a594d324 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This review mostly includes comments about text that was NOT changed in 8152bis, and is all minor editorial things. =E2=80=94 Section 1 =E2=80=94 CBOR was designed specifically to be both small in terms of messages transport and implementation size and be a schema-free decoder. A couple of nits fixed here, =E2=80=9Cmessages transport=E2=80=9D and =E2= =80=9Cbe both ... and be=E2=80=9D: NEW CBOR was designed specifically both to be small in terms of messages transported and implementation size, and to be a schema-free decoder. END The JOSE working group produced a set of documents [RFC7515] [RFC7516] [RFC7517] [RFC7518] using JSON that specified how to process encryption, signatures, and Message Authentication Code (MAC) operations and how to encode keys using JSON. There=E2=80=99s a redundancy with =E2=80=9Cusing JSON=E2=80=9D twice in tha= t sentence. I would remove the first instance and change the second to =E2=80=9C, all using JSO= N.=E2=80=9D =E2=80=94 Section 1.3 =E2=80=94 * Use binary encodings for binary data rather than base64url encodings. As written, that says that the document uses binary encodings for binary data, rather than using binary encodings for base64url encodings. NEW * Use binary encodings, rather than base64url encodings, to encode binary data. END =E2=80=94 Section 1.5 =E2=80=94 The presence of a label in a CBOR map that is not a text string or an integer is an error. I think you mean this: NEW The presence in a CBOR map of a label that is not a text string or an integer is an error. END =E2=80=94 Section 1.6 =E2=80=94 context' header parameter defined in [RFC8613], or identified by a protocol specific identifier. Nit: hyphenate =E2=80=9Cprotocol-specific=E2=80=9D. Context should generally be included in the cryptographic configuration, for more details see Section 4.3. Comma splice: change the comma to a semicolon. =E2=80=94 Section 4.1 =E2=80=94 An example of header a parameter about the content is the content type. Examples of a header parameters about the signature would be Nits: =E2=80=9Cof a header parameter=E2=80=9D and =E2=80=9Cof header parame= ters=E2=80=9D =E2=80=94 Section 6.1 =E2=80=94 The same techniques and nearly the same structure is used for encrypting both the plaintext and the keys. Nit: the subject is plural, so =E2=80=9Care used=E2=80=9D. Or to avoid the= awkward =E2=80=9Cstructure are used=E2=80=9D, recast the sentence: =E2=80=9CBoth th= e plaintext and they keys are encrypted using the same techniques and nearly the same structure.= =E2=80=9D =E2=80=94 Section 10 =E2=80=94 Same comment as in the algs doc: There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. Both instances of =E2=80=9Cneeds to=E2=80=9D seem odd. For that matter, so= does =E2=80=9Cthere has been an attempt=E2=80=9D. Maybe this, or something like= it?: NEW This document limits the restrictions it imposes on how the CBOR Encoder can work. END =E2=80=94 Appendix A =E2=80=94 The first set of recommendations apply to having an implicit algorithm identified for a single layer of a COSE object. The second set of recommendations apply to having multiple implicit algorithms identified for multiple layers of a COSE object. The third set of recommendations apply to having implicit algorithms for multiple COSE object constructs. Nits: For all three sentences, =E2=80=9Cset of recommendations=E2=80=9D is = a singular subject (=E2=80=9Cset=E2=80=9D is singular), so it needs =E2=80=9Capplies= =E2=80=9D, not =E2=80=9Capply=E2=80=9D. (And it=E2=80=99s correct two paragraphs later.) =E2=80=94 Barry --000000000000807c8e05a594d324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This review mostly includes comments about text that was = NOT changed in 8152bis, and is all minor editorial things.

=E2=80=94 Section 1 =E2=80=94

=C2=A0 =C2=A0CBOR was designed spe= cifically to be both small in terms
=C2=A0 =C2=A0of = messages transport and implementation size and be a schema-free
=C2=A0 =C2=A0decoder.

A couple of nits fixed here, =E2=80=9Cmessages transport=E2=80=9D= and =E2=80=9Cbe both ... and be=E2=80=9D:

NEW
CBOR was designed specificall= y both to be small in terms of messages transported and implementation size= , and to be a schema-free decoder.
END

=C2=A0 =C2=A0The JOSE working group p= roduced a set of documents [RFC7515]
=C2=A0 =C2=A0[R= FC7516] [RFC7517] [RFC7518] using JSON that specified how to
=C2=A0 =C2=A0process encryption, signatures, and Message Authenti= cation Code (MAC)
=C2=A0 =C2=A0operations and how to= encode keys using JSON.

There=E2=80=99s a redundancy with =E2=80=9Cusing JSON=E2=80=9D twice in th= at sentence.=C2=A0 I would remove the first instance and change the second = to =E2=80=9C, all using JSON.=E2=80=9D

=E2=80=94 Section 1.3 =E2=80=94

<= /div>
=C2=A0 =C2=A0* =C2=A0Use binary encodings for binary= data rather than base64url
=C2=A0 =C2=A0 =C2=A0 enc= odings.

As written, that= says that the document uses binary encodings for binary data, rather than = using binary encodings for base64url encodings.

=
NEW
=C2=A0 =C2=A0* =C2=A0Use= binary encodings, rather than base64url encodings,
= =C2=A0 =C2=A0 =C2=A0 to encode binary data.
END

=E2=80=94 Section 1.5 =E2=80= =94

=C2=A0 =C2=A0The pre= sence of a label in a CBOR map that is not a text string or an
=C2=A0 =C2=A0integer is an error.

I think you mean this:

NEW
=C2=A0 =C2=A0The presence in= a CBOR map of a label that is not a text string or an
=C2=A0 =C2=A0integer is an error.
END

=E2=80=94 Section 1.6 =E2=80=94

=C2=A0 =C2=A0context' h= eader parameter defined in [RFC8613], or identified by a
=C2=A0 =C2=A0protocol specific identifier.

=
Nit: hyphenate =E2=80=9Cprotocol-specific=E2=80=9D.=

=C2=A0 =C2=A0Context sh= ould generally be included
=C2=A0 =C2=A0in the crypt= ographic configuration, for more details see Section 4.3.

Comma splice: change the comma to a semic= olon.

=E2=80=94 Section = 4.1 =E2=80=94

=C2=A0 =C2= =A0An example of
=C2=A0 =C2=A0header a parameter abo= ut the content is the content type.=C2=A0 Examples
= =C2=A0 =C2=A0of a header parameters about the signature would be

Nits: =E2=80=9Cof a header paramet= er=E2=80=9D and =E2=80=9Cof header parameters=E2=80=9D

=E2=80=94 Section 6.1 =E2=80=94

=C2=A0 =C2=A0The same techniques and= nearly the same structure is used for
=C2=A0 =C2=A0= encrypting both the plaintext and the keys.

Nit: the subject is plural, so =E2=80=9Care used=E2=80= =9D.=C2=A0 Or to avoid the awkward =E2=80=9Cstructure are used=E2=80=9D, re= cast the sentence: =E2=80=9CBoth the plaintext and they keys are encrypted = using the same techniques and nearly the same structure.=E2=80=9D

=E2=80=94 Section 10 =E2=80=94
Same comment as in the algs doc:

=C2=A0 =C2=A0There has been an attempt to lim= it the number of places where the
=C2=A0 =C2=A0docum= ent needs to impose restrictions on how the CBOR Encoder needs
=C2=A0 =C2=A0to work.

Both instances of =E2=80=9Cneeds to=E2=80=9D seem odd.=C2=A0 For = that matter, so does
=E2=80=9Cthere has been an atte= mpt=E2=80=9D.=C2=A0 Maybe this, or something like it?:

NEW
This document lim= its the restrictions it imposes on how the CBOR
Enco= der can work.
END

<= div dir=3D"auto">=E2=80=94 Appendix A =E2=80=94

=
=C2=A0 =C2=A0The first set of
=C2=A0 =C2=A0recommendations apply to having an implicit algorithm identi= fied for
=C2=A0 =C2=A0a single layer of a COSE objec= t.=C2=A0 The second set of recommendations
=C2=A0 = =C2=A0apply to having multiple implicit algorithms identified for multiple<= /div>
=C2=A0 =C2=A0layers of a COSE object.=C2=A0 The thir= d set of recommendations apply to
=C2=A0 =C2=A0havin= g implicit algorithms for multiple COSE object constructs.

Nits: For all three sentences, =E2=80=9C= set of recommendations=E2=80=9D is a singular subject (=E2=80=9Cset=E2=80= =9D is singular), so it needs =E2=80=9Capplies=E2=80=9D, not =E2=80=9Capply= =E2=80=9D. =C2=A0(And it=E2=80=99s correct two paragraphs later.)

=E2=80=94=C2=A0
Barry
--000000000000807c8e05a594d324-- From nobody Thu May 14 13:39:54 2020 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 6174B3A0D26; Thu, 14 May 2020 13:39:52 -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 XWH0V80ko5Ty; Thu, 14 May 2020 13:39:50 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F693A0D23; Thu, 14 May 2020 13:39:49 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 May 2020 11:08:33 -0700 From: Jim Schaad To: 'Barry Leiba' , CC: References: In-Reply-To: Date: Wed, 13 May 2020 11:08:30 -0700 Message-ID: <018701d62951$84539bd0$8cfad370$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQINtj+cNFKyOMr199RO5+eEIdumXKg3LT6w Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_DIFF_CHECK?= 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, 14 May 2020 20:39:53 -0000 -----Original Message----- From: Barry Leiba =20 Sent: Tuesday, May 12, 2020 8:31 AM To: draft-ietf-cose-rfc8152bis-struct.all@ietf.org Cc: cose@ietf.org Subject: AD review of draft-ietf-cose-rfc8152bis-struct-08 =E2=80=94 = DIFF CHECK Hi, all. I've picked up the sponsorship of the two 8152bis drafts from = Ben in order to help share the load and get the documents moving faster = than Ben has time for just now. I've started AD review with a pass at the diffs between this document = and 8152; I will follow with a closer review of this document to see if = there are things that look like they should have been updated or = clarified, but weren't (I don't expect to find much there, but I want to = look). Here's the review of the diffs: Please be consistent about use of =E2=80=9Ccounter signature=E2=80=9D or = =E2=80=9Ccountersignature=E2=80=9D. Consider, for example, the = inconsistency in the 4th and 5th paragraphs of Section 5.1, and the = section title of 5 vs 5.1 and 5.2. (It looks like 8152 spelled it as two words and 8152bis = spells it as one. I don't care which way the WG wants to go for the = update, but it should be consistent throughout the document.) [JLS] Given that 8152 used two words, I made a pass to make it two words = here as well. =E2=80=94 Section 3 =E2=80=94 the value is wrapped in the binary object. Recipients MUST accept both a zero-length binary value and a zero-length map encoded in Should this say =E2=80=9Czero-length byte string=E2=80=9D for = consistency? [JLS] Looks good - done =E2=80=94 Section 4.3 =E2=80=94 proxy, or an attacker, changes the set of accept values by including the field in the application supplied data. Nit: hyphenate =E2=80=9Capplication-supplied=E2=80=9D. [JLS] look fine - done twice * If multiple items are included, applications need to ensure that the same byte string cannot produced if there are different Nit: =E2=80=9Ccannot be produced=E2=80=9D [JLS] looks fine - done =E2=80=94 Sections 4.4, 6.3, and 7.3 =E2=80=94 In bullets 2 and 3 in each, I think it=E2=80=99d be better to use = =E2=80=9Czero-length byte string=E2=80=9D for consistency in the text, = rather than =E2=80=9Cbstr of length zero=E2=80=9D or = =E2=80=9Czero-length bstr=E2=80=9D sometimes. [JLS] I don't feel strongly about this - done =E2=80=94 Section 5 =E2=80=94 It is always possible to construct cases where the decryption is successful, while providing completely different answers by using a different key. This situation is not detectable by a countersignature on the encrypted data. It took me a few readings of this to get what I think you mean. I = don=E2=80=99t think I would refer to this as =E2=80=9Cthe decryption is = successful.=E2=80=9D Might this be better said with something like this?: NEW It is always possible to construct cases where use of a different key = appears to result in successful decryption, but provides completely = different unencrypted data. This situation is not detectable by a = countersignature on the encrypted data. END [JLS] How about It is always possible to construct cases where the use of two different = keys will appear to result in a successful decryption (the tag check = success), but which produce two completely different plaintexts. This = situation is not detectable by a counter signature on the encrypted = data. =E2=80=94 Section 5.1 =E2=80=94 The full countersignature structure can be encoded as either a tagged or untagged depending on the context it is used in. Nit: remove =E2=80=9Ca=E2=80=9D. [JLS] Fine - done =E2=80=94 Section 5.2 =E2=80=94 Abbreviated countersignatures were designed primarily to deal with the problem of having group encrypted messaging Would =E2=80=9Cencrypted group messaging=E2=80=9D be better? The MLS = working group refers to "group messaging", and we're talking about = making that encrypted. [JLS] Core documents appear to use "secure group communication", but I = think that this change is still clear. done =E2=80=94 Section 7 =E2=80=94 COSE_MAC is used for all other cases. These include a requirement for multiple recipients, the key being unknown, or a recipient algorithm of other than direct. =E2=80=98Tis a total nit, but you changed =E2=80=9Cand=E2=80=9D to = =E2=80=9Cor=E2=80=9D here, and I think the change was incorrect, and the = original =E2=80=9Cand=E2=80=9D was correct =E2=80=94 the =E2=80=9Cother = cases=E2=80=9D include all three of the examples. [JLS] This change was made in response to a WG comment. I believe that = "or" is correct here as there are three different cases being listed = rather than a combination of the three cases. =E2=80=94 Section 9 =E2=80=94 This taxonomy should not be considered to be exhaustive as there are new algorithm structures that could be found or are not known to the author. This reads oddly to me: =E2=80=9Cthat could be found=E2=80=9D seems = strange, and =E2=80=9Cnot known to the author=E2=80=9D feels wrong in a = working group document. Can you try rewording this? [JLS] Does this seem better? In this section, a taxonomy of the different algorithm types = that can be used in COSE is laid out. This taxonomy should not be considered to be exhaustive. New algorithms will be created which will not fit into this = taxonomy. If this occurs, then new documents addressing this new = algorithms are going to be needed. =E2=80=94 Section 9.5.1 =E2=80=94 Should either or both instances of =E2=80=9Czero-length item=E2=80=9D = here be =E2=80=9Czero-length byte string=E2=80=9D or = =E2=80=9Czero-length text string=E2=80=9D so as to be appropriately = specific? [JLS] Yes they should - done. Jim -- Barry From nobody Thu May 14 13:57:10 2020 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 94D193A0D27; Thu, 14 May 2020 13:57:09 -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 q0DI_vQQyAYk; Thu, 14 May 2020 13:57:07 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6B33A08E3; Thu, 14 May 2020 13:57:06 -0700 (PDT) Received: from client-pool2-383.vpn.uni-bremen.de (client-pool2-383.vpn.uni-bremen.de [134.102.49.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49NP401gnKzyXt; Thu, 14 May 2020 22:57:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <018701d62951$84539bd0$8cfad370$@augustcellars.com> Date: Thu, 14 May 2020 22:57:03 +0200 Cc: Barry Leiba , draft-ietf-cose-rfc8152bis-struct.all@ietf.org, cose@ietf.org X-Mao-Original-Outgoing-Id: 611182623.229411-7407bd5ae541d36574cf0c3d3915374a Content-Transfer-Encoding: quoted-printable Message-Id: References: <018701d62951$84539bd0$8cfad370$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_DIFF_CHECK?= 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, 14 May 2020 20:57:10 -0000 On 2020-05-13, at 20:08, Jim Schaad wrote: >=20 > =E2=80=9Ccounter signature=E2=80=9D or =E2=80=9Ccountersignature=E2=80=9D= .=20 > [JLS] Given that 8152 used two words, I made a pass to make it two = words here as well. My dictionary does not agree. Neither does Wikipedia or Wiktionary: https://en.wikipedia.org/wiki/Countersign_(legal) https://en.wiktionary.org/wiki/countersignature Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 14 14:20:33 2020 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 5C5343A09DE; Thu, 14 May 2020 14:20:31 -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 yMOQ1h0C7ZY7; Thu, 14 May 2020 14:20:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554403A08F4; Thu, 14 May 2020 14:20:23 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 May 2020 14:20:14 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: 'Barry Leiba' , , References: <018701d62951$84539bd0$8cfad370$@augustcellars.com> In-Reply-To: Date: Thu, 14 May 2020 14:20:12 -0700 Message-ID: <022c01d62a35$75e0ac20$61a20460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQINtj+cNFKyOMr199RO5+eEIdumXAGcf4bCAH6DUzSoKCY4QA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_DIFF_CHECK?= 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, 14 May 2020 21:20:32 -0000 I looked at the dictionary before making that decision. -----Original Message----- From: Carsten Bormann =20 Sent: Thursday, May 14, 2020 1:57 PM To: Jim Schaad Cc: Barry Leiba ; = draft-ietf-cose-rfc8152bis-struct.all@ietf.org; cose@ietf.org Subject: Re: [COSE] AD review of draft-ietf-cose-rfc8152bis-struct-08 = =E2=80=94 DIFF CHECK On 2020-05-13, at 20:08, Jim Schaad wrote: >=20 > =E2=80=9Ccounter signature=E2=80=9D or = =E2=80=9Ccountersignature=E2=80=9D.=20 > [JLS] Given that 8152 used two words, I made a pass to make it two = words here as well. My dictionary does not agree. Neither does Wikipedia or Wiktionary: https://en.wikipedia.org/wiki/Countersign_(legal) https://en.wiktionary.org/wiki/countersignature Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 14 16:47:33 2020 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 8C4413A0736; Thu, 14 May 2020 16:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 EJj5vhBjx0Z1; Thu, 14 May 2020 16:47:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FD83A067A; Thu, 14 May 2020 16:47:26 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 May 2020 16:47:19 -0700 From: Jim Schaad To: 'Barry Leiba' , CC: References: In-Reply-To: Date: Thu, 14 May 2020 16:47:19 -0700 Message-ID: <024501d62a4a$01da7990$058f6cb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0246_01D62A0F.557CB300" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIOESST3HhtW8rbYCGuShPKr6FjB6g4aX6Q Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] =?utf-8?q?AD_review_of_draft-ietf-cose-rfc8152bis-struct-?= =?utf-8?q?08_=E2=80=94_THE_REST_OF_THE_REVIEW?= 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, 14 May 2020 23:47:31 -0000 ------=_NextPart_000_0246_01D62A0F.557CB300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ll post both at the same time =20 From: Barry Leiba =20 Sent: Wednesday, May 13, 2020 10:18 PM To: draft-ietf-cose-rfc8152bis-struct.all@ietf.org Cc: cose@ietf.org Subject: AD review of draft-ietf-cose-rfc8152bis-struct-08 =E2=80=94 THE = REST OF THE REVIEW =20 This review mostly includes comments about text that was NOT changed in = 8152bis, and is all minor editorial things. =20 =E2=80=94 Section 1 =E2=80=94 =20 CBOR was designed specifically to be both small in terms of messages transport and implementation size and be a schema-free decoder. =20 A couple of nits fixed here, =E2=80=9Cmessages transport=E2=80=9D and = =E2=80=9Cbe both ... and be=E2=80=9D: =20 NEW CBOR was designed specifically both to be small in terms of messages = transported and implementation size, and to be a schema-free decoder. END [JLS] looks fine - done =20 The JOSE working group produced a set of documents [RFC7515] [RFC7516] [RFC7517] [RFC7518] using JSON that specified how to process encryption, signatures, and Message Authentication Code (MAC) operations and how to encode keys using JSON. =20 There=E2=80=99s a redundancy with =E2=80=9Cusing JSON=E2=80=9D twice in = that sentence. I would remove the first instance and change the second = to =E2=80=9C, all using JSON.=E2=80=9D [JLS] Looks fine =E2=80=93 the first one is now gone. =20 =E2=80=94 Section 1.3 =E2=80=94 =20 * Use binary encodings for binary data rather than base64url encodings. =20 As written, that says that the document uses binary encodings for binary = data, rather than using binary encodings for base64url encodings. =20 NEW * Use binary encodings, rather than base64url encodings, to encode binary data. END [JLS] Reasonable - done =20 =E2=80=94 Section 1.5 =E2=80=94 =20 The presence of a label in a CBOR map that is not a text string or an integer is an error. =20 I think you mean this: =20 NEW The presence in a CBOR map of a label that is not a text string or an integer is an error. END [JLS] Looks fine =E2=80=93 done. =20 =E2=80=94 Section 1.6 =E2=80=94 =20 context' header parameter defined in [RFC8613], or identified by a protocol specific identifier. =20 Nit: hyphenate =E2=80=9Cprotocol-specific=E2=80=9D. [JLS] I guess I need to learn rules on this - done =20 Context should generally be included in the cryptographic configuration, for more details see Section 4.3. =20 Comma splice: change the comma to a semicolon. [JLS] done =20 =E2=80=94 Section 4.1 =E2=80=94 =20 An example of header a parameter about the content is the content type. Examples of a header parameters about the signature would be =20 Nits: =E2=80=9Cof a header parameter=E2=80=9D and =E2=80=9Cof header = parameters=E2=80=9D [JLS] done =20 =E2=80=94 Section 6.1 =E2=80=94 =20 The same techniques and nearly the same structure is used for encrypting both the plaintext and the keys. =20 Nit: the subject is plural, so =E2=80=9Care used=E2=80=9D. Or to avoid = the awkward =E2=80=9Cstructure are used=E2=80=9D, recast the sentence: = =E2=80=9CBoth the plaintext and they keys are encrypted using the same = techniques and nearly the same structure.=E2=80=9D [JLS] Just changed to plural. I think it stresses what I want to stress = better. =20 =E2=80=94 Section 10 =E2=80=94 Same comment as in the algs doc: =20 There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. =20 Both instances of =E2=80=9Cneeds to=E2=80=9D seem odd. For that matter, = so does =E2=80=9Cthere has been an attempt=E2=80=9D. Maybe this, or something = like it?: =20 NEW This document limits the restrictions it imposes on how the CBOR Encoder can work. END [JLS] Yes that reads better - done =20 =E2=80=94 Appendix A =E2=80=94 =20 The first set of recommendations apply to having an implicit algorithm identified for a single layer of a COSE object. The second set of recommendations apply to having multiple implicit algorithms identified for multiple layers of a COSE object. The third set of recommendations apply to having implicit algorithms for multiple COSE object constructs. =20 Nits: For all three sentences, =E2=80=9Cset of recommendations=E2=80=9D = is a singular subject (=E2=80=9Cset=E2=80=9D is singular), so it needs = =E2=80=9Capplies=E2=80=9D, not =E2=80=9Capply=E2=80=9D. (And = it=E2=80=99s correct two paragraphs later.) [JLS] that looks right =E2=80=93 done. =20 =E2=80=94=20 Barry ------=_NextPart_000_0246_01D62A0F.557CB300 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I=E2=80=99ll post both at the same = time

 

From: Barry Leiba = <barryleiba@computer.org>
Sent: Wednesday, May 13, 2020 = 10:18 PM
To: = draft-ietf-cose-rfc8152bis-struct.all@ietf.org
Cc: = cose@ietf.org
Subject: AD review of = draft-ietf-cose-rfc8152bis-struct-08 =E2=80=94 THE REST OF THE = REVIEW

 

This = review mostly includes comments about text that was NOT changed in = 8152bis, and is all minor editorial things.

 

=E2=80=94 Section 1 = =E2=80=94

 

   CBOR was designed specifically to be both = small in terms

  =  of messages transport and implementation size and be a = schema-free

  =  decoder.

 

A = couple of nits fixed here, =E2=80=9Cmessages transport=E2=80=9D and = =E2=80=9Cbe both ... and be=E2=80=9D:

 

NEW

CBOR = was designed specifically both to be small in terms of messages = transported and implementation size, and to be a schema-free = decoder.

END

[JLS] looks = fine - done

 

   The JOSE working group produced a set of = documents [RFC7515]

  =  [RFC7516] [RFC7517] [RFC7518] using JSON that specified how = to

   process = encryption, signatures, and Message Authentication Code = (MAC)

  =  operations and how to encode keys using = JSON.

 

There=E2=80=99s a redundancy with =E2=80=9Cusing = JSON=E2=80=9D twice in that sentence.  I would remove the first = instance and change the second to =E2=80=9C, all using = JSON.=E2=80=9D

[JLS] Looks fine = =E2=80=93 the first one is now gone.

 

=E2=80=94 Section 1.3 = =E2=80=94

 

   *  Use binary encodings for binary = data rather than base64url

      = encodings.

 

As written, that says that the document uses binary = encodings for binary data, rather than using binary encodings for = base64url encodings.

 

NEW

   *  Use binary encodings, rather than = base64url encodings,

      to encode binary = data.

END

[JLS] Reasonable - done

 

=E2=80=94 Section 1.5 = =E2=80=94

 

   The presence of a label in a CBOR map = that is not a text string or an

   integer is an = error.

 

I = think you mean this:

 

NEW

   The presence in a CBOR map of a label = that is not a text string or an

   integer is an = error.

END

[JLS] Looks = fine =E2=80=93 done.

 

=E2=80=94 Section 1.6 = =E2=80=94

 

   context' header parameter defined in = [RFC8613], or identified by a

   protocol specific = identifier.

 

Nit: hyphenate = =E2=80=9Cprotocol-specific=E2=80=9D.

[JLS] I guess I need to learn rules on this - = done

 

   Context should generally be = included

   in = the cryptographic configuration, for more details see Section = 4.3.

 

Comma splice: change the comma to a = semicolon.

[JLS] = done

 

=E2=80=94 Section 4.1 = =E2=80=94

 

   An example of

   header a parameter about the content is = the content type.  Examples

   of a header parameters about the = signature would be

 

Nits: =E2=80=9Cof a header parameter=E2=80=9D and = =E2=80=9Cof header parameters=E2=80=9D

[JLS] done

 

=E2=80=94 Section 6.1 = =E2=80=94

 

   The same techniques and nearly the same = structure is used for

   encrypting both the plaintext and the = keys.

 

Nit: the subject is plural, so =E2=80=9Care = used=E2=80=9D.  Or to avoid the awkward =E2=80=9Cstructure are = used=E2=80=9D, recast the sentence: =E2=80=9CBoth the plaintext and they = keys are encrypted using the same techniques and nearly the same = structure.=E2=80=9D

[JLS] Just = changed to plural. =C2=A0I think it stresses what I want to stress = better.

 

=E2=80=94 Section 10 = =E2=80=94

Same comment as = in the algs doc:

 

   There has been an attempt to limit the = number of places where the

   document needs to impose restrictions on = how the CBOR Encoder needs

   to work.

 

Both instances of =E2=80=9Cneeds to=E2=80=9D seem = odd.  For that matter, so does

=E2=80=9Cthere has been an attempt=E2=80=9D.  = Maybe this, or something like it?:

 

NEW

This = document limits the restrictions it imposes on how the = CBOR

Encoder can = work.

END

[JLS] Yes that reads better - = done

 

=E2=80=94 Appendix A = =E2=80=94

 

   The first set = of

  =  recommendations apply to having an implicit algorithm identified = for

   a single = layer of a COSE object.  The second set of = recommendations

  =  apply to having multiple implicit algorithms identified for = multiple

  =  layers of a COSE object.  The third set of recommendations = apply to

  =  having implicit algorithms for multiple COSE object = constructs.

 

Nits: For all three sentences, =E2=80=9Cset of = recommendations=E2=80=9D is a singular subject (=E2=80=9Cset=E2=80=9D is = singular), so it needs =E2=80=9Capplies=E2=80=9D, not = =E2=80=9Capply=E2=80=9D.  (And it=E2=80=99s correct two paragraphs = later.)

[JLS] that looks right = =E2=80=93 done.

 

=E2=80=94 

Barry

------=_NextPart_000_0246_01D62A0F.557CB300-- From nobody Thu May 14 20:51:37 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B943A0891; Thu, 14 May 2020 20:51:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <158951467831.16344.4689713722859811284@ietfa.amsl.com> Date: Thu, 14 May 2020 20:51:18 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-struct-09.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 03:51:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Structures and Process Author : Jim Schaad Filename : draft-ietf-cose-rfc8152bis-struct-09.txt Pages : 86 Date : 2020-05-14 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-09 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-struct-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 14 20:51:44 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 828F63A08A5; Thu, 14 May 2020 20:51:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <158951468649.24953.12426681223279388649@ietfa.amsl.com> Date: Thu, 14 May 2020 20:51:26 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-algs-08.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 03:51:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Initial Algorithms Author : Jim Schaad Filename : draft-ietf-cose-rfc8152bis-algs-08.txt Pages : 49 Date : 2020-05-14 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. The details of the structure of COSE are defined in [I-D.ietf-cose-rfc8152bis-struct]. This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes RFC8152. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-08 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-algs-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 14 21:28:49 2020 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 E12AF3A08DC for ; Thu, 14 May 2020 21:28:46 -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 P4EqgnDhXpZk for ; Thu, 14 May 2020 21:28:44 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2FB3A08DB for ; Thu, 14 May 2020 21:28:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 May 2020 21:28:37 -0700 From: Jim Schaad To: References: <158951467875.16344.15453633981661754390@ietfa.amsl.com> In-Reply-To: <158951467875.16344.15453633981661754390@ietfa.amsl.com> Date: Thu, 14 May 2020 21:28:34 -0700 Message-ID: <026d01d62a71$4d695cb0$e83c1610$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFbd2u9Sj29dE2/StoFe14KheUAvKmd85ww Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-rfc8152bis-struct-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: Fri, 15 May 2020 04:28:47 -0000 I have published this draft and the algs draft to deal with the AD = review. -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Thursday, May 14, 2020 8:51 PM To: Jim Schaad Subject: New Version Notification for = draft-ietf-cose-rfc8152bis-struct-09.txt A new version of I-D, draft-ietf-cose-rfc8152bis-struct-09.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-cose-rfc8152bis-struct Revision: 09 Title: CBOR Object Signing and Encryption (COSE): Structures and = Process Document date: 2020-05-14 Group: cose Pages: 86 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-struct-09= .txt Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ Htmlized: = https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-09 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-rfc8152bis-struct-09 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Fri May 15 06:30:44 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA283A09EF; Fri, 15 May 2020 06:30:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk CC: Matthew Miller , cose@ietf.org, barryleiba@gmail.com, draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, linuxwolf+ietf@outer-planes.net Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158954944170.21535.12532431418494332686@ietfa.amsl.com> Date: Fri, 15 May 2020 06:30:42 -0700 Archived-At: Subject: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Structures and Process) to Internet Standard X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 13:30:42 -0000 The IESG has received a request from the CBOR Object Signing and Encryption WG (cose) to consider the following document: - 'CBOR Object Signing and Encryption (COSE): Structures and Process' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-cose-rfc8152bis-algs: CBOR Object Signing and Encryption (COSE): Initial Algorithms (None - IETF stream) rfc7049: Concise Binary Object Representation (CBOR) (Proposed Standard - IETF stream) From nobody Fri May 15 06:35:55 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72F3A09F3; Fri, 15 May 2020 06:35:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk CC: cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net, barryleiba@gmail.com, draft-ietf-cose-rfc8152bis-algs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158954975258.11082.4524607222712464593@ietfa.amsl.com> Date: Fri, 15 May 2020 06:35:53 -0700 Archived-At: Subject: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Initial Algorithms) to Informational RFC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 13:35:54 -0000 The IESG has received a request from the CBOR Object Signing and Encryption WG (cose) to consider the following document: - 'CBOR Object Signing and Encryption (COSE): Initial Algorithms' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. The details of the structure of COSE are defined in [I-D.ietf-cose-rfc8152bis-struct]. This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes RFC8152. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ No IPR declarations have been submitted directly on this I-D. From nobody Sat May 16 22:49:30 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A9B3A0D8B; Sat, 16 May 2020 22:49:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gyan Mishra via Datatracker To: Cc: draft-ietf-cose-hash-algs.all@ietf.org, last-call@ietf.org, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158969456572.24607.4640414087582471657@ietfa.amsl.com> Reply-To: Gyan Mishra Date: Sat, 16 May 2020 22:49:25 -0700 Archived-At: Subject: [COSE] Genart last call review of draft-ietf-cose-hash-algs-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2020 05:49:26 -0000 Reviewer: Gyan Mishra Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cose-hash-algs-?? Reviewer: Gyan Mishra Review Date: 2020-05-16 IETF LC End Date: 2020-05-26 IESG Telechat date: Not scheduled for a telechat Summary: No issues found. This document is ready for me publication. Major issues: None Minor issues: None Nits/editorial comments: None From nobody Tue May 19 02:35:57 2020 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 A75273A09C8; Tue, 19 May 2020 02:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=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=btconnect.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 ngfVlhBXhxLu; Tue, 19 May 2020 02:35:52 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70118.outbound.protection.outlook.com [40.107.7.118]) (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 779993A09C4; Tue, 19 May 2020 02:35:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F2zDjEv2+l6FuahiFhureFsDPImrTJ3IygWS+nlx32vJr20YMiKtVqguoh8OSerwtsefYx2c+7p6SI3/qFPo00PsA95vKJifkTIr5ESz9rdDw9mUAi7GiCu89CqxMsA9Hu6XN41uBIHm+dHdwJ0bkgtumkqBN8a+HyXCjUmMC7ssTV8b2gIt0HILgBKO4HeCkw4Sny6xCcpf/Ce+90aNV952iqB/RaXJI25HdE1d9fbYqXbX2K1BbVSzvvs8TK9Sx7EJqXjPzA8BmwIcSMcdJkhA+ZJGKcNCaPjJ8xJ7+DVdfYL5f0Q/vZCUrTNJIZMh9zhYUrlYnnQ5SjrihQnYnw== 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=+0sZRRH6w9ia+9aE6QoNH5NFnGceAILcMFQgk628o6c=; b=imNU/3Hsf9R/R5ZwLHQ7i2OGZaxoHXoeahnsNLTZ7qJ9LsR4jOPGT4fOPfWMuhcs3190qN1hLG8fLv/TVx+9sz2RD5s/WtrS8SQdNCu7l13fb2I/vSgEeFolU+X29SH5RyIhxjhbio70nao81qVgTbrYnROamxVtMjZ3wrptsOZKo7Ny2VYzRcaaWyC2bfm+QzUNOG4q15q1h1cd36sX7JKW9g+MkzuJaEM5ykZ9t4kYOKdLO5mJnu06BEbdQJpySt8ZRgxvIK8qnnh65H2tnkfbBNE6UerpCkZheA7W4OKSAlo6DRQvrVmZ1QiidlyhNJjMmngZN+bkNIxs6gLGDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+0sZRRH6w9ia+9aE6QoNH5NFnGceAILcMFQgk628o6c=; b=XaTIV1RFaaQe7r7RZjoDTsgqzlirpS4NcWQUdOX+J1TDFliuYzMSycOGT0i350EDXAiv4WxkB128yCZDxrPNjls/uRELMZFG7pV8IokPygm9xYcDbZS7ZwLXypPBiaWJ8iGxLza5Dc6D0zcGmK3TnJyO7lyre0/u3akTdSCEgsg= Authentication-Results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB2192.eurprd07.prod.outlook.com (2603:10a6:800:31::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.11; Tue, 19 May 2020 09:35:48 +0000 Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3021.019; Tue, 19 May 2020 09:35:48 +0000 To: Last Call Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, ivaylo@ackl.io From: tom petch Message-ID: <5EC3A871.80903@btconnect.com> Date: Tue, 19 May 2020 10:35:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0257.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::29) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (81.131.229.108) by LO2P265CA0257.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3000.25 via Frontend Transport; Tue, 19 May 2020 09:35:47 +0000 X-Originating-IP: [81.131.229.108] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7acc53a5-b2d1-4d6b-182a-08d7fbd8032f X-MS-TrafficTypeDiagnostic: VI1PR0701MB2192: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 040866B734 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9gvj5Qycjz6Y8Mn6ubFPBDfbhUxou4Q51bkaRSc8UOYlb+ek4T+6ncZQ/0JWzKWzK8xjX1ayv3mdYT+kNgWO07v6qoXNN2uUybeU+xm4GvoXvuuD9dBnAnJLEp9+Gj4beuVeWp4fPbGjDWYmkYNdjr0NYJhXwegqBlgCiQe8qTcCyMlyB4AEXen69bsgu2I5+eibrng1A1bb0J2pTE+j2RnaDRHXITzT3nOAoXUVIYTIixtcaVL/QyfOTS//cLjFxh3bL1hUccU9TqhpqD/2LAYdRG3LP4XT+YykukUTQ5e63CIvbAJqiRE6IaxnvDaDVPQVnvSePYVJC/k0dD5eeSn+lPzwJ26ggrfWIi/djOJYw1qM6ktvEmEoifd4a6Uc5od7qFuTviYmrzXo6xppDG5YlK4RCeHgf9dZkzUh+yk7eSQA0sQG8KUW2UEyKBSCLKCX9nsoVDHa/dzR0cZI0wLBm8ix/CKudx3Ylh+XfL4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39860400002)(136003)(396003)(376002)(346002)(8676002)(52116002)(16576012)(33656002)(8936002)(86362001)(478600001)(5660300002)(6486002)(6916009)(16526019)(186003)(2906002)(26005)(316002)(36756003)(4326008)(956004)(2616005)(966005)(66476007)(66946007)(66556008)(49324003)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: E9p/gv/bUWchXtOz5tQ3SoWJ49TVSyYkyAZK65dBqt4b2sAiIJL+jrIfRCbMRPTBkhOv8BxH8zYtRTLUXtXeH/Y3wMSinPDUrww4gIe6qhdIbFNqINcT4/x2MsAIW+x8Kqk7EbT/K9aKWQtHv7LkRNFzZkI9QQhmG9+AOUEkYDrwgwf8oYfdZHqOvvtOFr5wSggRJaLDp1ZiwHHEWSptxt7t+am8BLDpUd4dM7PM0NClJVe+LVcrwfuA1mOS8yNzUT7BFLttcSLlEGMcMpT4mFS0wT6cXVA0iaB9iywbeL6Hsl6KelKr1l+tAwz53ygOjrzQSc8IknlxkV2zGPs/rJSAn+UwP94eZL+Fm4joH4ffGIf2q6LqnEv/E1KoCeSqdQGucbPLFHB1CTpIR5Y/LlN7bVRWhFSQ9yL95ShexnJveGl/Ke+CWn6DMUBNJ3n2o3sHmMODCYg5sv8ahZwkPW1OQxVEYyQFg96Fpucc8vc= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7acc53a5-b2d1-4d6b-182a-08d7fbd8032f X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2020 09:35:48.5978 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vhRrTo3snbW5ehvKU0kJatCrkhU4OkyYCXLJOETgoSNirLMD/8K/essdJ2wY2MzLTC/uJeunj8nMwgLsgCRORw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2192 Archived-At: Subject: Re: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC 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, 19 May 2020 09:35:56 -0000 I encounter a number of problems with this I-D. Much of it is about IANA Considerations and I note the absence of a reference to RFC8126 which provides the basis for much of my comments. RFC8126 specifies a two-tier structure for IANA, of Group name an Registry name, which makes it easier to find data, now and in future. This I-D makes no mention of the Group name; perhaps easy enough to guess in this instance, but better specified. The I-D contains references to some of TBD1 to TBD11, with no indication of what to do with them. Looking at the current registry it is apparent that Early Allocation took place in 2018 and 2019. The I-D makes no reference to this. Are all these values to be made permanent? Some of them? I expect the I-D to say. The I-D adds the value 'filter only' to one of the columns. The registry was set up by RFC8152 which lists permitted values of which this is not one. This then constitutes an update to RFC8152 which the I-D does not mention. The registry has five columns; this I-D adds a new one, Capabilities, another update to RFC8152. What then happens to this column for existing entries in the registry? The I-D is silent. RFC8152 is Standards Track; this I-D which IMHO updates it is Informational. The IANA registry entry gives a reference of 'RFC8152'; this I-D, which changes the specification of the registry, needs adding to that reference. RFC8126 recommends that IANA Considerations be for IANA, that IANA does not have to search the rest of the document for the data it needs. Here, the relevant data appears in three other sections as well (and there is much in the I-D that is not relevant to IANA, it is not one of those I-D that is only about IANA). Abstract should be plain text - [I-D.ietf-cose-rfc8152bis-struct] does not look like plain text. I have great faith in the ability of IANA to make sense of what they are asked to do but do think that the more straightforward that is the better. And then there are those that come after, who want the RFC to say what happened and why without digging into the e-mail archives (as I see happening now and again:-) Tom Petch > ----- Original Message ----- > From: "IETF-Announce on behalf of The IESG" > > To: > Cc: ; ; > ; > Sent: Tuesday, May 12, 2020 4:26 PM > >> The IESG has received a request from the CBOR Object Signing and > Encryption >> WG (cose) to consider the following document: - 'CBOR Object Signing > and >> Encryption (COSE): Hash Algorithms' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2020-05-26. Exceptionally, > comments may >> be sent to iesg@ietf.org instead. In either case, please retain the > beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The CBOR Object Signing and Encryption (COSE) syntax >> [I-D.ietf-cose-rfc8152bis-struct] does not define any direct > methods >> for using hash algorithms. There are however circumstances where >> hash algorithms are used: Indirect signatures where the hash of one >> or more contents are signed. X.509 certificate or other object >> identification by the use of a fingerprint. This document defines > a >> set of hash algorithms that are identified by COSE Algorithm >> Identifiers. >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> = From nobody Wed May 20 18:22:24 2020 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 8A0963A09A5; Wed, 20 May 2020 18:22:16 -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 ukJaNrnr1xgV; Wed, 20 May 2020 18:22:14 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EAD3A0852; Wed, 20 May 2020 18:22:13 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 May 2020 18:22:06 -0700 From: Jim Schaad To: 'tom petch' , 'Last Call' CC: , , , References: <5EC3A871.80903@btconnect.com> In-Reply-To: <5EC3A871.80903@btconnect.com> Date: Wed, 20 May 2020 18:21:39 -0700 Message-ID: <018e01d62f0e$3e91d2c0$bbb57840$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGmNH7wUMPaiAgjusIg758qJa0OcKkRopFg X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC 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, 21 May 2020 01:22:17 -0000 -----Original Message----- From: COSE On Behalf Of tom petch Sent: Tuesday, May 19, 2020 2:36 AM To: Last Call Cc: ivaylo@ackl.io; cose-chairs@ietf.org; draft-ietf-cose-hash-algs@ietf.org; cose@ietf.org Subject: Re: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC I encounter a number of problems with this I-D. Much of it is about IANA Considerations and I note the absence of a reference to RFC8126 which provides the basis for much of my comments. [JLS] There is a reason why you are not seeing much of the IANA Considerations that you believe should be present, it is because they are in draft-ietf-cose-rfc8152bis-algs and draft-ietf-cose-rfc8152bis-struct. Most of them are in the algorithm document. The presumption is that those two documents are going to be processed by IANA before this document is. I will make this explicit. RFC8126 specifies a two-tier structure for IANA, of Group name an Registry name, which makes it easier to find data, now and in future. This I-D makes no mention of the Group name; perhaps easy enough to guess in this instance, but better specified. The I-D contains references to some of TBD1 to TBD11, with no indication of what to do with them. Looking at the current registry it is apparent that Early Allocation took place in 2018 and 2019. The I-D makes no reference to this. Are all these values to be made permanent? Some of them? I expect the I-D to say. [JLS] use the TBD placeholders is normal usage with the values being assigned by IANA and replaced in the document. It would be possible to refer to the early assignments, but I personally feel that this is a decision for IANA to make. There may be reasons when the final assignment is done that different values need to be used. (For example, incorrect usage of existing values in the wild or collisions found during the assignment process.) I have always made the assumption that the instruction for the RFC Editor to replace them is implicit and does not need to be explicit. I can make that change although I doubt it makes any difference. The I-D adds the value 'filter only' to one of the columns. The registry was set up by RFC8152 which lists permitted values of which this is not one. This then constitutes an update to RFC8152 which the I-D does not mention. [JLS] I would disagree that this requires an update of RFC 8152 for two reasons. First this is not a change in the COSE protocol in any manner and thus would violate what I consider to be the letter of the law for updates. Second, when this change is made RFC 8152 will have been obsoleted by a new RFC and thus it does not really make sense to update it. This is an IANA instruction not a protocol change. The registry has five columns; this I-D adds a new one, Capabilities, another update to RFC8152. What then happens to this column for existing entries in the registry? The I-D is silent. [JLS] This is done by a different document. RFC8152 is Standards Track; this I-D which IMHO updates it is Informational. [JLS] Given that it is updating the IANA sections and not the protocol I would not consider that to be an issue. The IANA registry entry gives a reference of 'RFC8152'; this I-D, which changes the specification of the registry, needs adding to that reference. [JLS] This make sense and I will do it. RFC8126 recommends that IANA Considerations be for IANA, that IANA does not have to search the rest of the document for the data it needs. Here, the relevant data appears in three other sections as well (and there is much in the I-D that is not relevant to IANA, it is not one of those I-D that is only about IANA). [JLS] I do not consider that pointing to a table in the document to fall under the rubric of making IANA search for data. It is a direct pointer to the information that is required. Having the same table appear multiple times in a document is a recipe for making mistakes in terms of what the data is. There is already the problem of trying to harmonize text and the table with out adding another version of the table. Abstract should be plain text - [I-D.ietf-cose-rfc8152bis-struct] does not look like plain text. [JLS] This is not plain text and will be repaired by the RFC editor. Using the reference structure makes it clearer that this is something that the RFC editor is going to be required to update. This is not something I do for documents which are already RFCs. I have great faith in the ability of IANA to make sense of what they are asked to do but do think that the more straightforward that is the better. And then there are those that come after, who want the RFC to say what happened and why without digging into the e-mail archives (as I see happening now and again:-) [JLS] The other problem that you have not highlighted is the question of when a bis document is created should the IANA instructions be propagated forward into the new document despite the fact that IANA is not going to do anything. That is what is going to happen with some of these registries. It makes life even harder if duplicate or extraneous items are included. Jim Tom Petch > ----- Original Message ----- > From: "IETF-Announce on behalf of The IESG" > > To: > Cc: ; ; > ; > Sent: Tuesday, May 12, 2020 4:26 PM > >> The IESG has received a request from the CBOR Object Signing and > Encryption >> WG (cose) to consider the following document: - 'CBOR Object Signing > and >> Encryption (COSE): Hash Algorithms' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2020-05-26. Exceptionally, > comments may >> be sent to iesg@ietf.org instead. In either case, please retain the > beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The CBOR Object Signing and Encryption (COSE) syntax >> [I-D.ietf-cose-rfc8152bis-struct] does not define any direct > methods >> for using hash algorithms. There are however circumstances where >> hash algorithms are used: Indirect signatures where the hash of one >> or more contents are signed. X.509 certificate or other object >> identification by the use of a fingerprint. This document >> defines > a >> set of hash algorithms that are identified by COSE Algorithm >> Identifiers. >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> = _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Thu May 21 02:30:59 2020 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 B9A043A0B5B; Thu, 21 May 2020 02:30:41 -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, MSGID_FROM_MTA_HEADER=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=btconnect.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 mf9tQcwBuYG4; Thu, 21 May 2020 02:30:39 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2091.outbound.protection.outlook.com [40.107.21.91]) (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 CC78E3A0B5D; Thu, 21 May 2020 02:30:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hATWzvVXn6c+hRvogmmcIp4I9ZAcCyWy01UxOxTwkrDSQYnrF1ZMJT8NIrdfiusxt9ki95437FFafv8iqkM8eAbPtIPsSPNWkGsy6bBtByaxuhb6sG7TKMvvgAOAhS9bpSDb3UqkNrSNi0KIwmbcYW5kOEbCYU4P8yCzmHGVh4KZQNS+SQPuWqLhV/Y73ah2ZWNJvPZ+XQBLPC8snKjKm844lI4+XNds0sEE8uC4cXTFGyP6cScW53KMjPbxnvR4/+Fry5gPe74mw+p4tVGeb007tIfauN+z56kGlghTT92L81hH8MvGBOLdqWXSdEJrmLqGLd5oMfqeOlqZyMnaAA== 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=BU1+l9kgFo4szWOxlK8Kt52FQp+ZFm8Ab2me2GW6T10=; b=HYgfBwX6Mqhk6q5C8KbBDnxDw3hLk+v7cDXkFCSOOwj3Xkx/TRfr69t6CXq/xwbw5YWlYVVnf+gPj2qQ8jHKgnt2mObh27F16i/na+PTX2Wcb6EtVYw2CJgEEv2gCB7wL7LNNS2QSw+GnVDbP98Lc1eLB20xuM8HAz3kZi90vvPLUw0DmnBkhJ3NmeQPhsYku3VK2ZN2ORKnvOBt1npnvt9f4jUISODSEsq2gVKWm5VChUe4ZYQkabGF/f8PocQW1VoDDUJqnP4sxp0k+6r06pviMQJl/8vtS1kKZBxoTqvrttBDNr+KufAbkFu/yU0Ha4Q2TSRpVMU2NbcZ8j/0nA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BU1+l9kgFo4szWOxlK8Kt52FQp+ZFm8Ab2me2GW6T10=; b=gQ6x+cyQUbpcMfCjCwr1Z5P5+2cWwSWWzTHADTBp9QbMMeOTUCmkVSiQi/KySbRjH7Do8jQ47FnpG453B/srxDD8tRyvFPY8FTquy9FYqflCRQMWS5oJBZnISFRNNrEgk0Vnh+gXXUbCK4YYFm52SaFy12pJoWkGqTJ+1oe/fMg= Authentication-Results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB2992.eurprd07.prod.outlook.com (2603:10a6:800:81::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.13; Thu, 21 May 2020 09:30:35 +0000 Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3021.019; Thu, 21 May 2020 09:30:35 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable References: <5EC3A871.80903@btconnect.com> <018e01d62f0e$3e91d2c0$bbb57840$@augustcellars.com> Date: Thu, 21 May 2020 10:30:18 +0100 Message-ID: <1UW9V85i5B.1X3e1rfkHhW@pc8xp> In-Reply-To: <018e01d62f0e$3e91d2c0$bbb57840$@augustcellars.com> From: "tom petch" To: "Jim Schaad" , "'Last Call'" Cc: "ivaylo@ackl.io" , "cose-chairs@ietf.org" , "draft-ietf-cose-hash-algs@ietf.org" , "cose@ietf.org" User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28) X-ClientProxiedBy: LO2P265CA0383.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::35) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from pc8xp (81.131.229.108) by LO2P265CA0383.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24 via Frontend Transport; Thu, 21 May 2020 09:30:34 +0000 X-Originating-IP: [81.131.229.108] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4c572c1b-588c-4b10-e06d-08d7fd699d57 X-MS-TrafficTypeDiagnostic: VI1PR0701MB2992: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 041032FF37 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ey4rH6QS3nIVZ5EhL6pq9B2n5DlLUthMt7clkoaKwmlpCgbbjmNaAsoMBRG71869i27l7Fkry0ED4BMoXG3xMKMKpAQYvRq4PjyEORRd4fJFVnp8PyX+0uwKuvn3KX8/5ye1AA5tOYaC7Xf+jAIsmGdNZD1EC4I04sjxLKr49ZNl2l3amr/qhK3i3qWzC7pFmuFtwZW5+nsfK+EBpbNDrm1OIITbPyIZDh4eA4BlUz9RnBvEBFXheaW5tnOQNkQvuyvY/b39G/ChT64Vo7Yn7YmiY3wFT/Qpr2U/oagHk1dkt90Q4hCPHrPt69jCgOqML0Nui1+w1khERpoiXtFFy0QWc8kX40FnJ+9HTHCC51+9X33cRokxzwz116KJVdb9/DmcigghtOQHAIZV3Dn5IUm0vDLrPG57LG4pCzGmy8D4K6wxzdrSThYb6x0Ct2r+T8Yei3MU5zXzvZXnNgUhFA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(39860400002)(136003)(366004)(396003)(186003)(54906003)(110136005)(52230400001)(16526019)(55016002)(45080400002)(6666004)(9686003)(4326008)(8936002)(26005)(316002)(956004)(8676002)(86362001)(6496006)(2906002)(966005)(9576002)(66556008)(5660300002)(66946007)(66476007)(52116002)(478600001)(33716001)(49324003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: xNQZBs06Ypbh7GPmG1BjYIsAdmqyL3nirNxXJIfZXxQ3ohH7j73T+q/oxizDYNdGnGQaaqW9ZLETfcxLa3Bmsta2uwqyxtpESmUyhaVLQWEP9zJAAAWyqgNgIw0Z7wCP4mV0CfbyZOJ8CUyi/Mt6F+kfAvKq6fD02oVYm7jigZ88tU2KILdvRGR8iG7g65NpgChQKeJSwpCDl02IOxtWy3Jau1PXd9BUskjAl1+d9OdwsRX0Hr9hRPSEVR3fESwN8Rd7QOZKO2rSdLJZ4gCxNCL3b+xbwC4TH2TWOKeYDgNtQ1HQ6cPLVkaCGojyjEs3PThiAfRqjsblbNaY5/Ik6Dr2QyxmMssTIcitvBo6ns6QYXbilK5ckkrj4YZOkw065qMr4h0Lc9kiKbNZzwGptauvW7BRV4wGil9uI8wLEhjNMdk1aHdC1lebT+9ByQgQ9yMAG/sdkMhDy2WYzo1Tk9FWMQjqZK1YXQDbRDOzgXE= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c572c1b-588c-4b10-e06d-08d7fd699d57 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2020 09:30:35.4587 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mNjDr3EIWxaaExc58NcdbrGm5X1FXKMM30/WVvv71AXR6P2CTonIVF/2hHWHB8WtH19nidSzOFBH6EJ9/wVGiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2992 Archived-At: Subject: Re: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC 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, 21 May 2020 09:30:42 -0000 Jim=20 inline several times ----- Original Message ----- From: Jim Schaad ietf@augustcellars.com Sent: 21/05/2020 02:21:39 -----Original Message----- From: COSE On Behalf Of tom petch Sent: Tuesday, May 19, 2020 2:36 AM I encounter a number of problems with this I-D. Much of it is about IANA Considerations and I note the absence of a reference to RFC8126 which provides the basis for much of my comments. [JLS] There is a reason why you are not seeing much of the IANA Considerations that you believe should be present, it is because they are i= n draft-ietf-cose-rfc8152bis-algs and draft-ietf-cose-rfc8152bis-struct. Mos= t of them are in the algorithm document. The presumption is that those two documents are going to be processed by IANA before this document is. I wil= l make this explicit. Yes, if there had been a Normative Reference to rfc8152bis-algs then I wou= ld have read that first and my comments would have been different! If the = updates to the IANA Registry are all in -algs, then I think it confusing to= have them in here as well, rather just say that a new column is defined in= -algs I do not see any mention of 'filter only' in the two rfc8152bis, only in th= is I-D and that makes me see this I-D as updating RFC8152 with the conseque= nces thereof. RFC8126 specifies a two-tier structure for IANA, of Group name an Registry name, which makes it easier to find data, now and in future. This I-D makes no mention of the Group name; perhaps easy enough to guess i= n this instance, but better specified. The I-D contains references to some of TBD1 to TBD11, with no indication of what to do with them. Looking at the current registry it is apparent that Early Allocation took place in 2018 and 2019. The I-D makes no reference t= o this. Are all these values to be made permanent? Some of them? I expect the I-D to say. [JLS] use the TBD placeholders is normal usage with the values being assigned by IANA and replaced in the document. It would be possible to refer to the early assignments, but I personally feel that this is a decision for IANA to make. There may be reasons when the final assignment is done that different values need to be used. (For example, incorrect usage of existing values in the wild or collisions found during the assignment process.) I have always made the assumption that the instructio= n for the RFC Editor to replace them is implicit and does not need to be explicit. I can make that change although I doubt it makes any difference. I disagree with you here. Yes, the final allocation is for IANA to m= ake but you should ask for what you want to guide them. Early Allocation c= an mean implemented in ASICs and deployed in hundreds of thousands of boxes= in which case the cost of change is substantial compared to say a change o= f one constant in one line in Linux. You know, IANA do not; tell them! The I-D adds the value 'filter only' to one of the columns. The registry was set up by RFC8152 which lists permitted values of which this is not one= . This then constitutes an update to RFC8152 which the I-D does not mention. [JLS] I would disagree that this requires an update of RFC 8152 for two reasons. First this is not a change in the COSE protocol in any manner and thus would violate what I consider to be the letter of the law for updates. Second, when this change is made RFC 8152 will have been obsoleted by a new RFC and thus it does not really make sense to update it. This is an IANA instruction not a protocol change. I agree that the protocol does not change but the rules set out by RFC= 8152 for the IANA Registry do change and that IMHO is an update to RFC8152,= one that rfc8152bis-algs does not include,=20 The registry has five columns; this I-D adds a new one, Capabilities, another update to RFC8152. What then happens to this column for existing entries in the registry? The I-D is silent. [JLS] This is done by a different document. yes, I can see that now RFC8152 is Standards Track; this I-D which IMHO updates it is Informational= . [JLS] Given that it is updating the IANA sections and not the protocol I would not consider that to be an issue. I do :-) The IANA registry entry gives a reference of 'RFC8152'; this I-D, which changes the specification of the registry, needs adding to that reference. [JLS] This make sense and I will do it. RFC8126 recommends that IANA Considerations be for IANA, that IANA does not have to search the rest of the document for the data it needs. Here, the relevant data appears in three other sections as well (and there is much in the I-D that is not relevant to IANA, it is not one of those I-D that is only about IANA). [JLS] I do not consider that pointing to a table in the document to fall under the rubric of making IANA search for data. It is a direct pointer to the information that is required. Having the same table appear multiple times in a document is a recipe for making mistakes in terms of what the data is. There is already the problem of trying to harmonize text and the table with out adding another version of the table. Abstract should be plain text - [I-D.ietf-cose-rfc8152bis-struct] does not look like plain text. [JLS] This is not plain text and will be repaired by the RFC editor. Using the reference structure makes it clearer that this is something that the RF= C editor is going to be required to update. This is not something I do for documents which are already RFCs. An alternative that I see other Authors use is to specify RFC YYYY wit= h an RFC Editor note to replace YYYY when the I-D referenced becomes an RFC= - just a thought. Tom Petch I have great faith in the a --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ bility of IANA to make sense of what they are asked to do but do think that the more straightforward that is the better. And then there are those that come after, who want the RFC to say what happened and why without digging into the e-mail archives (as I see happening now and again:-) [JLS] The other problem that you have not highlighted is the question of when a bis document is created should the IANA instructions be propagated forward into the new document despite the fact that IANA is not going to do anything. That is what is going to happen with some of these registries. It makes life even harder if duplicate or extraneous items are included. Jim Tom Petch > ----- Original Message ----- > From: "IETF-Announce on behalf of The IESG" > > To: > Cc: ; ;=20 > ; > Sent: Tuesday, May 12, 2020 4:26 PM > >> The IESG has received a request from the CBOR Object Signing and > Encryption >> WG (cose) to consider the following document: - 'CBOR Object Signing > and >> Encryption (COSE): Hash Algorithms' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the=20 >> last-call@ietf.org mailing lists by 2020-05-26. Exceptionally, > comments may >> be sent to iesg@ietf.org instead. In either case, please retain the > beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The CBOR Object Signing and Encryption (COSE) syntax >> [I-D.ietf-cose-rfc8152bis-struct] does not define any direct > methods >> for using hash algorithms. There are however circumstances where >> hash algorithms are used: Indirect signatures where the hash of one >> or more contents are signed. X.509 certificate or other object >> identification by the use of a fingerprint. This document=20 >> defines > a >> set of hash algorithms that are identified by COSE Algorithm >> Identifiers. >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> =3D _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Fri May 22 02:25:46 2020 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 74BC03A08FC; Fri, 22 May 2020 02:25:44 -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, MSGID_FROM_MTA_HEADER=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=btconnect.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 wMKkPIaTpIw5; Fri, 22 May 2020 02:25:42 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30121.outbound.protection.outlook.com [40.107.3.121]) (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 02C503A08AF; Fri, 22 May 2020 02:25:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aL64EB7brhC5LMC1G4JaV4MPH/v+18vr1mpaMzR42FdTgz/8GynHoEgrUSL9s4RQ2tOaHxS3jf25el/jEHQeas/ouwhS2ckM0+okvTHbi5pg9EyG3J2aR3oWiD3BVQZOTSt5MvQjlHCaybyy2yTeFZsmyxRdmjAu/3myNvrUyGehVpBth6psxNSNzQyr0yXIged7/0EyZX0f/BE2BjICAfZUQ9EriQyxDWU2hFv1O6u4IvC9tEjzbfyQKax3PGYilKBlXNA3xslmE4UG0kPSR9blAwCXTIBSLu7mjm00X8AEMy9rbmp3MY5XUpkE3uRrJLR+YkQdGPpHcTF7d/znPA== 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=ZSkkI7GOuaoC530KDmBnxzKcB3DwRckzQhifFauwNv8=; b=OzeygE5lp5qb08NbTo2lzdU7B3AequWyZxc+3p759O3lFcQ3WwAIg8s86EOr2AhE80aSRorsxHAJx3JtN+fU1GleTbbykaISQHnbvpPo3MvqxQscNCMU8Wc0Mc5/Z3+DV+vbhsBd1gZiQS8+KEJq0m2BTzefWpoHA8svO+ZtzejJG/EBKn/Qy+4C3bg9pGX2P2LZ2N93uVxgwp3YNT8uMmHTqaUIyPlwHXf+RxzTlGKabb2jB7AB8cGg3bDnHt7VYBxc5OftCyBiBxokEDpGJBzuFlNiX29QIBg7vzYL41YtktzXBVcAAKGhc8KprwajVvGnWlhePW6V81SxspuF+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZSkkI7GOuaoC530KDmBnxzKcB3DwRckzQhifFauwNv8=; b=LbBo5df4OLgzMDTxIAfBlv7NhrAUqiJUNCSAfsRcrq3PqjOXI9LKs/GICUN/xz0AJMyULk2ldj2ZJrKQbgrX/QCtbif4ltfJWXvLE4d+TLA1S6jhtZvVjnhYrUiQal0T9Ul0AUHOr7brjQEzCtQTzVFLTqQoDFkqDoWkFDgAu0o= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB6976.eurprd07.prod.outlook.com (2603:10a6:800:17d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.8; Fri, 22 May 2020 09:25:39 +0000 Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3021.019; Fri, 22 May 2020 09:25:39 +0000 To: Last Call Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, barryleiba@gmail.com, cose@ietf.org From: tom petch Message-ID: <5EC79A8E.50508@btconnect.com> Date: Fri, 22 May 2020 10:25:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0175.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::19) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (81.131.229.108) by LO2P265CA0175.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3021.27 via Frontend Transport; Fri, 22 May 2020 09:25:38 +0000 X-Originating-IP: [81.131.229.108] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 328e28ff-1d90-4ccc-fd86-08d7fe32171c X-MS-TrafficTypeDiagnostic: VI1PR0701MB6976: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 04111BAC64 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 182w6LsNiG8TB2t3ONCj4ekY3ze2PvD68PsNlHv0pqjz1VrWTk4jVEeyB5rx8Kj2qWoDztYTc2T9X/dQhfOgQQeglU1+X2GUswSYaPBn+RuzfR3brNwoLfsnZaLgmwIBo+hsVEBUfqCus5EQmTFLYn1jJ8FKg5ZqlBVjXb6JgKiFdJh8+AFzO7d0sDwKhfj8ooHxbHBlxvlweBzqKw+3DJ4eTetkhR/QOL7I+/y06fasRJa+oPXko1BCx/bIZdpPQOKFhO8fyMdFsQdVJVPwnhWISoI5dJg+G1tI30UpaPjKJ6a41F8ly5p4LELBUv1K4qtdAeF7oyDbopEoH33MQuB3YmJiQi14E+Y+MOIDlHi3QfZE6bRqM1OSZOJ7f8iZW0RSEWHsViK40eM4YTZbhldt9SHnVlJqgyu21kWWI9hHmxXA6V5TxXA/m2gSadP+8rjyixLjPudiYITgBp5qag== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(376002)(346002)(136003)(366004)(39860400002)(956004)(2616005)(2906002)(8936002)(8676002)(66476007)(6486002)(66556008)(4326008)(66946007)(33656002)(6916009)(16526019)(52116002)(478600001)(966005)(16576012)(316002)(6666004)(26005)(86362001)(36756003)(186003)(66574014)(5660300002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: mf1pdccs3zVtd19Qwod1Ge1D6mf2whr1U88TJGBuBXPFV2SaowPvEwYjq5QCxbzarBqtsbDXDLjgBUhsy5amrTXt0/3/rj8yhnEAd0yRZpzDX+m8r1KB1XstqtvmHKtjtWdXsI+PGPZYlZd8poT6l/SQooRrQEgvSJ+r4+9p1w9i9mdmRk5x19UBl+w2wN9AN22r6Z1BBKYhcAmmQNuCNBy9YTiRjCmouuSDJS6qFpLXsLcBXNZMBqEaeMgw37AnPIPhyEPdNsgA9itmCueQyIY5zjewgGZfhjvyJy2TYFbp8Zccbno0fi38NAdicHtxQ9LsdaQcQi4sZwEgUE0uIrn/2Rs9MAw55zy2KMlM0UNTWkQNkLeCC7Cl61M2pJP05u2ENJK44bAnshgEbG9DJ1hF16QnWcmYIa1/EcMIoMQGHRpI6kddK4EP0no1Y2tZZcTopcipQOyqRfmy9GQ32sH9Dw9MVt5ipHicxaZIAuw= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 328e28ff-1d90-4ccc-fd86-08d7fe32171c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2020 09:25:39.4856 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JDavXb0Pq7yY+fRkb16KzzlFms7UxzR0disvr7U9GdVhlN5W/UEFMNSgOHhV9/TTdso/Grtp91PXT5Gk+GD/qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB6976 Archived-At: Subject: Re: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Initial Algorithms) to Informational RFC 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, 22 May 2020 09:25:45 -0000 This I-D obsoletes RFC8152, which set up the IANA Registry 'COSE Algorithms', and adds a new column to the registry but otherwise contains no details thereof so that, in future, a user will need to study the obsoleted RFC8152 and this I-D to understand the specification of the registry. In fact, it is more complicated than that since RFC8152 defines the permitted values in a column while the Informational I-D draft-ietf-cose-hash-algs, currently in IETF Last Call, introduces a new permitted value 'Filter Only '; to me, this is an update to RFC8152 (the author disagrees), obsolete or not. A future user wanting to understand the registry will need to look at - the obsoleted RFC8152 - this obsoleting I-D - the informational draft-ietf-cose-hash-algs Could be simpler for a future user. Tom Petch > ----- Original Message ----- > From: > To: > Cc: ; ; > ; > Sent: Friday, May 15, 2020 2:35 PM > >> The IESG has received a request from the CBOR Object Signing and > Encryption >> WG (cose) to consider the following document: - 'CBOR Object Signing > and >> Encryption (COSE): Initial Algorithms' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2020-05-29. Exceptionally, > comments may >> be sent to iesg@ietf.org instead. In either case, please retain the > beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> Concise Binary Object Representation (CBOR) is a data format > designed >> for small code size and small message size. There is a need for > the >> ability to have basic security services defined for this data > format. >> This document defines the CBOR Object Signing and Encryption (COSE) >> protocol. This specification describes how to create and process >> signatures, message authentication codes, and encryption using CBOR >> for serialization. COSE additionally describes how to represent >> cryptographic keys using CBOR. >> >> In this specification the conventions for the use of a number of >> cryptographic algorithms with COSE. The details of the structure > of >> COSE are defined in [I-D.ietf-cose-rfc8152bis-struct]. >> >> This document along with [I-D.ietf-cose-rfc8152bis-struct] > obsoletes >> RFC8152. >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ >> >> No IPR declarations have been submitted directly on this I-D. >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> . From nobody Fri May 22 13:36:51 2020 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 BEF313A0ABB; Fri, 22 May 2020 13:36:48 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEgyiAale1lP; Fri, 22 May 2020 13:36:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA4E3A0AB9; Fri, 22 May 2020 13:36:45 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 May 2020 13:36:19 -0700 From: Jim Schaad To: CC: Date: Fri, 22 May 2020 13:36:19 -0700 Message-ID: <025c01d63078$a7c20f10$f7462d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdYweHg9Lr3cbwZ5TSyCFlF5v88oiw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] Should the IANA description of the curve be modified 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, 22 May 2020 20:36:49 -0000 This is just a thought and it does not need to be acted on. Given the text of Section 3.3, should the description for secp256k1 in the COSE elliptic curve registry be modified to indicate that it is only to be used for ECDSA? Jim From nobody Fri May 22 13:48:18 2020 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 B9E903A0B27 for ; Fri, 22 May 2020 13:47:57 -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 VGOWyfl8Xhc1 for ; Fri, 22 May 2020 13:47:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8B53A0C26 for ; Fri, 22 May 2020 13:47:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 May 2020 13:47:22 -0700 From: Jim Schaad To: References: <159018027284.12059.11716121540132104383@ietfa.amsl.com> In-Reply-To: <159018027284.12059.11716121540132104383@ietfa.amsl.com> Date: Fri, 22 May 2020 13:47:21 -0700 Message-ID: <025d01d6307a$329b24e0$97d16ea0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIBawLsJcIH+gCE4cyrUDAow6ms0aheHfNg X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-schaad-cose-more-algs-01.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: Fri, 22 May 2020 20:47:59 -0000 This draft expired so I republished with my most current version. This version adds KMAC as a MAC algorithm and as a KDF algorithm. = Adding it as KDF algorithm implies that we increase the number of ECDH = algorithm identifiers to add KMAC as a KDF. Please let me know if some other algorithms need to be added. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Friday, May 22, 2020 1:45 PM To: Jim Schaad Subject: New Version Notification for draft-schaad-cose-more-algs-01.txt A new version of I-D, draft-schaad-cose-more-algs-01.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-schaad-cose-more-algs Revision: 01 Title: CBOR Object Signing and Encryption (COSE): Additional Algorithms Document date: 2020-05-22 Group: Individual Submission Pages: 13 URL: = https://www.ietf.org/internet-drafts/draft-schaad-cose-more-algs-01.txt Status: = https://datatracker.ietf.org/doc/draft-schaad-cose-more-algs/ Htmlized: = https://tools.ietf.org/html/draft-schaad-cose-more-algs-01 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-cose-more-algs Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-more-algs-01 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] allows for adding additional algorithms to the registries. This document adds one additional key wrap algorithm to the registry using the AES Wrap with Padding Algorithm [RFC5649]. This document adds Keccak Message Authentication Code (KMAC) algorithms as well as using KMAC as a Key Derivation Function (KDF). = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Fri May 22 19:23:08 2020 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 850643A0EC9; Fri, 22 May 2020 19:23:04 -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 zMsDaFEnEoEf; Fri, 22 May 2020 19:23:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A473A0DEA; Fri, 22 May 2020 19:23:00 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 May 2020 19:22:54 -0700 From: Jim Schaad To: , 'IETF-Announce' CC: 'Ivaylo Petrov' , , , , References: <158937361695.30811.14534799425984840549@ietfa.amsl.com> In-Reply-To: <158937361695.30811.14534799425984840549@ietfa.amsl.com> Date: Fri, 22 May 2020 19:22:54 -0700 Message-ID: <027401d630a9$12fa2d00$38ee8700$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHGsE9uJCC405T99FjDqvVj21ZBSqjT7zIA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard 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, 23 May 2020 02:23:05 -0000 I will raise the same issue that I did during the working group (https://mailarchive.ietf.org/arch/msg/cose/6SpNYAD0YC0fTM0dOA7MZ3fnqqo/ is the first time). The messages sent over to CFRG did not receive a positive response for the IETF recommending it (https://mailarchive.ietf.org/arch/msg/cfrg/iuRak1_HFZ33oWDWPl7KbvZHC0k/ among others). I believe that the IESG needs to debate if this document should be the one which makes the secp256k1 curve a recommended IETF curve to use. Jim -----Original Message----- From: COSE On Behalf Of The IESG Sent: Wednesday, May 13, 2020 5:40 AM To: IETF-Announce Cc: Ivaylo Petrov ; cose-chairs@ietf.org; superuser@gmail.com; draft-ietf-cose-webauthn-algorithms@ietf.org; cose@ietf.org Subject: [COSE] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard The IESG has received a request from the CBOR Object Signing and Encryption WG (cose) to consider the following document: - 'COSE and JOSE Registrations for WebAuthn Algorithms' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6194: Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms (Informational - IETF stream) _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Sat May 23 13:29:42 2020 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 68D8C3A0E9B; Sat, 23 May 2020 13:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=akamai.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 kkbeER2rQIZJ; Sat, 23 May 2020 13:29:38 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 18F8A3A0E98; Sat, 23 May 2020 13:29:37 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 04NKRf94023675; Sat, 23 May 2020 21:29:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=egQEgGthO0JO0P7gMr0E6QMpuVBEXWiNdNW9zKf4CuI=; b=CT4qZXRV4t2uqE7+qql2ia+OV+B6zL9Gq2ZlkqXFOURmF1WTTn6F9ixgDkcGZO6kvElt YgJmPNsYFl30/7TKixmpzmHlfA5/6brg4n01HenRNAUd1lv3WVgasGPsqKpKasC0jU9p A8NEWKW6wYCDYyDv1Db0OI3A9pMYr6CYKWL30QftU+BPEKrxDBbf/YbAhd1JW6w7OVnI c3WTbcZxDn/fSuttIgk6YIuszvaU/fZXPe2Km8yu2aFyLV62QN0VHfa5F04lMutu/qaW QkngyLbRDoxSGpASIRnza7Z1CJhsVDftuon7rAsPo0+v7c35wwfNJU7gdTNYRGphjRWt Ig== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 316uc5sj4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 May 2020 21:29:31 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 04NKHBhj004843; Sat, 23 May 2020 16:29:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint7.akamai.com with ESMTP id 31769hgt2a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 23 May 2020 16:29:30 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 23 May 2020 15:29:29 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Sat, 23 May 2020 15:29:29 -0500 From: "Salz, Rich" To: Jim Schaad , "last-call@ietf.org" CC: "cose@ietf.org" Thread-Topic: [Last-Call] [COSE] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard Thread-Index: AQHWKSO8GkLpAcgy2ECtMYl4VbAJrai1U6sAgADshwA= Date: Sat, 23 May 2020 20:29:29 +0000 Message-ID: References: <158937361695.30811.14534799425984840549@ietfa.amsl.com> <027401d630a9$12fa2d00$38ee8700$@augustcellars.com> In-Reply-To: <027401d630a9$12fa2d00$38ee8700$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.133] Content-Type: text/plain; charset="utf-8" Content-ID: <199B2584F784F94A890A076C82D84C16@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-23_12:2020-05-22, 2020-05-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=709 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2005230171 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-23_12:2020-05-22, 2020-05-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0 adultscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=696 suspectscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 phishscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005230172 Archived-At: Subject: Re: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard 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, 23 May 2020 20:29:40 -0000 PiAgICBJIGJlbGlldmUgdGhhdCB0aGUgSUVTRyBuZWVkcyB0byBkZWJhdGUgaWYgdGhpcyBkb2N1 bWVudCBzaG91bGQgYmUgdGhlIG9uZQ0KICAgIHdoaWNoIG1ha2VzIHRoZSBzZWNwMjU2azEgY3Vy dmUgYSByZWNvbW1lbmRlZCBJRVRGIGN1cnZlIHRvIHVzZS4NCg0KQSBnb29kIHBvaW50LCBhbGJl aXQgc2xpZ2h0bHkgc3VidGxlLiAgKzEuDQoNCg0KDQo= From nobody Sat May 23 14:36:43 2020 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 6EAD33A0D9E for ; Sat, 23 May 2020 14:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 h0xpF3cP0tz8 for ; Sat, 23 May 2020 14:36:39 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 05A6D3A0B65 for ; Sat, 23 May 2020 14:36:39 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id q2so16741061ljm.10 for ; Sat, 23 May 2020 14:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ewCaXmCJGmtUpUjo0YBBNrsWDTeVYKqguxMavqqaNR0=; b=cyCEtw8PDzrrjC7XcNoe38nWALPVcT3Dusq3p8r3+VUpaY/jo50vADkol9cQo9Z40p U36IMucPGgUVhWtp0VL6P0S/4pcEU84rx3Pam074gww4Ihc7rFsxJiN4m7yfQbqh5wKx hKKXVI8eAzPyTcQzu2UJX1x33+G3hG8t98IZbhVJhFNuwZ/3Y1UeuEPZ29zJB8N502lZ TeGY7ScG8X60xNXNhlZdSPwNr77KWvzDPqRCJ/esJdqHI+It0Ams7vOQhUpIINM0MXxt XdckXTEU4bqvLtRd1zde7aKIwi0ngztUCGKRokBLLOVRsityLAA2heBw7qXjntNAhP6y TzYA== 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=ewCaXmCJGmtUpUjo0YBBNrsWDTeVYKqguxMavqqaNR0=; b=tENLKGNY0DUW3ClVGmbxVf8XsS4mRaOGIuVjsyTWZKejE/ot/oacqC0QsYybOr5OhN /cCdRp4gCOWwmS5AzFKS1tMlw9+lqlLh5ayxtGaFJtHp7V5AY03527ute0W6vucFn9SG v5HNFMhaeIGjmXOVvMuQghGY910fvtA1QhixBGar8boD15etha2yJ3Z8ZjAYrsZLFNl3 172XF8nt2KT4tzNgx3CyLZUvMXlJ+35Dbt5cZAbrQirvPlowKrJrL2/xdbip560vjRyH uFCsuj+b+hU44Ac+mLPEO4rYlSqXPPAcXBqobeskywUvM0yaq0zNxB0PSi5VVa9lhPWt byWQ== X-Gm-Message-State: AOAM531kF4a/qR5EOWF4ue0efbm3X8HNX07NvEdjT6yOZpqwm1H5AJIU CJ1MmsWRypup1YesVwql3ASpY+rjfyXkapUM6dIZ8JF2pac= X-Google-Smtp-Source: ABdhPJzOnRvsvvTZ4lwp4WyDXAxw31exV306PHSCR6DxcFPhhsp9Q66clzUsUgzpOBmnKWq4Zy4buJ/0peUJcZ1hx+s= X-Received: by 2002:a2e:8053:: with SMTP id p19mr10574913ljg.199.1590269797257; Sat, 23 May 2020 14:36:37 -0700 (PDT) MIME-Version: 1.0 References: <158937361695.30811.14534799425984840549@ietfa.amsl.com> <027401d630a9$12fa2d00$38ee8700$@augustcellars.com> In-Reply-To: From: Eric Rescorla Date: Sat, 23 May 2020 14:36:01 -0700 Message-ID: To: "Salz, Rich" Cc: Jim Schaad , "last-call@ietf.org" , "cose@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ce6e405a6578a58" Archived-At: Subject: Re: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard 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, 23 May 2020 21:36:42 -0000 --0000000000005ce6e405a6578a58 Content-Type: text/plain; charset="UTF-8" Good catch. We definitely should not be recommending sep256k1. -Ekr On Sat, May 23, 2020 at 1:30 PM Salz, Rich wrote: > > I believe that the IESG needs to debate if this document should be > the one > which makes the secp256k1 curve a recommended IETF curve to use. > > A good point, albeit slightly subtle. +1. > > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > --0000000000005ce6e405a6578a58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catch. We definitely should not be recommending = sep256k1.

-Ekr


On Sat, May 23,= 2020 at 1:30 PM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 I believe that the= IESG needs to debate if this document should be the one
=C2=A0 =C2=A0 which makes the secp256k1 curve a recommended IETF curve to u= se.

A good point, albeit slightly subtle.=C2=A0 +1.



--
last-call mailing list
last-call@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/last-call
--0000000000005ce6e405a6578a58-- From nobody Sat May 23 16:48:56 2020 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 DCA7E3A0F6D; Sat, 23 May 2020 16:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=microsoft.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 L3nqNBOs9IDm; Sat, 23 May 2020 16:48:48 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650118.outbound.protection.outlook.com [40.107.65.118]) (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 30C243A0F6B; Sat, 23 May 2020 16:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bf911gFXuAj0M1AuMgTOS2OMFdcye/sR1TmNiPCyx/ZKCTK7zubUDw4iaRZQCvYKo61u1FL19rlUnc/PAQYIWjF160GPbVrc4YJiQNDeElXQE0HN6Ss55nI3hXK8OZL9FHQErdWvwqBn3UqRePi65tAM/PUOO8isQ/wiD11g6DjWOMZU0P51bqtDOoGXoUOuM1lyd9/lzGDPJ3ottYNqdlWhy61mI+sdr72OWNR+Adl8b6y+XTVkA4ogl1estUm3X7QpZYYOlGZScEt/Wbt++5tg0gt3fWznPSKYyUqOnJd2UMHYaJYycW7Xxs9HN/4tJI/QJ/TQCkcgmTHU4GxmEQ== 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=gsP45rJ9MmMuGtPfW4W5s9zVuCgGOsCdJ6IaQubk7+I=; b=HBPo4wRZMJOgtr8WwTV0bPat6azSVS60d8eoMWX3Ql5PpI2JAoqal7R24Vm/nRRFr9pkaAi05/g9Kbf16RtWXGu1DxCJ+E9chf+97hdCAYMYmyS0ZhdVvMa5WoD8pJ6pFzq6PD/fMJLj/cA0NIDc9j/RmylW63Ss26YGYhWTMJdJNbOVA6bYa9/gieFNNI+E72D6OwiBKfoVWbcViW3EPR1V6pJLHn92mNXQor5RTKz45aYYVkrOXPOF7qXeHQgTjFcsIWKl3XkF9HAtawOkUlJlC4xFdJE3sixH/sQk8f4XimafoUBMkxthT/ahHB0EoJJX3sFNnXRVAWVEDIPD4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gsP45rJ9MmMuGtPfW4W5s9zVuCgGOsCdJ6IaQubk7+I=; b=DGn+H1QJOZ2iNMYiDV0R24skGuCd4GjYgNpvu5UaB5Q9WiAktB6SoG+C8aCd7luoHSAbxrCwbD9ZjmixEVJHbz33TUc4jnc25cIZHCokov3oleKfZDw/U93m55LtOd8IDUGRspR2k7UneSixe+FPD2Z5P3sCCdiHAkWDxUcw/lA= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM5PR00MB0389.namprd00.prod.outlook.com (2603:10b6:4:a0::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3074.0; Sat, 23 May 2020 23:48:42 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::9101:55b5:7415:d38d]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::9101:55b5:7415:d38d%4]) with mapi id 15.20.3072.000; Sat, 23 May 2020 23:48:41 +0000 From: Mike Jones To: Eric Rescorla , "rsalz@akamai.com" CC: "last-call@ietf.org" , Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard Thread-Index: AdYxXK5oD21D1OE4Q7aiB+KOED7Tnw== Date: Sat, 23 May 2020 23:48:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6f8afca1-ed22-409e-a0ab-0000cf3991d6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-23T23:38:37Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6a73144f-218d-445f-badc-08d7ff73d2d6 x-ms-traffictypediagnostic: DM5PR00MB0389: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0412A98A59 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X3O6rpjW0Cn92PoYsYszH/05Ue7Pq+tDM2M4UcBjGG9ZxIpnzEPZd0gpaHIXvuHfG9ApHwQPqdtLT5PHgTw8cw7QAnOkMWFv/5vinepFp4kw+ou24174fdmjVUISoHOCivrs9XBRdMTb/fIuDqvy2z/evlQ+nVV+GaFwXvJjAYpkZNqp2UUP4qddS6v/2vHWrx5uIq3PEbXUMLcsLp6+JAEeK4vTa6GxZjK6bX3zXG6lzv9HoduIwvs2Ds725LVpSJfb8CznbVVK2HewW63TzNOENSqRyCTRYOyjFZzTOE/9LGc800HI7poU6ClLcrBoL3GwSkW/g64IstVYx+r/kPV2VFgq3g+ehtP2rNhqX8fVNQi4yEaDo0Kd8VMzkoU9KrvwswktOP6mJfMuF13AWw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(7696005)(2906002)(10290500003)(316002)(9686003)(53546011)(8990500004)(5660300002)(6506007)(86362001)(478600001)(966005)(186003)(26005)(52536014)(110136005)(55016002)(66476007)(64756008)(66556008)(166002)(4326008)(8936002)(66446008)(82950400001)(82960400001)(66946007)(54906003)(71200400001)(8676002)(33656002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: gssDQ3/AVs7YEKyGIUPd+Huo9f1uFS0xIgUjP3jbRAeB966qzfUnVG9xRfjIiuGIPuNBpV7Urfh6Y+5Kv3Ort/fOSlWohAT2f4WDplxhVWgqCPAgvA02eGVrqx4P6/qcQGQmA8u5cuTNN7qD3VxGlwGkELoqy63dw02J5w3nh9PxCUNWZItogJcLhJqPz/WIcy47C+tMa/yX5uEZGnBjOvGJXNVy4Fb3/HG4TOockZLUa+yZU/1ltyyQbhsO0XMGXeGahfSeCfGt+NDEJsu2yvv8z/mnJIGrN/bMhfp37fVC4F83MZ9/8nwmjfs5V7Uj35HPIUC47QFxbw4i/5OubPbVgGctF479qSKjyP67kGV8Q79mU8kuCirMIwkscXLF5YXExjEquCATqs47qwtBdVCKAT6isGhRUPpXPV88V0IbjlE9sEX+gieKp0ECRL5A5Z6MaFt3ZqFt/2yyJ+sw/forOzwyrBxmD/WHOH4eyFw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB068462959AADE20D1CE2BDE4F5B50DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a73144f-218d-445f-badc-08d7ff73d2d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2020 23:48:41.8470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TD+O3K3XKzQFrY5kxZtG9pm9M6KXDr9otsyiL7Qs8Wn9q+ytb5DpXgnQszVDqc7NXGyOBUN8xlnWWgZE0Un9Xg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0389 Archived-At: Subject: Re: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard 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, 23 May 2020 23:48:52 -0000 --_000_DM6PR00MB068462959AADE20D1CE2BDE4F5B50DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjYW4gY2VydGFpbmx5IGNoYW5nZSB0aGUgQ09TRSByZWNvbW1lbmRhdGlvbiBzdGF0dXMgZnJv bSBZZXMgdG8gTm8sIGlmIHRoYXTigJlzIHRoZSBwcmV2YWlsaW5nIG9waW5pb24uICBUaG9zZSB0 aGF0IGhhdmUgZGVjaWRlZCB0byB1c2Ugc2VjcDI1NmsxIG92ZXIgdGhlIE5JU1QgYW5kIDI1NTE5 IGN1cnZlcyB3aWxsIGxpa2VseSBjb250aW51ZSB0byBkbyBzbyBubyBtYXR0ZXIgd2hhdCB3ZSBk ZWNpZGUgaW4gdGhpcyByZWdhcmQuDQoNCknigJlsbCB3YWl0IHVudGlsIHRoZSBsYXN0IGNhbGwg ZXhwaXJlcyBvbiBXZWRuZXNkYXkgdG8gc2VlIHdoYXQgb3RoZXIgY29tbWVudHMgbWF5IGNvbWUg aW4gYW5kIHRoZW4gcHVibGlzaCBhbiB1cGRhdGVkIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGFsbCwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IENPU0UgPGNvc2UtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEVyaWMg UmVzY29ybGENClNlbnQ6IFNhdHVyZGF5LCBNYXkgMjMsIDIwMjAgMjozNiBQTQ0KVG86IFNhbHos IFJpY2ggPHJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBsYXN0LWNhbGxA aWV0Zi5vcmc7IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBjb3NlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0NPU0VdIFtMYXN0LUNhbGxdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA1LnR4dD4gKENPU0UgYW5kIEpPU0UgUmVnaXN0 cmF0aW9ucyBmb3IgV2ViQXV0aG4gQWxnb3JpdGhtcykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0K R29vZCBjYXRjaC4gV2UgZGVmaW5pdGVseSBzaG91bGQgbm90IGJlIHJlY29tbWVuZGluZyBzZXAy NTZrMS4NCg0KLUVrcg0KDQoNCk9uIFNhdCwgTWF5IDIzLCAyMDIwIGF0IDE6MzAgUE0gU2Fseiwg UmljaCA8cnNhbHo9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGFrYW1haS5j b21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4gICAgSSBiZWxpZXZlIHRoYXQgdGhlIElFU0cg bmVlZHMgdG8gZGViYXRlIGlmIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIHRoZSBvbmUNCiAgICB3 aGljaCBtYWtlcyB0aGUgc2VjcDI1NmsxIGN1cnZlIGEgcmVjb21tZW5kZWQgSUVURiBjdXJ2ZSB0 byB1c2UuDQoNCkEgZ29vZCBwb2ludCwgYWxiZWl0IHNsaWdodGx5IHN1YnRsZS4gICsxLg0KDQoN Cg0KLS0NCmxhc3QtY2FsbCBtYWlsaW5nIGxpc3QNCmxhc3QtY2FsbEBpZXRmLm9yZzxtYWlsdG86 bGFzdC1jYWxsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sYXN0LWNhbGwNCg== --_000_DM6PR00MB068462959AADE20D1CE2BDE4F5B50DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGNhbiBjZXJ0YWlubHkgY2hhbmdlIHRoZSBD T1NFIHJlY29tbWVuZGF0aW9uIHN0YXR1cyBmcm9tIFllcyB0byBObywgaWYgdGhhdOKAmXMgdGhl IHByZXZhaWxpbmcgb3Bpbmlvbi4mbmJzcDsgVGhvc2UgdGhhdCBoYXZlIGRlY2lkZWQgdG8gdXNl IHNlY3AyNTZrMSBvdmVyIHRoZSBOSVNUIGFuZCAyNTUxOSBjdXJ2ZXMgd2lsbCBsaWtlbHkgY29u dGludWUgdG8gZG8gc28gbm8NCiBtYXR0ZXIgd2hhdCB3ZSBkZWNpZGUgaW4gdGhpcyByZWdhcmQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J4oCZbGwgd2FpdCB1bnRpbCB0 aGUgbGFzdCBjYWxsIGV4cGlyZXMgb24gV2VkbmVzZGF5IHRvIHNlZSB3aGF0IG90aGVyIGNvbW1l bnRzIG1heSBjb21lIGluIGFuZCB0aGVuIHB1Ymxpc2ggYW4gdXBkYXRlZCBkcmFmdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGFua3MgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQ09TRSAmbHQ7Y29zZS1ib3VuY2VzQGlldGYub3JnJmd0 OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgTWF5IDIzLCAyMDIwIDI6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IFNhbHosIFJpY2gg Jmx0O3JzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+ IGxhc3QtY2FsbEBpZXRmLm9yZzsgSmltIFNjaGFhZCAmbHQ7aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bSZndDs7IGNvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDT1NFXSBbTGFz dC1DYWxsXSBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3JpdGht cy0wNS50eHQmZ3Q7IChDT1NFIGFuZCBKT1NFIFJlZ2lzdHJhdGlvbnMgZm9yIFdlYkF1dGhuIEFs Z29yaXRobXMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIGNhdGNoLiBXZSBkZWZpbml0ZWx5IHNob3VsZCBub3Qg YmUgcmVjb21tZW5kaW5nIHNlcDI1NmsxLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBNYXkgMjMsIDIwMjAgYXQgMTozMCBQ TSBTYWx6LCBSaWNoICZsdDtyc2Fsej08YSBocmVmPSJtYWlsdG86NDBha2FtYWkuY29tQGRtYXJj LmlldGYub3JnIj40MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsmbmJzcDsgJm5ic3A7IEkgYmVsaWV2ZSB0aGF0IHRoZSBJRVNHIG5lZWRzIHRvIGRlYmF0ZSBp ZiB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSB0aGUgb25lPGJyPg0KJm5ic3A7ICZuYnNwOyB3aGlj aCBtYWtlcyB0aGUgc2VjcDI1NmsxIGN1cnZlIGEgcmVjb21tZW5kZWQgSUVURiBjdXJ2ZSB0byB1 c2UuPGJyPg0KPGJyPg0KQSBnb29kIHBvaW50LCBhbGJlaXQgc2xpZ2h0bHkgc3VidGxlLiZuYnNw OyAmIzQzOzEuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KbGFzdC1jYWxsIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpsYXN0LWNhbGxAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5sYXN0LWNhbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sYXN0LWNhbGwiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xhc3QtY2FsbDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB068462959AADE20D1CE2BDE4F5B50DM6PR00MB0684namp_-- From nobody Mon May 25 14:14:54 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6E3A0968; Mon, 25 May 2020 14:14:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Theresa Enghardt via Datatracker To: Cc: cose@ietf.org, draft-ietf-cose-rfc8152bis-struct.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159044129232.11103.11777847473965400673@ietfa.amsl.com> Reply-To: Theresa Enghardt Date: Mon, 25 May 2020 14:14:52 -0700 Archived-At: Subject: [COSE] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 21:14:53 -0000 Reviewer: Theresa Enghardt Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cose-rfc8152bis-struct-09 Reviewer: Theresa Enghardt Review Date: 2020-05-25 IETF LC End Date: 2020-05-29 IESG Telechat date: Not scheduled for a telechat Summary: This document describes data structures and processes in detail, with minor updates. In combination with a companion document on algorithms, it obsoletes RFC 8152. The document has some issues and editorial nits, which should be addressed prior to publication. Major issues: The intended RFC status is Internet Standard, while RFC 8152 is a Proposed Standard. While this document points to three different implementations, how widespread is their deployment? Were there other lessons learned from implementation and deployment experience? Has complexity been reduced by removing unused features, as RFC 6410 suggests? Minor issues: In the introduction, it would be great to add some more context on how COSE is intended to be used. Is this solely for adding security to objects within CoAP, e.g., by signing and encrypting messages exchanged as CoAP payload? Or can it be used with other protocols or in other contexts? In RFC 7165, which describes JOSE use cases, Section 5.8.2 mentions Object Security for CoAP. Is COSE addressing this use case? If so, please add a link to Section 5.8.2 of RFC 7165. Section 9.5.4 mentions that COSE "is designed for a store and forward environment rather than an online environment". Perhaps it's worth mentioning such design goals and context in the introduction already. When adding one or two paragraphs on how COSE is intended to be used to the introduction, it's also worth stating explicitly that each application is expected to select the COSE objects and processes that it needs, and that Section 11 provides more guidance on how to do this. This will make it easier for application developers to understand how to use COSE. "One feature that is present in CMS [RFC5652] that is not present in this standard is a digest structure. This omission is deliberate. It is better for the structure to be defined in each document as different protocols will want to include a different set of fields as part of the structure." Does "in each document" refer to documents for different encryption algorithms or protocols? Please clarify. Is draft-ietf-cose-rfc8152bis-algs an example of one of these documents, as it describes algorithms? Or is another type of documents meant here? When introducing the CDDL syntaxes: Is "* label => values" missing here? It appears to be used in some examples below. "The CDDL grammar is informational; the prose description is normative." Why? Isn't it important for interoperability that the objects are structured in a certain way and that there is no ambiguity? In Section 2: "[...] The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit. (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding." I'm not sure I understand this scenario. Does this statement just apply to zero-length maps or to all kinds of protected buckets? What does "to be transported with a greater chance" mean here? That intermediates are less likely to block traffic containing such a COSE object? That intermediates are less likely to accidentally (or deliberately) modify it in such a way that it gets accepted by the receiver? Is this an effect of some cryptographic protection, is it related to different encoding techniques being used in different implementations, or both? Why is it a problem if all parties need to be able to do a common canonical encoding? In fact, what kind of encoding does this refer to: Binary encoding vs. base64 encoding? Or specific ways of encoding certain information as binary data? In Section 4.1: "An example of header a parameter about the content is the content type. " This sentence appears to be broken. In Section 4 or 5, maybe it's worth adding a brief description or reference of what a countersignature is. In contrast to the concepts of signing, encryption, and Message Authentication Codes, I would not expect every application developer to be familiar with the concept of a countersignature and what it's needed for. In Section 10, the document presents restrictions on the CBOR encoder. "We have managed to narrow it down to the following restrictions" sounds like these might have been narrowed down from RFC 8152, and maybe could be rephrased to sound more neutral. Why are these restrictions necessary? Maybe it's worth adding a brief explanation for each restriction. In the Security Considerations: What threat models have been considered for COSE? Nits/editorial comments: Section 12: "The only known action at this time is to update the references." Right after this statement, the document describes another IANA action. So maybe updating the references is not "the only known action" anymore? For most IANA registries, this document simply asks to update the references from RFC 8152 to this document. However, for the Media Type Registrations, Section 12.5 appears to repeat the registry information. Does this document introduce any changes here? If not, why is the information repeated here, but not in the other sections? From nobody Tue May 26 14:23:15 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 634103A0834; Tue, 26 May 2020 14:23:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: cose@ietf.org, last-call@ietf.org, draft-ietf-cose-rfc8152bis-algs.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159052818935.17307.5095159295288146706@ietfa.amsl.com> Reply-To: Nancy Cam-Winget Date: Tue, 26 May 2020 14:23:09 -0700 Archived-At: Subject: [COSE] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 21:23:10 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document describes an initial set of cryptographic algorithms used to protect CBOR, I believe this document is almost ready, barring some editorial nits (I only made a few below). In general, the description of the "initial" set of algorithms used in COSE make sense and it is good to see each section carry their own security section for better mapping of the considerations based on the security algorithm applied. As a reader (like myself) who is not fully versant to the nuances of CBOR it was a little hard to follow as the structures and taxonomy is described in the companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think the document is close to ready, I only noted a few technical and editorial nits for the earlier sections below: Section 2.1: - What field does the ECDSA algorithm value map to? I presume it is the 'alg' field (if present)? But should be made explicit. - It seems that the "should" in the 4th paragraph is normative (e.g. SHOULD) as it is needed for interoperability, and perhaps even a MUST as I'm not seeing negotiation or selection of curve choice. So, if it is to be implicit, then a MUST would be more appropriate. Section 2.2: - The rationaleThere may be some corner case in which there may be a very large (2K?) structure to be protected. It would be better to quantify "extremely large" or perhaps another/additional rationale for the need to ONLY do Pure edDSA is the intent for constrained devices not have enough memory to compute the block updates. Section 4.1.1: - GCM's limitation for one encryption string is 2^39-256 e.g. not "a single key"....so sufficiently large for COSE! However, it does mean that the nonce MUST be unique for every encrypted message (e.g. the bullet before this one is correct). I think the limit for one key using GCM is based on the size of the nonce as it must be unique. Section 4.2: - 'k' is the key size in bits (I presume), would be good to describe that before the table. Editorial nits: Section 1.5 - The second sentence is hard to parse. Is it that the intermediate values used for debugging are represented in both a hex as well as a CBOR diagnostic notation format"? - Third sentence, is it that some examples were designed to fail (e.g. they are "failure test bases")? Section 2.2: - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may leave more room for questions; as there may be some corner case in which there may be a very large (2K?) structure to be protected. For those that are in the healthcare sector (of IoT), I could see potential for large blocks and may wonder what qualifies as "extremely large". RFC 8032 speaks to HashEdDSA as providing better collision resilience...so am inclined to suggest to either remove this rationale or be more complete in justification. Section 3.1 - 3rd paragraph: "Some recipient algorithms carry the key while others derive a key from secret data"....I think you mean "Some algorithms are used to transmit a key, e.g. key wrapping." "Carry the key", in this sentence leads me to imply it's the same key being used in the HMAC. From nobody Tue May 26 16:51:28 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D29F3A0BE2; Tue, 26 May 2020 16:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: cose@ietf.org, draft-ietf-cose-webauthn-algorithms.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159053708200.16306.10159573848968846851@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Tue, 26 May 2020 16:51:22 -0700 Archived-At: Subject: [COSE] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 23:51:22 -0000 Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is to list down the COSE&JOSE Algorithms to be registered to IANA. But it seems the description is not complete. In the Section 2: among the 4 algorithms listed under RSASSA-PKCS1-v1_5, three are NOT recommended, one is deprecated. Under the Security Consideration (Section 5), Section 5.2 describes why SHA-2 is "Not Recommended", Section 5.3 describes why SHA-1 is "Deprecated". What about the description on why SHA-512, SHA-384, and SHA-256 are not recommended? Is the missing description intended? Best Regards, Linda Dunbar From nobody Tue May 26 19:57:52 2020 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 5824D3A0D63; Tue, 26 May 2020 19:57:43 -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 U52HBRnkKoaH; Tue, 26 May 2020 19:57:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED923A0D62; Tue, 26 May 2020 19:57:41 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 May 2020 19:57:33 -0700 From: Jim Schaad To: 'Nancy Cam-Winget' , CC: , , References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> In-Reply-To: <159052818935.17307.5095159295288146706@ietfa.amsl.com> Date: Tue, 26 May 2020 19:57:31 -0700 Message-ID: <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFNVp5fEKHTIFH++NxvYlUu0haDFanM9nMQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 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, 27 May 2020 02:57:44 -0000 Nancy - one clarification please jim -----Original Message----- From: Nancy Cam-Winget via Datatracker =20 Sent: Tuesday, May 26, 2020 2:23 PM To: secdir@ietf.org Cc: cose@ietf.org; last-call@ietf.org; = draft-ietf-cose-rfc8152bis-algs.all@ietf.org Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget Review result: Has Nits IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget I have reviewed this document as part of the security = directorate's=C3=8A ongoing effort to review all IETF documents being = processed by the=C3=8A IESG.=C3=8A=C3=8AThese comments were written = primarily for the benefit of the=C3=8A security area = directors.=C3=8A=C3=8ADocument editors and WG chairs should treat=C3=8A = these comments just like any other last call comments. This document describes an initial set of cryptographic algorithms used = to protect CBOR, I believe this document is almost ready, barring some = editorial nits (I only made a few below). In general, the description = of the "initial" set of algorithms used in COSE make sense and it is good to see each = section carry their own security section for better mapping of the = considerations based on the security algorithm applied. As a reader = (like myself) who is not fully versant to the nuances of CBOR it was a = little hard to follow as the structures and taxonomy is described in the = companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think = the document is close to ready, I only noted a few technical and = editorial nits for the earlier sections below: Section 2.1: - What field does the ECDSA algorithm value map to? I presume it is the = 'alg' field (if present)? But should be made explicit. - It seems that the = "should" in the 4th paragraph is normative (e.g. SHOULD) as it is needed for = interoperability, and perhaps even a MUST as I'm not seeing negotiation = or selection of curve choice. So, if it is to be implicit, then a MUST = would be more appropriate. [JLS] I don't think I know which "should" you are talking about. The = word does not exist in that paragraph so I don't know for sure that I = have the same number. Section 2.2: - The rationaleThere may be some corner case in which there may be a = very large (2K?) structure to be protected. It would be better to quantify = "extremely large" or perhaps another/additional rationale for the need = to ONLY do Pure edDSA is the intent for constrained devices not have = enough memory to compute the block updates. Section 4.1.1: - GCM's limitation for one encryption string is 2^39-256 e.g. not "a = single key"....so sufficiently large for COSE! However, it does mean = that the nonce MUST be unique for every encrypted message (e.g. the = bullet before this one is correct). I think the limit for one key using = GCM is based on the size of the nonce as it must be unique. Section 4.2: - 'k' is the key size in bits (I presume), would be good to describe = that before the table. Editorial nits: Section 1.5 - The second sentence is hard to parse. Is it that the intermediate = values used for debugging are represented in both a hex as well as a = CBOR diagnostic notation format"? - Third sentence, is it that some = examples were designed to fail (e.g. they are "failure test bases")? Section 2.2: - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may = leave more room for questions; as there may be some corner case in which = there may be a very large (2K?) structure to be protected. For those = that are in the healthcare sector (of IoT), I could see potential for = large blocks and may wonder what qualifies as "extremely large". RFC = 8032 speaks to HashEdDSA as providing better collision resilience...so = am inclined to suggest to either remove this rationale or be more = complete in justification. Section 3.1 - 3rd paragraph: "Some recipient algorithms carry the key while others = derive a key from secret data"....I think you mean "Some algorithms are = used to transmit a key, e.g. key wrapping." "Carry the key", in this = sentence leads me to imply it's the same key being used in the HMAC. From nobody Wed May 27 14:55:07 2020 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 C6BB83A0CC9 for ; Wed, 27 May 2020 14:55:05 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 zvRHX36_pzLX for ; Wed, 27 May 2020 14:55:04 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 7876D3A0CC0 for ; Wed, 27 May 2020 14:55:04 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id o13so841079otl.5 for ; Wed, 27 May 2020 14:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q84Y/NGysmFIl1Zlaok4i5hAhEX+NSRZWUttoN3MNcE=; b=Y9qV0q+JMLs9cpm5LdBETtA0fNlXBOwhNSbIigRDejrENHDYgnRRfL/LU/cFNUX7G9 TN0MTfFkImbV829TSxjU21YcuF9i41i7dv6gx5htaY4Irq6Cst3H+OaBJ5bgI9IUqU4e RzT/Kgdgc8VvAMNDXNwb+j1Z3FatrxHiGstw5Czko2Wbww8AdGido+7QgKdmqEtD2U/4 hv1ll+VcqloTCsjOI0Z0dD6t9Iqpik5RaPLOqpyQwVY/YtVq4Id7iq5U2OOR+h9nze3q 1fHoBiuPacnhp9joLqqXgW8Ny+N6IeXSePfKOfye4t6pTy8IsAGNY2LuRDdKHzzWwSRM vt4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Q84Y/NGysmFIl1Zlaok4i5hAhEX+NSRZWUttoN3MNcE=; b=ZZjWuOCNF3ezWAXbH25rChW3GbYl3cWoro/iQKDADRU/TFcxCmmrQrZ0e99Y4rfQcZ Lem85IlDrf0azhjVyesn69UM8f7yLJnPvdcSQ3e0w88ODgH5HZY6b1cAPo5SKiw0/nEi RNm/lvwVIIruYaoD+KdQiJ1nSnzsu64uagYYHasCYca8RBhV0/zcFJbG3EsSL+VMOYgk /xRdm4FjYLdpQ39XkecXTkM0V4BRi2kbF2aIX4EY28d22Blsp+J5erfrmgFV2bVRtnrB txvdeBCCZhm5O5U7dXaoBmdP66iUuuE3Hyy5A+Xghi5G7Z4jmY64zjyyiYMs0yfsVxd2 HAuA== X-Gm-Message-State: AOAM533fkK4ivDdehhaG/b47lFoTtlG6/P33+A82kssSjnV06imZrh/Y XyE1GzytVK9jphbB0X5JwtNtMmKCJ9p5zw== X-Google-Smtp-Source: ABdhPJwTw1crsPgd/NCnys07B+FdZDWZ0uGepiWGSz0X+ylyBl4vsxHiudOwex8X+wNAb/vDCSY+2w== X-Received: by 2002:a05:6830:210e:: with SMTP id i14mr135014otc.284.1590616503697; Wed, 27 May 2020 14:55:03 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:3d29:5003:84a:2526]) by smtp.gmail.com with ESMTPSA id d15sm1104839otk.41.2020.05.27.14.55.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:55:02 -0700 (PDT) To: Linda Dunbar , secdir@ietf.org Cc: cose@ietf.org, draft-ietf-cose-webauthn-algorithms.all@ietf.org, last-call@ietf.org References: <159053708200.16306.10159573848968846851@ietfa.amsl.com> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: Date: Wed, 27 May 2020 15:55:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <159053708200.16306.10159573848968846851@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 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, 27 May 2020 21:55:06 -0000 Hello Linda, Thanks for the review. Speaking on the author's behalf, SHA-2 is defined as the collection of hash algorithms, including all of those cited (SHA-256, SHA-384, SHA-512). Do you believe it is critical to call this out explicitly? - m&m Matthew A. Miller On 20/05/26 17:51, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This document is to list down the COSE&JOSE Algorithms to be registered to > IANA. But it seems the description is not complete. In the Section 2: among the > 4 algorithms listed under RSASSA-PKCS1-v1_5, three are NOT recommended, one is > deprecated. Under the Security Consideration (Section 5), Section 5.2 describes > why SHA-2 is "Not Recommended", Section 5.3 describes why SHA-1 is > "Deprecated". What about the description on why SHA-512, SHA-384, and SHA-256 > are not recommended? Is the missing description intended? > > Best Regards, > > Linda Dunbar > > > From nobody Wed May 27 17:21:58 2020 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 EC5903A0D5F; Wed, 27 May 2020 17:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 U7tv_aDdduXQ; Wed, 27 May 2020 17:21:54 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2120.outbound.protection.outlook.com [40.107.223.120]) (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 CF80B3A0EB3; Wed, 27 May 2020 17:21:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TMBjRqMW3SlV3mP1F7HZkzFW/rCodRckr5TSH8W/S1pNu3tp/4gMWuYzFPlA+lFojDVQzcivm8686LKpmmhvioEN0nTXjstBxFb/+2aWs+oGZjMX8wIWv/qR0uzMIzAJaCK2miPrUdUh/pP6iQmqzeD0pLfEAIbVnE1cK4IY25CJe91pGLoCx0OyQfJqUdLjVn4yVeHqgk1FR9cxPabtLJScdzFvKBmko7tNFKHSbfrFo/ZfdC403bsRP8xNdQK2A1memGX08A3qvFpwswj+Fegj+FroAm6dhDOtPwJbwZylHvVupwwTEEdZDKfkkYUOhtCFaCKF1UL+/+Mmp6oZvw== 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=4Kgm+iutcMQWm1ddej9y9cdRSFLgi82L0Zh5g1pEs6Q=; b=VDE5gLlMatRdwPmDhKhEWbdO57Zwydtlz8T+tjZD37OvFRVOdcmoSAapedfdJN8GK9FBJSs1lgacDKz6d/o3dfLnqBkhtZxMId2RlyAXyHivdcxoXDbSHv+1kwhnDJiu9alF5qZRWGppBgI9XYnSq/rrWvl6J2Sx9HqV+4m3ECtkrP99oPrdjjdGnA7hh1HjyT4k3cSHBkAy0N7Q0XLzlZ/WDTkBliCMZaS5goSulMrEAOKvudCc30qkA5S5lbHPehCnE4x3B+7/L+Z2Z+d8zGG13HAJWzVxnv3CdxQZ4P1QYpT/A7WDh1MnlwW6gzEJgN8n1R6XPhDBB1A877HZ0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Kgm+iutcMQWm1ddej9y9cdRSFLgi82L0Zh5g1pEs6Q=; b=Bd5qr6KVnfmlTIbpV3OjpGhrLwuPD+zbWrbzr0l7AUi0zWwM1cPuT54laN4uewzMGYag07T5Ka2BY3jdAH64GRHzMQAqawGtowxCk9J0Bo8oxG9KjJ68NNVVJX/iOSt9UoL8HkST2MGZUOSgUVPUAh6A+Gye0/5H11aVJeO+WNg= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2527.namprd13.prod.outlook.com (2603:10b6:805:58::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.10; Thu, 28 May 2020 00:21:42 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970%5]) with mapi id 15.20.3045.013; Thu, 28 May 2020 00:21:42 +0000 From: Linda Dunbar To: "Matthew A. Miller" , "secdir@ietf.org" CC: "cose@ietf.org" , "draft-ietf-cose-webauthn-algorithms.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 Thread-Index: AQHWNHF88QTcU9SYR0Gbkbt6ssDowai8okaw Date: Thu, 28 May 2020 00:21:42 +0000 Message-ID: References: <159053708200.16306.10159573848968846851@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: outer-planes.net; dkim=none (message not signed) header.d=none;outer-planes.net; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cc248342-4212-46c0-b857-08d8029d1917 x-ms-traffictypediagnostic: SN6PR13MB2527: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0AZR5L95lR2JcN04Ngcnt1KYYIxakxAqy3cUiA68Bh4m4ZWCNA4q6CTGEM80W6c79x/sOfBMF3aeQzWP0q6UckYT9EcojVS6w4CtDy/8fv+jlVLAsZGHIDiaw9DZ8sHn4bByy5cxp+7Yp95nbPu2AVC7tDi1A8xPIArAjotErvA0jpUcTPGgGTrZ50tygB2s232bo6Gx082fTWXnXfT3x30reWgtdTgpMzqaivwBNJYgw3xqCZZGhFTNx5T7lOgHDh4kdE3wAcDMs2n+9F44HS1eHjyjT8RqjYR+8DDE9Cm4C2+rqsUfVo0a1YwZwnbIPNrcpXAg9ZasK18SpfDU3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39850400004)(396003)(136003)(346002)(376002)(76116006)(66946007)(55016002)(5660300002)(8936002)(4326008)(9686003)(7696005)(186003)(54906003)(478600001)(83380400001)(86362001)(110136005)(2906002)(8676002)(33656002)(66476007)(53546011)(52536014)(316002)(66446008)(71200400001)(66556008)(64756008)(44832011)(26005)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2sUqlZNxhBLTtVMUwZlyJsCfJdHqcUnOoGS6lsud/6gtKC/B7yBjLua+BwPwAt5bw/M6K8wIWKWwrGBoqXRaCu05BzYrswiK9rFtvE/DPSRj9L7G4swY5ld0qJSkSSkaJaBDF+tZCJ8KaCb+2+lQS+SyK/gbIkHEDZWjYQDzwQkkd32YbGEoOyG3FoIX5gkQzmvgv3PKaEoalycQs02xtV8DVp+mS2nIHJDuKxqhpVBzoW1b24ddgN7Jz6OuIaCnzaMlMGc4d2/YCNM9S1L3f7PRmqYNu4n5SxoivHZ7QSGztrWuKqc1wfo27W6xhQO3UzAJpPRN9/OO3B4fh6756IpV2HCTEtNMJp4N5x87B0sBJiGFLP0fGA2AZgCDEemzMsms213vUumfyxpLDEfbe7NASN1zR+Q5HPiz0iMfHROfPUTDBBKTBe+gSvV1ncEiyLkd0VKOKXTcVj+L8rOP5KovieFgqROzJBCbs9T/Sks= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc248342-4212-46c0-b857-08d8029d1917 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 00:21:42.5242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Sk5Ykf1R9QK+QK5wiXUzghGrAwUfnr9iZP+IMuCoqfzuS6okFzimxkIPjiiRvFhguXqiH+CIe1hFYIbP1HN6rg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2527 Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 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, 28 May 2020 00:21:56 -0000 TWF0dGhldywgDQoNClRoYXQgaXMgd2hhdCBJIHdhcyB0aGlua2luZy4gQ2FuIHlvdSBhZGQgYSBz ZW50ZW5jZSBpbiBTZWN0aW9uIDUuMiB0byBzYXkgdGhhdCB0aGlzIGlzIGZvciB0aGUgY29sbGVj dGlvbiBvZiBTSEEtMjU2LCBTSEEtMzg0LCBTSEEtNTEyIGFsZ29yaXRobXM/IA0KT3RoZXJ3aXNl LCB0aGUgdHdvIHNlY3Rpb25zIG9mIHRoZSBkb2N1bWVudCBkb24ndCAgbWF0Y2guIA0KDQpUaGFu ayB5b3UNCkxpbmRhIER1bmJhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWF0dGhldyBBLiBNaWxsZXIgPGxpbnV4d29sZitpZXRmQG91dGVyLXBsYW5lcy5uZXQ+IA0KU2Vu dDogV2VkbmVzZGF5LCBNYXkgMjcsIDIwMjAgNDo1NSBQTQ0KVG86IExpbmRhIER1bmJhciA8bGlu ZGEuZHVuYmFyQGZ1dHVyZXdlaS5jb20+OyBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBjb3NlQGlldGYu b3JnOyBkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3JpdGhtcy5hbGxAaWV0Zi5vcmc7IGxh c3QtY2FsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9m IGRyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA2DQoNCkhlbGxvIExpbmRhLA0K DQpUaGFua3MgZm9yIHRoZSByZXZpZXcuICBTcGVha2luZyBvbiB0aGUgYXV0aG9yJ3MgYmVoYWxm LCBTSEEtMiBpcyBkZWZpbmVkIGFzIHRoZSBjb2xsZWN0aW9uIG9mIGhhc2ggYWxnb3JpdGhtcywg aW5jbHVkaW5nIGFsbCBvZiB0aG9zZSBjaXRlZCAoU0hBLTI1NiwgU0hBLTM4NCwgU0hBLTUxMiku ICBEbyB5b3UgYmVsaWV2ZSBpdCBpcyBjcml0aWNhbCB0byBjYWxsIHRoaXMgb3V0IGV4cGxpY2l0 bHk/DQoNCg0KLSBtJm0NCg0KTWF0dGhldyBBLiBNaWxsZXINCk9uIDIwLzA1LzI2IDE3OjUxLCBM aW5kYSBEdW5iYXIgdmlhIERhdGF0cmFja2VyIHdyb3RlOg0KPiBSZXZpZXdlcjogTGluZGEgRHVu YmFyDQo+IFJldmlldyByZXN1bHQ6IE5vdCBSZWFkeQ0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyANCj4gb25n b2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQg YnkgdGhlIA0KPiBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiAgRG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgDQo+IGFueSBvdGhlciAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gVGhpcyBkb2N1 bWVudCBpcyB0byBsaXN0IGRvd24gdGhlIENPU0UmSk9TRSBBbGdvcml0aG1zIHRvIGJlIA0KPiBy ZWdpc3RlcmVkIHRvIElBTkEuIEJ1dCBpdCBzZWVtcyB0aGUgZGVzY3JpcHRpb24gaXMgbm90IGNv bXBsZXRlLiBJbiANCj4gdGhlIFNlY3Rpb24gMjogYW1vbmcgdGhlDQo+IDQgYWxnb3JpdGhtcyBs aXN0ZWQgdW5kZXIgUlNBU1NBLVBLQ1MxLXYxXzUsIHRocmVlIGFyZSBOT1QgDQo+IHJlY29tbWVu ZGVkLCBvbmUgaXMgZGVwcmVjYXRlZC4gVW5kZXIgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb24g DQo+IChTZWN0aW9uIDUpLCBTZWN0aW9uIDUuMiBkZXNjcmliZXMgd2h5IFNIQS0yIGlzICJOb3Qg UmVjb21tZW5kZWQiLCANCj4gU2VjdGlvbiA1LjMgZGVzY3JpYmVzIHdoeSBTSEEtMSBpcyAiRGVw cmVjYXRlZCIuICBXaGF0IGFib3V0IHRoZSANCj4gZGVzY3JpcHRpb24gb24gd2h5IFNIQS01MTIs ICBTSEEtMzg0LCBhbmQgU0hBLTI1NiBhcmUgbm90IHJlY29tbWVuZGVkPyAgSXMgdGhlIG1pc3Np bmcgZGVzY3JpcHRpb24gaW50ZW5kZWQ/DQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBMaW5k YSBEdW5iYXINCj4gDQo+IA0KPiANCg== From nobody Wed May 27 18:02:53 2020 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 735E23A0819; Wed, 27 May 2020 18:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=heVIqvxI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YY4HTU6A 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 EKSCPrmhHewC; Wed, 27 May 2020 18:02:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318303A082B; Wed, 27 May 2020 18:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6402; q=dns/txt; s=iport; t=1590627762; x=1591837362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=heVIqvxIHUd+kf36F73/YyW7IMEZSgNDI2tNbgN2we1/QzlyfK8Wa8WS 6R8/lAhf+yNWmr/i4JPlGjVC5TszgdDmVa/JGMiUTJDsYV5/7l4G2p0oW CdTLI/4mQoNwhm4btqHenxkUXqTncd3RxkPUWDP0C3iwT/1Jw2g49rPjq E=; IronPort-PHdr: =?us-ascii?q?9a23=3A4dSrEhe1g1bN4btr2rcElojFlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaSB9fS9v1ZkPbdvqTkUHYbp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0bBx?= =?us-ascii?q?riLhZ+K+DxE5TJyc+w0rP695jaeQ4dgj27bPt7Jwm3qgOEsM4QjO4AYqY8wx?= =?us-ascii?q?fEuD1GYeNTkGhpPlmU2R3745S9?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCvDM9e/4QNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUCMvB4FHLywKhBuDRgONP5hCglIDVQsBAQEMAQEtAgQ?= =?us-ascii?q?BAYREAheBfwIkOBMCAwEBCwEBBQEBAQIBBgRthVcMhXIBAQEBAxIREQwBATc?= =?us-ascii?q?BCwQCAQYCDgMEAQEDAiYCAgIwFQgIAgQBDQUigwSCTAMuAZN+kGcCgTmIYXa?= =?us-ascii?q?BMoMBAQEFhUMYgg4JgQ4qgmSJQx0aggCBESccgk0+hCaDPDOCLZFnj1yRcAq?= =?us-ascii?q?CVI45hU6EWR2CZIkDkiGQUp1pAgQCBAUCDgEBBYFqIoFWcBVlAYI+UBgNkEC?= =?us-ascii?q?DcopWdDcCBgEHAQEDCXyJdIE0AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,443,1583193600"; d="scan'208";a="773261627" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 01:02:41 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 04S12fsk006122 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2020 01:02:41 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 20:02:40 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 20:02:40 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 27 May 2020 20:02:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LfFIGlFaDyFDNK92mBwFcIW5NmX8igSp+BIeGjJ8TlzOL7USf/bZNWP/0jbpS/B5MFtI1iQM7gAmTn/O9MsPRTZjJVBH0Vq/fbSpC81SioF8gfX0EkhCSYB0zUVxbBroOr2ZPc32vGfXQkSulNZXEbgjgDZKLXYG2d4PBRWUfEn6pqHoE/f7am8+jhTxho+vPLGzPIMobXYgSZksy7lS8Z6V2EfA4dryM0pokVYUYSItldAzmXRecfffwI2del0jqLjCUG4KMYwdR6h17sUSgk9M8B9F72bVQZj5spoBDjIuPCi0A1E7+5tdBGgB5JQ0t7V1v1WrEQjqQTJz+Slcqg== 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=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=WyKze7V50Xf4SqeJaHldw6WPHPNGevDSTUySIBYA8rNrwhGTl1QKqyRiqR6OQJgzbO5qOlq/mTG+R+5hH7rKnYF0c0y8Q0E2C55QfD9Jdp0zcF89IDOMOLgpgPMu96kVslqbCYRhLXPSUsb41qlCzn7dynwlzl7mDdFxidrMfpklTWjQOyyvhxcvARRFGRYfjWdco7cq4tdIdlrPzLlzp7WmKmyw3IsLQLdXqIXMkVzEQMqq3AAXG/wuKMS7gMCKbcGx4OcEp7fSQq7lVAeEZuwQVEjIvhWSaUfYEWJKtruYHbVBdc3GTZCJ+4h4Z1H+7gs4CbVs+PtlQg6Jy3sYrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=YY4HTU6Ac8RhfXz961klY/TvkivEpKaeHEqJMx0zYd14hwwh0S7OyrbiO4Zz/kwsL17ovrBtlIarnzXUtIywSOpf3Hxa5sYcSdmqcBw5PJcCgeRQHgIHBlxcd4uV2RsO3GKrMuN86xffAneEhuK+mtM8RN3hjZoTaJddGPZYzn8= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4291.namprd11.prod.outlook.com (2603:10b6:a03:1c2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Thu, 28 May 2020 01:02:38 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949%6]) with mapi id 15.20.3021.030; Thu, 28 May 2020 01:02:38 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Jim Schaad , "secdir@ietf.org" CC: "cose@ietf.org" , "last-call@ietf.org" , "draft-ietf-cose-rfc8152bis-algs.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Thread-Index: AQHWM9KZeZSj+xDsXECz02YXYKWNB6i8Ol2A Date: Thu, 28 May 2020 01:02:38 +0000 Message-ID: <4853C09B-52BB-495F-B533-E624C55A626B@cisco.com> References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com> In-Reply-To: <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.16.200509 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e335dee0-8bd8-4f39-b746-08d802a2d0eb x-ms-traffictypediagnostic: BY5PR11MB4291: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f5PDTbFQS5HiMUQ1vziKHMUabHu1f71VFy/NX0+OEufCJLkMcxmF6x8Ag3PYg/a3Kd9EZniirDNYC0RirovLp5rTtG3ocHDuO652yUbEJaZiC1Y/4pQP/A3ZipWYEjubKdUg0qatwpeZAqs5+S4QA/iy1lkZcMNX5lQ0VW7fgaQ9i+0HAgQwZgdVnl20+DjHLy06Rpi5uMqVH1A2XjPgE1dBHbzNpe0fU1DAhChFrxmqxfzHML+Mv8zRoqljbJ+yWZtpBwPFfS2cxU2JDSw8l37924M9r2RwyddqbkPzrP/t5bBWW9tAKPOT7wgEfns5bxQprg03e+Myiag85obTjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(2616005)(54906003)(8676002)(2906002)(4326008)(6512007)(316002)(76116006)(186003)(66476007)(36756003)(64756008)(26005)(53546011)(5660300002)(71200400001)(33656002)(478600001)(110136005)(6506007)(66446008)(86362001)(66556008)(83380400001)(8936002)(6486002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FUZdDEStbBdhfC9cB/Og0K6oURhgiesRaw7hPOzrS/UmE3weK8nX6ltCJJ2Knh/rl2Fykji86pOInNlo1DLEeFDpn3vwb2LG5G1LNtkpkxTw1MGoyKfLrg6a15QNJQgnE/h3pMrErJonak1fDWHXLeCUGZ/t8OgKf08ev/SNxuew2y4IF2+utKMZGBQrp9Yjmb8fED6a9svv1nkT1EsJBlpZ/Ro8OHK0QuChko7Hhvurbk3mPZH9pbg44Rr0bos7sGujrWj6c0ywhb5pGZcGtXkjpi2NboKICTv82oDAdA7F5cmdv6VvrMKNnfwx1ikcPE0bzxZK8qhUNWn5YDiARZkzZXq3m2V9oCtNWVIcuxRvzHKeMaKEffLKNRfqYFYJuN82ddClZAvEf7fvkR4ZSr1r4TLFAQ2qX1397ZISWOM5ZXFYaksBrL7dtc8cDK6ARd4f06e4LsITKCYyltuJyeC2GNrgg6xOGpiX0eRiWMNyvF+Dhui1Gi2lyCIMlpjG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e335dee0-8bd8-4f39-b746-08d802a2d0eb X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 01:02:38.4182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BFZmROvb6gvBLnlTJU8xWsLzPWYJLNtTj+g/wlUnh9rRnvm7T77XO7HkhjNh+0OwlBxW/TOlfvu6eh5RtfUw+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4291 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 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, 28 May 2020 01:02:52 -0000 SGkgSmltLA0KQXBvbG9naWVzIGZvciBub3QgYmVpbmcgbW9yZSBjbGVhciwgc2VlIG1vcmUgY29u dGV4dCBiZWxvdzoNCg0K77u/T24gNS8yNi8yMCwgNzo1NyBQTSwgIkppbSBTY2hhYWQiIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KICAgIE5hbmN5IC0gb25lIGNsYXJpZmljYXRp b24gcGxlYXNlDQogICAgDQogICAgamltDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCiAgICBGcm9tOiBOYW5jeSBDYW0tV2luZ2V0IHZpYSBEYXRhdHJhY2tlciA8bm9yZXBs eUBpZXRmLm9yZz4gDQogICAgU2VudDogVHVlc2RheSwgTWF5IDI2LCAyMDIwIDI6MjMgUE0NCiAg ICBUbzogc2VjZGlyQGlldGYub3JnDQogICAgQ2M6IGNvc2VAaWV0Zi5vcmc7IGxhc3QtY2FsbEBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxncy5hbGxAaWV0Zi5vcmcNCiAg ICBTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvc2UtcmZj ODE1MmJpcy1hbGdzLTA4DQogICAgDQogICAgUmV2aWV3ZXI6IE5hbmN5IENhbS1XaW5nZXQNCiAg ICBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KICAgIA0KICAgIElPVERJUiByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxncy0wOA0KICAgIA0KICAgIFJldmlld2VyOiBOYW5j eSBDYW0tV2luZ2V0DQogICAgDQogICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMg cGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUnc8OKIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZcOKIElFU0cuw4rD ilRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9m IHRoZcOKIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLsOKw4pEb2N1bWVudCBlZGl0b3JzIGFuZCBX RyBjaGFpcnMgc2hvdWxkIHRyZWF0w4ogdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgDQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YW4gaW5pdGlhbCBzZXQgb2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHVzZWQgdG8gcHJvdGVj dCBDQk9SLCBJIGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyBhbG1vc3QgcmVhZHksIGJhcnJpbmcg c29tZSBlZGl0b3JpYWwgbml0cyAoSSBvbmx5IG1hZGUgYSBmZXcgYmVsb3cpLiAgSW4gZ2VuZXJh bCwgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSAiaW5pdGlhbCINCiAgICBzZXQgb2YgYWxnb3JpdGht cyB1c2VkIGluIENPU0UgbWFrZSBzZW5zZSBhbmQgaXQgaXMgZ29vZCB0byBzZWUgZWFjaCBzZWN0 aW9uIGNhcnJ5IHRoZWlyIG93biBzZWN1cml0eSBzZWN0aW9uIGZvciBiZXR0ZXIgbWFwcGluZyBv ZiB0aGUgY29uc2lkZXJhdGlvbnMgYmFzZWQgb24gdGhlIHNlY3VyaXR5IGFsZ29yaXRobSBhcHBs aWVkLiAgQXMgYSByZWFkZXIgKGxpa2UgbXlzZWxmKSB3aG8gaXMgbm90IGZ1bGx5IHZlcnNhbnQg dG8gdGhlIG51YW5jZXMgb2YgQ0JPUiBpdCB3YXMgYSBsaXR0bGUgaGFyZCB0byBmb2xsb3cgYXMg dGhlIHN0cnVjdHVyZXMgYW5kIHRheG9ub215IGlzIGRlc2NyaWJlZCBpbiB0aGUgY29tcGFuaW9u IGRyYWZ0IChkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1zdHJ1Y3QpLiBBcyBhIHdob2xlLCBJ IHRoaW5rIHRoZSBkb2N1bWVudCBpcyBjbG9zZSB0byByZWFkeSwgSSBvbmx5IG5vdGVkIGEgZmV3 IHRlY2huaWNhbCBhbmQgZWRpdG9yaWFsIG5pdHMgZm9yIHRoZSBlYXJsaWVyIHNlY3Rpb25zIGJl bG93Og0KICAgIA0KICAgIFNlY3Rpb24gMi4xOg0KICAgIC0gV2hhdCBmaWVsZCBkb2VzIHRoZSBF Q0RTQSBhbGdvcml0aG0gdmFsdWUgbWFwIHRvPyBJIHByZXN1bWUgaXQgaXMgdGhlICdhbGcnDQog ICAgZmllbGQgKGlmIHByZXNlbnQpPyBCdXQgc2hvdWxkIGJlIG1hZGUgZXhwbGljaXQuIC0gSXQg c2VlbXMgdGhhdCB0aGUgInNob3VsZCINCiAgICBpbiB0aGUgNHRoIHBhcmFncmFwaCBpcyBub3Jt YXRpdmUgKGUuZy4gU0hPVUxEKSBhcyBpdCBpcyBuZWVkZWQgZm9yIGludGVyb3BlcmFiaWxpdHks IGFuZCBwZXJoYXBzIGV2ZW4gYSBNVVNUIGFzIEknbSBub3Qgc2VlaW5nIG5lZ290aWF0aW9uIG9y IHNlbGVjdGlvbiBvZiBjdXJ2ZSBjaG9pY2UuICBTbywgaWYgaXQgaXMgdG8gYmUgaW1wbGljaXQs IHRoZW4gYSBNVVNUIHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuDQogICAgW0pMU10gSSBkb24n dCB0aGluayBJIGtub3cgd2hpY2ggInNob3VsZCIgeW91IGFyZSB0YWxraW5nIGFib3V0LiAgVGhl IHdvcmQgZG9lcyBub3QgZXhpc3QgaW4gdGhhdCBwYXJhZ3JhcGggc28gSSBkb24ndCBrbm93IGZv ciBzdXJlIHRoYXQgSSBoYXZlIHRoZSBzYW1lIG51bWJlci4NCltOQ1ddIFRoZSBzZW50ZW5jZSBk b2Vzbid0IGhhdmUgYSBTSE9VTEQgdGhvdWdoIEkgdGhpbmsgdGhlIHdvcmQgInN1Z2dlc3RlZCIg c2hvdWxkIGJlIHN0cm9uZ2VyOyBlLmcuICJJbiBvcmRlciB0byBwcm9tb3RlIGludGVyb3BlcmFi aWxpdHksIFNIQS0yNTYgU0hPVUxEIGJlIHVzZWQgd2l0aCBjdXJ2ZSBQLTI1Ni4uLi4iDQogICAg DQogICAgU2VjdGlvbiAyLjI6DQogICAgLSBUaGUgcmF0aW9uYWxlVGhlcmUgbWF5IGJlIHNvbWUg Y29ybmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJlIGEgdmVyeSBsYXJnZQ0KICAgICgySz8p IHN0cnVjdHVyZSB0byBiZSBwcm90ZWN0ZWQuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcXVhbnRp ZnkgImV4dHJlbWVseSBsYXJnZSIgb3IgcGVyaGFwcyBhbm90aGVyL2FkZGl0aW9uYWwgcmF0aW9u YWxlIGZvciB0aGUgbmVlZCB0byBPTkxZIGRvIFB1cmUgZWREU0EgaXMgdGhlIGludGVudCBmb3Ig Y29uc3RyYWluZWQgZGV2aWNlcyBub3QgaGF2ZSBlbm91Z2ggbWVtb3J5IHRvIGNvbXB1dGUgdGhl IGJsb2NrIHVwZGF0ZXMuDQogICAgDQogICAgU2VjdGlvbiA0LjEuMToNCiAgICAtIEdDTSdzIGxp bWl0YXRpb24gZm9yIG9uZSBlbmNyeXB0aW9uIHN0cmluZyBpcyAyXjM5LTI1NiBlLmcuIG5vdCAi YSBzaW5nbGUga2V5Ii4uLi5zbyBzdWZmaWNpZW50bHkgbGFyZ2UgZm9yIENPU0UhICBIb3dldmVy LCBpdCBkb2VzIG1lYW4gdGhhdCB0aGUgbm9uY2UgTVVTVCBiZSB1bmlxdWUgZm9yIGV2ZXJ5IGVu Y3J5cHRlZCBtZXNzYWdlIChlLmcuIHRoZSBidWxsZXQgYmVmb3JlIHRoaXMgb25lIGlzIGNvcnJl Y3QpLiAgSSB0aGluayB0aGUgbGltaXQgZm9yIG9uZSBrZXkgdXNpbmcgR0NNIGlzIGJhc2VkIG9u IHRoZSBzaXplIG9mIHRoZSBub25jZSBhcyBpdCBtdXN0IGJlIHVuaXF1ZS4NCiAgICANCiAgICBT ZWN0aW9uIDQuMjoNCiAgICAtICdrJyBpcyB0aGUga2V5IHNpemUgaW4gYml0cyAoSSBwcmVzdW1l KSwgd291bGQgYmUgZ29vZCB0byBkZXNjcmliZSB0aGF0IGJlZm9yZSB0aGUgdGFibGUuDQogICAg DQogICAgRWRpdG9yaWFsIG5pdHM6DQogICAgU2VjdGlvbiAxLjUNCiAgICAtIFRoZSBzZWNvbmQg c2VudGVuY2UgaXMgaGFyZCB0byBwYXJzZS4gIElzIGl0IHRoYXQgdGhlIGludGVybWVkaWF0ZSB2 YWx1ZXMgdXNlZCBmb3IgZGVidWdnaW5nIGFyZSByZXByZXNlbnRlZCBpbiBib3RoIGEgaGV4IGFz IHdlbGwgYXMgYSBDQk9SIGRpYWdub3N0aWMgbm90YXRpb24gZm9ybWF0Ij8gLSBUaGlyZCBzZW50 ZW5jZSwgaXMgaXQgdGhhdCBzb21lIGV4YW1wbGVzIHdlcmUgZGVzaWduZWQgdG8gZmFpbCAoZS5n LiB0aGV5IGFyZSAiZmFpbHVyZSB0ZXN0IGJhc2VzIik/DQogICAgDQogICAgU2VjdGlvbiAyLjI6 DQogICAgLSBUaGUgcmF0aW9uYWxlIGZvciB3aHkgUHVyZSBFZERTQSBpcyB1c2VkIG9ubHkgKHZz LiBIYXNoRWREU0EpIG1heSBsZWF2ZSBtb3JlIHJvb20gZm9yIHF1ZXN0aW9uczsgYXMgdGhlcmUg bWF5IGJlIHNvbWUgY29ybmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJlIGEgdmVyeSBsYXJn ZSAoMks/KSBzdHJ1Y3R1cmUgdG8gYmUgcHJvdGVjdGVkLiAgRm9yIHRob3NlIHRoYXQgYXJlIGlu IHRoZSBoZWFsdGhjYXJlIHNlY3RvciAob2YgSW9UKSwgSSBjb3VsZCBzZWUgcG90ZW50aWFsIGZv ciBsYXJnZSBibG9ja3MgYW5kIG1heSB3b25kZXIgd2hhdCBxdWFsaWZpZXMgYXMgImV4dHJlbWVs eSBsYXJnZSIuICBSRkMgODAzMiBzcGVha3MgdG8gSGFzaEVkRFNBIGFzIHByb3ZpZGluZyBiZXR0 ZXIgY29sbGlzaW9uIHJlc2lsaWVuY2UuLi5zbyBhbSBpbmNsaW5lZCB0byBzdWdnZXN0IHRvIGVp dGhlciByZW1vdmUgdGhpcyByYXRpb25hbGUgb3IgYmUgbW9yZSBjb21wbGV0ZSBpbiBqdXN0aWZp Y2F0aW9uLg0KICAgIA0KICAgIFNlY3Rpb24gMy4xDQogICAgLSAzcmQgcGFyYWdyYXBoOiAiU29t ZSByZWNpcGllbnQgYWxnb3JpdGhtcyBjYXJyeSB0aGUga2V5IHdoaWxlIG90aGVycyBkZXJpdmUg YSBrZXkgZnJvbSBzZWNyZXQgZGF0YSIuLi4uSSB0aGluayB5b3UgbWVhbiAiU29tZSBhbGdvcml0 aG1zIGFyZSB1c2VkIHRvIHRyYW5zbWl0IGEga2V5LCBlLmcuIGtleSB3cmFwcGluZy4iICAiQ2Fy cnkgdGhlIGtleSIsIGluIHRoaXMgc2VudGVuY2UgbGVhZHMgbWUgdG8gaW1wbHkgaXQncyB0aGUg c2FtZSBrZXkgYmVpbmcgdXNlZCBpbiB0aGUgSE1BQy4NCiAgICANCiAgICANCiAgICANCiAgICAN Cg0K From nobody Wed May 27 19:20:25 2020 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 CCC353A0BE9; Wed, 27 May 2020 19:20:16 -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 rIcqhV2Kshcq; Wed, 27 May 2020 19:20:14 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5223A0B32; Wed, 27 May 2020 19:19:58 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 27 May 2020 19:19:50 -0700 From: Jim Schaad To: 'Theresa Enghardt' , CC: , , References: <159044129232.11103.11777847473965400673@ietfa.amsl.com> In-Reply-To: <159044129232.11103.11777847473965400673@ietfa.amsl.com> Date: Wed, 27 May 2020 19:19:49 -0700 Message-ID: <03c001d63496$786d5c20$69481460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQItAfBzXC8RKAezc3vFa2i802vvoKgMBbSQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 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, 28 May 2020 02:20:24 -0000 Theresa, Here is my response for your review. =20 I had to really think about a couple of your comments at least in part = because I am so immersed in this that it is hard for me to see things = with new eyes. There are comments below prefixed with [JLS] and I have = merged the comments into the repository so you can look at the text that = I inserted (or deleted) but did not copy into this message Jim Pull request with updated text: = https://github.com/cose-wg/cose-rfc8152bis/pull/22/commits/a9862ec70fa743= 39ce4a01a4ee743728f815952c Full text with last review: https://github.com/cose-wg/cose-rfc8152bis -----Original Message----- From: Theresa Enghardt via Datatracker =20 Sent: Monday, May 25, 2020 2:15 PM To: gen-art@ietf.org Cc: cose@ietf.org; draft-ietf-cose-rfc8152bis-struct.all@ietf.org; = last-call@ietf.org Subject: Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 Reviewer: Theresa Enghardt Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any = other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cose-rfc8152bis-struct-09 Reviewer: Theresa Enghardt Review Date: 2020-05-25 IETF LC End Date: 2020-05-29 IESG Telechat date: Not scheduled for a telechat Summary: This document describes data structures and processes in = detail, with minor updates. In combination with a companion document on = algorithms, it obsoletes RFC 8152. The document has some issues and = editorial nits, which should be addressed prior to publication. Major issues: The intended RFC status is Internet Standard, while RFC 8152 is a = Proposed Standard. While this document points to three different = implementations, how widespread is their deployment? Were there other = lessons learned from implementation and deployment experience? Has = complexity been reduced by removing unused features, as RFC 6410 = suggests? [JLS] This document lists the three most complete implementations of = the document that I know about. I am aware of at least nine different = implementations of the specification. The rest of them implement a = subset of the structures in the document and are not as complete. I am = aware of at least two different places where one of my implementations = has been adapted to work in a different location. I have had several = different jolts where I have learned that COSE is either being used or = is planned to be used in different locations. So yes, I believe that = there are a number of implementations and the usage of parts of COSE are = wide spread. =20 [JLS] The only complexity reduction in the document that has been made = is to remove the algorithm descriptions from the document and thus = shortening the structure document from 120 pages to around 80 pages. = The problem with removing any additional items is that some security = feature will no longer be available for applications to use. For that = reason no features have been removed. Minor issues: In the introduction, it would be great to add some more context on how = COSE is intended to be used. Is this solely for adding security to = objects within CoAP, e.g., by signing and encrypting messages exchanged = as CoAP payload? Or can it be used with other protocols or in other = contexts? In RFC 7165, which describes JOSE use cases, Section 5.8.2 = mentions Object Security for CoAP. Is COSE addressing this use case? If = so, please add a link to Section 5.8.2 of RFC 7165. Section 9.5.4 = mentions that COSE "is designed for a store and forward environment = rather than an online environment". Perhaps it's worth mentioning such = design goals and context in the introduction already. When adding one or = two paragraphs on how COSE is intended to be used to the introduction, = it's also worth stating explicitly that each application is expected to = select the COSE objects and processes that it needs, and that Section 11 = provides more guidance on how to do this. This will make it easier for = application developers to understand how to use COSE. [JLS] I have added such a paragraph which you can view in the github = version of the document. I did not reference 7165 as you suggested but = went directly to the CoRE solutions using COSE instead. "One feature that is present in CMS [RFC5652] that is not present in this standard is a digest structure. This omission is deliberate. It is better for the structure to be defined in each document as different protocols will want to include a different set of fields as part of the structure." Does "in each document" refer to documents for different encryption = algorithms or protocols? Please clarify. Is = draft-ietf-cose-rfc8152bis-algs an example of one of these documents, as = it describes algorithms? Or is another type of documents meant here? [JLS] modified to "It is better for the structure to be defined in each = protocol as different protocols will want to include a different set of = fields as part of the structure." I also added a reference to = "I-D.ietf-cose-hash-algs" which contains additional information and = algorithms for solving this problem. When introducing the CDDL syntaxes: Is "* label =3D> values" missing here? It appears to be used in some = examples below. [JLS] I do not believe that this needs to be introduced in the text. = The section discusses only a part of CDDL that is used in the document = and points to CDDL so that some additional things can be found. The = syntax "label=3D>value" is equivalent to "label: value" but either in a = yet to be defined sense or for something which is not a string or number = as the label. Given that the text is normative it does not worry me = that a complete description of CDDL is not presented here. "The CDDL grammar is informational; the prose description is normative." Why? Isn't it important for interoperability that the objects are = structured in a certain way and that there is no ambiguity? [JLS] There are a number of reasons why CDDL is not the normative = version of the grammar. Firstly, the RFC for it did not exist when RFC = 8152 was written. This meant that it was either going to be gated on = getting CDDL published or it needed to just not use CDDL in a normative = manner. Given that CDDL was not published until June of last year I am = just as happy that we did not wait for it. This means that it would = require a fairly major re-write of the document to make CDDL the = normative version now. While it is important that there is no ambiguity = in the layout, I believe that the prose version does not suffer from = that fault. Additionally, using CDDL normatively now would require a = discussion on the downwards reference from this document as a Full = Standard to CDDL as a Proposed Standard. In Section 2: "[...] The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit. (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding." I'm not sure I understand this scenario. Does this statement just apply = to zero-length maps or to all kinds of protected buckets? What does "to = be transported with a greater chance" mean here? That intermediates are = less likely to block traffic containing such a COSE object? That = intermediates are less likely to accidentally (or deliberately) modify = it in such a way that it gets accepted by the receiver? Is this an = effect of some cryptographic protection, is it related to different = encoding techniques being used in different implementations, or both? = Why is it a problem if all parties need to be able to do a common = canonical encoding? In fact, what kind of encoding does this refer to: = Binary encoding vs. base64 encoding? Or specific ways of encoding = certain information as binary data? [JLS] I think that you mean section 3 if that is not right please let me = know. The wrapping applies to all encoding of protected buckets. For a = zero length bucket this is less of an issue as there is only one way to = encode it per the rules in section 10. The issue is that an = intermediate entity could decode the message, including the map, and = encode it using a slightly different encoding. This normally has to do = with the order of items in the map but could be any number of things as = the rules for deterministic encoding would need to be expanded to cover = all possible CBOR objects rather than just the few that are given in = section 10. If one decodes all the way to the data model of CBOR then = things such as dates become difficult to encode canonically as it could = be encoded either as a floating point number or an integer number. By = doing the wrapping all parties doe NOT need to be able to do a common = canonical encoding. Experience with ASN.1 and the XML signature = security have shown that the number of times that at least one party is = going to get things wrong is much higher than one would like to see for = a security protocol that wants to be simple and small. Would starting a = new paragraph at this point make it easier to understand that it is = nothing to deal with zero-length maps? In Section 4.1: "An example of header a parameter about the content is the content type. " This sentence appears to be broken. [JLS] Yes, appending "header attribute" to the end of the sentence makes = it clearer. In Section 4 or 5, maybe it's worth adding a brief description or = reference of what a countersignature is. In contrast to the concepts of = signing, encryption, and Message Authentication Codes, I would not = expect every application developer to be familiar with the concept of a = countersignature and what it's needed for. [JLS] That makes sense and I have done so. In Section 10, the document presents restrictions on the CBOR encoder. "We have managed to narrow it down to the following restrictions" sounds = like these might have been narrowed down from RFC 8152, and maybe could = be rephrased to sound more neutral. Why are these restrictions = necessary? Maybe it's worth adding a brief explanation for each = restriction. [JLS] I have eliminated the sentence as it does not really add to = anything. I don't think that there is a real benefit to adding the = explanation for each of the restrictions. The first one has to do with = a deterministic encoding. The second one has to do with the possibility = of getting two different answers. The CBOR WG has been spending lots of = cycles recently on how to make this statement an the justifications for = it in the update CBOR document. I would rather not get into that type = of argument. In the Security Considerations: What threat models have been considered for COSE? [JLS] No specific threat models or security analysis has been done for = COSE. In general this is done either at the protocol layer or at the = algorithm layer. Details like what is sent and how identity and keys = are managed are at the protocol layer. Details on how much a symmetric = algorithm can be used are at the cryptographic layer. Some of the types = of things you might be looking for are going to be found in the = algorithms draft rather than here. Nits/editorial comments: Section 12: "The only known action at this time is to update the references." Right after this statement, the document describes another IANA action. = So maybe updating the references is not "the only known action" anymore? [JLS] This is a change in the document that I missed and should have = caught. Originally only reference updates were done and then the WG = decided that there should be a tag assignment made for = countersignatures. I have changed the sentence from "only known" to = "majority of", with some additional changes for readability. For most IANA registries, this document simply asks to update the = references from RFC 8152 to this document. However, for the Media Type = Registrations, Section 12.5 appears to repeat the registry information. = Does this document introduce any changes here? If not, why is the = information repeated here, but not in the other sections? [JLS] The registration template for a media-type is not placed into an = IANA registry. Rather the name of the media-type and a pointer to the = document is placed in the registry (see = https://www.iana.org/assignments/media-types/media-types.xhtml). = Copying the registration template forward is therefore needed in order = to have something in this document to point to. =20 From nobody Thu May 28 07:39:05 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC72C3A0FAD; Thu, 28 May 2020 07:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen via Datatracker To: Cc: cose@ietf.org, last-call@ietf.org, draft-ietf-cose-hash-algs.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159067673678.14090.12303273078013351780@ietfa.amsl.com> Reply-To: Jouni Korhonen Date: Thu, 28 May 2020 07:38:56 -0700 Archived-At: Subject: [COSE] Opsdir last call review of draft-ietf-cose-hash-algs-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 14:39:04 -0000 Reviewer: Jouni Korhonen Review result: Has Nits I find this document ready for publication. No substantial comments except the nit is the abstract having a reference as also reported by Idnits needs to be corrected. From nobody Thu May 28 14:15:07 2020 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 E59763A0ED1; Thu, 28 May 2020 14:15: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 P-1B7jcvCHy3; Thu, 28 May 2020 14:15:03 -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 285843A0ECF; Thu, 28 May 2020 14:15:02 -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 04SLEolq028159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 May 2020 17:14:53 -0400 Date: Thu, 28 May 2020 14:14:50 -0700 From: Benjamin Kaduk To: tom petch Cc: Jim Schaad , "'Last Call'" , "cose-chairs@ietf.org" , "draft-ietf-cose-hash-algs@ietf.org" , "cose@ietf.org" , "ivaylo@ackl.io" Message-ID: <20200528211450.GJ58497@kduck.mit.edu> References: <5EC3A871.80903@btconnect.com> <018e01d62f0e$3e91d2c0$bbb57840$@augustcellars.com> <1UW9V85i5B.1X3e1rfkHhW@pc8xp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1UW9V85i5B.1X3e1rfkHhW@pc8xp> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] [Last-Call] Last Call: (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC 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, 28 May 2020 21:15:06 -0000 The nested quoting is pretty hard to read; hopefully I am responding in the right places... On Thu, May 21, 2020 at 10:30:18AM +0100, tom petch wrote: > Jim > inline several times > > ----- Original Message ----- > From: Jim Schaad ietf@augustcellars.com > Sent: 21/05/2020 02:21:39 > > -----Original Message----- > From: COSE On Behalf Of tom petch > Sent: Tuesday, May 19, 2020 2:36 AM > > I encounter a number of problems with this I-D. Much of it is about IANA > Considerations and I note the absence of a reference to RFC8126 which > provides the basis for much of my comments. > > [JLS] There is a reason why you are not seeing much of the IANA > Considerations that you believe should be present, it is because they are in > draft-ietf-cose-rfc8152bis-algs and draft-ietf-cose-rfc8152bis-struct. Most > of them are in the algorithm document. The presumption is that those two > documents are going to be processed by IANA before this document is. I will > make this explicit. > > > Yes, if there had been a Normative Reference to rfc8152bis-algs then I would have read that first and my comments would have been different! If the updates to the IANA Registry are all in -algs, then I think it confusing to have them in here as well, rather just say that a new column is defined in -algs > > I do not see any mention of 'filter only' in the two rfc8152bis, only in this I-D and that makes me see this I-D as updating RFC8152 with the consequences thereof. > > > > RFC8126 specifies a two-tier structure for IANA, of Group name an Registry > name, which makes it easier to find data, now and in future. > This I-D makes no mention of the Group name; perhaps easy enough to guess in > this instance, but better specified. > > The I-D contains references to some of TBD1 to TBD11, with no indication of > what to do with them. Looking at the current registry it is apparent that > Early Allocation took place in 2018 and 2019. The I-D makes no reference to > this. Are all these values to be made permanent? Some of them? I expect > the I-D to say. > [JLS] use the TBD placeholders is normal usage with the values being > assigned by IANA and replaced in the document. It would be possible to > refer to the early assignments, but I personally feel that this is a > decision for IANA to make. There may be reasons when the final assignment > is done that different values need to be used. (For example, incorrect > usage of existing values in the wild or collisions found during the > assignment process.) I have always made the assumption that the instruction > for the RFC Editor to replace them is implicit and does not need to be > explicit. I can make that change although I doubt it makes any difference. > > I disagree with you here. Yes, the final allocation is for IANA to make but you should ask for what you want to guide them. Early Allocation can mean implemented in ASICs and deployed in hundreds of thousands of boxes in which case the cost of change is substantial compared to say a change of one constant in one line in Linux. You know, IANA do not; tell them! I do think it's pretty common to have the document say something about "makes permanent the early allocation of value NNN for ". > > The I-D adds the value 'filter only' to one of the columns. The registry > was set up by RFC8152 which lists permitted values of which this is not one. > This then constitutes an update to RFC8152 which the I-D does not mention. > [JLS] I would disagree that this requires an update of RFC 8152 for two > reasons. First this is not a change in the COSE protocol in any manner and > thus would violate what I consider to be the letter of the law for updates. > Second, when this change is made RFC 8152 will have been obsoleted by a new > RFC and thus it does not really make sense to update it. This is an IANA > instruction not a protocol change. > > I agree that the protocol does not change but the rules set out by RFC8152 for the IANA Registry do change and that IMHO is an update to RFC8152, one that rfc8152bis-algs does not include, The registry is an entity in its own right, and there is a "Reference" field associated with the registry that accepts multi-value input. Updating the registry is generally orthogonal to updating the document that created the registry initially. -Ben > > The registry has five columns; this I-D adds a new one, Capabilities, > another update to RFC8152. What then happens to this column for existing > entries in the registry? The I-D is silent. > [JLS] This is done by a different document. > yes, I can see that now > > RFC8152 is Standards Track; this I-D which IMHO updates it is Informational. > [JLS] Given that it is updating the IANA sections and not the protocol I > would not consider that to be an issue. > I do :-) > > The IANA registry entry gives a reference of 'RFC8152'; this I-D, which > changes the specification of the registry, needs adding to that reference. > [JLS] This make sense and I will do it. > > RFC8126 recommends that IANA Considerations be for IANA, that IANA does not > have to search the rest of the document for the data it needs. > Here, the relevant data appears in three other sections as well (and there > is much in the I-D that is not relevant to IANA, it is not one of those I-D > that is only about IANA). > [JLS] I do not consider that pointing to a table in the document to fall > under the rubric of making IANA search for data. It is a direct pointer to > the information that is required. Having the same table appear multiple > times in a document is a recipe for making mistakes in terms of what the > data is. There is already the problem of trying to harmonize text and the > table with out adding another version of the table. > > Abstract should be plain text - > [I-D.ietf-cose-rfc8152bis-struct] > does not look like plain text. > [JLS] This is not plain text and will be repaired by the RFC editor. Using > the reference structure makes it clearer that this is something that the RFC > editor is going to be required to update. This is not something I do for > documents which are already RFCs. > An alternative that I see other Authors use is to specify RFC YYYY with an RFC Editor note to replace YYYY when the I-D referenced becomes an RFC - just a thought. > > Tom Petch > > I have great faith in the a > > --- > New Outlook Express and Windows Live Mail replacement - get it here: > https://www.oeclassic.com/ > > bility of IANA to make sense of what they are > asked to do but do think that the more straightforward that is the better. > And then there are those that come after, who want the RFC to say what > happened and why without digging into the e-mail archives (as I see > happening now and again:-) > [JLS] The other problem that you have not highlighted is the question of > when a bis document is created should the IANA instructions be propagated > forward into the new document despite the fact that IANA is not going to do > anything. That is what is going to happen with some of these registries. > It makes life even harder if duplicate or extraneous items are included. > > Jim > > > Tom Petch > > > ----- Original Message ----- > > From: "IETF-Announce on behalf of The IESG" > > > > To: > > Cc: ; ; > > ; > > Sent: Tuesday, May 12, 2020 4:26 PM > > > >> The IESG has received a request from the CBOR Object Signing and > > Encryption > >> WG (cose) to consider the following document: - 'CBOR Object Signing > > and > >> Encryption (COSE): Hash Algorithms' > >> as Informational RFC > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > > final > >> comments on this action. Please send substantive comments to the > >> last-call@ietf.org mailing lists by 2020-05-26. Exceptionally, > > comments may > >> be sent to iesg@ietf.org instead. In either case, please retain the > > beginning > >> of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >> The CBOR Object Signing and Encryption (COSE) syntax > >> [I-D.ietf-cose-rfc8152bis-struct] does not define any direct > > methods > >> for using hash algorithms. There are however circumstances where > >> hash algorithms are used: Indirect signatures where the hash of one > >> or more contents are signed. X.509 certificate or other object > >> identification by the use of a fingerprint. This document > >> defines > > a > >> set of hash algorithms that are identified by COSE Algorithm > >> Identifiers. > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > >> > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > >> > >> > >> > >> _______________________________________________ > >> IETF-Announce mailing list > >> IETF-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf-announce > >> = > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Thu May 28 21:24:06 2020 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 A7A423A0AE1; Thu, 28 May 2020 21:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=tenghardt.net 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 lWhAifybKD-e; Thu, 28 May 2020 21:24:02 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2253F3A0ADE; Thu, 28 May 2020 21:24:01 -0700 (PDT) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 427DB9B; Fri, 29 May 2020 06:23:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1590726239; bh=ve9zxLfSrey/gwM4fmtt+tUy5uPFMuG9E7pkIYgpyO4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EuN1edi4axXZxcLzPf9jGvEB11OS1Owno5hLH5GNiqmtVWzBdn555bwLX2G+RJ9sO QyPfkwJ1Be/Ng5k/oo2Wah6wuP3Pu5YgWHrwwEOECP+AsTNJ5M7hZMjbpGBFLq5nt6 HvaDZIP7LVT0I5+F+Gq7wsd/z61iWNIXJ/NPksQYFEhbDFWIA7OG2j6nerzvLTjKia dnJUOwuxkB/wiuO6cnufyDTVPRAafKeErpB9f2NSLwLxuuA+BsMPxvXjfUXjg5Nd3e bpgVh8ow+ifo2CiwI/7zPUPutNLcvkHIM6wXgbBLxA5nPEqAYYg7Eg3aGjMnO4vzrv Y7BMsLBN7sTKw== To: Jim Schaad , gen-art@ietf.org Cc: draft-ietf-cose-rfc8152bis-struct.all@ietf.org, last-call@ietf.org, cose@ietf.org References: <159044129232.11103.11777847473965400673@ietfa.amsl.com> <03c001d63496$786d5c20$69481460$@augustcellars.com> From: Theresa Enghardt Message-ID: Date: Thu, 28 May 2020 21:23:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <03c001d63496$786d5c20$69481460$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [COSE] [Last-Call] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 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, 29 May 2020 04:24:05 -0000 Hi Jim, Thank you for the responses and text changes. Please find replies to some of your points inline, prefixed with "[TE]". Best, Theresa On 27.05.20 19:19, Jim Schaad wrote: > Major issues: > > The intended RFC status is Internet Standard, while RFC 8152 is a Propo= sed Standard. While this document points to three different implementatio= ns, how widespread is their deployment? Were there other lessons learned = from implementation and deployment experience? Has complexity been reduce= d by removing unused features, as RFC 6410 suggests? > > [JLS] This document lists the three most complete implementations of t= he document that I know about. I am aware of at least nine different imp= lementations of the specification. The rest of them implement a subset o= f the structures in the document and are not as complete. I am aware of = at least two different places where one of my implementations has been ad= apted to work in a different location. I have had several different jolt= s where I have learned that COSE is either being used or is planned to be= used in different locations. So yes, I believe that there are a number = of implementations and the usage of parts of COSE are wide spread. =20 > > [JLS] The only complexity reduction in the document that has been made = is to remove the algorithm descriptions from the document and thus shorte= ning the structure document from 120 pages to around 80 pages. The prob= lem with removing any additional items is that some security feature will= no longer be available for applications to use. For that reason no feat= ures have been removed. [TE] I see. I'm excited to hear about IoT security techniques getting deployed! > Minor issues: > > In the introduction, it would be great to add some more context on how = COSE is intended to be used. Is this solely for adding security to object= s within CoAP, e.g., by signing and encrypting messages exchanged as CoAP= payload? Or can it be used with other protocols or in other contexts? In= RFC 7165, which describes JOSE use cases, Section 5.8.2 mentions Object = Security for CoAP. Is COSE addressing this use case? If so, please add a = link to Section 5.8.2 of RFC 7165. Section 9.5.4 mentions that COSE "is d= esigned for a store and forward environment rather than an online environ= ment". Perhaps it's worth mentioning such design goals and context in the= introduction already. When adding one or two paragraphs on how COSE is i= ntended to be used to the introduction, it's also worth stating explicitl= y that each application is expected to select the COSE objects and proces= ses that it needs, and that Section 11 provides more guidance on how to d= o this. This will make it easier for application de > velopers to understand how to use COSE. > > [JLS] I have added such a paragraph which you can view in the github v= ersion of the document. I did not reference 7165 as you suggested but we= nt directly to the CoRE solutions using COSE instead. [TE] Thank you for adding this paragraph! I find it very helpful to better understand the context and use cases of COSE. Found one typo: "[=E2=80=A6] although one can use COSE in and online prot= ocol [=E2=80=A6]" -> "in an online protocol". > When introducing the CDDL syntaxes: > Is "* label =3D> values" missing here? It appears to be used in some ex= amples below. > > [JLS] I do not believe that this needs to be introduced in the text. T= he section discusses only a part of CDDL that is used in the document and= points to CDDL so that some additional things can be found. The syntax = "label=3D>value" is equivalent to "label: value" but either in a yet to b= e defined sense or for something which is not a string or number as the l= abel. Given that the text is normative it does not worry me that a compl= ete description of CDDL is not presented here. [TE] Right, I was just wondering if "* label" is similar to "+ label" used in other places. As "[+ FOO]" is introduced in Section 1.4, I was wondering if [* FOO] has to be introduced as well to be consistent. But maybe I'm misunderstanding and these are substantially different? > In Section 2: > "[...] The wrapping allows for the encoding of the > protected map to be transported with a greater chance that it will > not be altered in transit. (Badly behaved intermediates could > decode and re-encode, but this will result in a failure to verify > unless the re-encoded byte string is identical to the decoded byte > string.) This avoids the problem of all parties needing to be > able to do a common canonical encoding." > I'm not sure I understand this scenario. Does this statement just apply= to zero-length maps or to all kinds of protected buckets? What does "to = be transported with a greater chance" mean here? That intermediates are l= ess likely to block traffic containing such a COSE object? That intermedi= ates are less likely to accidentally (or deliberately) modify it in such = a way that it gets accepted by the receiver? Is this an effect of some cr= yptographic protection, is it related to different encoding techniques be= ing used in different implementations, or both? Why is it a problem if al= l parties need to be able to do a common canonical encoding? In fact, wha= t kind of encoding does this refer to: Binary encoding vs. base64 encodin= g? Or specific ways of encoding certain information as binary data? > > [JLS] I think that you mean section 3 if that is not right please let m= e know. The wrapping applies to all encoding of protected buckets. For = a zero length bucket this is less of an issue as there is only one way to= encode it per the rules in section 10. The issue is that an intermediat= e entity could decode the message, including the map, and encode it using= a slightly different encoding. This normally has to do with the order o= f items in the map but could be any number of things as the rules for det= erministic encoding would need to be expanded to cover all possible CBOR = objects rather than just the few that are given in section 10. If one de= codes all the way to the data model of CBOR then things such as dates bec= ome difficult to encode canonically as it could be encoded either as a fl= oating point number or an integer number. By doing the wrapping all part= ies doe NOT need to be able to do a common canonical encoding. Experienc= e with ASN.1 and the XML signature security have sh > own that the number of times that at least one party is going to get t= hings wrong is much higher than one would like to see for a security prot= ocol that wants to be simple and small. Would starting a new paragraph at= this point make it easier to understand that it is nothing to deal with = zero-length maps? [TE] You're right, I meant Section 3. And yes, I think starting a new paragraph here would make it easier to understand that this is no longer about the zero-length map. Also, maybe substituting "The wrapping" with something more general helps, because otherwise I'm wondering which part of the previous sentence the "The" refers to. Further, I'm wondering if it's worth adding "accidentally" (or similar wording) to the sentence saying that content is transported "with a greater chance that it will not be altered in transit". As the draft is about security, when reading this I was thinking about an attacker altering a message deliberately, but according to your explanation, this part appears to be more about accidentally altering a message. From nobody Fri May 29 10:22:22 2020 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 24C563A085D; Fri, 29 May 2020 10:22:13 -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 8gUXhvpqEoDI; Fri, 29 May 2020 10:22:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E41B3A084D; Fri, 29 May 2020 10:22:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 May 2020 10:22:04 -0700 From: Jim Schaad To: 'Nancy Cam-Winget' , CC: , , References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> In-Reply-To: <159052818935.17307.5095159295288146706@ietfa.amsl.com> Date: Fri, 29 May 2020 10:22:02 -0700 Message-ID: <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFNVp5fEKHTIFH++NxvYlUu0haDFanPMq1A X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 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, 29 May 2020 17:22:13 -0000 Hi Nancy, Comments inline. Jim -----Original Message----- From: Nancy Cam-Winget via Datatracker =20 Sent: Tuesday, May 26, 2020 2:23 PM To: secdir@ietf.org Cc: cose@ietf.org; last-call@ietf.org; = draft-ietf-cose-rfc8152bis-algs.all@ietf.org Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget Review result: Has Nits IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget I have reviewed this document as part of the security = directorate's=C3=8A ongoing effort to review all IETF documents being = processed by the=C3=8A IESG.=C3=8A=C3=8AThese comments were written = primarily for the benefit of the=C3=8A security area = directors.=C3=8A=C3=8ADocument editors and WG chairs should treat=C3=8A = these comments just like any other last call comments. This document describes an initial set of cryptographic algorithms used = to protect CBOR, I believe this document is almost ready, barring some = editorial nits (I only made a few below). In general, the description = of the "initial" set of algorithms used in COSE make sense and it is good to see each = section carry their own security section for better mapping of the = considerations based on the security algorithm applied. As a reader = (like myself) who is not fully versant to the nuances of CBOR it was a = little hard to follow as the structures and taxonomy is described in the = companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think = the document is close to ready, I only noted a few technical and = editorial nits for the earlier sections below: Section 2.1: - What field does the ECDSA algorithm value map to? I presume it is the = 'alg' field (if present)? But should be made explicit. - It seems that the = "should" in the 4th paragraph is normative (e.g. SHOULD) as it is needed for = interoperability, and perhaps even a MUST as I'm not seeing negotiation = or selection of curve choice. So, if it is to be implicit, then a MUST = would be more appropriate. [JLS] I have added text to section 1.3 (terminology) to describe the = contents of the tables to make what the value is clearer. [JLS] There is no need to negotiate the curve as this is implicit from = the size of the signature. That is P-256 is going to end up with two = 256-bit values as the signature. One implication is that only a single = curve of any given length can be assigned to ECDSA, thus the effort to = use the Ed25519 curve with ECDSA requires a different identifier so that = there is no confusion on what curve is being used. This means that the = length of the hash algorithm is not part of this selection process. It = is therefore possible to use SHA-256 with P-521 and SHA-512 with P-256 = (the hash value is truncated in this case). The only issue is that if a = piece of hardware supports the P-256 curve then it might only support = SHA-256 and thus would not be able to validate a signature that uses = SHA-512. There is no special security issue here, this is just a = recommendation for making things more likely to succeed. This is the = reason that it is not a 'SHOULD' or 'MUST' but is an 'suggested'. Does = this both make things clearer and reduce the feeling on you part that a = stronger statement is needed? Section 2.2: - The rationaleThere may be some corner case in which there may be a = very large (2K?) structure to be protected. It would be better to quantify = "extremely large" or perhaps another/additional rationale for the need = to ONLY do Pure edDSA is the intent for constrained devices not have = enough memory to compute the block updates. [JLS] I don't know that I would consider a 2K message to be very large, = I would expect a firmware update to be at least that large. The issue = is that EdDSA needs to do two passes over the message, this means that = the entire message needs to be held in memory. That would be limitation = on what I would consider to be "extremely large". The presumption is = that one is not going to try and create and stream the object out as = this would also require a streaming processing on the recipient. If = streaming is removed from the equation then there is no benefit not to = use Pure EdDSA. This means that ones idea of large is going to be very = device specific. I will not be surprised if some firmware packages do = indirect signing, but the manifest description is still going to need to = fit in memory. Section 4.1.1: - GCM's limitation for one encryption string is 2^39-256 e.g. not "a = single key"....so sufficiently large for COSE! However, it does mean = that the nonce MUST be unique for every encrypted message (e.g. the = bullet before this one is correct). I think the limit for one key using = GCM is based on the size of the nonce as it must be unique. [JLS] You are going to make me look this up again. However I think that = this limit may end up being smaller with more modern analysis so going = back and re--checking this is going to be worthwhile. It just will take = a few days. Section 4.2: - 'k' is the key size in bits (I presume), would be good to describe = that before the table. [JLS] I changed the title of the column to 'Key Length' Editorial nits: Section 1.5 - The second sentence is hard to parse. Is it that the intermediate = values used for debugging are represented in both a hex as well as a = CBOR diagnostic notation format"? - Third sentence, is it that some = examples were designed to fail (e.g. they are "failure test bases")? [JLS] I have updated this section. I think that this should solve your = issues. A GitHub project has been created at = <https://github.com/cose-wg/Examples> that contains a set of = testing examples as well.=20 Each example is found in a JSON file that contains the inputs = used to create the example, some of the intermediate values that can be = used for debugging, and the output of the example. The results are encoded using both hexadecimal and CBOR = diagnostic notation format. Some of the examples are designed to test failure case; these = are clearly marked as such in the JSON file.=20 If errors in the examples in this document are found, the = examples on GitHub will be updated, and a note to that effect will be = placed in the JSON file.=20 Section 2.2: - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may = leave more room for questions; as there may be some corner case in which = there may be a very large (2K?) structure to be protected. For those = that are in the healthcare sector (of IoT), I could see potential for = large blocks and may wonder what qualifies as "extremely large". RFC = 8032 speaks to HashEdDSA as providing better collision resilience...so = am inclined to suggest to either remove this rationale or be more = complete in justification. [JLS] See above. Section 3.1 - 3rd paragraph: "Some recipient algorithms carry the key while others = derive a key from secret data"....I think you mean "Some algorithms are = used to transmit a key, e.g. key wrapping." "Carry the key", in this = sentence leads me to imply it's the same key being used in the HMAC. [JLS] This is the same key that is being used in the HMAC algorithm. I = have changed "carry" to "transport" because I think that is going to be = clearer. From nobody Fri May 29 10:37:57 2020 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 3A0153A0E66; Fri, 29 May 2020 10:37:55 -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 NponiLhT4ePq; Fri, 29 May 2020 10:37:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0CF3A0E6A; Fri, 29 May 2020 10:37:52 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 May 2020 10:37:46 -0700 From: Jim Schaad To: 'Theresa Enghardt' , CC: , , References: <159044129232.11103.11777847473965400673@ietfa.amsl.com> <03c001d63496$786d5c20$69481460$@augustcellars.com> In-Reply-To: Date: Fri, 29 May 2020 10:37:44 -0700 Message-ID: <042001d635df$dec17d90$9c4478b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQItAfBzXC8RKAezc3vFa2i802vvoAJEDJLvAbKkY4qn8enbQA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] [Last-Call] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 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, 29 May 2020 17:37:55 -0000 Merged into the github again. Jim -----Original Message----- From: Theresa Enghardt =20 Sent: Thursday, May 28, 2020 9:24 PM To: Jim Schaad ; gen-art@ietf.org Cc: draft-ietf-cose-rfc8152bis-struct.all@ietf.org; last-call@ietf.org; = cose@ietf.org Subject: Re: [Last-Call] Genart last call review of = draft-ietf-cose-rfc8152bis-struct-09 Hi Jim, Thank you for the responses and text changes. Please find replies to some of your points inline, prefixed with "[TE]". Best, Theresa On 27.05.20 19:19, Jim Schaad wrote: > Major issues: > > The intended RFC status is Internet Standard, while RFC 8152 is a = Proposed Standard. While this document points to three different = implementations, how widespread is their deployment? Were there other = lessons learned from implementation and deployment experience? Has = complexity been reduced by removing unused features, as RFC 6410 = suggests? > > [JLS] This document lists the three most complete implementations of = the document that I know about. I am aware of at least nine different = implementations of the specification. The rest of them implement a = subset of the structures in the document and are not as complete. I am = aware of at least two different places where one of my implementations = has been adapted to work in a different location. I have had several = different jolts where I have learned that COSE is either being used or = is planned to be used in different locations. So yes, I believe that = there are a number of implementations and the usage of parts of COSE are = wide spread. =20 > > [JLS] The only complexity reduction in the document that has been made = is to remove the algorithm descriptions from the document and thus = shortening the structure document from 120 pages to around 80 pages. = The problem with removing any additional items is that some security = feature will no longer be available for applications to use. For that = reason no features have been removed. [TE] I see. I'm excited to hear about IoT security techniques getting = deployed! > Minor issues: > > In the introduction, it would be great to add some more context on how = > COSE is intended to be used. Is this solely for adding security to = objects within CoAP, e.g., by signing and encrypting messages exchanged = as CoAP payload? Or can it be used with other protocols or in other = contexts? In RFC 7165, which describes JOSE use cases, Section 5.8.2 = mentions Object Security for CoAP. Is COSE addressing this use case? If = so, please add a link to Section 5.8.2 of RFC 7165. Section 9.5.4 = mentions that COSE "is designed for a store and forward environment = rather than an online environment". Perhaps it's worth mentioning such = design goals and context in the introduction already. When adding one or = two paragraphs on how COSE is intended to be used to the introduction, = it's also worth stating explicitly that each application is expected to = select the COSE objects and processes that it needs, and that Section 11 = provides more guidance on how to do this. This will make it easier for = application de velopers to understand how to use COSE. > > [JLS] I have added such a paragraph which you can view in the github = version of the document. I did not reference 7165 as you suggested but = went directly to the CoRE solutions using COSE instead. [TE] Thank you for adding this paragraph! I find it very helpful to = better understand the context and use cases of COSE. Found one typo: "[=E2=80=A6] although one can use COSE in and online = protocol [=E2=80=A6]" -> "in an online protocol". [JLS] FIxed > When introducing the CDDL syntaxes: > Is "* label =3D> values" missing here? It appears to be used in some = examples below. > > [JLS] I do not believe that this needs to be introduced in the text. = The section discusses only a part of CDDL that is used in the document = and points to CDDL so that some additional things can be found. The = syntax "label=3D>value" is equivalent to "label: value" but either in a = yet to be defined sense or for something which is not a string or number = as the label. Given that the text is normative it does not worry me = that a complete description of CDDL is not presented here. [TE] Right, I was just wondering if "* label" is similar to "+ label" used in other places. As "[+ FOO]" is introduced in Section 1.4, I was = wondering if [* FOO] has to be introduced as well to be consistent. But = maybe I'm misunderstanding and these are substantially different? [JLS] Your intuition on this is probably right, '+' is one or more '*' = is zero or more. Adding something for '*' does make sense. > In Section 2: > "[...] The wrapping allows for the encoding of the > protected map to be transported with a greater chance that it will > not be altered in transit. (Badly behaved intermediates could > decode and re-encode, but this will result in a failure to verify > unless the re-encoded byte string is identical to the decoded byte > string.) This avoids the problem of all parties needing to be > able to do a common canonical encoding." > I'm not sure I understand this scenario. Does this statement just = apply to zero-length maps or to all kinds of protected buckets? What = does "to be transported with a greater chance" mean here? That = intermediates are less likely to block traffic containing such a COSE = object? That intermediates are less likely to accidentally (or = deliberately) modify it in such a way that it gets accepted by the = receiver? Is this an effect of some cryptographic protection, is it = related to different encoding techniques being used in different = implementations, or both? Why is it a problem if all parties need to be = able to do a common canonical encoding? In fact, what kind of encoding = does this refer to: Binary encoding vs. base64 encoding? Or specific = ways of encoding certain information as binary data? > > [JLS] I think that you mean section 3 if that is not right please let=20 > me know. The wrapping applies to all encoding of protected buckets. = For a zero length bucket this is less of an issue as there is only one = way to encode it per the rules in section 10. The issue is that an = intermediate entity could decode the message, including the map, and = encode it using a slightly different encoding. This normally has to do = with the order of items in the map but could be any number of things as = the rules for deterministic encoding would need to be expanded to cover = all possible CBOR objects rather than just the few that are given in = section 10. If one decodes all the way to the data model of CBOR then = things such as dates become difficult to encode canonically as it could = be encoded either as a floating point number or an integer number. By = doing the wrapping all parties doe NOT need to be able to do a common = canonical encoding. Experience with ASN.1 and the XML signature = security have sh own that the number of times that at least one party = is going to get things wrong is much higher than one would like to see = for a security protocol that wants to be simple and small. Would = starting a new paragraph at this point make it easier to understand that = it is nothing to deal with zero-length maps? [TE] You're right, I meant Section 3. And yes, I think starting a new = paragraph here would make it easier to understand that this is no longer = about the zero-length map. Also, maybe substituting "The wrapping" with = something more general helps, because otherwise I'm wondering which part = of the previous sentence the "The" refers to. Further, I'm wondering if it's worth adding "accidentally" (or similar wording) to the sentence saying that content is transported "with a = greater chance that it will not be altered in transit". As the draft is = about security, when reading this I was thinking about an attacker = altering a message deliberately, but according to your explanation, this = part appears to be more about accidentally altering a message. [JLS] - Ok I will change that. Making it not be deliberate makes = sense and I have changed the "The" to be explicit about what it is = talking about. [JLS] If an attacker changes the message deliberately then you are dead = no matter what. A part of this is left over from the world of S/MIME = where transport agents would do things like change the content transfer = encoding from 8-bit to 7-bit and thus the message was now different. = Not from an attacker, but simply from pulling apart the message looking = at it and putting it back together. There are times when I just feel = too old because of all of the ancient problems that I still remember as = being problems which may longer be ones. Jim From nobody Fri May 29 10:48:54 2020 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 1C7CE3A0E9F; Fri, 29 May 2020 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=f9ycjuDK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dCgukVFb 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 A5JTpo1aYiDD; Fri, 29 May 2020 10:48:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EBC3A0EA1; Fri, 29 May 2020 10:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11558; q=dns/txt; s=iport; t=1590774530; x=1591984130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A0ii+NlApK/PQ0FioT7qJaTz0uTqsQ3XyISgaGdAnao=; b=f9ycjuDKCYmzODpp9wiQGPh7plgxOktIhtYkmHWx++y2Mean+yMI28rn 1sCt3RuXdxiPEUIVNYDSHPLqG1NMyILxToLILm+zlfmqr5CchZwNFw8Hf POWMBVhz/ZJ3IQnaohzK1C0B4a0eu12OlXeLKMWSyKXUCEQTdLKlKbId8 I=; IronPort-PHdr: =?us-ascii?q?9a23=3AkM6JRR2sVNlQogXGsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWEv6dkkVDURpnQ5vZAgvDN9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7bv3Kv9iIZFx?= =?us-ascii?q?H7PBBuYO/yH92ag8G+zevn/ZrVbk1Bjya8ZrUnKhKwoGCz/skbiIdvMOA/0B?= =?us-ascii?q?zM93BJYO9Rg2hvIAGe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQB1StFe/4MNJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFQIy8Hb1gvLAqEG4NGA41CmEmBQoEQA1ULAQE?= =?us-ascii?q?BDAEBHw4CBAEBhEQCF4ILAiQ4EwIDAQELAQEFAQEBAgEGBG2FWQyFcgEBAQE?= =?us-ascii?q?DEhERDAEBNwELBAIBBgIOAwQBAQMCJgICAjAVCAgCBAENBSKDBAGCSwMuAQ6?= =?us-ascii?q?UbJBnAoE5iGF2gTKDAQEBBYVHGIIOAwaBDiqCZIlEHRqCAIERJxyCTT6CZwI?= =?us-ascii?q?CgTsOgy4zgi2Rb49hgSEvkCcKglSIMYtfhFsegmaQaYpFkF2BXogVk30CBAI?= =?us-ascii?q?EBQIOAQEFgWoigVZwFRpLAYI+UBcCDZBACxiDT4pWdDcCBgEHAQEDCXyKGAE?= =?us-ascii?q?mB4EGAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,449,1583193600"; d="scan'208";a="765689458" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 17:48:44 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04THmi8S023176 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 May 2020 17:48:44 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 12:48:44 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 12:48:43 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 29 May 2020 13:48:42 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOib3tlobB8p9ChPSk0W0HgFurO8YInpYRvjczxt4RpanfeLw1aq36cKY14xA3updYHzcieVIdpQ/OY+12YbP1w1MEGhnxn++o4eTHMHxFeG9ZzH61ifUUnrrBnxK/YE34Fy9z16t1LIBAzaSvacw7AJ/seh0lCbbdfpu9K4Ul0eA5CHOSs+J9vAn9JMRXRo6p0RC6tbU2/o3bLlFqYFwnb9izuyFm3CONNapKLcoG4xkfp76HkYn0HX+LZ0edIHHkvlCvlDzwACtgZU238/egLvLpVR9eXqn7CGmeqzthncDL9TRMFAaBje2H2BXRcAGTrtJKXi+uuhHAIyFwyOrA== 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=A0ii+NlApK/PQ0FioT7qJaTz0uTqsQ3XyISgaGdAnao=; b=IJ3Ein1OXRGBxLOJlhI8BHhvBi7ddKOP6IALeZBDg1atxwe2IgiO+QFyppFrk2ZPxNiMJSl9IzWDOrnDcmBzZW4w+OfYMt2l7EltAQrQOmWQGM40g5rnFgq+dMxKcI1E18Ab/WBmDHlfsYPLqrko70BUVz36MtN7oPtNKvHqyfYO+C7+1Dx0rztSehcSf0psz04Nomo2j5qcGOoWIwlVNfQElVhngcYsrgefDMG6h6af1UjYDQ6It8SlLTSQrDg76KKVkic+xeW7HHxxEQ84WmO6gJ6Tdb8gegPMWkygri1+CQr65DrHyhJoiH9iolK1+x00JtKi7Fq3MFSQgP/dyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A0ii+NlApK/PQ0FioT7qJaTz0uTqsQ3XyISgaGdAnao=; b=dCgukVFb0fPy3vTJIxkzstVpDkc+Oz2i1UiDzc9L0y0O9MAliCCGw35GLagNDyX5+rbOPgKytDeTHcmBOGBac8K7C66eEuzX/tL9rJTDb/94O7PKMTE2AfjMny2s/XG4dyiyRcRooRX4enrTEnzrbaiOMG+4DlTGrrywetUI9z0= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.26; Fri, 29 May 2020 17:48:41 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949%6]) with mapi id 15.20.3045.018; Fri, 29 May 2020 17:48:41 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Jim Schaad , "secdir@ietf.org" CC: "cose@ietf.org" , "last-call@ietf.org" , "draft-ietf-cose-rfc8152bis-algs.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Thread-Index: AQHWNd21+VD/kmDL3kuB39KUi65/xqi+4bEA Date: Fri, 29 May 2020 17:48:41 +0000 Message-ID: References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> In-Reply-To: <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.16.200509 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4fc9b105-13ae-4584-2c61-08d803f88695 x-ms-traffictypediagnostic: BY5PR11MB4196: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04180B6720 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ML6RvPDLNrttJoK5Y0MrRRfYC00JE9Siqg0PD5w6r6ZaHrJMcJ8acq/7xeGy29c9SSbEEq+cAWvuCN8Y7YQMIqBqW7zGL5pbzMmnAmhwOtSLg6Y8H2VUhABqd9vJf5q6MjzttL284lQt+jps7VK0RkuUcBP6itdri16alQpIXARxbDJgjI6mFJbYloZE96DNgdjdV3Kg6UPmIRtCGjv5fx2Dv8j03gbgtSEkXT+yXcscWtV9m6yno8OXfwDB5qJq+ZaOfkB2yb98BWpp9xmNy8I4PbpEwc4GrMR8tTjAlmfZJ56sjPXkRuVYmR+impdYFBrWXJpL0hYHXROCTZC+6cLSAK0xUiDH7AaTMpDYEiaUa+WZGl7bzHO4fjSwluaoPLv099BDSG39HaNYvcpWOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(110136005)(316002)(4326008)(54906003)(6506007)(71200400001)(66476007)(64756008)(6512007)(83380400001)(66446008)(36756003)(66556008)(66946007)(76116006)(53546011)(6486002)(2616005)(5660300002)(8676002)(186003)(478600001)(8936002)(33656002)(86362001)(2906002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FROM6qHfucXs+JkWytHYJ7OGMFRUD12EzSUc2npniXcgbpTzTy/GXIXjt32omgGgs62EKrtXd+l1M7O2tvQE6/b2MeTILRRnvKWjA9m1jGhWlguRrUoM8Koqs2vgCP32w5lYwpfPdFRtLyFk8zq4eZa2dwVEDpJRXdQFxF7q4V/a0baCtIbMc5k2/RBwyhBkPdzIDugfP72bNDNcAi/tvEK6u5zNgnScOwv0BdRDvlAPljOGjr/4AkMdgwR6g7avdRh7s0cHoikYQVkyKqq8TLULlVhqAE2K0EwmP+QH4d6Aw3t3kWRRvssNoAkprzsXoauY9nqOx+CGP59ojmkR3sOHxrbQJ3gxhkJD1lkLt8IYj2oRoAE5cmY5DIPebRIB67YWJM7taTtaHJe2rvtth+5UrFqrGWlifNcTMmr7XtP/CI4x2VEzo/A0PKp8WTAPg6TM0nl0lPREEINIuRCeKL7OACS+PvLuY2KBV/RmBSNDxOP0ybb5/NkLYch4Mj4z x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <242D2C4DB280D342885E315D6A7360DA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fc9b105-13ae-4584-2c61-08d803f88695 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 17:48:41.5732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AyrAUOJ+WUOcOwfKMiPo/82sZzMKc1f7w1UEUdMqy8ftc/jNcZTtqs0R05nF5KbjTyS6+S5Q39u/zQBcmbqKrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4196 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 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, 29 May 2020 17:48:52 -0000 SGkgSmltLA0KVGhhbmtzIGZvciBhZGRyZXNzaW5nIHRoZSBjb21tZW50cyEgIEFuc3dlcnMgYmVs b3c6DQoNCu+7v09uIDUvMjkvMjAsIDEwOjIyIEFNLCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0 Y2VsbGFycy5jb20+IHdyb3RlOg0KDQogICAgSGkgTmFuY3ksDQogICAgDQogICAgQ29tbWVudHMg aW5saW5lLg0KICAgIA0KICAgIEppbQ0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQogICAgRnJvbTogTmFuY3kgQ2FtLVdpbmdldCB2aWEgRGF0YXRyYWNrZXIgPG5v cmVwbHlAaWV0Zi5vcmc+IA0KICAgIFNlbnQ6IFR1ZXNkYXksIE1heSAyNiwgMjAyMCAyOjIzIFBN DQogICAgVG86IHNlY2RpckBpZXRmLm9yZw0KICAgIENjOiBjb3NlQGlldGYub3JnOyBsYXN0LWNh bGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MuYWxsQGlldGYub3Jn DQogICAgU3ViamVjdDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3Nl LXJmYzgxNTJiaXMtYWxncy0wOA0KICAgIA0KICAgIFJldmlld2VyOiBOYW5jeSBDYW0tV2luZ2V0 DQogICAgUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICANCiAgICBJT1RESVIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MtMDgNCiAgICANCiAgICBSZXZpZXdlcjog TmFuY3kgQ2FtLVdpbmdldA0KICAgIA0KICAgIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3PDiiBvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGXDiiBJRVNH LsOKw4pUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZp dCBvZiB0aGXDiiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy7DisOKRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdMOKIHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkg b3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgIA0KICAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGFuIGluaXRpYWwgc2V0IG9mIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB1c2VkIHRvIHBy b3RlY3QgQ0JPUiwgSSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgYWxtb3N0IHJlYWR5LCBiYXJy aW5nIHNvbWUgZWRpdG9yaWFsIG5pdHMgKEkgb25seSBtYWRlIGEgZmV3IGJlbG93KS4gIEluIGdl bmVyYWwsIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgImluaXRpYWwiDQogICAgc2V0IG9mIGFsZ29y aXRobXMgdXNlZCBpbiBDT1NFIG1ha2Ugc2Vuc2UgYW5kIGl0IGlzIGdvb2QgdG8gc2VlIGVhY2gg c2VjdGlvbiBjYXJyeSB0aGVpciBvd24gc2VjdXJpdHkgc2VjdGlvbiBmb3IgYmV0dGVyIG1hcHBp bmcgb2YgdGhlIGNvbnNpZGVyYXRpb25zIGJhc2VkIG9uIHRoZSBzZWN1cml0eSBhbGdvcml0aG0g YXBwbGllZC4gIEFzIGEgcmVhZGVyIChsaWtlIG15c2VsZikgd2hvIGlzIG5vdCBmdWxseSB2ZXJz YW50IHRvIHRoZSBudWFuY2VzIG9mIENCT1IgaXQgd2FzIGEgbGl0dGxlIGhhcmQgdG8gZm9sbG93 IGFzIHRoZSBzdHJ1Y3R1cmVzIGFuZCB0YXhvbm9teSBpcyBkZXNjcmliZWQgaW4gdGhlIGNvbXBh bmlvbiBkcmFmdCAoZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtc3RydWN0KS4gQXMgYSB3aG9s ZSwgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgY2xvc2UgdG8gcmVhZHksIEkgb25seSBub3RlZCBh IGZldyB0ZWNobmljYWwgYW5kIGVkaXRvcmlhbCBuaXRzIGZvciB0aGUgZWFybGllciBzZWN0aW9u cyBiZWxvdzoNCiAgICANCiAgICBTZWN0aW9uIDIuMToNCiAgICAtIFdoYXQgZmllbGQgZG9lcyB0 aGUgRUNEU0EgYWxnb3JpdGhtIHZhbHVlIG1hcCB0bz8gSSBwcmVzdW1lIGl0IGlzIHRoZSAnYWxn Jw0KICAgIGZpZWxkIChpZiBwcmVzZW50KT8gQnV0IHNob3VsZCBiZSBtYWRlIGV4cGxpY2l0LiAt IEl0IHNlZW1zIHRoYXQgdGhlICJzaG91bGQiDQogICAgaW4gdGhlIDR0aCBwYXJhZ3JhcGggaXMg bm9ybWF0aXZlIChlLmcuIFNIT1VMRCkgYXMgaXQgaXMgbmVlZGVkIGZvciBpbnRlcm9wZXJhYmls aXR5LCBhbmQgcGVyaGFwcyBldmVuIGEgTVVTVCBhcyBJJ20gbm90IHNlZWluZyBuZWdvdGlhdGlv biBvciBzZWxlY3Rpb24gb2YgY3VydmUgY2hvaWNlLiAgU28sIGlmIGl0IGlzIHRvIGJlIGltcGxp Y2l0LCB0aGVuIGEgTVVTVCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlLg0KICAgIFtKTFNdIEkg aGF2ZSBhZGRlZCB0ZXh0IHRvIHNlY3Rpb24gMS4zICh0ZXJtaW5vbG9neSkgdG8gZGVzY3JpYmUg dGhlIGNvbnRlbnRzIG9mIHRoZSB0YWJsZXMgdG8gbWFrZSB3aGF0IHRoZSB2YWx1ZSBpcyBjbGVh cmVyLg0KW05DV10gVGhhbmtzLCB0aGF0IHdpbGwgaGVscC4NCiAgICANCiAgICBbSkxTXSBUaGVy ZSBpcyBubyBuZWVkIHRvIG5lZ290aWF0ZSB0aGUgY3VydmUgYXMgdGhpcyBpcyBpbXBsaWNpdCBm cm9tIHRoZSBzaXplIG9mIHRoZSBzaWduYXR1cmUuICBUaGF0IGlzIFAtMjU2IGlzIGdvaW5nIHRv IGVuZCB1cCB3aXRoIHR3byAyNTYtYml0IHZhbHVlcyBhcyB0aGUgc2lnbmF0dXJlLiAgT25lIGlt cGxpY2F0aW9uIGlzIHRoYXQgb25seSBhIHNpbmdsZSBjdXJ2ZSBvZiBhbnkgZ2l2ZW4gbGVuZ3Ro IGNhbiBiZSBhc3NpZ25lZCB0byBFQ0RTQSwgdGh1cyB0aGUgZWZmb3J0IHRvIHVzZSB0aGUgRWQy NTUxOSBjdXJ2ZSB3aXRoIEVDRFNBIHJlcXVpcmVzIGEgZGlmZmVyZW50IGlkZW50aWZpZXIgc28g dGhhdCB0aGVyZSBpcyBubyBjb25mdXNpb24gb24gd2hhdCBjdXJ2ZSBpcyBiZWluZyB1c2VkLiAg VGhpcyBtZWFucyB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIGhhc2ggYWxnb3JpdGhtIGlzIG5vdCBw YXJ0IG9mIHRoaXMgc2VsZWN0aW9uIHByb2Nlc3MuICBJdCBpcyB0aGVyZWZvcmUgcG9zc2libGUg dG8gdXNlIFNIQS0yNTYgd2l0aCBQLTUyMSBhbmQgU0hBLTUxMiB3aXRoIFAtMjU2ICh0aGUgaGFz aCB2YWx1ZSBpcyB0cnVuY2F0ZWQgaW4gdGhpcyBjYXNlKS4gIFRoZSBvbmx5IGlzc3VlIGlzIHRo YXQgaWYgYSBwaWVjZSBvZiBoYXJkd2FyZSBzdXBwb3J0cyB0aGUgUC0yNTYgY3VydmUgdGhlbiBp dCBtaWdodCBvbmx5IHN1cHBvcnQgU0hBLTI1NiBhbmQgdGh1cyB3b3VsZCBub3QgYmUgYWJsZSB0 byB2YWxpZGF0ZSBhIHNpZ25hdHVyZSB0aGF0IHVzZXMgU0hBLTUxMi4gIFRoZXJlIGlzIG5vIHNw ZWNpYWwgc2VjdXJpdHkgaXNzdWUgaGVyZSwgdGhpcyBpcyBqdXN0IGEgcmVjb21tZW5kYXRpb24g Zm9yIG1ha2luZyB0aGluZ3MgbW9yZSBsaWtlbHkgdG8gc3VjY2VlZC4gVGhpcyBpcyB0aGUgcmVh c29uIHRoYXQgaXQgaXMgbm90IGEgJ1NIT1VMRCcgb3IgJ01VU1QnIGJ1dCBpcyBhbiAnc3VnZ2Vz dGVkJy4gIERvZXMgdGhpcyBib3RoIG1ha2UgdGhpbmdzIGNsZWFyZXIgYW5kIHJlZHVjZSB0aGUg ZmVlbGluZyBvbiB5b3UgcGFydCB0aGF0IGEgc3Ryb25nZXIgc3RhdGVtZW50IGlzIG5lZWRlZD8N CltOQ1ddIEFncmVlIHRoYXQgdGhlcmUgaXMgbm8gc2VjdXJpdHkgaXNzdWUsIGl0IHdhcyBtb3Jl IG9mIGJyZWFraW5nIGludGVyb3BlcmFiaWxpdHkuICBJIGRvbid0IGZlZWwgc3Ryb25nbHkgZWl0 aGVyIHdheSwgaXQgd2FzIGJ5IHRoZSB3YXkgaXQgcmVhZHMuLi4uaWYgeW91IHdhbnQgdG8gZW5z dXJlIGludGVyb3BlcmFiaWxpdHkgdGhlIGl0IHNlZW1zIHRoYXQgc3Ryb25nZXIgbGFuZ3VhZ2Ug d291bGQgYmUgbmVlZGVkIChidXQgdGhhdOKAmXMgbXkgcGVyc29uYWwgYmlhcykuDQogICAgDQog ICAgU2VjdGlvbiAyLjI6DQogICAgLSBUaGUgcmF0aW9uYWxlVGhlcmUgbWF5IGJlIHNvbWUgY29y bmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJlIGEgdmVyeSBsYXJnZQ0KICAgICgySz8pIHN0 cnVjdHVyZSB0byBiZSBwcm90ZWN0ZWQuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcXVhbnRpZnkg ImV4dHJlbWVseSBsYXJnZSIgb3IgcGVyaGFwcyBhbm90aGVyL2FkZGl0aW9uYWwgcmF0aW9uYWxl IGZvciB0aGUgbmVlZCB0byBPTkxZIGRvIFB1cmUgZWREU0EgaXMgdGhlIGludGVudCBmb3IgY29u c3RyYWluZWQgZGV2aWNlcyBub3QgaGF2ZSBlbm91Z2ggbWVtb3J5IHRvIGNvbXB1dGUgdGhlIGJs b2NrIHVwZGF0ZXMuDQogICAgDQogICAgW0pMU10gSSBkb24ndCBrbm93IHRoYXQgSSB3b3VsZCBj b25zaWRlciBhIDJLIG1lc3NhZ2UgdG8gYmUgdmVyeSBsYXJnZSwgSSB3b3VsZCBleHBlY3QgYSBm aXJtd2FyZSB1cGRhdGUgdG8gYmUgYXQgbGVhc3QgdGhhdCBsYXJnZS4gIFRoZSBpc3N1ZSBpcyB0 aGF0IEVkRFNBIG5lZWRzIHRvIGRvIHR3byBwYXNzZXMgb3ZlciB0aGUgbWVzc2FnZSwgdGhpcyBt ZWFucyB0aGF0IHRoZSBlbnRpcmUgbWVzc2FnZSBuZWVkcyB0byBiZSBoZWxkIGluIG1lbW9yeS4g IFRoYXQgd291bGQgYmUgbGltaXRhdGlvbiBvbiB3aGF0IEkgd291bGQgY29uc2lkZXIgdG8gYmUg ImV4dHJlbWVseSBsYXJnZSIuICBUaGUgcHJlc3VtcHRpb24gaXMgdGhhdCBvbmUgaXMgbm90IGdv aW5nIHRvIHRyeSBhbmQgY3JlYXRlIGFuZCBzdHJlYW0gdGhlIG9iamVjdCBvdXQgYXMgdGhpcyB3 b3VsZCBhbHNvIHJlcXVpcmUgYSBzdHJlYW1pbmcgcHJvY2Vzc2luZyBvbiB0aGUgcmVjaXBpZW50 LiAgSWYgc3RyZWFtaW5nIGlzIHJlbW92ZWQgZnJvbSB0aGUgZXF1YXRpb24gdGhlbiB0aGVyZSBp cyBubyBiZW5lZml0IG5vdCB0byB1c2UgUHVyZSBFZERTQS4gICBUaGlzIG1lYW5zIHRoYXQgb25l cyBpZGVhIG9mIGxhcmdlIGlzIGdvaW5nIHRvIGJlIHZlcnkgZGV2aWNlIHNwZWNpZmljLiAgSSB3 aWxsIG5vdCBiZSBzdXJwcmlzZWQgaWYgc29tZSBmaXJtd2FyZSBwYWNrYWdlcyBkbyBpbmRpcmVj dCBzaWduaW5nLCBidXQgdGhlIG1hbmlmZXN0IGRlc2NyaXB0aW9uIGlzIHN0aWxsIGdvaW5nIHRv IG5lZWQgdG8gZml0IGluIG1lbW9yeS4NCltOQ1ddIDJLYnl0ZXMgY2FuIHNlZW0gdmVyeSBsYXJn ZSB0byBzb21lIElvVCBkZXZpY2VzIF9fLiAgQnV0IHlvdXIgcG9pbnQgaXMgd2VsbCB0YWtlbi4u LnNvcnJ5IGlmIEkgd2FzIHRvbyBuaXQtcGlja3kuLi4uYXMgZm9yIGd1aWRhbmNlIEkgcGVyc29u YWxseSBwcmVmZXIgdG8gaGF2ZSBxdWFudGlmaWNhdGlvbiAocmFuZ2VzKS4NCiAgICANCiAgICBT ZWN0aW9uIDQuMS4xOg0KICAgIC0gR0NNJ3MgbGltaXRhdGlvbiBmb3Igb25lIGVuY3J5cHRpb24g c3RyaW5nIGlzIDJeMzktMjU2IGUuZy4gbm90ICJhIHNpbmdsZSBrZXkiLi4uLnNvIHN1ZmZpY2ll bnRseSBsYXJnZSBmb3IgQ09TRSEgIEhvd2V2ZXIsIGl0IGRvZXMgbWVhbiB0aGF0IHRoZSBub25j ZSBNVVNUIGJlIHVuaXF1ZSBmb3IgZXZlcnkgZW5jcnlwdGVkIG1lc3NhZ2UgKGUuZy4gdGhlIGJ1 bGxldCBiZWZvcmUgdGhpcyBvbmUgaXMgY29ycmVjdCkuICBJIHRoaW5rIHRoZSBsaW1pdCBmb3Ig b25lIGtleSB1c2luZyBHQ00gaXMgYmFzZWQgb24gdGhlIHNpemUgb2YgdGhlIG5vbmNlIGFzIGl0 IG11c3QgYmUgdW5pcXVlLg0KICAgIFtKTFNdIFlvdSBhcmUgZ29pbmcgdG8gbWFrZSBtZSBsb29r IHRoaXMgdXAgYWdhaW4uICBIb3dldmVyIEkgdGhpbmsgdGhhdCB0aGlzIGxpbWl0IG1heSBlbmQg dXAgYmVpbmcgc21hbGxlciB3aXRoIG1vcmUgbW9kZXJuIGFuYWx5c2lzIHNvIGdvaW5nIGJhY2sg YW5kIHJlLS1jaGVja2luZyB0aGlzIGlzIGdvaW5nIHRvIGJlIHdvcnRod2hpbGUuICBJdCBqdXN0 IHdpbGwgdGFrZSBhIGZldyBkYXlzLg0KW05DV10gTm8gd29ycmllcywgYXMgYW4gZWFybHkgYWRv cHRlciBvZiBHQ00sIEkgZG8gcmVjYWxsIHRoYXQgbnVtYmVyIGJlaW5nIGZvciBhIHBhY2tldC4u Li4NCiAgICANCiAgICBTZWN0aW9uIDQuMjoNCiAgICAtICdrJyBpcyB0aGUga2V5IHNpemUgaW4g Yml0cyAoSSBwcmVzdW1lKSwgd291bGQgYmUgZ29vZCB0byBkZXNjcmliZSB0aGF0IGJlZm9yZSB0 aGUgdGFibGUuDQogICAgW0pMU10gSSBjaGFuZ2VkIHRoZSB0aXRsZSBvZiB0aGUgY29sdW1uIHRv ICdLZXkgTGVuZ3RoJw0KW05DV10gVGhhbmtzLg0KICAgIA0KICAgIEVkaXRvcmlhbCBuaXRzOg0K ICAgIFNlY3Rpb24gMS41DQogICAgLSBUaGUgc2Vjb25kIHNlbnRlbmNlIGlzIGhhcmQgdG8gcGFy c2UuICBJcyBpdCB0aGF0IHRoZSBpbnRlcm1lZGlhdGUgdmFsdWVzIHVzZWQgZm9yIGRlYnVnZ2lu ZyBhcmUgcmVwcmVzZW50ZWQgaW4gYm90aCBhIGhleCBhcyB3ZWxsIGFzIGEgQ0JPUiBkaWFnbm9z dGljIG5vdGF0aW9uIGZvcm1hdCI/IC0gVGhpcmQgc2VudGVuY2UsIGlzIGl0IHRoYXQgc29tZSBl eGFtcGxlcyB3ZXJlIGRlc2lnbmVkIHRvIGZhaWwgKGUuZy4gdGhleSBhcmUgImZhaWx1cmUgdGVz dCBiYXNlcyIpPw0KICAgIFtKTFNdICBJIGhhdmUgdXBkYXRlZCB0aGlzIHNlY3Rpb24uICBJIHRo aW5rIHRoYXQgdGhpcyBzaG91bGQgc29sdmUgeW91ciBpc3N1ZXMuDQogICAgICAgICAgICA8dD4N CiAgICAgICAgICAgICAgQSBHaXRIdWIgcHJvamVjdCBoYXMgYmVlbiBjcmVhdGVkIGF0ICZsdDto dHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9FeGFtcGxlcyZndDsgdGhhdCBjb250YWlucyBhIHNl dCBvZiB0ZXN0aW5nIGV4YW1wbGVzIGFzIHdlbGwuIA0KICAgICAgICAgICAgICBFYWNoIGV4YW1w bGUgaXMgZm91bmQgaW4gYSBKU09OIGZpbGUgdGhhdCBjb250YWlucyB0aGUgaW5wdXRzIHVzZWQg dG8gY3JlYXRlIHRoZSBleGFtcGxlLCBzb21lIG9mIHRoZSBpbnRlcm1lZGlhdGUgdmFsdWVzIHRo YXQgY2FuIGJlIHVzZWQgZm9yIGRlYnVnZ2luZywgYW5kIHRoZSBvdXRwdXQgb2YgdGhlIGV4YW1w bGUuDQogICAgICAgICAgICAgIFRoZSByZXN1bHRzIGFyZSBlbmNvZGVkIHVzaW5nIGJvdGggaGV4 YWRlY2ltYWwgYW5kIENCT1IgZGlhZ25vc3RpYyBub3RhdGlvbiBmb3JtYXQuDQogICAgICAgICAg ICA8L3Q+DQogICAgICAgICAgICA8dD4NCiAgICAgICAgICAgICAgU29tZSBvZiB0aGUgZXhhbXBs ZXMgYXJlIGRlc2lnbmVkIHRvIHRlc3QgZmFpbHVyZSBjYXNlOyB0aGVzZSBhcmUgY2xlYXJseSBt YXJrZWQgYXMgc3VjaCBpbiB0aGUgSlNPTiBmaWxlLiANCiAgICAgICAgICAgICAgSWYgZXJyb3Jz IGluIHRoZSBleGFtcGxlcyBpbiB0aGlzIGRvY3VtZW50IGFyZSBmb3VuZCwgdGhlIGV4YW1wbGVz IG9uIEdpdEh1YiB3aWxsIGJlIHVwZGF0ZWQsIGFuZCBhIG5vdGUgdG8gdGhhdCBlZmZlY3Qgd2ls bCBiZSBwbGFjZWQgaW4gdGhlIEpTT04gZmlsZS4gDQogICAgICAgICAgICA8L3Q+DQogICAgW05D V10gVGhhbmsgeW91LCBJIGNhbiBwYXJzZSB0aGlzIGJldHRlci4NCg0KICAgIFNlY3Rpb24gMi4y Og0KICAgIC0gVGhlIHJhdGlvbmFsZSBmb3Igd2h5IFB1cmUgRWREU0EgaXMgdXNlZCBvbmx5ICh2 cy4gSGFzaEVkRFNBKSBtYXkgbGVhdmUgbW9yZSByb29tIGZvciBxdWVzdGlvbnM7IGFzIHRoZXJl IG1heSBiZSBzb21lIGNvcm5lciBjYXNlIGluIHdoaWNoIHRoZXJlIG1heSBiZSBhIHZlcnkgbGFy Z2UgKDJLPykgc3RydWN0dXJlIHRvIGJlIHByb3RlY3RlZC4gIEZvciB0aG9zZSB0aGF0IGFyZSBp biB0aGUgaGVhbHRoY2FyZSBzZWN0b3IgKG9mIElvVCksIEkgY291bGQgc2VlIHBvdGVudGlhbCBm b3IgbGFyZ2UgYmxvY2tzIGFuZCBtYXkgd29uZGVyIHdoYXQgcXVhbGlmaWVzIGFzICJleHRyZW1l bHkgbGFyZ2UiLiAgUkZDIDgwMzIgc3BlYWtzIHRvIEhhc2hFZERTQSBhcyBwcm92aWRpbmcgYmV0 dGVyIGNvbGxpc2lvbiByZXNpbGllbmNlLi4uc28gYW0gaW5jbGluZWQgdG8gc3VnZ2VzdCB0byBl aXRoZXIgcmVtb3ZlIHRoaXMgcmF0aW9uYWxlIG9yIGJlIG1vcmUgY29tcGxldGUgaW4ganVzdGlm aWNhdGlvbi4NCiAgICBbSkxTXSBTZWUgYWJvdmUuDQpbTkNXXSBPSw0KICAgIA0KICAgIFNlY3Rp b24gMy4xDQogICAgLSAzcmQgcGFyYWdyYXBoOiAiU29tZSByZWNpcGllbnQgYWxnb3JpdGhtcyBj YXJyeSB0aGUga2V5IHdoaWxlIG90aGVycyBkZXJpdmUgYSBrZXkgZnJvbSBzZWNyZXQgZGF0YSIu Li4uSSB0aGluayB5b3UgbWVhbiAiU29tZSBhbGdvcml0aG1zIGFyZSB1c2VkIHRvIHRyYW5zbWl0 IGEga2V5LCBlLmcuIGtleSB3cmFwcGluZy4iICAiQ2FycnkgdGhlIGtleSIsIGluIHRoaXMgc2Vu dGVuY2UgbGVhZHMgbWUgdG8gaW1wbHkgaXQncyB0aGUgc2FtZSBrZXkgYmVpbmcgdXNlZCBpbiB0 aGUgSE1BQy4NCiAgICBbSkxTXSAgVGhpcyBpcyB0aGUgc2FtZSBrZXkgdGhhdCBpcyBiZWluZyB1 c2VkIGluIHRoZSBITUFDIGFsZ29yaXRobS4gIEkgaGF2ZSBjaGFuZ2VkICJjYXJyeSIgdG8gInRy YW5zcG9ydCIgYmVjYXVzZSBJIHRoaW5rIHRoYXQgaXMgZ29pbmcgdG8gYmUgY2xlYXJlci4NCltO Q1ddIFllcywgaW5kZWVkLCB0aGF0IG1ha2VzIGl0IGJldHRlci4NCiAgICANCiAgICANCiAgICAN CiAgICANCg0K From nobody Fri May 29 14:37:18 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7583A1117; Fri, 29 May 2020 14:37:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159078822673.26324.15994551016582016082@ietfa.amsl.com> Date: Fri, 29 May 2020 14:37:06 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-04.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 21:37:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-04.txt Pages : 11 Date : 2020-05-29 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-04 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 16:45:38 2020 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 5A9DA3A11F7; Fri, 29 May 2020 16:45: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, 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 b_V87U9Ek5Np; Fri, 29 May 2020 16:45:36 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917B23A11F5; Fri, 29 May 2020 16:45:35 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 May 2020 16:45:30 -0700 From: Jim Schaad To: , References: <159078822673.26324.15994551016582016082@ietfa.amsl.com> In-Reply-To: <159078822673.26324.15994551016582016082@ietfa.amsl.com> Date: Fri, 29 May 2020 16:45:28 -0700 Message-ID: <044f01d63613$3d6a3f20$b83ebd60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIz/8W4axNI+SY4rVAcU8LqawPaMKgEJsqg X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-04.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: Fri, 29 May 2020 23:45:37 -0000 This version is to address the AD and IETF Last Call comments. -----Original Message----- From: COSE On Behalf Of internet-drafts@ietf.org Sent: Friday, May 29, 2020 2:37 PM To: i-d-announce@ietf.org Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-04.txt Pages : 11 Date : 2020-05-29 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-04 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Sat May 30 13:23:53 2020 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 DAA343A0DCE; Sat, 30 May 2020 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=tenghardt.net 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 pUAUu6taVjui; Sat, 30 May 2020 13:23:41 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379973A0DCC; Sat, 30 May 2020 13:23:40 -0700 (PDT) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 5BD679B; Sat, 30 May 2020 22:23:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1590870219; bh=wFkAkuPJ8GpUbyz1bzi27Vf/6Pkz9KZW8KsJ3KcGDlE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LJxaoksYxIvmDMeIj5I6Z65vpI5g7DrH+nLJBVHR04Qh1wdmbUaUURaHtq6RBR+cY 8+NPGElriC0cSLs2h1LRPGlorsp7oT1zPguNQWKDyiSjHhomJ217d7Zc3xNFek8dHW NUfBOaqrB7b8jQCt0r33F4wdxIjuzvz6Q2e3vMNDM/dHSB9ckpq2e0CxHwUsnqIZAA EtDWvPbdl5EXtjayPpGOlFXTpJ0ZzchykqNuq9Zw68uvntsrJiYe5GpYuZNcJ937y6 lrV+hYo4mkgLIz5CBncrABRoGOE3loRTJI6rHqlyoSA71nWDHHh1EGv5+JANvVIA8t NYE23raEDo1mA== To: Jim Schaad , gen-art@ietf.org Cc: draft-ietf-cose-rfc8152bis-struct.all@ietf.org, last-call@ietf.org, cose@ietf.org References: <159044129232.11103.11777847473965400673@ietfa.amsl.com> <03c001d63496$786d5c20$69481460$@augustcellars.com> <042001d635df$dec17d90$9c4478b0$@augustcellars.com> From: Theresa Enghardt Message-ID: <2a1d1b7c-4f4a-171e-7bfe-5e080d525b3d@tenghardt.net> Date: Sat, 30 May 2020 13:23:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <042001d635df$dec17d90$9c4478b0$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [COSE] [Last-Call] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 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, 30 May 2020 20:23:43 -0000 Dear Jim, This resolves all comments that I had. Thank you! Best, Theresa On 29.05.20 10:37, Jim Schaad wrote: > Merged into the github again. > > Jim >