From nobody Fri Dec 4 13:05:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90FC1A8B84; Fri, 4 Dec 2015 13:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0bFWnDbI7_ZE; Fri, 4 Dec 2015 13:05:49 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904BB1A8AEA; Fri, 4 Dec 2015 13:05:48 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 4 Dec 2015 22:05:45 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Fri, 4 Dec 2015 22:05:45 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Kathleen Moriarty Thread-Topic: [COSE] Consensus Call: Adoption of the COSE Token Thread-Index: AQHRGTKb6mzibdroQ0aWbiONihL/Fp6mw9kAgAHRn4CAAEgoAIASjksA Date: Fri, 4 Dec 2015 21:05:45 +0000 Message-ID: References: <7505C89A-FCA1-4AD6-93F6-BDE3517AF1B4@mit.edu> <80EA3B4B-6FF2-42F4-8379-0C5D9E4ADE7A@gmail.com> In-Reply-To: <80EA3B4B-6FF2-42F4-8379-0C5D9E4ADE7A@gmail.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: multipart/alternative; boundary="_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" , "" , Justin Richer , "cose@ietf.org" Subject: Re: [COSE] Consensus Call: Adoption of the COSE Token X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 21:05:52 -0000 --_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgQ0JPUiBX ZWIgVG9rZW4gKENXVCkgdG8gdGhlIEFDRSBXRyByZXBvc2l0b3J5LiBUaGUgbmV3IHZlcnNpb24g cmVmZXJlbmNlcyB0aGUgSldUIGNsYWltcy4gTmFtZSBpcyBhbHNvIGtlcHQgdG8gQ0JPUiBXZWIg VG9rZW4gdG8gbWFrZSBpdCBjbGVhciBpdOKAmXMgZGVyaXZlZCBmcm9tIEpXVCBhbmQgdXNlcyBi b3RoIGNsYWltIG5hbWVzIGFuZCBmb3JtYXRzLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd2FobHN0cm9lbS1hY2UtY2Jvci13ZWItdG9rZW4tMDANCg0KLyBFcmlrLCBNaWtl IGFuZCBIYW5uZXMNCg0KDQpPbiAyMyBOb3YgMjAxNSwgYXQgMDI6NDMsIEthdGhsZWVuIE1vcmlh cnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8sDQoNCkxvb2tpbmcgYWNyb3Nz IHRoZSB0aHJlZSBXR3MsIHRoZXJlIGFyZSBnb29kIGFyZ3VtZW50cyBmb3IgZG9pbmcgdGhlIHdv cmsgaW4gZWFjaCwgYnV0IEFDRSB3b3VsZCBiZSB0aGUgYmVzdCBXRyBmb3IgYSBmZXcgcmVhc29u cy4NCg0KQ09TRSBpcyBzdXBwb3NlZCB0byBiZSBzaG9ydC1saXZlZCwgbGV0J3Mga2VlcCBpdCB0 aGF0IHdheS4NCg0KT0FVVEggaGFzIGEgZnVsbCBwbGF0ZSwgYWx0aG91Z2ggdGhleSB0ZW5kIHRv IGJlIHZlcnkgcHJvZHVjdGl2ZS4NCg0KQUNFIGhhcyBqdXN0IGJlY29tZSBtb3JlIGZvY3VzZWQg YW5kIEkgdGhpbmsgdGhpcyBjb3VsZCBmaXQgd2VsbCBvbmNlIHRoZSBPQVVUSCBzb2x1dGlvbiB3 b3JrIGlzIHVuZGVyd2F5Lg0KDQpUaGVyZSdzIGVub3VnaCBvdmVybGFwIGZvciB0aGlzIHRvIGhh cHBlbiBpbiBhbnkgb2YgdGhlIFdHcy4NCg0KVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgSSB3 YXMgd2FpdGluZyB0byBjaGltZSBpbiB1bnRpbCBpdCB3YXMgaGFzaGVkIG91dCBhIGJpdCB0byBz ZWUgaWYgdGhlcmUgd2FzIGFueSBvdmVyd2hlbG1pbmcgY29uc2Vuc3VzIHdpdGhvdXQgaW5mbHVl bmNpbmcgdGhlIG91dGNvbWUuICBOb3cgdGhhdCBpdCBoYXMgcXVpZXRlZCBkb3duLCBBQ0UgaXMg cHJvYmFibHkgdGhlIGJlc3QgcGxhbi4NCg0KVGhhbmtzLA0KS2F0aGxlZW4NCg0KU2VudCBmcm9t IG15IGlQaG9uZQ0KDQpPbiBOb3YgMjIsIDIwMTUsIGF0IDQ6MjUgUE0sIEVyaWsgV2FobHN0csO2 bSBuZVh1cyA8ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208bWFpbHRvOmVyaWsud2FobHN0 cm9tQG5leHVzZ3JvdXAuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpZZXMsIHdlIGhhdmUgYSBkcmFm dCBwb3N0ZWQgaW4gdGhlIE9BdXRoIFdHIGZvciBhIENCT1IgV2ViIFRva2VuIChDV1QpLiBodHRw czovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9r ZW4tMDAudHh0DQoNCldlIHdhbnQgdG8ga2VlcCBpdCB0aGVyZSBhbmQgcmVmZXJlbmNlIHRoZSBK V1QgY2xhaW1zIChhbHNvIGRlZmluZWQgaW4gT0F1dGggV0cpIGFuZCBsYXRlciBhZGQgYXR0cmli dXRlcyBuZWVkZWQgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGZvciBJb1Qg dG8gSldUL0NXVCBpbiBBQ0UgV0cuDQoNClRoYW5rcw0KRXJpaw0KDQoNCg0KT24gMjEgTm92IDIw MTUsIGF0IDE4OjM5LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQE1JVC5FRFU8bWFpbHRvOmpyaWNo ZXJATUlULkVEVT4+IHdyb3RlOg0KDQpSZWFkaW5nIHRocm91Z2ggdGhlIHRocmVhZHMgYW4gb3Bp bmlvbnMsIHRoZXJlIGlzIG5vIGNsZWFyIGNvbnNlbnN1cyBhcyB0byB3aGVyZSB0aGUgd29yayBz aG91bGQgYmUgZG9uZS4gVGhlcmUgaXMgcm91Z2hseSBlcXVhbCBzdXBwb3J0IGZvciBkb2luZyB0 aGlzIGluIGFueSBvZiB0aGUgdGhyZWUgb2ZmZXJlZCB3b3JraW5nIGdyb3Vwcy4NCg0KVGhlcmUg aXMgY2xlYXIgY29uc2Vuc3VzIHRoYXQgaXQgc2hvdWxkIGJlIGRvbmUgYW5kIHRoYXQsIGFzIG11 Y2ggYXMgcG9zc2libGUsIGl0IHNob3VsZCBiZSBhIGRpcmVjdCBtYXAgb2YgdGhlIGV4aXN0aW5n IEpXVCBwYXlsb2FkIG9iamVjdCBhbmQgY29tbW9uIGNsYWltcy4NCg0KSW4gdGhpcyBsaWdodCwg c29tZW9uZSBuZWVkcyB0byBqdXN0IHN0YXJ0IHRoZSB3b3JrIGFzIGFuIGluZGl2aWR1YWwgZHJh ZnQgYW5kIHB1c2ggZm9yd2FyZCwgYW5kIHdoaWNoZXZlciB3b3JraW5nIGdyb3VwIG1vc3Qgd2Fu dHMgdG8gY2FuIHBpY2sgaXQgdXAgYW5kIHB1Ymxpc2ggaXQuIEkgaGF2ZSBubyBxdWFsbXMgb24g YWNjZXB0aW5nIHRoaXMgd29yayB3aXRoaW4gdGhlIENPU0Ugd29ya2luZyBncm91cCBhbmQgSSBi ZWxpZXZlIHRoZXJlIGlzIGVub3VnaCBzdXBwb3J0IHRvIHdhcnJhbnQgdGhhdCBwbGFjZW1lbnQg aWYgYW4gYXV0aG9yIHN1Ym1pdHMgYSBkcmFmdCBoZXJlIChhbmQgdGhpcyByZW1haW5zIG15IHBy ZWZlcmVuY2UgYXMgYW4gaW5kaXZpZHVhbCksIGJ1dCBJIHdpbGwgbm90IG9iamVjdCB0byBhbm90 aGVyIGdyb3VwIHBpY2tpbmcgaXQgdXAuDQoNCkkgYmVsaWV2ZSwgd2l0aCBhbGwgb2YgdGhlIG92 ZXJsYXAgYmV0d2VlbiBncm91cHMsIHRoYXQgd2Ugd2lsbCBoYXZlIG5vIHRyb3VibGUgZ2V0dGlu ZyB0aGUg4oCccmlnaHQgcGVvcGxl4oCdIHRvIGxvb2sgYXQgaXQuIEFkZGl0aW9uYWxseSwgaXQg aXMgY2xlYXIgdGhhdCBpdCB3aWxsIGJlIHZlcnkgYmVuZWZpY2lhbCB0byBoYXZlIGZvcm1hbCBy ZXZpZXdzIGZyb20gYWxsIHRocmVlIGdyb3VwcyBvbmNlIHRoZSBkcmFmdCBoYXMgcmVhY2hlZCBh IG1hdHVyZSBzdGF0dXMuDQoNClRoYW5rZnVsbHksIEVyaWsgaGFzIGFscmVhZHkgZG9uZSB0aGlz IHdpdGggaGlzIOKAnENPU0UgV2ViIFRva2Vu4oCdIGRyYWZ0LiBIZeKAmXMgaW5pdGlhbGx5IHRh cmdldGVkIHRoaXMgYXQgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIGFuZCB0aGUgd29yayBzdGFy dGVkIGluIEFDRSwgc28gSSBjYWxsIHRvIHRoZSBhdXRob3IgdG8gcGljayBhIGxvY2F0aW9uIGFu ZCBydW4gd2l0aCBpdC4NCg0K4oCUIEp1c3RpbiwgeW91ciBDT1NFIGNoYWlyDQoNCk9uIE5vdiA3 LCAyMDE1LCBhdCAzOjAxIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQE1JVC5FRFU8bWFpbHRv OmpyaWNoZXJATUlULkVEVT4+IHdyb3RlOg0KDQpBdCB0aGUgWW9rb2hhbWEgbWVldGluZywgdGhl IGNoYWlycyBhZ3JlZWQgdG8gZG8gYSBjb25zZW5zdXMgY2FsbCByZWdhcmRpbmcgdGhlIGFkb3B0 aW9uIGFuZCBwbGFjZW1lbnQgb2YgbmV3IHdvcmsgdG8gZGVmaW5lIGEgQ09TRSBUb2tlbiwgYW5h bG9nb3VzIHRvIHRoZSBKV1QgZnJvbSBKT1NFLiBJbiB0aGUgcm9vbSwgdGhlcmUgd2FzIGEgZ2Vu ZXJhbCBzZW50aW1lbnQgb2Ygc3VwcG9ydCBmb3IgdGhlIHdvcmsgYmVpbmcgZG9uZSwgd2l0aCB0 aGUgd2lkZSBhZG9wdGlvbiBvZiBKV1QgYW5kIGl0cyBkcml2aW5nIG9mIEpPU0UgYmVpbmcgYSBj b21tb24gdGhlbWUgb2YgcHJlY2VkZW50LiBXaGF0IHdhc27igJl0IGNsZWFyIGlzIHdoZXJlIHRo ZSB3b3JrIHNob3VsZCBiZSBkb25lIGFuZCB0byB3aGF0IGVuZCBpdCBzaG91bGQgZHJpdmUuIFRo ZSBzaXggcG9zaXRpb25zIHdlIGFyZSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lk ZXIgYW5kIHZvaWNlIHRoZWlyIHN1cHBvcnQgZm9yIGFyZToNCg0KQSkgRGVmaW5lIHRoZSBDT1NF IFRva2VuIHdpdGhpbiB0aGUgQ09TRSB3b3JraW5nIGdyb3VwIGFsb25nIHNpZGUgdGhlIENPU0Ug TWVzc2FnZXMgKGFuZCBwb3RlbnRpYWxseSBDT1NFIEF1eGlsaWFyeSBBbGdvcml0aG1zKSBkcmFm dC4NCkIpIERlZmluZSB0aGUgQ09TRSBUb2tlbiBpbnNpZGUgdGhlIE9BdXRoIHdvcmtpbmcgZ3Jv dXAuDQpDKSBEZWZpbmUgdGhlIENPU0UgVG9rZW4gaW5zaWRlIHRoZSBBQ0Ugd29ya2luZyBncm91 cC4NCkQpIERvbuKAmXQgZGVmaW5lIHRoZSBDT1NFIFRva2VuIGFueXdoZXJlLg0KRSkgWW91IG5l ZWQgbW9yZSBpbmZvcm1hdGlvbiB0byBkZWNpZGUuDQpGKSBZb3UgZG9u4oCZdCBnaXZlIGEgZmx5 aW5nIHJhdCBhYm91dCB0aGUgQ09TRSBUb2tlbi4qDQoNClRoZSBjb25zZW5zdXMgY2FsbCB3aWxs IHJlbWFpbiBvcGVuIGZvciB0d28gd2Vla3MgZnJvbSB0b2RheSwgY2xvc2luZyBvbiBOb3ZlbWJl ciAyMSwgMjAxNTsgYXQgd2hpY2ggdGltZSwgaG9wZWZ1bGx5IHdlIHdpbGwgaGF2ZSBhIGNsZWFy IGFuc3dlciBhbmQgZGlyZWN0aW9uIHRvIHBvaW50IHRoaXMgd29yay4NCg0KVGhhbmsgeW91LA0K 4oCUIEp1c3RpbiAmIEtlcGVuZywgeW91ciBDT1NFIGNoYWlycw0KDQoqIEkgcHJvbWlzZWQgdGhv c2UgaW4gdGhlIHJvb20gYXQgWW9rb2hhbWEgdG8gb2ZmZXIgYSBmbHlpbmcgcmF0IG9wdGlvbiwg Zm9yIHdoaWNoIEkgYW0gZGVlcGx5IHNvcnJ5Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkNPU0UgbWFpbGluZyBsaXN0DQpDT1NFQGlldGYub3JnPG1h aWx0bzpDT1NFQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3NlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDT1NFIG1haWxpbmcgbGlzdA0KQ09TRUBpZXRmLm9yZzxtYWlsdG86Q09TRUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QN CkNPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg0K --_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: <48B9DE0308B3B44BBD95A5DD3A6B879B@nexusgroup.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldl IGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgQ0JPUiBXZWIgVG9rZW4g KENXVCkgdG8gdGhlIEFDRSBXRyByZXBvc2l0b3J5LiBUaGUgbmV3IHZlcnNpb24gcmVmZXJlbmNl cyB0aGUgSldUIGNsYWltcy4gTmFtZSBpcyBhbHNvIGtlcHQgdG8gQ0JPUiBXZWIgVG9rZW4gdG8g bWFrZSBpdCBjbGVhciBpdOKAmXMgZGVyaXZlZCBmcm9tIEpXVCBhbmQgdXNlcyBib3RoIGNsYWlt IG5hbWVzIGFuZCBmb3JtYXRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdhaGxzdHJvZW0tYWNlLWNib3Itd2ViLXRva2VuLTAwIiBjbGFzcz0iIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1hY2UtY2Jvci13ZWItdG9rZW4t MDA8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4vIEVyaWssIE1pa2UgYW5kIEhhbm5lczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMjMgTm92IDIwMTUsIGF0IDAyOjQz LCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5 LmlldGZAZ21haWwuY29tIiBjbGFzcz0iIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPkhlbGxvLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+TG9va2luZyBhY3Jvc3MgdGhlIHRocmVlIFdHcywgdGhlcmUgYXJlIGdv b2QgYXJndW1lbnRzIGZvciBkb2luZyB0aGUgd29yayBpbiBlYWNoLCBidXQgQUNFIHdvdWxkIGJl IHRoZSBiZXN0IFdHIGZvciBhIGZldyByZWFzb25zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q09TRSBpcyBzdXBwb3NlZCB0byBiZSBz aG9ydC1saXZlZCwgbGV0J3Mga2VlcCBpdCB0aGF0IHdheS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9BVVRIIGhhcyBhIGZ1bGwgcGxh dGUsIGFsdGhvdWdoIHRoZXkgdGVuZCB0byBiZSB2ZXJ5IHByb2R1Y3RpdmUuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BQ0UgaGFzIGp1 c3QgYmVjb21lIG1vcmUgZm9jdXNlZCBhbmQgSSB0aGluayB0aGlzIGNvdWxkIGZpdCB3ZWxsIG9u Y2UgdGhlIE9BVVRIIHNvbHV0aW9uIHdvcmsgaXMgdW5kZXJ3YXkuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSdzIGVub3VnaCBv dmVybGFwIGZvciB0aGlzIHRvIGhhcHBlbiBpbiBhbnkgb2YgdGhlIFdHcy48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3Ig dGhlIGRpc2N1c3Npb24sIEkgd2FzIHdhaXRpbmcgdG8gY2hpbWUgaW4gdW50aWwgaXQgd2FzIGhh c2hlZCBvdXQgYSBiaXQgdG8gc2VlIGlmIHRoZXJlIHdhcyBhbnkgb3ZlcndoZWxtaW5nIGNvbnNl bnN1cyB3aXRob3V0IGluZmx1ZW5jaW5nIHRoZSBvdXRjb21lLiAmbmJzcDtOb3cgdGhhdCBpdCBo YXMgcXVpZXRlZCBkb3duLCBBQ0UgaXMgcHJvYmFibHkgdGhlIGJlc3QgcGxhbi48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+S2F0aGxlZW4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpTZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCk9uIE5vdiAyMiwgMjAxNSwgYXQgNDoyNSBQTSwgRXJpayBXYWhsc3Ryw7ZtIG5lWHVz ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb20iIGNsYXNz PSIiPmVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+SGksDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5ZZXMsIHdlIGhhdmUgYSBkcmFmdCBwb3N0ZWQgaW4gdGhlIE9B dXRoIFdHIGZvciBhIENCT1IgV2ViIFRva2VuIChDV1QpLiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0w MC50eHQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9l bS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQ8L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSB3YW50IHRvIGtlZXAg aXQgdGhlcmUgYW5kIHJlZmVyZW5jZSB0aGUgSldUIGNsYWltcyAoYWxzbyBkZWZpbmVkIGluIE9B dXRoIFdHKSBhbmQgbGF0ZXIgYWRkIGF0dHJpYnV0ZXMgbmVlZGVkIGZvciBhdXRoZW50aWNhdGlv biBhbmQgYXV0aG9yaXphdGlvbiBmb3IgSW9UIHRvIEpXVC9DV1QgaW4gQUNFIFdHLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtz PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVyaWs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDIxIE5vdiAyMDE1LCBhdCAxODozOSwg SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJATUlULkVEVSIgY2xhc3M9 IiI+anJpY2hlckBNSVQuRURVPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5SZWFkaW5nIHRocm91Z2ggdGhl IHRocmVhZHMgYW4gb3BpbmlvbnMsIHRoZXJlIGlzIG5vIGNsZWFyIGNvbnNlbnN1cyBhcyB0byB3 aGVyZSB0aGUgd29yayBzaG91bGQgYmUgZG9uZS4gVGhlcmUgaXMgcm91Z2hseSBlcXVhbCBzdXBw b3J0IGZvciBkb2luZyB0aGlzIGluIGFueSBvZiB0aGUgdGhyZWUgb2ZmZXJlZCB3b3JraW5nIGdy b3Vwcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBpcyBjbGVhciBjb25zZW5z dXMgdGhhdCBpdCBzaG91bGQgYmUgZG9uZSBhbmQgdGhhdCwgYXMgbXVjaCBhcyBwb3NzaWJsZSwg aXQgc2hvdWxkIGJlIGEgZGlyZWN0IG1hcCBvZiB0aGUgZXhpc3RpbmcgSldUIHBheWxvYWQgb2Jq ZWN0IGFuZCBjb21tb24gY2xhaW1zLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4g dGhpcyBsaWdodCwgc29tZW9uZSBuZWVkcyB0byBqdXN0IHN0YXJ0IHRoZSB3b3JrIGFzIGFuIGlu ZGl2aWR1YWwgZHJhZnQgYW5kIHB1c2ggZm9yd2FyZCwgYW5kIHdoaWNoZXZlciB3b3JraW5nIGdy b3VwIG1vc3Qgd2FudHMgdG8gY2FuIHBpY2sgaXQgdXAgYW5kIHB1Ymxpc2ggaXQuIEkgaGF2ZSBu byBxdWFsbXMgb24gYWNjZXB0aW5nIHRoaXMgd29yayB3aXRoaW4gdGhlIENPU0Ugd29ya2luZyBn cm91cCBhbmQgSSBiZWxpZXZlIHRoZXJlIGlzDQogZW5vdWdoIHN1cHBvcnQgdG8gd2FycmFudCB0 aGF0IHBsYWNlbWVudCBpZiBhbiBhdXRob3Igc3VibWl0cyBhIGRyYWZ0IGhlcmUgKGFuZCB0aGlz IHJlbWFpbnMgbXkgcHJlZmVyZW5jZSBhcyBhbiBpbmRpdmlkdWFsKSwgYnV0IEkgd2lsbCBub3Qg b2JqZWN0IHRvIGFub3RoZXIgZ3JvdXAgcGlja2luZyBpdCB1cC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJIGJlbGlldmUsIHdpdGggYWxsIG9mIHRoZSBvdmVybGFwIGJldHdlZW4gZ3Jv dXBzLCB0aGF0IHdlIHdpbGwgaGF2ZSBubyB0cm91YmxlIGdldHRpbmcgdGhlIOKAnHJpZ2h0IHBl b3BsZeKAnSB0byBsb29rIGF0IGl0LiBBZGRpdGlvbmFsbHksIGl0IGlzIGNsZWFyIHRoYXQgaXQg d2lsbCBiZSB2ZXJ5IGJlbmVmaWNpYWwgdG8gaGF2ZSBmb3JtYWwgcmV2aWV3cyBmcm9tIGFsbCB0 aHJlZSBncm91cHMgb25jZSB0aGUgZHJhZnQgaGFzIHJlYWNoZWQgYSBtYXR1cmUNCiBzdGF0dXMu IDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rZnVsbHksIEVyaWsgaGFzIGFscmVh ZHkgZG9uZSB0aGlzIHdpdGggaGlzIOKAnENPU0UgV2ViIFRva2Vu4oCdIGRyYWZ0LiBIZeKAmXMg aW5pdGlhbGx5IHRhcmdldGVkIHRoaXMgYXQgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIGFuZCB0 aGUgd29yayBzdGFydGVkIGluIEFDRSwgc28gSSBjYWxsIHRvIHRoZSBhdXRob3IgdG8gcGljayBh IGxvY2F0aW9uIGFuZCBydW4gd2l0aCBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQri gJQgSnVzdGluLCB5b3VyIENPU0UgY2hhaXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBOb3YgNywgMjAxNSwgYXQgMzowMSBB TSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJATUlULkVEVSIgY2xh c3M9IiI+anJpY2hlckBNSVQuRURVPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KQXQgdGhlIFlva29oYW1hIG1lZXRpbmcsIHRoZSBjaGFpcnMgYWdyZWVkIHRvIGRv IGEgY29uc2Vuc3VzIGNhbGwgcmVnYXJkaW5nIHRoZSBhZG9wdGlvbiBhbmQgcGxhY2VtZW50IG9m IG5ldyB3b3JrIHRvIGRlZmluZSBhIENPU0UgVG9rZW4sIGFuYWxvZ291cyB0byB0aGUgSldUIGZy b20gSk9TRS4gSW4gdGhlIHJvb20sIHRoZXJlIHdhcyBhIGdlbmVyYWwgc2VudGltZW50IG9mIHN1 cHBvcnQgZm9yIHRoZSB3b3JrIGJlaW5nIGRvbmUsIHdpdGggdGhlDQogd2lkZSBhZG9wdGlvbiBv ZiBKV1QgYW5kIGl0cyBkcml2aW5nIG9mIEpPU0UgYmVpbmcgYSBjb21tb24gdGhlbWUgb2YgcHJl Y2VkZW50LiBXaGF0IHdhc27igJl0IGNsZWFyIGlzIHdoZXJlIHRoZSB3b3JrIHNob3VsZCBiZSBk b25lIGFuZCB0byB3aGF0IGVuZCBpdCBzaG91bGQgZHJpdmUuIFRoZSBzaXggcG9zaXRpb25zIHdl IGFyZSBhc2tpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgYW5kIHZvaWNlIHRoZWly IHN1cHBvcnQgZm9yIGFyZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBKSBEZWZpbmUg dGhlIENPU0UgVG9rZW4gd2l0aGluIHRoZSBDT1NFIHdvcmtpbmcgZ3JvdXAgYWxvbmcgc2lkZSB0 aGUgQ09TRSBNZXNzYWdlcyAoYW5kIHBvdGVudGlhbGx5IENPU0UgQXV4aWxpYXJ5IEFsZ29yaXRo bXMpIGRyYWZ0LjxiciBjbGFzcz0iIj4NCkIpIERlZmluZSB0aGUgQ09TRSBUb2tlbiBpbnNpZGUg dGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuPGJyIGNsYXNzPSIiPg0KQykgRGVmaW5lIHRoZSBDT1NF IFRva2VuIGluc2lkZSB0aGUgQUNFIHdvcmtpbmcgZ3JvdXAuPGJyIGNsYXNzPSIiPg0KRCkgRG9u 4oCZdCBkZWZpbmUgdGhlIENPU0UgVG9rZW4gYW55d2hlcmUuPGJyIGNsYXNzPSIiPg0KRSkgWW91 IG5lZWQgbW9yZSBpbmZvcm1hdGlvbiB0byBkZWNpZGUuPGJyIGNsYXNzPSIiPg0KRikgWW91IGRv buKAmXQgZ2l2ZSBhIGZseWluZyByYXQgYWJvdXQgdGhlIENPU0UgVG9rZW4uKjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoZSBjb25zZW5zdXMgY2FsbCB3aWxsIHJlbWFpbiBvcGVuIGZv ciB0d28gd2Vla3MgZnJvbSB0b2RheSwgY2xvc2luZyBvbiBOb3ZlbWJlciAyMSwgMjAxNTsgYXQg d2hpY2ggdGltZSwgaG9wZWZ1bGx5IHdlIHdpbGwgaGF2ZSBhIGNsZWFyIGFuc3dlciBhbmQgZGly ZWN0aW9uIHRvIHBvaW50IHRoaXMgd29yay48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGFuayB5b3UsPGJyIGNsYXNzPSIiPg0K4oCUIEp1c3RpbiAmYW1wOyBLZXBlbmcsIHlvdXIgQ09T RSBjaGFpcnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIEkgcHJvbWlzZWQgdGhvc2Ug aW4gdGhlIHJvb20gYXQgWW9rb2hhbWEgdG8gb2ZmZXIgYSBmbHlpbmcgcmF0IG9wdGlvbiwgZm9y IHdoaWNoIEkgYW0gZGVlcGx5IHNvcnJ5LjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQ09TRSBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyIgY2xhc3M9 IiI+Q09TRUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29zZTwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCkNPU0UgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciIGNsYXNzPSIiPkNPU0VAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3NlIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv c2U8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPHNwYW4gY2xhc3M9IiI+Q09TRSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciIGNsYXNzPSIiPkNP U0VAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZSIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C1C044D142DA443DB97243CFF444733Bnexusgroupcom_-- From nobody Fri Dec 4 17:41:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795A81A1A9D for ; Fri, 4 Dec 2015 17:41:21 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 UQe6WGUbxYl9 for ; Fri, 4 Dec 2015 17:41:19 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0F11A1A7D for ; Fri, 4 Dec 2015 17:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GYQjxXz4tI+FqhwkjZbHWZInOzJN04zomhsOrUQMMJc=; b=eXFodGFtkwo543t8Z3Ov3Twn4J+g2fGYVBqRRhiTLWJXB7pM9X7vLIbYLYxofUS8qGGPNfwLG8SF/JqZRO/4P6gaJghWI0OLlZIM3Qma680dOe3h3ANAYw1VrFH+ybO07WiKC5rjnPIjsF7IRFV6OPVf113riqHq8JmIy4jdK1Y= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 5 Dec 2015 01:41:13 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 5 Dec 2015 01:41:13 +0000 From: Mike Jones To: Justin Richer , "cose@ietf.org" Thread-Topic: [COSE] COSE Issues Thread-Index: AQHRK4QE3ynUHFYEHkSAjELBbL/27Z67nufg Date: Sat, 5 Dec 2015 01:41:13 +0000 Message-ID: References: <831C610E-2326-4D70-A48C-77BA8A7D2369@mit.edu> In-Reply-To: <831C610E-2326-4D70-A48C-77BA8A7D2369@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:OsDZHcT9/NHDuT9XKVRMqFm3SLTG/ZlpjyY3BwfaLNW/t/XI8NSgR3juvX4SNCbctDKGxKGrhg+9xLX2qpLS5njyrDETvWMHZOUUfz+JKm1E/SJgXVYlFdaNPn34aryv1zlXqyhY6z+c5xAvsDUIWA==; 24:hfUT+dESj8s0+GVEjx2SwjNClYZPip0CnIk/Xy+dv68j/ktYcLp/tSpCVzaJ8jNgqHggrFncrEFJnwuf544XPgk3ocImQLZvALskg1zuaHs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(31014005)(199003)(189002)(13464003)(97736004)(19580395003)(11100500001)(2950100001)(77096005)(19617315012)(110136002)(50986999)(101416001)(2171001)(33656002)(106356001)(5001770100001)(105586002)(189998001)(106116001)(87936001)(54356999)(76176999)(8990500004)(5002640100001)(15975445007)(81156007)(19580405001)(19300405004)(10090500001)(99286002)(5001960100002)(74316001)(76576001)(92566002)(40100003)(2900100001)(1096002)(5003600100002)(16236675004)(107886002)(86612001)(5005710100001)(2501003)(19625215002)(5008740100001)(5004730100002)(86362001)(10400500002)(1220700001)(790700001)(6116002)(102836003)(10290500002)(586003)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4427E5C1D9BD2DC384501E4F50B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2015 01:41:13.3166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [COSE] COSE Issues X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 01:41:21 -0000 --_000_BY2PR03MB4427E5C1D9BD2DC384501E4F50B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEppbSwgZm9yIHdvcmtpbmcgdGhlc2UgaXNzdWVzLiAgSSBhbSBjb250ZW50IHdpdGgg bW9zdCBvZiB0aGUgcmVzb2x1dGlvbnMuDQoNCg0KSSBtYWRlIGNvbW1lbnRzIG9uIHRoZSBmb2xs b3dpbmcgdGhyZWUgaXNzdWVzLCByZXF1ZXN0aW5nIHRoYXQgdGhleSBiZSByZW9wZW5lZCwgc2lu Y2UgdGhlIGFjdGlvbnMgdGFrZW4gdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgd2VyZSBub3QgY2xl YXI6DQoNCsK3ICAgICAgICAgRWxhYm9yYXRlIG9uIOKAnGlmIGl0IGlzIG5vdCB1c2VkIGluIHRo ZSBjb21wdXRhdGlvbiBvZiB0aGUgY29udGVudCBrZXnigJ0gIzM1PGh0dHBzOi8vZ2l0aHViLmNv bS9jb3NlLXdnL2Nvc2UtaXNzdWVzL2lzc3Vlcy8zNT4NCg0KwrcgICAgICAgICBJcyBhIOKAnGRp cmVjdCBrZXnigJ0gc2VudCBpbiB0aGUgY2xlYXI/ICMzNjxodHRwczovL2dpdGh1Yi5jb20vY29z ZS13Zy9jb3NlLWlzc3Vlcy9pc3N1ZXMvMzY+DQoNCsK3ICAgICAgICAgUmVxdWlyZSBwdWJsaWNs eSB2aXNpYmxlIHN0YWJsZSBzcGVjaWZpY2F0aW9ucyBmb3IgSUFOQSByZWdpc3RyYXRpb25zICMz OTxodHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9jb3NlLWlzc3Vlcy9pc3N1ZXMvMzk+DQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCg0KDQpQLlMuICBNeSBhcG9sb2dpZXMgdG8gdGhlIHdvcmtpbmcgZ3Jv dXAgZm9yIG15IGJlaW5nIHRhcmR5IGluIHJldmlld2luZyB0aGVzZSByZXNvbHV0aW9ucy4gIEni gJl2ZSBoYWQgYW4gZXh0cmVtZWx5IGZ1bGwgcGxhdGUgdGhlIGxhc3QgZmV3IHdlZWtzLCBpbmNs dWRpbmcgcmV2aXNpbmcgSk9TRSBhbmQgT0F1dGggZHJhZnRzIHRvIGdldCB0aGVtIHJlYWR5IGZv ciBJRVRGIHJldmlldyBpbiB0aW1lIGZvciB0aGUgdGVsZWNoYXQgb24gRGVjZW1iZXIgMTd0aCwg d29ya2luZyBvbiBkcmFmdC13YWhsc3Ryb2VtLWFjZS1jYm9yLXdlYi10b2tlbiBhbmQgZHJhZnQt am9uZXMtb2F1dGgtZGlzY292ZXJ5LCBhbmQgdGFraW5nIHRpbWUgb2ZmIGZvciB0aGUgVVMgVGhh bmtzZ2l2aW5nIGhvbGlkYXkg4pi6Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IENPU0UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK dXN0aW4gUmljaGVyDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDMwLCAyMDE1IDc6MzAgQU0NClRv OiBjb3NlQGlldGYub3JnDQpTdWJqZWN0OiBbQ09TRV0gQ09TRSBJc3N1ZXMNCg0KDQoNCkhhdmlu ZyBoZWFyZCBubyBjb21wbGFpbnRzIG9uIHRoZSBsYXRlc3QgY2hhbmdlIHNldCwgdGhlIGNoYWly cyBhcmUgY2xvc2luZyBhbGwgaXNzdWVzIG1hcmtlZCBhcyDigJxjb21wbGV0ZWTigJ0gdG9kYXku IFlvdSBzaG91bGQgc2VlIG1vc3Qgb2YgdGhlIG5vdGlmaWNhdGlvbnMgcGVwcGVyIHRocm91Z2gg dG8gdGhlIGxpc3Qgc2hvcnRseSAodGhvdWdoIG91ciBnaXRodWIgaW50ZWdyYXRpb24gaXMgc3Bl Y2lhbCBhdCBiZXN0KS4gSWYgeW91IGJlbGlldmUgYW55IG9mIHRoZXNlIGlzc3VlcyBpcyBpbiBu ZWVkIG9mIHJlLWV4YW1pbmF0aW9uLCB3ZSBjYW4gYWx3YXlzIHJlLW9wZW4gdGhlbSBvciB5b3Ug Y2FuIGZpbGUgYSBuZXcgaXNzdWUgYWdhaW5zdCB0aGUgY3VycmVudCBkb2N1bWVudC4NCg0KDQoN ClRoYW5rIHlvdSBhbGwsDQoNCuKAlCBKdXN0aW4sIHlvdXIgQ09TRSBjaGFpcg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDT1NFIG1haWxpbmcg bGlzdA0KDQpDT1NFQGlldGYub3JnPG1haWx0bzpDT1NFQGlldGYub3JnPg0KDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg== --_000_BY2PR03MB4427E5C1D9BD2DC384501E4F50B0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5U ZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWlu IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uanMtaXNzdWUtdGl0 bGUNCgl7bXNvLXN0eWxlLW5hbWU6anMtaXNzdWUtdGl0bGU7fQ0Kc3Bhbi5naC1oZWFkZXItbnVt YmVyMQ0KCXttc28tc3R5bGUtbmFtZTpnaC1oZWFkZXItbnVtYmVyMTsNCgljb2xvcjojQUFBQUFB Ow0KCWxldHRlci1zcGFjaW5nOi0uNzVwdDsNCglmb250LXdlaWdodDpub3JtYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjEwMzE2MDcwODc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjExOTA3MjE3NjIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgSmlt LCBmb3Igd29ya2luZyB0aGVzZSBpc3N1ZXMuJm5ic3A7IEkgYW0gY29udGVudCB3aXRoIG1vc3Qg b2YgdGhlIHJlc29sdXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1hZGUgY29t bWVudHMgb24gdGhlIGZvbGxvd2luZyB0aHJlZSBpc3N1ZXMsIHJlcXVlc3RpbmcgdGhhdCB0aGV5 IGJlIHJlb3BlbmVkLCBzaW5jZSB0aGUgYWN0aW9ucyB0YWtlbiB0byBhZGRyZXNzIHRoZXNlIGlz c3VlcyB3ZXJlIG5vdCBjbGVhcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g Y2xhc3M9ImpzLWlzc3VlLXRpdGxlIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkVsYWJv cmF0ZSBvbiDigJxpZiBpdCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNv bnRlbnQga2V54oCdPC9zcGFuPjwvYj48L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMz Ij4NCjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImdoLWhlYWRlci1udW1iZXIxIj48Yj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9jb3NlLWlzc3Vlcy9pc3N1 ZXMvMzUiPiMzNTwvYT48L3NwYW4+PC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gY2xhc3M9ImpzLWlzc3VlLXRpdGxlIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMz MzMzMzMiPklzIGEg4oCcZGlyZWN0IGtleeKAnSBzZW50IGluIHRoZSBjbGVhcj88L3NwYW4+PC9i Pjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPg0KPC9zcGFuPjwvYj48c3BhbiBj bGFzcz0iZ2gtaGVhZGVyLW51bWJlcjEiPjxiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9jb3NlLXdnL2Nvc2UtaXNzdWVzL2lzc3Vlcy8zNiI+IzM2PC9hPjwvc3Bhbj48 L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBjbGFzcz0ianMt aXNzdWUtdGl0bGUiPjxiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+UmVxdWlyZSBwdWJsaWNs eSB2aXNpYmxlIHN0YWJsZSBzcGVjaWZpY2F0aW9ucyBmb3IgSUFOQSByZWdpc3RyYXRpb25zPC9z cGFuPjwvYj48L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4NCjwvc3Bhbj48L2I+ PHNwYW4gY2xhc3M9ImdoLWhlYWRlci1udW1iZXIxIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9jb3NlLWlzc3Vlcy9pc3N1ZXMvMzkiPiMzOTwvYT48 L3NwYW4+PC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UC5TLiZuYnNwOyBNeSBhcG9sb2dpZXMgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgZm9yIG15IGJl aW5nIHRhcmR5IGluIHJldmlld2luZyB0aGVzZSByZXNvbHV0aW9ucy4mbmJzcDsgSeKAmXZlIGhh ZCBhbiBleHRyZW1lbHkgZnVsbCBwbGF0ZSB0aGUgbGFzdCBmZXcgd2Vla3MsIGluY2x1ZGluZyBy ZXZpc2luZyBKT1NFIGFuZCBPQXV0aCBkcmFmdHMgdG8gZ2V0IHRoZW0gcmVhZHkgZm9yIElFVEYg cmV2aWV3IGluIHRpbWUgZm9yIHRoZQ0KIHRlbGVjaGF0IG9uIERlY2VtYmVyIDE3PHN1cD50aDwv c3VwPiwgd29ya2luZyBvbiBkcmFmdC13YWhsc3Ryb2VtLWFjZS1jYm9yLXdlYi10b2tlbiBhbmQg ZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LCBhbmQgdGFraW5nIHRpbWUgb2ZmIGZvciB0aGUg VVMgVGhhbmtzZ2l2aW5nIGhvbGlkYXkNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGlu Z3MiPko8L3NwYW4+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IENPU0UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyPGJyPg0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAzMCwgMjAxNSA3OjMwIEFNPGJyPg0KVG86IGNvc2VAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBb Q09TRV0gQ09TRSBJc3N1ZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhhdmluZyBoZWFyZCBubyBjb21w bGFpbnRzIG9uIHRoZSBsYXRlc3QgY2hhbmdlIHNldCwgdGhlIGNoYWlycyBhcmUgY2xvc2luZyBh bGwgaXNzdWVzIG1hcmtlZCBhcyDigJxjb21wbGV0ZWTigJ0gdG9kYXkuIFlvdSBzaG91bGQgc2Vl IG1vc3Qgb2YgdGhlIG5vdGlmaWNhdGlvbnMgcGVwcGVyIHRocm91Z2ggdG8gdGhlIGxpc3Qgc2hv cnRseSAodGhvdWdoIG91ciBnaXRodWIgaW50ZWdyYXRpb24gaXMgc3BlY2lhbA0KIGF0IGJlc3Qp LiBJZiB5b3UgYmVsaWV2ZSBhbnkgb2YgdGhlc2UgaXNzdWVzIGlzIGluIG5lZWQgb2YgcmUtZXhh bWluYXRpb24sIHdlIGNhbiBhbHdheXMgcmUtb3BlbiB0aGVtIG9yIHlvdSBjYW4gZmlsZSBhIG5l dyBpc3N1ZSBhZ2FpbnN0IHRoZSBjdXJyZW50IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UaGFuayB5b3UgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+4oCUIEp1c3RpbiwgeW91ciBDT1NFIGNoYWlyPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09TRSBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhy ZWY9Im1haWx0bzpDT1NFQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+Q09TRUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Nvc2U8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_BY2PR03MB4427E5C1D9BD2DC384501E4F50B0BY2PR03MB442namprd_-- From nobody Fri Dec 4 17:54:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C601B354F for ; Fri, 4 Dec 2015 17:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 keBEEZaTxTM4 for ; Fri, 4 Dec 2015 17:54:15 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBC31B354E for ; Fri, 4 Dec 2015 17:54:15 -0800 (PST) Date: Fri, 04 Dec 2015 17:54:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449280454; bh=Zb17oRYia1s5hUoXL8dru+DoNFOgRndj4G+gGdXabQk=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=gKdHfxKebtSZilQYgVmVGWG/at+BC/A8Ur7vQSHmqinvdur1umU+3M9tTQs+KEGx9 z6NSo1WApdAxv/1Oqz0EMY/MVTlhuO5/I0EGx9VDWasqmy74vEt4JIw+SnV5lUaBUz TyMTaxgWklNaufDhrvkiSwS4GwmyxN4EHLqrjtHk= From: Mike Jones To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566243c64deee_60003f8394d952b822943"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] =?utf-8?q?=5Bcose-issues=5D_Additional_inconsistency_betwe?= =?utf-8?b?ZW4g4oCcbm9uZeKAnSBhbmQg4oCcZGlyZWN04oCdIHRlcm1pbm9sb2d5ICgj?= =?utf-8?b?NDQp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 01:54:17 -0000 ----==_mimepart_566243c64deee_60003f8394d952b822943 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Issue #29 was incompletely addressed. Some instances of "none" were changed to "direct" but some others were not. Section 12.4.1 (ECDH) of draft -08 says "The key wrap algorithm can be 'none'" - rather than saying that the key wrap algorithm can be direct. Table 17 also contains several remaining uses of "none". --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/44 ----==_mimepart_566243c64deee_60003f8394d952b822943 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Issue #29 was incompletely address= ed. Some instances of "none" were changed to "direct" but some others we= re not.

Section 12.4.1 (ECDH) of draft -08 says "The key wrap algorithm can be= 'none'" - rather than saying that the key wrap algorithm can be direct. = Table 17 also contains several remaining uses of "none".

&m= dash;
Reply to this email directly or view it on GitHub.3D""

----==_mimepart_566243c64deee_60003f8394d952b822943-- From nobody Fri Dec 4 17:59:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A028C1B355F for ; Fri, 4 Dec 2015 17:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 5ghoAbBpgZy8 for ; Fri, 4 Dec 2015 17:59:15 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBA11B355B for ; Fri, 4 Dec 2015 17:59:15 -0800 (PST) Date: Fri, 04 Dec 2015 17:59:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449280754; bh=2L8S3+QohDjXTt5EPmpsdMO7QTshkR5Yc8fdkHWj7MA=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=MRVJ+Wm+eVMOxuFOhRNwJMpp8vwjDbxSSaUObax1pMR4tdg3ldrvnkIn160BBbVlW Te2owD1EL2Zlkcto+9y4i6XRJNCKMy20ZMXAjl1ePB/9huASGgozzifq4fHN6Cm1wg 6Gc0tcdrhmP55GUpfJ9ZsLiY/1XqVvq1VBKuyyxU= From: Mike Jones To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566244f2539fb_2fb53f8f77f3f2a01690b2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] "y > 0" should be "y >= 0" (#45) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 01:59:16 -0000 ----==_mimepart_566244f2539fb_2fb53f8f77f3f2a01690b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Section 13.1.1 (Double Coordinate Curves) of draft -08 contains this text: When encoding the sign of y, the expression 'y > 0' is evaluated and encoded a CBOR boolean. Given that the sign bit of a zero value is 0, I suspect that should actually be "y >= 0" so that it evaluates to true for all values with a zero sign bit. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/45 ----==_mimepart_566244f2539fb_2fb53f8f77f3f2a01690b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Section 13.1.1 (Double Coordinate Curves) of draft -08 contains this text:
When encoding the sign of y, the expression 'y > 0' is evaluated and encoded a CBOR boolean.

Given that the sign bit of a zero value is 0, I suspect that should actually be "y >= 0" so that it evaluates to true for all values with a zero sign bit.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_566244f2539fb_2fb53f8f77f3f2a01690b2-- From nobody Fri Dec 4 18:02:43 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4C1B356A for ; Fri, 4 Dec 2015 18:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 yCtKz-4R4CgT for ; Fri, 4 Dec 2015 18:02:40 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDFE1B3565 for ; Fri, 4 Dec 2015 18:02:40 -0800 (PST) Date: Fri, 04 Dec 2015 18:02:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449280959; bh=DOZsr8TaezE/cSAv7irMU9hZ9Hu49A39XguoLUWmwcE=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=2cHGUJ2IE6cgp5LPLAnWcm7sJ68QCc6MIN6WyCsZIQ6LxVVG15LVcX/ZTDuKhw9ll zC2Ax6clfUGKL1m1sgjeGaITiNLrqU80d5jIHHDfrvwP8U/hcvE1Voh34XgSrL2GtW TjeU8y2qH38d5lc1breFkNcMs+o2UaiYhfkdySGQ= From: Mike Jones To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566245bfafb21_60043f8394d952b81178a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Should the type of Partial IV be bstr like IV, rather than uint? (#46) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 02:02:41 -0000 ----==_mimepart_566245bfafb21_60043f8394d952b81178a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In Table 1 of draft -08, the type of IV is bstr, whereas the type of Partial IV is uint. Is there a reason for this inconsistency, or should it also be bstr? Or given that the use of Partial IV is application specific, should any type desired by the application be allowed for its value? --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/46 ----==_mimepart_566245bfafb21_60043f8394d952b81178a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

In Table 1 of draft -08, the type of IV is bstr, whereas the type of Partial IV is uint. Is there a reason for this inconsistency, or should it also be bstr?

Or given that the use of Partial IV is application specific, should any type desired by the application be allowed for its value?

—
Reply to this email directly or view it on GitHub.

----==_mimepart_566245bfafb21_60043f8394d952b81178a-- From nobody Fri Dec 4 18:04:32 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF21B3573 for ; Fri, 4 Dec 2015 18:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 4T2tVjMicsU7 for ; Fri, 4 Dec 2015 18:04:29 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920711B3572 for ; Fri, 4 Dec 2015 18:04:29 -0800 (PST) Date: Fri, 04 Dec 2015 18:04:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449281068; bh=3OdJFCXLKnmmbEXSSCRai2Txadwx9NADd8SiZFXnjN4=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=sbEXAemW6qseexTo+jcHy8REwQToLelvaaqJKwwmp0wtT3Py3IQpFubrozkCFGF6a n7tQsev+H34UWH4OHq02ymVgyofcBCE1Qhquxt4rlgh202UKlll0NZKYwyve66pfuG nJ9bq3vowD5RwQ5t2QA5c0YO0InFRaQwEzb3Gm5w= From: Mike Jones To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5662462cda704_39933fcf059932c01861dc"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Add an example showing the use of Partial IV (#47) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 02:04:31 -0000 ----==_mimepart_5662462cda704_39933fcf059932c01861dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It would be useful to developers to have an example showing the intended of use of Partial IV. In particular, please describe how the example Partial IV value is combined with other value(s) and then used in the cryptographic computation. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/47 ----==_mimepart_5662462cda704_39933fcf059932c01861dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

It would be useful to developers to have an example showing the intended of use of Partial IV. In particular, please describe how the example Partial IV value is combined with other value(s) and then used in the cryptographic computation.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5662462cda704_39933fcf059932c01861dc-- From nobody Fri Dec 4 18:07:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A283E1B357C for ; Fri, 4 Dec 2015 18:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 GiUp3dW_8z9h for ; Fri, 4 Dec 2015 18:07:46 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABD71B357F for ; Fri, 4 Dec 2015 18:07:46 -0800 (PST) Date: Fri, 04 Dec 2015 18:07:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449281265; bh=FOoJ8Ey2ZYl/8Tty3UkuLnP3bphbK0qUGa3tbq0uY8Q=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=I2wPPOSE7jR+UQyfOCbqBnnZQiqLFsGKgqOEf95KDCwKQMUVGyEO8mnFwX86d/20N midInGDh1hos4ML/YlqV166QbkPPuGtFFHXsL6lwMDYiOKWDqrhQqgs5gJMXbuduyg BUVg4rA4BOoWAmL05lRM7+y2xLFVghqaXGNg+pyw= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566246f1bd4b1_6a273ff9892692c025406d"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBJcyBhIOKAnGRpcmVjdCBrZXnigJ0g?= =?utf-8?q?sent_in_the_clear=3F_=28=2336=29?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 02:07:47 -0000 ----==_mimepart_566246f1bd4b1_6a273ff9892692c025406d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit s/supplied/identified/ --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/36#issuecomment-162130485 ----==_mimepart_566246f1bd4b1_6a273ff9892692c025406d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

s/supplied/identified/

—
Reply to this email directly or view it on GitHub.

----==_mimepart_566246f1bd4b1_6a273ff9892692c025406d-- From nobody Fri Dec 4 18:16:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6001B35A4 for ; Fri, 4 Dec 2015 18:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 pZpPcte4hyLp for ; Fri, 4 Dec 2015 18:16:15 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBD21B35A3 for ; Fri, 4 Dec 2015 18:16:15 -0800 (PST) Date: Fri, 04 Dec 2015 18:16:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449281774; bh=/adyZHGBfh7mxyqSvHbYMKwJkQ+xL9ZOAcexeim46/E=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=nHG4eTMT67U6bXHCUASFDTuyEQlYL1J6JFcc0BStq/L1Z0GG1mMVyycfktiH8ZXMy 2AgIpnQOUjgQCvQfCxShTgR7rGMRMPNklDh4d9nvO5BOzFQJXBIF9+CvP3u2xoJMGr EihXcCE55oqtKt1r159O0toHmwH5PplUu1vUdvXs= From: Mike Jones To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566248ee6daab_16573f919de3d2bc39357d"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 02:16:17 -0000 ----==_mimepart_566248ee6daab_16573f919de3d2bc39357d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The external_aad feature is one not found in JOSE, CMS, XMLDSIG, or other commonly used cryptographic formats. While I am satisfied with the resolution of issue #16 keeping this feature because of the discussions about the CoAP use cases that occurred in Yokohama, I still would like to see the common case that doesn't use it simplified. Currently, the sig_structure contains [ body_protected, sign_protected, external_aad, payload ]. I request that this be reordered to [ body_protected, sign_protected, payload, external_aad ] and the external_aad array element be specified to be not present when no external_aad value is supplied, so that in the no-external_aad case, the sig_structure value becomes [ body_protected, sign_protected, payload ]. It's no harder for the code to omit it than to include a zero-length binary value, as currently specified. And the code still signs the whole array - it's just that the array can have either 4 or 3 elements. Similarly, please revise the hmac_structure and enc_structure, placing external_aad at the end and making its presence optional. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/48 ----==_mimepart_566248ee6daab_16573f919de3d2bc39357d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

The external_aad feature is one not found in JOSE, CMS, XMLDSIG, or other commonly used cryptographic formats. While I am satisfied with the resolution of issue #16 keeping this feature because of the discussions about the CoAP use cases that occurred in Yokohama, I still would like to see the common case that doesn't use it simplified.

Currently, the sig_structure contains [ body_protected, sign_protected, external_aad, payload ]. I request that this be reordered to [ body_protected, sign_protected, payload, external_aad ] and the external_aad array element be specified to be not present when no external_aad value is supplied, so that in the no-external_aad case, the sig_structure value becomes [ body_protected, sign_protected, payload ]. It's no harder for the code to omit it than to include a zero-length binary value, as currently specified. And the code still signs the whole array - it's just that the array can have either 4 or 3 elements.

Similarly, please revise the hmac_structure and enc_structure, placing external_aad at the end and making its presence optional.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_566248ee6daab_16573f919de3d2bc39357d-- From nobody Fri Dec 4 18:22:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE981B35B8 for ; Fri, 4 Dec 2015 18:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 gPAs_rDRvGuw for ; Fri, 4 Dec 2015 18:22:14 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008EA1B35B7 for ; Fri, 4 Dec 2015 18:22:13 -0800 (PST) Date: Fri, 04 Dec 2015 18:22:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449282133; bh=ViqEvObSPfHbKeaPBbZcYTHiaL2GzUFpmoW2doj5Kus=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zVMv/KWcrRVg51SLmBucYJWhrhNIOATCGn05UWWWznaFmdHUn43QJZ4W1y/saCi+h jIsB+ipGFt3DW96VFI3OrryjUuD+cepcfYCMyIMD+M50ZaWLNEIkGIApWj0jDuRTjx yrZR3TYqt/3qRCHlHNKRnfr+iCguF5AW6p+QRWUY= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56624a5551287_5ff33f8394d952b861018f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] "y > 0" should be "y >= 0" (#45) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 02:22:15 -0000 ----==_mimepart_56624a5551287_5ff33f8394d952b861018f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I need to find the correct reference, but I believe that if y is zero then you have a bad point. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/45#issuecomment-162132436 ----==_mimepart_56624a5551287_5ff33f8394d952b861018f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I need to find the correct reference, but I believe that if y is zero then you have a bad point.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56624a5551287_5ff33f8394d952b861018f-- From nobody Fri Dec 4 19:51:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB931B3715 for ; Fri, 4 Dec 2015 19:51:01 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wbG6QEH_fnZO for ; Fri, 4 Dec 2015 19:50:58 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6921B2F5C for ; Fri, 4 Dec 2015 19:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2E8KL2kTD2xYYCoDX6NefxyK0kf0O5NEjmalveMRaTc=; b=MV1nQ4XBKRPcYG1jKSlicHuBX60eP5net55inxOo2oof7UGG0Oyvq6AjCKJf5wq6bMZ8pXEOQexG7iq2lNEE80IsfxPM9XsXvDWMd50Ckm5854KSCnd7o6pGJtXKQHFP/5Yo8e40B7xAmwwbYHOM8QFkTryJf01A9BRMECwclEg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 5 Dec 2015 03:50:39 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 5 Dec 2015 03:50:39 +0000 From: Mike Jones To: "'cose@ietf.org'" Thread-Topic: CBOR Web Token (CWT) spec for the ACE working group Thread-Index: AdEvDD/qhV0xKgF3TQ+OV37TSTGCSwAA7iNQ Date: Sat, 5 Dec 2015 03:50:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:r3UZqPsrjFzr19SryqkUJMsqKJE+BAXdbJpO4y3qTzmKPcpx8pqxKtYyCKn9JUpl4MOyxqsN7XiBJU4iZXJ4UKp9Rodf0vUNMo+wwJrzTxvfIQA9niJ8Gm8+5muA2PkNA2NhusM+dA379BRH9R62tw==; 24:7SjETaPBnpn+ObxesuRd7DzLsSwA4axNj3oLFJdd8s1teN3B2Fupapl/vDZm0Tqnf+17M7ItJqRjziVfW+sPqsufStIRN0oI24qiLmTaJ9A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(199003)(377454003)(189002)(1220700001)(19617315012)(189998001)(5002640100001)(54356999)(19580405001)(19580395003)(40100003)(16236675004)(106356001)(5005710100001)(10090500001)(87936001)(33656002)(122556002)(50986999)(76576001)(5003600100002)(8990500004)(86612001)(110136002)(11100500001)(5001960100002)(19300405004)(1096002)(5008740100001)(15975445007)(10290500002)(97736004)(86362001)(5004730100002)(77096005)(10400500002)(81156007)(450100001)(102836003)(92566002)(99286002)(107886002)(105586002)(101416001)(74316001)(6116002)(19625215002)(586003)(790700001)(2900100001)(3826002)(491001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442B727F98ED6E15F1FDA10F50B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2015 03:50:39.3069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [COSE] FW: CBOR Web Token (CWT) spec for the ACE working group X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 03:51:01 -0000 --_000_BY2PR03MB442B727F98ED6E15F1FDA10F50B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Per https://github.com/cose-wg/cose-issues/issues/42#issuecomment-158829660= by Kathleen... From: Mike Jones Sent: Friday, December 4, 2015 7:47 PM To: ace@ietf.org Subject: CBOR Web Token (CWT) spec for the ACE working group After input from many interested people, IETF Security Area Director Kathle= en Moriarty decided that the right place for the CBOR Web Token (CWT) work is the ACE= working group. Today Erik Wa= hlstr=F6m posted a new draft of the CBOR Web Token (CWT) specification that= is intended for ACE. This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and in= tentionally only includes equivalents of the claims defined by the JWT spec= . Other CWT claims, including those needed by ACE applications, will be de= fined by other specs and registered in the CWT claims registry. The specification is available at: =B7 http://tools.ietf.org/html/draft-wahlstroem-ace-cbor-web-token-= 00 An HTML-formatted version is also available at: =B7 http://self-issued.info/docs/draft-wahlstroem-ace-cbor-web-toke= n-00.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1503 and as= @selfissued. --_000_BY2PR03MB442B727F98ED6E15F1FDA10F50B0BY2PR03MB442namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Per https://github.com/cose-wg/cose-issues/issues/42#issuecomment-1= 58829660 by Kathleen…

 

From: Mike Jones
Sent: Friday, December 4, 2015 7:47 PM
To: ace@ietf.org
Subject: CBOR Web Token (CWT) spec for the ACE working group

 

After input from many interested people, IETF Securi= ty Area Director Kathleen Moriarty decided that the right place for the CBOR Web Token = (CWT) work is the ACE working group.  Today Erik Wahlstr=F6m posted a new draft of the CBOR Web Token (= CWT) specification that is intended for ACE.

 

This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and= intentionally only includes equivalents of the claims defined by the JWT s= pec.  Other CWT claims, including those needed by ACE applications, wi= ll be defined by other specs and registered in the CWT claims registry.

 

The specification is available at:

=B7         http://tools.ietf.org/html/= draft-wahlstroem-ace-cbor-web-token-00

 

An HTML-formatted version is also available at:=

=B7         http://self-issued.i= nfo/docs/draft-wahlstroem-ace-cbor-web-token-00.html<= /p>

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1503 and as @selfissued.

--_000_BY2PR03MB442B727F98ED6E15F1FDA10F50B0BY2PR03MB442namprd_-- From nobody Sun Dec 6 18:01:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F90C1A92B6 for ; Sun, 6 Dec 2015 18:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 1YbC6k7X67lH for ; Sun, 6 Dec 2015 18:01:17 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E1E1A92B5 for ; Sun, 6 Dec 2015 18:01:17 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 958A52CA0E; Sun, 6 Dec 2015 18:01:16 -0800 (PST) From: "Jim Schaad" To: "'Justin Richer'" References: <04e901d119ad$3207bea0$96173be0$@augustcellars.com> <564ECB3C.1070203@mit.edu> <064001d127b1$f9e2a590$eda7f0b0$@augustcellars.com> <98AFE54A-11BC-49FC-87BE-99A5A3760777@mit.edu> In-Reply-To: <98AFE54A-11BC-49FC-87BE-99A5A3760777@mit.edu> Date: Sun, 6 Dec 2015 17:58:30 -0800 Message-ID: <014f01d13092$c5b818b0$51284a10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIfvpSiX18QdRwxvFtmOBjrli/sGAGil9hXAsxqyvUB88P2AgI43rprAbsHM/2dzuzBoA== Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] MAC with no recipient structures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 02:01:19 -0000 > -----Original Message----- > From: Justin Richer [mailto:jricher@mit.edu] > Sent: Wednesday, November 25, 2015 11:04 AM > To: Jim Schaad > Cc: Francesca Palombini ; = cose@ietf.org > Subject: Re: [COSE] MAC with no recipient structures >=20 > (As an individual) >=20 > Speaking from my own experience with JOSE, the simplicity and utility = of MAC- > only cannot be denied. I can only see this being compounded in = constrained > environments. Decrypting payload means I need to keep two copies of = the data > around, I need to manage encryption state, and I need to solve issues = with > multiple recipients or components that need just read access. All of = these go > away with simple signatures or MACs without losing functionality or = security. > Security is always contextual in the application, and complexity is = the enemy of > getting security actually applied in a system. I would not agree with some of these points. I do believe that MAC has a large utility and is not going to be = removed. =20 I do not necessarily agree that it has a larger amount of utility over = encryption in a constrained environment. One of the big advantages of = using CTR modes of encryption is that encrypting in place is even easier = than it is with any version that does padding. This means that one does = not necessarily need to have two copies of the data around. =20 It is true that there is some additional data that needs to be managed = when doing encryption rather than a MAC. It is not clear that there is = a significant amount of data that needs to be managed. If one assumes = that some type of replay counter is maintained in both cases, then this = additional data amounts to an IV prefix which is constant and thus has = minimal maintenance associated with it. (I.e. it needs to be kept and = associated with the key.) The issues dealing with allowing multiple recipients or components that = just need read access is an interesting question to be addressed, and = one that points to the question that I keep asking. Does that other = entity that needs read access need to have the ability to know that the = data is correct? If the entity needs to be able to validate the = information, then using MACs or using encryption have the exact same = level of complexity for dealing with multiple recipients and multiple = keys. There is a difference between doing "simple signatures" and the = MAC/encryption case because how key management is done is completely = different. The expected security properties of are very different = between the signature and the MAC case as well. Finally, I would point out that the total security system is not = necessarily the same for a constrained and an unconstrained system. = OAuth as it is commonly used today is sending MAC messages using TLS. = The fact that TLS is being used means that, from a security analysis, = the only parties that would have read access to the MAC message are the = parties at each end of the TLS connection. One does not end up in = situations (or at least I am assuming that one does not) where there are = proxies that are going to be between these entities that also have = access to the data. This is not the case many times for a DTLS = situation in the constrained environments that are being contemplated = where provisions are being made for doing things like TLS<=3D>DTLS = proxies, proxies that mediate between different sub-networks and so = forth are expected components to be dealt with. The security system = and the analysis associated with it can be very different between the = OpenID case and the access granting case of a CoAP network. >=20 > I see absolutely zero reason to not support this simplified case, and = others have > made it clear it=E2=80=99s desirable for their use cases. I think the = burden is on you (Jim) > to prove that it=E2=80=99s not desirable, and I=E2=80=99m not = personally seeing support for that > position in this working group. So other than the OSCoAP people, who have a use case that they are = planning to use this for? I am hearing a lot of people saying that they = need it because that is what JOSE does. I am not hearing a lot of = people saying that they have a concrete use case for it. I do not = expect that COSE is going to replace JOSE for general JWT usage. Jim >=20 > =E2=80=94 Justin (as an individual, remember) >=20 > > On Nov 25, 2015, at 1:49 PM, Jim Schaad = wrote: > > > > Again, let me ask the question. Are you willing to be in a position > > where the tenant reads and acts on an incorrect data value since it > > cannot validate the MAC on the data. > > > >> -----Original Message----- > >> From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] > >> Sent: Wednesday, November 25, 2015 6:43 AM > >> To: Mike Jones ; Jim Schaad > >> ; cose@ietf.org > >> Subject: RE: [COSE] MAC with no recipient structures > >> > >> Hi, > >> > >> In the context of "visibility" another use case was mentioned = before(*): > >> electricity consumption is measured by a meter, forwarded to a > >> gateway > > where > >> the tenant reads the consumption and further to the distribution = operator. > > The > >> communication between meter and gateway, and gateway and network is > >> protected on transport layer; and between meter and network on > >> application layer, using COSE. Encryption of the COSE message does > >> not allow the > > tenant to > >> read the metering. > >> > >> Multiple recipients here are not necessary and, for optimization > >> reasons, > > the > >> COSE message should be able to omit the recipient structure > >> (analogously > > to the > >> COSE_Encrypted structure). > >> > >> (*) > >> = https://mailarchive.ietf.org/arch/msg/core/hmIcl0WIceg26h5clQ4Qv4kcfG > >> k > >> > >> Francesca > >> > >> -----Original Message----- > >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones > >> Sent: den 21 november 2015 20:54 > >> To: Justin Richer; Jim Schaad; cose@ietf.org > >> Subject: Re: [COSE] MAC with no recipient structures > >> > >> As a point of clarification, this thread wasn't about removing MAC. > >> It > > was about > >> adding a MAC representation with no explicit recipient - the > >> equivalent of > > the > >> JWS example in http://tools.ietf.org/html/rfc7515#section-3.3. > >> > >> This feature request is tracked as https://github.com/cose-wg/cose- > >> issues/issues/10 - Make "recipients" field optional. > >> > >> -- Mike > >> > >> -----Original Message----- > >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin = Richer > >> Sent: Thursday, November 19, 2015 11:27 PM > >> To: Jim Schaad ; cose@ietf.org > >> Subject: Re: [COSE] MAC with no recipient structures > >> > >> What I'm hearing from this thread is a lot of support for plain MAC > > structures, > >> including several documented use cases. Not the least of which is > >> mapping > > to > >> JOSE's HS* algorithm suite in JWS, one of the two most-used and = most- > >> successful portions of JOSE to date. > >> > >> Consequently, I'm not seeing any consensus to drop plain MAC = support > >> in > > favor > >> of any other method. I'm also not seeing opposition to defining = AEAD > > structures > >> in addition to MAC structures in COSE and allowing applications to = choose. > >> > >> Therefore, we'll keep MAC in place until there's sufficient = consensus > >> to > > remove > >> the capability from COSE. > >> > >> Thank you, > >> -- Justin, your COSE chair. > >> > >> On 11/7/2015 5:39 PM, Jim Schaad wrote: > >>> People keep telling me that they want to have a version of MACs = that > >>> do not have a set of recipient information attached so that they = can > >>> do direct MACs. I keep asking for a use case where this makes = sense. > >>> In all of the use cases that I have been presented so far, a = better > >>> answer is going to be to do an AEAD encrypted item rather than a > >>> MACed > >> item. > >>> > >>> The scenario that wants this is going to be: > >>> > >>> Alice sends data to Bob in such a way that Bob can authenticate = the > > data. > >>> Eve needs to be able to read the data in transit, without knowing = if > >>> the message contains data or misinformation and will act on the > >>> message as if it were data. > >>> > >>> The difference in message size between MAC and Encryption is going > >>> to be minimal, at most a few bytes. The execution difference is > >>> going to be a few extra encryption operations. > >>> > >>> What use cases exist for this where encryption is not a better > >>> security answer anyway. > >>> > >>> Jim > >>> > >>> > >>> _______________________________________________ > >>> COSE mailing list > >>> COSE@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cose > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Dec 7 09:28:05 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BAD1ACF1A for ; Mon, 7 Dec 2015 09:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 gmi9XmM0rX0U for ; Mon, 7 Dec 2015 09:27:58 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A023E1ACF6C for ; Mon, 7 Dec 2015 09:27:58 -0800 (PST) Date: Mon, 07 Dec 2015 09:27:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449509277; bh=SBgj/aBH29c1+quwb15Mfx9eA+ipCtCzvZXI0WcbXSI=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=XtPhxG5g4Jy+BRE+c6UQZfxFtgbth4s3XYOMIYChlhTnmuH3QTu2O6vMa/YryiA9F XEjXKJVdqTWrRfZDqSGTgoCRDD1hJIFnGSib1w2zWp8/HGedBL1UuvI6jNG8lFH1am 0qUL/9DYnViCl/1R16b9Pchxqu7LD59zJh61SoU4= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5665c19d6926e_20b73f8a22ff52bc11163b6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Allocate references to normative and informative (#49) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 17:28:04 -0000 ----==_mimepart_5665c19d6926e_20b73f8a22ff52bc11163b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Need to make a final determination on the informative and normative references before WGLC --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/49 ----==_mimepart_5665c19d6926e_20b73f8a22ff52bc11163b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Need to make a final determination on the informative and normative references before WGLC

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5665c19d6926e_20b73f8a22ff52bc11163b6-- From nobody Mon Dec 7 09:29:14 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C381F1AD05E for ; Mon, 7 Dec 2015 09:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 VlzdXIsU1kE3 for ; Mon, 7 Dec 2015 09:29:11 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983F41AD05D for ; Mon, 7 Dec 2015 09:29:11 -0800 (PST) Date: Mon, 07 Dec 2015 09:29:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449509350; bh=LJSCeBDUFs7cNzyYxtXRq1kT+JUox0mECS/aR6AI0Go=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=14hjK9tf6VHRBcgs17Ne0cQmmS1LCT4Y04tytFisPD4xHJgV7sOHiF7eIN7DlUQcu IiJcq0+ru9q5B8EuTUz8wYAprED8tQWbIptiCyVHgTrhay4YmtCbBjhbG7JBK2pPM2 OXA82/jYFV47SpKpZ6o08qC2Noz0hNT8vB32CtMw= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5665c1e6e2b57_3f603f8a13d172c01111a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] "y > 0" should be "y >= 0" (#45) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 17:29:12 -0000 ----==_mimepart_5665c1e6e2b57_3f603f8a13d172c01111a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Fixed in pull cose-wg/cose-spec#105 --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/45#issuecomment-162600608 ----==_mimepart_5665c1e6e2b57_3f603f8a13d172c01111a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Fixed in pull cose-wg/cose-spec#105

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5665c1e6e2b57_3f603f8a13d172c01111a-- From nobody Mon Dec 7 10:02:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B271B384B for ; Mon, 7 Dec 2015 10:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.154 X-Spam-Level: X-Spam-Status: No, score=-5.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 BGnrROoFUBiY for ; Mon, 7 Dec 2015 10:02:09 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056931B383D for ; Mon, 7 Dec 2015 10:02:09 -0800 (PST) Date: Mon, 07 Dec 2015 10:02:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449511327; bh=cNc4HrsfArQFISW4thc+lZ8jmGvfGkPlEjlWbPJlHTg=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PpUxm/tbhYQXG6LKkPzFTeZ58G4uMDzpmxZHIWeKxjUpMZccEoXgzTtlPYSdWEBEx 5z3MD16VXAiCsgWKnKpcwLLBPfsbcPxKs63Sxw4oNxJF3rRAy1Qo3WL8WKU6dk5K52 EMSOKjfQ6dn+sHrjpib30kfG5vwrxe/f2jYmfYuk= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5665c99f9187e_1a6f3f971cb0b2b832387b"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Move_=E2=80=9Ccreation_time?= =?utf-8?b?4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 18:02:10 -0000 ----==_mimepart_5665c99f9187e_1a6f3f971cb0b2b832387b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The field name is changed from "creation time" to "operation time". This better reflects what can actually be placed here, i.e. the time that the operation was performed. This field is useful for things like countersignatures when one wants to make a timestamp. This makes it something that should stay in the document. The justification text has been updated to reflect that this is the primary intent of the field. However, as posited by Hannes, this field can also be used for replay detection as a time point is a reasonable thing to be looking at when determining if the context should be processed. Placing it outside of the cryptographic text allows for checking the field before wasting time on the cryptographic operation. cose-wg/cose-spec#106 --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/13#issuecomment-162609224 ----==_mimepart_5665c99f9187e_1a6f3f971cb0b2b832387b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

The field name is changed from "creation time" to "operation time". This better reflects what can actually be placed here, i.e. the time that the operation was performed. This field is useful for things like countersignatures when one wants to make a timestamp. This makes it something that should stay in the document. The justification text has been updated to reflect that this is the primary intent of the field.

However, as posited by Hannes, this field can also be used for replay detection as a time point is a reasonable thing to be looking at when determining if the context should be processed. Placing it outside of the cryptographic text allows for checking the field before wasting time on the cryptographic operation.

cose-wg/cose-spec#106

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5665c99f9187e_1a6f3f971cb0b2b832387b-- From nobody Tue Dec 8 07:00:27 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E69E1B2ECD for ; Tue, 8 Dec 2015 07:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 mU8p1_TSzXGo for ; Tue, 8 Dec 2015 07:00:16 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA0D1B2EB7 for ; Tue, 8 Dec 2015 07:00:15 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-90-5666f07dcecc Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.0D.04914.D70F6665; Tue, 8 Dec 2015 16:00:13 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.149]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 16:00:12 +0100 From: Francesca Palombini To: "cose@ietf.org" Thread-Topic: Message size considerations Thread-Index: AdExx8w+7Fl8oavJQAC+jbJdBuSmQg== Date: Tue, 8 Dec 2015 15:00:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7t27th7Qwg7NrJS2mbZ3K6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAUdM5gKvrxjrOi9vpa9gfHVBcYuRk4OCQETiU0n77FD2GIS F+6tZ+ti5OIQEjjMKDHh/BQWCGcxo8SXq5+YQKrYBGwkLjx8zwpiiwgoS0w61gxmCwuoSHyb dJYdIq4psbRpJpStJ9H4/SaQzcHBAlTzZJE0SJhXwFfi17vDbCA2I9Di76fWgI1nFhCXuPVk PhPEQQISS/acZ4awRSVePv7HCjJGQkBRYnm/HER5vsT/681sECMFJU7OfMIygVFoFpJJs5CU zUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWl lmxiBEbFwS2/dXcwrn7teIhRgINRiYfX4HpqmBBrYllxZe4hRgkOZiURXitgTAnxpiRWVqUW 5ccXleakFh9ilOZgURLnbWF6ECokkJ5YkpqdmlqQWgSTZeLglGpgjEu/d2D3RM8encurLh6w 0uFumBQTs1FFXvLDnf2+9V6XFO5/CSl4seSEsM/BvikT0uUVC5j92WQfJsfcOjbZklV0Zazt sqvHEnYZmHcaBTWts9tss/DRIfXbs/fySbVNZp8RyFH3bta17kVuR+ue8OQdZGfQP7SvbpX9 6buZd1ictl/b4vs6SYmlOCPRUIu5qDgRAEzVkumGAgAA Archived-At: Subject: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:00:26 -0000 --_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have re-calculated the message sizes for the different use cases that ar= e relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column "ove= rhead cose-msg-08" of table below). We think that the COSE_Encrypt format is well designed for applications whi= ch have tight requirements on message size, the overhead being of the order= of 10 bytes (excluding tag and necessary header parameters of size which d= epends on application). We don't see any reason why we should get twice the= overhead if we MAC or Sign a message instead. In this mail we propose some optimizations that mainly have an impact on th= e other formats, see column "overhead with mod" in the table below. In order to decrease the message size overhead we propose to add 2 new mess= age types: one for single signature (1) (in our use case we don't need mult= iple signatures), and one for MAC with no recipient (2). The rest of the mail is discussing the optimizations and our proposal. We t= hought to start this discussion here in the mailing list, but we could also= add our requests in the issue tracker if it is preferred. Reading up on the discussion about COSE structure for single signer [2], [3= ], we could not find any "closure" to that discussion, and like to revisit = the topic again. Analogously to the COSE_Encrypted structure, we consider that all informati= on necessary for the cryptographic operations is pre-established between th= e endpoints. The Context Identifier sent protected in the message is enough= to identify the security context and all the parameters necessary for cryp= to computations (alg, key, etc) previously set up in the endpoints. Because= of that, we don't need to send the signer/recipient info in the message, a= nd we suggest to optimize the COSE structure for this use case. We propose the following modifications: a. remove the alg parameter from the message sent: since all information is= pre-established in the nodes' security context, we don't need to send the = alg in the message. (saves 2B) b. for the new single-signature structure (1), we only need to send the bts= tr 'signature', we can remove the 'signatures' and 'COSE_signature' structu= re. The Context Identifier and the Sequence Number are sent in the COSE_Sig= n protected header. (saves 5B) c. remove the recipient structure from the new MAC structure (2). (saves 8B= ) d. as for b, for the COSE_Encrypt with counter signature use case, we propo= se to give the choice to use the whole COSE_Signature structure or only the= btstr 'signature' as 'counter signature'. If we only send the btstr 'signature' (our use case), we assume that the al= g for counter signature is also defined in the security context. (saves 8B) Even if these improvements may seem small, please note that in some cases t= he difference is half the total overhead, which is not insignificant. Table: Message overhead +--------------+-------------+----------+------------+ | COSE | overhead | overhead | difference | | Structure | cose-msg-08 | with mod | | +--------------+-------------+----------+------------+ | COSE_Sign | 18 B | 11 B | 7 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 11 B | 9 B | 2 B | +--------------+-------------+----------+------------+ | COSE_Mac | 20 B | 10 B | 10 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 20 B | 12 B | 8 B | | +counter sig | | | | +--------------+-------------+----------+------------+ As a summary, this is how we would modify the COSE_Message structures in or= der to optimize the message size, and how many bytes we would save from eac= h modification: COSE_Sign: [protected, unprotected, payload, [[ protected, unprotected, sig= nature]]] Bytes removed: -2B(b) -1B(b) -4B(a,b) COSE_Sign single signature (new type): [protected, unprotected, payload, si= gnature] COSE_Mac: [protected, unprotected, payload, tag, [[ protected, unprotected,= ciphertext]]] Bytes removed: -2B(a) -2B(c) -1B(c) -4B(a,c) = -1B(c) COSE_Mac no recipient (new type): [protected, unprotected, payload, tag] COSE_Encrypt: [protected, unprotected, ciphertext] Bytes removed: -2B(a) COSE_Encrypt: [protected, unprotected, ciphertext] COSE_Encrypt with counter signature: [protected, {7:[protected, unprotected= , signature], ...}, ciphertext] Bytes removed: -2B(a) -1B(d) -1B(d) -4B(a,d) COSE_Encrypt with counter signature mod: [protected, {7: signature, ...}, c= iphertext] To meet Jim's arguments against b. and c. in his previous message [2] (most= recent message I could find about this topic): "4. There is currently a very clear cut rule about things only being used = at the layer they are placed in. This means that currently key identifiers= are never placed in the same layer as a content key algorithm. This would= be broken by the proposal put forth. I worry that once this is done, ther= e will be more items than kid that will migrate between layers. One of the= things that I never liked in the JOSE proposals what the number of places = that one needed to look for the various control fields. Currently in COSE = this is limited to two places. If we introduce the possibility of cross la= yer contamination then this number might grow in the future to deal with im= plementation faults. One of the way that these faults might develop is for designers to say - I = think that this should be authenticated, and thus will put it at the wrong = layer to ensure that it is. Either without thinking about the question - s= hould it be authenticated, or a different algorithm be required so that aut= hentication is possible." We suggest to have one layer only for this specific use case where we don't= use this recipient/signer structure anyway, in new structures adapted for = this use case. We are not proposing to change the current structures, which= would be used when recipient/signer structures are necessary. "5. Code size is going to be very different if two different methods of de= aling with structure needs to be supported. It is currently being assumed = that direct key is going to be the major use case in a number of situations= . If this is not the case then current proposals do not help the situation = any. If it is true that more than one method of key management needs to be supported then the code size is going to grow because of the need to suppor= t an additional way that key management is going to be done." In our particular application of COSE, we don't need to support use cases w= ith recipient/signer structures. The creation of different msg types as we = suggest should make implementation easier. Francesca [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 [2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY [3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc --_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

We have re-calculated the message sizes for the different us= e cases that are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (= see column “overhead cose-msg-08” of table below).

 

We think that the COSE_Encrypt format is well designed for a= pplications which have tight requirements on message size, the overhead bei= ng of the order of 10 bytes (excluding tag and necessary header parameters of size which depends on application). We don't see any = reason why we should get twice the overhead if we MAC or Sign a message ins= tead.

 

In this mail we propose some optimizations that mainly have = an impact on the other formats, see column “overhead with mod” = in the table below.

 

In order to decrease the message size overhead we propose to= add 2 new message types: one for single signature (1) (in our use case we = don't need multiple signatures), and one for MAC with no recipient (2).

 

The rest of the mail is discussing the optimizations and our= proposal. We thought to start this discussion here in the mailing list, bu= t we could also add our requests in the issue tracker if it is preferred.

 

 

 

Reading up on the discussion about COSE structure for single= signer [2], [3], we could not find any "closure" to that discuss= ion, and like to revisit the topic again.

 

Analogously to the COSE_Encrypted structure, we consider tha= t all information necessary for the cryptographic operations is pre-establi= shed between the endpoints. The Context Identifier sent protected in the message is enough to identify the security context a= nd all the parameters necessary for crypto computations (alg, key, etc) pre= viously set up in the endpoints. Because of that, we don't need to send the= signer/recipient info in the message, and we suggest to optimize the COSE structure for this use case.

 

 

We propose the following modifications:

 

a. remove the alg parameter from the message sent: since all= information is pre-established in the nodes' security context, we don't ne= ed to send the alg in the message. (saves 2B)

 

b. for the new single-signature structure (1), we only need = to send the btstr 'signature', we can remove the 'signatures' and 'COSE_sig= nature' structure. The Context Identifier and the Sequence Number are sent in the COSE_Sign protected header. (saves 5B)

 

c. remove the recipient structure from the new MAC structure= (2). (saves 8B)

 

d. as for b, for the COSE_Encrypt with counter signature use= case, we propose to give the choice to use the whole COSE_Signature struct= ure or only the btstr 'signature' as ‘counter signature’.<= /o:p>

If we only send the btstr 'signature' (our use case), we ass= ume that the alg for counter signature is also defined in the security cont= ext. (saves 8B)

 

 

Even if these improvements may seem small, please note that = in some cases the difference is half the total overhead, which is not insig= nificant.

 

 

Table: Message overhead

 

+--------------+-------------+----------+---= ---------+

|      COSE    |&nbs= p; overhead   | overhead | difference |

|  Structure   | cose-msg-08 | with mod |&nbs= p;           |=

+--------------+-------------+----------+---= ---------+

| COSE_Sign    |     18 B=     |   11 B   |    = 7 B    |

+--------------+-------------+----------+---= ---------+

| COSE_Encrypt |     11 B  &nb= sp; |    9 B   |     2 B =    |

+--------------+-------------+----------+---= ---------+

| COSE_Mac     |    = 20 B    |   10 B   |    = 10 B    |

+--------------+-------------+----------+---= ---------+

| COSE_Encrypt |     20 B  &nb= sp; |   12 B   |     8 B  = ;  |

| +counter sig |      &nbs= p;      |       = ;   |          =   |

+--------------+-------------+----------+---= ---------+

 

 

As a summary, this is how we would modify the COSE_Message s= tructures in order to optimize the message size, and how many bytes we woul= d save from each modification:

 

COSE_Sign: [protected, unprotected, payload, [[ protected, u= nprotected, signature]]]

Bytes removed:       &nbs= p;            &= nbsp;        -2B(b) -1B(b)  &n= bsp;  -4B(a,b)

 

COSE_Sign single signature (new type): [protected, unprotect= ed, payload, signature]

 

 

COSE_Mac: [protected, unprotected, payload, tag, [[ protecte= d, unprotected, ciphertext]]]

Bytes removed:       &nbs= p;   -2B(a)         =       -2B(c) -1B(c)     -4B(a,= c)    -1B(c)

 

COSE_Mac no recipient (new type): [protected, unprotected, p= ayload, tag]

 

 

COSE_Encrypt: [protected, unprotected, ciphertext]

Bytes removed:   -2B(a)

 

COSE_Encrypt: [protected, unprotected, ciphertext]

 

 

COSE_Encrypt with counter signature: [protected, {7:[protect= ed, unprotected, signature], …}, ciphertext]

Bytes removed:       &nbs= p;            &= nbsp;     -2B(a)  -1B(d) -1B(d)    = -4B(a,d)

 

COSE_Encrypt with counter signature mod: [protected, {7: sig= nature, …}, ciphertext]

 

 

To meet Jim's arguments against b. and c. in his previous me= ssage [2] (most recent message I could find about this topic):

 

"4.  There is currently a very clear cut rule abou= t things only being used at the layer they are placed in.  This means = that currently key identifiers are never placed in the same layer as a content key algorithm.  This would be broken by the proposal put= forth.  I worry that once this is done, there will be more items than= kid that will migrate between layers.  One of the things that I never= liked in the JOSE proposals what the number of places that one needed to look for the various control fields.  Curre= ntly in COSE this is limited to two places.  If we introduce the possi= bility of cross layer contamination then this number might grow in the futu= re to deal with implementation faults.  

One of the way that these faults might develop is for design= ers to say - I think that this should be authenticated, and thus will put i= t at the wrong layer to ensure that it is.  Either without thinking about the question - should it be authenticated, or a dif= ferent algorithm be required so that authentication is possible."=

 

We suggest to have one layer only for this specific use case= where we don't use this recipient/signer structure anyway, in new structur= es adapted for this use case. We are not proposing to change the current structures, which would be used when recipient/signe= r structures are necessary.

 

"5.  Code size is going to be very different if tw= o different methods of dealing with structure needs to be supported.  = It is currently being assumed that direct key is going to be the major use case in a number of situations. If this is not the case then cur= rent proposals do not help the situation any.  If it is true that more= than one method of key management needs to be

supported then the code size is going to grow because of the= need to support an additional way that key management is going to be done.= "

 

In our particular application of COSE, we don't need to supp= ort use cases with recipient/signer structures. The creation of different m= sg types as we suggest should make implementation easier.

 

Francesca

 

 

[1] https://tools.ietf.org/html/draft-selander-ace-object-security-03<= /o:p>

 

[2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY<= o:p>

 

[3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc<= o:p>

 

 

--_000_D2736FF6C4A3F3428982D3508DD478DE0D42B753ESESSMB205erics_-- From nobody Tue Dec 8 07:28:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397041B2F08 for ; Tue, 8 Dec 2015 07:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dxhl-JRNTYZK for ; Tue, 8 Dec 2015 07:28:31 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971121B2F22 for ; Tue, 8 Dec 2015 07:28:29 -0800 (PST) X-AuditID: 1209190e-f79046d0000036c0-14-5666f71c8046 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FC.6D.14016.C17F6665; Tue, 8 Dec 2015 10:28:28 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tB8FSRfW011242; Tue, 8 Dec 2015 10:28:27 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB8FSPcD004901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Dec 2015 10:28:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_D99A6FC1-1FE2-4D1B-9AEC-CB501D304EED" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 8 Dec 2015 10:28:24 -0500 Message-Id: <5750B6D8-9CFD-47E2-9BBC-602E1D0699D9@mit.edu> References: To: Francesca Palombini X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixG6nrivzPS3MYPFjYYtpW6eyWszsb2d0 YPL49fUqm8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIOf1vDXtC4kKli4umbrA2MF38xdjFyckgI mEjcvfaDCcIWk7hwbz1bFyMXh5DAYiaJvX9aGCGcDYwSZ68dYIJwHjBJzO25zgrSwiyQIPHz 2D8WEJtXQE/i1a3LYHFhAX2JVwsOg9lsAqoS09e0gK3gFPCTePf+DFCcg4NFQEXi0b9yiDHK Ev/+TmaCGGMl8eLDS2YQW0jAV2JlM8SlIkDxrlNfWCEulZXY/fsR0wRGgVlIrpiF5AqIuLbE soWvmSFsTYn93ctZMMU1JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81 pXQTIyjoOSX5djB+Pah0iFGAg1GJh/fEsdQwIdbEsuLK3EOMkhxMSqK8tz+lhQnxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4c3+BpTjTUmsrEotyodJSXOwKInzzv3iGyYkkJ5YkpqdmlqQWgST leHgUJLg1QdpFCxKTU+tSMvMKUFIM3FwggznARrO9BVkeHFBYm5xZjpE/hSjopQ4bzxIQgAk kVGaB9cLSkoJbw+bvmIUB3pFmPcxSBUPMKHBdb8CGswENDjqZTLI4JJEhJRUA2OFCYP3/jtL dmr9cpA+EtoaX3yRq2vzuuSb3qsvVs9fstDt+cMX3XICqrcVoo8+O7w16/uuFTserD24I1x+ 4emLT+dpGquWJAp0JAVz6OqJvotRrg7NtLocvEjsRtiV3hf+8/LXNOqVXp26a7L+8ikF71n1 zs6yqOTK9nav/7P1w51uN28xsQtKLMUZiYZazEXFiQBl9yyWJQMAAA== Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:28:35 -0000 --Apple-Mail=_D99A6FC1-1FE2-4D1B-9AEC-CB501D304EED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (As an individual) I agree with this approach very strongly. Not only are the size = differences considerable, the simplicity of the structures is very = compelling.=20 Looking back through the list, a lot of the early comparisons of size = difference between the current COSE draft=E2=80=99s approach were with = the JOSE =E2=80=9CJSON Encoded=E2=80=9D structures, which have multiple = recipients and all kinds of other buts. In my view this was always a = false comparison, like comparing the efficacy of a new painkiller with = the efficacy of shooting yourself in the *other* foot. Yes, it=E2=80=99s = going to be better, but nobody would choose that! What we saw with JOSE = was that the simple =E2=80=9Ccompact format=E2=80=9D versions were the = only ones really ever used in practice. If you look at what=E2=80=99s = been implemented in the real world, you=E2=80=99ll find that the =E2=80=9C= JSON Encoded=E2=80=9D structures with multiple recipients and all kinds = of flexibility were simply not used, and continue to not be used. The = vast majority of JOSE libraries don=E2=80=99t even bother to implement = them. That really should tell us something. And quite frankly, if the compact forms were desired in the JOSE world, = I can=E2=80=99t see why they=E2=80=99re not even *more* desired in the = more compact world of COSE. What we have in COSE right now is overly = complicated and over generalized, and this proposed modification cuts = all that fat. Flexibility can feel wonderful to build into a system, but its attendant = complexities can get in the way of that same system being actually = useful to people. =E2=80=94 Justin (not your chair at the moment) > On Dec 8, 2015, at 10:00 AM, Francesca Palombini = wrote: >=20 > Hi, > =20 > =20 > We have re-calculated the message sizes for the different use cases = that are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see = column =E2=80=9Coverhead cose-msg-08=E2=80=9D of table below). > =20 > We think that the COSE_Encrypt format is well designed for = applications which have tight requirements on message size, the overhead = being of the order of 10 bytes (excluding tag and necessary header = parameters of size which depends on application). We don't see any = reason why we should get twice the overhead if we MAC or Sign a message = instead. > =20 > In this mail we propose some optimizations that mainly have an impact = on the other formats, see column =E2=80=9Coverhead with mod=E2=80=9D in = the table below. > =20 > In order to decrease the message size overhead we propose to add 2 new = message types: one for single signature (1) (in our use case we don't = need multiple signatures), and one for MAC with no recipient (2). > =20 > The rest of the mail is discussing the optimizations and our proposal. = We thought to start this discussion here in the mailing list, but we = could also add our requests in the issue tracker if it is preferred. > =20 > =20 > =20 > Reading up on the discussion about COSE structure for single signer = [2], [3], we could not find any "closure" to that discussion, and like = to revisit the topic again. > =20 > Analogously to the COSE_Encrypted structure, we consider that all = information necessary for the cryptographic operations is = pre-established between the endpoints. The Context Identifier sent = protected in the message is enough to identify the security context and = all the parameters necessary for crypto computations (alg, key, etc) = previously set up in the endpoints. Because of that, we don't need to = send the signer/recipient info in the message, and we suggest to = optimize the COSE structure for this use case. > =20 > =20 > We propose the following modifications: > =20 > a. remove the alg parameter from the message sent: since all = information is pre-established in the nodes' security context, we don't = need to send the alg in the message. (saves 2B) > =20 > b. for the new single-signature structure (1), we only need to send = the btstr 'signature', we can remove the 'signatures' and = 'COSE_signature' structure. The Context Identifier and the Sequence = Number are sent in the COSE_Sign protected header. (saves 5B) > =20 > c. remove the recipient structure from the new MAC structure (2). = (saves 8B) > =20 > d. as for b, for the COSE_Encrypt with counter signature use case, we = propose to give the choice to use the whole COSE_Signature structure or = only the btstr 'signature' as =E2=80=98counter signature=E2=80=99. > If we only send the btstr 'signature' (our use case), we assume that = the alg for counter signature is also defined in the security context. = (saves 8B) > =20 > =20 > Even if these improvements may seem small, please note that in some = cases the difference is half the total overhead, which is not = insignificant. > =20 > =20 > Table: Message overhead > =20 > +--------------+-------------+----------+------------+ > | COSE | overhead | overhead | difference | > | Structure | cose-msg-08 | with mod | | > +--------------+-------------+----------+------------+ > | COSE_Sign | 18 B | 11 B | 7 B | > +--------------+-------------+----------+------------+ > | COSE_Encrypt | 11 B | 9 B | 2 B | > +--------------+-------------+----------+------------+ > | COSE_Mac | 20 B | 10 B | 10 B | > +--------------+-------------+----------+------------+ > | COSE_Encrypt | 20 B | 12 B | 8 B | > | +counter sig | | | | > +--------------+-------------+----------+------------+ > =20 > =20 > As a summary, this is how we would modify the COSE_Message structures = in order to optimize the message size, and how many bytes we would save = from each modification: > =20 > COSE_Sign: [protected, unprotected, payload, [[ protected, = unprotected, signature]]] > Bytes removed: -2B(b) -1B(b) -4B(a,b) > =20 > COSE_Sign single signature (new type): [protected, unprotected, = payload, signature] > =20 > =20 > COSE_Mac: [protected, unprotected, payload, tag, [[ protected, = unprotected, ciphertext]]] > Bytes removed: -2B(a) -2B(c) -1B(c) = -4B(a,c) -1B(c) > =20 > COSE_Mac no recipient (new type): [protected, unprotected, payload, = tag] > =20 > =20 > COSE_Encrypt: [protected, unprotected, ciphertext] > Bytes removed: -2B(a) > =20 > COSE_Encrypt: [protected, unprotected, ciphertext] > =20 > =20 > COSE_Encrypt with counter signature: [protected, {7:[protected, = unprotected, signature], =E2=80=A6}, ciphertext] > Bytes removed: -2B(a) -1B(d) -1B(d) = -4B(a,d) > =20 > COSE_Encrypt with counter signature mod: [protected, {7: signature, = =E2=80=A6}, ciphertext] > =20 > =20 > To meet Jim's arguments against b. and c. in his previous message [2] = (most recent message I could find about this topic): > =20 > "4. There is currently a very clear cut rule about things only being = used at the layer they are placed in. This means that currently key = identifiers are never placed in the same layer as a content key = algorithm. This would be broken by the proposal put forth. I worry = that once this is done, there will be more items than kid that will = migrate between layers. One of the things that I never liked in the = JOSE proposals what the number of places that one needed to look for the = various control fields. Currently in COSE this is limited to two = places. If we introduce the possibility of cross layer contamination = then this number might grow in the future to deal with implementation = faults. =20 > One of the way that these faults might develop is for designers to say = - I think that this should be authenticated, and thus will put it at the = wrong layer to ensure that it is. Either without thinking about the = question - should it be authenticated, or a different algorithm be = required so that authentication is possible." > =20 > We suggest to have one layer only for this specific use case where we = don't use this recipient/signer structure anyway, in new structures = adapted for this use case. We are not proposing to change the current = structures, which would be used when recipient/signer structures are = necessary. > =20 > "5. Code size is going to be very different if two different methods = of dealing with structure needs to be supported. It is currently being = assumed that direct key is going to be the major use case in a number of = situations. If this is not the case then current proposals do not help = the situation any. If it is true that more than one method of key = management needs to be > supported then the code size is going to grow because of the need to = support an additional way that key management is going to be done." > =20 > In our particular application of COSE, we don't need to support use = cases with recipient/signer structures. The creation of different msg = types as we suggest should make implementation easier. > =20 > Francesca > =20 > =20 > [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 = > =20 > [2] = https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY = > =20 > [3] = https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc = > =20 > =20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_D99A6FC1-1FE2-4D1B-9AEC-CB501D304EED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (As an individual)

I agree with this approach very strongly. Not only are the = size differences considerable, the simplicity of the structures is very = compelling. 

Looking back through the list, a lot of the early comparisons = of size difference between the current COSE draft=E2=80=99s approach = were with the JOSE =E2=80=9CJSON Encoded=E2=80=9D structures, which have = multiple recipients and all kinds of other buts. In my view this was = always a false comparison, like comparing the efficacy of a new = painkiller with the efficacy of shooting yourself in the *other* foot. = Yes, it=E2=80=99s going to be better, but nobody would choose that! What = we saw with JOSE was that the simple =E2=80=9Ccompact format=E2=80=9D = versions were the only ones really ever used in practice. If you look at = what=E2=80=99s been implemented in the real world, you=E2=80=99ll find = that the =E2=80=9CJSON Encoded=E2=80=9D structures with multiple = recipients and all kinds of flexibility were simply not used, and = continue to not be used. The vast majority of JOSE libraries don=E2=80=99t= even bother to implement them. That really should tell us = something.

And = quite frankly, if the compact forms were desired in the JOSE world, I = can=E2=80=99t see why they=E2=80=99re not even *more* desired in the = more compact world of COSE. What we have in COSE right now is overly = complicated and over generalized, and this proposed modification cuts = all that fat.

Flexibility can feel wonderful to build into a system, but = its attendant complexities can get in the way of that same system being = actually useful to people.

 =E2=80=94 Justin (not your chair at the = moment)

On Dec 8, 2015, at 10:00 AM, Francesca = Palombini <francesca.palombini@ericsson.com> wrote:

Hi,

 

 

We have = re-calculated the message sizes for the different use cases that are = relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column = =E2=80=9Coverhead cose-msg-08=E2=80=9D of table below).

 

We think that = the COSE_Encrypt format is well designed for applications which have = tight requirements on message size, the overhead being of the order of = 10 bytes (excluding tag and necessary header parameters of size which depends on application). We don't see = any reason why we should get twice the overhead if we MAC or Sign a = message instead.

 

In this mail we = propose some optimizations that mainly have an impact on the other = formats, see column =E2=80=9Coverhead with mod=E2=80=9D in the table = below.

 

In order to = decrease the message size overhead we propose to add 2 new message = types: one for single signature (1) (in our use case we don't need = multiple signatures), and one for MAC with no recipient (2).

 

The rest of the = mail is discussing the optimizations and our proposal. We thought to = start this discussion here in the mailing list, but we could also add = our requests in the issue tracker if it is preferred.

 

 

 

Reading up on = the discussion about COSE structure for single signer [2], [3], we could = not find any "closure" to that discussion, and like to revisit the topic = again.

 

Analogously to = the COSE_Encrypted structure, we consider that all information necessary = for the cryptographic operations is pre-established between the = endpoints. The Context Identifier sent protected in the message is enough to identify the security = context and all the parameters necessary for crypto computations (alg, = key, etc) previously set up in the endpoints. Because of that, we don't = need to send the signer/recipient info in the message, and we suggest to optimize the COSE structure for this use case.

 

 

We propose the = following modifications:

 

a. remove the = alg parameter from the message sent: since all information is = pre-established in the nodes' security context, we don't need to send = the alg in the message. (saves 2B)

 

b. for the new = single-signature structure (1), we only need to send the btstr = 'signature', we can remove the 'signatures' and 'COSE_signature' = structure. The Context Identifier and the Sequence Number are sent in the COSE_Sign protected header. (saves = 5B)

 

c. remove the = recipient structure from the new MAC structure (2). (saves 8B)

 

d. as for b, = for the COSE_Encrypt with counter signature use case, we propose to give = the choice to use the whole COSE_Signature structure or only the btstr = 'signature' as =E2=80=98counter signature=E2=80=99.

If we only send = the btstr 'signature' (our use case), we assume that the alg for counter = signature is also defined in the security context. (saves 8B)

 

 

Even if these = improvements may seem small, please note that in some cases the = difference is half the total overhead, which is not insignificant.

 

 

Table: Message = overhead

 

+--------------+-------------+----------+------------+

|      COSE    = |  overhead   | overhead | difference |

|  = Structure   | cose-msg-08 | with mod = |            = |

+--------------+-------------+----------+------------+

| = COSE_Sign    |     18 = B    |   11 B   = |     7 B    |

+--------------+-------------+----------+------------+

| COSE_Encrypt = |     11 B    |    9 = B   |     2 B    |

+--------------+-------------+----------+------------+

| = COSE_Mac     |     20 = B    |   10 B   |    = 10 B    |

+--------------+-------------+----------+------------+

| COSE_Encrypt = |     20 B    |   12 = B   |     8 B    |

| +counter sig = |             = |          = |            = |

+--------------+-------------+----------+------------+

 

 

As a summary, = this is how we would modify the COSE_Message structures in order to = optimize the message size, and how many bytes we would save from each = modification:

 

COSE_Sign: = [protected, unprotected, payload, [[ protected, unprotected, = signature]]]

Bytes = removed:           =             &n= bsp;     -2B(b) -1B(b)     = -4B(a,b)

 

COSE_Sign = single signature (new type): [protected, unprotected, payload, = signature]

 

 

COSE_Mac: = [protected, unprotected, payload, tag, [[ protected, unprotected, = ciphertext]]]

Bytes = removed:           = -2B(a)           &n= bsp;   -2B(c) -1B(c)     = -4B(a,c)    -1B(c)

 

COSE_Mac no = recipient (new type): [protected, unprotected, payload, tag]

 

 

COSE_Encrypt: = [protected, unprotected, ciphertext]

Bytes = removed:   -2B(a)

 

COSE_Encrypt: = [protected, unprotected, ciphertext]

 

 

COSE_Encrypt = with counter signature: [protected, {7:[protected, unprotected, = signature], =E2=80=A6}, ciphertext]

Bytes = removed:           =             &n= bsp;  -2B(a)  -1B(d) -1B(d)    -4B(a,d)

 

COSE_Encrypt = with counter signature mod: [protected, {7: signature, =E2=80=A6}, = ciphertext]

 

 

To meet Jim's = arguments against b. and c. in his previous message [2] (most recent = message I could find about this topic):

 

"4.  There = is currently a very clear cut rule about things only being used at the = layer they are placed in.  This means that currently key = identifiers are never placed in the same layer as a content key algorithm.  This would be broken by the proposal = put forth.  I worry that once this is done, there will be more = items than kid that will migrate between layers.  One of the things = that I never liked in the JOSE proposals what the number of places that one needed to look for the various control fields.  = Currently in COSE this is limited to two places.  If we introduce = the possibility of cross layer contamination then this number might grow = in the future to deal with implementation faults.  

One of the way that these faults might develop is for = designers to say - I think that this should be authenticated, and thus = will put it at the wrong layer to ensure that it is.  Either without thinking about the question - should it be authenticated, or a = different algorithm be required so that authentication is possible."

 

We suggest to = have one layer only for this specific use case where we don't use this = recipient/signer structure anyway, in new structures adapted for this = use case. We are not proposing to change the current structures, which would be used when = recipient/signer structures are necessary.

 

"5.  Code = size is going to be very different if two different methods of dealing = with structure needs to be supported.  It is currently being = assumed that direct key is going to be the major use case in a number of situations. If this is not the case then = current proposals do not help the situation any.  If it is true = that more than one method of key management needs to be

supported then = the code size is going to grow because of the need to support an = additional way that key management is going to be done."

 

In our = particular application of COSE, we don't need to support use cases with = recipient/signer structures. The creation of different msg types as we = suggest should make implementation easier.

 

Francesca

 

 

[1] = https://tools.ietf.org/html/draft-selander-ace-object-security-03

 

[2] = https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY=

 

[3] = https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc=

 

 

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

= --Apple-Mail=_D99A6FC1-1FE2-4D1B-9AEC-CB501D304EED-- From nobody Tue Dec 8 07:58:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE951B2F5A for ; Tue, 8 Dec 2015 07:58:40 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ft2o-1KRqeIH for ; Tue, 8 Dec 2015 07:58:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A8A1B2F59 for ; Tue, 8 Dec 2015 07:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t+m2GCGNaF6q+3rsnVcj0oWtPC3NZRVTzOiubzh1P+o=; b=Ft5Wv5Gh47AzyT13q7roQICdZwVFvbkzC3OID37qRSbbOiutsEmkflotJS6npnw8C/6f0PcUssfiB8kzT8Jk3RLb8Sp1hfpCyyZRGlL4t8Jnw6toOcDKJSXEES5z+bdY698MAlEpq3Diz2SWS/Q6IlwS9Sde1EnpJehSKCrihyM= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 8 Dec 2015 15:58:09 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 8 Dec 2015 15:58:09 +0000 From: Mike Jones To: Francesca Palombini , Justin Richer Thread-Topic: [COSE] Message size considerations Thread-Index: AdExx8w+7Fl8oavJQAC+jbJdBuSmQgABUeEAAAkXS8A= Date: Tue, 8 Dec 2015 15:58:09 +0000 Message-ID: References: <5750B6D8-9CFD-47E2-9BBC-602E1D0699D9@mit.edu> In-Reply-To: <5750B6D8-9CFD-47E2-9BBC-602E1D0699D9@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:PCQjinosY8LLOQcpyKeYiSjpxE1ke/ye0DZFJBdzbrNF7h8qfhswQDzGy1liU0fNXdZKsJJ9eg0ik8MbibHc3tDGVKDodhN28XHEGtB8+IJEskmZI+6ozf5FamSvrh24dQBqAbzXD6rGlJLNDxHDhQ==; 24:qhRqh2yUsySpUP4Z2tCKKj2qm6UqoOXrFVS9Xcz1qnSTT0QB15xzR7lGtwxEcHjvAETMiQHbqh5qSe1bCsFO5G4Xj4s1j+j/Sk6yQMzTao0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0784C803FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(199003)(377454003)(51444003)(189002)(52314003)(561944003)(86362001)(54356999)(7110500001)(76576001)(10710500006)(5002640100001)(33656002)(101416001)(19625215002)(2420400006)(16236675004)(189998001)(5008740100001)(19580395003)(105586002)(50986999)(19300405004)(11100500001)(10400500002)(10090500001)(10290500002)(5003600100002)(5005710100001)(106356001)(19580405001)(74316001)(99286002)(1096002)(8990500004)(1220700001)(575784001)(19617315012)(66066001)(86612001)(5004730100002)(5001960100002)(19609705001)(5001770100001)(97736004)(92566002)(87936001)(2171001)(2950100001)(76176999)(77096005)(81156007)(122556002)(3846002)(790700001)(2900100001)(6116002)(15975445007)(102836003)(40100003)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4424AAF0A18670E3606F1A6F5080BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 15:58:09.1809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 15:58:40 -0000 --_000_BY2PR03MB4424AAF0A18670E3606F1A6F5080BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEZyYW5jZXNjYS4gIEkgbGlrZXdpc2UgYWdyZWUgd2l0aCB5b3VyIGFwcHJvYWNoLCBh cyBJIGtub3cgZG8gYSBudW1iZXIgb2Ygb3RoZXJzLiAgT3BlbiBpc3N1ZSAjMTA8aHR0cHM6Ly9n aXRodWIuY29tL2Nvc2Utd2cvY29zZS1pc3N1ZXMvaXNzdWVzLzEwPiBhbHNvIGFza3MgZm9yIHNp bXBsaWZpY2F0aW9ucyBhbG9uZyB0aGVzZSBsaW5lcy4gIEFzIHlvdSBjYW4gc2VlIHJlZmVyZW5j ZWQgaW4gdGhhdCBpc3N1ZSwgR8O2cmFuIFNlbGFuZGVyIG1hZGUgYSBzaW1pbGFyIHJlcXVlc3Qg aW4gaGlzIHByZXNlbnRhdGlvbiDigJxBQ0UvQ09SRSByZXF1aXJlbWVudHMgb24gQ09TRTxodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLWNvc2UtNi5w ZGY+4oCdIGluIFByYWd1ZS4gIEhvcGVmdWxseSB0aGUgZWRpdG9ycyB3aWxsIGFkZHJlc3MgdGhp cyBpc3N1ZSBhbG9uZyB0aGUgbGluZXMgdGhhdCB5b3Ugc3VnZ2VzdCBzb29uLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSnVzdGluIFJpY2hlcg0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgOCwgMjAxNSA3OjI4IEFN DQpUbzogRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5j b20+DQpDYzogY29zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDT1NFXSBNZXNzYWdlIHNpemUg Y29uc2lkZXJhdGlvbnMNCg0KKEFzIGFuIGluZGl2aWR1YWwpDQoNCkkgYWdyZWUgd2l0aCB0aGlz IGFwcHJvYWNoIHZlcnkgc3Ryb25nbHkuIE5vdCBvbmx5IGFyZSB0aGUgc2l6ZSBkaWZmZXJlbmNl cyBjb25zaWRlcmFibGUsIHRoZSBzaW1wbGljaXR5IG9mIHRoZSBzdHJ1Y3R1cmVzIGlzIHZlcnkg Y29tcGVsbGluZy4NCg0KTG9va2luZyBiYWNrIHRocm91Z2ggdGhlIGxpc3QsIGEgbG90IG9mIHRo ZSBlYXJseSBjb21wYXJpc29ucyBvZiBzaXplIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgY3VycmVu dCBDT1NFIGRyYWZ04oCZcyBhcHByb2FjaCB3ZXJlIHdpdGggdGhlIEpPU0Ug4oCcSlNPTiBFbmNv ZGVk4oCdIHN0cnVjdHVyZXMsIHdoaWNoIGhhdmUgbXVsdGlwbGUgcmVjaXBpZW50cyBhbmQgYWxs IGtpbmRzIG9mIG90aGVyIGJ1dHMuIEluIG15IHZpZXcgdGhpcyB3YXMgYWx3YXlzIGEgZmFsc2Ug Y29tcGFyaXNvbiwgbGlrZSBjb21wYXJpbmcgdGhlIGVmZmljYWN5IG9mIGEgbmV3IHBhaW5raWxs ZXIgd2l0aCB0aGUgZWZmaWNhY3kgb2Ygc2hvb3RpbmcgeW91cnNlbGYgaW4gdGhlICpvdGhlciog Zm9vdC4gWWVzLCBpdOKAmXMgZ29pbmcgdG8gYmUgYmV0dGVyLCBidXQgbm9ib2R5IHdvdWxkIGNo b29zZSB0aGF0ISBXaGF0IHdlIHNhdyB3aXRoIEpPU0Ugd2FzIHRoYXQgdGhlIHNpbXBsZSDigJxj b21wYWN0IGZvcm1hdOKAnSB2ZXJzaW9ucyB3ZXJlIHRoZSBvbmx5IG9uZXMgcmVhbGx5IGV2ZXIg dXNlZCBpbiBwcmFjdGljZS4gSWYgeW91IGxvb2sgYXQgd2hhdOKAmXMgYmVlbiBpbXBsZW1lbnRl ZCBpbiB0aGUgcmVhbCB3b3JsZCwgeW914oCZbGwgZmluZCB0aGF0IHRoZSDigJxKU09OIEVuY29k ZWTigJ0gc3RydWN0dXJlcyB3aXRoIG11bHRpcGxlIHJlY2lwaWVudHMgYW5kIGFsbCBraW5kcyBv ZiBmbGV4aWJpbGl0eSB3ZXJlIHNpbXBseSBub3QgdXNlZCwgYW5kIGNvbnRpbnVlIHRvIG5vdCBi ZSB1c2VkLiBUaGUgdmFzdCBtYWpvcml0eSBvZiBKT1NFIGxpYnJhcmllcyBkb27igJl0IGV2ZW4g Ym90aGVyIHRvIGltcGxlbWVudCB0aGVtLiBUaGF0IHJlYWxseSBzaG91bGQgdGVsbCB1cyBzb21l dGhpbmcuDQoNCkFuZCBxdWl0ZSBmcmFua2x5LCBpZiB0aGUgY29tcGFjdCBmb3JtcyB3ZXJlIGRl c2lyZWQgaW4gdGhlIEpPU0Ugd29ybGQsIEkgY2Fu4oCZdCBzZWUgd2h5IHRoZXnigJlyZSBub3Qg ZXZlbiAqbW9yZSogZGVzaXJlZCBpbiB0aGUgbW9yZSBjb21wYWN0IHdvcmxkIG9mIENPU0UuIFdo YXQgd2UgaGF2ZSBpbiBDT1NFIHJpZ2h0IG5vdyBpcyBvdmVybHkgY29tcGxpY2F0ZWQgYW5kIG92 ZXIgZ2VuZXJhbGl6ZWQsIGFuZCB0aGlzIHByb3Bvc2VkIG1vZGlmaWNhdGlvbiBjdXRzIGFsbCB0 aGF0IGZhdC4NCg0KRmxleGliaWxpdHkgY2FuIGZlZWwgd29uZGVyZnVsIHRvIGJ1aWxkIGludG8g YSBzeXN0ZW0sIGJ1dCBpdHMgYXR0ZW5kYW50IGNvbXBsZXhpdGllcyBjYW4gZ2V0IGluIHRoZSB3 YXkgb2YgdGhhdCBzYW1lIHN5c3RlbSBiZWluZyBhY3R1YWxseSB1c2VmdWwgdG8gcGVvcGxlLg0K DQog4oCUIEp1c3RpbiAobm90IHlvdXIgY2hhaXIgYXQgdGhlIG1vbWVudCkNCg0KT24gRGVjIDgs IDIwMTUsIGF0IDEwOjAwIEFNLCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21i aW5pQGVyaWNzc29uLmNvbTxtYWlsdG86ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+ PiB3cm90ZToNCg0KSGksDQoNCg0KV2UgaGF2ZSByZS1jYWxjdWxhdGVkIHRoZSBtZXNzYWdlIHNp emVzIGZvciB0aGUgZGlmZmVyZW50IHVzZSBjYXNlcyB0aGF0IGFyZSByZWxldmFudCBmb3IgT1ND T0FQIFsxXSwgYmFzZWQgb24gZHJhZnQtaWV0Zi1jb3NlLW1zZy0wOCAoc2VlIGNvbHVtbiDigJxv dmVyaGVhZCBjb3NlLW1zZy0wOOKAnSBvZiB0YWJsZSBiZWxvdykuDQoNCldlIHRoaW5rIHRoYXQg dGhlIENPU0VfRW5jcnlwdCBmb3JtYXQgaXMgd2VsbCBkZXNpZ25lZCBmb3IgYXBwbGljYXRpb25z IHdoaWNoIGhhdmUgdGlnaHQgcmVxdWlyZW1lbnRzIG9uIG1lc3NhZ2Ugc2l6ZSwgdGhlIG92ZXJo ZWFkIGJlaW5nIG9mIHRoZSBvcmRlciBvZiAxMCBieXRlcyAoZXhjbHVkaW5nIHRhZyBhbmQgbmVj ZXNzYXJ5IGhlYWRlciBwYXJhbWV0ZXJzIG9mIHNpemUgd2hpY2ggZGVwZW5kcyBvbiBhcHBsaWNh dGlvbikuIFdlIGRvbid0IHNlZSBhbnkgcmVhc29uIHdoeSB3ZSBzaG91bGQgZ2V0IHR3aWNlIHRo ZSBvdmVyaGVhZCBpZiB3ZSBNQUMgb3IgU2lnbiBhIG1lc3NhZ2UgaW5zdGVhZC4NCg0KSW4gdGhp cyBtYWlsIHdlIHByb3Bvc2Ugc29tZSBvcHRpbWl6YXRpb25zIHRoYXQgbWFpbmx5IGhhdmUgYW4g aW1wYWN0IG9uIHRoZSBvdGhlciBmb3JtYXRzLCBzZWUgY29sdW1uIOKAnG92ZXJoZWFkIHdpdGgg bW9k4oCdIGluIHRoZSB0YWJsZSBiZWxvdy4NCg0KSW4gb3JkZXIgdG8gZGVjcmVhc2UgdGhlIG1l c3NhZ2Ugc2l6ZSBvdmVyaGVhZCB3ZSBwcm9wb3NlIHRvIGFkZCAyIG5ldyBtZXNzYWdlIHR5cGVz OiBvbmUgZm9yIHNpbmdsZSBzaWduYXR1cmUgKDEpIChpbiBvdXIgdXNlIGNhc2Ugd2UgZG9uJ3Qg bmVlZCBtdWx0aXBsZSBzaWduYXR1cmVzKSwgYW5kIG9uZSBmb3IgTUFDIHdpdGggbm8gcmVjaXBp ZW50ICgyKS4NCg0KVGhlIHJlc3Qgb2YgdGhlIG1haWwgaXMgZGlzY3Vzc2luZyB0aGUgb3B0aW1p emF0aW9ucyBhbmQgb3VyIHByb3Bvc2FsLiBXZSB0aG91Z2h0IHRvIHN0YXJ0IHRoaXMgZGlzY3Vz c2lvbiBoZXJlIGluIHRoZSBtYWlsaW5nIGxpc3QsIGJ1dCB3ZSBjb3VsZCBhbHNvIGFkZCBvdXIg cmVxdWVzdHMgaW4gdGhlIGlzc3VlIHRyYWNrZXIgaWYgaXQgaXMgcHJlZmVycmVkLg0KDQoNCg0K UmVhZGluZyB1cCBvbiB0aGUgZGlzY3Vzc2lvbiBhYm91dCBDT1NFIHN0cnVjdHVyZSBmb3Igc2lu Z2xlIHNpZ25lciBbMl0sIFszXSwgd2UgY291bGQgbm90IGZpbmQgYW55ICJjbG9zdXJlIiB0byB0 aGF0IGRpc2N1c3Npb24sIGFuZCBsaWtlIHRvIHJldmlzaXQgdGhlIHRvcGljIGFnYWluLg0KDQpB bmFsb2dvdXNseSB0byB0aGUgQ09TRV9FbmNyeXB0ZWQgc3RydWN0dXJlLCB3ZSBjb25zaWRlciB0 aGF0IGFsbCBpbmZvcm1hdGlvbiBuZWNlc3NhcnkgZm9yIHRoZSBjcnlwdG9ncmFwaGljIG9wZXJh dGlvbnMgaXMgcHJlLWVzdGFibGlzaGVkIGJldHdlZW4gdGhlIGVuZHBvaW50cy4gVGhlIENvbnRl eHQgSWRlbnRpZmllciBzZW50IHByb3RlY3RlZCBpbiB0aGUgbWVzc2FnZSBpcyBlbm91Z2ggdG8g aWRlbnRpZnkgdGhlIHNlY3VyaXR5IGNvbnRleHQgYW5kIGFsbCB0aGUgcGFyYW1ldGVycyBuZWNl c3NhcnkgZm9yIGNyeXB0byBjb21wdXRhdGlvbnMgKGFsZywga2V5LCBldGMpIHByZXZpb3VzbHkg c2V0IHVwIGluIHRoZSBlbmRwb2ludHMuIEJlY2F1c2Ugb2YgdGhhdCwgd2UgZG9uJ3QgbmVlZCB0 byBzZW5kIHRoZSBzaWduZXIvcmVjaXBpZW50IGluZm8gaW4gdGhlIG1lc3NhZ2UsIGFuZCB3ZSBz dWdnZXN0IHRvIG9wdGltaXplIHRoZSBDT1NFIHN0cnVjdHVyZSBmb3IgdGhpcyB1c2UgY2FzZS4N Cg0KDQpXZSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgbW9kaWZpY2F0aW9uczoNCg0KYS4gcmVtb3Zl IHRoZSBhbGcgcGFyYW1ldGVyIGZyb20gdGhlIG1lc3NhZ2Ugc2VudDogc2luY2UgYWxsIGluZm9y bWF0aW9uIGlzIHByZS1lc3RhYmxpc2hlZCBpbiB0aGUgbm9kZXMnIHNlY3VyaXR5IGNvbnRleHQs IHdlIGRvbid0IG5lZWQgdG8gc2VuZCB0aGUgYWxnIGluIHRoZSBtZXNzYWdlLiAoc2F2ZXMgMkIp DQoNCmIuIGZvciB0aGUgbmV3IHNpbmdsZS1zaWduYXR1cmUgc3RydWN0dXJlICgxKSwgd2Ugb25s eSBuZWVkIHRvIHNlbmQgdGhlIGJ0c3RyICdzaWduYXR1cmUnLCB3ZSBjYW4gcmVtb3ZlIHRoZSAn c2lnbmF0dXJlcycgYW5kICdDT1NFX3NpZ25hdHVyZScgc3RydWN0dXJlLiBUaGUgQ29udGV4dCBJ ZGVudGlmaWVyIGFuZCB0aGUgU2VxdWVuY2UgTnVtYmVyIGFyZSBzZW50IGluIHRoZSBDT1NFX1Np Z24gcHJvdGVjdGVkIGhlYWRlci4gKHNhdmVzIDVCKQ0KDQpjLiByZW1vdmUgdGhlIHJlY2lwaWVu dCBzdHJ1Y3R1cmUgZnJvbSB0aGUgbmV3IE1BQyBzdHJ1Y3R1cmUgKDIpLiAoc2F2ZXMgOEIpDQoN CmQuIGFzIGZvciBiLCBmb3IgdGhlIENPU0VfRW5jcnlwdCB3aXRoIGNvdW50ZXIgc2lnbmF0dXJl IHVzZSBjYXNlLCB3ZSBwcm9wb3NlIHRvIGdpdmUgdGhlIGNob2ljZSB0byB1c2UgdGhlIHdob2xl IENPU0VfU2lnbmF0dXJlIHN0cnVjdHVyZSBvciBvbmx5IHRoZSBidHN0ciAnc2lnbmF0dXJlJyBh cyDigJhjb3VudGVyIHNpZ25hdHVyZeKAmS4NCklmIHdlIG9ubHkgc2VuZCB0aGUgYnRzdHIgJ3Np Z25hdHVyZScgKG91ciB1c2UgY2FzZSksIHdlIGFzc3VtZSB0aGF0IHRoZSBhbGcgZm9yIGNvdW50 ZXIgc2lnbmF0dXJlIGlzIGFsc28gZGVmaW5lZCBpbiB0aGUgc2VjdXJpdHkgY29udGV4dC4gKHNh dmVzIDhCKQ0KDQoNCkV2ZW4gaWYgdGhlc2UgaW1wcm92ZW1lbnRzIG1heSBzZWVtIHNtYWxsLCBw bGVhc2Ugbm90ZSB0aGF0IGluIHNvbWUgY2FzZXMgdGhlIGRpZmZlcmVuY2UgaXMgaGFsZiB0aGUg dG90YWwgb3ZlcmhlYWQsIHdoaWNoIGlzIG5vdCBpbnNpZ25pZmljYW50Lg0KDQoNClRhYmxlOiBN ZXNzYWdlIG92ZXJoZWFkDQoNCistLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tKw0KfCAgICAgIENPU0UgICAgfCAgb3ZlcmhlYWQgICB8IG92ZXJoZWFk IHwgZGlmZmVyZW5jZSB8DQp8ICBTdHJ1Y3R1cmUgICB8IGNvc2UtbXNnLTA4IHwgd2l0aCBtb2Qg fCAgICAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tKw0KfCBDT1NFX1NpZ24gICAgfCAgICAgMTggQiAgICB8ICAgMTEgQiAgIHwg ICAgIDcgQiAgICB8DQorLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSsNCnwgQ09TRV9FbmNyeXB0IHwgICAgIDExIEIgICAgfCAgICA5IEIgICB8ICAg ICAyIEIgICAgfA0KKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0rDQp8IENPU0VfTWFjICAgICB8ICAgICAyMCBCICAgIHwgICAxMCBCICAgfCAgICAx MCBCICAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tKw0KfCBDT1NFX0VuY3J5cHQgfCAgICAgMjAgQiAgICB8ICAgMTIgQiAgIHwgICAgIDgg QiAgICB8DQp8ICtjb3VudGVyIHNpZyB8ICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAg ICAgIHwNCistLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tKw0KDQoNCkFzIGEgc3VtbWFyeSwgdGhpcyBpcyBob3cgd2Ugd291bGQgbW9kaWZ5IHRoZSBD T1NFX01lc3NhZ2Ugc3RydWN0dXJlcyBpbiBvcmRlciB0byBvcHRpbWl6ZSB0aGUgbWVzc2FnZSBz aXplLCBhbmQgaG93IG1hbnkgYnl0ZXMgd2Ugd291bGQgc2F2ZSBmcm9tIGVhY2ggbW9kaWZpY2F0 aW9uOg0KDQpDT1NFX1NpZ246IFtwcm90ZWN0ZWQsIHVucHJvdGVjdGVkLCBwYXlsb2FkLCBbWyBw cm90ZWN0ZWQsIHVucHJvdGVjdGVkLCBzaWduYXR1cmVdXV0NCkJ5dGVzIHJlbW92ZWQ6ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtMkIoYikgLTFCKGIpICAgICAtNEIoYSxiKQ0KDQpDT1NF X1NpZ24gc2luZ2xlIHNpZ25hdHVyZSAobmV3IHR5cGUpOiBbcHJvdGVjdGVkLCB1bnByb3RlY3Rl ZCwgcGF5bG9hZCwgc2lnbmF0dXJlXQ0KDQoNCkNPU0VfTWFjOiBbcHJvdGVjdGVkLCB1bnByb3Rl Y3RlZCwgcGF5bG9hZCwgdGFnLCBbWyBwcm90ZWN0ZWQsIHVucHJvdGVjdGVkLCBjaXBoZXJ0ZXh0 XV1dDQpCeXRlcyByZW1vdmVkOiAgICAgICAgICAgLTJCKGEpICAgICAgICAgICAgICAgLTJCKGMp IC0xQihjKSAgICAgLTRCKGEsYykgICAgLTFCKGMpDQoNCkNPU0VfTWFjIG5vIHJlY2lwaWVudCAo bmV3IHR5cGUpOiBbcHJvdGVjdGVkLCB1bnByb3RlY3RlZCwgcGF5bG9hZCwgdGFnXQ0KDQoNCkNP U0VfRW5jcnlwdDogW3Byb3RlY3RlZCwgdW5wcm90ZWN0ZWQsIGNpcGhlcnRleHRdDQpCeXRlcyBy ZW1vdmVkOiAgIC0yQihhKQ0KDQpDT1NFX0VuY3J5cHQ6IFtwcm90ZWN0ZWQsIHVucHJvdGVjdGVk LCBjaXBoZXJ0ZXh0XQ0KDQoNCkNPU0VfRW5jcnlwdCB3aXRoIGNvdW50ZXIgc2lnbmF0dXJlOiBb cHJvdGVjdGVkLCB7NzpbcHJvdGVjdGVkLCB1bnByb3RlY3RlZCwgc2lnbmF0dXJlXSwg4oCmfSwg Y2lwaGVydGV4dF0NCkJ5dGVzIHJlbW92ZWQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAtMkIo YSkgIC0xQihkKSAtMUIoZCkgICAgLTRCKGEsZCkNCg0KQ09TRV9FbmNyeXB0IHdpdGggY291bnRl ciBzaWduYXR1cmUgbW9kOiBbcHJvdGVjdGVkLCB7Nzogc2lnbmF0dXJlLCDigKZ9LCBjaXBoZXJ0 ZXh0XQ0KDQoNClRvIG1lZXQgSmltJ3MgYXJndW1lbnRzIGFnYWluc3QgYi4gYW5kIGMuIGluIGhp cyBwcmV2aW91cyBtZXNzYWdlIFsyXSAobW9zdCByZWNlbnQgbWVzc2FnZSBJIGNvdWxkIGZpbmQg YWJvdXQgdGhpcyB0b3BpYyk6DQoNCiI0LiAgVGhlcmUgaXMgY3VycmVudGx5IGEgdmVyeSBjbGVh ciBjdXQgcnVsZSBhYm91dCB0aGluZ3Mgb25seSBiZWluZyB1c2VkIGF0IHRoZSBsYXllciB0aGV5 IGFyZSBwbGFjZWQgaW4uICBUaGlzIG1lYW5zIHRoYXQgY3VycmVudGx5IGtleSBpZGVudGlmaWVy cyBhcmUgbmV2ZXIgcGxhY2VkIGluIHRoZSBzYW1lIGxheWVyIGFzIGEgY29udGVudCBrZXkgYWxn b3JpdGhtLiAgVGhpcyB3b3VsZCBiZSBicm9rZW4gYnkgdGhlIHByb3Bvc2FsIHB1dCBmb3J0aC4g IEkgd29ycnkgdGhhdCBvbmNlIHRoaXMgaXMgZG9uZSwgdGhlcmUgd2lsbCBiZSBtb3JlIGl0ZW1z IHRoYW4ga2lkIHRoYXQgd2lsbCBtaWdyYXRlIGJldHdlZW4gbGF5ZXJzLiAgT25lIG9mIHRoZSB0 aGluZ3MgdGhhdCBJIG5ldmVyIGxpa2VkIGluIHRoZSBKT1NFIHByb3Bvc2FscyB3aGF0IHRoZSBu dW1iZXIgb2YgcGxhY2VzIHRoYXQgb25lIG5lZWRlZCB0byBsb29rIGZvciB0aGUgdmFyaW91cyBj b250cm9sIGZpZWxkcy4gIEN1cnJlbnRseSBpbiBDT1NFIHRoaXMgaXMgbGltaXRlZCB0byB0d28g cGxhY2VzLiAgSWYgd2UgaW50cm9kdWNlIHRoZSBwb3NzaWJpbGl0eSBvZiBjcm9zcyBsYXllciBj b250YW1pbmF0aW9uIHRoZW4gdGhpcyBudW1iZXIgbWlnaHQgZ3JvdyBpbiB0aGUgZnV0dXJlIHRv IGRlYWwgd2l0aCBpbXBsZW1lbnRhdGlvbiBmYXVsdHMuDQpPbmUgb2YgdGhlIHdheSB0aGF0IHRo ZXNlIGZhdWx0cyBtaWdodCBkZXZlbG9wIGlzIGZvciBkZXNpZ25lcnMgdG8gc2F5IC0gSSB0aGlu ayB0aGF0IHRoaXMgc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQsIGFuZCB0aHVzIHdpbGwgcHV0IGl0 IGF0IHRoZSB3cm9uZyBsYXllciB0byBlbnN1cmUgdGhhdCBpdCBpcy4gIEVpdGhlciB3aXRob3V0 IHRoaW5raW5nIGFib3V0IHRoZSBxdWVzdGlvbiAtIHNob3VsZCBpdCBiZSBhdXRoZW50aWNhdGVk LCBvciBhIGRpZmZlcmVudCBhbGdvcml0aG0gYmUgcmVxdWlyZWQgc28gdGhhdCBhdXRoZW50aWNh dGlvbiBpcyBwb3NzaWJsZS4iDQoNCldlIHN1Z2dlc3QgdG8gaGF2ZSBvbmUgbGF5ZXIgb25seSBm b3IgdGhpcyBzcGVjaWZpYyB1c2UgY2FzZSB3aGVyZSB3ZSBkb24ndCB1c2UgdGhpcyByZWNpcGll bnQvc2lnbmVyIHN0cnVjdHVyZSBhbnl3YXksIGluIG5ldyBzdHJ1Y3R1cmVzIGFkYXB0ZWQgZm9y IHRoaXMgdXNlIGNhc2UuIFdlIGFyZSBub3QgcHJvcG9zaW5nIHRvIGNoYW5nZSB0aGUgY3VycmVu dCBzdHJ1Y3R1cmVzLCB3aGljaCB3b3VsZCBiZSB1c2VkIHdoZW4gcmVjaXBpZW50L3NpZ25lciBz dHJ1Y3R1cmVzIGFyZSBuZWNlc3NhcnkuDQoNCiI1LiAgQ29kZSBzaXplIGlzIGdvaW5nIHRvIGJl IHZlcnkgZGlmZmVyZW50IGlmIHR3byBkaWZmZXJlbnQgbWV0aG9kcyBvZiBkZWFsaW5nIHdpdGgg c3RydWN0dXJlIG5lZWRzIHRvIGJlIHN1cHBvcnRlZC4gIEl0IGlzIGN1cnJlbnRseSBiZWluZyBh c3N1bWVkIHRoYXQgZGlyZWN0IGtleSBpcyBnb2luZyB0byBiZSB0aGUgbWFqb3IgdXNlIGNhc2Ug aW4gYSBudW1iZXIgb2Ygc2l0dWF0aW9ucy4gSWYgdGhpcyBpcyBub3QgdGhlIGNhc2UgdGhlbiBj dXJyZW50IHByb3Bvc2FscyBkbyBub3QgaGVscCB0aGUgc2l0dWF0aW9uIGFueS4gIElmIGl0IGlz IHRydWUgdGhhdCBtb3JlIHRoYW4gb25lIG1ldGhvZCBvZiBrZXkgbWFuYWdlbWVudCBuZWVkcyB0 byBiZQ0Kc3VwcG9ydGVkIHRoZW4gdGhlIGNvZGUgc2l6ZSBpcyBnb2luZyB0byBncm93IGJlY2F1 c2Ugb2YgdGhlIG5lZWQgdG8gc3VwcG9ydCBhbiBhZGRpdGlvbmFsIHdheSB0aGF0IGtleSBtYW5h Z2VtZW50IGlzIGdvaW5nIHRvIGJlIGRvbmUuIg0KDQpJbiBvdXIgcGFydGljdWxhciBhcHBsaWNh dGlvbiBvZiBDT1NFLCB3ZSBkb24ndCBuZWVkIHRvIHN1cHBvcnQgdXNlIGNhc2VzIHdpdGggcmVj aXBpZW50L3NpZ25lciBzdHJ1Y3R1cmVzLiBUaGUgY3JlYXRpb24gb2YgZGlmZmVyZW50IG1zZyB0 eXBlcyBhcyB3ZSBzdWdnZXN0IHNob3VsZCBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llci4NCg0K RnJhbmNlc2NhDQoNCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxh bmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAzDQoNClsyXSBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL2Nvc2UvajFQM05xdDF3RVpTVEdDWU8wZ0ZTZWF6eFVZDQoNClszXSBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Nvc2UvOGZLR1pCTVp1VW12SmFm d1FvZEtxTXhRR2JjDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNPU0UgbWFpbGluZyBsaXN0DQpDT1NFQGlldGYub3JnPG1haWx0bzpDT1NFQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== --_000_BY2PR03MB4424AAF0A18670E3606F1A6F5080BY2PR03MB442namprd_ 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 cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlNWO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzIEZyYW5jZXNjYS4mbmJzcDsgSSBsaWtld2lzZSBh Z3JlZSB3aXRoIHlvdXIgYXBwcm9hY2gsIGFzIEkga25vdyBkbyBhIG51bWJlciBvZiBvdGhlcnMu Jm5ic3A7IE9wZW4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL2Nvc2UtaXNz dWVzL2lzc3Vlcy8xMCI+aXNzdWUgIzEwPC9hPiBhbHNvIGFza3MgZm9yIHNpbXBsaWZpY2F0aW9u cyBhbG9uZyB0aGVzZSBsaW5lcy4mbmJzcDsgQXMgeW91IGNhbiBzZWUgcmVmZXJlbmNlZCBpbiB0 aGF0IGlzc3VlLCBHw7ZyYW4gU2VsYW5kZXIgbWFkZSBhIHNpbWlsYXIgcmVxdWVzdCBpbiBoaXMg cHJlc2VudGF0aW9uIOKAnDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz LzkzL3NsaWRlcy9zbGlkZXMtOTMtY29zZS02LnBkZiI+QUNFL0NPUkUNCiByZXF1aXJlbWVudHMg b24gQ09TRTwvYT7igJ0gaW4gUHJhZ3VlLiZuYnNwOyBIb3BlZnVsbHkgdGhlIGVkaXRvcnMgd2ls bCBhZGRyZXNzIHRoaXMgaXNzdWUgYWxvbmcgdGhlIGxpbmVzIHRoYXQgeW91IHN1Z2dlc3Qgc29v bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3Nw YW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IENPU0UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZg0KPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RGVjZW1iZXIgOCwgMjAxNSA3OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBGcmFuY2VzY2EgUGFsb21i aW5pICZsdDtmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IGNvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDT1NFXSBNZXNzYWdl IHNpemUgY29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPihBcyBhbiBpbmRpdmlkdWFsKTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl IHdpdGggdGhpcyBhcHByb2FjaCB2ZXJ5IHN0cm9uZ2x5LiBOb3Qgb25seSBhcmUgdGhlIHNpemUg ZGlmZmVyZW5jZXMgY29uc2lkZXJhYmxlLCB0aGUgc2ltcGxpY2l0eSBvZiB0aGUgc3RydWN0dXJl cyBpcyB2ZXJ5IGNvbXBlbGxpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgYmFjayB0aHJvdWdoIHRoZSBsaXN0LCBh IGxvdCBvZiB0aGUgZWFybHkgY29tcGFyaXNvbnMgb2Ygc2l6ZSBkaWZmZXJlbmNlIGJldHdlZW4g dGhlIGN1cnJlbnQgQ09TRSBkcmFmdOKAmXMgYXBwcm9hY2ggd2VyZSB3aXRoIHRoZSBKT1NFIOKA nEpTT04gRW5jb2RlZOKAnSBzdHJ1Y3R1cmVzLCB3aGljaCBoYXZlIG11bHRpcGxlIHJlY2lwaWVu dHMgYW5kIGFsbCBraW5kcyBvZiBvdGhlciBidXRzLiBJbiBteSB2aWV3DQogdGhpcyB3YXMgYWx3 YXlzIGEgZmFsc2UgY29tcGFyaXNvbiwgbGlrZSBjb21wYXJpbmcgdGhlIGVmZmljYWN5IG9mIGEg bmV3IHBhaW5raWxsZXIgd2l0aCB0aGUgZWZmaWNhY3kgb2Ygc2hvb3RpbmcgeW91cnNlbGYgaW4g dGhlICpvdGhlciogZm9vdC4gWWVzLCBpdOKAmXMgZ29pbmcgdG8gYmUgYmV0dGVyLCBidXQgbm9i b2R5IHdvdWxkIGNob29zZSB0aGF0ISBXaGF0IHdlIHNhdyB3aXRoIEpPU0Ugd2FzIHRoYXQgdGhl IHNpbXBsZSDigJxjb21wYWN0IGZvcm1hdOKAnQ0KIHZlcnNpb25zIHdlcmUgdGhlIG9ubHkgb25l cyByZWFsbHkgZXZlciB1c2VkIGluIHByYWN0aWNlLiBJZiB5b3UgbG9vayBhdCB3aGF04oCZcyBi ZWVuIGltcGxlbWVudGVkIGluIHRoZSByZWFsIHdvcmxkLCB5b3XigJlsbCBmaW5kIHRoYXQgdGhl IOKAnEpTT04gRW5jb2RlZOKAnSBzdHJ1Y3R1cmVzIHdpdGggbXVsdGlwbGUgcmVjaXBpZW50cyBh bmQgYWxsIGtpbmRzIG9mIGZsZXhpYmlsaXR5IHdlcmUgc2ltcGx5IG5vdCB1c2VkLCBhbmQgY29u dGludWUgdG8gbm90DQogYmUgdXNlZC4gVGhlIHZhc3QgbWFqb3JpdHkgb2YgSk9TRSBsaWJyYXJp ZXMgZG9u4oCZdCBldmVuIGJvdGhlciB0byBpbXBsZW1lbnQgdGhlbS4gVGhhdCByZWFsbHkgc2hv dWxkIHRlbGwgdXMgc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgcXVpdGUgZnJhbmtseSwgaWYgdGhlIGNvbXBhY3QgZm9y bXMgd2VyZSBkZXNpcmVkIGluIHRoZSBKT1NFIHdvcmxkLCBJIGNhbuKAmXQgc2VlIHdoeSB0aGV5 4oCZcmUgbm90IGV2ZW4gKm1vcmUqIGRlc2lyZWQgaW4gdGhlIG1vcmUgY29tcGFjdCB3b3JsZCBv ZiBDT1NFLiBXaGF0IHdlIGhhdmUgaW4gQ09TRSByaWdodCBub3cgaXMgb3Zlcmx5IGNvbXBsaWNh dGVkIGFuZCBvdmVyIGdlbmVyYWxpemVkLCBhbmQgdGhpcw0KIHByb3Bvc2VkIG1vZGlmaWNhdGlv biBjdXRzIGFsbCB0aGF0IGZhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RmxleGliaWxpdHkgY2FuIGZlZWwgd29uZGVyZnVsIHRvIGJ1aWxk IGludG8gYSBzeXN0ZW0sIGJ1dCBpdHMgYXR0ZW5kYW50IGNvbXBsZXhpdGllcyBjYW4gZ2V0IGlu IHRoZSB3YXkgb2YgdGhhdCBzYW1lIHN5c3RlbSBiZWluZyBhY3R1YWxseSB1c2VmdWwgdG8gcGVv cGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDvigJQgSnVzdGluIChub3QgeW91ciBjaGFpciBhdCB0aGUgbW9tZW50KTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDgs IDIwMTUsIGF0IDEwOjAwIEFNLCBGcmFuY2VzY2EgUGFsb21iaW5pICZsdDs8YSBocmVmPSJtYWls dG86ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20iPmZyYW5jZXNjYS5wYWxvbWJpbmlA ZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPkhpLDwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlIGhhdmUgcmUtY2FsY3VsYXRl ZCB0aGUgbWVzc2FnZSBzaXplcyBmb3IgdGhlIGRpZmZlcmVudCB1c2UgY2FzZXMgdGhhdCBhcmUg cmVsZXZhbnQgZm9yIE9TQ09BUCBbMV0sIGJhc2VkIG9uIGRyYWZ0LWlldGYtY29zZS1tc2ctMDgg KHNlZSBjb2x1bW4g4oCcb3ZlcmhlYWQgY29zZS1tc2ctMDjigJ0gb2YgdGFibGUgYmVsb3cpLg0K PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5XZSB0aGluayB0aGF0IHRoZSBDT1NFX0VuY3J5cHQgZm9ybWF0IGlzIHdl bGwgZGVzaWduZWQgZm9yIGFwcGxpY2F0aW9ucyB3aGljaCBoYXZlIHRpZ2h0IHJlcXVpcmVtZW50 cyBvbiBtZXNzYWdlIHNpemUsIHRoZSBvdmVyaGVhZCBiZWluZyBvZiB0aGUgb3JkZXIgb2YgMTAg Ynl0ZXMgKGV4Y2x1ZGluZyB0YWcgYW5kIG5lY2Vzc2FyeSBoZWFkZXINCiBwYXJhbWV0ZXJzIG9m IHNpemUgd2hpY2ggZGVwZW5kcyBvbiBhcHBsaWNhdGlvbikuIFdlIGRvbid0IHNlZSBhbnkgcmVh c29uIHdoeSB3ZSBzaG91bGQgZ2V0IHR3aWNlIHRoZSBvdmVyaGVhZCBpZiB3ZSBNQUMgb3IgU2ln biBhIG1lc3NhZ2UgaW5zdGVhZC48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkluIHRoaXMgbWFpbCB3ZSBwcm9wb3Nl IHNvbWUgb3B0aW1pemF0aW9ucyB0aGF0IG1haW5seSBoYXZlIGFuIGltcGFjdCBvbiB0aGUgb3Ro ZXIgZm9ybWF0cywgc2VlIGNvbHVtbiDigJxvdmVyaGVhZCB3aXRoIG1vZOKAnSBpbiB0aGUgdGFi bGUgYmVsb3cuDQo8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkluIG9yZGVyIHRvIGRlY3JlYXNlIHRoZSBtZXNzYWdl IHNpemUgb3ZlcmhlYWQgd2UgcHJvcG9zZSB0byBhZGQgMiBuZXcgbWVzc2FnZSB0eXBlczogb25l IGZvciBzaW5nbGUgc2lnbmF0dXJlICgxKSAoaW4gb3VyIHVzZSBjYXNlIHdlIGRvbid0IG5lZWQg bXVsdGlwbGUgc2lnbmF0dXJlcyksIGFuZCBvbmUgZm9yIE1BQyB3aXRoIG5vIHJlY2lwaWVudA0K ICgyKS48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlRoZSByZXN0IG9mIHRoZSBtYWlsIGlzIGRpc2N1c3NpbmcgdGhl IG9wdGltaXphdGlvbnMgYW5kIG91ciBwcm9wb3NhbC4gV2UgdGhvdWdodCB0byBzdGFydCB0aGlz IGRpc2N1c3Npb24gaGVyZSBpbiB0aGUgbWFpbGluZyBsaXN0LCBidXQgd2UgY291bGQgYWxzbyBh ZGQgb3VyIHJlcXVlc3RzIGluIHRoZSBpc3N1ZSB0cmFja2VyIGlmIGl0IGlzDQogcHJlZmVycmVk Ljwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWFkaW5nIHVwIG9uIHRoZSBkaXNj dXNzaW9uIGFib3V0IENPU0Ugc3RydWN0dXJlIGZvciBzaW5nbGUgc2lnbmVyIFsyXSwgWzNdLCB3 ZSBjb3VsZCBub3QgZmluZCBhbnkgJnF1b3Q7Y2xvc3VyZSZxdW90OyB0byB0aGF0IGRpc2N1c3Np b24sIGFuZCBsaWtlIHRvIHJldmlzaXQgdGhlIHRvcGljIGFnYWluLg0KPC9zcGFuPjxzcGFuIGxh bmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5B bmFsb2dvdXNseSB0byB0aGUgQ09TRV9FbmNyeXB0ZWQgc3RydWN0dXJlLCB3ZSBjb25zaWRlciB0 aGF0IGFsbCBpbmZvcm1hdGlvbiBuZWNlc3NhcnkgZm9yIHRoZSBjcnlwdG9ncmFwaGljIG9wZXJh dGlvbnMgaXMgcHJlLWVzdGFibGlzaGVkIGJldHdlZW4gdGhlIGVuZHBvaW50cy4gVGhlIENvbnRl eHQgSWRlbnRpZmllciBzZW50IHByb3RlY3RlZA0KIGluIHRoZSBtZXNzYWdlIGlzIGVub3VnaCB0 byBpZGVudGlmeSB0aGUgc2VjdXJpdHkgY29udGV4dCBhbmQgYWxsIHRoZSBwYXJhbWV0ZXJzIG5l Y2Vzc2FyeSBmb3IgY3J5cHRvIGNvbXB1dGF0aW9ucyAoYWxnLCBrZXksIGV0YykgcHJldmlvdXNs eSBzZXQgdXAgaW4gdGhlIGVuZHBvaW50cy4gQmVjYXVzZSBvZiB0aGF0LCB3ZSBkb24ndCBuZWVk IHRvIHNlbmQgdGhlIHNpZ25lci9yZWNpcGllbnQgaW5mbyBpbiB0aGUgbWVzc2FnZSwgYW5kIHdl IHN1Z2dlc3QNCiB0byBvcHRpbWl6ZSB0aGUgQ09TRSBzdHJ1Y3R1cmUgZm9yIHRoaXMgdXNlIGNh c2UuPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgcHJvcG9zZSB0aGUgZm9sbG93aW5nIG1vZGlm aWNhdGlvbnM6PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hLiByZW1vdmUgdGhlIGFsZyBwYXJhbWV0ZXIgZnJvbSB0 aGUgbWVzc2FnZSBzZW50OiBzaW5jZSBhbGwgaW5mb3JtYXRpb24gaXMgcHJlLWVzdGFibGlzaGVk IGluIHRoZSBub2Rlcycgc2VjdXJpdHkgY29udGV4dCwgd2UgZG9uJ3QgbmVlZCB0byBzZW5kIHRo ZSBhbGcgaW4gdGhlIG1lc3NhZ2UuIChzYXZlcyAyQik8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmIuIGZvciB0aGUg bmV3IHNpbmdsZS1zaWduYXR1cmUgc3RydWN0dXJlICgxKSwgd2Ugb25seSBuZWVkIHRvIHNlbmQg dGhlIGJ0c3RyICdzaWduYXR1cmUnLCB3ZSBjYW4gcmVtb3ZlIHRoZSAnc2lnbmF0dXJlcycgYW5k ICdDT1NFX3NpZ25hdHVyZScgc3RydWN0dXJlLiBUaGUgQ29udGV4dCBJZGVudGlmaWVyIGFuZCB0 aGUgU2VxdWVuY2UgTnVtYmVyDQogYXJlIHNlbnQgaW4gdGhlIENPU0VfU2lnbiBwcm90ZWN0ZWQg aGVhZGVyLiAoc2F2ZXMgNUIpPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jLiByZW1vdmUgdGhlIHJlY2lwaWVudCBz dHJ1Y3R1cmUgZnJvbSB0aGUgbmV3IE1BQyBzdHJ1Y3R1cmUgKDIpLiAoc2F2ZXMgOEIpPC9zcGFu PjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5kLiBhcyBmb3IgYiwgZm9yIHRoZSBDT1NFX0VuY3J5cHQgd2l0aCBjb3VudGVyIHNp Z25hdHVyZSB1c2UgY2FzZSwgd2UgcHJvcG9zZSB0byBnaXZlIHRoZSBjaG9pY2UgdG8gdXNlIHRo ZSB3aG9sZSBDT1NFX1NpZ25hdHVyZSBzdHJ1Y3R1cmUgb3Igb25seSB0aGUgYnRzdHIgJ3NpZ25h dHVyZScgYXMg4oCYY291bnRlciBzaWduYXR1cmXigJkuPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHdlIG9ubHkgc2VuZCB0aGUg YnRzdHIgJ3NpZ25hdHVyZScgKG91ciB1c2UgY2FzZSksIHdlIGFzc3VtZSB0aGF0IHRoZSBhbGcg Zm9yIGNvdW50ZXIgc2lnbmF0dXJlIGlzIGFsc28gZGVmaW5lZCBpbiB0aGUgc2VjdXJpdHkgY29u dGV4dC4gKHNhdmVzIDhCKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNW Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkV2ZW4gaWYgdGhlc2UgaW1w cm92ZW1lbnRzIG1heSBzZWVtIHNtYWxsLCBwbGVhc2Ugbm90ZSB0aGF0IGluIHNvbWUgY2FzZXMg dGhlIGRpZmZlcmVuY2UgaXMgaGFsZiB0aGUgdG90YWwgb3ZlcmhlYWQsIHdoaWNoIGlzIG5vdCBp bnNpZ25pZmljYW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRhYmxlOiBNZXNzYWdlIG92ZXJo ZWFkPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENPU0UmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBvdmVyaGVhZCZuYnNw OyZuYnNwOyB8IG92ZXJoZWFkIHwgZGlmZmVyZW5jZSB8PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwmbmJzcDsgU3RydWN0dXJlJm5i c3A7Jm5ic3A7IHwgY29zZS1tc2ctMDggfCB3aXRoIG1vZCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PHNw YW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0Mzst LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+fCBDT1NFX1NpZ24mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxOCBCJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMTEgQiZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDcgQiZuYnNwOyZuYnNwOyZuYnNw OyB8PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwgQ09TRV9FbmNyeXB0IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMTEgQiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkg QiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIgQiZuYnNwOyZuYnNwOyZu YnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnwgQ09TRV9NYWMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMCBCJm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsgMTAgQiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwIEIm bmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5n PSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij58IENPU0VfRW5jcnlw dCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwIEImbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyAxMiBCJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOCBCJm5i c3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+fCAmIzQzO2NvdW50ZXIgc2lnIHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5B cyBhIHN1bW1hcnksIHRoaXMgaXMgaG93IHdlIHdvdWxkIG1vZGlmeSB0aGUgQ09TRV9NZXNzYWdl IHN0cnVjdHVyZXMgaW4gb3JkZXIgdG8gb3B0aW1pemUgdGhlIG1lc3NhZ2Ugc2l6ZSwgYW5kIGhv dyBtYW55IGJ5dGVzIHdlIHdvdWxkIHNhdmUgZnJvbSBlYWNoIG1vZGlmaWNhdGlvbjo8L3NwYW4+ PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkNPU0VfU2lnbjogW3Byb3RlY3RlZCwgdW5wcm90ZWN0ZWQsIHBheWxvYWQsIFtbIHBy b3RlY3RlZCwgdW5wcm90ZWN0ZWQsIHNpZ25hdHVyZV1dXTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CeXRlcyByZW1vdmVkOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtMkIoYikg LTFCKGIpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC00QihhLGIpPC9zcGFuPjxzcGFuIGxhbmc9 IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DT1NF X1NpZ24gc2luZ2xlIHNpZ25hdHVyZSAobmV3IHR5cGUpOiBbcHJvdGVjdGVkLCB1bnByb3RlY3Rl ZCwgcGF5bG9hZCwgc2lnbmF0dXJlXTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNPU0VfTWFjOiBb cHJvdGVjdGVkLCB1bnByb3RlY3RlZCwgcGF5bG9hZCwgdGFnLCBbWyBwcm90ZWN0ZWQsIHVucHJv dGVjdGVkLCBjaXBoZXJ0ZXh0XV1dPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJ5dGVzIHJlbW92ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0yQihhKSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtMkIoYykgLTFCKGMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC00QihhLGMpJm5ic3A7Jm5ic3A7Jm5ic3A7IC0xQihjKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q09TRV9NYWMg bm8gcmVjaXBpZW50IChuZXcgdHlwZSk6IFtwcm90ZWN0ZWQsIHVucHJvdGVjdGVkLCBwYXlsb2Fk LCB0YWddPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q09TRV9FbmNyeXB0OiBbcHJvdGVjdGVkLCB1 bnByb3RlY3RlZCwgY2lwaGVydGV4dF08L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Qnl0ZXMgcmVtb3ZlZDombmJzcDsmbmJzcDsgLTJC KGEpPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5DT1NFX0VuY3J5cHQ6IFtwcm90ZWN0ZWQsIHVucHJvdGVjdGVkLCBj aXBoZXJ0ZXh0XTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNPU0VfRW5jcnlwdCB3aXRoIGNvdW50 ZXIgc2lnbmF0dXJlOiBbcHJvdGVjdGVkLCB7NzpbcHJvdGVjdGVkLCB1bnByb3RlY3RlZCwgc2ln bmF0dXJlXSwg4oCmfSwgY2lwaGVydGV4dF08L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Qnl0ZXMgcmVtb3ZlZDombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLTJCKGEpJm5ic3A7IC0xQihkKSAtMUIoZCkmbmJzcDsm bmJzcDsmbmJzcDsgLTRCKGEsZCk8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNPU0VfRW5jcnlwdCB3aXRoIGNvdW50 ZXIgc2lnbmF0dXJlIG1vZDogW3Byb3RlY3RlZCwgezc6IHNpZ25hdHVyZSwg4oCmfSwgY2lwaGVy dGV4dF08L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbyBtZWV0IEppbSdzIGFyZ3VtZW50cyBhZ2Fp bnN0IGIuIGFuZCBjLiBpbiBoaXMgcHJldmlvdXMgbWVzc2FnZSBbMl0gKG1vc3QgcmVjZW50IG1l c3NhZ2UgSSBjb3VsZCBmaW5kIGFib3V0IHRoaXMgdG9waWMpOjwvc3Bhbj48c3BhbiBsYW5nPSJT ViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7 NC4mbmJzcDsgVGhlcmUgaXMgY3VycmVudGx5IGEgdmVyeSBjbGVhciBjdXQgcnVsZSBhYm91dCB0 aGluZ3Mgb25seSBiZWluZyB1c2VkIGF0IHRoZSBsYXllciB0aGV5IGFyZSBwbGFjZWQgaW4uJm5i c3A7IFRoaXMgbWVhbnMgdGhhdCBjdXJyZW50bHkga2V5IGlkZW50aWZpZXJzIGFyZSBuZXZlciBw bGFjZWQgaW4gdGhlIHNhbWUgbGF5ZXIgYXMgYSBjb250ZW50DQoga2V5IGFsZ29yaXRobS4mbmJz cDsgVGhpcyB3b3VsZCBiZSBicm9rZW4gYnkgdGhlIHByb3Bvc2FsIHB1dCBmb3J0aC4mbmJzcDsg SSB3b3JyeSB0aGF0IG9uY2UgdGhpcyBpcyBkb25lLCB0aGVyZSB3aWxsIGJlIG1vcmUgaXRlbXMg dGhhbiBraWQgdGhhdCB3aWxsIG1pZ3JhdGUgYmV0d2VlbiBsYXllcnMuJm5ic3A7IE9uZSBvZiB0 aGUgdGhpbmdzIHRoYXQgSSBuZXZlciBsaWtlZCBpbiB0aGUgSk9TRSBwcm9wb3NhbHMgd2hhdCB0 aGUgbnVtYmVyIG9mIHBsYWNlcyB0aGF0DQogb25lIG5lZWRlZCB0byBsb29rIGZvciB0aGUgdmFy aW91cyBjb250cm9sIGZpZWxkcy4mbmJzcDsgQ3VycmVudGx5IGluIENPU0UgdGhpcyBpcyBsaW1p dGVkIHRvIHR3byBwbGFjZXMuJm5ic3A7IElmIHdlIGludHJvZHVjZSB0aGUgcG9zc2liaWxpdHkg b2YgY3Jvc3MgbGF5ZXIgY29udGFtaW5hdGlvbiB0aGVuIHRoaXMgbnVtYmVyIG1pZ2h0IGdyb3cg aW4gdGhlIGZ1dHVyZSB0byBkZWFsIHdpdGggaW1wbGVtZW50YXRpb24gZmF1bHRzLiZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPk9uZSBvZiB0aGUgd2F5IHRoYXQgdGhlc2UgZmF1bHRzIG1pZ2h0IGRldmVsb3Ag aXMgZm9yIGRlc2lnbmVycyB0byBzYXkgLSBJIHRoaW5rIHRoYXQgdGhpcyBzaG91bGQgYmUgYXV0 aGVudGljYXRlZCwgYW5kIHRodXMgd2lsbCBwdXQgaXQgYXQgdGhlIHdyb25nIGxheWVyIHRvIGVu c3VyZSB0aGF0IGl0IGlzLiZuYnNwOyBFaXRoZXIgd2l0aG91dCB0aGlua2luZw0KIGFib3V0IHRo ZSBxdWVzdGlvbiAtIHNob3VsZCBpdCBiZSBhdXRoZW50aWNhdGVkLCBvciBhIGRpZmZlcmVudCBh bGdvcml0aG0gYmUgcmVxdWlyZWQgc28gdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBwb3NzaWJsZS4m cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPldlIHN1Z2dlc3QgdG8gaGF2ZSBvbmUgbGF5ZXIgb25seSBmb3Ig dGhpcyBzcGVjaWZpYyB1c2UgY2FzZSB3aGVyZSB3ZSBkb24ndCB1c2UgdGhpcyByZWNpcGllbnQv c2lnbmVyIHN0cnVjdHVyZSBhbnl3YXksIGluIG5ldyBzdHJ1Y3R1cmVzIGFkYXB0ZWQgZm9yIHRo aXMgdXNlIGNhc2UuIFdlIGFyZSBub3QgcHJvcG9zaW5nIHRvIGNoYW5nZQ0KIHRoZSBjdXJyZW50 IHN0cnVjdHVyZXMsIHdoaWNoIHdvdWxkIGJlIHVzZWQgd2hlbiByZWNpcGllbnQvc2lnbmVyIHN0 cnVjdHVyZXMgYXJlIG5lY2Vzc2FyeS48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90OzUuJm5ic3A7IENvZGUg c2l6ZSBpcyBnb2luZyB0byBiZSB2ZXJ5IGRpZmZlcmVudCBpZiB0d28gZGlmZmVyZW50IG1ldGhv ZHMgb2YgZGVhbGluZyB3aXRoIHN0cnVjdHVyZSBuZWVkcyB0byBiZSBzdXBwb3J0ZWQuJm5ic3A7 IEl0IGlzIGN1cnJlbnRseSBiZWluZyBhc3N1bWVkIHRoYXQgZGlyZWN0IGtleSBpcyBnb2luZyB0 byBiZSB0aGUgbWFqb3IgdXNlIGNhc2UNCiBpbiBhIG51bWJlciBvZiBzaXR1YXRpb25zLiBJZiB0 aGlzIGlzIG5vdCB0aGUgY2FzZSB0aGVuIGN1cnJlbnQgcHJvcG9zYWxzIGRvIG5vdCBoZWxwIHRo ZSBzaXR1YXRpb24gYW55LiZuYnNwOyBJZiBpdCBpcyB0cnVlIHRoYXQgbW9yZSB0aGFuIG9uZSBt ZXRob2Qgb2Yga2V5IG1hbmFnZW1lbnQgbmVlZHMgdG8gYmU8L3NwYW4+PHNwYW4gbGFuZz0iU1Yi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+c3VwcG9ydGVkIHRoZW4gdGhl IGNvZGUgc2l6ZSBpcyBnb2luZyB0byBncm93IGJlY2F1c2Ugb2YgdGhlIG5lZWQgdG8gc3VwcG9y dCBhbiBhZGRpdGlvbmFsIHdheSB0aGF0IGtleSBtYW5hZ2VtZW50IGlzIGdvaW5nIHRvIGJlIGRv bmUuJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBvdXIgcGFydGljdWxhciBhcHBsaWNhdGlvbiBvZiBD T1NFLCB3ZSBkb24ndCBuZWVkIHRvIHN1cHBvcnQgdXNlIGNhc2VzIHdpdGggcmVjaXBpZW50L3Np Z25lciBzdHJ1Y3R1cmVzLiBUaGUgY3JlYXRpb24gb2YgZGlmZmVyZW50IG1zZyB0eXBlcyBhcyB3 ZSBzdWdnZXN0IHNob3VsZCBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llci48L3NwYW4+PHNwYW4g bGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkZyYW5jZXNjYTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlsxXSA8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wMyI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1z ZWN1cml0eS0wMzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlsyXSA8YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL2Nvc2UvajFQM05xdDF3RVpTVEdDWU8wZ0ZTZWF6eFVZIj4N Cmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY29zZS9qMVAzTnF0MXdFWlNU R0NZTzBnRlNlYXp4VVk8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5bM10gPGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3NlLzhmS0daQk1adVVtdkphZndRb2RLcU14UUdi YyI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Nvc2UvOGZLR1pCTVp1 VW12SmFmd1FvZEtxTXhRR2JjPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpDT1NFIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpDT1NFQGlldGYub3JnIj5DT1NFQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB4424AAF0A18670E3606F1A6F5080BY2PR03MB442namprd_-- From nobody Tue Dec 8 12:34:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784EE1A6F84 for ; Tue, 8 Dec 2015 12:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9zMFgvrIAEH1 for ; Tue, 8 Dec 2015 12:34:02 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD361A6F6B for ; Tue, 8 Dec 2015 12:34:02 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-20-56673eb8cf59 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C6.9C.26997.9BE37665; Tue, 8 Dec 2015 15:34:01 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tB8KY0va013963; Tue, 8 Dec 2015 15:34:00 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tB8KXwhU017329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Dec 2015 15:33:59 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_DB7F0E0A-6DC5-449B-BFA9-0AD0688CFE61" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 8 Dec 2015 15:33:58 -0500 Message-Id: <9A8139D7-6B53-4762-9F74-ADF618797F94@mit.edu> References: <831C610E-2326-4D70-A48C-77BA8A7D2369@mit.edu> To: "cose@ietf.org" X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nrrvTLj3MYNllFotpW6eyWuyd9onF gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGWsvzqNveBWccWGW49YGhhPpXYxcnJICJhI rOi+wgphi0lcuLeerYuRi0NIYDGTRPeLl2AJIYENjBL3v0VCJB4wSSzr/8oMkmAWSJBo2HmW EcTmFdCTeHXrMliDsIC8xNZJF5hAbDYBVYnpa1rAbE6BaIkNXVNYQGwWARWJTx+2s0DM0ZFY sXYaG8QcK4l173oZIZZ1Mkp0dW0CWyYioCwx6Vgz1KmyErt/P2KawCgwC8kds5DcARHXlli2 8DUzhK0psb97OQumuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpWujlZpbopaaU bmIEh7yL6g7GCYeUDjEKcDAq8fAqnEwNE2JNLCuuzD3EKMnBpCTKG22UHibEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhLdYAyjHm5JYWZValA+TkuZgURLnnfvFN0xIID2xJDU7NbUgtQgmK8PB oSTBu84WqFGwKDU9tSItM6cEIc3EwQkynAdo+CtrkOHFBYm5xZnpEPlTjIpS4rxeIM0CIImM 0jy4XlBKSnh72PQVozjQK8K8u0CqeIDpDK77FdBgJqDBUS+TQQaXJCKkpBoYo86XnV+yv1wz w9x3Y0+9ux9LzYslrS2qIUVRZt9PPp8mt+j8nYgLBZt1289OPHMzzOjcKkNZG+Pqh9PSpdrb VikpepVZP+a52r32ZvGVzerf5gn/Tk+z+hEs3Vq8ZNX0uX89Wu23vtU5/o/jcPLbpX699q19 BsvdWB7lV/Of7c0v+OUt8mmREktxRqKhFnNRcSIAgzVcsiQDAAA= Archived-At: Cc: Mike Jones Subject: Re: [COSE] COSE Issues X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 20:34:10 -0000 --Apple-Mail=_DB7F0E0A-6DC5-449B-BFA9-0AD0688CFE61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, We haven=E2=80=99t heard any feedback from the group of whether or not = these issues should be re-opened or re-examined, so they have remained = closed. If you think they should be reopened, please let the list know. Mike, we already know you want them re-opened so please do not write = back to the list and tell us that again. Thanks. =E2=80=94 Justin, your COSE chair > On Dec 4, 2015, at 8:41 PM, Mike Jones = wrote: >=20 > Thanks Jim, for working these issues. I am content with most of the = resolutions. > =20 > I made comments on the following three issues, requesting that they be = reopened, since the actions taken to address these issues were not = clear: > =C2=B7 Elaborate on =E2=80=9Cif it is not used in the = computation of the content key=E2=80=9D #35 = > =C2=B7 Is a =E2=80=9Cdirect key=E2=80=9D sent in the clear? = #36 > =C2=B7 Require publicly visible stable specifications for IANA = registrations #39 > =20 > -- = Mike > =20 > P.S. My apologies to the working group for my being tardy in = reviewing these resolutions. I=E2=80=99ve had an extremely full plate = the last few weeks, including revising JOSE and OAuth drafts to get them = ready for IETF review in time for the telechat on December 17th, working = on draft-wahlstroem-ace-cbor-web-token and draft-jones-oauth-discovery, = and taking time off for the US Thanksgiving holiday J. > =20 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Monday, November 30, 2015 7:30 AM > To: cose@ietf.org > Subject: [COSE] COSE Issues > =20 > Having heard no complaints on the latest change set, the chairs are = closing all issues marked as =E2=80=9Ccompleted=E2=80=9D today. You = should see most of the notifications pepper through to the list shortly = (though our github integration is special at best). If you believe any = of these issues is in need of re-examination, we can always re-open them = or you can file a new issue against the current document. > =20 > Thank you all, > =E2=80=94 Justin, your COSE chair > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose = --Apple-Mail=_DB7F0E0A-6DC5-449B-BFA9-0AD0688CFE61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks,

We = haven=E2=80=99t heard any feedback from the group of whether or not = these issues should be re-opened or re-examined, so they have remained = closed. If you think they should be reopened, please let the list = know.

Mike, we = already know you want them re-opened so please do not write back to the = list and tell us that again. Thanks.

 =E2=80=94 Justin, your COSE = chair

On Dec 4, 2015, at 8:41 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks Jim, for = working these issues.  I am content with most of the = resolutions.

 

I made comments on the = following three issues, requesting that they be reopened, since the = actions taken to address these issues were not clear:

=C2=B7         Elaborate on =E2=80=9Cif it is not used in the computation of = the content key=E2=80=9D #35

=C2=B7         Is a =E2=80=9Cdirect key=E2=80=9D sent in the = clear? #36

=C2=B7         Require publicly visible stable specifications for IANA = registrations #39

 

         =             &n= bsp;           &nbs= p;            =             &n= bsp;     -- Mike

 

P.S.  My apologies to the working group for = my being tardy in reviewing these resolutions.  I=E2=80=99ve had an = extremely full plate the last few weeks, including revising JOSE and = OAuth drafts to get them ready for IETF review in time for the telechat on December 17th, working on = draft-wahlstroem-ace-cbor-web-token and draft-jones-oauth-discovery, and = taking time off for the US Thanksgiving holiday J.

 

-----Original = Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Monday, November 30, 2015 7:30 AM
To: cose@ietf.org
Subject: [COSE] COSE Issues

 

Having heard no = complaints on the latest change set, the chairs are closing all issues = marked as =E2=80=9Ccompleted=E2=80=9D today. You should see most of the = notifications pepper through to the list shortly (though our github = integration is special at best). If you believe any of these issues is in need of = re-examination, we can always re-open them or you can file a new issue = against the current document.

 

Thank you all,

=E2=80=94 Justin, your COSE chair

_______________________________________________

COSE mailing list

COSE@ietf.org

https://www.ietf.org/mailman/listinfo/cose


= --Apple-Mail=_DB7F0E0A-6DC5-449B-BFA9-0AD0688CFE61-- From nobody Tue Dec 8 13:05:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139081A7000 for ; Tue, 8 Dec 2015 13:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 NWgtARJt14df for ; Tue, 8 Dec 2015 13:05:16 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 2B61D1A6FC2 for ; Tue, 8 Dec 2015 13:05:16 -0800 (PST) Received: by qgeb1 with SMTP id b1so37162456qge.1 for ; Tue, 08 Dec 2015 13:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rzCX5R9L4IoFjLWcWVjILviPtL7jY5yhrz5LiqhDh58=; b=b17EJ+SKJmIqZLdEtgiRcmCrFILR6Bh07+bY7RR2WdMx9xMqJPg8ZYk7Hfh/azMBvt sGxuF2zX9de57812KfE85/AYpcy9ogS/yQCslhnHNJ24QdHHsbr0hyVQWXiE0Cm909pI HscqtDiWQU0jhmbjc28WNDQbv67jJr/SMUVdXqs0lwCPyIrqaAajbf5AyGu9o/NplpwR RhC1lGFV6BBIqVUWcrHPaGHqfHfOP+y9l1o4T50MYy0OClboB3C+EUYwVODqm63fZI5b d0ruh0Z4xaaJF4+tu6LMFUdJjiE8RVjfVPE3Sh81oeKIRlAAK//UcQR4sHXC5MKMT8cn eudw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rzCX5R9L4IoFjLWcWVjILviPtL7jY5yhrz5LiqhDh58=; b=OWSr24pxvrSdsWksjglZmxSzMctLTlC+cJ1PTIjzK20BPoDumzDcwrzhr1CP4V5RjX RlE2gF20H92yQfKpVVo4MnhKXQfe/0X4ET3RkOMeXcfqF6jW+N6wN5JcxMrvPBIR6jLv FH5CUWXp05IgUqhh8+xsoGu2g42FuxGplAe27A67nQIjDi26L3IMeil6pxGjZlrRZyna jBoxATxVEhqww5gwnby4EO5DJtMcKrE6jqnuQk7aAywhsyRNiNfH/NF5JX3FGO3ZkvUe 03Ck1sC5VVo+4bJ+LH6vyVU2+yB+x8xxyHWEZDxRQO7LZJIeD4TUn51jktXhlRVlMXzc cUZA== X-Gm-Message-State: ALoCoQmG9N2Zhhhh+ZRY2tq9gvznkqvfH44xIPVOGF6Jdus2nLQv0MG19g74LUpx6mlD3o9P5OCs8ItzzsUWzKy64Uy5cbPIdg== X-Received: by 10.140.160.69 with SMTP id g66mr7528296qhg.86.1449608714566; Tue, 08 Dec 2015 13:05:14 -0800 (PST) Received: from [192.168.8.101] ([181.202.66.86]) by smtp.gmail.com with ESMTPSA id x129sm2300017qhc.33.2015.12.08.13.05.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 13:05:13 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3521A346-1B2E-4D10-BB9F-1A01BB1D5F0E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <9A8139D7-6B53-4762-9F74-ADF618797F94@mit.edu> Date: Tue, 8 Dec 2015 18:05:08 -0300 Message-Id: <55E01E33-4096-4937-B101-5A3F6CC6214A@ve7jtb.com> References: <831C610E-2326-4D70-A48C-77BA8A7D2369@mit.edu> <9A8139D7-6B53-4762-9F74-ADF618797F94@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Michael Jones , "cose@ietf.org" Subject: Re: [COSE] COSE Issues X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:05:19 -0000 --Apple-Mail=_3521A346-1B2E-4D10-BB9F-1A01BB1D5F0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry I have been a touch preoccupied myself. For #35 Jim pointed to cose-wg/cose-spec@d5e2de2 = stating that addressed the issue. There is a update to sec = 12.1.2 Direct Key with KDF but I don=E2=80=99t see a change to 12.1. If something was missed then we should re-open. For #36 Jim changed supplied to identified key in 12.1.1 I think that = resolves the issue but Mike should double check, if that was what he was = getting at. For #37 a reference to RFC4949 was added in sec 12.4 and looks closed to = me. John B. > On Dec 8, 2015, at 5:33 PM, Justin Richer wrote: >=20 > Folks, >=20 > We haven=E2=80=99t heard any feedback from the group of whether or not = these issues should be re-opened or re-examined, so they have remained = closed. If you think they should be reopened, please let the list know. >=20 > Mike, we already know you want them re-opened so please do not write = back to the list and tell us that again. Thanks. >=20 > =E2=80=94 Justin, your COSE chair >=20 >> On Dec 4, 2015, at 8:41 PM, Mike Jones > wrote: >>=20 >> Thanks Jim, for working these issues. I am content with most of the = resolutions. >> =20 >> I made comments on the following three issues, requesting that they = be reopened, since the actions taken to address these issues were not = clear: >> =C2=B7 Elaborate on =E2=80=9Cif it is not used in the = computation of the content key=E2=80=9D #35 = >> =C2=B7 Is a =E2=80=9Cdirect key=E2=80=9D sent in the clear? = #36 >> =C2=B7 Require publicly visible stable specifications for = IANA registrations #39 = >> =20 >> -- = Mike >> =20 >> P.S. My apologies to the working group for my being tardy in = reviewing these resolutions. I=E2=80=99ve had an extremely full plate = the last few weeks, including revising JOSE and OAuth drafts to get them = ready for IETF review in time for the telechat on December 17th, working = on draft-wahlstroem-ace-cbor-web-token and draft-jones-oauth-discovery, = and taking time off for the US Thanksgiving holiday J. >> =20 >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Justin Richer >> Sent: Monday, November 30, 2015 7:30 AM >> To: cose@ietf.org >> Subject: [COSE] COSE Issues >> =20 >> Having heard no complaints on the latest change set, the chairs are = closing all issues marked as =E2=80=9Ccompleted=E2=80=9D today. You = should see most of the notifications pepper through to the list shortly = (though our github integration is special at best). If you believe any = of these issues is in need of re-examination, we can always re-open them = or you can file a new issue against the current document. >> =20 >> Thank you all, >> =E2=80=94 Justin, your COSE chair >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose = > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_3521A346-1B2E-4D10-BB9F-1A01BB1D5F0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry I have been a touch preoccupied myself.

For #35 Jim pointed = to cose-wg/cose-spec@d5e2de2 stating that addressed the issue. =  There is a update to sec 12.1.2 Direct Key with KDF but I don=E2=80=99= t see a change to 12.1.
If something was missed = then we should re-open.

For #36 Jim changed supplied to identified key in 12.1.1 I = think that resolves the issue but Mike should double check, if that was = what he was getting at.

For #37 a reference to RFC4949 was added in sec 12.4 and = looks closed to me.

John B.

On Dec 8, 2015, at 5:33 PM, = Justin Richer <jricher@mit.edu> wrote:

Folks,

We haven=E2=80=99t heard any = feedback from the group of whether or not these issues should be = re-opened or re-examined, so they have remained closed. If you think = they should be reopened, please let the list know.

Mike, we already know you want = them re-opened so please do not write back to the list and tell us that = again. Thanks.

 =E2=80=94 Justin, your COSE = chair

On Dec 4, 2015, at 8:41 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks = Jim, for working these issues.  I am content with most of the = resolutions.
 
I made comments on the following three issues, requesting = that they be reopened, since the actions taken to address these issues = were not clear:
=C2=B7         Elaborate on =E2=80=9Cif it is not used in the computation of the = content key=E2=80=9D #35
=C2=B7         Is = a =E2=80=9Cdirect key=E2=80=9D sent in the clear? #36
=C2=B7         Require publicly visible stable specifications for IANA = registrations #39
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
P.S.  My apologies to the working = group for my being tardy in reviewing these resolutions.  I=E2=80=99v= e had an extremely full plate the last few weeks, including revising = JOSE and OAuth drafts to get them ready for IETF review in time for the = telechat on December 17th, working on = draft-wahlstroem-ace-cbor-web-token and draft-jones-oauth-discovery, and = taking time off for the US Thanksgiving holiday J.
 
-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Monday, November 30, 2015 7:30 AM
To: cose@ietf.org
Subject: [COSE] COSE Issues
 
Having heard no complaints on the latest change set, the = chairs are closing all issues marked as =E2=80=9Ccompleted=E2=80=9D = today. You should see most of the notifications pepper through to the = list shortly (though our github integration is special at best). If you = believe any of these issues is in need of re-examination, we can always = re-open them or you can file a new issue against the current = document.
 
Thank you all,
=E2=80=94 Justin, your COSE chair
_______________________________________________
COSE = mailing list
https://www.ietf.org/mailman/listinfo/cose

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

= --Apple-Mail=_3521A346-1B2E-4D10-BB9F-1A01BB1D5F0E-- From nobody Tue Dec 8 13:19:35 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652C11A87E6 for ; Tue, 8 Dec 2015 13:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ezhsFq0FUzzu for ; Tue, 8 Dec 2015 13:19:31 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 4AEE61A87E4 for ; Tue, 8 Dec 2015 13:19:31 -0800 (PST) Received: by qgcc31 with SMTP id c31so37890548qgc.3 for ; Tue, 08 Dec 2015 13:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Fvvx7wltNDzcckflm4C+Z98qgY7CyybUw0E0FLirsVI=; b=pTE+SAs4pB+Fq6mEsI7YBHmDHJrQwC3h10C0grAJyQgBqvaybTQeSO/t9YO1QeqbZk UYZG028n2lh/ohoWMntUOLeCeQWxXT82hAOXlqXCEr56WUMo71i04embJ/65lPrn3Uwo jPRuDjAvGb3hQMpvrTAZXP+7dYc95QNiippMNv6+p7pz1eGjKb8PA904EUS7NEK3hBgF ajSV3D16q1mi9lWZYlkgsl8+jG/XzH2/uBuck6GkvFAd3fWEcrg5Chc0Wlg27jTieiWJ s6Fz8nacGiZQNyc7a9haCZX5OP4CAutWvNlJ4jdyqVRzNdNW/+nUMHc0/vKNDJ0f4fj3 +R0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Fvvx7wltNDzcckflm4C+Z98qgY7CyybUw0E0FLirsVI=; b=FiGa9EQGSwVcKhOENcY2U4r1CWOrJmPoBR1ZsDLusGVdPKX52D+Fpd7paAYxb+e/os dF6PG9BgrU134V98UQzHvlhykU0S+03WzxX3/DOhnATtkh4PrdbYJhP0uZmB2X8yyFdU xvD5UPxaW0KoJ3PiO7QpjrxqEI8vjuLUdhq9XxSjAoWi+/XflZCEo7eZAZYUTs3dc/t/ l1V4xLgm1BYd6GDg5TM9EN99GmFgdJr+NUAPufFW0Q0+cuvK60DhFvToDFamAdjhWg8G H3dX/P26VyOru4j5+tuqKljyCiBeoqJD79+f/iP3kQw7owjA5Wi3XhHottm1cBciPyLn f7IA== X-Gm-Message-State: ALoCoQkuKrhTjZi2ezwu0Ekku8LGfUeEcZW9vZNMt6d3VRB9k6r7k9/15GdVRc26aoGlqhanex5I9pxM1D4Cie5NELGYU47Izw== X-Received: by 10.55.195.216 with SMTP id r85mr2747927qkl.4.1449609570392; Tue, 08 Dec 2015 13:19:30 -0800 (PST) Received: from [192.168.8.101] ([181.202.66.86]) by smtp.gmail.com with ESMTPSA id t77sm2344401qhb.3.2015.12.08.13.19.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 13:19:29 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_405C4C03-A5F8-46DE-A224-33EEED776A3C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <55E01E33-4096-4937-B101-5A3F6CC6214A@ve7jtb.com> Date: Tue, 8 Dec 2015 18:19:23 -0300 Message-Id: References: <831C610E-2326-4D70-A48C-77BA8A7D2369@mit.edu> <9A8139D7-6B53-4762-9F74-ADF618797F94@mit.edu> <55E01E33-4096-4937-B101-5A3F6CC6214A@ve7jtb.com> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Michael Jones , "cose@ietf.org" Subject: Re: [COSE] COSE Issues X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:19:34 -0000 --Apple-Mail=_405C4C03-A5F8-46DE-A224-33EEED776A3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry I mistook #39 for #37 For #39 I tend to be on the side of you need to publicly document it if = you are going to reserve it.=20 I think we need more input on this from the WG, and at-least a update = to the guidance for the DE if we expect them to monitor and remove code = points issued in the low positive range that don=E2=80=99t have a = specification forthcoming. I would at-least prefer to see a ID before = granting a early registration. John B. > On Dec 8, 2015, at 6:05 PM, John Bradley wrote: >=20 > Sorry I have been a touch preoccupied myself. >=20 > For #35 Jim pointed to cose-wg/cose-spec@d5e2de2 = stating that addressed the issue. There is a update to sec = 12.1.2 Direct Key with KDF but I don=E2=80=99t see a change to 12.1. > If something was missed then we should re-open. >=20 > For #36 Jim changed supplied to identified key in 12.1.1 I think that = resolves the issue but Mike should double check, if that was what he was = getting at. >=20 > For #37 a reference to RFC4949 was added in sec 12.4 and looks closed = to me. >=20 > John B. >=20 >> On Dec 8, 2015, at 5:33 PM, Justin Richer > wrote: >>=20 >> Folks, >>=20 >> We haven=E2=80=99t heard any feedback from the group of whether or = not these issues should be re-opened or re-examined, so they have = remained closed. If you think they should be reopened, please let the = list know. >>=20 >> Mike, we already know you want them re-opened so please do not write = back to the list and tell us that again. Thanks. >>=20 >> =E2=80=94 Justin, your COSE chair >>=20 >>> On Dec 4, 2015, at 8:41 PM, Mike Jones > wrote: >>>=20 >>> Thanks Jim, for working these issues. I am content with most of the = resolutions. >>> =20 >>> I made comments on the following three issues, requesting that they = be reopened, since the actions taken to address these issues were not = clear: >>> =C2=B7 Elaborate on =E2=80=9Cif it is not used in the = computation of the content key=E2=80=9D #35 = >>> =C2=B7 Is a =E2=80=9Cdirect key=E2=80=9D sent in the clear? = #36 >>> =C2=B7 Require publicly visible stable specifications for = IANA registrations #39 = >>> =20 >>> -- = Mike >>> =20 >>> P.S. My apologies to the working group for my being tardy in = reviewing these resolutions. I=E2=80=99ve had an extremely full plate = the last few weeks, including revising JOSE and OAuth drafts to get them = ready for IETF review in time for the telechat on December 17th, working = on draft-wahlstroem-ace-cbor-web-token and draft-jones-oauth-discovery, = and taking time off for the US Thanksgiving holiday J. >>> =20 >>> -----Original Message----- >>> From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Justin Richer >>> Sent: Monday, November 30, 2015 7:30 AM >>> To: cose@ietf.org >>> Subject: [COSE] COSE Issues >>> =20 >>> Having heard no complaints on the latest change set, the chairs are = closing all issues marked as =E2=80=9Ccompleted=E2=80=9D today. You = should see most of the notifications pepper through to the list shortly = (though our github integration is special at best). If you believe any = of these issues is in need of re-examination, we can always re-open them = or you can file a new issue against the current document. >>> =20 >>> Thank you all, >>> =E2=80=94 Justin, your COSE chair >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose = >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose = --Apple-Mail=_405C4C03-A5F8-46DE-A224-33EEED776A3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry I mistook #39 for #37

For #39  I tend to be on the side = of you need to publicly document it if you are going to reserve = it. 
I think we need more input on this from = the WG,  and at-least a update to the guidance for the DE if we = expect them to monitor and remove code points issued in the low positive = range that don=E2=80=99t have a specification forthcoming.   =  I would at-least prefer to see a ID before granting a early = registration.

John B.
On Dec 8, 2015, at 6:05 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:

Sorry I have = been a touch preoccupied myself.

For #35 Jim pointed to cose-wg/cose-spec@d5e2de2 stating that addressed the issue. =  There is a update to sec 12.1.2 Direct Key with KDF but I don=E2=80=99= t see a change to 12.1.
If something was missed = then we should re-open.

For #36 Jim changed supplied to identified key in 12.1.1 I = think that resolves the issue but Mike should double check, if that was = what he was getting at.

For #37 a reference to RFC4949 was added in sec 12.4 and = looks closed to me.

John B.

On Dec = 8, 2015, at 5:33 PM, Justin Richer <jricher@mit.edu> wrote:

Folks,

We haven=E2=80=99t heard any = feedback from the group of whether or not these issues should be = re-opened or re-examined, so they have remained closed. If you think = they should be reopened, please let the list know.

Mike, we already know you want = them re-opened so please do not write back to the list and tell us that = again. Thanks.

 =E2=80=94 Justin, your COSE = chair

On Dec 4, 2015, at 8:41 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks = Jim, for working these issues.  I am content with most of the = resolutions.
 
I made comments on the following three issues, requesting = that they be reopened, since the actions taken to address these issues = were not clear:
=C2=B7         Elaborate on =E2=80=9Cif it is not used in the computation of the = content key=E2=80=9D #35
=C2=B7         Is = a =E2=80=9Cdirect key=E2=80=9D sent in the clear? #36
=C2=B7         Require publicly visible stable specifications for IANA = registrations #39
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
P.S.  My apologies to the working = group for my being tardy in reviewing these resolutions.  I=E2=80=99v= e had an extremely full plate the last few weeks, including revising = JOSE and OAuth drafts to get them ready for IETF review in time for the = telechat on December 17th, working on = draft-wahlstroem-ace-cbor-web-token and draft-jones-oauth-discovery, and = taking time off for the US Thanksgiving holiday J.
 
-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Monday, November 30, 2015 7:30 AM
To: cose@ietf.org
Subject: [COSE] COSE Issues
 
Having heard no complaints on the latest change set, the = chairs are closing all issues marked as =E2=80=9Ccompleted=E2=80=9D = today. You should see most of the notifications pepper through to the = list shortly (though our github integration is special at best). If you = believe any of these issues is in need of re-examination, we can always = re-open them or you can file a new issue against the current = document.
 
Thank you all,
=E2=80=94 Justin, your COSE chair
_______________________________________________
COSE = mailing list
https://www.ietf.org/mailman/listinfo/cose

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


= --Apple-Mail=_405C4C03-A5F8-46DE-A224-33EEED776A3C-- From nobody Tue Dec 8 13:31:47 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0E21A88D2 for ; Tue, 8 Dec 2015 13:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 EkvhfqwFcKvr for ; Tue, 8 Dec 2015 13:31:43 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FB01A8848 for ; Tue, 8 Dec 2015 13:31:43 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id EFE172C9F2; Tue, 8 Dec 2015 13:31:42 -0800 (PST) From: "Jim Schaad" To: "Jones Mike" References: In-Reply-To: Date: Tue, 8 Dec 2015 13:28:40 -0800 Message-ID: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_02FB_01D131BC.647E5A70" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJY+7PJPQiRbWKu9aVD9Lyha8uQhAGyX8GTnaRt5eA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:31:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FB_01D131BC.647E5A70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02FC_01D131BC.647E8180" ------=_NextPart_001_02FC_01D131BC.647E8180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I do not believe that invoking security is incorrect in this instance. = The statement that security issues tend to arise on parsing is not = something I would accept as a given. I have probably seen just as many = or more problems with building strings, random number generation, timing = attacks as I have seen parsing errors. I don=E2=80=99t think that is a = supportable proposition. =20 You and I have different ideas on what it means to =E2=80=9Ckeep things = simple=E2=80=9D. For me, one way of doing things without options is = always simpler and less prone to error. Thus to me having a fixed array = is the simpler option. It does not matter if the specific = implementation does or does not support external aad, creating the one = additional field in the array is not the same burden as the same thing = is going to be for those implementations that do implement the external = aad feature. Making it optional introduces a new state into the system = of a zero length aad which is different from no aad. =20 Again in my opinion =E2=80=93 the current version is simpler that what = you are proposing. =20 Jim =20 =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 12:39 PM To: cose-wg/cose-issues Cc: Jim Schaad Subject: Re: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 Invoking security seems incorrect and overstated here. These values are = never parsed - which is when security issues tend to arise. They are = just created internally and then used as serialized byte array inputs to = cryptographic operations. There is no security problem with having both = 3-member and 4-member array values for this intermediate temporary = result. Please capitalize on this opportunity to "keep simple things simple" - = one of the working group principles stated by the chairs on slide 22 of = their opening presentation at = https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. = Especially in light of the fact that many implementations won't need = support for external_aad, per issue #50 = , please make these = implementations simpler by making the presence of the external_aad array = member optional. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_02FC_01D131BC.647E8180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I do not believe that invoking security is incorrect in this = instance.=C2=A0 The statement that security issues tend to arise on = parsing is not something I would accept as a given.=C2=A0 I have = probably seen just as many or more problems with building strings, = random number generation, timing attacks as I have seen parsing = errors.=C2=A0=C2=A0 I don=E2=80=99t think that is a supportable = proposition.

 

You and I have different ideas on what it means to =E2=80=9Ckeep things = simple=E2=80=9D.=C2=A0 For me, one way of doing things without options = is always simpler and less prone to error.=C2=A0 Thus to me having a = fixed array is the simpler option.=C2=A0 It does not matter if the = specific implementation does or does not support external aad, creating = the one additional field in the array is not the same burden as the same = thing is going to be for those implementations that do implement the = external aad feature.=C2=A0 Making it optional introduces a new state = into the system of a zero length aad which is different from no = aad.

 

Again in my opinion =E2=80=93 the current version is simpler that what = you are proposing.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:notifications@github.com]
Sent: Tuesday, = December 08, 2015 12:39 PM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-issues] Move = external_aad to the end of structures using it and make its presence = optional (#48)

 

Invoking security seems = incorrect and overstated here. These values are never parsed - which is = when security issues tend to arise. They are just created internally and = then used as serialized byte array inputs to cryptographic operations. = There is no security problem with having both 3-member and 4-member = array values for this intermediate temporary = result.

Please capitalize on this opportunity to = "keep simple things simple" - one of the working group = principles stated by the chairs on slide 22 of their opening = presentation at = https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. = Especially in light of the fact that many implementations won't need = support for external_aad, per issue #50, please make these implementations simpler by = making the presence of the external_aad array member = optional.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_02FC_01D131BC.647E8180-- ------=_NextPart_000_02FB_01D131BC.647E5A70 Content-Type: image/jpeg; name="~WRD000.jpg" Content-Transfer-Encoding: base64 Content-ID: <~WRD000.jpg> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== ------=_NextPart_000_02FB_01D131BC.647E5A70-- From nobody Tue Dec 8 13:32:26 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D731A8928 for ; Tue, 8 Dec 2015 13:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 6Jii9gWUM1_T for ; Tue, 8 Dec 2015 13:32:23 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8951A8915 for ; Tue, 8 Dec 2015 13:32:11 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id AC16538EEA; Tue, 8 Dec 2015 13:32:10 -0800 (PST) From: "Jim Schaad" To: "Jones Mike" References: In-Reply-To: Date: Tue, 8 Dec 2015 13:29:25 -0800 Message-ID: <030001d131ff$8320ee50$8962caf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0301_01D131BC.74FF5C00" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQKEFiEzy1pKG9qWtcxujbuoFG8zWgJZjpJYnUkGH+A= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBJcyBhIOKAnGRpcmVjdCBrZXnigJ0g?= =?utf-8?q?sent_in_the_clear=3F_=28=2336=29?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:32:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0301_01D131BC.74FF5C00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0302_01D131BC.74FF8310" ------=_NextPart_001_0302_01D131BC.74FF8310 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You mean text like =20 The direct encryption class algorithms share a secret between the sender = and the recipient that is used either directly or after manipulation as = the content key. =20 Which is from section 12.1? =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 1:08 PM To: cose-wg/cose-issues Cc: Jim Schaad Subject: Re: [cose-issues] Is a =E2=80=9Cdirect key=E2=80=9D sent in the = clear? (#36) =20 This change helps some. Things would still be much clearer if the text = explicitly said something along the lines of "The direct key is known to = the two parties and not transmitted as part of the message." Thanks. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_0302_01D131BC.74FF8310 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

You mean text like

 

The direct encryption = class algorithms share a secret between the sender and the recipient = that is used either directly or after manipulation as the content = key.

 

Which is from section 12.1?

 

From:<= /b> = Mike Jones [mailto:notifications@github.com]
Sent: Tuesday, = December 08, 2015 1:08 PM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-issues] Is a = =E2=80=9Cdirect key=E2=80=9D sent in the clear? = (#36)

 

This change helps some. Things = would still be much clearer if the text explicitly said something along = the lines of "The direct key is known to the two parties and not = transmitted as part of the message." Thanks.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_0302_01D131BC.74FF8310-- ------=_NextPart_000_0301_01D131BC.74FF5C00 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_0301_01D131BC.74FF5C00-- From nobody Tue Dec 8 13:35:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2B91A8837 for ; Tue, 8 Dec 2015 13:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 YZe3Wxyeuczp for ; Tue, 8 Dec 2015 13:35:01 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2401A8880 for ; Tue, 8 Dec 2015 13:35:01 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 5A6F52CA29; Tue, 8 Dec 2015 13:35:01 -0800 (PST) From: "Jim Schaad" To: "Jones Mike" References: In-Reply-To: Date: Tue, 8 Dec 2015 13:32:15 -0800 Message-ID: <030601d131ff$e8d8f850$ba8ae8f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0307_01D131BC.DAB78D10" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQEwVcYikThpA/XjGYy62Zs6go30SgMBDom+n+tLftA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Elaborate_on_=E2=80=9Cif_it_is?= =?utf-8?q?_not_used_in_the_computation_of_the_content_key=E2=80=9D_=28=23?= =?utf-8?b?MzUp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:35:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0307_01D131BC.DAB78D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0308_01D131BC.DAB78D10" ------=_NextPart_001_0308_01D131BC.DAB78D10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So from section 12.1.1 =20 When this algorithm is used, the protected field MUST be zero length. =20 >From section 12.1.2 =20 The 'protected' field can be of non-zero length. The 'protected' field = is copied into the SuppPubInfo.protected field of the context structure. =20 I think that covers it more than sufficiently. =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 1:02 PM To: cose-wg/cose-issues Cc: Jim Schaad Subject: Re: [cose-issues] Elaborate on =E2=80=9Cif it is not used in = the computation of the content key=E2=80=9D (#35) =20 Reading the commit, I can't find the text you're referring to. For = instance, I searched for "null" and the string didn't appear in the = commit. Can you please quote the text you're referring to, Jim so I can = review it? Thanks. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_0308_01D131BC.DAB78D10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

So from section 12.1.1

 

When this algorithm is = used, the protected field MUST be zero length.

 

From section = 12.1.2

 

The 'protected' field can be of non-zero length. The = 'protected' field is copied into the SuppPubInfo.protected field of the = context structure.

 

I think that = covers it more than sufficiently.

 

From:<= /b> = Mike Jones [mailto:notifications@github.com]
Sent: Tuesday, = December 08, 2015 1:02 PM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-issues] = Elaborate on =E2=80=9Cif it is not used in the computation of the = content key=E2=80=9D (#35)

 

Reading the commit, I can't = find the text you're referring to. For instance, I searched for = "null" and the string didn't appear in the commit. Can you = please quote the text you're referring to, Jim so I can review it? = Thanks.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_0308_01D131BC.DAB78D10-- ------=_NextPart_000_0307_01D131BC.DAB78D10 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_0307_01D131BC.DAB78D10-- From nobody Tue Dec 8 13:47:24 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC571A8A20 for ; Tue, 8 Dec 2015 13:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qDxzTNvWCfhw for ; Tue, 8 Dec 2015 13:47:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E2D1A8A27 for ; Tue, 8 Dec 2015 13:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vWWKc1/Jsh+MjE8/iAZlba12xQfP/HiBIw7LRk7FYCU=; b=lCvGik0Hwuc1/HyGrtOV4Z8RoyL0Xhpx6xupPIMrlokZVlB5oJmi43NSbVNPPWWg7F41lTxvK6g8c3aDQDWgIZuj1zGzo4RkVAyWWey/0WhjBD/W1jknnyIV93NwLq9NNdG9UTm58tUjFDxt+G+Pj2MWp+TL02Zd48UN7z/W/ug= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 8 Dec 2015 21:46:51 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 8 Dec 2015 21:46:51 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: =?utf-8?B?W2Nvc2UtaXNzdWVzXSBFbGFib3JhdGUgb24g4oCcaWYgaXQgaXMgbm90IHVz?= =?utf-8?B?ZWQgaW4gdGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleeKAnSAo?= =?utf-8?Q?#35)?= Thread-Index: AQHRMgBNXEne0nX4aUeKnfaqSb0/mp7Bnizw Date: Tue, 8 Dec 2015 21:46:50 +0000 Message-ID: References: <030601d131ff$e8d8f850$ba8ae8f0$@augustcellars.com> In-Reply-To: <030601d131ff$e8d8f850$ba8ae8f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:5zQEVAr1eYVtzNAI5ti3350MnPwa3xlYgEBu5VYXA0xGga5fWKwCVtYrlWRE5vL4vxDanKtmE+TSXuBfKuQo7UfNpC0wBOZWq+EHYY/UKw8gL6WfdbTcKkwSVuaE8AV8NzXzB/edA3amlyODMFyUKQ==; 24:eHJR0g0l+BUvm4IkVDwaC2g/zposCQnLbri94W80uQFDb+eMGK5gvSfuRIZmUw39GERrOa1xQSTR9MF88X1kUfTsLvJumGI6f0WPpHNNoDU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0784C803FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(51444003)(164054003)(52604005)(377454003)(110136002)(19609705001)(8990500004)(18206015028)(5005710100001)(5003600100002)(189998001)(10400500002)(2950100001)(2900100001)(86612001)(77096005)(19627595001)(10290500002)(19617315012)(97736004)(5008740100001)(40100003)(10090500001)(99936001)(5001960100002)(1220700001)(81156007)(15975445007)(790700001)(586003)(6116002)(5002640100001)(1096002)(122556002)(50986999)(76576001)(19625215002)(33656002)(17760045003)(101416001)(86362001)(19300405004)(99286002)(102836003)(19580395003)(19580405001)(11100500001)(74316001)(5004730100002)(87936001)(92566002)(76176999)(16236675004)(54356999)(106116001)(105586002)(106356001)(7099028)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 21:46:50.9069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Elaborate_on_=E2=80=9Cif_it_is?= =?utf-8?q?_not_used_in_the_computation_of_the_content_key=E2=80=9D_=28=23?= =?utf-8?b?MzUp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:47:20 -0000 --_004_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_" --_000_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0sg4oCTIHRoYW5rcyBmb3Igc3VwcGx5aW5nIHRoZSBleHBsaWNpdCB0ZXh0IHlvdSB3ZXJlIHJl ZmVycmluZyB0by4gIEkgYWdyZWUgdGhhdCB0aGVzZSB0d28gYWRkaXRpb25hbCBzdGF0ZW1lbnRz IHN1ZmZpY2llbnRseSBxdWFsaWZ5IHRoZSBpbml0aWFsIHN0YXRlbWVudCB0aGF0IG15IGNvbW1l bnQgd2FzIGFib3V0IOKAnFRoZSAncHJvdGVjdGVkJyBmaWVsZCBNVVNUIGJlIGEgemVybyBsZW5n dGggaXRlbSBpZiBpdCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRl bnQga2V5LuKAnSBpbiBhIHdheSB0aGF0IG1ha2VzIHRoZSBvdmVyYWxsIG1lYW5pbmcgdW5hbWJp Z3VvdXMgd2hlbiByZWFkIHRvZ2V0aGVyLg0KDQpUbyBtYWtlIGl0IGVhc2llciBmb3IgcmVhZGVy cyB0byB0aWUgdGhlIHR3byBjb250ZXh0cyB0b2dldGhlciwgY291bGQgeW91IHBsZWFzZSBjaGFu Z2U6IOKAnFRoZSAncHJvdGVjdGVkJyBmaWVsZCBNVVNUIGJlIGEgemVybyBsZW5ndGggaXRlbSBp ZiBpdCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V5LuKA nSB0byDigJxUaGUgJ3Byb3RlY3RlZCcgZmllbGQgTVVTVCBiZSBhIHplcm8gbGVuZ3RoIGl0ZW0g aWYgaXQgaXMgbm90IHVzZWQgaW4gdGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleSAo YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMTIuMS4yKS7igJ0NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxh cnMuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgOCwgMjAxNSAxOjMyIFBNDQpUbzogTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IGNvc2VAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBbY29zZS1pc3N1ZXNdIEVsYWJvcmF0ZSBvbiDigJxpZiBpdCBpcyBub3Qg dXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V54oCdICgjMzUpDQoNClNv IGZyb20gc2VjdGlvbiAxMi4xLjENCg0KV2hlbiB0aGlzIGFsZ29yaXRobSBpcyB1c2VkLCB0aGUg cHJvdGVjdGVkIGZpZWxkIE1VU1QgYmUgemVybyBsZW5ndGguDQoNCkZyb20gc2VjdGlvbiAxMi4x LjINCg0KVGhlICdwcm90ZWN0ZWQnIGZpZWxkIGNhbiBiZSBvZiBub24temVybyBsZW5ndGguIFRo ZSAncHJvdGVjdGVkJyBmaWVsZCBpcyBjb3BpZWQgaW50byB0aGUgU3VwcFB1YkluZm8ucHJvdGVj dGVkIGZpZWxkIG9mIHRoZSBjb250ZXh0IHN0cnVjdHVyZS4NCg0KSSB0aGluayB0aGF0IGNvdmVy cyBpdCBtb3JlIHRoYW4gc3VmZmljaWVudGx5Lg0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86 bm90aWZpY2F0aW9uc0BnaXRodWIuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDgsIDIw MTUgMTowMiBQTQ0KVG86IGNvc2Utd2cvY29zZS1pc3N1ZXMgPGNvc2UtaXNzdWVzQG5vcmVwbHku Z2l0aHViLmNvbTxtYWlsdG86Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tPj4NCkNjOiBK aW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxh cnMuY29tPj4NClN1YmplY3Q6IFJlOiBbY29zZS1pc3N1ZXNdIEVsYWJvcmF0ZSBvbiDigJxpZiBp dCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V54oCdICgj MzUpDQoNCg0KUmVhZGluZyB0aGUgY29tbWl0LCBJIGNhbid0IGZpbmQgdGhlIHRleHQgeW91J3Jl IHJlZmVycmluZyB0by4gRm9yIGluc3RhbmNlLCBJIHNlYXJjaGVkIGZvciAibnVsbCIgYW5kIHRo ZSBzdHJpbmcgZGlkbid0IGFwcGVhciBpbiB0aGUgY29tbWl0LiBDYW4geW91IHBsZWFzZSBxdW90 ZSB0aGUgdGV4dCB5b3UncmUgcmVmZXJyaW5nIHRvLCBKaW0gc28gSSBjYW4gcmV2aWV3IGl0PyBU aGFua3MuDQoNCuKAlA0KUmVwbHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSBvciB2aWV3IGl0IG9u IEdpdEh1YjxodHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9jb3NlLWlzc3Vlcy9pc3N1ZXMvMzUj aXNzdWVjb21tZW50LTE2MzAxNjc1MT4uDQo= --_000_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5PSyDigJMgdGhhbmtzIGZvciBzdXBwbHlp bmcgdGhlIGV4cGxpY2l0IHRleHQgeW91IHdlcmUgcmVmZXJyaW5nIHRvLiZuYnNwOyBJIGFncmVl IHRoYXQgdGhlc2UgdHdvIGFkZGl0aW9uYWwgc3RhdGVtZW50cyBzdWZmaWNpZW50bHkgcXVhbGlm eSB0aGUgaW5pdGlhbCBzdGF0ZW1lbnQgdGhhdA0KIG15IGNvbW1lbnQgd2FzIGFib3V0IOKAnDwv c3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+VGhlICdwcm90 ZWN0ZWQnIGZpZWxkIE1VU1QgYmUgYSB6ZXJvIGxlbmd0aCBpdGVtIGlmIGl0IGlzIG5vdCB1c2Vk IGluIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgY29udGVudCBrZXkuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj7igJ0NCiBpbiBhIHdheSB0aGF0IG1ha2VzIHRoZSBvdmVyYWxs IG1lYW5pbmcgdW5hbWJpZ3VvdXMgd2hlbiByZWFkIHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VG8gbWFrZSBpdCBlYXNpZXIgZm9yIHJlYWRlcnMg dG8gdGllIHRoZSB0d28gY29udGV4dHMgdG9nZXRoZXIsIGNvdWxkIHlvdSBwbGVhc2UgY2hhbmdl OiDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPlRo ZQ0KICdwcm90ZWN0ZWQnIGZpZWxkIE1VU1QgYmUgYSB6ZXJvIGxlbmd0aCBpdGVtIGlmIGl0IGlz IG5vdCB1c2VkIGluIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgY29udGVudCBrZXkuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj7igJ0gdG8g4oCcPC9zcGFuPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5UaGUNCiAncHJvdGVjdGVkJyBmaWVsZCBN VVNUIGJlIGEgemVybyBsZW5ndGggaXRlbSBpZiBpdCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0 YXRpb24gb2YgdGhlIGNvbnRlbnQga2V5DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOnJlZCI+KGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEyLjEuMik8L3NwYW4+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPi48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEppbSBTY2hh YWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIERlY2VtYmVyIDgsIDIwMTUgMTozMiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25l cyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gY29z ZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2Nvc2UtaXNzdWVzXSBFbGFib3Jh dGUgb24g4oCcaWYgaXQgaXMgbm90IHVzZWQgaW4gdGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250 ZW50IGtleeKAnSAoIzM1KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBmcm9tIHNlY3Rpb24gMTIu MS4xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoZW4gdGhpcyBhbGdvcml0aG0gaXMgdXNlZCwgdGhlIHByb3RlY3Rl ZCBmaWVsZCBNVVNUIGJlIHplcm8gbGVuZ3RoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9t IHNlY3Rpb24gMTIuMS4yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSAncHJvdGVjdGVkJyBm aWVsZCBjYW4gYmUgb2Ygbm9uLXplcm8gbGVuZ3RoLiBUaGUgJ3Byb3RlY3RlZCcgZmllbGQgaXMg Y29waWVkIGludG8gdGhlIFN1cHBQdWJJbmZvLnByb3RlY3RlZCBmaWVsZCBvZiB0aGUgY29udGV4 dCBzdHJ1Y3R1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCBjb3ZlcnMg aXQgbW9yZSB0aGFuIHN1ZmZpY2llbnRseS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gTWlrZSBKb25lcyBbPGEgaHJlZj0ibWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0 aHViLmNvbSI+bWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0aHViLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMDgsIDIwMTUgMTowMiBQTTxicj4NCjxiPlRvOjwv Yj4gY29zZS13Zy9jb3NlLWlzc3VlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvc2UtaXNzdWVzQG5v cmVwbHkuZ2l0aHViLmNvbSI+Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3Vz dGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtjb3NlLWlzc3Vlc10gRWxhYm9yYXRlIG9uIOKAnGlmIGl0IGlzIG5vdCB1 c2VkIGluIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgY29udGVudCBrZXnigJ0gKCMzNSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5SZWFkaW5nIHRoZSBjb21taXQsIEkgY2FuJ3QgZmluZCB0 aGUgdGV4dCB5b3UncmUgcmVmZXJyaW5nIHRvLiBGb3IgaW5zdGFuY2UsIEkgc2VhcmNoZWQgZm9y ICZxdW90O251bGwmcXVvdDsgYW5kIHRoZSBzdHJpbmcgZGlkbid0IGFwcGVhciBpbiB0aGUgY29t bWl0LiBDYW4geW91IHBsZWFzZSBxdW90ZSB0aGUgdGV4dCB5b3UncmUgcmVmZXJyaW5nIHRvLCBK aW0gc28gSSBjYW4gcmV2aWV3IGl0PyBUaGFua3MuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0Om5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2 Ij7igJQ8YnI+DQpSZXBseSB0byB0aGlzIGVtYWlsIGRpcmVjdGx5IG9yIDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9jb3NlLXdnL2Nvc2UtaXNzdWVzL2lzc3Vlcy8zNSNpc3N1ZWNvbW1lbnQt MTYzMDE2NzUxIj4NCnZpZXcgaXQgb24gR2l0SHViPC9hPi48c3BhbiBzdHlsZT0iYm9yZGVyOnNv bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0i MSIgaGVpZ2h0PSIxIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFE MTMxQkUuRTIzMDJCOTAiIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIj48L3NwYW4+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_-- --_004_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=332; creation-date="Tue, 08 Dec 2015 21:46:50 GMT"; modification-date="Tue, 08 Dec 2015 21:46:50 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= --_004_BY2PR03MB4426219ADB0D2269A49DAC6F5080BY2PR03MB442namprd_-- From nobody Tue Dec 8 13:58:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8DA1A9083 for ; Tue, 8 Dec 2015 13:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 eL8NBBUdhfaH for ; Tue, 8 Dec 2015 13:58:33 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A008C1A9053 for ; Tue, 8 Dec 2015 13:58:33 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id E404538EFA; Tue, 8 Dec 2015 13:58:32 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <030601d131ff$e8d8f850$ba8ae8f0$@augustcellars.com> In-Reply-To: Date: Tue, 8 Dec 2015 13:55:47 -0800 Message-ID: <033601d13203$323686e0$96a394a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0337_01D131C0.2415B7E0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQEwVcYikThpA/XjGYy62Zs6go30SgMBDom+AwQR3FoCP5943p/BNH5A Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Elaborate_on_=E2=80=9Cif_it_is?= =?utf-8?q?_not_used_in_the_computation_of_the_content_key=E2=80=9D_=28=23?= =?utf-8?b?MzUp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:58:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0337_01D131C0.2415B7E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0338_01D131C0.2415DEF0" ------=_NextPart_001_0338_01D131C0.2415DEF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The problem I would have with this text is that the text is intended to = imply for any new direct+kdf algorithms that are created as well. The = parenthetical would appear to apply only to the one algorithm and not a = new one. =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Tuesday, December 08, 2015 1:47 PM To: Jim Schaad Cc: cose@ietf.org Subject: RE: [cose-issues] Elaborate on =E2=80=9Cif it is not used in = the computation of the content key=E2=80=9D (#35) =20 OK =E2=80=93 thanks for supplying the explicit text you were referring = to. I agree that these two additional statements sufficiently qualify = the initial statement that my comment was about =E2=80=9CThe 'protected' = field MUST be a zero length item if it is not used in the computation of = the content key.=E2=80=9D in a way that makes the overall meaning = unambiguous when read together. =20 To make it easier for readers to tie the two contexts together, could = you please change: =E2=80=9CThe 'protected' field MUST be a zero length = item if it is not used in the computation of the content key.=E2=80=9D = to =E2=80=9CThe 'protected' field MUST be a zero length item if it is = not used in the computation of the content key (as described in Section = 12.1.2).=E2=80=9D =20 Thanks, -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Tuesday, December 8, 2015 1:32 PM To: Mike Jones > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Elaborate on =E2=80=9Cif it is not used in = the computation of the content key=E2=80=9D (#35) =20 So from section 12.1.1 =20 When this algorithm is used, the protected field MUST be zero length. =20 >From section 12.1.2 =20 The 'protected' field can be of non-zero length. The 'protected' field = is copied into the SuppPubInfo.protected field of the context structure. =20 I think that covers it more than sufficiently. =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 1:02 PM To: cose-wg/cose-issues > Cc: Jim Schaad > Subject: Re: [cose-issues] Elaborate on =E2=80=9Cif it is not used in = the computation of the content key=E2=80=9D (#35) =20 Reading the commit, I can't find the text you're referring to. For = instance, I searched for "null" and the string didn't appear in the = commit. Can you please quote the text you're referring to, Jim so I can = review it? Thanks. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_0338_01D131C0.2415DEF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The problem I would have with this text is that the text is intended to = imply for any new direct+kdf algorithms that are created as well.=C2=A0 = The parenthetical would appear to apply only to the one algorithm and = not a new one.

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Tuesday, December 08, 2015 1:47 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = cose@ietf.org
Subject: RE: [cose-issues] Elaborate on = =E2=80=9Cif it is not used in the computation of the content = key=E2=80=9D (#35)

 

OK =E2=80=93 thanks for supplying the explicit text you were referring = to.  I agree that these two additional statements sufficiently = qualify the initial statement that my comment was about = =E2=80=9CThe 'protected' field MUST be a zero length item if it is not used in = the computation of the content key.=E2=80=9D in a way that makes the overall meaning unambiguous when read = together.

 

To make it easier for readers to tie the two contexts together, could = you please change: =E2=80=9CThe 'protected' field MUST be a zero length item if it is not used in = the computation of the content key.=E2=80=9D to =E2=80=9CThe 'protected' field MUST be a zero length item if it is not used in = the computation of the content key (= as described in Section 12.1.2).=E2=80=9D

 

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   Thanks,

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   -- Mike

 

From:<= /b> = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Tuesday, December 8, 2015 1:32 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: cose@ietf.org
Subject: RE: = [cose-issues] Elaborate on =E2=80=9Cif it is not used in the computation = of the content key=E2=80=9D (#35)

 

So from section 12.1.1

 

When this algorithm is = used, the protected field MUST be zero length.

 

From section = 12.1.2

 

The 'protected' field can be of non-zero length. The = 'protected' field is copied into the SuppPubInfo.protected field of the = context structure.

 

I think that = covers it more than sufficiently.

 

From:<= /b> = Mike Jones [mailto:notifications@github.com<= /a>]
Sent: Tuesday, December 08, 2015 1:02 PM
To: = cose-wg/cose-issues <cose-issues@noreply.github= .com>
Cc: Jim Schaad <ietf@augustcellars.com>
= Subject: Re: [cose-issues] Elaborate on =E2=80=9Cif it is not = used in the computation of the content key=E2=80=9D = (#35)

 

Reading the commit, I can't = find the text you're referring to. For instance, I searched for = "null" and the string didn't appear in the commit. Can you = please quote the text you're referring to, Jim so I can review it? = Thanks.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_0338_01D131C0.2415DEF0-- ------=_NextPart_000_0337_01D131C0.2415B7E0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_0337_01D131C0.2415B7E0-- From nobody Tue Dec 8 14:40:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE9F1AC3AC for ; Tue, 8 Dec 2015 14:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 zTXcf5HFvjPn for ; Tue, 8 Dec 2015 14:40:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1661ACD12 for ; Tue, 8 Dec 2015 14:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1Za4LRojml/wV+pTLi6lsVlynDg/Er6nMsFAp2lUp0M=; b=LGliUR8PVnm6iHJETF9KiiX6bGKSkqIa/4qlcAzEHCwDdPAWVOQ6NeU7A23iFDVPDAsdRHCXBjJEqkH8fdB6EwcILF9w/mzJWm44CdQ5hGlcQJk2RWrnb9c4+sZYc/JZSN0BaVItVeGapUR5IN1o/fcW5bb7DIvc+RH3rPQAoRI= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 8 Dec 2015 22:40:45 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 8 Dec 2015 22:40:45 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: =?utf-8?B?W2Nvc2UtaXNzdWVzXSBFbGFib3JhdGUgb24g4oCcaWYgaXQgaXMgbm90IHVz?= =?utf-8?B?ZWQgaW4gdGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleeKAnSAo?= =?utf-8?Q?#35)?= Thread-Index: AQHRMgBNXEne0nX4aUeKnfaqSb0/mp7BnizwgAAENoCAAAw+cA== Date: Tue, 8 Dec 2015 22:40:45 +0000 Message-ID: References: <030601d131ff$e8d8f850$ba8ae8f0$@augustcellars.com> <033601d13203$323686e0$96a394a0$@augustcellars.com> In-Reply-To: <033601d13203$323686e0$96a394a0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:1::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:DocVUc8dinHvoFoRMtWPsPXYGjaaxrthyDTUJtLvcRYZXAkr5EPV6533xqaesIbwuw8jPC2H2DO49e5qE6e/0PI3zDKyraoHH8uoGkLr3OzyIrbVvX8QcyMnkKxBEl71olsawqbxBgiFVtWYIBDjTg==; 24:2CXjRktuuJ0E+mexkHxDnkk6OFOi+sZK+YVyhNJB01FFw3zvWTY7tKUwvheyGui6LEsjK5ymGkagiZporibjc4mDOnnFZFyprTF8MyehS5I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0784C803FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(51444003)(189002)(52604005)(377454003)(199003)(97736004)(110136002)(19627595001)(1096002)(1220700001)(11100500001)(33656002)(76576001)(5003600100002)(54356999)(6116002)(5004730100002)(122556002)(5002640100001)(5001960100002)(19300405004)(2950100001)(10290500002)(189998001)(8990500004)(92566002)(19580395003)(10400500002)(2900100001)(19580405001)(15975445007)(81156007)(5008740100001)(10090500001)(77096005)(40100003)(5005710100001)(106356001)(106116001)(19617315012)(99936001)(105586002)(19609705001)(586003)(790700001)(102836003)(16236675004)(93886004)(87936001)(18206015028)(86362001)(86612001)(19625215002)(17760045003)(101416001)(99286002)(76176999)(74316001)(50986999)(7099028)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 22:40:45.3005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Elaborate_on_=E2=80=9Cif_it_is?= =?utf-8?q?_not_used_in_the_computation_of_the_content_key=E2=80=9D_=28=23?= =?utf-8?b?MzUp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:40:51 -0000 --_004_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_" --_000_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2guICBUaGVuIGNoYW5nZSBpdCB0byDigJxUaGUgJ3Byb3RlY3RlZCcgZmllbGQg TVVTVCBiZSBhIHplcm8gbGVuZ3RoIGl0ZW0gaWYgaXQgaXMgbm90IHVzZWQgaW4gdGhlIGNvbXB1 dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleSAoYXMgaXMgZG9uZSwgZm9yIGluc3RhbmNlLCBpbiBT ZWN0aW9uIDEyLjEuMiku4oCdDQoNCkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3Vz dGNlbGxhcnMuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgOCwgMjAxNSAxOjU2IFBNDQpU bzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IGNvc2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29zZS1pc3N1ZXNdIEVsYWJvcmF0ZSBvbiDigJxpZiBpdCBp cyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V54oCdICgjMzUp DQoNClRoZSBwcm9ibGVtIEkgd291bGQgaGF2ZSB3aXRoIHRoaXMgdGV4dCBpcyB0aGF0IHRoZSB0 ZXh0IGlzIGludGVuZGVkIHRvIGltcGx5IGZvciBhbnkgbmV3IGRpcmVjdCtrZGYgYWxnb3JpdGht cyB0aGF0IGFyZSBjcmVhdGVkIGFzIHdlbGwuICBUaGUgcGFyZW50aGV0aWNhbCB3b3VsZCBhcHBl YXIgdG8gYXBwbHkgb25seSB0byB0aGUgb25lIGFsZ29yaXRobSBhbmQgbm90IGEgbmV3IG9uZS4N Cg0KRnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0N ClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA4LCAyMDE1IDE6NDcgUE0NClRvOiBKaW0gU2NoYWFk IDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4N CkNjOiBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtj b3NlLWlzc3Vlc10gRWxhYm9yYXRlIG9uIOKAnGlmIGl0IGlzIG5vdCB1c2VkIGluIHRoZSBjb21w dXRhdGlvbiBvZiB0aGUgY29udGVudCBrZXnigJ0gKCMzNSkNCg0KT0sg4oCTIHRoYW5rcyBmb3Ig c3VwcGx5aW5nIHRoZSBleHBsaWNpdCB0ZXh0IHlvdSB3ZXJlIHJlZmVycmluZyB0by4gIEkgYWdy ZWUgdGhhdCB0aGVzZSB0d28gYWRkaXRpb25hbCBzdGF0ZW1lbnRzIHN1ZmZpY2llbnRseSBxdWFs aWZ5IHRoZSBpbml0aWFsIHN0YXRlbWVudCB0aGF0IG15IGNvbW1lbnQgd2FzIGFib3V0IOKAnFRo ZSAncHJvdGVjdGVkJyBmaWVsZCBNVVNUIGJlIGEgemVybyBsZW5ndGggaXRlbSBpZiBpdCBpcyBu b3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V5LuKAnSBpbiBhIHdh eSB0aGF0IG1ha2VzIHRoZSBvdmVyYWxsIG1lYW5pbmcgdW5hbWJpZ3VvdXMgd2hlbiByZWFkIHRv Z2V0aGVyLg0KDQpUbyBtYWtlIGl0IGVhc2llciBmb3IgcmVhZGVycyB0byB0aWUgdGhlIHR3byBj b250ZXh0cyB0b2dldGhlciwgY291bGQgeW91IHBsZWFzZSBjaGFuZ2U6IOKAnFRoZSAncHJvdGVj dGVkJyBmaWVsZCBNVVNUIGJlIGEgemVybyBsZW5ndGggaXRlbSBpZiBpdCBpcyBub3QgdXNlZCBp biB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V5LuKAnSB0byDigJxUaGUgJ3Byb3Rl Y3RlZCcgZmllbGQgTVVTVCBiZSBhIHplcm8gbGVuZ3RoIGl0ZW0gaWYgaXQgaXMgbm90IHVzZWQg aW4gdGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleSAoYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMTIuMS4yKS7igJ0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXQ0KU2VudDogVHVl c2RheSwgRGVjZW1iZXIgOCwgMjAxNSAxOjMyIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0K Q2M6IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2Nv c2UtaXNzdWVzXSBFbGFib3JhdGUgb24g4oCcaWYgaXQgaXMgbm90IHVzZWQgaW4gdGhlIGNvbXB1 dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleeKAnSAoIzM1KQ0KDQpTbyBmcm9tIHNlY3Rpb24gMTIu MS4xDQoNCldoZW4gdGhpcyBhbGdvcml0aG0gaXMgdXNlZCwgdGhlIHByb3RlY3RlZCBmaWVsZCBN VVNUIGJlIHplcm8gbGVuZ3RoLg0KDQpGcm9tIHNlY3Rpb24gMTIuMS4yDQoNClRoZSAncHJvdGVj dGVkJyBmaWVsZCBjYW4gYmUgb2Ygbm9uLXplcm8gbGVuZ3RoLiBUaGUgJ3Byb3RlY3RlZCcgZmll bGQgaXMgY29waWVkIGludG8gdGhlIFN1cHBQdWJJbmZvLnByb3RlY3RlZCBmaWVsZCBvZiB0aGUg Y29udGV4dCBzdHJ1Y3R1cmUuDQoNCkkgdGhpbmsgdGhhdCBjb3ZlcnMgaXQgbW9yZSB0aGFuIHN1 ZmZpY2llbnRseS4NCg0KRnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0 aHViLmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA4LCAyMDE1IDE6MDIgUE0NClRvOiBj b3NlLXdnL2Nvc2UtaXNzdWVzIDxjb3NlLWlzc3Vlc0Bub3JlcGx5LmdpdGh1Yi5jb208bWFpbHRv OmNvc2UtaXNzdWVzQG5vcmVwbHkuZ2l0aHViLmNvbT4+DQpDYzogSmltIFNjaGFhZCA8aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+DQpTdWJqZWN0 OiBSZTogW2Nvc2UtaXNzdWVzXSBFbGFib3JhdGUgb24g4oCcaWYgaXQgaXMgbm90IHVzZWQgaW4g dGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleeKAnSAoIzM1KQ0KDQoNClJlYWRpbmcg dGhlIGNvbW1pdCwgSSBjYW4ndCBmaW5kIHRoZSB0ZXh0IHlvdSdyZSByZWZlcnJpbmcgdG8uIEZv ciBpbnN0YW5jZSwgSSBzZWFyY2hlZCBmb3IgIm51bGwiIGFuZCB0aGUgc3RyaW5nIGRpZG4ndCBh cHBlYXIgaW4gdGhlIGNvbW1pdC4gQ2FuIHlvdSBwbGVhc2UgcXVvdGUgdGhlIHRleHQgeW91J3Jl IHJlZmVycmluZyB0bywgSmltIHNvIEkgY2FuIHJldmlldyBpdD8gVGhhbmtzLg0KDQrigJQNClJl cGx5IHRvIHRoaXMgZW1haWwgZGlyZWN0bHkgb3IgdmlldyBpdCBvbiBHaXRIdWI8aHR0cHM6Ly9n aXRodWIuY29tL2Nvc2Utd2cvY29zZS1pc3N1ZXMvaXNzdWVzLzM1I2lzc3VlY29tbWVudC0xNjMw MTY3NTE+Lg0K --_000_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMDAyMDYwOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+RmFpciBlbm91Z2guJm5ic3A7IFRoZW4gY2hhbmdlIGl0IHRv IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+VGhl ICdwcm90ZWN0ZWQnIGZpZWxkIE1VU1QgYmUNCiBhIHplcm8gbGVuZ3RoIGl0ZW0gaWYgaXQgaXMg bm90IHVzZWQgaW4gdGhlIGNvbXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleSA8L3NwYW4+DQo8 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj4oYXMgaXMgZG9uZSwgZm9yIGlu c3RhbmNlLCBpbiBTZWN0aW9uIDEyLjEuMik8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMzMzMzMzMiPi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSmltIFNjaGFh ZCBbbWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgRGVjZW1iZXIgOCwgMjAxNSAxOjU2IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVz ICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBjb3Nl QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbY29zZS1pc3N1ZXNdIEVsYWJvcmF0 ZSBvbiDigJxpZiBpdCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRl bnQga2V54oCdICgjMzUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9ibGVtIEkgd291bGQg aGF2ZSB3aXRoIHRoaXMgdGV4dCBpcyB0aGF0IHRoZSB0ZXh0IGlzIGludGVuZGVkIHRvIGltcGx5 IGZvciBhbnkgbmV3IGRpcmVjdCYjNDM7a2RmIGFsZ29yaXRobXMgdGhhdCBhcmUgY3JlYXRlZCBh cyB3ZWxsLiZuYnNwOyBUaGUgcGFyZW50aGV0aWNhbCB3b3VsZA0KIGFwcGVhciB0byBhcHBseSBv bmx5IHRvIHRoZSBvbmUgYWxnb3JpdGhtIGFuZCBub3QgYSBuZXcgb25lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1p a2UgSm9uZXMgWzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPm1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIERlY2VtYmVyIDA4LCAyMDE1IDE6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEppbSBT Y2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5pZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpj b3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W2Nvc2UtaXNzdWVzXSBFbGFib3JhdGUgb24g4oCcaWYgaXQgaXMgbm90IHVzZWQgaW4gdGhlIGNv bXB1dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleeKAnSAoIzM1KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5PSyDigJMgdGhhbmtzIGZvciBzdXBwbHlpbmcgdGhlIGV4cGxpY2l0IHRleHQgeW91IHdlcmUg cmVmZXJyaW5nIHRvLiZuYnNwOyBJIGFncmVlIHRoYXQgdGhlc2UgdHdvIGFkZGl0aW9uYWwgc3Rh dGVtZW50cyBzdWZmaWNpZW50bHkgcXVhbGlmeSB0aGUgaW5pdGlhbCBzdGF0ZW1lbnQgdGhhdA0K IG15IGNvbW1lbnQgd2FzIGFib3V0IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzMzMzMzMyI+VGhlICdwcm90ZWN0ZWQnIGZpZWxkIE1VU1QgYmUgYSB6ZXJvIGxl bmd0aCBpdGVtIGlmIGl0IGlzIG5vdCB1c2VkIGluIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgY29u dGVudCBrZXkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj7igJ0NCiBpbiBh IHdheSB0aGF0IG1ha2VzIHRoZSBvdmVyYWxsIG1lYW5pbmcgdW5hbWJpZ3VvdXMgd2hlbiByZWFk IHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VG8g bWFrZSBpdCBlYXNpZXIgZm9yIHJlYWRlcnMgdG8gdGllIHRoZSB0d28gY29udGV4dHMgdG9nZXRo ZXIsIGNvdWxkIHlvdSBwbGVhc2UgY2hhbmdlOiDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPlRoZQ0KICdwcm90ZWN0ZWQnIGZpZWxkIE1VU1QgYmUg YSB6ZXJvIGxlbmd0aCBpdGVtIGlmIGl0IGlzIG5vdCB1c2VkIGluIHRoZSBjb21wdXRhdGlvbiBv ZiB0aGUgY29udGVudCBrZXkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj7i gJ0gdG8g4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMz Ij5UaGUNCiAncHJvdGVjdGVkJyBmaWVsZCBNVVNUIGJlIGEgemVybyBsZW5ndGggaXRlbSBpZiBp dCBpcyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V5DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+KGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDEyLjEuMik8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMzMzMzMzMiPi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IEppbSBTY2hhYWQgWzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3Vz dGNlbGxhcnMuY29tIj5tYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgOCwgMjAxNSAxOjMyIFBNPGJyPg0KPGI+VG86 PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbY29zZS1pc3N1ZXNdIEVsYWJvcmF0ZSBvbiDigJxpZiBpdCBp cyBub3QgdXNlZCBpbiB0aGUgY29tcHV0YXRpb24gb2YgdGhlIGNvbnRlbnQga2V54oCdICgjMzUp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIGZyb20gc2VjdGlvbiAxMi4xLjE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hlbiB0aGlzIGFsZ29yaXRobSBpcyB1c2VkLCB0aGUgcHJvdGVjdGVkIGZpZWxkIE1VU1QgYmUg emVybyBsZW5ndGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb20gc2VjdGlvbiAxMi4xLjI8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlICdwcm90ZWN0ZWQnIGZpZWxkIGNhbiBiZSBvZiBu b24temVybyBsZW5ndGguIFRoZSAncHJvdGVjdGVkJyBmaWVsZCBpcyBjb3BpZWQgaW50byB0aGUg U3VwcFB1YkluZm8ucHJvdGVjdGVkIGZpZWxkIG9mIHRoZSBjb250ZXh0IHN0cnVjdHVyZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IGNvdmVycyBpdCBtb3JlIHRoYW4gc3Vm ZmljaWVudGx5LjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtl IEpvbmVzIFs8YSBocmVmPSJtYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tIj5tYWlsdG86 bm90aWZpY2F0aW9uc0BnaXRodWIuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBEZWNlbWJlciAwOCwgMjAxNSAxOjAyIFBNPGJyPg0KPGI+VG86PC9iPiBjb3NlLXdnL2Nvc2Ut aXNzdWVzICZsdDs8YSBocmVmPSJtYWlsdG86Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29t Ij5jb3NlLWlzc3Vlc0Bub3JlcGx5LmdpdGh1Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g SmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmll dGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Nv c2UtaXNzdWVzXSBFbGFib3JhdGUgb24g4oCcaWYgaXQgaXMgbm90IHVzZWQgaW4gdGhlIGNvbXB1 dGF0aW9uIG9mIHRoZSBjb250ZW50IGtleeKAnSAoIzM1KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwPlJlYWRpbmcgdGhlIGNvbW1pdCwgSSBjYW4ndCBmaW5kIHRoZSB0ZXh0IHlvdSdyZSBy ZWZlcnJpbmcgdG8uIEZvciBpbnN0YW5jZSwgSSBzZWFyY2hlZCBmb3IgJnF1b3Q7bnVsbCZxdW90 OyBhbmQgdGhlIHN0cmluZyBkaWRuJ3QgYXBwZWFyIGluIHRoZSBjb21taXQuIENhbiB5b3UgcGxl YXNlIHF1b3RlIHRoZSB0ZXh0IHlvdSdyZSByZWZlcnJpbmcgdG8sIEppbSBzbyBJIGNhbiByZXZp ZXcgaXQ/IFRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSItd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPuKAlDxicj4NClJlcGx5 IHRvIHRoaXMgZW1haWwgZGlyZWN0bHkgb3IgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2Nv c2Utd2cvY29zZS1pc3N1ZXMvaXNzdWVzLzM1I2lzc3VlY29tbWVudC0xNjMwMTY3NTEiPg0Kdmll dyBpdCBvbiBHaXRIdWI8L2E+LjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIGlk PSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQxMzFDNi42QURENTFGMCIg YWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iPjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_-- --_004_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=332; creation-date="Tue, 08 Dec 2015 22:40:44 GMT"; modification-date="Tue, 08 Dec 2015 22:40:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= --_004_BY2PR03MB44239896E333A57AD7B5D54F5080BY2PR03MB442namprd_-- From nobody Tue Dec 8 14:42:14 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707AF1ACD34 for ; Tue, 8 Dec 2015 14:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 lnKN_54vHgDj for ; Tue, 8 Dec 2015 14:42:12 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4FF1ACD31 for ; Tue, 8 Dec 2015 14:42:11 -0800 (PST) Date: Tue, 08 Dec 2015 14:42:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449614528; bh=40Kj8FlLsiQlGrDCzKuKgEfgYeojStCvcFRLPXr5Q0E=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=S/BMXUzj5zlIbZx13GzRfAXJc2hbcIxhDLnS0OnM3ARIrBghgTOcafvjr6ORyN7pF 5fvz1Dss1nFk/9TpgBwS6T7RvAmu91AWBjZt7V0j0C/3AJQ9jz57ZuRaFx0aHX5YQE oN7UwZY0GUVG86yebkLjJAq9PWwmAmn8+hXhGSag= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56675cc0ac688_677c3fac731a92bc1226bb"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBJcyBhIOKAnGRpcmVjdCBrZXnigJ0g?= =?utf-8?q?sent_in_the_clear=3F_=28=2336=29?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:42:13 -0000 ----==_mimepart_56675cc0ac688_677c3fac731a92bc1226bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit All right. In the interest of moving forward, I'll drop this one, given the now-clear explanation being on record. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/36#issuecomment-163043149 ----==_mimepart_56675cc0ac688_677c3fac731a92bc1226bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

All right. In the interest of moving forward, I'll drop this one, given the now-clear explanation being on record.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56675cc0ac688_677c3fac731a92bc1226bb-- From nobody Tue Dec 8 14:55:04 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC301ACD84 for ; Tue, 8 Dec 2015 14:55:02 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EUBElaAZnkZF for ; Tue, 8 Dec 2015 14:54:59 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2281ACD7B for ; Tue, 8 Dec 2015 14:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LTTd4pDBEPGn+pnstWirjhAhFDz7v0T8NEtRyONVBU4=; b=M/S9ZDvqBRTB8S85ODrw+HeAqs1ynaibpi+pUsqf4wyLNjg57sP8/PJJJOCV36pEuAXWQ9qovcKCWZ0TC+0Wmvx5DOVBZi1//d+Px6U5gQ5k2fIE3E2jSY/j98AuZCpZ9rLKs7eeYY9BqiagfFyidyuG5b+U1/MK743Hz4V/rgo= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 8 Dec 2015 22:54:56 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 8 Dec 2015 22:54:56 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) Thread-Index: AQHRMf/XJAIDJHSH2Ui0CSTNS8vNPZ7Br9Hw Date: Tue, 8 Dec 2015 22:54:56 +0000 Message-ID: References: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> In-Reply-To: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:1::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:EHCzY0yeC7Dpze27ixzKM+oE8Y42gB9gpPi4mkYFNorLnXppmw0XL6PLJPMmeia5oUGuSAllG7ytglQHTMDOm4elnBq3rCxsjoHFYaDz8Vw7JT63IBGNh19jKp9K/3rVuv0T5zJdSx/we7UK82U5nA==; 24:9FqV0BSr7mEBgnW5hBelTBgDUGXN1HXeWPG2QH2RmFzQuzrjSWa6suhkKWr0ZPDJ5yRxjkUQaFIpGlx7tFfdEHiQCpR9LcmcvbWijEB0eDA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0784C803FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(86612001)(5004730100002)(110136002)(92566002)(5001960100002)(19609705001)(19627595001)(19617315012)(122556002)(790700001)(2900100001)(6116002)(15975445007)(586003)(40100003)(81156007)(102836003)(87936001)(76176999)(2950100001)(77096005)(18206015028)(33656002)(19625215002)(76576001)(101416001)(16236675004)(5002640100001)(86362001)(561944003)(10290500002)(54356999)(10090500001)(17760045003)(106356001)(5005710100001)(19580405001)(106116001)(1220700001)(97736004)(8990500004)(10400500002)(1096002)(74316001)(99286002)(5003600100002)(189998001)(5008740100001)(19580395003)(50986999)(105586002)(19300405004)(11100500001)(7099028)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C938387967335B47FCB0F5080BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 22:54:56.3844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 22:55:02 -0000 --_000_BY2PR03MB442C938387967335B47FCB0F5080BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciB3YXkgaGFzIGNvbmRpdGlvbmFsIGxvZ2ljIGZvciBjb25zdHJ1Y3RpbmcgdGhlIGRhdGEg c3RydWN0dXJlcyBkZXBlbmRpbmcgdXBvbiB3aGV0aGVyIGFuIGV4dGVybmFsX2FhZCB2YWx1ZSBp cyBzdXBwbGllZC4gIFNvIGRvZXMgbWluZS4gIFNvIGJvdGggaGF2ZSDigJx0d28gd2F5cyBvZiBk b2luZyB0aGluZ3PigJ0g4oCTIG5vdCBvbmUgd2F5LiAgVGhlIGRpZmZlcmVuY2UgaXMgb25seSB3 aGV0aGVyIGEgemVyby1sZW5ndGggZmllbGQgaXMgc3VwcGxpZWQgb3Igd2hldGhlciBpdOKAmXMg b21pdHRlZCwgd2hpY2ggaXMgcHJldHR5IG11Y2ggZXF1aXZhbGVudCBmcm9tIGEgc2VjdXJpdHkg YW5kIHRpbWluZyBwZXJzcGVjdGl2ZS4NCg0KWW91IHNlZW0gd29ycmllZCBhYm91dCBpbXBsZW1l bnRhdGlvbiBlcnJvcnMsIHdoaWNoIEkgYWdyZWUgaXMgb2Z0ZW4gYSB2YWxpZCBjb25jZXJuLiAg VGhlIGdvb2QgbmV3cyBpbiB0aGlzIGNhc2UgaXMgdGhhdCBpbmNvcnJlY3QgaW1wbGVtZW50YXRp b25zIHdpbGwgZ2VuZXJhdGUgdGhlIHdyb25nIHNpZ25hdHVyZSBvciBITUFDIHZhbHVlLCBjYXVz aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBmYWlsIGR1cmluZyBpbnRlcm9wIHRlc3RpbmcsIHdl bGwgYmVmb3JlIGl04oCZcyBldmVyIGRlcGxveWVkLiAgTm9ybWFsIHRlc3RpbmcvZGVidWdnaW5n IHdpbGwgY2F0Y2ggdGhpcy4NCg0KVGhlIGFkZGl0aW9uYWwgc2ltcGxpZmljYXRpb24gdGhhdCBt eSBwcm9wb3NhbCBlbmFibGVzIGlzIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gY2FuIGhhdmUgemVy byBjb2RlIGFib3V0IGV4dGVybmFsX2FhZCBpZiBpdOKAmXMgbm90IHN1cHBvcnRlZCwgd2hlcmUg d2l0aCB5b3VyIHJlcHJlc2VudGF0aW9uLCB0aGUgaW1wbGVtZW50YXRpb24gc3RpbGwgaGFzIHRv IGhhdmUgY29kZSB0byBpbnNlcnQgdGhlIHVubmVjZXNzYXJ5IGFuZCB1bnVzZWQgYXJyYXkgdmFs dWUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1 Z3VzdGNlbGxhcnMuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgOCwgMjAxNSAxOjI5IFBN DQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IGNvc2VA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29zZS1pc3N1ZXNdIE1vdmUgZXh0ZXJuYWxfYWFkIHRv IHRoZSBlbmQgb2Ygc3RydWN0dXJlcyB1c2luZyBpdCBhbmQgbWFrZSBpdHMgcHJlc2VuY2Ugb3B0 aW9uYWwgKCM0OCkNCg0KSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGludm9raW5nIHNlY3VyaXR5IGlz IGluY29ycmVjdCBpbiB0aGlzIGluc3RhbmNlLiAgVGhlIHN0YXRlbWVudCB0aGF0IHNlY3VyaXR5 IGlzc3VlcyB0ZW5kIHRvIGFyaXNlIG9uIHBhcnNpbmcgaXMgbm90IHNvbWV0aGluZyBJIHdvdWxk IGFjY2VwdCBhcyBhIGdpdmVuLiAgSSBoYXZlIHByb2JhYmx5IHNlZW4ganVzdCBhcyBtYW55IG9y IG1vcmUgcHJvYmxlbXMgd2l0aCBidWlsZGluZyBzdHJpbmdzLCByYW5kb20gbnVtYmVyIGdlbmVy YXRpb24sIHRpbWluZyBhdHRhY2tzIGFzIEkgaGF2ZSBzZWVuIHBhcnNpbmcgZXJyb3JzLiAgIEkg ZG9u4oCZdCB0aGluayB0aGF0IGlzIGEgc3VwcG9ydGFibGUgcHJvcG9zaXRpb24uDQoNCllvdSBh bmQgSSBoYXZlIGRpZmZlcmVudCBpZGVhcyBvbiB3aGF0IGl0IG1lYW5zIHRvIOKAnGtlZXAgdGhp bmdzIHNpbXBsZeKAnS4gIEZvciBtZSwgb25lIHdheSBvZiBkb2luZyB0aGluZ3Mgd2l0aG91dCBv cHRpb25zIGlzIGFsd2F5cyBzaW1wbGVyIGFuZCBsZXNzIHByb25lIHRvIGVycm9yLiAgVGh1cyB0 byBtZSBoYXZpbmcgYSBmaXhlZCBhcnJheSBpcyB0aGUgc2ltcGxlciBvcHRpb24uICBJdCBkb2Vz IG5vdCBtYXR0ZXIgaWYgdGhlIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGRvZXMgb3IgZG9lcyBu b3Qgc3VwcG9ydCBleHRlcm5hbCBhYWQsIGNyZWF0aW5nIHRoZSBvbmUgYWRkaXRpb25hbCBmaWVs ZCBpbiB0aGUgYXJyYXkgaXMgbm90IHRoZSBzYW1lIGJ1cmRlbiBhcyB0aGUgc2FtZSB0aGluZyBp cyBnb2luZyB0byBiZSBmb3IgdGhvc2UgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gaW1wbGVtZW50 IHRoZSBleHRlcm5hbCBhYWQgZmVhdHVyZS4gIE1ha2luZyBpdCBvcHRpb25hbCBpbnRyb2R1Y2Vz IGEgbmV3IHN0YXRlIGludG8gdGhlIHN5c3RlbSBvZiBhIHplcm8gbGVuZ3RoIGFhZCB3aGljaCBp cyBkaWZmZXJlbnQgZnJvbSBubyBhYWQuDQoNCkFnYWluIGluIG15IG9waW5pb24g4oCTIHRoZSBj dXJyZW50IHZlcnNpb24gaXMgc2ltcGxlciB0aGF0IHdoYXQgeW91IGFyZSBwcm9wb3NpbmcuDQoN CkppbQ0KDQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpub3RpZmljYXRpb25zQGdpdGh1Yi5j b21dDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwOCwgMjAxNSAxMjozOSBQTQ0KVG86IGNvc2Ut d2cvY29zZS1pc3N1ZXMgPGNvc2UtaXNzdWVzQG5vcmVwbHkuZ2l0aHViLmNvbTxtYWlsdG86Y29z ZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tPj4NCkNjOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3Vz dGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4NClN1YmplY3Q6IFJl OiBbY29zZS1pc3N1ZXNdIE1vdmUgZXh0ZXJuYWxfYWFkIHRvIHRoZSBlbmQgb2Ygc3RydWN0dXJl cyB1c2luZyBpdCBhbmQgbWFrZSBpdHMgcHJlc2VuY2Ugb3B0aW9uYWwgKCM0OCkNCg0KDQpJbnZv a2luZyBzZWN1cml0eSBzZWVtcyBpbmNvcnJlY3QgYW5kIG92ZXJzdGF0ZWQgaGVyZS4gVGhlc2Ug dmFsdWVzIGFyZSBuZXZlciBwYXJzZWQgLSB3aGljaCBpcyB3aGVuIHNlY3VyaXR5IGlzc3VlcyB0 ZW5kIHRvIGFyaXNlLiBUaGV5IGFyZSBqdXN0IGNyZWF0ZWQgaW50ZXJuYWxseSBhbmQgdGhlbiB1 c2VkIGFzIHNlcmlhbGl6ZWQgYnl0ZSBhcnJheSBpbnB1dHMgdG8gY3J5cHRvZ3JhcGhpYyBvcGVy YXRpb25zLiBUaGVyZSBpcyBubyBzZWN1cml0eSBwcm9ibGVtIHdpdGggaGF2aW5nIGJvdGggMy1t ZW1iZXIgYW5kIDQtbWVtYmVyIGFycmF5IHZhbHVlcyBmb3IgdGhpcyBpbnRlcm1lZGlhdGUgdGVt cG9yYXJ5IHJlc3VsdC4NCg0KUGxlYXNlIGNhcGl0YWxpemUgb24gdGhpcyBvcHBvcnR1bml0eSB0 byAia2VlcCBzaW1wbGUgdGhpbmdzIHNpbXBsZSIgLSBvbmUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAg cHJpbmNpcGxlcyBzdGF0ZWQgYnkgdGhlIGNoYWlycyBvbiBzbGlkZSAyMiBvZiB0aGVpciBvcGVu aW5nIHByZXNlbnRhdGlvbiBhdCBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9z bGlkZXMvc2xpZGVzLTkzLWNvc2UtMi5wZGYuIEVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgdGhlIGZh Y3QgdGhhdCBtYW55IGltcGxlbWVudGF0aW9ucyB3b24ndCBuZWVkIHN1cHBvcnQgZm9yIGV4dGVy bmFsX2FhZCwgcGVyIGlzc3VlICM1MDxodHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9jb3NlLWlz c3Vlcy9pc3N1ZXMvNTA+LCBwbGVhc2UgbWFrZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgc2ltcGxl ciBieSBtYWtpbmcgdGhlIHByZXNlbmNlIG9mIHRoZSBleHRlcm5hbF9hYWQgYXJyYXkgbWVtYmVy IG9wdGlvbmFsLg0KDQrigJQNClJlcGx5IHRvIHRoaXMgZW1haWwgZGlyZWN0bHkgb3IgdmlldyBp dCBvbiBHaXRIdWI8aHR0cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cvY29zZS1pc3N1ZXMvaXNzdWVz LzQ4I2lzc3VlY29tbWVudC0xNjMwMTExNDM+Lg0K --_000_BY2PR03MB442C938387967335B47FCB0F5080BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj5Zb3VyIHdheSBoYXMgY29uZGl0aW9uYWwgbG9naWMgZm9yIGNvbnN0 cnVjdGluZyB0aGUgZGF0YSBzdHJ1Y3R1cmVzIGRlcGVuZGluZyB1cG9uIHdoZXRoZXIgYW4gZXh0 ZXJuYWxfYWFkIHZhbHVlIGlzIHN1cHBsaWVkLiZuYnNwOyBTbyBkb2VzIG1pbmUuJm5ic3A7IFNv IGJvdGggaGF2ZSDigJx0d28NCiB3YXlzIG9mIGRvaW5nIHRoaW5nc+KAnSDigJMgbm90IG9uZSB3 YXkuICZuYnNwO1RoZSBkaWZmZXJlbmNlIGlzIG9ubHkgd2hldGhlciBhIHplcm8tbGVuZ3RoIGZp ZWxkIGlzIHN1cHBsaWVkIG9yIHdoZXRoZXIgaXTigJlzIG9taXR0ZWQsIHdoaWNoIGlzIHByZXR0 eSBtdWNoIGVxdWl2YWxlbnQgZnJvbSBhIHNlY3VyaXR5IGFuZCB0aW1pbmcgcGVyc3BlY3RpdmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5Zb3Ugc2VlbSB3b3Jy aWVkIGFib3V0IGltcGxlbWVudGF0aW9uIGVycm9ycywgd2hpY2ggSSBhZ3JlZSBpcyBvZnRlbiBh IHZhbGlkIGNvbmNlcm4uJm5ic3A7IFRoZSBnb29kIG5ld3MgaW4gdGhpcyBjYXNlIGlzIHRoYXQg aW5jb3JyZWN0IGltcGxlbWVudGF0aW9ucyB3aWxsIGdlbmVyYXRlDQogdGhlIHdyb25nIHNpZ25h dHVyZSBvciBITUFDIHZhbHVlLCBjYXVzaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBmYWlsIGR1 cmluZyBpbnRlcm9wIHRlc3RpbmcsIHdlbGwgYmVmb3JlIGl04oCZcyBldmVyIGRlcGxveWVkLiZu YnNwOyBOb3JtYWwgdGVzdGluZy9kZWJ1Z2dpbmcgd2lsbCBjYXRjaCB0aGlzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIGFkZGl0aW9uYWwgc2ltcGxpZmlj YXRpb24gdGhhdCBteSBwcm9wb3NhbCBlbmFibGVzIGlzIHRoYXQgYW4gaW1wbGVtZW50YXRpb24g Y2FuIGhhdmUgemVybyBjb2RlIGFib3V0IGV4dGVybmFsX2FhZCBpZiBpdOKAmXMgbm90IHN1cHBv cnRlZCwgd2hlcmUgd2l0aCB5b3VyDQogcmVwcmVzZW50YXRpb24sIHRoZSBpbXBsZW1lbnRhdGlv biBzdGlsbCBoYXMgdG8gaGF2ZSBjb2RlIHRvIGluc2VydCB0aGUgdW5uZWNlc3NhcnkgYW5kIHVu dXNlZCBhcnJheSB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKaW0gU2NoYWFkIFttYWlsdG86aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJl ciA4LCAyMDE1IDE6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGNvc2VAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtjb3NlLWlzc3Vlc10gTW92ZSBleHRlcm5hbF9hYWQgdG8g dGhlIGVuZCBvZiBzdHJ1Y3R1cmVzIHVzaW5nIGl0IGFuZCBtYWtlIGl0cyBwcmVzZW5jZSBvcHRp b25hbCAoIzQ4KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvIG5vdCBiZWxpZXZlIHRoYXQgaW52 b2tpbmcgc2VjdXJpdHkgaXMgaW5jb3JyZWN0IGluIHRoaXMgaW5zdGFuY2UuJm5ic3A7IFRoZSBz dGF0ZW1lbnQgdGhhdCBzZWN1cml0eSBpc3N1ZXMgdGVuZCB0byBhcmlzZSBvbiBwYXJzaW5nIGlz IG5vdCBzb21ldGhpbmcgSSB3b3VsZCBhY2NlcHQNCiBhcyBhIGdpdmVuLiZuYnNwOyBJIGhhdmUg cHJvYmFibHkgc2VlbiBqdXN0IGFzIG1hbnkgb3IgbW9yZSBwcm9ibGVtcyB3aXRoIGJ1aWxkaW5n IHN0cmluZ3MsIHJhbmRvbSBudW1iZXIgZ2VuZXJhdGlvbiwgdGltaW5nIGF0dGFja3MgYXMgSSBo YXZlIHNlZW4gcGFyc2luZyBlcnJvcnMuJm5ic3A7Jm5ic3A7IEkgZG9u4oCZdCB0aGluayB0aGF0 IGlzIGEgc3VwcG9ydGFibGUgcHJvcG9zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Zb3UgYW5kIEkgaGF2ZSBkaWZmZXJlbnQgaWRlYXMgb24gd2hhdCBp dCBtZWFucyB0byDigJxrZWVwIHRoaW5ncyBzaW1wbGXigJ0uJm5ic3A7IEZvciBtZSwgb25lIHdh eSBvZiBkb2luZyB0aGluZ3Mgd2l0aG91dCBvcHRpb25zIGlzIGFsd2F5cyBzaW1wbGVyIGFuZCBs ZXNzIHByb25lIHRvDQogZXJyb3IuJm5ic3A7IFRodXMgdG8gbWUgaGF2aW5nIGEgZml4ZWQgYXJy YXkgaXMgdGhlIHNpbXBsZXIgb3B0aW9uLiZuYnNwOyBJdCBkb2VzIG5vdCBtYXR0ZXIgaWYgdGhl IHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGRvZXMgb3IgZG9lcyBub3Qgc3VwcG9ydCBleHRlcm5h bCBhYWQsIGNyZWF0aW5nIHRoZSBvbmUgYWRkaXRpb25hbCBmaWVsZCBpbiB0aGUgYXJyYXkgaXMg bm90IHRoZSBzYW1lIGJ1cmRlbiBhcyB0aGUgc2FtZSB0aGluZyBpcyBnb2luZyB0byBiZQ0KIGZv ciB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBpbXBsZW1lbnQgdGhlIGV4dGVybmFsIGFh ZCBmZWF0dXJlLiZuYnNwOyBNYWtpbmcgaXQgb3B0aW9uYWwgaW50cm9kdWNlcyBhIG5ldyBzdGF0 ZSBpbnRvIHRoZSBzeXN0ZW0gb2YgYSB6ZXJvIGxlbmd0aCBhYWQgd2hpY2ggaXMgZGlmZmVyZW50 IGZyb20gbm8gYWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QWdhaW4gaW4gbXkgb3BpbmlvbiDigJMgdGhlIGN1cnJlbnQgdmVyc2lvbiBpcyBzaW1wbGVyIHRo YXQgd2hhdCB5b3UgYXJlIHByb3Bvc2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkppbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtl IEpvbmVzIFs8YSBocmVmPSJtYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tIj5tYWlsdG86 bm90aWZpY2F0aW9uc0BnaXRodWIuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBEZWNlbWJlciAwOCwgMjAxNSAxMjozOSBQTTxicj4NCjxiPlRvOjwvYj4gY29zZS13Zy9jb3Nl LWlzc3VlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvc2UtaXNzdWVzQG5vcmVwbHkuZ2l0aHViLmNv bSI+Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ IEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5p ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtj b3NlLWlzc3Vlc10gTW92ZSBleHRlcm5hbF9hYWQgdG8gdGhlIGVuZCBvZiBzdHJ1Y3R1cmVzIHVz aW5nIGl0IGFuZCBtYWtlIGl0cyBwcmVzZW5jZSBvcHRpb25hbCAoIzQ4KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwPkludm9raW5nIHNlY3VyaXR5IHNlZW1zIGluY29ycmVjdCBhbmQgb3Zl cnN0YXRlZCBoZXJlLiBUaGVzZSB2YWx1ZXMgYXJlIG5ldmVyIHBhcnNlZCAtIHdoaWNoIGlzIHdo ZW4gc2VjdXJpdHkgaXNzdWVzIHRlbmQgdG8gYXJpc2UuIFRoZXkgYXJlIGp1c3QgY3JlYXRlZCBp bnRlcm5hbGx5IGFuZCB0aGVuIHVzZWQgYXMgc2VyaWFsaXplZCBieXRlIGFycmF5IGlucHV0cyB0 byBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMuIFRoZXJlIGlzIG5vIHNlY3VyaXR5DQogcHJvYmxl bSB3aXRoIGhhdmluZyBib3RoIDMtbWVtYmVyIGFuZCA0LW1lbWJlciBhcnJheSB2YWx1ZXMgZm9y IHRoaXMgaW50ZXJtZWRpYXRlIHRlbXBvcmFyeSByZXN1bHQuPG86cD48L286cD48L3A+DQo8cD5Q bGVhc2UgY2FwaXRhbGl6ZSBvbiB0aGlzIG9wcG9ydHVuaXR5IHRvICZxdW90O2tlZXAgc2ltcGxl IHRoaW5ncyBzaW1wbGUmcXVvdDsgLSBvbmUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgcHJpbmNpcGxl cyBzdGF0ZWQgYnkgdGhlIGNoYWlycyBvbiBzbGlkZSAyMiBvZiB0aGVpciBvcGVuaW5nIHByZXNl bnRhdGlvbiBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMv c2xpZGVzL3NsaWRlcy05My1jb3NlLTIucGRmIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85My9zbGlkZXMvc2xpZGVzLTkzLWNvc2UtMi5wZGY8L2E+LiBFc3BlY2lhbGx5IGluIGxp Z2h0IG9mIHRoZSBmYWN0IHRoYXQgbWFueSBpbXBsZW1lbnRhdGlvbnMgd29uJ3QgbmVlZCBzdXBw b3J0IGZvciBleHRlcm5hbF9hYWQsIHBlciBpc3N1ZQ0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL2Nvc2Utd2cvY29zZS1pc3N1ZXMvaXNzdWVzLzUwIiB0aXRsZT0iQWRkIHRoZSBzdGF0ZW1l bnQ6ICZxdW90O0NPU0UgaW1wbGVtZW50YXRpb25zIG9ubHkgbmVlZCB0byBpbXBsZW1lbnQgdGhl IGZlYXR1cmVzIG5lZWRlZCBmb3IgdGhlIGFwcGxpY2F0aW9ucyB0aGV5IGFyZSBkZXNpZ25lZCB0 byBzdXBwb3J0JnF1b3Q7Ij4NCiM1MDwvYT4sIHBsZWFzZSBtYWtlIHRoZXNlIGltcGxlbWVudGF0 aW9ucyBzaW1wbGVyIGJ5IG1ha2luZyB0aGUgcHJlc2VuY2Ugb2YgdGhlIGV4dGVybmFsX2FhZCBh cnJheSBtZW1iZXIgb3B0aW9uYWwuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0iLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0Om5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij7igJQ8YnI+ DQpSZXBseSB0byB0aGlzIGVtYWlsIGRpcmVjdGx5IG9yIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9jb3NlLXdnL2Nvc2UtaXNzdWVzL2lzc3Vlcy80OCNpc3N1ZWNvbW1lbnQtMTYzMDExMTQz Ij4NCnZpZXcgaXQgb24gR2l0SHViPC9hPi48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0 PSIxIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMTMxQjkuOUI2 RDJGRjAiIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIj48L3NwYW4+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442C938387967335B47FCB0F5080BY2PR03MB442namprd_-- From nobody Tue Dec 8 15:23:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1441ACE0F for ; Tue, 8 Dec 2015 15:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 4LOcnRkHlMLd for ; Tue, 8 Dec 2015 15:23:41 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194781ACE0D for ; Tue, 8 Dec 2015 15:23:41 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 4774B2CA24; Tue, 8 Dec 2015 15:23:40 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> In-Reply-To: Date: Tue, 8 Dec 2015 15:20:54 -0800 Message-ID: <035601d1320f$16766090$436321b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0357_01D131CC.0857B470" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJY+7PJPQiRbWKu9aVD9Lyha8uQhAGyX8GTAn1FzXgDEZTOQJ14HDLw Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 23:23:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0357_01D131CC.0857B470 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Tuesday, December 08, 2015 2:55 PM To: Jim Schaad Cc: cose@ietf.org Subject: RE: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 Your way has conditional logic for constructing the data structures = depending upon whether an external_aad value is supplied. So does mine. = So both have =E2=80=9Ctwo ways of doing things=E2=80=9D =E2=80=93 not = one way. The difference is only whether a zero-length field is supplied = or whether it=E2=80=99s omitted, which is pretty much equivalent from a = security and timing perspective. =20 No =E2=80=93 I do not have any logic about adding the value. I = initialize my environment to be a zero length aad value and always add = it to the computation. If we pick up your change then I would have to = add logic into the system to deal with the presence or lack of it. = Similarly if there is no support at all for external add value there is = no conditions =E2=80=93 a zero length bstring (i.e one byte) is always = added to the value computed. =20 This is simpler than the logic your version would require me to = implement. =20 You seem worried about implementation errors, which I agree is often a = valid concern. The good news in this case is that incorrect = implementations will generate the wrong signature or HMAC value, causing = the implementation to fail during interop testing, well before = it=E2=80=99s ever deployed. Normal testing/debugging will catch this. =20 The additional simplification that my proposal enables is that an = implementation can have zero code about external_aad if it=E2=80=99s not = supported, where with your representation, the implementation still has = to have code to insert the unnecessary and unused array value. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Tuesday, December 8, 2015 1:29 PM To: Mike Jones > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 I do not believe that invoking security is incorrect in this instance. = The statement that security issues tend to arise on parsing is not = something I would accept as a given. I have probably seen just as many = or more problems with building strings, random number generation, timing = attacks as I have seen parsing errors. I don=E2=80=99t think that is a = supportable proposition. =20 You and I have different ideas on what it means to =E2=80=9Ckeep things = simple=E2=80=9D. For me, one way of doing things without options is = always simpler and less prone to error. Thus to me having a fixed array = is the simpler option. It does not matter if the specific = implementation does or does not support external aad, creating the one = additional field in the array is not the same burden as the same thing = is going to be for those implementations that do implement the external = aad feature. Making it optional introduces a new state into the system = of a zero length aad which is different from no aad. =20 Again in my opinion =E2=80=93 the current version is simpler that what = you are proposing. =20 Jim =20 =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 12:39 PM To: cose-wg/cose-issues > Cc: Jim Schaad > Subject: Re: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 Invoking security seems incorrect and overstated here. These values are = never parsed - which is when security issues tend to arise. They are = just created internally and then used as serialized byte array inputs to = cryptographic operations. There is no security problem with having both = 3-member and 4-member array values for this intermediate temporary = result. Please capitalize on this opportunity to "keep simple things simple" - = one of the working group principles stated by the chairs on slide 22 of = their opening presentation at = https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. = Especially in light of the fact that many implementations won't need = support for external_aad, per issue #50 = , please make these = implementations simpler by making the presence of the external_aad array = member optional. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_000_0357_01D131CC.0857B470 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Tuesday, December 08, 2015 2:55 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = cose@ietf.org
Subject: RE: [cose-issues] Move external_aad to = the end of structures using it and make its presence optional = (#48)

 

Your way has conditional logic for constructing the data structures = depending upon whether an external_aad value is supplied.  So does = mine.  So both have =E2=80=9Ctwo ways of doing things=E2=80=9D = =E2=80=93 not one way.  The difference is only whether a = zero-length field is supplied or whether it=E2=80=99s omitted, which is = pretty much equivalent from a security and timing = perspective.

 

No =E2=80=93 I do not have any logic about adding the value.=C2=A0 I = initialize my environment to be a zero length aad value and always add = it to the computation.=C2=A0 If we pick up your change then I = =C2=A0would have to add logic into the system to deal with the presence = or lack of it.=C2=A0 Similarly if there is no support at all for = external add value there is no conditions =E2=80=93 a zero length = bstring (i.e one byte) is always added to the value = computed.

 

This is simpler than the logic your version would require me to = implement.

 

You seem worried about implementation errors, which I agree is often a = valid concern.  The good news in this case is that incorrect = implementations will generate the wrong signature or HMAC value, causing = the implementation to fail during interop testing, well before = it=E2=80=99s ever deployed.  Normal testing/debugging will catch = this.

 

The additional simplification that my proposal enables is that an = implementation can have zero code about external_aad if it=E2=80=99s not = supported, where with your representation, the implementation still has = to have code to insert the unnecessary and unused array = value.

 

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   -- Mike

 

From:<= /b> = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Tuesday, December 8, 2015 1:29 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: cose@ietf.org
Subject: RE: = [cose-issues] Move external_aad to the end of structures using it and = make its presence optional (#48)

 

I do not believe that invoking security is incorrect in this = instance.  The statement that security issues tend to arise on = parsing is not something I would accept as a given.  I have = probably seen just as many or more problems with building strings, = random number generation, timing attacks as I have seen parsing = errors.   I don=E2=80=99t think that is a supportable = proposition.

 

You and I have different ideas on what it means to =E2=80=9Ckeep things = simple=E2=80=9D.  For me, one way of doing things without options = is always simpler and less prone to error.  Thus to me having a = fixed array is the simpler option.  It does not matter if the = specific implementation does or does not support external aad, creating = the one additional field in the array is not the same burden as the same = thing is going to be for those implementations that do implement the = external aad feature.  Making it optional introduces a new state = into the system of a zero length aad which is different from no = aad.

 

Again in my opinion =E2=80=93 the current version is simpler that what = you are proposing.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:notifications@github.com<= /a>]
Sent: Tuesday, December 08, 2015 12:39 PM
To: = cose-wg/cose-issues <cose-issues@noreply.github= .com>
Cc: Jim Schaad <ietf@augustcellars.com>
= Subject: Re: [cose-issues] Move external_aad to the end of = structures using it and make its presence optional = (#48)

 

Invoking security seems = incorrect and overstated here. These values are never parsed - which is = when security issues tend to arise. They are just created internally and = then used as serialized byte array inputs to cryptographic operations. = There is no security problem with having both 3-member and 4-member = array values for this intermediate temporary = result.

Please capitalize on this opportunity to = "keep simple things simple" - one of the working group = principles stated by the chairs on slide 22 of their opening = presentation at = https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. = Especially in light of the fact that many implementations won't need = support for external_aad, per issue #50, please make these implementations simpler by = making the presence of the external_aad array member = optional.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_000_0357_01D131CC.0857B470-- From nobody Tue Dec 8 23:05:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6B91ACEF8 for ; Tue, 8 Dec 2015 23:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 sQbEp49xkb6t for ; Tue, 8 Dec 2015 23:05:05 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B001AD079 for ; Tue, 8 Dec 2015 23:05:05 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 92F2738F08; Tue, 8 Dec 2015 23:05:04 -0800 (PST) From: "Jim Schaad" To: "'Francesca Palombini'" , References: In-Reply-To: Date: Tue, 8 Dec 2015 23:02:18 -0800 Message-ID: <03b901d1324f$8b97ed90$a2c7c8b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BA_01D1320C.7D7E98A0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQKqhtmtZ3pImNnwms00T1yv8Wfi+J0PkVeA Archived-At: Subject: Re: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 07:05:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03BA_01D1320C.7D7E98A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Putting this in CDDL would be helpful From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Francesca Palombini Sent: Tuesday, December 08, 2015 7:00 AM To: cose@ietf.org Subject: [COSE] Message size considerations Hi, We have re-calculated the message sizes for the different use cases that are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column "overhead cose-msg-08" of table below). We think that the COSE_Encrypt format is well designed for applications which have tight requirements on message size, the overhead being of the order of 10 bytes (excluding tag and necessary header parameters of size which depends on application). We don't see any reason why we should get twice the overhead if we MAC or Sign a message instead. In this mail we propose some optimizations that mainly have an impact on the other formats, see column "overhead with mod" in the table below. In order to decrease the message size overhead we propose to add 2 new message types: one for single signature (1) (in our use case we don't need multiple signatures), and one for MAC with no recipient (2). The rest of the mail is discussing the optimizations and our proposal. We thought to start this discussion here in the mailing list, but we could also add our requests in the issue tracker if it is preferred. Reading up on the discussion about COSE structure for single signer [2], [3], we could not find any "closure" to that discussion, and like to revisit the topic again. Analogously to the COSE_Encrypted structure, we consider that all information necessary for the cryptographic operations is pre-established between the endpoints. The Context Identifier sent protected in the message is enough to identify the security context and all the parameters necessary for crypto computations (alg, key, etc) previously set up in the endpoints. Because of that, we don't need to send the signer/recipient info in the message, and we suggest to optimize the COSE structure for this use case. We propose the following modifications: a. remove the alg parameter from the message sent: since all information is pre-established in the nodes' security context, we don't need to send the alg in the message. (saves 2B) b. for the new single-signature structure (1), we only need to send the btstr 'signature', we can remove the 'signatures' and 'COSE_signature' structure. The Context Identifier and the Sequence Number are sent in the COSE_Sign protected header. (saves 5B) c. remove the recipient structure from the new MAC structure (2). (saves 8B) d. as for b, for the COSE_Encrypt with counter signature use case, we propose to give the choice to use the whole COSE_Signature structure or only the btstr 'signature' as 'counter signature'. If we only send the btstr 'signature' (our use case), we assume that the alg for counter signature is also defined in the security context. (saves 8B) Even if these improvements may seem small, please note that in some cases the difference is half the total overhead, which is not insignificant. Table: Message overhead +--------------+-------------+----------+------------+ | COSE | overhead | overhead | difference | | Structure | cose-msg-08 | with mod | | +--------------+-------------+----------+------------+ | COSE_Sign | 18 B | 11 B | 7 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 11 B | 9 B | 2 B | +--------------+-------------+----------+------------+ | COSE_Mac | 20 B | 10 B | 10 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 20 B | 12 B | 8 B | | +counter sig | | | | +--------------+-------------+----------+------------+ As a summary, this is how we would modify the COSE_Message structures in order to optimize the message size, and how many bytes we would save from each modification: COSE_Sign: [protected, unprotected, payload, [[ protected, unprotected, signature]]] Bytes removed: -2B(b) -1B(b) -4B(a,b) COSE_Sign single signature (new type): [protected, unprotected, payload, signature] COSE_Mac: [protected, unprotected, payload, tag, [[ protected, unprotected, ciphertext]]] Bytes removed: -2B(a) -2B(c) -1B(c) -4B(a,c) -1B(c) COSE_Mac no recipient (new type): [protected, unprotected, payload, tag] COSE_Encrypt: [protected, unprotected, ciphertext] Bytes removed: -2B(a) COSE_Encrypt: [protected, unprotected, ciphertext] COSE_Encrypt with counter signature: [protected, {7:[protected, unprotected, signature], .}, ciphertext] Bytes removed: -2B(a) -1B(d) -1B(d) -4B(a,d) COSE_Encrypt with counter signature mod: [protected, {7: signature, .}, ciphertext] To meet Jim's arguments against b. and c. in his previous message [2] (most recent message I could find about this topic): "4. There is currently a very clear cut rule about things only being used at the layer they are placed in. This means that currently key identifiers are never placed in the same layer as a content key algorithm. This would be broken by the proposal put forth. I worry that once this is done, there will be more items than kid that will migrate between layers. One of the things that I never liked in the JOSE proposals what the number of places that one needed to look for the various control fields. Currently in COSE this is limited to two places. If we introduce the possibility of cross layer contamination then this number might grow in the future to deal with implementation faults. One of the way that these faults might develop is for designers to say - I think that this should be authenticated, and thus will put it at the wrong layer to ensure that it is. Either without thinking about the question - should it be authenticated, or a different algorithm be required so that authentication is possible." We suggest to have one layer only for this specific use case where we don't use this recipient/signer structure anyway, in new structures adapted for this use case. We are not proposing to change the current structures, which would be used when recipient/signer structures are necessary. "5. Code size is going to be very different if two different methods of dealing with structure needs to be supported. It is currently being assumed that direct key is going to be the major use case in a number of situations. If this is not the case then current proposals do not help the situation any. If it is true that more than one method of key management needs to be supported then the code size is going to grow because of the need to support an additional way that key management is going to be done." In our particular application of COSE, we don't need to support use cases with recipient/signer structures. The creation of different msg types as we suggest should make implementation easier. Francesca [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 [2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY [3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc ------=_NextPart_000_03BA_01D1320C.7D7E98A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Putting this in CDDL would be = helpful

 

From: COSE = [mailto:cose-bounces@ietf.org] On Behalf Of Francesca = Palombini
Sent: Tuesday, December 08, 2015 7:00 = AM
To: cose@ietf.org
Subject: [COSE] Message size = considerations

 

Hi,

 

 

We have = re-calculated the message sizes for the different use cases that are = relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column = “overhead cose-msg-08” of table below). =

 

We think = that the COSE_Encrypt format is well designed for applications which = have tight requirements on message size, the overhead being of the order = of 10 bytes (excluding tag and necessary header parameters of size which = depends on application). We don't see any reason why we should get twice = the overhead if we MAC or Sign a message = instead.

 

In this mail = we propose some optimizations that mainly have an impact on the other = formats, see column “overhead with mod” in the table below. =

 

In order to = decrease the message size overhead we propose to add 2 new message = types: one for single signature (1) (in our use case we don't need = multiple signatures), and one for MAC with no recipient = (2).

 

The rest of = the mail is discussing the optimizations and our proposal. We thought to = start this discussion here in the mailing list, but we could also add = our requests in the issue tracker if it is = preferred.

 

 

 

Reading up = on the discussion about COSE structure for single signer [2], [3], we = could not find any "closure" to that discussion, and like to = revisit the topic again.

 

Analogously to the COSE_Encrypted = structure, we consider that all information necessary for the = cryptographic operations is pre-established between the endpoints. The = Context Identifier sent protected in the message is enough to identify = the security context and all the parameters necessary for crypto = computations (alg, key, etc) previously set up in the endpoints. Because = of that, we don't need to send the signer/recipient info in the message, = and we suggest to optimize the COSE structure for this use = case.

 

 

We propose the following = modifications:

 

a. remove = the alg parameter from the message sent: since all information is = pre-established in the nodes' security context, we don't need to send = the alg in the message. (saves 2B)

 

b. for the new single-signature = structure (1), we only need to send the btstr 'signature', we can remove = the 'signatures' and 'COSE_signature' structure. The Context Identifier = and the Sequence Number are sent in the COSE_Sign protected header. = (saves 5B)

 

c. remove = the recipient structure from the new MAC structure (2). (saves = 8B)

 

d. as for b, = for the COSE_Encrypt with counter signature use case, we propose to give = the choice to use the whole COSE_Signature structure or only the btstr = 'signature' as ‘counter signature’.

If we only = send the btstr 'signature' (our use case), we assume that the alg for = counter signature is also defined in the security context. (saves = 8B)

 

 

Even if these improvements may seem = small, please note that in some cases the difference is half the total = overhead, which is not insignificant.

 

 

Table: = Message overhead

 

+--------------+-------------+----------+------------+

|      COSE    |  = overhead   | overhead | difference |

|  = Structure   | cose-msg-08 | with mod = |            = |

+--------------+-------------+----------+------------+

| COSE_Sign    |     18 = B    |   11 B   = |     7 B    = |

+--------------+-------------+----------+------------+

| COSE_Encrypt |     11 B    = |    9 B   |     2 = B    |

+--------------+-------------+----------+------------+

| COSE_Mac     |     20 = B    |   10 B   |    = 10 B    |

+--------------+-------------+----------+------------+

| COSE_Encrypt |     20 B    = |   12 B   |     8 = B    |

| +counter sig = |            = |          = |            = |

+--------------+-------------+----------+------------+

 

 

As a = summary, this is how we would modify the COSE_Message structures in = order to optimize the message size, and how many bytes we would save = from each modification:

 

COSE_Sign: = [protected, unprotected, payload, [[ protected, unprotected, = signature]]]

Bytes = removed:           = ;            =       -2B(b) -1B(b)     = -4B(a,b)

 

COSE_Sign = single signature (new type): [protected, unprotected, payload, = signature]

 

 

COSE_Mac: [protected, unprotected, = payload, tag, [[ protected, unprotected, = ciphertext]]]

Bytes = removed:           = -2B(a)           &= nbsp;   -2B(c) -1B(c)     = -4B(a,c)    -1B(c)

 

COSE_Mac no recipient (new type): = [protected, unprotected, payload, tag]

 

 

COSE_Encrypt: [protected, unprotected, = ciphertext]

Bytes removed:   = -2B(a)

 

COSE_Encrypt: [protected, unprotected, = ciphertext]

 

 

COSE_Encrypt with counter signature: = [protected, {7:[protected, unprotected, signature], …}, = ciphertext]

Bytes = removed:           = ;            =    -2B(a)  -1B(d) -1B(d)    = -4B(a,d)

 

COSE_Encrypt = with counter signature mod: [protected, {7: signature, …}, = ciphertext]

 

 

To meet Jim's arguments against b. = and c. in his previous message [2] (most recent message I could find = about this topic):

 

"4.  There is currently a very clear cut rule about = things only being used at the layer they are placed in.  This means = that currently key identifiers are never placed in the same layer as a = content key algorithm.  This would be broken by the proposal put = forth.  I worry that once this is done, there will be more items = than kid that will migrate between layers.  One of the things that = I never liked in the JOSE proposals what the number of places that one = needed to look for the various control fields.  Currently in COSE = this is limited to two places.  If we introduce the possibility of = cross layer contamination then this number might grow in the future to = deal with implementation faults.  

One of the = way that these faults might develop is for designers to say - I think = that this should be authenticated, and thus will put it at the wrong = layer to ensure that it is.  Either without thinking about the = question - should it be authenticated, or a different algorithm be = required so that authentication is = possible."

 

We suggest = to have one layer only for this specific use case where we don't use = this recipient/signer structure anyway, in new structures adapted for = this use case. We are not proposing to change the current structures, = which would be used when recipient/signer structures are = necessary.

 

"5.  Code size is going to be very different if two = different methods of dealing with structure needs to be supported.  = It is currently being assumed that direct key is going to be the major = use case in a number of situations. If this is not the case then current = proposals do not help the situation any.  If it is true that more = than one method of key management needs to be

supported = then the code size is going to grow because of the need to support an = additional way that key management is going to be = done."

 

In our = particular application of COSE, we don't need to support use cases with = recipient/signer structures. The creation of different msg types as we = suggest should make implementation easier.

 

Francesca

 

 

[1] https://tools.ietf.org/html/draft-selander-ace-object-security-03

 

[2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSea= zxUY

 

[3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMx= QGbc

 

 

------=_NextPart_000_03BA_01D1320C.7D7E98A0-- From nobody Wed Dec 9 09:51:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5881B2AFE for ; Wed, 9 Dec 2015 09:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 mo41g-wTS3fX for ; Wed, 9 Dec 2015 09:51:16 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 2D1101B2A98 for ; Wed, 9 Dec 2015 09:51:16 -0800 (PST) Received: by ioir85 with SMTP id r85so67808761ioi.1 for ; Wed, 09 Dec 2015 09:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kqrDtjp39fuEmHnQQ8Lc59CTRI1CgEOXUAW3Z9vPxQE=; b=dbbHOYKa0+Fa1JoYAssKjvT3mFXO0kVn17QbjuOv9J8MKkKj000bp/hGzobX1hoDWV Fh9h1aJ0uqOSgU59CYsXq2+cMe6x2tICj9u2dNnI6crNLT6V69m937SovM5CMuqtLe18 uOLa/kPOWVSPd8fKcZKL2+hHer9yLXq9YVHXo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kqrDtjp39fuEmHnQQ8Lc59CTRI1CgEOXUAW3Z9vPxQE=; b=K8nkPEpttdsPojLBwSfZQNwEiM9esGITQHOuwXlgaWWI/xt9SJLW/s8SUAwd+LhX9L ktvrinSRMrStZnUYOwHRrSr9mVKg5A6vpyIl+Y//Tl0S+utttb+91Rdy5BEVg+uODivH 1px4joUYu2YZbj4sNXlJBYeHCksWbdSIK7SXWBeH/P2aTbjOePyIQ+DmUVSDBmJlksXi HTeH+e1JjlFk5As6KYpTI/gskLvTMtk6aZiUo1O55w4ALjjbyGKbXLIwHOikS4yvzRvP 6HvVn/D5BPHaM4SFpVyN7MvtJfgTwJ6xyIP0TV6DQXsiUnPMpcD60cONtMoeJcS9HJbB 1FyA== X-Gm-Message-State: ALoCoQnG+fK5v/WqY3mj6PWK/hqoLfpJICYgzb3JVP+8/P2WSh3Xqb6hPM8Z+B7qG6iOmSzFLhVw8kt22qk9WwAcsQVtvgx/soGTqCSf6kdMG6o2mQ73C3o= X-Received: by 10.107.36.208 with SMTP id k199mr7736133iok.147.1449683475418; Wed, 09 Dec 2015 09:51:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Wed, 9 Dec 2015 09:50:45 -0800 (PST) In-Reply-To: <035601d1320f$16766090$436321b0$@augustcellars.com> References: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> <035601d1320f$16766090$436321b0$@augustcellars.com> From: Brian Campbell Date: Wed, 9 Dec 2015 10:50:45 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11405f04971a7e05267abc30 Archived-At: Cc: Mike Jones , cose@ietf.org Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 17:51:18 -0000 --001a11405f04971a7e05267abc30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I dare say that simplicity is in the eye of the beholder here. Depending on one's perspective, it's quite reasonable to argue that either approach is simpler. What's less subjective is the matter of message size. Using a 3 element array when there's no external aad does result in a smaller message for that arguably common case. It's only one byte smaller but it is smaller and even a single byte is meaningful when the amount of overhead being discussed is in the 10-20 byte neighborhood - http://www.ietf.org/mail-archive/web/cose/current/msg00850.html . On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad wrote: > > > > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Tuesday, December 08, 2015 2:55 PM > *To:* Jim Schaad > *Cc:* cose@ietf.org > *Subject:* RE: [cose-issues] Move external_aad to the end of structures > using it and make its presence optional (#48) > > > > Your way has conditional logic for constructing the data structures > depending upon whether an external_aad value is supplied. So does mine. > So both have =E2=80=9Ctwo ways of doing things=E2=80=9D =E2=80=93 not one= way. The difference is > only whether a zero-length field is supplied or whether it=E2=80=99s omit= ted, which > is pretty much equivalent from a security and timing perspective. > > > > No =E2=80=93 I do not have any logic about adding the value. I initializ= e my > environment to be a zero length aad value and always add it to the > computation. If we pick up your change then I would have to add logic > into the system to deal with the presence or lack of it. Similarly if > there is no support at all for external add value there is no conditions = =E2=80=93 > a zero length bstring (i.e one byte) is always added to the value compute= d. > > > > This is simpler than the logic your version would require me to implement= . > > > > You seem worried about implementation errors, which I agree is often a > valid concern. The good news in this case is that incorrect > implementations will generate the wrong signature or HMAC value, causing > the implementation to fail during interop testing, well before it=E2=80= =99s ever > deployed. Normal testing/debugging will catch this. > > > > The additional simplification that my proposal enables is that an > implementation can have zero code about external_aad if it=E2=80=99s not = supported, > where with your representation, the implementation still has to have code > to insert the unnecessary and unused array value. > > > > -- Mike > > > > *From:* Jim Schaad [mailto:ietf@augustcellars.com ] > > *Sent:* Tuesday, December 8, 2015 1:29 PM > *To:* Mike Jones > *Cc:* cose@ietf.org > *Subject:* RE: [cose-issues] Move external_aad to the end of structures > using it and make its presence optional (#48) > > > > I do not believe that invoking security is incorrect in this instance. > The statement that security issues tend to arise on parsing is not > something I would accept as a given. I have probably seen just as many o= r > more problems with building strings, random number generation, timing > attacks as I have seen parsing errors. I don=E2=80=99t think that is a > supportable proposition. > > > > You and I have different ideas on what it means to =E2=80=9Ckeep things s= imple=E2=80=9D. > For me, one way of doing things without options is always simpler and les= s > prone to error. Thus to me having a fixed array is the simpler option. = It > does not matter if the specific implementation does or does not support > external aad, creating the one additional field in the array is not the > same burden as the same thing is going to be for those implementations th= at > do implement the external aad feature. Making it optional introduces a n= ew > state into the system of a zero length aad which is different from no aad= . > > > > Again in my opinion =E2=80=93 the current version is simpler that what yo= u are > proposing. > > > > Jim > > > > > > *From:* Mike Jones [mailto:notifications@github.com > ] > *Sent:* Tuesday, December 08, 2015 12:39 PM > *To:* cose-wg/cose-issues > *Cc:* Jim Schaad > *Subject:* Re: [cose-issues] Move external_aad to the end of structures > using it and make its presence optional (#48) > > > > Invoking security seems incorrect and overstated here. These values are > never parsed - which is when security issues tend to arise. They are just > created internally and then used as serialized byte array inputs to > cryptographic operations. There is no security problem with having both > 3-member and 4-member array values for this intermediate temporary result= . > > Please capitalize on this opportunity to "keep simple things simple" - on= e > of the working group principles stated by the chairs on slide 22 of their > opening presentation at > https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. > Especially in light of the fact that many implementations won't need > support for external_aad, per issue #50 > , please make these > implementations simpler by making the presence of the external_aad array > member optional. > > =E2=80=94 > Reply to this email directly or view it on GitHub > = .[image: > Image removed by sender.] > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --001a11405f04971a7e05267abc30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I dare say that simplicity is in the eye of the behol= der here. Depending on one's perspective, it's quite reasonable to = argue that either approach is simpler.

What's less subjec= tive is the matter of message size. Using a 3 element array when there'= s no external aad does result in a smaller message for that arguably common= case. It's only one byte smaller but it is smaller and even a single b= yte is meaningful when the amount of overhead being discussed is in the 10-= 20 byte neighborhood - http://www.ietf.org/mail-archive/web/cose/current/m= sg00850.html .

On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad &l= t;ietf@augustce= llars.com> wrote:

=C2=A0

=C2=A0

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Tuesday, December 08, 2015 2:55 PM
To: Jim Schaad <= ietf@augustcell= ars.com>
Cc: cose@ietf.org
Subject: RE: [cose-issue= s] Move external_aad to the end of structures using it and make its presenc= e optional (#48)

=C2=A0

Your = way has conditional logic for constructing the data structures depending up= on whether an external_aad value is supplied.=C2=A0 So does mine.=C2=A0 So = both have =E2=80=9Ctwo ways of doing things=E2=80=9D =E2=80=93 not one way.= =C2=A0 The difference is only whether a zero-length field is supplied or wh= ether it=E2=80=99s omitted, which is pretty much equivalent from a security= and timing perspective.

=C2=A0

No =E2=80=93 I do not have any logic about adding the value.=C2=A0 I = initialize my environment to be a zero length aad value and always add it t= o the computation.=C2=A0 If we pick up your change then I =C2=A0would have = to add logic into the system to deal with the presence or lack of it.=C2=A0= Similarly if there is no support at all for external add value there is no= conditions =E2=80=93 a zero length bstring (i.e one byte) is always added = to the value computed.

=C2=A0

This is simpler than the logic your version would require me to impleme= nt.

=C2=A0

You seem worried about implementation errors, which I agree is often a = valid concern.=C2=A0 The good news in this case is that incorrect implement= ations will generate the wrong signature or HMAC value, causing the impleme= ntation to fail during interop testing, well before it=E2=80=99s ever deplo= yed.=C2=A0 Normal testing/debugging will catch this.

=C2=A0

The additional simplification that my pro= posal enables is that an implementation can have zero code about external_a= ad if it=E2=80=99s not supported, where with your representation, the imple= mentation still has to have code to insert the unnecessary and unused array= value.

=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2= =A0

From:<= /b> Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Tuesday, December 8, = 2015 1:29 PM
To: Mike Jones <Michael.Jones@microsoft.com>
C= c: cose@ietf.org=
Subject: RE: [cose-issues] Move external_aad to the end of struc= tures using it and make its presence optional (#48)

=C2=A0

I do not believe that invoking security is incorrect= in this instance.=C2=A0 The statement that security issues tend to arise o= n parsing is not something I would accept as a given.=C2=A0 I have probably= seen just as many or more problems with building strings, random number ge= neration, timing attacks as I have seen parsing errors.=C2=A0=C2=A0 I don= =E2=80=99t think that is a supportable proposition.

=C2=A0

You and I have different ideas on what it = means to =E2=80=9Ckeep things simple=E2=80=9D.=C2=A0 For me, one way of doi= ng things without options is always simpler and less prone to error.=C2=A0 = Thus to me having a fixed array is the simpler option.=C2=A0 It does not ma= tter if the specific implementation does or does not support external aad, = creating the one additional field in the array is not the same burden as th= e same thing is going to be for those implementations that do implement the= external aad feature.=C2=A0 Making it optional introduces a new state into= the system of a zero length aad which is different from no aad.<= /u>

=C2=A0

Again in my opinion =E2=80=93= the current version is simpler that what you are proposing.<= /span>

=C2=A0=

Jim

=C2=A0

=C2=A0

From: Mike Jones [mailto:notifications@github= .com]
Sent: Tuesday, December 08, 2015 12:39 PM
To: cose-wg/cose-issues <cose-issues@noreply.github.com>
Cc: Jim= Schaad <iet= f@augustcellars.com>
Subject: Re: [cose-issues] Move exter= nal_aad to the end of structures using it and make its presence optional (#= 48)

=C2= =A0

Invoking security seems incorrect and overstated here. The= se values are never parsed - which is when security issues tend to arise. T= hey are just created internally and then used as serialized byte array inpu= ts to cryptographic operations. There is no security problem with having bo= th 3-member and 4-member array values for this intermediate temporary resul= t.

Please capitalize on this opportunity to "keep = simple things simple" - one of the working group principles stated by = the chairs on slide 22 of their opening presentation at = https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. Especi= ally in light of the fact that many implementations won't need support = for external_aad, per issue #50, please make these implementat= ions simpler by making the presence of the external_aad array member option= al.

=E2=80=94
Reply to= this email directly or view it on GitHub.3D"Image<= /u>


__________________________= _____________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--001a11405f04971a7e05267abc30-- From nobody Wed Dec 9 10:17:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576271B2BBC for ; Wed, 9 Dec 2015 10:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 ZHeUrxE_xzPO for ; Wed, 9 Dec 2015 10:16:58 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E94D1B2BBE for ; Wed, 9 Dec 2015 10:16:56 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 6F1EC38F0F; Wed, 9 Dec 2015 10:16:55 -0800 (PST) From: "Jim Schaad" To: "'Brian Campbell'" References: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> <035601d1320f$16766090$436321b0$@augustcellars.com> In-Reply-To: Date: Wed, 9 Dec 2015 10:14:10 -0800 Message-ID: <043f01d132ad$66ed8c30$34c8a490$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0440_01D1326A.58D1C640" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJY+7PJPQiRbWKu9aVD9Lyha8uQhAGyX8GTAn1FzXgDEZTOQAIINqCTAiBIwd2dWBVw8A== Archived-At: Cc: 'Mike Jones' , cose@ietf.org Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 18:17:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0440_01D1326A.58D1C640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Given that this field is never transmitted across the wire, there is no = difference in message size. =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Wednesday, December 09, 2015 9:51 AM To: Jim Schaad Cc: Mike Jones ; cose@ietf.org Subject: Re: [COSE] [cose-issues] Move external_aad to the end of = structures using it and make its presence optional (#48) =20 I dare say that simplicity is in the eye of the beholder here. Depending = on one's perspective, it's quite reasonable to argue that either = approach is simpler.=20 What's less subjective is the matter of message size. Using a 3 element = array when there's no external aad does result in a smaller message for = that arguably common case. It's only one byte smaller but it is smaller = and even a single byte is meaningful when the amount of overhead being = discussed is in the 10-20 byte neighborhood - = http://www.ietf.org/mail-archive/web/cose/current/msg00850.html .=20 =20 On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad > wrote: =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com = ]=20 Sent: Tuesday, December 08, 2015 2:55 PM To: Jim Schaad > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 Your way has conditional logic for constructing the data structures = depending upon whether an external_aad value is supplied. So does mine. = So both have =E2=80=9Ctwo ways of doing things=E2=80=9D =E2=80=93 not = one way. The difference is only whether a zero-length field is supplied = or whether it=E2=80=99s omitted, which is pretty much equivalent from a = security and timing perspective. =20 No =E2=80=93 I do not have any logic about adding the value. I = initialize my environment to be a zero length aad value and always add = it to the computation. If we pick up your change then I would have to = add logic into the system to deal with the presence or lack of it. = Similarly if there is no support at all for external add value there is = no conditions =E2=80=93 a zero length bstring (i.e one byte) is always = added to the value computed. =20 This is simpler than the logic your version would require me to = implement. =20 You seem worried about implementation errors, which I agree is often a = valid concern. The good news in this case is that incorrect = implementations will generate the wrong signature or HMAC value, causing = the implementation to fail during interop testing, well before = it=E2=80=99s ever deployed. Normal testing/debugging will catch this. =20 The additional simplification that my proposal enables is that an = implementation can have zero code about external_aad if it=E2=80=99s not = supported, where with your representation, the implementation still has = to have code to insert the unnecessary and unused array value. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Tuesday, December 8, 2015 1:29 PM To: Mike Jones > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 I do not believe that invoking security is incorrect in this instance. = The statement that security issues tend to arise on parsing is not = something I would accept as a given. I have probably seen just as many = or more problems with building strings, random number generation, timing = attacks as I have seen parsing errors. I don=E2=80=99t think that is a = supportable proposition. =20 You and I have different ideas on what it means to =E2=80=9Ckeep things = simple=E2=80=9D. For me, one way of doing things without options is = always simpler and less prone to error. Thus to me having a fixed array = is the simpler option. It does not matter if the specific = implementation does or does not support external aad, creating the one = additional field in the array is not the same burden as the same thing = is going to be for those implementations that do implement the external = aad feature. Making it optional introduces a new state into the system = of a zero length aad which is different from no aad. =20 Again in my opinion =E2=80=93 the current version is simpler that what = you are proposing. =20 Jim =20 =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 12:39 PM To: cose-wg/cose-issues > Cc: Jim Schaad > Subject: Re: [cose-issues] Move external_aad to the end of structures = using it and make its presence optional (#48) =20 Invoking security seems incorrect and overstated here. These values are = never parsed - which is when security issues tend to arise. They are = just created internally and then used as serialized byte array inputs to = cryptographic operations. There is no security problem with having both = 3-member and 4-member array values for this intermediate temporary = result. Please capitalize on this opportunity to "keep simple things simple" - = one of the working group principles stated by the chairs on slide 22 of = their opening presentation at = https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. = Especially in light of the fact that many implementations won't need = support for external_aad, per issue #50 = , please make these = implementations simpler by making the presence of the external_aad array = member optional. =E2=80=94 Reply to this email directly or view it on GitHub = = . _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_0440_01D1326A.58D1C640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Given that this field is never transmitted across the wire, there is no = difference in message size.

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Wednesday, December 09, 2015 9:51 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Mike Jones = <Michael.Jones@microsoft.com>; cose@ietf.org
Subject: = Re: [COSE] [cose-issues] Move external_aad to the end of structures = using it and make its presence optional = (#48)

 

I dare say that simplicity is in the eye = of the beholder here. Depending on one's perspective, it's quite = reasonable to argue that either approach is simpler. =

What's less subjective is the = matter of message size. Using a 3 element array when there's no external = aad does result in a smaller message for that arguably common case. It's = only one byte smaller but it is smaller and even a single byte is = meaningful when the amount of overhead being discussed is in the 10-20 = byte neighborhood - = http://www.ietf.org/mail-archive/web/cose/current/msg00850.html . =

 

On Tue, = Dec 8, 2015 at 4:20 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Tuesday, December 08, 2015 2:55 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose@ietf.org
Subject: RE: [cose-issues] = Move external_aad to the end of structures using it and make its = presence optional (#48)

 <= /o:p>

Your way has conditional logic for constructing the data structures = depending upon whether an external_aad value is supplied.  So does = mine.  So both have =E2=80=9Ctwo ways of doing things=E2=80=9D = =E2=80=93 not one way.  The difference is only whether a = zero-length field is supplied or whether it=E2=80=99s omitted, which is = pretty much equivalent from a security and timing = perspective.

 

No =E2=80=93 I do not have any logic about adding the value.  I = initialize my environment to be a zero length aad value and always add = it to the computation.  If we pick up your change then I =  would have to add logic into the system to deal with the presence = or lack of it.  Similarly if there is no support at all for = external add value there is no conditions =E2=80=93 a zero length = bstring (i.e one byte) is always added to the value = computed.

 

This is simpler than the logic your version would require me to = implement.

 

You seem worried about implementation errors, which I agree is often a = valid concern.  The good news in this case is that incorrect = implementations will generate the wrong signature or HMAC value, causing = the implementation to fail during interop testing, well before = it=E2=80=99s ever deployed.  Normal testing/debugging will catch = this.

 

The additional simplification that my proposal enables is that an = implementation can have zero code about external_aad if it=E2=80=99s not = supported, where with your representation, the implementation still has = to have code to insert the unnecessary and unused array = value.

 

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   -- Mike

 

From:<= /b> = Jim Schaad [mailto:ietf@augustcellars.com]
Sent: = Tuesday, December 8, 2015 1:29 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: cose@ietf.org
Subject: RE: [cose-issues] = Move external_aad to the end of structures using it and make its = presence optional (#48)

 <= /o:p>

I do not believe that invoking security is incorrect in this = instance.  The statement that security issues tend to arise on = parsing is not something I would accept as a given.  I have = probably seen just as many or more problems with building strings, = random number generation, timing attacks as I have seen parsing = errors.   I don=E2=80=99t think that is a supportable = proposition.

 

You and I have different ideas on what it means to =E2=80=9Ckeep things = simple=E2=80=9D.  For me, one way of doing things without options = is always simpler and less prone to error.  Thus to me having a = fixed array is the simpler option.  It does not matter if the = specific implementation does or does not support external aad, creating = the one additional field in the array is not the same burden as the same = thing is going to be for those implementations that do implement the = external aad feature.  Making it optional introduces a new state = into the system of a zero length aad which is different from no = aad.

 

Again in my opinion =E2=80=93 the current version is simpler that what = you are proposing.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:notifications@github.com]
Sent: = Tuesday, December 08, 2015 12:39 PM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: = Jim Schaad <ietf@augustcellars.com>
Subject: Re: = [cose-issues] Move external_aad to the end of structures using it and = make its presence optional (#48)

 <= /o:p>

Invoking security seems incorrect and overstated here. These = values are never parsed - which is when security issues tend to arise. = They are just created internally and then used as serialized byte array = inputs to cryptographic operations. There is no security problem with = having both 3-member and 4-member array values for this intermediate = temporary result.

Please capitalize on this opportunity = to "keep simple things simple" - one of the working group = principles stated by the chairs on slide 22 of their opening = presentation at https://www.ietf.org/proceedings/93/slides/slides-93-co= se-2.pdf. Especially in light of the fact that many implementations = won't need support for external_aad, per issue #50, please make these implementations = simpler by making the presence of the external_aad array member = optional.

=E2=80=94
Reply to this email directly or view it on = GitHub.


______________________________________= _________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

 

------=_NextPart_000_0440_01D1326A.58D1C640-- From nobody Wed Dec 9 10:28:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7C01B2C74 for ; Wed, 9 Dec 2015 10:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6f4I5X8GLTDR for ; Wed, 9 Dec 2015 10:28:41 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 1F3531B2CD9 for ; Wed, 9 Dec 2015 10:27:42 -0800 (PST) Received: by ioir85 with SMTP id r85so68980347ioi.1 for ; Wed, 09 Dec 2015 10:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cRQRzIvDEDv+S/fl9JNwGQ+nUv+2GwskDV3ht3mSih4=; b=Mtds+ug2Ktxx1BdBY+6IpPbAJW5ok3EmZrqU/c7CjgdRkyz/9tjdqNhzk6JsBDrUmM dLPg/U+ZUMyPaX1+YvAB+kcKftUb+fVMZfExFkMewOgmQhnxooUdJqoIQuOPIVGsiimn 8CguzD4KRi3K6zVD8TE5UwX/q+MMcdAG/P/DY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cRQRzIvDEDv+S/fl9JNwGQ+nUv+2GwskDV3ht3mSih4=; b=TV8IQApPCoLU+4qoSyNiASuYqM9zeW9r36k4jXCPavirQ/kqBqElk0HCQ3Ekj96L5k hBmv5AHuCk4iXLrNTOUmiKko0u9btfnuJ9LNThCMyCGPr3tpuWyWYhIxK5PFrKq286M/ UEgcriYc+lEQk4WfRa1JW4CFPtMDP3Fh5PxVaaLLA2AyJOergbtqzMjIY0CxsQI0C4So m5CR2x13WcOc3fQ3goChvcOYYkuGBDuhQt9lB9zYihGJofBy7UeRYmnCnitxZsNyafiP OeiuJ2PgU9kpiYOsY++28chGQscLVzbKWGhVwUvl+z+yg0Kz3z1e/zD9GGVj5R71KV/a Ebbg== X-Gm-Message-State: ALoCoQmslyIHPLK9oalDL+wTzuyty69VEuc5ZNkTBO93CCTsuPvo47VkkFF3SQtI8WdJSKUG3iwOgHuW2p/TYQhV+MPsrW/P5WKcJtMr5In0A3+gl09zrEs= X-Received: by 10.107.158.213 with SMTP id h204mr8235872ioe.129.1449685661348; Wed, 09 Dec 2015 10:27:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Wed, 9 Dec 2015 10:27:11 -0800 (PST) In-Reply-To: <043f01d132ad$66ed8c30$34c8a490$@augustcellars.com> References: <02fa01d131ff$729e1800$57da4800$@augustcellars.com> <035601d1320f$16766090$436321b0$@augustcellars.com> <043f01d132ad$66ed8c30$34c8a490$@augustcellars.com> From: Brian Campbell Date: Wed, 9 Dec 2015 11:27:11 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a114075c2e1971105267b3ed3 Archived-At: Cc: Mike Jones , cose@ietf.org Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 18:28:44 -0000 --001a114075c2e1971105267b3ed3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My mistake, apologies. On Wed, Dec 9, 2015 at 11:14 AM, Jim Schaad wrote: > Given that this field is never transmitted across the wire, there is no > difference in message size. > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, December 09, 2015 9:51 AM > *To:* Jim Schaad > *Cc:* Mike Jones ; cose@ietf.org > *Subject:* Re: [COSE] [cose-issues] Move external_aad to the end of > structures using it and make its presence optional (#48) > > > > I dare say that simplicity is in the eye of the beholder here. Depending > on one's perspective, it's quite reasonable to argue that either approach > is simpler. > > What's less subjective is the matter of message size. Using a 3 element > array when there's no external aad does result in a smaller message for > that arguably common case. It's only one byte smaller but it is smaller a= nd > even a single byte is meaningful when the amount of overhead being > discussed is in the 10-20 byte neighborhood - > http://www.ietf.org/mail-archive/web/cose/current/msg00850.html . > > > > On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad wrote= : > > > > > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Tuesday, December 08, 2015 2:55 PM > *To:* Jim Schaad > *Cc:* cose@ietf.org > *Subject:* RE: [cose-issues] Move external_aad to the end of structures > using it and make its presence optional (#48) > > > > Your way has conditional logic for constructing the data structures > depending upon whether an external_aad value is supplied. So does mine. > So both have =E2=80=9Ctwo ways of doing things=E2=80=9D =E2=80=93 not one= way. The difference is > only whether a zero-length field is supplied or whether it=E2=80=99s omit= ted, which > is pretty much equivalent from a security and timing perspective. > > > > No =E2=80=93 I do not have any logic about adding the value. I initializ= e my > environment to be a zero length aad value and always add it to the > computation. If we pick up your change then I would have to add logic > into the system to deal with the presence or lack of it. Similarly if > there is no support at all for external add value there is no conditions = =E2=80=93 > a zero length bstring (i.e one byte) is always added to the value compute= d. > > > > This is simpler than the logic your version would require me to implement= . > > > > You seem worried about implementation errors, which I agree is often a > valid concern. The good news in this case is that incorrect > implementations will generate the wrong signature or HMAC value, causing > the implementation to fail during interop testing, well before it=E2=80= =99s ever > deployed. Normal testing/debugging will catch this. > > > > The additional simplification that my proposal enables is that an > implementation can have zero code about external_aad if it=E2=80=99s not = supported, > where with your representation, the implementation still has to have code > to insert the unnecessary and unused array value. > > > > -- Mike > > > > *From:* Jim Schaad [mailto:ietf@augustcellars.com ] > > *Sent:* Tuesday, December 8, 2015 1:29 PM > *To:* Mike Jones > *Cc:* cose@ietf.org > *Subject:* RE: [cose-issues] Move external_aad to the end of structures > using it and make its presence optional (#48) > > > > I do not believe that invoking security is incorrect in this instance. > The statement that security issues tend to arise on parsing is not > something I would accept as a given. I have probably seen just as many o= r > more problems with building strings, random number generation, timing > attacks as I have seen parsing errors. I don=E2=80=99t think that is a > supportable proposition. > > > > You and I have different ideas on what it means to =E2=80=9Ckeep things s= imple=E2=80=9D. > For me, one way of doing things without options is always simpler and les= s > prone to error. Thus to me having a fixed array is the simpler option. = It > does not matter if the specific implementation does or does not support > external aad, creating the one additional field in the array is not the > same burden as the same thing is going to be for those implementations th= at > do implement the external aad feature. Making it optional introduces a n= ew > state into the system of a zero length aad which is different from no aad= . > > > > Again in my opinion =E2=80=93 the current version is simpler that what yo= u are > proposing. > > > > Jim > > > > > > *From:* Mike Jones [mailto:notifications@github.com > ] > *Sent:* Tuesday, December 08, 2015 12:39 PM > *To:* cose-wg/cose-issues > *Cc:* Jim Schaad > *Subject:* Re: [cose-issues] Move external_aad to the end of structures > using it and make its presence optional (#48) > > > > Invoking security seems incorrect and overstated here. These values are > never parsed - which is when security issues tend to arise. They are just > created internally and then used as serialized byte array inputs to > cryptographic operations. There is no security problem with having both > 3-member and 4-member array values for this intermediate temporary result= . > > Please capitalize on this opportunity to "keep simple things simple" - on= e > of the working group principles stated by the chairs on slide 22 of their > opening presentation at > https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf. > Especially in light of the fact that many implementations won't need > support for external_aad, per issue #50 > , please make these > implementations simpler by making the presence of the external_aad array > member optional. > > =E2=80=94 > Reply to this email directly or view it on GitHub > = . > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > --001a114075c2e1971105267b3ed3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My mistake, apologies.
--001a114075c2e1971105267b3ed3-- From nobody Wed Dec 9 21:57:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C241B316F for ; Wed, 9 Dec 2015 21:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 YGtwozKMh5WZ for ; Wed, 9 Dec 2015 21:57:15 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D1D1B3167 for ; Wed, 9 Dec 2015 21:57:15 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 324A138EFF; Wed, 9 Dec 2015 21:57:14 -0800 (PST) From: "Jim Schaad" To: "Jones Mike" References: In-Reply-To: Date: Wed, 9 Dec 2015 21:54:28 -0800 Message-ID: <008401d1330f$3bcef540$b36cdfc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01D132CC.2DAD3BE0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJUr44u7k+y6hFVO0U7BSHgtMT5SgIwoC1Pnas3lMA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] [cose-spec] Add Partial IV example (#104) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 05:57:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0085_01D132CC.2DAD3BE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That to me is more of an issue of the text being insufficient. I have = augmented the text to try and address this issue. =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Tuesday, December 08, 2015 12:54 PM To: cose-wg/cose-spec Cc: Jim Schaad Subject: Re: [cose-spec] Add Partial IV example (#104) =20 Maybe it will be clearer once there's a rendered version available, but = it's not clear to me how the Partial IV value 6:24999 is used to create = the actual IV value, or how that relates to the text "Prefix for IV is = 89F52F65A1C580933B52". The intent of the request for the example was for = it to show semantically how the Partial IV value was used in the example = cryptographic computation - not just show syntactically how a Partial IV = value could be carried. =E2=80=94 Reply to this email directly or view it on GitHub = . = = =20 ------=_NextPart_000_0085_01D132CC.2DAD3BE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That to me is more of an issue of the text being insufficient.=C2=A0 I = have augmented the text to try and address this = issue.

 

From:<= /b> = Mike Jones [mailto:notifications@github.com]
Sent: Tuesday, = December 08, 2015 12:54 PM
To: cose-wg/cose-spec = <cose-spec@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-spec] Add = Partial IV example (#104)

 

Maybe it will be clearer once = there's a rendered version available, but it's not clear to me how the = Partial IV value 6:24999 is used to create the actual IV value, or how = that relates to the text "Prefix for IV is = 89F52F65A1C580933B52". The intent of the request for the example = was for it to show semantically how the Partial IV value was used in the = example cryptographic computation - not just show syntactically how a = Partial IV value could be carried.

=E2=80=94
Reply to this email directly or view it on GitHub.

= ------=_NextPart_000_0085_01D132CC.2DAD3BE0-- From nobody Thu Dec 10 07:28:50 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27AE1B32DC for ; Thu, 10 Dec 2015 07:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YGwPajl7EZGf for ; Thu, 10 Dec 2015 07:28:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21B31B32DF for ; Thu, 10 Dec 2015 07:28:46 -0800 (PST) Received: from [192.168.10.142] ([108.178.170.34]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MTjqS-1Zgkqv3H96-00QTsh; Thu, 10 Dec 2015 16:28:43 +0100 To: Francesca Palombini , "cose@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56699A2B.90703@gmx.net> Date: Thu, 10 Dec 2015 16:28:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tpkghD2dIdhBGVW05GBugnxAA8slEJNNV" X-Provags-ID: V03:K0:RdoNN8Uub2OpkSb+gdJqMZGvfTgUxrvijuBulsYXBz6Nx6YfJ12 O/ZrTqmh7Im3tRYVcr8P0/oNOspdqfHaVfEbpZfpVJIwqUo6jDLv/KzYyCH/I4rjmGS1oP6 sqJQU7KLdCEvA+Aj78lkXmuiWDlRVGLztct8pXYlNui6wlfK6OXmOpFwemZitRVbQfcBlLy DJIw/8TBeM9NZNycpsoKQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:mgu150kMBug=:0gCKWkgb1+vUZHoGldKb6p 3zjFVMqx8BcXlCs4Wog0DEMZDR/JWpXkN02PTCvQL45vwMVe2t5kG/vyUTi7x5LDOwuHJuG4h dCx2ny/UAG8+G3z/bMHPu+wYAJXDQdMX6YNQBFwdBKHbPHkwy6OjXp2W+HZ+wVlX+mJNGpOxo wx8U5Nm345juZ1dI3ZT+4+Tci1zKZ4sW9Z0EEoMAmzmaajm0nFMT27BCYx/fhlaRMgXKCYzQe PDmaRZ30NzvKaNU1syP6DI27JAtISZiUlsT3JLRMnjrEZlaWWkO/rNbR0uxnverAKOzAGxQxJ kv8HpK6Yytm9rjbVE/3+5Hkk9i9ZZgLP+dvCf1+49I41XfSJoBlTRKnvTCPNYc1SpGVL3lKzl ML80dpAKX3/jqbZQczjGli0jsvgysJpP0ByeTgbH7azNqfooWCm/Y88t0s78RHO6UQYQH50DC E/tqUzViPmXsNYU+a2kbvKbsq9tRaig/1ldwj9Gwy/j5APXWT4qwcpTtXTUlsg87yINBYMtyQ EyRgnePqCQJ8ljrF2+BVLxR2Z6/ruh7Z0Kf5Qc4ZBeWuNRMnRFbSoxkEcd1ELivstI3InrFSa Uv3DQhExn1q0dUhDr8iAuTXw6alj40crAmaXiwr9VTX56H994pecmqzWSGFXXhLVfoEfebMzp ywBZ8Ivo+c3psStSXR1Pmy8V7hmjhP8BtcInUBB5eTZ6Lvp9JpHKCAUxKQLjr5gE9p0dtiUpp TUnxI9Ldkk1uzH27K6eUHVQcqY4tso0sGqpi2EzPHU/4WoH095bNDcqVOTQ= Archived-At: Subject: Re: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:28:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tpkghD2dIdhBGVW05GBugnxAA8slEJNNV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Francesca, I like your proposal. Thanks for bringing it up. Ciao Hannes On 12/08/2015 04:00 PM, Francesca Palombini wrote: > Hi, >=20 > =20 >=20 > =20 >=20 > We have re-calculated the message sizes for the different use cases tha= t > are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see colum= n > =93overhead cose-msg-08=94 of table below). >=20 > =20 >=20 > We think that the COSE_Encrypt format is well designed for applications= > which have tight requirements on message size, the overhead being of th= e > order of 10 bytes (excluding tag and necessary header parameters of siz= e > which depends on application). We don't see any reason why we should ge= t > twice the overhead if we MAC or Sign a message instead. >=20 > =20 >=20 > In this mail we propose some optimizations that mainly have an impact o= n > the other formats, see column =93overhead with mod=94 in the table belo= w. >=20 > =20 >=20 > In order to decrease the message size overhead we propose to add 2 new > message types: one for single signature (1) (in our use case we don't > need multiple signatures), and one for MAC with no recipient (2). >=20 > =20 >=20 > The rest of the mail is discussing the optimizations and our proposal. > We thought to start this discussion here in the mailing list, but we > could also add our requests in the issue tracker if it is preferred. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Reading up on the discussion about COSE structure for single signer [2]= , > [3], we could not find any "closure" to that discussion, and like to > revisit the topic again. >=20 > =20 >=20 > Analogously to the COSE_Encrypted structure, we consider that all > information necessary for the cryptographic operations is > pre-established between the endpoints. The Context Identifier sent > protected in the message is enough to identify the security context and= > all the parameters necessary for crypto computations (alg, key, etc) > previously set up in the endpoints. Because of that, we don't need to > send the signer/recipient info in the message, and we suggest to > optimize the COSE structure for this use case. >=20 > =20 >=20 > =20 >=20 > We propose the following modifications: >=20 > =20 >=20 > a. remove the alg parameter from the message sent: since all informatio= n > is pre-established in the nodes' security context, we don't need to sen= d > the alg in the message. (saves 2B) >=20 > =20 >=20 > b. for the new single-signature structure (1), we only need to send the= > btstr 'signature', we can remove the 'signatures' and 'COSE_signature' > structure. The Context Identifier and the Sequence Number are sent in > the COSE_Sign protected header. (saves 5B) >=20 > =20 >=20 > c. remove the recipient structure from the new MAC structure (2). (save= s 8B) >=20 > =20 >=20 > d. as for b, for the COSE_Encrypt with counter signature use case, we > propose to give the choice to use the whole COSE_Signature structure or= > only the btstr 'signature' as =91counter signature=92. >=20 > If we only send the btstr 'signature' (our use case), we assume that th= e > alg for counter signature is also defined in the security context. > (saves 8B) >=20 > =20 >=20 > =20 >=20 > Even if these improvements may seem small, please note that in some > cases the difference is half the total overhead, which is not insignifi= cant. >=20 > =20 >=20 > =20 >=20 > Table: Message overhead >=20 > =20 >=20 > +--------------+-------------+----------+------------+ >=20 > | COSE | overhead | overhead | difference | >=20 > | Structure | cose-msg-08 | with mod | | >=20 > +--------------+-------------+----------+------------+ >=20 > | COSE_Sign | 18 B | 11 B | 7 B | >=20 > +--------------+-------------+----------+------------+ >=20 > | COSE_Encrypt | 11 B | 9 B | 2 B | >=20 > +--------------+-------------+----------+------------+ >=20 > | COSE_Mac | 20 B | 10 B | 10 B | >=20 > +--------------+-------------+----------+------------+ >=20 > | COSE_Encrypt | 20 B | 12 B | 8 B | >=20 > | +counter sig | | | | >=20 > +--------------+-------------+----------+------------+ >=20 > =20 >=20 > =20 >=20 > As a summary, this is how we would modify the COSE_Message structures i= n > order to optimize the message size, and how many bytes we would save > from each modification: >=20 > =20 >=20 > COSE_Sign: [protected, unprotected, payload, [[ protected, unprotected,= > signature]]] >=20 > Bytes removed: -2B(b) -1B(b) -4B(a,b) >=20 > =20 >=20 > COSE_Sign single signature (new type): [protected, unprotected, payload= , > signature] >=20 > =20 >=20 > =20 >=20 > COSE_Mac: [protected, unprotected, payload, tag, [[ protected, > unprotected, ciphertext]]] >=20 > Bytes removed: -2B(a) -2B(c) -1B(c) =20 > -4B(a,c) -1B(c) >=20 > =20 >=20 > COSE_Mac no recipient (new type): [protected, unprotected, payload, tag= ] >=20 > =20 >=20 > =20 >=20 > COSE_Encrypt: [protected, unprotected, ciphertext] >=20 > Bytes removed: -2B(a) >=20 > =20 >=20 > COSE_Encrypt: [protected, unprotected, ciphertext] >=20 > =20 >=20 > =20 >=20 > COSE_Encrypt with counter signature: [protected, {7:[protected, > unprotected, signature], =85}, ciphertext] >=20 > Bytes removed: -2B(a) -1B(d) -1B(d) -4B(a,= d) >=20 > =20 >=20 > COSE_Encrypt with counter signature mod: [protected, {7: signature, =85= }, > ciphertext] >=20 > =20 >=20 > =20 >=20 > To meet Jim's arguments against b. and c. in his previous message [2] > (most recent message I could find about this topic): >=20 > =20 >=20 > "4. There is currently a very clear cut rule about things only being > used at the layer they are placed in. This means that currently key > identifiers are never placed in the same layer as a content key > algorithm. This would be broken by the proposal put forth. I worry > that once this is done, there will be more items than kid that will > migrate between layers. One of the things that I never liked in the > JOSE proposals what the number of places that one needed to look for th= e > various control fields. Currently in COSE this is limited to two > places. If we introduce the possibility of cross layer contamination > then this number might grow in the future to deal with implementation > faults. =20 >=20 > One of the way that these faults might develop is for designers to say = - > I think that this should be authenticated, and thus will put it at the > wrong layer to ensure that it is. Either without thinking about the > question - should it be authenticated, or a different algorithm be > required so that authentication is possible." >=20 > =20 >=20 > We suggest to have one layer only for this specific use case where we > don't use this recipient/signer structure anyway, in new structures > adapted for this use case. We are not proposing to change the current > structures, which would be used when recipient/signer structures are > necessary. >=20 > =20 >=20 > "5. Code size is going to be very different if two different methods o= f > dealing with structure needs to be supported. It is currently being > assumed that direct key is going to be the major use case in a number o= f > situations. If this is not the case then current proposals do not help > the situation any. If it is true that more than one method of key > management needs to be >=20 > supported then the code size is going to grow because of the need to > support an additional way that key management is going to be done." >=20 > =20 >=20 > In our particular application of COSE, we don't need to support use > cases with recipient/signer structures. The creation of different msg > types as we suggest should make implementation easier. >=20 > =20 >=20 > Francesca >=20 > =20 >=20 > =20 >=20 > [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 >=20 > =20 >=20 > [2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeaz= xUY >=20 > =20 >=20 > [3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQ= Gbc >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 --tpkghD2dIdhBGVW05GBugnxAA8slEJNNV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWaZosAAoJEGhJURNOOiAtfxQH/2eQlH+kEagZ6BHEckQnJY9W mDobPe8WMk4wsEZlDMumZLU4eSf3EuTxERRHJ3VLVzr5KLFCeCx/4gEDDvLn0mQw y4ZT37JkuslRlSk65UntqulutdVwGoiUZzYnzrX3g39pdljuBEvOGqU/EPQetUrx kp8UmJaymlEEgyjbbHxCjEVXjHH90Nau757vQsy7/AmkiGRH6cL/dNNNb5Byawub P9nedX/EjyfNQDPDLsv61mse6qCME6wntRa34O3JHPQf3sHTWWVRFyNkRGZr1Ujt Db/p1x3So1TaibMyLYglCkAgQxVuQHjp/KDQEgo8vMp64p/mQ2vAMOEN1M8PiKk= =kOv3 -----END PGP SIGNATURE----- --tpkghD2dIdhBGVW05GBugnxAA8slEJNNV-- From nobody Thu Dec 10 07:54:47 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD301A016E for ; Thu, 10 Dec 2015 07:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3i-zKkbisqRR for ; Thu, 10 Dec 2015 07:54:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00E41A015F for ; Thu, 10 Dec 2015 07:54:35 -0800 (PST) Received: from [192.168.10.142] ([108.178.170.34]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MBIAz-1Zz3Jw3kph-00AEQJ; Thu, 10 Dec 2015 16:54:26 +0100 To: Jim Schaad , 'Justin Richer' References: <04e901d119ad$3207bea0$96173be0$@augustcellars.com> <564ECB3C.1070203@mit.edu> <064001d127b1$f9e2a590$eda7f0b0$@augustcellars.com> <98AFE54A-11BC-49FC-87BE-99A5A3760777@mit.edu> <014f01d13092$c5b818b0$51284a10$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5669A02F.8070604@gmx.net> Date: Thu, 10 Dec 2015 16:54:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <014f01d13092$c5b818b0$51284a10$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WqX2McRxSr0TcDgrldh8JsOButAqBibNp" X-Provags-ID: V03:K0:E/T6dHso8ztzy8GQES2yAvGhCjGuWy8dBjEw+QyNqKkQT1j/xf9 xuZYT0RrAL1v9odY8KXvv2VwT5C3N8VmEKhX8DzWjEhRcZIpRUSAyqQe6tLf3JsAplTQ5ET d9M0SMrWC60mCFyfLXddVT6x+mAJCNMhy2QBwsoRPs7GqjAhMOh8GoAbkJVtymFTnA60qit KklgJkjdRE5aHdfDwpPmw== X-UI-Out-Filterresults: notjunk:1;V01:K0:14DA3vdNV0w=:Y/9EVrAmjCklHtUbqHLYRU 6H30CYAfC6bbWSYEoMQHyDU5N0akbSM4Xfw3CibRp0MdXcKHjQof4YAnT/FzJIJ/SYRfCSOTV T/9jEuJUdQbQSN0iJjm6SV+spEarc3H+dLnGZqZVilSZZHnIyop+3Mt5HBCBIdfCUheYdpwzQ gtY9NqsegOW+t0l7OZ4xXjh/WT/ebGpkPJD3+5xYxtMKVClsha6wp/6d+K2OLJZKYCPs6zs0q fEaLXbXznrO8uwLxoxOxidNLSXMtKAU4zfl+kug2V+cLJQYFUVdFVIhtMrpjPjTyIWDJQZXKa pTQr5AB/oiO831iu8LJ+Xc0AEqmzSR6BUY0qNxgdemEb/bwfm4/5OwnpMtBX1/4/PjW9uub6X pyajHWuKyX4WN0v7UMVAISNdxu+0zFgIJXTKj8w6riaJoUWfFxOmwFA1MZavFoSZoUiMrZKFM mXvgiFNA0WtryupfxxwyXDw68rgakPuqP8hkm3js66p6GHJF1FagLlrHiIdUii+ucR0zb2J8T sYbAZM8+lBdxdU3CXniJ14ynhprfCgYA3wnhc58KD6I0stcOZyymjnMXVc/ezQIpDuxoguZbZ dF8CMnliFhFmxlyDqfTbE03SvRbkTuLEK5+hNIQU7TbervX5DkqyAoQ8L/yw5Wf9ei9oxN9z6 u8Tx9TtZlXBdwN7KfC62qfymMj1ExRPMjQPIEgvMfby2Sw40laQsSxLfLFdqfi6H6ewUQip5e QcK4/yZn6i1BiwCjcDaCZPtYn5MFGnjyZuxDRY/ra6ldF1lwEFCsRQQCkYE= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] MAC with no recipient structures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:54:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WqX2McRxSr0TcDgrldh8JsOButAqBibNp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wanted to contribute my thoughts on this statement: > On 11/7/2015 5:39 PM, Jim Schaad wrote: People keep telling me that they want to have a version of MACs that do not have a set of recipient information attached so that they can do direct MACs. I keep asking for a use case where this makes sense. In all of the use cases that I have been presented so far, a better answer is going to be to do an AEAD encrypted item rather than a MACed item. When Erik and I worked on an OAuth doorlock access control scenario and tried to take this aspect into account (based on the suggestion from Jim) by doing two things (with relevance to ACE): * use an AEAD cipher for protection of the JWT, and * use an AEAD cipher for use with the proof of possession when the client talks to the resource serve (=3Ddoor lock) While we haven't used CBOR/COSE yet (but the JWT) it did not lead to any problems from that point of view. The implication of using encryption was that the JWT content was not visible to the client, which it shouldn't be anyway. Of course, there are more scenarios to look into but this is our current experience. We are going to switch to CBOR and COSE and will let you know what the experience was. So, consider this a work-in-progress activity. Ciao Hannes On 12/07/2015 02:58 AM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mit.edu] >> Sent: Wednesday, November 25, 2015 11:04 AM >> To: Jim Schaad >> Cc: Francesca Palombini ; cose@ietf.= org >> Subject: Re: [COSE] MAC with no recipient structures >> >> (As an individual) >> >> Speaking from my own experience with JOSE, the simplicity and utility = of MAC- >> only cannot be denied. I can only see this being compounded in constra= ined >> environments. Decrypting payload means I need to keep two copies of th= e data >> around, I need to manage encryption state, and I need to solve issues = with >> multiple recipients or components that need just read access. All of t= hese go >> away with simple signatures or MACs without losing functionality or se= curity. >> Security is always contextual in the application, and complexity is th= e enemy of >> getting security actually applied in a system. >=20 > I would not agree with some of these points. >=20 > I do believe that MAC has a large utility and is not going to be remove= d. =20 >=20 > I do not necessarily agree that it has a larger amount of utility over = encryption in a constrained environment. One of the big advantages of us= ing CTR modes of encryption is that encrypting in place is even easier th= an it is with any version that does padding. This means that one does no= t necessarily need to have two copies of the data around. =20 >=20 > It is true that there is some additional data that needs to be managed = when doing encryption rather than a MAC. It is not clear that there is a= significant amount of data that needs to be managed. If one assumes tha= t some type of replay counter is maintained in both cases, then this addi= tional data amounts to an IV prefix which is constant and thus has minima= l maintenance associated with it. (I.e. it needs to be kept and associat= ed with the key.) >=20 > The issues dealing with allowing multiple recipients or components that= just need read access is an interesting question to be addressed, and on= e that points to the question that I keep asking. Does that other entity= that needs read access need to have the ability to know that the data is= correct? If the entity needs to be able to validate the information, th= en using MACs or using encryption have the exact same level of complexity= for dealing with multiple recipients and multiple keys. There is a diff= erence between doing "simple signatures" and the MAC/encryption case beca= use how key management is done is completely different. The expected se= curity properties of are very different between the signature and the MAC= case as well. >=20 > Finally, I would point out that the total security system is not necess= arily the same for a constrained and an unconstrained system. OAuth as i= t is commonly used today is sending MAC messages using TLS. The fact tha= t TLS is being used means that, from a security analysis, the only partie= s that would have read access to the MAC message are the parties at each = end of the TLS connection. One does not end up in situations (or at leas= t I am assuming that one does not) where there are proxies that are going= to be between these entities that also have access to the data. This is= not the case many times for a DTLS situation in the constrained environm= ents that are being contemplated where provisions are being made for doin= g things like TLS<=3D>DTLS proxies, proxies that mediate between differen= t sub-networks and so forth are expected components to be dealt with. T= he security system and the analysis associated with it can be very differ= ent between the OpenID case and the access granting=20 case of a CoAP network. >=20 >> >> I see absolutely zero reason to not support this simplified case, and = others have >> made it clear it=E2=80=99s desirable for their use cases. I think the = burden is on you (Jim) >> to prove that it=E2=80=99s not desirable, and I=E2=80=99m not personal= ly seeing support for that >> position in this working group. >=20 > So other than the OSCoAP people, who have a use case that they are plan= ning to use this for? I am hearing a lot of people saying that they need= it because that is what JOSE does. I am not hearing a lot of people say= ing that they have a concrete use case for it. I do not expect that COSE= is going to replace JOSE for general JWT usage. >=20 > Jim >=20 >> >> =E2=80=94 Justin (as an individual, remember) >> >>> On Nov 25, 2015, at 1:49 PM, Jim Schaad wrot= e: >>> >>> Again, let me ask the question. Are you willing to be in a position >>> where the tenant reads and acts on an incorrect data value since it >>> cannot validate the MAC on the data. >>> >>>> -----Original Message----- >>>> From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] >>>> Sent: Wednesday, November 25, 2015 6:43 AM >>>> To: Mike Jones ; Jim Schaad >>>> ; cose@ietf.org >>>> Subject: RE: [COSE] MAC with no recipient structures >>>> >>>> Hi, >>>> >>>> In the context of "visibility" another use case was mentioned before= (*): >>>> electricity consumption is measured by a meter, forwarded to a >>>> gateway >>> where >>>> the tenant reads the consumption and further to the distribution ope= rator. >>> The >>>> communication between meter and gateway, and gateway and network is >>>> protected on transport layer; and between meter and network on >>>> application layer, using COSE. Encryption of the COSE message does >>>> not allow the >>> tenant to >>>> read the metering. >>>> >>>> Multiple recipients here are not necessary and, for optimization >>>> reasons, >>> the >>>> COSE message should be able to omit the recipient structure >>>> (analogously >>> to the >>>> COSE_Encrypted structure). >>>> >>>> (*) >>>> https://mailarchive.ietf.org/arch/msg/core/hmIcl0WIceg26h5clQ4Qv4kcf= G >>>> k >>>> >>>> Francesca >>>> >>>> -----Original Message----- >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones >>>> Sent: den 21 november 2015 20:54 >>>> To: Justin Richer; Jim Schaad; cose@ietf.org >>>> Subject: Re: [COSE] MAC with no recipient structures >>>> >>>> As a point of clarification, this thread wasn't about removing MAC. >>>> It >>> was about >>>> adding a MAC representation with no explicit recipient - the >>>> equivalent of >>> the >>>> JWS example in http://tools.ietf.org/html/rfc7515#section-3.3. >>>> >>>> This feature request is tracked as https://github.com/cose-wg/cose- >>>> issues/issues/10 - Make "recipients" field optional. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer= >>>> Sent: Thursday, November 19, 2015 11:27 PM >>>> To: Jim Schaad ; cose@ietf.org >>>> Subject: Re: [COSE] MAC with no recipient structures >>>> >>>> What I'm hearing from this thread is a lot of support for plain MAC >>> structures, >>>> including several documented use cases. Not the least of which is >>>> mapping >>> to >>>> JOSE's HS* algorithm suite in JWS, one of the two most-used and most= - >>>> successful portions of JOSE to date. >>>> >>>> Consequently, I'm not seeing any consensus to drop plain MAC support= >>>> in >>> favor >>>> of any other method. I'm also not seeing opposition to defining AEAD= >>> structures >>>> in addition to MAC structures in COSE and allowing applications to c= hoose. >>>> >>>> Therefore, we'll keep MAC in place until there's sufficient consensu= s >>>> to >>> remove >>>> the capability from COSE. >>>> >>>> Thank you, >>>> -- Justin, your COSE chair. >>>> >>>> On 11/7/2015 5:39 PM, Jim Schaad wrote: >>>>> People keep telling me that they want to have a version of MACs tha= t >>>>> do not have a set of recipient information attached so that they ca= n >>>>> do direct MACs. I keep asking for a use case where this makes sens= e. >>>>> In all of the use cases that I have been presented so far, a better= >>>>> answer is going to be to do an AEAD encrypted item rather than a >>>>> MACed >>>> item. >>>>> >>>>> The scenario that wants this is going to be: >>>>> >>>>> Alice sends data to Bob in such a way that Bob can authenticate the= >>> data. >>>>> Eve needs to be able to read the data in transit, without knowing i= f >>>>> the message contains data or misinformation and will act on the >>>>> message as if it were data. >>>>> >>>>> The difference in message size between MAC and Encryption is going >>>>> to be minimal, at most a few bytes. The execution difference is >>>>> going to be a few extra encryption operations. >>>>> >>>>> What use cases exist for this where encryption is not a better >>>>> security answer anyway. >>>>> >>>>> Jim >>>>> >>>>> >>>>> _______________________________________________ >>>>> COSE mailing list >>>>> COSE@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cose >>>> >>>> _______________________________________________ >>>> COSE mailing list >>>> COSE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cose >>>> >>>> _______________________________________________ >>>> COSE mailing list >>>> COSE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cose >>> >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 --WqX2McRxSr0TcDgrldh8JsOButAqBibNp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWaaAvAAoJEGhJURNOOiAtLEkH/1vajqlLuxR9LKFh6tKj97j/ dYElKlXAclObYFZm1Ofz2EQn6YeBkGe79ZAzDQODk2kuMfwItYj6ucT6hARMpMue wqcihSQWXimj8kgK+KHs/Q63nmTGNJ+ZhBflCQoyTkv9I/CPBXpoSZ1NbJi8lfzo eXfyBE9GkDeaVbrAiYakw1Zs+Lz1ow2Suhxkl3ao2Si7kteFi0yliWrCK8nojs8Z a8Wo+pyTTwKuKdIlgHG5IxLU30YDRz6+hGmZZuy2q52coqfOqQJIc2h9rFgIPTgZ K98ykxmjVQJjVUxE4l0ZsNZ9fuWn6dSutx8bkNkyfoM+GPSXmMY6Qitq6C032So= =f1Zj -----END PGP SIGNATURE----- --WqX2McRxSr0TcDgrldh8JsOButAqBibNp-- From nobody Thu Dec 10 13:26:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314441B2BF9 for ; Thu, 10 Dec 2015 13:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 4X3iDQ6dYa7B for ; Thu, 10 Dec 2015 13:26:26 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BF31B2BF5 for ; Thu, 10 Dec 2015 13:26:22 -0800 (PST) Date: Thu, 10 Dec 2015 13:26:21 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449782781; bh=2EGiE4mGd2jXZfhzzlKwmxNzZbhTov3dxzmeRB4cdF8=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JfEIQ0NqGpjfc6FiGQAfltNsuTCJVjR6j8pJIpSYnE4A5rNv8a0pQUCLnUcTye1H0 6+z5LDtV16rt1PlZH/TEFn17FyhWn4WkxBvdtN2srsF/Imj8p6IX0y+JzbjFVmpE/m ggDxDMTScGLZkWBs+3uRJ2OdvuT6szlzDPWPv7Cs= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5669edfd79915_4f7e3f98344812bc2078f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Add the statement: "COSE implementations only need to implement the features needed for the applications they are designed to support" (#50) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 21:26:28 -0000 ----==_mimepart_5669edfd79915_4f7e3f98344812bc2078f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This should be covered in the new Application Guidance re-write --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/50#issuecomment-163754158 ----==_mimepart_5669edfd79915_4f7e3f98344812bc2078f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

This should be covered in the new Application Guidance re-write

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5669edfd79915_4f7e3f98344812bc2078f-- From nobody Thu Dec 10 14:07:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730D21B2C72 for ; Thu, 10 Dec 2015 14:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 YJTC03wIfEct for ; Thu, 10 Dec 2015 14:07:34 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47A21B2C45 for ; Thu, 10 Dec 2015 14:07:33 -0800 (PST) Date: Thu, 10 Dec 2015 14:07:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449785252; bh=a5rBpWLRQskSNjajHq1yYssFJ9Q9BFKfID8x9o3i+y4=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=omtMW/dWLxiuiUsrEstcHkaBgdeYAyAfK+vghQdwz2W67o2UMy2dOHvJl0TV52z+M Dn8pgE4KfEWN7nLscwwSjirPxhkbBNdI88arUwkj3/uDDea9CcXO1A2TRloHnR+JUX Q4YwG1LqfaCDHsh7nAqu7NKlPr5QADUT9tBLoIJI= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5669f7a4da654_5c03fdcd652329c36046a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 22:07:35 -0000 ----==_mimepart_5669f7a4da654_5c03fdcd652329c36046a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Re-opening for further discussion. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/39#issuecomment-163763417 ----==_mimepart_5669f7a4da654_5c03fdcd652329c36046a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Re-opening for further discussion.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5669f7a4da654_5c03fdcd652329c36046a-- From nobody Thu Dec 10 15:22:13 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E991B2E30 for ; Thu, 10 Dec 2015 15:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 whQEpiLDaGNR for ; Thu, 10 Dec 2015 15:22:10 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31311B2E2B for ; Thu, 10 Dec 2015 15:22:09 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 342F92CA06; Thu, 10 Dec 2015 15:22:09 -0800 (PST) From: "Jim Schaad" To: "'Hannes Tschofenig'" References: In-Reply-To: Date: Thu, 10 Dec 2015 15:19:24 -0800 Message-ID: <023501d133a1$353bae70$9fb30b50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0236_01D1335E.271EB000" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIh77xEt34fKYVFI50LfMLhy5sRZQKTr8pong7FDlA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:22:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0236_01D1335E.271EB000 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0237_01D1335E.271EB000" ------=_NextPart_001_0237_01D1335E.271EB000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The text on expert review was inserted at IANA=E2=80=99s request. =20 =20 I think that the text we may want to change is the first come, first = server. However, I don=E2=80=99t see any problems with saying that it = is first-come, first serve and still require the expert review portion. =20 =20 From: Hannes Tschofenig [mailto:notifications@github.com]=20 Sent: Thursday, December 10, 2015 10:06 AM To: cose-wg/cose-issues Cc: Jim Schaad Subject: Re: [cose-issues] Require publicly visible stable = specifications for IANA registrations (#39) =20 Here are my thoughts on the topic Mike raised.=20 In summary, the COSE Header Parameter Registry contains an address space = that is divided into different ranges (each with a different policy), = namely: [I only focus on the integer values below.] * 1 - 255: Standards Track Document required. * 256 - 65535: Specification Required * 65535>: first come, first served * -1 to -65536: delegated to the "COSE Header Algorithm Label" = registry.=20 * Integer values beyond -65536: private use. I agree with Mike that we should require a publically available = specification with some level of review. The First Come, First Served = policy does not give us what we want. For this reason, I would get rid = of the first come, first serve registry range and merge it with the = Specification Required range. I believe we will increase = interoperability when companies are not introducing random parameters = but the bar with specification required is not that high either.=20 Additionally, I also don't like the idea of having a label be either an = integer or a string. Why cannot we just use integers? This sounds like = introducing options for no good reasons that just increase the = implementation complexity.=20 The text in the first paragraph of Section 16.2. "COSE Header Parameter = Registry" of = https://tools.ietf.org/html/draft-ietf-cose-msg-08#section-16.2 says:=20 " The registery is to be created as Expert Review Required."=20 This is clearly wrong given the text that follows afterwards. I suggest = that this sentence is removed.=20 =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_0237_01D1335E.271EB000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The text on expert review was inserted at IANA=E2=80=99s request.=C2=A0 =

 

I think that the text we may want to change is the first come, first = server.=C2=A0 However, I don=E2=80=99t see any problems with saying that = it is first-come, first serve and still require the expert review = portion.

 

 

From:<= /b> = Hannes Tschofenig [mailto:notifications@github.com]
Sent: = Thursday, December 10, 2015 10:06 AM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-issues] = Require publicly visible stable specifications for IANA registrations = (#39)

 

Here are my thoughts on the = topic Mike raised.

In summary, the COSE Header = Parameter Registry contains an address space that is divided into = different ranges (each with a different policy), namely:
[I only = focus on the integer values below.]

  • 1 - 255: Standards Track Document = required.
  • 256 - 65535: Specification Required

=C2=B7     = 65535>: first come, first = served

=C2=B7     -1 to = -65536: delegated to the "COSE Header Algorithm Label" = registry.

  • Integer values beyond -65536: private = use.

I agree with Mike that we should require a = publically available specification with some level of review. The First = Come, First Served policy does not give us what we want. For this = reason, I would get rid of the first come, first serve registry range = and merge it with the Specification Required range. I believe we will = increase interoperability when companies are not introducing random = parameters but the bar with specification required is not that high = either.

Additionally, I also don't like the idea of = having a label be either an integer or a string. Why cannot we just use = integers? This sounds like introducing options for no good reasons that = just increase the implementation complexity.

The text = in the first paragraph of Section 16.2. "COSE Header Parameter = Registry" of = https://tools.ietf.org/html/draft-ietf-cose-msg-08#section-16.2 = says:
" The registery is to be created as Expert Review = Required."

This is clearly wrong given the text = that follows afterwards. I suggest that this sentence is removed. =

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_0237_01D1335E.271EB000-- ------=_NextPart_000_0236_01D1335E.271EB000 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_0236_01D1335E.271EB000-- From nobody Thu Dec 10 15:29:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93CF1B2E4C for ; Thu, 10 Dec 2015 15:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 L07juZudjMGy for ; Thu, 10 Dec 2015 15:29:33 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74491B2E68 for ; Thu, 10 Dec 2015 15:29:33 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 4A5C638F0D; Thu, 10 Dec 2015 15:29:33 -0800 (PST) From: "Jim Schaad" To: "'Hannes Tschofenig'" Date: Thu, 10 Dec 2015 15:26:48 -0800 Message-ID: <023b01d133a2$3dee21f0$b9ca65d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023C_01D1335F.2FCBCC50" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdEzoUmVyJDKJisRTWSe3E8BUEQSIA== Archived-At: Cc: cose@ietf.org Subject: [COSE] Label vs integer for keys X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:29:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023C_01D1335F.2FCBCC50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hannes, =20 The reason for allowing both strings and integers for keys was to = maximize the amount of short encoding registration space that is = available. Using just integers already introduces the problem that = there are actually two different encodings that need to be taking into = account, non-negative and negative integers. Depending on how the = library works for decoding this means that one needs to deal with that = for doing key lookups. If that is the case then adding the text version = does not seem to be a huge factor. =20 If we allow only integers to be used, then there is a maximum of 255 + = 255 values that can be encoded as a two bytes (a portion of those are = actually encoded as single bytes). If we add the text string to that = then we allow for an additional 180 points where we can have a single = byte encoding be added. (Respecting the UTF8-ness of the field shrinks = it slightly.) =20 I think that the additional small encoding space makes up for the slight = complication in matching tag headers. =20 Jim =20 =20 From: Hannes Tschofenig [mailto:notifications@github.com]=20 Sent: Thursday, December 10, 2015 10:06 AM To: cose-wg/cose-issues Cc: Jim Schaad Subject: Re: [cose-issues] Require publicly visible stable = specifications for IANA registrations (#39) =20 Here are my thoughts on the topic Mike raised.=20 In summary, the COSE Header Parameter Registry contains an address space = that is divided into different ranges (each with a different policy), = namely: [I only focus on the integer values below.] * 1 - 255: Standards Track Document required. * 256 - 65535: Specification Required * 65535>: first come, first served * -1 to -65536: delegated to the "COSE Header Algorithm Label" = registry.=20 * Integer values beyond -65536: private use. I agree with Mike that we should require a publically available = specification with some level of review. The First Come, First Served = policy does not give us what we want. For this reason, I would get rid = of the first come, first serve registry range and merge it with the = Specification Required range. I believe we will increase = interoperability when companies are not introducing random parameters = but the bar with specification required is not that high either.=20 Additionally, I also don't like the idea of having a label be either an = integer or a string. Why cannot we just use integers? This sounds like = introducing options for no good reasons that just increase the = implementation complexity.=20 The text in the first paragraph of Section 16.2. "COSE Header Parameter = Registry" of = https://tools.ietf.org/html/draft-ietf-cose-msg-08#section-16.2 says:=20 " The registery is to be created as Expert Review Required."=20 This is clearly wrong given the text that follows afterwards. I suggest = that this sentence is removed.=20 =E2=80=94 Reply to this email directly or view it on GitHub = = . = =20 ------=_NextPart_000_023C_01D1335F.2FCBCC50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hannes,

 

The reason for allowing both strings and integers for keys was to = maximize the amount of short encoding registration space that is = available.=C2=A0 Using just integers already introduces the problem that = there are actually two different encodings that need to be taking into = account, non-negative and negative integers.=C2=A0 Depending on how the = library works for decoding this means that one needs to deal with that = for doing key lookups.=C2=A0 If that is the case then adding the text = version does not seem to be a huge factor.

 

If we allow only integers to be used, then there is a maximum of 255 + = 255 values that can be encoded as a two bytes (a portion of those are = actually encoded as single bytes).=C2=A0 If we add the text string to = that then we allow for an additional 180 points where we can have a = single byte encoding be added.=C2=A0 (Respecting the UTF8-ness of the = field shrinks it slightly.)

 

I think that the additional small encoding space makes up for the = slight complication in matching tag headers.

 

Jim

 

 

From:<= /b> = Hannes Tschofenig [mailto:notifications@github.com]
Sent: = Thursday, December 10, 2015 10:06 AM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-issues] = Require publicly visible stable specifications for IANA registrations = (#39)

 

Here are my thoughts on the = topic Mike raised.

In summary, the COSE Header = Parameter Registry contains an address space that is divided into = different ranges (each with a different policy), namely:
[I only = focus on the integer values below.]

  • 1 - 255: Standards Track Document = required.
  • 256 - 65535: Specification Required

=C2=B7     = 65535>: first come, first = served

=C2=B7     -1 to = -65536: delegated to the "COSE Header Algorithm Label" = registry.

  • Integer values beyond -65536: private = use.

I agree with Mike that we should require a = publically available specification with some level of review. The First = Come, First Served policy does not give us what we want. For this = reason, I would get rid of the first come, first serve registry range = and merge it with the Specification Required range. I believe we will = increase interoperability when companies are not introducing random = parameters but the bar with specification required is not that high = either.

Additionally, I also don't like the idea of = having a label be either an integer or a string. Why cannot we just use = integers? This sounds like introducing options for no good reasons that = just increase the implementation complexity.

The text = in the first paragraph of Section 16.2. "COSE Header Parameter = Registry" of = https://tools.ietf.org/html/draft-ietf-cose-msg-08#section-16.2 = says:
" The registery is to be created as Expert Review = Required."

This is clearly wrong given the text = that follows afterwards. I suggest that this sentence is removed. =

=E2=80=94
Reply to this email directly or view it on GitHub.

= ------=_NextPart_000_023C_01D1335F.2FCBCC50-- From nobody Fri Dec 11 12:47:01 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2B1A88AB for ; Fri, 11 Dec 2015 12:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 m87L8eZ9-JDd for ; Fri, 11 Dec 2015 12:46:57 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92B31A88C1 for ; Fri, 11 Dec 2015 12:46:49 -0800 (PST) Date: Fri, 11 Dec 2015 12:46:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449866808; bh=5ef2/tdsthUOhZB8p+cdInY2Vpe6rociFsSl9I4KhLU=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EbdSuajoFlFRvVafECod0ZljAnd2sEyGmyHn1VbBiUIICkISKRmgJDXWvupZsa5vK NE33jneAnvba9sFACX0oYz+7HNAto9VeNKjmUnYs2IX82fN+7Jeg4pjkhSirmC1WqU jacUU65mWL/uTBLcWs45TsxU5+G+Eo7m1QYFBDr0= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566b3638ce8fa_3b393f85476eb2a04990dd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBNYWtlIOKAnHJlY2lwaWVudHPigJ0g?= =?utf-8?q?field_optional_=28=2310=29?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 20:46:59 -0000 ----==_mimepart_566b3638ce8fa_3b393f85476eb2a04990dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit There is now a MAC version cose-wg/cose-spec#112 --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/10#issuecomment-164043698 ----==_mimepart_566b3638ce8fa_3b393f85476eb2a04990dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

There is now a MAC version cose-wg/cose-spec#112

—
Reply to this email directly or view it on GitHub.

----==_mimepart_566b3638ce8fa_3b393f85476eb2a04990dd-- From nobody Fri Dec 11 12:49:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607751A88D6 for ; Fri, 11 Dec 2015 12:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_34=1, SPF_PASS=-0.001] autolearn=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 Lqf-vtKbTHvK for ; Fri, 11 Dec 2015 12:49:16 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 B2F241A88D4 for ; Fri, 11 Dec 2015 12:49:16 -0800 (PST) Received: by igcto18 with SMTP id to18so46692612igc.0 for ; Fri, 11 Dec 2015 12:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=67afQUxy+25NLfHEzm2ySaejypfW5dxu2r7GlTAROVs=; b=PAzHHRxNvLKlBT314JOsGYRp10YCFLF/gK6CFDdWuzFEzXGkOH0Wi/tzZ7knvGjqAt lxE9kknllcDz4JrBExAa7xaZf+RnKr0CCj3uu+ld1klWineeuMMxwppk+W1EB+0rAcBS k6OtBHkrMHqKbMuG0SBC+Tx18XvdigfZHMFfQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=67afQUxy+25NLfHEzm2ySaejypfW5dxu2r7GlTAROVs=; b=K+DkHHt8qFkLsb/JwPHXdmZEMod7oPKRpHe+R+ADzRfIqHuKRi4BtIQxie5MpnyJy7 c+zqorI8rl4yX1K4Gzn2PEMhkUnnj/59NaVAJ2JJuiQLIDptGoQaw8MN0ep7MbLudV8M d9PrvQfwIUvDc1KB8OHq2gBruLXFIuH1+weK0Qyf4O5zqu51Gt/zoPmLxlt7lYtvJWnO l6mRj7Xlf7X9/zX43jjJj+A221kjm2GZ5jYLkp2Eg60hmyMrvJ7zpLHZpJnR4/R+nl8j EXC7QYu9cB+yCOx/pNAJz1j73Hu3eljw4lwJeT8sTunQbll3xMhKnjg95yUaTySwXK6p zLfQ== X-Gm-Message-State: ALoCoQnhS+bS1BuPspZTV5qXbJVHWMD6ANrWTtZrOytGHLBmX6onXSq8c6bXmGAZvKlbQ9NvLlItkEv4+FfBHddprcU5bE3OJc420sxNa6y6vjKPPGKkv7Q= X-Received: by 10.50.142.73 with SMTP id ru9mr6681918igb.49.1449866955936; Fri, 11 Dec 2015 12:49:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Fri, 11 Dec 2015 12:48:46 -0800 (PST) In-Reply-To: <5669A02F.8070604@gmx.net> References: <04e901d119ad$3207bea0$96173be0$@augustcellars.com> <564ECB3C.1070203@mit.edu> <064001d127b1$f9e2a590$eda7f0b0$@augustcellars.com> <98AFE54A-11BC-49FC-87BE-99A5A3760777@mit.edu> <014f01d13092$c5b818b0$51284a10$@augustcellars.com> <5669A02F.8070604@gmx.net> From: Brian Campbell Date: Fri, 11 Dec 2015 13:48:46 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c3db70e18fc60526a57479 Archived-At: Cc: Jim Schaad , Justin Richer , cose@ietf.org Subject: Re: [COSE] MAC with no recipient structures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 20:49:21 -0000 --001a11c3db70e18fc60526a57479 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In my own experience with JOSE compact serializations and JWT (which I realize isn't directly analogous to COSE but somewhat informative nonetheless) I must say that I've found a ton of utility in JWE's symmetric AEAD messages and pretty much exclusively use it over MAC nowadays. It is more complicated though - looking back I see that I had JWS HSxxx support nearly a year before any JWE support. And there are still some JOSE/JWT libraries that only support the HMAC algorithms - http://jwt.io/ has a pretty good survey of them and there aren't as many as I remember but definitely some that are MAC only. There is something to the simplicity. In my view a MAC with no recipient structures isn't a particularly necessary thing in and of itself. But I see this more as a proxy argument, of sorts, from the faction of folks who'd like to see first order support for all the single recipient and single signature cases. The expectation is that single recipient/signature messages will be the vast majority of what actually happens and it'd be nice to have direct and simplified support for it rather than just being a sub case of the more general and more complicated multi recipient/signature cases. On Thu, Dec 10, 2015 at 8:54 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > I wanted to contribute my thoughts on this statement: > > > On 11/7/2015 5:39 PM, Jim Schaad wrote: People keep telling me that > they want to have a version of MACs that do not have a set of recipient > information attached so that they can do direct MACs. I keep asking for > a use case where this makes sense. In all of the use cases that I have > been presented so far, a better answer is going to be to do an AEAD > encrypted item rather than a MACed item. > > When Erik and I worked on an OAuth doorlock access control scenario and > tried to take this aspect into account (based on the suggestion from > Jim) by doing two things (with relevance to ACE): > * use an AEAD cipher for protection of the JWT, and > * use an AEAD cipher for use with the proof of possession when the > client talks to the resource serve (=3Ddoor lock) > > While we haven't used CBOR/COSE yet (but the JWT) it did not lead to any > problems from that point of view. The implication of using encryption > was that the JWT content was not visible to the client, which it > shouldn't be anyway. > > Of course, there are more scenarios to look into but this is our current > experience. We are going to switch to CBOR and COSE and will > let you know what the experience was. So, consider this a > work-in-progress activity. > > Ciao > Hannes > > > On 12/07/2015 02:58 AM, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: Justin Richer [mailto:jricher@mit.edu] > >> Sent: Wednesday, November 25, 2015 11:04 AM > >> To: Jim Schaad > >> Cc: Francesca Palombini ; > cose@ietf.org > >> Subject: Re: [COSE] MAC with no recipient structures > >> > >> (As an individual) > >> > >> Speaking from my own experience with JOSE, the simplicity and utility > of MAC- > >> only cannot be denied. I can only see this being compounded in > constrained > >> environments. Decrypting payload means I need to keep two copies of th= e > data > >> around, I need to manage encryption state, and I need to solve issues > with > >> multiple recipients or components that need just read access. All of > these go > >> away with simple signatures or MACs without losing functionality or > security. > >> Security is always contextual in the application, and complexity is th= e > enemy of > >> getting security actually applied in a system. > > > > I would not agree with some of these points. > > > > I do believe that MAC has a large utility and is not going to be remove= d. > > > > I do not necessarily agree that it has a larger amount of utility over > encryption in a constrained environment. One of the big advantages of > using CTR modes of encryption is that encrypting in place is even easier > than it is with any version that does padding. This means that one does > not necessarily need to have two copies of the data around. > > > > It is true that there is some additional data that needs to be managed > when doing encryption rather than a MAC. It is not clear that there is a > significant amount of data that needs to be managed. If one assumes that > some type of replay counter is maintained in both cases, then this > additional data amounts to an IV prefix which is constant and thus has > minimal maintenance associated with it. (I.e. it needs to be kept and > associated with the key.) > > > > The issues dealing with allowing multiple recipients or components that > just need read access is an interesting question to be addressed, and one > that points to the question that I keep asking. Does that other entity > that needs read access need to have the ability to know that the data is > correct? If the entity needs to be able to validate the information, the= n > using MACs or using encryption have the exact same level of complexity fo= r > dealing with multiple recipients and multiple keys. There is a differenc= e > between doing "simple signatures" and the MAC/encryption case because how > key management is done is completely different. The expected security > properties of are very different between the signature and the MAC case a= s > well. > > > > Finally, I would point out that the total security system is not > necessarily the same for a constrained and an unconstrained system. OAut= h > as it is commonly used today is sending MAC messages using TLS. The fact > that TLS is being used means that, from a security analysis, the only > parties that would have read access to the MAC message are the parties at > each end of the TLS connection. One does not end up in situations (or at > least I am assuming that one does not) where there are proxies that are > going to be between these entities that also have access to the data. Th= is > is not the case many times for a DTLS situation in the constrained > environments that are being contemplated where provisions are being made > for doing things like TLS<=3D>DTLS proxies, proxies that mediate between > different sub-networks and so forth are expected components to be dealt > with. The security system and the analysis associated with it can be ve= ry > different between the OpenID case and the access granting > case of a CoAP network. > > > >> > >> I see absolutely zero reason to not support this simplified case, and > others have > >> made it clear it=E2=80=99s desirable for their use cases. I think the = burden is > on you (Jim) > >> to prove that it=E2=80=99s not desirable, and I=E2=80=99m not personal= ly seeing support > for that > >> position in this working group. > > > > So other than the OSCoAP people, who have a use case that they are > planning to use this for? I am hearing a lot of people saying that they > need it because that is what JOSE does. I am not hearing a lot of people > saying that they have a concrete use case for it. I do not expect that > COSE is going to replace JOSE for general JWT usage. > > > > Jim > > > >> > >> =E2=80=94 Justin (as an individual, remember) > >> > >>> On Nov 25, 2015, at 1:49 PM, Jim Schaad > wrote: > >>> > >>> Again, let me ask the question. Are you willing to be in a position > >>> where the tenant reads and acts on an incorrect data value since it > >>> cannot validate the MAC on the data. > >>> > >>>> -----Original Message----- > >>>> From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] > >>>> Sent: Wednesday, November 25, 2015 6:43 AM > >>>> To: Mike Jones ; Jim Schaad > >>>> ; cose@ietf.org > >>>> Subject: RE: [COSE] MAC with no recipient structures > >>>> > >>>> Hi, > >>>> > >>>> In the context of "visibility" another use case was mentioned > before(*): > >>>> electricity consumption is measured by a meter, forwarded to a > >>>> gateway > >>> where > >>>> the tenant reads the consumption and further to the distribution > operator. > >>> The > >>>> communication between meter and gateway, and gateway and network is > >>>> protected on transport layer; and between meter and network on > >>>> application layer, using COSE. Encryption of the COSE message does > >>>> not allow the > >>> tenant to > >>>> read the metering. > >>>> > >>>> Multiple recipients here are not necessary and, for optimization > >>>> reasons, > >>> the > >>>> COSE message should be able to omit the recipient structure > >>>> (analogously > >>> to the > >>>> COSE_Encrypted structure). > >>>> > >>>> (*) > >>>> https://mailarchive.ietf.org/arch/msg/core/hmIcl0WIceg26h5clQ4Qv4kcf= G > >>>> k > >>>> > >>>> Francesca > >>>> > >>>> -----Original Message----- > >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones > >>>> Sent: den 21 november 2015 20:54 > >>>> To: Justin Richer; Jim Schaad; cose@ietf.org > >>>> Subject: Re: [COSE] MAC with no recipient structures > >>>> > >>>> As a point of clarification, this thread wasn't about removing MAC. > >>>> It > >>> was about > >>>> adding a MAC representation with no explicit recipient - the > >>>> equivalent of > >>> the > >>>> JWS example in http://tools.ietf.org/html/rfc7515#section-3.3. > >>>> > >>>> This feature request is tracked as https://github.com/cose-wg/cose- > >>>> issues/issues/10 - Make "recipients" field optional. > >>>> > >>>> -- Mike > >>>> > >>>> -----Original Message----- > >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer > >>>> Sent: Thursday, November 19, 2015 11:27 PM > >>>> To: Jim Schaad ; cose@ietf.org > >>>> Subject: Re: [COSE] MAC with no recipient structures > >>>> > >>>> What I'm hearing from this thread is a lot of support for plain MAC > >>> structures, > >>>> including several documented use cases. Not the least of which is > >>>> mapping > >>> to > >>>> JOSE's HS* algorithm suite in JWS, one of the two most-used and most= - > >>>> successful portions of JOSE to date. > >>>> > >>>> Consequently, I'm not seeing any consensus to drop plain MAC support > >>>> in > >>> favor > >>>> of any other method. I'm also not seeing opposition to defining AEAD > >>> structures > >>>> in addition to MAC structures in COSE and allowing applications to > choose. > >>>> > >>>> Therefore, we'll keep MAC in place until there's sufficient consensu= s > >>>> to > >>> remove > >>>> the capability from COSE. > >>>> > >>>> Thank you, > >>>> -- Justin, your COSE chair. > >>>> > >>>> On 11/7/2015 5:39 PM, Jim Schaad wrote: > >>>>> People keep telling me that they want to have a version of MACs tha= t > >>>>> do not have a set of recipient information attached so that they ca= n > >>>>> do direct MACs. I keep asking for a use case where this makes sens= e. > >>>>> In all of the use cases that I have been presented so far, a better > >>>>> answer is going to be to do an AEAD encrypted item rather than a > >>>>> MACed > >>>> item. > >>>>> > >>>>> The scenario that wants this is going to be: > >>>>> > >>>>> Alice sends data to Bob in such a way that Bob can authenticate the > >>> data. > >>>>> Eve needs to be able to read the data in transit, without knowing i= f > >>>>> the message contains data or misinformation and will act on the > >>>>> message as if it were data. > >>>>> > >>>>> The difference in message size between MAC and Encryption is going > >>>>> to be minimal, at most a few bytes. The execution difference is > >>>>> going to be a few extra encryption operations. > >>>>> > >>>>> What use cases exist for this where encryption is not a better > >>>>> security answer anyway. > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> COSE mailing list > >>>>> COSE@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/cose > >>>> > >>>> _______________________________________________ > >>>> COSE mailing list > >>>> COSE@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cose > >>>> > >>>> _______________________________________________ > >>>> COSE mailing list > >>>> COSE@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cose > >>> > >>> _______________________________________________ > >>> COSE mailing list > >>> COSE@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --001a11c3db70e18fc60526a57479 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In my own experience with JOSE compact serialization= s and JWT (which I realize isn't directly analogous to COSE but somewha= t informative nonetheless) I must say that I've found a ton of utility = in JWE's symmetric AEAD messages and pretty much exclusively use it ove= r MAC nowadays. It is more complicated though - looking back I= see that I had JWS HSxxx support nearly a year before any JWE support.=C2= =A0 And there are still some JOSE/JWT libraries that only support the HMAC = algorithms - http://jwt.io/ has a pretty good survey of them and there aren't as many as I rememb= er but definitely some that are MAC only. There is something to the simplic= ity.

=


On Thu, Dec 10, 2015 at 8:54 AM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:
I w= anted to contribute my thoughts on this statement:

> On 11/7/2015 5:39 PM, Jim Schaad wrote: People keep telling me that they want to have a version of MACs that do not have a set of recipient
information attached so that they can do direct MACs. I keep asking for
a use case where this makes sense. In all of the use cases that I have
been presented so far, a better answer is going to be to do an AEAD
encrypted item rather than a MACed item.

When Erik and I worked on an OAuth doorlock access control scenario = and
tried to take this aspect into account (based on the suggestion from
Jim) by doing two things (with relevance to ACE):
=C2=A0* use an AEAD cipher for protection of the JWT, and
=C2=A0* use an AEAD cipher for use with the proof of possession when the client talks to the resource serve (=3Ddoor lock)

While we haven't used CBOR/COSE yet (but the JWT) it did not lead to an= y
problems from that point of view. The implication of using encryption
was that the JWT content was not visible to the client, which it
shouldn't be anyway.

Of course, there are more scenarios to look into but this is our current experience. We are going to switch to CBOR and COSE and will
let you know what the experience was. So, consider this a
work-in-progress activity.

Ciao
Hannes


On 12/07/2015 02:58 AM, Jim Schaad wrote:
>
>
>> -----Original Message-----
>> From: Justin Richer [mailto:jri= cher@mit.edu]
>> Sent: Wednesday, November 25, 2015 11:04 AM
>> To: Jim Schaad <ietf@= augustcellars.com>
>> Cc: Francesca Palombini <francesca.palombini@ericsson.com>; cose@ietf.org
>> Subject: Re: [COSE] MAC with no recipient structures
>>
>> (As an individual)
>>
>> Speaking from my own experience with JOSE, the simplicity and util= ity of MAC-
>> only cannot be denied. I can only see this being compounded in con= strained
>> environments. Decrypting payload means I need to keep two copies o= f the data
>> around, I need to manage encryption state, and I need to solve iss= ues with
>> multiple recipients or components that need just read access. All = of these go
>> away with simple signatures or MACs without losing functionality o= r security.
>> Security is always contextual in the application, and complexity i= s the enemy of
>> getting security actually applied in a system.
>
> I would not agree with some of these points.
>
> I do believe that MAC has a large utility and is not going to be remov= ed.
>
> I do not necessarily agree that it has a larger amount of utility over= encryption in a constrained environment.=C2=A0 One of the big advantages o= f using CTR modes of encryption is that encrypting in place is even easier = than it is with any version that does padding.=C2=A0 This means that one do= es not necessarily need to have two copies of the data around.
>
> It is true that there is some additional data that needs to be managed= when doing encryption rather than a MAC.=C2=A0 It is not clear that there = is a significant amount of data that needs to be managed.=C2=A0 If one assu= mes that some type of replay counter is maintained in both cases, then this= additional data amounts to an IV prefix which is constant and thus has min= imal maintenance associated with it.=C2=A0 (I.e. it needs to be kept and as= sociated with the key.)
>
> The issues dealing with allowing multiple recipients or components tha= t just need read access is an interesting question to be addressed, and one= that points to the question that I keep asking.=C2=A0 Does that other enti= ty that needs read access need to have the ability to know that the data is= correct?=C2=A0 If the entity needs to be able to validate the information,= then using MACs or using encryption have the exact same level of complexit= y for dealing with multiple recipients and multiple keys.=C2=A0 There is a = difference between doing "simple signatures" and the MAC/encrypti= on case because how key management is done is completely different.=C2=A0 = =C2=A0The expected security properties of are very different between the si= gnature and the MAC case as well.
>
> Finally, I would point out that the total security system is not neces= sarily the same for a constrained and an unconstrained system.=C2=A0 OAuth = as it is commonly used today is sending MAC messages using TLS.=C2=A0 The f= act that TLS is being used means that, from a security analysis, the only p= arties that would have read access to the MAC message are the parties at ea= ch end of the TLS connection.=C2=A0 One does not end up in situations (or a= t least I am assuming that one does not) where there are proxies that are g= oing to be between these entities that also have access to the data.=C2=A0 = This is not the case many times for a DTLS situation in the constrained env= ironments that are being contemplated where provisions are being made for d= oing things like TLS<=3D>DTLS proxies, proxies that mediate between d= ifferent sub-networks and so forth are expected components to be dealt with= .=C2=A0 =C2=A0The security system and the analysis associated with it can b= e very different between the OpenID case and the access granting
case of a CoAP network.
>
>>
>> I see absolutely zero reason to not support this simplified case, = and others have
>> made it clear it=E2=80=99s desirable for their use cases. I think = the burden is on you (Jim)
>> to prove that it=E2=80=99s not desirable, and I=E2=80=99m not pers= onally seeing support for that
>> position in this working group.
>
> So other than the OSCoAP people, who have a use case that they are pla= nning to use this for?=C2=A0 I am hearing a lot of people saying that they = need it because that is what JOSE does.=C2=A0 I am not hearing a lot of peo= ple saying that they have a concrete use case for it.=C2=A0 I do not expect= that COSE is going to replace JOSE for general JWT usage.
>
> Jim
>
>>
>>=C2=A0 =E2=80=94 Justin (as an individual, remember)
>>
>>> On Nov 25, 2015, at 1:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>>>
>>> Again, let me ask the question.=C2=A0 Are you willing to be in= a position
>>> where the tenant reads and acts on an incorrect data value sin= ce it
>>> cannot validate the MAC on the data.
>>>
>>>> -----Original Message-----
>>>> From: Francesca Palombini [mailto:francesca.palombini@ericsson.com]
>>>> Sent: Wednesday, November 25, 2015 6:43 AM
>>>> To: Mike Jones <Michael.Jones@microsoft.com>; Jim Schaad
>>>> <ietf@augustc= ellars.com>; cose@ietf.org
>>>> Subject: RE: [COSE] MAC with no recipient structures
>>>>
>>>> Hi,
>>>>
>>>> In the context of "visibility" another use case = was mentioned before(*):
>>>> electricity consumption is measured by a meter, forwarded = to a
>>>> gateway
>>> where
>>>> the tenant reads the consumption and further to the distri= bution operator.
>>> The
>>>> communication between meter and gateway, and gateway and n= etwork is
>>>> protected on transport layer; and between meter and networ= k on
>>>> application layer, using COSE. Encryption of the COSE mess= age does
>>>> not allow the
>>> tenant to
>>>> read the metering.
>>>>
>>>> Multiple recipients here are not necessary and, for optimi= zation
>>>> reasons,
>>> the
>>>> COSE message should be able to omit the recipient structur= e
>>>> (analogously
>>> to the
>>>> COSE_Encrypted structure).
>>>>
>>>> (*)
>>>> https://mailar= chive.ietf.org/arch/msg/core/hmIcl0WIceg26h5clQ4Qv4kcfG
>>>> k
>>>>
>>>> Francesca
>>>>
>>>> -----Original Message-----
>>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones
>>>> Sent: den 21 november 2015 20:54
>>>> To: Justin Richer; Jim Schaad; cose@ietf.org
>>>> Subject: Re: [COSE] MAC with no recipient structures
>>>>
>>>> As a point of clarification, this thread wasn't about = removing MAC.
>>>> It
>>> was about
>>>> adding a MAC representation with no explicit recipient - t= he
>>>> equivalent of
>>> the
>>>> JWS example in http://tools.ietf.org/= html/rfc7515#section-3.3.
>>>>
>>>> This feature request is tracked as https://github.c= om/cose-wg/cose-
>>>> issues/issues/10 - Make "recipients" field optio= nal.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer
>>>> Sent: Thursday, November 19, 2015 11:27 PM
>>>> To: Jim Schaad <ietf@augustcellars.com>; cose@ie= tf.org
>>>> Subject: Re: [COSE] MAC with no recipient structures
>>>>
>>>> What I'm hearing from this thread is a lot of support = for plain MAC
>>> structures,
>>>> including several documented use cases. Not the least of w= hich is
>>>> mapping
>>> to
>>>> JOSE's HS* algorithm suite in JWS, one of the two most= -used and most-
>>>> successful portions of JOSE to date.
>>>>
>>>> Consequently, I'm not seeing any consensus to drop pla= in MAC support
>>>> in
>>> favor
>>>> of any other method. I'm also not seeing opposition to= defining AEAD
>>> structures
>>>> in addition to MAC structures in COSE and allowing applica= tions to choose.
>>>>
>>>> Therefore, we'll keep MAC in place until there's s= ufficient consensus
>>>> to
>>> remove
>>>> the capability from COSE.
>>>>
>>>> Thank you,
>>>>=C2=A0 -- Justin, your COSE chair.
>>>>
>>>> On 11/7/2015 5:39 PM, Jim Schaad wrote:
>>>>> People keep telling me that they want to have a versio= n of MACs that
>>>>> do not have a set of recipient information attached so= that they can
>>>>> do direct MACs.=C2=A0 I keep asking for a use case whe= re this makes sense.
>>>>> In all of the use cases that I have been presented so = far, a better
>>>>> answer is going to be to do an AEAD encrypted item rat= her than a
>>>>> MACed
>>>> item.
>>>>>
>>>>> The scenario that wants this is going to be:
>>>>>
>>>>> Alice sends data to Bob in such a way that Bob can aut= henticate the
>>> data.
>>>>> Eve needs to be able to read the data in transit, with= out knowing if
>>>>> the message contains data or misinformation and will a= ct on the
>>>>> message as if it were data.
>>>>>
>>>>> The difference in message size between MAC and Encrypt= ion is going
>>>>> to be minimal, at most a few bytes.=C2=A0 The executio= n difference is
>>>>> going to be a few extra encryption operations.
>>>>>
>>>>> What use cases exist for this where encryption is not = a better
>>>>> security answer anyway.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> COSE mailing list
>>>>> COSE@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo= /cose
>>>>
>>>> _______________________________________________
>>>> COSE mailing list
>>>> COSE@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cos= e
>>>>
>>>> _______________________________________________
>>>> COSE mailing list
>>>> COSE@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cos= e
>>>
>>> _______________________________________________
>>> COSE mailing list
>>> COSE@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>


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


--001a11c3db70e18fc60526a57479-- From nobody Sat Dec 12 11:39:14 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620631A8AD3 for ; Sat, 12 Dec 2015 11:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 3f_ETQTtdRr2 for ; Sat, 12 Dec 2015 11:39:10 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B64A1A8ACD for ; Sat, 12 Dec 2015 11:39:10 -0800 (PST) Date: Sat, 12 Dec 2015 11:39:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1449949147; bh=VkT8ahSqGpJyL5rIWgdlVTWUKRIHt0o2b3aVWLFBoOQ=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tKVchxgWzBZbeyJXWmgaHfNghIDhOL/XvypphnOtQQv6Vwcm0mxBaH0AXIXObewJ4 eGT0wusSbPKPnotqDrDX+FEt1UTuGKujY0rX4e5vbnStuWdjT5CDaIpaqIlqviJzHz KKTH9QtOkeX27x05a2GiAaRW6GGp5dkGos05XUjE= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_566c77dbb870b_68e3fc3b86072bc53276"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 19:39:12 -0000 ----==_mimepart_566c77dbb870b_68e3fc3b86072bc53276 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Beauty is in the eye of the beholder on this in terms of what is easier. However, while putting something other than the body last works for signatures with appendix schemes, it will not work correctly for signature recovery schemes. For such schemes the body needs to be last so that it is the part that is going to be recovered. Otherwise, there is no difference in the size of the message that is being transmitted. Recovering the external AAD information which is not transmitted does not help reduce the message size. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/48#issuecomment-164178245 ----==_mimepart_566c77dbb870b_68e3fc3b86072bc53276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Beauty is in the eye of the beholder on this in terms of what is easier.

However, while putting something other than the body last works for signatures with appendix schemes, it will not work correctly for signature recovery schemes. For such schemes the body needs to be last so that it is the part that is going to be recovered. Otherwise, there is no difference in the size of the message that is being transmitted. Recovering the external AAD information which is not transmitted does not help reduce the message size.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_566c77dbb870b_68e3fc3b86072bc53276-- From nobody Tue Dec 15 05:10:56 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8C1A88D9 for ; Tue, 15 Dec 2015 05:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 oFpIQqLTtyhc for ; Tue, 15 Dec 2015 05:10:49 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A871A88D6 for ; Tue, 15 Dec 2015 05:10:48 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-c7-56701156a936 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.FF.05041.65110765; Tue, 15 Dec 2015 14:10:46 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.115]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 14:09:54 +0100 From: Francesca Palombini To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Message size considerations Thread-Index: AdExx8w+7Fl8oavJQAC+jbJdBuSmQgAf1ycAATvupzA= Date: Tue, 15 Dec 2015 13:09:53 +0000 Message-ID: References: <03b901d1324f$8b97ed90$a2c7c8b0$@augustcellars.com> In-Reply-To: <03b901d1324f$8b97ed90$a2c7c8b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D2736FF6C4A3F3428982D3508DD478DE0D450C8FESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2J7uG6YYEGYwfTJqhbTtk5ltVg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxcdckxoIzF5gqju18y9zAuGw5UxcjJ4eE gInEp0tvmSFsMYkL99azdTFycQgJHGaUOLNuGhOEs4RRYtvriWAdbAI2EhcevmcFsUUEPCR2 7f4E1i0soC/R8GoiVNxA4sSyCVC2lcSKzgVsIDaLgKpE26p/QHM4OHgFfCWOz0sHCQsJNDNK /DvoBWJzCjhIPPp4nRHEZgQ66PupNWBrmQXEJW49mQ91tIDEkj3noY4WlXj5+B8ryEgJASWJ aVvTIMrzJX6sWg1WzisgKHFy5hOWCYwis5BMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcO PGZCFl/AyL6KUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCyDm75bbWD8eBzx0OMAhyMSjy8 GwTzw4RYE8uKK3MPMUpwMCuJ8D78BxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO28z0IFRIID2x JDU7NbUgtQgmy8TBKdXAWFBQPP9L/93J1d/7v7o2N1R4mwfa6ywoCJz+j0lihujMg7N9D2r/ 39W96e6dgITvZaG+y81qblxvuS9z6PU6zzXN9T0hXS4spc+n68aJbHfPUPh1leFZzZzYqC4e m0TWY1KTW2JL2ScZrrniZ6lw57Uiq+D37Wl54q/yvPVuWi+eeepyzIS3SizFGYmGWsxFxYkA 3ELrQqgCAAA= Archived-At: Subject: Re: [COSE] Message size considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:10:55 -0000 --_000_D2736FF6C4A3F3428982D3508DD478DE0D450C8FESESSMB205erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you all for your feedback. I come a bit late for the Mac structure (as you Jim have already started wi= th that), but here is the CDDL / text change in the draft that we were aimi= ng at with our modifications: a. section 3.1 : alg "This parameter MUST be present at each level of a sig= ned, encrypted or authenticated message." We would like the alg to be optio= nal. b. Add a COSE_Sign0 structure COSE_Sign0 =3D [ Headers, payload : bstr / nil, signature : bstr ] (I guess this is what Mike meant with "equivalent no-recipient signature ve= rsion" in cose-wg/cose-spec#112 ) c. Add a COSE_Mac0 structure (already addressed in cose-wg/cose-spec#112) COSE_Mac0 =3D [ Headers, payload: bstr / nil, tag: bstr ] (editorial comment: there is one comma that should not be there after tag: = bstr line 1417) d. Modify Table 1 section 3.1 to give a choice between COSE_signature and bstr= as Table 1: Common Header Parameters | counter | 7 | COSE_signatur | | CBOR encoded | | signatur | | e / bstr | | signature | | e | | | | structure / | | | | | | signature | | | | | | value | I may have missed other places, but you get the idea. Francesca From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: den 9 december 2015 08:02 To: Francesca Palombini; cose@ietf.org Subject: RE: [COSE] Message size considerations Putting this in CDDL would be helpful From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Francesca Palombini Sent: Tuesday, December 08, 2015 7:00 AM To: cose@ietf.org Subject: [COSE] Message size considerations Hi, We have re-calculated the message sizes for the different use cases that ar= e relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (see column "ove= rhead cose-msg-08" of table below). We think that the COSE_Encrypt format is well designed for applications whi= ch have tight requirements on message size, the overhead being of the order= of 10 bytes (excluding tag and necessary header parameters of size which d= epends on application). We don't see any reason why we should get twice the= overhead if we MAC or Sign a message instead. In this mail we propose some optimizations that mainly have an impact on th= e other formats, see column "overhead with mod" in the table below. In order to decrease the message size overhead we propose to add 2 new mess= age types: one for single signature (1) (in our use case we don't need mult= iple signatures), and one for MAC with no recipient (2). The rest of the mail is discussing the optimizations and our proposal. We t= hought to start this discussion here in the mailing list, but we could also= add our requests in the issue tracker if it is preferred. Reading up on the discussion about COSE structure for single signer [2], [3= ], we could not find any "closure" to that discussion, and like to revisit = the topic again. Analogously to the COSE_Encrypted structure, we consider that all informati= on necessary for the cryptographic operations is pre-established between th= e endpoints. The Context Identifier sent protected in the message is enough= to identify the security context and all the parameters necessary for cryp= to computations (alg, key, etc) previously set up in the endpoints. Because= of that, we don't need to send the signer/recipient info in the message, a= nd we suggest to optimize the COSE structure for this use case. We propose the following modifications: a. remove the alg parameter from the message sent: since all information is= pre-established in the nodes' security context, we don't need to send the = alg in the message. (saves 2B) b. for the new single-signature structure (1), we only need to send the bts= tr 'signature', we can remove the 'signatures' and 'COSE_signature' structu= re. The Context Identifier and the Sequence Number are sent in the COSE_Sig= n protected header. (saves 5B) c. remove the recipient structure from the new MAC structure (2). (saves 8B= ) d. as for b, for the COSE_Encrypt with counter signature use case, we propo= se to give the choice to use the whole COSE_Signature structure or only the= btstr 'signature' as 'counter signature'. If we only send the btstr 'signature' (our use case), we assume that the al= g for counter signature is also defined in the security context. (saves 8B) Even if these improvements may seem small, please note that in some cases t= he difference is half the total overhead, which is not insignificant. Table: Message overhead +--------------+-------------+----------+------------+ | COSE | overhead | overhead | difference | | Structure | cose-msg-08 | with mod | | +--------------+-------------+----------+------------+ | COSE_Sign | 18 B | 11 B | 7 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 11 B | 9 B | 2 B | +--------------+-------------+----------+------------+ | COSE_Mac | 20 B | 10 B | 10 B | +--------------+-------------+----------+------------+ | COSE_Encrypt | 20 B | 12 B | 8 B | | +counter sig | | | | +--------------+-------------+----------+------------+ As a summary, this is how we would modify the COSE_Message structures in or= der to optimize the message size, and how many bytes we would save from eac= h modification: COSE_Sign: [protected, unprotected, payload, [[ protected, unprotected, sig= nature]]] Bytes removed: -2B(b) -1B(b) -4B(a,b) COSE_Sign single signature (new type): [protected, unprotected, payload, si= gnature] COSE_Mac: [protected, unprotected, payload, tag, [[ protected, unprotected,= ciphertext]]] Bytes removed: -2B(a) -2B(c) -1B(c) -4B(a,c) = -1B(c) COSE_Mac no recipient (new type): [protected, unprotected, payload, tag] COSE_Encrypt: [protected, unprotected, ciphertext] Bytes removed: -2B(a) COSE_Encrypt: [protected, unprotected, ciphertext] COSE_Encrypt with counter signature: [protected, {7:[protected, unprotected= , signature], ...}, ciphertext] Bytes removed: -2B(a) -1B(d) -1B(d) -4B(a,d) COSE_Encrypt with counter signature mod: [protected, {7: signature, ...}, c= iphertext] To meet Jim's arguments against b. and c. in his previous message [2] (most= recent message I could find about this topic): "4. There is currently a very clear cut rule about things only being used = at the layer they are placed in. This means that currently key identifiers= are never placed in the same layer as a content key algorithm. This would= be broken by the proposal put forth. I worry that once this is done, ther= e will be more items than kid that will migrate between layers. One of the= things that I never liked in the JOSE proposals what the number of places = that one needed to look for the various control fields. Currently in COSE = this is limited to two places. If we introduce the possibility of cross la= yer contamination then this number might grow in the future to deal with im= plementation faults. One of the way that these faults might develop is for designers to say - I = think that this should be authenticated, and thus will put it at the wrong = layer to ensure that it is. Either without thinking about the question - s= hould it be authenticated, or a different algorithm be required so that aut= hentication is possible." We suggest to have one layer only for this specific use case where we don't= use this recipient/signer structure anyway, in new structures adapted for = this use case. We are not proposing to change the current structures, which= would be used when recipient/signer structures are necessary. "5. Code size is going to be very different if two different methods of de= aling with structure needs to be supported. It is currently being assumed = that direct key is going to be the major use case in a number of situations= . If this is not the case then current proposals do not help the situation = any. If it is true that more than one method of key management needs to be supported then the code size is going to grow because of the need to suppor= t an additional way that key management is going to be done." In our particular application of COSE, we don't need to support use cases w= ith recipient/signer structures. The creation of different msg types as we = suggest should make implementation easier. Francesca [1] https://tools.ietf.org/html/draft-selander-ace-object-security-03 [2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY [3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc --_000_D2736FF6C4A3F3428982D3508DD478DE0D450C8FESESSMB205erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank y= ou all for your feedback.

&n= bsp;

I come = a bit late for the Mac structure (as you Jim have already started with that= ), but here is the CDDL / text change in the draft that we were aiming at with our modificati= ons:

&n= bsp;

a. sect= ion 3.1 : alg “This parameter MUST be present at each le= vel of a signed, encrypted or authenticated message.” We would like the alg t= o be optional.

&n= bsp;

b.=

Add a COSE_Sign0 structure

 

COSE_Sign0 =3D [

   Headers,

   payload : bstr / nil,<= /span>

   signature : bstr

]

 

(I gues= s this is what Mike meant with “equivalent no-recipient signature ver= sion” in  cose-wg/cose-spec#112 )=

&n= bsp;

c.=

Add a COSE_Mac0 structure (already addr= essed in  cose-wg/cose-spe= c#112)

 

COSE_Mac0 =3D [

   Headers,

   payload: bstr / nil,

   tag: bstr

]

 

(editor= ial comment: there is one comma that should not be there after tag: bstr li= ne 1417)

&n= bsp;

d.

Modify = Table 1 section 3.1 to give a choice between COSE_signature and bstr as

&n= bsp;

  Table 1: Common Header Parameters<= /o:p>

 

| counter  | 7     | = COSE_signatur |          =       | CBOR encoded  |

| signatur |     &nbs= p; | e / bstr      |     =            | signature&nb= sp;    |

| e        = |       |      =          |     =            | structu= re /   |

|       &nb= sp;  |       |    &n= bsp;          |  &nb= sp;            = | signature     |

|       &nb= sp;  |       |    &n= bsp;          |  &nb= sp;            = | value         |

 

I may h= ave missed other places, but you get the idea.

Frances= ca

&n= bsp;

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: den 9 december 2015 08:02
To: Francesca Palombini; cose@ietf.org
Subject: RE: [COSE] Message size considerations

 

Putting= this in CDDL would be helpful

&n= bsp;

From: COSE [mailto:cose-boun= ces@ietf.org] On Behalf Of Francesca Palombini
Sent: Tuesday, December 08, 2015 7:00 AM
To: cose@ietf.org
Subject: [COSE] Message size considerations

 

Hi,

 

 

We have re-calculated the message sizes for the different us= e cases that are relevant for OSCOAP [1], based on draft-ietf-cose-msg-08 (= see column “overhead cose-msg-08” of table below).

 

We think that the COSE_Encrypt format is well designed for a= pplications which have tight requirements on message size, the overhead bei= ng of the order of 10 bytes (excluding tag and necessary header parameters of size which depends on application). We don't see any = reason why we should get twice the overhead if we MAC or Sign a message ins= tead.

 

In this mail we propose some optimizations that mainly have = an impact on the other formats, see column “overhead with mod” = in the table below.

 

In order to decrease the message size overhead we propose to= add 2 new message types: one for single signature (1) (in our use case we = don't need multiple signatures), and one for MAC with no recipient (2).

 

The rest of the mail is discussing the optimizations and our= proposal. We thought to start this discussion here in the mailing list, bu= t we could also add our requests in the issue tracker if it is preferred.

 

 

 

Reading up on the discussion about COSE structure for single= signer [2], [3], we could not find any "closure" to that discuss= ion, and like to revisit the topic again.

 

Analogously to the COSE_Encrypted structure, we consider tha= t all information necessary for the cryptographic operations is pre-establi= shed between the endpoints. The Context Identifier sent protected in the message is enough to identify the security context a= nd all the parameters necessary for crypto computations (alg, key, etc) pre= viously set up in the endpoints. Because of that, we don't need to send the= signer/recipient info in the message, and we suggest to optimize the COSE structure for this use case.

 

 

We propose the following modifications:

 

a. remove the alg parameter from the message sent: since all= information is pre-established in the nodes' security context, we don't ne= ed to send the alg in the message. (saves 2B)

 

b. for the new single-signature structure (1), we only need = to send the btstr 'signature', we can remove the 'signatures' and 'COSE_sig= nature' structure. The Context Identifier and the Sequence Number are sent in the COSE_Sign protected header. (saves 5B)

 

c. remove the recipient structure from the new MAC structure= (2). (saves 8B)

 

d. as for b, for the COSE_Encrypt with counter signature use= case, we propose to give the choice to use the whole COSE_Signature struct= ure or only the btstr 'signature' as ‘counter signature’.<= /o:p>

If we only send the btstr 'signature' (our use case), we ass= ume that the alg for counter signature is also defined in the security cont= ext. (saves 8B)

 

 

Even if these improvements may seem small, please note that = in some cases the difference is half the total overhead, which is not insig= nificant.

 

 

Table: Message overhead

 

+--------------+-------------+----------+---= ---------+

|      COSE    |&nbs= p; overhead   | overhead | difference |

|  Structure   | cose-msg-08 | with mod |&nbs= p;           |=

+--------------+-------------+----------+---= ---------+

| COSE_Sign    |     18 B=     |   11 B   |    = 7 B    |

+--------------+-------------+----------+---= ---------+

| COSE_Encrypt |     11 B  &nb= sp; |    9 B   |     2 B =    |

+--------------+-------------+----------+---= ---------+

| COSE_Mac     |    = 20 B    |   10 B   |    = 10 B    |

+--------------+-------------+----------+---= ---------+

| COSE_Encrypt |     20 B  &nb= sp; |   12 B   |     8 B  = ;  |

| +counter sig |      &nbs= p;      |       = ;   |          =   |

+--------------+-------------+----------+---= ---------+

 

 

As a summary, this is how we would modify the COSE_Message s= tructures in order to optimize the message size, and how many bytes we woul= d save from each modification:

 

COSE_Sign: [protected, unprotected, payload, [[ protected, u= nprotected, signature]]]

Bytes removed:       &nbs= p;            &= nbsp;        -2B(b) -1B(b)  &n= bsp;  -4B(a,b)

 

COSE_Sign single signature (new type): [protected, unprotect= ed, payload, signature]

 

 

COSE_Mac: [protected, unprotected, payload, tag, [[ protecte= d, unprotected, ciphertext]]]

Bytes removed:       &nbs= p;   -2B(a)         =       -2B(c) -1B(c)     -4B(a,= c)    -1B(c)

 

COSE_Mac no recipient (new type): [protected, unprotected, p= ayload, tag]

 

 

COSE_Encrypt: [protected, unprotected, ciphertext]

Bytes removed:   -2B(a)

 

COSE_Encrypt: [protected, unprotected, ciphertext]

 

 

COSE_Encrypt with counter signature: [protected, {7:[protect= ed, unprotected, signature], …}, ciphertext]

Bytes removed:       &nbs= p;            &= nbsp;     -2B(a)  -1B(d) -1B(d)    = -4B(a,d)

 

COSE_Encrypt with counter signature mod: [protected, {7: sig= nature, …}, ciphertext]

 

 

To meet Jim's arguments against b. and c. in his previous me= ssage [2] (most recent message I could find about this topic):

 

"4.  There is currently a very clear cut rule abou= t things only being used at the layer they are placed in.  This means = that currently key identifiers are never placed in the same layer as a content key algorithm.  This would be broken by the proposal put= forth.  I worry that once this is done, there will be more items than= kid that will migrate between layers.  One of the things that I never= liked in the JOSE proposals what the number of places that one needed to look for the various control fields.  Curre= ntly in COSE this is limited to two places.  If we introduce the possi= bility of cross layer contamination then this number might grow in the futu= re to deal with implementation faults.  

One of the way that these faults might develop is for design= ers to say - I think that this should be authenticated, and thus will put i= t at the wrong layer to ensure that it is.  Either without thinking about the question - should it be authenticated, or a dif= ferent algorithm be required so that authentication is possible."=

 

We suggest to have one layer only for this specific use case= where we don't use this recipient/signer structure anyway, in new structur= es adapted for this use case. We are not proposing to change the current structures, which would be used when recipient/signe= r structures are necessary.

 

"5.  Code size is going to be very different if tw= o different methods of dealing with structure needs to be supported.  = It is currently being assumed that direct key is going to be the major use case in a number of situations. If this is not the case then cur= rent proposals do not help the situation any.  If it is true that more= than one method of key management needs to be

supported then the code size is going to grow because of the= need to support an additional way that key management is going to be done.= "

 

In our particular application of COSE, we don't need to supp= ort use cases with recipient/signer structures. The creation of different m= sg types as we suggest should make implementation easier.

 

Francesca

 

 

[1] https://tools.ietf.org/html/draft-selander-ace-object-security-03<= /o:p>

 

[2] https://mailarchive.ietf.org/arch/msg/cose/j1P3Nqt1wEZSTGCYO0gFSeazxUY<= o:p>

 

[3] https://mailarchive.ietf.org/arch/msg/cose/8fKGZBMZuUmvJafwQodKqMxQGbc<= o:p>

 

 

--_000_D2736FF6C4A3F3428982D3508DD478DE0D450C8FESESSMB205erics_-- From nobody Tue Dec 15 13:04:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF31ACDD1 for ; Tue, 15 Dec 2015 13:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 osbjbKSgwH78 for ; Tue, 15 Dec 2015 13:04:49 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886AB1ACDF4 for ; Tue, 15 Dec 2015 13:04:43 -0800 (PST) Date: Tue, 15 Dec 2015 13:04:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450213482; bh=p3o3VjW/iv1bSuFjdz0VGD1cELfiCn6BvYWVVLAYLbc=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KoMOpUqGbnJsWHG44+4sBcd+uwO7QJLMmQkpclcpFCgdKblh5xQcpcrJefU8xXi/j av+yMNBNwWiWERbSaa3vJza87BJati0VUFx4XH11rVSkBRyDTgDgbqfZpv5wRgBrQ2 SytjVBAzINLkyMkLfMbDtrjNTvGtN7yf9YbdKZQ4= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5670806a436a9_10233f99dd1432bc30707e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] CFRG document for Curve25519 and Goldilocks has odd shared secret issue (#9) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 21:04:51 -0000 ----==_mimepart_5670806a436a9_10233f99dd1432bc30707e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit We have moved these algorithms to the secondary algorithm document. We are not going to change how the secret is created for the NIST versions of the ECDH algorithms. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/9#issuecomment-164896206 ----==_mimepart_5670806a436a9_10233f99dd1432bc30707e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

We have moved these algorithms to the secondary algorithm document. We are not going to change how the secret is created for the NIST versions of the ECDH algorithms.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5670806a436a9_10233f99dd1432bc30707e-- From nobody Wed Dec 16 02:40:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE7D1ACE64 for ; Wed, 16 Dec 2015 02:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 NCTlpEoccU5y for ; Wed, 16 Dec 2015 02:40:34 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935DE1ACE61 for ; Wed, 16 Dec 2015 02:40:34 -0800 (PST) Date: Wed, 16 Dec 2015 02:40:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450262432; bh=VLsgckCtKBVVROYpSAeKcVt/k4nnI9sjSUFr4utaHbI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=l1rorb0y2yACXoT1m4Kj6dVKjQGldpKnVhGEcsG3cr8ItgPqa6qGrEWJA1fFR9er8 TZSzWoLZWZ1Ou8NQaSkeGJThRJXGrwQTVX5yJ0jPXp9KJCp2zICHO9q7ZppJ9aGakZ 4vsjfN1NXrqWJdbmCpT1K4lj2ZGuG0s/RVmPyiP4= From: fpalombini To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56713fa0b8601_68743fea15f612bc189013f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: fpalombini X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Remove_=E2=80=9Ccounter_signat?= =?utf-8?b?dXJl4oCdIGhlYWRlciBwYXJhbWV0ZXIgKCMxMik=?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 10:40:36 -0000 ----==_mimepart_56713fa0b8601_68743fea15f612bc189013f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Following our analysis [posted to the mailing list](https://mailarchive.ietf.org/arch/msg/cose/AF_Mv2O-IEwDs_NETtRYHkdcrXw), we consider this parameter useful in the case Symmetric Ecnryption-Asymmetric Signature, that would otherwise be done by encapsulating a COSE_Encrypt in a COSE_Sign structure, causing a very large overhead, as presented at the IETF94 f2f meeting. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/12#issuecomment-165062219 ----==_mimepart_56713fa0b8601_68743fea15f612bc189013f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Following our analysis posted to the mailing list, we consider this parameter useful in the case Symmetric Ecnryption-Asymmetric Signature, that would otherwise be done by encapsulating a COSE_Encrypt in a COSE_Sign structure, causing a very large overhead, as presented at the IETF94 f2f meeting.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56713fa0b8601_68743fea15f612bc189013f-- From nobody Wed Dec 16 12:32:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0AD1A89F2 for ; Wed, 16 Dec 2015 12:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 AZqhE2Zg7Pc3 for ; Wed, 16 Dec 2015 12:32:26 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08811A89D3 for ; Wed, 16 Dec 2015 12:32:25 -0800 (PST) Date: Wed, 16 Dec 2015 12:32:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450297945; bh=i5qGOuJE1CCex0AQiL2ggea/lSh0yaFGIv0FWOTjt0g=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f+WIUt5J6AS4EzYpUYlDgYC/820Geau5SKf40hqCGSwAQt0vJvct1pWr96A3Q8+yC OYTp6yJF2rOSuyBbS82xnGxTFouGlSpH2u9XD/epPwBL6bExyd3JBBz15XN67hGoGz aR8Z2/GnFekT7RrAeSleirm9PZWj5hqh/2Jzy5h8= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5671ca58e9f3e_6c0d3f927f5e729c23698f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Remove_=E2=80=9Ccounter_signat?= =?utf-8?b?dXJl4oCdIGhlYWRlciBwYXJhbWV0ZXIgKCMxMik=?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 20:32:27 -0000 ----==_mimepart_5671ca58e9f3e_6c0d3f927f5e729c23698f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Given that we have a solid use case for this parameter, it will remain in the document. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/12#issuecomment-165230796 ----==_mimepart_5671ca58e9f3e_6c0d3f927f5e729c23698f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Given that we have a solid use case for this parameter, it will remain in the document.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5671ca58e9f3e_6c0d3f927f5e729c23698f-- From nobody Wed Dec 16 16:28:13 2015 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 9B9301A1A56; Wed, 16 Dec 2015 16:28:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217002811.12150.94109.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 16:28:11 -0800 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-09.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 00:28:11 -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 Working Group of the IETF. Title : CBOR Encoded Message Syntax Author : Jim Schaad Filename : draft-ietf-cose-msg-09.txt Pages : 99 Date : 2015-12-16 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies procesing for signatures, message authentication codes, and encryption using CBOR. This document also specifies a represention for cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-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 Wed Dec 16 20:51:23 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16661A6FB0 for ; Wed, 16 Dec 2015 20:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 M-z5FlvHbfpN for ; Wed, 16 Dec 2015 20:51:21 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD741A6F9C for ; Wed, 16 Dec 2015 20:51:20 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 9D7BD2C9C5 for ; Wed, 16 Dec 2015 20:51:17 -0800 (PST) From: "Jim Schaad" To: References: <20151217002811.12150.94109.idtracker@ietfa.amsl.com> In-Reply-To: <20151217002811.12150.94109.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 20:48:33 -0800 Message-ID: <008101d13886$2f13b990$8d3b2cb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQITQGEFCabIPfFY6e9IdXW0KDI0a55KdFsg Archived-At: Subject: [COSE] FW: I-D Action: draft-ietf-cose-msg-09.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 04:51:23 -0000 This draft has a great many changes - including some that complicate the document and make it longer. It now supports the versions of MAC and Sign that people kept asking for. It is not clear that the excess complexity is worth the effort, but that is personal opinion that is not generally shared. Almost all of the issues in the tracker have been addressed which are not targeted at the WGLC version of the document. The main ones left are: * Clarifications of the registration process around first-come, first-served and/or Expert review and if they are incompatible. Mail to Hannes has already been sent asking for clarifications of his opinion - but others please chime in on that conversation. * Restoration of the 'use' parameter - I sent mail on 11/6 in part on this issue (subject deals with key_ops) where I had a proposal that would allow key_ops to devolve be basically the same as use in size. I do not like the idea of two ways of doing the same thing. It does not appear to have been responded to. * I need to look at the last mail from the OSCoAP people and deal with what issues it raises. I am hopeful that we can look at doing a WGLC by the middle of January. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, December 16, 2015 4:28 PM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-msg-09.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 Working > Group of the IETF. > > Title : CBOR Encoded Message Syntax > Author : Jim Schaad > Filename : draft-ietf-cose-msg-09.txt > Pages : 99 > Date : 2015-12-16 > > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for the > ability to have the basic security services defined for this data > format. This document specifies procesing for signatures, message > authentication codes, and encryption using CBOR. This document also > specifies a represention for cryptographic keys using CBOR. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cose-msg-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-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/ > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Dec 21 12:22:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D171E1ACCFA for ; Mon, 21 Dec 2015 12:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 k767tejM1Uyl for ; Mon, 21 Dec 2015 12:22:38 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536E91ACCFB for ; Mon, 21 Dec 2015 12:22:38 -0800 (PST) Date: Mon, 21 Dec 2015 12:22:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450729357; bh=JBzTwJB7wCqKuGJTbfhY1xRqwQrReX3LNZVAVag2tFc=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=QpfEmlyPtByemoAkyTCeyjqeqOGfCuLxjm4SoU55b/M6DIPal5zfCnZOoWUtv8XSj 6vWsjNulU0f7rMM15w2/nhiEh1hhDiPRiIitkrLJ3kLZ+fK14CP99VgoYqjdVv0K2I kthE0mjS0DsqxJKGoaKT+8EkrAZ59VbzEblM6Cpo= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56785f8d4aa78_6d8c3f80075912a05507a3"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Tag Request Range for CBOR Tags (#54) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 20:22:40 -0000 ----==_mimepart_56785f8d4aa78_6d8c3f80075912a05507a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Do we need to change the request range of CBOR Tags in the current document The current request is going to produce two byte tags It would be possible to request single byte tags for some of the structures However, it is equally possible that the untagged versions are going to be used and the content types are going to be carried in COaP --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/54 ----==_mimepart_56785f8d4aa78_6d8c3f80075912a05507a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Do we need to change the request range of CBOR Tags in the current document The current request is going to produce two byte tags It would be possible to request single byte tags for some of the structures However, it is equally possible that the untagged versions are going to be used and the content types are going to be carried in COaP

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56785f8d4aa78_6d8c3f80075912a05507a3-- From nobody Mon Dec 21 13:19:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B59B1ACD62 for ; Mon, 21 Dec 2015 13:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 iimUvyJE20Io for ; Mon, 21 Dec 2015 13:18:57 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B166A1ACD61 for ; Mon, 21 Dec 2015 13:18:57 -0800 (PST) Date: Mon, 21 Dec 2015 13:18:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450732736; bh=j5LEbru2YqpCMlqW6OkFX/KjVtq5GgTF5KqV5VDgUEQ=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=tYfeRrwCRCeBsiKBnL5/yTZDTY6tSOWwnIGLxdUKg+/GWQfTOg1bRbEA8QyVigF25 4DoQXhyIjsXBuQH/BtoJ7xHZJpbpdYF1L1juE8WVOFexMMym0S00jMtcgnpnIsp8sZ LNyHgji7NsMZOEcZIXq5PJY7vJNDKybL01bFKwVs= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56786cc04e97d_501b3fb10ffdf2a062348e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Define a curve registry. (#55) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 21:18:59 -0000 ----==_mimepart_56786cc04e97d_501b3fb10ffdf2a062348e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Do we need to define a curve registry or is the fact that EC2 curves are going the way of the dodo mean that we can avoid it --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/55 ----==_mimepart_56786cc04e97d_501b3fb10ffdf2a062348e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Do we need to define a curve registry or is the fact that EC2 curves are going the way of the dodo mean that we can avoid it

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56786cc04e97d_501b3fb10ffdf2a062348e-- From nobody Mon Dec 21 13:30:35 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2CC1ACD87 for ; Mon, 21 Dec 2015 13:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 GBeFUKCo7zN6 for ; Mon, 21 Dec 2015 13:30:31 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10BC1ACD81 for ; Mon, 21 Dec 2015 13:30:31 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id D724838EEE; Mon, 21 Dec 2015 13:30:30 -0800 (PST) From: "Jim Schaad" To: "'Ilari Liusvaara'" , References: <20151123052530.GA14493@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151123052530.GA14493@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 21 Dec 2015 13:27:47 -0800 Message-ID: <011401d13c36$70a38440$51ea8cc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL8Rv3guYwGKrv37rhtM3tlUgiH7px/2V2w Content-Language: en-us Archived-At: Subject: Re: [COSE] CFRG ECC algorithms in COSE -- design aspects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 21:30:34 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Sunday, November 22, 2015 9:26 PM > To: cose@ietf.org > Subject: [COSE] CFRG ECC algorithms in COSE -- design aspects > > I have done a few rounds on pre-draft about CFRG ECC algorithms in JOSE on > the jose list, and seems things are converging. Now, to porting this stuff to > COSE. CFRG-Curves is already in RFC-Ed.Q, but CFRG-EDDSA is unlikely to reach > that in time before COSE-MSG is sent to IESG (assuming you keep your > schedule), so this stuff would likely go to an extra document[1]. > > > The important design points are: > - A new key type "OKP" (Octet Key Pair) > - Has paramter "crv" (don't ask why they wanted it named that) that is > essentially subtype of key (X25519, X448, Ed25519, Ed25519ph, Ed448, > Ed448ph). This is because mixing different kinds of keys is > dangerous. Another possibility would be to kill the "crv" parameter and to require the "alg" parameter to be present. We are, for all practical purposes, going towards saying that the algorithm and the key type are becoming synonymous. > - Has parameter "x" (again, don't ask) that is base64-encoded public > key octet string. And since we only have X - we can avoid issues of compressed formats (yeah!!!) > - ECDH-ES with X25519/X448 uses the respective Diffie-Hellman > Functions, with octet-string inputs and outputs. > - Signatures use the signing and verification functions, with octet- > string inputs and outputs (except for verification, which has > boolean output). > - All keys and signatures are handled are handled as octet strings with > no structure. > > > Straightforward method to port most of this stuff: > - New key type: OKP(1): Octet-string key pairs > - Key parameters for it: > * crv(-1)[int/tstr]: Key subtype > * x(-2)[bstr]: Public key (octet string) > * d(-4)[bstr]: Private key (octet string) > > Now, for the less trivial stuff: > - Can one reuse the crv values 1-3 (these are used in another key > type ("EC2"))? I think we can go either way on this. If we re-use the same values then it is a new registry and one can be happy. If we don't re-use the same values then we can create a registry and refer to the registry for both key types. On the other hand, if we make alg required then we can punt this question. > - What length of identifiers one should assign? I would think that > the identifiers for X25519 and Ed25519 should be from range 0-23 > (1 byte), and others could be 24-255 (2 bytes), as Ed25519ph > is odd one, and the others have quite a bit larger keys and > signatures due to higher security level. That would be a reasonable ask of IANA. > - Combine all the signature algorithms under just one identifier > (use key subtyping to resolve what algorithm is used, removes > a source of security bugs)? I am not sure that is going to remove security bugs or adds security bugs. Once upon a time there were no problems with DSA as the key size and hash were fixed. Over time this has become no longer true and thus we get back some security bugs that we would like to get rid of. I am not really happy with how I have specified the ECDSA algorithms in the core document due to the fact that multiple curves can be used with a single hash size - the hash being truncated if it is too long. Being more hard core by making a new algorithm for each one, and making the algorithm specify all of the details might be a better answer. What is the best way to talk about things - the way algorithm identifiers are assigned for RSA-SSA v1.5 or for RSA-PSS. In the former case the hash algorithm is part of the identifier and a new identifier needs to be assigned for every new hash algorithm. The latter does not have a hash algorithm in any part of the signed value and thus it would be possible (although unlikely) to be able to do a hash algorithm substitution attack. > > The pre-draft does talk about JWK thumbprints too (and even contains an > example thumbprint computation). I haven't seen COSE discussing thumbprints. I am somewhat anti-thumbprint algorithm as I don't really believe that they are useful. A thumbprint is only helpful if one going to assume that two entities can compute the same thumbprint and they have a good reason to do so. I would be more inclined to do something along the likes of the PKIX key identifier where one can say - here are some different ways to compute one, try and make them unique. Jim > > > [1] I realize that you do want to be a quick WG and shut down. I think Crudle (or > whatever the WG ends up being called) could take the work then. Given that there is going to be a secondary algorithm draft, I don't know that this is an issue. > > > -Ilari > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Dec 21 14:24:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5288D1ACDEF for ; Mon, 21 Dec 2015 14:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 ZvQWnkFCrSv7 for ; Mon, 21 Dec 2015 14:24:49 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6301ACDEC for ; Mon, 21 Dec 2015 14:24:49 -0800 (PST) Date: Mon, 21 Dec 2015 14:24:47 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450736687; bh=HO9h+UCRhW4sBhl8UfaU0y4Xt0ogbCLkqFlRYv67Jsc=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=yEOt/MYiMLBW3KLdJifvkmVqVPtBmQ/KAfhWK/nj4tWW9xQ79HOKAR9CsyIOh0r0y cWIy1kiw7LBiXM4aSu8gj0PyOCs3T6GhmEGsAC+aZBl5opZqX1v82lUC2KPClf/Y5v c96beB4cV4MFtAZDPTb04wzll6DNUUuRjgiv5yjk= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56787c2f7a927_93b3fa019a732a022443f5"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Change the definition of label (#56) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 22:24:51 -0000 ----==_mimepart_56787c2f7a927_93b3fa019a732a022443f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This issue was raised by Hannes Additionally, I also don't like the idea of having a label be either an integer or a string Why cannot we just use integers? This sounds like introducing options for no good reasons that just increase the implementation complexity --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/56 ----==_mimepart_56787c2f7a927_93b3fa019a732a022443f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

This issue was raised by Hannes

Additionally, I also don't like the idea of having a label be either an integer or a string Why cannot we just use integers? This sounds like introducing options for no good reasons that just increase the implementation complexity

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56787c2f7a927_93b3fa019a732a022443f5-- From nobody Mon Dec 21 16:34:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB81ACDDD for ; Mon, 21 Dec 2015 16:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 mrxll9MSbN3A for ; Mon, 21 Dec 2015 16:34:18 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219371A6F9C for ; Mon, 21 Dec 2015 16:34:18 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8FB0C38F0E; Mon, 21 Dec 2015 16:34:17 -0800 (PST) From: "Jim Schaad" To: "Jones Mike" References: In-Reply-To: Date: Mon, 21 Dec 2015 16:31:34 -0800 Message-ID: <015801d13c50$1d1e24a0$575a6de0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIh77xEt34fKYVFI50LfMLhy5sRZQE/4W0Wniq+CmA= Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 00:34:19 -0000 Mike, I was wondering if you could address what might be seen as a change in = your attitude to this over time. The JOSE specifications allow for a privately defined header field to be = created. Something similar to the current COSE allocations is done in the JOSE = documents by the following: Registered Header Parameter Names in JOSE: This corresponds to the = general area of Specification Required assignment area of COSE = documents. I note that although a reference to a document is required, = it implicitly but does not explicitly require that the document be = publicly available.=20 Public Header Parameter Names in JOSE: This correspond to the set of = first-come, first serve assignment area of COSE documents. JOSE deals = with this by saying that it should be collision resistant by prefixing = (or some other method) to make the name statistically unique. For COSE = it would not be possible to have any degree of uniqueness of the headers = in the same way while still maintaining the desire to have very short = identifiers. There is a big difference in size between = "http://example.org/COSE/foobar" and 0x100000 when doing the encodings = in CBOR. Private Header Parameter Names in JOSE: This corresponds to the private = registry assignment area of COSE documents. It would appear from this that there is an implicit registry area for = JOSE which allows for a section header parameters which does not have = publicly available specifications when implicitly registered. To wit, = the Public Header Parameter Names. I am not sure if this really represents a change in your opinions or if = you have just not considered these as being equivalent. Jim From nobody Tue Dec 22 20:25:30 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164EF1AC3A1 for ; Tue, 22 Dec 2015 20:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 68-ZpGaG4TZ9 for ; Tue, 22 Dec 2015 20:25:27 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0981AC39E for ; Tue, 22 Dec 2015 20:25:27 -0800 (PST) Date: Tue, 22 Dec 2015 20:25:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1450844727; bh=U73YImKaFo3kVFkh75oEZ3NsV0es07mKQVsIy7vRrw4=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=GcM+pjl4Q0D4zhFikoa3RAC7o/1AJsVZXMThcoaPdnEx/e29eHe7QuvKoqPIFZ2ZQ 0ZPyQJuRhSYt74W61CXc6uGMzn6ZDSItsocijqK0eKCUjMr9Qs9MsnLBys/Owavpfq wDmpjc/ToWTufiClpUP3EnXSHauy0Z6kgi/W5vdM= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_567a2236ea37c_9253fc2f12832c040055e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Change Example File Names (#57) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 04:25:29 -0000 ----==_mimepart_567a2236ea37c_9253fc2f12832c040055e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Change the file names of the examples in the example repository to match the appendix numbers in the document and then remove the file names from the text --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/57 ----==_mimepart_567a2236ea37c_9253fc2f12832c040055e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Change the file names of the examples in the example repository to match the appendix numbers in the document and then remove the file names from the text

—
Reply to this email directly or view it on GitHub.

----==_mimepart_567a2236ea37c_9253fc2f12832c040055e--

On Wed, Dec 9, 2015 at 11:14 AM, Jim Schaa= d <ietf@augustcellars.com> wrote:

Given that this field is never transmitted= across the wire, there is no difference in message size.

=C2=A0

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Wednesday, December 09= , 2015 9:51 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: M= ike Jones <Michael.Jones@microsoft.com>; cose@ietf.org
Subject: Re: [COSE] [cose-issu= es] Move external_aad to the end of structures using it and make its presen= ce optional (#48)

=C2=A0

I dare say that simplicity is in the = eye of the beholder here. Depending on one's perspective, it's quit= e reasonable to argue that either approach is simpler.

What's less subjective is the matter of mess= age size. Using a 3 element array when there's no external aad does res= ult in a smaller message for that arguably common case. It's only one b= yte smaller but it is smaller and even a single byte is meaningful when the= amount of overhead being discussed is in the 10-20 byte neighborhood - http://www.ietf.org/mail-archive/web/cose/current/msg00850.= html .

= =C2=A0

= On Tue, Dec 8, 2015 at 4:20 PM, Jim Schaad <ietf@augustcellars.com> wrote:

=C2= =A0

=C2=A0

From:= Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Tue= sday, December 08, 2015 2:55 PM
To: Jim Schaad <ietf@augustcellars.com>= ;
Cc: cose@iet= f.org
Subject: RE: [cose-issues] Move external_aad to the end= of structures using it and make its presence optional (#48)<= u>

=C2=A0

Your way has conditional logic for construc= ting the data structures depending upon whether an external_aad value is su= pplied.=C2=A0 So does mine.=C2=A0 So both have =E2=80=9Ctwo ways of doing t= hings=E2=80=9D =E2=80=93 not one way.=C2=A0 The difference is only whether = a zero-length field is supplied or whether it=E2=80=99s omitted, which is p= retty much equivalent from a security and timing perspective.=

=C2=A0

No =E2=80=93 I do not have any l= ogic about adding the value.=C2=A0 I initialize my environment to be a zero= length aad value and always add it to the computation.=C2=A0 If we pick up= your change then I =C2=A0would have to add logic into the system to deal w= ith the presence or lack of it.=C2=A0 Similarly if there is no support at a= ll for external add value there is no conditions =E2=80=93 a zero length bs= tring (i.e one byte) is always added to the value computed.

=C2=A0<= /p>

This is simpler than the logic you= r version would require me to implement.

=C2=A0

You seem worried about implementation errors, which= I agree is often a valid concern.=C2=A0 The good news in this case is that= incorrect implementations will generate the wrong signature or HMAC value,= causing the implementation to fail during interop testing, well before it= =E2=80=99s ever deployed.=C2=A0 Normal testing/debugging will catch this.

=C2=A0<= u>

The additional simpl= ification that my proposal enables is that an implementation can have zero = code about external_aad if it=E2=80=99s not supported, where with your repr= esentation, the implementation still has to have code to insert the unneces= sary and unused array value.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: = Tuesday, December 8, 2015 1:29 PM
To: Mike Jones <Michael.Jones@microsof= t.com>
Cc: cose@ietf.org
Subject: RE: [cose-issues] Move external_aa= d to the end of structures using it and make its presence optional (#48)

=C2=A0

I do not believe that invoking = security is incorrect in this instance.=C2=A0 The statement that security i= ssues tend to arise on parsing is not something I would accept as a given.= =C2=A0 I have probably seen just as many or more problems with building str= ings, random number generation, timing attacks as I have seen parsing error= s.=C2=A0=C2=A0 I don=E2=80=99t think that is a supportable proposition.

=C2=A0=

You and I have differe= nt ideas on what it means to =E2=80=9Ckeep things simple=E2=80=9D.=C2=A0 Fo= r me, one way of doing things without options is always simpler and less pr= one to error.=C2=A0 Thus to me having a fixed array is the simpler option.= =C2=A0 It does not matter if the specific implementation does or does not s= upport external aad, creating the one additional field in the array is not = the same burden as the same thing is going to be for those implementations = that do implement the external aad feature.=C2=A0 Making it optional introd= uces a new state into the system of a zero length aad which is different fr= om no aad.

= =C2=A0

Again = in my opinion =E2=80=93 the current version is simpler that what you are pr= oposing.

=C2= =A0

Jim

=C2=A0

=C2=A0<= /u>

From: Mi= ke Jones [mai= lto:notifications@github.com]
Sent: Tuesday, December 08, 20= 15 12:39 PM
To: cose-wg/cose-issues <cose-issues@noreply.github.com>
Cc: Jim Schaad <ietf@augustcellars.com>
Subject: Re: = [cose-issues] Move external_aad to the end of structures using it and make = its presence optional (#48)

=C2=A0

Invoking security seems incorrect an= d overstated here. These values are never parsed - which is when security i= ssues tend to arise. They are just created internally and then used as seri= alized byte array inputs to cryptographic operations. There is no security = problem with having both 3-member and 4-member array values for this interm= ediate temporary result.

Please capitalize on this oppo= rtunity to "keep simple things simple" - one of the working group= principles stated by the chairs on slide 22 of their opening presentation = at https://www.ietf.org/proceedings/93/slides/slides-93-= cose-2.pdf. Especially in light of the fact that many implementations w= on't need support for external_aad, per issue #50, please = make these implementations simpler by making the presence of the external_a= ad array member optional.

=E2=80=94
Reply to this email directly or vi= ew it on GitHub.

=


_______________________________________________
COSE mailing list<= br>COSE@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/cose

=C2=A0