From nobody Mon Jun 4 17:28:01 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D7130E31 for ; Mon, 4 Jun 2018 17:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osv6HofA2RZF for ; Mon, 4 Jun 2018 17:27:55 -0700 (PDT) Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80289130E27 for ; Mon, 4 Jun 2018 17:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1528158475; x=1559694475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=27eKVXFHBlG8rs+Xy4oekR38VBY4xLRjcFMkIlWTBUI=; b=oYApGGbTZ2jkiDlmPR0WpjZOrio8j3yEesCIyquuYGBOOCiPZzHsRHb4 rB5fOx+1vBO3rxfVX1QJORu0+yzbA7dqvtYYJW/sk3OrwA8HMlxV+Xiqb /9h+XGuw46OIosAeL7MnOr9OuwwWXWvL0uveBPNPvyklOMf56W4EyTden s=; Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-01.qualcomm.com with ESMTP; 04 Jun 2018 17:27:53 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8914"; a="179197891" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 04 Jun 2018 17:27:49 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 4 Jun 2018 17:27:40 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Mon, 4 Jun 2018 17:27:40 -0700 From: Laurence Lundblade To: Carsten Bormann CC: "cbor@ietf.org" Thread-Topic: [Cbor] Canonical CBOR Thread-Index: AQHT+DAtw9B4IAE4bU+ppwSV0kSEKKRJGMsAgAg0MoA= Date: Tue, 5 Jun 2018 00:27:39 +0000 Message-ID: <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> In-Reply-To: <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="utf-8" Content-ID: <0438C80D9F022140B3DE30E5FA62338F@qualcomm.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 00:27:58 -0000 U28gSeKAmXZlIGhhZCBzb21lIHRoaW5rIHRpbWUgb24gdGhpcy4NCg0KUmF0aGVyIHRoYW4gYXNr aW5nIGFib3V0IGltcGxlbWVudGF0aW9ucywgSSBzaG91bGQgaGF2ZSBhc2tlZCBhYm91dCBDQk9S LWJhc2VkIHByb3RvY29sIGRlc2lnbnMgdGhhdCBuZWVkIG9yIGJlbmVmaXQgZnJvbSBjYW5vbmlj YWxpemF0aW9uLiAgSeKAmW0gZmFtaWxpYXIgd2l0aCBDV1QgYW5kIENPU0Ugc28gbGV04oCZcyBz ZWUgYWJvdXQgY2Fub25pY2FsaXphdGlvbiBpbiB0aGVtLg0KDQpDV1QgZG9lc27igJl0IHJlcXVp cmUgY2Fub25pY2FsaXphdGlvbiBhbmQgdGhhdCBhbGwgc2VlbXMgZmluZS4gIFRoZSBtYWluIGJl bmVmaXQgSSBjYW4gc2VlIGNhbm9uaWNhbGl6YXRpb24gYnJpbmdpbmcgaXMgdGhlIHRlc3Rpbmcg YmVuZWZpdCB0aGF0IHlvdSBtZW50aW9uLiBGb3IgdGhlIHNhbWUgc2V0IG9mIGlucHV0IGNsYWlt cywgeW91IGNhbiBiaW5hcnkgY29tcGFyZSB0aGUgb3V0cHV0IG9mIHR3byBpbXBsZW1lbnRhdGlv bnMgYW5kIGtub3cgdGhleSBtYXRjaCAoYXQgbGVhc3QgdGhhdCBpcyB0aGUgdGVzdGluZyBiZW5l Zml0IEkgdGhpbmsgeW91IGFyZSBtZW50aW9uaW5nKS4gIE15IGZlZWxpbmcgaXMgdGhhdCByZXF1 aXJpbmcgY2Fub25pY2FsaXphdGlvbiBmb3IgQ1dUIGZvciB0aGlzIHJlYXNvbiB3b3VsZCBub3Qg YmUgYSBnb29kIGRlc2lnbiB0cmFkZS1vZmYuIA0KDQpDT1NFIG9uIHRoZSBvdGhlciBoYW5kIGRv ZXMgcmVxdWlyZSBjYW5vbmljYWxpemF0aW9uIGluIHNvbWUgcGxhY2VzIGFuZCAobWF5YmUpIG5v dCBpbiBvdGhlcnMuDQoNClNlY3Rpb24gMyBzYXlzIHRoYXQgcHJvdGVjdGVkIGhlYWRlcnMgYXJl IGJzdHIgd3JhcHBlZCBzbyB0aGV5IGRvbuKAmXQgaGF2ZSB0byBiZSBjYW5vbmljYWxpemVkLg0K DQpTZWN0aW9uIDE0IHJlcXVpcmVzIGNhbm9uaWNhbGl6YXRpb24gZm9yIFNpZ19zdHJ1Y3R1cmUs ICBFbmNfc3RydWN0dXJlLCBhbmQgTUFDX3N0cnVjdHVyZS4gIEkgaW50ZXJwcmV0IHRoaXMgYXMg cmVxdWlyaW5nIGNhbm9uaWNhbGl6YXRpb24gZm9yIGFueSAvIGFsbCBvZiB0aGUgbWFwcyBpbiB0 aGVzZSBzdHJ1Y3R1cmVzIGluY2x1ZGluZyBzb3J0aW5nLiBJIGhhdmUgYSBmZXcgaXNzdWVzIHdp dGggdGhpcyByZXF1aXJlbWVudDoNCg0KLSBUaGlzIHNlZW1zIGF0IG9kZHMgd2l0aCB0aGUgc3Rh dGVtZW50IFNlY3Rpb24gMyBlc3BlY2lhbGx5IGFzIHRoZSBwcm90ZWN0ZWQgcGFydHMgb2YgdGhl c2Ugc3RydWN0dXJlcyBhcmUgYnN0ciB3cmFwcGVkLg0KDQotIFRoaXMgY2Fub25pY2FsaXphdGlv biBzZWVtcyB1bm5lY2Vzc2FyeS4gSSBqdXN0IGNhbuKAmXQgc2VlIHdoYXQgY291bGQgZ28gd3Jv bmcgaWYgeW91IGRvbuKAmXQgY2Fub25pY2FsaXplLiBDYW5vbmljYWxpemUgb2YgdGhlIHBheWxv YWQgaXMgbm90IHJlcXVpcmVkIGFuZCB0aGF0IHdvcmtzIE9LLiAgSXQgc2VlbXMgbGlrZSBDT1NF IHdvdWxkIGJlIGJldHRlciBieSBqdXN0IGRlbGV0aW5nIHNlY3Rpb24gMTQuDQoNCkl0IGZlZWxz IGxpa2UgbWF5YmUgdGhpcyB3YXMgcHV0IGluIHdoZW4gdGhlcmUgd2FzIHNvbWUgdGhpbmtpbmcg dGhhdCBjYW5vbmljYWxpemF0aW9uIHdhcyBnb29kIGZvciBzaWduaW5nLCBidXQgbm93IHRoYXQg dHVybmVkIG91dCBub3QgdG8gYmUgdHJ1ZT8gUGFyZG9uIGlmIEnigJltIGRlbnNlIGFuZCBtaXNz aW5nIHNvbWV0aGluZy4gSG93ZXZlciwgSSByZWFsbHkgYW0gdHJ5aW5nIHRvIGJlIGNvbnN0cnVj dGl2ZS4NCg0KDQpUbyBnbyBhIGJpdCBmdXJ0aGVyLCBpdOKAmXMgdGhlIHNvcnRpbmcgZm9yIHRo ZSBwdXJwb3NlIG9mIGR1cGxpY2F0ZSBkZXRlY3Rpb24gdGhhdCByZWFsbHkgYm90aGVycyBtZSBi ZWNhdXNlIHRoZSBjb3N0IG9mIGltcGxlbWVudGF0aW9uIG9mIHRoYXQgY2FuIGJlIGEgYml0IGhp Z2guIEl0IG1pZ2h0IHJlcXVpcmUgc29ydGluZyB2YXJpYWJsZSBsZW5ndGggY2h1bmtzIG9mIG1l bW9yeSBpbiBSQU0gKGJ5IGNvbXBhcmlzb24sIHRoZSBzbWFsbGVzdC1wb3NzaWJsZSBsZW5ndGgg LyBpbnQgZW5jb2RpbmcgaXMgbm90IGRpZmZpY3VsdCB0byBpbXBsZW1lbnQpLiANCg0KWW91IGNh biBkbyBkdXBsaWNhdGUgZGV0ZWN0aW9uIG9uIHRoZSBDT1NFIGhlYWRlcnMgZWZmaWNpZW50bHkg ZXZlbiBpZiB0aGUgaW5wdXQgaXMgbm90IHNvcnRlZC4gV2hlbiBpbml0aWFsaXplIHRoZSBrZXks IElWIGFuZCBvdGhlciBoZWFkZXIgdmFycyB0byBlbXB0eS4gSWYgeW91IHRyeSB0byBzZXQgb25l IHRoYXQgaXMgbm90IGVtcHR5IHlvdSBjYW4gZXJyb3Igb3V0LiAgSSB0aGluayBtYXliZSBzb3J0 aW5nIHdoaWxlIGVuY29kaW5nIG1pZ2h0IGJlIG1vcmUgY29tcGxleCB0aGFuIGRvaW5nIGR1cGxp Y2F0ZSBkZXRlY3Rpb24gb24gYW4gdW5zb3J0ZWQgbWFwIGR1cmluZyBkZWNvZGluZy4NCg0KTEwN Cg0KDQoNCg0KDQo+IE9uIE1heSAzMCwgMjAxOCwgYXQgMTI6MTAgUE0sIENhcnN0ZW4gQm9ybWFu biA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4gDQo+IEhpIExhdXJlbmNlLA0KPiANCj4gdGhhbmsg eW91IGZvciBicmluZ2luZyB0aGlzIHN1YmplY3QgdXAgYWdhaW4uDQo+IA0KPiBJbiAyMDEzLCB3 ZSBrbmV3IHdoYXQgd2Ugd2VyZSB1cCB0byB3aGVuIHdlIHdyb3RlIHRoZSBvcmlnaW5hbCBzZWN0 aW9uIDMuOSBvZiBSRkMgNzA0OS4NCj4gRXNzZW50aWFsbHksIGNhbm9uaWNhbGl6YXRpb24gKDE0 bikgaXMgYSBtaW5lIGZpZWxkIHdoZXJlIHRoZSBvbmx5IHdheSB0byB3aW4gaXMgdG8gbm90IHBs YXkuDQo+IA0KPiBIb3dldmVyLCB3ZSBnb3QgYSBmZXcgdGhpbmdzIHJpZ2h0LCBJIHRoaW5rOg0K PiANCj4gKDEpIHdlIGFja25vd2xlZGdlZCB0aGF0IGMxNG4gaXMgdG8gYSBjZXJ0YWluIGV4dGVu dCBhcHBsaWNhdGlvbi1zcGVjaWZpYy4gIFNvIHRoZSBSRkMgZ2l2ZXMgc29tZSBndWlkYW5jZSwg YnV0IGRvZXMgbm90IGRlZmluZSBhIHNpbmdsZSBoYXJkIGFuZCBmYXN0IHNldCBvZiBydWxlcy4N Cj4gDQo+ICgyKSB0aGUgc2VyaWFsaXphdGlvbiBwcm92aWRlcyBsaXR0bGUgaW50cmluc2ljIGlu Y2VudGl2ZSBmb3IgZ3JhdHVpdG91cyB2YXJpYXRpb24uICBBcGFydCBmcm9tIGRlZmluaXRlIHZz LiBpbmRlZmluaXRlIGxlbmd0aHMgKHdoaWNoIGlzIGFuIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRo YXQgZGVwZW5kcyBvbiBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUgb2J2aW91cyBydWxl IHRvIHVzZSB0aGUgc2hvcnRlc3Qgb2Ygc2V2ZXJhbCBwb3NzaWJsZSBlbmNvZGluZ3MgaXMgbmF0 dXJhbCBhbmQgZWFzeSB0byBpbXBsZW1lbnQuICBbT25lIGRlc2lnbiBhbHRlcm5hdGl2ZSwgdG8g b25seSBldmVyIGFsbG93IHRoZSBzaG9ydGVzdCBlbmNvZGluZywgaXMgcHJvYmxlbWF0aWMgZm9y IHNvbWUgb3RoZXIgYXBwbGljYXRpb25zLl0gIEltcGxlbWVudGF0aW9ucyBhbHJlYWR5IGRvIHRo aXMgbmF0dXJhbGx5IChleGNlcHQgc29tZXRpbWVzIGZvciBmbG9hdGluZyBwb2ludCDigJQgaW1w bGVtZW50ZXJzIG9mIHNlcmlhbGl6YXRpb24gbGF5ZXJzIG9mdGVuIGtub3cgbGl0dGxlIGFib3V0 IGZsb2F0aW5nIHBvaW50IGFuZCBhcmUgcmlnaHRmdWxseSBzY2FyZWQgYnkgaXQuICBUaGF04oCZ cyB3aHkgd2UgaGF2ZSB0aGUgZXhhbXBsZSBjb2RlIGluIHRoZSBhcHBlbmRpeOKApiBhbmQgaXQg aXMgZWFzeSB0byBkbyBleGhhdXN0aXZlIHRlc3RpbmcgYXQgbGVhc3QgZm9yIGJpbmFyeTE2ISku DQo+IA0KPiBXZSBhbHNvIGdvdCBvbmUgdGhpbmcgZXh0cmVtZWx5IHdyb25nOg0KPiANCj4gKEEp IHRoZSBjYW5vbmljYWwgb3JkZXJpbmcgZm9yIGtleXMgYmFzZWQgb24gbGVuZ3RocyBmaXJzdCwg dGhlbiBieXRlLXdpc2UgbGV4aWNvZ3JhcGhpY2FsIG9yZGVyLCBpcyB2aW9sYXRpbmcgdGhlIHBy aW5jaXBsZSBvZiBsZWFzdCBzdXJwcmlzZSBhbmQgcG9zZXMgc29tZSBwZXJmb3JtYW5jZSBkaXNh ZHZhbnRhZ2VzLiAgVGhpcyBwcm9iYWJseSBzaG91bGQgYmUgZml4ZWQgdG8gcHVyZSBieXRlLXdp c2UgbGV4aWNvZ3JhcGhpY2FsIG9yZGVyLiAgQXBwbGljYXRpb25zIHRoYXQgYWxyZWFkeSBoYXZl IGRlY2lkZWQgdG8gdXNlIHRoZSBleGlzdGluZyBtYXAgb3JkZXIgZ3VpZGFuY2UgY2FuIGRvIHRo YXQgYnkgaW52b2tpbmcgKDEpIGFib3ZlLg0KPiANCj4gDQo+IFNvIHdoYXQgYXJlIHRoZSB1c2Ug Y2FzZXM/ICBTaWduaW5nIGluZm9ybWF0aW9uIGV4cHJlc3NlZCBhdCB0aGUgZGF0YSBtb2RlbCBs ZXZlbCBpcyBvZnRlbiBnaXZlbiBhcyBvbmUsIGJ1dCBpdCBpcyBub3QgdmVyeSBjb252aW5jaW5n LiAgV2hhdCBJIGNvbnNpZGVyIG11Y2ggbW9yZSBpbnRlcmVzdGluZyBpcyB0byBiZSBhYmxlIHRv IGRvIGJ5dGUtd2lzZSBjb21wYXJpc29uIG9mIGluc3RhbmNlcyB0byBlc3RhYmxpc2ggYSBjZXJ0 YWluIGRlZ3JlZSBvZiBkYXRhIG1vZGVsIGxldmVsIGVxdWFsaXR5L2luZXF1YWxpdHkuICBUaGlz IGlzIHJlYWxseSB1c2VmdWwgZm9yIHRlc3RpbmcgYW5kIGZvciBtYXRjaGluZyBpbmZvcm1hdGlv biBpbiBhIGRhdGFiYXNlLg0KPiANCj4gU2V2ZXJhbCBvZiB0aGUgNTAgaW1wbGVtZW50YXRpb25z IG9mIENCT1IgbGlzdGVkIGF0IGNib3IuaW8gZG8gc29tZSBmb3JtIG9mIGMxNG4sIHNvbWV0aW1l cyBhcyBhbiBhZGQtb24uICAoRS5nLiwgZm9yIGNib3ItcnVieSwgdGhlcmUgaXMgYSBzZXBhcmF0 ZSBnZW0gY2Jvci1jYW5vbmljYWwgdGhhdCBwcm92aWRlcyBjYW5vbmljYWwgZW5jb2RpbmcuICBU aGVyZSBpcyBubyBkZWNvZGUgY2hlY2tlciDigJQgeW91IGNoZWNrIGJ5IGNhbm9uaWNhbC1lbmNv ZGluZyBhZ2FpbiBhbmQgdGhlbiBkb2luZyBhIGJ5dGV3aXNlIGNvbXBhcmlzb24uKSAgSSBuZXZl ciBnb3QgYXJvdW5kIHRvIGNvbGxlY3RpbmcgZmVhdHVyZSBsaXN0cyBmb3IgdGhlIGltcGxlbWVu dGF0aW9ucyBvbiBjYm9yLmlvLCBzbyBJIGRvbuKAmXQga25vdyBob3cgbWFueSBvZiB0aGVtIGRv IGNhbm9uaWNhbC4NCj4gDQo+IA0KPiBXZSBkaXNjdXNzZWQgYzE0biBpbiBzb21lIGRldGFpbCBh dCBJRVRGIDEwMS4NCj4gUGxlYXNlIHNlYXJjaCBmb3Ig4oCcYzE0buKAnSBpbjoNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvbWludXRlcy0xMDEt Y2Jvci0wMA0KPiBhbmQgcmVhZCB1cCB0byDigJxpbXBsZW1lbnRhdGlvbiBtYXRyaXjigJ0uDQo+ IA0KPiBXaGlsZSB3ZSBkaWRu4oCZdCBtYWtlIGEgZmluYWwgZGV0ZXJtaW5hdGlvbiBhdCB0aGUg bWVldGluZywgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBr ZWVwIGMxNG4gYXQgdGhlIOKAnHByb3Bvc2VkIHN0YW5kYXJk4oCdIGxldmVsLCBieSBzcGxpdHRp bmcgaXQgb3V0IHRvIGEgc2VwYXJhdGUgZG9jdW1lbnQsIHdoaWxlIHRoZSByZXN0IG9mIENCT1Ig Z29lcyB0byBJbnRlcm5ldCBTdGFuZGFyZC4gIFRoaXMgYWxzbyByZWZsZWN0cyB0aGUgbG93ZXIg bGV2ZWxzIG9mIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Ugd2UgaGF2ZSB3aXRoIGMxNG4sIGFu ZCB0aGUgZGVzaXJlIHRvIGZpeCB0aGUgbWFwIG9yZGVyLg0KPiANCj4+IEhlcmXigJlzIGEgZmV3 IGlkZWFzIGZvciB3aGF0IHRvIGRvOg0KPj4gDQo+PiAjMSBSZXF1aXJlIGFsbCBpbnRlZ2VycyBh bmQgbGVuZ3RocyB0byBhbHdheXMgYmUgaW4gc2hvcnRlc3QgZm9ybSBhbmQgYWx3YXlzIHRoZSBz YW1lLg0KPiANCj4gV2UgYWxyZWFkeSBkbyB0aGlzIGZvciBjMTRuLiAgKERvIHlvdSBtZWFuIHRv IGFsd2F5cyByZXF1aXJlIHRoaXM/ICBOb3Qgc28gc3VyZSBhYm91dCB0aGF0LikNCj4gDQo+PiBE byB0aGUgc2FtZSBmb3IgZmxvYXRpbmcgcG9pbnQsDQo+IA0KPiAoQnV0IG9ubHkgd2Vha2x5IHNv IGZvciBmbG9hdGluZyBwb2ludC4pDQo+IA0KPj4gZGF0ZXMgYW5kIGFzIG1hbnkgb3RoZXIgb2Yg dGhlIHR5cGVzIGRlZmluZWQgaW4gdGhlIHNwZWMgYXMgcG9zc2libGUuICANCj4gDQo+IFRoZXNl IG9mdGVuIGhhdmUgd2F5IG1vcmUgYXBwbGljYXRpb24gc2VtYW50aWNzIHRoYW4geW91IGNhbiBo YW5kbGUgaW4gYSBnZW5lcmljIGNhbm9uaWNhbGl6ZXIuDQo+IFRyeSBjYW5vbmljYWxpemluZyBV UklzLCBSZWdleHBzLCBldGMuICBEbyB5b3UgY2Fub25pY2FsaXplIFJGQyAzMzM5IGRhdGVzIHRv IFVUQz8NCj4gSSB0aGluayB3ZSBoYXZlIHRvIGJlIG9wZW4gYWJvdXQgdGhlIGxpbWl0YXRpb25z IG9mIHdoYXQgY2FuIGJlIGRvbmUgaGVyZS4NCj4gDQo+PiBGb3IgYSBsb3Qgb2YgZGF0YSB0eXBl cywgdGhpcyBpcyBub3QgdGhhdCBoYXJkIHRvIGltcGxlbWVudCBhbmQgaXQgZWxpbWluYXRlcyBh IHZhcmlhYmlsaXR5IGluIHRoZSBzcGVjIHRoYXQgc2VlbXMgdW5uZWNlc3NhcnkuIFRoZW4geW91 IGRvbuKAmXQgaGF2ZSB0byBkZWZpbmUgYSBjYW5vbmljYWwgZm9ybWF0IGZvciB0aGVzZSB0eXBl cy4gVGhleSBhcmUgYWx3YXlzIGNhbm9uaWNhbC4NCj4gDQo+IEkgc3VyZSBsaWtlIHRoYXQgYXBw cm9hY2guDQo+IA0KPj4gIzIgSWYgbm90ICMxLCB0aGVuIG1ha2UgYSBjbGVhciBzdWJzZWN0aW9u IG9mIHRoZSBkb2N1bWVudCB0aGF0IHNoYXJwbHkgZGVmaW5lcyB0aGUgY2Fub25pY2FsIGZvcm1h dCBmb3IgYWxsIGRhdGEgdHlwZXMgdGhhdCBoYXZlIG11bHRpcGxlIHJlcHJlc2VudGF0aW9ucy4g VGhpcyBpcyBzcGVjaWFsbHkgY2FsbGVkIOKAnENhbm9uaWNhbCBDQk9S4oCdIGFuZCBhbnlvbmUg Y2xhaW1pbmcgdG8gaW1wbGVtZW50IGl0LCBNVVNUIGltcGxlbWVudCBhbGwgYXNwZWN0cyBvZiBp dC4gIFdlIGFsc28gaGlnaGx5IHJlY29tbWVuZGVkIHRoYXQgZXZlcnkgaW1wbGVtZW50YXRpb24g dXNlIGl0LiAgTW92ZSB0aGlzIHRvIHNlY3Rpb24gMyBzbyBpdCBpcyBub3QgaW4gdGhlIHJlY29t bWVuZGF0aW9ucyBmb3IgY3JlYXRpbmcgcHJvdG9jb2xzLg0KPiANCj4gVGhhdCB3b3VsZCBiZSB0 aGUgc2VwYXJhdGUgZG9jdW1lbnQgcHJvcG9zZWQgYWJvdmU/DQo+IA0KPj4gTGVhdmUgdGhlIHNv cnRpbmcgb3JkZXIgYW5kIHVzZSBvZiBkZWZpbml0ZSBsZW5ndGhzIHJlcXVpcmVtZW50cyBvdXQg b2YgdGhpcyBzZWN0aW9uIGJlY2F1c2UgdGhleSBhcmUgY29zdGx5IHRvIGltcGxlbWVudC4NCj4g DQo+IEVyLCBub3cgeW91IGxvc3QgbWUuDQo+IA0KPj4gIzMgUmVuYW1lIHNlY3Rpb24gNC45IHRv IHNvbWV0aGluZyBsaWtlIOKAnHJlY29tbWVuZGF0aW9ucyBmb3IgdW5pZm9ybSBDQk9S4oCdIChv ciDigJxpbnZhcmlhbnTigJ0sIG9yIOKAnGNvbnNpc3RlbnTigJ0gQ0JPUikuIFRoaXMgdGV4dCBp cyBub24tbm9ybWF0aXZlIHJlY29tbWVuZGF0aW9ucyBvbmx5LiBUaGUgc29ydGluZyBvcmRlciBj YW4gYmUgcGFydCBvZiB0aGlzLg0KPiANCj4g4oCcQ29uc2lzdGVudCBDQk9S4oCdIHNvdW5kcyBn b29kIHRvIG1lLiAgKEFzIGEgbmFtZSBmb3IgdGhlIG5ldyB2ZXJzaW9uIHdpdGggdGhlIGZpeGVk IG1hcCBzb3J0aW5nIG9yZGVy4oCmKQ0KPiANCj4+IEJhc2ljYWxseSwgdGhlIGxlc3Mgd29yayB3 ZSBsZWF2ZSB0byBDQk9SIHByb3RvY29sIGRlc2lnbmVycywgdGhlIGJldHRlci4gSXTigJlsbCBi ZSBlYXNpZXIgZm9yIHByb3RvY29sIGRlc2lnbmVycyB0byBkbyB0aGVyZSB3b3JrLCB0aGV54oCZ bGwgZ2V0IGl0IHJpZ2h0IG1vcmUgb2Z0ZW4gYW5kIHRoZXJl4oCZbGwgYmUgbGVzcyBpbnRlcm9w IHByb2JsZW1zLg0KPiANCj4gSSBjYW7igJl0IGFyZ3VlIHdpdGggdGhhdC4gIFByZW1hdHVyZWx5 IG5haWxpbmcgZG93biBkZXRhaWxzIGNhbiBhbHNvIGJlIHZlcnkgY29zdGx5LCB0aG91Z2guDQo+ IA0KPj4gTGFzdCwgSSB0aGluayB0aGUgbmFtZXMg4oCcQ2Fub25pY2FsIEVuY29kZWQgQ0JPUuKA nSBhbmQg4oCcU3RyaWN0IENCT1IgRGVjb2RpbmfigJ0gd291bGQgYmUgcmVhbGx5IGhlbHBmdWwu IA0KPiANCj4gV2l0aCB3aGF0IHNlbWFudGljcz8NCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4g DQoNCg== From nobody Mon Jun 4 22:25:15 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883AB130ECB for ; Mon, 4 Jun 2018 22:25:14 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUmearCHqiZr for ; Mon, 4 Jun 2018 22:25:12 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AAF130EC9 for ; Mon, 4 Jun 2018 22:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w555P7f0002860; Tue, 5 Jun 2018 07:25:08 +0200 (CEST) Received: from [192.168.217.102] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 410Kxv5gDBzDX2k; Tue, 5 Jun 2018 07:25:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> Date: Tue, 5 Jun 2018 07:25:06 +0200 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 549869104.87994-caa52e05fe3804d807d43be85904f822 Content-Transfer-Encoding: quoted-printable Message-Id: <7AA4B7F0-26C3-4C3D-ACCD-0CC2F6D1DFD2@tzi.org> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 05:25:15 -0000 On Jun 5, 2018, at 02:27, Laurence Lundblade = wrote: >=20 > This canonicalization seems unnecessary. Hi Laurence, we need consistent encoding (=E2=80=9Ccanonicalization=E2=80=9D) of = those structures that are *not* actually transferred. In many protocols, we construct signing inputs and other crypto = parameters from various sources. This computation is so much easier to = describe (and correctly implement!) if it uses the same encoding = machinery that we use for the data that does get transferred. The difference here is that we can carefully construct (and constrain) = these signing inputs so that consistently encoding them becomes trivial. = That=E2=80=99s what COSE did. Thank you for reminding us that RFC 8152 actually refers normatively to = Section 3.9 of RFC 7049. If we excise that from CBORbis, we need to = retain a section about consistent encoding to the level that COSE = requires it. Again, this should be trivial, but we need to do it. (It is maybe unfortunate that Section 14 of RFC 8152 addresses = =E2=80=9Cencoder restrictions=E2=80=9D for both consistent encoding and = for the need to avoid duplicate keys in maps. The latter is not a = requirement about consistent encoding =E2=80=94 COSE is careful to not = use maps in building those crypto input data structures. Duplicate keys = are bad within the actually transferred data structures as well.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 5 07:58:34 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8602F1310C6 for ; Tue, 5 Jun 2018 07:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTX7BXvwudzM for ; Tue, 5 Jun 2018 07:58:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4E71310CC for ; Tue, 5 Jun 2018 07:58:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B5A120091; Tue, 5 Jun 2018 11:11:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7B6FC2F8F; Tue, 5 Jun 2018 10:57:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 793082F86; Tue, 5 Jun 2018 10:57:54 -0400 (EDT) From: Michael Richardson To: "cbor\@ietf.org" , Laurence Lundblade In-Reply-To: <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:58:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Laurence Lundblade wrote: > Section 14 requires canonicalization for Sig_structure, Enc_structur= e, > and MAC_structure. I interpret this as requiring canonicalization for > any / all of the maps in these structures including sorting. I have a > few issues with this requirement: I'm a bit puzzled by this. Sig_structure, Enc_structure and MAC_structure are CBOR arrays, and the contents are fully specified. There aren't any choices, so I don't understand why we can talk about canonicalization? > - This canonicalization seems unnecessary. I just can=E2=80=99t see w= hat could > go wrong if you don=E2=80=99t canonicalize. Canonicalize of the paylo= ad is not > required and that works OK. It seems like COSE would be better by ju= st > deleting section 14. The restrictions of section 14 seem self-evident, but they seem to be there just to cover all our bases. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxak74CLcPvd0N1lAQJ9iQgAu5HKeH5bpe67wuSaqWh+A3i1dYDGXR8v mDZv2obgejqCFABwBin3dgZ/7uf22IdSyaDiX3N9jKoTT5yoBSVFy5CuKoSJueSC HyqabY8bZlb4Ij4YecDClTC1fxZB2ND30xSQURZTD7MZbPSITwr7o0a+RTONoMEB 1f1m4inqyzGboyRCYW3gD6lcMVsGKaNH7VioC8C+gyHQRnk1+eoVSG6E50PP2xLo rwLywl6kewfOOa1ICyH0njxjDHBXeJdEULjnFeRWDvH16NEgGb03az1HMCQ6C07H CpMc3vaIEnfpVDuCLX/YCsuk64/d/yKGdECzV2Q1fXyUe70CEtHCdg== =kvry -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 5 08:10:02 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0D91310D8 for ; Tue, 5 Jun 2018 08:10:00 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViMRvOdEoml1 for ; Tue, 5 Jun 2018 08:09:57 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FBB1310D3 for ; Tue, 5 Jun 2018 08:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w55F9snq016151; Tue, 5 Jun 2018 17:09:54 +0200 (CEST) Received: from client-0081.vpn.uni-bremen.de (client-0081.vpn.uni-bremen.de [134.102.107.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 410Zwf1P4vzDXBY; Tue, 5 Jun 2018 17:09:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <31799.1528210674@localhost> Date: Tue, 5 Jun 2018 17:09:54 +0200 Cc: "cbor@ietf.org" , Laurence Lundblade X-Mao-Original-Outgoing-Id: 549904192.3684109-8a341d2afa67da12d5722ec02be2ea60 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> <31799.1528210674@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:10:01 -0000 > On Jun 5, 2018, at 16:57, Michael Richardson = wrote: >=20 >=20 > Laurence Lundblade wrote: >> Section 14 requires canonicalization for Sig_structure, = Enc_structure, >> and MAC_structure. I interpret this as requiring canonicalization = for >> any / all of the maps in these structures including sorting. I have a >> few issues with this requirement: >=20 > I'm a bit puzzled by this. > Sig_structure, Enc_structure and MAC_structure are CBOR arrays, and = the > contents are fully specified. There aren't any choices, so I don't > understand why we can talk about canonicalization? I failed to say in my previous message https://mailarchive.ietf.org/arch/msg/cbor/EcX4hHT7yKyFsCnwUmcm6eIcH2U there is a theoretical choice between shortest (e.g., 01) and = not-so-short (e.g., 1801 or 190001) encoding of the heads of the items. There is no good reason to use not-so-short for these internal = encodings, so it really is a bit of a theoretical discussion. But it needs to be officially defined that way=E2=80=A6 >> - This canonicalization seems unnecessary. I just can=E2=80=99t see = what could >> go wrong if you don=E2=80=99t canonicalize. Canonicalize of the = payload is not >> required and that works OK. It seems like COSE would be better by = just >> deleting section 14. >=20 > The restrictions of section 14 seem self-evident, but they seem to be = there > just to cover all our bases. Pretty much so =E2=80=94 that=E2=80=99s how the encoding of the = structures was chosen. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 5 08:38:10 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20B91310F2 for ; Tue, 5 Jun 2018 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEDV2I0ML7ha for ; Tue, 5 Jun 2018 08:38:06 -0700 (PDT) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55DE1310DD for ; Tue, 5 Jun 2018 08:38:05 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 08:38:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,479,1520924400"; d="scan'208";a="54938754" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by FMSMGA003.fm.intel.com with ESMTP; 05 Jun 2018 08:38:04 -0700 Received: from tjmaciei-mobl1.localnet (10.254.185.146) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Jun 2018 08:38:04 -0700 From: Thiago Macieira To: Date: Tue, 5 Jun 2018 08:38:03 -0700 Message-ID: <3922109.8YJUi6FOoO@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <31799.1528210674@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.254.185.146] Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:38:08 -0000 On Tuesday, 5 June 2018 08:09:54 PDT Carsten Bormann wrote: > https://mailarchive.ietf.org/arch/msg/cbor/EcX4hHT7yKyFsCnwUmcm6eIcH2U > there is a theoretical choice between shortest (e.g., 01) and not-so-short > (e.g., 1801 or 190001) encoding of the heads of the items. There is no go= od > reason to use not-so-short for these internal encodings, so it really is a > bit of a theoretical discussion. But it needs to be officially defined th= at > way=E2=80=A6 Actually, there is. This was exactly the stumbling block I had when attempt= ing=20 to implement COSE with a single-pass zero-allocation solution for constrain= ed=20 systems. Long story short: I failed and abandoned the project. One of my attempted solutions was to reserve 5 or 9 bytes (32- or 64-bit) f= or=20 size of the Byte String containing the payload, so the contents could be=20 stored elsewhere while calculating the cryptographic data. The idea was to = use=20 something like struct iovec[3], where the CBOR data would be split into thr= ee=20 parts: what came before the crypto data and including the data size, the=20 crypto data, then what came after. The requirement to have canonical encoding would have forced me to go back = to=20 the byte stream and re-encode the length, which in turn changed the length = of=20 the "pre" block. PS: since I didn't complete the project, I can't say whether there were=20 further problems or solutions I didn't think of. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Tue Jun 5 08:56:27 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC6613112C for ; Tue, 5 Jun 2018 08:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OKUkgnGvaw1 for ; Tue, 5 Jun 2018 08:56:17 -0700 (PDT) Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7830131127 for ; Tue, 5 Jun 2018 08:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1528214175; x=1559750175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Mc2gjYITL3jY4/FdfBQRd0SzdWGvMgElYSYKpk+3Dgc=; b=L+y39bnNukK98voNmnNhEobeASRTqDetgINKintfDHS/CxFRvw5SadQ7 5baZHD1bpGgo1L/3HJxtONIoBhEVGxn9+GIiNZCnj8Y4uPdRR4IHs+oIO ftyY2UOiT7BsBJUPnJ1MjuC06TB26aItf+ukAdJDnF55LkdhUUxEwsOg9 Y=; Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-01.qualcomm.com with ESMTP; 05 Jun 2018 08:56:15 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8914"; a="102932109" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 05 Jun 2018 08:56:15 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 5 Jun 2018 08:56:14 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Tue, 5 Jun 2018 08:56:14 -0700 From: Laurence Lundblade To: Carsten Bormann CC: "cbor@ietf.org" Thread-Topic: [Cbor] Canonical CBOR Thread-Index: AQHT+DAtw9B4IAE4bU+ppwSV0kSEKKRJGMsAgAg0MoCAAFMbAIAAsFqA Date: Tue, 5 Jun 2018 15:56:14 +0000 Message-ID: <8FB777CE-CF4E-40E1-82DC-E3A3DAECAB89@qti.qualcomm.com> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> <7AA4B7F0-26C3-4C3D-ACCD-0CC2F6D1DFD2@tzi.org> In-Reply-To: <7AA4B7F0-26C3-4C3D-ACCD-0CC2F6D1DFD2@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="utf-8" Content-ID: <268B17DF47BC554D92A276E40054A023@qualcomm.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:56:26 -0000 T24gSnVuIDQsIDIwMTgsIGF0IDEwOjI1IFBNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9y Zz4gd3JvdGU6DQo+IA0KPiBPbiBKdW4gNSwgMjAxOCwgYXQgMDI6MjcsIExhdXJlbmNlIEx1bmRi bGFkZSA8bGx1bmRibGFAcXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQo+PiANCj4+IFRoaXMgY2Fu b25pY2FsaXphdGlvbiBzZWVtcyB1bm5lY2Vzc2FyeS4NCj4gDQo+IEhpIExhdXJlbmNlLA0KPiAN Cj4gd2UgbmVlZCBjb25zaXN0ZW50IGVuY29kaW5nICjigJxjYW5vbmljYWxpemF0aW9u4oCdKSBv ZiB0aG9zZSBzdHJ1Y3R1cmVzIHRoYXQgYXJlICpub3QqIGFjdHVhbGx5IHRyYW5zZmVycmVkLg0K DQpBaGhoLCB0aGF04oCZcyB3aGF0IEkgd2FzIG1pc3NpbmcuIFRoYW5rcyBmb3IgeW91ciBwYXRp ZW5jZS4NCg0KTEwNCg0K From nobody Tue Jun 5 11:10:30 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D112F1A6 for ; Tue, 5 Jun 2018 11:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJEewRgQdvQW for ; Tue, 5 Jun 2018 11:10:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52E0126F72 for ; Tue, 5 Jun 2018 11:10:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C9CD520091; Tue, 5 Jun 2018 14:23:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 519552F8F; Tue, 5 Jun 2018 14:09:51 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4E8212F86; Tue, 5 Jun 2018 14:09:51 -0400 (EDT) From: Michael Richardson To: Thiago Macieira cc: cbor@ietf.org In-Reply-To: <3922109.8YJUi6FOoO@tjmaciei-mobl1> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <31799.1528210674@localhost> <3922109.8YJUi6FOoO@tjmaciei-mobl1> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:10:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thiago Macieira wrote: > On Tuesday, 5 June 2018 08:09:54 PDT Carsten Bormann wrote: >> https://mailarchive.ietf.org/arch/msg/cbor/EcX4hHT7yKyFsCnwUmcm6eIcH= 2U >> there is a theoretical choice between shortest (e.g., 01) and not-so= -short >> (e.g., 1801 or 190001) encoding of the heads of the items. There is = no good >> reason to use not-so-short for these internal encodings, so it reall= y is a >> bit of a theoretical discussion. But it needs to be officially defin= ed that >> way=E2=80=A6 > Actually, there is. This was exactly the stumbling block I had when a= ttempting=20 > to implement COSE with a single-pass zero-allocation solution for con= strained=20 > systems. Long story short: I failed and abandoned the project. oh. > One of my attempted solutions was to reserve 5 or 9 bytes (32- or 64-= bit) for=20 > size of the Byte String containing the payload, so the contents could= be=20 > stored elsewhere while calculating the cryptographic data. The idea w= as to use=20 > something like struct iovec[3], where the CBOR data would be split in= to three=20 > parts: what came before the crypto data and including the data size, = the=20 > crypto data, then what came after. > The requirement to have canonical encoding would have forced me to go= back to=20 > the byte stream and re-encode the length, which in turn changed the l= ength of=20 > the "pre" block. I see the problem that you had... It seems that the goal wasn't just single-pass (you didn't have to revisit the payload!), but being able to stream-write the data out, and not have to buffer it all in memory before sending. This would also make it easier to do things like take some of the content from ROM. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxbR64CLcPvd0N1lAQIOTQgAqH3y2XZEdm1p0s1VHVU5cl/A0HO4qFKV UEVP1qUYIs8AS4BpuW0if1SGT5QIYMy75pRpuY7oS8CwAei4VS0F+xgmq6+mSGix WBQCoxgVYJpXJ5kKe73hDFqvsyqushNHkz/eI8LRoD9SJsZWr2vzSwoVtZ4e9716 Vgw/IGU07o0j2UTJgBP3YCU+iXpQZKz969rLtI7DmDH2Ktv4hN/7l4j/flmXbTsz ZEfTHoJy6+VJTu6wQnP8p7pzJzdll3f08Hh53HZM2+JtM7Iq/Ds9/wC9SsZyw1IQ Fs37AQF3XSNviVR1+YGaDXkLZGSJJW1TMinRxhVitLzaKkWarS1VxQ== =ZjIh -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 5 11:29:48 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F646130934 for ; Tue, 5 Jun 2018 11:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFTQJURzhmv6 for ; Tue, 5 Jun 2018 11:29:45 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1D3131137 for ; Tue, 5 Jun 2018 11:29:45 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 11:29:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,479,1520924400"; d="scan'208";a="205559254" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga004.jf.intel.com with ESMTP; 05 Jun 2018 11:29:44 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.67) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Jun 2018 11:29:44 -0700 From: Thiago Macieira To: Michael Richardson CC: Date: Tue, 5 Jun 2018 11:29:43 -0700 Message-ID: <3942334.DbnG8l7WTc@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <10511.1528222191@localhost> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <3922109.8YJUi6FOoO@tjmaciei-mobl1> <10511.1528222191@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.67] Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:29:47 -0000 On Tuesday, 5 June 2018 11:09:51 PDT Michael Richardson wrote: > It seems that the goal wasn't just single-pass (you didn't have to revisit > the payload!), but being able to stream-write the data out, and not have to > buffer it all in memory before sending. This would also make it easier to > do things like take some of the content from ROM. Yes, and it was very difficult to do stream-writing too, another reason for my abandoning the project. The structures that are found in the COSE payload are similar to but still different from the structures used as additional data for the cryptographic routines. I could not find a way to perform this with zero-allocation streaming. I don't know if a different protocol design could have done it, but that was clearly not a goal for COSE. So I gave up adding support for it in TinyCBOR. It's now left for a higher layer to implement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Tue Jun 5 12:02:14 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852BE13115E for ; Tue, 5 Jun 2018 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJZBoQI-VNZu for ; Tue, 5 Jun 2018 12:02:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5498C131152 for ; Tue, 5 Jun 2018 12:01:59 -0700 (PDT) Received: from Jude (216.53.143.123) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 5 Jun 2018 11:58:54 -0700 From: Jim Schaad To: 'Laurence Lundblade' , 'Carsten Bormann' CC: References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> In-Reply-To: <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> Date: Tue, 5 Jun 2018 15:01:40 -0400 Message-ID: <00c901d3fcff$a5120d00$ef362700$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGllD7+yObJ82UzPxgPlgWMyXmPEQNF1t1+AtnxHYOkfdYUkA== Content-Language: en-us X-Originating-IP: [216.53.143.123] Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:02:12 -0000 > -----Original Message----- > From: CBOR On Behalf Of Laurence Lundblade > Sent: Monday, June 4, 2018 8:28 PM > To: Carsten Bormann > Cc: cbor@ietf.org > Subject: Re: [Cbor] Canonical CBOR >=20 > So I=E2=80=99ve had some think time on this. >=20 > Rather than asking about implementations, I should have asked about = CBOR- > based protocol designs that need or benefit from canonicalization. = I=E2=80=99m > familiar with CWT and COSE so let=E2=80=99s see about canonicalization = in them. >=20 > CWT doesn=E2=80=99t require canonicalization and that all seems fine. = The main > benefit I can see canonicalization bringing is the testing benefit = that you > mention. For the same set of input claims, you can binary compare the > output of two implementations and know they match (at least that is = the > testing benefit I think you are mentioning). My feeling is that = requiring > canonicalization for CWT for this reason would not be a good design = trade- > off. >=20 > COSE on the other hand does require canonicalization in some places = and > (maybe) not in others. >=20 > Section 3 says that protected headers are bstr wrapped so they = don=E2=80=99t have to > be canonicalized. >=20 > Section 14 requires canonicalization for Sig_structure, = Enc_structure, and > MAC_structure. I interpret this as requiring canonicalization for any = / all of > the maps in these structures including sorting. I have a few issues = with this > requirement: There are no maps in these structures so there is no requirement for = sorting of maps anyplace in the document. >=20 > - This seems at odds with the statement Section 3 especially as the = protected > parts of these structures are bstr wrapped. >=20 > - This canonicalization seems unnecessary. I just can=E2=80=99t see = what could go > wrong if you don=E2=80=99t canonicalize. Canonicalize of the payload = is not required > and that works OK. It seems like COSE would be better by just = deleting > section 14. Parts of these structures are not transmitted on the wire and thus doing = a bstr wrapping is not helpful to think in terms of it being = transmitted. The canonization done for COSE is very limited. It looks a arrays, text = strings (of a set of well-known constants) and binary strings. Doing = canonicalization on this set of things is not only easy but not = controversial. There is a re-iteration of don't do duplicate headers = which is a general problem and is stated several times. >=20 > It feels like maybe this was put in when there was some thinking that > canonicalization was good for signing, but now that turned out not to = be > true? Pardon if I=E2=80=99m dense and missing something. However, I = really am trying > to be constructive. >=20 >=20 > To go a bit further, it=E2=80=99s the sorting for the purpose of = duplicate detection that > really bothers me because the cost of implementation of that can be a = bit > high. It might require sorting variable length chunks of memory in RAM = (by > comparison, the smallest-possible length / int encoding is not = difficult to > implement). >=20 > You can do duplicate detection on the COSE headers efficiently even if = the > input is not sorted. When initialize the key, IV and other header vars = to > empty. If you try to set one that is not empty you can error out. I = think > maybe sorting while encoding might be more complex than doing = duplicate > detection on an unsorted map during decoding. >=20 > LL >=20 >=20 >=20 >=20 >=20 > > On May 30, 2018, at 12:10 PM, Carsten Bormann wrote: > > > > Hi Laurence, > > > > thank you for bringing this subject up again. > > > > In 2013, we knew what we were up to when we wrote the original = section > 3.9 of RFC 7049. > > Essentially, canonicalization (14n) is a mine field where the only = way to win > is to not play. > > > > However, we got a few things right, I think: > > > > (1) we acknowledged that c14n is to a certain extent = application-specific. > So the RFC gives some guidance, but does not define a single hard and = fast > set of rules. > > > > (2) the serialization provides little intrinsic incentive for = gratuitous variation. > Apart from definite vs. indefinite lengths (which is an example of = something > that depends on application requirements), the obvious rule to use the > shortest of several possible encodings is natural and easy to = implement. > [One design alternative, to only ever allow the shortest encoding, is > problematic for some other applications.] Implementations already do = this > naturally (except sometimes for floating point =E2=80=94 implementers = of > serialization layers often know little about floating point and are = rightfully > scared by it. That=E2=80=99s why we have the example code in the = appendix=E2=80=A6 and it is > easy to do exhaustive testing at least for binary16!). > > > > We also got one thing extremely wrong: > > > > (A) the canonical ordering for keys based on lengths first, then = byte-wise > lexicographical order, is violating the principle of least surprise = and poses > some performance disadvantages. This probably should be fixed to pure > byte-wise lexicographical order. Applications that already have = decided to > use the existing map order guidance can do that by invoking (1) above. > > > > > > So what are the use cases? Signing information expressed at the = data > model level is often given as one, but it is not very convincing. = What I > consider much more interesting is to be able to do byte-wise = comparison of > instances to establish a certain degree of data model level > equality/inequality. This is really useful for testing and for = matching > information in a database. > > > > Several of the 50 implementations of CBOR listed at cbor.io do some = form > of c14n, sometimes as an add-on. (E.g., for cbor-ruby, there is a = separate > gem cbor-canonical that provides canonical encoding. There is no = decode > checker =E2=80=94 you check by canonical-encoding again and then doing = a bytewise > comparison.) I never got around to collecting feature lists for the > implementations on cbor.io, so I don=E2=80=99t know how many of them = do canonical. > > > > > > We discussed c14n in some detail at IETF 101. > > Please search for =E2=80=9Cc14n=E2=80=9D in: > > = https://datatracker.ietf.org/meeting/101/materials/minutes-101-cbor-00 > > and read up to =E2=80=9Cimplementation matrix=E2=80=9D. > > > > While we didn=E2=80=99t make a final determination at the meeting, = it seems to me > that the best way forward is to keep c14n at the =E2=80=9Cproposed = standard=E2=80=9D level, > by splitting it out to a separate document, while the rest of CBOR = goes to > Internet Standard. This also reflects the lower levels of = implementation > experience we have with c14n, and the desire to fix the map order. > > > >> Here=E2=80=99s a few ideas for what to do: > >> > >> #1 Require all integers and lengths to always be in shortest form = and > always the same. > > > > We already do this for c14n. (Do you mean to always require this? = Not so > sure about that.) > > > >> Do the same for floating point, > > > > (But only weakly so for floating point.) > > > >> dates and as many other of the types defined in the spec as = possible. > > > > These often have way more application semantics than you can handle = in a > generic canonicalizer. > > Try canonicalizing URIs, Regexps, etc. Do you canonicalize RFC 3339 = dates > to UTC? > > I think we have to be open about the limitations of what can be done = here. > > > >> For a lot of data types, this is not that hard to implement and it = eliminates > a variability in the spec that seems unnecessary. Then you = don=E2=80=99t have to > define a canonical format for these types. They are always canonical. > > > > I sure like that approach. > > > >> #2 If not #1, then make a clear subsection of the document that = sharply > defines the canonical format for all data types that have multiple > representations. This is specially called =E2=80=9CCanonical = CBOR=E2=80=9D and anyone claiming > to implement it, MUST implement all aspects of it. We also highly > recommended that every implementation use it. Move this to section 3 = so it > is not in the recommendations for creating protocols. > > > > That would be the separate document proposed above? > > > >> Leave the sorting order and use of definite lengths requirements = out of > this section because they are costly to implement. > > > > Er, now you lost me. > > > >> #3 Rename section 4.9 to something like =E2=80=9Crecommendations = for uniform > CBOR=E2=80=9D (or =E2=80=9Cinvariant=E2=80=9D, or = =E2=80=9Cconsistent=E2=80=9D CBOR). This text is non-normative > recommendations only. The sorting order can be part of this. > > > > =E2=80=9CConsistent CBOR=E2=80=9D sounds good to me. (As a name for = the new version > with the fixed map sorting order=E2=80=A6) > > > >> Basically, the less work we leave to CBOR protocol designers, the = better. > It=E2=80=99ll be easier for protocol designers to do there work, = they=E2=80=99ll get it right more > often and there=E2=80=99ll be less interop problems. > > > > I can=E2=80=99t argue with that. Prematurely nailing down details = can also be very > costly, though. > > > >> Last, I think the names =E2=80=9CCanonical Encoded CBOR=E2=80=9D = and =E2=80=9CStrict CBOR > Decoding=E2=80=9D would be really helpful. > > > > With what semantics? > > > > Gr=C3=BC=C3=9Fe, Carsten > > >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jun 5 12:04:01 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C64130DC1 for ; Tue, 5 Jun 2018 12:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw-HjHTX-Ghq for ; Tue, 5 Jun 2018 12:03:57 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E505113114D for ; Tue, 5 Jun 2018 12:03:56 -0700 (PDT) Received: from Jude (216.53.143.123) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 5 Jun 2018 12:00:59 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Laurence Lundblade' CC: References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com> <7AA4B7F0-26C3-4C3D-ACCD-0CC2F6D1DFD2@tzi.org> In-Reply-To: <7AA4B7F0-26C3-4C3D-ACCD-0CC2F6D1DFD2@tzi.org> Date: Tue, 5 Jun 2018 15:03:46 -0400 Message-ID: <00de01d3fcff$efabf380$cf03da80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGllD7+yObJ82UzPxgPlgWMyXmPEQNF1t1+AtnxHYMBNeS2AKR0KZTA Content-Language: en-us X-Originating-IP: [216.53.143.123] Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:04:00 -0000 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Tuesday, June 5, 2018 1:25 AM > To: Laurence Lundblade > Cc: cbor@ietf.org > Subject: Re: [Cbor] Canonical CBOR >=20 > On Jun 5, 2018, at 02:27, Laurence Lundblade = > wrote: > > > > This canonicalization seems unnecessary. >=20 > Hi Laurence, >=20 > we need consistent encoding (=E2=80=9Ccanonicalization=E2=80=9D) of = those structures that are > *not* actually transferred. >=20 > In many protocols, we construct signing inputs and other crypto = parameters > from various sources. This computation is so much easier to describe = (and > correctly implement!) if it uses the same encoding machinery that we = use for > the data that does get transferred. >=20 > The difference here is that we can carefully construct (and constrain) = these > signing inputs so that consistently encoding them becomes trivial. = That=E2=80=99s > what COSE did. >=20 > Thank you for reminding us that RFC 8152 actually refers normatively = to > Section 3.9 of RFC 7049. If we excise that from CBORbis, we need to = retain a > section about consistent encoding to the level that COSE requires it. = Again, > this should be trivial, but we need to do it. For the level of canonization that is required by RFC 8152, it matters = not which canonical encoding is referred to and could be cut into a = revision of that document in the future if really needed. Jim >=20 > (It is maybe unfortunate that Section 14 of RFC 8152 addresses = =E2=80=9Cencoder > restrictions=E2=80=9D for both consistent encoding and for the need to = avoid duplicate > keys in maps. The latter is not a requirement about consistent = encoding =E2=80=94 > COSE is careful to not use maps in building those crypto input data = structures. > Duplicate keys are bad within the actually transferred data structures = as > well.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jun 5 19:26:28 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF13130E2D for ; Tue, 5 Jun 2018 19:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElVp0pRuw1sN for ; Tue, 5 Jun 2018 19:26:25 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003105.outbound.protection.outlook.com [40.92.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7384130E2B for ; Tue, 5 Jun 2018 19:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GY6fcZBweH6KvOdg498dGieb21YJQ1ZPankiCO5RG6c=; b=Z0fW4SUl8o59ofh+2Iytm577yrwSTn6ZNxani/xfJ41n73szK3kpDEJYyRHhCCiZ6VK5x4pIUP1XpK1CAr756UL7axCely9Ft3gGAntK3TLu30DKb86fP+gKEVR1vDXmBeJZxrmLiglfjJra+lGSI1JtzNNVttbujoHQeC2EX9bnwrvCeS3baBV8KtD8j3JnU4rknjnZtU1/ERKO5pM4cnwDI4SK/+O1dR9vyEBwCqHAca5k9o5E5KmMnPLD2r19/xqgBKI/2O9dUQYuaqvopWQt26rnWW+XdAo/vX3IYZo4Vk9mAGbI16sGPCN7gmLWq+fql34zhSix/ZhDdMuXSQ== Received: from SN1NAM02FT063.eop-nam02.prod.protection.outlook.com (10.152.72.52) by SN1NAM02HT177.eop-nam02.prod.protection.outlook.com (10.152.73.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10; Wed, 6 Jun 2018 02:26:22 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.72.55) by SN1NAM02FT063.mail.protection.outlook.com (10.152.72.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.841.10 via Frontend Transport; Wed, 6 Jun 2018 02:26:22 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::9c0c:a628:dc3e:585a]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::9c0c:a628:dc3e:585a%5]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 02:26:22 +0000 From: Burt Harris To: "cbor@ietf.org" CC: Carsten Bormann Thread-Topic: [Cbor] Canonical CBOR Thread-Index: AdP9L7DlyMlprJTkT1K1mD44RdGBAQ== Date: Wed, 6 Jun 2018 02:26:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:0B3A802487C0157E99471193E3CAC25FD78361E692E4BB1CDFFCD22479BB9C9C; UpperCasedChecksum:7CE28E4769060E481DA9F5F2031CF87C0A52DB8A56FCF8E29D1D6B8809261A0A; SizeAsReceived:6804; Count:44 x-tmn: [hkeNhHKBsqNqYsOeriqyw5RBjNspmiF7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT177; 7:Hsue6X1EEZdpAgsOKttL+dztzitF6hxKRf/hnWAljPYUQ/SAyqlyE/hTS8Sy47n7wN0UVNv5uPbRqE+q4jgFiTmln5Ikvt8QhhZkME8Xtowr+gsqngvXELyzIrK1T23j04gxuv5NThF553/v3vp4ZX7+tToSbk0tqRd7UTh8OewlzpvDtceIcaK6lgOlSR789dKKLh3PiPOrY7YxRT8bYkEIH/7zTcdEzWNRQOe3LK1CR5lAY1swHPDNBp9/8Oo4 x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101448)(1701031045); SRVR:SN1NAM02HT177; x-ms-traffictypediagnostic: SN1NAM02HT177: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM02HT177; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT177; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(82202002)(6306002)(6436002)(25786009)(8936002)(4326008)(97736004)(229853002)(20460500001)(87572001)(2900100001)(3280700002)(3660700001)(6506007)(59450400001)(99286004)(486006)(7696005)(305945005)(2501003)(5250100002)(74316002)(73972006)(83332001)(26005)(6346003)(102836004)(2351001)(8676002)(68736007)(81156014)(86362001)(1730700003)(6246003)(104016004)(106356001)(105586002)(9686003)(476003)(45080400002)(33656002)(55016002)(5640700003)(5660300001)(6916009)(14454004)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT177; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: KW+xKU45dgeU/ZJSOJNJhNj1N19zr1hO/y6W9J3PlBD891JoN5CTfArMu2u3kIJz8c909V+Mr7BlZnWXsFXVckx7wEHhQv6rnBcIM8iAqHgAaFWtZ2+jiegZYRAIaee1B2PZszFefj0PwHBHOhK6gyMGIdWcOj6kH6NwPki96CuNZ3kiRcqujIYFt3IuGtJn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bfb0dafb-9c5e-4a90-41d8-08d5cb54e55f X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: bfb0dafb-9c5e-4a90-41d8-08d5cb54e55f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 02:26:22.8084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT177 Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 02:26:27 -0000 Other than one of two crypto-related protocols Carsten mentioned, I'm unawa= re of any protocol requiring canonical CBOR. While don't disagree that ex= amining existing CBOR based designs is appropriate, I think they are few en= ough to be insufficient today, and crypto is itself a special case, one of = the few that seem like the _might_ benefit from some standard form for func= tional reasons But where is that true? =20 Looking outside the CBOR scope, consider Unicode. There are multiple ways= to represent letters with accents. Being a native English speaker, it ha= s only been a curiosity for me, but let's look how Unicode deals with the m= atter, as described in [TR 15](http://www.unicode.org/reports/tr15/.) The= TR describes not one, but several "Unicode normalization forms."=20 This permits applications and protocols above the presentation level to cho= ose to implement normalization convention using standardized terminology, w= ithout dictating a single standard. RFC-7049 canonicalization can remain = a thing long after we publish CBOR bis, CBOR tre, etc. The original RFC i= s forever, and references to it don't change because we might rethink somet= hing, and implementations are free to implement an normalization option-sel= ection mechanism if its important to the implementor. But this is entirely different from UTF-8's saying that overlong encodings = are forbidden (which is similar to RFC-7049's rule for canonicalizing integ= ers.) Both are not opinionated, they eliminate only something that is less = efficient. Similarly, all the UTF-* encodings forbid unpaired surrogate c= ode points, which used to be perfectly legal in UCS-2 (UTF-16's predecessor= ). So is "compatability" a strong argument for blocking progress? I don= 't think so. Window-32 was widely deployed, supported UCS-2 rather than = UTF-16, and Microsoft adapted. (I should know, I worked there.) =20 But what is really interesting is section 11.1 of Unicode TR 15. It says: > 11.1 Stability of Normalized Forms >=20 > For all versions, even prior to Unicode 4.1, the following policy is foll= owed: > A normalized string is guaranteed to be stable; that is, once normalized,= a string is normalized=20 > according to all future versions of Unicode. >=20 > More precisely, if a string has been normalized according to a particular= version=20 > of Unicode and contains only characters allocated in that version, it wil= l qualify as=20 > normalized according to any future version of Unicode. The policy is reasonable, but there is more than one way to achieve it. Ap= plying this to CBOR for example, Since RFC-7049 specified a somewhat surpri= sing map serialization order, one way would be to stay stuck on that order,= but no I don't think that's a good solution at all. To see the other app= roach I suggest we need substitute "map" (or better yet "object") in each = place where the above policy says "string". So if the default rule is "pr= eserve the serialized order of maps" rather than "sort maps to normalize th= em", any existing serialized map stays normal in whatever normalization was= applied at the time the map was created. We don't have to preserve the = old=20 normalization if the map is modified, that's a higher-level concern, at the= application (semantic) protocol layer rather than at the presentation (syn= tax) layer. Without layered protocols, we get stuck in a quagmire of=20 unseparated concerns. =20 It seems quite clear to me that CBOR the spec is a presentation layer proto= col, just like character encodings and graphics formats. A CBOR implementa= tion however may have a mixture of presentation layer and application layer= concerns, but that does NOT mean that every implementation should behave t= he same when implementing application-level concern like canonicalization. = The fact that a particular implementation r CBOR-titled presentation laye= r RFC was opinionated about application-level concerns does not justify mix= ing of concerns, it illustrates why efforts should be made to separate them= . When people argue for canonicalization by saying that that testing by bina= ry comparison of serialization output is a reason for canonicalization anot= her implementation are totally unconvincing to me. There are alternative= s to binary comparison on virtually every platform I've looked at recently,= typically called deep comparison or deep-equal. That solves the comparis= on problem at the application level rather than the serialization level. JavaScript for example applies extreme simplicity for it's built-in compari= son of maps (objects): > Comparing x =3D=3D=3D y, where x and y are values, return true or false. = Comparing=20 > x =3D=3D=3D y, where x and y are objects, returns true if x and y refer t= o the same object.=20 > Otherwise, returns false even if the objects appear identical. Deep compare is simply a normal function that defines a different way of co= mparing objects. By making this an application concern, rather than buildi= ng it into the language, JavaScript allows other ways that might (for examp= le) ignore Unicode canonicalization (expensive) or assume some specific can= onicalized rule when comparing strings, or use case insensitive string comp= arisons. There are two special case where JavaScript defines something other than th= e "leave it in the order you found it" rule: 0. Sparse arrays. Any object can be a sparse array in JavaScript. The in= dex values for sparse arrays are limited to non-negative integers, just lik= e normal arrays. So non-negative integers sort to the beginning in ascend= ing order. Negative integers are not allowed as sparse array indexes, so = they are treated as strings. If you think of object as a hash table, this= does not make a lot of sense.=20 1. Normal objects (strings as keys). Generally kept in the order they w= ere added. Once, a long time ago there could be a glitch in order if you = used the JavaScript delete as a command, but that's a legacy holdover now, = all modern JavaScript fixes this. =20 2. Instances of the Symbol class. The reason Symbol keys are sorted last= is that they represent private information, information that should NOT be= converted in serialization. A serializer or reserialize should typically= skip past all other symbol keys and wrap-up the job. (Symbols didn't exi= st in earlier versions of JavaScript, so putting them last in key sort orde= r makes sense. So, if we can get over CBOR calling CBOR maps "maps", and deal with the rea= lity that CBOR maps always have some order when serialized, it might make s= ense now why I think we should allow (not require) that maps carry an order= , but say that applications SHOULD NOT compare values based on that key ord= er. By saying that the presentation layer SHOULD preserve key order, we e= nable using it as an optimization to handle special cases like sparse array= s. Sorry if this contains typos or seems disorganized. I'm very tired for u= nrelated reasons. From nobody Tue Jun 5 19:58:38 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D929130E3A for ; Tue, 5 Jun 2018 19:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uwC_tRxaCk1 for ; Tue, 5 Jun 2018 19:58:32 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-oln040092006049.outbound.protection.outlook.com [40.92.6.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A8D130E37 for ; Tue, 5 Jun 2018 19:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JHvpoaGSr4NJYAMrZkZbHxO1yws1jG/s1JWzDmJCYNE=; b=qbylCIhqgjmtfC9lhXuqBVrjKaaPkq2RDLc99pdYO1j/OvcAdS+6Dr2SqG+4f8DRfzzjkD/6KzI7deW8ksEbPVrIHmOPjYPSqMQeh4wk/6Q+XNRyejk3B4+NbPNWJ1+NS6/KJbwAG2dTZFTnO9xTt+vADSonyjBj/mQwiA76UBAU6j9bRW/MmtS8uRnBYZT6FA0g78eVw19DFHRjgt+rUU0toIy8cPkC9uvP/w0GKy/rm/nLcAZE8q/stYMUMpzMlwm6kvbSNlrIgdwhkdWJ4XZcEJQz3HAIfb/jz489SvW8uTKkuQPt04n6zDmy3+VYt897+hEjPqT7xP1s6S72pg== Received: from BY2NAM03FT024.eop-NAM03.prod.protection.outlook.com (10.152.84.54) by BY2NAM03HT200.eop-NAM03.prod.protection.outlook.com (10.152.85.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10; Wed, 6 Jun 2018 02:58:31 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.84.60) by BY2NAM03FT024.mail.protection.outlook.com (10.152.84.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10 via Frontend Transport; Wed, 6 Jun 2018 02:58:31 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::9c0c:a628:dc3e:585a]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::9c0c:a628:dc3e:585a%5]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 02:58:31 +0000 From: Burt Harris To: "cbor@ietf.org" CC: Carsten Bormann Thread-Topic: [Cbor] Canonical CBOR Thread-Index: AdP9L7DlyMlprJTkT1K1mD44RdGBAQAEFytQ Date: Wed, 6 Jun 2018 02:58:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:8B416E4E00154DD650D777A8A46EABF312E72B1F168CBD660F403375C9F893E9; UpperCasedChecksum:6FBD14B62EE525D130BB308381AD4C018758389BEAB6DB9C69F0D966F2563FF4; SizeAsReceived:7004; Count:46 x-tmn: [6L1AfRlzAhnaS6lJv511ym7cGFNIcKCh] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM03HT200; 7:7m89NrSj/w/J4LXsjFjCLW5V6zySJGuR8nVkFLk0Xp4/W9Wiw7RsRPko3K3M3OrDfyIp3l0ScaHcuK8rc+LL+cmh9gOW/RxBlQv9XXcOaO3YRZCnierzzbKW6WAqxlXKZ7zmvNHEke7HcjS7ntd5Y910iSJSFOyRjh8aecU7ZxhAJrGrhoYmPdvk70bTIIowEIT1nE8pqTE9RanUerArWy4QnnOTtAMeveqBTRln3oBKaHbuUVNrNjFlhPZuNfpF x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:BY2NAM03HT200; x-ms-traffictypediagnostic: BY2NAM03HT200: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM03HT200; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM03HT200; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(13464003)(199004)(189003)(59450400001)(53546011)(1730700003)(73972006)(6506007)(6346003)(102836004)(74316002)(55016002)(26005)(229853002)(20460500001)(5640700003)(81156014)(8936002)(104016004)(5660300001)(14454004)(83332001)(86362001)(106356001)(5250100002)(76176011)(6436002)(82202002)(7696005)(6306002)(305945005)(2501003)(6916009)(105586002)(2351001)(446003)(68736007)(33656002)(25786009)(476003)(2940100002)(4326008)(486006)(99286004)(11346002)(87572001)(45080400002)(97736004)(8676002)(6246003)(9686003)(3280700002)(2900100001)(3660700001)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM03HT200; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: 3yZIHmN5WezbP94WSHelb+VuQply1N32c2LrhXroj3Uen334FTkdGul/9NOtPGeOHpJk6UaqAtncVnSG8hXVpCCCtLmrOYN6Q7tjTnMQLygrXz0vtQXArjI9zxFpBW4MszH7zLZur8YEkKkbGs5bGMEKPaTg8lC6HgLhYAb++u3Dxy+y6SF3ou9AfSJkvHlp Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a818d87b-99d3-4ba2-b2d4-08d5cb5962ae X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: a818d87b-99d3-4ba2-b2d4-08d5cb5962ae X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 02:58:31.0156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT200 Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 02:58:35 -0000 The other design example to consider as an anti-pattern is of course ASN-1.= Of all the different "encoding rules", about half are complications add= ed by trying to force canonical into the rules and failing to separate conc= erns of encoding from canonicalization. That turned into a mess, with a = lack of interoperability in some if not many cases. I gave up on ASN-1 du= e more than when I realized how much energy was being put into designing "e= ncoding rules" based on guess and opinion rather than focus on clarity of o= ne easily described and implemented encoding. Enough said (I hope.) -----Original Message----- From: Burt Harris=20 Sent: Tuesday, June 5, 2018 7:26 PM To: cbor@ietf.org Cc: 'Carsten Bormann' Subject: Re: [Cbor] Canonical CBOR Other than one of two crypto-related protocols Carsten mentioned, I'm unawa= re of any protocol requiring canonical CBOR. While don't disagree that ex= amining existing CBOR based designs is appropriate, I think they are few en= ough to be insufficient today, and crypto is itself a special case, one of = the few that seem like the _might_ benefit from some standard form for func= tional reasons But where is that true? =20 Looking outside the CBOR scope, consider Unicode. There are multiple ways= to represent letters with accents. Being a native English speaker, it ha= s only been a curiosity for me, but let's look how Unicode deals with the m= atter, as described in [TR 15](http://www.unicode.org/reports/tr15/.) The= TR describes not one, but several "Unicode normalization forms."=20 This permits applications and protocols above the presentation level to cho= ose to implement normalization convention using standardized terminology, w= ithout dictating a single standard. RFC-7049 canonicalization can remain = a thing long after we publish CBOR bis, CBOR tre, etc. The original RFC i= s forever, and references to it don't change because we might rethink somet= hing, and implementations are free to implement an normalization option-sel= ection mechanism if its important to the implementor. But this is entirely different from UTF-8's saying that overlong encodings = are forbidden (which is similar to RFC-7049's rule for canonicalizing integ= ers.) Both are not opinionated, they eliminate only something that is less = efficient. Similarly, all the UTF-* encodings forbid unpaired surrogate c= ode points, which used to be perfectly legal in UCS-2 (UTF-16's predecessor= ). So is "compatability" a strong argument for blocking progress? I don= 't think so. Window-32 was widely deployed, supported UCS-2 rather than = UTF-16, and Microsoft adapted. (I should know, I worked there.) =20 But what is really interesting is section 11.1 of Unicode TR 15. It says: > 11.1 Stability of Normalized Forms >=20 > For all versions, even prior to Unicode 4.1, the following policy is foll= owed: > A normalized string is guaranteed to be stable; that is, once=20 > normalized, a string is normalized according to all future versions of Un= icode. >=20 > More precisely, if a string has been normalized according to a=20 > particular version of Unicode and contains only characters allocated=20 > in that version, it will qualify as normalized according to any future ve= rsion of Unicode. The policy is reasonable, but there is more than one way to achieve it. Ap= plying this to CBOR for example, Since RFC-7049 specified a somewhat surpri= sing map serialization order, one way would be to stay stuck on that order,= but no I don't think that's a good solution at all. To see the other app= roach I suggest we need substitute "map" (or better yet "object") in each = place where the above policy says "string". So if the default rule is "pr= eserve the serialized order of maps" rather than "sort maps to normalize th= em", any existing serialized map stays normal in whatever normalization was= applied at the time the map was created. We don't have to preserve the = old=20 normalization if the map is modified, that's a higher-level concern, at the= application (semantic) protocol layer rather than at the presentation (syn= tax) layer. Without layered protocols, we get stuck in a quagmire of=20 unseparated concerns. =20 It seems quite clear to me that CBOR the spec is a presentation layer proto= col, just like character encodings and graphics formats. A CBOR implementa= tion however may have a mixture of presentation layer and application layer= concerns, but that does NOT mean that every implementation should behave t= he same when implementing application-level concern like canonicalization. = The fact that a particular implementation r CBOR-titled presentation laye= r RFC was opinionated about application-level concerns does not justify mix= ing of concerns, it illustrates why efforts should be made to separate them= . When people argue for canonicalization by saying that that testing by bina= ry comparison of serialization output is a reason for canonicalization anot= her implementation are totally unconvincing to me. There are alternative= s to binary comparison on virtually every platform I've looked at recently,= typically called deep comparison or deep-equal. That solves the comparis= on problem at the application level rather than the serialization level. JavaScript for example applies extreme simplicity for it's built-in compari= son of maps (objects): > Comparing x =3D=3D=3D y, where x and y are values, return true or false.= =20 > Comparing x =3D=3D=3D y, where x and y are objects, returns true if x and= y refer to the same object. > Otherwise, returns false even if the objects appear identical. Deep compare is simply a normal function that defines a different way of co= mparing objects. By making this an application concern, rather than buildi= ng it into the language, JavaScript allows other ways that might (for examp= le) ignore Unicode canonicalization (expensive) or assume some specific can= onicalized rule when comparing strings, or use case insensitive string comp= arisons. There are two special case where JavaScript defines something other than th= e "leave it in the order you found it" rule: 0. Sparse arrays. Any object can be a sparse array in JavaScript. The in= dex values for sparse arrays are limited to non-negative integers, just lik= e normal arrays. So non-negative integers sort to the beginning in ascend= ing order. Negative integers are not allowed as sparse array indexes, so = they are treated as strings. If you think of object as a hash table, this= does not make a lot of sense.=20 1. Normal objects (strings as keys). Generally kept in the order they w= ere added. Once, a long time ago there could be a glitch in order if you = used the JavaScript delete as a command, but that's a legacy holdover now, = all modern JavaScript fixes this. =20 2. Instances of the Symbol class. The reason Symbol keys are sorted last= is that they represent private information, information that should NOT be= converted in serialization. A serializer or reserialize should typically= skip past all other symbol keys and wrap-up the job. (Symbols didn't exi= st in earlier versions of JavaScript, so putting them last in key sort orde= r makes sense. So, if we can get over CBOR calling CBOR maps "maps", and deal with the rea= lity that CBOR maps always have some order when serialized, it might make s= ense now why I think we should allow (not require) that maps carry an order= , but say that applications SHOULD NOT compare values based on that key ord= er. By saying that the presentation layer SHOULD preserve key order, we e= nable using it as an optimization to handle special cases like sparse array= s. Sorry if this contains typos or seems disorganized. I'm very tired for u= nrelated reasons. From nobody Tue Jun 5 21:49:24 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ED3130E27 for ; Tue, 5 Jun 2018 21:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-8dgIjOuHE8 for ; Tue, 5 Jun 2018 21:49:16 -0700 (PDT) Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EB7130E1C for ; Tue, 5 Jun 2018 21:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1528260556; x=1559796556; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=No0uQfVjxRoukuBZo3ZLSJY9kMF+rHLj9PGkNyAxGfk=; b=cBcOB3XFAIoltY7adg8nm5tlOPtjKmHN4o8H1+8oba8cEsPTAE17fQZy wjViPusGeWkhPejj0VU0OPR9IHUf4bzPeyYDH4Zibl/NOHLXAMZknmWTm ruK+MklF38xCWsAW55EyJo2fD3og30NQ6gamWtnXVnH9CmH2doDyCau/V M=; X-IronPort-AV: E=Sophos;i="5.49,481,1520924400"; d="scan'208";a="4262029" Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-02.qualcomm.com with ESMTP; 05 Jun 2018 21:49:15 -0700 Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 05 Jun 2018 21:49:15 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 5 Jun 2018 21:49:15 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Tue, 5 Jun 2018 21:49:15 -0700 From: Laurence Lundblade To: Michael Richardson , "cbor@ietf.org" Thread-Topic: [Cbor] Canonical CBOR Thread-Index: AQHT+DAtw9B4IAE4bU+ppwSV0kSEKKRJGMsAgAg0MoCAAPMlAIAAbtQm Date: Wed, 6 Jun 2018 04:49:14 +0000 Message-ID: <1528260550529.88987@qti.qualcomm.com> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com>, <31799.1528210674@localhost> In-Reply-To: <31799.1528210674@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 04:49:21 -0000 In 5.3, the COSE Enc_structure includes:=0A= =0A= protected : empty_or_serialized_map=0A= =0A= This is described as:=0A= =0A= The protected attributes from the body structure encoded in a bstr type.= =0A= =0A= I assume these are protected headers parameters as described in section 3. = The ones that are part of the Headers in the COSE_Encrypt that will specify= the alg. (It's a bit confusing because of the use of the word "attribute";= section 3 mostly refers to them as "parameters").=0A= =0A= My question is: does the canonicalization requirement apply to the protect= ed headers because they are included in the Enc_structure? Do protected he= aders have to be sorted? =0A= =0A= My first thought was "yes", but thinking some more, they are transmitted an= d they are bstr wrapped, so probably "no". Thus, there is very little to ca= nonicalize in the Enc_strucutre. =0A= =0A= Sound right?=0A= =0A= LL=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: Michael Richardson =0A= Sent: Tuesday, June 5, 2018 7:57 AM=0A= To: cbor@ietf.org; Laurence Lundblade=0A= Subject: Re: [Cbor] Canonical CBOR=0A= =0A= Laurence Lundblade wrote:=0A= > Section 14 requires canonicalization for Sig_structure, Enc_structur= e,=0A= > and MAC_structure. I interpret this as requiring canonicalization fo= r=0A= > any / all of the maps in these structures including sorting. I have a= =0A= > few issues with this requirement:=0A= =0A= I'm a bit puzzled by this.=0A= Sig_structure, Enc_structure and MAC_structure are CBOR arrays, and the=0A= contents are fully specified. There aren't any choices, so I don't=0A= understand why we can talk about canonicalization?=0A= =0A= > - This canonicalization seems unnecessary. I just can=92t see what co= uld=0A= > go wrong if you don=92t canonicalize. Canonicalize of the payload is = not=0A= > required and that works OK. It seems like COSE would be better by ju= st=0A= > deleting section 14.=0A= =0A= The restrictions of section 14 seem self-evident, but they seem to be there= =0A= just to cover all our bases.=0A= =0A= --=0A= ] Never tell me the odds! | ipv6 mesh network= s [=0A= ] Michael Richardson, Sandelman Software Works | network architect= [=0A= ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=0A= From nobody Wed Jun 6 03:17:28 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42D2130E61 for ; Wed, 6 Jun 2018 03:17:25 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsexU8O-PINn for ; Wed, 6 Jun 2018 03:17:20 -0700 (PDT) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC3C129C6B for ; Wed, 6 Jun 2018 03:17:20 -0700 (PDT) Received: from a-webmail.mh.aa.net.uk ([2001:8b0:0:30::75] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fQVVH-0000sB-BG; Wed, 06 Jun 2018 11:17:19 +0100 Received: from cpc105066-sgyl40-2-0-cust671.18-2.cable.virginm.net ([82.1.242.160]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Wed, 06 Jun 2018 11:17:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6f5ade75f8f90c76434c9e01532a008c" Date: Wed, 06 Jun 2018 11:17:13 +0100 From: Kio Smallwood To: Laurence Lundblade Cc: cbor@ietf.org In-Reply-To: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> Message-ID: <3e13d15101573979d104d1b333673d27@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 10:17:26 -0000 --=_6f5ade75f8f90c76434c9e01532a008c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Speaking as someone who has implemented canonical encoding, I did so without knowing what I could use it for, assuming that the need for it would become clear in time as more CBOR-based protocols used it. I had originally considered using canonical encoding to create a file encryption header similar to https://github.com/diafygi/myLock which uses JSON as the file header format. However since it is good practice to use authenticated encryption or encrypt-then-mac on the serialized header, the order of keys in the header is not significant. The content of an encrypted file header would be unique every time the file was re-encrypted since a new ephemeral key would be used. In the cbor2 python implementation, canonicalizing dictionaries doubles the memory for the keys (we have to maintain a sorted list of encoded keys) but leaves the values alone. It also makes iterating through the collection less efficient, since Python has special methods that iterate through key-value pairs in a single operation which we can't use on canonical maps. Duplicate keys are also not an issue for dynamic languages since they will simply use the last value encountered. Hope that helps. Kio On 2018-05-30 17:06, Laurence Lundblade wrote: > To be a bit direct here, canonical CBOR seems only about 2/3 baked to me. I have a couple of ideas on what to do about and may volunteer to write some text, but first I want to ask about use cases for it. I've seen some described, but they really aren't compelling to me. > > I think the important question is this: has anyone actually implemented it and put it to use? > > One use case mentioned is to be able to reconstruct the encoded CBOR to verify a signature after decoding. If that is to be supported we should specify canonical encoding for every type in the RFC. Right now there is a good specification for some types (integers), but only suggestions for others (floating point). > > Another use case is that map sorting allows for fast detection of duplicate labels. I don't know why duplicate detection is needed. If you can't trust the sender and/or transport to not add duplicates, you can't really trust them to not make other worse mistakes. > > But the real question is about implementations. If now one has implemented in the years that 7049 has been around it seems questionable. > > Here's a few ideas for what to do: > > #1 Require all integers and lengths to always be in shortest form and always the same. Do the same for floating point, dates and as many other of the types defined in the spec as possible. For a lot of data types, this is not that hard to implement and it eliminates a variability in the spec that seems unnecessary. Then you don't have to define a canonical format for these types. They are always canonical. > > #2 If not #1, then make a clear subsection of the document that sharply defines the canonical format for all data types that have multiple representations. This is specially called "Canonical CBOR" and anyone claiming to implement it, MUST implement all aspects of it. We also highly recommended that every implementation use it. Move this to section 3 so it is not in the recommendations for creating protocols. Leave the sorting order and use of definite lengths requirements out of this section because they are costly to implement. > > #3 Rename section 4.9 to something like "recommendations for uniform CBOR" (or "invariant", or "consistent" CBOR). This text is non-normative recommendations only. The sorting order can be part of this. > > Basically, the less work we leave to CBOR protocol designers, the better. It'll be easier for protocol designers to do there work, they'll get it right more often and there'll be less interop problems. > > Last, I think the names "Canonical Encoded CBOR" and "Strict CBOR Decoding" would be really helpful. > > LL > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --=_6f5ade75f8f90c76434c9e01532a008c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Speaking as someone who has implemented canonical encoding, I did so wit= hout knowing what I could use it for, assuming that the need for it would b= ecome clear in time as more CBOR-based protocols used it.

I had originally considered using canonical encoding to create a file en= cryption header similar to ht= tps://github.com/diafygi/myLock  which uses JSON as the file heade= r format. However since it is good practice to use authenticated encryption= or encrypt-then-mac on the serialized header, the order of keys in the hea= der is not significant. The content of an encrypted file header would be un= ique every time the file was re-encrypted since a new ephemeral key would b= e used.

In the cbor2 python implementation, canonicalizing dictionaries doubles = the memory for the keys (we have to maintain a sorted list of encoded keys)= but leaves the values alone. It also makes iterating through the collectio= n less efficient, since Python has special methods that iterate through key= -value pairs in a single operation which we can't use on canonical maps. Du= plicate keys are also not an issue for dynamic languages since they will si= mply use the last value encountered.

Hope that helps.

Kio

On 2018-05-30 17:06, Laurence Lundblade wrote:

= To be a bit direct here, canonical CBOR seems only about 2/3 baked to me. I= have a couple of ideas on what to do about and may volunteer to write some= text, but first I want to ask about use cases for it.  I've seen some= described, but they really aren't compelling to me.

I think t= he important question is this: has anyone actually implemented it and put i= t to use?

One use case mentioned is to be able to reconstruct= the encoded CBOR to verify a signature after decoding. If that is to be su= pported we should specify canonical encoding for every type in the RFC. Rig= ht now there is a good specification for some types (integers), but only su= ggestions for others (floating point).

Another use case is th= at map sorting allows for fast detection of duplicate labels. I don't know = why duplicate detection is needed. If you can't trust the sender and/or tra= nsport to not add duplicates, you can't really trust them to not make other= worse mistakes.

But the real question is about implementatio= ns. If now one has implemented in the years that 7049 has been around it se= ems questionable.


Here's a few ideas for what to do:
#1 Require all integers and lengths to always be in shortest for= m and always the same. Do the same for floating point, dates and as many ot= her of the types defined in the spec as possible.  For a lot of data t= ypes, this is not that hard to implement and it eliminates a variability in= the spec that seems unnecessary. Then you don't have to define a canonical= format for these types. They are always canonical.

#2 If not = #1, then make a clear subsection of the document that sharply defines the c= anonical format for all data types that have multiple representations. This= is specially called "Canonical CBOR" and anyone claiming to implement it, = MUST implement all aspects of it.  We also highly recommended that eve= ry implementation use it.  Move this to section 3 so it is not in the = recommendations for creating protocols. Leave the sorting order and use of = definite lengths requirements out of this section because they are costly t= o implement.

#3 Rename section 4.9 to something like "recommen= dations for uniform CBOR" (or "invariant", or "consistent" CBOR). This text= is non-normative recommendations only. The sorting order can be part of th= is.

Basically, the less work we leave to CBOR protocol design= ers, the better. It'll be easier for protocol designers to do there work, t= hey'll get it right more often and there'll be less interop problems.
=

Last, I think the names "Canonical Encoded CBOR" and "Strict= CBOR Decoding" would be really helpful.

LL







_____________________________________= __________
CBOR mailing list
C= BOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor


--=_6f5ade75f8f90c76434c9e01532a008c-- From nobody Wed Jun 6 04:40:04 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72623130E39 for ; Wed, 6 Jun 2018 04:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb6xEOqQFQBG for ; Wed, 6 Jun 2018 04:39:56 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E941277BB for ; Wed, 6 Jun 2018 04:39:56 -0700 (PDT) Received: from Jude (216.53.143.123) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 6 Jun 2018 04:36:58 -0700 From: Jim Schaad To: 'Laurence Lundblade' , 'Michael Richardson' , References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> <423B5793-F031-4522-B2DD-78125704A407@qti.qualcomm.com>, <31799.1528210674@localhost> <1528260550529.88987@qti.qualcomm.com> In-Reply-To: <1528260550529.88987@qti.qualcomm.com> Date: Wed, 6 Jun 2018 07:39:44 -0400 Message-ID: <013301d3fd8b$12c8fe40$385afac0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGllD7+yObJ82UzPxgPlgWMyXmPEQNF1t1+AtnxHYMCsNRxkgJ9ihcIpFV8MFA= Content-Language: en-us X-Originating-IP: [216.53.143.123] Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 11:40:02 -0000 > -----Original Message----- > From: CBOR On Behalf Of Laurence Lundblade > Sent: Wednesday, June 6, 2018 12:49 AM > To: Michael Richardson ; cbor@ietf.org > Subject: Re: [Cbor] Canonical CBOR > > In 5.3, the COSE Enc_structure includes: > > protected : empty_or_serialized_map > > This is described as: > > The protected attributes from the body structure encoded in a bstr type. > > I assume these are protected headers parameters as described in section 3. > The ones that are part of the Headers in the COSE_Encrypt that will specify > the alg. (It's a bit confusing because of the use of the word "attribute"; > section 3 mostly refers to them as "parameters"). > > My question is: does the canonicalization requirement apply to the > protected headers because they are included in the Enc_structure? Do > protected headers have to be sorted? > > My first thought was "yes", but thinking some more, they are transmitted > and they are bstr wrapped, so probably "no". Thus, there is very little to > canonicalize in the Enc_strucutre. No they do not because of the bstr wrap. This was done specifically so that the map was not needed to be canonically encoded but to be used as transported. Jim > > Sound right? > > LL > > > > > ________________________________________ > From: Michael Richardson > Sent: Tuesday, June 5, 2018 7:57 AM > To: cbor@ietf.org; Laurence Lundblade > Subject: Re: [Cbor] Canonical CBOR > > Laurence Lundblade wrote: > > Section 14 requires canonicalization for Sig_structure, Enc_structure, > > and MAC_structure. I interpret this as requiring canonicalization for > > any / all of the maps in these structures including sorting. I have a > > few issues with this requirement: > > I'm a bit puzzled by this. > Sig_structure, Enc_structure and MAC_structure are CBOR arrays, and the > contents are fully specified. There aren't any choices, so I don't understand > why we can talk about canonicalization? > > > - This canonicalization seems unnecessary. I just can't see what could > > go wrong if you don't canonicalize. Canonicalize of the payload is not > > required and that works OK. It seems like COSE would be better by just > > deleting section 14. > > The restrictions of section 14 seem self-evident, but they seem to be there > just to cover all our bases. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sat Jun 16 06:34:45 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DAD130E43; Sat, 16 Jun 2018 06:34:36 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF0dZeYVGIMU; Sat, 16 Jun 2018 06:34:33 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD5B130E3E; Sat, 16 Jun 2018 06:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5GDYTh3016843; Sat, 16 Jun 2018 15:34:29 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 417JHT4FM3zDXmH; Sat, 16 Jun 2018 15:34:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 550848867.3362-46253f92ae822c5022ffbc08a3f25e61 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 16 Jun 2018 15:34:28 +0200 Message-Id: To: ace , Core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 13:34:37 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a personal problem for me, throwing in TEEP on top is a bit weird, though. 6TISCH vs. SUIT is probably painful for the few individuals who care about security in both. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Viger INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Viger ART *** core Constrained RESTful Environments WG Place du Canada INT intarea Internet Area Working Group WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Duluth ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC secdispatch Security Dispatch WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Van Horne INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** suit Software Updates for Internet of Things = WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Centre Ville OPS v6ops IPv6 Operations WG Viger RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Viger IRTF*** t2trg Thing-to-Thing Duluth OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Duluth IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Tue Jun 19 08:11:36 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB191310FA; Tue, 19 Jun 2018 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl_atoovB5jR; Tue, 19 Jun 2018 08:11:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E866F130EA8; Tue, 19 Jun 2018 08:11:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CAE420090; Tue, 19 Jun 2018 11:25:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 54A901A69; Tue, 19 Jun 2018 11:08:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 52BDA1A68; Tue, 19 Jun 2018 11:08:21 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org cc: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cbor] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:11:27 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value for GRASP. In this normative part of the document, there is only one choic= e, but it is our intention to allow additional choices, as per section 2.2.2 of cddl-02. We think that we should specify our single "choice", using /=3D, rather tha= n =3D, as this should clue the reader in to expect multiple values here. From=20our document: transport-proto /=3D IPPROTO_TCP ; note this is an extensible CDDL choice ; and can be added to in subsequent ; specifications using the /=3D and //=3D It is unclear in section 2.2.2 if we can say foo /=3D without having said foo =3D 1 / 2 / 3 previously, but it seems like it should be reasonable to do in order to indicate that implementations should expect future values. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWykcYoCLcPvd0N1lAQL1jAgAusybcmaLIX9NsI/t9/LhWFq4tVsJQgC5 5rcnQjCPZfsPaTw5C4Fj3Jpxp60PiKbxOcnmb1teE+HJDimynHY0fHQBom0YkM59 3NjjGj9SimYMd2NmQPehbkzhK8Bdz+Rmu/Ia4nkenEwY5dVKa3oXnd2IXb0X6s6N R6GvumhHKXkEvimxhSAxb0afU3DVIHQ+zzQG99re1lK2PL0X/x3CgUH0NMPQm6qT MBu396c9Ya8d2Y0y5A7pRCEQwJaBlv3iswnD3O/3yHf7rqi1qgPLxd+EX0e2Gt2H TPKO7p8OgKtxhWqhZUPbzEYlj60L6U7suHwvvThYv0sOtmtR50ULDA== =YHEL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 08:20:43 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38F7130EA8; Tue, 19 Jun 2018 08:20:40 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rxphkyIyX5Z; Tue, 19 Jun 2018 08:20:38 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F41A130E3C; Tue, 19 Jun 2018 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5JFKZot020467; Tue, 19 Jun 2018 17:20:35 +0200 (CEST) Received: from client-0114.vpn.uni-bremen.de (client-0114.vpn.uni-bremen.de [134.102.107.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 419BVV6gDDzDWqv; Tue, 19 Jun 2018 17:20:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <1812.1529420901@localhost> Date: Tue, 19 Jun 2018 17:20:34 +0200 Cc: cbor@ietf.org, anima@ietf.org X-Mao-Original-Outgoing-Id: 551114432.56145-f39f25e63e1f01b7bfa80e9ded777149 Content-Transfer-Encoding: quoted-printable Message-Id: <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> References: <1812.1529420901@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:20:41 -0000 Hi Michael, 2.2.2 says: It is not an error if a name is first used with a "/=3D" or "//=3D" (there is no need to =E2=80=9Ccreate it" with "=3D"). The intention is indeed to say that no initial rule with a =E2=80=9C=3D=E2= =80=9C is needed. Any ideas how we can clarify this some more? You could also make use of the convention (not currently checked by any = tool, but that could be done) to mark an extension point with a dollar = sign: $transport-proto /=3D IPPROTO_TCP (See section 3.9 for more about that convention.) Gr=C3=BC=C3=9Fe, Carsten > On Jun 19, 2018, at 17:08, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol = value > for GRASP. In this normative part of the document, there is only one = choice, > but it is our intention to allow additional choices, as per section = 2.2.2 > of cddl-02. >=20 > We think that we should specify our single "choice", using /=3D, = rather than =3D, > as this should clue the reader in to expect multiple values here. >=20 > =46rom our document: >=20 > transport-proto /=3D IPPROTO_TCP ; note this is an extensible CDDL = choice > ; and can be added to in subsequent > ; specifications using the /=3D and = //=3D >=20 > It is unclear in section 2.2.2 if we can say foo /=3D without having = said > foo =3D 1 / 2 / 3 > previously, but it seems like it should be reasonable to do in order = to > indicate that implementations should expect future values. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 From nobody Tue Jun 19 08:21:32 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC1130E3C; Tue, 19 Jun 2018 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVx6ycvqUx4r; Tue, 19 Jun 2018 08:21:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7817F1310FA; Tue, 19 Jun 2018 08:21:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Jun 2018 08:18:10 -0700 From: Jim Schaad To: 'Michael Richardson' , CC: References: <1812.1529420901@localhost> In-Reply-To: <1812.1529420901@localhost> Date: Tue, 19 Jun 2018 08:21:08 -0700 Message-ID: <01a601d407e1$275c1850$761448f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQId9lHu77pIXu+Dt0rbOoVrMt9rC6PT1YZA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:21:30 -0000 Look at the last paragraph in section 2.2.2 It is not an error if a name is first used with a "/=" or "//=" (there is no need to "create it" with "="). Jim > -----Original Message----- > From: CBOR On Behalf Of Michael Richardson > Sent: Tuesday, June 19, 2018 8:08 AM > To: cbor@ietf.org > Cc: anima@ietf.org > Subject: [Cbor] CDDL-02 section 2.2.2 choices > > > In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value > for GRASP. In this normative part of the document, there is only one choice, > but it is our intention to allow additional choices, as per section 2.2.2 of cddl- > 02. > > We think that we should specify our single "choice", using /=, rather than =, > as this should clue the reader in to expect multiple values here. > > From our document: > > transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice > ; and can be added to in subsequent > ; specifications using the /= and //= > > It is unclear in section 2.2.2 if we can say foo /= without having said > foo = 1 / 2 / 3 > previously, but it seems like it should be reasonable to do in order to indicate > that implementations should expect future values. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Tue Jun 19 10:15:46 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2E131185; Tue, 19 Jun 2018 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jPKCr4s5DfwW; Tue, 19 Jun 2018 10:15:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA66130DFF; Tue, 19 Jun 2018 10:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3744; q=dns/txt; s=iport; t=1529428535; x=1530638135; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BFcXvSNWlGKgMYLKTnUzLRMeezrUrM9vACui9590I6Y=; b=cNG6xOOu3hC+FJ//rrvx12R0BLubBOZVFPcu8ol+/ANlqlfD+jFPcZBs 6UeGk2pPbZlnNEGAamx4P1pojzADmsSksTqaO5hv3phGP4uYTy4/YGLGH sxioH6nOKtb+s34I9yKg7WLpYBkU7bpWDlGhJvXDIYoTDMOYBmOKez0T4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgCBOSlb/4gNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCoNvlFWCAJR7gXgLGAuBVIJ1AheCVyE1FwECAQE?= =?us-ascii?q?BAQEBAm0cDIUoAQEBAwEBASERNgQLBQsCAQYCDgoCAiYCAgIlCxUQAgQOBYM?= =?us-ascii?q?lAYF3CA+QYptHghyISIFjBYELh0mCE4EPJIJogxMBAYFggwExgiQCjD6MYQk?= =?us-ascii?q?Chm6BcIYvgT+LfpEsAhETAYEkHgE2gVJwFTsqAYIYgiEXiFmFPm+LNoEaAQE?= X-IronPort-AV: E=Sophos;i="5.51,243,1526342400"; d="scan'208";a="131263961" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 17:15:34 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w5JHFYPS021401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2018 17:15:34 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 19 Jun 2018 12:15:34 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Tue, 19 Jun 2018 12:15:34 -0500 From: "Max Pritikin (pritikin)" To: Carsten Bormann CC: Michael Richardson , "cbor@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] CDDL-02 section 2.2.2 choices Thread-Index: AQHUB9/T4H6EDf6GI0Ga7rncl8Sqt6RoBjQAgAAgIIA= Date: Tue, 19 Jun 2018 17:15:34 +0000 Message-ID: References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> In-Reply-To: <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: <0EA05333EC660C4CB8C8D5DB307841A9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:15:39 -0000 DQoNCj4gT24gSnVuIDE5LCAyMDE4LCBhdCA5OjIwIEFNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBNaWNoYWVsLA0KPiANCj4gMi4yLjIgc2F5czoNCj4g DQo+ICAgSXQgaXMgbm90IGFuIGVycm9yIGlmIGEgbmFtZSBpcyBmaXJzdCB1c2VkIHdpdGggYSAi Lz0iIG9yICIvLz0iDQo+ICAgKHRoZXJlIGlzIG5vIG5lZWQgdG8g4oCcY3JlYXRlIGl0IiB3aXRo ICI94oCcKS4NCg0KV2UgbXVzdCBoYXZlIGFic29yYmVkIHRoaXMgc2VudGVuY2Ugdy9vIG5vdGlj aW5nIGl0LiANCg0KPiANCj4gVGhlIGludGVudGlvbiBpcyBpbmRlZWQgdG8gc2F5IHRoYXQgbm8g aW5pdGlhbCBydWxlIHdpdGggYSDigJw94oCcIGlzIG5lZWRlZC4NCj4gQW55IGlkZWFzIGhvdyB3 ZSBjYW4gY2xhcmlmeSB0aGlzIHNvbWUgbW9yZT8NCg0KSSB3b3VsZCBoZWxwIGlmIHRoZSB1c2Ug b2YgLz0gb3IgLy89IGlzIGNsYXJpZmllZCB0byBiZSBhIG1lc3NhZ2UgdG8gaW1wbGVtZW50b3Jz IHRoYXQgZnV0dXJlIHZhbHVlcyBzaG91bGQgYmUgZXhwZWN0ZWQgYW5kIGhhbmRsZWQgYXBwcm9w cmlhdGVseS4gQXMgaXQgcmVhZHMsIGluIGNvbmNlcnQgd2l0aCB0aGUgZmlyc3Qgc2VudGVuY2Ug b2YgdGhlIG5leHQgc2VjdGlvbiAo4oCcSW5zdGVhZCBvZiBuYW1pbmcgYWxsIHRoZSB2YWx1ZXMg dGhhdCBtYWtlIHVwIGEgY2hvaWNl4oCdKSwgSSBmaW5kIG15c2VsZiB1bnN1cmUgYXMgdG8gdGhl IG5lZWQgZm9yIGEgc2VudGVuY2Ugc3VjaCBhcyB3ZeKAmXZlIHByb3ZpZGVkLiBEbyB3ZSBuZWVk IHRvIGluZm9ybSBpbXBsZW1lbnRvcnMgdGhhdCBmdXR1cmUgdmFsdWVzIE1BWSBiZSBzZWVuPyBX aGF0IGlmIHdlIGludGVuZGVkIHRoYXQgZnV0dXJlIHZhbHVlcyBNVVNUIE5PVCBiZSBpbmNsdWRl ZD8gDQoNCkl0cyByZWFzb25hYmxlIGZvciBDRERMIHRvIGRlY2xhcmUgdGhhdCBvdXQtb2Ytc2Nv cGU7IGluIHdoaWNoIGNhc2UgdGhlIGN1cnJlbnQgbGFuZ3VhZ2UgbG9va3Mgc3VmZmljaWVudCBi dXQgaXQgd291bGQgbWVhbiB1c2Ugb2YgQ0RETCBpbiB0aGlzIGFyZWEgd2lsbCBvZnRlbiBoYXZl IGFuIGFkZGl0aW9uYWwgc2VudGVuY2UgdG8gY2xhcmlmeSBmb3IgaW1wbGVtZW50b3JzLg0KDQot IG1heA0KDQo+IA0KPiBZb3UgY291bGQgYWxzbyBtYWtlIHVzZSBvZiB0aGUgY29udmVudGlvbiAo bm90IGN1cnJlbnRseSBjaGVja2VkIGJ5IGFueSB0b29sLCBidXQgdGhhdCBjb3VsZCBiZSBkb25l KSB0byBtYXJrIGFuIGV4dGVuc2lvbiBwb2ludCB3aXRoIGEgZG9sbGFyIHNpZ246DQo+IA0KPiAk dHJhbnNwb3J0LXByb3RvIC89IElQUFJPVE9fVENQDQo+IA0KPiAoU2VlIHNlY3Rpb24gMy45IGZv ciBtb3JlIGFib3V0IHRoYXQgY29udmVudGlvbi4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+ IA0KPiANCj4+IE9uIEp1biAxOSwgMjAxOCwgYXQgMTc6MDgsIE1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+IA0KPj4gU2lnbmVkIFBHUCBwYXJ0DQo+ PiANCj4+IEluIGRyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0xNSwgd2Ug c3BlY2lmeSBhIHByb3RvY29sIHZhbHVlDQo+PiBmb3IgR1JBU1AuICBJbiB0aGlzIG5vcm1hdGl2 ZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCwgdGhlcmUgaXMgb25seSBvbmUgY2hvaWNlLA0KPj4gYnV0 IGl0IGlzIG91ciBpbnRlbnRpb24gdG8gYWxsb3cgYWRkaXRpb25hbCBjaG9pY2VzLCBhcyBwZXIg c2VjdGlvbiAyLjIuMg0KPj4gb2YgY2RkbC0wMi4NCj4+IA0KPj4gV2UgdGhpbmsgdGhhdCB3ZSBz aG91bGQgc3BlY2lmeSBvdXIgc2luZ2xlICJjaG9pY2UiLCB1c2luZyAvPSwgcmF0aGVyIHRoYW4g PSwNCj4+IGFzIHRoaXMgc2hvdWxkIGNsdWUgdGhlIHJlYWRlciBpbiB0byBleHBlY3QgbXVsdGlw bGUgdmFsdWVzIGhlcmUuDQo+PiANCj4+IEZyb20gb3VyIGRvY3VtZW50Og0KPj4gDQo+PiB0cmFu c3BvcnQtcHJvdG8gLz0gSVBQUk9UT19UQ1AgICA7IG5vdGUgdGhpcyBpcyBhbiBleHRlbnNpYmxl IENEREwgY2hvaWNlDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBhbmQgY2Fu IGJlIGFkZGVkIHRvIGluIHN1YnNlcXVlbnQNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA7IHNwZWNpZmljYXRpb25zIHVzaW5nIHRoZSAvPSBhbmQgLy89DQo+PiANCj4+IEl0IGlz IHVuY2xlYXIgaW4gc2VjdGlvbiAyLjIuMiBpZiB3ZSBjYW4gc2F5IGZvbyAvPSB3aXRob3V0IGhh dmluZyBzYWlkDQo+PiAgZm9vID0gMSAvIDIgLyAzDQo+PiBwcmV2aW91c2x5LCBidXQgaXQgc2Vl bXMgbGlrZSBpdCBzaG91bGQgYmUgcmVhc29uYWJsZSB0byBkbyBpbiBvcmRlciB0bw0KPj4gaW5k aWNhdGUgdGhhdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGV4cGVjdCBmdXR1cmUgdmFsdWVzLg0K Pj4gDQo+PiAtLQ0KPj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0N Cj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Tue Jun 19 10:56:51 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA841311BD; Tue, 19 Jun 2018 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxr2SSgdz-e6; Tue, 19 Jun 2018 10:56:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D191311BB; Tue, 19 Jun 2018 10:56:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BA5D20090; Tue, 19 Jun 2018 14:10:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F02811A69; Tue, 19 Jun 2018 13:53:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ED95B1A68; Tue, 19 Jun 2018 13:53:45 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org, anima@ietf.org In-Reply-To: <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:56:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > 2.2.2 says: >> It is not an error if a name is first used with a "/=3D" or "//=3D" >> (there is no need to =E2=80=9Ccreate it" with "=3D"). > The intention is indeed to say that no initial rule with a =E2=80=9C= =3D=E2=80=9C is needed. > Any ideas how we can clarify this some more? Neither Max nor I saw this while we were perusing this part. May I suggest that it be moved to be the second paragraph? > You could also make use of the convention (not currently checked by a= ny > tool, but that could be done) to mark an extension point with a dollar > sign: > $transport-proto /=3D IPPROTO_TCP > (See section 3.9 for more about that convention.) Ah, interesting. thank you. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWylDJ4CLcPvd0N1lAQILQAf/UT3ocGN3gGhn+YBsAIVYOjc8fwcRcXho t6n5T0tI6Jfp4mu8K1+nnu5k5gsPs3wfD3KkHIxELX99e90YqXlwVg+YmDT87Jgy do5mAisMWJhS/cRXvp4T1Zygv70GXoSwEJEg312yPZlwF+BGLb4cyojt/eUIlxy3 /eoqo204Nveq7h2X15eyil1MDjEJ3o51m7+Hr4FeTdC5imt6DTtpVWxcOTGyEgfm Pn7PE5vTPByW04yYND4MC/LVGlGl+IzBO5UjSAzim5vbqGkLqSmB8yoEsJkgxah1 pFR3COINej3IPdLwAAb3K5RXjERB8ERVJt9DYoF9PRb0240bGIB80Q== =sfbz -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 13:46:09 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512A8130F27; Tue, 19 Jun 2018 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mCvf3hduwkU; Tue, 19 Jun 2018 13:45:58 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 A536C130F0D; Tue, 19 Jun 2018 13:45:58 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id k1-v6so478697plt.2; Tue, 19 Jun 2018 13:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Tc2PnTxWVP5Ii7YVpiN/b+I5nxwg64yNQLZFpzuByhs=; b=D4fBwetOCdKYsxAyiSntjsH5P3z45l17GQjfHaaWQwO9d5USNtAk8xl9aYjMm3rrwr 79szgN7RUQeAQCt0WHZoGvTlsNva+mtxedflf6YKvO0AjqLVK62eYqz9klJE8qDSuMzc rJWBH3ATyeID9W9OKMR889mp4kwqToZZPt9cvhijxBSqIz7Sf2yEvfyL9TBVoaKzehSx A72KPu7rWyhU1BzZ2qFzT9BmMklbNt16oB8LC6WZOO79oaWNHVwTO2JtjmtfTmi1C4W0 MWnVbANbQbsP9ubDoG4Sei0g1fDorptl+CvZntVDXij2GaXMtF1LwcC1Jyz2Kj+UEGhW /Vxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Tc2PnTxWVP5Ii7YVpiN/b+I5nxwg64yNQLZFpzuByhs=; b=gHGZ+JykLKPN78+YNyzIrXBnGpuO4zAnHk07giK9Q66zBd+eTkRo5Fz9eETXbv2Pdm Y9/PBNUdos/9mRO6NCkjVejBiDbfcTxtH7ABPl4E3Xy5/z7pUbZOWfWQwd0Jg9meobXv 7OfrOqkTdQKIm32gyNS38HERKIkxV5qUeG1WrOL4MUiZCm6iv5E7ce5yy2sl0PJTp9XQ RBbaSN4zJNgn0aD7sEs9wSUs3dDHQFE8dwOg4srtMmR6nr4g1oUlYFySyMMczI7JSVAO FyyySzSajR6p1DMynZidceb0RLUij+1bvpYKKxkFQFq7xGRNUtDLsMSf9uhGu9duKZQh rPYA== X-Gm-Message-State: APt69E0qm3OsXm+WjOe9B+WVLj46FIe5JzJGjTZ6pkC1slzEznqFgd0D SpHwZXvaLz2iMQ5q/pvSyUVPCA== X-Google-Smtp-Source: ADUXVKKABNyX79nGVmOJpWV1MdWhtxlnJ8jNVQ+z+HBEPa5MgLCamKavHp9EUxHDLd8CQiHcomfouw== X-Received: by 2002:a17:902:981:: with SMTP id 1-v6mr20679515pln.11.1529441157712; Tue, 19 Jun 2018 13:45:57 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z3-v6sm659545pfn.36.2018.06.19.13.45.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:45:56 -0700 (PDT) To: Michael Richardson , Carsten Bormann Cc: cbor@ietf.org, anima@ietf.org References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> <4918.1529430825@localhost> From: Brian E Carpenter Message-ID: <8dd31a39-6e66-b7fe-845b-c9ffe3eb02a2@gmail.com> Date: Wed, 20 Jun 2018 08:45:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <4918.1529430825@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:46:02 -0000 On 20/06/2018 05:53, Michael Richardson wrote: >=20 > Carsten Bormann wrote: > > 2.2.2 says: >=20 > >> It is not an error if a name is first used with a "/=3D" or "//=3D= " > >> (there is no need to =E2=80=9Ccreate it" with "=3D"). >=20 > > The intention is indeed to say that no initial rule with a =E2=80= =9C=3D=E2=80=9C is needed. > > Any ideas how we can clarify this some more? >=20 > Neither Max nor I saw this while we were perusing this part. > May I suggest that it be moved to be the second paragraph? >=20 > > You could also make use of the convention (not currently checked = by any > > tool, but that could be done) to mark an extension point with a d= ollar > > sign: >=20 > > $transport-proto /=3D IPPROTO_TCP >=20 > > (See section 3.9 for more about that convention.) >=20 > Ah, interesting. thank you. However: I suggest not using that in the BRSKI draft. Our emergency plan if CDDL is not yet close to being an RFC is to add a normative appendix to GRASP specifying the subset of CDDL that we use, and I'd like to keep that subset as small as possible. Even better, CBOR could wrap up the CDDL spec in Montreal. Regards Brian From nobody Tue Jun 19 16:31:19 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73D5130FEC for ; Tue, 19 Jun 2018 16:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o257WLS5CsUs for ; Tue, 19 Jun 2018 16:31:14 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C35130E4B for ; Tue, 19 Jun 2018 16:31:14 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id VQ5hfyf7wKS3IVQ5ifVxBC; Tue, 19 Jun 2018 16:31:14 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_65A6E79C-F017-4E27-9F98-C20F4348825A" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <9F2DE250-24B9-454B-A7CA-19D0A9C6C433@island-resort.com> Date: Tue, 19 Jun 2018 16:31:13 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfIvrUSKnxCumjTTgUNvuvsdgT8T95KQ0evHdIAll3fMzrcSzRpsZi8c5QgUaRCjm3tzBlmYRnXyNACzYhVLuAhdA1MhQcBVJf9SsKbvB01Jjzamu98Mv JfnHHXE+mAAOTAw+wotZw427ULoYaHpc/hlF2/GVtvyjDUlh1bJCDiKj Archived-At: Subject: [Cbor] Signing and canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:31:17 -0000 --Apple-Mail=_65A6E79C-F017-4E27-9F98-C20F4348825A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The reason I took a careful look at CBOR canonicalization was to = understand if it was important in a protocol design (EAT = ) that was very = focused on signed data. It took me a while and a mistake or two to = understand the best way to format the TBS bytes in CBOR. Here=E2=80=99s = the conclusions in the form of some text that would have helped me a lot = which I hope can be added to one of the CBOR documents. How to design signing in CBOR protocols Any protocol that involves signing needs to define exactly what the TBS = (to-be-signed) bytes are, the exact bytes that are input the signing and = verification operations. There are two main approaches . In the first approach, the data is CBOR encoded as it normally would be. = Then the binary bytes that are the encoded CBOR is wrapped in a bstr. = The bstr is inserted into the message and transmitted along with the = signature. The value of the bstr is the TBS bytes.=20 For example if the encoded CBOR was an integer with the value 1, that = encodes to one byte, 0x01, then the bstr wrapping of that would be two = bytes, 0x41, 0x01. =20 In theory the bstr wrapping could be skipped, but this makes it very = difficult to implement with generic CBOR parsers because they do not = give access to encoded sub-parts of a CBOR message.=20 Canonicalization of the transmitted data is NOT required. =46rom the = signature generation and verification view, it is even OK if there is = variance from message to message. For example it is OK if integers are = encoded in the shortest form sometimes and sometimes not. It is OK to = use definite and indefinite lengths. The second less obvious approach is for the TBS bytes to be constructed = by some precisely defined process. Since CBOR has several different ways = of representing the same data, some form of canonicalization is required = because the sender and the receiver must come up with exactly the same = TBS bytes. Canonical Encoded CBOR should be used in this case, but = protocols can also define their own rules for canonicalization if they = wish. The main reason for choosing this second approach is that it can reduce = the size of the messages transmitted and/or provide flexibility in the = way the data is structured. In the end, a good practice is just to use the COSE format for signing = as it takes care of these details. In COSE the payload does NOT need to = be canonicalized. It seems there is some consensus that canonicalization should not be in = the main CBOR RFC, but I haven=E2=80=99t seen anything in GitHub for = that yet. When that is figured out, I can make a pull request out of the = above text. I=E2=80=99m definitely in favor of reducing variability in protocols for = better interop, like what CTAP did and Postel Was Wrong makes sense, but = the sorting requirement in canonicalization would be disruptive to more = complex EAT implementations since they stitch together chunks of encoded = CBOR from several sub systems on a device.=20 An implementation could try to sort encoded CBOR, but the variable = lengths and such make that seem like a rather bad idea. LL P.S. I am no longer working for Qualcomm (now that I have them hooked = on CBOR for a few projects), but want to participate here as a private = network citizen. =20 --Apple-Mail=_65A6E79C-F017-4E27-9F98-C20F4348825A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The reason I took a = careful look at CBOR canonicalization was to understand if it was = important in a protocol design (EAT) that was very focused on signed data. It took me a = while and a mistake or two to understand the best way to format the TBS = bytes in CBOR.  Here=E2=80=99s the conclusions in the form of some = text that would have helped me a lot which I hope can be added to one of = the CBOR documents.

How to design signing in CBOR protocols

Any protocol that involves signing needs to define exactly = what the TBS (to-be-signed) bytes are, the exact bytes that are input = the signing and verification operations. There are two main approaches = .

In the first = approach, the data is CBOR encoded as it normally would be. Then the = binary bytes that are the encoded CBOR is wrapped in a bstr.  The = bstr is inserted into the message and transmitted along with the = signature. The value of the bstr is the TBS bytes. 

For example if the encoded CBOR was an integer with the = value 1, that encodes to one byte, 0x01, then the bstr wrapping of that = would be two bytes, 0x41, 0x01.  

In = theory the bstr wrapping could be skipped, but this makes it very = difficult to implement with generic CBOR parsers because they do not = give access to encoded sub-parts of a CBOR = message. 

Canonicalization = of the transmitted data is NOT required. =46rom the signature generation = and verification view, it is even OK if there is variance from message = to message. For example it is OK if integers are encoded in the shortest = form sometimes and sometimes not. It is OK to use definite and = indefinite lengths.

The second less = obvious approach is for the TBS bytes to be constructed by some = precisely defined process. Since CBOR has several different ways of = representing the same data, some form of canonicalization is required = because the sender and the receiver must come up with exactly the same = TBS bytes.  Canonical Encoded CBOR should be used in this case, but = protocols can also define their own rules for canonicalization if they = wish.

The main reason = for choosing this second approach is that it can reduce the = size of the messages transmitted and/or provide flexibility in the way = the data is structured.

In the end, a = good practice is just to use the COSE format for signing as it takes = care of these details. In COSE the payload does NOT need to be = canonicalized.
It seems there is some consensus that = canonicalization should not be in the main CBOR RFC, but I haven=E2=80=99t= seen anything in GitHub for that yet. When that is figured out, I can = make a pull request out of the above text.

I=E2=80=99m definitely in favor of = reducing variability in protocols for better interop, like what CTAP did = and Postel Was Wrong makes sense, but the = sorting requirement in canonicalization would be disruptive to more = complex EAT implementations since they stitch together chunks of encoded = CBOR from several sub systems on a device. 

An implementation could try to sort = encoded CBOR, but the variable lengths and such make that seem like a = rather bad idea.

LL

P.S.  I am no longer working for Qualcomm (now that I = have them hooked on CBOR for a few projects), but want to participate = here as a private network citizen.
 

= --Apple-Mail=_65A6E79C-F017-4E27-9F98-C20F4348825A-- From nobody Tue Jun 19 16:51:40 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9C13101E; Tue, 19 Jun 2018 16:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfWpGZ4PjE09; Tue, 19 Jun 2018 16:51:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DADE131012; Tue, 19 Jun 2018 16:51:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C245F20090; Tue, 19 Jun 2018 20:05:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 69BA8F0; Tue, 19 Jun 2018 19:48:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6706497; Tue, 19 Jun 2018 19:48:26 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Carsten Bormann , cbor@ietf.org, anima@ietf.org In-Reply-To: <8dd31a39-6e66-b7fe-845b-c9ffe3eb02a2@gmail.com> References: <1812.1529420901@localhost> <067929E9-1FF7-48FC-A2DA-FEED1A7489B3@tzi.org> <4918.1529430825@localhost> <8dd31a39-6e66-b7fe-845b-c9ffe3eb02a2@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] [Anima] CDDL-02 section 2.2.2 choices X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:51:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > On 20/06/2018 05:53, Michael Richardson wrote: >> >> Carsten Bormann wrote: >> > 2.2.2 says: >> >> >> It is not an error if a name is first used with a "/=3D" or "//= =3D" >> >> (there is no need to =E2=80=9Ccreate it" with "=3D"). >> >> > The intention is indeed to say that no initial rule with a =E2=80= =9C=3D=E2=80=9C is needed. >> > Any ideas how we can clarify this some more? >> >> Neither Max nor I saw this while we were perusing this part. >> May I suggest that it be moved to be the second paragraph? >> >> > You could also make use of the convention (not currently checked b= y any >> > tool, but that could be done) to mark an extension point with a do= llar >> > sign: >> >> > $transport-proto /=3D IPPROTO_TCP >> >> > (See section 3.9 for more about that convention.) >> >> Ah, interesting. thank you. > However: I suggest not using that in the BRSKI draft. Our emergency p= lan > if CDDL is not yet close to being an RFC is to add a normative append= ix > to GRASP specifying the subset of CDDL that we use, and I'd like to > keep that subset as small as possible. > Even better, CBOR could wrap up the CDDL spec in Montreal. I don't believe that BRSKI will enter the RFC-EDITOR queue before CDDL. If it does, we could fix stuff as you suggest. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWymWSICLcPvd0N1lAQIVDQgAiwMEDlV2530FrClTGRuNZLnSEz9Ar8Bo nYPjgJ/MzKUpvtCq1T8B+eiAtAHJByBvbXykkxYQOFTP1VD3YMxJoN5ulwyEss7w IjxZbUP2XSVJuvZVdQqTJf61JlB45s3u3KWunfYsG/b96iYayeSPquUMYyrYS6gb Hi9dmBBw2OwbrTgWxjbuPjFGw7IeYCz2nXQQVxgH+azckuQeYyCBnH6Kv0jhZena tCDHNV5rQajfOhRPCP1SbbIo7AAJUwM8l46X/4lCH/a64hWgZpMUKeTLpPmU2vD0 z57n2UQpfj/Jzkp8dOnKtvetv0YiL8KchKsNDxlbnwC8aFqsUxUxAA== =OFSG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 25 05:53:39 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA3130DE3 for ; Mon, 25 Jun 2018 05:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ro6KRKUk; dkim=pass (1024-bit key) header.d=ericsson.com header.b=coPvkdIN 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 erSkOWod36MB for ; Mon, 25 Jun 2018 05:53:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90639130DE0 for ; Mon, 25 Jun 2018 05:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529931213; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Drm/GO0jubK6Ostukm/WD2pHul0c0XZnY0UDFmIMusU=; b=Ro6KRKUkHhx5R11ToXw64NIp1hS8q7dTDO5QtMlJcOFgS6cXsHg3inTCb1LyhXvy 01f2HRyfygTPbCp8zO8vAGOqSPTuUN3g/ziSY5aS/NBTwV2KAcJcauDqNR5E4ZF7 btDFY+1e9YG2cP/o6gzndFY60Z1Ny6QZYarCta0J7QI=; X-AuditID: c1b4fb3a-dcb6e9c0000079c1-7c-5b30e5cd4e9e Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.2A.31169.DC5E03B5; Mon, 25 Jun 2018 14:53:33 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.122) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 25 Jun 2018 14:53:28 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 25 Jun 2018 14:53:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Drm/GO0jubK6Ostukm/WD2pHul0c0XZnY0UDFmIMusU=; b=coPvkdINXaXdXqwIJnNRWd+xFDpwDx1BNht3ZMyEY+qNs9TRIFSTWUjh7KY88xdix6wCG9ij3jgO3qbfMIdobGTH8+GYZyqJURUdLLv0+CFcUIPPpsSoAqVk2gT6weq9gnnSK2KOzmaxfiEmS0tKy7iUERMJI2h1+VQGERGsfN4= Received: from AMSPR07MB344.eurprd07.prod.outlook.com (10.242.20.149) by AMSPR07MB373.eurprd07.prod.outlook.com (10.242.21.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.10; Mon, 25 Jun 2018 12:53:27 +0000 Received: from AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::a8aa:563d:8c60:b818]) by AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::a8aa:563d:8c60:b818%2]) with mapi id 15.20.0906.017; Mon, 25 Jun 2018 12:53:27 +0000 From: Francesca Palombini To: Carsten Bormann CC: "draft-ietf-cbor-7049bis@ietf.org" , "cbor@ietf.org" , "cbor-chairs@ietf.org" Thread-Topic: [Cbor] Progressing work on draft-ietf-cbor-7049bis Thread-Index: AdPdaLX8Y4h/ih/5T5G03fZliVt7GwW7CMQAAAhoxoAAf0sDUAADqQaABYAoXxA= Date: Mon, 25 Jun 2018 12:53:26 +0000 Message-ID: References: <001101d3f476$7ed9fd50$7c8df7f0$@augustcellars.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AMSPR07MB373; 7:tAzQgZtYV5S3YFoCaq0YPQawLw8ZCQ+debV9LTSjMGaF2s8Zg6hcLMbCu34gzkb2oxGBklvvuvgZKVgnCdsBejl+jDqZmWJ4q78n8L9xaZszDUrbXPiFBz6xb386rEZaOPvQZJ6MN1zCBh3NI2Y4MkqYFyuKx3kHqjK6cn8IkFlMydtx9YGB3+3EG4SYeFk5KoaP73PJbQNO5Cg/33Zal2otLvjzJB5buBypdScn3OG+9CYvtEbyzUw+Lyo/mKEw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f803a456-f7e1-4b6e-4369-08d5da9aa4f7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:AMSPR07MB373; x-ms-traffictypediagnostic: AMSPR07MB373: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:AMSPR07MB373; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB373; x-forefront-prvs: 0714841678 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(376002)(366004)(396003)(13464003)(199004)(189003)(229853002)(105586002)(5660300001)(106356001)(26005)(305945005)(7736002)(74316002)(44832011)(3280700002)(53546011)(68736007)(478600001)(76176011)(59450400001)(6506007)(3660700001)(5250100002)(33656002)(55016002)(9686003)(102836004)(486006)(7696005)(2900100001)(6436002)(6916009)(6246003)(476003)(81166006)(81156014)(11346002)(446003)(97736004)(66066001)(316002)(8676002)(99286004)(25786009)(2906002)(53936002)(14454004)(86362001)(6116002)(54906003)(8936002)(3846002)(93886005)(186003)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB373; H:AMSPR07MB344.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YDgxUg+0xwv7SCbngHJkN4nT9IYQTc9SZPsDbfY74HUjiwXxKbS0vsxWmWM6RN4382+TR1dS35V0sazZcHc+QT/V2eQgAW6yakcQYyDN+mG1QcodNxxLu3TnN1jjOYwZ2uqyhqPoPL40ZHeIn11DGaAzyRBlfp2w8XpgHNfdi6FWdLtH3nocuQugBLmRMPu8uY4ugJyHY6SMY71IXbLfRqzttYYroLw+4u0Qxo2v0HTRfgvh4yqmBSl9wLoZBtJ8VP5E+tW5ST0XoYajAz5tHTbtNyjO0mvJ2x5DYQbENucBbG9kpCjFodId0RTtHrtihKGK6rBLeTrt5RumZTvVy9vsxFKuPjNIVWYg52jUwN0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f803a456-f7e1-4b6e-4369-08d5da9aa4f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 12:53:26.9342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB373 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42KZGbG9SvfsU4Nog5XnLC2OTLnLajH77xZG i5kd01ksfv5fy+TA4rFkyU8mj2mLMgOYorhsUlJzMstSi/TtErgyrq3bwlKwi7di++/z7A2M PbxdjBwcEgImEh9aVLoYuTiEBI4ySjz4dJAZwvnGKNHWuYwdwlnCJHHv9zmwDIvABGaJg4/7 oTL9TBL/e9+yQDgPGCXuXH7M2sXIycEmYCNx4eF7MFtEQEniwsU1bCBFzAJzGSU6di5iAtku LGAv8eqeIUSNg0TX1ptsELafxKJt51hAbBYBVYltG7exg9i8AlESk57OZINYdpNJ4sHhrYwg CU4Ba4nD81+ANTMKyEp8aVzNDGIzC4hL3HoynwnElhAQkFiy5zwzhC0q8fLxP1aI+mSJK7f7 2CHiChK3lx9ngbBlJS7N72YEWSYhsJlJ4vTPF1DNuhIfpk6Fsn0lGu79YIMoOs8ocWTqaqhJ mhL7F+yDsjMldmy+ywgJbyuJeWdiIcJyEqt6H7JMYDScheTWWUBVzEDd63fpQ4QVJaZ0P2Sf Bfa/oMTJmU9YFjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQITCUHt/y22sF48LnjIUYB DkYlHl61CwbRQqyJZcWVuYcYJTiYlUR47fYDhXhTEiurUovy44tKc1KLDzFKc7AoifM6pVlE CQmkJ5akZqemFqQWwWSZODilGhgd3Ca95//Okf72Xs/XRt0oedEdm3OjlmpsMHY9FxBra1B2 ZhOXfIEu35VvV9UXczNsPXeS/dTza1d97k4PdNv92vvb1OwjAWUhGfYHtiYLOB6pMfh2sJp5 z9/fMUu/cwfU/pvulmXbe9b1w85aV3d+j17Vf6miJ+dftVnj9+a8m8jn/S0FRQuUWIozEg21 mIuKEwHVZE64IQMAAA== Archived-At: Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 12:53:39 -0000 SGkgQ2Fyc3RlbiwgYXV0aG9ycywNCg0KSSBkaWQgbm90IHNlZSB0aGVzZSBtZXJnZXMgYmVpbmcg ZG9uZSwgY291bGQgeW91IHVwZGF0ZSB1cyBvbiB3aGF0IGlzIHRoZSBzdGF0dXM/IFdoYXQgaXMg aG9sZGluZyB0aGVzZSB1cD8NCg0KVGhhbmtzLA0KRnJhbmNlc2NhIA0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0K PiBTZW50OiBkZW4gMjggbWFqIDIwMTggMTQ6NDkNCj4gVG86IEZyYW5jZXNjYSBQYWxvbWJpbmkg PGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPg0KPiBDYzogSmltIFNjaGFhZCA8aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT47IEplZmZyZXkgWWFzc2tpbg0KPiA8anlhc3NraW5AY2hyb21p dW0ub3JnPjsgZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXNAaWV0Zi5vcmc7IGNib3JAaWV0Zi5vcmc7 DQo+IGNib3ItY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ2Jvcl0gUHJvZ3Jlc3Np bmcgd29yayBvbiBkcmFmdC1pZXRmLWNib3ItNzA0OWJpcw0KPiANCj4gT24gTWF5IDI4LCAyMDE4 LCBhdCAxMzoyMywgRnJhbmNlc2NhIFBhbG9tYmluaQ0KPiA8ZnJhbmNlc2NhLnBhbG9tYmluaUBl cmljc3Nvbi5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSSB0aGluayBpdCBpcyB0aW1lIHRvIG1lcmdl OiAxNCwgMTUsIDE5LCAyMC4gQXV0aG9ycywgY291bGQgeW91IGdvIG9uIGFuZA0KPiBtZXJnZSB0 aGVzZT8NCj4gDQo+IFRoaXMgd2VlayBpcyBhIGdvb2Qgd2VlayBmb3IgZ2V0dGluZyBtZXJnZXMg ZG9uZS4NCj4gDQo+IENvbnRyaWJ1dG9yczogUGxlYXNlIGRvIG5vdCBtYWtlIGZvcm1hdHRpbmcg Y2hhbmdlcyB0aGF0IGFyZSB1bnJlbGF0ZWQgdG8NCj4gdGhlIHBhcnQgdGhhdCB5b3UgYXJlIHBy b3Bvc2luZyB0byBjaGFuZ2UuICBUaGlzIGNyZWF0ZXMgbWVyZ2UgY29uZmxpY3RzIGFuZA0KPiBv YnNjdXJlcyB0aGUgY2hhbmdlcyB0aGF0IGFjdHVhbGx5IGFyZSBiZWluZyBtYWRlLiAgKFllcywg dGhlIHNvdXJjZSBpcw0KPiBzb21ld2hhdCBpbmNvbnNpc3RlbnRseSBmb3JtYXR0ZWQgaW4gc29t ZSBwbGFjZXMg4oCUIHRoZSBkYW1hZ2UgdG8gdmVyc2lvbg0KPiBjb250cm9sIGZyb20gZml4aW5n IHRoaXMgaXMgbXVjaCBsYXJnZXIgdGhhbiB0aGUgc2xpZ2h0IGRpc2NvbWZvcnQgd2UNCj4gZXhw ZXJpZW5jZSB3aGVuIHdlIGFyZSBlZGl0aW5nIGl0LikNCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4N Cg0K From nobody Thu Jun 28 00:08:21 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF48130E8D for ; Thu, 28 Jun 2018 00:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=MTAQB53Q; dkim=pass (1024-bit key) header.d=ericsson.com header.b=BoJA0WaV 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 pHGBnosCnKBz for ; Thu, 28 Jun 2018 00:08:17 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7472C12F1AC for ; Thu, 28 Jun 2018 00:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530169695; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=40xcp1lMHbe3WlIs6Dz91wFFMYjjoNMrAPb1YMN2vQo=; b=MTAQB53Q2D4FVP9+EEYBUgwZ0WzMgGIEqXbAgtnJwVbqClXLhKaoEMb+dfM7SCQj QCWEkCxZkKUXw23VnRD3K6095i5AB2sjlr/v/a7U8GO7Dsl9cGgBde+/dLBaH/5J k1TSKTARS8XWwr62Ch07RewJiA+XXmbZPOGlwip4gWQ=; X-AuditID: c1b4fb25-202c69c000006310-dc-5b34895f4b2f Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F9.91.25360.F59843B5; Thu, 28 Jun 2018 09:08:15 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 28 Jun 2018 09:07:30 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 28 Jun 2018 09:07:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRJr/tNN9RNs6K0/gxd+wk+2LFptf+tmYUTMDesGNrA=; b=BoJA0WaVwfN8WmcAkGRpWm3oHBHJf0o55o0aHXBQ+X3NZ8IV2mwhuWh/YfQDSv9bsPjMzXqZXpEIY2SwwomldMRr1ejMzkqmNNYUl3lEYzXODGTqgMNan+IlLQyfAoh67ahEclT9IxI0LM0m9o/B/kuKE2E89ymnLOcnUcXvTDQ= Received: from AMSPR07MB344.eurprd07.prod.outlook.com (10.242.20.149) by AMSPR07MB231.eurprd07.prod.outlook.com (10.242.19.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.20; Thu, 28 Jun 2018 07:07:29 +0000 Received: from AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::a8aa:563d:8c60:b818]) by AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::a8aa:563d:8c60:b818%2]) with mapi id 15.20.0906.023; Thu, 28 Jun 2018 07:07:28 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Slot requests for IETF102 Thread-Index: AdQOrm73Tucd/1XzQwqcHIwrVVKZFA== Date: Thu, 28 Jun 2018 07:07:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AMSPR07MB231; 7:Sb9ewOKZt/am52EMgzigYk2T6grUc/V2c2/gv+xVKzYUmIJF47Z41B1tGobO1dZqVRMGsd38xcfvlkQkU0MR8kVYXDC0jHHUzCgBuUPNr4UkKRmDe2qL3PbtznCxwNdA+Ziy8lyGLi8jIxpqCa1fZbZhYF+AlZ3GPjusvm2y7xIsEHpwsI61EM+ra32Fqn+iQ/bwsU+H5MJHbIwCoCV6R3d9+/xhUEwp0ic2n+une0ng3QjFARyLDXaW+0OpjiUE x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 607cf9b9-b1e5-48e2-b6ea-08d5dcc5cf62 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:AMSPR07MB231; x-ms-traffictypediagnostic: AMSPR07MB231: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AMSPR07MB231; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB231; x-forefront-prvs: 0717E25089 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(396003)(136003)(39860400002)(66544003)(189003)(53754006)(199004)(14454004)(6116002)(25786009)(5660300001)(606006)(97736004)(9686003)(106356001)(105586002)(5640700003)(14444005)(6436002)(2900100001)(86362001)(6916009)(450100002)(966005)(236005)(790700001)(3846002)(53936002)(4326008)(54896002)(55016002)(6306002)(26005)(186003)(5250100002)(2906002)(6506007)(102836004)(68736007)(5630700001)(7696005)(44832011)(74316002)(99286004)(7736002)(2501003)(81156014)(256004)(66066001)(316002)(476003)(2351001)(8936002)(33656002)(1730700003)(8676002)(478600001)(81166006)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB231; H:AMSPR07MB344.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: WIdr7ORmzRmz3HMtzmlAxX9L18+myITDV0lN85isQsM6/Ej+cIwJZ8DjSrLRck81gkRZ8j1hXXjkLl8DvrhgDNGmlPTAr2cDehzyVcBZWwd7JmBEC/bVeVq4FzDYKtyiPG2q06va3uU6GcXjPU7XKq3U2Ds0KcV8JKAI9eEa+neBiwxGkuNSEbzDW1UamQxs/ml1mdZFY+7aXvvDkZHsUohh6KjbpGWO0wGMwY1Pd6EYImBI2GYTVDipTzBWuM4NZjwybXmN6j7180dDtwi2ucTK9Psf3N+s9ROrC6bFxrfm6M/c1RGs3P3Klj9Wgy20ZOzJVMtU/CIl56hcUGi+LPxWJSZFxa1AxtdNEcrYAO8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMSPR07MB3441D239DDF1AEC63252E0B984F0AMSPR07MB344eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 607cf9b9-b1e5-48e2-b6ea-08d5dcc5cf62 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2018 07:07:28.7720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB231 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHO/febXfShdNUfLIsWWnka+ZEMQ0zUCOsyD7YDNzSmy512q6J RqRlks1KC2csDbdcEhP7kEK1ZqSWIBWKLxEZ+JoWZpmJJFnmdhT69nt+z/85nOdwWFrWIPJk Ndp8XqdVZ8vFLowx+bEuMPWqImVXTZVPRO2fVhRhLL/NxFAJFssidQQpXaLS+WxNAa8L3qty yZxv7ER5DdsL790vlZSgt1v1SMoCVkBrZxXSIxdWhl8huNXxUESKBQQ3Z/U0KSwUGOtLGUfB 4CoaPv0oox3zMlxJQc1gIUmNIBibnEKOhhhHQe/od5GD3fA2MFR3ivWIZWkcAov2Mw7tiuVg KF+WkMgOGBp8xxAOgibbpNMz2Ae6DAan57ASrlU2Oo9H2AvmLzY570BjD/gwUU+RfTBY7D00 YXf4Mv5XRPJpMDB0Q0K8HPqWzKsZL+irr3DuD7iFgiu/6sSkEQizBgPtuDPgROhvDyeZHgRl T3+uDu+EqZf9DGENPKirYEg+BZqth4neAtbrowyZta88XNPwan4z2D72SKpQ0J3/diCcC0vW 107m8AboNk4wxAeA6dmcmLA/NJqn6TV+82Kc+t+bkMSK3AVeOJmTsTs0iNdp0gQhVxuk5fMf oZWv09762+cJ6v+6rwNhFsnXc5HlihSZSF0gFOV0IGBpuRvnvX9FcenqonO8LjdVdzabFzrQ JpaRe3Cj4S1KGc5Q5/NZPJ/H69a6FCv1LEFR/j4b207s6U6PjewK+NasqbaJ26TRMcdsXHhx WHFvcjz3/qBrkm1hXaxReilY+XkxakRpbjAL8TlxvtN+qhIVlTSjnqmNTjyQeMp+VJFQM6Z1 ZQJgOW9OKvGNRJILs6Hex0/XjYcduhxD5ZhM5cMV8yplSpY1Tjp8/u7zATkjZKpD/GidoP4H arn/ADYDAAA= Archived-At: Subject: [Cbor] Slot requests for IETF102 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 07:08:20 -0000 --_000_AMSPR07MB3441D239DDF1AEC63252E0B984F0AMSPR07MB344eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have started planning the CBOR session agenda for the IETF102. You can s= ee the draft agenda at https://datatracker.ietf.org/meeting/102/materials/a= genda-102-cbor . If you are interested in having a presentation slot, please send a request = to the chairs with the following details: - Draft - Presenter - Objective: Present an idea, get adoption, ask for feedback/reviewers/... - Time: How much time you think you will need Also, since we will meet in the beginning of the week, it would be good if = the presenters could send the slides the week before the meeting (July 15th= at the latest). See you soon in Montreal, Francesca & Barry --_000_AMSPR07MB3441D239DDF1AEC63252E0B984F0AMSPR07MB344eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have started planning the CBOR session agenda = for the IETF102. You can see the draft agenda at https://datatracker.ietf.org/meeting/102/materials/agenda-102-cbor = .

 

If you are interested in having a presentation sl= ot, please send a request to the chairs with the following details:

 

- Draft

- Presenter

- Objective: Present an idea, get adoption, ask f= or feedback/reviewers/...

- Time: How much time you think you will need

 

Also, since we will meet in the beginning of the = week, it would be good if the presenters could send the slides the week bef= ore the meeting (July 15th at the latest).

 

See you soon in Montreal,

Francesca & Barry

 

--_000_AMSPR07MB3441D239DDF1AEC63252E0B984F0AMSPR07MB344eurprd_--