From nobody Mon Aug 3 08:17:42 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EB01A90EB for ; Mon, 3 Aug 2015 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LScISEFWgsEh for ; Mon, 3 Aug 2015 08:17:39 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BD81A90CD for ; Mon, 3 Aug 2015 08:17:39 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 295632CA11 for ; Mon, 3 Aug 2015 08:17:39 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 3 Aug 2015 08:18:02 -0700 Message-ID: <049901d0cdff$97613870$c623a950$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdDN/ura0lxdFCRhQNOiECT68XLs2Q== Archived-At: Subject: [COSE] Issue: External Authenticated Data X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 15:17:40 -0000 I want to close the issue of allowing for externally provided information to be included in the integrity computation. This was added to the document in order to support the ability of doing integrity protection over CoAP option fields which appears to be a requirement from the ACE documents. The current working document has expanded text dealing with what an application needs to do in order to support this. It also added the concept to signed data, something that I originally did not think was needed. Are there objections to including this concept in the COSE work? Are there people who believe that this is not needed for the ACE work and therefore should be removed? Feel free to comment on the current text as well. Jim From nobody Mon Aug 3 08:21:44 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914BB1A914C for ; Mon, 3 Aug 2015 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpx0JvM9zlzN for ; Mon, 3 Aug 2015 08:21:41 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31C71A90F4 for ; Mon, 3 Aug 2015 08:21:41 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3712F2CA06 for ; Mon, 3 Aug 2015 08:21:41 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 3 Aug 2015 08:22:04 -0700 Message-ID: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdDN/7POlzXYk9TwQjeI18YsQXyCxA== Archived-At: Subject: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 15:21:42 -0000 JOSE concatenates the fields together that are used for doing integrity protection. The current document uses a CBOR array to do the same thing. The use of CBOR array does require a small amount of canonical encoding. However the only thing that is required is minimum length encoding of fields. This should be simple for people to implement. Everything else is just binary wrapped. The method used does enforce fences between the different fields to prevent data bleeding between fields. Are there any objections to this approach? From nobody Mon Aug 3 11:33:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976AF1B2F2F for ; Mon, 3 Aug 2015 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ode0K60dQNcm for ; Mon, 3 Aug 2015 11:33:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE861B2F29 for ; Mon, 3 Aug 2015 11:33:37 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Mon, 3 Aug 2015 18:33:36 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Mon, 3 Aug 2015 18:33:36 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC Thread-Index: AdDN/7POlzXYk9TwQjeI18YsQXyCxAAGwADA Date: Mon, 3 Aug 2015 18:33:35 +0000 Message-ID: References: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> In-Reply-To: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:4tp90HuhydULBX8MH9RMPtvaOHn00Aohq3gEDTTjIhdO+yHr+eshz8haa0E98z6ok1DKFOTP1P6Wa9qRF4dgX/joqrKJ9mukyvF+xgaaJqEfCXzCuCFwsgIMakCs4DReGoR8BeakrrhHzYXTcX+8bQ==; 24:/5Txna9jNjvkg7JzyCBvucG7tougO3XGsGrFPy1ryzC+wlJK7lLsKP7W5le7Qqz+UTR/KwUdK3c3D/e6+Y4CYNNqxrSkoYqdFpzsVFspEOM=; 20:S6+zDlFoD2S5MR3042koYkKAyssCVGGhGzqxCfFg7Lsjq8I0CwfSS9yLLOvUACflNVh7QAXzi39bhI3HwgU2TQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(189002)(377454003)(101416001)(74316001)(105586002)(19580395003)(2900100001)(106356001)(66066001)(99286002)(64706001)(19580405001)(10090500001)(33656002)(575784001)(40100003)(5002640100001)(122556002)(86362001)(62966003)(92566002)(102836002)(15975445007)(50986999)(86612001)(68736005)(77096005)(189998001)(107886002)(87936001)(54356999)(2950100001)(46102003)(2656002)(5001960100002)(97736004)(5001830100001)(5001770100001)(5001860100001)(77156002)(81156007)(4001540100001)(76176999)(76576001)(2501003)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 18:33:35.9555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:33:43 -0000 I think it's a good idea to concatenate all the integrity protected fields = together in the COSE representation. That saves having to create a separat= e concatenation for input to the signature or MAC function. -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, August 03, 2015 8:22 AM To: cose@ietf.org Subject: [COSE] Issue: Use CBOR array rather than concatenation to build st= rings to hash/MAC JOSE concatenates the fields together that are used for doing integrity pro= tection. The current document uses a CBOR array to do the same thing. The use of CBOR array does require a small amount of canonical encoding. However the only thing that is required is minimum length encoding of field= s. This should be simple for people to implement. Everything else is just binary wrapped. The method used does enforce fence= s between the different fields to prevent data bleeding between fields. Are there any objections to this approach? _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c55a34eae7c8a4cb8790008d29c173f31%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3D5g2kakSMDHHdFR2Bm09ezMFIR0tC%2fLlG8QrqNLRtB8g%3d From nobody Mon Aug 3 11:36:57 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC61B2F5E for ; Mon, 3 Aug 2015 11:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGLwIhpEnPmJ for ; Mon, 3 Aug 2015 11:36:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697DD1B2F5C for ; Mon, 3 Aug 2015 11:36:53 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Mon, 3 Aug 2015 18:36:33 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Mon, 3 Aug 2015 18:36:33 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Issue: External Authenticated Data Thread-Index: AdDN/ura0lxdFCRhQNOiECT68XLs2QAHAPQQ Date: Mon, 3 Aug 2015 18:36:33 +0000 Message-ID: References: <049901d0cdff$97613870$c623a950$@augustcellars.com> In-Reply-To: <049901d0cdff$97613870$c623a950$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:/HgutIqPT5In/BNEpr9SAd/qm3D6kka+ySk7mmuhwpY+88XfreTPqn31I7gC+xg1HPHzsVGBURcSDXunqM3GjWNWY/mNqoazZ1IWStQbxMdHn6G+f+Ifog/NZS0IwuiWSrQGk8pHEN/wIIi9ZaeACg==; 24:q6dMx1VGBfHr48/STeoWi/AKO2dki6b1TyTCw4xMZSssfxGUkzAfGi86vWVT8yKnSGpq7We8B3M329UrpxM7Kzy41jzdkEwjqSWtmJX5ShU=; 20:edA+UvXML2zIpWhxikbbSJBT23uj+qc3KHjtXhJPgU8dyT4fFQW3BAJfHx1p8omoTmp4Z+zxgxMXMeSpIr+xog== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51444003)(199003)(189002)(377454003)(52044002)(101416001)(74316001)(105586002)(19580395003)(2900100001)(106356001)(66066001)(99286002)(64706001)(19580405001)(10090500001)(33656002)(575784001)(40100003)(5002640100001)(122556002)(86362001)(62966003)(92566002)(102836002)(15975445007)(50986999)(86612001)(68736005)(77096005)(189998001)(107886002)(87936001)(54356999)(2950100001)(46102003)(2656002)(5001960100002)(97736004)(5001830100001)(5001770100001)(5001860100001)(77156002)(81156007)(4001540100001)(76176999)(76576001)(2501003)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 18:36:33.1881 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [COSE] Issue: External Authenticated Data X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:36:55 -0000 The way that I would suggest that we enable external authenticated data to = be included in the integrity computations is to have the application place = that data in the protected header. I think that we should not provide a to= p-level field for this. It's a corner case that will often not be used, an= d we shouldn't optimize for it. Rather, we should optimize for the case wh= ere there is no externally provided integrity protected data, and allow it = to be included in the set of protected header values, when needed. -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, August 03, 2015 8:18 AM To: cose@ietf.org Subject: [COSE] Issue: External Authenticated Data I want to close the issue of allowing for externally provided information t= o be included in the integrity computation. This was added to the document= in order to support the ability of doing integrity protection over CoAP op= tion fields which appears to be a requirement from the ACE documents. The current working document has expanded text dealing with what an applica= tion needs to do in order to support this. It also added the concept to si= gned data, something that I originally did not think was needed. Are there objections to including this concept in the COSE work? Are there people who believe that this is not needed for the ACE work and t= herefore should be removed? Feel free to comment on the current text as well. Jim _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c7ab20cae993640ef3bf208d29c16af7c%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3D5EJcqh0d676TU8H37EKcmUcCOGxvhOMgiNf9fYmxXzc%3d From nobody Mon Aug 3 12:14:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9521ACD42 for ; Mon, 3 Aug 2015 12:14:35 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwuRNU268u70 for ; Mon, 3 Aug 2015 12:14:34 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369371ACD71 for ; Mon, 3 Aug 2015 12:14:34 -0700 (PDT) Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9AEC938F17; Mon, 3 Aug 2015 12:14:33 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> In-Reply-To: Date: Mon, 3 Aug 2015 12:14:55 -0700 Message-ID: <050501d0ce20$af9d2090$0ed761b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJKMWuTbtzsSQ3+nv7/DLziTWSaWQNnDL3AnOymFbA= Archived-At: Subject: Re: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:14:35 -0000 I am unable to process your position. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, August 03, 2015 11:34 AM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Issue: Use CBOR array rather than concatenation to build > strings to hash/MAC > > I think it's a good idea to concatenate all the integrity protected fields together > in the COSE representation. That saves having to create a separate > concatenation for input to the signature or MAC function. > > -- Mike > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Monday, August 03, 2015 8:22 AM > To: cose@ietf.org > Subject: [COSE] Issue: Use CBOR array rather than concatenation to build strings > to hash/MAC > > JOSE concatenates the fields together that are used for doing integrity > protection. The current document uses a CBOR array to do the same thing. > > The use of CBOR array does require a small amount of canonical encoding. > However the only thing that is required is minimum length encoding of fields. > This should be simple for people to implement. > Everything else is just binary wrapped. The method used does enforce fences > between the different fields to prevent data bleeding between fields. > > Are there any objections to this approach? > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf. > org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro > soft.com%7c55a34eae7c8a4cb8790008d29c173f31%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=5g2kakSMDHHdFR2Bm09ezMFIR0tC%2fLlG8QrqNLRt > B8g%3d From nobody Mon Aug 3 12:14:51 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717C91ACD92 for ; Mon, 3 Aug 2015 12:14:50 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOmj0GoNbI19 for ; Mon, 3 Aug 2015 12:14:49 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5D81ACD87 for ; Mon, 3 Aug 2015 12:14:49 -0700 (PDT) Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9672838EF9; Mon, 3 Aug 2015 12:14:48 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <049901d0cdff$97613870$c623a950$@augustcellars.com> In-Reply-To: Date: Mon, 3 Aug 2015 12:15:11 -0700 Message-ID: <050601d0ce20$b8869f10$2993dd30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIbFlabw4gri1JDnUgMray3wSuZAgKmaTtOnVDhbsA= Archived-At: Subject: Re: [COSE] Issue: External Authenticated Data X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:14:50 -0000 Have you read the ACE draft? > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, August 03, 2015 11:37 AM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Issue: External Authenticated Data > > The way that I would suggest that we enable external authenticated data to be > included in the integrity computations is to have the application place that data > in the protected header. I think that we should not provide a top-level field for > this. It's a corner case that will often not be used, and we shouldn't optimize for > it. Rather, we should optimize for the case where there is no externally provided > integrity protected data, and allow it to be included in the set of protected > header values, when needed. > > -- Mike > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Monday, August 03, 2015 8:18 AM > To: cose@ietf.org > Subject: [COSE] Issue: External Authenticated Data > > I want to close the issue of allowing for externally provided information to be > included in the integrity computation. This was added to the document in order > to support the ability of doing integrity protection over CoAP option fields which > appears to be a requirement from the ACE documents. > > The current working document has expanded text dealing with what an > application needs to do in order to support this. It also added the concept to > signed data, something that I originally did not think was needed. > > Are there objections to including this concept in the COSE work? > > Are there people who believe that this is not needed for the ACE work and > therefore should be removed? > > Feel free to comment on the current text as well. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf. > org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro > soft.com%7c7ab20cae993640ef3bf208d29c16af7c%7c72f988bf86f141af91ab2d > 7cd011db47%7c1&sdata=5EJcqh0d676TU8H37EKcmUcCOGxvhOMgiNf9fYmxXz > c%3d From nobody Mon Aug 3 12:47:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383C91ACD6B for ; Mon, 3 Aug 2015 12:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT1DbyxdeOpV for ; Mon, 3 Aug 2015 12:47:52 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92A81ACD62 for ; Mon, 3 Aug 2015 12:47:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 94B6AE2038; Mon, 3 Aug 2015 15:47:50 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09267-09; Mon, 3 Aug 2015 15:47:49 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 97588E2034; Mon, 3 Aug 2015 15:47:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438631268; bh=Kq0yTbRuS9Dklu4Vx1B1Gcz1IpN9IJtStdv15NFoVU8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=a0jSn8svTCp5fA9dNZEmx0n7J0lgq6u0/ZDdxHLYv6qExDuggRv2YiDwwSOJ6z2af GNxlEDA7CX31QUcBkX5X7vTJa50iCAH5bZFigqRmhduKvPJa5y3nB5hM1pSKFQyfJT q5u5jXEMdfdl/7lVfHPsgxxIGpVV1FsBr7l0U/jY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t73JlmhS026176; Mon, 3 Aug 2015 15:47:48 -0400 From: Derek Atkins To: "Jim Schaad" References: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> Date: Mon, 03 Aug 2015 15:47:48 -0400 In-Reply-To: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> (Jim Schaad's message of "Mon, 3 Aug 2015 08:22:04 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:47:53 -0000 "Jim Schaad" writes: > JOSE concatenates the fields together that are used for doing integrity > protection. The current document uses a CBOR array to do the same thing. > > The use of CBOR array does require a small amount of canonical encoding. > However the only thing that is required is minimum length encoding of > fields. This should be simple for people to implement. > Everything else is just binary wrapped. The method used does enforce fences > between the different fields to prevent data bleeding between fields. > > Are there any objections to this approach? No objection from me. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Aug 3 14:11:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD21A0195 for ; Mon, 3 Aug 2015 14:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyVgLKFwNPsE for ; Mon, 3 Aug 2015 14:11:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4719D1A03AB for ; Mon, 3 Aug 2015 14:11:12 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.231.11; Mon, 3 Aug 2015 21:11:10 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Mon, 3 Aug 2015 21:11:10 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC Thread-Index: AdDN/7POlzXYk9TwQjeI18YsQXyCxAAGwADAAAF+loAAA/xIMA== Date: Mon, 3 Aug 2015 21:11:10 +0000 Message-ID: References: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> <050501d0ce20$af9d2090$0ed761b0$@augustcellars.com> In-Reply-To: <050501d0ce20$af9d2090$0ed761b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [131.107.147.149] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:+FRbJEowA+1LRmw3qFRcledBlyo6nTrr9iLxoK/w3Dh2rWTl4g125XBDkClVUYPQEEm+jPFGvlroQ3gHkWthZPlxjBlIVP2qAYfjQ7O83ZioUW3jKUF9rPEIEVAzj9c/KBRHm9gey4sKtkTZnV6xaw==; 24:uLRWg7/KXiqmHRZY3xw0gyC+TD2dten0AfuW18aWf6SI9t2VuRV5n2rZEFgg7ta7sZRQAtMMyCSX8zqxanI1ofWLJ1CwysVCKPODbFrUS7g=; 20:tJ7ib5ujhraCGcGkImHomGqerZEBoxyQeUWiFxHQALudR2oRdFAKBESWeUWmS9lkunZFSGGqR+4w9soM7SsU1A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(189002)(199003)(92566002)(77156002)(33656002)(86362001)(97736004)(5001960100002)(19580395003)(4001540100001)(5001830100001)(87936001)(2656002)(106356001)(40100003)(81156007)(46102003)(5001860100001)(575784001)(5001770100001)(105586002)(62966003)(99286002)(107886002)(66066001)(76176999)(68736005)(50986999)(5002640100001)(19580405001)(86612001)(64706001)(76576001)(77096005)(15975445007)(122556002)(5003600100002)(54356999)(74316001)(189998001)(2950100001)(2900100001)(102836002)(101416001)(10090500001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 21:11:10.3161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 21:11:15 -0000 If I correctly understood your statement "The current document uses a CBOR = array to do the same thing", to mean that COSE now concatenates all the int= egrity protected fields, then I was writing to support your position. -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Monday, August 03, 2015 12:15 PM To: Mike Jones; cose@ietf.org Subject: RE: [COSE] Issue: Use CBOR array rather than concatenation to buil= d strings to hash/MAC I am unable to process your position. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, August 03, 2015 11:34 AM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Issue: Use CBOR array rather than concatenation to build > strings to hash/MAC >=20 > I think it's a good idea to concatenate all the integrity protected=20 > fields together > in the COSE representation. That saves having to create a separate=20 > concatenation for input to the signature or MAC function. >=20 > -- Mike >=20 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Monday, August 03, 2015 8:22 AM > To: cose@ietf.org > Subject: [COSE] Issue: Use CBOR array rather than concatenation to=20 > build strings > to hash/MAC >=20 > JOSE concatenates the fields together that are used for doing=20 > integrity protection. The current document uses a CBOR array to do the s= ame thing. >=20 > The use of CBOR array does require a small amount of canonical encoding. > However the only thing that is required is minimum length encoding of fields. > This should be simple for people to implement. > Everything else is just binary wrapped. The method used does enforce fences > between the different fields to prevent data bleeding between fields. >=20 > Are there any objections to this approach? >=20 >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf. > org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micro > soft.com%7c55a34eae7c8a4cb8790008d29c173f31%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=3D5g2kakSMDHHdFR2Bm09ezMFIR0tC%2fLlG8QrqNLRt > B8g%3d From nobody Mon Aug 3 14:19:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF91A1A76 for ; Mon, 3 Aug 2015 14:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6-rMzNZs4cx for ; Mon, 3 Aug 2015 14:19:42 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6851A1A0B for ; Mon, 3 Aug 2015 14:19:42 -0700 (PDT) Received: by iodd187 with SMTP id d187so157218560iod.2 for ; Mon, 03 Aug 2015 14:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rmKrZsYaGL23G3VopopBphYdnsPhIr7H7NKxMOdik9E=; b=FZ+SbKqqk1J/VRfp44UeygkO0DZ4p8QPpD3fF99cklRie3hyBzULM5fR4ySL+3qPiC S+B8mwpDjjM69EnwhnNpTCajXFqs16q4P2b3fBdc/JlyLT4Jk8CsWJqQwb2nMXsKMvNd t8CGjrXqI2ORa9bPCAxFSkrm9PEe88iauXeAs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rmKrZsYaGL23G3VopopBphYdnsPhIr7H7NKxMOdik9E=; b=U/qtE1gEKIpUPObrWtPmVeSGnO/zi22LdlCtMWLxeoNYT2gWiEGKf0CkuRoZCm66Iz /BzTgPmj5LCS5WoClNjpjmW5GCfoudtZoKwB7N3/7Xk43FuPcUScY5FClrn8jOQZlbCE PAoYEtkYrwTszk8Nl2AhDS3lGrGlcBWE7Pg2WC64KB48gti/zHk4Qu8v5PB83JDd2nRc 5ewVN2kCLxI8cy68VCsjlFHjZ1pZaRc6gXxcZhQHfh/ohbKvbNoHIQVcy1U++tQyDSbo RT8b6bF1HKHonwAAoM3czLDR23mCUYnES4QxlUlzgUgNLmKUDHUvzbpokxXdjiaLoSnN ybVw== X-Gm-Message-State: ALoCoQnAQ1uksagzoz5cvcjx9UXxLqLheipxlKLEFsIVLvQoN9Motn9Z5tK9DaFTUY7CrNcAwW5h X-Received: by 10.107.11.83 with SMTP id v80mr83733ioi.95.1438636782122; Mon, 03 Aug 2015 14:19:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Mon, 3 Aug 2015 14:19:12 -0700 (PDT) In-Reply-To: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> From: Brian Campbell Date: Mon, 3 Aug 2015 15:19:12 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113eeb525c158e051c6ebaaa Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 21:19:44 -0000 --001a113eeb525c158e051c6ebaaa Content-Type: text/plain; charset=UTF-8 I'm not sure what you mean that there is no legacy that needs to be supported for COSE? Short of implementing algorithms from scratch, which I expect to be very rare, COSE implementations will be constrained in their algorithm support by what is available from the the underlying platform or easily accessible libraries. >From what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly available and most widely used RSA based signature mechanism. If RSA is being included for completeness, RSASSA-PKCS1-v1_5 should also be included. A default installation of Java, for example, doesn't have RSASSA-PSS support. Google's whole federated identity system, as another example, only supports JWS's RS256 to sign its JWT is tokens. On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad wrote: > I am currently in the process of updating/expanding the text for RSA. This > message is what I am using the control the decision process. > > * The world of IoT is not interested (or so close to not interested) in > using RSA that it could be ignored from that point of view. Therefore RSA > is being included as for completeness as anything else. There may be some > other items that port over and use RSA, but it is expected that most are > going to use EC instead. > > * There is no legacy that needs to be supported for COSE. This means > that > there is no pressing need to support any of the RSA v1.5 algorithms. Any > code that needs to have RSA can use the "modern" versions. > > * We do want to support both public keys and private keys in the COSE key > structure. > > * There is sufficient reason to support all three if the "standard" SHA-2 > hash algorithms with all of the RSA algorithms. This means that PSS and > OAEP for SHA-256, SHA-384 and SHA-512. > > * As IoT does not have an interest in these algorithms, there is no reason > to waste precious one byte algorithm identifiers on them. They will get > two > byte algorithm identifiers. > > If anyone has problems with this, please let me know. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a113eeb525c158e051c6ebaaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure what you mean that there i= s no legacy that needs to be supported for COSE?

Short of imp= lementing algorithms from scratch, which I expect to be very rare, COSE imp= lementations will be constrained in their algorithm support by what is avai= lable from the the underlying platform or easily accessible libraries.
=
From what I've seen, RSASSA-PKCS1-v1_5 is still the most= commonly available and most widely used RSA based signature mechanism.=C2= =A0 If RSA is being included for completeness, RSASSA-PKCS1-v1_5 should als= o be included.

A default installation of Java, for = example, doesn't have RSASSA-PSS support. Google's whole federated = identity system, as another example, only supports JWS's RS256 to sign = its JWT is tokens.








=




On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad <i= etf@augustcellars.com> wrote:
I am currently in the process of updating/expanding the text for RSA.=C2= =A0 This
message is what I am using the control the decision process.

*=C2=A0 The world of IoT is not interested (or so close to not interested) = in
using RSA that it could be ignored from that point of view.=C2=A0 Therefore= RSA
is being included as for completeness as anything else.=C2=A0 =C2=A0There m= ay be some
other items that port over and use RSA, but it is expected that most are going to use EC instead.

*=C2=A0 There is no legacy that needs to be supported for COSE.=C2=A0 =C2= =A0This means that
there is no pressing need to support any of the RSA v1.5 algorithms.=C2=A0 = Any
code that needs to have RSA can use the "modern" versions.

*=C2=A0 We do want to support both public keys and private keys in the COSE= key
structure.

*=C2=A0 There is sufficient reason to support all three if the "standa= rd" SHA-2
hash algorithms with all of the RSA algorithms.=C2=A0 This means that PSS a= nd
OAEP for SHA-256, SHA-384 and SHA-512.

*=C2=A0 As IoT does not have an interest in these algorithms, there is no r= eason
to waste precious one byte algorithm identifiers on them.=C2=A0 They will g= et two
byte algorithm identifiers.

If anyone has problems with this, please let me know.

Jim


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

--001a113eeb525c158e051c6ebaaa-- From nobody Mon Aug 3 15:26:09 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82FA1B2B2C for ; Mon, 3 Aug 2015 15:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b4ctjjOj5kd for ; Mon, 3 Aug 2015 15:26:04 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 20F0A1ACED2 for ; Mon, 3 Aug 2015 15:26:04 -0700 (PDT) Received: by igbij6 with SMTP id ij6so63396347igb.1 for ; Mon, 03 Aug 2015 15:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4gTKJlFgMxJGo4uEF/AoyRIVZbqOPslx9133X0g56So=; b=BJNxmux5fLx3xcq5MPvNeLCznL1hAMYgT8+p6KaHuwcPR420G3AT5wMYp2wtm3xIDA q+Q6PSqJOpAuWdRJGln6kDFF6kijwacx5bfcbZszOhuTisJ8nGtX0Itc7rlyCupcKizl 4HRJpViV8/2y1W58xbufMFA6vmQjF2sosqSew= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4gTKJlFgMxJGo4uEF/AoyRIVZbqOPslx9133X0g56So=; b=G517Zn1nxht9bUS/e5D7fOivC9etOTa8XmPi251LsSYOgXwbo4fx0IhnEfiQhERjLy duT0F7o7Pw/8m1StAdqQxFQfR+GoZ6LJHgv2StRvLjN4tyIt7LAuLV1Fe1sWd7GOQ8aB 2zfRUun36WGQQbkpNxhzGBl544WmJ6AgiKdh2S98W7cZyjchtwza7grNlsXZsmgcjaMG GkUSdp+u6i8bRtP7xYcaOc6be5P/6cLzavo2sBcBc606rataQqeuRVvCg0brT6mb9xyq K0ckgM3zMPsMgMmFwVV/rP0FGyvFsgemYLW6AqI0COzi/P0jbjtuUMUtj0hOlJw4VFWe gwyQ== X-Gm-Message-State: ALoCoQmFr6MExco9D3cBp/BKl+4x5Entu/XZCJa5bw+OPItNtrz5HOs3ecycIvB/AcJgtN3Ps0px X-Received: by 10.50.64.147 with SMTP id o19mr473101igs.15.1438640763593; Mon, 03 Aug 2015 15:26:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Mon, 3 Aug 2015 15:25:34 -0700 (PDT) In-Reply-To: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> From: Brian Campbell Date: Mon, 3 Aug 2015 16:25:34 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7bea2f98ac8708051c6fa71d Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 22:26:06 -0000 --047d7bea2f98ac8708051c6fa71d Content-Type: text/plain; charset=UTF-8 "is tokens" should say "id tokens" On Mon, Aug 3, 2015 at 3:19 PM, Brian Campbell wrote: > I'm not sure what you mean that there is no legacy that needs to be > supported for COSE? > > Short of implementing algorithms from scratch, which I expect to be very > rare, COSE implementations will be constrained in their algorithm support > by what is available from the the underlying platform or easily accessible > libraries. > > From what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly > available and most widely used RSA based signature mechanism. If RSA is > being included for completeness, RSASSA-PKCS1-v1_5 should also be included. > > A default installation of Java, for example, doesn't have RSASSA-PSS > support. Google's whole federated identity system, as another example, only > supports JWS's RS256 to sign its JWT is tokens. > > > > > > > > > > > > > > On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad > wrote: > >> I am currently in the process of updating/expanding the text for RSA. >> This >> message is what I am using the control the decision process. >> >> * The world of IoT is not interested (or so close to not interested) in >> using RSA that it could be ignored from that point of view. Therefore RSA >> is being included as for completeness as anything else. There may be >> some >> other items that port over and use RSA, but it is expected that most are >> going to use EC instead. >> >> * There is no legacy that needs to be supported for COSE. This means >> that >> there is no pressing need to support any of the RSA v1.5 algorithms. Any >> code that needs to have RSA can use the "modern" versions. >> >> * We do want to support both public keys and private keys in the COSE key >> structure. >> >> * There is sufficient reason to support all three if the "standard" SHA-2 >> hash algorithms with all of the RSA algorithms. This means that PSS and >> OAEP for SHA-256, SHA-384 and SHA-512. >> >> * As IoT does not have an interest in these algorithms, there is no >> reason >> to waste precious one byte algorithm identifiers on them. They will get >> two >> byte algorithm identifiers. >> >> If anyone has problems with this, please let me know. >> >> Jim >> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> > > --047d7bea2f98ac8708051c6fa71d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"is tokens" should say "id tokens"
=

On Mon, Aug= 3, 2015 at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I'm not sure what you mean that there is no legacy that nee= ds to be supported for COSE?

Short of implementing algorithms= from scratch, which I expect to be very rare, COSE implementations will be= constrained in their algorithm support by what is available from the the u= nderlying platform or easily accessible libraries.

From = what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly available = and most widely used RSA based signature mechanism.=C2=A0 If RSA is being i= ncluded for completeness, RSASSA-PKCS1-v1_5 should also be included.

A default installation of Java, for example, doesn't = have RSASSA-PSS support. Google's whole federated identity system, as a= nother example, only supports JWS's RS256 to sign its JWT is tokens.












On Thu, Jul 30, 2015 at 4:32 PM, = Jim Schaad <ietf@augustcellars.com> wrote:
I am currently in the process of updating/expanding t= he text for RSA.=C2=A0 This
message is what I am using the control the decision process.

*=C2=A0 The world of IoT is not interested (or so close to not interested) = in
using RSA that it could be ignored from that point of view.=C2=A0 Therefore= RSA
is being included as for completeness as anything else.=C2=A0 =C2=A0There m= ay be some
other items that port over and use RSA, but it is expected that most are going to use EC instead.

*=C2=A0 There is no legacy that needs to be supported for COSE.=C2=A0 =C2= =A0This means that
there is no pressing need to support any of the RSA v1.5 algorithms.=C2=A0 = Any
code that needs to have RSA can use the "modern" versions.

*=C2=A0 We do want to support both public keys and private keys in the COSE= key
structure.

*=C2=A0 There is sufficient reason to support all three if the "standa= rd" SHA-2
hash algorithms with all of the RSA algorithms.=C2=A0 This means that PSS a= nd
OAEP for SHA-256, SHA-384 and SHA-512.

*=C2=A0 As IoT does not have an interest in these algorithms, there is no r= eason
to waste precious one byte algorithm identifiers on them.=C2=A0 They will g= et two
byte algorithm identifiers.

If anyone has problems with this, please let me know.

Jim


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


--047d7bea2f98ac8708051c6fa71d-- From nobody Mon Aug 3 16:37:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716161B31BA for ; Mon, 3 Aug 2015 16:36:56 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UPIJwMRrWJ2 for ; Mon, 3 Aug 2015 16:36:51 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B8B1A6EF0 for ; Mon, 3 Aug 2015 16:36:51 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 4720338EF1; Mon, 3 Aug 2015 16:36:51 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <049a01d0ce00$27a87e20$76f97a60$@augustcellars.com> <050501d0ce20$af9d2090$0ed761b0$@augustcellars.com> In-Reply-To: Date: Mon, 3 Aug 2015 16:37:14 -0700 Message-ID: <056001d0ce45$53fc3fd0$fbf4bf70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJKMWuTbtzsSQ3+nv7/DLziTWSaWQNnDL3AATsSgxACqXbzvpzNyvdQ Archived-At: Subject: Re: [COSE] Issue: Use CBOR array rather than concatenation to build strings to hash/MAC X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:36:56 -0000 Ok - I was not sure if you were saying that it should be a CBOR array or just concatenate things together. The sentence was not clear. Thanks for doing the clarification. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, August 03, 2015 2:11 PM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Issue: Use CBOR array rather than concatenation to build > strings to hash/MAC > > If I correctly understood your statement "The current document uses a CBOR > array to do the same thing", to mean that COSE now concatenates all the > integrity protected fields, then I was writing to support your position. > > -- Mike > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Monday, August 03, 2015 12:15 PM > To: Mike Jones; cose@ietf.org > Subject: RE: [COSE] Issue: Use CBOR array rather than concatenation to build > strings to hash/MAC > > I am unable to process your position. > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Monday, August 03, 2015 11:34 AM > > To: Jim Schaad; cose@ietf.org > > Subject: RE: [COSE] Issue: Use CBOR array rather than concatenation to > build > > strings to hash/MAC > > > > I think it's a good idea to concatenate all the integrity protected > > fields > together > > in the COSE representation. That saves having to create a separate > > concatenation for input to the signature or MAC function. > > > > -- Mike > > > > -----Original Message----- > > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: Monday, August 03, 2015 8:22 AM > > To: cose@ietf.org > > Subject: [COSE] Issue: Use CBOR array rather than concatenation to > > build > strings > > to hash/MAC > > > > JOSE concatenates the fields together that are used for doing > > integrity protection. The current document uses a CBOR array to do the same > thing. > > > > The use of CBOR array does require a small amount of canonical encoding. > > However the only thing that is required is minimum length encoding of > fields. > > This should be simple for people to implement. > > Everything else is just binary wrapped. The method used does enforce > fences > > between the different fields to prevent data bleeding between fields. > > > > Are there any objections to this approach? > > > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf. > > > org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro > > > soft.com%7c55a34eae7c8a4cb8790008d29c173f31%7c72f988bf86f141af91ab2 > > > d7cd011db47%7c1&sdata=5g2kakSMDHHdFR2Bm09ezMFIR0tC%2fLlG8QrqNLRt > > B8g%3d From nobody Mon Aug 3 17:00:03 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8701B31E1 for ; Mon, 3 Aug 2015 17:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrVxnCRqs3yk for ; Mon, 3 Aug 2015 17:00:00 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017DB1ACEA4 for ; Mon, 3 Aug 2015 17:00:00 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 76FF538EF1; Mon, 3 Aug 2015 16:59:59 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> In-Reply-To: Date: Mon, 3 Aug 2015 17:00:22 -0700 Message-ID: <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0562_01D0CE0D.E30B7520" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmieSfc9wA== Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:00:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0562_01D0CE0D.E30B7520 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When I said there is no legacy, I was referring to the fact that there = is currently no code base that is using COSE as a message format. This = is different than JOSE where, as you point out, there is a large amount = of RSA v1.5 that was being used even before the JOSE specifications were = really finalized. =20 There is an interesting question of where COSE is going to be used. For = the constrained world, I would think that we could eliminated RSA and = they would just yawn for the most part. So there are two questions: = Where outside of constrained environments is COSE going to be used? How = badly do we feel about the security problems with RSA v1.5? =20 I don=E2=80=99t know the answer to the first question. =20 =20 On the second question I have opinions. RSA has opinions and the = IAB/IESG has opinions. =20 >From PKCS#1 dated Feb 2003 =20 Two encryption schemes are specified in this document: RSAES-OAEP and RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications. =20 I think that I have seen similar language coming from the Sec Area = Directorate, the IESG and IAB (although perhaps as individuals). =20 =20 This is an opinion that I share. There are too many different ways to = get attacks on PKCS #1 v1.5 to keep it as a primary system. I would = prefer to make people install up-to-date security systems that to = continue using the old algorithms. This means that I don=E2=80=99t = really worry about the fact that it is not supported in all = environments. We are not currently supporting DH or DSA either, we are = assuming that people are going to be able to support the EC versions of = those algorithms. The statement above is far enough ago in the past = that we should be willing to accept it and move forward. =20 I would be perfectly willing to deprecate all of RSA, the only question = is do we need to keep it for some type of fail over point. =20 jim =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Monday, August 03, 2015 3:26 PM To: Jim Schaad Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions =20 "is tokens" should say "id tokens" =20 On Mon, Aug 3, 2015 at 3:19 PM, Brian Campbell = > wrote: I'm not sure what you mean that there is no legacy that needs to be = supported for COSE?=20 Short of implementing algorithms from scratch, which I expect to be very = rare, COSE implementations will be constrained in their algorithm = support by what is available from the the underlying platform or easily = accessible libraries.=20 >From what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly = available and most widely used RSA based signature mechanism. If RSA is = being included for completeness, RSASSA-PKCS1-v1_5 should also be = included. =20 A default installation of Java, for example, doesn't have RSASSA-PSS = support. Google's whole federated identity system, as another example, = only supports JWS's RS256 to sign its JWT is tokens. =20 =20 =20 On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad > wrote: I am currently in the process of updating/expanding the text for RSA. = This message is what I am using the control the decision process. * The world of IoT is not interested (or so close to not interested) in using RSA that it could be ignored from that point of view. Therefore = RSA is being included as for completeness as anything else. There may be = some other items that port over and use RSA, but it is expected that most are going to use EC instead. * There is no legacy that needs to be supported for COSE. This means = that there is no pressing need to support any of the RSA v1.5 algorithms. = Any code that needs to have RSA can use the "modern" versions. * We do want to support both public keys and private keys in the COSE = key structure. * There is sufficient reason to support all three if the "standard" = SHA-2 hash algorithms with all of the RSA algorithms. This means that PSS and OAEP for SHA-256, SHA-384 and SHA-512. * As IoT does not have an interest in these algorithms, there is no = reason to waste precious one byte algorithm identifiers on them. They will get = two byte algorithm identifiers. If anyone has problems with this, please let me know. Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 =20 ------=_NextPart_000_0562_01D0CE0D.E30B7520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

When I said there is no legacy, I was referring to the fact that = there is currently no code base that is using COSE as a message = format.=C2=A0 This is different than JOSE where, as you point out, there = is a large amount of RSA v1.5 that was being used even before the JOSE = specifications were really finalized.

 

There is an interesting question of where COSE is going to be = used.=C2=A0 For the constrained world, I would think that we could = eliminated RSA and they would just yawn for the most part.=C2=A0 So = there are two questions:=C2=A0 Where outside of constrained environments = is COSE going to be used?=C2=A0 How badly do we feel about the security = problems with RSA v1.5?

 

I don=E2=80=99t know the answer to the first question.=C2=A0 =

 

On the second question I have opinions.=C2=A0 RSA has opinions and = the IAB/IESG has opinions.

 

From PKCS#1 dated Feb 2003

 

=C2=A0=C2=A0 Two = encryption schemes are specified in this document: RSAES-OAEP = and

=C2=A0=C2=A0 = RSAES-PKCS1-v1_5.=C2=A0 RSAES-OAEP is recommended for new = applications;

=C2=A0=C2=A0 = RSAES-PKCS1-v1_5 is included only for compatibility with = existing

=C2=A0=C2=A0 = applications, and is not recommended for new = applications.

 

I think that I have seen similar language coming from the Sec Area = Directorate, the IESG and IAB (although perhaps as = individuals).=C2=A0=C2=A0

 

This is an opinion that I share.=C2=A0 There are too many different = ways to get attacks on PKCS #1 v1.5 to keep it as a primary = system.=C2=A0=C2=A0 I would prefer to make people install up-to-date = security systems that to continue using the old algorithms.=C2=A0 This = means that I don=E2=80=99t really worry about the fact that it is not = supported in all environments.=C2=A0 We are not currently supporting DH = or DSA either, we are assuming that people are going to be able to = support the EC versions of those algorithms.=C2=A0 The statement above = is far enough ago in the past that we should be willing to accept it and = move forward.

 

I would be perfectly willing to deprecate all of RSA, the only = question is do we need to keep it for some type of fail over = point.

 

jim

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, = August 03, 2015 3:26 PM
To: Jim Schaad
Cc: = cose@ietf.org
Subject: Re: [COSE] RSA Algorithm = Decisions

 

"is tokens" should say "id = tokens"

 

On Mon, = Aug 3, 2015 at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

I'm not sure what you = mean that there is no legacy that needs to be supported for COSE? =

Short of implementing algorithms from = scratch, which I expect to be very rare, COSE implementations will be = constrained in their algorithm support by what is available from the the = underlying platform or easily accessible libraries. =

From what I've seen, = RSASSA-PKCS1-v1_5 is still the most commonly available and most widely = used RSA based signature mechanism.  If RSA is being included for = completeness, RSASSA-PKCS1-v1_5 should also be = included.

 

A default installation of Java, for = example, doesn't have RSASSA-PSS support. Google's whole federated = identity system, as another example, only supports JWS's RS256 to sign = its JWT is tokens.

 

 






<= /div>

 

On Thu, = Jul 30, 2015 at 4:32 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I am = currently in the process of updating/expanding the text for RSA.  = This
message is what I am using the control the decision = process.

*  The world of IoT is not interested (or so close = to not interested) in
using RSA that it could be ignored from that = point of view.  Therefore RSA
is being included as for = completeness as anything else.   There may be some
other = items that port over and use RSA, but it is expected that most = are
going to use EC instead.

*  There is no legacy that = needs to be supported for COSE.   This means that
there is = no pressing need to support any of the RSA v1.5 algorithms.  = Any
code that needs to have RSA can use the "modern" = versions.

*  We do want to support both public keys and = private keys in the COSE key
structure.

*  There is = sufficient reason to support all three if the "standard" = SHA-2
hash algorithms with all of the RSA algorithms.  This = means that PSS and
OAEP for SHA-256, SHA-384 and = SHA-512.

*  As IoT does not have an interest in these = algorithms, there is no reason
to waste precious one byte algorithm = identifiers on them.  They will get two
byte algorithm = identifiers.

If anyone has problems with this, please let me = know.

Jim


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

 

 

------=_NextPart_000_0562_01D0CE0D.E30B7520-- From nobody Tue Aug 4 06:21:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30481A9145 for ; Tue, 4 Aug 2015 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHpzMNVyHRF0 for ; Tue, 4 Aug 2015 06:21:33 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 3DB4C1A90ED for ; Tue, 4 Aug 2015 06:21:33 -0700 (PDT) Received: by ioeg141 with SMTP id g141so16332443ioe.3 for ; Tue, 04 Aug 2015 06:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5VnXa5xCB9ByHyhwMyUytZBppY1snTaMKiiYdtDuvno=; b=OlQVSzsAUvQTgva8l3RZpqNhuiXYdG7/HVfcyEV/wtKN2phXzNqF8Wj1TvgCkR+FRJ 9X+Q2YRu3fPpXb61IW1P2vapoD61xMI+YnvjdcD3yK6yGW5jzFiIKklenCrb/dBBCFin mg81N8nYv3f+DvROYBhoGBIyvuc9NsA4/mdGQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5VnXa5xCB9ByHyhwMyUytZBppY1snTaMKiiYdtDuvno=; b=KonlNMMJ6r2N34SkBgw0dtPyRLrMpyDKYqOlME2n8E4vFOZa0+EN4CbhZospcZmGZa QG4dYVtAEwHsA/Vn66GQbym75yotO66l4gwfVqHdGw3CMs5UysIv8XMy7If+wP8+bRIQ E7NlPgBPVSFx69C6syOPWoJp7Q8xcbzcsgtDn8irv8s4TPzKQUjKjo2SRyKzQjQH2/Cw cCTvXdlW3ZsKm+ANPk1sW0+KIbk0CT7KexFTNf9UxuAGHwZBBjSw1GyrsDQGbYKmPwTu VEWllNkfmRI7m0MNz8hL6hmh6vL6mXrQVAvHqgvrE3YQMKsgt8ckZSba5C8B3vigYGVp Lg1A== X-Gm-Message-State: ALoCoQkbr0JfTy/aT81B+aSaDlzQ4Q6HTOflfxIUpYET4Udh5pgcRqygvMoqL1PqHBiKwKxX2JSu X-Received: by 10.107.32.147 with SMTP id g141mr3272449iog.86.1438694492634; Tue, 04 Aug 2015 06:21:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Tue, 4 Aug 2015 06:21:03 -0700 (PDT) In-Reply-To: <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> From: Brian Campbell Date: Tue, 4 Aug 2015 07:21:03 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1141bb8a2ca365051c7c2ae5 Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:21:36 -0000 --001a1141bb8a2ca365051c7c2ae5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The suggestion was that RSASSA-PKCS1-v1_5 be included as a signature scheme, not for RSAES-PKCS1-v1_5 as an encryption scheme. The latter has known issues and support for the recommended alternative of RSAES-OAEP is fairly widespread. On the former, according to PKCS#1 V2.2, dated Oct 2012, "no attacks are known against RSASSA-PKCS1-v1_5". And support for the alternative RSASSA-PSS isn't particularly extensive. And you've misconstrued what I was trying say about JOSE and RSASSA-PKCS1-v1_5. I was suggesting that Google (a decent sized company with some resources at its disposal and services used by a few people) choosing RS256 as the only JWS algorithm they use to sign ID tokens says something about the usage, availability and security of the RSA based signature schemes in the real world deployments. On Mon, Aug 3, 2015 at 6:00 PM, Jim Schaad wrote: > When I said there is no legacy, I was referring to the fact that there is > currently no code base that is using COSE as a message format. This is > different than JOSE where, as you point out, there is a large amount of R= SA > v1.5 that was being used even before the JOSE specifications were really > finalized. > > > > There is an interesting question of where COSE is going to be used. For > the constrained world, I would think that we could eliminated RSA and the= y > would just yawn for the most part. So there are two questions: Where > outside of constrained environments is COSE going to be used? How badly = do > we feel about the security problems with RSA v1.5? > > > > I don=E2=80=99t know the answer to the first question. > > > > On the second question I have opinions. RSA has opinions and the IAB/IES= G > has opinions. > > > > From PKCS#1 dated Feb 2003 > > > > Two encryption schemes are specified in this document: RSAES-OAEP and > > RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; > > RSAES-PKCS1-v1_5 is included only for compatibility with existing > > applications, and is not recommended for new applications. > > > > I think that I have seen similar language coming from the Sec Area > Directorate, the IESG and IAB (although perhaps as individuals). > > > > This is an opinion that I share. There are too many different ways to ge= t > attacks on PKCS #1 v1.5 to keep it as a primary system. I would prefer = to > make people install up-to-date security systems that to continue using th= e > old algorithms. This means that I don=E2=80=99t really worry about the f= act that > it is not supported in all environments. We are not currently supporting > DH or DSA either, we are assuming that people are going to be able to > support the EC versions of those algorithms. The statement above is far > enough ago in the past that we should be willing to accept it and move > forward. > > > > I would be perfectly willing to deprecate all of RSA, the only question i= s > do we need to keep it for some type of fail over point. > > > > jim > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, August 03, 2015 3:26 PM > *To:* Jim Schaad > *Cc:* cose@ietf.org > *Subject:* Re: [COSE] RSA Algorithm Decisions > > > > "is tokens" should say "id tokens" > > > > On Mon, Aug 3, 2015 at 3:19 PM, Brian Campbell > wrote: > > I'm not sure what you mean that there is no legacy that needs to be > supported for COSE? > > Short of implementing algorithms from scratch, which I expect to be very > rare, COSE implementations will be constrained in their algorithm support > by what is available from the the underlying platform or easily accessibl= e > libraries. > > From what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly > available and most widely used RSA based signature mechanism. If RSA is > being included for completeness, RSASSA-PKCS1-v1_5 should also be include= d. > > > > A default installation of Java, for example, doesn't have RSASSA-PSS > support. Google's whole federated identity system, as another example, on= ly > supports JWS's RS256 to sign its JWT is tokens. > > > > > > > > > > > > > On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad > wrote: > > I am currently in the process of updating/expanding the text for RSA. Th= is > message is what I am using the control the decision process. > > * The world of IoT is not interested (or so close to not interested) in > using RSA that it could be ignored from that point of view. Therefore RS= A > is being included as for completeness as anything else. There may be so= me > other items that port over and use RSA, but it is expected that most are > going to use EC instead. > > * There is no legacy that needs to be supported for COSE. This means > that > there is no pressing need to support any of the RSA v1.5 algorithms. Any > code that needs to have RSA can use the "modern" versions. > > * We do want to support both public keys and private keys in the COSE ke= y > structure. > > * There is sufficient reason to support all three if the "standard" SHA-= 2 > hash algorithms with all of the RSA algorithms. This means that PSS and > OAEP for SHA-256, SHA-384 and SHA-512. > > * As IoT does not have an interest in these algorithms, there is no reas= on > to waste precious one byte algorithm identifiers on them. They will get > two > byte algorithm identifiers. > > If anyone has problems with this, please let me know. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > > --001a1141bb8a2ca365051c7c2ae5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The suggestion was that RSASSA-PKCS1-v1_5 be included= as a signature scheme, not for RSAES-PKCS1-v1_5 as an encryption scheme. T= he latter has known issues and support for the recommended alternative of R= SAES-OAEP is fairly widespread. On the former, according to PKCS#1 V2.2, da= ted Oct 2012, "no attacks are known against RSASSA-PKCS1-v1_5". A= nd support for the alternative RSASSA-PSS isn't particularly extensive.=

And you've misconstrued what I was trying say about JOSE= and RSASSA-PKCS1-v1_5. I was suggesting that Google (a decent sized compan= y with some resources at its disposal and services used by a few people) ch= oosing RS256 as the only JWS algorithm they use to sign ID tokens says some= thing about the usage, availability and security of the RSA based signature= schemes in the real world deployments.=C2=A0

On Mon, Aug 3, 2015 at 6:00 PM, Jim Schaad= <ietf@augustcellars.com> wrote:

When I said there is no legacy= , I was referring to the fact that there is currently no code base that is = using COSE as a message format.=C2=A0 This is different than JOSE where, as= you point out, there is a large amount of RSA v1.5 that was being used eve= n before the JOSE specifications were really finalized.

=C2=A0=

There is an in= teresting question of where COSE is going to be used.=C2=A0 For the constra= ined world, I would think that we could eliminated RSA and they would just = yawn for the most part.=C2=A0 So there are two questions:=C2=A0 Where outsi= de of constrained environments is COSE going to be used?=C2=A0 How badly do= we feel about the security problems with RSA v1.5?

=C2=A0

I don=E2=80=99t kn= ow the answer to the first question.=C2=A0

=C2=A0

<= p class=3D"MsoNormal">On the second question I h= ave opinions.=C2=A0 RSA has opinions and the IAB/IESG has opinions.<= u>

= =C2=A0

F= rom PKCS#1 dated Feb 2003

=C2=A0

= =C2=A0=C2=A0 Two encryption schemes are specified in this document: RSAES-O= AEP and

=C2=A0=C2=A0 RSAES-PKCS1-v= 1_5.=C2=A0 RSAES-OAEP is recommended for new applications;

=C2=A0=C2=A0 RSAES-PKCS1-v1_5 is included only for= compatibility with existing

=C2= =A0=C2=A0 applications, and is not recommended for new applications.=

= =C2=A0

I= think that I have seen similar language coming from the Sec Area Directora= te, the IESG and IAB (although perhaps as individuals).=C2=A0=C2=A0 =

= =C2=A0

T= his is an opinion that I share.=C2=A0 There are too many different ways to = get attacks on PKCS #1 v1.5 to keep it as a primary system.=C2=A0=C2=A0 I w= ould prefer to make people install up-to-date security systems that to cont= inue using the old algorithms.=C2=A0 This means that I don=E2=80=99t really= worry about the fact that it is not supported in all environments.=C2=A0 W= e are not currently supporting DH or DSA either, we are assuming that peopl= e are going to be able to support the EC versions of those algorithms.=C2= =A0 The statement above is far enough ago in the past that we should be wil= ling to accept it and move forward.

=C2=A0

I would be perfectly willing to d= eprecate all of RSA, the only question is do we need to keep it for some ty= pe of fail over point.

=C2=A0

jim

=C2=A0

<= div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0= in 0in">

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, Aug= ust 03, 2015 3:26 PM
To: Jim Schaad
Cc: cose@ietf.org
Subject: Re= : [COSE] RSA Algorithm Decisions

<= div>

=C2=A0

"is tokens" should say "id tokens"

=C2=A0

On Mon, Aug 3, 2015 at 3:19 PM, Brian Campbell <bcampbell@pingidentity.= com> wrote:

I'm not sure what you mean that there is no legacy that nee= ds to be supported for COSE?

Short of implementing algorithms from scrat= ch, which I expect to be very rare, COSE implementations will be constraine= d in their algorithm support by what is available from the the underlying p= latform or easily accessible libraries.

From what I've seen, RSASSA-PKCS1-v1_5 is still the mo= st commonly available and most widely used RSA based signature mechanism.= =C2=A0 If RSA is being included for completeness, RSASSA-PKCS1-v1_5 should = also be included.

=C2=A0

A default installation of Java, for example, doesn't have RSASSA-PSS= support. Google's whole federated identity system, as another example,= only supports JWS's RS256 to sign its JWT is tokens.

=

=C2=A0

=C2=A0






=C2=A0

On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad <ietf@augustcellars.com= > wrote:

I am currently in the process of updating/expa= nding the text for RSA.=C2=A0 This
message is what I am using the contro= l the decision process.

*=C2=A0 The world of IoT is not interested (= or so close to not interested) in
using RSA that it could be ignored fro= m that point of view.=C2=A0 Therefore RSA
is being included as for compl= eteness as anything else.=C2=A0 =C2=A0There may be some
other items that= port over and use RSA, but it is expected that most are
going to use EC= instead.

*=C2=A0 There is no legacy that needs to be supported for = COSE.=C2=A0 =C2=A0This means that
there is no pressing need to support a= ny of the RSA v1.5 algorithms.=C2=A0 Any
code that needs to have RSA can= use the "modern" versions.

*=C2=A0 We do want to support = both public keys and private keys in the COSE key
structure.

*=C2= =A0 There is sufficient reason to support all three if the "standard&q= uot; SHA-2
hash algorithms with all of the RSA algorithms.=C2=A0 This me= ans that PSS and
OAEP for SHA-256, SHA-384 and SHA-512.

*=C2=A0 A= s IoT does not have an interest in these algorithms, there is no reason
= to waste precious one byte algorithm identifiers on them.=C2=A0 They will g= et two
byte algorithm identifiers.

If anyone has problems with th= is, please let me know.

Jim


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

=C2=A0

=C2=A0


--001a1141bb8a2ca365051c7c2ae5-- From nobody Tue Aug 4 12:54:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04E1A88EC for ; Tue, 4 Aug 2015 12:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SxRt4BJMbIw for ; Tue, 4 Aug 2015 12:54:48 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 466E21A8FD4 for ; Tue, 4 Aug 2015 12:54:45 -0700 (PDT) Received: by iggf3 with SMTP id f3so18763954igg.1 for ; Tue, 04 Aug 2015 12:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=J/xw/mwe0TBOz4B3uavVgkfE5+YPLolrCF4YoQraWPY=; b=SRx4SRH08pCqzjQD7kQek1OcNaSpZcrZJwKVCSujghesP6rhG+QbTGZBYxjxHxW3bf 5syPyaTCf+0OEMwoR3L4swqaCCKcZ7fgF1YrEnIqNwiQbpv8JK0J7mzaYn7YYmWwiyxt bVb714AireSIYxiVlUE4S3VlCtVP8ZfCv04sU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=J/xw/mwe0TBOz4B3uavVgkfE5+YPLolrCF4YoQraWPY=; b=HqLpKSZp3S8z+LGqBOnhN3UU1Y4ir8TvbrVOuee4Bsms3nIT0Pkfx3jk1yvVkEqcMm 9ox57q2CJoGWfagG5t+zTHuYlUDwgZ/9+nP6WBjoWjKhFtsPDG+9xRhpy8Y79KMgZQzk B9a+6fRET6f6FdH+01qfxAYqxYQOZ1lBrYHV6CUYil8SUC3vPNsujyOO8TwS8rsLobUx bSei9xbe7spR0WouRaYkzzHPyH5mjNqlQaGg0y3WMCEhhphfYmqbPE4yX+OS9L3MuO0u 6V0no9n4RPAWAR4JlV3nP6KBITYu5D6F//CsTlOAw6+JV8INRQVClEDczKpnWPlOUsTm JieQ== X-Gm-Message-State: ALoCoQl63xVQ+06nk+yUMYzvf6ElXdehBQR9RWgfKddSfPpLu/8FxwFSa9tnx0Slo1Tuc7OnJ+Xk X-Received: by 10.50.61.195 with SMTP id s3mr1595462igr.62.1438718084669; Tue, 04 Aug 2015 12:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Tue, 4 Aug 2015 12:54:15 -0700 (PDT) From: Brian Campbell Date: Tue, 4 Aug 2015 13:54:15 -0600 Message-ID: To: cose@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc05f25e8493051c81a873 Archived-At: Subject: [COSE] Key Identification Headers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:54:50 -0000 --047d7bdc05f25e8493051c81a873 Content-Type: text/plain; charset=UTF-8 JOSE has seven different headers aimed at helping the message recipient identity the key to use to verify or decrypt the message. They are "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" and are discussed in JWS http://tools.ietf.org/html/rfc7515#section-4.1 and JWE http://tools.ietf.org/html/rfc7516#section-4.1 Personally, I've always felt that JOSE had too many key hinting/signaling headers and my implementation experience has only solidified that belief. I don't think there's any question that COSE should have a Key ID header that serves a purpose similar to JOSE's Key ID/"kid" header. This message is intended to try and coerce the WG towards some consensus about what other key hinting headers to include in the main COSE specification. What follows is a somewhat brief discussion of each of the JOSE headers and their potential applicability to COSE. Long story short, I propose that COSE have significantly fewer key hinting/signaling headers. Perhaps going as far as only having a Key ID header. Parameters like "jku" and "x5u", which encourage implementations to blindly retrieve remote content seem ripe for security problems ranging from resource consumption attacks to inadvertently trusting verification keys that shouldn't be trusted. They are also not particularly space efficient and (as defined for JOSE anyway) are for HTTPS URIs only. In practice with JOSE I've seen many applications which use a JWK Set available at an HTTPS URI, however, the URI is determined some other way (out of band agreement, metadata exchange, etc.) and never carried in the message. I propose that COSE not port over the "jku" or "x5u" message headers and also not attempt to define a COSE key URI style equivalent header. Porting the "jwk" message header directly to carry a JWK in a COSE message doesn't really make sense and I'd propose that COSE not try to define a similar header to carry a COSE_Key. The full key is not a space efficient way to signal the key (as apposed to a key id or hash, for example) and adds risk that an implementation might accept a message with a such a key without proper trust decision or binding of the key to an identity of a trusted sender. A header to carry a X.509 Certificate or Chain (like "x5c" in JOSE) does potentially seem useful to carry a key that is bound to some identity via the certificate(s). However, it may not be particularly appropriate or useful in the constrained word due to the size overhead it adds to a message. It's also really only meaningful for signed message so probably wouldn't be appropriate to be defined as a top level header. I'd like to know if folks in the WG feel strongly (more than just a speculative feeling that it might be useful) that such a header is needed. I'm inclined to say that COSE would be better off without. Does COSE need header(s) to convey the certificate fingerprint/thumbprint? JOSE has two - "x5t" and "x5t#S256". As an implementer, I sure would have preferred that there was only one. Or even none. While a thumbprint does inherently convey some additional semantics over a key ID alone, a key ID can certainly carry a thumbprint. I imagine that most deployments will need to come to agreement about how keys will be singled anyway. So agreeing that, in the situations that want to do it, the key ID can carry a certificate thumbprint value seems no more cumbersome than agreeing to use a more specific header for the same purpose. This is another one where I'd like to hear if folks in the WG feel strongly that a certificate fingerprint/thumbprint header is needed in COSE. If so, it'd be really nice if we could land on a single header for it rather than two. Perhaps a truncated SHA-256 could be a little bit more space efficient while avoiding SHA1. --047d7bdc05f25e8493051c81a873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
JOSE has seven different headers aimed at helpin= g the message recipient identity the key to use to verify or decrypt the me= ssage. They are "jku", "jwk", "kid", "x5= u", "x5c", "x5t", and "x5t#S256" and are= discussed in JWS http://tools.ietf.org/html/rfc7515#section-4.1 and JWE http://tools.ietf.org/html/rfc= 7516#section-4.1

Personally, I've always felt tha= t JOSE had too many key hinting/signaling headers and my implementation exp= erience has only solidified that belief.

I don't think there= 9;s any question that COSE should have a Key ID header that serves a purpose similar to JOSE's Key ID/"kid" header.= This message is intended to try and coerce the WG towards some consensus a= bout what other key hinting headers to include in the main COSE specificati= on. What follows is a somewhat brief discussion of each of the JOSE headers= and their potential applicability to COSE. Long story short, I propose tha= t COSE have significantly fewer key hinting/signaling headers. Perhaps goin= g as far as only having a Key ID header.

Parameters like "jku&q= uot; and "x5u", which encourage implementations to blindly retrie= ve remote content seem ripe for security problems ranging from resource con= sumption attacks=C2=A0 to inadvertently trusting verification keys that sho= uldn't be trusted. They are also not particularly space efficient and (= as defined for JOSE anyway) are for HTTPS URIs only. In practice with JOSE = I've seen many applications which use a JWK Set available at an HTTPS U= RI, however, the URI is determined some other way (out of band agreement, m= etadata exchange, etc.) and never carried in the message.=C2=A0 I propose t= hat COSE not port over the "jku" or "x5u" message heade= rs and also not attempt to define a COSE key URI style equivalent header. <= br>
Porting the "jwk" message header directly to carry a JWK i= n a COSE message doesn't really make sense and I'd propose that COS= E not try to define a similar header to carry a COSE_Key. The full key is = not a space efficient way to signal the key (as apposed to a key id or hash= , for example) and adds risk that an implementation might accept a message = with a such a key without proper trust decision or binding of the key to an= identity of a trusted sender.

A header to carry a X.509= Certificate or Chain (like "x5c" in JOSE) does potentially seem = useful to carry a key that is bound to some identity via the certificate(s)= . However, it may not be particularly appropriate or useful in the constrai= ned word due to the size overhead it adds to a message. It's also reall= y only meaningful for signed message so probably wouldn't be appropriat= e to be defined as a top level header. I'd like to know if folks in the= WG feel strongly (more than just a speculative feeling that it might be us= eful) that such a header is needed. I'm inclined to say that COSE would= be better off without.

Does COSE need header(s) to conve= y the certificate fingerprint/thumbprint? JOSE has two - "x5t" an= d "x5t#S256".=C2=A0 As an implementer, I sure would have preferre= d that there was only one. Or even none. While a thumbprint does inherently= convey some additional semantics over a key ID alone, a key ID can certain= ly carry a thumbprint. I imagine that most deployments will need to come to= agreement about how keys will be singled anyway. So agreeing that, in the = situations that want to do it, the key ID can carry a certificate thumbprin= t value seems no more cumbersome than agreeing to use a more specific heade= r for the same purpose. This is another one where I'd like to hear if f= olks in the WG feel strongly that a certificate fingerprint/thumbprint head= er is needed in COSE. If so, it'd be really nice if we could land on a = single header for it rather than two. Perhaps a truncated SHA-256 could be = a little bit more space efficient while avoiding SHA1.













<= div>

--047d7bdc05f25e8493051c81a873-- From nobody Wed Aug 5 12:16:26 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E881AC40F for ; Wed, 5 Aug 2015 12:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKT3_SyTL8YN for ; Wed, 5 Aug 2015 12:16:21 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD401AC3EE for ; Wed, 5 Aug 2015 12:16:21 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 794962CA12; Wed, 5 Aug 2015 12:16:20 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> In-Reply-To: Date: Wed, 5 Aug 2015 12:16:42 -0700 Message-ID: <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07A6_01D0CF78.97D1F950" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmgC8OqlTwHK57wSnibhLXA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:16:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07A6_01D0CF78.97D1F950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable First, let=E2=80=99s get the full quote from PKCS#1 V2.2 instead of just = the partial quote that you included. =20 Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest = of increased robustness, RSASSA-PSS is required in new applications. = RSASSA-PKCS1-v1_5 is included only for compatibility with existing = applications. =20 I would agree that there is an issue with deployment of PSS signatures, = however there exists lots of code that implements it. It has not been = deployed widely because people are not using it widely. However there = are many cases where it is going to start being required. For example, = TLS is moving towards only accepting PSS in v1.3. =20 =20 I believe that we qualify as a =E2=80=9Cnew application=E2=80=9D and = therefore we should be following the advice from RSA even if it may not = popular with people doing deployments immediately. I still would not = expect any constrained deployments to be using RSA, so it will be = interesting to see who picks this up and if they find it to be a = problem. I would not, for example, be expecting that this is going to = take over the world of JWT (and this is one way which might slow down = any such process). However, I must admit that the fact they are using = RSA rather than ECDSA to be disturbing due to the size issues for some = browsers. (Although not, as I understand it, an issue for chrome.) =20 Jim =20 =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Tuesday, August 04, 2015 6:21 AM To: Jim Schaad Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions =20 The suggestion was that RSASSA-PKCS1-v1_5 be included as a signature = scheme, not for RSAES-PKCS1-v1_5 as an encryption scheme. The latter has = known issues and support for the recommended alternative of RSAES-OAEP = is fairly widespread. On the former, according to PKCS#1 V2.2, dated Oct = 2012, "no attacks are known against RSASSA-PKCS1-v1_5". And support for = the alternative RSASSA-PSS isn't particularly extensive.=20 And you've misconstrued what I was trying say about JOSE and = RSASSA-PKCS1-v1_5. I was suggesting that Google (a decent sized company = with some resources at its disposal and services used by a few people) = choosing RS256 as the only JWS algorithm they use to sign ID tokens says = something about the usage, availability and security of the RSA based = signature schemes in the real world deployments. =20 =20 On Mon, Aug 3, 2015 at 6:00 PM, Jim Schaad > wrote: When I said there is no legacy, I was referring to the fact that there = is currently no code base that is using COSE as a message format. This = is different than JOSE where, as you point out, there is a large amount = of RSA v1.5 that was being used even before the JOSE specifications were = really finalized. =20 There is an interesting question of where COSE is going to be used. For = the constrained world, I would think that we could eliminated RSA and = they would just yawn for the most part. So there are two questions: = Where outside of constrained environments is COSE going to be used? How = badly do we feel about the security problems with RSA v1.5? =20 I don=E2=80=99t know the answer to the first question. =20 =20 On the second question I have opinions. RSA has opinions and the = IAB/IESG has opinions. =20 >From PKCS#1 dated Feb 2003 =20 Two encryption schemes are specified in this document: RSAES-OAEP and RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications. =20 I think that I have seen similar language coming from the Sec Area = Directorate, the IESG and IAB (although perhaps as individuals). =20 =20 This is an opinion that I share. There are too many different ways to = get attacks on PKCS #1 v1.5 to keep it as a primary system. I would = prefer to make people install up-to-date security systems that to = continue using the old algorithms. This means that I don=E2=80=99t = really worry about the fact that it is not supported in all = environments. We are not currently supporting DH or DSA either, we are = assuming that people are going to be able to support the EC versions of = those algorithms. The statement above is far enough ago in the past = that we should be willing to accept it and move forward. =20 I would be perfectly willing to deprecate all of RSA, the only question = is do we need to keep it for some type of fail over point. =20 jim =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com = ]=20 Sent: Monday, August 03, 2015 3:26 PM To: Jim Schaad Cc: cose@ietf.org =20 Subject: Re: [COSE] RSA Algorithm Decisions =20 "is tokens" should say "id tokens" =20 On Mon, Aug 3, 2015 at 3:19 PM, Brian Campbell = > wrote: I'm not sure what you mean that there is no legacy that needs to be = supported for COSE?=20 Short of implementing algorithms from scratch, which I expect to be very = rare, COSE implementations will be constrained in their algorithm = support by what is available from the the underlying platform or easily = accessible libraries.=20 >From what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly = available and most widely used RSA based signature mechanism. If RSA is = being included for completeness, RSASSA-PKCS1-v1_5 should also be = included. =20 A default installation of Java, for example, doesn't have RSASSA-PSS = support. Google's whole federated identity system, as another example, = only supports JWS's RS256 to sign its JWT is tokens. =20 =20 =20 On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad > wrote: I am currently in the process of updating/expanding the text for RSA. = This message is what I am using the control the decision process. * The world of IoT is not interested (or so close to not interested) in using RSA that it could be ignored from that point of view. Therefore = RSA is being included as for completeness as anything else. There may be = some other items that port over and use RSA, but it is expected that most are going to use EC instead. * There is no legacy that needs to be supported for COSE. This means = that there is no pressing need to support any of the RSA v1.5 algorithms. = Any code that needs to have RSA can use the "modern" versions. * We do want to support both public keys and private keys in the COSE = key structure. * There is sufficient reason to support all three if the "standard" = SHA-2 hash algorithms with all of the RSA algorithms. This means that PSS and OAEP for SHA-256, SHA-384 and SHA-512. * As IoT does not have an interest in these algorithms, there is no = reason to waste precious one byte algorithm identifiers on them. They will get = two byte algorithm identifiers. If anyone has problems with this, please let me know. Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 =20 =20 ------=_NextPart_000_07A6_01D0CF78.97D1F950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

First, let=E2=80=99s get the full quote from PKCS#1 V2.2 instead of = just the partial quote that you included.

 

Although no attacks = are known against RSASSA-PKCS1-v1_5, in the interest of increased = robustness, RSASSA-PSS is required in new applications. = RSASSA-PKCS1-v1_5 is included only for compatibility with existing = applications.

 

I would agree that there is an issue with deployment of PSS = signatures, however there exists lots of code that implements it.=C2=A0 = It has not been deployed widely because people are not using it = widely.=C2=A0 However there are many cases where it is going to start = being required.=C2=A0 For example, TLS is moving towards only accepting = PSS in v1.3.=C2=A0

 

I believe that we qualify as a =E2=80=9Cnew application=E2=80=9D and = therefore we should be following the advice from RSA even if it may not = popular with people doing deployments immediately.=C2=A0 =C2=A0I still = would not expect any constrained deployments to be using RSA, so it will = be interesting to see who picks this up and if they find it to be a = problem.=C2=A0 I would not, for example, be expecting that this is going = to take over the world of JWT (and this is one way which might slow down = any such process).=C2=A0 However, I must admit that the fact they are = using RSA rather than ECDSA to be disturbing due to the size issues for = some browsers. (Although not, as I understand it, an issue for = chrome.)

 

Jim

 

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.com]
Sent: Tuesday, = August 04, 2015 6:21 AM
To: Jim Schaad
Cc: = cose@ietf.org
Subject: Re: [COSE] RSA Algorithm = Decisions

 

The suggestion was that RSASSA-PKCS1-v1_5 = be included as a signature scheme, not for RSAES-PKCS1-v1_5 as an = encryption scheme. The latter has known issues and support for the = recommended alternative of RSAES-OAEP is fairly widespread. On the = former, according to PKCS#1 V2.2, dated Oct 2012, "no attacks are = known against RSASSA-PKCS1-v1_5". And support for the alternative = RSASSA-PSS isn't particularly extensive.

And you've misconstrued what I was trying say about = JOSE and RSASSA-PKCS1-v1_5. I was suggesting that Google (a decent sized = company with some resources at its disposal and services used by a few = people) choosing RS256 as the only JWS algorithm they use to sign ID = tokens says something about the usage, availability and security of the = RSA based signature schemes in the real world deployments.  =

 

On Mon, Aug 3, 2015 at 6:00 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

When I said there is no legacy, I was referring to the fact that = there is currently no code base that is using COSE as a message = format.  This is different than JOSE where, as you point out, there = is a large amount of RSA v1.5 that was being used even before the JOSE = specifications were really finalized.

 

There is an interesting question of where COSE is going to be = used.  For the constrained world, I would think that we could = eliminated RSA and they would just yawn for the most part.  So = there are two questions:  Where outside of constrained environments = is COSE going to be used?  How badly do we feel about the security = problems with RSA v1.5?

 

I don=E2=80=99t know the answer to the first question.  =

 

On the second question I have opinions.  RSA has opinions and = the IAB/IESG has opinions.

 

From PKCS#1 dated Feb 2003

 

   Two = encryption schemes are specified in this document: RSAES-OAEP = and

   = RSAES-PKCS1-v1_5.  RSAES-OAEP is recommended for new = applications;

   = RSAES-PKCS1-v1_5 is included only for compatibility with = existing

   = applications, and is not recommended for new = applications.

 

I think that I have seen similar language coming from the Sec Area = Directorate, the IESG and IAB (although perhaps as = individuals).  

 

This is an opinion that I share.  There are too many different = ways to get attacks on PKCS #1 v1.5 to keep it as a primary = system.   I would prefer to make people install up-to-date = security systems that to continue using the old algorithms.  This = means that I don=E2=80=99t really worry about the fact that it is not = supported in all environments.  We are not currently supporting DH = or DSA either, we are assuming that people are going to be able to = support the EC versions of those algorithms.  The statement above = is far enough ago in the past that we should be willing to accept it and = move forward.

 

I would be perfectly willing to deprecate all of RSA, the only = question is do we need to keep it for some type of fail over = point.

 

jim

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Monday, August 03, 2015 3:26 PM
To: Jim Schaad
Cc: = cose@ietf.org
Subject: Re: [COSE] RSA = Algorithm Decisions

 <= /o:p>

"is = tokens" should say "id = tokens"

 <= /o:p>

On Mon, Aug = 3, 2015 at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

I'm not sure what = you mean that there is no legacy that needs to be supported for COSE? =

Short of = implementing algorithms from scratch, which I expect to be very rare, = COSE implementations will be constrained in their algorithm support by = what is available from the the underlying platform or easily accessible = libraries.

From what = I've seen, RSASSA-PKCS1-v1_5 is still the most commonly available and = most widely used RSA based signature mechanism.  If RSA is being = included for completeness, RSASSA-PKCS1-v1_5 should also be = included.

 <= /o:p>

A default = installation of Java, for example, doesn't have RSASSA-PSS support. = Google's whole federated identity system, as another example, only = supports JWS's RS256 to sign its JWT is = tokens.

 <= /p>

 <= /p>





 <= /o:p>

On Thu, Jul = 30, 2015 at 4:32 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I am = currently in the process of updating/expanding the text for RSA.  = This
message is what I am using the control the decision = process.

*  The world of IoT is not interested (or so close = to not interested) in
using RSA that it could be ignored from that = point of view.  Therefore RSA
is being included as for = completeness as anything else.   There may be some
other = items that port over and use RSA, but it is expected that most = are
going to use EC instead.

*  There is no legacy that = needs to be supported for COSE.   This means that
there is = no pressing need to support any of the RSA v1.5 algorithms.  = Any
code that needs to have RSA can use the "modern" = versions.

*  We do want to support both public keys and = private keys in the COSE key
structure.

*  There is = sufficient reason to support all three if the "standard" = SHA-2
hash algorithms with all of the RSA algorithms.  This = means that PSS and
OAEP for SHA-256, SHA-384 and = SHA-512.

*  As IoT does not have an interest in these = algorithms, there is no reason
to waste precious one byte algorithm = identifiers on them.  They will get two
byte algorithm = identifiers.

If anyone has problems with this, please let me = know.

Jim


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

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_07A6_01D0CF78.97D1F950-- From nobody Fri Aug 7 15:55:50 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A119C1A8781 for ; Fri, 7 Aug 2015 15:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJQ4_VGVKb0O for ; Fri, 7 Aug 2015 15:55:44 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BEA1A1BC0 for ; Fri, 7 Aug 2015 15:55:44 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id B385D2CA20; Fri, 7 Aug 2015 15:55:43 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" , References: In-Reply-To: Date: Fri, 7 Aug 2015 15:56:06 -0700 Message-ID: <0a9a01d0d164$3efbd290$bcf377b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A9B_01D0D129.929F1D70" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIwH7IDJcHL3S+isDzmb7y7nkZlnp1ChJAg Archived-At: Subject: Re: [COSE] Key Identification Headers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 22:55:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A9B_01D0D129.929F1D70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have been holding off on giving my opinion to let others have first = crack at this issue. Since there does not seem to be anyone who cares = about these issues I will give my opinion and we will see where things = fall out. =20 I completely agree that key id is needed. That is why it is the one of = these methods that I put into the core document and assigned an integer = value for. =20 Until a group of people come to the working group and say that they have = a need to have X.509 certificates as a basis for trust, it is not clear = to me that there is any need to support any of the X.509 certificate = identification methods. Even then, there is the ability to use the key = id field to match against the subject key identifier field in a = certificate so we are not leaving them completely hanging in the wind. =20 I was never happy with the idea of using URLs to fetch keys for many of = the reasons that Brian states below. This is one of the reasons why I = was pressing for language in the JOSE documents that discussed the ideas = of binding identify to a key retrieved from a URL as being problematic. = I would be happy not to support this key fetching method. =20 I have an, admittedly small, degree of sympathy for allowing the key to = be carried in the message. Doing some has some issues about the size of = the data that is transmitted. However, the key is going to be a far = more unique value than a key identifier field is for matching against in = a database. I currently have defined a version of carrying the key for = doing static-static DH. It is easier to say compare the key against a = trust database than it is to say compare one of the other fields (i.e. = URL). However, I would expect that this would not be used much and that = key identifier is going to be the 99% case of key identification. I = can live with this option either being present or absent in the = specification. =20 jim =20 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, August 04, 2015 12:54 PM To: cose@ietf.org Subject: [COSE] Key Identification Headers =20 JOSE has seven different headers aimed at helping the message recipient = identity the key to use to verify or decrypt the message. They are = "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" and are = discussed in JWS http://tools.ietf.org/html/rfc7515#section-4.1 and JWE = http://tools.ietf.org/html/rfc7516#section-4.1 Personally, I've always felt that JOSE had too many key = hinting/signaling headers and my implementation experience has only = solidified that belief.=20 I don't think there's any question that COSE should have a Key ID header = that serves a purpose similar to JOSE's Key ID/"kid" header. This = message is intended to try and coerce the WG towards some consensus = about what other key hinting headers to include in the main COSE = specification. What follows is a somewhat brief discussion of each of = the JOSE headers and their potential applicability to COSE. Long story = short, I propose that COSE have significantly fewer key = hinting/signaling headers. Perhaps going as far as only having a Key ID = header. Parameters like "jku" and "x5u", which encourage implementations to = blindly retrieve remote content seem ripe for security problems ranging = from resource consumption attacks to inadvertently trusting = verification keys that shouldn't be trusted. They are also not = particularly space efficient and (as defined for JOSE anyway) are for = HTTPS URIs only. In practice with JOSE I've seen many applications which = use a JWK Set available at an HTTPS URI, however, the URI is determined = some other way (out of band agreement, metadata exchange, etc.) and = never carried in the message. I propose that COSE not port over the = "jku" or "x5u" message headers and also not attempt to define a COSE key = URI style equivalent header.=20 Porting the "jwk" message header directly to carry a JWK in a COSE = message doesn't really make sense and I'd propose that COSE not try to = define a similar header to carry a COSE_Key. The full key is not a space = efficient way to signal the key (as apposed to a key id or hash, for = example) and adds risk that an implementation might accept a message = with a such a key without proper trust decision or binding of the key to = an identity of a trusted sender.=20 A header to carry a X.509 Certificate or Chain (like "x5c" in JOSE) does = potentially seem useful to carry a key that is bound to some identity = via the certificate(s). However, it may not be particularly appropriate = or useful in the constrained word due to the size overhead it adds to a = message. It's also really only meaningful for signed message so probably = wouldn't be appropriate to be defined as a top level header. I'd like to = know if folks in the WG feel strongly (more than just a speculative = feeling that it might be useful) that such a header is needed. I'm = inclined to say that COSE would be better off without. Does COSE need header(s) to convey the certificate = fingerprint/thumbprint? JOSE has two - "x5t" and "x5t#S256". As an = implementer, I sure would have preferred that there was only one. Or = even none. While a thumbprint does inherently convey some additional = semantics over a key ID alone, a key ID can certainly carry a = thumbprint. I imagine that most deployments will need to come to = agreement about how keys will be singled anyway. So agreeing that, in = the situations that want to do it, the key ID can carry a certificate = thumbprint value seems no more cumbersome than agreeing to use a more = specific header for the same purpose. This is another one where I'd like = to hear if folks in the WG feel strongly that a certificate = fingerprint/thumbprint header is needed in COSE. If so, it'd be really = nice if we could land on a single header for it rather than two. Perhaps = a truncated SHA-256 could be a little bit more space efficient while = avoiding SHA1. =20 =20 =20 ------=_NextPart_000_0A9B_01D0D129.929F1D70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have been holding off on giving my opinion to let others have first = crack at this issue.=C2=A0 Since there does not seem to be anyone who = cares about these issues I will give my opinion and we will see where = things fall out.

 

I completely agree that key id is needed.=C2=A0 That is why it is the = one of these methods that I put into the core document and assigned an = integer value for.

 

Until a group of people come to the working group and say that they = have a need to have X.509 certificates as a basis for trust, it is not = clear to me that there is any need to support any of the X.509 = certificate identification methods.=C2=A0 Even then, there is the = ability to use the key id field to match against the subject key = identifier field in a certificate so we are not leaving them completely = hanging in the wind.

 

I was never happy with the idea of using URLs to fetch keys for many = of the reasons that Brian states below.=C2=A0 This is one of the reasons = why I was pressing for language in the JOSE documents that discussed the = ideas of binding identify to a key retrieved from a URL as being = problematic.=C2=A0 I would be happy not to support this key fetching = method.

 

I have an, admittedly small, degree of sympathy for allowing the key = to be carried in the message.=C2=A0 Doing some has some issues about the = size of the data that is transmitted.=C2=A0 However, the key is going to = be a far more unique value than a key identifier field is for matching = against in a database.=C2=A0 I currently have defined a version of = carrying the key for doing static-static DH. It is easier to say compare = the key against a trust database than it is to say compare one of the = other fields (i.e. URL).=C2=A0 However, I would expect that this would = not be used much and that key identifier is going to be the 99% case of = key identification.=C2=A0=C2=A0 I can live with this option either being = present or absent in the specification.

 

jim

 

From: COSE = [mailto:cose-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Tuesday, August 04, 2015 12:54 PM
To: = cose@ietf.org
Subject: [COSE] Key Identification = Headers

 

JOSE has seven = different headers aimed at helping the message recipient identity the = key to use to verify or decrypt the message. They are "jku", = "jwk", "kid", "x5u", "x5c", = "x5t", and "x5t#S256" and are discussed in JWS http://tools.ietf= .org/html/rfc7515#section-4.1 and JWE http://tools.ietf= .org/html/rfc7516#section-4.1

Personally, I've always = felt that JOSE had too many key hinting/signaling headers and my = implementation experience has only solidified that belief.

I = don't think there's any question that COSE should have a Key ID header = that serves a purpose similar to JOSE's Key ID/"kid" header. = This message is intended to try and coerce the WG towards some consensus = about what other key hinting headers to include in the main COSE = specification. What follows is a somewhat brief discussion of each of = the JOSE headers and their potential applicability to COSE. Long story = short, I propose that COSE have significantly fewer key = hinting/signaling headers. Perhaps going as far as only having a Key ID = header.

Parameters like "jku" and "x5u", = which encourage implementations to blindly retrieve remote content seem = ripe for security problems ranging from resource consumption = attacks  to inadvertently trusting verification keys that shouldn't = be trusted. They are also not particularly space efficient and (as = defined for JOSE anyway) are for HTTPS URIs only. In practice with JOSE = I've seen many applications which use a JWK Set available at an HTTPS = URI, however, the URI is determined some other way (out of band = agreement, metadata exchange, etc.) and never carried in the = message.  I propose that COSE not port over the "jku" or = "x5u" message headers and also not attempt to define a COSE = key URI style equivalent header.

Porting the "jwk" = message header directly to carry a JWK in a COSE message doesn't really = make sense and I'd propose that COSE not try to define a similar header = to carry a COSE_Key. The full key is not a space efficient way to signal = the key (as apposed to a key id or hash, for example) and adds risk that = an implementation might accept a message with a such a key without = proper trust decision or binding of the key to an identity of a trusted = sender.

A header to carry a X.509 Certificate or = Chain (like "x5c" in JOSE) does potentially seem useful to = carry a key that is bound to some identity via the certificate(s). = However, it may not be particularly appropriate or useful in the = constrained word due to the size overhead it adds to a message. It's = also really only meaningful for signed message so probably wouldn't be = appropriate to be defined as a top level header. I'd like to know if = folks in the WG feel strongly (more than just a speculative feeling that = it might be useful) that such a header is needed. I'm inclined to say = that COSE would be better off without.

Does COSE need = header(s) to convey the certificate fingerprint/thumbprint? JOSE has two = - "x5t" and "x5t#S256".  As an implementer, I = sure would have preferred that there was only one. Or even none. While a = thumbprint does inherently convey some additional semantics over a key = ID alone, a key ID can certainly carry a thumbprint. I imagine that most = deployments will need to come to agreement about how keys will be = singled anyway. So agreeing that, in the situations that want to do it, = the key ID can carry a certificate thumbprint value seems no more = cumbersome than agreeing to use a more specific header for the same = purpose. This is another one where I'd like to hear if folks in the WG = feel strongly that a certificate fingerprint/thumbprint header is needed = in COSE. If so, it'd be really nice if we could land on a single header = for it rather than two. Perhaps a truncated SHA-256 could be a little = bit more space efficient while avoiding = SHA1.

 



 





<= div>

 

------=_NextPart_000_0A9B_01D0D129.929F1D70-- From nobody Fri Aug 7 18:59:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E961ACDB0 for ; Fri, 7 Aug 2015 18:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP4tl2JyW-NN for ; Fri, 7 Aug 2015 18:59:37 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2C91A8901 for ; Fri, 7 Aug 2015 18:59:37 -0700 (PDT) Date: Fri, 07 Aug 2015 18:59:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1438999176; bh=xoOvEUshjXj4557AsjZ35nqAgzSBROeHhKc5Q8mNrIM=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=lekyU7deHIZbXmXv5UG+A7BRVgzcoTLXwmAyviY3qsygmY8+dTFvzymJR9tlzN4S8 mn7gwrG8u5rIJmlCMXsDTlTN4mhPHnCfMYNBzbh/TEOpbMiDq18aswt5Skerb9yxQI ZR254I3eYrPRKP0uxpbuK4qv6BfYWVyQNtw7CbZM= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55c56287f34c8_c323fc77b4232b82396ab"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Registry for media-types (#4) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 01:59:40 -0000 ----==_mimepart_55c56287f34c8_c323fc77b4232b82396ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit We have a field for media types to be placed in a message. We either need to look at killing this, decide to say that it will really take strings or figure out how we want to do the registry for this so that we can make things smaller in the message transmission. Options to be looked at in making this decisions: tstr - use the current string from the media-types registry. [tstr, tstr] - use an array and keep the types separated [int, tstr] - change the top level to an integer but keep the lower level as a string [int, (int/tstr)] - create a registry for the lower level (could potentially modify the existing registry) (int / tstr) - create a registry for everything (could potentially modify the existing registry) (tstr / [int, (int/tstr]) - Allows for having maximum flexibility in the future while letting us just use strings today (this or the first option is the "punt" option). If we decide to do an integer registration for this, then we need to have some type of criteria for assigning values to the existing registry entries. Personal opinion - there is a lot to be said for punting this issue down the road until we get some input from people who are going to need this feature. One of the places we can do some soliciting of data is from the JOSE mailing list to see if anybody there is using the content type field that was defined for JOSE. Until we get people who are creating specialized content for transport with COSE, I don't think we have enough information to answer this question. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/4 ----==_mimepart_55c56287f34c8_c323fc77b4232b82396ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

We have a field for media types to be placed in a message.

We either need to look at killing this, decide to say that it will really take strings or figure out how we want to do the registry for this so that we can make things smaller in the message transmission.

Options to be looked at in making this decisions:

tstr - use the current string from the media-types registry.
[tstr, tstr] - use an array and keep the types separated
[int, tstr] - change the top level to an integer but keep the lower level as a string
[int, (int/tstr)] - create a registry for the lower level (could potentially modify the existing registry)
(int / tstr) - create a registry for everything (could potentially modify the existing registry)
(tstr / [int, (int/tstr]) - Allows for having maximum flexibility in the future while letting us just use strings today (this or the first option is the "punt" option).

If we decide to do an integer registration for this, then we need to have some type of criteria for assigning values to the existing registry entries.

Personal opinion - there is a lot to be said for punting this issue down the road until we get some input from people who are going to need this feature. One of the places we can do some soliciting of data is from the JOSE mailing list to see if anybody there is using the content type field that was defined for JOSE. Until we get people who are creating specialized content for transport with COSE, I don't think we have enough information to answer this question.

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

----==_mimepart_55c56287f34c8_c323fc77b4232b82396ab-- From nobody Sun Aug 9 22:55:13 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B5D1A9073; Sun, 9 Aug 2015 22:55:10 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV8DqNhdaefn; Sun, 9 Aug 2015 22:55:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D224F1A907A; Sun, 9 Aug 2015 22:55:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150810055509.20525.8398.idtracker@ietfa.amsl.com> Date: Sun, 09 Aug 2015 22:55:09 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-03.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 05:55:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption Working Group of the IETF. Title : CBOR Encoded Message Syntax Author : Jim Schaad Filename : draft-ietf-cose-msg-03.txt Pages : 87 Date : 2015-08-09 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies how to do signatures, message authentication codes and encryption using this data format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 9 23:14:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F11A9250 for ; Sun, 9 Aug 2015 23:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38Fzq08C5ZuD for ; Sun, 9 Aug 2015 23:14:03 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC3F1A924C for ; Sun, 9 Aug 2015 23:14:03 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D62E42C9F8 for ; Sun, 9 Aug 2015 23:14:02 -0700 (PDT) From: "Jim Schaad" To: References: <20150810055509.20525.8398.idtracker@ietfa.amsl.com> In-Reply-To: <20150810055509.20525.8398.idtracker@ietfa.amsl.com> Date: Sun, 9 Aug 2015 23:14:23 -0700 Message-ID: <002801d0d333$cf29cb80$6d7d6280$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHrL+jerpGUB/tT2/r4igo9jM6YI53QB3OQ Content-Language: en-us Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-msg-03.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 06:14:05 -0000 This draft update is, for the most part, focused on getting updates to the algorithms section of the document. While not complete it as undergone significant revisions since the last posted version. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, August 09, 2015 10:55 PM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-msg-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CBOR Object Signing and Encryption Working > Group of the IETF. > > Title : CBOR Encoded Message Syntax > Author : Jim Schaad > Filename : draft-ietf-cose-msg-03.txt > Pages : 87 > Date : 2015-08-09 > > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for the > ability to have the basic security services defined for this data > format. This document specifies how to do signatures, message > authentication codes and encryption using this data format. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cose-msg-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Aug 10 00:14:09 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89711AC422 for ; Mon, 10 Aug 2015 00:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQzuXBSN7OOJ for ; Mon, 10 Aug 2015 00:14:06 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78761A0231 for ; Mon, 10 Aug 2015 00:14:05 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8A92D2C9F1 for ; Mon, 10 Aug 2015 00:14:05 -0700 (PDT) From: "Jim Schaad" To: References: In-Reply-To: Date: Mon, 10 Aug 2015 00:14:28 -0700 Message-ID: <003a01d0d33c$328c5320$97a4f960$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDTFRDQhzB6GcMkQE6C2xfHP0xDXwAJxh0w Content-Language: en-us Archived-At: Subject: [COSE] FW: draft-gerdes-ace-actors X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 07:14:07 -0000 I forgot to cc the working group on this mail > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Sunday, August 09, 2015 11:19 PM > To: 'draft-gerdes-ace-actors@tools.ietf.org' > Subject: draft-gerdes-ace-actors > > Trying to continue my review from before. > > * I find following the actor abbreviations to be difficult to follow. It would be > easier if the names were reflective of each other. I am not sure if you are > grabbing the names from a different world in which case this probably cannot be > done. > So it would be easier with C <--> R, CAS <--> RAS, CO <--> RO. Trying to > figure out that RqP belongs on the C side of the world is somewhat confusing for > a first time reader. Similarly the fact that AS has a prefix for the C side but not > the R side is difficult. As things stand one cannot discuss an AS as a standalone > entity which is a generic CAS and RAS item and contrast it with the differences > from being on one side or the other. > > * Section 5, para 2- Suggest 'an actor is an entity which performs a set of tasks, > has a security domain (client domain or resource domain), and a level > (constrained, less-constrained or principal).' The second sentence in this > paragraph adds no additional detail. > > * Section 5, para 3 - s/for constrained devices/for the architecture/. The > second sentence in this paragraph probably wants to say something along the > lines of 'An extant architecture can combine multiple actors into a single physical > entity. In this case the combined entity needs to deal with all of the security > requirements of the logical actors. > > * Section 5.1 - As I understand things, the task 'Validate that an entity is an > authorized server for R' should be assigned the CAS and not to C. I could be > wrong - it might be assigned to AS. But it is still not a task for C > > * Section 5.1 - The last sentence is not making sense to me. Based on the > definition of security domains in section 5, C and RS are always going to belong > to different security domains even if the resource owners are the same. One of > these needs to be clarified. > > * Section 5.1 - Kill figure 8 and point to figure 1 > > * Section 5.2 - Why is this your objective? It might be your model or > architecture, but it is hardly an objective. > > * Section 5.2 - para 1 - the last sentence is unclear - do the principals belong to > the same security domain or do the principals and their resources belong to the > same security domain. The latter is what seems to be said. > > * Section 5.3 - bullet 3 - who is it doing the negotiation with? Itself and C? that > is what the text seems to imply > > * Section 5.3 - Should this section also discuss discovery. How is C supposed to > discover the existence of R and the identity of RS? > > * Section 6.1 - What are the requirements that DTLS considers? If you don't tell > me what the requirements are in this section then there is no reason for me to > believe that you have good examples in this section. Additionally, what you > have listed here are just transport protocols. What about the data that is going > to be transported using this protocol? How do these protocols need to be > designed? What levels do the constraints needs to be examined? Transport > level? Security Level? Data Level? Discovery > > * Section 6 is not delivering any useful information. Either it needs to have > information that is needed or it should just be eliminated. > > * Section 7.1 - are you moving authorization information, or authorization > decisions from AS to RS? > > * Section 7.1 - What about dealing with authorization information going > between CAS and AS? > > * Section 7.1 - The second sentence in bullet 3 seems to be misplaced. > > * Section 7.1 - Why is C not enforcing authorization decisions as well? > > * Section 7.2 - bullet 1 - Is there a need for mutual authentication? > > * Section 7.2 - bullet 3 - the second sentence is positing a solution not a > requirement. > > * Section 7.2 - bullet 4 - I don't know why this is not written in the same way as > bullet 3 - you are just authenticating properties not the entire thing. > > * Section 8 - I am not sure what the purpose of this section is for. It would > seem to be better to fold this into section 7. > > > From nobody Mon Aug 10 10:15:31 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684691B3A36 for ; Mon, 10 Aug 2015 10:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d23MKM0sq7HB for ; Mon, 10 Aug 2015 10:15:24 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 CE0C61B3A3B for ; Mon, 10 Aug 2015 10:15:23 -0700 (PDT) Received: by iodd187 with SMTP id d187so176092481iod.2 for ; Mon, 10 Aug 2015 10:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UADfd+l/wUNlz2afZjwqlM4jfpE1wS+wyQ+JDpt7Bb0=; b=bdX/Fwg5AmhfNIJK6XXs2W6AIC+EMJYjF85fK7eqzGGzD6z/PH8tJqJV7rz9TYuMHu Gn4FAmmdl2IelVOMtF9ZpyuheDRZJEBp+ZVtaFOD2ZMirXgsWi71+Yrv3pUN1UCFZKvY HZyUvRj9xybAp6xnJJo4C4V2eVlnAOTm1MqWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UADfd+l/wUNlz2afZjwqlM4jfpE1wS+wyQ+JDpt7Bb0=; b=ENEpvzgpLNp5canr0Jh/ynH+1ypvxpRFcTaoPuyBthpKk/LLhhfA2oAxT5Hr9M9XCa KtwI6C9N3m1eZyh3ttRjXSA7Mgru6LvErIRRtoDX86ungMQW3UmNZtHU4czhr1MNG8pZ fiAWpYTcQP4tgZt4FH5UJeWpaX4Tut/pthuewLt5cr186dmI6665uAgRQupPMUXNOC9c GWByKpHEdCBMsOOILeBLpz4+sSKXA544U7ebN5h6NEwVRo8KLGfUYbttQLMI3KOt/MEn +7r4Y9MvUBM+22kmsKZtUjDKkR7AHiA5u7rikEyzTsRqIWcPA+VrdI8hmjIou8q4StR1 +hEQ== X-Gm-Message-State: ALoCoQliJgqhRfstDl925Ypwa5WNXsPnq0eoYcDXK3WxDyxeSpW64d+fSNAQT7zH4DxoWtsIsq0i X-Received: by 10.107.11.32 with SMTP id v32mr22564592ioi.95.1439226923091; Mon, 10 Aug 2015 10:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Mon, 10 Aug 2015 10:14:53 -0700 (PDT) In-Reply-To: <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> From: Brian Campbell Date: Mon, 10 Aug 2015 11:14:53 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113fb6e480ac49051cf821c5 Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:15:27 -0000 --001a113fb6e480ac49051cf821c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, I'm aware of the full text there. I quoted only the absence of known attacks on RSASSA-PKCS1-v1_5 because that seemed to be your main concern with RSAES-PKCS1-v1_5 (though a bit of a detour because I wasn't suggesting that one). I think compatibility with support in existing platforms and libraries is sufficient reason to include RSASSA-PKCS1-v1_5 and that omitting it would be a mistake that ignores the realities of real world practice and availability. I suspect also that those moving away from RSASSA-PKCS1-v1_5 will be looking to move to ECDSA due to more easily quantified benefits of smaller keys and signatures rather than the more abstract benefits of PSS. Anyway, we disagree on this. And don't seem to be making any headway in swaying one another. I wonder if there is any input for the WG or strong opinions one way or the other? On Wed, Aug 5, 2015 at 1:16 PM, Jim Schaad wrote: > First, let=E2=80=99s get the full quote from PKCS#1 V2.2 instead of just = the > partial quote that you included. > > > > Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest > of increased robustness, RSASSA-PSS is required in new applications. > RSASSA-PKCS1-v1_5 is included only for compatibility with existing > applications. > > > > I would agree that there is an issue with deployment of PSS signatures, > however there exists lots of code that implements it. It has not been > deployed widely because people are not using it widely. However there ar= e > many cases where it is going to start being required. For example, TLS i= s > moving towards only accepting PSS in v1.3. > > > > I believe that we qualify as a =E2=80=9Cnew application=E2=80=9D and ther= efore we should > be following the advice from RSA even if it may not popular with people > doing deployments immediately. I still would not expect any constrained > deployments to be using RSA, so it will be interesting to see who picks > this up and if they find it to be a problem. I would not, for example, b= e > expecting that this is going to take over the world of JWT (and this is o= ne > way which might slow down any such process). However, I must admit that > the fact they are using RSA rather than ECDSA to be disturbing due to the > size issues for some browsers. (Although not, as I understand it, an issu= e > for chrome.) > > > > Jim > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Tuesday, August 04, 2015 6:21 AM > > *To:* Jim Schaad > *Cc:* cose@ietf.org > *Subject:* Re: [COSE] RSA Algorithm Decisions > > > > The suggestion was that RSASSA-PKCS1-v1_5 be included as a signature > scheme, not for RSAES-PKCS1-v1_5 as an encryption scheme. The latter has > known issues and support for the recommended alternative of RSAES-OAEP is > fairly widespread. On the former, according to PKCS#1 V2.2, dated Oct 201= 2, > "no attacks are known against RSASSA-PKCS1-v1_5". And support for the > alternative RSASSA-PSS isn't particularly extensive. > > And you've misconstrued what I was trying say about JOSE and > RSASSA-PKCS1-v1_5. I was suggesting that Google (a decent sized company > with some resources at its disposal and services used by a few people) > choosing RS256 as the only JWS algorithm they use to sign ID tokens says > something about the usage, availability and security of the RSA based > signature schemes in the real world deployments. > > > > On Mon, Aug 3, 2015 at 6:00 PM, Jim Schaad wrote= : > > When I said there is no legacy, I was referring to the fact that there is > currently no code base that is using COSE as a message format. This is > different than JOSE where, as you point out, there is a large amount of R= SA > v1.5 that was being used even before the JOSE specifications were really > finalized. > > > > There is an interesting question of where COSE is going to be used. For > the constrained world, I would think that we could eliminated RSA and the= y > would just yawn for the most part. So there are two questions: Where > outside of constrained environments is COSE going to be used? How badly = do > we feel about the security problems with RSA v1.5? > > > > I don=E2=80=99t know the answer to the first question. > > > > On the second question I have opinions. RSA has opinions and the IAB/IES= G > has opinions. > > > > From PKCS#1 dated Feb 2003 > > > > Two encryption schemes are specified in this document: RSAES-OAEP and > > RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; > > RSAES-PKCS1-v1_5 is included only for compatibility with existing > > applications, and is not recommended for new applications. > > > > I think that I have seen similar language coming from the Sec Area > Directorate, the IESG and IAB (although perhaps as individuals). > > > > This is an opinion that I share. There are too many different ways to ge= t > attacks on PKCS #1 v1.5 to keep it as a primary system. I would prefer = to > make people install up-to-date security systems that to continue using th= e > old algorithms. This means that I don=E2=80=99t really worry about the f= act that > it is not supported in all environments. We are not currently supporting > DH or DSA either, we are assuming that people are going to be able to > support the EC versions of those algorithms. The statement above is far > enough ago in the past that we should be willing to accept it and move > forward. > > > > I would be perfectly willing to deprecate all of RSA, the only question i= s > do we need to keep it for some type of fail over point. > > > > jim > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, August 03, 2015 3:26 PM > *To:* Jim Schaad > *Cc:* cose@ietf.org > *Subject:* Re: [COSE] RSA Algorithm Decisions > > > > "is tokens" should say "id tokens" > > > > On Mon, Aug 3, 2015 at 3:19 PM, Brian Campbell > wrote: > > I'm not sure what you mean that there is no legacy that needs to be > supported for COSE? > > Short of implementing algorithms from scratch, which I expect to be very > rare, COSE implementations will be constrained in their algorithm support > by what is available from the the underlying platform or easily accessibl= e > libraries. > > From what I've seen, RSASSA-PKCS1-v1_5 is still the most commonly > available and most widely used RSA based signature mechanism. If RSA is > being included for completeness, RSASSA-PKCS1-v1_5 should also be include= d. > > > > A default installation of Java, for example, doesn't have RSASSA-PSS > support. Google's whole federated identity system, as another example, on= ly > supports JWS's RS256 to sign its JWT is tokens. > > > > > > > > > > > > On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad > wrote: > > I am currently in the process of updating/expanding the text for RSA. Th= is > message is what I am using the control the decision process. > > * The world of IoT is not interested (or so close to not interested) in > using RSA that it could be ignored from that point of view. Therefore RS= A > is being included as for completeness as anything else. There may be so= me > other items that port over and use RSA, but it is expected that most are > going to use EC instead. > > * There is no legacy that needs to be supported for COSE. This means > that > there is no pressing need to support any of the RSA v1.5 algorithms. Any > code that needs to have RSA can use the "modern" versions. > > * We do want to support both public keys and private keys in the COSE ke= y > structure. > > * There is sufficient reason to support all three if the "standard" SHA-= 2 > hash algorithms with all of the RSA algorithms. This means that PSS and > OAEP for SHA-256, SHA-384 and SHA-512. > > * As IoT does not have an interest in these algorithms, there is no reas= on > to waste precious one byte algorithm identifiers on them. They will get > two > byte algorithm identifiers. > > If anyone has problems with this, please let me know. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > > > > --001a113fb6e480ac49051cf821c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, I'm aware of the full text there. I quoted only = the absence of known attacks on RSASSA-PKCS1-v1_5 because that seemed to be= your main concern with RSAES-PKCS1-v1_5 (though a bit of a detour because = I wasn't suggesting that one). I think compatibility with support in ex= isting platforms and libraries is sufficient reason to include RSASSA-PKCS1= -v1_5 and that omitting it would be a mistake that ignores the realities of= real world practice and availability. I suspect also that those moving awa= y from RSASSA-PKCS1-v1_5 will be looking to move to ECDSA due to more easil= y quantified benefits of smaller keys and signatures rather than the more a= bstract benefits of PSS.

Anyway, we disagree on this. And don't= seem to be making any headway in swaying one another. I wonder if there is= any input for the WG or strong opinions one way or the other?


=

On Wed, Aug= 5, 2015 at 1:16 PM, Jim Schaad <ietf@augustcellars.com> wrote:

F= irst, let=E2=80=99s get the full quote from PKCS#1 V2.2 instead of just the= partial quote that you included.

=C2=A0

Although no attacks are known against RSASSA-PKCS1-v1_5, in the= interest of increased robustness, RSASSA-PSS is required in new applicatio= ns. RSASSA-PKCS1-v1_5 is included only for compatibility with existing appl= ications.

I would agree that there is an issue with deployment of PSS signatu= res, however there exists lots of code that implements it.=C2=A0 It has not= been deployed widely because people are not using it widely.=C2=A0 However= there are many cases where it is going to start being required.=C2=A0 For = example, TLS is moving towards only accepting PSS in v1.3.=C2=A0 =

=C2= =A0

I be= lieve that we qualify as a =E2=80=9Cnew application=E2=80=9D and therefore = we should be following the advice from RSA even if it may not popular with = people doing deployments immediately.=C2=A0 =C2=A0I still would not expect = any constrained deployments to be using RSA, so it will be interesting to s= ee who picks this up and if they find it to be a problem.=C2=A0 I would not= , for example, be expecting that this is going to take over the world of JW= T (and this is one way which might slow down any such process).=C2=A0 Howev= er, I must admit that the fact they are using RSA rather than ECDSA to be d= isturbing due to the size issues for some browsers. (Although not, as I und= erstand it, an issue for chrome.)

=C2=A0

Jim

=C2=A0

=C2=A0=

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent:= Tuesday, August 04, 2015 6:21 AM


= To: Jim Schaad
Cc: cose@ietf.org
Subject: Re: [COSE] RSA Algorithm D= ecisions

=C2=A0

The suggestion was that RSASSA-PKCS1-v= 1_5 be included as a signature scheme, not for RSAES-PKCS1-v1_5 as an encry= ption scheme. The latter has known issues and support for the recommended a= lternative of RSAES-OAEP is fairly widespread. On the former, according to = PKCS#1 V2.2, dated Oct 2012, "no attacks are known against RSASSA-PKCS= 1-v1_5". And support for the alternative RSASSA-PSS isn't particul= arly extensive.

And you'= ve misconstrued what I was trying say about JOSE and RSASSA-PKCS1-v1_5. I w= as suggesting that Google (a decent sized company with some resources at it= s disposal and services used by a few people) choosing RS256 as the only JW= S algorithm they use to sign ID tokens says something about the usage, avai= lability and security of the RSA based signature schemes in the real world = deployments.=C2=A0

=C2= =A0

On Mon, Aug 3, 2015 at 6:00 PM, J= im Schaad <i= etf@augustcellars.com> wrote:

When I said there is no legacy, I was referring to the fact= that there is currently no code base that is using COSE as a message forma= t.=C2=A0 This is different than JOSE where, as you point out, there is a la= rge amount of RSA v1.5 that was being used even before the JOSE specificati= ons were really finalized.

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

There is an interesting question of where C= OSE is going to be used.=C2=A0 For the constrained world, I would think tha= t we could eliminated RSA and they would just yawn for the most part.=C2=A0= So there are two questions:=C2=A0 Where outside of constrained environment= s is COSE going to be used?=C2=A0 How badly do we feel about the security p= roblems with RSA v1.5?

=C2=A0

I don=E2=80=99t know the answer to the first qu= estion.=C2=A0

=C2=A0

On the second question I have opinions.=C2=A0 RSA has= opinions and the IAB/IESG has opinions.

=C2=A0

From PKCS#1 dated Feb 2003<= /span>

= =C2=A0

=C2=A0=C2=A0 Two encryption= schemes are specified in this document: RSAES-OAEP and

=C2=A0=C2=A0 RSAES-PKCS1-v1_5.=C2=A0 RSAES-OAEP is re= commended for new applications;

= =C2=A0=C2=A0 RSAES-PKCS1-v1_5 is included only for compatibility with exist= ing

=C2=A0=C2=A0 applications, and= is not recommended for new applications.

=C2=A0

I think that I have seen si= milar language coming from the Sec Area Directorate, the IESG and IAB (alth= ough perhaps as individuals).=C2=A0=C2=A0

=C2=A0

This is an opinion that I s= hare.=C2=A0 There are too many different ways to get attacks on PKCS #1 v1.= 5 to keep it as a primary system.=C2=A0=C2=A0 I would prefer to make people= install up-to-date security systems that to continue using the old algorit= hms.=C2=A0 This means that I don=E2=80=99t really worry about the fact that= it is not supported in all environments.=C2=A0 We are not currently suppor= ting DH or DSA either, we are assuming that people are going to be able to = support the EC versions of those algorithms.=C2=A0 The statement above is f= ar enough ago in the past that we should be willing to accept it and move f= orward.

=C2=A0

I would be perfectly willing to deprecate all of RSA, the only= question is do we need to keep it for some type of fail over point.=

=C2=A0<= /span>

j= im

From: Brian Campbell [mailto:bcampbell@pingi= dentity.com]
Sent: Monday, August 03, 2015 3:26 PM
To:= Jim Schaad
Cc: cose@ietf.org
Subject: Re: [COSE] RSA Algorithm Decisio= ns

=C2= =A0

"is tokens" shou= ld say "id tokens"

=C2=A0

On Mon, Aug 3, 201= 5 at 3:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I'm not sure what you mean that there is no legacy t= hat needs to be supported for COSE?

Short of implementing algorithms fro= m scratch, which I expect to be very rare, COSE implementations will be con= strained in their algorithm support by what is available from the the under= lying platform or easily accessible libraries.

From what I've seen, RSASSA-PKCS1-v1_5 is still= the most commonly available and most widely used RSA based signature mecha= nism.=C2=A0 If RSA is being included for completeness, RSASSA-PKCS1-v1_5 sh= ould also be included.

= =C2=A0

A default installation of Java, for example, doesn't have RSAS= SA-PSS support. Google's whole federated identity system, as another ex= ample, only supports JWS's RS256 to sign its JWT is tokens.

=C2= =A0

=C2=A0





=C2=A0

On Thu, Jul 30, 2015 at 4:32 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I am currently= in the process of updating/expanding the text for RSA.=C2=A0 This
messa= ge is what I am using the control the decision process.

*=C2=A0 The = world of IoT is not interested (or so close to not interested) in
using = RSA that it could be ignored from that point of view.=C2=A0 Therefore RSAis being included as for completeness as anything else.=C2=A0 =C2=A0There= may be some
other items that port over and use RSA, but it is expected = that most are
going to use EC instead.

*=C2=A0 There is no legacy= that needs to be supported for COSE.=C2=A0 =C2=A0This means that
there = is no pressing need to support any of the RSA v1.5 algorithms.=C2=A0 Anycode that needs to have RSA can use the "modern" versions.
*=C2=A0 We do want to support both public keys and private keys in the CO= SE key
structure.

*=C2=A0 There is sufficient reason to support a= ll three if the "standard" SHA-2
hash algorithms with all of t= he RSA algorithms.=C2=A0 This means that PSS and
OAEP for SHA-256, SHA-3= 84 and SHA-512.

*=C2=A0 As IoT does not have an interest in these al= gorithms, there is no reason
to waste precious one byte algorithm identi= fiers on them.=C2=A0 They will get two
byte algorithm identifiers.
If anyone has problems with this, please let me know.

Jim

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

=C2=A0

=C2=A0

=C2=A0=

--001a113fb6e480ac49051cf821c5-- From nobody Mon Aug 10 10:26:28 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EA11B3A74 for ; Mon, 10 Aug 2015 10:26:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK6KkeDQzXiU for ; Mon, 10 Aug 2015 10:26:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CE21B3A71 for ; Mon, 10 Aug 2015 10:26:20 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.231.11; Mon, 10 Aug 2015 17:26:17 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Mon, 10 Aug 2015 17:26:17 +0000 From: Mike Jones To: Brian Campbell , Jim Schaad Thread-Topic: [COSE] RSA Algorithm Decisions Thread-Index: AdDLFYVQBaFhIPMqQIC5i6cbL8YD+QDHIWQAAAJRXQAAA0+UAAAb9quAAD62XQAA9zPkgAAAYILw Date: Mon, 10 Aug 2015 17:26:17 +0000 Message-ID: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.134.242.1] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:+LVerCqD69O33LRaY78XjgKRpyuRdmI/TZmwS3Pd1y4rPux00PAZgz9AWPc14UALYpohzAbFfh3pzbMLCzMhzlcjoiw3gDECx33euRqmc/eH29iHU067w2/IWW7gO56+qaXEuWGpHMBgaX3tfEzU5A==; 24:dpl7+8H1+QPa5xmM3B9wZMu/ahzceSVx6V/63+exK1HIVzZ4yYEXVcOvq0ErtWQ9+R5F7PjDvhXT4Z9j9iKYVhZ6OhPzAwZgCOlIzu8/ztA=; 20:9JF2TBoV+1iNyR2wLvmaCxJgtppwysOvTnCTz+bZOWVjyHkiMXEdKeQFDY0PXW3wpgXkGUszlCXJrwGBoE9bJQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(54094003)(51444003)(52314003)(24454002)(199003)(377454003)(189002)(57704003)(19609705001)(189998001)(97736004)(5001960100002)(10090500001)(105586002)(87936001)(5001770100001)(86362001)(5001860100001)(50986999)(64706001)(16236675004)(4001540100001)(106356001)(93886004)(19625215002)(92566002)(81156007)(33656002)(46102003)(86612001)(5001830100001)(99286002)(19300405004)(101416001)(19617315012)(54356999)(5005710100001)(19580395003)(68736005)(62966003)(122556002)(5003600100002)(2656002)(5001920100001)(10400500002)(2950100001)(77096005)(66066001)(76176999)(2900100001)(19580405001)(10290500002)(40100003)(5002640100001)(77156002)(15975445007)(102836002)(74316001)(76576001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442701642D780AE2FC64319F5700BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 17:26:17.7122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:26:28 -0000 --_000_BY2PR03MB442701642D780AE2FC64319F5700BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGluY2x1ZGluZyBSU0FFUy1QS0NTMS12MV81IGFzIGEgZGVmaW5lZCBhbGdv cml0aG0gaXMgZXNzZW50aWFsLg0KDQpGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IE1vbmRheSwgQXVndXN0 IDEwLCAyMDE1IDEwOjE1IEFNDQpUbzogSmltIFNjaGFhZA0KQ2M6IGNvc2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQ09TRV0gUlNBIEFsZ29yaXRobSBEZWNpc2lvbnMNCg0KWWVhaCwgSSdtIGF3 YXJlIG9mIHRoZSBmdWxsIHRleHQgdGhlcmUuIEkgcXVvdGVkIG9ubHkgdGhlIGFic2VuY2Ugb2Yg a25vd24gYXR0YWNrcyBvbiBSU0FTU0EtUEtDUzEtdjFfNSBiZWNhdXNlIHRoYXQgc2VlbWVkIHRv IGJlIHlvdXIgbWFpbiBjb25jZXJuIHdpdGggUlNBRVMtUEtDUzEtdjFfNSAodGhvdWdoIGEgYml0 IG9mIGEgZGV0b3VyIGJlY2F1c2UgSSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IG9uZSkuIEkgdGhp bmsgY29tcGF0aWJpbGl0eSB3aXRoIHN1cHBvcnQgaW4gZXhpc3RpbmcgcGxhdGZvcm1zIGFuZCBs aWJyYXJpZXMgaXMgc3VmZmljaWVudCByZWFzb24gdG8gaW5jbHVkZSBSU0FTU0EtUEtDUzEtdjFf NSBhbmQgdGhhdCBvbWl0dGluZyBpdCB3b3VsZCBiZSBhIG1pc3Rha2UgdGhhdCBpZ25vcmVzIHRo ZSByZWFsaXRpZXMgb2YgcmVhbCB3b3JsZCBwcmFjdGljZSBhbmQgYXZhaWxhYmlsaXR5LiBJIHN1 c3BlY3QgYWxzbyB0aGF0IHRob3NlIG1vdmluZyBhd2F5IGZyb20gUlNBU1NBLVBLQ1MxLXYxXzUg d2lsbCBiZSBsb29raW5nIHRvIG1vdmUgdG8gRUNEU0EgZHVlIHRvIG1vcmUgZWFzaWx5IHF1YW50 aWZpZWQgYmVuZWZpdHMgb2Ygc21hbGxlciBrZXlzIGFuZCBzaWduYXR1cmVzIHJhdGhlciB0aGFu IHRoZSBtb3JlIGFic3RyYWN0IGJlbmVmaXRzIG9mIFBTUy4NCg0KQW55d2F5LCB3ZSBkaXNhZ3Jl ZSBvbiB0aGlzLiBBbmQgZG9uJ3Qgc2VlbSB0byBiZSBtYWtpbmcgYW55IGhlYWR3YXkgaW4gc3dh eWluZyBvbmUgYW5vdGhlci4gSSB3b25kZXIgaWYgdGhlcmUgaXMgYW55IGlucHV0IGZvciB0aGUg V0cgb3Igc3Ryb25nIG9waW5pb25zIG9uZSB3YXkgb3IgdGhlIG90aGVyPw0KDQoNCk9uIFdlZCwg QXVnIDUsIDIwMTUgYXQgMToxNiBQTSwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+IHdyb3RlOg0KRmlyc3QsIGxldOKAmXMg Z2V0IHRoZSBmdWxsIHF1b3RlIGZyb20gUEtDUyMxIFYyLjIgaW5zdGVhZCBvZiBqdXN0IHRoZSBw YXJ0aWFsIHF1b3RlIHRoYXQgeW91IGluY2x1ZGVkLg0KDQpBbHRob3VnaCBubyBhdHRhY2tzIGFy ZSBrbm93biBhZ2FpbnN0IFJTQVNTQS1QS0NTMS12MV81LCBpbiB0aGUgaW50ZXJlc3Qgb2YgaW5j cmVhc2VkIHJvYnVzdG5lc3MsIFJTQVNTQS1QU1MgaXMgcmVxdWlyZWQgaW4gbmV3IGFwcGxpY2F0 aW9ucy4gUlNBU1NBLVBLQ1MxLXYxXzUgaXMgaW5jbHVkZWQgb25seSBmb3IgY29tcGF0aWJpbGl0 eSB3aXRoIGV4aXN0aW5nIGFwcGxpY2F0aW9ucy4NCg0KSSB3b3VsZCBhZ3JlZSB0aGF0IHRoZXJl IGlzIGFuIGlzc3VlIHdpdGggZGVwbG95bWVudCBvZiBQU1Mgc2lnbmF0dXJlcywgaG93ZXZlciB0 aGVyZSBleGlzdHMgbG90cyBvZiBjb2RlIHRoYXQgaW1wbGVtZW50cyBpdC4gIEl0IGhhcyBub3Qg YmVlbiBkZXBsb3llZCB3aWRlbHkgYmVjYXVzZSBwZW9wbGUgYXJlIG5vdCB1c2luZyBpdCB3aWRl bHkuICBIb3dldmVyIHRoZXJlIGFyZSBtYW55IGNhc2VzIHdoZXJlIGl0IGlzIGdvaW5nIHRvIHN0 YXJ0IGJlaW5nIHJlcXVpcmVkLiAgRm9yIGV4YW1wbGUsIFRMUyBpcyBtb3ZpbmcgdG93YXJkcyBv bmx5IGFjY2VwdGluZyBQU1MgaW4gdjEuMy4NCg0KSSBiZWxpZXZlIHRoYXQgd2UgcXVhbGlmeSBh cyBhIOKAnG5ldyBhcHBsaWNhdGlvbuKAnSBhbmQgdGhlcmVmb3JlIHdlIHNob3VsZCBiZSBmb2xs b3dpbmcgdGhlIGFkdmljZSBmcm9tIFJTQSBldmVuIGlmIGl0IG1heSBub3QgcG9wdWxhciB3aXRo IHBlb3BsZSBkb2luZyBkZXBsb3ltZW50cyBpbW1lZGlhdGVseS4gICBJIHN0aWxsIHdvdWxkIG5v dCBleHBlY3QgYW55IGNvbnN0cmFpbmVkIGRlcGxveW1lbnRzIHRvIGJlIHVzaW5nIFJTQSwgc28g aXQgd2lsbCBiZSBpbnRlcmVzdGluZyB0byBzZWUgd2hvIHBpY2tzIHRoaXMgdXAgYW5kIGlmIHRo ZXkgZmluZCBpdCB0byBiZSBhIHByb2JsZW0uICBJIHdvdWxkIG5vdCwgZm9yIGV4YW1wbGUsIGJl IGV4cGVjdGluZyB0aGF0IHRoaXMgaXMgZ29pbmcgdG8gdGFrZSBvdmVyIHRoZSB3b3JsZCBvZiBK V1QgKGFuZCB0aGlzIGlzIG9uZSB3YXkgd2hpY2ggbWlnaHQgc2xvdyBkb3duIGFueSBzdWNoIHBy b2Nlc3MpLiAgSG93ZXZlciwgSSBtdXN0IGFkbWl0IHRoYXQgdGhlIGZhY3QgdGhleSBhcmUgdXNp bmcgUlNBIHJhdGhlciB0aGFuIEVDRFNBIHRvIGJlIGRpc3R1cmJpbmcgZHVlIHRvIHRoZSBzaXpl IGlzc3VlcyBmb3Igc29tZSBicm93c2Vycy4gKEFsdGhvdWdoIG5vdCwgYXMgSSB1bmRlcnN0YW5k IGl0LCBhbiBpc3N1ZSBmb3IgY2hyb21lLikNCg0KSmltDQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJl bGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20+XQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDA0LCAyMDE1IDY6MjEgQU0N Cg0KVG86IEppbSBTY2hhYWQNCkNjOiBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtDT1NFXSBSU0EgQWxnb3JpdGhtIERlY2lzaW9ucw0KDQpUaGUgc3Vn Z2VzdGlvbiB3YXMgdGhhdCBSU0FTU0EtUEtDUzEtdjFfNSBiZSBpbmNsdWRlZCBhcyBhIHNpZ25h dHVyZSBzY2hlbWUsIG5vdCBmb3IgUlNBRVMtUEtDUzEtdjFfNSBhcyBhbiBlbmNyeXB0aW9uIHNj aGVtZS4gVGhlIGxhdHRlciBoYXMga25vd24gaXNzdWVzIGFuZCBzdXBwb3J0IGZvciB0aGUgcmVj b21tZW5kZWQgYWx0ZXJuYXRpdmUgb2YgUlNBRVMtT0FFUCBpcyBmYWlybHkgd2lkZXNwcmVhZC4g T24gdGhlIGZvcm1lciwgYWNjb3JkaW5nIHRvIFBLQ1MjMSBWMi4yLCBkYXRlZCBPY3QgMjAxMiwg Im5vIGF0dGFja3MgYXJlIGtub3duIGFnYWluc3QgUlNBU1NBLVBLQ1MxLXYxXzUiLiBBbmQgc3Vw cG9ydCBmb3IgdGhlIGFsdGVybmF0aXZlIFJTQVNTQS1QU1MgaXNuJ3QgcGFydGljdWxhcmx5IGV4 dGVuc2l2ZS4NCkFuZCB5b3UndmUgbWlzY29uc3RydWVkIHdoYXQgSSB3YXMgdHJ5aW5nIHNheSBh Ym91dCBKT1NFIGFuZCBSU0FTU0EtUEtDUzEtdjFfNS4gSSB3YXMgc3VnZ2VzdGluZyB0aGF0IEdv b2dsZSAoYSBkZWNlbnQgc2l6ZWQgY29tcGFueSB3aXRoIHNvbWUgcmVzb3VyY2VzIGF0IGl0cyBk aXNwb3NhbCBhbmQgc2VydmljZXMgdXNlZCBieSBhIGZldyBwZW9wbGUpIGNob29zaW5nIFJTMjU2 IGFzIHRoZSBvbmx5IEpXUyBhbGdvcml0aG0gdGhleSB1c2UgdG8gc2lnbiBJRCB0b2tlbnMgc2F5 cyBzb21ldGhpbmcgYWJvdXQgdGhlIHVzYWdlLCBhdmFpbGFiaWxpdHkgYW5kIHNlY3VyaXR5IG9m IHRoZSBSU0EgYmFzZWQgc2lnbmF0dXJlIHNjaGVtZXMgaW4gdGhlIHJlYWwgd29ybGQgZGVwbG95 bWVudHMuDQoNCk9uIE1vbiwgQXVnIDMsIDIwMTUgYXQgNjowMCBQTSwgSmltIFNjaGFhZCA8aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+IHdyb3Rl Og0KV2hlbiBJIHNhaWQgdGhlcmUgaXMgbm8gbGVnYWN5LCBJIHdhcyByZWZlcnJpbmcgdG8gdGhl IGZhY3QgdGhhdCB0aGVyZSBpcyBjdXJyZW50bHkgbm8gY29kZSBiYXNlIHRoYXQgaXMgdXNpbmcg Q09TRSBhcyBhIG1lc3NhZ2UgZm9ybWF0LiAgVGhpcyBpcyBkaWZmZXJlbnQgdGhhbiBKT1NFIHdo ZXJlLCBhcyB5b3UgcG9pbnQgb3V0LCB0aGVyZSBpcyBhIGxhcmdlIGFtb3VudCBvZiBSU0EgdjEu NSB0aGF0IHdhcyBiZWluZyB1c2VkIGV2ZW4gYmVmb3JlIHRoZSBKT1NFIHNwZWNpZmljYXRpb25z IHdlcmUgcmVhbGx5IGZpbmFsaXplZC4NCg0KVGhlcmUgaXMgYW4gaW50ZXJlc3RpbmcgcXVlc3Rp b24gb2Ygd2hlcmUgQ09TRSBpcyBnb2luZyB0byBiZSB1c2VkLiAgRm9yIHRoZSBjb25zdHJhaW5l ZCB3b3JsZCwgSSB3b3VsZCB0aGluayB0aGF0IHdlIGNvdWxkIGVsaW1pbmF0ZWQgUlNBIGFuZCB0 aGV5IHdvdWxkIGp1c3QgeWF3biBmb3IgdGhlIG1vc3QgcGFydC4gIFNvIHRoZXJlIGFyZSB0d28g cXVlc3Rpb25zOiAgV2hlcmUgb3V0c2lkZSBvZiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgaXMg Q09TRSBnb2luZyB0byBiZSB1c2VkPyAgSG93IGJhZGx5IGRvIHdlIGZlZWwgYWJvdXQgdGhlIHNl Y3VyaXR5IHByb2JsZW1zIHdpdGggUlNBIHYxLjU/DQoNCkkgZG9u4oCZdCBrbm93IHRoZSBhbnN3 ZXIgdG8gdGhlIGZpcnN0IHF1ZXN0aW9uLg0KDQpPbiB0aGUgc2Vjb25kIHF1ZXN0aW9uIEkgaGF2 ZSBvcGluaW9ucy4gIFJTQSBoYXMgb3BpbmlvbnMgYW5kIHRoZSBJQUIvSUVTRyBoYXMgb3Bpbmlv bnMuDQoNCkZyb20gUEtDUyMxIGRhdGVkIEZlYiAyMDAzDQoNCiAgIFR3byBlbmNyeXB0aW9uIHNj aGVtZXMgYXJlIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50OiBSU0FFUy1PQUVQIGFuZA0KICAg UlNBRVMtUEtDUzEtdjFfNS4gIFJTQUVTLU9BRVAgaXMgcmVjb21tZW5kZWQgZm9yIG5ldyBhcHBs aWNhdGlvbnM7DQogICBSU0FFUy1QS0NTMS12MV81IGlzIGluY2x1ZGVkIG9ubHkgZm9yIGNvbXBh dGliaWxpdHkgd2l0aCBleGlzdGluZw0KICAgYXBwbGljYXRpb25zLCBhbmQgaXMgbm90IHJlY29t bWVuZGVkIGZvciBuZXcgYXBwbGljYXRpb25zLg0KDQpJIHRoaW5rIHRoYXQgSSBoYXZlIHNlZW4g c2ltaWxhciBsYW5ndWFnZSBjb21pbmcgZnJvbSB0aGUgU2VjIEFyZWEgRGlyZWN0b3JhdGUsIHRo ZSBJRVNHIGFuZCBJQUIgKGFsdGhvdWdoIHBlcmhhcHMgYXMgaW5kaXZpZHVhbHMpLg0KDQpUaGlz IGlzIGFuIG9waW5pb24gdGhhdCBJIHNoYXJlLiAgVGhlcmUgYXJlIHRvbyBtYW55IGRpZmZlcmVu dCB3YXlzIHRvIGdldCBhdHRhY2tzIG9uIFBLQ1MgIzEgdjEuNSB0byBrZWVwIGl0IGFzIGEgcHJp bWFyeSBzeXN0ZW0uICAgSSB3b3VsZCBwcmVmZXIgdG8gbWFrZSBwZW9wbGUgaW5zdGFsbCB1cC10 by1kYXRlIHNlY3VyaXR5IHN5c3RlbXMgdGhhdCB0byBjb250aW51ZSB1c2luZyB0aGUgb2xkIGFs Z29yaXRobXMuICBUaGlzIG1lYW5zIHRoYXQgSSBkb27igJl0IHJlYWxseSB3b3JyeSBhYm91dCB0 aGUgZmFjdCB0aGF0IGl0IGlzIG5vdCBzdXBwb3J0ZWQgaW4gYWxsIGVudmlyb25tZW50cy4gIFdl IGFyZSBub3QgY3VycmVudGx5IHN1cHBvcnRpbmcgREggb3IgRFNBIGVpdGhlciwgd2UgYXJlIGFz c3VtaW5nIHRoYXQgcGVvcGxlIGFyZSBnb2luZyB0byBiZSBhYmxlIHRvIHN1cHBvcnQgdGhlIEVD IHZlcnNpb25zIG9mIHRob3NlIGFsZ29yaXRobXMuICBUaGUgc3RhdGVtZW50IGFib3ZlIGlzIGZh ciBlbm91Z2ggYWdvIGluIHRoZSBwYXN0IHRoYXQgd2Ugc2hvdWxkIGJlIHdpbGxpbmcgdG8gYWNj ZXB0IGl0IGFuZCBtb3ZlIGZvcndhcmQuDQoNCkkgd291bGQgYmUgcGVyZmVjdGx5IHdpbGxpbmcg dG8gZGVwcmVjYXRlIGFsbCBvZiBSU0EsIHRoZSBvbmx5IHF1ZXN0aW9uIGlzIGRvIHdlIG5lZWQg dG8ga2VlcCBpdCBmb3Igc29tZSB0eXBlIG9mIGZhaWwgb3ZlciBwb2ludC4NCg0KamltDQoNCkZy b206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPl0NClNlbnQ6IE1vbmRheSwgQXVndXN0IDAz LCAyMDE1IDM6MjYgUE0NClRvOiBKaW0gU2NoYWFkDQpDYzogY29zZUBpZXRmLm9yZzxtYWlsdG86 Y29zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ09TRV0gUlNBIEFsZ29yaXRobSBEZWNpc2lv bnMNCg0KImlzIHRva2VucyIgc2hvdWxkIHNheSAiaWQgdG9rZW5zIg0KDQpPbiBNb24sIEF1ZyAz LCAyMDE1IGF0IDM6MTkgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkknbSBub3Qg c3VyZSB3aGF0IHlvdSBtZWFuIHRoYXQgdGhlcmUgaXMgbm8gbGVnYWN5IHRoYXQgbmVlZHMgdG8g YmUgc3VwcG9ydGVkIGZvciBDT1NFPw0KU2hvcnQgb2YgaW1wbGVtZW50aW5nIGFsZ29yaXRobXMg ZnJvbSBzY3JhdGNoLCB3aGljaCBJIGV4cGVjdCB0byBiZSB2ZXJ5IHJhcmUsIENPU0UgaW1wbGVt ZW50YXRpb25zIHdpbGwgYmUgY29uc3RyYWluZWQgaW4gdGhlaXIgYWxnb3JpdGhtIHN1cHBvcnQg Ynkgd2hhdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgdGhlIHVuZGVybHlpbmcgcGxhdGZvcm0gb3Ig ZWFzaWx5IGFjY2Vzc2libGUgbGlicmFyaWVzLg0KRnJvbSB3aGF0IEkndmUgc2VlbiwgUlNBU1NB LVBLQ1MxLXYxXzUgaXMgc3RpbGwgdGhlIG1vc3QgY29tbW9ubHkgYXZhaWxhYmxlIGFuZCBtb3N0 IHdpZGVseSB1c2VkIFJTQSBiYXNlZCBzaWduYXR1cmUgbWVjaGFuaXNtLiAgSWYgUlNBIGlzIGJl aW5nIGluY2x1ZGVkIGZvciBjb21wbGV0ZW5lc3MsIFJTQVNTQS1QS0NTMS12MV81IHNob3VsZCBh bHNvIGJlIGluY2x1ZGVkLg0KDQpBIGRlZmF1bHQgaW5zdGFsbGF0aW9uIG9mIEphdmEsIGZvciBl eGFtcGxlLCBkb2Vzbid0IGhhdmUgUlNBU1NBLVBTUyBzdXBwb3J0LiBHb29nbGUncyB3aG9sZSBm ZWRlcmF0ZWQgaWRlbnRpdHkgc3lzdGVtLCBhcyBhbm90aGVyIGV4YW1wbGUsIG9ubHkgc3VwcG9y dHMgSldTJ3MgUlMyNTYgdG8gc2lnbiBpdHMgSldUIGlzIHRva2Vucy4NCg0KDQoNCg0KDQoNCk9u IFRodSwgSnVsIDMwLCAyMDE1IGF0IDQ6MzIgUE0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2Vs bGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+PiB3cm90ZToNCkkgYW0gY3Vy cmVudGx5IGluIHRoZSBwcm9jZXNzIG9mIHVwZGF0aW5nL2V4cGFuZGluZyB0aGUgdGV4dCBmb3Ig UlNBLiAgVGhpcw0KbWVzc2FnZSBpcyB3aGF0IEkgYW0gdXNpbmcgdGhlIGNvbnRyb2wgdGhlIGRl Y2lzaW9uIHByb2Nlc3MuDQoNCiogIFRoZSB3b3JsZCBvZiBJb1QgaXMgbm90IGludGVyZXN0ZWQg KG9yIHNvIGNsb3NlIHRvIG5vdCBpbnRlcmVzdGVkKSBpbg0KdXNpbmcgUlNBIHRoYXQgaXQgY291 bGQgYmUgaWdub3JlZCBmcm9tIHRoYXQgcG9pbnQgb2Ygdmlldy4gIFRoZXJlZm9yZSBSU0ENCmlz IGJlaW5nIGluY2x1ZGVkIGFzIGZvciBjb21wbGV0ZW5lc3MgYXMgYW55dGhpbmcgZWxzZS4gICBU aGVyZSBtYXkgYmUgc29tZQ0Kb3RoZXIgaXRlbXMgdGhhdCBwb3J0IG92ZXIgYW5kIHVzZSBSU0Es IGJ1dCBpdCBpcyBleHBlY3RlZCB0aGF0IG1vc3QgYXJlDQpnb2luZyB0byB1c2UgRUMgaW5zdGVh ZC4NCg0KKiAgVGhlcmUgaXMgbm8gbGVnYWN5IHRoYXQgbmVlZHMgdG8gYmUgc3VwcG9ydGVkIGZv ciBDT1NFLiAgIFRoaXMgbWVhbnMgdGhhdA0KdGhlcmUgaXMgbm8gcHJlc3NpbmcgbmVlZCB0byBz dXBwb3J0IGFueSBvZiB0aGUgUlNBIHYxLjUgYWxnb3JpdGhtcy4gIEFueQ0KY29kZSB0aGF0IG5l ZWRzIHRvIGhhdmUgUlNBIGNhbiB1c2UgdGhlICJtb2Rlcm4iIHZlcnNpb25zLg0KDQoqICBXZSBk byB3YW50IHRvIHN1cHBvcnQgYm90aCBwdWJsaWMga2V5cyBhbmQgcHJpdmF0ZSBrZXlzIGluIHRo ZSBDT1NFIGtleQ0Kc3RydWN0dXJlLg0KDQoqICBUaGVyZSBpcyBzdWZmaWNpZW50IHJlYXNvbiB0 byBzdXBwb3J0IGFsbCB0aHJlZSBpZiB0aGUgInN0YW5kYXJkIiBTSEEtMg0KaGFzaCBhbGdvcml0 aG1zIHdpdGggYWxsIG9mIHRoZSBSU0EgYWxnb3JpdGhtcy4gIFRoaXMgbWVhbnMgdGhhdCBQU1Mg YW5kDQpPQUVQIGZvciBTSEEtMjU2LCBTSEEtMzg0IGFuZCBTSEEtNTEyLg0KDQoqICBBcyBJb1Qg ZG9lcyBub3QgaGF2ZSBhbiBpbnRlcmVzdCBpbiB0aGVzZSBhbGdvcml0aG1zLCB0aGVyZSBpcyBu byByZWFzb24NCnRvIHdhc3RlIHByZWNpb3VzIG9uZSBieXRlIGFsZ29yaXRobSBpZGVudGlmaWVy cyBvbiB0aGVtLiAgVGhleSB3aWxsIGdldCB0d28NCmJ5dGUgYWxnb3JpdGhtIGlkZW50aWZpZXJz Lg0KDQpJZiBhbnlvbmUgaGFzIHByb2JsZW1zIHdpdGggdGhpcywgcGxlYXNlIGxldCBtZSBrbm93 Lg0KDQpKaW0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3 d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZjb3NlJmRhdGE9MDElN2MwMSU3Y01p Y2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdjYmIxOGUxZWMzMDlhNGUzZjUyYTIwOGQyYTFh NzRlYjUlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9c3VQUyUy ZnhUb0F2dmtwVGFXMjNKSkhRb1k1YWt4c1RaZ3prTGtNNHFEb0JjJTNkPg0KDQoNCg0KDQo= --_000_BY2PR03MB442701642D780AE2FC64319F5700BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IGluY2x1ZGluZyBSU0FFUy1QS0NTMS12 MV81IGFzIGEgZGVmaW5lZCBhbGdvcml0aG0gaXMgZXNzZW50aWFsLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ09TRSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBBdWd1c3QgMTAsIDIwMTUgMTA6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEppbSBT Y2hhYWQ8YnI+DQo8Yj5DYzo8L2I+IGNvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtDT1NFXSBSU0EgQWxnb3JpdGhtIERlY2lzaW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WWVhaCwgSSdtIGF3 YXJlIG9mIHRoZSBmdWxsIHRleHQgdGhlcmUuIEkgcXVvdGVkIG9ubHkgdGhlIGFic2VuY2Ugb2Yg a25vd24gYXR0YWNrcyBvbiBSU0FTU0EtUEtDUzEtdjFfNSBiZWNhdXNlIHRoYXQgc2VlbWVkIHRv IGJlIHlvdXIgbWFpbiBjb25jZXJuIHdpdGggUlNBRVMtUEtDUzEtdjFfNSAodGhvdWdoIGEgYml0 IG9mIGEgZGV0b3VyIGJlY2F1c2UgSSB3YXNuJ3QNCiBzdWdnZXN0aW5nIHRoYXQgb25lKS4gSSB0 aGluayBjb21wYXRpYmlsaXR5IHdpdGggc3VwcG9ydCBpbiBleGlzdGluZyBwbGF0Zm9ybXMgYW5k IGxpYnJhcmllcyBpcyBzdWZmaWNpZW50IHJlYXNvbiB0byBpbmNsdWRlIFJTQVNTQS1QS0NTMS12 MV81IGFuZCB0aGF0IG9taXR0aW5nIGl0IHdvdWxkIGJlIGEgbWlzdGFrZSB0aGF0IGlnbm9yZXMg dGhlIHJlYWxpdGllcyBvZiByZWFsIHdvcmxkIHByYWN0aWNlIGFuZCBhdmFpbGFiaWxpdHkuIEkg c3VzcGVjdA0KIGFsc28gdGhhdCB0aG9zZSBtb3ZpbmcgYXdheSBmcm9tIFJTQVNTQS1QS0NTMS12 MV81IHdpbGwgYmUgbG9va2luZyB0byBtb3ZlIHRvIEVDRFNBIGR1ZSB0byBtb3JlIGVhc2lseSBx dWFudGlmaWVkIGJlbmVmaXRzIG9mIHNtYWxsZXIga2V5cyBhbmQgc2lnbmF0dXJlcyByYXRoZXIg dGhhbiB0aGUgbW9yZSBhYnN0cmFjdCBiZW5lZml0cyBvZiBQU1MuDQo8YnI+DQo8YnI+DQpBbnl3 YXksIHdlIGRpc2FncmVlIG9uIHRoaXMuIEFuZCBkb24ndCBzZWVtIHRvIGJlIG1ha2luZyBhbnkg aGVhZHdheSBpbiBzd2F5aW5nIG9uZSBhbm90aGVyLiBJIHdvbmRlciBpZiB0aGVyZSBpcyBhbnkg aW5wdXQgZm9yIHRoZSBXRyBvciBzdHJvbmcgb3BpbmlvbnMgb25lIHdheSBvciB0aGUgb3RoZXI/ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgMToxNiBQTSwgSmltIFNjaGFhZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkZpcnN0LCBsZXTigJlzIGdldCB0aGUgZnVsbCBxdW90ZSBmcm9tIFBLQ1Mj MSBWMi4yIGluc3RlYWQgb2YganVzdCB0aGUgcGFydGlhbCBxdW90ZSB0aGF0IHlvdSBpbmNsdWRl ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsdGhvdWdoIG5vIGF0dGFja3MgYXJlIGtu b3duIGFnYWluc3QgUlNBU1NBLVBLQ1MxLXYxXzUsIGluIHRoZSBpbnRlcmVzdCBvZiBpbmNyZWFz ZWQgcm9idXN0bmVzcywgUlNBU1NBLVBTUyBpcyByZXF1aXJlZCBpbiBuZXcgYXBwbGljYXRpb25z LiBSU0FTU0EtUEtDUzEtdjFfNSBpcyBpbmNsdWRlZCBvbmx5DQogZm9yIGNvbXBhdGliaWxpdHkg d2l0aCBleGlzdGluZyBhcHBsaWNhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGFncmVlIHRoYXQgdGhl cmUgaXMgYW4gaXNzdWUgd2l0aCBkZXBsb3ltZW50IG9mIFBTUyBzaWduYXR1cmVzLCBob3dldmVy IHRoZXJlIGV4aXN0cyBsb3RzDQogb2YgY29kZSB0aGF0IGltcGxlbWVudHMgaXQuJm5ic3A7IEl0 IGhhcyBub3QgYmVlbiBkZXBsb3llZCB3aWRlbHkgYmVjYXVzZSBwZW9wbGUgYXJlIG5vdCB1c2lu ZyBpdCB3aWRlbHkuJm5ic3A7IEhvd2V2ZXIgdGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgaXQg aXMgZ29pbmcgdG8gc3RhcnQgYmVpbmcgcmVxdWlyZWQuJm5ic3A7IEZvciBleGFtcGxlLCBUTFMg aXMgbW92aW5nIHRvd2FyZHMgb25seSBhY2NlcHRpbmcgUFNTIGluIHYxLjMuJm5ic3A7DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIGJlbGlldmUgdGhhdCB3ZSBxdWFsaWZ5IGFzIGEg4oCcbmV3IGFwcGxpY2F0 aW9u4oCdIGFuZCB0aGVyZWZvcmUgd2Ugc2hvdWxkIGJlIGZvbGxvd2luZyB0aGUgYWR2aWNlDQog ZnJvbSBSU0EgZXZlbiBpZiBpdCBtYXkgbm90IHBvcHVsYXIgd2l0aCBwZW9wbGUgZG9pbmcgZGVw bG95bWVudHMgaW1tZWRpYXRlbHkuJm5ic3A7ICZuYnNwO0kgc3RpbGwgd291bGQgbm90IGV4cGVj dCBhbnkgY29uc3RyYWluZWQgZGVwbG95bWVudHMgdG8gYmUgdXNpbmcgUlNBLCBzbyBpdCB3aWxs IGJlIGludGVyZXN0aW5nIHRvIHNlZSB3aG8gcGlja3MgdGhpcyB1cCBhbmQgaWYgdGhleSBmaW5k IGl0IHRvIGJlIGEgcHJvYmxlbS4mbmJzcDsgSSB3b3VsZCBub3QsIGZvcg0KIGV4YW1wbGUsIGJl IGV4cGVjdGluZyB0aGF0IHRoaXMgaXMgZ29pbmcgdG8gdGFrZSBvdmVyIHRoZSB3b3JsZCBvZiBK V1QgKGFuZCB0aGlzIGlzIG9uZSB3YXkgd2hpY2ggbWlnaHQgc2xvdyBkb3duIGFueSBzdWNoIHBy b2Nlc3MpLiZuYnNwOyBIb3dldmVyLCBJIG11c3QgYWRtaXQgdGhhdCB0aGUgZmFjdCB0aGV5IGFy ZSB1c2luZyBSU0EgcmF0aGVyIHRoYW4gRUNEU0EgdG8gYmUgZGlzdHVyYmluZyBkdWUgdG8gdGhl IHNpemUgaXNzdWVzIGZvciBzb21lDQogYnJvd3NlcnMuIChBbHRob3VnaCBub3QsIGFzIEkgdW5k ZXJzdGFuZCBpdCwgYW4gaXNzdWUgZm9yIGNocm9tZS4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmltPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEF1Z3VzdCAwNCwgMjAxNSA2OjIxIEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IEppbSBTY2hhYWQ8YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+Y29zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDT1NFXSBSU0Eg QWxnb3JpdGhtIERlY2lzaW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIHN1Z2dlc3Rp b24gd2FzIHRoYXQgUlNBU1NBLVBLQ1MxLXYxXzUgYmUgaW5jbHVkZWQgYXMgYSBzaWduYXR1cmUg c2NoZW1lLCBub3QgZm9yIFJTQUVTLVBLQ1MxLXYxXzUgYXMgYW4gZW5jcnlwdGlvbiBzY2hlbWUu IFRoZSBsYXR0ZXIgaGFzIGtub3duIGlzc3VlcyBhbmQgc3VwcG9ydCBmb3IgdGhlIHJlY29tbWVu ZGVkDQogYWx0ZXJuYXRpdmUgb2YgUlNBRVMtT0FFUCBpcyBmYWlybHkgd2lkZXNwcmVhZC4gT24g dGhlIGZvcm1lciwgYWNjb3JkaW5nIHRvIFBLQ1MjMSBWMi4yLCBkYXRlZCBPY3QgMjAxMiwgJnF1 b3Q7bm8gYXR0YWNrcyBhcmUga25vd24gYWdhaW5zdCBSU0FTU0EtUEtDUzEtdjFfNSZxdW90Oy4g QW5kIHN1cHBvcnQgZm9yIHRoZSBhbHRlcm5hdGl2ZSBSU0FTU0EtUFNTIGlzbid0IHBhcnRpY3Vs YXJseSBleHRlbnNpdmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5BbmQgeW91J3ZlIG1pc2NvbnN0cnVlZCB3aGF0IEkgd2FzIHRyeWluZyBzYXkgYWJv dXQgSk9TRSBhbmQgUlNBU1NBLVBLQ1MxLXYxXzUuIEkgd2FzIHN1Z2dlc3RpbmcgdGhhdCBHb29n bGUgKGEgZGVjZW50IHNpemVkIGNvbXBhbnkgd2l0aCBzb21lIHJlc291cmNlcyBhdCBpdHMgZGlz cG9zYWwgYW5kIHNlcnZpY2VzDQogdXNlZCBieSBhIGZldyBwZW9wbGUpIGNob29zaW5nIFJTMjU2 IGFzIHRoZSBvbmx5IEpXUyBhbGdvcml0aG0gdGhleSB1c2UgdG8gc2lnbiBJRCB0b2tlbnMgc2F5 cyBzb21ldGhpbmcgYWJvdXQgdGhlIHVzYWdlLCBhdmFpbGFiaWxpdHkgYW5kIHNlY3VyaXR5IG9m IHRoZSBSU0EgYmFzZWQgc2lnbmF0dXJlIHNjaGVtZXMgaW4gdGhlIHJlYWwgd29ybGQgZGVwbG95 bWVudHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gTW9uLCBBdWcgMywgMjAxNSBhdCA2OjAwIFBNLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJt YWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0 Y2VsbGFycy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XaGVuIEkgc2FpZCB0aGVyZSBpcyBubyBsZWdhY3ksIEkgd2FzIHJlZmVycmluZyB0byB0aGUg ZmFjdCB0aGF0IHRoZXJlIGlzIGN1cnJlbnRseSBubyBjb2RlIGJhc2UNCiB0aGF0IGlzIHVzaW5n IENPU0UgYXMgYSBtZXNzYWdlIGZvcm1hdC4mbmJzcDsgVGhpcyBpcyBkaWZmZXJlbnQgdGhhbiBK T1NFIHdoZXJlLCBhcyB5b3UgcG9pbnQgb3V0LCB0aGVyZSBpcyBhIGxhcmdlIGFtb3VudCBvZiBS U0EgdjEuNSB0aGF0IHdhcyBiZWluZyB1c2VkIGV2ZW4gYmVmb3JlIHRoZSBKT1NFIHNwZWNpZmlj YXRpb25zIHdlcmUgcmVhbGx5IGZpbmFsaXplZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBhbiBp bnRlcmVzdGluZyBxdWVzdGlvbiBvZiB3aGVyZSBDT1NFIGlzIGdvaW5nIHRvIGJlIHVzZWQuJm5i c3A7IEZvciB0aGUgY29uc3RyYWluZWQgd29ybGQsIEkNCiB3b3VsZCB0aGluayB0aGF0IHdlIGNv dWxkIGVsaW1pbmF0ZWQgUlNBIGFuZCB0aGV5IHdvdWxkIGp1c3QgeWF3biBmb3IgdGhlIG1vc3Qg cGFydC4mbmJzcDsgU28gdGhlcmUgYXJlIHR3byBxdWVzdGlvbnM6Jm5ic3A7IFdoZXJlIG91dHNp ZGUgb2YgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzIGlzIENPU0UgZ29pbmcgdG8gYmUgdXNlZD8m bmJzcDsgSG93IGJhZGx5IGRvIHdlIGZlZWwgYWJvdXQgdGhlIHNlY3VyaXR5IHByb2JsZW1zIHdp dGggUlNBIHYxLjU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IGtub3cgdGhlIGFuc3dlciB0byB0 aGUgZmlyc3QgcXVlc3Rpb24uJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUgc2Vjb25kIHF1 ZXN0aW9uIEkgaGF2ZSBvcGluaW9ucy4mbmJzcDsgUlNBIGhhcyBvcGluaW9ucyBhbmQgdGhlIElB Qi9JRVNHIGhhcyBvcGluaW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIFBLQ1MjMSBkYXRlZCBGZWIg MjAwMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBU d28gZW5jcnlwdGlvbiBzY2hlbWVzIGFyZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudDogUlNB RVMtT0FFUCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUlNBRVMtUEtDUzEtdjFfNS4mbmJzcDsgUlNBRVMtT0FF UCBpcyByZWNvbW1lbmRlZCBmb3IgbmV3IGFwcGxpY2F0aW9uczs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUlNBRVMt UEtDUzEtdjFfNSBpcyBpbmNsdWRlZCBvbmx5IGZvciBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3Rp bmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zLCBhbmQgaXMgbm90IHJlY29tbWVuZGVkIGZvciBu ZXcgYXBwbGljYXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCBJIGhhdmUgc2VlbiBz aW1pbGFyIGxhbmd1YWdlIGNvbWluZyBmcm9tIHRoZSBTZWMgQXJlYSBEaXJlY3RvcmF0ZSwgdGhl IElFU0cgYW5kIElBQg0KIChhbHRob3VnaCBwZXJoYXBzIGFzIGluZGl2aWR1YWxzKS4mbmJzcDsm bmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhbiBvcGluaW9uIHRoYXQgSSBzaGFyZS4mbmJz cDsgVGhlcmUgYXJlIHRvbyBtYW55IGRpZmZlcmVudCB3YXlzIHRvIGdldCBhdHRhY2tzIG9uIFBL Q1MgIzEgdjEuNQ0KIHRvIGtlZXAgaXQgYXMgYSBwcmltYXJ5IHN5c3RlbS4mbmJzcDsmbmJzcDsg SSB3b3VsZCBwcmVmZXIgdG8gbWFrZSBwZW9wbGUgaW5zdGFsbCB1cC10by1kYXRlIHNlY3VyaXR5 IHN5c3RlbXMgdGhhdCB0byBjb250aW51ZSB1c2luZyB0aGUgb2xkIGFsZ29yaXRobXMuJm5ic3A7 IFRoaXMgbWVhbnMgdGhhdCBJIGRvbuKAmXQgcmVhbGx5IHdvcnJ5IGFib3V0IHRoZSBmYWN0IHRo YXQgaXQgaXMgbm90IHN1cHBvcnRlZCBpbiBhbGwgZW52aXJvbm1lbnRzLiZuYnNwOyBXZSBhcmUg bm90IGN1cnJlbnRseQ0KIHN1cHBvcnRpbmcgREggb3IgRFNBIGVpdGhlciwgd2UgYXJlIGFzc3Vt aW5nIHRoYXQgcGVvcGxlIGFyZSBnb2luZyB0byBiZSBhYmxlIHRvIHN1cHBvcnQgdGhlIEVDIHZl cnNpb25zIG9mIHRob3NlIGFsZ29yaXRobXMuJm5ic3A7IFRoZSBzdGF0ZW1lbnQgYWJvdmUgaXMg ZmFyIGVub3VnaCBhZ28gaW4gdGhlIHBhc3QgdGhhdCB3ZSBzaG91bGQgYmUgd2lsbGluZyB0byBh Y2NlcHQgaXQgYW5kIG1vdmUgZm9yd2FyZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGJlIHBlcmZl Y3RseSB3aWxsaW5nIHRvIGRlcHJlY2F0ZSBhbGwgb2YgUlNBLCB0aGUgb25seSBxdWVzdGlvbiBp cyBkbyB3ZSBuZWVkIHRvIGtlZXAgaXQNCiBmb3Igc29tZSB0eXBlIG9mIGZhaWwgb3ZlciBwb2lu dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5qaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMDMsIDIw MTUgMzoyNiBQTTxicj4NCjxiPlRvOjwvYj4gSmltIFNjaGFhZDxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3NlQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NPU0VdIFJTQSBBbGdvcml0aG0gRGVjaXNp b25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O2lzIHRva2VucyZxdW90OyBzaG91bGQgc2F5ICZxdW90 O2lkIHRva2VucyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIE1vbiwgQXVnIDMsIDIwMTUgYXQgMzoxOSBQTSwgQnJpYW4gQ2FtcGJlbGwg Jmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkknbSBub3Qgc3Vy ZSB3aGF0IHlvdSBtZWFuIHRoYXQgdGhlcmUgaXMgbm8gbGVnYWN5IHRoYXQgbmVlZHMgdG8gYmUg c3VwcG9ydGVkIGZvciBDT1NFPw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+U2hvcnQgb2YgaW1wbGVtZW50aW5nIGFsZ29yaXRobXMgZnJvbSBzY3JhdGNoLCB3aGlj aCBJIGV4cGVjdCB0byBiZSB2ZXJ5IHJhcmUsIENPU0UgaW1wbGVtZW50YXRpb25zIHdpbGwgYmUg Y29uc3RyYWluZWQgaW4gdGhlaXIgYWxnb3JpdGhtIHN1cHBvcnQgYnkgd2hhdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgdGhlIHVuZGVybHlpbmcNCiBwbGF0Zm9ybSBvciBlYXNpbHkgYWNjZXNzaWJs ZSBsaWJyYXJpZXMuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Gcm9tIHdoYXQgSSd2ZSBzZWVuLCBSU0FTU0EtUEtDUzEtdjFfNSBpcyBzdGls bCB0aGUgbW9zdCBjb21tb25seSBhdmFpbGFibGUgYW5kIG1vc3Qgd2lkZWx5IHVzZWQgUlNBIGJh c2VkIHNpZ25hdHVyZSBtZWNoYW5pc20uJm5ic3A7IElmIFJTQSBpcyBiZWluZyBpbmNsdWRlZCBm b3IgY29tcGxldGVuZXNzLCBSU0FTU0EtUEtDUzEtdjFfNQ0KIHNob3VsZCBhbHNvIGJlIGluY2x1 ZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5BIGRlZmF1 bHQgaW5zdGFsbGF0aW9uIG9mIEphdmEsIGZvciBleGFtcGxlLCBkb2Vzbid0IGhhdmUgUlNBU1NB LVBTUyBzdXBwb3J0LiBHb29nbGUncyB3aG9sZSBmZWRlcmF0ZWQgaWRlbnRpdHkgc3lzdGVtLCBh cyBhbm90aGVyIGV4YW1wbGUsIG9ubHkgc3VwcG9ydHMgSldTJ3MgUlMyNTYgdG8gc2lnbiBpdHMg SldUIGlzDQogdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEp1bCAzMCwgMjAx NSBhdCA0OjMyIFBNLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIGN1cnJlbnRseSBp biB0aGUgcHJvY2VzcyBvZiB1cGRhdGluZy9leHBhbmRpbmcgdGhlIHRleHQgZm9yIFJTQS4mbmJz cDsgVGhpczxicj4NCm1lc3NhZ2UgaXMgd2hhdCBJIGFtIHVzaW5nIHRoZSBjb250cm9sIHRoZSBk ZWNpc2lvbiBwcm9jZXNzLjxicj4NCjxicj4NCiombmJzcDsgVGhlIHdvcmxkIG9mIElvVCBpcyBu b3QgaW50ZXJlc3RlZCAob3Igc28gY2xvc2UgdG8gbm90IGludGVyZXN0ZWQpIGluPGJyPg0KdXNp bmcgUlNBIHRoYXQgaXQgY291bGQgYmUgaWdub3JlZCBmcm9tIHRoYXQgcG9pbnQgb2Ygdmlldy4m bmJzcDsgVGhlcmVmb3JlIFJTQTxicj4NCmlzIGJlaW5nIGluY2x1ZGVkIGFzIGZvciBjb21wbGV0 ZW5lc3MgYXMgYW55dGhpbmcgZWxzZS4mbmJzcDsgJm5ic3A7VGhlcmUgbWF5IGJlIHNvbWU8YnI+ DQpvdGhlciBpdGVtcyB0aGF0IHBvcnQgb3ZlciBhbmQgdXNlIFJTQSwgYnV0IGl0IGlzIGV4cGVj dGVkIHRoYXQgbW9zdCBhcmU8YnI+DQpnb2luZyB0byB1c2UgRUMgaW5zdGVhZC48YnI+DQo8YnI+ DQoqJm5ic3A7IFRoZXJlIGlzIG5vIGxlZ2FjeSB0aGF0IG5lZWRzIHRvIGJlIHN1cHBvcnRlZCBm b3IgQ09TRS4mbmJzcDsgJm5ic3A7VGhpcyBtZWFucyB0aGF0PGJyPg0KdGhlcmUgaXMgbm8gcHJl c3NpbmcgbmVlZCB0byBzdXBwb3J0IGFueSBvZiB0aGUgUlNBIHYxLjUgYWxnb3JpdGhtcy4mbmJz cDsgQW55PGJyPg0KY29kZSB0aGF0IG5lZWRzIHRvIGhhdmUgUlNBIGNhbiB1c2UgdGhlICZxdW90 O21vZGVybiZxdW90OyB2ZXJzaW9ucy48YnI+DQo8YnI+DQoqJm5ic3A7IFdlIGRvIHdhbnQgdG8g c3VwcG9ydCBib3RoIHB1YmxpYyBrZXlzIGFuZCBwcml2YXRlIGtleXMgaW4gdGhlIENPU0Uga2V5 PGJyPg0Kc3RydWN0dXJlLjxicj4NCjxicj4NCiombmJzcDsgVGhlcmUgaXMgc3VmZmljaWVudCBy ZWFzb24gdG8gc3VwcG9ydCBhbGwgdGhyZWUgaWYgdGhlICZxdW90O3N0YW5kYXJkJnF1b3Q7IFNI QS0yPGJyPg0KaGFzaCBhbGdvcml0aG1zIHdpdGggYWxsIG9mIHRoZSBSU0EgYWxnb3JpdGhtcy4m bmJzcDsgVGhpcyBtZWFucyB0aGF0IFBTUyBhbmQ8YnI+DQpPQUVQIGZvciBTSEEtMjU2LCBTSEEt Mzg0IGFuZCBTSEEtNTEyLjxicj4NCjxicj4NCiombmJzcDsgQXMgSW9UIGRvZXMgbm90IGhhdmUg YW4gaW50ZXJlc3QgaW4gdGhlc2UgYWxnb3JpdGhtcywgdGhlcmUgaXMgbm8gcmVhc29uPGJyPg0K dG8gd2FzdGUgcHJlY2lvdXMgb25lIGJ5dGUgYWxnb3JpdGhtIGlkZW50aWZpZXJzIG9uIHRoZW0u Jm5ic3A7IFRoZXkgd2lsbCBnZXQgdHdvPGJyPg0KYnl0ZSBhbGdvcml0aG0gaWRlbnRpZmllcnMu PGJyPg0KPGJyPg0KSWYgYW55b25lIGhhcyBwcm9ibGVtcyB3aXRoIHRoaXMsIHBsZWFzZSBsZXQg bWUga25vdy48YnI+DQo8YnI+DQpKaW08YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNPU0UgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5DT1NFQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUy Zmxpc3RpbmZvJTJmY29zZSZhbXA7ZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jv c29mdC5jb20lN2NiYjE4ZTFlYzMwOWE0ZTNmNTJhMjA4ZDJhMWE3NGViNSU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9c3VQUyUyZnhUb0F2dmtwVGFXMjNK SkhRb1k1YWt4c1RaZ3prTGtNNHFEb0JjJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442701642D780AE2FC64319F5700BY2PR03MB442namprd_-- From nobody Mon Aug 10 13:19:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5EF1A8938 for ; Mon, 10 Aug 2015 13:19:18 -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 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 wKGh8KXb5zdy for ; Mon, 10 Aug 2015 13:19:16 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B373A1B2AEB for ; Mon, 10 Aug 2015 13:19:05 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 163BE2CA0A for ; Mon, 10 Aug 2015 13:19:05 -0700 (PDT) From: "Jim Schaad" To: References: <022201d0c93d$123c15a0$36b440e0$@augustcellars.com> <026601d0c953$3128cb50$937a61f0$@augustcellars.com> <03d601d0ca0a$41d3d5f0$c57b81d0$@augustcellars.com> In-Reply-To: <03d601d0ca0a$41d3d5f0$c57b81d0$@augustcellars.com> Date: Mon, 10 Aug 2015 13:19:28 -0700 Message-ID: <018d01d0d3a9$dc47ef60$94d7ce20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018E_01D0D36F.2FEFCE20" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEINhblT3H2MKFRpgnHLaMPnVEXAwEDIOpgAk2vEk8BvBS1sZ9ugDhw Content-Language: en-us Archived-At: Subject: Re: [COSE] Arrays vs maps at the top level X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:19:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018E_01D0D36F.2FEFCE20 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I have not heard anything to say I should not do this. I will merge the pull request at the end of this week. =20 Jim =20 =20 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, July 29, 2015 7:24 AM To: cose@ietf.org Subject: Re: [COSE] Arrays vs maps at the top level =20 The set of changes can be found in pull request #61 =20 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, July 28, 2015 9:34 AM To: 'Mike Jones'; cose@ietf.org =20 Subject: Re: [COSE] Arrays vs maps at the top level =20 The only change in the grammar is from map to array. Nothing else is re-ordered. =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Tuesday, July 28, 2015 8:48 AM To: Jim Schaad; cose@ietf.org =20 Subject: RE: [COSE] Arrays vs maps at the top level =20 Sounds reasonable. What would the structure of the top level arrays be? -- Mike _____ =20 From: Jim Schaad =20 Sent: =FD7/=FD28/=FD2015 6:55 AM To: cose@ietf.org =20 Subject: [COSE] Arrays vs maps at the top level As I stated in a previous response to Carsten that I was keeping the question of arrays vs maps at the top level because I felt that there = was not a lot of strong arguments either way and it was a bit of a weak consensus. There have been a number of changes that we have made that have changed = the number of bytes of overhead. This may change some people's opinions. = The overhead differences are now as follows: MAP ARRAY Direct Encryption 12 10 Signature 12 10 MAC Direct 14 11 The removal of AAD, IV and TAG as independent fields makes the array = size smaller in those cases where it is not used. The shrinkage is less for = MAP since the assumption of them not being there for recipient structures = was already built in. The last time I did this analysis the sizes were basically equal. There is now an advantage for arrays in all cases. = For encryption and mac - going from direct to any other key management = technique will increase the size of MAP w/o a corresponding increase in the size = of Array since all fields already exist for it. Based on implementation experience, I have also found that doing the = array version is much simpler from a couple of perspectives. - It is much easier to look at the array to see what is and what is not present than for maps. This has become very true with the loss of text labels since the tag 1 is not unique. It means different things in different places. This makes things harder to look at. - It is easier to get a comparison routine working correctly. Since = maps are randomly placed but arrays are fixed, it is simpler to do automated comparisons. There may still be issues with the protected/unprotected maps. But that is more likely to be under the program than library = control so it is easier to control from the outside. There are still issues = where one may need to do sorting of these maps to do comparisons. However removing one layer of problems seems to be goodness. - At the f2f, Carsten raised the fact that for an array version, since = the message type is in a fixed location, code can examine this value when it = is in an array and processing can be aborted at an earlier point if the = message structure type is not supported. Based on these arguments and the new numbers, I want to move back to = arrays from maps for the top level objects. Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.or g%2fmailman%2flistinfo%2fcose &data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c8f8e25f384c34d399a5e08d= 29754 2ef3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQ= CWZsU xVoBNYRhRqCfN7cvRmM%3d ------=_NextPart_000_018E_01D0D36F.2FEFCE20 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

I have not heard anything to say I should not do this.=A0 I will = merge the pull request at the end of this week.

 

Jim

 

 

From: COSE = [mailto:cose-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Wednesday, July 29, 2015 7:24 AM
To: = cose@ietf.org
Subject: Re: [COSE] Arrays vs maps at the top = level

 

The set of changes can be found in pull request = #61

 

From: COSE [mailto:cose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Tuesday, July 28, 2015 = 9:34 AM
To: 'Mike Jones'; cose@ietf.org
Subject: Re: = [COSE] Arrays vs maps at the top = level

 

The only change in the grammar is from map to array.  Nothing = else is re-ordered.

 

From: Mike = Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Tuesday, July 28, 2015 8:48 AM
To: = Jim Schaad; cose@ietf.org
Subject: RE: = [COSE] Arrays vs maps at the top = level

 

Sounds = reasonable. What would the structure of the top level arrays = be?

-- Mike

From: = Jim Schaad
Sent: = =FD7/=FD28/= =FD2015 6:55 AM
To: = cose@ietf.org
Subject: = [COSE] = Arrays vs maps at the top level

As I stated in a = previous response to Carsten that I was keeping the
question of = arrays vs maps at the top level because I felt that there was
not a = lot of strong arguments either way and it was a bit of a = weak
consensus.

There have been a number of changes that we = have made that have changed the
number of bytes of overhead.  = This may change some people's opinions.  The
overhead = differences are now as = follows:

         &nb= sp;           &nbs= p;  = MAP           &nbs= p; ARRAY
Direct Encryption       = 12            = ;  = 10
Signature         &nbs= p;     = 12            = ;  10
MAC = Direct           &= nbsp;  = 14            = ;  11

The removal of AAD, IV and TAG as independent fields = makes the array size
smaller in those cases where it is not = used.  The shrinkage is less for MAP
since the assumption of = them not being there for recipient structures was
already built = in.   The last time I did this analysis the sizes = were
basically equal.  There is now an advantage for arrays in = all cases.  For
encryption and mac - going from direct to any = other key management technique
will increase the size of MAP w/o a = corresponding increase in the size of
Array since all fields already = exist for it.

Based on implementation experience, I have also = found that doing the array
version is much simpler from a couple of = perspectives.

- It is much easier to look at the array to see = what is and what is not
present than for maps.  This has become = very true with the loss of text
labels since the tag 1 is not = unique.  It means different things in
different places.  = This makes things harder to look at.

- It is easier to get a = comparison routine working correctly.  Since maps
are randomly = placed but arrays are fixed, it is simpler to do = automated
comparisons.   There may still be issues with the = protected/unprotected
maps.  But that is more likely to be under = the program than library control
so it is easier to control from the = outside.  There are still issues where
one may need to do = sorting of these maps to do comparisons.  However
removing one = layer of problems seems to be goodness.

- At the f2f, Carsten = raised the fact that for an array version, since the
message type is = in a fixed location, code can examine this value when it is
in an = array and processing can be aborted at an earlier point if the = message
structure type is not supported.

Based on these = arguments and the new numbers, I want to move back to arrays
from = maps for the top level = objects.

Jim



______________________________________= _________
COSE mailing list
COSE@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%= 2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichae= l.Jones%40microsoft.com%7c8f8e25f384c34d399a5e08d297542ef3%7c72f988bf86f1= 41af91ab2d7cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQCWZsUxVoBNYRhRq= CfN7cvRmM%3d

------=_NextPart_000_018E_01D0D36F.2FEFCE20-- From nobody Mon Aug 10 14:35:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9011B3EFE for ; Mon, 10 Aug 2015 14:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.009 X-Spam-Level: X-Spam-Status: No, score=-4.009 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQUFBiw-7cIH for ; Mon, 10 Aug 2015 14:34:57 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FEFA1B3EFC for ; Mon, 10 Aug 2015 14:34:57 -0700 (PDT) Date: Mon, 10 Aug 2015 14:34:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1439242496; bh=MUB8T+uFEauEB4rxn8iWZv1fjq93XRKjksffSZRpOF4=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UBoOBCDD2hSFIJV8Ku1MKllDe0pjjOVHCi/OPALm0s+pEKAEutHQB7XTM+P10/jL4 OaPiOq7sZwMhzXUTssJGx+d+azxxKMab5DKS1snCnzvfoN34eJcNcGk+x4+WcYaeDX +oYz3bMgzlp3JNw642IcoVoORMbJ0ctNHgh2AY3k= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55c919009c343_3b0e3fed9cf4f2bc317160"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-GitHub-Reason: comment X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Cc: cose-ietf Subject: Re: [COSE] [cose-issues] Registry for media-types (#4) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 21:34:59 -0000 ----==_mimepart_55c919009c343_3b0e3fed9cf4f2bc317160 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I had not realized that there was a registry for this purpose already. So the only question left is what should the syntax be. I think that having the content encoding as part of the registry makes sense. If one has text/plain then one still needs to know what the code page is for that text. At this point I am planning on making the syntax for this field (int / tstr) where the integers come from the CoAP table and the strings from the normal media-types table. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/4#issuecomment-129616826 ----==_mimepart_55c919009c343_3b0e3fed9cf4f2bc317160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I had not realized that there was a registry for this purpose already. So the only question left is what should the syntax be. I think that having the content encoding as part of the registry makes sense. If one has text/plain then one still needs to know what the code page is for that text.

At this point I am planning on making the syntax for this field (int / tstr) where the integers come from the CoAP table and the strings from the normal media-types table.

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

----==_mimepart_55c919009c343_3b0e3fed9cf4f2bc317160-- From nobody Wed Aug 12 14:11:44 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2A31ACDF9 for ; Wed, 12 Aug 2015 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRkIZoBoh-UH for ; Wed, 12 Aug 2015 14:11:41 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93C21ACDF6 for ; Wed, 12 Aug 2015 14:11:41 -0700 (PDT) Received: from hebrews (173-164-71-213-Oregon.hfc.comcastbusiness.net [173.164.71.213]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 44F1C38F01 for ; Wed, 12 Aug 2015 14:11:41 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 12 Aug 2015 14:12:03 -0700 Message-ID: <018b01d0d543$895664d0$9c032e70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDVPUvS5F1YA735RGCWN8QwL15TOQ== Content-Language: en-us Archived-At: Subject: [COSE] Single Recipient Discussions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 21:11:43 -0000 Since we appear to have finished dealing with the question of array vs map at the top level, I want to restart the discussions dealing with handing single recipient/signer as a special case. 1. I am assuming that we are going with arrays at the top level for all of the sizes that I cite in this mail. As such, these number will be slightly different that those cited by the advocates of a single recipient solution, but I do not believe that the slightly different numbers would change their arguments in any way. 2. I believe that it is a misnomer to call the discussion that has been primarily advanced to be about a single recipient use case. It would be more accurate the tag this discussion as being about making the case of using a PSK directly as the key. The proposals do nothing to deal with any of the other key management techniques as a single recipient, they only deal with a key management algorithm of 'direct'. 3. The message space savings for the proposals that have been advanced will save at most 8 bytes from the current document. 2 bytes for the two array markers, 2 bytes for the two maps, 1 byte for the absent ciphertext, 1 byte for the zero length recipient array, 2 bytes for the algorithm identifier tag and value. Of these 8 bytes, we can remove 3 of them relatively easily. If the recipient array is optional, then it disappears. If we unroll the recipients in the case of a single recipient then the 2 bytes for array markers disappears. The published document does the first but not the latter. 4. There is currently a very clear cut rule about things only being used at the layer they are placed in. This means that currently key identifiers are never placed in the same layer as a content key algorithm. This would be broken by the proposal put forth. I worry that once this is done, there will be more items than kid that will migrate between layers. One of the things that I never liked in the JOSE proposals what the number of places that one needed to look for the various control fields. Currently in COSE this is limited to two places. If we introduce the possibility of cross layer contamination then this number might grow in the future to deal with implementation faults. One of the way that these faults might develop is for designers to say - I think that this should be authenticated, and thus will put it at the wrong layer to ensure that it is. Either without thinking about the question - should it be authenticated, or a different algorithm be required so that authentication is possible. 5. Code size is going to be very different if two different methods of dealing with structure needs to be supported. It is currently being assumed that direct key is going to be the major use case in a number of situations. If this is not the case then current proposals do not help the situation any. If it is true that more than one method of key management needs to be supported then the code size is going to grow because of the need to support an additional way that key management is going to be done. 6. Personally, I am planning to argue against using direct key in future work of ACE for long term authentication keys. The fact that it is going to be hard to rotate them means that one needs to either add a KDF step or else have a key agreement method to keep the same key from being used for the entire lifetime of the device (perhaps 30 years?). This is something that is related to the previous item as we now are going to need to support multiple key management methods in these cases. 7. Now that we are doing arrays, it would be possible to have a generic one recipient/signer solution by unrolling the recipient/signer structure on the end of the message. This was originally proposed before the change from arrays to maps was initially made. Since we are moving from maps back to arrays it is one again a viable solution to look at. It would be totally viable to have applications state that there is one recipient/signer and the unrolled version is always used. This would still allow for multiple key management types to be used. Systems in more unconstrained spaces could potentially setup to have multiple recipients - but only if use cases exist where it would be needed. From nobody Wed Aug 12 14:24:54 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2993E1ACE0A for ; Wed, 12 Aug 2015 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmsGqruVoPzE for ; Wed, 12 Aug 2015 14:24:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7F81ACE08 for ; Wed, 12 Aug 2015 14:24:51 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Wed, 12 Aug 2015 21:24:34 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Wed, 12 Aug 2015 21:24:34 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Single Recipient Discussions Thread-Index: AdDVPUvS5F1YA735RGCWN8QwL15TOQAB5uWQ Date: Wed, 12 Aug 2015 21:24:34 +0000 Message-ID: References: <018b01d0d543$895664d0$9c032e70$@augustcellars.com> In-Reply-To: <018b01d0d543$895664d0$9c032e70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.95.140.212] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:djkQFU+LVJwNx8nV7VxS1uqomKzoow/qqL/xuhVIwi3ET1fI2zRdv6YVsTt1eXUM5dUHEgxLIqJFt4bR6ECgrTulRx1J2BiOuMho+SepIXNAQaD/mPNxWkYMEE5+8gcPbVBZQ0Gf7JIQKS/NEGtOdA==; 24:IwVl/bS62bWpXLh/lx1gNPxHejJOlWGhJWa01DG/fNz4aIVSxmL4a758CBgQ4/YsQOPmEdIB0JV6LJTphrs7WsViCih3LcJtwEZIKWM3Dwo=; 20:tFWXUqXEac5kiPppqnsIl6LUx3rSqTICpsxfEQwy9Fv8lvgjZ3apFOnp525brItKsXj8mHNKyUxMXkUvl9XUwA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(164054003)(51444003)(199003)(189002)(377454003)(106356001)(107886002)(2656002)(19580395003)(122556002)(2900100001)(66066001)(64706001)(5005710100001)(68736005)(50986999)(19580405001)(561944003)(33656002)(40100003)(86362001)(575784001)(99286002)(2950100001)(101416001)(77156002)(10090500001)(74316001)(92566002)(62966003)(102836002)(189998001)(77096005)(87936001)(5001860100001)(46102003)(105586002)(86612001)(15975445007)(5002640100001)(97736004)(10400500002)(81156007)(5001960100002)(10290500002)(5003600100002)(76576001)(54356999)(76176999)(5001770100001)(5001830100001)(4001540100001)(2501003)(8990500004)(5001920100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2015 21:24:34.2869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [COSE] Single Recipient Discussions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 21:24:54 -0000 I think I know what your proposal in 7 would look like, but it could probab= ly help the discussion if you were to give us a concrete example - not usin= g numbers and an actual representation, but using symbolic names for the ar= ray fields. I'm thinking something like: [protected, unprotected, payload, signature] I realize you may be envisioning more fields than that to maintain the laye= ring you discuss below, which is part of why I'd like us to be able to easi= ly see what they are. Thanks, -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, August 12, 2015 5:12 PM To: cose@ietf.org Subject: [COSE] Single Recipient Discussions Since we appear to have finished dealing with the question of array vs map = at the top level, I want to restart the discussions dealing with handing si= ngle recipient/signer as a special case. 1. I am assuming that we are going with arrays at the top level for all of= the sizes that I cite in this mail. As such, these number will be slightl= y different that those cited by the advocates of a single recipient solutio= n, but I do not believe that the slightly different numbers would change th= eir arguments in any way. 2. I believe that it is a misnomer to call the discussion that has been pr= imarily advanced to be about a single recipient use case. It would be more= accurate the tag this discussion as being about making the case of using a= PSK directly as the key. The proposals do nothing to deal with any of the= other key management techniques as a single recipient, they only deal with= a key management algorithm of 'direct'. 3. The message space savings for the proposals that have been advanced wil= l save at most 8 bytes from the current document. 2 bytes for the two arra= y markers, 2 bytes for the two maps, 1 byte for the absent ciphertext, 1 by= te for the zero length recipient array, 2 bytes for the algorithm identifie= r tag and value. Of these 8 bytes, we can remove 3 of them relatively easily. If the recipient array is optional, then it disappears. If we unr= oll the recipients in the case of a single recipient then the 2 bytes for a= rray markers disappears. The published document does the first but not the= latter. 4. There is currently a very clear cut rule about things only being used a= t the layer they are placed in. This means that currently key identifiers = are never placed in the same layer as a content key algorithm. This would = be broken by the proposal put forth. I worry that once this is done, there= will be more items than kid that will migrate between layers. One of the = things that I never liked in the JOSE proposals what the number of places t= hat one needed to look for the various control fields. Currently in COSE t= his is limited to two places. If we introduce the possibility of cross lay= er contamination then this number might grow in the future to deal with implementation faults. =20 One of the way that these faults might develop is for designers to say - I = think that this should be authenticated, and thus will put it at the wrong = layer to ensure that it is. Either without thinking about the question - s= hould it be authenticated, or a different algorithm be required so that aut= hentication is possible. 5. Code size is going to be very different if two different methods of dea= ling with structure needs to be supported. It is currently being assumed t= hat direct key is going to be the major use case in a number of situations. If this is not the case then current proposals do not help the situation an= y. If it is true that more than one method of key management needs to be s= upported then the code size is going to grow because of the need to support= an additional way that key management is going to be done. 6. Personally, I am planning to argue against using direct key in future w= ork of ACE for long term authentication keys. The fact that it is going to= be hard to rotate them means that one needs to either add a KDF step or el= se have a key agreement method to keep the same key from being used for the= entire lifetime of the device (perhaps 30 years?). This is something that= is related to the previous item as we now are going to need to support mul= tiple key management methods in these cases. 7. Now that we are doing arrays, it would be possible to have a generic on= e recipient/signer solution by unrolling the recipient/signer structure on = the end of the message. This was originally proposed before the change fro= m arrays to maps was initially made. Since we are moving from maps back to= arrays it is one again a viable solution to look at. It would be totally = viable to have applications state that there is one recipient/signer and th= e unrolled version is always used. This would still allow for multiple key= management types to be used. Systems in more unconstrained spaces could p= otentially setup to have multiple recipients - but only if use cases exist = where it would be needed. _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c42b45138af2043af976708d2a35aa0e5%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3D62f4AJob4HGGxfnZpU2Yt7AGjiTJcxW75rCq2jYKlUo%3d From nobody Wed Aug 12 19:49:08 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1F71A219F for ; Wed, 12 Aug 2015 19:49:06 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TROXe2nZHsJi for ; Wed, 12 Aug 2015 19:49:02 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E715C1B2F4E for ; Wed, 12 Aug 2015 19:49:02 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id EE53738F0E; Wed, 12 Aug 2015 19:49:01 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <018b01d0d543$895664d0$9c032e70$@augustcellars.com> In-Reply-To: Date: Wed, 12 Aug 2015 19:49:24 -0700 Message-ID: <020901d0d572$aa4f82f0$feee88d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLFFI7A7XD+J74WsC9DlLF5QD7CrQGCodbunBSm5PA= Content-Language: en-us Archived-At: Subject: Re: [COSE] Single Recipient Discussions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 02:49:06 -0000 No it would look like [ msg_type, protected, unprotected, payload, protected, unprotected, signature] One would append the signature structure to the end of the body structure. Similar for encryption and mac. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, August 12, 2015 2:25 PM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Single Recipient Discussions > > I think I know what your proposal in 7 would look like, but it could probably help > the discussion if you were to give us a concrete example - not using numbers > and an actual representation, but using symbolic names for the array fields. I'm > thinking something like: > > [protected, > unprotected, > payload, > signature] > > I realize you may be envisioning more fields than that to maintain the layering > you discuss below, which is part of why I'd like us to be able to easily see what > they are. > > Thanks, > -- Mike > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Wednesday, August 12, 2015 5:12 PM > To: cose@ietf.org > Subject: [COSE] Single Recipient Discussions > > Since we appear to have finished dealing with the question of array vs map at > the top level, I want to restart the discussions dealing with handing single > recipient/signer as a special case. > > 1. I am assuming that we are going with arrays at the top level for all of the > sizes that I cite in this mail. As such, these number will be slightly different that > those cited by the advocates of a single recipient solution, but I do not believe > that the slightly different numbers would change their arguments in any way. > > 2. I believe that it is a misnomer to call the discussion that has been primarily > advanced to be about a single recipient use case. It would be more accurate the > tag this discussion as being about making the case of using a PSK directly as the > key. The proposals do nothing to deal with any of the other key management > techniques as a single recipient, they only deal with a key management > algorithm of 'direct'. > > 3. The message space savings for the proposals that have been advanced will > save at most 8 bytes from the current document. 2 bytes for the two array > markers, 2 bytes for the two maps, 1 byte for the absent ciphertext, 1 byte for > the zero length recipient array, 2 bytes for the algorithm identifier > tag and value. Of these 8 bytes, we can remove 3 of them relatively > easily. If the recipient array is optional, then it disappears. If we unroll the > recipients in the case of a single recipient then the 2 bytes for array markers > disappears. The published document does the first but not the latter. > > 4. There is currently a very clear cut rule about things only being used at the > layer they are placed in. This means that currently key identifiers are never > placed in the same layer as a content key algorithm. This would be broken by > the proposal put forth. I worry that once this is done, there will be more items > than kid that will migrate between layers. One of the things that I never liked in > the JOSE proposals what the number of places that one needed to look for the > various control fields. Currently in COSE this is limited to two places. If we > introduce the possibility of cross layer contamination then this number might > grow in the future to deal with > implementation faults. > > One of the way that these faults might develop is for designers to say - I think > that this should be authenticated, and thus will put it at the wrong layer to > ensure that it is. Either without thinking about the question - should it be > authenticated, or a different algorithm be required so that authentication is > possible. > > 5. Code size is going to be very different if two different methods of dealing > with structure needs to be supported. It is currently being assumed that direct > key is going to be the major use case in a number of situations. > If this is not the case then current proposals do not help the situation any. If it is > true that more than one method of key management needs to be supported > then the code size is going to grow because of the need to support an additional > way that key management is going to be done. > > 6. Personally, I am planning to argue against using direct key in future work of > ACE for long term authentication keys. The fact that it is going to be hard to > rotate them means that one needs to either add a KDF step or else have a key > agreement method to keep the same key from being used for the entire lifetime > of the device (perhaps 30 years?). This is something that is related to the > previous item as we now are going to need to support multiple key management > methods in these cases. > > 7. Now that we are doing arrays, it would be possible to have a generic one > recipient/signer solution by unrolling the recipient/signer structure on the end of > the message. This was originally proposed before the change from arrays to > maps was initially made. Since we are moving from maps back to arrays it is one > again a viable solution to look at. It would be totally viable to have applications > state that there is one recipient/signer and the unrolled version is always used. > This would still allow for multiple key management types to be used. Systems in > more unconstrained spaces could potentially setup to have multiple recipients - > but only if use cases exist where it would be needed. > > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf. > org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro > soft.com%7c42b45138af2043af976708d2a35aa0e5%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=62f4AJob4HGGxfnZpU2Yt7AGjiTJcxW75rCq2jYKlUo% > 3d From nobody Wed Aug 12 21:54:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91AF1B2A36 for ; Wed, 12 Aug 2015 21:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.054 X-Spam-Level: X-Spam-Status: No, score=-4.054 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXmT8qep9eHh for ; Wed, 12 Aug 2015 21:54:40 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F8E1B2A35 for ; Wed, 12 Aug 2015 21:54:40 -0700 (PDT) Date: Wed, 12 Aug 2015 21:54:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1439441679; bh=jRAtTkWt8nmjFwWXEj7Ia8bfAKSgpZBJ/E6VwZS+vuQ=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=oY7uh8fZzhJh3fjIVdCWKpFYzwhVMK78dEz4YQlD2UfpOv0Snk9043nAfdt2dbZUA VT/JhVL/Md8NfuisdGSMeTuSn7xgqSwTSs0C93auBba347oUatn4+10deci5Zms0rq kk42t+OptqsXDFOrC4PihLM2jTRQ9x/euHfsyQRQ= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55cc230f8660e_13593f87598872bc9260e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Add RSA v1.5 Signature to the set of accepted algorithms (#5) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 04:54:43 -0000 ----==_mimepart_55cc230f8660e_13593f87598872bc9260e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Moving this issue from the internal tracker because it has not been resolved in discussions on the list. Does COSE need to have RSA v1.5 signatures added as an algorithm in the base specification? Pro: People seem to think that RSA-PSS is not sufficiently wide spread so that if RSA is going to be supported then v1.5 needs to be supported. There are enough recognized attacks against v1.5 encryption that nobody thinks it should be kept. Con: RSA told us almost 15 years ago to stop using it, use RSA-PSS instead. Yes there are no known attacks against it, but if we don't switchover now when are we going to do so. Don't Care: Everybody, especially in constrained environments, are going to use ECDSA if they use any signature algorithm so who cares what the decision is. People commenting in the email discussion: 3 (two of which are the editors) Punt this issue off until sometime in october. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/5 ----==_mimepart_55cc230f8660e_13593f87598872bc9260e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Moving this issue from the internal tracker because it has not been resolved in discussions on the list.

Does COSE need to have RSA v1.5 signatures added as an algorithm in the base specification?

Pro: People seem to think that RSA-PSS is not sufficiently wide spread so that if RSA is going to be supported then v1.5 needs to be supported. There are enough recognized attacks against v1.5 encryption that nobody thinks it should be kept.

Con: RSA told us almost 15 years ago to stop using it, use RSA-PSS instead. Yes there are no known attacks against it, but if we don't switchover now when are we going to do so.

Don't Care: Everybody, especially in constrained environments, are going to use ECDSA if they use any signature algorithm so who cares what the decision is.

People commenting in the email discussion: 3 (two of which are the editors)

Punt this issue off until sometime in october.

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

----==_mimepart_55cc230f8660e_13593f87598872bc9260e-- From nobody Thu Aug 13 10:53:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF06F1A8F49 for ; Thu, 13 Aug 2015 10:52: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_CHtAg9Mif6 for ; Thu, 13 Aug 2015 10:52:58 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A241A9023 for ; Thu, 13 Aug 2015 10:52:57 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 18B8138F23; Thu, 13 Aug 2015 10:52:57 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> In-Reply-To: Date: Thu, 13 Aug 2015 10:53:20 -0700 Message-ID: <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmgC8OqlTwHK57wSAbj7Yf0B8rD4AZ4WETdg Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 17:52:59 -0000 Brian, I wonder if you have any contacts inside of google to query them why = they went with RSA v1.5. However, I think that if you do it might be = because of the implementation requirements in the JOSE algorithms draft. = I just looked and RS256 is labeled as recommended, but PS256 is = labeled as optional. It appears that similar language is in the JWT = draft. We may find the decision to use RSA v1.5 by google had more to = do with expected JWT libraries than with crypto library support. Jim =20 From nobody Thu Aug 13 11:02:24 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805381B2D25 for ; Thu, 13 Aug 2015 11:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mdtfk-pvgp8U for ; Thu, 13 Aug 2015 11:02:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF741A8F3D for ; Thu, 13 Aug 2015 11:02:17 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 13 Aug 2015 18:02:12 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Thu, 13 Aug 2015 18:02:10 +0000 From: Mike Jones To: Jim Schaad , 'Brian Campbell' Thread-Topic: [COSE] RSA Algorithm Decisions Thread-Index: AdDLFYVQBaFhIPMqQIC5i6cbL8YD+QDHIWQAAAJRXQAAA0+UAAAb9quAAD62XQAA9zPkgACYN5QAAAAtiFA= Date: Thu, 13 Aug 2015 18:02:10 +0000 Message-ID: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> In-Reply-To: <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.95.140.212] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:vMoNvihnZq5GG5PnVH1AF7tbh+dI07/GRosijXdtn9zFMkUEE0ZjTG+A30FTyj+SppfzWNLdGS6mHzwwprFaNzwXqRW0skmKF+skrDUoBOnN16D7X05pb34dc4ovrrZwgySuPBldPVX0NXvtbb1sQA==; 24:JkwMad/eHONWlH60e7ho+h2thxlEw3UET7CGnXSSqsia3hhNijRPlnTqIyCx8bPIKDMtVgYyfX3jpDGFL0uWaxlw8tqpTIHKM5qsfkq8zag=; 20:viTTYTZZ71NM59bMgGiAnUr0wKkHS75YOiBB5r0cg3YOMt7F9ztgKCX3nAwsYKLKMua+Y2wK4AvGSCP7AhGkfQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0667289FF8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(54094003)(51444003)(199003)(377454003)(13464003)(189002)(77156002)(97736004)(50986999)(99936001)(40100003)(5001960100002)(99286002)(5001830100001)(62966003)(66066001)(76176999)(54356999)(5001860100001)(86362001)(101416001)(19580395003)(15975445007)(64706001)(68736005)(74316001)(10290500002)(2656002)(86612001)(19580405001)(87936001)(122556002)(102836002)(5005710100001)(10400500002)(106356001)(5001770100001)(81156007)(33656002)(2900100001)(77096005)(93886004)(4001540100001)(76576001)(8990500004)(92566002)(5003600100002)(5002640100001)(46102003)(105586002)(189998001)(2950100001)(10090500001)(5890100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_BY2PR03MB442106F992CB37412E9C308F57D0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2015 18:02:10.7008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 18:02:23 -0000 --_002_BY2PR03MB442106F992CB37412E9C308F57D0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Google was using RSA v1.5 (with 1024 bit keys) to sign their proprietary to= kens before JWT existed. I'm sure it was because it's ubiquitously availab= le in all Web development tools - as we determined in the survey of algorit= hms supported by common Web development platforms done by the JOSE working = group in mid-2012 (attached). -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, August 13, 2015 1:53 PM To: 'Brian Campbell' Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions Brian, I wonder if you have any contacts inside of google to query them why they w= ent with RSA v1.5. However, I think that if you do it might be because of = the implementation requirements in the JOSE algorithms draft. I just look= ed and RS256 is labeled as recommended, but PS256 is labeled as optional. = It appears that similar language is in the JWT draft. We may find the dec= ision to use RSA v1.5 by google had more to do with expected JWT libraries = than with crypto library support. Jim =20 _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d --_002_BY2PR03MB442106F992CB37412E9C308F57D0BY2PR03MB442namprd_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=18750; creation-date="Thu, 13 Aug 2015 18:01:14 GMT"; modification-date="Thu, 13 Aug 2015 18:01:14 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_002_BY2PR03MB442106F992CB37412E9C308F57D0BY2PR03MB442namprd_-- From nobody Thu Aug 13 11:29:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3DD1B2DB8 for ; Thu, 13 Aug 2015 11:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyiBsgBaar4M for ; Thu, 13 Aug 2015 11:29:19 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1EF1A92F4 for ; Thu, 13 Aug 2015 11:29:18 -0700 (PDT) Received: by iods203 with SMTP id s203so61235271iod.0 for ; Thu, 13 Aug 2015 11:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0+A5eiNYR+dPEKqH2IaHtyhy+0Xwrr1O3VV5lakFslA=; b=oBU7dH6HrZtVliZ9YC94SsHa0eHP0R9tIeQ5std6OQ8MDoSBOxJ8pqOdILjlsj1TBX Mh7rVSTjQPL6Garlq9rg0YJUM5aLsi1s/bKLu7UhhcA2rA8WrZ3YT12FHoy7o4AxS5e4 BpAxucyyXwyAqYzt3uoKCs8piC+mfFnWVhsAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0+A5eiNYR+dPEKqH2IaHtyhy+0Xwrr1O3VV5lakFslA=; b=GPgFfkf8OS0lyKzkzrcqhgZf3sTHHF3D/QWK/oAVoQGnEk0JB0pSKHDo78XGacSROy aJ1BsV2N/MaShhdnViERGdDN4+iK21T6oOSapc8vE/cIqgnO6XxZ+BTrB/BckJ8PcKPM cZJgpQC9gOL+IPAFtbku1p83d2Y1k085Tiv0jQem66CAZXvwM2lIVNWHoyZY0h2QNh7i wBRlDF3cEELhnD51C/uStcAACQNh3anwYBvuLjIxDhjyziK82zl+DEXgXA1aasLVHLEe w/4UY/Pc9YF97JTpqyBYun3bKYtqFZkL5d4vhAu02+SYSaiV/MbsgOSYEOzHNR3zVQHY fjNQ== X-Gm-Message-State: ALoCoQnXpejD40LanZz7RZzKJOpaJr9oxDDYXS0hGiKU4crPI+QWCc0Uwv4rckpayqdAe4gW+XKg X-Received: by 10.107.135.15 with SMTP id j15mr16973980iod.174.1439490558090; Thu, 13 Aug 2015 11:29:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 13 Aug 2015 11:28:48 -0700 (PDT) In-Reply-To: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> From: Brian Campbell Date: Thu, 13 Aug 2015 12:28:48 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113f95725f998b051d3583fb Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 18:29:20 -0000 --001a113f95725f998b051d3583fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I know a couple folks and I'll make an informal query to them. They may or may not know the answer and may or may not reply. But I'll try. I suspect Mike is more right than not, however, which was basically the impetus for my using them as an example in the first place. On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones wrote: > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprietary > tokens before JWT existed. I'm sure it was because it's ubiquitously > available in all Web development tools - as we determined in the survey o= f > algorithms supported by common Web development platforms done by the JOSE > working group in mid-2012 (attached). > > -- Mike > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Thursday, August 13, 2015 1:53 PM > To: 'Brian Campbell' > Cc: cose@ietf.org > Subject: Re: [COSE] RSA Algorithm Decisions > > Brian, > > I wonder if you have any contacts inside of google to query them why they > went with RSA v1.5. However, I think that if you do it might be because = of > the implementation requirements in the JOSE algorithms draft. I just > looked and RS256 is labeled as recommended, but PS256 is labeled as > optional. It appears that similar language is in the JWT draft. We may > find the decision to use RSA v1.5 by google had more to do with expected > JWT libraries than with crypto library support. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microso= ft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d > --001a113f95725f998b051d3583fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I know a couple folks and I'll make an informal q= uery to them.=C2=A0 They may or may not know the answer and may or may not = reply. But I'll try.

I suspect Mike is more right than no= t, however, which was basically the impetus for my using them as an example= in the first place.=C2=A0

On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary tokens before JWT existed.=C2=A0 I'm sure it was because it= 's ubiquitously available in all Web development tools - as we determin= ed in the survey of algorithms supported by common Web development platform= s done by the JOSE working group in mid-2012 (attached).

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

-----Original Message-----
From: COSE [mailto:cose-bounces@ie= tf.org] On Behalf Of Jim Schaad
Sent: Thursday, August 13, 2015 1:53 PM
To: 'Brian Campbell'
Cc: cose@ietf.org
Subject: Re: [COSE] RSA Algorithm Decisions

Brian,

I wonder if you have any contacts inside of google to query them why they w= ent with RSA v1.5.=C2=A0 However, I think that if you do it might be becaus= e of the implementation requirements in the JOSE algorithms draft.=C2=A0 = =C2=A0I just looked and RS256 is labeled as recommended, but PS256 is label= ed as optional.=C2=A0 It appears that similar language is in the JWT draft.= =C2=A0 =C2=A0We may find the decision to use RSA v1.5 by google had more to= do with expected JWT libraries than with crypto library support.

Jim


______________________________________________= _
COSE mailing list
COSE@ietf.org
https://na01.safelinks.pr= otection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo= %2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40= ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%= 2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d

--001a113f95725f998b051d3583fb-- From nobody Thu Aug 13 11:31:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5768F1B2DBC for ; Thu, 13 Aug 2015 11:30:58 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY3S2DfUCGI8 for ; Thu, 13 Aug 2015 11:30:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173551B2DCA for ; Thu, 13 Aug 2015 11:30:55 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 13 Aug 2015 18:30:39 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Thu, 13 Aug 2015 18:30:39 +0000 From: Mike Jones To: Dirk Balfanz Thread-Topic: [COSE] RSA Algorithm Decisions Thread-Index: AdDLFYVQBaFhIPMqQIC5i6cbL8YD+QDHIWQAAAJRXQAAA0+UAAAb9quAAD62XQAA9zPkgACYN5QAAAAtiFAAAQ+RAAAAB+hA Date: Thu, 13 Aug 2015 18:30:39 +0000 Message-ID: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.95.140.212] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:vHsnpoRt3nEw1SOkVUFgWgJFru5jPa5o2yiKeaB4/A7v2wHLG9nBBKns5U7HP/09Upwgm6qeyDM445cVQVC1ziKLCxTo1mFEsDDrnkPVhfDOXusU27TVc+7lhdkcvD33vH1UHGlAFZV1RnNYtARbJw==; 24:ui4id3nPAj3/Ldp5cELjm5qMY6q8fXBlTmJSwphncvfZz3nA/n/FzUyJhTdrIjn83hGK8MXTChGptpqaSLIDPScAo3tU9ymu5d7Yvq+tbr8=; 20:IAQhftRnBTFuJIqQrQ34u43HXUQ1jldf9HLrqk4DjHgoyV9lFS/FyxYgvcL6iWKl5Q9yOWFaUNag+7uKQPzMBQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0667289FF8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(54094003)(51444003)(199003)(377454003)(189002)(13464003)(77156002)(16236675004)(97736004)(50986999)(40100003)(5001960100002)(19609705001)(99286002)(5001830100001)(62966003)(66066001)(54356999)(76176999)(86362001)(5001860100001)(101416001)(19580395003)(110136002)(19300405004)(15975445007)(68736005)(74316001)(2656002)(10290500002)(64706001)(86612001)(19580405001)(87936001)(122556002)(102836002)(5005710100001)(10400500002)(106356001)(33656002)(81156007)(19625215002)(2900100001)(77096005)(93886004)(4001540100001)(76576001)(8990500004)(92566002)(19617315012)(5003600100002)(5002640100001)(46102003)(105586002)(189998001)(2950100001)(10090500001)(5890100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4426A4C297A9330150AB7A6F57D0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2015 18:30:39.6807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: Jim Schaad , Brian Campbell , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 18:30:58 -0000 --_000_BY2PR03MB4426A4C297A9330150AB7A6F57D0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlyayDigJMgeW914oCZcmUgb24gdGhpcyBsaXN0LCBjb3JyZWN0PyAgRG8geW91IGhhdmUgYW55 IGNvbW1lbnRzIG9uIHdoeSBHb29nbGUgaXMgdXNpbmcgUlNBU1NBIHYxLjUgdG8gc2lnbiB0aGlu Z3M/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTMsIDIwMTUgMjoy OSBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBKaW0gU2NoYWFkOyBjb3NlQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0NPU0VdIFJTQSBBbGdvcml0aG0gRGVjaXNpb25zDQoNCkkga25vdyBhIGNvdXBs ZSBmb2xrcyBhbmQgSSdsbCBtYWtlIGFuIGluZm9ybWFsIHF1ZXJ5IHRvIHRoZW0uICBUaGV5IG1h eSBvciBtYXkgbm90IGtub3cgdGhlIGFuc3dlciBhbmQgbWF5IG9yIG1heSBub3QgcmVwbHkuIEJ1 dCBJJ2xsIHRyeS4NCkkgc3VzcGVjdCBNaWtlIGlzIG1vcmUgcmlnaHQgdGhhbiBub3QsIGhvd2V2 ZXIsIHdoaWNoIHdhcyBiYXNpY2FsbHkgdGhlIGltcGV0dXMgZm9yIG15IHVzaW5nIHRoZW0gYXMg YW4gZXhhbXBsZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCk9uIFRodSwgQXVnIDEzLCAyMDE1IGF0 IDEyOjAyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KR29vZ2xlIHdhcyB1c2luZyBS U0EgdjEuNSAod2l0aCAxMDI0IGJpdCBrZXlzKSB0byBzaWduIHRoZWlyIHByb3ByaWV0YXJ5IHRv a2VucyBiZWZvcmUgSldUIGV4aXN0ZWQuICBJJ20gc3VyZSBpdCB3YXMgYmVjYXVzZSBpdCdzIHVi aXF1aXRvdXNseSBhdmFpbGFibGUgaW4gYWxsIFdlYiBkZXZlbG9wbWVudCB0b29scyAtIGFzIHdl IGRldGVybWluZWQgaW4gdGhlIHN1cnZleSBvZiBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSBjb21t b24gV2ViIGRldmVsb3BtZW50IHBsYXRmb3JtcyBkb25lIGJ5IHRoZSBKT1NFIHdvcmtpbmcgZ3Jv dXAgaW4gbWlkLTIwMTIgKGF0dGFjaGVkKS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDT1NFIFtt YWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgSmltIFNjaGFhZA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMywgMjAx NSAxOjUzIFBNDQpUbzogJ0JyaWFuIENhbXBiZWxsJw0KQ2M6IGNvc2VAaWV0Zi5vcmc8bWFpbHRv OmNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NPU0VdIFJTQSBBbGdvcml0aG0gRGVjaXNp b25zDQpCcmlhbiwNCg0KSSB3b25kZXIgaWYgeW91IGhhdmUgYW55IGNvbnRhY3RzIGluc2lkZSBv ZiBnb29nbGUgdG8gcXVlcnkgdGhlbSB3aHkgdGhleSB3ZW50IHdpdGggUlNBIHYxLjUuICBIb3dl dmVyLCBJIHRoaW5rIHRoYXQgaWYgeW91IGRvIGl0IG1pZ2h0IGJlIGJlY2F1c2Ugb2YgdGhlIGlt cGxlbWVudGF0aW9uIHJlcXVpcmVtZW50cyBpbiB0aGUgSk9TRSBhbGdvcml0aG1zIGRyYWZ0LiAg IEkganVzdCBsb29rZWQgYW5kIFJTMjU2IGlzIGxhYmVsZWQgYXMgcmVjb21tZW5kZWQsIGJ1dCBQ UzI1NiBpcyBsYWJlbGVkIGFzIG9wdGlvbmFsLiAgSXQgYXBwZWFycyB0aGF0IHNpbWlsYXIgbGFu Z3VhZ2UgaXMgaW4gdGhlIEpXVCBkcmFmdC4gICBXZSBtYXkgZmluZCB0aGUgZGVjaXNpb24gdG8g dXNlIFJTQSB2MS41IGJ5IGdvb2dsZSBoYWQgbW9yZSB0byBkbyB3aXRoIGV4cGVjdGVkIEpXVCBs aWJyYXJpZXMgdGhhbiB3aXRoIGNyeXB0byBsaWJyYXJ5IHN1cHBvcnQuDQoNCkppbQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5n IGxpc3QNCkNPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5vcmc+DQpodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5p ZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZmNvc2UmZGF0YT0wMSU3YzAxJTdjTWljaGFl bC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2MwOTM4YjNmYmVkYWU0MGVjODBkNjA4ZDJhNDA4MDg0 NCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1UUDdCJTJmMWF3 TjdFNFZwQVJFQXVBRzJFTjdOZlI5Y1NKMjY1bzhQTU9MbjAlM2QNCg0K --_000_BY2PR03MB4426A4C297A9330150AB7A6F57D0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5EaXJrIOKAkyB5b3XigJlyZSBvbiB0aGlzIGxpc3QsIGNvcnJlY3Q/Jm5ic3A7IERvIHlv dSBoYXZlIGFueSBjb21tZW50cyBvbiB3aHkgR29vZ2xlIGlzIHVzaW5nIFJTQVNTQSB2MS41IHRv IHNpZ24gdGhpbmdzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1 Z3VzdCAxMywgMjAxNSAyOjI5IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+ Q2M6PC9iPiBKaW0gU2NoYWFkOyBjb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbQ09TRV0gUlNBIEFsZ29yaXRobSBEZWNpc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGtub3cg YSBjb3VwbGUgZm9sa3MgYW5kIEknbGwgbWFrZSBhbiBpbmZvcm1hbCBxdWVyeSB0byB0aGVtLiZu YnNwOyBUaGV5IG1heSBvciBtYXkgbm90IGtub3cgdGhlIGFuc3dlciBhbmQgbWF5IG9yIG1heSBu b3QgcmVwbHkuIEJ1dCBJJ2xsIHRyeS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHN1c3BlY3QgTWlrZSBpcyBtb3JlIHJpZ2h0IHRoYW4gbm90LCBob3dl dmVyLCB3aGljaCB3YXMgYmFzaWNhbGx5IHRoZSBpbXBldHVzIGZvciBteSB1c2luZyB0aGVtIGFz IGFuIGV4YW1wbGUgaW4gdGhlIGZpcnN0IHBsYWNlLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAxMywgMjAxNSBhdCAxMjow MiBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5Hb29nbGUgd2FzIHVzaW5nIFJTQSB2MS41ICh3aXRoIDEwMjQg Yml0IGtleXMpIHRvIHNpZ24gdGhlaXIgcHJvcHJpZXRhcnkgdG9rZW5zIGJlZm9yZSBKV1QgZXhp c3RlZC4mbmJzcDsgSSdtIHN1cmUgaXQgd2FzIGJlY2F1c2UgaXQncyB1YmlxdWl0b3VzbHkgYXZh aWxhYmxlIGluIGFsbCBXZWIgZGV2ZWxvcG1lbnQgdG9vbHMgLSBhcyB3ZSBkZXRlcm1pbmVkIGlu IHRoZQ0KIHN1cnZleSBvZiBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSBjb21tb24gV2ViIGRldmVs b3BtZW50IHBsYXRmb3JtcyBkb25lIGJ5IHRoZSBKT1NFIHdvcmtpbmcgZ3JvdXAgaW4gbWlkLTIw MTIgKGF0dGFjaGVkKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gTWlrZTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQ09TRSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjb3Nl LWJvdW5jZXNAaWV0Zi5vcmciPmNvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBKaW0gU2NoYWFkPGJyPg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMywgMjAxNSAxOjUzIFBN PGJyPg0KVG86ICdCcmlhbiBDYW1wYmVsbCc8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOmNvc2VA aWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtDT1NFXSBSU0Eg QWxnb3JpdGhtIERlY2lzaW9uczxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJyaWFuLDxicj4NCjxi cj4NCkkgd29uZGVyIGlmIHlvdSBoYXZlIGFueSBjb250YWN0cyBpbnNpZGUgb2YgZ29vZ2xlIHRv IHF1ZXJ5IHRoZW0gd2h5IHRoZXkgd2VudCB3aXRoIFJTQSB2MS41LiZuYnNwOyBIb3dldmVyLCBJ IHRoaW5rIHRoYXQgaWYgeW91IGRvIGl0IG1pZ2h0IGJlIGJlY2F1c2Ugb2YgdGhlIGltcGxlbWVu dGF0aW9uIHJlcXVpcmVtZW50cyBpbiB0aGUgSk9TRSBhbGdvcml0aG1zIGRyYWZ0LiZuYnNwOyAm bmJzcDtJIGp1c3QgbG9va2VkIGFuZCBSUzI1NiBpcyBsYWJlbGVkIGFzIHJlY29tbWVuZGVkLA0K IGJ1dCBQUzI1NiBpcyBsYWJlbGVkIGFzIG9wdGlvbmFsLiZuYnNwOyBJdCBhcHBlYXJzIHRoYXQg c2ltaWxhciBsYW5ndWFnZSBpcyBpbiB0aGUgSldUIGRyYWZ0LiZuYnNwOyAmbmJzcDtXZSBtYXkg ZmluZCB0aGUgZGVjaXNpb24gdG8gdXNlIFJTQSB2MS41IGJ5IGdvb2dsZSBoYWQgbW9yZSB0byBk byB3aXRoIGV4cGVjdGVkIEpXVCBsaWJyYXJpZXMgdGhhbiB3aXRoIGNyeXB0byBsaWJyYXJ5IHN1 cHBvcnQuPGJyPg0KPGJyPg0KSmltPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpDT1NFIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpDT1NFQGlldGYub3JnIj5DT1NFQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmY29zZSZhbXA7ZGF0YT0w MSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2MwOTM4YjNmYmVkYWU0MGVj ODBkNjA4ZDJhNDA4MDg0NCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh bXA7c2RhdGE9VFA3QiUyZjFhd043RTRWcEFSRUF1QUcyRU43TmZSOWNTSjI2NW84UE1PTG4wJTNk IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGlu Zm8lMmZjb3NlJmFtcDtkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNv bSU3YzA5MzhiM2ZiZWRhZTQwZWM4MGQ2MDhkMmE0MDgwODQ0JTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1UUDdCJTJmMWF3TjdFNFZwQVJFQXVBRzJFTjdO ZlI5Y1NKMjY1bzhQTU9MbjAlM2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB4426A4C297A9330150AB7A6F57D0BY2PR03MB442namprd_-- From nobody Thu Aug 13 11:35:33 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2A71B2DB6 for ; Thu, 13 Aug 2015 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z81b2BFAXrrT for ; Thu, 13 Aug 2015 11:35:30 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 0E2BD1B2DD1 for ; Thu, 13 Aug 2015 11:35:30 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so85903889wib.0 for ; Thu, 13 Aug 2015 11:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UN9WcI9CKwxSWb3jpSiK0TGuVV+5L38GvU5FAGhh3NE=; b=fz5QroTfeMVu1xXRT6nu74jRj/5LEcwI4Vfr421LIUi9pdLZEDonshODFd8Z9Okjaf YnPupenoDZJV6M5iAGIJJCcyXHte+ixVZeihKGy7/VCBU3yasxpV/RZojBN2jE7ZeoDA nqFlgerEnpy8oflZhJ1ApVkBT64cqt8+yv26jiQQwxd7Ms/RRnhmtFNaewFmVyppEozd GQy8RmlhzJKqhnU6Zsl9Tm61TqlfSt8Ct0oRrmNOxnooSULG1uVBYRAm5DR/rdPvOcQo 34watk+R4PDzd8EOOFJGNLUuKlrLCfA4plKuGlXuHfvXROmfEt1bOAwss0xubr/bE0Xp uHPA== MIME-Version: 1.0 X-Received: by 10.180.87.230 with SMTP id bb6mr8954459wib.36.1439490928772; Thu, 13 Aug 2015 11:35:28 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Thu, 13 Aug 2015 11:35:28 -0700 (PDT) In-Reply-To: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> Date: Thu, 13 Aug 2015 14:35:28 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jim Schaad , Brian Campbell , Dirk Balfanz , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 18:35:32 -0000 It would be good to get an answer from folks actually using it, but there is no reason we can't move forward without it. Google and other vendors have been very good about deprecating algorithms and protocols in their products, and even making customers aware when they are in use (browsers with https in red with a strikethrough and Mozilla using a yellow caution triangle). Since COSE isn't deployed yet, I think it's okay and a good thing to be forward thinking. Kathleen On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones w= rote: > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have any com= ments on why Google > is using RSASSA v1.5 to sign things? > > > > -- Mike > > > > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Thursday, August 13, 2015 2:29 PM > To: Mike Jones > Cc: Jim Schaad; cose@ietf.org > Subject: Re: [COSE] RSA Algorithm Decisions > > > > I know a couple folks and I'll make an informal query to them. They may = or > may not know the answer and may or may not reply. But I'll try. > > I suspect Mike is more right than not, however, which was basically the > impetus for my using them as an example in the first place. > > > > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones > wrote: > > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprietary > tokens before JWT existed. I'm sure it was because it's ubiquitously > available in all Web development tools - as we determined in the survey o= f > algorithms supported by common Web development platforms done by the JOSE > working group in mid-2012 (attached). > > -- Mike > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Thursday, August 13, 2015 1:53 PM > To: 'Brian Campbell' > Cc: cose@ietf.org > Subject: Re: [COSE] RSA Algorithm Decisions > > Brian, > > I wonder if you have any contacts inside of google to query them why they > went with RSA v1.5. However, I think that if you do it might be because = of > the implementation requirements in the JOSE algorithms draft. I just > looked and RS256 is labeled as recommended, but PS256 is labeled as > optional. It appears that similar language is in the JWT draft. We may > find the decision to use RSA v1.5 by google had more to do with expected = JWT > libraries than with crypto library support. > > Jim > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microso= ft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --=20 Best regards, Kathleen From nobody Sun Aug 16 14:48:51 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04F1AD0C3 for ; Sun, 16 Aug 2015 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vywLqSVSJvWm for ; Sun, 16 Aug 2015 14:48:47 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3211AD0C7 for ; Sun, 16 Aug 2015 14:48:46 -0700 (PDT) Date: Sun, 16 Aug 2015 14:48:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1439761724; bh=/Zb253ViCp+x2Zd+KG/2Cyt3OO8mVUWbmmF7hIni5NM=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Qoz4Y+wrtMmdwpyOnyfFCQXcvZ6kvW6jLTQP+fuB0l/Rg9FWqfyT8tf/9s46GJ7Af sl1EnHGFBT56KtXpMr8/mvsNamxs9CNnEvbd1ZnPAvVEJttIEvx73ZnRaunwBpXOoa QlwrghNklp1ayofDiL517UPeJ8ge3C43uzJ7+yrw= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55d1053c3bcd7_6fe93f899d1d72a0268632"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-GitHub-Reason: comment X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Cc: cose-ietf Subject: Re: [COSE] [cose-issues] Registry for media-types (#4) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 21:48:49 -0000 ----==_mimepart_55d1053c3bcd7_6fe93f899d1d72a0268632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Addressed in pull request cose-wg/cose-spec#70 --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/4#issuecomment-131630369 ----==_mimepart_55d1053c3bcd7_6fe93f899d1d72a0268632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Addressed in pull request cose-wg/cose-spec#70

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

----==_mimepart_55d1053c3bcd7_6fe93f899d1d72a0268632-- From nobody Sun Aug 16 14:56:53 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4681AD0D3 for ; Sun, 16 Aug 2015 14:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-PoJ4SE4Ob2 for ; Sun, 16 Aug 2015 14:56:51 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41DB1AD0D2 for ; Sun, 16 Aug 2015 14:56:50 -0700 (PDT) Date: Sun, 16 Aug 2015 14:56:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1439762210; bh=ggeN/Zlo6Soc4ob747ciuSpbPvzy1N4x+nPo6vyXSAA=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FAAtBTo2H3J0JDT+PAfRVOIZmez7bFAShLhNrOOygH7V0tnucZvxCfPsuMeGMvhe4 X1NvBy08th2ak/R7D0YwpDugsO+31s9Ok9j8EI26CMaIcan1SQwrHS7C77RxgEKEEJ aX2GRWvnE4U11jXiitzWrhCAKHCr4FzrByteYd3w= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55d107221caad_75e43f899d1d72a0107974c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Key Management is an ambiguous term (#2) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 21:56:52 -0000 ----==_mimepart_55d107221caad_75e43f899d1d72a0107974c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #2 via cose-wg/cose-spec#71. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/2#event-383700695 ----==_mimepart_55d107221caad_75e43f899d1d72a0107974c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #2 via cose-wg/cose-spec#71.

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

----==_mimepart_55d107221caad_75e43f899d1d72a0107974c-- From nobody Mon Aug 17 06:22:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAF31B2E30 for ; Mon, 17 Aug 2015 06:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy9TGJ6tR7JQ for ; Mon, 17 Aug 2015 06:22:37 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D0F1B2E2C for ; Mon, 17 Aug 2015 06:22:37 -0700 (PDT) Received: by igui7 with SMTP id i7so56691575igu.1 for ; Mon, 17 Aug 2015 06:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zarIPA/8kBn7G6/AWUeu5Fo8jquOlaSupGCsxPfU+Ww=; b=F3+KrxTovMyNY0dRjm+1rXzIwYgYcYULnb6aRDvHzoAWHqqDJnFn8vIy681rxcrxDa 2LmSBDQbYFlN8pVSUpYa8t/Pv2ScWVxEsodbFFpq9fzfIxxfqZZpMJ17pI0x7xpV+O86 10WEiLFqvkUu1tvy6Bzz0v6mGYEn2SlhDhq0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zarIPA/8kBn7G6/AWUeu5Fo8jquOlaSupGCsxPfU+Ww=; b=JCdwZ+erczfXakulev1zgSNhw8oVRm9u8LJqThyOwlzeTVDcxC2VL5Jlu8f7eF6qHR BADWhEDFmYUBkyakJ4pFdDSdBCBMqEl1Y6Ra4AEGZ1Z2K5Vwum46B+6rLv8CgfbULZt/ PQoQWCgJ1/1EOSSVJqqCNtQr7/AzbKXk8djb+rg9/kehYTHMeyULGQUF1jLXDgTHXB8g 1pSFiRsiB8hfmv0N71t4giUTdkVlFYM9YUJ11XGnNGkRXbxwkpoX5qBeWJe37R8wg6p4 k6RA4lIIVF5CjUK9CG/Lm2dch8yK4ifwBu8pfPVHbQN9nDv3NupiX33mks23MmcqZnP8 4fbQ== X-Gm-Message-State: ALoCoQktmaUQ5BtUgV0wuy2G497jnOMPtz1Z/08ysnjmBZf/7I5mcYUF0rPMN+rvL9DrG0GmKxgi X-Received: by 10.50.50.175 with SMTP id d15mr16525603igo.18.1439817756673; Mon, 17 Aug 2015 06:22:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Mon, 17 Aug 2015 06:22:07 -0700 (PDT) In-Reply-To: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> From: Brian Campbell Date: Mon, 17 Aug 2015 07:22:07 -0600 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=047d7b2e549ceda4cf051d81b10c Archived-At: Cc: Mike Jones , Dirk Balfanz , Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 13:22:39 -0000 --047d7b2e549ceda4cf051d81b10c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I got an answer back from Google on their selection of RSASSA-PKCS1-v1_5 for signing of tokens, which I'll quote here: "We [Google] will always use an asymmetric alg so we can rotate keys. Of the asymmetric algs, RSA 1.5 was chosen due to its wide availability for client libraries at the time. If we were to support a newer alg in the future, it would also be an asymmetric one." On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > It would be good to get an answer from folks actually using it, but > there is no reason we can't move forward without it. Google and other > vendors have been very good about deprecating algorithms and protocols > in their products, and even making customers aware when they are in > use (browsers with https in red with a strikethrough and Mozilla using > a yellow caution triangle). > > Since COSE isn't deployed yet, I think it's okay and a good thing to > be forward thinking. > > Kathleen > > On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones > wrote: > > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have any c= omments on why > Google > > is using RSASSA v1.5 to sign things? > > > > > > > > -- Mike > > > > > > > > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > > Sent: Thursday, August 13, 2015 2:29 PM > > To: Mike Jones > > Cc: Jim Schaad; cose@ietf.org > > Subject: Re: [COSE] RSA Algorithm Decisions > > > > > > > > I know a couple folks and I'll make an informal query to them. They ma= y > or > > may not know the answer and may or may not reply. But I'll try. > > > > I suspect Mike is more right than not, however, which was basically the > > impetus for my using them as an example in the first place. > > > > > > > > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones < > Michael.Jones@microsoft.com> > > wrote: > > > > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprietar= y > > tokens before JWT existed. I'm sure it was because it's ubiquitously > > available in all Web development tools - as we determined in the survey > of > > algorithms supported by common Web development platforms done by the JO= SE > > working group in mid-2012 (attached). > > > > -- Mike > > > > -----Original Message----- > > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: Thursday, August 13, 2015 1:53 PM > > To: 'Brian Campbell' > > Cc: cose@ietf.org > > Subject: Re: [COSE] RSA Algorithm Decisions > > > > Brian, > > > > I wonder if you have any contacts inside of google to query them why th= ey > > went with RSA v1.5. However, I think that if you do it might be becaus= e > of > > the implementation requirements in the JOSE algorithms draft. I just > > looked and RS256 is labeled as recommended, but PS256 is labeled as > > optional. It appears that similar language is in the JWT draft. We m= ay > > find the decision to use RSA v1.5 by google had more to do with expecte= d > JWT > > libraries than with crypto library support. > > > > Jim > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microso= ft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d > > > > > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > > > -- > > Best regards, > Kathleen > --047d7b2e549ceda4cf051d81b10c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I got an answer back from Google on their selection of RSA= SSA-PKCS1-v1_5 for signing of tokens, which I'll quote here:

&q= uot;We [Google] will always use an asymmetric alg so we can rotate keys.=C2= =A0 Of the=20 asymmetric algs, RSA 1.5 was chosen due to its wide availability for=20 client libraries at the time.=C2=A0 If we were to support a newer alg in th= e=20 future, it would also be an asymmetric one."



On Thu, Aug 13, 2015 at 1= 2:35 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m> wrote:
It would be good = to get an answer from folks actually using it, but
there is no reason we can't move forward without it.=C2=A0 Google and o= ther
vendors have been very good about deprecating algorithms and protocols
in their products, and even making customers aware when they are in
use (browsers with https in red with a strikethrough and Mozilla using
a yellow caution triangle).

Since COSE isn't deployed yet, I think it's okay and a good thing t= o
be forward thinking.

Kathleen

On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> Dirk =E2=80=93 you=E2=80=99re on this list, correct?=C2=A0 Do you have= any comments on why Google
> is using RSASSA v1.5 to sign things?
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= Mike
>
>
>
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Thursday, August 13, 2015 2:29 PM
> To: Mike Jones
> Cc: Jim Schaad; cose@ietf.org
> Subject: Re: [COSE] RSA Algorithm Decisions
>
>
>
> I know a couple folks and I'll make an informal query to them.=C2= =A0 They may or
> may not know the answer and may or may not reply. But I'll try. >
> I suspect Mike is more right than not, however, which was basically th= e
> impetus for my using them as an example in the first place.
>
>
>
> On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> Google was using RSA v1.5 (with 1024 bit keys) to sign their proprieta= ry
> tokens before JWT existed.=C2=A0 I'm sure it was because it's = ubiquitously
> available in all Web development tools - as we determined in the surve= y of
> algorithms supported by common Web development platforms done by the J= OSE
> working group in mid-2012 (attached).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: COSE [mailto:cose-bounc= es@ietf.org] On Behalf Of Jim Schaad
> Sent: Thursday, August 13, 2015 1:53 PM
> To: 'Brian Campbell'
> Cc: cose@ietf.org
> Subject: Re: [COSE] RSA Algorithm Decisions
>
> Brian,
>
> I wonder if you have any contacts inside of google to query them why t= hey
> went with RSA v1.5.=C2=A0 However, I think that if you do it might be = because of
> the implementation requirements in the JOSE algorithms draft.=C2=A0 = =C2=A0I just
> looked and RS256 is labeled as recommended, but PS256 is labeled as > optional.=C2=A0 It appears that similar language is in the JWT draft.= =C2=A0 =C2=A0We may
> find the decision to use RSA v1.5 by google had more to do with expect= ed JWT
> libraries than with crypto library support.
>
> Jim
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://na01.safelinks.prot= ection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2= fcose&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec= 80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f= 1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d
>
>
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cos= e
>



--

Best regards,
Kathleen

--047d7b2e549ceda4cf051d81b10c-- From nobody Mon Aug 17 06:34:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC75F1B2E42 for ; Mon, 17 Aug 2015 06:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZqizxlLGqgx for ; Mon, 17 Aug 2015 06:34:33 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 A78B61B2E51 for ; Mon, 17 Aug 2015 06:34:32 -0700 (PDT) Received: by wicne3 with SMTP id ne3so71003383wic.0 for ; Mon, 17 Aug 2015 06:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=E39q5Js4A/ds8nEQFVnl8CiSackttEaEzlOaYbjf43Y=; b=HD3a28agTWKukfaRboU9UluiQFJqxIK1r7MO7rxoFs3+yPrr1TVrQqOXUVwbZDF280 dvPPd1ZZPhGK+zRKqSmqLaLakbx3VpoVInGRBVwP+iMghneHEJue7y2aKNQsNDN5dvKO TdxkosR8RBcdMfBBCi9YbfWOQ70L+BAGG/JRAcuZxRn4oiX0MVS4QFu7FY9dSdsK1FJG fYHyDQFk7wDlJX848kFU+7ENJA814z36U9Vy9cvHwqa+0/AFczA6XLLsD3AHDVynbhU0 uP22xC6QYc6fF2fiFKm95V5YWHDw4zUKgeSxchDqvqghJHsT52lAIV1iXUV1G1AiuZuv +nzQ== MIME-Version: 1.0 X-Received: by 10.194.2.9 with SMTP id 9mr2626335wjq.95.1439818471415; Mon, 17 Aug 2015 06:34:31 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Mon, 17 Aug 2015 06:34:31 -0700 (PDT) In-Reply-To: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> Date: Mon, 17 Aug 2015 09:34:31 -0400 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mike Jones , Dirk Balfanz , Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 13:34:34 -0000 Thanks for tracking that down. If we were to not include it, we would just need to recommend an asymmetric choice and ask them to join the discussion. Google and other organizations are usually very good about staying with current recommendation. Since COSE has not been implemented, it seems like a good time to do the right thing. Thanks, Kathleen On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell wrote: > I got an answer back from Google on their selection of RSASSA-PKCS1-v1_5 = for > signing of tokens, which I'll quote here: > > "We [Google] will always use an asymmetric alg so we can rotate keys. Of > the asymmetric algs, RSA 1.5 was chosen due to its wide availability for > client libraries at the time. If we were to support a newer alg in the > future, it would also be an asymmetric one." > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > wrote: >> >> It would be good to get an answer from folks actually using it, but >> there is no reason we can't move forward without it. Google and other >> vendors have been very good about deprecating algorithms and protocols >> in their products, and even making customers aware when they are in >> use (browsers with https in red with a strikethrough and Mozilla using >> a yellow caution triangle). >> >> Since COSE isn't deployed yet, I think it's okay and a good thing to >> be forward thinking. >> >> Kathleen >> >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones >> wrote: >> > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have any = comments on why >> > Google >> > is using RSASSA v1.5 to sign things? >> > >> > >> > >> > -- Mike >> > >> > >> > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> > Sent: Thursday, August 13, 2015 2:29 PM >> > To: Mike Jones >> > Cc: Jim Schaad; cose@ietf.org >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > >> > >> > I know a couple folks and I'll make an informal query to them. They m= ay >> > or >> > may not know the answer and may or may not reply. But I'll try. >> > >> > I suspect Mike is more right than not, however, which was basically th= e >> > impetus for my using them as an example in the first place. >> > >> > >> > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones >> > >> > wrote: >> > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprieta= ry >> > tokens before JWT existed. I'm sure it was because it's ubiquitously >> > available in all Web development tools - as we determined in the surve= y >> > of >> > algorithms supported by common Web development platforms done by the >> > JOSE >> > working group in mid-2012 (attached). >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >> > Sent: Thursday, August 13, 2015 1:53 PM >> > To: 'Brian Campbell' >> > Cc: cose@ietf.org >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > Brian, >> > >> > I wonder if you have any contacts inside of google to query them why >> > they >> > went with RSA v1.5. However, I think that if you do it might be becau= se >> > of >> > the implementation requirements in the JOSE algorithms draft. I just >> > looked and RS256 is labeled as recommended, but PS256 is labeled as >> > optional. It appears that similar language is in the JWT draft. We >> > may >> > find the decision to use RSA v1.5 by google had more to do with expect= ed >> > JWT >> > libraries than with crypto library support. >> > >> > Jim >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= .ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micr= osoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d >> > >> > >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > https://www.ietf.org/mailman/listinfo/cose >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > --=20 Best regards, Kathleen From nobody Mon Aug 17 10:51:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9651ACE06 for ; Mon, 17 Aug 2015 10:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A46P8Qr4k4Rv for ; Mon, 17 Aug 2015 10:51:16 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 A799D1ACE05 for ; Mon, 17 Aug 2015 10:51:16 -0700 (PDT) Received: by igxp17 with SMTP id p17so61857876igx.1 for ; Mon, 17 Aug 2015 10:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GWYrhsBUCHE2L+PLNgtfHIL2xyZI1Sdi/U7S+ipd//U=; b=b4BeLnmzbR7BiU2um1yKglhyfNLd5DkjQmLrZA45snhN2eJWJrztbuKqqiYd2BLGEH vEGB8SSPZBul6cyLQVhskra3tdtHQE9YExTbd2bCYV1o9x/kmaSmitCQ9fYsSkucfjkj pANyIIYpFSUL5WXbcCBOuBwYFrt+1kdSPfas0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GWYrhsBUCHE2L+PLNgtfHIL2xyZI1Sdi/U7S+ipd//U=; b=E23wBFWe5y4vGgTbs4KfT07BYHimxpBcqbFI9hlD0HuAvpXcAL/AjUnkqJYdhDZjY7 cHf3JmrWOO2O/6iMqEozUQod0cP1DcERPRoYVLljH7nCN8jjRoSagLAWpEHaaA2NPHeJ wCEOyFV5JVBECXZoEyIJdpFh0JlcJlk+uoZTkS1aXeh0B6AsTwTeq2f3RLJfxnW6SEEz JGwEpDqlASS1ovObOb54UF51h8TqH0epSFsNqatdOvcBIuHTAgjGhJ7/z770gOP2qEdq IfC9Lnetr18uEsB2AadXnMX2f6RjK3BUQPSCXCXTpmn7Cm36pnEL0/Sm+LvRC3RX1sy0 zjoQ== X-Gm-Message-State: ALoCoQlThaEgdfR3Gt/N+RmT9GKKgx9ZKZK3x6AG/MM1Zj6XGTId+yeio90PKADiiOiXrgOzovDs X-Received: by 10.50.64.147 with SMTP id o19mr18558426igs.15.1439833876003; Mon, 17 Aug 2015 10:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Mon, 17 Aug 2015 10:50:46 -0700 (PDT) In-Reply-To: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> From: Brian Campbell Date: Mon, 17 Aug 2015 11:50:46 -0600 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=047d7bea2f98b72ba4051d85728d Archived-At: Cc: Mike Jones , Dirk Balfanz , Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:51:19 -0000 --047d7bea2f98b72ba4051d85728d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I didn't bring up Google's use of RSA1.5 with respect to them using or not using COSE. I don't know about their interest in COSE one way or the other. I brought it up as a proxy, of sorts, for a sampling of real world support for asymmetric signature algorithms in practice out in the 'real world'. They are signing tokens which will be consumed on an extremely wide variety of platforms and systems. They chose RSA1.5 for that due to its "wide availability." On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks for tracking that down. If we were to not include it, we would > just need to recommend an asymmetric choice and ask them to join the > discussion. Google and other organizations are usually very good > about staying with current recommendation. Since COSE has not been > implemented, it seems like a good time to do the right thing. > > Thanks, > Kathleen > > On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > wrote: > > I got an answer back from Google on their selection of RSASSA-PKCS1-v1_= 5 > for > > signing of tokens, which I'll quote here: > > > > "We [Google] will always use an asymmetric alg so we can rotate keys. = Of > > the asymmetric algs, RSA 1.5 was chosen due to its wide availability fo= r > > client libraries at the time. If we were to support a newer alg in the > > future, it would also be an asymmetric one." > > > > > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > wrote: > >> > >> It would be good to get an answer from folks actually using it, but > >> there is no reason we can't move forward without it. Google and other > >> vendors have been very good about deprecating algorithms and protocols > >> in their products, and even making customers aware when they are in > >> use (browsers with https in red with a strikethrough and Mozilla using > >> a yellow caution triangle). > >> > >> Since COSE isn't deployed yet, I think it's okay and a good thing to > >> be forward thinking. > >> > >> Kathleen > >> > >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones < > Michael.Jones@microsoft.com> > >> wrote: > >> > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have an= y comments on why > >> > Google > >> > is using RSASSA v1.5 to sign things? > >> > > >> > > >> > > >> > -- Mike > >> > > >> > > >> > > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > >> > Sent: Thursday, August 13, 2015 2:29 PM > >> > To: Mike Jones > >> > Cc: Jim Schaad; cose@ietf.org > >> > Subject: Re: [COSE] RSA Algorithm Decisions > >> > > >> > > >> > > >> > I know a couple folks and I'll make an informal query to them. They > may > >> > or > >> > may not know the answer and may or may not reply. But I'll try. > >> > > >> > I suspect Mike is more right than not, however, which was basically > the > >> > impetus for my using them as an example in the first place. > >> > > >> > > >> > > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones > >> > > >> > wrote: > >> > > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their > proprietary > >> > tokens before JWT existed. I'm sure it was because it's ubiquitousl= y > >> > available in all Web development tools - as we determined in the > survey > >> > of > >> > algorithms supported by common Web development platforms done by the > >> > JOSE > >> > working group in mid-2012 (attached). > >> > > >> > -- Mike > >> > > >> > -----Original Message----- > >> > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > >> > Sent: Thursday, August 13, 2015 1:53 PM > >> > To: 'Brian Campbell' > >> > Cc: cose@ietf.org > >> > Subject: Re: [COSE] RSA Algorithm Decisions > >> > > >> > Brian, > >> > > >> > I wonder if you have any contacts inside of google to query them why > >> > they > >> > went with RSA v1.5. However, I think that if you do it might be > because > >> > of > >> > the implementation requirements in the JOSE algorithms draft. I ju= st > >> > looked and RS256 is labeled as recommended, but PS256 is labeled as > >> > optional. It appears that similar language is in the JWT draft. W= e > >> > may > >> > find the decision to use RSA v1.5 by google had more to do with > expected > >> > JWT > >> > libraries than with crypto library support. > >> > > >> > Jim > >> > > >> > _______________________________________________ > >> > COSE mailing list > >> > COSE@ietf.org > >> > > >> > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microso= ft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > COSE mailing list > >> > COSE@ietf.org > >> > https://www.ietf.org/mailman/listinfo/cose > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > > > > > -- > > Best regards, > Kathleen > --047d7bea2f98b72ba4051d85728d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I didn't bring up Google's use of RSA1.5 with= respect to them using or not using COSE. I don't know about their inte= rest in COSE one way or the other.

I brought it up as a proxy= , of sorts, for a sampling of real world support for asymmetric signature a= lgorithms in practice out in the 'real world'. They are signing tok= ens which will be consumed on an extremely wide variety of platforms and sy= stems. They chose RSA1.5 for that due to its "wide availability."= ; =C2=A0

On= Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty <kathleen.= moriarty.ietf@gmail.com> wrote:
Thanks for tracking that down.=C2=A0 If we were to not include it, we = would
just need to recommend an asymmetric choice and ask them to join the
discussion.=C2=A0 Google and other organizations are usually very good
about staying with current recommendation.=C2=A0 Since COSE has not been implemented, it seems like a good time to do the right thing.

Thanks,
Kathleen

On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> I got an answer back from Google on their selection of RSASSA-PKCS1-v1= _5 for
> signing of tokens, which I'll quote here:
>
> "We [Google] will always use an asymmetric alg so we can rotate k= eys.=C2=A0 Of
> the asymmetric algs, RSA 1.5 was chosen due to its wide availability f= or
> client libraries at the time.=C2=A0 If we were to support a newer alg = in the
> future, it would also be an asymmetric one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> It would be good to get an answer from folks actually using it, bu= t
>> there is no reason we can't move forward without it.=C2=A0 Goo= gle and other
>> vendors have been very good about deprecating algorithms and proto= cols
>> in their products, and even making customers aware when they are i= n
>> use (browsers with https in red with a strikethrough and Mozilla u= sing
>> a yellow caution triangle).
>>
>> Since COSE isn't deployed yet, I think it's okay and a goo= d thing to
>> be forward thinking.
>>
>> Kathleen
>>
>> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> > Dirk =E2=80=93 you=E2=80=99re on this list, correct?=C2=A0 Do= you have any comments on why
>> > Google
>> > is using RSASSA v1.5 to sign things?
>> >
>> >
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-- Mike
>> >
>> >
>> >
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]
>> > Sent: Thursday, August 13, 2015 2:29 PM
>> > To: Mike Jones
>> > Cc: Jim Schaad; cose@ietf.or= g
>> > Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> >
>> >
>> > I know a couple folks and I'll make an informal query to = them.=C2=A0 They may
>> > or
>> > may not know the answer and may or may not reply. But I'l= l try.
>> >
>> > I suspect Mike is more right than not, however, which was bas= ically the
>> > impetus for my using them as an example in the first place. >> >
>> >
>> >
>> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jo= nes@microsoft.com>
>> > wrote:
>> >
>> > Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary
>> > tokens before JWT existed.=C2=A0 I'm sure it was because = it's ubiquitously
>> > available in all Web development tools - as we determined in = the survey
>> > of
>> > algorithms supported by common Web development platforms done= by the
>> > JOSE
>> > working group in mid-2012 (attached).
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>> >
>> > -----Original Message-----
>> > From: COSE [mailto:c= ose-bounces@ietf.org] On Behalf Of Jim Schaad
>> > Sent: Thursday, August 13, 2015 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> > Brian,
>> >
>> > I wonder if you have any contacts inside of google to query t= hem why
>> > they
>> > went with RSA v1.5.=C2=A0 However, I think that if you do it = might be because
>> > of
>> > the implementation requirements in the JOSE algorithms draft.= =C2=A0 =C2=A0I just
>> > looked and RS256 is labeled as recommended, but PS256 is labe= led as
>> > optional.=C2=A0 It appears that similar language is in the JW= T draft.=C2=A0 =C2=A0We
>> > may
>> > find the decision to use RSA v1.5 by google had more to do wi= th expected
>> > JWT
>> > libraries than with crypto library support.
>> >
>> > Jim
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > COSE@ietf.org
>> >
>> > https://na01.safel= inks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2fl= istinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3f= bedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata= =3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen

--047d7bea2f98b72ba4051d85728d-- From nobody Mon Aug 17 13:14:08 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672311B2F1A for ; Mon, 17 Aug 2015 13:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD4txf9C5yEI for ; Mon, 17 Aug 2015 13:14:03 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490DF1B2FCD for ; Mon, 17 Aug 2015 13:14:03 -0700 (PDT) Received: from hebrews (173-12-187-169-oregon.hfc.comcastbusiness.net [173.12.187.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 35B0C38EE7; Mon, 17 Aug 2015 13:14:02 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" , "'Kathleen Moriarty'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2015 13:14:22 -0700 Message-ID: <093401d0d929$4fc63260$ef529720$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0935_01D0D8EE.A36D74E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmgC8OqlTwHK57wSAbj7Yf0B8rD4AQJbo6bMAPHWWWoC2bLXKgG2P2djAsWU58wCccWxFQGoeRnYAMJZuyedoIT+cA== Content-Language: en-us Archived-At: Cc: 'Mike Jones' , 'Dirk Balfanz' , cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 20:14:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0935_01D0D8EE.A36D74E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That was definitely my understanding of your position. I asked the = question about Google simply because I was trying to determine if the = issue was really the deployment question or the question of how the = specs for JOSE were written. =20 Like Brian, I don=E2=80=99t know that Google would or would not have any = interest in ever using COSE. I do know from personal experience that it = is not the easiest thing to implement in JavaScript due to the fact that = we are using integers as keys rather than strictly sticking to strings. = Even the easy mapping (make the integer a string) would not necessarily = work in the long run as COSE would support both having keys of 1 (as a = number) and =E2=80=9C1=E2=80=9D (as a string) for a map key value. = This makes any direct JavaScript support lots of fun. =20 Jim =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Monday, August 17, 2015 10:51 AM To: Kathleen Moriarty Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions =20 I didn't bring up Google's use of RSA1.5 with respect to them using or = not using COSE. I don't know about their interest in COSE one way or the = other.=20 I brought it up as a proxy, of sorts, for a sampling of real world = support for asymmetric signature algorithms in practice out in the 'real = world'. They are signing tokens which will be consumed on an extremely = wide variety of platforms and systems. They chose RSA1.5 for that due to = its "wide availability." =20 =20 On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty = > wrote: Thanks for tracking that down. If we were to not include it, we would just need to recommend an asymmetric choice and ask them to join the discussion. Google and other organizations are usually very good about staying with current recommendation. Since COSE has not been implemented, it seems like a good time to do the right thing. Thanks, Kathleen On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > wrote: > I got an answer back from Google on their selection of = RSASSA-PKCS1-v1_5 for > signing of tokens, which I'll quote here: > > "We [Google] will always use an asymmetric alg so we can rotate keys. = Of > the asymmetric algs, RSA 1.5 was chosen due to its wide availability = for > client libraries at the time. If we were to support a newer alg in = the > future, it would also be an asymmetric one." > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > wrote: >> >> It would be good to get an answer from folks actually using it, but >> there is no reason we can't move forward without it. Google and = other >> vendors have been very good about deprecating algorithms and = protocols >> in their products, and even making customers aware when they are in >> use (browsers with https in red with a strikethrough and Mozilla = using >> a yellow caution triangle). >> >> Since COSE isn't deployed yet, I think it's okay and a good thing to >> be forward thinking. >> >> Kathleen >> >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones = > >> wrote: >> > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have = any comments on why >> > Google >> > is using RSASSA v1.5 to sign things? >> > >> > >> > >> > -- Mike >> > >> > >> > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com = ] >> > Sent: Thursday, August 13, 2015 2:29 PM >> > To: Mike Jones >> > Cc: Jim Schaad; cose@ietf.org =20 >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > >> > >> > I know a couple folks and I'll make an informal query to them. = They may >> > or >> > may not know the answer and may or may not reply. But I'll try. >> > >> > I suspect Mike is more right than not, however, which was basically = the >> > impetus for my using them as an example in the first place. >> > >> > >> > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones >> > > >> > wrote: >> > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary >> > tokens before JWT existed. I'm sure it was because it's = ubiquitously >> > available in all Web development tools - as we determined in the = survey >> > of >> > algorithms supported by common Web development platforms done by = the >> > JOSE >> > working group in mid-2012 (attached). >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Jim Schaad >> > Sent: Thursday, August 13, 2015 1:53 PM >> > To: 'Brian Campbell' >> > Cc: cose@ietf.org =20 >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > Brian, >> > >> > I wonder if you have any contacts inside of google to query them = why >> > they >> > went with RSA v1.5. However, I think that if you do it might be = because >> > of >> > the implementation requirements in the JOSE algorithms draft. I = just >> > looked and RS256 is labeled as recommended, but PS256 is labeled as >> > optional. It appears that similar language is in the JWT draft. = We >> > may >> > find the decision to use RSA v1.5 by google had more to do with = expected >> > JWT >> > libraries than with crypto library support. >> > >> > Jim >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org =20 >> > >> > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose = = &data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d= 2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4Vp= AREAuAG2EN7NfR9cSJ265o8PMOLn0%3d >> > >> > >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org =20 >> > https://www.ietf.org/mailman/listinfo/cose >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > -- Best regards, Kathleen =20 ------=_NextPart_000_0935_01D0D8EE.A36D74E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

That was definitely my understanding of your position.=C2=A0 I asked = the question about Google simply because I was trying to determine if = the issue was really the deployment question or the question of how the = specs for JOSE were written.

 

Like Brian, I don=E2=80=99t know that Google would or would not have = any interest in ever using COSE.=C2=A0 I do know from personal = experience that it is not the easiest thing to implement in JavaScript = due to the fact that we are using integers as keys rather than strictly = sticking to strings.=C2=A0 Even the easy mapping (make the integer a = string) would not necessarily work in the long run as COSE would support = both having keys of 1 (as a number) and =E2=80=9C1=E2=80=9D (as a = string) for a map key value.=C2=A0=C2=A0 This makes any direct = JavaScript support lots of fun.

 

Jim

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, = August 17, 2015 10:51 AM
To: Kathleen Moriarty
Cc: = Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org
Subject: = Re: [COSE] RSA Algorithm Decisions

 

I didn't bring up Google's use of RSA1.5 = with respect to them using or not using COSE. I don't know about their = interest in COSE one way or the other.

I brought it up as a proxy, of sorts, for a sampling = of real world support for asymmetric signature algorithms in practice = out in the 'real world'. They are signing tokens which will be consumed = on an extremely wide variety of platforms and systems. They chose RSA1.5 = for that due to its "wide availability."   =

 

On Mon, = Aug 17, 2015 at 7:34 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Thanks = for tracking that down.  If we were to not include it, we = would
just need to recommend an asymmetric choice and ask them to = join the
discussion.  Google and other organizations are usually = very good
about staying with current recommendation.  Since COSE = has not been
implemented, it seems like a good time to do the right = thing.

Thanks,
Kathleen


On Mon, Aug 17, = 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.com= > wrote:
> I got an answer back from Google on their selection = of RSASSA-PKCS1-v1_5 for
> signing of tokens, which I'll quote = here:
>
> "We [Google] will always use an asymmetric = alg so we can rotate keys.  Of
> the asymmetric algs, RSA 1.5 = was chosen due to its wide availability for
> client libraries at = the time.  If we were to support a newer alg in the
> future, = it would also be an asymmetric = one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 = PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@g= mail.com> wrote:
>>
>> It would be good to get = an answer from folks actually using it, but
>> there is no = reason we can't move forward without it.  Google and = other
>> vendors have been very good about deprecating = algorithms and protocols
>> in their products, and even making = customers aware when they are in
>> use (browsers with https in = red with a strikethrough and Mozilla using
>> a yellow caution = triangle).
>>
>> Since COSE isn't deployed yet, I = think it's okay and a good thing to
>> be forward = thinking.
>>
>> Kathleen
>>
>> On = Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> > Dirk =E2=80=93 you=E2=80=99re = on this list, correct?  Do you have any comments on why
>> = > Google
>> > is using RSASSA v1.5 to sign = things?
>> >
>> >
>> >
>> = >                  =                     =                     =    -- Mike
>> >
>> >
>> = >
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com= ]
>> > Sent: Thursday, August 13, 2015 2:29 PM
>> = > To: Mike Jones
>> > Cc: Jim Schaad; cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = >
>> >
>> > I know a couple folks and I'll = make an informal query to them.  They may
>> > = or
>> > may not know the answer and may or may not reply. = But I'll try.
>> >
>> > I suspect Mike is more = right than not, however, which was basically the
>> > = impetus for my using them as an example in the first place.
>> = >
>> >
>> >
>> > On Thu, Aug 13, = 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jones@microsoft.com>
>> > wrote:
>> >
>> > Google = was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary
>> > tokens before JWT existed.  I'm sure = it was because it's ubiquitously
>> > available in all Web = development tools - as we determined in the survey
>> > = of
>> > algorithms supported by common Web development = platforms done by the
>> > JOSE
>> > working = group in mid-2012 (attached).
>> >
>> >  =                     =            -- Mike
>> = >
>> > -----Original Message-----
>> > From: = COSE [mailto:cose-bounces@ietf.org] On = Behalf Of Jim Schaad
>> > Sent: Thursday, August 13, 2015 = 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = > Brian,
>> >
>> > I wonder if you have any = contacts inside of google to query them why
>> > = they
>> > went with RSA v1.5.  However, I think that if = you do it might be because
>> > of
>> > the = implementation requirements in the JOSE algorithms draft.   I = just
>> > looked and RS256 is labeled as recommended, but = PS256 is labeled as
>> > optional.  It appears that = similar language is in the JWT draft.   We
>> > = may
>> > find the decision to use RSA v1.5 by google had = more to do with expected
>> > JWT
>> > libraries = than with crypto library support.
>> >
>> > = Jim
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> = >
>> > https://na01.safelinks.protection.outlook.com/?url=3Dht= tps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7= cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f98= 8bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7Nf= R9cSJ265o8PMOLn0%3d
>> >
>> >
>> = >
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>&= gt; >
>>
>>
>>
>> = --
>>
>> Best regards,
>> = Kathleen
>
>


--

Best = regards,
Kathleen

 

------=_NextPart_000_0935_01D0D8EE.A36D74E0-- From nobody Mon Aug 17 20:46:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C586B1B3163 for ; Mon, 17 Aug 2015 20:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZtaTdquIMzg for ; Mon, 17 Aug 2015 20:46:52 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322161B3161 for ; Mon, 17 Aug 2015 20:46:52 -0700 (PDT) Date: Mon, 17 Aug 2015 20:46:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1439869609; bh=HTV4AQU9tEkmLvpeUyFR8GITNgn0tyDQifDybYTD/kM=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=01fyQQzRNl1OvdI0AaT+V7xTaphROOFIAQ+JQl7/ufoaKwrn3ugM/qGYQolLrrS1d b3eFlQkAjzNzSh11j0cNLrF6mvySL+azsz2E1BqIXRS5Wxnkcm80v+QqrWM9bmpz5e 9aWWvQsMMFkg69jFjAOozDmHFdp938Qhx3oh3sFc= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55d2aaa930071_6e873f7ec73e92b8934cf"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Algorithms: Should we have support for password based algorithms (#6) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 03:46:53 -0000 ----==_mimepart_55d2aaa930071_6e873f7ec73e92b8934cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit JOSE has support for password based algorithms mainly for the purpose of saving private keys for later use. Given that we do not know what the introduction model for small devices is going be and given that many small devices do not have UI to enter a password, does it makes sense for use to skip having password based algorithms on the first pass of COSE. They can always be added at a later time if they are needed. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/6 ----==_mimepart_55d2aaa930071_6e873f7ec73e92b8934cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

JOSE has support for password based algorithms mainly for the purpose of saving private keys for later use. Given that we do not know what the introduction model for small devices is going be and given that many small devices do not have UI to enter a password, does it makes sense for use to skip having password based algorithms on the first pass of COSE. They can always be added at a later time if they are needed.

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

----==_mimepart_55d2aaa930071_6e873f7ec73e92b8934cf-- From nobody Mon Aug 17 21:26:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3513F1B319F for ; Mon, 17 Aug 2015 21:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1OWGutEAAED for ; Mon, 17 Aug 2015 21:26:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44441B319E for ; Mon, 17 Aug 2015 21:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qghzMr9A3kphA3p+A5Qz1PG9dZlzj2/sFucw3QLMOJs=; b=QQROdDedf0YXMLpyo3s4qO+q23dZat94jcehIPXDqTkk3S6lbati+aTeEylA6iq2ljax1IQ89y3TjNQDbKv4FB7ku9onnbWIS/xbodCkClKFQSlTpRGu5xxF6Ak5wKPW0nDA+niPrkmk/m36rNYBI5isaotw3wEzOfvZ46aDkjg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 18 Aug 2015 04:26:22 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Tue, 18 Aug 2015 04:26:22 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Single Recipient Discussions Thread-Index: AdDVPUvS5F1YA735RGCWN8QwL15TOQAB5uWQAAtwhAAA/qkm0A== Date: Tue, 18 Aug 2015 04:26:22 +0000 Message-ID: References: <018b01d0d543$895664d0$9c032e70$@augustcellars.com> <020901d0d572$aa4f82f0$feee88d0$@augustcellars.com> In-Reply-To: <020901d0d572$aa4f82f0$feee88d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.117.139] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:FCRJ8nty6OQEOyJ4U9+yhc1esetAof7V43X/5fqOEWXcABTVqcnsnB+VA+n2mimtL5y1m5NoU0YwX8m2ILEkv6FvpG3ZqZyJXI7JPIbjFdc9GoaC1ZJgEsUaP4Z6x2+1e79hPMPO1B8tk5oBZGzQbg==; 24:umIDHRnHJLLLvH8olgY82h6/25XCx1yncYmqOOpWF2i6K7pY3E2E7tMI1Fu6kQdQnyrjQL64rHOL9GKx955qCg7FAmEitdPN05luLm0XfDs=; 20:eEqAVi+QgJBt53LkQoaIACSZPpu7QJ/QAqgVldScFMNZ2iLfR3BpoEmWUA7qJxj5B4dpPs4XPzQt2QFKKWp7vg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(13464003)(189002)(199003)(86362001)(4001540100001)(10090500001)(15975445007)(2501003)(76176999)(76576001)(101416001)(46102003)(10400500002)(33656002)(66066001)(87936001)(68736005)(86612001)(54356999)(5001960100002)(97736004)(64706001)(10290500002)(8990500004)(5001830100001)(5001770100001)(81156007)(107886002)(2900100001)(77096005)(62966003)(5001860100001)(2950100001)(19580405001)(5002640100001)(102836002)(5005710100001)(40100003)(5003600100002)(189998001)(92566002)(19580395003)(50986999)(106356001)(105586002)(561944003)(122556002)(2656002)(99286002)(575784001)(74316001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2015 04:26:22.6351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [COSE] Single Recipient Discussions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 04:26:44 -0000 Would people prefer the structure that Jim described below: [ msg_type, protected, unprotected, payload, protected, unprotected, si= gnature] or the flattened structure: [ msg_type, protected, unprotected, payload, signature] The latter seems to me like it does a better job of "keeping simple things = simple". Jim, would MAC look exactly like signature, or if not, what would the diffe= rences be? Likewise, would encrypted content look like this in your propos= al? [ msg_type, protected, unprotected, ciphertext, protected, unprotected,= encrypted_key] Likewise, in the encrypted structure, if we can coalesce the two sets of pr= otected and unprotected headers, that would seem simpler. -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Wednesday, August 12, 2015 7:49 PM To: Mike Jones; cose@ietf.org Subject: RE: [COSE] Single Recipient Discussions No it would look like [ msg_type, protected, unprotected, payload, protected, unprotected, signat= ure] One would append the signature structure to the end of the body structure. Similar for encryption and mac. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, August 12, 2015 2:25 PM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Single Recipient Discussions >=20 > I think I know what your proposal in 7 would look like, but it could probably help > the discussion if you were to give us a concrete example - not using numbers > and an actual representation, but using symbolic names for the array fields. I'm > thinking something like: >=20 > [protected, > unprotected, > payload, > signature] >=20 > I realize you may be envisioning more fields than that to maintain the layering > you discuss below, which is part of why I'd like us to be able to=20 > easily see what > they are. >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Wednesday, August 12, 2015 5:12 PM > To: cose@ietf.org > Subject: [COSE] Single Recipient Discussions >=20 > Since we appear to have finished dealing with the question of array vs=20 > map at > the top level, I want to restart the discussions dealing with handing single > recipient/signer as a special case. >=20 > 1. I am assuming that we are going with arrays at the top level for=20 > all of the > sizes that I cite in this mail. As such, these number will be=20 > slightly different that > those cited by the advocates of a single recipient solution, but I do=20 > not believe > that the slightly different numbers would change their arguments in=20 > any way. >=20 > 2. I believe that it is a misnomer to call the discussion that has=20 > been primarily > advanced to be about a single recipient use case. It would be more accurate the > tag this discussion as being about making the case of using a PSK=20 > directly as the > key. The proposals do nothing to deal with any of the other key management > techniques as a single recipient, they only deal with a key management=20 > algorithm of 'direct'. >=20 > 3. The message space savings for the proposals that have been=20 > advanced will > save at most 8 bytes from the current document. 2 bytes for the two=20 > array markers, 2 bytes for the two maps, 1 byte for the absent=20 > ciphertext, 1 byte for > the zero length recipient array, 2 bytes for the algorithm identifier > tag and value. Of these 8 bytes, we can remove 3 of them relatively > easily. If the recipient array is optional, then it disappears. If=20 > we unroll the > recipients in the case of a single recipient then the 2 bytes for=20 > array markers > disappears. The published document does the first but not the latter. >=20 > 4. There is currently a very clear cut rule about things only being=20 > used at the > layer they are placed in. This means that currently key identifiers=20 > are never > placed in the same layer as a content key algorithm. This would be=20 > broken by > the proposal put forth. I worry that once this is done, there will be more items > than kid that will migrate between layers. One of the things that I=20 > never liked in > the JOSE proposals what the number of places that one needed to look=20 > for the > various control fields. Currently in COSE this is limited to two places. If we > introduce the possibility of cross layer contamination then this=20 > number might > grow in the future to deal with > implementation faults. >=20 > One of the way that these faults might develop is for designers to say=20 > - I think > that this should be authenticated, and thus will put it at the wrong=20 > layer to > ensure that it is. Either without thinking about the question -=20 > should it be > authenticated, or a different algorithm be required so that=20 > authentication is > possible. >=20 > 5. Code size is going to be very different if two different methods=20 > of dealing > with structure needs to be supported. It is currently being assumed=20 > that direct > key is going to be the major use case in a number of situations. > If this is not the case then current proposals do not help the=20 > situation any. If it is > true that more than one method of key management needs to be supported=20 > then the code size is going to grow because of the need to support an additional > way that key management is going to be done. >=20 > 6. Personally, I am planning to argue against using direct key in=20 > future work of > ACE for long term authentication keys. The fact that it is going to=20 > be hard to > rotate them means that one needs to either add a KDF step or else have=20 > a key > agreement method to keep the same key from being used for the entire lifetime > of the device (perhaps 30 years?). This is something that is related=20 > to the > previous item as we now are going to need to support multiple key management > methods in these cases. >=20 > 7. Now that we are doing arrays, it would be possible to have a=20 > generic one > recipient/signer solution by unrolling the recipient/signer structure=20 > on the end of > the message. This was originally proposed before the change from=20 > arrays to > maps was initially made. Since we are moving from maps back to arrays=20 > it is one > again a viable solution to look at. It would be totally viable to=20 > have applications > state that there is one recipient/signer and the unrolled version is always used. > This would still allow for multiple key management types to be used. Systems in > more unconstrained spaces could potentially setup to have multiple recipients - > but only if use cases exist where it would be needed. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf. > org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micro > soft.com%7c42b45138af2043af976708d2a35aa0e5%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=3D62f4AJob4HGGxfnZpU2Yt7AGjiTJcxW75rCq2jYKlUo% > 3d From nobody Mon Aug 17 21:31:47 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAA1B31A6 for ; Mon, 17 Aug 2015 21:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZlDMQ3jPyKC for ; Mon, 17 Aug 2015 21:31:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54761B31A7 for ; Mon, 17 Aug 2015 21:31:41 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 18 Aug 2015 04:31:21 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Tue, 18 Aug 2015 04:31:21 +0000 From: Mike Jones To: Jim Schaad , 'Brian Campbell' , 'Kathleen Moriarty' Thread-Topic: [COSE] RSA Algorithm Decisions Thread-Index: AdDLFYVQBaFhIPMqQIC5i6cbL8YD+QDHIWQAAAJRXQAAA0+UAAAb9quAAD62XQAA9zPkgACYN5QAAAAtiFAAAQ+RAAAAB+hAAAAzsgAAvjjZgAAAbt2AAAjzDgAABQPiAAARNAwA Date: Tue, 18 Aug 2015 04:31:20 +0000 Message-ID: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d929$4fc63260$ef529720$@augustcellars.com> In-Reply-To: <093401d0d929$4fc63260$ef529720$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.117.139] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:K5hCxTt1o8u2dIy7OAGbUtvpwhJHUfJWHuNvEFtkaDmwUXMbXXG05r6ePSwmAvCZi0pfEwwwrGJ7yqYEPX/QGcucwY/STcW9KYuQd0HA/v5s+NL4jdwr1rNQq1jtwNF0jDmglb2mazS7DdOaAARLQA==; 24:Z+c//gmHcgNF/qKXBlxuWPCaZemEAM7+5e4NIH8knP7SE2j5iQOUzeyh7rKuQURadGoYMw5WmH3ICB7kmU4G2hGBjPXrODJ8JFG3uckJVzM=; 20:d+XXNm27ROdYrx35Qbv7tT7T89BxPINxpAj3BYYBT+3qikofLNCOHLM0yIUWGiWtIf2tjwM97ZSsiXqL98VtUQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(52604005)(164054003)(51444003)(54094003)(13464003)(24454002)(66066001)(46102003)(10090500001)(74316001)(97736004)(33656002)(5001960100002)(5001860100001)(5890100001)(92566002)(81156007)(5001770100001)(19625215002)(5001830100001)(16236675004)(76576001)(4001540100001)(105586002)(106356001)(64706001)(99286002)(76176999)(99936001)(19580395003)(101416001)(54356999)(86612001)(5005710100001)(87936001)(2656002)(19617315012)(19300405004)(50986999)(19609705001)(86362001)(5003600100002)(19580405001)(2950100001)(8990500004)(122556002)(2900100001)(189998001)(68736005)(10290500002)(77156002)(102836002)(10400500002)(15975445007)(62966003)(5002640100001)(40100003)(77096005)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2015 04:31:20.8960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: 'Dirk Balfanz' , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 04:31:46 -0000 --_004_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_" --_000_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gcGVyc29uYWxseSBxdWVhc3kgd2l0aCBub3QgZGVmaW5pbmcgYW4gYWxnb3JpdGhtIGlk ZW50aWZpZXIgZm9yIFJTQVNTQSB2MS41IHVubGVzcyB3ZSBmaXJzdCB1bmRlcnRha2UgYSBzdHVk eSBlcXVpdmFsZW50IHRvIHRoZSBhdHRhY2hlZCBhbGdvcml0aG0gYXZhaWxhYmlsaXR5IHN1cnZl eSBhbmQgY29udmluY2Ugb3Vyc2VsdmVzIHRoYXQgUlNBLVBTUyBpcyBub3cgdWJpcXVpdG91c2x5 IGF2YWlsYWJsZS4gIEdpdmVuIHRoYXQgdGhlcmUgYXJlIG5vIGtub3duIGF0dGFja3Mgb24gUlNB U1NBIHYxLjUsIHRyeWluZyB0byBydWxlIG91dCB0aGUgdXNlIG9mIHRoZSBtb3N0IGNvbW1vbmx5 IHVzZWQgc2lnbmF0dXJlIGFsZ29yaXRobSB3aXRob3V0IGZpcnN0IGRvaW5nIHRoZSBzdHVkeSBz ZWVtcyBwcmVtYXR1cmUgdG8gbWUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSmltIFNjaGFhZCBb bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxNywg MjAxNSAxOjE0IFBNDQpUbzogJ0JyaWFuIENhbXBiZWxsJzsgJ0thdGhsZWVuIE1vcmlhcnR5Jw0K Q2M6IE1pa2UgSm9uZXM7ICdEaXJrIEJhbGZhbnonOyBjb3NlQGlldGYub3JnDQpTdWJqZWN0OiBS RTogW0NPU0VdIFJTQSBBbGdvcml0aG0gRGVjaXNpb25zDQoNClRoYXQgd2FzIGRlZmluaXRlbHkg bXkgdW5kZXJzdGFuZGluZyBvZiB5b3VyIHBvc2l0aW9uLiAgSSBhc2tlZCB0aGUgcXVlc3Rpb24g YWJvdXQgR29vZ2xlIHNpbXBseSBiZWNhdXNlIEkgd2FzIHRyeWluZyB0byBkZXRlcm1pbmUgaWYg dGhlIGlzc3VlIHdhcyByZWFsbHkgdGhlIGRlcGxveW1lbnQgcXVlc3Rpb24gb3IgdGhlIHF1ZXN0 aW9uIG9mIGhvdyB0aGUgc3BlY3MgZm9yIEpPU0Ugd2VyZSB3cml0dGVuLg0KDQpMaWtlIEJyaWFu LCBJIGRvbuKAmXQga25vdyB0aGF0IEdvb2dsZSB3b3VsZCBvciB3b3VsZCBub3QgaGF2ZSBhbnkg aW50ZXJlc3QgaW4gZXZlciB1c2luZyBDT1NFLiAgSSBkbyBrbm93IGZyb20gcGVyc29uYWwgZXhw ZXJpZW5jZSB0aGF0IGl0IGlzIG5vdCB0aGUgZWFzaWVzdCB0aGluZyB0byBpbXBsZW1lbnQgaW4g SmF2YVNjcmlwdCBkdWUgdG8gdGhlIGZhY3QgdGhhdCB3ZSBhcmUgdXNpbmcgaW50ZWdlcnMgYXMg a2V5cyByYXRoZXIgdGhhbiBzdHJpY3RseSBzdGlja2luZyB0byBzdHJpbmdzLiAgRXZlbiB0aGUg ZWFzeSBtYXBwaW5nIChtYWtlIHRoZSBpbnRlZ2VyIGEgc3RyaW5nKSB3b3VsZCBub3QgbmVjZXNz YXJpbHkgd29yayBpbiB0aGUgbG9uZyBydW4gYXMgQ09TRSB3b3VsZCBzdXBwb3J0IGJvdGggaGF2 aW5nIGtleXMgb2YgMSAoYXMgYSBudW1iZXIpIGFuZCDigJwx4oCdIChhcyBhIHN0cmluZykgZm9y IGEgbWFwIGtleSB2YWx1ZS4gICBUaGlzIG1ha2VzIGFueSBkaXJlY3QgSmF2YVNjcmlwdCBzdXBw b3J0IGxvdHMgb2YgZnVuLg0KDQpKaW0NCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE3LCAyMDE1 IDEwOjUxIEFNDQpUbzogS2F0aGxlZW4gTW9yaWFydHkNCkNjOiBNaWtlIEpvbmVzOyBEaXJrIEJh bGZhbno7IEppbSBTY2hhYWQ7IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW0NPU0VdIFJTQSBBbGdvcml0aG0gRGVjaXNpb25zDQoNCkkgZGlkbid0IGJy aW5nIHVwIEdvb2dsZSdzIHVzZSBvZiBSU0ExLjUgd2l0aCByZXNwZWN0IHRvIHRoZW0gdXNpbmcg b3Igbm90IHVzaW5nIENPU0UuIEkgZG9uJ3Qga25vdyBhYm91dCB0aGVpciBpbnRlcmVzdCBpbiBD T1NFIG9uZSB3YXkgb3IgdGhlIG90aGVyLg0KSSBicm91Z2h0IGl0IHVwIGFzIGEgcHJveHksIG9m IHNvcnRzLCBmb3IgYSBzYW1wbGluZyBvZiByZWFsIHdvcmxkIHN1cHBvcnQgZm9yIGFzeW1tZXRy aWMgc2lnbmF0dXJlIGFsZ29yaXRobXMgaW4gcHJhY3RpY2Ugb3V0IGluIHRoZSAncmVhbCB3b3Js ZCcuIFRoZXkgYXJlIHNpZ25pbmcgdG9rZW5zIHdoaWNoIHdpbGwgYmUgY29uc3VtZWQgb24gYW4g ZXh0cmVtZWx5IHdpZGUgdmFyaWV0eSBvZiBwbGF0Zm9ybXMgYW5kIHN5c3RlbXMuIFRoZXkgY2hv c2UgUlNBMS41IGZvciB0aGF0IGR1ZSB0byBpdHMgIndpZGUgYXZhaWxhYmlsaXR5LiINCg0KT24g TW9uLCBBdWcgMTcsIDIwMTUgYXQgNzozNCBBTSwgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0cmFja2luZyB0aGF0IGRvd24uICBJZiB3ZSB3 ZXJlIHRvIG5vdCBpbmNsdWRlIGl0LCB3ZSB3b3VsZA0KanVzdCBuZWVkIHRvIHJlY29tbWVuZCBh biBhc3ltbWV0cmljIGNob2ljZSBhbmQgYXNrIHRoZW0gdG8gam9pbiB0aGUNCmRpc2N1c3Npb24u ICBHb29nbGUgYW5kIG90aGVyIG9yZ2FuaXphdGlvbnMgYXJlIHVzdWFsbHkgdmVyeSBnb29kDQph Ym91dCBzdGF5aW5nIHdpdGggY3VycmVudCByZWNvbW1lbmRhdGlvbi4gIFNpbmNlIENPU0UgaGFz IG5vdCBiZWVuDQppbXBsZW1lbnRlZCwgaXQgc2VlbXMgbGlrZSBhIGdvb2QgdGltZSB0byBkbyB0 aGUgcmlnaHQgdGhpbmcuDQoNClRoYW5rcywNCkthdGhsZWVuDQoNCk9uIE1vbiwgQXVnIDE3LCAy MDE1IGF0IDk6MjIgQU0sIEJyaWFuIENhbXBiZWxsDQo8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQo+IEkgZ290IGFu IGFuc3dlciBiYWNrIGZyb20gR29vZ2xlIG9uIHRoZWlyIHNlbGVjdGlvbiBvZiBSU0FTU0EtUEtD UzEtdjFfNSBmb3INCj4gc2lnbmluZyBvZiB0b2tlbnMsIHdoaWNoIEknbGwgcXVvdGUgaGVyZToN Cj4NCj4gIldlIFtHb29nbGVdIHdpbGwgYWx3YXlzIHVzZSBhbiBhc3ltbWV0cmljIGFsZyBzbyB3 ZSBjYW4gcm90YXRlIGtleXMuICBPZg0KPiB0aGUgYXN5bW1ldHJpYyBhbGdzLCBSU0EgMS41IHdh cyBjaG9zZW4gZHVlIHRvIGl0cyB3aWRlIGF2YWlsYWJpbGl0eSBmb3INCj4gY2xpZW50IGxpYnJh cmllcyBhdCB0aGUgdGltZS4gIElmIHdlIHdlcmUgdG8gc3VwcG9ydCBhIG5ld2VyIGFsZyBpbiB0 aGUNCj4gZnV0dXJlLCBpdCB3b3VsZCBhbHNvIGJlIGFuIGFzeW1tZXRyaWMgb25lLiINCj4NCj4N Cj4NCj4gT24gVGh1LCBBdWcgMTMsIDIwMTUgYXQgMTI6MzUgUE0sIEthdGhsZWVuIE1vcmlhcnR5 DQo+IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCj4+DQo+PiBJdCB3b3VsZCBiZSBnb29kIHRv IGdldCBhbiBhbnN3ZXIgZnJvbSBmb2xrcyBhY3R1YWxseSB1c2luZyBpdCwgYnV0DQo+PiB0aGVy ZSBpcyBubyByZWFzb24gd2UgY2FuJ3QgbW92ZSBmb3J3YXJkIHdpdGhvdXQgaXQuICBHb29nbGUg YW5kIG90aGVyDQo+PiB2ZW5kb3JzIGhhdmUgYmVlbiB2ZXJ5IGdvb2QgYWJvdXQgZGVwcmVjYXRp bmcgYWxnb3JpdGhtcyBhbmQgcHJvdG9jb2xzDQo+PiBpbiB0aGVpciBwcm9kdWN0cywgYW5kIGV2 ZW4gbWFraW5nIGN1c3RvbWVycyBhd2FyZSB3aGVuIHRoZXkgYXJlIGluDQo+PiB1c2UgKGJyb3dz ZXJzIHdpdGggaHR0cHMgaW4gcmVkIHdpdGggYSBzdHJpa2V0aHJvdWdoIGFuZCBNb3ppbGxhIHVz aW5nDQo+PiBhIHllbGxvdyBjYXV0aW9uIHRyaWFuZ2xlKS4NCj4+DQo+PiBTaW5jZSBDT1NFIGlz bid0IGRlcGxveWVkIHlldCwgSSB0aGluayBpdCdzIG9rYXkgYW5kIGEgZ29vZCB0aGluZyB0bw0K Pj4gYmUgZm9yd2FyZCB0aGlua2luZy4NCj4+DQo+PiBLYXRobGVlbg0KPj4NCj4+IE9uIFRodSwg QXVnIDEzLCAyMDE1IGF0IDI6MzAgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCj4+IHdyb3RlOg0K Pj4gPiBEaXJrIOKAkyB5b3XigJlyZSBvbiB0aGlzIGxpc3QsIGNvcnJlY3Q/ICBEbyB5b3UgaGF2 ZSBhbnkgY29tbWVudHMgb24gd2h5DQo+PiA+IEdvb2dsZQ0KPj4gPiBpcyB1c2luZyBSU0FTU0Eg djEuNSB0byBzaWduIHRoaW5ncz8NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K Pj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT5d DQo+PiA+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTMsIDIwMTUgMjoyOSBQTQ0KPj4gPiBUbzog TWlrZSBKb25lcw0KPj4gPiBDYzogSmltIFNjaGFhZDsgY29zZUBpZXRmLm9yZzxtYWlsdG86Y29z ZUBpZXRmLm9yZz4NCj4+ID4gU3ViamVjdDogUmU6IFtDT1NFXSBSU0EgQWxnb3JpdGhtIERlY2lz aW9ucw0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBJIGtub3cgYSBjb3VwbGUgZm9sa3MgYW5kIEkn bGwgbWFrZSBhbiBpbmZvcm1hbCBxdWVyeSB0byB0aGVtLiAgVGhleSBtYXkNCj4+ID4gb3INCj4+ ID4gbWF5IG5vdCBrbm93IHRoZSBhbnN3ZXIgYW5kIG1heSBvciBtYXkgbm90IHJlcGx5LiBCdXQg SSdsbCB0cnkuDQo+PiA+DQo+PiA+IEkgc3VzcGVjdCBNaWtlIGlzIG1vcmUgcmlnaHQgdGhhbiBu b3QsIGhvd2V2ZXIsIHdoaWNoIHdhcyBiYXNpY2FsbHkgdGhlDQo+PiA+IGltcGV0dXMgZm9yIG15 IHVzaW5nIHRoZW0gYXMgYW4gZXhhbXBsZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+PiA+DQo+PiA+ DQo+PiA+DQo+PiA+IE9uIFRodSwgQXVnIDEzLCAyMDE1IGF0IDEyOjAyIFBNLCBNaWtlIEpvbmVz DQo+PiA+IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+DQo+PiA+IHdyb3RlOg0KPj4gPg0KPj4gPiBHb29nbGUgd2FzIHVzaW5n IFJTQSB2MS41ICh3aXRoIDEwMjQgYml0IGtleXMpIHRvIHNpZ24gdGhlaXIgcHJvcHJpZXRhcnkN Cj4+ID4gdG9rZW5zIGJlZm9yZSBKV1QgZXhpc3RlZC4gIEknbSBzdXJlIGl0IHdhcyBiZWNhdXNl IGl0J3MgdWJpcXVpdG91c2x5DQo+PiA+IGF2YWlsYWJsZSBpbiBhbGwgV2ViIGRldmVsb3BtZW50 IHRvb2xzIC0gYXMgd2UgZGV0ZXJtaW5lZCBpbiB0aGUgc3VydmV5DQo+PiA+IG9mDQo+PiA+IGFs Z29yaXRobXMgc3VwcG9ydGVkIGJ5IGNvbW1vbiBXZWIgZGV2ZWxvcG1lbnQgcGxhdGZvcm1zIGRv bmUgYnkgdGhlDQo+PiA+IEpPU0UNCj4+ID4gd29ya2luZyBncm91cCBpbiBtaWQtMjAxMiAoYXR0 YWNoZWQpLg0KPj4gPg0KPj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCj4+ID4NCj4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4gRnJvbTogQ09T RSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y29zZS1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQNCj4+ID4gU2VudDogVGh1cnNkYXksIEF1Z3Vz dCAxMywgMjAxNSAxOjUzIFBNDQo+PiA+IFRvOiAnQnJpYW4gQ2FtcGJlbGwnDQo+PiA+IENjOiBj b3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KPj4gPiBTdWJqZWN0OiBSZTogW0NP U0VdIFJTQSBBbGdvcml0aG0gRGVjaXNpb25zDQo+PiA+DQo+PiA+IEJyaWFuLA0KPj4gPg0KPj4g PiBJIHdvbmRlciBpZiB5b3UgaGF2ZSBhbnkgY29udGFjdHMgaW5zaWRlIG9mIGdvb2dsZSB0byBx dWVyeSB0aGVtIHdoeQ0KPj4gPiB0aGV5DQo+PiA+IHdlbnQgd2l0aCBSU0EgdjEuNS4gIEhvd2V2 ZXIsIEkgdGhpbmsgdGhhdCBpZiB5b3UgZG8gaXQgbWlnaHQgYmUgYmVjYXVzZQ0KPj4gPiBvZg0K Pj4gPiB0aGUgaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnRzIGluIHRoZSBKT1NFIGFsZ29yaXRo bXMgZHJhZnQuICAgSSBqdXN0DQo+PiA+IGxvb2tlZCBhbmQgUlMyNTYgaXMgbGFiZWxlZCBhcyBy ZWNvbW1lbmRlZCwgYnV0IFBTMjU2IGlzIGxhYmVsZWQgYXMNCj4+ID4gb3B0aW9uYWwuICBJdCBh cHBlYXJzIHRoYXQgc2ltaWxhciBsYW5ndWFnZSBpcyBpbiB0aGUgSldUIGRyYWZ0LiAgIFdlDQo+ PiA+IG1heQ0KPj4gPiBmaW5kIHRoZSBkZWNpc2lvbiB0byB1c2UgUlNBIHYxLjUgYnkgZ29vZ2xl IGhhZCBtb3JlIHRvIGRvIHdpdGggZXhwZWN0ZWQNCj4+ID4gSldUDQo+PiA+IGxpYnJhcmllcyB0 aGFuIHdpdGggY3J5cHRvIGxpYnJhcnkgc3VwcG9ydC4NCj4+ID4NCj4+ID4gSmltDQo+PiA+DQo+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ IENPU0UgbWFpbGluZyBsaXN0DQo+PiA+IENPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5v cmc+DQo+PiA+DQo+PiA+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZv JTJmY29zZSZkYXRhPTAxJTdjMDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzA5 MzhiM2ZiZWRhZTQwZWM4MGQ2MDhkMmE0MDgwODQ0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN2MxJnNkYXRhPVRQN0IlMmYxYXdON0U0VnBBUkVBdUFHMkVON05mUjljU0oyNjVv OFBNT0xuMCUzZA0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBDT1NFIG1haWxpbmcgbGlzdA0K Pj4gPiBDT1NFQGlldGYub3JnPG1haWx0bzpDT1NFQGlldGYub3JnPg0KPj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZt YWlsbWFuJTJmbGlzdGluZm8lMmZjb3NlJmRhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBt aWNyb3NvZnQuY29tJTdjNDc0OWIzNTI4Y2ZlNDg1YzA5NGYwOGQyYTc0MDY2MjAlN2M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9JTJmU3J2ZFZUT1NWbnNkTThXajg0 akx2UFNTRjBzWHhwN2lhaTZPUFJIRFQ0JTNkPg0KPj4gPg0KPj4NCj4+DQo+Pg0KPj4gLS0NCj4+ DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBLYXRobGVlbg0KPg0KPg0KDQotLQ0KDQpCZXN0IHJlZ2Fy ZHMsDQpLYXRobGVlbg0KDQo= --_000_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5J4oCZbSBwZXJzb25hbGx5IHF1ZWFzeSB3aXRoIG5vdCBkZWZpbmluZyBhbiBhbGdv cml0aG0gaWRlbnRpZmllciBmb3IgUlNBU1NBIHYxLjUgdW5sZXNzIHdlIGZpcnN0IHVuZGVydGFr ZSBhIHN0dWR5IGVxdWl2YWxlbnQgdG8gdGhlIGF0dGFjaGVkIGFsZ29yaXRobSBhdmFpbGFiaWxp dHkNCiBzdXJ2ZXkgYW5kIGNvbnZpbmNlIG91cnNlbHZlcyB0aGF0IFJTQS1QU1MgaXMgbm93IHVi aXF1aXRvdXNseSBhdmFpbGFibGUuJm5ic3A7IEdpdmVuIHRoYXQgdGhlcmUgYXJlIG5vIGtub3du IGF0dGFja3Mgb24gUlNBU1NBIHYxLjUsIHRyeWluZyB0byBydWxlIG91dCB0aGUgdXNlIG9mIHRo ZSBtb3N0IGNvbW1vbmx5IHVzZWQgc2lnbmF0dXJlIGFsZ29yaXRobSB3aXRob3V0IGZpcnN0IGRv aW5nIHRoZSBzdHVkeSBzZWVtcyBwcmVtYXR1cmUgdG8gbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1 Z3VzdGNlbGxhcnMuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDE3LCAy MDE1IDE6MTQgUE08YnI+DQo8Yj5Ubzo8L2I+ICdCcmlhbiBDYW1wYmVsbCc7ICdLYXRobGVlbiBN b3JpYXJ0eSc8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXM7ICdEaXJrIEJhbGZhbnonOyBjb3Nl QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQ09TRV0gUlNBIEFsZ29yaXRobSBE ZWNpc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCB3YXMgZGVmaW5p dGVseSBteSB1bmRlcnN0YW5kaW5nIG9mIHlvdXIgcG9zaXRpb24uJm5ic3A7IEkgYXNrZWQgdGhl IHF1ZXN0aW9uIGFib3V0IEdvb2dsZSBzaW1wbHkgYmVjYXVzZSBJIHdhcyB0cnlpbmcgdG8gZGV0 ZXJtaW5lIGlmIHRoZSBpc3N1ZSB3YXMgcmVhbGx5IHRoZQ0KIGRlcGxveW1lbnQgcXVlc3Rpb24g b3IgdGhlIHF1ZXN0aW9uIG9mIGhvdyB0aGUgc3BlY3MgZm9yIEpPU0Ugd2VyZSB3cml0dGVuLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TGlrZSBCcmlhbiwgSSBkb27igJl0IGtub3cgdGhhdCBHb29nbGUgd291bGQgb3Ig d291bGQgbm90IGhhdmUgYW55IGludGVyZXN0IGluIGV2ZXIgdXNpbmcgQ09TRS4mbmJzcDsgSSBk byBrbm93IGZyb20gcGVyc29uYWwgZXhwZXJpZW5jZSB0aGF0IGl0IGlzIG5vdCB0aGUgZWFzaWVz dA0KIHRoaW5nIHRvIGltcGxlbWVudCBpbiBKYXZhU2NyaXB0IGR1ZSB0byB0aGUgZmFjdCB0aGF0 IHdlIGFyZSB1c2luZyBpbnRlZ2VycyBhcyBrZXlzIHJhdGhlciB0aGFuIHN0cmljdGx5IHN0aWNr aW5nIHRvIHN0cmluZ3MuJm5ic3A7IEV2ZW4gdGhlIGVhc3kgbWFwcGluZyAobWFrZSB0aGUgaW50 ZWdlciBhIHN0cmluZykgd291bGQgbm90IG5lY2Vzc2FyaWx5IHdvcmsgaW4gdGhlIGxvbmcgcnVu IGFzIENPU0Ugd291bGQgc3VwcG9ydCBib3RoIGhhdmluZyBrZXlzDQogb2YgMSAoYXMgYSBudW1i ZXIpIGFuZCDigJwx4oCdIChhcyBhIHN0cmluZykgZm9yIGEgbWFwIGtleSB2YWx1ZS4mbmJzcDsm bmJzcDsgVGhpcyBtYWtlcyBhbnkgZGlyZWN0IEphdmFTY3JpcHQgc3VwcG9ydCBsb3RzIG9mIGZ1 bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkppbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEJyaWFuIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20iPm1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMTcsIDIwMTUgMTA6NTEgQU08YnI+DQo8Yj5Ubzo8 L2I+IEthdGhsZWVuIE1vcmlhcnR5PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzOyBEaXJrIEJh bGZhbno7IEppbSBTY2hhYWQ7IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NPU0VdIFJTQSBBbGdvcml0aG0g RGVjaXNpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZGlkbid0IGJyaW5n IHVwIEdvb2dsZSdzIHVzZSBvZiBSU0ExLjUgd2l0aCByZXNwZWN0IHRvIHRoZW0gdXNpbmcgb3Ig bm90IHVzaW5nIENPU0UuIEkgZG9uJ3Qga25vdyBhYm91dCB0aGVpciBpbnRlcmVzdCBpbiBDT1NF IG9uZSB3YXkgb3IgdGhlIG90aGVyLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYnJvdWdodCBpdCB1cCBhcyBhIHByb3h5LCBvZiBzb3J0cywgZm9yIGEg c2FtcGxpbmcgb2YgcmVhbCB3b3JsZCBzdXBwb3J0IGZvciBhc3ltbWV0cmljIHNpZ25hdHVyZSBh bGdvcml0aG1zIGluIHByYWN0aWNlIG91dCBpbiB0aGUgJ3JlYWwgd29ybGQnLiBUaGV5IGFyZSBz aWduaW5nIHRva2VucyB3aGljaCB3aWxsIGJlIGNvbnN1bWVkIG9uIGFuIGV4dHJlbWVseSB3aWRl IHZhcmlldHkgb2YgcGxhdGZvcm1zDQogYW5kIHN5c3RlbXMuIFRoZXkgY2hvc2UgUlNBMS41IGZv ciB0aGF0IGR1ZSB0byBpdHMgJnF1b3Q7d2lkZSBhdmFpbGFiaWxpdHkuJnF1b3Q7ICZuYnNwOyA8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVn IDE3LCAyMDE1IGF0IDc6MzQgQU0sIEthdGhsZWVuIE1vcmlhcnR5ICZsdDs8YSBocmVmPSJtYWls dG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXRo bGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRyYWNraW5nIHRoYXQgZG93bi4mbmJzcDsgSWYg d2Ugd2VyZSB0byBub3QgaW5jbHVkZSBpdCwgd2Ugd291bGQ8YnI+DQpqdXN0IG5lZWQgdG8gcmVj b21tZW5kIGFuIGFzeW1tZXRyaWMgY2hvaWNlIGFuZCBhc2sgdGhlbSB0byBqb2luIHRoZTxicj4N CmRpc2N1c3Npb24uJm5ic3A7IEdvb2dsZSBhbmQgb3RoZXIgb3JnYW5pemF0aW9ucyBhcmUgdXN1 YWxseSB2ZXJ5IGdvb2Q8YnI+DQphYm91dCBzdGF5aW5nIHdpdGggY3VycmVudCByZWNvbW1lbmRh dGlvbi4mbmJzcDsgU2luY2UgQ09TRSBoYXMgbm90IGJlZW48YnI+DQppbXBsZW1lbnRlZCwgaXQg c2VlbXMgbGlrZSBhIGdvb2QgdGltZSB0byBkbyB0aGUgcmlnaHQgdGhpbmcuPGJyPg0KPGJyPg0K VGhhbmtzLDxicj4NCkthdGhsZWVuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTW9u LCBBdWcgMTcsIDIwMTUgYXQgOToyMiBBTSwgQnJpYW4gQ2FtcGJlbGw8YnI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSSBnb3QgYW4gYW5zd2VyIGJhY2sgZnJv bSBHb29nbGUgb24gdGhlaXIgc2VsZWN0aW9uIG9mIFJTQVNTQS1QS0NTMS12MV81IGZvcjxicj4N CiZndDsgc2lnbmluZyBvZiB0b2tlbnMsIHdoaWNoIEknbGwgcXVvdGUgaGVyZTo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmcXVvdDtXZSBbR29vZ2xlXSB3aWxsIGFsd2F5cyB1c2UgYW4gYXN5bW1ldHJp YyBhbGcgc28gd2UgY2FuIHJvdGF0ZSBrZXlzLiZuYnNwOyBPZjxicj4NCiZndDsgdGhlIGFzeW1t ZXRyaWMgYWxncywgUlNBIDEuNSB3YXMgY2hvc2VuIGR1ZSB0byBpdHMgd2lkZSBhdmFpbGFiaWxp dHkgZm9yPGJyPg0KJmd0OyBjbGllbnQgbGlicmFyaWVzIGF0IHRoZSB0aW1lLiZuYnNwOyBJZiB3 ZSB3ZXJlIHRvIHN1cHBvcnQgYSBuZXdlciBhbGcgaW4gdGhlPGJyPg0KJmd0OyBmdXR1cmUsIGl0 IHdvdWxkIGFsc28gYmUgYW4gYXN5bW1ldHJpYyBvbmUuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUaHUsIEF1ZyAxMywgMjAxNSBhdCAxMjozNSBQTSwg S2F0aGxlZW4gTW9yaWFydHk8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2F0aGxlZW4u bW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJdCB3b3VsZCBiZSBn b29kIHRvIGdldCBhbiBhbnN3ZXIgZnJvbSBmb2xrcyBhY3R1YWxseSB1c2luZyBpdCwgYnV0PGJy Pg0KJmd0OyZndDsgdGhlcmUgaXMgbm8gcmVhc29uIHdlIGNhbid0IG1vdmUgZm9yd2FyZCB3aXRo b3V0IGl0LiZuYnNwOyBHb29nbGUgYW5kIG90aGVyPGJyPg0KJmd0OyZndDsgdmVuZG9ycyBoYXZl IGJlZW4gdmVyeSBnb29kIGFib3V0IGRlcHJlY2F0aW5nIGFsZ29yaXRobXMgYW5kIHByb3RvY29s czxicj4NCiZndDsmZ3Q7IGluIHRoZWlyIHByb2R1Y3RzLCBhbmQgZXZlbiBtYWtpbmcgY3VzdG9t ZXJzIGF3YXJlIHdoZW4gdGhleSBhcmUgaW48YnI+DQomZ3Q7Jmd0OyB1c2UgKGJyb3dzZXJzIHdp dGggaHR0cHMgaW4gcmVkIHdpdGggYSBzdHJpa2V0aHJvdWdoIGFuZCBNb3ppbGxhIHVzaW5nPGJy Pg0KJmd0OyZndDsgYSB5ZWxsb3cgY2F1dGlvbiB0cmlhbmdsZSkuPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBTaW5jZSBDT1NFIGlzbid0IGRlcGxveWVkIHlldCwgSSB0aGluayBpdCdzIG9r YXkgYW5kIGEgZ29vZCB0aGluZyB0bzxicj4NCiZndDsmZ3Q7IGJlIGZvcndhcmQgdGhpbmtpbmcu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBLYXRobGVlbjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgT24gVGh1LCBBdWcgMTMsIDIwMTUgYXQgMjozMCBQTSwgTWlrZSBKb25lcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IERpcmsg4oCTIHlvdeKAmXJlIG9uIHRoaXMgbGlzdCwgY29ycmVjdD8mbmJzcDsgRG8g eW91IGhhdmUgYW55IGNvbW1lbnRzIG9uIHdoeTxicj4NCiZndDsmZ3Q7ICZndDsgR29vZ2xlPGJy Pg0KJmd0OyZndDsgJmd0OyBpcyB1c2luZyBSU0FTU0EgdjEuNSB0byBzaWduIHRoaW5ncz88YnI+ DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7LS0gTWlrZTxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgRnJvbTogQnJpYW4gQ2FtcGJlbGwgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMTMsIDIwMTUgMjoyOSBQTTxicj4NCiZndDsmZ3Q7ICZndDsgVG86IE1pa2UgSm9uZXM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IENjOiBKaW0gU2NoYWFkOyA8YSBocmVmPSJtYWlsdG86Y29zZUBp ZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJl OiBbQ09TRV0gUlNBIEFsZ29yaXRobSBEZWNpc2lvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEkga25v dyBhIGNvdXBsZSBmb2xrcyBhbmQgSSdsbCBtYWtlIGFuIGluZm9ybWFsIHF1ZXJ5IHRvIHRoZW0u Jm5ic3A7IFRoZXkgbWF5PGJyPg0KJmd0OyZndDsgJmd0OyBvcjxicj4NCiZndDsmZ3Q7ICZndDsg bWF5IG5vdCBrbm93IHRoZSBhbnN3ZXIgYW5kIG1heSBvciBtYXkgbm90IHJlcGx5LiBCdXQgSSds bCB0cnkuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgSSBzdXNwZWN0IE1p a2UgaXMgbW9yZSByaWdodCB0aGFuIG5vdCwgaG93ZXZlciwgd2hpY2ggd2FzIGJhc2ljYWxseSB0 aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGltcGV0dXMgZm9yIG15IHVzaW5nIHRoZW0gYXMgYW4gZXhh bXBsZSBpbiB0aGUgZmlyc3QgcGxhY2UuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBPbiBUaHUsIEF1ZyAx MywgMjAxNSBhdCAxMjowMiBQTSwgTWlrZSBKb25lczxicj4NCiZndDsmZ3Q7ICZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBHb29nbGUgd2FzIHVzaW5nIFJTQSB2MS41ICh3 aXRoIDEwMjQgYml0IGtleXMpIHRvIHNpZ24gdGhlaXIgcHJvcHJpZXRhcnk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IHRva2VucyBiZWZvcmUgSldUIGV4aXN0ZWQuJm5ic3A7IEknbSBzdXJlIGl0IHdhcyBi ZWNhdXNlIGl0J3MgdWJpcXVpdG91c2x5PGJyPg0KJmd0OyZndDsgJmd0OyBhdmFpbGFibGUgaW4g YWxsIFdlYiBkZXZlbG9wbWVudCB0b29scyAtIGFzIHdlIGRldGVybWluZWQgaW4gdGhlIHN1cnZl eTxicj4NCiZndDsmZ3Q7ICZndDsgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFsZ29yaXRobXMgc3Vw cG9ydGVkIGJ5IGNvbW1vbiBXZWIgZGV2ZWxvcG1lbnQgcGxhdGZvcm1zIGRvbmUgYnkgdGhlPGJy Pg0KJmd0OyZndDsgJmd0OyBKT1NFPGJyPg0KJmd0OyZndDsgJmd0OyB3b3JraW5nIGdyb3VwIGlu IG1pZC0yMDEyIChhdHRhY2hlZCkuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7LS0gTWlrZTxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgJmd0OyBGcm9tOiBDT1NFIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZyI+Y29zZS1ib3VuY2VzQGll dGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBBdWd1c3QgMTMsIDIwMTUgMTo1MyBQTTxicj4NCiZndDsmZ3Q7ICZndDsg VG86ICdCcmlhbiBDYW1wYmVsbCc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IENjOiA8YSBocmVmPSJtYWls dG86Y29zZUBpZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFN1 YmplY3Q6IFJlOiBbQ09TRV0gUlNBIEFsZ29yaXRobSBEZWNpc2lvbnM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBCcmlhbiw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyBJIHdvbmRlciBpZiB5b3UgaGF2ZSBhbnkgY29udGFjdHMgaW5zaWRlIG9mIGdv b2dsZSB0byBxdWVyeSB0aGVtIHdoeTxicj4NCiZndDsmZ3Q7ICZndDsgdGhleTxicj4NCiZndDsm Z3Q7ICZndDsgd2VudCB3aXRoIFJTQSB2MS41LiZuYnNwOyBIb3dldmVyLCBJIHRoaW5rIHRoYXQg aWYgeW91IGRvIGl0IG1pZ2h0IGJlIGJlY2F1c2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IG9mPGJyPg0K Jmd0OyZndDsgJmd0OyB0aGUgaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnRzIGluIHRoZSBKT1NF IGFsZ29yaXRobXMgZHJhZnQuJm5ic3A7ICZuYnNwO0kganVzdDxicj4NCiZndDsmZ3Q7ICZndDsg bG9va2VkIGFuZCBSUzI1NiBpcyBsYWJlbGVkIGFzIHJlY29tbWVuZGVkLCBidXQgUFMyNTYgaXMg bGFiZWxlZCBhczxicj4NCiZndDsmZ3Q7ICZndDsgb3B0aW9uYWwuJm5ic3A7IEl0IGFwcGVhcnMg dGhhdCBzaW1pbGFyIGxhbmd1YWdlIGlzIGluIHRoZSBKV1QgZHJhZnQuJm5ic3A7ICZuYnNwO1dl PGJyPg0KJmd0OyZndDsgJmd0OyBtYXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGZpbmQgdGhlIGRlY2lz aW9uIHRvIHVzZSBSU0EgdjEuNSBieSBnb29nbGUgaGFkIG1vcmUgdG8gZG8gd2l0aCBleHBlY3Rl ZDxicj4NCiZndDsmZ3Q7ICZndDsgSldUPGJyPg0KJmd0OyZndDsgJmd0OyBsaWJyYXJpZXMgdGhh biB3aXRoIGNyeXB0byBsaWJyYXJ5IHN1cHBvcnQuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsgSmltPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IENPU0UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyA8YSBocmVmPSJtYWls dG86Q09TRUBpZXRmLm9yZyI+Q09TRUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4l MmZsaXN0aW5mbyUyZmNvc2UmYW1wO2RhdGE9MDElN2MwMSU3Y01pY2hhZWwuSm9uZXMlNDBtaWNy b3NvZnQuY29tJTdjMDkzOGIzZmJlZGFlNDBlYzgwZDYwOGQyYTQwODA4NDQlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVRQN0IlMmYxYXdON0U0VnBBUkVB dUFHMkVON05mUjljU0oyNjVvOFBNT0xuMCUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3 d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZjb3NlJmFtcDtkYXRhPTAxJTdjMDEl N2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3YzA5MzhiM2ZiZWRhZTQwZWM4MGQ2MDhk MmE0MDgwODQ0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0 YT1UUDdCJTJmMWF3TjdFNFZwQVJFQXVBRzJFTjdOZlI5Y1NKMjY1bzhQTU9MbjAlM2Q8L2E+PGJy Pg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7IENPU0UgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyI+ Q09TRUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3 LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmY29zZSZhbXA7ZGF0YT0wMSU3YzAxJTdj TWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN2M0NzQ5YjM1MjhjZmU0ODVjMDk0ZjA4ZDJh NzQwNjYyMCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9 JTJmU3J2ZFZUT1NWbnNkTThXajg0akx2UFNTRjBzWHhwN2lhaTZPUFJIRFQ0JTNkIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+ PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJl Z2FyZHMsPGJyPg0KJmd0OyZndDsgS2F0aGxlZW48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLTwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNs YXNzPSJob2VuemIiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+S2F0aGxlZW48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_-- --_004_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=18750; creation-date="Tue, 18 Aug 2015 04:29:16 GMT"; modification-date="Tue, 18 Aug 2015 04:29:16 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_004_BY2PR03MB442C1CE21A8B6791BF3AA4FF5780BY2PR03MB442namprd_-- From nobody Mon Aug 17 22:04:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA271B31BA for ; Mon, 17 Aug 2015 22:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCv8hOipeGKw for ; Mon, 17 Aug 2015 22:04:44 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1790B1A0370 for ; Mon, 17 Aug 2015 22:04:44 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 317EB2C9BE; Mon, 17 Aug 2015 22:04:43 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d92 9$4fc63260$ef529720$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2015 22:05:05 -0700 Message-ID: <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09C2_01D0D938.C63AC280" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmgC8OqlTwHK57wSAbj7Yf0B8rD4AQJbo6bMAPHWWWoC2bLXKgG2P2djAsWU58wCccWxFQGoeRnYAnj24AoB3rXeBwLXmB6OnW2y6UA= Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 05:04:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09C2_01D0D938.C63AC280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So what are the use cases you think we need to support this in? That = would be the first thing that one would need to look at before one can = make any guesses as to what environments we need to do the inventory = for. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, August 17, 2015 9:31 PM To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty' Cc: 'Dirk Balfanz'; cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions =20 I=E2=80=99m personally queasy with not defining an algorithm identifier = for RSASSA v1.5 unless we first undertake a study equivalent to the = attached algorithm availability survey and convince ourselves that = RSA-PSS is now ubiquitously available. Given that there are no known = attacks on RSASSA v1.5, trying to rule out the use of the most commonly = used signature algorithm without first doing the study seems premature = to me. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Monday, August 17, 2015 1:14 PM To: 'Brian Campbell'; 'Kathleen Moriarty' Cc: Mike Jones; 'Dirk Balfanz'; cose@ietf.org =20 Subject: RE: [COSE] RSA Algorithm Decisions =20 That was definitely my understanding of your position. I asked the = question about Google simply because I was trying to determine if the = issue was really the deployment question or the question of how the = specs for JOSE were written. =20 Like Brian, I don=E2=80=99t know that Google would or would not have any = interest in ever using COSE. I do know from personal experience that it = is not the easiest thing to implement in JavaScript due to the fact that = we are using integers as keys rather than strictly sticking to strings. = Even the easy mapping (make the integer a string) would not necessarily = work in the long run as COSE would support both having keys of 1 (as a = number) and =E2=80=9C1=E2=80=9D (as a string) for a map key value. = This makes any direct JavaScript support lots of fun. =20 Jim =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Monday, August 17, 2015 10:51 AM To: Kathleen Moriarty Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org = =20 Subject: Re: [COSE] RSA Algorithm Decisions =20 I didn't bring up Google's use of RSA1.5 with respect to them using or = not using COSE. I don't know about their interest in COSE one way or the = other.=20 I brought it up as a proxy, of sorts, for a sampling of real world = support for asymmetric signature algorithms in practice out in the 'real = world'. They are signing tokens which will be consumed on an extremely = wide variety of platforms and systems. They chose RSA1.5 for that due to = its "wide availability." =20 =20 On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty = > wrote: Thanks for tracking that down. If we were to not include it, we would just need to recommend an asymmetric choice and ask them to join the discussion. Google and other organizations are usually very good about staying with current recommendation. Since COSE has not been implemented, it seems like a good time to do the right thing. Thanks, Kathleen On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > wrote: > I got an answer back from Google on their selection of = RSASSA-PKCS1-v1_5 for > signing of tokens, which I'll quote here: > > "We [Google] will always use an asymmetric alg so we can rotate keys. = Of > the asymmetric algs, RSA 1.5 was chosen due to its wide availability = for > client libraries at the time. If we were to support a newer alg in = the > future, it would also be an asymmetric one." > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > wrote: >> >> It would be good to get an answer from folks actually using it, but >> there is no reason we can't move forward without it. Google and = other >> vendors have been very good about deprecating algorithms and = protocols >> in their products, and even making customers aware when they are in >> use (browsers with https in red with a strikethrough and Mozilla = using >> a yellow caution triangle). >> >> Since COSE isn't deployed yet, I think it's okay and a good thing to >> be forward thinking. >> >> Kathleen >> >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones = > >> wrote: >> > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have = any comments on why >> > Google >> > is using RSASSA v1.5 to sign things? >> > >> > >> > >> > -- Mike >> > >> > >> > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com = ] >> > Sent: Thursday, August 13, 2015 2:29 PM >> > To: Mike Jones >> > Cc: Jim Schaad; cose@ietf.org =20 >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > >> > >> > I know a couple folks and I'll make an informal query to them. = They may >> > or >> > may not know the answer and may or may not reply. But I'll try. >> > >> > I suspect Mike is more right than not, however, which was basically = the >> > impetus for my using them as an example in the first place. >> > >> > >> > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones >> > > >> > wrote: >> > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary >> > tokens before JWT existed. I'm sure it was because it's = ubiquitously >> > available in all Web development tools - as we determined in the = survey >> > of >> > algorithms supported by common Web development platforms done by = the >> > JOSE >> > working group in mid-2012 (attached). >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Jim Schaad >> > Sent: Thursday, August 13, 2015 1:53 PM >> > To: 'Brian Campbell' >> > Cc: cose@ietf.org =20 >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > Brian, >> > >> > I wonder if you have any contacts inside of google to query them = why >> > they >> > went with RSA v1.5. However, I think that if you do it might be = because >> > of >> > the implementation requirements in the JOSE algorithms draft. I = just >> > looked and RS256 is labeled as recommended, but PS256 is labeled as >> > optional. It appears that similar language is in the JWT draft. = We >> > may >> > find the decision to use RSA v1.5 by google had more to do with = expected >> > JWT >> > libraries than with crypto library support. >> > >> > Jim >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org =20 >> > >> > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose = = &data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d= 2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4Vp= AREAuAG2EN7NfR9cSJ265o8PMOLn0%3d >> > >> > >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org =20 >> > https://www.ietf.org/mailman/listinfo/cose = =20 >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > -- Best regards, Kathleen =20 ------=_NextPart_000_09C2_01D0D938.C63AC280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So what are the use cases you think we need to support this in?=C2=A0 = That would be the first thing that one would need to look at before one = can make any guesses as to what environments we need to do the inventory = for.

 

Jim

 

 

From: Mike = Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = August 17, 2015 9:31 PM
To: Jim Schaad; 'Brian Campbell'; = 'Kathleen Moriarty'
Cc: 'Dirk Balfanz'; = cose@ietf.org
Subject: RE: [COSE] RSA Algorithm = Decisions

 

I=E2=80=99m personally queasy with not defining an algorithm = identifier for RSASSA v1.5 unless we first undertake a study equivalent = to the attached algorithm availability survey and convince ourselves = that RSA-PSS is now ubiquitously available.  Given that there are = no known attacks on RSASSA v1.5, trying to rule out the use of the most = commonly used signature algorithm without first doing the study seems = premature to me.

 

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

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Monday, August 17, 2015 1:14 PM
To: 'Brian = Campbell'; 'Kathleen Moriarty'
Cc: Mike Jones; 'Dirk Balfanz'; = cose@ietf.org
Subject: = RE: [COSE] RSA Algorithm Decisions

 

That was definitely my understanding of your position.  I asked = the question about Google simply because I was trying to determine if = the issue was really the deployment question or the question of how the = specs for JOSE were written.

 

Like Brian, I don=E2=80=99t know that Google would or would not have = any interest in ever using COSE.  I do know from personal = experience that it is not the easiest thing to implement in JavaScript = due to the fact that we are using integers as keys rather than strictly = sticking to strings.  Even the easy mapping (make the integer a = string) would not necessarily work in the long run as COSE would support = both having keys of 1 (as a number) and =E2=80=9C1=E2=80=9D (as a = string) for a map key value.   This makes any direct = JavaScript support lots of fun.

 

Jim

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.= com]
Sent: Monday, August 17, 2015 10:51 AM
To: = Kathleen Moriarty
Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org
Subject: Re: = [COSE] RSA Algorithm Decisions

 

I didn't bring up Google's use of RSA1.5 = with respect to them using or not using COSE. I don't know about their = interest in COSE one way or the other.

I brought it up as a proxy, of sorts, for a sampling = of real world support for asymmetric signature algorithms in practice = out in the 'real world'. They are signing tokens which will be consumed = on an extremely wide variety of platforms and systems. They chose RSA1.5 = for that due to its "wide availability."   =

 

On Mon, = Aug 17, 2015 at 7:34 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Thanks for tracking that down.  If we = were to not include it, we would
just need to recommend an asymmetric = choice and ask them to join the
discussion.  Google and other = organizations are usually very good
about staying with current = recommendation.  Since COSE has not been
implemented, it seems = like a good time to do the right = thing.

Thanks,
Kathleen


On Mon, Aug 17, = 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.com= > wrote:
> I got an answer back from Google on their selection = of RSASSA-PKCS1-v1_5 for
> signing of tokens, which I'll quote = here:
>
> "We [Google] will always use an asymmetric = alg so we can rotate keys.  Of
> the asymmetric algs, RSA 1.5 = was chosen due to its wide availability for
> client libraries at = the time.  If we were to support a newer alg in the
> future, = it would also be an asymmetric = one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 = PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@g= mail.com> wrote:
>>
>> It would be good to get = an answer from folks actually using it, but
>> there is no = reason we can't move forward without it.  Google and = other
>> vendors have been very good about deprecating = algorithms and protocols
>> in their products, and even making = customers aware when they are in
>> use (browsers with https in = red with a strikethrough and Mozilla using
>> a yellow caution = triangle).
>>
>> Since COSE isn't deployed yet, I = think it's okay and a good thing to
>> be forward = thinking.
>>
>> Kathleen
>>
>> On = Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> > Dirk =E2=80=93 you=E2=80=99re = on this list, correct?  Do you have any comments on why
>> = > Google
>> > is using RSASSA v1.5 to sign = things?
>> >
>> >
>> >
>> = >                  =                     =                     =    -- Mike
>> >
>> >
>> = >
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com= ]
>> > Sent: Thursday, August 13, 2015 2:29 PM
>> = > To: Mike Jones
>> > Cc: Jim Schaad; cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = >
>> >
>> > I know a couple folks and I'll = make an informal query to them.  They may
>> > = or
>> > may not know the answer and may or may not reply. = But I'll try.
>> >
>> > I suspect Mike is more = right than not, however, which was basically the
>> > = impetus for my using them as an example in the first place.
>> = >
>> >
>> >
>> > On Thu, Aug 13, = 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jones@microsoft.com>
>> > wrote:
>> >
>> > Google = was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary
>> > tokens before JWT existed.  I'm sure = it was because it's ubiquitously
>> > available in all Web = development tools - as we determined in the survey
>> > = of
>> > algorithms supported by common Web development = platforms done by the
>> > JOSE
>> > working = group in mid-2012 (attached).
>> >
>> >  =                     =            -- Mike
>> = >
>> > -----Original Message-----
>> > From: = COSE [mailto:cose-bounces@ietf.org] On = Behalf Of Jim Schaad
>> > Sent: Thursday, August 13, 2015 = 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = > Brian,
>> >
>> > I wonder if you have any = contacts inside of google to query them why
>> > = they
>> > went with RSA v1.5.  However, I think that if = you do it might be because
>> > of
>> > the = implementation requirements in the JOSE algorithms draft.   I = just
>> > looked and RS256 is labeled as recommended, but = PS256 is labeled as
>> > optional.  It appears that = similar language is in the JWT draft.   We
>> > = may
>> > find the decision to use RSA v1.5 by google had = more to do with expected
>> > JWT
>> > libraries = than with crypto library support.
>> >
>> > = Jim
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> = >
>> > https://na01.safelinks.protection.outlook.com/?url=3Dht= tps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7= cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f98= 8bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7Nf= R9cSJ265o8PMOLn0%3d
>> >
>> >
>> = >
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>&= gt; >
>>
>>
>>
>> = --
>>
>> Best regards,
>> = Kathleen
>
>

--

Best = regards,
Kathleen

 

------=_NextPart_000_09C2_01D0D938.C63AC280-- From nobody Mon Aug 17 22:14:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5451A044F for ; Mon, 17 Aug 2015 22:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYdyuqy1f-Hq for ; Mon, 17 Aug 2015 22:14:03 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E6B1A039A for ; Mon, 17 Aug 2015 22:14:03 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 69A2738F10; Mon, 17 Aug 2015 22:14:02 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <018b01d0d543$895664d0$9c032e70$@augustcellars.com> <020901d0d572$aa4f82f0$feee88d0$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2015 22:14:24 -0700 Message-ID: <09c601d0d974$bfe8c080$3fba4180$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLFFI7A7XD+J74WsC9DlLF5QD7CrQGCodbuAVYHbNwCQCAK95v/9+Yg Content-Language: en-us Archived-At: Subject: Re: [COSE] Single Recipient Discussions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 05:14:06 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, August 17, 2015 9:26 PM > To: Jim Schaad; cose@ietf.org > Subject: RE: [COSE] Single Recipient Discussions > > Would people prefer the structure that Jim described below: > > [ msg_type, protected, unprotected, payload, protected, unprotected, > signature] > > or the flattened structure: > > [ msg_type, protected, unprotected, payload, signature] > > The latter seems to me like it does a better job of "keeping simple things > simple". So which part of "keeping simple things simpler" does it make simpler? Do you want to address issue 4 below? Do you want to address issue 5 below? How many bytes are you saving by doing this? How much code space to you add if you need to do multiple signatures? Do you believe that there is never going to be the need to go from one to two signatures later? > > Jim, would MAC look exactly like signature, or if not, what would the differences No, you need to expand the correct set of structures [msg_type, protected, unprotected, plaintext, tag, protected, unprotected, encrypted_key] > be? Likewise, would encrypted content look like this in your proposal? > > [ msg_type, protected, unprotected, ciphertext, protected, unprotected, > encrypted_key] > > Likewise, in the encrypted structure, if we can coalesce the two sets of > protected and unprotected headers, that would seem simpler. Again - same questions > > -- Mike > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Wednesday, August 12, 2015 7:49 PM > To: Mike Jones; cose@ietf.org > Subject: RE: [COSE] Single Recipient Discussions > > No it would look like > > [ msg_type, protected, unprotected, payload, protected, unprotected, > signature] > > One would append the signature structure to the end of the body structure. > Similar for encryption and mac. > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Wednesday, August 12, 2015 2:25 PM > > To: Jim Schaad; cose@ietf.org > > Subject: RE: [COSE] Single Recipient Discussions > > > > I think I know what your proposal in 7 would look like, but it could > probably help > > the discussion if you were to give us a concrete example - not using > numbers > > and an actual representation, but using symbolic names for the array > fields. I'm > > thinking something like: > > > > [protected, > > unprotected, > > payload, > > signature] > > > > I realize you may be envisioning more fields than that to maintain the > layering > > you discuss below, which is part of why I'd like us to be able to > > easily > see what > > they are. > > > > Thanks, > > -- Mike > > > > -----Original Message----- > > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: Wednesday, August 12, 2015 5:12 PM > > To: cose@ietf.org > > Subject: [COSE] Single Recipient Discussions > > > > Since we appear to have finished dealing with the question of array vs > > map > at > > the top level, I want to restart the discussions dealing with handing > single > > recipient/signer as a special case. > > > > 1. I am assuming that we are going with arrays at the top level for > > all > of the > > sizes that I cite in this mail. As such, these number will be > > slightly > different that > > those cited by the advocates of a single recipient solution, but I do > > not > believe > > that the slightly different numbers would change their arguments in > > any > way. > > > > 2. I believe that it is a misnomer to call the discussion that has > > been > primarily > > advanced to be about a single recipient use case. It would be more > accurate the > > tag this discussion as being about making the case of using a PSK > > directly > as the > > key. The proposals do nothing to deal with any of the other key > management > > techniques as a single recipient, they only deal with a key management > > algorithm of 'direct'. > > > > 3. The message space savings for the proposals that have been > > advanced > will > > save at most 8 bytes from the current document. 2 bytes for the two > > array markers, 2 bytes for the two maps, 1 byte for the absent > > ciphertext, 1 > byte for > > the zero length recipient array, 2 bytes for the algorithm identifier > > tag and value. Of these 8 bytes, we can remove 3 of them relatively > > easily. If the recipient array is optional, then it disappears. If > > we > unroll the > > recipients in the case of a single recipient then the 2 bytes for > > array > markers > > disappears. The published document does the first but not the latter. > > > > 4. There is currently a very clear cut rule about things only being > > used > at the > > layer they are placed in. This means that currently key identifiers > > are > never > > placed in the same layer as a content key algorithm. This would be > > broken > by > > the proposal put forth. I worry that once this is done, there will be > more items > > than kid that will migrate between layers. One of the things that I > > never > liked in > > the JOSE proposals what the number of places that one needed to look > > for > the > > various control fields. Currently in COSE this is limited to two places. > If we > > introduce the possibility of cross layer contamination then this > > number > might > > grow in the future to deal with > > implementation faults. > > > > One of the way that these faults might develop is for designers to say > > - I > think > > that this should be authenticated, and thus will put it at the wrong > > layer > to > > ensure that it is. Either without thinking about the question - > > should it > be > > authenticated, or a different algorithm be required so that > > authentication > is > > possible. > > > > 5. Code size is going to be very different if two different methods > > of > dealing > > with structure needs to be supported. It is currently being assumed > > that > direct > > key is going to be the major use case in a number of situations. > > If this is not the case then current proposals do not help the > > situation > any. If it is > > true that more than one method of key management needs to be supported > > then the code size is going to grow because of the need to support an > additional > > way that key management is going to be done. > > > > 6. Personally, I am planning to argue against using direct key in > > future > work of > > ACE for long term authentication keys. The fact that it is going to > > be > hard to > > rotate them means that one needs to either add a KDF step or else have > > a > key > > agreement method to keep the same key from being used for the entire > lifetime > > of the device (perhaps 30 years?). This is something that is related > > to > the > > previous item as we now are going to need to support multiple key > management > > methods in these cases. > > > > 7. Now that we are doing arrays, it would be possible to have a > > generic > one > > recipient/signer solution by unrolling the recipient/signer structure > > on > the end of > > the message. This was originally proposed before the change from > > arrays > to > > maps was initially made. Since we are moving from maps back to arrays > > it > is one > > again a viable solution to look at. It would be totally viable to > > have > applications > > state that there is one recipient/signer and the unrolled version is > always used. > > This would still allow for multiple key management types to be used. > Systems in > > more unconstrained spaces could potentially setup to have multiple > recipients - > > but only if use cases exist where it would be needed. > > > > > > > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf. > > > org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro > > > soft.com%7c42b45138af2043af976708d2a35aa0e5%7c72f988bf86f141af91ab2 > > > d7cd011db47%7c1&sdata=62f4AJob4HGGxfnZpU2Yt7AGjiTJcxW75rCq2jYKlUo% > > 3d From nobody Mon Aug 17 22:16:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D481A044F for ; Mon, 17 Aug 2015 22:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V-7ss_0NLQ8 for ; Mon, 17 Aug 2015 22:16:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08031A19F7 for ; Mon, 17 Aug 2015 22:16:46 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 18 Aug 2015 05:16:26 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Tue, 18 Aug 2015 05:16:25 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [COSE] RSA Algorithm Decisions Thread-Index: AdDLFYVQBaFhIPMqQIC5i6cbL8YD+QDHIWQAAAJRXQAAA0+UAAAb9quAAD62XQAA9zPkgACYN5QAAAAtiFAAAQ+RAAAAB+hAAAAzsgAAvjjZgAAAbt2AAAjzDgAABQPiAAARNAwAAAFU7oAAAGVezw== Date: Tue, 18 Aug 2015 05:16:25 +0000 Message-ID: References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d92 9$4fc63260$ef529720$@augustcellars.com> , <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> In-Reply-To: <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [166.176.186.14] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:TaMnXr/NpqRKNn/gRVrPouhkNhVnwsX0Dpe2oeXdaXS7nHv5x7PuLEoeYyJWkloY3oXm2YEG+4E2X3aBWoSnTbrsssdR9JZfSQYKNuqkzGig2fS4JwhPgbVDWmjYhuT5U5aE2uJ7ZI2FoSStkDVEvQ==; 24:Z11yWJPo1tq2FvMMaFPiqt5hQ1rE4U564GExgtSDauz8cMaVUY6/JaBD2fkfAcuIzomZjQ36SrUgP5G9TiKdOe5bF18HhaFau6NZV1RejZw=; 20:ckUUwxexSdzNKL9JVB7PcSH7IHFjlpB4FrhXoAUGsjoW4cNj7fY0Wcthuyx2/pskxvyhVG7aE+xnPYPA2sqXVg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 067270ECAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(51444003)(54094003)(199003)(164054003)(377454003)(13464003)(24454002)(52604005)(16236675004)(86362001)(64706001)(19580395003)(92566002)(50986999)(2900100001)(68736005)(54356999)(101416001)(19625215002)(5001830100001)(2950100001)(76176999)(5001960100002)(33656002)(97736004)(105586002)(87936001)(86612001)(99286002)(110136002)(5890100001)(5001860100001)(189998001)(19580405001)(4001540100001)(81156007)(66066001)(10090500001)(106356001)(15975445007)(77156002)(8990500004)(62966003)(102836002)(77096005)(122556002)(46102003)(5003600100002)(5005710100001)(93886004)(10400500002)(76576001)(19617315012)(10290500002)(40100003)(2656002)(5002640100001)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44270BCE6B5398C5D6994C9F5780BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2015 05:16:25.4350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 05:16:51 -0000 --_000_BY2PR03MB44270BCE6B5398C5D6994C9F5780BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Among others, I think we should look at the popular embedded systems toolki= ts, such as the offering from Wind River. Others will have more current kn= owledge of these than me. -- Mike ________________________________ From: Jim Schaad Sent: =FD8/=FD17/=FD2015 10:04 PM To: Mike Jones Cc: cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions So what are the use cases you think we need to support this in? That would= be the first thing that one would need to look at before one can make any = guesses as to what environments we need to do the inventory for. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, August 17, 2015 9:31 PM To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty' Cc: 'Dirk Balfanz'; cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions I=92m personally queasy with not defining an algorithm identifier for RSASS= A v1.5 unless we first undertake a study equivalent to the attached algorit= hm availability survey and convince ourselves that RSA-PSS is now ubiquitou= sly available. Given that there are no known attacks on RSASSA v1.5, tryin= g to rule out the use of the most commonly used signature algorithm without= first doing the study seems premature to me. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, August 17, 2015 1:14 PM To: 'Brian Campbell'; 'Kathleen Moriarty' Cc: Mike Jones; 'Dirk Balfanz'; cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions That was definitely my understanding of your position. I asked the questio= n about Google simply because I was trying to determine if the issue was re= ally the deployment question or the question of how the specs for JOSE were= written. Like Brian, I don=92t know that Google would or would not have any interest= in ever using COSE. I do know from personal experience that it is not the= easiest thing to implement in JavaScript due to the fact that we are using= integers as keys rather than strictly sticking to strings. Even the easy = mapping (make the integer a string) would not necessarily work in the long = run as COSE would support both having keys of 1 (as a number) and =931=94 (= as a string) for a map key value. This makes any direct JavaScript suppor= t lots of fun. Jim From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Monday, August 17, 2015 10:51 AM To: Kathleen Moriarty Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions I didn't bring up Google's use of RSA1.5 with respect to them using or not = using COSE. I don't know about their interest in COSE one way or the other. I brought it up as a proxy, of sorts, for a sampling of real world support = for asymmetric signature algorithms in practice out in the 'real world'. Th= ey are signing tokens which will be consumed on an extremely wide variety o= f platforms and systems. They chose RSA1.5 for that due to its "wide availa= bility." On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty > wrote: Thanks for tracking that down. If we were to not include it, we would just need to recommend an asymmetric choice and ask them to join the discussion. Google and other organizations are usually very good about staying with current recommendation. Since COSE has not been implemented, it seems like a good time to do the right thing. Thanks, Kathleen On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > wrote: > I got an answer back from Google on their selection of RSASSA-PKCS1-v1_5 = for > signing of tokens, which I'll quote here: > > "We [Google] will always use an asymmetric alg so we can rotate keys. Of > the asymmetric algs, RSA 1.5 was chosen due to its wide availability for > client libraries at the time. If we were to support a newer alg in the > future, it would also be an asymmetric one." > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > wrote: >> >> It would be good to get an answer from folks actually using it, but >> there is no reason we can't move forward without it. Google and other >> vendors have been very good about deprecating algorithms and protocols >> in their products, and even making customers aware when they are in >> use (browsers with https in red with a strikethrough and Mozilla using >> a yellow caution triangle). >> >> Since COSE isn't deployed yet, I think it's okay and a good thing to >> be forward thinking. >> >> Kathleen >> >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones > >> wrote: >> > Dirk =96 you=92re on this list, correct? Do you have any comments on = why >> > Google >> > is using RSASSA v1.5 to sign things? >> > >> > >> > >> > -- Mike >> > >> > >> > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> > Sent: Thursday, August 13, 2015 2:29 PM >> > To: Mike Jones >> > Cc: Jim Schaad; cose@ietf.org >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > >> > >> > I know a couple folks and I'll make an informal query to them. They m= ay >> > or >> > may not know the answer and may or may not reply. But I'll try. >> > >> > I suspect Mike is more right than not, however, which was basically th= e >> > impetus for my using them as an example in the first place. >> > >> > >> > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones >> > > >> > wrote: >> > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprieta= ry >> > tokens before JWT existed. I'm sure it was because it's ubiquitously >> > available in all Web development tools - as we determined in the surve= y >> > of >> > algorithms supported by common Web development platforms done by the >> > JOSE >> > working group in mid-2012 (attached). >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: COSE [mailto:cose-bounces@ietf.org= ] On Behalf Of Jim Schaad >> > Sent: Thursday, August 13, 2015 1:53 PM >> > To: 'Brian Campbell' >> > Cc: cose@ietf.org >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > Brian, >> > >> > I wonder if you have any contacts inside of google to query them why >> > they >> > went with RSA v1.5. However, I think that if you do it might be becau= se >> > of >> > the implementation requirements in the JOSE algorithms draft. I just >> > looked and RS256 is labeled as recommended, but PS256 is labeled as >> > optional. It appears that similar language is in the JWT draft. We >> > may >> > find the decision to use RSA v1.5 by google had more to do with expect= ed >> > JWT >> > libraries than with crypto library support. >> > >> > Jim >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= .ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micr= osoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d >> > >> > >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > https://www.ietf.org/mailman/listinfo/cose >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > -- Best regards, Kathleen --_000_BY2PR03MB44270BCE6B5398C5D6994C9F5780BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Among others,= I think we should look at the popular embedded systems toolkits, such as t= he offering from Wind River.  Others will have more current knowledge = of these than me.

-- Mike
From: Jim Schaad
Sent: =FD8/= =FD17/=FD2015 10:04 PM
To: Mike Jones
Cc: cose@ietf.org
Subject: RE: [= COSE] RSA Algorithm Decisions

So what are the use cas= es you think we need to support this in?  That would be the first thin= g that one would need to look at before one can make any guesses as to what environments we need to do the inventory for.

 

Jim

 

 

From: Mike= Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, August 17, 2015 9:31 PM
To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty'
Cc: 'Dirk Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm Decisions

 

I=92m personally queasy= with not defining an algorithm identifier for RSASSA v1.5 unless we first = undertake a study equivalent to the attached algorithm availability survey and convince ourselves that RSA-PSS is now ubiquitously available.&= nbsp; Given that there are no known attacks on RSASSA v1.5, trying to rule = out the use of the most commonly used signature algorithm without first doi= ng the study seems premature to me.

 

    = ;            &n= bsp;            = ;            &n= bsp;            = ;      -- Mike

 

From: Jim Sc= haad [mailto:ietf@augustcellars.c= om]
Sent: Monday, August 17, 2015 1:14 PM
To: 'Brian Campbell'; 'Kathleen Moriarty'
Cc: Mike Jones; 'Dirk Balfanz'; cos= e@ietf.org
Subject: RE: [COSE] RSA Algorithm Decisions

 

That was definitely my = understanding of your position.  I asked the question about Google sim= ply because I was trying to determine if the issue was really the deployment question or the question of how the specs for JOSE were wri= tten.

 

Like Brian, I don=92t k= now that Google would or would not have any interest in ever using COSE.&nb= sp; I do know from personal experience that it is not the easiest thing to implement in JavaScript due to the fact that we are using integer= s as keys rather than strictly sticking to strings.  Even the easy map= ping (make the integer a string) would not necessarily work in the long run= as COSE would support both having keys of 1 (as a number) and =931=94 (as a string) for a map key value. &nb= sp; This makes any direct JavaScript support lots of fun.

 

Jim

 

From: Bria= n Campbell [mailto:bcampbell@= pingidentity.com]
Sent: Monday, August 17, 2015 10:51 AM
To: Kathleen Moriarty
Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org
Subject: Re: [COSE] RSA Algorithm Decisions

 

I didn't bring up Goo= gle's use of RSA1.5 with respect to them using or not using COSE. I don't k= now about their interest in COSE one way or the other.

I brought it up as a proxy, of sorts, for a sampling= of real world support for asymmetric signature algorithms in practice out = in the 'real world'. They are signing tokens which will be consumed on an e= xtremely wide variety of platforms and systems. They chose RSA1.5 for that due to its "wide availability= ."  

 

On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty &= lt;ka= thleen.moriarty.ietf@gmail.com> wrote:

Thanks for tracking that down.  If we were to n= ot include it, we would
just need to recommend an asymmetric choice and ask them to join the
discussion.  Google and other organizations are usually very good
about staying with current recommendation.  Since COSE has not been implemented, it seems like a good time to do the right thing.

Thanks,
Kathleen


On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> I got an answer back from Google on their selection of RSASSA-PKCS1-v1= _5 for
> signing of tokens, which I'll quote here:
>
> "We [Google] will always use an asymmetric alg so we can rotate k= eys.  Of
> the asymmetric algs, RSA 1.5 was chosen due to its wide availability f= or
> client libraries at the time.  If we were to support a newer alg = in the
> future, it would also be an asymmetric one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> It would be good to get an answer from folks actually using it, bu= t
>> there is no reason we can't move forward without it.  Google = and other
>> vendors have been very good about deprecating algorithms and proto= cols
>> in their products, and even making customers aware when they are i= n
>> use (browsers with https in red with a strikethrough and Mozilla u= sing
>> a yellow caution triangle).
>>
>> Since COSE isn't deployed yet, I think it's okay and a good thing = to
>> be forward thinking.
>>
>> Kathleen
>>
>> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> > Dirk =96 you=92re on this list, correct?  Do you have an= y comments on why
>> > Google
>> > is using RSASSA v1.5 to sign things?
>> >
>> >
>> >
>> >                 =                     &nbs= p;                     &n= bsp;-- Mike
>> >
>> >
>> >
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]
>> > Sent: Thursday, August 13, 2015 2:29 PM
>> > To: Mike Jones
>> > Cc: Jim Schaad; cose@ietf.or= g
>> > Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> >
>> >
>> > I know a couple folks and I'll make an informal query to them= .  They may
>> > or
>> > may not know the answer and may or may not reply. But I'll tr= y.
>> >
>> > I suspect Mike is more right than not, however, which was bas= ically the
>> > impetus for my using them as an example in the first place. >> >
>> >
>> >
>> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jo= nes@microsoft.com>
>> > wrote:
>> >
>> > Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary
>> > tokens before JWT existed.  I'm sure it was because it's= ubiquitously
>> > available in all Web development tools - as we determined in = the survey
>> > of
>> > algorithms supported by common Web development platforms done= by the
>> > JOSE
>> > working group in mid-2012 (attached).
>> >
>> >                 =                -- Mike
>> >
>> > -----Original Message-----
>> > From: COSE [mailto:c= ose-bounces@ietf.org] On Behalf Of Jim Schaad
>> > Sent: Thursday, August 13, 2015 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> > Brian,
>> >
>> > I wonder if you have any contacts inside of google to query t= hem why
>> > they
>> > went with RSA v1.5.  However, I think that if you do it = might be because
>> > of
>> > the implementation requirements in the JOSE algorithms draft.=    I just
>> > looked and RS256 is labeled as recommended, but PS256 is labe= led as
>> > optional.  It appears that similar language is in the JW= T draft.   We
>> > may
>> > find the decision to use RSA v1.5 by google had more to do wi= th expected
>> > JWT
>> > libraries than with crypto library support.
>> >
>> > Jim
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > COSE@ietf.org
>> >
>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micro= soft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d >> >
>> >
>> >
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>

--

Best regards,
Kathleen

 

--_000_BY2PR03MB44270BCE6B5398C5D6994C9F5780BY2PR03MB442namprd_-- From nobody Mon Aug 17 22:52:31 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A0C1B31EA for ; Mon, 17 Aug 2015 22:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z06vatyaEQtm for ; Mon, 17 Aug 2015 22:52:24 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D101B31F9 for ; Mon, 17 Aug 2015 22:52:24 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9299238F0C; Mon, 17 Aug 2015 22:52:23 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d9 2 9$4fc63260$ef529720$@augustcellars.com> , <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2015 22:52:45 -0700 Message-ID: <09d101d0d97a$1b8c2030$52a46090$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09D2_01D0D93F.6F34E950" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmgC8OqlTwHK57wSAbj7Yf0B8rD4AQJbo6bMAPHWWWoC2bLXKgG2P2djAsWU58wCccWxFQGoeRnYASg0UG8B5BBUxwLXmB6OAknwfFQCRjtC6p1TmkGQ Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 05:52:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09D2_01D0D93F.6F34E950 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable But it is unlikely that embedded systems are going to use RSA =96they = are going to use ECDSA in all probability. =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, August 17, 2015 10:16 PM To: Jim Schaad Cc: cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions =20 Among others, I think we should look at the popular embedded systems toolkits, such as the offering from Wind River. Others will have more current knowledge of these than me. -- Mike _____ =20 From: Jim Schaad =20 Sent: =FD8/=FD17/=FD2015 10:04 PM To: Mike Jones =20 Cc: cose@ietf.org =20 Subject: RE: [COSE] RSA Algorithm Decisions So what are the use cases you think we need to support this in? That = would be the first thing that one would need to look at before one can make = any guesses as to what environments we need to do the inventory for. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, August 17, 2015 9:31 PM To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty' Cc: 'Dirk Balfanz'; cose@ietf.org =20 Subject: RE: [COSE] RSA Algorithm Decisions =20 I=92m personally queasy with not defining an algorithm identifier for = RSASSA v1.5 unless we first undertake a study equivalent to the attached = algorithm availability survey and convince ourselves that RSA-PSS is now = ubiquitously available. Given that there are no known attacks on RSASSA v1.5, trying = to rule out the use of the most commonly used signature algorithm without = first doing the study seems premature to me. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Monday, August 17, 2015 1:14 PM To: 'Brian Campbell'; 'Kathleen Moriarty' Cc: Mike Jones; 'Dirk Balfanz'; cose@ietf.org =20 Subject: RE: [COSE] RSA Algorithm Decisions =20 That was definitely my understanding of your position. I asked the = question about Google simply because I was trying to determine if the issue was really the deployment question or the question of how the specs for JOSE were written. =20 Like Brian, I don=92t know that Google would or would not have any = interest in ever using COSE. I do know from personal experience that it is not the easiest thing to implement in JavaScript due to the fact that we are = using integers as keys rather than strictly sticking to strings. Even the = easy mapping (make the integer a string) would not necessarily work in the = long run as COSE would support both having keys of 1 (as a number) and = =931=94 (as a string) for a map key value. This makes any direct JavaScript support = lots of fun. =20 Jim =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Monday, August 17, 2015 10:51 AM To: Kathleen Moriarty Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org =20 Subject: Re: [COSE] RSA Algorithm Decisions =20 I didn't bring up Google's use of RSA1.5 with respect to them using or = not using COSE. I don't know about their interest in COSE one way or the = other.=20 I brought it up as a proxy, of sorts, for a sampling of real world = support for asymmetric signature algorithms in practice out in the 'real world'. They are signing tokens which will be consumed on an extremely wide = variety of platforms and systems. They chose RSA1.5 for that due to its "wide availability." =20 =20 On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty > wrote: Thanks for tracking that down. If we were to not include it, we would just need to recommend an asymmetric choice and ask them to join the discussion. Google and other organizations are usually very good about staying with current recommendation. Since COSE has not been implemented, it seems like a good time to do the right thing. Thanks, Kathleen On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > wrote: > I got an answer back from Google on their selection of = RSASSA-PKCS1-v1_5 for > signing of tokens, which I'll quote here: > > "We [Google] will always use an asymmetric alg so we can rotate keys. = Of > the asymmetric algs, RSA 1.5 was chosen due to its wide availability = for > client libraries at the time. If we were to support a newer alg in = the > future, it would also be an asymmetric one." > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > wrote: >> >> It would be good to get an answer from folks actually using it, but >> there is no reason we can't move forward without it. Google and = other >> vendors have been very good about deprecating algorithms and = protocols >> in their products, and even making customers aware when they are in >> use (browsers with https in red with a strikethrough and Mozilla = using >> a yellow caution triangle). >> >> Since COSE isn't deployed yet, I think it's okay and a good thing to >> be forward thinking. >> >> Kathleen >> >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones = > >> wrote: >> > Dirk =96 you=92re on this list, correct? Do you have any comments = on why >> > Google >> > is using RSASSA v1.5 to sign things? >> > >> > >> > >> > -- Mike >> > >> > >> > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com ] >> > Sent: Thursday, August 13, 2015 2:29 PM >> > To: Mike Jones >> > Cc: Jim Schaad; cose@ietf.org =20 >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > >> > >> > I know a couple folks and I'll make an informal query to them. = They may >> > or >> > may not know the answer and may or may not reply. But I'll try. >> > >> > I suspect Mike is more right than not, however, which was basically = the >> > impetus for my using them as an example in the first place. >> > >> > >> > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones >> > > >> > wrote: >> > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprietary >> > tokens before JWT existed. I'm sure it was because it's = ubiquitously >> > available in all Web development tools - as we determined in the = survey >> > of >> > algorithms supported by common Web development platforms done by = the >> > JOSE >> > working group in mid-2012 (attached). >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Jim Schaad >> > Sent: Thursday, August 13, 2015 1:53 PM >> > To: 'Brian Campbell' >> > Cc: cose@ietf.org =20 >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > Brian, >> > >> > I wonder if you have any contacts inside of google to query them = why >> > they >> > went with RSA v1.5. However, I think that if you do it might be because >> > of >> > the implementation requirements in the JOSE algorithms draft. I = just >> > looked and RS256 is labeled as recommended, but PS256 is labeled as >> > optional. It appears that similar language is in the JWT draft. = We >> > may >> > find the decision to use RSA v1.5 by google had more to do with expected >> > JWT >> > libraries than with crypto library support. >> > >> > Jim >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org =20 >> > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.or g%2fmailman%2flistinfo%2fcose &data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d= 2a408 0844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAu= AG2EN 7NfR9cSJ265o8PMOLn0%3d >> > >> > >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org =20 >> > https://www.ietf.org/mailman/listinfo/cose =20 >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > -- Best regards, Kathleen =20 ------=_NextPart_000_09D2_01D0D93F.6F34E950 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

But it is unlikely that embedded systems are going to use RSA =96they = are going to use ECDSA in all probability.

 

 

From: Mike = Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = August 17, 2015 10:16 PM
To: Jim Schaad
Cc: = cose@ietf.org
Subject: RE: [COSE] RSA Algorithm = Decisions

 

Among = others, I think we should look at the popular embedded systems toolkits, = such as the offering from Wind River.  Others will have more = current knowledge of these than me.

-- = Mike

From: = Jim Schaad
Sent: = =FD8/=FD17/= =FD2015 10:04 PM
To: = Mike = Jones
Cc: = cose@ietf.org
Subject: = RE: [COSE] = RSA Algorithm Decisions

So what are the use cases you think we need to support this in?  = That would be the first thing that one would need to look at before one = can make any guesses as to what environments we need to do the inventory = for.

 

Jim

 

 

From: Mike = Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Monday, August 17, 2015 9:31 = PM
To: Jim Schaad; 'Brian Campbell'; 'Kathleen = Moriarty'
Cc: 'Dirk Balfanz'; cose@ietf.org
Subject: RE: = [COSE] RSA Algorithm Decisions

 

I=92m personally queasy with not defining an algorithm identifier for = RSASSA v1.5 unless we first undertake a study equivalent to the attached = algorithm availability survey and convince ourselves that RSA-PSS is now = ubiquitously available.  Given that there are no known attacks on = RSASSA v1.5, trying to rule out the use of the most commonly used = signature algorithm without first doing the study seems premature to = me.

 

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

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Monday, August 17, 2015 1:14 PM
To: 'Brian = Campbell'; 'Kathleen Moriarty'
Cc: Mike Jones; 'Dirk Balfanz'; = cose@ietf.org
Subject: = RE: [COSE] RSA Algorithm Decisions

 

That was definitely my understanding of your position.  I asked = the question about Google simply because I was trying to determine if = the issue was really the deployment question or the question of how the = specs for JOSE were written.

 

Like Brian, I don=92t know that Google would or would not have any = interest in ever using COSE.  I do know from personal experience = that it is not the easiest thing to implement in JavaScript due to the = fact that we are using integers as keys rather than strictly sticking to = strings.  Even the easy mapping (make the integer a string) would = not necessarily work in the long run as COSE would support both having = keys of 1 (as a number) and =931=94 (as a string) for a map key = value.   This makes any direct JavaScript support lots of = fun.

 

Jim

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.= com]
Sent: Monday, August 17, 2015 10:51 AM
To: = Kathleen Moriarty
Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org
Subject: Re: = [COSE] RSA Algorithm Decisions

 

I didn't bring up Google's use of RSA1.5 = with respect to them using or not using COSE. I don't know about their = interest in COSE one way or the other.

I brought it up as a proxy, of sorts, for a sampling = of real world support for asymmetric signature algorithms in practice = out in the 'real world'. They are signing tokens which will be consumed = on an extremely wide variety of platforms and systems. They chose RSA1.5 = for that due to its "wide availability."   =

 

On Mon, = Aug 17, 2015 at 7:34 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:

Thanks for tracking that down.  If we = were to not include it, we would
just need to recommend an asymmetric = choice and ask them to join the
discussion.  Google and other = organizations are usually very good
about staying with current = recommendation.  Since COSE has not been
implemented, it seems = like a good time to do the right = thing.

Thanks,
Kathleen


On Mon, Aug 17, = 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.com= > wrote:
> I got an answer back from Google on their selection = of RSASSA-PKCS1-v1_5 for
> signing of tokens, which I'll quote = here:
>
> "We [Google] will always use an asymmetric = alg so we can rotate keys.  Of
> the asymmetric algs, RSA 1.5 = was chosen due to its wide availability for
> client libraries at = the time.  If we were to support a newer alg in the
> future, = it would also be an asymmetric = one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 = PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@g= mail.com> wrote:
>>
>> It would be good to get = an answer from folks actually using it, but
>> there is no = reason we can't move forward without it.  Google and = other
>> vendors have been very good about deprecating = algorithms and protocols
>> in their products, and even making = customers aware when they are in
>> use (browsers with https in = red with a strikethrough and Mozilla using
>> a yellow caution = triangle).
>>
>> Since COSE isn't deployed yet, I = think it's okay and a good thing to
>> be forward = thinking.
>>
>> Kathleen
>>
>> On = Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> > Dirk =96 you=92re on this = list, correct?  Do you have any comments on why
>> > = Google
>> > is using RSASSA v1.5 to sign things?
>> = >
>> >
>> >
>> >    =                     =                     =                  -- = Mike
>> >
>> >
>> >
>> > = From: Brian Campbell [mailto:bcampbell@pingidentity.com= ]
>> > Sent: Thursday, August 13, 2015 2:29 PM
>> = > To: Mike Jones
>> > Cc: Jim Schaad; cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = >
>> >
>> > I know a couple folks and I'll = make an informal query to them.  They may
>> > = or
>> > may not know the answer and may or may not reply. = But I'll try.
>> >
>> > I suspect Mike is more = right than not, however, which was basically the
>> > = impetus for my using them as an example in the first place.
>> = >
>> >
>> >
>> > On Thu, Aug 13, = 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jones@microsoft.com>
>> > wrote:
>> >
>> > Google = was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary
>> > tokens before JWT existed.  I'm sure = it was because it's ubiquitously
>> > available in all Web = development tools - as we determined in the survey
>> > = of
>> > algorithms supported by common Web development = platforms done by the
>> > JOSE
>> > working = group in mid-2012 (attached).
>> >
>> >  =                     =            -- Mike
>> = >
>> > -----Original Message-----
>> > From: = COSE [mailto:cose-bounces@ietf.org] On = Behalf Of Jim Schaad
>> > Sent: Thursday, August 13, 2015 = 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = > Brian,
>> >
>> > I wonder if you have any = contacts inside of google to query them why
>> > = they
>> > went with RSA v1.5.  However, I think that if = you do it might be because
>> > of
>> > the = implementation requirements in the JOSE algorithms draft.   I = just
>> > looked and RS256 is labeled as recommended, but = PS256 is labeled as
>> > optional.  It appears that = similar language is in the JWT draft.   We
>> > = may
>> > find the decision to use RSA v1.5 by google had = more to do with expected
>> > JWT
>> > libraries = than with crypto library support.
>> >
>> > = Jim
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> = >
>> > https://na01.safelinks.protection.outlook.com/?url=3Dht= tps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7= cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f98= 8bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7Nf= R9cSJ265o8PMOLn0%3d
>> >
>> >
>> = >
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>&= gt; >
>>
>>
>>
>> = --
>>
>> Best regards,
>> = Kathleen
>
>

--

Best = regards,
Kathleen

 

------=_NextPart_000_09D2_01D0D93F.6F34E950-- From nobody Tue Aug 18 08:37:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF81A1AA5 for ; Tue, 18 Aug 2015 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xlh1maotbHE for ; Tue, 18 Aug 2015 08:37:34 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (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 6B00F1A1BA9 for ; Tue, 18 Aug 2015 08:37:31 -0700 (PDT) Received: by qged69 with SMTP id d69so119433111qge.0 for ; Tue, 18 Aug 2015 08:37:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=bgpBingku9UuCZSR1aJCWGTESnR607ROEMiKfVt0oNQ=; b=PEAcF4jP8JX/5WM+/GZLJ7Mq/PtT/T69FEOrkUbVmTSOPkN9w7aOb6D60b2EARtq8u ha7kdUpFYyNYjxpxW93xG/NBsCCv2JeQDHcTkXBFqoR08e4Zffy/CxuEOen17NuY7KC2 k7YCmKYS4f3CqOqDKkbYdgA4XUR++iMsECezKqhow3pD91HI055/dF2O7VisME326/Ea yycCmFJcsgGb3tbs/9RP1gwZ0gfZV23Tc/FFQsOPFLh7CluDqFMdr/Z5hMY23OgMcRwm 6Y2/VP7F744YnHjHi31mb3XqOonBQ5mPkcZ4jQQj7W60TGtSLtpfhTIHVhCWUOxQervA ReFA== X-Gm-Message-State: ALoCoQkXH1F8XhPk9sjCpPArikXIJsY5N/uqXVgTa76WXyuqVVJpZXG19ti3oswiS/sue3aJFdPA X-Received: by 10.141.28.80 with SMTP id f77mr14444957qhe.100.1439912250431; Tue, 18 Aug 2015 08:37:30 -0700 (PDT) Received: from [192.168.8.100] ([181.202.11.85]) by smtp.gmail.com with ESMTPSA id 65sm10414441qks.30.2015.08.18.08.37.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Aug 2015 08:37:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_462B0EA7-7517-4813-8912-20684F4A2B22"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John Bradley In-Reply-To: Date: Tue, 18 Aug 2015 12:37:26 -0300 Message-Id: <40A5E40A-ECC4-4E7A-B132-EC82C5AF9C23@ve7jtb.com> References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d92 9$4fc63260$ef529720$@augustcellars.com> <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> To: Michael Jones X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 15:37:38 -0000 --Apple-Mail=_462B0EA7-7517-4813-8912-20684F4A2B22 Content-Type: multipart/alternative; boundary="Apple-Mail=_879156E9-859E-47B6-9A53-4B6E0C06B2DE" --Apple-Mail=_879156E9-859E-47B6-9A53-4B6E0C06B2DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think we need to look at that around supporting RSA v1.5 for = signature.=20 My gut feeling is that no one is really going to be interested in RSA = PSS signatures. If we don=E2=80=99t include RSA v1.5 then we probably = should simplify things for COSE and not include RSA at all. That might be hard line but the right thing if this really is targeted = at constrained systems. Using RSA will make people want to use 1028bit = or smaller keys and that is becoming more theatre than security even = with PSS. I think the Google use of RSA v1.5 goes back to this = https://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.= html = when Nat and I first talked to them about unifying with JSON = Simple Sign before JOSE. The issue for them was having something that developers could implement. = They wanted no signature agility at the time, and we argued for = allowing PSS and EC signatures as a option at the time. It is the ability of clients to verify signatures not them signing them = that continues to be the concern. I have no idea if there is any = interest in COSE at the moment in Google. On the JWT side I prefer to lobby for implementing EC signatures as a = option for clients rather then PSS, as it is a bigger benefit for about = the same amount of work in any cases. John B. > On Aug 18, 2015, at 2:16 AM, Mike Jones = wrote: >=20 > Among others, I think we should look at the popular embedded systems = toolkits, such as the offering from Wind River. Others will have more = current knowledge of these than me. >=20 > -- Mike > From: Jim Schaad > Sent: =E2=80=8E8/=E2=80=8E17/=E2=80=8E2015 10:04 PM > To: Mike Jones > Cc: cose@ietf.org > Subject: RE: [COSE] RSA Algorithm Decisions >=20 > So what are the use cases you think we need to support this in? That = would be the first thing that one would need to look at before one can = make any guesses as to what environments we need to do the inventory = for. > =20 > Jim > =20 > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Monday, August 17, 2015 9:31 PM > To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty' > Cc: 'Dirk Balfanz'; cose@ietf.org > Subject: RE: [COSE] RSA Algorithm Decisions > =20 > I=E2=80=99m personally queasy with not defining an algorithm = identifier for RSASSA v1.5 unless we first undertake a study equivalent = to the attached algorithm availability survey and convince ourselves = that RSA-PSS is now ubiquitously available. Given that there are no = known attacks on RSASSA v1.5, trying to rule out the use of the most = commonly used signature algorithm without first doing the study seems = premature to me. > =20 > -- Mike > =20 > From: Jim Schaad [mailto:ietf@augustcellars.com = ]=20 > Sent: Monday, August 17, 2015 1:14 PM > To: 'Brian Campbell'; 'Kathleen Moriarty' > Cc: Mike Jones; 'Dirk Balfanz'; cose@ietf.org > Subject: RE: [COSE] RSA Algorithm Decisions > =20 > That was definitely my understanding of your position. I asked the = question about Google simply because I was trying to determine if the = issue was really the deployment question or the question of how the = specs for JOSE were written. > =20 > Like Brian, I don=E2=80=99t know that Google would or would not have = any interest in ever using COSE. I do know from personal experience = that it is not the easiest thing to implement in JavaScript due to the = fact that we are using integers as keys rather than strictly sticking to = strings. Even the easy mapping (make the integer a string) would not = necessarily work in the long run as COSE would support both having keys = of 1 (as a number) and =E2=80=9C1=E2=80=9D (as a string) for a map key = value. This makes any direct JavaScript support lots of fun. > =20 > Jim > =20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com = ]=20 > Sent: Monday, August 17, 2015 10:51 AM > To: Kathleen Moriarty > Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org = > Subject: Re: [COSE] RSA Algorithm Decisions > =20 > I didn't bring up Google's use of RSA1.5 with respect to them using or = not using COSE. I don't know about their interest in COSE one way or the = other. >=20 > I brought it up as a proxy, of sorts, for a sampling of real world = support for asymmetric signature algorithms in practice out in the 'real = world'. They are signing tokens which will be consumed on an extremely = wide variety of platforms and systems. They chose RSA1.5 for that due to = its "wide availability." =20 > =20 > On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty = > wrote: > Thanks for tracking that down. If we were to not include it, we would > just need to recommend an asymmetric choice and ask them to join the > discussion. Google and other organizations are usually very good > about staying with current recommendation. Since COSE has not been > implemented, it seems like a good time to do the right thing. >=20 > Thanks, > Kathleen >=20 > On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > > = wrote: > > I got an answer back from Google on their selection of = RSASSA-PKCS1-v1_5 for > > signing of tokens, which I'll quote here: > > > > "We [Google] will always use an asymmetric alg so we can rotate = keys. Of > > the asymmetric algs, RSA 1.5 was chosen due to its wide availability = for > > client libraries at the time. If we were to support a newer alg in = the > > future, it would also be an asymmetric one." > > > > > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > > wrote: > >> > >> It would be good to get an answer from folks actually using it, but > >> there is no reason we can't move forward without it. Google and = other > >> vendors have been very good about deprecating algorithms and = protocols > >> in their products, and even making customers aware when they are in > >> use (browsers with https in red with a strikethrough and Mozilla = using > >> a yellow caution triangle). > >> > >> Since COSE isn't deployed yet, I think it's okay and a good thing = to > >> be forward thinking. > >> > >> Kathleen > >> > >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones = > > >> wrote: > >> > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have = any comments on why > >> > Google > >> > is using RSASSA v1.5 to sign things? > >> > > >> > > >> > > >> > -- = Mike > >> > > >> > > >> > > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com = ] > >> > Sent: Thursday, August 13, 2015 2:29 PM > >> > To: Mike Jones > >> > Cc: Jim Schaad; cose@ietf.org > >> > Subject: Re: [COSE] RSA Algorithm Decisions > >> > > >> > > >> > > >> > I know a couple folks and I'll make an informal query to them. = They may > >> > or > >> > may not know the answer and may or may not reply. But I'll try. > >> > > >> > I suspect Mike is more right than not, however, which was = basically the > >> > impetus for my using them as an example in the first place. > >> > > >> > > >> > > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones > >> > > > >> > wrote: > >> > > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary > >> > tokens before JWT existed. I'm sure it was because it's = ubiquitously > >> > available in all Web development tools - as we determined in the = survey > >> > of > >> > algorithms supported by common Web development platforms done by = the > >> > JOSE > >> > working group in mid-2012 (attached). > >> > > >> > -- Mike > >> > > >> > -----Original Message----- > >> > From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Jim Schaad > >> > Sent: Thursday, August 13, 2015 1:53 PM > >> > To: 'Brian Campbell' > >> > Cc: cose@ietf.org > >> > Subject: Re: [COSE] RSA Algorithm Decisions > >> > > >> > Brian, > >> > > >> > I wonder if you have any contacts inside of google to query them = why > >> > they > >> > went with RSA v1.5. However, I think that if you do it might be = because > >> > of > >> > the implementation requirements in the JOSE algorithms draft. I = just > >> > looked and RS256 is labeled as recommended, but PS256 is labeled = as > >> > optional. It appears that similar language is in the JWT draft. = We > >> > may > >> > find the decision to use RSA v1.5 by google had more to do with = expected > >> > JWT > >> > libraries than with crypto library support. > >> > > >> > Jim > >> > > >> > _______________________________________________ > >> > COSE mailing list > >> > COSE@ietf.org > >> > > >> > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microso= ft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db= 47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d = > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > COSE mailing list > >> > COSE@ietf.org > >> > https://www.ietf.org/mailman/listinfo/cose = > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > >=20 > -- >=20 > Best regards, > Kathleen > =20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_879156E9-859E-47B6-9A53-4B6E0C06B2DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think we need to look at that around supporting RSA v1.5 for signature. 

My gut feeling is that no one is really = going to be interested in RSA PSS signatures.   If we don=E2=80=99t = include RSA v1.5 then we probably should simplify things for COSE = and not include RSA at all.

That might be hard line but the right thing if this really = is targeted at constrained systems.   Using RSA will make people = want to use 1028bit or smaller keys and that is becoming more theatre = than security even with PSS.

I think the Google use of RSA v1.5 goes = back to this https://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-m= agicsig-00.html when Nat and I first talked to them about = unifying with JSON Simple Sign before JOSE.

The issue for them was having something = that developers could implement.  They wanted no signature agility = at the time, and we argued for allowing PSS and EC signatures as a = option at the time.

It is the ability of clients to verify signatures not them = signing them that continues to be the concern.  I have no idea if = there is any interest in COSE at the moment  in Google.

On the JWT side I prefer = to lobby for implementing EC signatures as a option for clients rather = then PSS, as it is a bigger benefit for about the same amount of work in = any cases.

John = B.


On Aug 18, 2015, at 2:16 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Among others, I think we should look at the popular embedded = systems toolkits, such as the offering from Wind River.  Others = will have more current knowledge of these than me.

-- Mike
From: Jim Schaad
Sent: =E2=80=8E8/=E2=80=8E17/=E2=80=8E2015 10:04 PM
To: Mike Jones
Cc: cose@ietf.org
Subject: RE: [COSE] RSA Algorithm Decisions

So what are the use = cases you think we need to support this in?  That would be the = first thing that one would need to look at before one can make any = guesses as to what environments we need to do the inventory = for.

 

Jim

 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Monday, August 17, 2015 = 9:31 PM
To: Jim Schaad; 'Brian = Campbell'; 'Kathleen Moriarty'
Cc: 'Dirk Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm = Decisions

 

I=E2=80=99m personally queasy with not = defining an algorithm identifier for RSASSA v1.5 unless we first = undertake a study equivalent to the attached algorithm availability = survey and convince ourselves that RSA-PSS is now ubiquitously = available.  Given that there are no known attacks on RSASSA v1.5, = trying to rule out the use of the most commonly used signature algorithm = without first doing the study seems premature to me.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike

 

From: Jim Schaad = [mailto:ietf@augustcellars.com] 
Sent: Monday, August 17, 2015 = 1:14 PM
To: 'Brian Campbell'; 'Kathleen = Moriarty'
Cc: Mike Jones; 'Dirk = Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm = Decisions

 

That was definitely my understanding of = your position.  I asked the question about Google simply because I = was trying to determine if the issue was really the deployment question = or the question of how the specs for JOSE were written.

 

Like Brian, I don=E2=80=99t know that = Google would or would not have any interest in ever using COSE.  I = do know from personal experience that it is not the easiest thing to = implement in JavaScript due to the fact that we are using integers as = keys rather than strictly sticking to strings.  Even the easy = mapping (make the integer a string) would not necessarily work in the = long run as COSE would support both having keys of 1 (as a number) and = =E2=80=9C1=E2=80=9D (as a string) for a map key value.   This = makes any direct JavaScript support lots of fun.

 

Jim

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Monday, August 17, 2015 = 10:51 AM
To: Kathleen Moriarty
Cc: Mike Jones; Dirk Balfanz; = Jim Schaad; cose@ietf.org
Subject: Re: [COSE] RSA Algorithm = Decisions

 

I didn't bring up Google's use of RSA1.5 with respect to = them using or not using COSE. I don't know about their interest in COSE = one way or the other.

I = brought it up as a proxy, of sorts, for a sampling of real world support = for asymmetric signature algorithms in practice out in the 'real world'. = They are signing tokens which will be consumed on an extremely wide = variety of platforms and systems. They chose RSA1.5 for that due to its = "wide availability."   

 

On Mon, Aug 17, 2015 = at 7:34 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:
Thanks for tracking that down.  If = we were to not include it, we would
just need to recommend = an asymmetric choice and ask them to join the
discussion.  Google and other organizations are usually = very good
about staying with current recommendation.  = Since COSE has not been
implemented, it seems like a good = time to do the right thing.

Thanks,
Kathleen


On Mon, Aug 17, = 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.com>= wrote:
> I got an answer back from Google on their = selection of RSASSA-PKCS1-v1_5 for
> signing of tokens, = which I'll quote here:
>
> "We = [Google] will always use an asymmetric alg so we can rotate keys.  = Of
> the asymmetric algs, RSA 1.5 was chosen due to its = wide availability for
> client libraries at the = time.  If we were to support a newer alg in the
> = future, it would also be an asymmetric one."
>
>
>
> On Thu, Aug 13, = 2015 at 12:35 PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> It would be good to get an = answer from folks actually using it, but
>> there is = no reason we can't move forward without it.  Google and other
>> vendors have been very good about deprecating = algorithms and protocols
>> in their products, and = even making customers aware when they are in
>> use = (browsers with https in red with a strikethrough and Mozilla using
>> a yellow caution triangle).
>>
>> Since COSE isn't deployed yet, I think it's okay and = a good thing to
>> be forward thinking.
>>
>> Kathleen
>>
>> On Thu, Aug 13, 2015 at 2:30 = PM, Mike Jones <Michael.Jones@microsoft.com>
>> = wrote:
>> > Dirk =E2=80=93 you=E2=80=99re on this = list, correct?  Do you have any comments on why
>> > Google
>> > is using = RSASSA v1.5 to sign things?
>> >
>> >
>> >
>> >              =                     =                     =        -- Mike
>> >
>> >
>> >
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]>> > Sent: Thursday, August 13, 2015 2:29 PM
>> > To: Mike Jones
>> > Cc: = Jim Schaad; cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> = >
>> >
>> >
>> > I know a couple folks and I'll make an informal = query to them.  They may
>> > or
>> > may not know the answer and may or may not = reply. But I'll try.
>> >
>> = > I suspect Mike is more right than not, however, which was basically = the
>> > impetus for my using them as an example = in the first place.
>> >
>> = >
>> >
>> > On Thu, Aug = 13, 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jones@microsoft.com>
>> = > wrote:
>> >
>> > = Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary
>> > tokens before JWT existed.  = I'm sure it was because it's ubiquitously
>> > = available in all Web development tools - as we determined in the = survey
>> > of
>> > = algorithms supported by common Web development platforms done by the
>> > JOSE
>> > working group = in mid-2012 (attached).
>> >
>>= >                  =                -- Mike
>> >
>> > -----Original = Message-----
>> > From: COSE [mailto:cose-bounces@ietf.org] On = Behalf Of Jim Schaad
>> > Sent: Thursday, August = 13, 2015 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> = >
>> > Brian,
>> >
>> > I wonder if you have any contacts inside of = google to query them why
>> > they
>> > went with RSA v1.5.  However, I think that = if you do it might be because
>> > of
>> > the implementation requirements in the JOSE = algorithms draft.   I just
>> > looked = and RS256 is labeled as recommended, but PS256 is labeled as
>> > optional.  It appears that similar = language is in the JWT draft.   We
>> > = may
>> > find the decision to use RSA v1.5 by = google had more to do with expected
>> > JWT
>> > libraries than with crypto library support.
>> >
>> > Jim
>> >
>> > = _______________________________________________
>> = > COSE mailing list
>> > COSE@ietf.org
>> >
>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.= Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141a= f91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8P= MOLn0%3d
>> >
>> >
>> >
>> >
>> > = _______________________________________________
>> = > COSE mailing list
>> > COSE@ietf.org
>> = > https://www.ietf.org/mailman/listinfo/cose
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>

--

Best regards,
Kathleen

 

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

= --Apple-Mail=_879156E9-859E-47B6-9A53-4B6E0C06B2DE-- --Apple-Mail=_462B0EA7-7517-4813-8912-20684F4A2B22 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA4MTgxNTM3MjdaMCMGCSqGSIb3DQEJBDEWBBTdGqs5PF4Ln2zzHX39Wstj PKDAJjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBXsSJwQSefV/pnTOTMU27sUhAZbjYaEQZa7Y/shyqU56iT5HqR34od tLpL7w0o5M6P9r8mbnB2IeoaGzPnQEVN/StRqgycX7ds8qNLmnY5L8oxCtFfMs2H/AT4BMCXVE/B PXJkTb0Wknnv3nIjHloV1nBQBrhPHDIFVGlN0e1+bZJGsYaN3xfz7Conf1p7AzKz+Vj5dTMgKKr6 JCZPNSgIPWsK5Y+E/O/tfC4y5ApiphCURkU1icH+Vhu1tX1JbbOb1prYhSppJJ1+bYtdQVzvH7ex FbwvbYfMAMmw4PeaLXnY+IjgGsENv1LJlo641yUIL+xuqLbNk07s1xKU6lS8AAAAAAAA --Apple-Mail=_462B0EA7-7517-4813-8912-20684F4A2B22-- From nobody Tue Aug 18 16:28:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C691A8880 for ; Tue, 18 Aug 2015 16:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIZ9hA8f-vdM for ; Tue, 18 Aug 2015 16:28:15 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224311A889C for ; Tue, 18 Aug 2015 16:28:15 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 425472CA1B; Tue, 18 Aug 2015 16:28:14 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Michael Jones'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <056101d0ce48$8f693bb0$ae3bb310$@augustcellars.com> <07a501d0cfb3$442b2c00$cc818400$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d9 2 9$4fc63260$ef529720$@augustcellars.com> <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> <40A5E40A-ECC4-4E7A-B132-EC82C5AF9C23@ve7jtb.com> In-Reply-To: <40A5E40A-ECC4-4E7A-B132-EC82C5AF9C23@ve7jtb.com> Date: Tue, 18 Aug 2015 16:28:36 -0700 Message-ID: <0b1f01d0da0d$9b512200$d1f36600$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B20_01D0D9D2.EEF55740" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGVE6hMCm2r3Ee0RFNhkVpcWyP46QK5GLufAlRxNmgC8OqlTwHK57wSAbj7Yf0B8rD4AQJbo6bMAPHWWWoC2bLXKgG2P2djAsWU58wCccWxFQGoeRnYASg0UG8B5BBUxwLXmB6OAknwfFQCRjtC6gIFKQIxnUSYAyA= Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 23:28:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B20_01D0D9D2.EEF55740 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would have no problems with pulling all of the RSA algorithms from the = draft. =20 Jim =20 =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Tuesday, August 18, 2015 8:37 AM To: Michael Jones Cc: Jim Schaad; cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions =20 I think we need to look at that around supporting RSA v1.5 for = signature.=20 =20 My gut feeling is that no one is really going to be interested in RSA = PSS signatures. If we don=E2=80=99t include RSA v1.5 then we probably = should simplify things for COSE and not include RSA at all. =20 That might be hard line but the right thing if this really is targeted = at constrained systems. Using RSA will make people want to use 1028bit = or smaller keys and that is becoming more theatre than security even = with PSS. =20 I think the Google use of RSA v1.5 goes back to this = https://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00= .html when Nat and I first talked to them about unifying with JSON = Simple Sign before JOSE. =20 The issue for them was having something that developers could implement. = They wanted no signature agility at the time, and we argued for = allowing PSS and EC signatures as a option at the time. =20 It is the ability of clients to verify signatures not them signing them = that continues to be the concern. I have no idea if there is any = interest in COSE at the moment in Google. =20 On the JWT side I prefer to lobby for implementing EC signatures as a = option for clients rather then PSS, as it is a bigger benefit for about = the same amount of work in any cases. =20 John B. =20 =20 On Aug 18, 2015, at 2:16 AM, Mike Jones > wrote: =20 Among others, I think we should look at the popular embedded systems = toolkits, such as the offering from Wind River. Others will have more = current knowledge of these than me. -- Mike _____ =20 From: Jim Schaad Sent: =E2=80=8E8/=E2=80=8E17/=E2=80=8E2015 10:04 PM To: Mike Jones Cc: cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions So what are the use cases you think we need to support this in? That = would be the first thing that one would need to look at before one can = make any guesses as to what environments we need to do the inventory = for. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, August 17, 2015 9:31 PM To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty' Cc: 'Dirk Balfanz'; cose@ietf.org =20 Subject: RE: [COSE] RSA Algorithm Decisions =20 I=E2=80=99m personally queasy with not defining an algorithm identifier = for RSASSA v1.5 unless we first undertake a study equivalent to the = attached algorithm availability survey and convince ourselves that = RSA-PSS is now ubiquitously available. Given that there are no known = attacks on RSASSA v1.5, trying to rule out the use of the most commonly = used signature algorithm without first doing the study seems premature = to me. =20 -- Mike =20 From: Jim Schaad [ = mailto:ietf@augustcellars.com]=20 Sent: Monday, August 17, 2015 1:14 PM To: 'Brian Campbell'; 'Kathleen Moriarty' Cc: Mike Jones; 'Dirk Balfanz'; cose@ietf.org Subject: RE: [COSE] RSA Algorithm Decisions =20 That was definitely my understanding of your position. I asked the = question about Google simply because I was trying to determine if the = issue was really the deployment question or the question of how the = specs for JOSE were written. =20 Like Brian, I don=E2=80=99t know that Google would or would not have any = interest in ever using COSE. I do know from personal experience that it = is not the easiest thing to implement in JavaScript due to the fact that = we are using integers as keys rather than strictly sticking to strings. = Even the easy mapping (make the integer a string) would not necessarily = work in the long run as COSE would support both having keys of 1 (as a = number) and =E2=80=9C1=E2=80=9D (as a string) for a map key value. = This makes any direct JavaScript support lots of fun. =20 Jim =20 From: Brian Campbell [ = mailto:bcampbell@pingidentity.com]=20 Sent: Monday, August 17, 2015 10:51 AM To: Kathleen Moriarty Cc: Mike Jones; Dirk Balfanz; Jim Schaad; = cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions =20 I didn't bring up Google's use of RSA1.5 with respect to them using or = not using COSE. I don't know about their interest in COSE one way or the = other. I brought it up as a proxy, of sorts, for a sampling of real world = support for asymmetric signature algorithms in practice out in the 'real = world'. They are signing tokens which will be consumed on an extremely = wide variety of platforms and systems. They chose RSA1.5 for that due to = its "wide availability." =20 =20 On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty < = = kathleen.moriarty.ietf@gmail.com> wrote: Thanks for tracking that down. If we were to not include it, we would just need to recommend an asymmetric choice and ask them to join the discussion. Google and other organizations are usually very good about staying with current recommendation. Since COSE has not been implemented, it seems like a good time to do the right thing. Thanks, Kathleen On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell < bcampbell@pingidentity.com> wrote: > I got an answer back from Google on their selection of = RSASSA-PKCS1-v1_5 for > signing of tokens, which I'll quote here: > > "We [Google] will always use an asymmetric alg so we can rotate keys. = Of > the asymmetric algs, RSA 1.5 was chosen due to its wide availability = for > client libraries at the time. If we were to support a newer alg in = the > future, it would also be an asymmetric one." > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > < = kathleen.moriarty.ietf@gmail.com> wrote: >> >> It would be good to get an answer from folks actually using it, but >> there is no reason we can't move forward without it. Google and = other >> vendors have been very good about deprecating algorithms and = protocols >> in their products, and even making customers aware when they are in >> use (browsers with https in red with a strikethrough and Mozilla = using >> a yellow caution triangle). >> >> Since COSE isn't deployed yet, I think it's okay and a good thing to >> be forward thinking. >> >> Kathleen >> >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones < = Michael.Jones@microsoft.com> >> wrote: >> > Dirk =E2=80=93 you=E2=80=99re on this list, correct? Do you have = any comments on why >> > Google >> > is using RSASSA v1.5 to sign things? >> > >> > >> > >> > -- Mike >> > >> > >> > >> > From: Brian Campbell [mailto: = bcampbell@pingidentity.com] >> > Sent: Thursday, August 13, 2015 2:29 PM >> > To: Mike Jones >> > Cc: Jim Schaad; cose@ietf.org >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > >> > >> > I know a couple folks and I'll make an informal query to them. = They may >> > or >> > may not know the answer and may or may not reply. But I'll try. >> > >> > I suspect Mike is more right than not, however, which was basically = the >> > impetus for my using them as an example in the first place. >> > >> > >> > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones >> > < Michael.Jones@microsoft.com> >> > wrote: >> > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign their = proprietary >> > tokens before JWT existed. I'm sure it was because it's = ubiquitously >> > available in all Web development tools - as we determined in the = survey >> > of >> > algorithms supported by common Web development platforms done by = the >> > JOSE >> > working group in mid-2012 (attached). >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: COSE [mailto: = cose-bounces@ietf.org] On Behalf Of Jim Schaad >> > Sent: Thursday, August 13, 2015 1:53 PM >> > To: 'Brian Campbell' >> > Cc: cose@ietf.org >> > Subject: Re: [COSE] RSA Algorithm Decisions >> > >> > Brian, >> > >> > I wonder if you have any contacts inside of google to query them = why >> > they >> > went with RSA v1.5. However, I think that if you do it might be = because >> > of >> > the implementation requirements in the JOSE algorithms draft. I = just >> > looked and RS256 is labeled as recommended, but PS256 is labeled as >> > optional. It appears that similar language is in the JWT draft. = We >> > may >> > find the decision to use RSA v1.5 by google had more to do with = expected >> > JWT >> > libraries than with crypto library support. >> > >> > Jim >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > >> > = = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micro= soft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd01= 1db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d >> > >> > >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > = = https://www.ietf.org/mailman/listinfo/cose >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > -- Best regards, Kathleen =20 _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_0B20_01D0D9D2.EEF55740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I would have no problems with pulling all of the RSA algorithms from = the draft.

 

Jim

 

 

From: John = Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, August 18, = 2015 8:37 AM
To: Michael Jones
Cc: Jim Schaad; = cose@ietf.org
Subject: Re: [COSE] RSA Algorithm = Decisions

 

I think we = need to look at that around supporting RSA v1.5 for = signature. 

 

My gut feeling is that no one is really going to be = interested in RSA PSS signatures.   If we don=E2=80=99t = include RSA v1.5 then we probably should simplify things for COSE = and not include RSA at all.

 

That might be hard line but the right thing if this = really is targeted at constrained systems.   Using RSA will make = people want to use 1028bit or smaller keys and that is becoming more = theatre than security even with PSS.

 

I = think the Google use of RSA v1.5 goes back to this https://salmon-protocol.googlecode.com/svn/trunk/draft-pan= zer-magicsig-00.html when Nat and I first talked to them about = unifying with JSON Simple Sign before JOSE.

 

The issue for them was having something that = developers could implement.  They wanted no signature agility at = the time, and we argued for allowing PSS and EC signatures as a option = at the time.

 

It is the ability of clients to verify signatures not = them signing them that continues to be the concern.  I have no idea = if there is any interest in COSE at the moment  in = Google.

 

On the JWT side I prefer to lobby for implementing EC = signatures as a option for clients rather then PSS, as it is a bigger = benefit for about the same amount of work in any = cases.

 

John B.

 

 

On Aug 18, 2015, at 2:16 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

From: Jim = Schaad
Sent: =E2=80=8E8/= =E2=80=8E17/=E2=80=8E2015 10:04 PM
To: Mike Jones
Cc: cose@ietf.org
Subject: RE: [COSE] = RSA Algorithm Decisions

So what are the use cases you think we need to support this in?  = That would be the first thing that one would need to look at before one = can make any guesses as to what environments we need to do the inventory = for.

 

Jim

 

 

From: Mike Jones = [mailto:Michael.Jones@microsof= t.com] 
Sent: Monday, August 17, 2015 9:31 = PM
To: Jim = Schaad; 'Brian Campbell'; 'Kathleen Moriarty'
Cc: 'Dirk Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm = Decisions

 

I=E2=80=99m personally queasy with not defining an algorithm = identifier for RSASSA v1.5 unless we first undertake a study equivalent = to the attached algorithm availability survey and convince ourselves = that RSA-PSS is now ubiquitously available.  Given that there are = no known attacks on RSASSA v1.5, trying to rule out the use of the most = commonly used signature algorithm without first doing the study seems = premature to me.

 

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

 

From:=  Jim Schaad = [mailto:ietf@augustcellars.com] 
Sent: Monday, August 17, 2015 1:14 = PM
To: 'Brian = Campbell'; 'Kathleen Moriarty'
Cc: Mike Jones; 'Dirk = Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm = Decisions

 

That was definitely my understanding of your position.  I asked = the question about Google simply because I was trying to determine if = the issue was really the deployment question or the question of how the = specs for JOSE were written.

 

Like Brian, I don=E2=80=99t know that Google would or would not have = any interest in ever using COSE.  I do know from personal = experience that it is not the easiest thing to implement in JavaScript = due to the fact that we are using integers as keys rather than strictly = sticking to strings.  Even the easy mapping (make the integer a = string) would not necessarily work in the long run as COSE would support = both having keys of 1 (as a number) and =E2=80=9C1=E2=80=9D (as a = string) for a map key value.   This makes any direct = JavaScript support lots of fun.

 

Jim

 

From: Brian = Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Monday, August 17, 2015 10:51 = AM
To: Kathleen = Moriarty
Cc: Mike Jones; Dirk Balfanz; Jim = Schaad; cose@ietf.org
Subject: Re: [COSE] RSA Algorithm = Decisions

 

I didn't bring up Google's use of RSA1.5 = with respect to them using or not using COSE. I don't know about their = interest in COSE one way or the other.

I brought it up as a proxy, of sorts, for a sampling = of real world support for asymmetric signature algorithms in practice = out in the 'real world'. They are signing tokens which will be consumed = on an extremely wide variety of platforms and systems. They chose RSA1.5 = for that due to its "wide availability."   

 

On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

Thanks for tracking that down.  If = we were to not include it, we would
just need to recommend an = asymmetric choice and ask them to join the
discussion.  Google = and other organizations are usually very good
about staying with = current recommendation.  Since COSE has not been
implemented, it = seems like a good time to do the right = thing.

Thanks,
Kathleen


On Mon, Aug 17, = 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.com> = wrote:
> I got an answer back from Google on their selection of = RSASSA-PKCS1-v1_5 for
> signing of tokens, which I'll quote = here:
>
> "We [Google] will always use an asymmetric = alg so we can rotate keys.  Of
> the asymmetric algs, RSA 1.5 = was chosen due to its wide availability for
> client libraries at = the time.  If we were to support a newer alg in the
> future, = it would also be an asymmetric = one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 = PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> = wrote:
>>
>> It would be good to get an answer from = folks actually using it, but
>> there is no reason we can't = move forward without it.  Google and other
>> vendors have = been very good about deprecating algorithms and protocols
>> in = their products, and even making customers aware when they are = in
>> use (browsers with https in red with a strikethrough and = Mozilla using
>> a yellow caution = triangle).
>>
>> Since COSE isn't deployed yet, I = think it's okay and a good thing to
>> be forward = thinking.
>>
>> Kathleen
>>
>> On = Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>= > wrote:
>> > Dirk =E2=80=93 you=E2=80=99re on this list, = correct?  Do you have any comments on why
>> > = Google
>> > is using RSASSA v1.5 to sign things?
>> = >
>> >
>> >
>> >    =                     =                     =                  -- = Mike
>> >
>> >
>> >
>> > = From: Brian Campbell [mailto:bcampbell@pingidentity.com]
>>= > Sent: Thursday, August 13, 2015 2:29 PM
>> > To: Mike = Jones
>> > Cc: Jim Schaad; cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = >
>> >
>> > I know a couple folks and I'll = make an informal query to them.  They may
>> > = or
>> > may not know the answer and may or may not reply. = But I'll try.
>> >
>> > I suspect Mike is more = right than not, however, which was basically the
>> > = impetus for my using them as an example in the first place.
>> = >
>> >
>> >
>> > On Thu, Aug 13, = 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jones@microsoft.com>
>= > > wrote:
>> >
>> > Google was using RSA = v1.5 (with 1024 bit keys) to sign their proprietary
>> > = tokens before JWT existed.  I'm sure it was because it's = ubiquitously
>> > available in all Web development tools - = as we determined in the survey
>> > of
>> > = algorithms supported by common Web development platforms done by = the
>> > JOSE
>> > working group in mid-2012 = (attached).
>> >
>> >        =                     =      -- Mike
>> >
>> > = -----Original Message-----
>> > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of = Jim Schaad
>> > Sent: Thursday, August 13, 2015 1:53 = PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > = Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> = > Brian,
>> >
>> > I wonder if you have any = contacts inside of google to query them why
>> > = they
>> > went with RSA v1.5.  However, I think that if = you do it might be because
>> > of
>> > the = implementation requirements in the JOSE algorithms draft.   I = just
>> > looked and RS256 is labeled as recommended, but = PS256 is labeled as
>> > optional.  It appears that = similar language is in the JWT draft.   We
>> > = may
>> > find the decision to use RSA v1.5 by google had = more to do with expected
>> > JWT
>> > libraries = than with crypto library support.
>> >
>> > = Jim
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> = >
>> > https://na01.safelinks.protection.outlook.com/?url= =3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7= c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c= 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTP7B%2f1awN7E4VpAREAuAG2= EN7NfR9cSJ265o8PMOLn0%3d
>> >
>> = >
>> >
>> >
>> > = _______________________________________________
>> > COSE = mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose<= /a>
>> >
>>
>>
>>
>> = --
>>
>> Best regards,
>> = Kathleen
>
>

 

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

<= p class=3DMsoNormal> 

------=_NextPart_000_0B20_01D0D9D2.EEF55740-- From nobody Tue Aug 18 17:49:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427321A1BA3 for ; Tue, 18 Aug 2015 17:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oh7bTwbl7K7 for ; Tue, 18 Aug 2015 17:48:58 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1CB1A1B9A for ; Tue, 18 Aug 2015 17:48:56 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-c0-55d3d2760097 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 6B.4B.32179.672D3D55; Tue, 18 Aug 2015 20:48:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t7J0mrD0004010; Tue, 18 Aug 2015 20:48:54 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7J0mp3N020542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Aug 2015 20:48:52 -0400 To: Jim Schaad , "'John Bradley'" , "'Michael Jones'" References: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> <033601d0d5f0$f1316d40$d39447c0$@augustcellars.com> <093401d0d9 2 9$4fc63260$ef529720$@augustcellars.com> <09c101d0d973$72968d40$57c3a7c0$@augustcellars.com> <40A5E40A-ECC4-4E7A-B132-EC82C5AF9C23@ve7jtb.com> <0b1f01d0da0d$9b512200$d1f36600$@augustcellars.com> From: Justin Richer Message-ID: <55D3D26E.1000207@mit.edu> Date: Tue, 18 Aug 2015 20:48:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0b1f01d0da0d$9b512200$d1f36600$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------080909020402070800020805" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrFt26XKowZ2TehbTtk5ltVg9/Tub xd5pn1gsVt/9y+bA4rFxznQ2jyVLfjJ5tO74y+5x+/ZGlgCWKC6blNSczLLUIn27BK6ML6s+ MBVsuMdc8WHTTdYGxvvTmboYOTkkBEwkjv5YxAphi0lcuLeerYuRi0NIYDGTxNxlh9khnI2M EgufrmOEcG4zSZx+vACsXVhAW2J9+zywhIhAO6PEsYdTWCGqvrJLdN3+wQxSxSwgKLG6cRI7 iM0moCoxfU0LWDevgJrE1udXwZazAMVP313DBmKLCsRI9PzawAZRIyhxcuYTFhCbU8BB4smR dhaImWESMztPMk1gFJiFpGwWkhSEbSbRtbWLEcKWl2jeOpsZwlaTuL3tKjuy+AJGtlWMsim5 Vbq5iZk5xanJusXJiXl5qUW6Fnq5mSV6qSmlmxhBMcLuorqDccIhpUOMAhyMSjy8H3ZcDhVi TSwrrsw9xCjJwaQkyrttH1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO/PnUA53pTEyqrUonyY lDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXu2LQI2CRanpqRVpmTklCGkmDk6Q4TxA w9lBaniLCxJzizPTIfKnGBWlxHl/XQBKCIAkMkrz4HphKewVozjQK8K8hiDtPMD0B9f9Cmgw E9DgwxMuggwuSURISTUwtrYxT1MPuMzVIKJfVRYsVnLt5peFG3LeH06R3nLDq32bvGHn2prE zvpoG5931+fUJTUp/w8ytbX+3vN2z4TlvJt5tr3m7u1l2bndXWhx7QSF6JORToYv3hn0Zbyq jv3u8+Wiw4xT57bwqRXfDHx18YHxW/c65pCX/fWeNe7HRaMzfh9L/iWlxFKckWioxVxUnAgA kylMDTwDAAA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] RSA Algorithm Decisions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 00:49:03 -0000 This is a multi-part message in MIME format. --------------080909020402070800020805 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit As chair, I want to remind the working group that one of the goals here in COSE is cryptographic agility. If there is a need or desire to add the RSA algorithms (or any others) back into the COSE fold, we can do so with a supplementary draft that defines the algorithm point and the methods for fitting them into the appropriate signature and encryption structures. That said, I want to make sure that the editors and WG members make sure that the structures chosen are generally re-usable for the time when such new algorithms are added. I believe the current structures are, and we should endeavour not to lose that feature. -- Justin (as your COSE chair) On 8/18/2015 7:28 PM, Jim Schaad wrote: > > I would have no problems with pulling all of the RSA algorithms from > the draft. > > Jim > > *From:*John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Tuesday, August 18, 2015 8:37 AM > *To:* Michael Jones > *Cc:* Jim Schaad; cose@ietf.org > *Subject:* Re: [COSE] RSA Algorithm Decisions > > I think we need to look at that around supporting RSA v1.5 for signature. > > My gut feeling is that no one is really going to be interested in RSA > PSS signatures. If we don’t include RSA v1.5 then we probably should > simplify things for COSE and not include RSA at all. > > That might be hard line but the right thing if this really is targeted > at constrained systems. Using RSA will make people want to use 1028bit > or smaller keys and that is becoming more theatre than security even > with PSS. > > I think the Google use of RSA v1.5 goes back to this > https://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html when > Nat and I first talked to them about unifying with JSON Simple Sign > before JOSE. > > The issue for them was having something that developers could > implement. They wanted no signature agility at the time, and we > argued for allowing PSS and EC signatures as a option at the time. > > It is the ability of clients to verify signatures not them signing > them that continues to be the concern. I have no idea if there is any > interest in COSE at the moment in Google. > > On the JWT side I prefer to lobby for implementing EC signatures as a > option for clients rather then PSS, as it is a bigger benefit for > about the same amount of work in any cases. > > John B. > > On Aug 18, 2015, at 2:16 AM, Mike Jones > > > wrote: > > Among others, I think we should look at the popular embedded > systems toolkits, such as the offering from Wind River. Others > will have more current knowledge of these than me. > > -- Mike > > ------------------------------------------------------------------------ > > *From:*Jim Schaad > *Sent:*‎8/‎17/‎2015 10:04 PM > *To:*Mike Jones > *Cc:*cose@ietf.org > *Subject:*RE: [COSE] RSA Algorithm Decisions > > So what are the use cases you think we need to support this in? > That would be the first thing that one would need to look at > before one can make any guesses as to what environments we need to > do the inventory for. > > Jim > > *From:*Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:*Monday, August 17, 2015 9:31 PM > *To:*Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty' > *Cc:*'Dirk Balfanz'; cose@ietf.org > *Subject:*RE: [COSE] RSA Algorithm Decisions > > I’m personally queasy with not defining an algorithm identifier > for RSASSA v1.5 unless we first undertake a study equivalent to > the attached algorithm availability survey and convince ourselves > that RSA-PSS is now ubiquitously available. Given that there are > no known attacks on RSASSA v1.5, trying to rule out the use of the > most commonly used signature algorithm without first doing the > study seems premature to me. > > -- Mike > > *From:*Jim Schaad [mailto:ietf@augustcellars.com] > *Sent:*Monday, August 17, 2015 1:14 PM > *To:*'Brian Campbell'; 'Kathleen Moriarty' > *Cc:*Mike Jones; 'Dirk Balfanz';cose@ietf.org > *Subject:*RE: [COSE] RSA Algorithm Decisions > > That was definitely my understanding of your position. I asked > the question about Google simply because I was trying to determine > if the issue was really the deployment question or the question of > how the specs for JOSE were written. > > Like Brian, I don’t know that Google would or would not have any > interest in ever using COSE. I do know from personal experience > that it is not the easiest thing to implement in JavaScript due to > the fact that we are using integers as keys rather than strictly > sticking to strings. Even the easy mapping (make the integer a > string) would not necessarily work in the long run as COSE would > support both having keys of 1 (as a number) and “1” (as a string) > for a map key value. This makes any direct JavaScript support > lots of fun. > > Jim > > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:*Monday, August 17, 2015 10:51 AM > *To:*Kathleen Moriarty > *Cc:*Mike Jones; Dirk Balfanz; Jim Schaad;cose@ietf.org > > *Subject:*Re: [COSE] RSA Algorithm Decisions > > I didn't bring up Google's use of RSA1.5 with respect to them > using or not using COSE. I don't know about their interest in COSE > one way or the other. > > I brought it up as a proxy, of sorts, for a sampling of real world > support for asymmetric signature algorithms in practice out in the > 'real world'. They are signing tokens which will be consumed on an > extremely wide variety of platforms and systems. They chose RSA1.5 > for that due to its "wide availability." > > On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty > > wrote: > > Thanks for tracking that down. If we were to not include it, > we would > just need to recommend an asymmetric choice and ask them to > join the > discussion. Google and other organizations are usually very good > about staying with current recommendation. Since COSE has not > been > implemented, it seems like a good time to do the right thing. > > Thanks, > Kathleen > > > On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell > > wrote: > > I got an answer back from Google on their selection of > RSASSA-PKCS1-v1_5 for > > signing of tokens, which I'll quote here: > > > > "We [Google] will always use an asymmetric alg so we can > rotate keys. Of > > the asymmetric algs, RSA 1.5 was chosen due to its wide > availability for > > client libraries at the time. If we were to support a newer > alg in the > > future, it would also be an asymmetric one." > > > > > > > > On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty > > > wrote: > >> > >> It would be good to get an answer from folks actually using > it, but > >> there is no reason we can't move forward without it. Google > and other > >> vendors have been very good about deprecating algorithms > and protocols > >> in their products, and even making customers aware when > they are in > >> use (browsers with https in red with a strikethrough and > Mozilla using > >> a yellow caution triangle). > >> > >> Since COSE isn't deployed yet, I think it's okay and a good > thing to > >> be forward thinking. > >> > >> Kathleen > >> > >> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones > > > >> wrote: > >> > Dirk – you’re on this list, correct? Do you have any > comments on why > >> > Google > >> > is using RSASSA v1.5 to sign things? > >> > > >> > > >> > > >> > -- Mike > >> > > >> > > >> > > >> > From: Brian Campbell [mailto:bcampbell@pingidentity.com > ] > >> > Sent: Thursday, August 13, 2015 2:29 PM > >> > To: Mike Jones > >> > Cc: Jim Schaad;cose@ietf.org > >> > Subject: Re: [COSE] RSA Algorithm Decisions > >> > > >> > > >> > > >> > I know a couple folks and I'll make an informal query to > them. They may > >> > or > >> > may not know the answer and may or may not reply. But > I'll try. > >> > > >> > I suspect Mike is more right than not, however, which was > basically the > >> > impetus for my using them as an example in the first place. > >> > > >> > > >> > > >> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones > >> > > > >> > wrote: > >> > > >> > Google was using RSA v1.5 (with 1024 bit keys) to sign > their proprietary > >> > tokens before JWT existed. I'm sure it was because it's > ubiquitously > >> > available in all Web development tools - as we determined > in the survey > >> > of > >> > algorithms supported by common Web development platforms > done by the > >> > JOSE > >> > working group in mid-2012 (attached). > >> > > >> > -- Mike > >> > > >> > -----Original Message----- > >> > From: COSE [mailto:cose-bounces@ietf.org > ] On Behalf Of Jim Schaad > >> > Sent: Thursday, August 13, 2015 1:53 PM > >> > To: 'Brian Campbell' > >> > Cc:cose@ietf.org > >> > Subject: Re: [COSE] RSA Algorithm Decisions > >> > > >> > Brian, > >> > > >> > I wonder if you have any contacts inside of google to > query them why > >> > they > >> > went with RSA v1.5. However, I think that if you do it > might be because > >> > of > >> > the implementation requirements in the JOSE algorithms > draft. I just > >> > looked and RS256 is labeled as recommended, but PS256 is > labeled as > >> > optional. It appears that similar language is in the JWT > draft. We > >> > may > >> > find the decision to use RSA v1.5 by google had more to > do with expected > >> > JWT > >> > libraries than with crypto library support. > >> > > >> > Jim > >> > > >> > _______________________________________________ > >> > COSE mailing list > >> >COSE@ietf.org > >> > > >> > >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > COSE mailing list > >> >COSE@ietf.org > >> >https://www.ietf.org/mailman/listinfo/cose > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --------------080909020402070800020805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit As chair, I want to remind the working group that one of the goals here in COSE is cryptographic agility. If there is a need or desire to add the RSA algorithms (or any others) back into the COSE fold, we can do so with a supplementary draft that defines the algorithm point and the methods for fitting them into the appropriate signature and encryption structures.

That said, I want to make sure that the editors and WG members make sure that the structures chosen are generally re-usable for the time when such new algorithms are added. I believe the current structures are, and we should endeavour not to lose that feature.

 -- Justin (as your COSE chair)

On 8/18/2015 7:28 PM, Jim Schaad wrote:

I would have no problems with pulling all of the RSA algorithms from the draft.

 

Jim

 

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, August 18, 2015 8:37 AM
To: Michael Jones
Cc: Jim Schaad; cose@ietf.org
Subject: Re: [COSE] RSA Algorithm Decisions

 

I think we need to look at that around supporting RSA v1.5 for signature. 

 

My gut feeling is that no one is really going to be interested in RSA PSS signatures.   If we don’t include RSA v1.5 then we probably should simplify things for COSE and not include RSA at all.

 

That might be hard line but the right thing if this really is targeted at constrained systems.   Using RSA will make people want to use 1028bit or smaller keys and that is becoming more theatre than security even with PSS.

 

I think the Google use of RSA v1.5 goes back to this https://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html when Nat and I first talked to them about unifying with JSON Simple Sign before JOSE.

 

The issue for them was having something that developers could implement.  They wanted no signature agility at the time, and we argued for allowing PSS and EC signatures as a option at the time.

 

It is the ability of clients to verify signatures not them signing them that continues to be the concern.  I have no idea if there is any interest in COSE at the moment  in Google.

 

On the JWT side I prefer to lobby for implementing EC signatures as a option for clients rather then PSS, as it is a bigger benefit for about the same amount of work in any cases.

 

John B.

 

 

On Aug 18, 2015, at 2:16 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

Among others, I think we should look at the popular embedded systems toolkits, such as the offering from Wind River.  Others will have more current knowledge of these than me.

-- Mike

From: Jim Schaad
Sent: ‎8/‎17/‎2015 10:04 PM
To: Mike Jones
Cc: cose@ietf.org
Subject: RE: [COSE] RSA Algorithm Decisions

So what are the use cases you think we need to support this in?  That would be the first thing that one would need to look at before one can make any guesses as to what environments we need to do the inventory for.

 

Jim

 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Monday, August 17, 2015 9:31 PM
To: Jim Schaad; 'Brian Campbell'; 'Kathleen Moriarty'
Cc: 'Dirk Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm Decisions

 

I’m personally queasy with not defining an algorithm identifier for RSASSA v1.5 unless we first undertake a study equivalent to the attached algorithm availability survey and convince ourselves that RSA-PSS is now ubiquitously available.  Given that there are no known attacks on RSASSA v1.5, trying to rule out the use of the most commonly used signature algorithm without first doing the study seems premature to me.

 

                                                            -- Mike

 

From: Jim Schaad [mailto:ietf@augustcellars.com] 
Sent: Monday, August 17, 2015 1:14 PM
To: 'Brian Campbell'; 'Kathleen Moriarty'
Cc: Mike Jones; 'Dirk Balfanz'; cose@ietf.org
Subject: RE: [COSE] RSA Algorithm Decisions

 

That was definitely my understanding of your position.  I asked the question about Google simply because I was trying to determine if the issue was really the deployment question or the question of how the specs for JOSE were written.

 

Like Brian, I don’t know that Google would or would not have any interest in ever using COSE.  I do know from personal experience that it is not the easiest thing to implement in JavaScript due to the fact that we are using integers as keys rather than strictly sticking to strings.  Even the easy mapping (make the integer a string) would not necessarily work in the long run as COSE would support both having keys of 1 (as a number) and “1” (as a string) for a map key value.   This makes any direct JavaScript support lots of fun.

 

Jim

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Monday, August 17, 2015 10:51 AM
To: Kathleen Moriarty
Cc: Mike Jones; Dirk Balfanz; Jim Schaad; cose@ietf.org
Subject: Re: [COSE] RSA Algorithm Decisions

 

I didn't bring up Google's use of RSA1.5 with respect to them using or not using COSE. I don't know about their interest in COSE one way or the other.

I brought it up as a proxy, of sorts, for a sampling of real world support for asymmetric signature algorithms in practice out in the 'real world'. They are signing tokens which will be consumed on an extremely wide variety of platforms and systems. They chose RSA1.5 for that due to its "wide availability."   

 

On Mon, Aug 17, 2015 at 7:34 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Thanks for tracking that down.  If we were to not include it, we would
just need to recommend an asymmetric choice and ask them to join the
discussion.  Google and other organizations are usually very good
about staying with current recommendation.  Since COSE has not been
implemented, it seems like a good time to do the right thing.

Thanks,
Kathleen


On Mon, Aug 17, 2015 at 9:22 AM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
> I got an answer back from Google on their selection of RSASSA-PKCS1-v1_5 for
> signing of tokens, which I'll quote here:
>
> "We [Google] will always use an asymmetric alg so we can rotate keys.  Of
> the asymmetric algs, RSA 1.5 was chosen due to its wide availability for
> client libraries at the time.  If we were to support a newer alg in the
> future, it would also be an asymmetric one."
>
>
>
> On Thu, Aug 13, 2015 at 12:35 PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> It would be good to get an answer from folks actually using it, but
>> there is no reason we can't move forward without it.  Google and other
>> vendors have been very good about deprecating algorithms and protocols
>> in their products, and even making customers aware when they are in
>> use (browsers with https in red with a strikethrough and Mozilla using
>> a yellow caution triangle).
>>
>> Since COSE isn't deployed yet, I think it's okay and a good thing to
>> be forward thinking.
>>
>> Kathleen
>>
>> On Thu, Aug 13, 2015 at 2:30 PM, Mike Jones <Michael.Jones@microsoft.com>
>> wrote:
>> > Dirk – you’re on this list, correct?  Do you have any comments on why
>> > Google
>> > is using RSASSA v1.5 to sign things?
>> >
>> >
>> >
>> >                                                             -- Mike
>> >
>> >
>> >
>> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]
>> > Sent: Thursday, August 13, 2015 2:29 PM
>> > To: Mike Jones
>> > Cc: Jim Schaad; cose@ietf.org
>> > Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> >
>> >
>> > I know a couple folks and I'll make an informal query to them.  They may
>> > or
>> > may not know the answer and may or may not reply. But I'll try.
>> >
>> > I suspect Mike is more right than not, however, which was basically the
>> > impetus for my using them as an example in the first place.
>> >
>> >
>> >
>> > On Thu, Aug 13, 2015 at 12:02 PM, Mike Jones
>> > <Michael.Jones@microsoft.com>
>> > wrote:
>> >
>> > Google was using RSA v1.5 (with 1024 bit keys) to sign their proprietary
>> > tokens before JWT existed.  I'm sure it was because it's ubiquitously
>> > available in all Web development tools - as we determined in the survey
>> > of
>> > algorithms supported by common Web development platforms done by the
>> > JOSE
>> > working group in mid-2012 (attached).
>> >
>> >                                 -- Mike
>> >
>> > -----Original Message-----
>> > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
>> > Sent: Thursday, August 13, 2015 1:53 PM
>> > To: 'Brian Campbell'
>> > Cc: cose@ietf.org
>> > Subject: Re: [COSE] RSA Algorithm Decisions
>> >
>> > Brian,
>> >
>> > I wonder if you have any contacts inside of google to query them why
>> > they
>> > went with RSA v1.5.  However, I think that if you do it might be because
>> > of
>> > the implementation requirements in the JOSE algorithms draft.   I just
>> > looked and RS256 is labeled as recommended, but PS256 is labeled as
>> > optional.  It appears that similar language is in the JWT draft.   We
>> > may
>> > find the decision to use RSA v1.5 by google had more to do with expected
>> > JWT
>> > libraries than with crypto library support.
>> >
>> > Jim
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > COSE@ietf.org
>> >
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c0938b3fbedae40ec80d608d2a4080844%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TP7B%2f1awN7E4VpAREAuAG2EN7NfR9cSJ265o8PMOLn0%3d
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > COSE@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>

--

Best regards,
Kathleen

 

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

 



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

--------------080909020402070800020805-- From nobody Wed Aug 19 12:37:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7401B1A890F for ; Wed, 19 Aug 2015 12:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awGpEIYIxdFF for ; Wed, 19 Aug 2015 12:37:08 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58B21A8725 for ; Wed, 19 Aug 2015 12:37:08 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 1C4E52CA16 for ; Wed, 19 Aug 2015 12:37:08 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 19 Aug 2015 12:37:30 -0700 Message-ID: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDatdSZJv5I+PAqTwCYbJ1sQvN/7g== Content-Language: en-us Archived-At: Subject: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:37:10 -0000 I have switched Key Identifiers from being a string (a base64 string if it was binary) to being a binary value in all cases. As with JOSE the internal structure of a KID is not defined or reliable. Is there any reason to allow for KID values to be a text string as well as a binary string? The only possible reason that I can think of is to allow for readable KID values if one does a dump of a message. I don't know that this is worth the flexibility. Is there anyone who wants to argue for allowing have text values for KIDs that are not encoded as binary items? Jim From nobody Wed Aug 19 13:25:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5520C1A9060 for ; Wed, 19 Aug 2015 13:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0eukYPr6LdN for ; Wed, 19 Aug 2015 13:25:48 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1F31A1A94 for ; Wed, 19 Aug 2015 13:25:47 -0700 (PDT) X-AuditID: 12074425-f799a6d000007db3-fe-55d4e64962cb Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E6.D0.32179.946E4D55; Wed, 19 Aug 2015 16:25:45 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t7JKPjRS006328; Wed, 19 Aug 2015 16:25:45 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7JKPhSa015831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2015 16:25:44 -0400 To: Jim Schaad , cose@ietf.org References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> From: Justin Richer Message-ID: <55D4E640.1000806@mit.edu> Date: Wed, 19 Aug 2015 16:25:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nruv57EqoQVOXtcW0rVNZLVZP/87m wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGVMXPOGraCXu+JM/1umBsYbHF2MnBwSAiYS txfsZ4SwxSQu3FvP1sXIxSEksJhJ4v2v06wQzkZGiXerVrGCVAkJ3GaSuLpTCcQWFtCX2H3i JzuILSJgJrHmbBMbRI29xLl3z8Hq2QRUJaavaWECsXkF1CR+N1wDs1mA4ptO7WcGsUUFYiR6 fm1gg6gRlDg58wlLFyMHB6eAg8TynZkgYWYBW4k7c3czQ9jyEtvfzmGewCgwC0nHLCRls5CU LWBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRroZebWaKXmlK6iREcpi6qOxgnHFI6xCjAwajE w/thx+VQIdbEsuLK3EOMkhxMSqK8aWevhArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4XW9D5Tj TUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLg3f0EqFGwKDU9tSItM6cE Ic3EwQkynAdo+DqQGt7igsTc4sx0iPwpRkUpcd4rIAkBkERGaR5cLyyNvGIUB3pFmPcRSBUP MAXBdb8CGswENPjwhIsgg0sSEVJSDYzbbphUyLWG7jH16zA/1lR03vDeKuslV02k1651/ST0 YNanC99M5vKctt4r+dtzNqtebIHV1W6zGYHLcn51sfPtL+qPeRxkWJC4JpdT95Lf/aLJhioM yz32W31e92BOwZkPagtvT/jUMaVx3c8Xxcc3K3H/5d3r3OJy+dhVRsU3nx4dX79inX+IEktx RqKhFnNRcSIAujuXDf4CAAA= Archived-At: Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:25:50 -0000 (Speaking as an individual) In my JOSE experience, the *only* KID values I have ever used in any deployments are simple strings. Usually with values like "rsa-1" and "2015-08-19" and the like. No binary encoded data, no thumbprints, no base64. As such, I don't see the purpose of a binary value in the first place. What if I'm using a JWK encoded key but a COSE-encoded token? How am I supposed to map the KID here: https://mitreid.org/jwk to my COSE object if it's binary? If the answer is "just encode the JSON string as a binary", then I'm not sure what the binary actually buys us. -- Justin On 8/19/2015 3:37 PM, Jim Schaad wrote: > I have switched Key Identifiers from being a string (a base64 string if it > was binary) to being a binary value in all cases. As with JOSE the internal > structure of a KID is not defined or reliable. Is there any reason to allow > for KID values to be a text string as well as a binary string? The only > possible reason that I can think of is to allow for readable KID values if > one does a dump of a message. I don't know that this is worth the > flexibility. > > Is there anyone who wants to argue for allowing have text values for KIDs > that are not encoded as binary items? > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Aug 19 13:32:28 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D7A1B29AB for ; Wed, 19 Aug 2015 13:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kwmppxHYO0g for ; Wed, 19 Aug 2015 13:32:26 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE3D1AD0BC for ; Wed, 19 Aug 2015 13:32:26 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9F5D838F15; Wed, 19 Aug 2015 13:32:25 -0700 (PDT) From: "Jim Schaad" To: "'Justin Richer'" , References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> <55D4E640.1000806@mit.edu> In-Reply-To: <55D4E640.1000806@mit.edu> Date: Wed, 19 Aug 2015 13:32:47 -0700 Message-ID: <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIPnNG6hLSiKCXNqJBHdsIjfpOVvgIXOLhOnYWIY+A= Content-Language: en-us Archived-At: Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:32:27 -0000 For JOSE that is exactly what I would expect the experience to be, if for no other reason that that's what the examples were showing. Going to a binary value is a space consumption for JOSE because of the base64 encoding. However, do you think that people might start using thumbprints with the new document coming out of the JOSE working group? These are really common outside of the JOSE space for identifying keys because they have a greater degree of uniqueness (even if one truncates them). Jim > -----Original Message----- > From: Justin Richer [mailto:jricher@mit.edu] > Sent: Wednesday, August 19, 2015 1:26 PM > To: Jim Schaad; cose@ietf.org > Subject: Re: [COSE] Question on Key Identifiers > > (Speaking as an individual) > > In my JOSE experience, the *only* KID values I have ever used in any > deployments are simple strings. Usually with values like "rsa-1" and "2015-08- > 19" and the like. No binary encoded data, no thumbprints, no base64. > > As such, I don't see the purpose of a binary value in the first place. > What if I'm using a JWK encoded key but a COSE-encoded token? How am I > supposed to map the KID here: > > https://mitreid.org/jwk > > to my COSE object if it's binary? If the answer is "just encode the JSON string as > a binary", then I'm not sure what the binary actually buys us. > > -- Justin > > On 8/19/2015 3:37 PM, Jim Schaad wrote: > > I have switched Key Identifiers from being a string (a base64 string > > if it was binary) to being a binary value in all cases. As with JOSE > > the internal structure of a KID is not defined or reliable. Is there > > any reason to allow for KID values to be a text string as well as a > > binary string? The only possible reason that I can think of is to > > allow for readable KID values if one does a dump of a message. I > > don't know that this is worth the flexibility. > > > > Is there anyone who wants to argue for allowing have text values for > > KIDs that are not encoded as binary items? > > > > Jim > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Aug 19 13:35:42 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4821ABC10 for ; Wed, 19 Aug 2015 13:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcEjGZh25HzM for ; Wed, 19 Aug 2015 13:35:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128D11A8A56 for ; Wed, 19 Aug 2015 13:35:37 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.231.11; Wed, 19 Aug 2015 20:35:36 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Wed, 19 Aug 2015 20:35:36 +0000 From: Mike Jones To: Jim Schaad , 'Justin Richer' , "cose@ietf.org" Thread-Topic: [COSE] Question on Key Identifiers Thread-Index: AdDatdSZJv5I+PAqTwCYbJ1sQvN/7gAB2AAAAABAOYAAABkwkg== Date: Wed, 19 Aug 2015 20:35:36 +0000 Message-ID: References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> <55D4E640.1000806@mit.edu>, <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> In-Reply-To: <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [166.176.186.14] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:boXPPZgA9DQEmxYKwRIsPQM9/9ls69+15GyLp/LNMe4eZu8VfG7Uc6HUXfZSaGr+klQmnDlHd8NUub4CF1uLoCZUEynOPDqx83JNgiPhYzDR1zFillNC+Uxi6T4CyaHU4OTF7LJ3mnYrKA0aRT9ywQ==; 24:eZNJhNH4hHeZVeUzl4t64Wn0VRk2cZGPL6HSZGjg8TegxTVQljjpte46EuazDMzSiTRqePr2z/FzEOLfZZ5yl+B4LgJMhvWd5Yta8t92nQE=; 20:rN79932RoUzXgcNA08MdPdLEgfxrSqQ1qe1AEKefSMme7FmLMMn1r3bcX6NNaFqWQmcYAHvd8zCLOsWsNEMv0A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(479174004)(24454002)(13464003)(33656002)(101416001)(2950100001)(10090500001)(5001830100001)(19625215002)(106356001)(5001960100002)(2501003)(74316001)(76176999)(16236675004)(97736004)(81156007)(66066001)(46102003)(19580395003)(107886002)(5001770100001)(5001860100001)(4001540100001)(76576001)(105586002)(64706001)(99286002)(92566002)(54356999)(86612001)(50986999)(10400500002)(5005710100001)(86362001)(19617315012)(87936001)(2171001)(2656002)(19580405001)(5003600100002)(2900100001)(8990500004)(68736005)(189998001)(10290500002)(122556002)(77156002)(62966003)(102836002)(15975445007)(40100003)(5002640100001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4429E0874291F1AD9AF76CEF5670BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2015 20:35:36.2892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:35:41 -0000 --_000_BY2PR03MB4429E0874291F1AD9AF76CEF5670BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I would use thumbprints as COSE key ID values, and so would favor binary ke= y ID values. -- Mike ________________________________ From: Jim Schaad Sent: =FD8/=FD19/=FD2015 1:32 PM To: 'Justin Richer'; cose@ietf.org Subject: Re: [COSE] Question on Key Identifiers For JOSE that is exactly what I would expect the experience to be, if for n= o other reason that that's what the examples were showing. Going to a binary value is a space consumption for JOSE because of the base64 encoding. However, do you think that people might start using thumbprints with the ne= w document coming out of the JOSE working group? These are really common outside of the JOSE space for identifying keys because they have a greater degree of uniqueness (even if one truncates them). Jim > -----Original Message----- > From: Justin Richer [mailto:jricher@mit.edu] > Sent: Wednesday, August 19, 2015 1:26 PM > To: Jim Schaad; cose@ietf.org > Subject: Re: [COSE] Question on Key Identifiers > > (Speaking as an individual) > > In my JOSE experience, the *only* KID values I have ever used in any > deployments are simple strings. Usually with values like "rsa-1" and "2015-08- > 19" and the like. No binary encoded data, no thumbprints, no base64. > > As such, I don't see the purpose of a binary value in the first place. > What if I'm using a JWK encoded key but a COSE-encoded token? How am I > supposed to map the KID here: > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmitrei= d.org%2fjwk&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7cf144e2aacf2c4d= a1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D3pUQcoqpF= eFUf4zPkf6KRgZTS3HpAK9z57ZbkTa7Rxc%3d > > to my COSE object if it's binary? If the answer is "just encode the JSON string as > a binary", then I'm not sure what the binary actually buys us. > > -- Justin > > On 8/19/2015 3:37 PM, Jim Schaad wrote: > > I have switched Key Identifiers from being a string (a base64 string > > if it was binary) to being a binary value in all cases. As with JOSE > > the internal structure of a KID is not defined or reliable. Is there > > any reason to allow for KID values to be a text string as well as a > > binary string? The only possible reason that I can think of is to > > allow for readable KID values if one does a dump of a message. I > > don't know that this is worth the flexibility. > > > > Is there anyone who wants to argue for allowing have text values for > > KIDs that are not encoded as binary items? > > > > Jim > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.= ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micro= soft.com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DjBQrziGATnv69UC1%2fRtwfCUMSblsc5R7S7V6oOoP2dI%3d _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3DjBQrziGATnv69UC1%2fRtwfCUMSblsc5R7S7V6oOoP2dI%3d --_000_BY2PR03MB4429E0874291F1AD9AF76CEF5670BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I would use t= humbprints as COSE key ID values, and so would favor binary key ID values.<= br>
-- Mike
From: Jim Schaad
Sent: =FD8/= =FD19/=FD2015 1:32 PM
To: 'Justin Richer'; cose@ietf.org
Subject: Re: [= COSE] Question on Key Identifiers

For JOSE that is exactly what I would expect the e= xperience to be, if for no
other reason that that's what the examples were showing.  Going to a b= inary
value is a space consumption for JOSE because of the base64 encoding.

However, do you think that people might start using thumbprints with the ne= w
document coming out of the JOSE working group?  These are really commo= n
outside of the JOSE space for identifying keys because they have a greater<= br> degree of uniqueness (even if one truncates them).

Jim


> -----Original Message-----
> From: Justin Richer [mailto:jricher= @mit.edu]
> Sent: Wednesday, August 19, 2015 1:26 PM
> To: Jim Schaad; cose@ietf.org
> Subject: Re: [COSE] Question on Key Identifiers
>
> (Speaking as an individual)
>
> In my JOSE experience, the *only* KID values I have ever used in any > deployments are simple strings. Usually with values like "rsa-1&q= uot; and
"2015-08-
> 19" and the like. No binary encoded data, no thumbprints, no base= 64.
>
> As such, I don't see the purpose of a binary value in the first place.=
> What if I'm using a JWK encoded key but a COSE-encoded token? How am I=
> supposed to map the KID here:
>
> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmitreid.= org%2fjwk&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7cf144e2aacf2c= 4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D3pU= QcoqpFeFUf4zPkf6KRgZTS3HpAK9z57ZbkTa7Rxc%3d
>
> to my COSE object if it's binary? If the answer is "just encode t= he JSON
string as
> a binary", then I'm not sure what the binary actually buys us. >
>   -- Justin
>
> On 8/19/2015 3:37 PM, Jim Schaad wrote:
> > I have switched Key Identifiers from being a string (a base64 str= ing
> > if it was binary) to being a binary value in all cases.  As = with JOSE
> > the internal structure of a KID is not defined or reliable. = Is there
> > any reason to allow for KID values to be a text string as well as= a
> > binary string?  The only possible reason that I can think of= is to
> > allow for readable KID values if one does a dump of a message.&nb= sp; I
> > don't know that this is worth the flexibility.
> >
> > Is there anyone who wants to argue for allowing have text values = for
> > KIDs that are not encoded as binary items?
> >
> > Jim
> >
> >
> > _______________________________________________
> > COSE mailing list
> > COSE@ietf.org
> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40micro= soft.com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DjBQrziGATnv69UC1%2fRtwfCUMSblsc5R7S7V6oOoP2dI%3d
_______________________________________________
COSE mailing list
COSE@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww= w.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%4= 0microsoft.com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7= cd011db47%7c1&sdata=3DjBQrziGATnv69UC1%2fRtwfCUMSblsc5R7S7V6oOoP2dI%3d<= /a>
 --_000_BY2PR03MB4429E0874291F1AD9AF76CEF5670BY2PR03MB442namprd_-- From nobody Wed Aug 19 14:14:33 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC021B2B0A for ; Wed, 19 Aug 2015 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTtu-jcsJyZi for ; Wed, 19 Aug 2015 14:14:29 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC9B1B2B04 for ; Wed, 19 Aug 2015 14:14:29 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-7f-55d4f1b36712 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 3E.A2.01570.3B1F4D55; Wed, 19 Aug 2015 17:14:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t7JLER45012514; Wed, 19 Aug 2015 17:14:27 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7JLENMg017422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2015 17:14:26 -0400 To: Jim Schaad , cose@ietf.org References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> <55D4E640.1000806@mit.edu> <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> From: Justin Richer Message-ID: <55D4F1A8.1050409@mit.edu> Date: Wed, 19 Aug 2015 17:14:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6norvl45VQg+cLmCymbZ3KarF6+nc2 ByaPjXOms3ksWfKTKYApissmJTUnsyy1SN8ugStjx/eigqvSFZeu7WFqYPwl2sXIySEhYCLx d9kPZghbTOLCvfVsXYxcHEICi5kk3vSsYwFJCAlsZJRonCkKkbjNJNH54xsjSEJYQF9i94mf 7CC2iICZxJqzTVDdkxglphxuYQVJsAmoSkxf08LUxcjBwSugJnF/miZImAUoPPX/ZrBeUYEY iZ5fG9hAbF4BQYmTM5+ALeYUcJBoaO4AizML2ErcmbubGcKWl9j+dg7zBEaBWUhaZiEpm4Wk bAEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdQ73czBK91JTSTYygMOWU5NnB+Oag0iFGAQ5G JR7eDzsuhwqxJpYVV+YeYpTkYFIS5U07eyVUiC8pP6UyI7E4I76oNCe1+BCjBAezkgiv632g HG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBO//90CNgkWp6akVaZk5 JQhpJg5OkOE8QMMNPoAMLy5IzC3OTIfIn2JUlBLnfQDSLACSyCjNg+uFpZFXjOJArwjz5oK0 8wBTEFz3K6DBTECDD0+4CDK4JBEhJdXA2PN3Z4DH6bXJe4vFu/Pf7PA7w6SsctGr5qJZXay3 +1LZfV9uPNiQdudk9oXfcgumXvzGtj5tX5mT0DUljb5986vN+B59+7Wq+SPj4chd0xrcOrmy 3yjPdHZMvRohKSFxdEfTW+k3xbPuNDiYhym1/fflTV/xxcP/cuXzl4uSn+xyV4tYdsN9hxJL cUaioRZzUXEiAAV5/8r+AgAA Archived-At: Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 21:14:31 -0000 (Again, as an individual). I honestly don't see people going to thumbprints in the COSE space. Your argument of space efficiency assumes that I've got a big binary value that I want to store in the KID. If I have a keystore with a handful of keys, it's going to be much easier and more space efficient to tell my apps/devices/things-of-the-internet "use key '1'" instead of "use key with the hash 'abcd2341'", because the latter is something they're going to have to compute themselves and compare. It would seem to me that most of these devices are going to have a bucket of keys to test against that they'll be getting from context, either as pre-placed into the device at onboarding/configuration time, or fetched over the network using a mechanism like jwks_uri is used in JOSE-based protocols like OpenID Connect. This position is based (and biased) from my JOSE deployment experience, so take it with the appropriate salt. In the end, I do think strings are a lot more flexible as an ID and I would personally anticipate them being more common. I don't anticipate moving any of my JOSE-related things to using thumbprints, so I wouldn't expect to see them enforced here in COSE. -- Justin On 8/19/2015 4:32 PM, Jim Schaad wrote: > For JOSE that is exactly what I would expect the experience to be, if for no > other reason that that's what the examples were showing. Going to a binary > value is a space consumption for JOSE because of the base64 encoding. > > However, do you think that people might start using thumbprints with the new > document coming out of the JOSE working group? These are really common > outside of the JOSE space for identifying keys because they have a greater > degree of uniqueness (even if one truncates them). > > Jim > > >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mit.edu] >> Sent: Wednesday, August 19, 2015 1:26 PM >> To: Jim Schaad; cose@ietf.org >> Subject: Re: [COSE] Question on Key Identifiers >> >> (Speaking as an individual) >> >> In my JOSE experience, the *only* KID values I have ever used in any >> deployments are simple strings. Usually with values like "rsa-1" and > "2015-08- >> 19" and the like. No binary encoded data, no thumbprints, no base64. >> >> As such, I don't see the purpose of a binary value in the first place. >> What if I'm using a JWK encoded key but a COSE-encoded token? How am I >> supposed to map the KID here: >> >> https://mitreid.org/jwk >> >> to my COSE object if it's binary? If the answer is "just encode the JSON > string as >> a binary", then I'm not sure what the binary actually buys us. >> >> -- Justin >> >> On 8/19/2015 3:37 PM, Jim Schaad wrote: >>> I have switched Key Identifiers from being a string (a base64 string >>> if it was binary) to being a binary value in all cases. As with JOSE >>> the internal structure of a KID is not defined or reliable. Is there >>> any reason to allow for KID values to be a text string as well as a >>> binary string? The only possible reason that I can think of is to >>> allow for readable KID values if one does a dump of a message. I >>> don't know that this is worth the flexibility. >>> >>> Is there anyone who wants to argue for allowing have text values for >>> KIDs that are not encoded as binary items? >>> >>> Jim >>> >>> >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose From nobody Wed Aug 19 14:18:39 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35C91B2B15 for ; Wed, 19 Aug 2015 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI0iPiwsWXOF for ; Wed, 19 Aug 2015 14:18:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D59B1B2B1E for ; Wed, 19 Aug 2015 14:18:34 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Wed, 19 Aug 2015 21:18:33 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0231.011; Wed, 19 Aug 2015 21:18:33 +0000 From: Mike Jones To: Justin Richer , Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Question on Key Identifiers Thread-Index: AdDatdSZJv5I+PAqTwCYbJ1sQvN/7gAB2AAAAABAOYAAAXLkAAAADJrQ Date: Wed, 19 Aug 2015 21:18:33 +0000 Message-ID: References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> <55D4E640.1000806@mit.edu> <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> <55D4F1A8.1050409@mit.edu> In-Reply-To: <55D4F1A8.1050409@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8::33c] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:IUX/oXvHYHZu+RYYmzAdUpA4n/qXXz0ZCByaDo7yjZdVHqUm72eHhjUQkmwdkHwZUu88ZCf5q4H1igCNn43KuSdXuLSff+SqqgTo25Y3L5/aAWkKdCAKd7XcG3SyU+tJt2+qqRhWg7lOCnZSfhKklw==; 24:uHADkR+LpVKK7tATPPqgPMa8aW/jAfQWQ8uIBwMM1JAdX9SuMstSodIBLIiz0aHCugPMwVLwI8piNQDUgOmo7UaTWznX1R4nD1cP/KLbTpA=; 20:XhzCNzJ7OwjPUulJUycLy1NjFHiC/UjxDgXbiQPeM+jWeDAOZMX4xXXvOQwpxDbtFtV5fP/BBya6ammP7jJR0w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(13464003)(24454002)(479174004)(99286002)(107886002)(97736004)(76176999)(2501003)(50986999)(54356999)(575784001)(2900100001)(86362001)(101416001)(87936001)(2171001)(5001960100002)(5007970100001)(189998001)(2950100001)(33656002)(5001860100001)(86612001)(105586002)(77156002)(92566002)(46102003)(81156007)(4001540100001)(15975445007)(68736005)(122556002)(8990500004)(5001830100001)(93886004)(64706001)(19580395003)(5003600100002)(10400500002)(10090500001)(106356001)(62966003)(102836002)(77096005)(19580405001)(5005710100001)(5001770100001)(76576001)(5002640100001)(40100003)(10290500002)(74316001)(2656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2015 21:18:33.4998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 21:18:38 -0000 Even if I do use the string key ID "1", there's a natural mapping of that s= tring, via UTF-8, to the binary key ID value [49]. In fact, we could recom= mend this mapping in the spec for key IDs that begin their life as strings. -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, August 19, 2015 2:14 PM To: Jim Schaad; cose@ietf.org Subject: Re: [COSE] Question on Key Identifiers (Again, as an individual). I honestly don't see people going to thumbprints in the COSE space. Your ar= gument of space efficiency assumes that I've got a big binary value that I = want to store in the KID. If I have a keystore with a handful of keys, it's= going to be much easier and more space efficient to tell my apps/devices/t= hings-of-the-internet "use key '1'" instead of "use key with the hash 'abcd= 2341'", because the latter is something they're going to have to compute th= emselves and compare. It would seem to me that most of these devices are go= ing to have a bucket of keys to test against that they'll be getting from c= ontext, either as pre-placed into the device at onboarding/configuration ti= me, or fetched over the network using a mechanism like jwks_uri is used in = JOSE-based protocols like OpenID Connect. This position is based (and biase= d) from my JOSE deployment experience, so take it with the appropriate salt= . In the end, I do think strings are a lot more flexible as an ID and I would= personally anticipate them being more common. I don't anticipate moving an= y of my JOSE-related things to using thumbprints, so I wouldn't expect to s= ee them enforced here in COSE. -- Justin On 8/19/2015 4:32 PM, Jim Schaad wrote: > For JOSE that is exactly what I would expect the experience to be, if=20 > for no other reason that that's what the examples were showing. Going=20 > to a binary value is a space consumption for JOSE because of the base64 e= ncoding. > > However, do you think that people might start using thumbprints with=20 > the new document coming out of the JOSE working group? These are=20 > really common outside of the JOSE space for identifying keys because=20 > they have a greater degree of uniqueness (even if one truncates them). > > Jim > > >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mit.edu] >> Sent: Wednesday, August 19, 2015 1:26 PM >> To: Jim Schaad; cose@ietf.org >> Subject: Re: [COSE] Question on Key Identifiers >> >> (Speaking as an individual) >> >> In my JOSE experience, the *only* KID values I have ever used in any=20 >> deployments are simple strings. Usually with values like "rsa-1" and > "2015-08- >> 19" and the like. No binary encoded data, no thumbprints, no base64. >> >> As such, I don't see the purpose of a binary value in the first place. >> What if I'm using a JWK encoded key but a COSE-encoded token? How am=20 >> I supposed to map the KID here: >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fmitr >> eid.org%2fjwk&data=3D01%7c01%7cMichael.Jones%40microsoft.com%7ca599a69b >> 5bfb4e9b9c6b08d2a8db2f2f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata >> =3D3wdnV1iQbIVRRb6N7s99e1Eo2b1wV2Yjxxk0wAJoLh8%3d >> >> to my COSE object if it's binary? If the answer is "just encode the=20 >> JSON > string as >> a binary", then I'm not sure what the binary actually buys us. >> >> -- Justin >> >> On 8/19/2015 3:37 PM, Jim Schaad wrote: >>> I have switched Key Identifiers from being a string (a base64 string=20 >>> if it was binary) to being a binary value in all cases. As with=20 >>> JOSE the internal structure of a KID is not defined or reliable. Is=20 >>> there any reason to allow for KID values to be a text string as well=20 >>> as a binary string? The only possible reason that I can think of is=20 >>> to allow for readable KID values if one does a dump of a message. I=20 >>> don't know that this is worth the flexibility. >>> >>> Is there anyone who wants to argue for allowing have text values for=20 >>> KIDs that are not encoded as binary items? >>> >>> Jim >>> >>> >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww >>> .ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%4 >>> 0microsoft.com%7ca599a69b5bfb4e9b9c6b08d2a8db2f2f%7c72f988bf86f141af >>> 91ab2d7cd011db47%7c1&sdata=3DmlyeJeT5e1SmN3%2bfHZnuxL0vu1v8fNaOcUEfdBx >>> GGxM%3d _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7ca599a69b5bfb4e9b9c6b08d2a8db2f2f%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3DmlyeJeT5e1SmN3%2bfHZnuxL0vu1v8fNaOcUEfdBxGGxM%3d From nobody Wed Aug 19 14:41:05 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C21B2B36 for ; Wed, 19 Aug 2015 14:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 659IkcFxgYVu for ; Wed, 19 Aug 2015 14:41:03 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B70A1B2B22 for ; Wed, 19 Aug 2015 14:41:03 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id EB88938F15; Wed, 19 Aug 2015 14:41:02 -0700 (PDT) From: "Jim Schaad" To: "'Justin Richer'" , References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> <55D4E640.1000806@mit.edu> <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> <55D4F1A8.1050409@mit.edu> In-Reply-To: <55D4F1A8.1050409@mit.edu> Date: Wed, 19 Aug 2015 14:41:24 -0700 Message-ID: <00bf01d0dac7$cc52f440$64f8dcc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIPnNG6hLSiKCXNqJBHdsIjfpOVvgIXOLhOAagkZKgCK2WIXZ1m/Dhg Content-Language: en-us Archived-At: Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 21:41:05 -0000 > -----Original Message----- > From: Justin Richer [mailto:jricher@mit.edu] > Sent: Wednesday, August 19, 2015 2:14 PM > To: Jim Schaad; cose@ietf.org > Subject: Re: [COSE] Question on Key Identifiers > > (Again, as an individual). > > I honestly don't see people going to thumbprints in the COSE space. Your > argument of space efficiency assumes that I've got a big binary value that I want > to store in the KID. If I have a keystore with a handful of keys, it's going to be > much easier and more space efficient to tell my apps/devices/things-of-the- > internet "use key '1'" instead of "use key with the hash 'abcd2341'", because the > latter is something they're going to have to compute themselves and compare. No, you are operating under a misconception of how things are going to work. The thumbprint is computed once, by the person who generates the key and it is placed in the key id field. From that point on things are going to work the same way as they would if you used the string "use key 1". If you needed to recomputed the thumbprint then it would be necessary to know the format of the data to be encoded and the hash being used. This is strictly a function of the creator of the initial identifier. jim > It would seem to me that most of these devices are going to have a bucket of > keys to test against that they'll be getting from context, either as pre-placed into > the device at onboarding/configuration time, or fetched over the network using > a mechanism like jwks_uri is used in JOSE-based protocols like OpenID Connect. > This position is based (and biased) from my JOSE deployment experience, so take > it with the appropriate salt. > > In the end, I do think strings are a lot more flexible as an ID and I would > personally anticipate them being more common. I don't anticipate moving any > of my JOSE-related things to using thumbprints, so I wouldn't expect to see them > enforced here in COSE. > > -- Justin > > > On 8/19/2015 4:32 PM, Jim Schaad wrote: > > For JOSE that is exactly what I would expect the experience to be, if > > for no other reason that that's what the examples were showing. Going > > to a binary value is a space consumption for JOSE because of the base64 > encoding. > > > > However, do you think that people might start using thumbprints with > > the new document coming out of the JOSE working group? These are > > really common outside of the JOSE space for identifying keys because > > they have a greater degree of uniqueness (even if one truncates them). > > > > Jim > > > > > >> -----Original Message----- > >> From: Justin Richer [mailto:jricher@mit.edu] > >> Sent: Wednesday, August 19, 2015 1:26 PM > >> To: Jim Schaad; cose@ietf.org > >> Subject: Re: [COSE] Question on Key Identifiers > >> > >> (Speaking as an individual) > >> > >> In my JOSE experience, the *only* KID values I have ever used in any > >> deployments are simple strings. Usually with values like "rsa-1" and > > "2015-08- > >> 19" and the like. No binary encoded data, no thumbprints, no base64. > >> > >> As such, I don't see the purpose of a binary value in the first place. > >> What if I'm using a JWK encoded key but a COSE-encoded token? How am > >> I supposed to map the KID here: > >> > >> https://mitreid.org/jwk > >> > >> to my COSE object if it's binary? If the answer is "just encode the > >> JSON > > string as > >> a binary", then I'm not sure what the binary actually buys us. > >> > >> -- Justin > >> > >> On 8/19/2015 3:37 PM, Jim Schaad wrote: > >>> I have switched Key Identifiers from being a string (a base64 string > >>> if it was binary) to being a binary value in all cases. As with > >>> JOSE the internal structure of a KID is not defined or reliable. Is > >>> there any reason to allow for KID values to be a text string as well > >>> as a binary string? The only possible reason that I can think of is > >>> to allow for readable KID values if one does a dump of a message. I > >>> don't know that this is worth the flexibility. > >>> > >>> Is there anyone who wants to argue for allowing have text values for > >>> KIDs that are not encoded as binary items? > >>> > >>> Jim > >>> > >>> > >>> _______________________________________________ > >>> COSE mailing list > >>> COSE@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cose From nobody Thu Aug 20 21:35:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533501A6FF2 for ; Thu, 20 Aug 2015 21:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5IuOOu4IJug for ; Thu, 20 Aug 2015 21:35:43 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29031A6FF8 for ; Thu, 20 Aug 2015 21:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0A8B5E2034; Fri, 21 Aug 2015 00:35:41 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00865-06; Fri, 21 Aug 2015 00:35:38 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-204.IHTFP.ORG [192.168.248.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 83917E2035; Fri, 21 Aug 2015 00:35:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1440131738; bh=4Uwr07k8LOGTWGjKtOQChY8+taZI8tL4+lM0w2MDQ9k=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=lp6yycpbn42FtLW9r2xjHRUZfE/bX8snid0ukH4ZiZzieaP9dEIE0BoYIiUFv3OLb EAxrUU1yydK+7h0QVi7ReWaLBWe1WNbgh3YZDzIeRj3JMkyeySbLfRkP0FivzvXxsG LRfrAz6FvcNBnMgbhGQa+i5ZCRmQl42xdBsdeZ8M= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7L2AWiS002875; Thu, 20 Aug 2015 22:10:32 -0400 From: Derek Atkins To: "Jim Schaad" References: <00a101d0dab6$7cbabbe0$763033a0$@augustcellars.com> <55D4E640.1000806@mit.edu> <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> Date: Thu, 20 Aug 2015 22:10:32 -0400 In-Reply-To: <00b101d0dabe$363886e0$a2a994a0$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Aug 2015 13:32:47 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: 'Justin Richer' , cose@ietf.org Subject: Re: [COSE] Question on Key Identifiers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 04:35:44 -0000 Jim, "Jim Schaad" writes: > For JOSE that is exactly what I would expect the experience to be, if for no > other reason that that's what the examples were showing. Going to a binary > value is a space consumption for JOSE because of the base64 encoding. > > However, do you think that people might start using thumbprints with the new > document coming out of the JOSE working group? These are really common > outside of the JOSE space for identifying keys because they have a greater > degree of uniqueness (even if one truncates them). In my implementation/use of COSE we plan to use a PGP Fingerprints as KIDs. We expect to use the binary form, not a printable string. > Jim -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 26 12:27:23 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9948F1A1B5A for ; Wed, 26 Aug 2015 12:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiX6ic7pvHrc for ; Wed, 26 Aug 2015 12:27:16 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 1AB0A1A88C7 for ; Wed, 26 Aug 2015 12:27:15 -0700 (PDT) Received: by wicja10 with SMTP id ja10so24565176wic.1 for ; Wed, 26 Aug 2015 12:27:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2ttmug5YXSUCkaM31QyyvxfoCaoHAfQrKX6Yq5VABoE=; b=TdiGZcwjsaYJ9nm3krBuNNGTzyw3/9vg/kOWGqaPKGGbEyV3EluWCmWwZJw7+09lU9 D78USt5qdxxtjAgep427n6EfgSJyMVIpioS3KX4XvKYdJDByLd+89eAnqlsJok963vzv 1F9WJx6Bo+6lsMaeKQtK2cXdtcbdzXmd2WFyyWoumhXl4sXBMwxH43+uR3CT1dw7PeRG VZb7BD507+MF8eObYw/djkkAWAnO5e/iQnEy3oJ+PJSLKm4hKCqVDLZoajF8H/Hywwyq xxEvaLlP/US5zLoWXZoSjbjiPocJvCnDOfTcwrfPpXR/o9qHgve3JiHuuIOPi/wZn+ws Cw+g== X-Gm-Message-State: ALoCoQmKxNF0FyLGg54fsNSkfdEI6XRYdqH/aRrx7uI7npN4+nVaUlUp10qYCnWitl7lKNidZFSD MIME-Version: 1.0 X-Received: by 10.180.24.3 with SMTP id q3mr6314618wif.24.1440617234406; Wed, 26 Aug 2015 12:27:14 -0700 (PDT) Received: by 10.28.56.136 with HTTP; Wed, 26 Aug 2015 12:27:14 -0700 (PDT) In-Reply-To: <0a9a01d0d164$3efbd290$bcf377b0$@augustcellars.com> References: <0a9a01d0d164$3efbd290$bcf377b0$@augustcellars.com> Date: Wed, 26 Aug 2015 21:27:14 +0200 Message-ID: From: Samuel Erdtman To: Jim Schaad Content-Type: multipart/alternative; boundary=f46d043be1dc83b224051e3bd6de Archived-At: Cc: Brian Campbell , cose Subject: Re: [COSE] Key Identification Headers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 19:27:20 -0000 --f46d043be1dc83b224051e3bd6de Content-Type: text/plain; charset=UTF-8 Hi, I come for the PKI side of things and like the idea that the device trusts one or several roots and then the connecting entity provides the chain to one of the trusted root(s) when sending a signed message, giving the benefit that no lookup is needed or no big tables with trusted keys etc. With that said I can see that the messages will grow a lot when adding the x509 chain and to validate the chain several asymmetric crypto operations would be needed so the devices that would benefit of the simplified provisioning with just a trust anchor would need to handel the larger message and do several crypto operations, i.e. it might just as well be able to handle JOSE. With that said I think having the option to send the chain is good, but I can see the problems also so if no one else wants it will will not push for it. Best Regards Samuel Erdtman On Sat, Aug 8, 2015 at 12:56 AM, Jim Schaad wrote: > I have been holding off on giving my opinion to let others have first > crack at this issue. Since there does not seem to be anyone who cares > about these issues I will give my opinion and we will see where things fall > out. > > > > I completely agree that key id is needed. That is why it is the one of > these methods that I put into the core document and assigned an integer > value for. > > > > Until a group of people come to the working group and say that they have a > need to have X.509 certificates as a basis for trust, it is not clear to me > that there is any need to support any of the X.509 certificate > identification methods. Even then, there is the ability to use the key id > field to match against the subject key identifier field in a certificate so > we are not leaving them completely hanging in the wind. > > > > I was never happy with the idea of using URLs to fetch keys for many of > the reasons that Brian states below. This is one of the reasons why I was > pressing for language in the JOSE documents that discussed the ideas of > binding identify to a key retrieved from a URL as being problematic. I > would be happy not to support this key fetching method. > > > > I have an, admittedly small, degree of sympathy for allowing the key to be > carried in the message. Doing some has some issues about the size of the > data that is transmitted. However, the key is going to be a far more > unique value than a key identifier field is for matching against in a > database. I currently have defined a version of carrying the key for doing > static-static DH. It is easier to say compare the key against a trust > database than it is to say compare one of the other fields (i.e. URL). > However, I would expect that this would not be used much and that key > identifier is going to be the 99% case of key identification. I can live > with this option either being present or absent in the specification. > > > > jim > > > > *From:* COSE [mailto:cose-bounces@ietf.org] *On Behalf Of *Brian Campbell > *Sent:* Tuesday, August 04, 2015 12:54 PM > *To:* cose@ietf.org > *Subject:* [COSE] Key Identification Headers > > > > JOSE has seven different headers aimed at helping the message recipient > identity the key to use to verify or decrypt the message. They are "jku", > "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" and are discussed in JWS > http://tools.ietf.org/html/rfc7515#section-4.1 and JWE > http://tools.ietf.org/html/rfc7516#section-4.1 > > Personally, I've always felt that JOSE had too many key hinting/signaling > headers and my implementation experience has only solidified that belief. > > I don't think there's any question that COSE should have a Key ID header > that serves a purpose similar to JOSE's Key ID/"kid" header. This message > is intended to try and coerce the WG towards some consensus about what > other key hinting headers to include in the main COSE specification. What > follows is a somewhat brief discussion of each of the JOSE headers and > their potential applicability to COSE. Long story short, I propose that > COSE have significantly fewer key hinting/signaling headers. Perhaps going > as far as only having a Key ID header. > > Parameters like "jku" and "x5u", which encourage implementations to > blindly retrieve remote content seem ripe for security problems ranging > from resource consumption attacks to inadvertently trusting verification > keys that shouldn't be trusted. They are also not particularly space > efficient and (as defined for JOSE anyway) are for HTTPS URIs only. In > practice with JOSE I've seen many applications which use a JWK Set > available at an HTTPS URI, however, the URI is determined some other way > (out of band agreement, metadata exchange, etc.) and never carried in the > message. I propose that COSE not port over the "jku" or "x5u" message > headers and also not attempt to define a COSE key URI style equivalent > header. > > Porting the "jwk" message header directly to carry a JWK in a COSE message > doesn't really make sense and I'd propose that COSE not try to define a > similar header to carry a COSE_Key. The full key is not a space efficient > way to signal the key (as apposed to a key id or hash, for example) and > adds risk that an implementation might accept a message with a such a key > without proper trust decision or binding of the key to an identity of a > trusted sender. > > A header to carry a X.509 Certificate or Chain (like "x5c" in JOSE) does > potentially seem useful to carry a key that is bound to some identity via > the certificate(s). However, it may not be particularly appropriate or > useful in the constrained word due to the size overhead it adds to a > message. It's also really only meaningful for signed message so probably > wouldn't be appropriate to be defined as a top level header. I'd like to > know if folks in the WG feel strongly (more than just a speculative feeling > that it might be useful) that such a header is needed. I'm inclined to say > that COSE would be better off without. > > Does COSE need header(s) to convey the certificate fingerprint/thumbprint? > JOSE has two - "x5t" and "x5t#S256". As an implementer, I sure would have > preferred that there was only one. Or even none. While a thumbprint does > inherently convey some additional semantics over a key ID alone, a key ID > can certainly carry a thumbprint. I imagine that most deployments will need > to come to agreement about how keys will be singled anyway. So agreeing > that, in the situations that want to do it, the key ID can carry a > certificate thumbprint value seems no more cumbersome than agreeing to use > a more specific header for the same purpose. This is another one where I'd > like to hear if folks in the WG feel strongly that a certificate > fingerprint/thumbprint header is needed in COSE. If so, it'd be really nice > if we could land on a single header for it rather than two. Perhaps a > truncated SHA-256 could be a little bit more space efficient while avoiding > SHA1. > > > > > > > > > > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --f46d043be1dc83b224051e3bd6de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I come for the PKI side of things a= nd like the idea that the device trusts one or several roots and then the c= onnecting entity provides the chain to one of the trusted root(s) when send= ing a signed message, giving the benefit that no lookup is needed or no big= tables with trusted keys etc. With that said I can see that the messages w= ill grow a lot when adding the x509 chain and to validate the chain several= asymmetric crypto operations would be needed so the devices that would ben= efit of the simplified provisioning with just a trust anchor would need to = handel the larger message and do several crypto operations, i.e. it might j= ust as well be able to handle JOSE.

With that said= I think having the option to send the chain is good, but I can see the pro= blems also so if no one else wants it will will not push for it.
=
Best Regards
Samuel Erdtman



On Sat, Aug 8, 2015 at 12:56 AM, Jim Schaad <ietf@augustcellars.com= > wrote:

I have been holding off on giving my opinion to let others hav= e first crack at this issue.=C2=A0 Since there does not seem to be anyone w= ho cares about these issues I will give my opinion and we will see where th= ings fall out.

=C2=A0

I completely agree that key id is needed.=C2=A0 That = is why it is the one of these methods that I put into the core document and= assigned an integer value for.

=C2=A0

Until a group of people come to the wo= rking group and say that they have a need to have X.509 certificates as a b= asis for trust, it is not clear to me that there is any need to support any= of the X.509 certificate identification methods.=C2=A0 Even then, there is= the ability to use the key id field to match against the subject key ident= ifier field in a certificate so we are not leaving them completely hanging = in the wind.

=C2=A0

I was never happy with the idea of using URLs to fetch ke= ys for many of the reasons that Brian states below.=C2=A0 This is one of th= e reasons why I was pressing for language in the JOSE documents that discus= sed the ideas of binding identify to a key retrieved from a URL as being pr= oblematic.=C2=A0 I would be happy not to support this key fetching method.<= u>

<= u>=C2=A0

I have an, admittedly small, degree of sympathy for allowing the key t= o be carried in the message.=C2=A0 Doing some has some issues about the siz= e of the data that is transmitted.=C2=A0 However, the key is going to be a = far more unique value than a key identifier field is for matching against i= n a database.=C2=A0 I currently have defined a version of carrying the key = for doing static-static DH. It is easier to say compare the key against a t= rust database than it is to say compare one of the other fields (i.e. URL).= =C2=A0 However, I would expect that this would not be used much and that ke= y identifier is going to be the 99% case of key identification.=C2=A0=C2=A0= I can live with this option either being present or absent in the specific= ation.

=C2=A0

jim

=C2=A0

From: COSE [mailto:= cose-bounces@iet= f.org] On Behalf Of Brian Campbell
Sent: Tuesday, Augu= st 04, 2015 12:54 PM
To: cose@ietf.org
Subject: [COSE] Key Identification = Headers

=C2=A0

JOSE has seven different headers aimed at = helping the message recipient identity the key to use to verify or decrypt = the message. They are "jku", "jwk", "kid", &q= uot;x5u", "x5c", "x5t", and "x5t#S256" a= nd are discussed in JWS http://tools.ietf.org/html/rfc7515#section-4.1 and JWE http://tools.ietf.org/html/rfc7516#section-4.1

Perso= nally, I've always felt that JOSE had too many key hinting/signaling he= aders and my implementation experience has only solidified that belief.
I don't think there's any question that COSE should have a Key= ID header that serves a purpose similar to JOSE's Key ID/"kid&quo= t; header. This message is intended to try and coerce the WG towards some c= onsensus about what other key hinting headers to include in the main COSE s= pecification. What follows is a somewhat brief discussion of each of the JO= SE headers and their potential applicability to COSE. Long story short, I p= ropose that COSE have significantly fewer key hinting/signaling headers. Pe= rhaps going as far as only having a Key ID header.

Parameters like &= quot;jku" and "x5u", which encourage implementations to blin= dly retrieve remote content seem ripe for security problems ranging from re= source consumption attacks=C2=A0 to inadvertently trusting verification key= s that shouldn't be trusted. They are also not particularly space effic= ient and (as defined for JOSE anyway) are for HTTPS URIs only. In practice = with JOSE I've seen many applications which use a JWK Set available at = an HTTPS URI, however, the URI is determined some other way (out of band ag= reement, metadata exchange, etc.) and never carried in the message.=C2=A0 I= propose that COSE not port over the "jku" or "x5u" mes= sage headers and also not attempt to define a COSE key URI style equivalent= header.

Porting the "jwk" message header directly to car= ry a JWK in a COSE message doesn't really make sense and I'd propos= e that COSE not try to define a similar header to carry a COSE_Key. The ful= l key is not a space efficient way to signal the key (as apposed to a key i= d or hash, for example) and adds risk that an implementation might accept a= message with a such a key without proper trust decision or binding of the = key to an identity of a trusted sender.

A header to carry a X.509 C= ertificate or Chain (like "x5c" in JOSE) does potentially seem us= eful to carry a key that is bound to some identity via the certificate(s). = However, it may not be particularly appropriate or useful in the constraine= d word due to the size overhead it adds to a message. It's also really = only meaningful for signed message so probably wouldn't be appropriate = to be defined as a top level header. I'd like to know if folks in the W= G feel strongly (more than just a speculative feeling that it might be usef= ul) that such a header is needed. I'm inclined to say that COSE would b= e better off without.

Does COSE need header(s) to convey the certifi= cate fingerprint/thumbprint? JOSE has two - "x5t" and "x5t#S= 256".=C2=A0 As an implementer, I sure would have preferred that there = was only one. Or even none. While a thumbprint does inherently convey some = additional semantics over a key ID alone, a key ID can certainly carry a th= umbprint. I imagine that most deployments will need to come to agreement ab= out how keys will be singled anyway. So agreeing that, in the situations th= at want to do it, the key ID can carry a certificate thumbprint value seems= no more cumbersome than agreeing to use a more specific header for the sam= e purpose. This is another one where I'd like to hear if folks in the W= G feel strongly that a certificate fingerprint/thumbprint header is needed = in COSE. If so, it'd be really nice if we could land on a single header= for it rather than two. Perhaps a truncated SHA-256 could be a little bit = more space efficient while avoiding SHA1.

=C2=A0



=C2=A0

=




=C2=A0


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


--f46d043be1dc83b224051e3bd6de-- From nobody Thu Aug 27 09:22:42 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DC11A0140 for ; Thu, 27 Aug 2015 09:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLP5MyqH5sps for ; Thu, 27 Aug 2015 09:22:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195061A1B1D for ; Thu, 27 Aug 2015 09:22:40 -0700 (PDT) Received: from [192.168.131.140] ([80.92.121.239]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MGBdv-1ZXQXB14PX-00FCvb for ; Thu, 27 Aug 2015 18:22:38 +0200 Message-ID: <55DF394D.1020403@gmx.net> Date: Thu, 27 Aug 2015 18:22:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "cose@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5mAmimIterCfRfRtHp3FbdCbrfQHm7JjG" X-Provags-ID: V03:K0:F+ntsRthV6kU+jM8+JsgfPCOv0zaJPmkI+9twieW8hMdyIRzSO2 E+Gg/c/OC+XRTMEf/ZGmIGTiN4ixtMtaeBg7SNkJdLAqoo/63PPJoMfXSLrdsF8hCozekaq 3v7RyuZPfKxt1PMbNwaZT7ojM3YlivzzBFn+E+coD+aIkvkz47F4/aSn8JYyewvAyS7MwL4 zaU3Gb/CRdw0xvN2lPJQw== X-UI-Out-Filterresults: notjunk:1;V01:K0:aiVM3R2on1U=:eWdDtC3VfJQ9eiK+aySvIX c42jV5Rk+FvWbsfkkbiHTIVCaz+jrtSLL9du50KWZHBo1i6/B5BLKfLaMhY4YLTCcQchQlAjV dTyLMqOgHosXpvP2XfENWFpAEK4k9ls9qpDoKx7K29xbJ/aTbaIHbYUeTCuUly6W6mpyYdOLe fkq3y8zZNWge1BM8gbPycyFGLK5KMYqDNOTJabQVcyqEaPgHjLzu925m0C1cfwnMdMiBaCe4W oeq0TibBKD4Q7QtNtC/+KKuwzjqaSkte73/0WzFZgrwG++jrpHntwBlRXpm0oi9+3PiMDj8B0 84woX4CBP5i2hZ6Jx/IJnl9q2Wv8Hqd7qJeuFLo0Z/ifikukeTVBA4OiE79W9P1K5mBdntT7y TwHsB/ycqVl96hvYCxw7sjf9Em8Ie+Jq2SjMy6FPywCsmz4vuM7JdLdFt0lZVPaTSNwHv417c 8Hmw6GRBvYY0UE+Wxq0D9CFUeXM92CT31AKw6bPJ64bH0zuwYr/ygE6Ijp4w9AJlYTvOi9bIf DuOap2W8q8OXQFItz+IoFuCsGrTjICgoLbQa/Kt76nckWsvmajsOUMlw2fQ1BnjsjOWk44ls+ D9UFqasomUWqhmD8meLkbtIFPCDKl/JUUdMr+WWW/uu3dypu8kdUG4XoB84AoUAN8Uf2nmw/1 muGBu04aQ81ZKNPTrHz1OEmUK4HpLuNPwuVIcp4jSk3XCMZ3WhkApWRUnROMtbwOLxLTQD6WG /EF59tAYCqPTCx9e Archived-At: Subject: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 16:22:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5mAmimIterCfRfRtHp3FbdCbrfQHm7JjG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Hi all, out of curiosity I have been reading through the latest version of the COSE draft and ran into a few questions. * MTI Section 1.6 is supposed to define mandatory-to-implement algorithms but actually doesn't say what those are. I personally don't believe it is useful to define MTI algorithms for such a document that will most likely be used in a variety of different environments. I would nevertheless be interested to know what the MTI algorithms should be (from your point of view). * Examples As most people I also look at the examples first and would have appreciated a bit more explanation. So, help me understand them. Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the 'direct shared secret' means that the sender of the message and the receiver share a symmetric key. What does "File name: Mac-04" mean? Just to make sure that I understand the structure correctly I added comments inline: { 1: 3, --> msg_type is COSE_mac 2: h'a1016f4145532d434d41432d3235362f3634', --> protected header fields When I use a CBOR decoder I get the value of '"\xA1\x01oAES-CMAC-256/64". Is that really the encoding for the algorithm id? 4: h'546869732069732074686520636f6e74656e742e', --> payload of the string "This is the content." 10: h'd9afa663dd740848', --> tag which contains the MAC value. 9: [ --> recipients { 3: { 1: -6, 4: h'6f75722d736563726574' } } ] } Section 6 talks about recipients and says: " recipients contains the recipient information. See the description under COSE_Encryption for more info. " When I look for more info in Section 5 then I do not find a lot. Why is the field mandatory? What is the meaning of it in this example? For an IoT context I would imagine that the algorithm and the key has been agreed between the sender and the receiver using some key management protocol and the appropriate example would be something like: { 1: 3, 2: {4: 1,6: 1}, 4: "This is the content.", 10: h'd9afa663dd740848' } (Note that I don't really know whether this is the encoding you envision for the header parameters.) Minor issues: * You write: "CBOR extended the data model of the JavaScript Object Notation (JSON) by allowing for binary data among other changes." Is 'data model' the right term here? I think we are talking about encodin= g. For a more detailed treatment of what a data model is take a look at RFC 3444. * You write: " o The author did not always agree with some of the decisions made by the JOSE working group. Many of these decisions have been re- examined, and where it seems to the author to be superior or simpler, replaced. " For a working group draft it does not matter whether the author agrees or disagrees. I would suggest to remove this paragraph. * SMIME/CMS I would remove references to CMS and S/MIME since they are most likely only helpful to a very small audience. Ciao Hannes --5mAmimIterCfRfRtHp3FbdCbrfQHm7JjG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV3zlNAAoJEGhJURNOOiAtrNMH/1OCY2c+WshBZz/XgGA29Jur Jl3cj9MKS5Ea+IMtnaEYcY1ZUafKVHUU+WCqqv19iLi9hKF2D8mIcz8ZEqhDzwrP YXqg5EnRnQ4wKjyUifzWkhvW2vuBHXULBv21bIwCCikt52NSGKkemYe7lGiQ6x5k T1hmDMJyiavPTEHvn3L0TguVUnWmiONrOXNuKHTJIU9SRxM4AInlv5WlME8HbBoB km2MAbSgAEbSyCOIt27PPuF/pDAASFBKlS1yu0h+ojOby6pNbxHn7Upk5zkeICL1 d47tOjQg1l5PXxqvGvlk8LTyTLeyXSZmTYsgIxdIMEV7SOO+sGgd2JpEhAcGViM= =/J4p -----END PGP SIGNATURE----- --5mAmimIterCfRfRtHp3FbdCbrfQHm7JjG-- From nobody Thu Aug 27 10:15:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D51B1B3C03 for ; Thu, 27 Aug 2015 10:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ziPZOHMUD2v for ; Thu, 27 Aug 2015 10:15:18 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCB31B3BF8 for ; Thu, 27 Aug 2015 10:15:18 -0700 (PDT) X-AuditID: 1209190f-f79716d000002ea2-b6-55df45a49d1e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id EE.B1.11938.4A54FD55; Thu, 27 Aug 2015 13:15:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t7RHFG9o000830; Thu, 27 Aug 2015 13:15:16 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7RHFEEl022597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Aug 2015 13:15:15 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_58B07731-B1C1-4152-9EA6-6A222C797721"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.1 From: Justin Richer In-Reply-To: <55DF394D.1020403@gmx.net> Date: Thu, 27 Aug 2015 13:15:12 -0400 Message-Id: <1BD52CEB-9D32-4AA7-8E5D-DCD60589BE83@mit.edu> References: <55DF394D.1020403@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsUixG6nrrvE9X6owbdmc4tpW6eyWizdeY/V gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp41X6NueCBRsWChuvsDYwNCl2MnBwSAiYS e+Z8YYSwxSQu3FvP1sXIxSEksJhJ4sGLu1DORkaJnobpLCBVQgIPmSRuTDHtYuTgEBYwl7i0 UwokzCugJ/Hq1mVWkHpmgSmMEo1HlrKD1EgISEms+KAMUsMmoCoxfU0LE4jNKaAu8eDgYTYQ mwUofm5lO1icWUBZ4t/fyUwQM60k+nbcYYRYqyZxf/EmsHoRAUOJ6zOns0IcLSux+/cjpgmM grOQnDEL2RmzwOZqSyxb+JoZwtaU2N+9nAXClpfY/nYOVNxSYvHMG1BxW4lbfQuYIGw7iUfT FrEuYORYxSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZopeaUrqJERQ5nJL8Oxi/HVQ6xCjA wajEw7sj7l6oEGtiWXFl7iFGSQ4mJVHeCrv7oUJ8SfkplRmJxRnxRaU5qcWHGFWAdj3asPoC oxRLXn5eqpIIb7ohUB1vSmJlVWpRPkyZNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQne VBegRsGi1PTUirTMnBKENBMH5yFGCQ4eoOGWIDW8xQWJucWZ6RD5U4yKUuK8x0ESAiCJjNI8 uF5YwnvFKA70ljCvBUgVDzBZwnW/AhrMBDT4ZfxdkMEliQgpqQZGqUvBkSqO4UxixmciN/n1 qxoqfwi7XmTsH1L3JnPSadkTGxYKl4vaphm1LGMxSLVT1Xj1TlUlfVPYCo6GyxbL7kULber4 56BpXPDqt5lEX45Qx0JOGb93m5fe49z9/enS1p2KzCabzuTLTnASeJB6uOG8U/GeR5uNlPdJ fNveenSe2LqXIp+UWIozEg21mIuKEwF0dKaVUwMAAA== Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:15:20 -0000 --Apple-Mail=_58B07731-B1C1-4152-9EA6-6A222C797721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking as chair: > * You write: > " > o The author did not always agree with some of the decisions made = by > the JOSE working group. Many of these decisions have been re- > examined, and where it seems to the author to be superior or > simpler, replaced. > " >=20 > For a working group draft it does not matter whether the author agrees > or disagrees. I would suggest to remove this paragraph. I agree with Hannes, this kind of text has no business in a working = group draft. Jim, please remove it in the next draft. (I=E2=80=99ll file = an issue in a moment.) =E2=80=94 Justin > On Aug 27, 2015, at 12:22 PM, Hannes Tschofenig = wrote: >=20 > Hi Jim, Hi all, >=20 > out of curiosity I have been reading through the latest version of the > COSE draft and ran into a few questions. >=20 > * MTI >=20 > Section 1.6 is supposed to define mandatory-to-implement algorithms = but > actually doesn't say what those are. >=20 > I personally don't believe it is useful to define MTI algorithms for > such a document that will most likely be used in a variety of = different > environments. I would nevertheless be interested to know what the MTI > algorithms should be (from your point of view). >=20 > * Examples >=20 > As most people I also look at the examples first and would have > appreciated a bit more explanation. So, help me understand them. >=20 > Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the > 'direct shared secret' means that the sender of the message and the > receiver share a symmetric key. >=20 > What does "File name: Mac-04" mean? >=20 > Just to make sure that I understand the structure correctly I added > comments inline: >=20 > { > 1: 3, --> msg_type is COSE_mac > 2: h'a1016f4145532d434d41432d3235362f3634', >=20 > --> protected header fields > When I use a CBOR decoder I get the value of > '"\xA1\x01oAES-CMAC-256/64". > Is that really the encoding for the algorithm id? >=20 > 4: h'546869732069732074686520636f6e74656e742e', > --> payload of the string "This is the content." >=20 > 10: h'd9afa663dd740848', --> tag which contains the MAC value. > 9: [ --> recipients > { > 3: { > 1: -6, > 4: h'6f75722d736563726574' > } > } > ] > } >=20 > Section 6 talks about recipients and says: >=20 > " > recipients contains the recipient information. See the description > under COSE_Encryption for more info. > " >=20 > When I look for more info in Section 5 then I do not find a lot. > Why is the field mandatory? What is the meaning of it in this example? >=20 > For an IoT context I would imagine that the algorithm and the key has > been agreed between the sender and the receiver using some key > management protocol and the appropriate example would be something = like: >=20 > { > 1: 3, > 2: {4: 1,6: 1}, > 4: "This is the content.", > 10: h'd9afa663dd740848' > } >=20 > (Note that I don't really know whether this is the encoding you = envision > for the header parameters.) >=20 > Minor issues: >=20 > * You write: "CBOR extended the data model of the JavaScript Object > Notation (JSON) by allowing for binary data among other changes." >=20 > Is 'data model' the right term here? I think we are talking about = encoding. > For a more detailed treatment of what a data model is take a look at = RFC > 3444. >=20 > * You write: > " > o The author did not always agree with some of the decisions made = by > the JOSE working group. Many of these decisions have been re- > examined, and where it seems to the author to be superior or > simpler, replaced. > " >=20 > For a working group draft it does not matter whether the author agrees > or disagrees. I would suggest to remove this paragraph. >=20 >=20 > * SMIME/CMS >=20 > I would remove references to CMS and S/MIME since they are most likely > only helpful to a very small audience. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_58B07731-B1C1-4152-9EA6-6A222C797721 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJV30WhAAoJEDPAngkbd+w9vn8H/19ekPdhfV9mbzMrR7KRE3AX cR513TDF9mW2dYmwTa4h7ASIND9eRUstmNhGWVvo1UgnRRJPaoSMroSTRPRopPrK hF+NDgb+DA0rvzBNTO/YlDm9iJOY7fdBo1wz8P9W0RVi4+pklVfaoqKFvO/84H9M AJn4FATrBDc8mGDQ/UQVEUoz30yUlvIgVvGiZ/j+pJl+ZYNzCuBc6e/Gfgc8Xwmh q8kaHvahJq1aB6LNPNrKQmZRCTyKod4+bN8EnLGz/8SjTYAMCLIp1l0ArGhDGXzR JLb011qYT9krnBoNke8tioDmI+Gzh9UNRJ6TqHgZNL+AP4YmUIGkZR4BfGabjcs= =qd8h -----END PGP SIGNATURE----- --Apple-Mail=_58B07731-B1C1-4152-9EA6-6A222C797721-- From nobody Thu Aug 27 10:16:51 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA561B3C45 for ; Thu, 27 Aug 2015 10:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usfnt42xDEsu for ; Thu, 27 Aug 2015 10:16:48 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF791B3C27 for ; Thu, 27 Aug 2015 10:16:48 -0700 (PDT) Date: Thu, 27 Aug 2015 10:16:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1440695806; bh=AaPOz+rjWYm2lYxhaKN5vY1bSMim3MZF/bkzLrR2jF8=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=w90hcXTusCKSH37YBlaJ4e06MVhcH5YFduGF+3PVCkKK1w2z43QpGMQc4oaTBv95Y 0HQ2HKysmp0m6mz/frLnR370ZV8HwSKJjmUSxwdzRfm7xPFwGfZv/wy/RdQCyR6tAu dydnNBTbx61GrAYX/mqWxCqDRh4couwO9PztZQTY= From: Justin Richer To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55df45fe7fd82_3c713fe40e1752a0120550"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Remove JOSE commentary (#7) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:16:50 -0000 ----==_mimepart_55df45fe7fd82_3c713fe40e1752a0120550 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The current draft contains the text: The author did not always agree with some of the decisions made by the JOSE working group. Many of these decisions have been re- examined, and where it seems to the author to be superior or simpler, replaced. The COSE working group is not about "fixing JOSE" in retrospect. This paragraph needs to be removed. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/7 ----==_mimepart_55df45fe7fd82_3c713fe40e1752a0120550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

The current draft contains the text:

The author did not always agree with some of the decisions made by
 the JOSE working group.  Many of these decisions have been re-
 examined, and where it seems to the author to be superior or
 simpler, replaced.

The COSE working group is not about "fixing JOSE" in retrospect. This paragraph needs to be removed.

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

----==_mimepart_55df45fe7fd82_3c713fe40e1752a0120550-- From nobody Thu Aug 27 13:39:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256D71A8733 for ; Thu, 27 Aug 2015 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K1CdOsQ4LEM for ; Thu, 27 Aug 2015 13:39:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99D31A874D for ; Thu, 27 Aug 2015 13:39:14 -0700 (PDT) Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CF1602CA08; Thu, 27 Aug 2015 13:39:13 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55DF394D.1020403@gmx.net> In-Reply-To: <55DF394D.1020403@gmx.net> Date: Thu, 27 Aug 2015 13:37:04 -0700 Message-ID: <013201d0e108$2325eb60$6971c220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJn36g0b++GHPEUf65M22awuFXax5zyRuGw Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:39:17 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Thursday, August 27, 2015 9:23 AM > To: cose@ietf.org > Subject: [COSE] Comments for draft-ietf-cose-msg-03 >=20 > Hi Jim, Hi all, >=20 > out of curiosity I have been reading through the latest version of the = COSE draft > and ran into a few questions. You might also look at the WIP draft on github as it has a change from = using maps to arrays at the top level. This makes the code slightly = different and provides a small decrease in message sizes. >=20 > * MTI >=20 > Section 1.6 is supposed to define mandatory-to-implement algorithms = but > actually doesn't say what those are. >=20 > I personally don't believe it is useful to define MTI algorithms for = such a > document that will most likely be used in a variety of different = environments. I > would nevertheless be interested to know what the MTI algorithms = should be > (from your point of view). I agree with the idea of it not being useful to define the MTI = algorithms. I am at a loss why you think it should be given that the = first paragraph includes the following sentence: However, we have elected not to specify a set of mandatory algorithms in = this document. That being said. If I were to think about a mandatory set it would = probably look something like: * Content Encryption: either AES-GCM or AES-CCM depending on if you = think that small devices are the target market. AES-CCM is easier to = implement, but it prohibits any streaming encryption operation as you = need to know the length of the output before you start. * Key Management: Probably ECDH either directly or wrapped with AES-KW. = The first allows for low grade origination if one does static-static so = it would be useful both for encryption and MACs * MAC algorithm - HMAC-Sha256 * Signature Algorithm - ECDSA The latter three make the assumption that SHA-256 is a supported hash = algorithm. If that is not doable then one would need to re-look at the = outputs. I am not ready to jump ship to the new algorithms, but might = soon be willing to do so with the new ECDH curve and signatures. >=20 > * Examples >=20 > As most people I also look at the examples first and would have = appreciated a > bit more explanation. So, help me understand them. >=20 > Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the = 'direct > shared secret' means that the sender of the message and the receiver = share a > symmetric key. Yes this is correct. >=20 > What does "File name: Mac-04" mean? This is the name of the file in the examples project up on github (see = first paragraph of appendix C). >=20 > Just to make sure that I understand the structure correctly I added = comments > inline: >=20 > { > 1: 3, --> msg_type is COSE_mac > 2: h'a1016f4145532d434d41432d3235362f3634', >=20 > --> protected header fields > When I use a CBOR decoder I get the value of = '"\xA1\x01oAES-CMAC-256/64". > Is that really the encoding for the algorithm id? Yes. The string will be shortened to an integer when it gets assigned. = Until then I am using the string for the identifier. At that point it = would be something like 'a101XX' where XX would be an encoded integer = of the correct value. This is expected to be done relatively soon. >=20 > 4: h'546869732069732074686520636f6e74656e742e', > --> payload of the string "This is the content." >=20 > 10: h'd9afa663dd740848', --> tag which contains the MAC value. > 9: [ --> recipients > { > 3: { > 1: -6, > 4: h'6f75722d736563726574' > } > } > ] > } >=20 > Section 6 talks about recipients and says: >=20 > " > recipients contains the recipient information. See the = description > under COSE_Encryption for more info. > " >=20 > When I look for more info in Section 5 then I do not find a lot. > Why is the field mandatory? What is the meaning of it in this example? For MACs, one still needs to do some type management for the recipient = to identify the key that is going to be used to compute the MAC for = verification. This is not restricted to just having a pre-shared = secret. Instead one can derive the secret by using, for example, = ECDH-SS. Part of the question here is if anonymous MAC is interesting = (i.e. just encrypting the MAC key for the recipient with RSA) or if low = grade origination is needed. Even for low-grade origination the direct, = derived from direct and ECDH-SS direct recipient types would all give = the needed origination proofs. >=20 > For an IoT context I would imagine that the algorithm and the key has = been > agreed between the sender and the receiver using some key management > protocol and the appropriate example would be something like: >=20 > { > 1: 3, > 2: {4: 1,6: 1}, > 4: "This is the content.", > 10: h'd9afa663dd740848' > } >=20 > (Note that I don't really know whether this is the encoding you = envision for the > header parameters.) There is an on-again, off-again discussion about making direct key = management privileged in terms of key management. Personally, I am = against this as I would prefer to see everything be uniform in all cases = and I don't know that you win enough by making things special. Part of = the question is are you ever going to do anything except direct key. = >From a security point of view, I would argue that you are much better = off doing a KDF on a shared secret and using that on a per message basis = rather than having a key that is used until some external event occurs. = I would also tend to make the same argument about making the algorithm = be implicit rather than explicit. While possible, I don't know that = this is really a good idea. I have generally found it to be a problem = latter on in the process. However, the implementations that I have done = would allow for that to happen. I just don't care for it as a suggested = way to travel. This means that I would be looking more at { 1:3, 2:{1:15}, 4:"This is the content.", 10:h'd9afa663dd740848', 9:[{ 3:{1:-6}}] } I am not sure what you are looking at for the two parameters that you = included in your example. If they are just place holders then you could = include them as well. I omit the KID parameter from the recipient = structure since that can be implied relatively easily if you only have = one dialog going on between the two entities. If you have multiple = dialogs then include a KID is useful. >=20 > Minor issues: >=20 > * You write: "CBOR extended the data model of the JavaScript Object = Notation > (JSON) by allowing for binary data among other changes." >=20 > Is 'data model' the right term here? I think we are talking about = encoding. > For a more detailed treatment of what a data model is take a look at = RFC 3444. I took the term from RFC 7049 in the introduction section. Different = people have different definitions of data model but I think that this is = a legal one. "The underlying data model is an extended version of the JSON data model = [RFC4627]." >=20 > * You write: > " > o The author did not always agree with some of the decisions made = by > the JOSE working group. Many of these decisions have been re- > examined, and where it seems to the author to be superior or > simpler, replaced. > " >=20 > For a working group draft it does not matter whether the author agrees = or > disagrees. I would suggest to remove this paragraph. Yes - It was originally written to be an individual draft not a working = group draft. I will look at doing a re-write because for people who = come into this from the JOSE world, they may want some explanation about = why things are different. >=20 >=20 > * SMIME/CMS >=20 > I would remove references to CMS and S/MIME since they are most likely = only > helpful to a very small audience. Will look at. >=20 > Ciao > Hannes >=20 From nobody Thu Aug 27 16:17:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071771B30E0 for ; Thu, 27 Aug 2015 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJBWBJj0AQ3u for ; Thu, 27 Aug 2015 16:17:19 -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 346521A89F1 for ; Thu, 27 Aug 2015 16:17:19 -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 t7RNHCDf008908; Fri, 28 Aug 2015 01:17:12 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n2KhR4kKGz4v5K; Fri, 28 Aug 2015 01:17:11 +0200 (CEST) Message-ID: <55DF9A76.1040709@tzi.org> Date: Fri, 28 Aug 2015 01:17:10 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Jim Schaad References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> In-Reply-To: <013201d0e108$2325eb60$6971c220$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Hannes Tschofenig' , cose@ietf.org Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 23:17:21 -0000 Great discussion. My two yens for now: > You might also look at the WIP draft on github as it has a change from using maps to arrays at the top level. I'm curious: What keeps us from working with that as the WG draft? I think we would benefit from reducing the distance between the editor's draft and the WG draft. (Next, I'd like to get rid of the msg_type.) > * Signature Algorithm - ECDSA There is little point in having an "MTI" signature algorithm without also specifying the curve. (And you mentioned the GCM-CCM split.) Oh, and: > key management I think we'll all benefit from not using that word any more in this WG. >> Is 'data model' the right term here? I think we are talking about encoding. No, we are indeed talking about the data model. It's JSON's data model that does not provide for binary data (= byte strings). (Yes, that also means there is no encoding for binary data in JSON, but that is ancillary to binary data not being there in the first place.) >> For a more detailed treatment of what a data model is take a look at RFC 3444. That is still the same kind of data model, except that in RFC 3444 it is used for a specific data model and contrasted to the information model. Here we are talking about the generic data model of JSON as compared to CBOR. (The information models represented in these data models could still be the same, e.g., by base64-encoding some information in JSON while keeping it in its natural form in CBOR.) Grüße, Carsten From nobody Thu Aug 27 20:40:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED981B355E for ; Thu, 27 Aug 2015 20:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W9NGvudmGNK for ; Thu, 27 Aug 2015 20:39:59 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FCC1B3CEF for ; Thu, 27 Aug 2015 20:31:54 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id AF7622C9E7; Thu, 27 Aug 2015 20:31:53 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> <55DF9A76.1040709@tzi.org> In-Reply-To: <55DF9A76.1040709@tzi.org> Date: Thu, 27 Aug 2015 20:29:43 -0700 Message-ID: <016101d0e141$c812bf20$58383d60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJn36g0b++GHPEUf65M22awuFXaxwDUaryiARY+862c4236IA== Archived-At: Cc: 'Hannes Tschofenig' , cose@ietf.org Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 03:40:01 -0000 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, August 27, 2015 4:17 PM > To: Jim Schaad > Cc: 'Hannes Tschofenig' ; cose@ietf.org > Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 >=20 > Great discussion. >=20 > My two yens for now: >=20 > > You might also look at the WIP draft on github as it has a change = from using > maps to arrays at the top level. >=20 > I'm curious: What keeps us from working with that as the WG draft? > I think we would benefit from reducing the distance between the = editor's draft > and the WG draft. I am not sure what I can do to point people to the github draft more = than is already done. The only behavior that I can change is to publish more often in terms of = reducing the distance between drafts. But I am currently thinking in = terms of doing this every 2-3 weeks. I don't know that more frequently = is helpful. >=20 > (Next, I'd like to get rid of the msg_type.) >=20 > > * Signature Algorithm - ECDSA >=20 > There is little point in having an "MTI" signature algorithm without = also > specifying the curve. (And you mentioned the GCM-CCM split.) Yeah, I kind of did that in terms of saying that I was not ready to jump = to the new CFRG curves. I was kind of assuming it would be P256 for = size reasons. >=20 > Oh, and: >=20 > > key management >=20 > I think we'll all benefit from not using that word any more in this = WG. I will keep trying, but this is the term that is ingrained in my = vocabulary. It is not in the document anymore. Jim >=20 > >> Is 'data model' the right term here? I think we are talking about = encoding. >=20 > No, we are indeed talking about the data model. > It's JSON's data model that does not provide for binary data (=3D byte = strings). > (Yes, that also means there is no encoding for binary data in JSON, = but that is > ancillary to binary data not being there in the first place.) >=20 > >> For a more detailed treatment of what a data model is take a look = at RFC > 3444. >=20 > That is still the same kind of data model, except that in RFC 3444 it = is used for a > specific data model and contrasted to the information model. > Here we are talking about the generic data model of JSON as compared = to > CBOR. (The information models represented in these data models could = still be > the same, e.g., by base64-encoding some information in JSON while = keeping it in > its natural form in CBOR.) >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 27 23:13:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878AB1A001B for ; Thu, 27 Aug 2015 23:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjFjglDZpj1r for ; Thu, 27 Aug 2015 23:13:46 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 B15D71A8A13 for ; Thu, 27 Aug 2015 23:13:45 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so24305576lbb.0 for ; Thu, 27 Aug 2015 23:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=d0a8hYd6RnYHnqZn33e6mBdkuTgfhoGK+TpbL9+iqpI=; b=J0WrWLbVdgKn6K3whqTjpgG6goFBI8VIKpgBUR/cSEziXY7kGSU2MpEAP7B3owgLAw Fwz02zpXqvWtaijp/L8W7Q8OQG8uyCv1lpgcnrdpaGXbqEYOacbVLvlr0D2oreRrAwCO Ad0FTR6u3WvF3to2VKBmSjpQUfPq3GW//SieVUTdbfaKGTQjDqgZxGg4DiPiq7zQGjnv AkFueMBXtUVEhbb9UkxMpBPS1kUbCX+X2XYrDIo4xTq18K54TNEtArGurlGcwA0F363l 5COfqc7nufi4+WieUm0GeQPVu/TjG4BVVUZbdxC3nVb9AqaTYzd/FxYXJpBOLtRzxnwp RUMA== X-Gm-Message-State: ALoCoQnZ95c8s48D9A7YkDgbLRkDZiGldomlqxgSMugz7JGFltYBASXzFlGBQoIb26A78dOwigMG X-Received: by 10.153.7.137 with SMTP id dc9mr4279378lad.16.1440742423802; Thu, 27 Aug 2015 23:13:43 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id ph4sm1136774lbb.3.2015.08.27.23.13.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 23:13:43 -0700 (PDT) To: cose@ietf.org, Hannes Tschofenig References: <55DF394D.1020403@gmx.net> From: Ludwig Seitz Message-ID: <55DFFC10.1040700@sics.se> Date: Fri, 28 Aug 2015 08:13:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DF394D.1020403@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020401030804050509070405" Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 06:13:47 -0000 This is a cryptographically signed message in MIME format. --------------ms020401030804050509070405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable =2E.. > --> protected header fields > When I use a CBOR decoder I get the value of > '"\xA1\x01oAES-CMAC-256/64". > Is that really the encoding for the algorithm id? > Ha! That one made me think twice and read the fine-print. a1016f4145532d434d41432d3235362f3634 (which indeed decodes to "\xA1\x01oAES-CMAC-256/64") is a binary representation of the protected header which is a CBOR=20 structure itself, so if you put a1016f4145532d434d41432d3235362f3634 in=20 a CBOR decoder you get: {1: "AES-CMAC-256/64"} =2E.. which makes perfect sense. --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms020401030804050509070405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgyODA2MTMzNlowLwYJKoZI hvcNAQkEMSIEIJy99Do+1qE4bmQmu+oUko4AbBmXzxpm/xazmWX4K9x0MGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBNYZqGQP8ZoD7dIzJococi/X4egLpt2dgRDZGkl9dB Uq4lpVZu5ix6tOox8o2KbabnrbYEL+Hy+couVSAFopJWTZP4GH+Wa7Yewv5T9Xq80yDINPQu RHik9Xb+Pt8X9NijqkmtAbutkoAEdSdHCYvMQOCgiHteEa93XFUgHuVPkD/1DpLbBqBbvTlQ C7CIpuiCNHqKg6WgF6dwvMrE4AYKZTQyEDY2N2bmgY1nWagXjHXbS0/huztvNoq/BVCoVXTE LIjbfGybYSqCbbKJpZEyZIwqRM3+IacIoBU+jmOk/D566BYazRGnu35UpTeHiVsRvU1PpTOD 4GyrfmXIY5LsAAAAAAAA --------------ms020401030804050509070405-- From nobody Thu Aug 27 23:16:05 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2408B1B137B for ; Thu, 27 Aug 2015 23:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCuTAU0vseyO for ; Thu, 27 Aug 2015 23:16:02 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 69A4D1AD378 for ; Thu, 27 Aug 2015 23:16:01 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so24250311lbc.2 for ; Thu, 27 Aug 2015 23:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=0vnbVaEhbP5RJVckiQITf/ffV1QRCd7B/3KCyQ8OQ4U=; b=OJWF9WJbYpYbS8R/799s04k6Zge68YVMgs13tlKAdjzBg1Tp/mthG0nnvHpoVbMKRW uovKQlUYZn22SXI90nMoUWvf3qZuEumM2BC0jEGJtcFfP88Jcjy6DlZB+cQPhjXudT4s XAWKhLKigeenBPQ6+57Nujri5OvitluV+LzWJlX0byRC/R+z3zK/XTFTerMDtOF6UmLz VwDGdcLoGTLBd7vmLQjFx1qXno0EGRx87IlgKk/mFehoO1Dwm9AduxNCMeRz/g4xYlyV oMS+ACaq4VhV4MgYRMDBwVr93olgLQUbSbq50HEU9oMJx03/t5zt6kDDxQL9E1V6WosX 1PkA== X-Gm-Message-State: ALoCoQk9+/x2D+ly5AGn/bS3hyqtx9svg+fpEe6ophm8ElSvTqXylWcvyVBp6IRA6E5GK87R9wja X-Received: by 10.152.37.137 with SMTP id y9mr3844234laj.105.1440742559848; Thu, 27 Aug 2015 23:15:59 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id b5sm1134760laa.34.2015.08.27.23.15.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 23:15:59 -0700 (PDT) To: cose@ietf.org References: <55DF394D.1020403@gmx.net> From: Ludwig Seitz Message-ID: <55DFFC9E.3010602@sics.se> Date: Fri, 28 Aug 2015 08:15:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DF394D.1020403@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050106010401000808070805" Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 06:16:03 -0000 This is a cryptographically signed message in MIME format. --------------ms050106010401000808070805 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jim, a few nitpicks from me: Section 1.4 "... choice data items ..." should be "... chose data items = =2E.." Section 3. 3rd para "a common connical encoding" should be "a common=20 cannonical encoding" i guess Section 4: I'd rather reference the definition of 'Headers' instead of the=20 definition of 'protected' and 'unprotected' in the last two CDDLs. Same=20 goes for sections 5 and 6. Section 5: "In COSE, the same techniques and structures for encrypting both the=20 plain text and the keys used to protect the text." This sentence is missing a word. Perhaps "... keys are used ..."? Section 8: "in the worst case it because the same as doing a singature with appendix= =2E " s/because/becomes/ Section 12.1.2 "One unpredictable manner than can be used is to use the HKDF function=20 to generate the IV." s/than/that/ Appendix B, Second bullet list jumps from Level 1 to Level 3 for no=20 apparent reason (or I'm just not getting it). Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms050106010401000808070805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgyODA2MTU1OFowLwYJKoZI hvcNAQkEMSIEIEx2JIFaysmiiDr09ibxq+czPvx/4hFcoyytriBJbuZTMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBbpPR1xqL7UgJrM9oL2NF9MDcnBQFqZD7QpRQSeQ3S XpbG0j3XLJvWM3ar+6JwnZ6BzDyfjelVMxavjIfy857fjxHeWmdYMObUAM235ZoZeFZifkEP SswMgQuJ+t79rX9TY2qbvw/u2HMKEVPyAHETrJSMHLbbK7uBxbWsFaMGjldwmziXqYirIQpb YzLAaVEZe6CY2F1Dr1BQXUxzH0TrZp216P9zyDL3Ht3LpugcbQ6otfDtwlcAJr7wZS1GlJfl APRx3vDsDBPg6bBSC1ybb3dxpDltsU3tbZDCQvFrm38W26lTEXo+rGNPYYKZO29ConFDuBd6 ndZl4/gO0g8lAAAAAAAA --------------ms050106010401000808070805-- From nobody Fri Aug 28 05:06:51 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6881A916C for ; Fri, 28 Aug 2015 05:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22uPLvgKNIAg for ; Fri, 28 Aug 2015 05:06:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6219C1A9078 for ; Fri, 28 Aug 2015 05:06:48 -0700 (PDT) Received: from [192.168.131.140] ([80.92.121.239]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MRoyH-1Z7KZQ2YGH-00SyEc; Fri, 28 Aug 2015 14:06:45 +0200 To: Ludwig Seitz , cose@ietf.org, Hannes Tschofenig References: <55DF394D.1020403@gmx.net> <55DFFC10.1040700@sics.se> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55E04EC4.2030907@gmx.net> Date: Fri, 28 Aug 2015 14:06:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DFFC10.1040700@sics.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fcfExlnvKit2cUbe74Ki1qAofiF0eNrhE" X-Provags-ID: V03:K0:do0uT9VqF9kCA0hNOS8ZSy/9owXDlfvnVrb6eCdKVs3uGr0xHLf WqjNT/tioRV4m+UOI7Wfukqe9vWSMzOonARUZ5iYX08LQN0bLkKYYaYrijMpwGOgU3Zh65k M/N2mCKuWlA7SxDRpSviE0dKgOZx+j6rjcR8BZx7txoFGJK83IBEWhns0Ty2zTuNlt8zSgk hPPghDnuH9LsCEzojRloQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:pRRhiokkg+k=:bUgi7R5aJ2ivyihKnnqmbu mq7nw/9kuNEXqUShzcotdMCFWn3C+QHuyq22w20WxFV10I4ZXUQaqBYM4kX/z1EiM1hmvUUQj ix2FeyOJmbsdTn3ubMQq4dU7y1xgdQpF/jGuQt3eGsNWqzS7K1Zi7h1PhB+OurwiEcBqKighE 1GYnxaxvYGHLoXP8jBfvA63C3Nje7HIhp2ehFpdxuOcE/LUZuzuK4s2PUgNsB/Pem4hTPV4pI zvzz0Q2Tu0+d0im0d+rv7aQVxEDkK7pwfCyvKSiLlq47mV5zTigSKNEuEasbX1uGtgdFwPZ+A mMli5Noivlnt0ZIzWV2JWzDR7Os8PTc13hjeSlI8lpSwmToxtBMkijaB9/VqdCA9Wtzy8BmzS E1oiGD2JxtMTeRd9vc02PUp58QHqHbL1/VGDlf8GvwV7J3ADdlycNqhdjcA33g6690NlL9KSl kPfj2Lq+UerLfJ4NPUTUb55rZxOt5YkoitoSeHizYSUSQ1TLibM0dwVswsI54ho0UEy8qTZtP yiGuAApLxyisjGURYe+HPVyEfjYq1jURuqtjNDCT20mdSYWRBDLNBx2EYzgRvOnKDkGFCQfHy qVzt1Vawt38oEKCSY8s4QjbctxE2/fCIaiCxlUWvwGZNX2hpUHprWsGRmVkDbYR+ZMZIDxJXO ZEisCOEENqXOMJrXV5rZmcrRTsrtegMk5pUtX53FNU253SNAWg60qJTEdq57GpGZ39IR/xlBB RM9JMXtDNxwhhZQR Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:06:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fcfExlnvKit2cUbe74Ki1qAofiF0eNrhE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The point I was trying to make is a different one. Here is the issue: If we try to optimize as much as we can then it does not make sense to put a text string for an algorithm in there. Instead, it would make more sense to create a registry and then number #5 would then correspond to 'AES-CMAC-256/64'. On 08/28/2015 08:13 AM, Ludwig Seitz wrote: > Ha! That one made me think twice and read the fine-print. >=20 >=20 > a1016f4145532d434d41432d3235362f3634 (which indeed decodes to > "\xA1\x01oAES-CMAC-256/64") >=20 > is a binary representation of the protected header which is a CBOR > structure itself, so if you put a1016f4145532d434d41432d3235362f3634 in= > a CBOR decoder you get: >=20 > {1: "AES-CMAC-256/64"} >=20 > ... which makes perfect sense. --fcfExlnvKit2cUbe74Ki1qAofiF0eNrhE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV4E7EAAoJEGhJURNOOiAtUY8H/i5GUFQ1RsCjCvFAxvvHKbqZ TMWUhgL0qyt9RPv8r420eUrTHj7hLxa2PlD/qk04SGY+h2EaUr2tNFWjQzYqsJe0 6gS7sdHYzQQ59GaAMVlfHOzehBFo9YUSN3RJ1Poejpb1WM/vI9Hyny7W4PK3dXDT T9bgaLCy/V/CQ1w/xNLvn/sywj3nbajCJD6QeZ3vfDUuFvoxBPBbf9zG7FvsTnhZ ofomT0J06ItvZQ9bXvxUCUzEuXUM3C0Q0aR20vKOjPVXUK2i/6m6tneRf3hiF4aR 7M3QNJ/Xd97JeXkvUfR6nZPNTzkN+HAassyLuMhP3hw2Zb/WxTpcQelVlThEDWc= =3HUS -----END PGP SIGNATURE----- --fcfExlnvKit2cUbe74Ki1qAofiF0eNrhE-- From nobody Fri Aug 28 05:08:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ABB1A0389 for ; Fri, 28 Aug 2015 05:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qORb2YLydQi0 for ; Fri, 28 Aug 2015 05:08:37 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 7B83D1A9171 for ; Fri, 28 Aug 2015 05:08:30 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so28824848lbb.3 for ; Fri, 28 Aug 2015 05:08:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=JnEkj4EG2fywuCmNZLb9LqQBbsgjPlT54s6x29uwUuU=; b=MTZdYT/BTb5CXJem0tEPUm0t05BUjzFq+zTytzD7ARjYWh5IwUJBCRGtezOE85n73P ZxYKGg6T3m8I5tZgt/MzX0mzcuKqPxX2s3YV7q6AmWxhWUh52BbMWRlY13Ga2KC3V1Ih tG6406BeVsvK2hLfZ6Ac+S9D/3+pylAsns7Yy5PiSeitMcR9vhe+22mzSc4wnZb9f8hY GTOW3SKO0BI2h9ssj5LztT6KPvUjBbbakibQv28ubGK3Erv3HFpjn8XKXPhOrgT9UAzl 5yEdJgEWxxbdceJqB55IdFkkn3Gpf3zMJxSUvSvOBXJfWMEF3fxIBOkVuilNdXuNDHi/ AHAQ== X-Gm-Message-State: ALoCoQkgMiFxI72Gsyy5kNRWbNazjR2nfnL5ZGAs7QpiqqO979cBFUZFQZxnU8zZr2NU7a5bPdDx X-Received: by 10.152.20.228 with SMTP id q4mr4562822lae.74.1440763708859; Fri, 28 Aug 2015 05:08:28 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id s2sm1358440lae.28.2015.08.28.05.08.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2015 05:08:28 -0700 (PDT) To: Hannes Tschofenig , cose@ietf.org, Hannes Tschofenig References: <55DF394D.1020403@gmx.net> <55DFFC10.1040700@sics.se> <55E04EC4.2030907@gmx.net> From: Ludwig Seitz Message-ID: <55E04F3B.8020509@sics.se> Date: Fri, 28 Aug 2015 14:08:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E04EC4.2030907@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020103070108000301050406" Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:08:39 -0000 This is a cryptographically signed message in MIME format. --------------ms020103070108000301050406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-08-28 14:06, Hannes Tschofenig wrote: > The point I was trying to make is a different one. Here is the issue: I= f > we try to optimize as much as we can then it does not make sense to put= > a text string for an algorithm in there. Instead, it would make more > sense to create a registry and then number #5 would then correspond to > 'AES-CMAC-256/64'. > Ok, no contention on that one, sorry for missing your point. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms020103070108000301050406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgyODEyMDgyN1owLwYJKoZI hvcNAQkEMSIEIOnrEzBELc5IOLVKoyylEcVlI0NI2aIB94oqz76HK0iEMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQA4Vm0aiN08m9yU6R7LFoInq/xONN/4mHANaZNO96+i cu1eG83ERSxl9umS6nZy89MkbHFYi5NUnHUpk6Z+I91N8VJD9WqY2xzyQzfjKchmZ1Cm8+kf hMH2TXWxMJ5B2pXCNteZqqO/GbpQru2SZ5H/udExz7Xh1hHxfc2E3AS30Qvyoxj20spcuC8T c3kVK8INbG4ZAzLNUkU8tcVZxY0NmWFBK9IUwn/lLcz7BtodFsQpS4g1hNZ1twqwmLgOY8qo ZfOIIY5CMzBUktIko4BO+mCgqXJpM8OP+zElNus3B1FcrqrK5eLv98CWwothH6kbWuRnEs5I Lj4hfBM+/BnGAAAAAAAA --------------ms020103070108000301050406-- From nobody Fri Aug 28 05:48:53 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79B1A89F6 for ; Fri, 28 Aug 2015 05:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLS09tH4lgKZ for ; Fri, 28 Aug 2015 05:48:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B401AC3B6 for ; Fri, 28 Aug 2015 05:48:47 -0700 (PDT) Received: from [192.168.131.140] ([80.92.121.239]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lk81O-1YyzP41FcY-00c9pF; Fri, 28 Aug 2015 14:48:44 +0200 To: Jim Schaad , cose@ietf.org References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E058A9.5040404@gmx.net> Date: Fri, 28 Aug 2015 14:48:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <013201d0e108$2325eb60$6971c220$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6kh5XieNerDl3taojvEp7lbcfC5F89u3r" X-Provags-ID: V03:K0:KS16AQqje6biGU1q69+srTZZs87i/CnPXEo9W+lS3QXQQzsdbG+ HAgi6PQKv7zsZyIyyp06g/Tj+EF5NTxo9LcSYunR/l1y3KGh2nBWed6eEwib6CubAdIhgfA p074TvxBTKlcmkyxgSI54a2heYYrKWE9XsFE2+4Z0B+LOvweWh3LZQh71GsGfucYUcei+FH lPlikAxOXObw57vFRkf+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:7xUz6z8nqcc=:Rw0i2I35hRjQ4TnVKLtVJC tODSRwcQRv6Pnwg5uMtIxunHwwZbd0JZSx8kA7Y8IgiLuu27ehELRcygkcS39k3JUGxkeRhOu hcRauLI+YT72DZUs0YF3MQZV4fbT/0+94ZLXENFTthTWXZNKip9auLZ+SXI9JZFK/yTQGVngn YtwEeCajQb4dmxmemqbr4Q567d7xCUN4qDXRznc2lA/ei9E5kfUZZQMLBAsCM8BC+uOZaFF7+ 347FB/kuhrzKloQ8Kg8DaU47nd8jIY2G2x7il9yLL1BGI6ekIfUgxKAQNMI7BZxDhARk2Avcf hYKSaNMDwilJ3jg6MPBVzcnjLLp2EmqLwmo/JRUv2CpfdN0Jr3i5zhdASBxgcLfXhx4hO0Qlh tWnvW8+ZPkZ7t0sxnY8xwixEdibU7jNeslQjbmNdmO3RScy2OIcoOg9fxo5C/yU7kuY3YVUe3 KfzepVD1fdaKA51S4/whlmA1bpgMW2x3zhyr8MmlwICRBwD76xtY9jlBimCkBxe2umCUu7Qt1 /HCG3jQ/1h5foplT1xi9E0Gn4qCNkBGammTXp3HhdzH6ndUljMG9Xd3TD3PpVFP/tvi45Fu6q QCLFzBcTzZQKjKiFLQBJSngsxQcByXaV2clf8Qd+GWX6XFzkPt7w2lB1DenM9aMy1qcqC/Dg/ +rets9teJ9cJ0tRyyr7ms68Go1IQo0ZrTbIu57HxGFESFMWpTPp2QbdX3xj8W7jd/XIQXsolh tOBufTAM1Ls+pqiz Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:48:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6kh5XieNerDl3taojvEp7lbcfC5F89u3r Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, thanks for your quick response. On 08/27/2015 10:37 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes Tschofen= ig >> Sent: Thursday, August 27, 2015 9:23 AM >> To: cose@ietf.org >> Subject: [COSE] Comments for draft-ietf-cose-msg-03 >> >> Hi Jim, Hi all, >> >> out of curiosity I have been reading through the latest version of the= COSE draft >> and ran into a few questions. >=20 > You might also look at the WIP draft on github as it has a change from = using maps to arrays at the top level. This makes the code slightly diff= erent and provides a small decrease in message sizes. >=20 Thanks for pointing this out. >> >> * MTI >> >> Section 1.6 is supposed to define mandatory-to-implement algorithms bu= t >> actually doesn't say what those are. >> >> I personally don't believe it is useful to define MTI algorithms for s= uch a >> document that will most likely be used in a variety of different envir= onments. I >> would nevertheless be interested to know what the MTI algorithms shoul= d be >> (from your point of view). >=20 > I agree with the idea of it not being useful to define the MTI algorith= ms. Great. If more people in the working group agree then we might get away without specifying algorithms that are mandatory-to-implement. > I am at a loss why you think it should be given that the first paragra= ph includes the following sentence: >=20 > However, we have elected not to specify a set of mandatory algorithms i= n this document. >=20 > That being said. If I were to think about a mandatory set it would pro= bably look something like: >=20 > * Content Encryption: either AES-GCM or AES-CCM depending on if you thi= nk that small devices are the target market. AES-CCM is easier to implem= ent, but it prohibits any streaming encryption operation as you need to k= now the length of the output before you start. > * Key Management: Probably ECDH either directly or wrapped with AES-KW.= The first allows for low grade origination if one does static-static so= it would be useful both for encryption and MACs > * MAC algorithm - HMAC-Sha256 > * Signature Algorithm - ECDSA >=20 > The latter three make the assumption that SHA-256 is a supported hash a= lgorithm. If that is not doable then one would need to re-look at the ou= tputs. I am not ready to jump ship to the new algorithms, but might soon= be willing to do so with the new ECDH curve and signatures. >=20 >> >> * Examples >> >> As most people I also look at the examples first and would have apprec= iated a >> bit more explanation. So, help me understand them. >> >> Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the 'dir= ect >> shared secret' means that the sender of the message and the receiver s= hare a >> symmetric key. >=20 > Yes this is correct. Ok. >=20 >> >> What does "File name: Mac-04" mean? >=20 > This is the name of the file in the examples project up on github (see = first paragraph of appendix C). >=20 Ok. I guess it will be removed at some point in time. >> >> Just to make sure that I understand the structure correctly I added co= mments >> inline: >> >> { >> 1: 3, --> msg_type is COSE_mac >> 2: h'a1016f4145532d434d41432d3235362f3634', >> >> --> protected header fields >> When I use a CBOR decoder I get the value of '"\xA1\x01oAES-CMAC-2= 56/64". >> Is that really the encoding for the algorithm id? >=20 > Yes. The string will be shortened to an integer when it gets assigned.= Until then I am using the string for the identifier. At that point it = would be something like 'a101XX' where XX would be an encoded integer of= the correct value. This is expected to be done relatively soon. Perfect. Maybe we could already create an assignment and use the integers already since you are going to create a new registry for this purpose (or are you planning to re-use an existing registry)? >=20 >> >> 4: h'546869732069732074686520636f6e74656e742e', >> --> payload of the string "This is the content." >> >> 10: h'd9afa663dd740848', --> tag which contains the MAC value. >> 9: [ --> recipients >> { >> 3: { >> 1: -6, >> 4: h'6f75722d736563726574' >> } >> } >> ] >> } >> >> Section 6 talks about recipients and says: >> >> " >> recipients contains the recipient information. See the descriptio= n >> under COSE_Encryption for more info. >> " >> >> When I look for more info in Section 5 then I do not find a lot. >> Why is the field mandatory? What is the meaning of it in this example?= >=20 > For MACs, one still needs to do some type management for the recipient = to identify the key that is going to be used to compute the MAC for verif= ication. This is not restricted to just having a pre-shared secret. Ins= tead one can derive the secret by using, for example, ECDH-SS. Part of t= he question here is if anonymous MAC is interesting (i.e. just encrypting= the MAC key for the recipient with RSA) or if low grade origination is n= eeded. Even for low-grade origination the direct, derived from direct an= d ECDH-SS direct recipient types would all give the needed origination pr= oofs. >=20 I agree that there has to be an identifier somewhere in the message to allow the recipient to pick the right key. The question is what is this identifier and where in the message is it. Here I believe we will have to look at the use cases, which is what I am doing right now. >> >> For an IoT context I would imagine that the algorithm and the key has = been >> agreed between the sender and the receiver using some key management >> protocol and the appropriate example would be something like: >> >> { >> 1: 3, >> 2: {4: 1,6: 1}, >> 4: "This is the content.", >> 10: h'd9afa663dd740848' >> } >> >> (Note that I don't really know whether this is the encoding you envisi= on for the >> header parameters.) >=20 > There is an on-again, off-again discussion about making direct key mana= gement privileged in terms of key management. Personally, I am against t= his as I would prefer to see everything be uniform in all cases and I don= 't know that you win enough by making things special. Part of the questi= on is are you ever going to do anything except direct key. From a secur= ity point of view, I would argue that you are much better off doing a KDF= on a shared secret and using that on a per message basis rather than hav= ing a key that is used until some external event occurs. =20 >=20 Here we again need to look at the use cases we are trying to solve. Happy to provide some input here. In my use cases, there is another separate key management solution in use (such as OMA LWM2M, or the stuff we are developing in ACE). The keys + parameters are then available to the communication parties and only need to be applied to the CBOR payload (using COSE). > I would also tend to make the same argument about making the algorithm = be implicit rather than explicit. While possible, I don't know that this= is really a good idea. I have generally found it to be a problem latter= on in the process. However, the implementations that I have done would = allow for that to happen. I just don't care for it as a suggested way to= travel. >=20 > This means that I would be looking more at > { 1:3, > 2:{1:15}, > 4:"This is the content.", > 10:h'd9afa663dd740848', > 9:[{ 3:{1:-6}}] > } >=20 > I am not sure what you are looking at for the two parameters that you i= ncluded in your example. If they are just place holders then you could i= nclude them as well. I omit the KID parameter from the recipient structu= re since that can be implied relatively easily if you only have one dialo= g going on between the two entities. If you have multiple dialogs then i= nclude a KID is useful. In my example I am trying to add two fields, namely a 'kid' and a sequence number. Both values are set to '1'. I don't understand what this line "9:[{ 3:{1:-6}}]" means. Ciao Hannes --6kh5XieNerDl3taojvEp7lbcfC5F89u3r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV4FipAAoJEGhJURNOOiAtj/AH/Ro7Y41yCCOeMLM1PSNyWmJy 0U/K0t4soVA8Au9ck4pO3D87Z/CJ6WrqvibjGCyVb+LHksmp71+klqCkVv1jhpVr y0ab8oOPPcR2c3tFGxMk+umCaNoIdrdHa8yfhfpO2CgsELibV6qoA7Wec8UcHB/i L9DTJF7fNG3zKcOxQAP1BbIEYRuNvRvm0RguavR8v0qtEA8ZdSZXXfWrGE5ymUdy kK7IZjj5xI61okPx2oaV9pAm8DHvt0JM4iRyVU1A9h7t7MOCZkSuP+pKqi1ibP+S 30MU16JMK9Kb508fGMDQpfRJsRvcwffJajut2vJZAdj4J+JEYue9bdWCrMM2ALw= =ik/M -----END PGP SIGNATURE----- --6kh5XieNerDl3taojvEp7lbcfC5F89u3r-- From nobody Fri Aug 28 06:21:14 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18181B3452 for ; Fri, 28 Aug 2015 06:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4WJs7S34G-y for ; Fri, 28 Aug 2015 06:21:11 -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 5C6121B3483 for ; Fri, 28 Aug 2015 06:21: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 t7SDL51f004440; Fri, 28 Aug 2015 15:21:05 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n2hQ91yfRz4vYk; Fri, 28 Aug 2015 15:21:05 +0200 (CEST) Message-ID: <55E0603E.8090409@tzi.org> Date: Fri, 28 Aug 2015 15:21:02 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Hannes Tschofenig References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> <55E058A9.5040404@gmx.net> In-Reply-To: <55E058A9.5040404@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , cose@ietf.org Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:21:13 -0000 Hannes Tschofenig wrote: > I don't understand what this line "9:[{ 3:{1:-6}}]" means. In the context of { 1:3, 2:{1:15}, 4:"This is the content.", 10:h'd9afa663dd740848', 9:[{ 3:{1:-6}}] } it means that this map has an entry with a key of integer 9, and a value that is an array with a single map in it, which maps 3 to another map, which maps 1 to -6. The relevant translations are: | recipients | 9 | For COSE_encrypt and COSE_mac | | unprotected | 3 | Occurs in all structures | | alg | 1 | int / | COSE | Integers are taken | | | | tstr | Algorithm | from table --POINT TO | | | | | Registry | REGISTRY-- | | direct | -6 | Direct use of CEK | (I'm not sure about the 2:{1:15} though.) Anyway, this is a nice demonstration why we need a better prettyprinter (which I'm writing as we speak, by the way), as Mike pointed out. Grüße, Carsten From nobody Fri Aug 28 11:09:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68F41A0095 for ; Fri, 28 Aug 2015 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byn78E75bpY8 for ; Fri, 28 Aug 2015 11:09:33 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266C41ACE38 for ; Fri, 28 Aug 2015 11:09:33 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 604982CA1A; Fri, 28 Aug 2015 11:09:32 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> <55E058A9.5040404@gmx.net> In-Reply-To: <55E058A9.5040404@gmx.net> Date: Fri, 28 Aug 2015 11:07:21 -0700 Message-ID: <020401d0e1bc$62b75e30$28261a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJn36g0b++GHPEUf65M22awuFXaxwDUaryiAcasB3ac3t4e0A== Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:09:35 -0000 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, August 28, 2015 5:49 AM > To: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 >=20 > Hi Jim, >=20 > thanks for your quick response. >=20 > On 08/27/2015 10:37 PM, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes > >> Tschofenig > >> Sent: Thursday, August 27, 2015 9:23 AM > >> To: cose@ietf.org > >> Subject: [COSE] Comments for draft-ietf-cose-msg-03 > >> > >> Hi Jim, Hi all, > >> > >> out of curiosity I have been reading through the latest version of > >> the COSE draft and ran into a few questions. > > > > You might also look at the WIP draft on github as it has a change = from using > maps to arrays at the top level. This makes the code slightly = different and > provides a small decrease in message sizes. > > > Thanks for pointing this out. >=20 >=20 > >> > >> * MTI > >> > >> Section 1.6 is supposed to define mandatory-to-implement algorithms > >> but actually doesn't say what those are. > >> > >> I personally don't believe it is useful to define MTI algorithms = for > >> such a document that will most likely be used in a variety of > >> different environments. I would nevertheless be interested to know > >> what the MTI algorithms should be (from your point of view). > > > > I agree with the idea of it not being useful to define the MTI = algorithms. >=20 > Great. If more people in the working group agree then we might get = away > without specifying algorithms that are mandatory-to-implement. >=20 >=20 > > I am at a loss why you think it should be given that the first = paragraph includes > the following sentence: > > > > However, we have elected not to specify a set of mandatory = algorithms in this > document. > > > > That being said. If I were to think about a mandatory set it would = probably > look something like: > > > > * Content Encryption: either AES-GCM or AES-CCM depending on if you = think > that small devices are the target market. AES-CCM is easier to = implement, but it > prohibits any streaming encryption operation as you need to know the = length of > the output before you start. > > * Key Management: Probably ECDH either directly or wrapped with > > AES-KW. The first allows for low grade origination if one does > > static-static so it would be useful both for encryption and MACs > > * MAC algorithm - HMAC-Sha256 > > * Signature Algorithm - ECDSA > > > > The latter three make the assumption that SHA-256 is a supported = hash > algorithm. If that is not doable then one would need to re-look at = the outputs. I > am not ready to jump ship to the new algorithms, but might soon be = willing to > do so with the new ECDH curve and signatures. > > > >> > >> * Examples > >> > >> As most people I also look at the examples first and would have > >> appreciated a bit more explanation. So, help me understand them. > >> > >> Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the > >> 'direct shared secret' means that the sender of the message and the > >> receiver share a symmetric key. > > > > Yes this is correct. >=20 > Ok. >=20 > > > >> > >> What does "File name: Mac-04" mean? > > > > This is the name of the file in the examples project up on github = (see first > paragraph of appendix C). > > >=20 > Ok. I guess it will be removed at some point in time. >=20 > >> > >> Just to make sure that I understand the structure correctly I added > >> comments > >> inline: > >> > >> { > >> 1: 3, --> msg_type is COSE_mac > >> 2: h'a1016f4145532d434d41432d3235362f3634', > >> > >> --> protected header fields > >> When I use a CBOR decoder I get the value of = '"\xA1\x01oAES-CMAC- > 256/64". > >> Is that really the encoding for the algorithm id? > > > > Yes. The string will be shortened to an integer when it gets = assigned. Until > then I am using the string for the identifier. At that point it would = be something > like 'a101XX' where XX would be an encoded integer of the correct = value. This is > expected to be done relatively soon. > Perfect. Maybe we could already create an assignment and use the = integers > already since you are going to create a new registry for this purpose = (or are you > planning to re-use an existing registry)? The registry is defined in section 15.5 of the document. It is just = that not all algorithms defined in the document have been assigned = integer values. Part of this is a question of which algorithms should = be defined. >=20 >=20 > > > >> > >> 4: h'546869732069732074686520636f6e74656e742e', > >> --> payload of the string "This is the content." > >> > >> 10: h'd9afa663dd740848', --> tag which contains the MAC value. > >> 9: [ --> recipients > >> { > >> 3: { > >> 1: -6, > >> 4: h'6f75722d736563726574' > >> } > >> } > >> ] > >> } > >> > >> Section 6 talks about recipients and says: > >> > >> " > >> recipients contains the recipient information. See the = description > >> under COSE_Encryption for more info. > >> " > >> > >> When I look for more info in Section 5 then I do not find a lot. > >> Why is the field mandatory? What is the meaning of it in this = example? > > > > For MACs, one still needs to do some type management for the = recipient to > identify the key that is going to be used to compute the MAC for = verification. > This is not restricted to just having a pre-shared secret. Instead = one can derive > the secret by using, for example, ECDH-SS. Part of the question here = is if > anonymous MAC is interesting (i.e. just encrypting the MAC key for the = recipient > with RSA) or if low grade origination is needed. Even for low-grade = origination > the direct, derived from direct and ECDH-SS direct recipient types = would all give > the needed origination proofs. > > > I agree that there has to be an identifier somewhere in the message to = allow the > recipient to pick the right key. >=20 > The question is what is this identifier and where in the message is = it. >=20 > Here I believe we will have to look at the use cases, which is what I = am doing > right now. >=20 >=20 >=20 > >> > >> For an IoT context I would imagine that the algorithm and the key = has > >> been agreed between the sender and the receiver using some key > >> management protocol and the appropriate example would be something = like: > >> > >> { > >> 1: 3, > >> 2: {4: 1,6: 1}, > >> 4: "This is the content.", > >> 10: h'd9afa663dd740848' > >> } > >> > >> (Note that I don't really know whether this is the encoding you > >> envision for the header parameters.) > > > > There is an on-again, off-again discussion about making direct key > management privileged in terms of key management. Personally, I am = against > this as I would prefer to see everything be uniform in all cases and I = don't know > that you win enough by making things special. Part of the question is = are you > ever going to do anything except direct key. From a security point = of view, I > would argue that you are much better off doing a KDF on a shared = secret and > using that on a per message basis rather than having a key that is = used until > some external event occurs. > > > Here we again need to look at the use cases we are trying to solve. > Happy to provide some input here. >=20 > In my use cases, there is another separate key management solution in = use (such > as OMA LWM2M, or the stuff we are developing in ACE). The keys > + parameters are then available to the communication parties and only > need to be applied to the CBOR payload (using COSE). I understand that this is the case. But it still comes to the question = of which key is used for a specific message if you do any KDF work or if = a different key management solution is used. Input on what the use cases really are and what the algorithms they want = to use are is highly appreciated. >=20 > > I would also tend to make the same argument about making the = algorithm be > implicit rather than explicit. While possible, I don't know that this = is really a > good idea. I have generally found it to be a problem latter on in the = process. > However, the implementations that I have done would allow for that to = happen. > I just don't care for it as a suggested way to travel. > > > > This means that I would be looking more at { 1:3, > > 2:{1:15}, > > 4:"This is the content.", > > 10:h'd9afa663dd740848', > > 9:[{ 3:{1:-6}}] > > } > > > > I am not sure what you are looking at for the two parameters that = you > included in your example. If they are just place holders then you = could include > them as well. I omit the KID parameter from the recipient structure = since that > can be implied relatively easily if you only have one dialog going on = between the > two entities. If you have multiple dialogs then include a KID is = useful. >=20 > In my example I am trying to add two fields, namely a 'kid' and a = sequence > number. Both values are set to '1'. >=20 > I don't understand what this line "9:[{ 3:{1:-6}}]" means. This line says -=20 Recipients - 1 "9:[" Recipient is type direct "1:-6" In the original example, the "4: h'6f75722d736563726574'" is a key = identifier for the direct key to be used. We still need to define a sequence number, but that is going to be = dependent in part on how the key is identified/derived. I would make it = part of the KDF context process if you derive a key from the shared = secret rather than being a property of the message if you use the key = directly. The other question, is the sequence number part of the COSE = structure or part of the CoAP structure needs to be addressed as well. >=20 > Ciao > Hannes From nobody Fri Aug 28 11:12:01 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9711B3410 for ; Fri, 28 Aug 2015 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDKbPdepXeDF for ; Fri, 28 Aug 2015 11:11:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319431B3023 for ; Fri, 28 Aug 2015 11:11:59 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A36352CA4E; Fri, 28 Aug 2015 11:11:58 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , "'Hannes Tschofenig'" References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> <55E058A9.5040404@gmx.net> <55E0603E.8090409@tzi.org> In-Reply-To: <55E0603E.8090409@tzi.org> Date: Fri, 28 Aug 2015 11:09:47 -0700 Message-ID: <020501d0e1bc$b9f02a10$2dd07e30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJn36g0b++GHPEUf65M22awuFXaxwDUaryiAcasB3YB7p+QhJzPbALA Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:12:00 -0000 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Friday, August 28, 2015 6:21 AM > To: Hannes Tschofenig > Cc: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 >=20 > Hannes Tschofenig wrote: > > I don't understand what this line "9:[{ 3:{1:-6}}]" means. >=20 > In the context of >=20 > { 1:3, > 2:{1:15}, > 4:"This is the content.", > 10:h'd9afa663dd740848', > 9:[{ 3:{1:-6}}] > } >=20 > it means that this map has an entry with a key of integer 9, and a = value that is an > array with a single map in it, which maps 3 to another map, which maps = 1 to -6. >=20 > The relevant translations are: >=20 >=20 > | recipients | 9 | For COSE_encrypt and COSE_mac = | >=20 > | unprotected | 3 | Occurs in all structures = | >=20 > | alg | 1 | int / | COSE | Integers are taken = | > | | | tstr | Algorithm | from table --POINT TO = | > | | | | Registry | REGISTRY-- = | >=20 > | direct | -6 | Direct use of CEK | >=20 > (I'm not sure about the 2:{1:15} though.) This is 1- algorithm and then 15 - a random integer replacement for the = algorithm string. Jim >=20 > Anyway, this is a nice demonstration why we need a better = prettyprinter (which > I'm writing as we speak, by the way), as Mike pointed out. >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 28 12:31:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF861AC3E3 for ; Fri, 28 Aug 2015 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ0FgnJc9EkS for ; Fri, 28 Aug 2015 12:31:47 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF1E1ABD3F for ; Fri, 28 Aug 2015 12:31:47 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 69E1938F0D; Fri, 28 Aug 2015 12:31:46 -0700 (PDT) From: "Jim Schaad" To: "'Ludwig Seitz'" , References: <55DF394D.1020403@gmx.net> <55DFFC9E.3010602@sics.se> In-Reply-To: <55DFFC9E.3010602@sics.se> Date: Fri, 28 Aug 2015 12:29:35 -0700 Message-ID: <022e01d0e1c7$df96fc20$9ec4f460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJn36g0b++GHPEUf65M22awuFXaxwEpeAD8nOqCpZA= Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:31:48 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Ludwig Seitz > Sent: Thursday, August 27, 2015 11:16 PM > To: cose@ietf.org > Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 >=20 > Hi Jim, >=20 > a few nitpicks from me: >=20 > Section 1.4 "... choice data items ..." should be "... chose data = items ..." Got it >=20 >=20 > Section 3. 3rd para "a common connical encoding" should be "a common > cannonical encoding" i guess Got it=20 >=20 > Section 4: > I'd rather reference the definition of 'Headers' instead of the > definition of 'protected' and 'unprotected' in the last two CDDLs. = Same > goes for sections 5 and 6. I would agree with this, but currently the CDDL is not a normative for = the document. As such there is a balance that needs to be reached between = what the text says and what the CDDL is. If CDDL were farther along in the process, I would love to make it normative. I like formal language in documents because it can be automated. As such we cannot really do = this. >=20 > Section 5: > "In COSE, the same techniques and structures for encrypting both the > plain text and the keys used to protect the text." >=20 > This sentence is missing a word. Perhaps "... keys are used ..."? This paragraph is gone in the next version. >=20 > Section 8: > "in the worst case it because the same as doing a singature with = appendix. " >=20 > s/because/becomes/ Got it >=20 > Section 12.1.2 > "One unpredictable manner than can be used is to use the HKDF function > to generate the IV." >=20 > s/than/that/ Got it >=20 >=20 > Appendix B, Second bullet list jumps from Level 1 to Level 3 for no > apparent reason (or I'm just not getting it). Editor typo. Fixed. Jim >=20 >=20 > Regards, > Ludwig >=20 > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se From nobody Fri Aug 28 14:37:54 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F811A8A3C for ; Fri, 28 Aug 2015 14:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvTQXONKPV_1 for ; Fri, 28 Aug 2015 14:37:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6F81A8871 for ; Fri, 28 Aug 2015 14:37:49 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 21:37:48 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0243.020; Fri, 28 Aug 2015 21:37:48 +0000 From: Mike Jones To: Carsten Bormann , Hannes Tschofenig Thread-Topic: [COSE] Comments for draft-ietf-cose-msg-03 Thread-Index: AQHQ4OScitzIMWZSvEWY67mYt4dY2Z4gTnoAgAEPeICAAAkKAIAAioXQ Date: Fri, 28 Aug 2015 21:37:48 +0000 Message-ID: References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> <55E058A9.5040404@gmx.net> <55E0603E.8090409@tzi.org> In-Reply-To: <55E0603E.8090409@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:zpsvah1PeNQTFC9DVOCzZMOB4txdK24QRixXNl+7tEOsUjL8r05ag1sad1fWt0YXiLeIC51NBR9QL80NvepHqWcr7tKXwWcAACw+zCHvoIHSfdLamCAL2lrJk+ttAp+HsxcowozdgA2q6eZxehO/7g==; 24:jCCFc5NFTiLOM/aqXe9t6hhOTJ/FaL12GbCjhU4l5C1fqy4pegF/ETdAi68kKCRUf+8gzOgLkrqg0wwxXfLpPvgY0fMQzZw2k3bV6kMbQvU=; 20:8nponKpA7o9DZPM14WvIWhBlr4Y+BspFeft6vE1sTTUQ6F0lMdy10GJmDys2xv6jk/pqUw3fiPlpGFdjDASBkg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(52034003)(24454002)(52314003)(13464003)(377454003)(199003)(189002)(2950100001)(8990500004)(74316001)(5001770100001)(5001830100001)(97736004)(106116001)(2656002)(86612001)(77096005)(189998001)(4001540100001)(10290500002)(93886004)(102836002)(19580405001)(5003600100002)(15975445007)(230783001)(5001860100001)(10400500002)(81156007)(19580395003)(5001960100002)(5005710100001)(105586002)(10090500001)(54356999)(86362001)(33656002)(87936001)(575784001)(76176999)(62966003)(99286002)(77156002)(68736005)(92566002)(106356001)(46102003)(122556002)(5004730100002)(5002640100001)(40100003)(50986999)(5007970100001)(76576001)(101416001)(64706001)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2015 21:37:48.4501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:37:53 -0000 VGhhbmtzIGZvciB3b3JraW5nIG9uIHRoZSBiZXR0ZXIgcHJldHR5LXByaW50ZXIsIENhcnN0ZW4u ICBBcyB5b3UgY2FuIHRlbGwsIGFib3V0IGhhbGYgb2YgdGhpcyB0aHJlYWQgd291bGRuJ3QgZXZl biBleGlzdCBpZiB0aGUgb3V0cHV0IGluIHRoZSBzcGVjIHdhcyBzdWZmaWNpZW50bHkgYW5ub3Rh dGVkLiA6LSkNCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IENPU0UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJz dGVuIEJvcm1hbm4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDI4LCAyMDE1IDY6MjEgQU0NClRvOiBI YW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBKaW0gU2No YWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgY29zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtDT1NFXSBDb21tZW50cyBmb3IgZHJhZnQtaWV0Zi1jb3NlLW1zZy0wMw0KDQpIYW5uZXMgVHNj aG9mZW5pZyB3cm90ZToNCj4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBsaW5lICI5Olt7 IDM6ezE6LTZ9fV0iIG1lYW5zLg0KDQpJbiB0aGUgY29udGV4dCBvZg0KDQp7ICAxOjMsDQogICAy OnsxOjE1fSwNCiAgIDQ6IlRoaXMgaXMgdGhlIGNvbnRlbnQuIiwNCiAgIDEwOmgnZDlhZmE2NjNk ZDc0MDg0OCcsDQogICA5Olt7IDM6ezE6LTZ9fV0NCn0NCg0KaXQgbWVhbnMgdGhhdCB0aGlzIG1h cCBoYXMgYW4gZW50cnkgd2l0aCBhIGtleSBvZiBpbnRlZ2VyIDksIGFuZCBhIHZhbHVlIHRoYXQg aXMgYW4gYXJyYXkgd2l0aCBhIHNpbmdsZSBtYXAgaW4gaXQsIHdoaWNoIG1hcHMgMyB0byBhbm90 aGVyIG1hcCwgd2hpY2ggbWFwcyAxIHRvIC02Lg0KDQpUaGUgcmVsZXZhbnQgdHJhbnNsYXRpb25z IGFyZToNCg0KDQogICB8IHJlY2lwaWVudHMgIHwgOSAgICAgIHwgRm9yIENPU0VfZW5jcnlwdCBh bmQgQ09TRV9tYWMgICAgICAgICAgICAgIHwNCg0KICAgfCB1bnByb3RlY3RlZCB8IDMgICAgICB8 IE9jY3VycyBpbiBhbGwgc3RydWN0dXJlcyAgICAgICAgICAgICAgICAgICB8DQoNCiAgIHwgYWxn ICAgICAgfCAxICAgICB8IGludCAvICAgIHwgQ09TRSAgICAgICAgfCBJbnRlZ2VycyBhcmUgdGFr ZW4gICAgfA0KICAgfCAgICAgICAgICB8ICAgICAgIHwgdHN0ciAgICAgfCBBbGdvcml0aG0gICB8 IGZyb20gdGFibGUgLS1QT0lOVCBUTyB8DQogICB8ICAgICAgICAgIHwgICAgICAgfCAgICAgICAg ICB8IFJlZ2lzdHJ5ICAgIHwgUkVHSVNUUlktLSAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAg ICAgICAgfCBkaXJlY3QgfCAtNiAgICB8IERpcmVjdCB1c2Ugb2YgQ0VLIHwNCg0KKEknbSBub3Qg c3VyZSBhYm91dCB0aGUgMjp7MToxNX0gdGhvdWdoLikNCg0KQW55d2F5LCB0aGlzIGlzIGEgbmlj ZSBkZW1vbnN0cmF0aW9uIHdoeSB3ZSBuZWVkIGEgYmV0dGVyIHByZXR0eXByaW50ZXIgKHdoaWNo IEknbSB3cml0aW5nIGFzIHdlIHNwZWFrLCBieSB0aGUgd2F5KSwgYXMgTWlrZSBwb2ludGVkIG91 dC4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNPU0VAaWV0Zi5vcmcNCmh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm JTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmY29zZSUwYSZkYXRhPTAxJTdj MDElN2NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3Y2I1MzdjMzRkNzVlMDQ2ZDBjOWMy MDhkMmFmYWI4Y2NhJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh PXFKZUcweHZqbWlkUWsyM3pOcXhydWVSY0hLODVEUkIyYWlpVkZCTDElMmI3dyUzZA0K From nobody Fri Aug 28 14:58:04 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE41ACE66; Fri, 28 Aug 2015 14:58:00 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLfi4CYFWtrR; Fri, 28 Aug 2015 14:57:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 702E81A88FC; Fri, 28 Aug 2015 14:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150828215759.11444.9800.idtracker@ietfa.amsl.com> Date: Fri, 28 Aug 2015 14:57:59 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-04.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:58:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption Working Group of the IETF. Title : CBOR Encoded Message Syntax Authors : Jim Schaad Brian Campbell Filename : draft-ietf-cose-msg-04.txt Pages : 86 Date : 2015-08-28 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies how to do signatures, message authentication codes and encryption using this data format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 28 15:22:53 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6291ACD01 for ; Fri, 28 Aug 2015 15:22:53 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwIHU_WrY0ZV for ; Fri, 28 Aug 2015 15:22:51 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A711AC419 for ; Fri, 28 Aug 2015 15:22:51 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5DC1738F52 for ; Fri, 28 Aug 2015 15:22:51 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 28 Aug 2015 15:20:39 -0700 Message-ID: <026e01d0e1df$c5a1db60$50e59220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdDh35flglI1XZ3mTgeWkL72RL8zIQ== Archived-At: Subject: [COSE] draft -04 published X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 22:22:53 -0000 I have pushed up the -04 version of the message document. This version pulls in the change to using arrays at the top level, changes to algorithm sections and the reviews that we have received. Jim From nobody Fri Aug 28 15:39:10 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FABE1ACE24 for ; Fri, 28 Aug 2015 15:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.508 X-Spam-Level: X-Spam-Status: No, score=-4.508 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC86uM3mKIbP for ; Fri, 28 Aug 2015 15:39:06 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99201A9149 for ; Fri, 28 Aug 2015 15:39:06 -0700 (PDT) Date: Fri, 28 Aug 2015 15:39:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1440801545; bh=X78yVXH7kiNF5bL3sM2FrG0/E+MEx2N1ZrsetAyTAMQ=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=VEqgSKka1IGtt6INq47q06yd3UE4r5OAZX/VYVNV2iEy5C/O0rFE+2yZSxqUbSGoZ 72RoOfaIe0QVdu3II5V0SNVhgo3Qffk02JENB5DEdIhzZnhy5L6ZkDVoL2AlePK1oJ e1Cm0E1TlU4i7oUjB0T0Om6xJLXFuQJkqCxVVglQ= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55e0e3093d3be_655a3f9c39f592bc5717dd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Assign integers to all algorithms (#8) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 22:39:08 -0000 ----==_mimepart_55e0e3093d3be_655a3f9c39f592bc5717dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I want to make a pass through the document and do "final" assignment of algorithm identifiers. In order to do this we first need to make a pass through the document and make sure that the algorithms defined by the document are those that need to be present. And potentially to remove algorithms that nobody (or maybe nobody but me) believe need to be present. Please review the set of algorithms that this document defines and send information to the list if you see algorithms which are not defined that you think should be in the standard group and also if there are algorithms that are defined that you think should not be defined. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/8 ----==_mimepart_55e0e3093d3be_655a3f9c39f592bc5717dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I want to make a pass through the document and do "final" assignment of algorithm identifiers. In order to do this we first need to make a pass through the document and make sure that the algorithms defined by the document are those that need to be present. And potentially to remove algorithms that nobody (or maybe nobody but me) believe need to be present.

Please review the set of algorithms that this document defines and send information to the list if you see algorithms which are not defined that you think should be in the standard group and also if there are algorithms that are defined that you think should not be defined.

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

----==_mimepart_55e0e3093d3be_655a3f9c39f592bc5717dd-- From nobody Fri Aug 28 22:22:31 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387911B2AB4 for ; Fri, 28 Aug 2015 22:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkC44O2w3hFl for ; Fri, 28 Aug 2015 22:22:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B771ABD38 for ; Fri, 28 Aug 2015 22:22:27 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-38-55e141913b09 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B7.1B.27359.19141E55; Sat, 29 Aug 2015 07:22:25 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Sat, 29 Aug 2015 07:22:24 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Comments for draft-ietf-cose-msg-03 Thread-Index: AQHQ4OSbYQV3kisjwkWFHRkW66PXAp4gLPMAgAEPeICAATcyAA== Date: Sat, 29 Aug 2015 05:22:24 +0000 Message-ID: References: <55DF394D.1020403@gmx.net> <013201d0e108$2325eb60$6971c220$@augustcellars.com> <55E058A9.5040404@gmx.net> In-Reply-To: <55E058A9.5040404@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rnei48NQg6M9qhbTtk5ltVi68x6r xerp39kcmD02zpnO5rF40342jyVLfjIFMEdx2aSk5mSWpRbp2yVwZbzbsZyxYI5+xdN531ka GBv0uhg5OSQETCTmP17FDmGLSVy4t56ti5GLQ0jgKKPErNePWCGcxYwSf8/OYQGpYhNwkXjQ 8IgJxBYRqJR48agbqIiDQ1jAXOLSTimIsIXEiZYOZgjbSaJr7zGwVhYBVYn9LzvYQMp5gWq2 HyoDCQsBTVl1az5YOaeAusT0CwvByhmB7vl+ag3YJmYBcYlbT+YzQdwpILFkz3lmCFtU4uXj f6wgtqiAnsTK601sEHEliRXbLzGCrGIW0JRYv0sfYoy1xOZNL5khbEWJKd0PwV7nFRCUODnz CcsERvFZSLbNQuiehaR7FpLuWUi6FzCyrmIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjL6D W34b7GB8+dzxEKMAB6MSD6+C0MNQIdbEsuLK3EOM0hwsSuK8zUwPQoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwsk05puDtaC/2bmXCt4d5mzsfLm+Q77GV8ZSI53xoLXjTN3b7k53v1ohX rGC/JjxJa4+52pSdq502v1+z7duvyU3e4gXnTTabTa9flcc2UzP4yNpTH3zy2idPDQlSEWQu EulnfDL51JYV7zuNVtU8FHFXuWnVOEGGobryQGnUI0PzN7ZOWiVblFiKMxINtZiLihMBD7Ed 5J8CAAA= Archived-At: Subject: Re: [COSE] Comments for draft-ietf-cose-msg-03 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 05:22:30 -0000 SGkgSGFubmVzLCBKaW0sDQoNCk9uIDIwMTUtMDgtMjggMTQ6NDgsICJIYW5uZXMgVHNjaG9mZW5p ZyIgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KDQoNCj4+Pg0KPj4+IEZvciBh biBJb1QgY29udGV4dCBJIHdvdWxkIGltYWdpbmUgdGhhdCB0aGUgYWxnb3JpdGhtIGFuZCB0aGUg a2V5IGhhcw0KPj4+YmVlbg0KPj4+IGFncmVlZCBiZXR3ZWVuIHRoZSBzZW5kZXIgYW5kIHRoZSBy ZWNlaXZlciB1c2luZyBzb21lIGtleSBtYW5hZ2VtZW50DQo+Pj5Qcm90b2NvbCANCg0KDQpbR1M6 IEluIHRoZSBBQ0UgYXJjaGl0ZWN0dXJlIENsaWVudCBhbmQgUmVzb3VyY2UgU2VydmVyIGRvIG5v dCBuZWNlc3NhcmlseQ0KaGF2ZSBhIHByZS1leGlzdGluZyBzZWN1cml0eSByZWxhdGlvbnNoaXAg dG8gZWFjaCBvdGhlci4gRm9yIGV4YW1wbGU6DQoNCi0gQyBhbmQgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgY29tbXVuaWNhdGUgc2VjdXJlbHksIHNheSwgdXNpbmcgRFRMUyBiYXNlZA0Kb24gY2VydGlm aWNhdGVzOyANCi0gUlMgYW5kIEFTIHNoYXJlIGEgc3ltbWV0cmljIGtleSBLMTsNCg0KQnV0IHdo ZW4gQyBjb250YWN0cyBSUyBmb3IgdGhlIGZpcnN0IHRpbWUsIGUuZy4gaW4gdGhlIFB1c2ggYXV0 aG9yaXphdGlvbg0Kc2NoZW1lLCBSUyBtYXkgbmV2ZXIgaGF2ZSBoZWFyZCBvZiBDIGJlZm9yZS4g RS5nLiBDIG1heSBQT1NUIHRvIFJTIGEgQ09TRQ0Kb2JqZWN0IChhY2Nlc3MgdG9rZW4pIGdlbmVy YXRlZCBieSBBUy4gQyBjYW4gdGhlbiB2ZXJpZnkgdGhlIG9iamVjdCB1c2luZw0KSzEgKG9yIHNv bWUga2V5IGRlcml2ZWQgZnJvbSBLMSkgYW5kIGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiBpbiB0 aGUNCm9iamVjdCBleHRyYWN0IG9yIGRlcml2ZSBhIGtleSBLMiAoKyBrZXkgaWRlbnRpZmllcikg Zm9yIHVzZSB3aXRoIEMuDQoNCkMgY291bGQgdGhlbiwgb3IgaW4gdGhlIHNhbWUgZXhjaGFuZ2Us IG1ha2UgYSByZXF1ZXN0IHRvIHNvbWUgUmVzb3VyY2Ugb24NClJTLCB0aGUgcmVxdWVzdCBiZWlu ZyB3cmFwcGVkIGluIGFub3RoZXIgQ09TRSBvYmplY3QgKE9TQ09BUCkgcHJvdGVjdGVkDQp3aXRo IEsyLiBUaGUgYWxnb3JpdGhtIHVzZWQgY291bGQgYWxzbyBiZSBkaWZmZXJlbnQgZnJvbSB0aGF0 IG9mIHRoZSBmaXJzdA0Kb2JqZWN0LiBLMiwga2V5IGlkZW50aWZpZXIgYW5kIGFsZ29yaXRobSBj b3VsZCBiZSBwcm92aWRlZCBieSBBUyB0byBDLg0KDQpTbywgaW5mb3JtYXRpb24gYWJvdXQga2V5 IGFuZCBhbGdvcml0aG0gaGFzIHRvIGNvbWUgZnJvbSBzb21lIHRydXN0ZWQNCnNvdXJjZSwgYnV0 IG5vdCBuZWNlc3NhcmlseSBhZ3JlZWQgYmV0d2VlbiBzZW5kZXIgYW5kIHJlY2VpdmVyIGJlZm9y ZWhhbmQuXQ0KDQoNCg0KDQo+Pj5hbmQgdGhlIGFwcHJvcHJpYXRlIGV4YW1wbGUgd291bGQgYmUg c29tZXRoaW5nIGxpa2U6DQo+Pj4NCj4+PiAgICB7DQo+Pj4gICAgICAxOiAzLA0KPj4+ICAgICAg MjogezQ6IDEsNjogMX0sDQo+Pj4gICAgICA0OiAiVGhpcyBpcyB0aGUgY29udGVudC4iLA0KPj4+ ICAgICAgMTA6IGgnZDlhZmE2NjNkZDc0MDg0OCcNCj4+PiAgICB9DQo+Pj4NCj4+PiAoTm90ZSB0 aGF0IEkgZG9uJ3QgcmVhbGx5IGtub3cgd2hldGhlciB0aGlzIGlzIHRoZSBlbmNvZGluZyB5b3UN Cj4+PmVudmlzaW9uIGZvciB0aGUNCj4+PiBoZWFkZXIgcGFyYW1ldGVycy4pDQo+PiANCj4+IFRo ZXJlIGlzIGFuIG9uLWFnYWluLCBvZmYtYWdhaW4gZGlzY3Vzc2lvbiBhYm91dCBtYWtpbmcgZGly ZWN0IGtleQ0KPj5tYW5hZ2VtZW50IHByaXZpbGVnZWQgaW4gdGVybXMgb2Yga2V5IG1hbmFnZW1l bnQuICBQZXJzb25hbGx5LCBJIGFtDQo+PmFnYWluc3QgdGhpcyBhcyBJIHdvdWxkIHByZWZlciB0 byBzZWUgZXZlcnl0aGluZyBiZSB1bmlmb3JtIGluIGFsbCBjYXNlcw0KPj5hbmQgSSBkb24ndCBr bm93IHRoYXQgeW91IHdpbiBlbm91Z2ggYnkgbWFraW5nIHRoaW5ncyBzcGVjaWFsLiAgUGFydCBv Zg0KPj50aGUgcXVlc3Rpb24gaXMgYXJlIHlvdSBldmVyIGdvaW5nIHRvIGRvIGFueXRoaW5nIGV4 Y2VwdCBkaXJlY3Qga2V5Lg0KDQoNCltHUzogSW4gbXkgZXhhbXBsZSBhYm92ZSwgZm9yIHRoZSBm aXJzdCBvYmplY3QgeW91IHdvdWxkIHByb2JhYmx5IG5vdCB3YW50DQp0byB1c2UgYSBsb25nIHRl cm0ga2V5LiBGb3IgdGhlIHNlY29uZCBvYmplY3QgaXQgbWF5IGJlIGRpcmVjdCBrZXksIHdoZXJl DQp0aGUgZmlyc3Qgb2JqZWN0IGlzIHVzZWQgdG8gY3JlYXRlIHRoZSBkaXJlY3Qga2V5IHRvIHVz ZSB3aXRoIHNlY29uZC4gQnV0DQppZiB3ZSB3b3VsZCBhZGQgZm9yd2FyZCBzZWNyZWN5IHcuci50 LiBBUywgSSBleHBlY3Qgd2Ugd291bGQgaGF2ZSB0bw0KaW5jbHVkZSBzb21lIGRlcml2YXRpb24u IF0NCg0KDQo+PiAgRnJvbSBhIHNlY3VyaXR5IHBvaW50IG9mIHZpZXcsIEkgd291bGQgYXJndWUg dGhhdCB5b3UgYXJlIG11Y2ggYmV0dGVyDQo+Pm9mZiBkb2luZyBhIEtERiBvbiBhIHNoYXJlZCBz ZWNyZXQgYW5kIHVzaW5nIHRoYXQgb24gYSBwZXIgbWVzc2FnZSBiYXNpcw0KPj5yYXRoZXIgdGhh biBoYXZpbmcgYSBrZXkgdGhhdCBpcyB1c2VkIHVudGlsIHNvbWUgZXh0ZXJuYWwgZXZlbnQgb2Nj dXJzLg0KPj4gDQo+SGVyZSB3ZSBhZ2FpbiBuZWVkIHRvIGxvb2sgYXQgdGhlIHVzZSBjYXNlcyB3 ZSBhcmUgdHJ5aW5nIHRvIHNvbHZlLg0KPkhhcHB5IHRvIHByb3ZpZGUgc29tZSBpbnB1dCBoZXJl Lg0KPg0KPkluIG15IHVzZSBjYXNlcywgdGhlcmUgaXMgYW5vdGhlciBzZXBhcmF0ZSBrZXkgbWFu YWdlbWVudCBzb2x1dGlvbiBpbg0KPnVzZSAoc3VjaCBhcyBPTUEgTFdNMk0sIG9yIHRoZSBzdHVm ZiB3ZSBhcmUgZGV2ZWxvcGluZyBpbiBBQ0UpLiBUaGUga2V5cw0KPisgcGFyYW1ldGVycyBhcmUg dGhlbiBhdmFpbGFibGUgdG8gdGhlIGNvbW11bmljYXRpb24gcGFydGllcyBhbmQgb25seQ0KPm5l ZWQgdG8gYmUgYXBwbGllZCB0byB0aGUgQ0JPUiBwYXlsb2FkICh1c2luZyBDT1NFKS4NCj4NCj4+ IEkgd291bGQgYWxzbyB0ZW5kIHRvIG1ha2UgdGhlIHNhbWUgYXJndW1lbnQgYWJvdXQgbWFraW5n IHRoZSBhbGdvcml0aG0NCj4+YmUgaW1wbGljaXQgcmF0aGVyIHRoYW4gZXhwbGljaXQuDQoNCg0K W0dTOiBJbiB0aGUgZXhhbXBsZSBhYm92ZSB0aGUgYWxnb3JpdGhtIGluIHRoZSBzZWNvbmQgQ09T RSBvYmplY3QgbWF5IGhhdmUNCnRvIGJlIGV4cGxpY2l0LiBBbHRlcm5hdGl2ZWx5IGluZm9ybWF0 aW9uIGFib3V0IGFsZ29yaXRobSB0byB1c2Ugd2l0aCBLMg0KbWF5IGJlIGNhcnJpZWQgaW4gdGhl IGZpcnN0IENPU0Ugb2JqZWN0LiBdDQoNCg0KR8O2cmFuDQoNCg0KPj5XaGlsZSBwb3NzaWJsZSwg SSBkb24ndCBrbm93IHRoYXQgdGhpcyBpcyByZWFsbHkgYSBnb29kIGlkZWEuICBJIGhhdmUNCj4+ Z2VuZXJhbGx5IGZvdW5kIGl0IHRvIGJlIGEgcHJvYmxlbSBsYXR0ZXIgb24gaW4gdGhlIHByb2Nl c3MuICBIb3dldmVyLA0KPj50aGUgaW1wbGVtZW50YXRpb25zIHRoYXQgSSBoYXZlIGRvbmUgd291 bGQgYWxsb3cgZm9yIHRoYXQgdG8gaGFwcGVuLiAgSQ0KPj5qdXN0IGRvbid0IGNhcmUgZm9yIGl0 IGFzIGEgc3VnZ2VzdGVkIHdheSB0byB0cmF2ZWwuDQo+PiANCj4+IFRoaXMgbWVhbnMgdGhhdCBJ IHdvdWxkIGJlIGxvb2tpbmcgbW9yZSBhdA0KPj4geyAgMTozLA0KPj4gICAgMjp7MToxNX0sDQo+ PiAgICA0OiJUaGlzIGlzIHRoZSBjb250ZW50LiIsDQo+PiAgICAxMDpoJ2Q5YWZhNjYzZGQ3NDA4 NDgnLA0KPj4gICAgOTpbeyAzOnsxOi02fX1dDQo+PiB9DQo+PiANCj4+IEkgYW0gbm90IHN1cmUg d2hhdCB5b3UgYXJlIGxvb2tpbmcgYXQgZm9yIHRoZSB0d28gcGFyYW1ldGVycyB0aGF0IHlvdQ0K Pj5pbmNsdWRlZCBpbiB5b3VyIGV4YW1wbGUuICBJZiB0aGV5IGFyZSBqdXN0IHBsYWNlIGhvbGRl cnMgdGhlbiB5b3UgY291bGQNCj4+aW5jbHVkZSB0aGVtIGFzIHdlbGwuICBJIG9taXQgdGhlIEtJ RCBwYXJhbWV0ZXIgZnJvbSB0aGUgcmVjaXBpZW50DQo+PnN0cnVjdHVyZSBzaW5jZSB0aGF0IGNh biBiZSBpbXBsaWVkIHJlbGF0aXZlbHkgZWFzaWx5IGlmIHlvdSBvbmx5IGhhdmUNCj4+b25lIGRp YWxvZyBnb2luZyBvbiBiZXR3ZWVuIHRoZSB0d28gZW50aXRpZXMuICBJZiB5b3UgaGF2ZSBtdWx0 aXBsZQ0KPj5kaWFsb2dzIHRoZW4gaW5jbHVkZSBhIEtJRCBpcyB1c2VmdWwuDQo+DQo+SW4gbXkg ZXhhbXBsZSBJIGFtIHRyeWluZyB0byBhZGQgdHdvIGZpZWxkcywgbmFtZWx5IGEgJ2tpZCcgYW5k IGENCj5zZXF1ZW5jZSBudW1iZXIuIEJvdGggdmFsdWVzIGFyZSBzZXQgdG8gJzEnLg0KPg0KPkkg ZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoaXMgbGluZSAiOTpbeyAzOnsxOi02fX1dIiBtZWFucy4N Cj4NCj5DaWFvDQo+SGFubmVzDQo+DQoNCg== From nobody Sat Aug 29 00:16:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9581B373D for ; Sat, 29 Aug 2015 00:16:40 -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 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 F7owE-jA310k for ; Sat, 29 Aug 2015 00:16:38 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D831B374C for ; Sat, 29 Aug 2015 00:16:35 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id CF2C29001C; Sat, 29 Aug 2015 10:16:32 +0300 (EEST) Date: Sat, 29 Aug 2015 10:16:32 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20150829071632.GA8427@LK-Perkele-VII> References: <026e01d0e1df$c5a1db60$50e59220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <026e01d0e1df$c5a1db60$50e59220$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] draft -04 published X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 07:16:40 -0000 On Fri, Aug 28, 2015 at 03:20:39PM -0700, Jim Schaad wrote: > I have pushed up the -04 version of the message document. This version > pulls in the change to using arrays at the top level, changes to algorithm > sections and the reviews that we have received. Oh, regarding issue #3, TLS does not truncate the zeroes for ECDH ("leading zeros found in this octet string MUST NOT be truncated."), maybe you were thinking about DH, where leading string truncation does happen? Now for some reviewing: 1) There is still one reference to "Key management" in section 1.5. 2) There have been many vulernabilies in JOSE implementations due to implementations using cryptographic keys with wrong algorithms (e.g. RSA public key as MAC key). And it looks like the document doesn't say anything about these types of problems (e.g. by requiring to check that alg of message is consistent with kty of key). 3) Regarding questionable header parameters: - URL-type things: jku and x5u... URL retretival has nontrivial security concerns. - X509-type things: x5c, x5t, x5t#SHA256, x5u: These assume X.509, which is complicated to the point that even full-powered systems have problems implementing it. - jwk: Apparently this header is used with JOSE, so I would imagine equivalent usecases do apply here too. - zip: Constrained systems probably don't appreciate compression, but it could be nice in full-powered systems. 4) The prose descriptions of structures don't seem to say what order the fields are in (looks to be order listed). 5) What does it mean to omit the ciphertext field in encryption structure (how is that encoded)? Also, looks like other messages allow omitting payload? 6) The ECDSA section should explicitly suggest P-256/P-384/P-521 instead of arbitrary-looking curves of given bitlength. 7) ECDSA with Curve25519? I'm getting bad flashbacks... :-) 8) The CDDL description in section 11.2 looks to use arrays, yet there is table of labels? 9) Looks like latest cfrg-curves renames Curve25519 and Curve448 to X25519 and X448 (and the document is in RGLC). -Ilari From nobody Sat Aug 29 11:24:39 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C651B34D7 for ; Sat, 29 Aug 2015 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOd5dsmtOYNr for ; Sat, 29 Aug 2015 11:24:36 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262D01B349F for ; Sat, 29 Aug 2015 11:24:36 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 384C82CA39; Sat, 29 Aug 2015 11:24:35 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" References: <026e01d0e1df$c5a1db60$50e59220$@augustcellars.com> <20150829071632.GA8427@LK-Perkele-VII> In-Reply-To: <20150829071632.GA8427@LK-Perkele-VII> Date: Sat, 29 Aug 2015 11:22:24 -0700 Message-ID: <034801d0e287$a7674650$f635d2f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQENUre+FXEbbNplQCvcOaGIEYgULwIvAbYQn5js5aA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] draft -04 published X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 18:24:38 -0000 > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Saturday, August 29, 2015 12:17 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] draft -04 published >=20 > On Fri, Aug 28, 2015 at 03:20:39PM -0700, Jim Schaad wrote: > > I have pushed up the -04 version of the message document. This > > version pulls in the change to using arrays at the top level, = changes > > to algorithm sections and the reviews that we have received. >=20 > Oh, regarding issue #3, TLS does not truncate the zeroes for ECDH = ("leading > zeros found in this octet string MUST NOT be truncated."), maybe you = were > thinking about DH, where leading string truncation does happen? Ah - I had not recently read the section on ECDH for TLS. Yes I was = thinking about DH when I created the issue. I know of the issue because = I have needed to deal with both of the encodings at different times. I = was not sure what TLS did for the NIST curves. I was sure that for the = new CFRG curves that leading zeros were not going to be stripped because = of the little endian encoding. Thanks for the correction. >=20 >=20 > Now for some reviewing: >=20 > 1) There is still one reference to "Key management" in section 1.5. I see this and will look at it. > 2) There have been many vulernabilies in JOSE implementations due to > implementations using cryptographic keys with wrong algorithms = (e.g. > RSA public key as MAC key). And it looks like the document doesn't > say anything about these types of problems (e.g. by requiring to > check that alg of message is consistent with kty of key). Issue is in the document and I will look for a good place to put text. How do you feel about requiring the algorithm field to be present in = keys since also helps to makes sure that keys are not mis-used. > 3) Regarding questionable header parameters: > - URL-type things: jku and x5u... URL retretival has nontrivial > security concerns. > - X509-type things: x5c, x5t, x5t#SHA256, x5u: These assume X.509, > which is complicated to the point that even full-powered systems > have problems implementing it. > - jwk: Apparently this header is used with JOSE, so I would imagine > equivalent usecases do apply here too. > - zip: Constrained systems probably don't appreciate compression, > but it could be nice in full-powered systems. Brian is currently working on these issues and should respond. > 4) The prose descriptions of structures don't seem to say what order > the fields are in (looks to be order listed). I will put this into the document. Since we can't use CDDL as normative = this does need to be stated. > 5) What does it mean to omit the ciphertext field in encryption > structure (how is that encoded)? Also, looks like other messages > allow omitting payload? Yes, I missed this when I move from maps back to arrays. The correct = answer is that the type becomes (bstr or null) for the content fields. > 6) The ECDSA section should explicitly suggest P-256/P-384/P-521 > instead of arbitrary-looking curves of given bitlength. Yes, this should be restricted. > 7) ECDSA with Curve25519? I'm getting bad flashbacks... :-) I would be happy to use a different curve. I wanted to have a concrete = example so that people would understand what I was trying to say. I = have had problems describing this type of problem in the past because = people just could not understand what I was trying to say. Could you = suggest something? > 8) The CDDL description in section 11.2 looks to use arrays, yet > there is table of labels? Yes this is correct. The fields are placed in the protected and = unprotected maps for transportation and then encoded into the context = structure for doing the KDF. I will look to see if I missed something = here. > 9) Looks like latest cfrg-curves renames Curve25519 and Curve448 > to X25519 and X448 (and the document is in RGLC). Missed that change. Thanks for doing a review of the document. Jim >=20 >=20 > -Ilari From nobody Sat Aug 29 12:24:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637AD1A8850 for ; Sat, 29 Aug 2015 12:24:28 -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 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 vVNS999w9FxY for ; Sat, 29 Aug 2015 12:24:26 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97FD1A8781 for ; Sat, 29 Aug 2015 12:24:24 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 3BB124040; Sat, 29 Aug 2015 22:24:21 +0300 (EEST) Date: Sat, 29 Aug 2015 22:24:21 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20150829192421.GA17705@LK-Perkele-VII> References: <026e01d0e1df$c5a1db60$50e59220$@augustcellars.com> <20150829071632.GA8427@LK-Perkele-VII> <034801d0e287$a7674650$f635d2f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <034801d0e287$a7674650$f635d2f0$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] draft -04 published X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 19:24:28 -0000 On Sat, Aug 29, 2015 at 11:22:24AM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > > Sent: Saturday, August 29, 2015 12:17 AM > > To: Jim Schaad > > Cc: cose@ietf.org > > Subject: Re: [COSE] draft -04 published > > > > On Fri, Aug 28, 2015 at 03:20:39PM -0700, Jim Schaad wrote: > > > I have pushed up the -04 version of the message document. This > > > version pulls in the change to using arrays at the top level, changes > > > to algorithm sections and the reviews that we have received. > > > > > > > Now for some reviewing: > > > 2) There have been many vulernabilies in JOSE implementations due to > > implementations using cryptographic keys with wrong algorithms (e.g. > > RSA public key as MAC key). And it looks like the document doesn't > > say anything about these types of problems (e.g. by requiring to > > check that alg of message is consistent with kty of key). > > Issue is in the document and I will look for a good place to put text. > How do you feel about requiring the algorithm field to be present in keys since also helps to makes sure that keys are not mis-used. > > > 7) ECDSA with Curve25519? I'm getting bad flashbacks... :-) > > I would be happy to use a different curve. I wanted to have a > concrete example so that people would understand what I was > trying to say. I have had problems describing this type of > problem in the past because people just could not understand > what I was trying to say. Could you suggest something? If you want an example of curve that is the same length as secp256r1 ("NIST P-256") but different, there is secp256k1. That curve is additionally much more likely to be used with ECDSA than Curve25519. AFAIK, ECDSA-secp256k1 is at least used in the wild by one piece of software, instead of being confined to proof of concept code. :-) > > 8) The CDDL description in section 11.2 looks to use arrays, yet > > there is table of labels? > > Yes this is correct. The fields are placed in the protected and > unprotected maps for transportation and then encoded into the context > structure for doing the KDF. I will look to see if I missed > something here. Looking at the CDDL (because the text doesn't say what types the composites are), PartyUInfo, PartyVInfo and SuppPubInfo look to be arrays ([]), not maps ({}) or groups (()). But nevertheless, those seem to have labels specified, like those were maps (except SuppPubInfo, which doesn't). That those three should be maps that are octet-string wrapped would certainly make sense assuming Cocat KDF takes in those kinds of parameters as octet strings. -Ilari From nobody Sat Aug 29 13:14:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7FC1B3563 for ; Sat, 29 Aug 2015 13:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCH5p9-X48H7 for ; Sat, 29 Aug 2015 13:14:17 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEBE1B2FF7 for ; Sat, 29 Aug 2015 13:14:17 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3ADB62CA09; Sat, 29 Aug 2015 13:14:16 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" References: <026e01d0e1df$c5a1db60$50e59220$@augustcellars.com> <20150829071632.GA8427@LK-Perkele-VII> <034801d0e287$a7674650$f635d2f0$@augustcellars.com> <20150829192421.GA17705@LK-Perkele-VII> In-Reply-To: <20150829192421.GA17705@LK-Perkele-VII> Date: Sat, 29 Aug 2015 13:12:05 -0700 Message-ID: <037001d0e296$f9c25a20$ed470e60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQENUre+FXEbbNplQCvcOaGIEYgULwIvAbYQAW2UnbkBU7p5c5+DBO9Q Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] draft -04 published X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 20:14:18 -0000 > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Saturday, August 29, 2015 12:24 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] draft -04 published >=20 > On Sat, Aug 29, 2015 at 11:22:24AM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > > > Sent: Saturday, August 29, 2015 12:17 AM > > > To: Jim Schaad > > > Cc: cose@ietf.org > > > Subject: Re: [COSE] draft -04 published > > > > > > On Fri, Aug 28, 2015 at 03:20:39PM -0700, Jim Schaad wrote: > > > > I have pushed up the -04 version of the message document. This > > > > version pulls in the change to using arrays at the top level, > > > > changes to algorithm sections and the reviews that we have = received. > > > > > > > > > > > Now for some reviewing: > > > > > 2) There have been many vulernabilies in JOSE implementations due = to > > > implementations using cryptographic keys with wrong algorithms = (e.g. > > > RSA public key as MAC key). And it looks like the document = doesn't > > > say anything about these types of problems (e.g. by requiring = to > > > check that alg of message is consistent with kty of key). > > > > Issue is in the document and I will look for a good place to put = text. > > How do you feel about requiring the algorithm field to be present in = keys since > also helps to makes sure that keys are not mis-used. > > > > > 7) ECDSA with Curve25519? I'm getting bad flashbacks... :-) > > > > I would be happy to use a different curve. I wanted to have a > > concrete example so that people would understand what I was trying = to > > say. I have had problems describing this type of problem in the = past > > because people just could not understand what I was trying to say. > > Could you suggest something? >=20 > If you want an example of curve that is the same length as secp256r1 = ("NIST P- > 256") but different, there is secp256k1. That curve is additionally = much more > likely to be used with ECDSA than Curve25519. Yes that is much better. Thanks >=20 > AFAIK, ECDSA-secp256k1 is at least used in the wild by one piece of = software, > instead of being confined to proof of concept code. > :-) >=20 > > > 8) The CDDL description in section 11.2 looks to use arrays, yet > > > there is table of labels? > > > > Yes this is correct. The fields are placed in the protected and > > unprotected maps for transportation and then encoded into the = context > > structure for doing the KDF. I will look to see if I missed > > something here. >=20 > Looking at the CDDL (because the text doesn't say what types the = composites > are), PartyUInfo, PartyVInfo and SuppPubInfo look to be arrays ([]), = not maps ({}) > or groups (()). >=20 > But nevertheless, those seem to have labels specified, like those were = maps > (except SuppPubInfo, which doesn't). >=20 > That those three should be maps that are octet-string wrapped would = certainly > make sense assuming Cocat KDF takes in those kinds of parameters as = octet > strings. Ok - I need to have a more explicit example someplace that people can = look at. The maps that I was referring to are the protected and unprotected maps = in the COSE_Sign, COSE_Encrypt, COSE_Mac, and COSE_signature. This is = distinct from the context structure. The context structure uses arrays = because it is easier to get a canonical encoding out of it than out of = maps. >=20 >=20 > -Ilari From nobody Sat Aug 29 13:27:14 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EF11A89F5 for ; Sat, 29 Aug 2015 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEHlsAVcfFW7 for ; Sat, 29 Aug 2015 13:27:11 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1D31A8A54 for ; Sat, 29 Aug 2015 13:27:11 -0700 (PDT) Date: Sat, 29 Aug 2015 13:27:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1440880030; bh=39zhbNbMDvG5/i7yaWJqpG/erMjcNnUB4CZXC6ElQ9Q=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Q08+INL99qRSthVWXiSxPIDRCfInzyRgnfr277rEWOYIlZqD3bCR5f5J1I7JDWeqO UrdI69QJtOkeaPo2YZlZWU80GJ0EdbU6K3Ik92lpewz1un6eShcqd0TqyP9bUXlAVG OkIVsPzgVnplF9qBdrRtdOcHuZWDaNa4yeov9uDU= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55e2159e10a6f_60c63f937f9572a01878f6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Do we remove leading zeros from a ECDH key agreement secret (#3) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 20:27:13 -0000 ----==_mimepart_55e2159e10a6f_60c63f937f9572a01878f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Input from Ilari tells me that while this is true in TLS for the DH algorithm, this is not true for the ECDH algorithm. This means that we can assume that leading zeros are not going to be removed in any situation. I don't think we need to document this fact. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/3#issuecomment-136045094 ----==_mimepart_55e2159e10a6f_60c63f937f9572a01878f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Input from Ilari tells me that while this is true in TLS for the DH algorithm, this is not true for the ECDH algorithm. This means that we can assume that leading zeros are not going to be removed in any situation. I don't think we need to document this fact.

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

----==_mimepart_55e2159e10a6f_60c63f937f9572a01878f6-- From nobody Sat Aug 29 13:43:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4A1B2A9B for ; Sat, 29 Aug 2015 13:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrYZ_kdJo4xg for ; Sat, 29 Aug 2015 13:43:03 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0711ACD11 for ; Sat, 29 Aug 2015 13:43:03 -0700 (PDT) Date: Sat, 29 Aug 2015 13:43:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1440880982; bh=d7qup7HWLk7s6sYoCJ8NWC89lAd0ccyZr7TPm4g3XRY=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=UQXKlqftgGj9YvIakK0rN1//2yCZPDUouaM2LLlFUWbFMLU8C9NOFo7zsuX/uZstK NJEB+UVAqFN4urvuTmiMNLU1pvO1CIxRWu9KaBeVzijtZ8IKk4pO+SW+yhN4X3E/dH GVbHQRnwtrKbCby66zLBPmEB2A7BgjY2LSioB1oA= From: Jim Schaad To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55e21956d1209_4f463fda40dfb2b8350177"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] CFRG document for Curve25519 and Goldilocks has odd shared secret issue (#9) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 20:43:05 -0000 ----==_mimepart_55e21956d1209_4f463fda40dfb2b8350177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The current document has the sentence Alice and Bob can then use a key-derivation function that includes K, K_A and K_B to derive a key. We need to make a decision if this is necessary or if we can just hash K instead. The reason given was an attack where either K_A or K_B was set to all zeros by a MITM to force the generated key K to all zeros. The check of K not being all zeros should protect against this attack without needing to include K_A and K_B in the result. Among other things we should track TLS Note that these curves may not make the cut for the current document. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/9 ----==_mimepart_55e21956d1209_4f463fda40dfb2b8350177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

The current document has the sentence

Alice and Bob can then use a key-derivation function that includes K, K_A and K_B to derive a key.

We need to make a decision if this is necessary or if we can just hash K instead. The reason given was an attack where either K_A or K_B was set to all zeros by a MITM to force the generated key K to all zeros. The check of K not being all zeros should protect against this attack without needing to include K_A and K_B in the result.

Among other things we should track TLS

Note that these curves may not make the cut for the current document.

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

----==_mimepart_55e21956d1209_4f463fda40dfb2b8350177-- From nobody Sat Aug 29 17:40:48 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051AF1B370C for ; Sat, 29 Aug 2015 17:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lcpm0ZJk1dce for ; Sat, 29 Aug 2015 17:40:45 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 78E901B2AA1 for ; Sat, 29 Aug 2015 17:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1440895244; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=VpIctBNvZYLtETF1l7n6A+dRBQcUEccBJiAaySKpceI=; b=F7qUcWqqnqdT2d2CjP0ec8NTmzqh3gpy3r+aN/PJgWSduD7kAzNlJlrXzeK3GNh7HW3cGLpOTjPtObXiKCI6ORv/iZ0gZomI0bgOZ94DAUIeNPJgyxCzwzZKyQ91CAWoG+Oub6pU14AircXAfdC3+00TBqpT/KisI+nspdGn75w= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03295; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.51.86(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 30 Aug 2015 08:40:41 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 30 Aug 2015 08:40:33 +0800 From: "Kepeng Li" To: "cose@ietf.org" Message-ID: Thread-Topic: cose - New Meeting Session Request for IETF 94 References: <20150826124540.31105.22078.idtracker@ietfa.amsl.com> In-Reply-To: <20150826124540.31105.22078.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [COSE] FW: cose - New Meeting Session Request for IETF 94 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 00:40:47 -0000 Hello all, FYI that we requested 1.5 hours for IETF 94 F2F meeting in Yokohama. Kind Regards Kepeng & Justin =D4=DA 26/8/15 8:45 pm=A3=AC ""IETF Meeting Session Request Tool"" =D0=B4=C8=EB: > > >A new meeting session request has just been submitted by Kepeng Li, a >Chair of the cose working group. > > >--------------------------------------------------------- >Working Group Name: CBOR Object Signing and Encryption >Area Name: Security Area >Session Requester: Kepeng Li > >Number of Sessions: 1 >Length of Session(s): 1.5 Hours >Number of Attendees: 50 >Conflicts to Avoid: > First Priority: abfab sacm radext dime tls ace core oauth jose > Second Priority: dane httpauth kitten dice saag > Third Priority: httpbis sidr > > >Special Requests: > =20 >--------------------------------------------------------- From nobody Sun Aug 30 02:23:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1295A1AC3D9 for ; Sun, 30 Aug 2015 02:23:44 -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 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 Rn72ZSoLrtpO for ; Sun, 30 Aug 2015 02:23:42 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB131A1A17 for ; Sun, 30 Aug 2015 02:23:40 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 9D62E1A25EA for ; Sun, 30 Aug 2015 12:23:38 +0300 (EEST) Date: Sun, 30 Aug 2015 12:23:38 +0300 From: Ilari Liusvaara To: cose@ietf.org Message-ID: <20150830092338.GA22298@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [COSE] [cose-issues] CFRG document for Curve25519 and Goldilocks has odd shared secret issue (#9) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 09:23:44 -0000 On Sat, Aug 29, 2015 at 01:43:02PM -0700, Jim Schaad wrote: > The current document has the sentence > > Alice and Bob can then use a key-derivation function that includes > K, K_A and K_B to derive a key. > > We need to make a decision if this is necessary or if we can just > hash K instead. The reason given was an attack where either K_A or > K_B was set to all zeros by a MITM to force the generated key K to > all zeros. The check of K not being all zeros should protect against > this attack without needing to include K_A and K_B in the result. The problem with not hashing K_A or K_B is that attacker can manipulate the keys so the key derivation results are predictable and can repeat. Which can lead into trouble (e.g. TLS took a nasty hit from that). TLS 1.3 draft and TLS 1.2 with appropriate security fix extension (and there are already drafts that have that extension as REQUIRED) does hash K_A and K_B into secrets. Also, SSHv2 does hash K_A and K_B (via handshake hash) into its secrets. I don't offhand know if offline protocols (like COSE) got hit in as nasty manner as online protocols (like TLS). Also: - K_A and K_B don't have to be all zeroes to generate "zero" K. - Some libraries using two-coordinate ECC don't validate points (or don't check for existence of square root when uncompressing), which effectively creates points with all sorts of strange orders or behaviour. - Some ECC libraries allegedly have strange repesentation of infinitity (so attacker can send order-1 point). -Ilari From nobody Sun Aug 30 08:53:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B621A8A7F for ; Sun, 30 Aug 2015 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6efQr9XZgL3G for ; Sun, 30 Aug 2015 08:53:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F336F1A87EE for ; Sun, 30 Aug 2015 08:53:16 -0700 (PDT) Received: from [192.168.10.151] ([101.53.7.10]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M8ZtH-1Yj4u10Iy3-00wGYp for ; Sun, 30 Aug 2015 17:53:14 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E326E6.4050107@gmx.net> Date: Sun, 30 Aug 2015 17:53:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sgg4Aw7Qqo07WMX1jI5iQB2U6DGVnVjdj" X-Provags-ID: V03:K0:ZB7qKUkPwVyw5AlNywURJoA0hJSZ6PmfSmRHa7aQXEqac1dotNB VpJvUPX0lzw3CjojZFp/LngRykxGTNcPAaV3EruTX4xxWGYuaMmgiimYoiflC8gW/j9aEtr RZvqymJYGKN04nYmCMxGKOz53I7egMw/CuVIY4VOHrbomUkLZ6D7HCye1P5CGLA4TYyLeCO 5cyDZUpSOmqiaNx2tJYag== X-UI-Out-Filterresults: notjunk:1;V01:K0:3aT8bsmuS58=:X6qLCLf17UqFwu9cIJq+JV vepc/RHc/qJyeMcPZn5wwkc0T+a3M6nKXM13etLId7xGaOR9i/ObsbgAE3wFwCqm8BDVF7STd em5kwQw1qPNmyWb1NWGjgzsWIBrDvCCRVfoqywPAab6uftEvss/lX+LsfmBN9tChdj+bUL45/ P3qCNAdm18fbcYH5qk656YR2+B94M9IJAxxJ1aP72PhdofDfSLC7To0sXxlNBiXhzz1YsbAwT iimu1JDwpck4YCONBHv2vS7S+u2BASucPjDS+shEhkigZ8FmooSHybgJeVLaqfjrztxDsr4LZ B1TCtSevqGAk1UgewdkOqvKUDbLuusYJwqDhX3qmpSgrSWyC5f2Dl6WMmK6pEr7ixqzjgZds6 KTeq+Ils2uUr9zQAmPeilyzIMCxffTwvvxdeq6uxjCmMy9/cl3AJwsMQxq73xK7lGOFyxB8BU p0Fq6z/6V5bO8KP0abIurnc9KBRCPCTKQwaRMfMeUAkKxzyGz+nXdY+4FLaHriZo2U22tZvY8 Sbvrf1/UFQmKcnQyeyyhNi/Q0FzUSfLv3fa1mliMqAfTwkyKhQdjTxdGDYn2cmOEFg9FcqNrE SRACKqq53ZN2g1YXwprfnDXRn1r0IhfEIgutcIstZcLWYHUJVa/ANMDFB7EhekhpThwQzz0xi F823hy+PWR8x5WAQZqWq3ae/Ev54j8ICaCabIVrocCa/R0EaDTE8+MdkPARMQMFoewfInESbv aLPZ+mse8jKoEsBM7anevLksjw6bS2qxfLlL0Q== Archived-At: Subject: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 15:53:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sgg4Aw7Qqo07WMX1jI5iQB2U6DGVnVjdj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear WG draft authors, Hi all, I have two comments regarding the use of CDDL in the COSE draft. 1) I don't believe it helps anyone to use a (formal) data definition language. Natural text is sufficient. The COSE specification is hopefully not so complex in the end that such a data definition language is needed. In general, I believe this typically just creates a misalignment between what is described in the text and what is contained in the formal description. There are many examples where the two descriptions disagree. I don't think it will help a human to understand the specification better (instead focus on better examples) and it will not help to automatically create code (which has often been mentioned as a benefit with other formal languages). 2) Please explain what the status of CDDL in the IETF is. The COSE spec references it normatively but the specification is an individual submission. My preferences is to remove the reference to CDDL and remove the CDDL related content from the draft making the spec shorter and easier to read. I hope others agree with me. Ciao Hannes --sgg4Aw7Qqo07WMX1jI5iQB2U6DGVnVjdj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV4ybnAAoJEGhJURNOOiAt48oIAJvH8ekR/RASdPHCqpYKuiSY 41HpukpOB4nfYhnsdlkFj3XDZUMEEwg2k1f5ln5qLRsZ6HV52QzuYf5K+EVLfCp1 pgGAU7nzz/fvgKmq2Ep+SSYwn/I2hyg+w6xvvmFCbieS7OFeNuGwtmzj6o1ATeIO GdNpDTXEouliiGn+GjCLsThU/Zf+SO341apqdKaWNV2PkhLdgJzp7m8NgyTLUvQl 7h8Ryrt3Gzt1XEXenq7iny5OmkdYej95nJjMVZl9WeCI8XyUHB72sGrj0wFALtAz 5vGGTsaDxoCOKKpk5h19QD9Ojj2Q86k69jkc0bGdDmLpvNmdYz3i9Epj1DsgbJs= =F4Fb -----END PGP SIGNATURE----- --sgg4Aw7Qqo07WMX1jI5iQB2U6DGVnVjdj-- From nobody Sun Aug 30 09:07:24 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56E41B337B for ; Sun, 30 Aug 2015 09:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMN41Tder9XR for ; Sun, 30 Aug 2015 09:07:21 -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 C09941B335C for ; Sun, 30 Aug 2015 09:07:20 -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 t7UG7Ghu026258; Sun, 30 Aug 2015 18:07:16 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n40102sBfz4v2C; Sun, 30 Aug 2015 18:07:16 +0200 (CEST) Message-ID: <55E32A33.10000@tzi.org> Date: Sun, 30 Aug 2015 18:07:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Hannes Tschofenig References: <55E326E6.4050107@gmx.net> In-Reply-To: <55E326E6.4050107@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 16:07:22 -0000 Hannes Tschofenig wrote: > Dear WG draft authors, Hi all, > > I have two comments regarding the use of CDDL in the COSE draft. > > 1) I don't believe it helps anyone to use a (formal) data definition > language. Hannes, with all due respect: speak for yourself. There are people who benefit from ABNF in other protocol specifications, and the same is definitely true here. (CDDL is also useful for automatically verifying the examples, but that is an effect that accrues independently of whether the spec actually contains it or not. Not publishing the CDDL that was used for verifying the examples would not be a bright move, though.) > Natural text is sufficient. The COSE specification is > hopefully not so complex in the end that such a data definition language > is needed. In general, I believe this typically just creates a > misalignment between what is described in the text and what is contained > in the formal description. There are many examples where the two > descriptions disagree. True for ABNF as well. The main effect of an ABNF spec has been that people have been more careful when actually creating the spec. > I don't think it will help a human to understand the specification > better (instead focus on better examples) and it will not help to > automatically create code (which has often been mentioned as a benefit > with other formal languages). > > 2) Please explain what the status of CDDL in the IETF is. The COSE spec > references it normatively but the specification is an individual > submission. Right. Given the number of efforts that have started looking at CDDL, it is likely that we'll go for standardizing CDDL. But the timeline for CDDL becoming an RFC is likely longer than that for COSE. > My preferences is to remove the reference to CDDL and remove the CDDL > related content from the draft making the spec shorter and easier to > read. I hope others agree with me. I definitely don't. Grüße, Carsten From nobody Sun Aug 30 09:25:15 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAB11B2DDF for ; Sun, 30 Aug 2015 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLxQFnq0c3E1 for ; Sun, 30 Aug 2015 09:25:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0841B2CE0 for ; Sun, 30 Aug 2015 09:25:10 -0700 (PDT) Received: from [192.168.10.151] ([101.53.7.10]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M08ia-1YimcK0Wke-00uIMn; Sun, 30 Aug 2015 18:25:09 +0200 To: Carsten Bormann References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E32E5F.2040900@gmx.net> Date: Sun, 30 Aug 2015 18:25:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E32A33.10000@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TetRMLVV4EACuerUDnu4L0qbW8CGNK7QS" X-Provags-ID: V03:K0:BMP590Y12CkSqMefI82IPjA8azbWJ/rSeRESN9TU5e8QrrU17ZG oe5TU1wxWTBhahhi3xUdGE/T9YiPPglV0jvCpQGxeFJVpZ/tgq9EdrO8gyDHKL0PoSt9orm 4Q0JRceysgS/M5ANlMrbqFG4CzOK8ZPyPcvhm0mgiG1uD50BfCYt/HHQeljagYEeuPRMcRV 6Gu8wc1vGOjd0J2p1IO5w== X-UI-Out-Filterresults: notjunk:1;V01:K0:EUHWvCnUZbE=:ZNnyU7vYWh0GFBrfHtkErC v9FmF9Ml19sRKlYsXEsypM6U2oqskDDE2w/k91S8Q7KTvfdtd6kCZ+lpH8SDjZOswgDUJTe53 LhB4nUUQxBFsikQMgyfBap8wCLLy+kqJXg9ajNCmGy0i9om7Pook37z30UvB1DSdKe5IXF75f hcN2Ea3o3Ki13SWro/JYwtPAQMU2Uz36liJT5lZEjTug6buYh96BKLjMYvu9HHc6U/BNR12fZ kmpkcNmScpNZzAuU71d+DvgV4FvufgQgALpoAQx3rZN4CEj71Ry+JUWaVKc0YAz2QZOwGXuEw 9SdvzJg60twlFYZyzlQm+yxKABA9uJma9lGgYWKDV8a8y+gLuS80NYJTMFreqJnBBUQTPC99t qY292p2+dUmxGm5pwBMU4jNQLNuPw/KXa0K9VffSfiY2mnHbpkgpeExUxsHl/On5CI0eVoHSd 6PgOsKfxJWjFclW/Iw7DyrmvwLRZOiF9lu/pC1eBEByLIJqn+w99CD8BT7lIAPL1a4Yl3rTdt 6AsAOUXS8sbU/PcQ05JF0W0FQkeGVtbGtLepR4E9d+OskCPhYbek4zAU/zxD2QM9aLc4+RrlO slR3jHO5CRyf/S1VI0VQOY58OjyCoqqJtsKU0x6e6jMQhqQkk/Eoeu8OtrPjM2XwcEs9HfS0H UVWD0z0S5Tq3wYwMKONV4giLNfGg29ynyfWVaQPmqHhwKMeJ5+VZq8rhBuCAI3qigJo4MuliM c7j3v8FkFx9ZzY02hQ8Ko/zvtt6UXxvMq5/K6w== Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 16:25:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TetRMLVV4EACuerUDnu4L0qbW8CGNK7QS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten thanks for your quick response. On 08/30/2015 06:07 PM, Carsten Bormann wrote: > Hannes Tschofenig wrote: >> Dear WG draft authors, Hi all, >> >> I have two comments regarding the use of CDDL in the COSE draft. >> >> 1) I don't believe it helps anyone to use a (formal) data definition >> language.=20 >=20 > Hannes, with all due respect: speak for yourself. I am not sure how you got the impression that I am not speaking for myself in this email. >=20 > There are people who benefit from ABNF in other protocol specifications= , > and the same is definitely true here. Speaking for myself again: I have never benefited from ABNF and I have used it a lot in Diameter. I had to use it in the documents since there was the perceived need to do so not because it provided a benefit for me. The same has, btw, been true for me for XML schemas. >=20 > (CDDL is also useful for automatically verifying the examples, but that= > is an effect that accrues independently of whether the spec actually > contains it or not. Not publishing the CDDL that was used for verifyin= g > the examples would not be a bright move, though.) I believe you are biased in this case since one of the authors is from TZ= I. One should also be able to verify examples based on the text in the specification. Furthermore, you will not be able to verify the examples purely based on the CDDL anyway since you need tools to actually verify the cryptographic operations (which is the main purpose of the specification). >=20 >> Natural text is sufficient. The COSE specification is >> hopefully not so complex in the end that such a data definition langua= ge >> is needed. In general, I believe this typically just creates a >> misalignment between what is described in the text and what is contain= ed >> in the formal description. There are many examples where the two >> descriptions disagree. >=20 > True for ABNF as well. I also don't like ABNF. > The main effect of an ABNF spec has been that > people have been more careful when actually creating the spec. I fear that this is wishful thinking. I am a strong believer that examples help people to understand specifications faster. >=20 >> I don't think it will help a human to understand the specification >> better (instead focus on better examples) and it will not help to >> automatically create code (which has often been mentioned as a benefit= >> with other formal languages). >> >> 2) Please explain what the status of CDDL in the IETF is. The COSE spe= c >> references it normatively but the specification is an individual >> submission. >=20 > Right. Given the number of efforts that have started looking at CDDL, > it is likely that we'll go for standardizing CDDL. But the timeline fo= r > CDDL becoming an RFC is likely longer than that for COSE. Not a good thing either. >=20 >> My preferences is to remove the reference to CDDL and remove the CDDL >> related content from the draft making the spec shorter and easier to >> read. I hope others agree with me. >=20 > I definitely don't. That's fine. I hope that others carefully think about this issue and make up their mind themselves. This is why I raise it here on the list. Ciao Hannes >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 --TetRMLVV4EACuerUDnu4L0qbW8CGNK7QS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV4y5gAAoJEGhJURNOOiAtHd8H/2V8A6Q0faxK5eVgFZOY0LQ1 str4/iksAZJ6TAfSeepK29PXuzGyqlAKHR2alchP9Psolwp7e0K6v7Gw0ZoTPhqf cFMeK22uAMbs1MLnQY2kUqHR4YPXYh/A5p38xV/sbswRpMYO9HqXh7BEWbfe6n7v 6/2xYzh6YweZ2A3JiSgM1u941+CVCPpEd7Mgq2d9JXjj1vqdOvIKu0IO0sNfQdck bWJ7iQVuGJtgByHFyNI0w61XCRurjmJDvdnq7unErDwZSPJ3OfOezOsV4u5EYC+M ykOkErJFDYiIDQaqt4vLYxuf3l72Ix0SVa9BRmKI1AG3DDcKDX7a0shsXkeLeos= =FdsV -----END PGP SIGNATURE----- --TetRMLVV4EACuerUDnu4L0qbW8CGNK7QS-- From nobody Sun Aug 30 09:58:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0641A1B9A for ; Sun, 30 Aug 2015 09:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTyS5hhRBXwA for ; Sun, 30 Aug 2015 09:58:27 -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 40E511A024C for ; Sun, 30 Aug 2015 09:58:26 -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 t7UGwNfi023489; Sun, 30 Aug 2015 18:58:23 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n417z24bQz4vh7; Sun, 30 Aug 2015 18:58:23 +0200 (CEST) Message-ID: <55E3362D.1050504@tzi.org> Date: Sun, 30 Aug 2015 18:58:21 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Hannes Tschofenig References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> <55E32E5F.2040900@gmx.net> In-Reply-To: <55E32E5F.2040900@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 16:58:28 -0000 Hannes Tschofenig wrote: >>> 1) I don't believe it helps anyone to use a (formal) data definition >>> language. >> Hannes, with all due respect: speak for yourself. > > I am not sure how you got the impression that I am not speaking for > myself in this email. You said you don't believe it helps anyone. I just wanted to point out that this belief is false. >> There are people who benefit from ABNF in other protocol specifications, >> and the same is definitely true here. > > Speaking for myself again: I have never benefited from ABNF and I have > used it a lot in Diameter. Again, I wanted to point out that there are people who do benefit from ABNF (even if it is a slightly strange instance of the class of specification languages known as EBNF). > I had to use it in the documents since there was the perceived need to > do so not because it provided a benefit for me. The same has, btw, been > true for me for XML schemas. We can agree there are some bad schema languages out there... Still, most XML-based specifications do benefit from a document structure definition language, in particular if it is a state of the art language such as Relax-NG in compact form. > I believe you are biased in this case since one of the authors is from TZI. (Well, I'm actually helping with their work. And the reason I'm doing this is: I strongly believe that formal specifications do help, under a number of conditions that have only recently become understood well enough.) > One should also be able to verify examples based on the text in the > specification. Sure. Let's get rid of those pesky math expressions, too. (If you have been present in the software development community in the last couple of decades, you know that you get better quality from better automation. It is hard to automate testing from English text, and that's why formats such as Cucumber's Gherkin have been developed. But this is off-topic from this WG's work...) > Furthermore, you will not be able to verify the examples > purely based on the CDDL anyway since you need tools to actually verify > the cryptographic operations (which is the main purpose of the > specification). Certainly. ABNF and CDDL only give you syntax, which is a small part of the specification problem. But it is a frequent source of interoperability problems, and it is a part where we know how to automate at low cost. It is simply not very good workmanship not to. > I am a strong believer that examples help people to understand > specifications faster. I absolutely agree. ABNF or CDDL are not at all substitutes for examples. But like tests, examples can only ever be examples, not demonstrate the boundary of the spec. All that said, I do understand a good counter-argument against specification languages: They can make it too easy to add complexity. Good thing we are not falling into this trap with COSE. Grüße, Carsten From nobody Sun Aug 30 11:37:42 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8AF1A87BD for ; Sun, 30 Aug 2015 11:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0IKC77CTrCB for ; Sun, 30 Aug 2015 11:37:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04871A1DBE for ; Sun, 30 Aug 2015 11:37:39 -0700 (PDT) Received: from [192.168.10.152] ([101.53.7.10]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MFctN-1ZSahR364z-00EgGU; Sun, 30 Aug 2015 20:37:37 +0200 To: Carsten Bormann References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> <55E32E5F.2040900@gmx.net> <55E3362D.1050504@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E34D6B.9070303@gmx.net> Date: Sun, 30 Aug 2015 20:37:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E3362D.1050504@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MiaUt9nuoC2GOtkwrc9hlD5abTiQDDEPB" X-Provags-ID: V03:K0:eH0c5g06jwnmZ7FCp2/KdjXa+x0h2xNwOrcV7Ya2HgjdCK18uBX 23Vcz5DbkZ2wSHqBd870F3UkMgT9udNplLD7cxuA9RTpkXYkTBLbgkJxggg0UlpaBGWSkMm UX0RH5ocALa9KXx25xNq5PrLfoo6GbWoPyLCfI47YXKjOtwXiDLSDOYA9JcDQOIXaGeVD4L iYo68Kudu0I+iZFssIDLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:/fnPmJreIqw=:b8pfSJyjcm6GmGZ+ld5vZe SpgnVLYuTA91Xcujp8yiwFYXdCSjNx9sb+fGdZna9sK0GxjWKgH+bn2bZBxLO1MjANgvWbWBX 1dPR8DYyara6apfaZt9IRQNjppuJPds/6lSXPBfOZRrbufQMXRf0bTeYF6VdygIuh7EvikU7u 8KxdORag68goK/yconGe2zdh6FVMNjYxJTVzh2bgAp7Eb0QiGoLtXRBD3tzw/YKTIvsH+tP5I Txi+877DPk9MslMLwsqxi8TCAQ/y0WL0Ct3GxRT57IUYpuxb2Jg2YHUKXLtlFF8lOqJtXoEbD fQcCNCCyPYJe8xVC6PDxP2aqqhljBH3Xrrt3N39QWkHlqVYl5AzKiNzbfUz7fEFfHMCQ/6XXJ Nt9G0K8i3So+VVPgI5L7toI/OhaFBn7qvEI1ZnZXEA5hk3NrBQdgh3x3i7CV85c1AV4ws3wSs JzgLIcqxRJWTNaEA/2kCmckw8YmQAdQ3qgDAint2i/9MKitra3NVJldM3+654LBOwcmkvTuwz nKPhE5XsZZZ0HS0V2YdCOIEO7TnbA3ZzlxJ1TcuE6lnyTet0wj9c4gN1MxperXsRttynJWPd1 YIaC/XcuJfrsib88d2dF8iui4fX3xTT0S2irj8rfmllGeLG+aGJgOVef8sI4Q+dLl4N1EAF0Y +V5FPCCzS1rt55bWAI8pXN7AL//PgTf13RxvNPI8iOyKugTaE5uAYyRY2bRtScW7WKOA2beH5 XWb+ht7FhW+ENtJK/kUsIrzQrJPXZ8wf4Dgehg== Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 18:37:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MiaUt9nuoC2GOtkwrc9hlD5abTiQDDEPB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Let us see whether others in the group have an opinion about this topic. I don't believe anyone in the group was asked whether they want to use a data definition language at all, CCDL, or something else in the COSE WG document. I guess we two have a different view about this subject. More discussion will not change our perspective. Ciao Hannes On 08/30/2015 06:58 PM, Carsten Bormann wrote: > Hannes Tschofenig wrote: >=20 >>>> 1) I don't believe it helps anyone to use a (formal) data definition= >>>> language.=20 >>> Hannes, with all due respect: speak for yourself. >> >> I am not sure how you got the impression that I am not speaking for >> myself in this email. >=20 > You said you don't believe it helps anyone. > I just wanted to point out that this belief is false. >=20 >>> There are people who benefit from ABNF in other protocol specificatio= ns, >>> and the same is definitely true here. >> >> Speaking for myself again: I have never benefited from ABNF and I have= >> used it a lot in Diameter. >=20 > Again, I wanted to point out that there are people who do benefit from > ABNF (even if it is a slightly strange instance of the class of > specification languages known as EBNF). >=20 >> I had to use it in the documents since there was the perceived need to= >> do so not because it provided a benefit for me. The same has, btw, bee= n >> true for me for XML schemas. >=20 > We can agree there are some bad schema languages out there... > Still, most XML-based specifications do benefit from a document > structure definition language, in particular if it is a state of the ar= t > language such as Relax-NG in compact form. >=20 >> I believe you are biased in this case since one of the authors is from= TZI. >=20 > (Well, I'm actually helping with their work. > And the reason I'm doing this is: I strongly believe that formal > specifications do help, under a number of conditions that have only > recently become understood well enough.) >=20 >> One should also be able to verify examples based on the text in the >> specification.=20 >=20 > Sure. Let's get rid of those pesky math expressions, too. > (If you have been present in the software development community in the > last couple of decades, you know that you get better quality from bette= r > automation. It is hard to automate testing from English text, and > that's why formats such as Cucumber's Gherkin have been developed. But= > this is off-topic from this WG's work...) >=20 >> Furthermore, you will not be able to verify the examples >> purely based on the CDDL anyway since you need tools to actually verif= y >> the cryptographic operations (which is the main purpose of the >> specification). >=20 > Certainly. ABNF and CDDL only give you syntax, which is a small part o= f > the specification problem. But it is a frequent source of > interoperability problems, and it is a part where we know how to > automate at low cost. It is simply not very good workmanship not to. >=20 >> I am a strong believer that examples help people to understand >> specifications faster. >=20 > I absolutely agree. >=20 > ABNF or CDDL are not at all substitutes for examples. But like tests, > examples can only ever be examples, not demonstrate the boundary of the= > spec. >=20 > All that said, I do understand a good counter-argument against > specification languages: They can make it too easy to add complexity. > Good thing we are not falling into this trap with COSE. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --MiaUt9nuoC2GOtkwrc9hlD5abTiQDDEPB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV401rAAoJEGhJURNOOiAtubQIAJ/qtMJniELH0IHhcG9sNQBL mRyEy34Rj81UYa2Rl+OMI8OB9zJ4b0ZsKpvhMwfg3tzTfKfTgVUXzWiOVUhudC1U xFeZ9SODRKzNEcF6GGP9duFQwVPaR8A1Qncm9hS5UQHy2g3z0eDkyYDtyAsoKOKv 5Qxjjcm1a/Oq5SNJVgtqEc4vb0LEMebslGlHynjLGAhf8aurLcWfQuCHeBq1AxLL TkJmS6L3BZxbYKk87HNYX3oDYYSDadoTqBMQ5Yn4VZvTFCATwYcReWkh01OZS9UV Q8YJu1xpEvwWVx0aqeHl2L0sjDuaUoETxWVQ/21x9AUud92FHiINy8V01fev6ec= =L7v7 -----END PGP SIGNATURE----- --MiaUt9nuoC2GOtkwrc9hlD5abTiQDDEPB-- From nobody Sun Aug 30 12:09:46 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAA11A8904 for ; Sun, 30 Aug 2015 12:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy6KeuJYHQ0D for ; Sun, 30 Aug 2015 12:09:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 03C5D1A88AF for ; Sun, 30 Aug 2015 12:09:43 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7UJ9eFE022874 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Aug 2015 19:09:40 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7UJ9dGB000871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Aug 2015 19:09:40 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7UJ9dUI023606; Sun, 30 Aug 2015 19:09:39 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 Aug 2015 12:09:39 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12H321) In-Reply-To: <55E34D6B.9070303@gmx.net> Date: Sun, 30 Aug 2015 12:09:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> <55E32E5F.2040900@gmx.net> <55E3362D.1050504@tzi.org> <55E34D6B.9070303@gmx.net> To: Hannes Tschofenig X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Carsten Bormann , "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 19:09:45 -0000 I don't see the need for CDDL. Especially if it will delay COSE.=20 Phil > On Aug 30, 2015, at 11:37, Hannes Tschofenig w= rote: >=20 > Hi Carsten, >=20 > Let us see whether others in the group have an opinion about this topic. > I don't believe anyone in the group was asked whether they want to use a > data definition language at all, CCDL, or something else in the COSE WG > document. >=20 > I guess we two have a different view about this subject. More discussion > will not change our perspective. >=20 > Ciao > Hannes >=20 >> On 08/30/2015 06:58 PM, Carsten Bormann wrote: >> Hannes Tschofenig wrote: >>=20 >>>>> 1) I don't believe it helps anyone to use a (formal) data definition >>>>> language. >>>> Hannes, with all due respect: speak for yourself. >>>=20 >>> I am not sure how you got the impression that I am not speaking for >>> myself in this email. >>=20 >> You said you don't believe it helps anyone. >> I just wanted to point out that this belief is false. >>=20 >>>> There are people who benefit from ABNF in other protocol specifications= , >>>> and the same is definitely true here. >>>=20 >>> Speaking for myself again: I have never benefited from ABNF and I have >>> used it a lot in Diameter. >>=20 >> Again, I wanted to point out that there are people who do benefit from >> ABNF (even if it is a slightly strange instance of the class of >> specification languages known as EBNF). >>=20 >>> I had to use it in the documents since there was the perceived need to >>> do so not because it provided a benefit for me. The same has, btw, been >>> true for me for XML schemas. >>=20 >> We can agree there are some bad schema languages out there... >> Still, most XML-based specifications do benefit from a document >> structure definition language, in particular if it is a state of the art >> language such as Relax-NG in compact form. >>=20 >>> I believe you are biased in this case since one of the authors is from T= ZI. >>=20 >> (Well, I'm actually helping with their work. >> And the reason I'm doing this is: I strongly believe that formal >> specifications do help, under a number of conditions that have only >> recently become understood well enough.) >>=20 >>> One should also be able to verify examples based on the text in the >>> specification. >>=20 >> Sure. Let's get rid of those pesky math expressions, too. >> (If you have been present in the software development community in the >> last couple of decades, you know that you get better quality from better >> automation. It is hard to automate testing from English text, and >> that's why formats such as Cucumber's Gherkin have been developed. But >> this is off-topic from this WG's work...) >>=20 >>> Furthermore, you will not be able to verify the examples >>> purely based on the CDDL anyway since you need tools to actually verify >>> the cryptographic operations (which is the main purpose of the >>> specification). >>=20 >> Certainly. ABNF and CDDL only give you syntax, which is a small part of >> the specification problem. But it is a frequent source of >> interoperability problems, and it is a part where we know how to >> automate at low cost. It is simply not very good workmanship not to. >>=20 >>> I am a strong believer that examples help people to understand >>> specifications faster. >>=20 >> I absolutely agree. >>=20 >> ABNF or CDDL are not at all substitutes for examples. But like tests, >> examples can only ever be examples, not demonstrate the boundary of the >> spec. >>=20 >> All that said, I do understand a good counter-argument against >> specification languages: They can make it too easy to add complexity. >> Good thing we are not falling into this trap with COSE. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sun Aug 30 12:52:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995C31A879F for ; Sun, 30 Aug 2015 12:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fkwLOo_qCgp for ; Sun, 30 Aug 2015 12:52:43 -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 0B18E1A88F6 for ; Sun, 30 Aug 2015 12:52:42 -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 t7UJqdDW004652; Sun, 30 Aug 2015 21:52:39 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n45131jC9z4tqp; Sun, 30 Aug 2015 21:52:39 +0200 (CEST) Message-ID: <55E35F05.2020409@tzi.org> Date: Sun, 30 Aug 2015 21:52:37 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Phil Hunt References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> <55E32E5F.2040900@gmx.net> <55E3362D.1050504@tzi.org> <55E34D6B.9070303@gmx.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 19:52:44 -0000 Phil Hunt wrote: > I don't see the need for CDDL. I don't think anybody sees a "need", as in "it can't be done without". But that is no reason to do without. > Especially if it will delay COSE. There is no need for that to happen. The current plan is to relegate the CDDL specs to an appendix once the structures are stable. The normative part will be the English text (at least unless CDDL manages to overtake COSE...). (Just as the examples aren't what's normative, either, but are what is being used by implementers anyway.) Grüße, Carsten From nobody Sun Aug 30 13:57:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2571A9253 for ; Sun, 30 Aug 2015 13:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0BelSawZNPn for ; Sun, 30 Aug 2015 13:56:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5051A924A for ; Sun, 30 Aug 2015 13:56:59 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8268A2CA16; Sun, 30 Aug 2015 13:56:58 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E326E6.4050107@gmx.net> In-Reply-To: <55E326E6.4050107@gmx.net> Date: Sun, 30 Aug 2015 13:54:48 -0700 Message-ID: <040301d0e366$1bdb9890$5392c9b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJSIQ7w+k/qCYw/XYnDXOZG5Tths50ih85Q Archived-At: Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2015 20:57:01 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Sunday, August 30, 2015 8:53 AM > To: cose@ietf.org > Subject: [COSE] cddl >=20 > Dear WG draft authors, Hi all, >=20 > I have two comments regarding the use of CDDL in the COSE draft. >=20 > 1) I don't believe it helps anyone to use a (formal) data definition = language. > Natural text is sufficient. The COSE specification is hopefully not so = complex in > the end that such a data definition language is needed. In general, I = believe this > typically just creates a misalignment between what is described in the = text and > what is contained in the formal description. There are many examples = where the > two descriptions disagree. >=20 > I don't think it will help a human to understand the specification = better (instead > focus on better examples) and it will not help to automatically create = code > (which has often been mentioned as a benefit with other formal = languages). I totally disagree. I think that there are huge advantages to using = formal languages. And while automatic code creation is a benefit, it is = hardly the only one. I find such structures easier to read than natural = code for many things. When there is formal language in a specification, = that is generally where I start with understanding the major parts of = the document, and use the natural language for finer points. It is much = easier to locate and skip a formal language section than to look through = several hundred lines of text to find the one that you need. It was = just pointed out to me that I had missed some text in the document that = is only required because CDDL is not normative and thus it needs to be = duplicated. If I could make CDDL normative, then I would start ripping out natural = language descriptions are being duplicated by the formal language. = Where ever possible I would have only one description and it would be = the formal language. Having natural language do the same thing except = for clarifications is what I would object to. I have never liked the idea of document by examples. It can be both = very limiting - I do something that is legal but not in the examples. = You do not process it because it is not in the examples. Examples = should be illustrative not where the specification is understood. That being said. What examples do you think need to be added to the = document to improve it. Jim >=20 > 2) Please explain what the status of CDDL in the IETF is. The COSE = spec > references it normatively but the specification is an individual = submission. >=20 > My preferences is to remove the reference to CDDL and remove the CDDL > related content from the draft making the spec shorter and easier to = read. I > hope others agree with me. >=20 > Ciao > Hannes >=20 From nobody Sun Aug 30 21:40:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBD31AD0A5 for ; Sun, 30 Aug 2015 21:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGtXm7KWwdU2 for ; Sun, 30 Aug 2015 21:40:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054691AD094 for ; Sun, 30 Aug 2015 21:40:52 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MB2G8-1ZObw41mcu-009vlj; Mon, 31 Aug 2015 06:40:49 +0200 To: Jim Schaad , cose@ietf.org References: <55E326E6.4050107@gmx.net> <040301d0e366$1bdb9890$5392c9b0$@augustcellars.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E3DACA.5000102@gmx.net> Date: Mon, 31 Aug 2015 06:40:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <040301d0e366$1bdb9890$5392c9b0$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ISSx2RNdPlOlGVIJa7SeN3LluQWX3AhEg" X-Provags-ID: V03:K0:lDRTyAcpPKLZLsljW3Djm971VMBzyBi7aI3FpQTJGq5tyfPflef aCMj2vDZyc9es9qjd6DnyvPCUNB87eXOdZosLLYKGskQLQ7b9MqzIizZ8wWy7z4BdEslFqf 2tgFf7oCvXreUHE2qkeNhFsECBUpWaNGoEkhDtpLFwq0iI7yaMUws/Dli9aXJQv53/yef3U TMlcEX3ConofWCHa8J3qA== X-UI-Out-Filterresults: notjunk:1;V01:K0:BVmaNGsjV0U=:Jp6ZUFHOG9D3QjpF2fDjMF KJqy0lAY6cIxBtIz4KpToUdWszm0GWVk5N6bZdxPnBJwNB6W2boSdpFf5JFUXsWwIeyI5YA+D I8jrzY71tfOmXXMrMf0YVIdkEMzwRS/DPyIR00vbPZZBrPteXZ0QGbhcSUfbq3KD8fF7c7Nj9 AR2GHY8162n7rhfk9fu5fGo3i1fWGXlK6/ldkgNJeXjIPOMME0FQUYDgPH4DO4uxq0M7q1Hpk Akwy18EyvKfSbcKucOom8PtVZVXx7sybMcFspbo1GWgXSl+LmKdEb/ZIxu+V3Q6tMHsIfJpt5 CPSLkGKG2rFfqJBAjUlbSLCuDY4EE85A78yc5DGR3mhpCa0IzQglDKOgzC/PJvSo6VCVgiAzv qtjiwBKdRg/Ygi4HtRHVzEzwmLeFGD0+n3b2NH2aYbLFuxA0LKt8+eHQoICAq8MIpRmS/LS48 jtvshhaw071o7AJijbGb/0xC1g66NfjQXV8r7SzA9IV1TngAeeVU1a+te1LNQfgEZX2BHwSQa 6j+zoAfEiEHPj2+55GC5ze0n5HKibM4T3a+PixzB8HaG691h4MtYe28Ps0W20drzXVrsOKcEw iPioWsfnakSiV6O2CFbi3jdhNfRwpu3WWjvow+0GsvsUdDXmC499NQJHTz44kujQntaVIL+CP +tn1G/lWYdcS/UIqqIxZ3Pxr89S/atBfNfJNx2Lz1mhKV2a5SQxaJaTlK+AumJFcZ0OAE3Da+ nCt4JN6jkjeZuCqJYBmof2JuV+8xgR8tdWfoOA== Archived-At: Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 04:40:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ISSx2RNdPlOlGVIJa7SeN3LluQWX3AhEg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, thanks for your response. It is interesting to see how different people are in terms of writing documents. I personally liked the JOSE documents quite a bit -- they are easy to read and to understand. They got away without CDDL. You asked about the examples. I have just tried to work on the multicast use case and found none of the examples applicable. It would be interesting to know what IoT use cases you had in mind when you added the examples. Ciao Hannes On 08/30/2015 10:54 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- From: COSE >> [mailto:cose-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: >> Sunday, August 30, 2015 8:53 AM To: cose@ietf.org Subject: [COSE] >> cddl >>=20 >> Dear WG draft authors, Hi all, >>=20 >> I have two comments regarding the use of CDDL in the COSE draft. >>=20 >> 1) I don't believe it helps anyone to use a (formal) data >> definition language. Natural text is sufficient. The COSE >> specification is hopefully not so complex in the end that such a >> data definition language is needed. In general, I believe this=20 >> typically just creates a misalignment between what is described in >> the text and what is contained in the formal description. There are >> many examples where the two descriptions disagree. >>=20 >> I don't think it will help a human to understand the specification >> better (instead focus on better examples) and it will not help to >> automatically create code (which has often been mentioned as a >> benefit with other formal languages). >=20 > I totally disagree. I think that there are huge advantages to using > formal languages. And while automatic code creation is a benefit, it > is hardly the only one. I find such structures easier to read than > natural code for many things. When there is formal language in a > specification, that is generally where I start with understanding the > major parts of the document, and use the natural language for finer > points. It is much easier to locate and skip a formal language > section than to look through several hundred lines of text to find > the one that you need. It was just pointed out to me that I had > missed some text in the document that is only required because CDDL > is not normative and thus it needs to be duplicated. >=20 > If I could make CDDL normative, then I would start ripping out > natural language descriptions are being duplicated by the formal > language. Where ever possible I would have only one description and > it would be the formal language. Having natural language do the same > thing except for clarifications is what I would object to. >=20 > I have never liked the idea of document by examples. It can be both > very limiting - I do something that is legal but not in the examples. > You do not process it because it is not in the examples. Examples > should be illustrative not where the specification is understood. >=20 > That being said. What examples do you think need to be added to the > document to improve it. >=20 > Jim >=20 >>=20 >> 2) Please explain what the status of CDDL in the IETF is. The COSE >> spec references it normatively but the specification is an >> individual submission. >>=20 >> My preferences is to remove the reference to CDDL and remove the >> CDDL related content from the draft making the spec shorter and >> easier to read. I hope others agree with me. >>=20 >> Ciao Hannes >>=20 >=20 >=20 --ISSx2RNdPlOlGVIJa7SeN3LluQWX3AhEg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV49rKAAoJEGhJURNOOiAtlUYH/306bLz5w82wQ7ME/RStYKyd 8ptcCsszUt4Pv58D8sW4D20vwews1KyAsG6Nh/Whq+On8Aeq+anTD5Y+Sgiv8i4D JnUTO7sv+BVlByKVQgYprUvHc1Dq5suoj2rB84qDzFbx81WNIJuLMDn6cPaRUobv WhK/X7aEoiiFBlCoA0MUw4t6KhALBlEOeK8W5IGXsaVKGdlvKBXRjBa+bp+A+lA9 xW871ir/6nmmhn4w9UEbbbEc2aoJBr0L3FRb5c4qWXjlv1EFgBKZKfXhXNBPy1oi E4kgGxZ98UIGmwrjnrGfDbLzAh+R/Un3x+1U99gYt3uAObbK+SjnR8wV3Ep7vh8= =KVJJ -----END PGP SIGNATURE----- --ISSx2RNdPlOlGVIJa7SeN3LluQWX3AhEg-- From nobody Sun Aug 30 21:41:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E2E1AD0D3 for ; Sun, 30 Aug 2015 21:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYbMvKJ1EVHa for ; Sun, 30 Aug 2015 21:41:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D971AD0CC for ; Sun, 30 Aug 2015 21:41:27 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9wrU-1ZPhJs1Kae-00B1H5; Mon, 31 Aug 2015 06:41:17 +0200 To: Carsten Bormann , Phil Hunt References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> <55E32E5F.2040900@gmx.net> <55E3362D.1050504@tzi.org> <55E34D6B.9070303@gmx.net> <55E35F05.2020409@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E3DAE7.9030700@gmx.net> Date: Mon, 31 Aug 2015 06:41:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E35F05.2020409@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FfCukvjxb2PAFE42FQN2wJoJe7F2A6kVC" X-Provags-ID: V03:K0:SWGxGN4j7j7dJb4d0AWzaYwar81fzijVTX5EV83R3mfcVpDl5AF FVS8T781V3RG1ikjibE9ZWTFzLDASwHqJcrPOpKNHZaD2+P4BU7H0bAxCm6Babf3I2gjqKl cqE6adCu5XwLWjpgZOE2QRhhBTPjb34WcDqoEYOMSIB7G74PdpL4BHTNt5AEAw0sllxCv6P KKRwljnqbPVhX7P6FnrcQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:V4OpV+6TwXI=:iJHflj4d++cRC3oFbWV9kF I1kITwnnD219Iea7FrnyZK2Yjl9XXFuYUQFWZWodLpHf0G4+d86vNt5+YEQnr8UBRn225NV7h FMel3fJ/agSIN3wYDwnOG+ampGxTEWp6wTXQ/Y+nMOcSFNnrrbRDTU2IMnvwi+4RFsK4N2rYZ kzRRqj9Usr0vB7ox9fkNAS1DMKLtgjyOA7igradqYr/afrIURM9hLaPus+v6j8Xsi7Sd5d0mO a2na2l9zOoj82IZTPvurgnK5dmzi0lCo5wlRTS9JGvsLEeTQ83vJS5HAxRr1kKVQEei7MpXCO bHnf9aEHL1sIz0iiO+IVxHs5Xi+UuY0zwmCdYC3NB4O76ApLaekBi5jLdiLDcQ3HtVK1zCiHA Mhgrm6CcG3d6BTHlQA1Y8lRsFsm1ki3wO6rcnjUtaCoZOcl4HihaNnluJ9h9EQU3Yc2DbUius jyDSq8ZIAsgPi9rzFhqHbl0ZmQ7WQZszzrhShoD4z+gvlaLpyZvVsrLrDya6nBXvzIAEKFYWV PvriG+V9STb2Gi/YiMUFBUKDHDvd1p46M9TBdpho/0QF0kUkBt/ToYSZ8Cu+x3yirfyLaW+zz LsFfJbvFwLJIKsrxtMUVxb6lO9Zh6LSQ0dhI+PFTAsOJimtcCoGa12wyT/LCj3RkMfyaWWOdA 3ipe+6tOclgDnTk5SLBM9ImU2LQ9P/Za74XRkWs3+ITzuIUplkQDzIQS9UFo9r4vsBKGf+yoT mYNJRzFdPmkOsdqLWTpbVTHMFZLXwMYwQpVNBg== Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 04:41:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FfCukvjxb2PAFE42FQN2wJoJe7F2A6kVC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, >> Especially if it will delay COSE.=20 >=20 > There is no need for that to happen. > The current plan is to relegate the CDDL specs to an appendix once the > structures are stable. The normative part will be the English text (at= > least unless CDDL manages to overtake COSE...). > (Just as the examples aren't what's normative, either, but are what is > being used by implementers anyway.) Who came up with this plan? Ciao Hannes --FfCukvjxb2PAFE42FQN2wJoJe7F2A6kVC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV49roAAoJEGhJURNOOiAtXR8IAJHjcHGZKofQfL4cYTOKCiOu AGpIal7H1Uf12eVEVUMEHKwkIRUj5IRyMb8SHB4gqu/n/h93dDEpW+x202pOg0bw ysz2oupXJUcwlbSsNPSbDOAvsH53qlzGD0Uar3a8dXx87dK/m49jrfkeo2aRGTbY hoZldZKg/ofecpVurYLitObuEIg0MLWR3vM7hDW/gwGMj0jPS0vEizXT5kg8lUmV FKm52edD1ED45B7X1syWEGtIX5gfH+ByltwvwnswX4d8B73G1jKmzweeT8RG87/r D/HRTPYg3KJlf03hlLTntnlN1FtziUz+V0+5ZwjMSA758xbRtO+lMeYysada7mg= =9PBC -----END PGP SIGNATURE----- --FfCukvjxb2PAFE42FQN2wJoJe7F2A6kVC-- From nobody Sun Aug 30 22:06:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A263D1AC43B for ; Sun, 30 Aug 2015 22:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYI1vZfk1AUC for ; Sun, 30 Aug 2015 22:06:15 -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 1CEE01AC428 for ; Sun, 30 Aug 2015 22:06:14 -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 t7V56ALL013375; Mon, 31 Aug 2015 07:06:10 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n4KHk1sZWz4vFr; Mon, 31 Aug 2015 07:06:10 +0200 (CEST) Message-ID: <55E3E0C0.5070308@tzi.org> Date: Mon, 31 Aug 2015 07:06:08 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Hannes Tschofenig References: <55E326E6.4050107@gmx.net> <55E32A33.10000@tzi.org> <55E32E5F.2040900@gmx.net> <55E3362D.1050504@tzi.org> <55E34D6B.9070303@gmx.net> <55E35F05.2020409@tzi.org> <55E3DAE7.9030700@gmx.net> In-Reply-To: <55E3DAE7.9030700@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 05:06:17 -0000 Hannes Tschofenig wrote: > Hi Carsten, > >>> Especially if it will delay COSE. >> There is no need for that to happen. >> The current plan is to relegate the CDDL specs to an appendix once the >> structures are stable. The normative part will be the English text (at >> least unless CDDL manages to overtake COSE...). >> (Just as the examples aren't what's normative, either, but are what is >> being used by implementers anyway.) > > Who came up with this plan? I don't remember, because it's the obvious thing to do. Its been a while when we discussed this. E.g., http://www.ietf.org/mail-archive/web/cose/current/msg00239.html (No, I haven't written the English language generator yet, but it is still tempting to do so.) Grüße, Carsten From nobody Mon Aug 31 00:11:47 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9641B2C27 for ; Mon, 31 Aug 2015 00:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig0zeXkMeQxJ for ; Mon, 31 Aug 2015 00:11:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651741B2C1D for ; Mon, 31 Aug 2015 00:11:44 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MO7Ca-1Zbmu12h1w-005ay7 for ; Mon, 31 Aug 2015 09:11:42 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E3FE2A.1010807@gmx.net> Date: Mon, 31 Aug 2015 09:11:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I90xo7h2i2kqge3x2O97s7dxtm6hhjeKH" X-Provags-ID: V03:K0:8N+YJ6L7odZ40YDjPtGS7Zy4kgtG9nrnEupZEPClRn5ORv24NJz uUeAF7RToI4RxXY7A8l5lronOPkCIWXUEA+zGoz2XRtL0TjK5B8bQ8eSTafullMEaM74xEY Jz6V4SHG/tnHvppQeU8i78osdMC25FdazNlHCwoy8ihxlKeuf7A6nImkkyG1xxjOp5L4H7R RIuhT/fiKlI+KFV7SpUog== X-UI-Out-Filterresults: notjunk:1;V01:K0:CBdIckMColo=:b7PImE1Trswt12OEhI60Mh KHSRyep4kXdNvN+cxVxWX4rm7/wefS9DYGazqh0N4QXfOhNsfvefF0Kq/rzL5JVnF9TYGFUUZ y5cvuGs46C/4pIJ/l0q5BWSujqKq2BjvU0g0E0SbXKHysV8rDEHabWybFTXOyePfo4W09lWyG PBmK60biduSAN+cWiuDPWUrZLBfPrJP/AGzvMX7s5apb9vpg+7X4c6LW8c9Cuu48xs3X0iRqj sHUCEhDfmNoPK29acVzl2sJrhtS15BlQBjPTfB4EyEdHnEd9+TA2f6z2yER3mSq9HonWEiMiQ Mqnav8m7Dbz20ugDBt+STRjr+YUwPfDqN35mM0EA/HXW3FDBRuJLPNHKSVnJfN7zK578FVXC+ OajXLPVnFJcW5LEWfDi4wpO37nkYi3F0GNiEJpY7cIiXbprwAqAIYA7J+8Pakja+mbGXjFP7Y VMmfoCuPJkzZ78Ao1/bQJPZtUeI/rW/N6jmUTmdC9emagyytjmURvqf07i95nw8uP7F2XD/IU WFxnWJgbCpvXaL46dfUfAcVKb1AtwgDkvNzjp6j9M8CrqGJXYRrH/5GgcrrtcQRt9mtfLLv+r +VqeJensfUBJvdylT6oEBFqs6r1oxm6oYM2yhE6lmXDFmJOv1pzMoGbNr52NupWbKf4NHMzFq mftZyF4U+2eCQgjPPSt+CR1Wso8XnwTlJCXuc6Eyvv+Uh5AaZR/fW+Y7IaQPX8j7Co+yxLc7O pkNkLzddpBNMvMv26MU0ENH3JFeuhHG8xr91zQ== Archived-At: Subject: [COSE] Data Types X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:11:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I90xo7h2i2kqge3x2O97s7dxtm6hhjeKH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Hi Brian, CBOR introduces a couple of data types, such as text string and byte string. COSE-04 uses tstr, bstr, etc. I suspect that they are simply the short-hand version of CBOR data types. This could be mentioned in the terminology section or, alternatively, you could also use the CBOR defined terms. Ciao Hannes --I90xo7h2i2kqge3x2O97s7dxtm6hhjeKH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV4/4rAAoJEGhJURNOOiAtdNoH/1KbpnVFX5WE6iZK/+NGbZjZ HvAemQBHmXMNBBPsRa1izs4GLAhYptx+3EHZh2pfFEuMN7J2pNTliHmydgZ04/er ff5jdEm6gFnlUhmXnWuJ48b6DIYWLONaZ1f/1c4UfAcJRcuAxuGTIOlgOf6AI96A ppJDuWGvruMvencO3XsmFVEi2ZEE3gFqNF8sMujEP40KMTD733Fh0iZ5CbjQsn2t RrOkISqHIjaraU/AoKnUc1vVClP59me8ezYUEuXqnpqIV67JhgIyv4e1sRdt+Rjr wDn9PvmpKykVIh7alfZAPw9NNNRM9Bz0T0GYyGUclHSaWdEfNfubrEorfZqfzFg= =1lC0 -----END PGP SIGNATURE----- --I90xo7h2i2kqge3x2O97s7dxtm6hhjeKH-- From nobody Mon Aug 31 00:12:07 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3701B2A26 for ; Mon, 31 Aug 2015 00:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP9zNX5CkT-C for ; Mon, 31 Aug 2015 00:12:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60F61B2C33 for ; Mon, 31 Aug 2015 00:12:03 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MHal6-1ZZb373948-003Oxn for ; Mon, 31 Aug 2015 09:12:02 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E3FE3D.7060400@gmx.net> Date: Mon, 31 Aug 2015 09:11:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NkpX0E7JvLfaeFrNj2VxRBmLuhUR395Rc" X-Provags-ID: V03:K0:nXieJkFUED77tp7TkxC/hdaVwvqkd8LkJHyMzVw/4A2V8JlM92Y liKFwrY2aYiq8Be2yaBii4RCTdMmU7rqmdq5PAwHnvafCnlKBv8Rwm/+Yx5oi1Rzl0KmACl bK4vT0cCvAp/7OedUsUyfoV2IL9RJADIYDoH54YzQxy2avr+bkNM4ecwKcuwaREJsvDW5ou bp13SrJF0Wvt2qvnuwL9A== X-UI-Out-Filterresults: notjunk:1;V01:K0:cQbb0GoQjBg=:hK5rE5Qw5PFhJc/hFyHyaC J6I/GY9kbvwdTKGcuno7RZmUkiAq6X3WrxOeK3CSd8Dp+E0rkxHcakZBfoRg/GzeSgRyD5P9n GP5rXfKasTOGr4SEsas3UOVefTQ1Jsbd6thnqTitKwGNSSQQeLUfSwUyG3KGRE4KIn2gQRrQe orI5irrts7MBSuzOITIbH7wm3WWF1wf/BZl0XmH/vHNyAphE4lLlng5X/331JQA7TXIP9hz2b Dd9Zac1Ca7aiq99jhPlSMKvu1hK6ssu+PcVnJqy7yVcukaKkgEPJg++opRwRn6Br53ObWGJYx Cwe7/Fnlu5Ub+tP9BMguTW5OGljK26gKL23AE+qvs6yb3NO5Q6g8Bnv6yBSBz4wFOGUvcL6z0 UL/qavBulziadnSNzP5F9jv5Yj78ohzphXW7g92+JXapdHywkwESIqAfK5G2Q9eU7gC6I+O1G NG584s/IK3nb5m2yJNWCKiE431lGA6GcHoVPTgLbf3KqmVxcWbVEFkkiHNGaxKLYMNphHPfsO RKmrd2Z4J/LmCk8H1H+Re95SqTDONpogV4avn42MKfGqVHdFB/X05EIGu/8YjH7dgzk/9vwfx 3jGxtNXS7YCsY97Jqv2C2vAfLG46yhf+uYa/G7DGw84QKT11HFuA5LubsdLNu1fhYxcJnxuQG 1PFAsXPlFdW89rDBlzGJjaJqp8l8NY3iojxFKVKQMDgtzJDBsk5JTBMfm1atnogQZ9th4JcmK WLJOpkAF+G3M06k2SwlOeWJ3zBsVmADJJWZYGQ== Archived-At: Subject: [COSE] alg Header Parameter X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:12:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NkpX0E7JvLfaeFrNj2VxRBmLuhUR395Rc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Hi Brian, Is it possible to make the alg parameter optional? Reason: When a key id is used then all the necessary information, including the algorithm, can be determined from the key id itself. Table 1 ' Common Header Parameters' defines the alg parameter as follows:= +----------+-------+----------+-----------------+-------------------+ | name | label | value | value registry | description | | | | type | | | +----------+-------+----------+-----------------+-------------------+ | alg | 1 | int / | COSE Algorithm | Integers are | | | | tstr | Registry | taken from table | | | | | | --POINT TO | | | | | | REGISTRY-- | I would prefer to only have one option to represent the value, namely as an integer. I also think that you could include a pointer to the appropriate section. While the other text in this section points to Section 15.3 I don't believe that this is actually correct. Regarding the fields in the header parameter table I was wondering why not to standardize the full list as listed in the table. Currently, a number of entries are marked with a "*". Regarding the nonce field do you expect it to also serve as a container for sequence numbers or do you plan to add a separate field for it? What about adding a timestamp field (for an alternative replay protection mechanism for those cases where sequences numbers are not appropriate)? Ciao Hannes --NkpX0E7JvLfaeFrNj2VxRBmLuhUR395Rc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV4/4+AAoJEGhJURNOOiAtSMMIAIxG7HFbT9rJgqP4geY4eoM2 lsQN8GYQQqreO9vrk08qiWTYM5/9IOXRCkPSzaCMZAOg6mzgEwjHZeg8HdqXd+W+ Vywi2Y7fIU8QGQTuEi1APqV5lctO9BXrMRDtgWe8/QcBwMdFG3TqAFTasN6L+Mmq BTqft/q3XJti187GXfoCME23sAJF5cQZF5n8apwOW8ktrmgwmC3PJEGrVMl21aDP Dght8KCQd7iQp851MOCXvSvXE2oxcWTc6kp5bME+mpOljOLw04GX84rdAy4Knrjd OX8EGgP/AouVK+JLk2smEegNHLtvpzqWPnE76x4Q/Csf7XFoegm0RmvXLVzoFT0= =BRfJ -----END PGP SIGNATURE----- --NkpX0E7JvLfaeFrNj2VxRBmLuhUR395Rc-- From nobody Mon Aug 31 00:22:32 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747451AD0CA for ; Mon, 31 Aug 2015 00:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBdwcunLMEdG for ; Mon, 31 Aug 2015 00:22:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7991AC39E for ; Mon, 31 Aug 2015 00:22:27 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MUoiS-1ZBXy90bvQ-00Y7I2 for ; Mon, 31 Aug 2015 09:22:26 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E400AC.7090507@gmx.net> Date: Mon, 31 Aug 2015 09:22:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EaNtEwPW7Fx5DH2R6iVU9vdlQx2jgAqlb" X-Provags-ID: V03:K0:sJ4QZ61bYZ6a5ZvRvt49STHu/PYvODGfYhUTfL77wFm/sJAoCXB nGlluDRwgrkDOItnPklbj5FaKznxvWb5xlTC1p/7vDS87QpC0s2PoiK3oSTjDQWPFrPJVR0 WOppDK8SBnpTat9esdiQBsruC+xBazBkBr606D+LKQ6+RZLM7cklygWQm0h/NfXPcmiQ+pk q+OMaq7bLvYTvT2Y7KSeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:0C7poBngssg=:7BgE/eSr+eh1uCI68OXzkx TjWPo26HmKMEyheVJG3um/f3vhCXfx3f1afS2Zo9EUxpwK22AChNdqCeByAdKS3evCwVXRJNC lQec4ZaM3+30aMKfoiHXK3jyNNf364Y0yEdtDacqEcBQ8KLLp1AY/m49f0h5w9XGWsyq7RKeb 7A+/749L0kb8cagD/vam6MJtPC1BKIxYs3UBthBD2lSux0C8pwHuhVG3NdWW9kGsPzEGy86ad 9Tj+N4xSrW9udvqeeiriU+DekoPjv/NehlQ/7s5SeCJdJGly9tvdeQAXX9BrIkB/YKR/PAfuQ xxMhY3muK8JFrUAH+9g2SEwr+CfDW2Z4YTaZDlQxvaH+q31Iy4us2ASyfjZi+THbUgaBmaao9 3SqjDaEDJcHQ27phPHvVANT79nfRH6knBgxB6Q/flDP0SZ39+yUKjhRTAWB3obVxwMMJk07xG mBfHo7ATVqQIS+oH/3A1rhtR+PiVpc7xLARCR/yI7zVdS2zdstZ07LgZgcjl+zCfPtdSlCp+I WUJi88p/3mG0wGxqWyoTp14lT0+207onsAwZsDU9UWW5qg9gmI+HdGiKIglgm+1BKEAAMbxS8 CmXccaRI7hjJjGr50FzJJIl8bo4+MsdNhQmhD+7FQieRSkVGC3B0rWspITeHi9te2skRrgyHK kuoJteXWBPrm9JIgiq5XtkASal/ZGFuLTjY2A5OKHByKpE/2iREE0piwlIC3kDGXPY7GHN5+0 XSUBkU8epLPTkbU64Ilj1RbJTFsVZWEhUPkGRQ== Archived-At: Subject: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:22:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EaNtEwPW7Fx5DH2R6iVU9vdlQx2jgAqlb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Brian, all, I am trying to compare the work on multicast security done by Sandeed & co against an application layer solution using CBOR/COSE. The DTLS multicast includes the following relevant components: - Epoch: 2 Byte - Sender ID: 1 Byte - Sequence Number: 5 Byte The combination of epoch, sender id and sequence number are used as a nonce for the cipher and the use of the sender id ensures that no member of the group accidentally selects values that will cause re-use. The 1 byte sender id is chosen small to reflect the expected size of a group in the professional lighting environment, as explained in the DTLS multicast document. Ciphersuite related information includes: - Encrypted Content (variable length) - MAC (variable length) Content Type, Version and Length are DTLS-specific aspects that cannot be removed without re-design of the record layer. Data based on Figure 4 of http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08.txt. Since there is no sequence number defined in COSE I put the epoch and the sequence number together into the nonce field. Here is the commented version of the COSE message I came up with: [ 2, // Encrypted COSE message { 1: 10, // Algorithm - AES-CCM-16-64-128 5: h'89f52fa' // 7-byte nonce }, h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', // encrypted payload. [ [ h'', { 1: -6, // Direct use of CEK 4: h'01' // Key ID - 0x01 }, h'' ] ] ] According to cbor.me the resulting COSE encoding has 59 bytes whereby 28 bytes are purely used for message encryption. This means that there is 31 bytes overhead with COSE compared to 12 bytes [=3D 8 for Epoch + Sequence Number + Sender ID, 3 bytes for Content Type and Version fields]= =2E Ciao Hannes --EaNtEwPW7Fx5DH2R6iVU9vdlQx2jgAqlb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5ACtAAoJEGhJURNOOiAt+IgH/0AAcU1dkWafW/NIX+hYRb1B 6FgfnxFM49soLnGQmjpPCPtGO71kiYr5mX9yH5JI1ZBDFqYTQnUgXj4gDH03beGg u/s6JTN52iJ3ZtQqcZKR73Dsj7K0pg7Fc5yUAFQDimWrGTj63g18rkBe9AQaim/I ewYIFZa+tH/yarv8fBTmBC/TFlSIAQpdvyLq5kL14dyuoDR7iSd3tPj0vfZLHXHX qv+fG7UCdb+9O2JXJuNCvwgjse6anCCRpviz7n4OElH29XhHk7CM6KvM3aFQ66zJ c4yc1wjkyFyIq+rpTw7kNUwLXByHeg5RVMP39krETO/25fb+vyEVXsnG3+b+L9A= =69H6 -----END PGP SIGNATURE----- --EaNtEwPW7Fx5DH2R6iVU9vdlQx2jgAqlb-- From nobody Mon Aug 31 00:32:42 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854741B30C2 for ; Mon, 31 Aug 2015 00:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsMgwwVEwq-l for ; Mon, 31 Aug 2015 00:32:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBBC1B30B6 for ; Mon, 31 Aug 2015 00:32:38 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LiDrv-1YtjF92F2B-00nSFE for ; Mon, 31 Aug 2015 09:32:37 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E4030F.5020009@gmx.net> Date: Mon, 31 Aug 2015 09:32:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TH5rbhupH06R32G1A11wSKcUqQOmUSLOx" X-Provags-ID: V03:K0:jaKzwzSZK6Q/7NvkbCqbvcaMa1VJ0+puYaYnOW0Ibr+X8LzWrOv KujjR9xLAdzIZuxNoJ1Lx0fZ9zvp+zwJZSizH6AelTpGEhq+RTFe/hvri1euAnuT7SlsVRh fLX5CnUuAqPzX78nQgapXTbrOYsOAaAf3PXUePYPGGRhGDSCNzozGolfhG9+HV6Ilpuvhof QXH6uO33DL0sSvFpF+lsw== X-UI-Out-Filterresults: notjunk:1;V01:K0:F922dEZEELc=:XDt7SNdiyv3jdAw5LaF6j+ E/kFwyXccf7KRASUQ6x2UkmS4lgeQOBsuw4belQ/DyqtdgQh/Su6t0J4dG0ScXT0oU2RJmhKw FlzkjFZ5Lk1P5UHUNg+wHzMky+LP33sMupHQ9kcWSCV3w7ZEnVUOV8ktGKh8ZCMO7eyVapcak KXeZl5JY6iaGODEy6zbkddF9+4Wz2cHa2b792vY09eYY3EkmfQT4phgBVZcay5r1hPmztdh+2 Ll4QJwqr1CLPo6pkzzcGMpk1WbjtCZ5uuygE1pfLlnSM8ieYo7mfpwTymqLXgpS5LPt21OOm1 qINGWlXJM68V7y5S1bNbkq1wYg/0c8RZyU79cu1VZa9TFkFaHuTGj2UQBZrtk8pN2S2oUmHCs 3mTAOl4noTOQ9qxobvGerlXmrOo+8UMK+61ZnrrFt5QpanZqyhDNeY1dDK+S26Zn0/1ChxTZF EeHcw+qih92jYyA70g+IwvJzN30tAM+hYPYmtPiaE4Caio5x801ALc6aD64MzkW7Jpx2CgiOR 1eZhFPyGaP9P3PeWuU+2vbE0JDUNlHmCeDswwAlS7mipNcr0w8ANpJ458zofSWT0VAqN9Dn3k qAJm742DaQLzO+Im69pO0Ko2cr2ZlM+PuIfe1jFu5oBz+YYtXDuGKxLPkZVnoq0hmehiPw+J3 NUDr/fWj6NF+2j/Z2L5cv3R8Ac/DGLt8vi5pg5pcTKESvjyyQYji3AtkhU6KLB6+Mbw57QDRz LpA0fOVSLm9j0nAyaHUX5RAlKggPPYUATe/Auw== Archived-At: Subject: [COSE] CDDL Grammar Descriptions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:32:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TH5rbhupH06R32G1A11wSKcUqQOmUSLOx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, Hi Jim. you write: " The CDDL grammar for a signature message is: COSE_Sign =3D [ msg_type: msg_type_signed, Headers, payload : bstr, signatures : [+ COSE_signature] ] " Then, you explain the fields. " msg_type identifies this as providing the signed security service. The value MUST be msg_type_signed (1). protected is described in Section 3. unprotected is described in Section 3. " Unfortunately, protected and unprotected are not part of the CDDL grammar above. So, it would be better to write: " msg_type identifies this as providing the signed security service. The value MUST be msg_type_signed (1). Header: The header parameter is described in Section 3. " The same occurs in other places of the document. Ciao Hannes --TH5rbhupH06R32G1A11wSKcUqQOmUSLOx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5AMQAAoJEGhJURNOOiAt77YH/jLjr7TKEieYN68Swf+Rg+w7 BrorARcY6xXDLzaM1mENcWL+4ha8kzRURK9DHEqj9teWJ2t5fZZfRUBLhsjZqbLM 9ogNFksGw0Nz60sDa98elbCuy6WZN+tpCje3M0SCSCvKdS7Fhr6f7VWSnN2l9Tk/ KAywvha1yFra76SkrvZccY3r9JwJ4NxWHH1ysnnAReHEqpbIkHEoOGaclXI/fciY PwoP2NGH0q9ZD7EX84ePdhxxLQGgz/bKkG/U8yXJoWf1H4PSShBUWNQNgimnbIpj xqTI25n2H38qIdVZBml/xUvaqBgHj6x05Z0/BsYwp2SrHbEzrUX2SSARpwzwBMg= =Skq8 -----END PGP SIGNATURE----- --TH5rbhupH06R32G1A11wSKcUqQOmUSLOx-- From nobody Mon Aug 31 00:33:23 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E721B30E5 for ; Mon, 31 Aug 2015 00:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqOYOK03ZKR4 for ; Mon, 31 Aug 2015 00:33:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1931B30E1 for ; Mon, 31 Aug 2015 00:33:20 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M86jp-1YkPrb2R61-00vfjo for ; Mon, 31 Aug 2015 09:33:19 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55E4033A.8010409@gmx.net> Date: Mon, 31 Aug 2015 09:33:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="buETd7qVwqvlDfjv7nvkEAJSdtwMt8NHI" X-Provags-ID: V03:K0:PcFbVD3QhhUJ7qafC4L6Wp/Url//hBzBuXl2f3tltUIvuv5SqmN ldtF1msEw5rPfpWg8ZI/oLtRFg8zawuZtFsH+ppTi3AcCjDmMCkOgduNZ4OBjcHVdPUBo23 19Xajf6P638Y4d6LQB/LfwMk4IpiYXYv9gOpar8vFvrtEsJrC+2SrWP9bJOGJ80YsosBmoS cLaGKRfg4zAG4KInJAY0A== X-UI-Out-Filterresults: notjunk:1;V01:K0:7Mp3i13uPu0=:cQbmK7ZvGokqpLtrBi3mhj ALP6T1eE6hGHyCzEU+Lhdo09Zp6UjC+vWxWZWjmL3XqTipQcjHv2Gi8UO08f5+pBFr1gjY6vT 3+xZDoCg401SNr7gDUypoZO2eHhUPa5RnaOFDPOn7isVAwG2dXYGrdQ+zfxBZhU2DvSkl5DWx n59SE/dBTRsknhUlLWhB9bAqEK40k0U9UPhK/izYiOlVnHAKBgIoy8kghNDOPmOqdOGeVrE/k cJ8OBqB0OqHejiBBiKIbfg99AovDtzZNzRPhrl/MZ6WekYdJIrgq4ahCB91XgDDAViCKdpi6U 2YXTZHqQX55ZDXKnmwIQ9Mmc8ny6+enRFyFdCQW07WfbDJExx/1MYTnbLq02MwQx/ijrLxzBx hz0018X5XRKvHk+yDpi948nHnoWjX9I642MckLd1R97yITLkxciLT30lwOqJkRvjNDX8Xo61z N29tqPbszje1VI1hTBMh4mMszqdb4MynxlPhymMyuKZjchjyLPcbnhHFsGvnMuJz/OqhiGNoJ KKpuTMSgstjCtxQhpLx2wZ6D3E1OiSkCk9R7JCWDf9t6XaAjTdTDyIgEub9zFN9QGCnJUGWDP QI/9DmqnyQ8yrCCXMTAWZS8gkhXOhY+u3bcdVpPQzjeJZw4+maREwHjbTw7xNaKPzS9ikAXE+ eZyhHQXGgNPhJVX0qecTS6nCs7O9U/TH+RZBSynENZv41E5ZXEmRCvFXyD+6R/LmbQ1BaJD/q 8PM79G/SKfAhAPcPqJ/Jz2mY90rM+LJo2UmAwQ== Archived-At: Subject: [COSE] 'Common Header Parameters' and 'Key Map Labels' X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --buETd7qVwqvlDfjv7nvkEAJSdtwMt8NHI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Hi Brian, Table 1 defines 'Common Header Parameters' including kid and alg. Table 2 'Key Map Labels' defines further labels, such as kid and alg, but those appear to have different semantic. Maybe it is possible to give them different labels to reduce confusion. Ciao Hannes --buETd7qVwqvlDfjv7nvkEAJSdtwMt8NHI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5AM6AAoJEGhJURNOOiAtx74IAKF5oyjgK9gfllortVWEG5Of lvPfCOdaPljoQcmM0Rz54jZnCq8Q6eoL5QotxLCCGrc81OgPoBJxT1aZoypvIQg7 +aT5bMUu5fKWP9k0j1/XSM54PQx+bApcCNIy4WauIUtstFdZQAxUt63U9hTVVrmw xQhhOz9LH55/rCZRm9HXCIEjjY9MJrMgDdo+ZRid7WmpcUrw+/yTjATWe0S+hQLz udP0DSkfCqByFAdDaL9LcRVEJn/PhEdpRnmdfEHTXLkAO4Y017iFpEWYf4UVbcOO fXMcu/MuoJfN8YZ6gENvkQBbRPpe5viI10wkRtNPz26+fw22Qh5WX3ukPuG7gKY= =4XCV -----END PGP SIGNATURE----- --buETd7qVwqvlDfjv7nvkEAJSdtwMt8NHI-- From nobody Mon Aug 31 00:51:47 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C91B3475 for ; Mon, 31 Aug 2015 00:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJi8mcBuebDz for ; Mon, 31 Aug 2015 00:51:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9701B3474 for ; Mon, 31 Aug 2015 00:51:44 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lj25i-1YyuX535yA-00dFkY for ; Mon, 31 Aug 2015 09:51:42 +0200 To: "cose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55E40787.6010603@gmx.net> Date: Mon, 31 Aug 2015 09:51:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x4umEudH2xCD6nlQme6Qi3pubAJX6FB8B" X-Provags-ID: V03:K0:rgXIEs/bC3ioMKBp+CTFt5k7Eba7VJVRICRt0mBwLSEE4fosVy9 UCSWaMpT8tfjOm2ckTHV/d2K6rrdg9zFfl9AGhdoU2xPAfBTLesOvdhjVMa+doasyojmliD Xb6WzbopC6mKZBJWvrAwEMM5pCBRCaqddvist1MnbN04VpkoDG2eJEdO2EiuIOeR+bP53hg vgRIl2lSt8hodWgL/4gsA== X-UI-Out-Filterresults: notjunk:1;V01:K0:qlYo5eomOjc=:ErsfNLn/iDid5K7UIe+bd8 kh7Y2Dn38j6gQheYv3gFudEpu58vOhnrp9XdttAVwS75k7YNBITLmxrtqKOxmsC+KZWneyhtw pqZtXBBaYzfBh/iwTqpEqugXvX8lF1+5SclLmhq5vHVkzYPQ4E6ErOdCgRc6yqwK8TzjFsRSj ykL+i4C6A36j+fdnLKUTVK6A740eFj0s2fnpohbl15S8J2vP7MY/LhrwPd3nzHH5AaT9E2yxm eSG7dV1nIzlp0K7AZzVAlDWREQkf9NIxaMfQfQizvZXuUOXB+kenYIcEGGCk7OWaXgC7oIyKP Ul3dQcKZRNzTmgucErlouER/5D4whyDXxqymCdJgTGaMMKSs67M4ZtYQxGi8nuNUvqBbDQk8n +Asrf3uujdE58bUDQnQ7RWkartekaBzR7HOx8GV7FaXE8VnxMLen9MY1eFzh7/MIoIr6fvBy+ oy7TAQKqipfDxLilu/lagpbGs16wOk2pKi/AqTbz5xj5VpwKG+QF2kUu7+qiP3TC7z71xAL4H 6kZ2TVZIl6uu+PIkOH/TlpLW4N3iGe7h5Np1yMD8z9H5ei9LwwiuB93q2PcNsGKFFUzVsz9bx ctexttUqDstGilzVkL2seP4DKnzYmRqFyAkYB0NcyQu9r2acaGga8AbuePnhJt+rF1SzO+Kc/ 3GEVqzgTM9unNJr1QcRx+r1cm5YWkMFjnGC+jqp87Urw6nDfu/rM7jYlSwatWWSwNLGY/pyYw vp0MpyUfvcy9+6Iodr1T3mmkjrRkPyn2XSSZsQ== Archived-At: Subject: [COSE] Security Considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:51:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x4umEudH2xCD6nlQme6Qi3pubAJX6FB8B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Hi Brian, In Section 8 "Signature Algorithms", Section 9 "Message Authentication (MAC) Algorithms", and Section 10 "Content Encryption Algorithms" contain algorithm descriptions. Each algorithm description comes with a security consideration section. Since the COSE specification is just a consumer of already standardized cryptographic algorithms I am wondering whether the security considerations are needed since their content should already be available with the documents that specify the algorithm. Ciao Hannes --x4umEudH2xCD6nlQme6Qi3pubAJX6FB8B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5AeIAAoJEGhJURNOOiAtvioIAJh+ou3e1zYxvqn8kh3qhdZf 8kcIVPmuAaBGwKtH6JlMoHDUPRNZ3Ld++77yGRsak89AbXDECfMLUyb8y7QG2HRy qFEkL8mF5Hkk0CeHB8wd/TnLrMV88aGtFf2L3HSNmuP+UXojOWnp9MYsuiS4uaa6 BucCPwPkj5BYFzd8kAGVFdTxSFsqy3NfVUjXxQ9/EgjFcm6YHEFjWstNiRu/Aw9J UVFUTO3p3R5YekTXTn7I5qStEMlKUqSYhRceKT6xiWKq6/fLLTIPwrr50MriWt89 cBR3xho4airTdY4t2GfeCHU2do+8hhrWeU+UhtAOCy5NYlSUAuiOnFoFUF3PvTQ= =bueg -----END PGP SIGNATURE----- --x4umEudH2xCD6nlQme6Qi3pubAJX6FB8B-- From nobody Mon Aug 31 01:18:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10041A8AE8 for ; Mon, 31 Aug 2015 01:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYYtiyPFIGCh for ; Mon, 31 Aug 2015 01:18:47 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 9D5EA1A21BD for ; Mon, 31 Aug 2015 01:18:46 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so56232577lbb.1 for ; Mon, 31 Aug 2015 01:18:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=w3oTOCTpwEwE7tLTyHH1SMSBvHOXqa5M4+U/vpzLYSE=; b=klR6tigC3SwQBVtN49KixeYe48Ec22xij701d2gm1KRoFlbt0QZQEjlruvhlTW4yVr N2lKvIyw8Qxt+cXTp/k7q7ANMC3D9/BA8GxCmdAEAq36QAKoajuF5iXoiRDCrMJCFNyr NlmtK+IImm09tyCccp2GKZFskU3Nx/fAuemDtJXtbAkEe2ViGg7EqZK/oOWc3rxqMP87 wqVUz6BMN43uFfBGYGQGpjU7+c0/au4Sa4CFG269BVIb19qz5iumattoRjtJ4fFDJsX1 14SomrzCZE1pr5e6RCyV6TvqUOHNfoNgfL7cd3dGqpoPCYmDWjs8CDcpbSBK4DjvlATf 61SA== X-Gm-Message-State: ALoCoQm3tBbxp5rScbkkGWNgbI/gT3WM79owVb6QO6VRLXBZE/SlivZA0RozL5AkaZMIkbhJWA7P X-Received: by 10.112.164.4 with SMTP id ym4mr10014168lbb.7.1441009124995; Mon, 31 Aug 2015 01:18:44 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id uh4sm3721534lbc.48.2015.08.31.01.18.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 01:18:44 -0700 (PDT) To: cose@ietf.org References: <55E3FE3D.7060400@gmx.net> From: Ludwig Seitz Message-ID: <55E40DDC.7030307@sics.se> Date: Mon, 31 Aug 2015 10:18:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E3FE3D.7060400@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040709070603060808040205" Archived-At: Subject: Re: [COSE] alg Header Parameter X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 08:18:48 -0000 This is a cryptographically signed message in MIME format. --------------ms040709070603060808040205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-08-31 09:11, Hannes Tschofenig wrote: [...] > What about adding a timestamp field (for an alternative replay > protection mechanism for those cases where sequences numbers are not > appropriate)? > > Ciao > Hannes > > +1 The sequence numbers are being discussed in ACE for replay protection=20 because _some_ IoT devices can not reliably measure time. Those that can = use time should have a dedicated header option for this. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms040709070603060808040205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgzMTA4MTgzNlowLwYJKoZI hvcNAQkEMSIEIF0mG1Ot+rb1V8KcaJO7dhmMmAQkWYNsl8wvQKRtoo2BMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQB2ST9iKImDGybxNNnUkCuV1LabsKs8B9JzGqHXw5U4 /XJvuKlp0QCqENGbPLXEr5xbAzTp2IQ9YhRYon/dkBu3gUA/j/q5BMvpvBVlFGPysbz7mnvP OmTkmFOX0xEI6BuLlnA9/1a0GX0Yun0BrxKMqNzXzzzfhBmwSBwn48dNony4XJiyYDQejDhr A64v0HREgldAmMYZb9XCD4ClcK/bH4LFDerHLoMj9J+DQLrmABIIpVk/LC7TULyfej1LWFJQ rWOUWHgsPHKUOXQXbKpuSk73tVcaYvAzouvGfazDCi0EBKYigIST0sM5OQb0qR9RReS7tfCa 5Pg8vfmpFjfBAAAAAAAA --------------ms040709070603060808040205-- From nobody Mon Aug 31 02:28:32 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE11B3A76 for ; Mon, 31 Aug 2015 02:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUavA9TsqVAK for ; Mon, 31 Aug 2015 02:28:30 -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 998681B3791 for ; Mon, 31 Aug 2015 02:28:29 -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 t7V9SPpr007104; Mon, 31 Aug 2015 11:28:25 +0200 (CEST) Received: from alma.local (eduroam-pool7-0748.wlan.uni-bremen.de [134.102.114.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n4R6K3Sp8z4vRH; Mon, 31 Aug 2015 11:28:25 +0200 (CEST) Message-ID: <55E41E38.7030404@tzi.org> Date: Mon, 31 Aug 2015 11:28:24 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Hannes Tschofenig References: <55E4030F.5020009@gmx.net> In-Reply-To: <55E4030F.5020009@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] CDDL Grammar Descriptions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 09:28:31 -0000 Hannes Tschofenig wrote: > Header: The header parameter is described in Section 3. I would probably write: Headers: The common header parameters (protected, unprotected) are described in Section 3. Grüße, Carsten From nobody Mon Aug 31 02:51:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20D11B3F97 for ; Mon, 31 Aug 2015 02:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urfjhke-VxaN for ; Mon, 31 Aug 2015 02:51:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61861B3F90 for ; Mon, 31 Aug 2015 02:51:45 -0700 (PDT) Received: from [192.168.10.153] ([101.53.7.10]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MaZWz-1ZHInp2U3d-00K7y6; Mon, 31 Aug 2015 11:51:37 +0200 To: Carsten Bormann References: <55E4030F.5020009@gmx.net> <55E41E38.7030404@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55E423A4.7090605@gmx.net> Date: Mon, 31 Aug 2015 11:51:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E41E38.7030404@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rAH13vp1umPwbETq03OSl5g1BVlrSbn6f" X-Provags-ID: V03:K0:Er9rJTUJtvs3HSJZKT7qG92lmfd6Veg28nEoWl3K2PxENTZ1D9K 1K7MHJIVwU7+5CW6g6U3h2PiG0G83zsiYbxeNDmumMRpUqkzrRPzySgZtu3aJD+nlhHo6ve wBTDYvJxjKmGo5HczACaqWdGNqMOFqdWf6QShaZmRcc9tp59oMp+IHBOczrUeue5Zthfu5+ MaWPJ4DkHMIz+MvC65xhQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:esWvIwQJKUk=:Zf3Jo6EJP6VtqxElkip4ra PNBZwZ6IwYkdqVOO/bII1/2f1wYI5pi7sPSaZAkaKgF/KpL8t4B68TFpXe4hfvzGIzpbb/Qt9 M1VLj44AmXkG3zestDL0WGMvTjJt73AuiMvjkAT+EnSgxewzXmKUk23/oPfjsx3t5ZfG3TD4f YoRZT8+q9DIvXROM53y47rakybmKQnXuROKHQpqjqrQjm/8YThLBXb7Pwo1liYOyORiab0rRV ZTt2hDmy4VythgTEqtnee0fBs7AtqyZWfvlZW8q5+U93hPeewWcNOa6ta0we6+gZCscYeRe4f fbBPhJzQ4X546Aou1lCzCMLAmzg5NzRRPuw8ZYi3O8UfG536nEbVEjs4Uzb1bIhd3mrqUSqv2 p8k2H+J0O7qs7z0vFyqxndNEGLAhkPjPA/PGtnUc1Xnuc0kKOfKCAV63VFkE1nQ+uPjDeKnwI dwl4ZcrqGKILy3EFWQE7EOvqFwpXtb6lsHh5nns7adsfbn4l0rC/m0PND63xFKeMFJjo1PT1p Np26WyUbzgpSBT+H/Taet2EutTk9DEcnYKaadpeXw+tQZXCK1mhJuHNaDJdJJvREj9VzyjpKU tGCeIZAqGzt5ZcPR9ONBMQTgMe1mOxx1V/EDjTtC8Ow7QPnc/5/RZkmyls+T4yC+Sk6Yh7RsD Oe2sdmir+N6318DskD5gr1J4vAJnU86v2ID7b2n2m+5AjDl/AHTTu2khSoSEReiTl22JvMrbF d7//s4+TisyBfpD6DwfHh4GQh1jHgcG/UPTrQw== Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] CDDL Grammar Descriptions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 09:51:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rAH13vp1umPwbETq03OSl5g1BVlrSbn6f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds good to me. On 08/31/2015 11:28 AM, Carsten Bormann wrote: > Hannes Tschofenig wrote: >> Header: The header parameter is described in Section 3. >=20 > I would probably write: >=20 > Headers: The common header parameters (protected, unprotected) are > described in Section 3. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --rAH13vp1umPwbETq03OSl5g1BVlrSbn6f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5COlAAoJEGhJURNOOiAt3dwH/jCzEu22c158ErIjKmjkk3Kg mF0VMhr6+SIfr7GOeYimtK1XNOAbdRM6+W9KXBTxAnvwjKLNQYscpuGTokW6siBy IWDMD3HhMAV2RFqocrKshlNu8zPfkKJWwL6d2ryY2cYyc7xp4OHRATjPO9u8puqw ZCrm1zJjwDPoLi4dt4j2UySvUeHiRG0DJMKeKivNYxrgrSRdySlms6Yrx3CX99JB x5Y0hO70zetMGdXDMZppH4obqX0PWs7ELZmqnv6A8QTNA/Jh9ii+f+Puajk2xbFD uBOxa7Z53tlpPrWHpCFDpeAfyUFYCIJRSen5wZHJywrJYLkE6G9+vVIdmElGfXs= =7ZGD -----END PGP SIGNATURE----- --rAH13vp1umPwbETq03OSl5g1BVlrSbn6f-- From nobody Mon Aug 31 03:50:58 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02261B41D7; Mon, 31 Aug 2015 03:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rakyOUXih9BP; Mon, 31 Aug 2015 03:50:51 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1F31B41DD; Mon, 31 Aug 2015 03:50:49 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-49-55e43187137b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.FA.17026.78134E55; Mon, 31 Aug 2015 12:50:47 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 12:50:47 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "ace@ietf.org" Thread-Topic: COSE requirements from CORE/ACE Thread-Index: AQHQ49rkEpGsSdn1LEmcbWdqGxxzHg== Date: Mon, 31 Aug 2015 10:50:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <69A7C31698E2A847843A5D6FD222271B@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW674ZNQg6mndS2+f+thttj3dj2z xbStU1kdmD2WLPnJFMAYxWWTkpqTWZZapG+XwJVx/+189oIFEhVLbzWxNjBeEO9i5OSQEDCR 2HxvGjuELSZx4d56ti5GLg4hgaOMEr+27mOGcBYzSiyZ+4cNpIpNwEXiQcMjJhBbRMBJounD brA4s4CyROOGSywgtrCAhsT8aa1QNboSJy/uZIOw9ST2ToCIswioShzYd5AZxOYVsJBYcHMd WJwR6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwpiiwLNXHm9iQ0iriTRuOQJUJwD qFdTYv0ufYgx1hL7OtugzlSUmNL9kB1iraDEyZlPWCYwis1Csm0WQvcsJN2zkHTPQtK9gJF1 FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgVB3c8lt3B+Pq146HGAU4GJV4eBW2Pg4VYk0s K67MPcQozcGiJM7bwvQgVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj2IJ1TdW3p76zVlOR OKP19M8Zi3MmEizrKn29Jn/5L9xX2W4Z8q7nxGH26umrJCv51gcF7rvrHvrzQoJUyz0vxaSG nBvzmmq0t6oX7TWN2Pvrzs1Wi9BDTw0P+75+dvvggs5O5xkX783Nu7k39Io1g1Qi95Lp16Z9 /Hr18edDW5fOEH2RtVgqTomlOCPRUIu5qDgRAL0fbBeLAgAA Archived-At: Cc: "cose@ietf.org" Subject: [COSE] COSE requirements from CORE/ACE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 10:50:52 -0000 DQpEZWFyIENPUkUgYW5kIEFDRSBtZW1iZXJzLA0KDQoNCkluIHRoZSBDT1NFIFdHIG1lZXRpbmcg aW4gUHJhZ3VlIG9uZSBvZiB0aGUgdG9waWNzIHdhcyByZXF1aXJlbWVudHMgZnJvbSBhDQpjb25z dHJhaW5lZCBub2RlIG5ldHdvcmsgcG9pbnQgb2YgdmlldyBvbiBtZXNzYWdlIGZvcm1hdCwgY3J5 cHRvIHN1aXRlcw0KZXRjLiBTb21lIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGlu ZyBhbmQgc29tZSBpbiBzbWFsbGVyIGdyb3Vwcw0KYWZ0ZXIgdGhlIG1lZXRpbmcuIEl0IHdvdWxk IGJlIGdvb2QgdG8gY29sbGVjdCB0aGUgdmlld3Mgb2Ygd2hhdCBwZW9wbGUNCnRoaW5rIGFyZSBp bXBvcnRhbnQgcmVxdWlyZW1lbnRzIGZvciBDT1NFIHRvIGNvbnNpZGVyLiBJIGxpc3QgYSBmZXcg aXNzdWVzDQpoZXJlLCBmZWVsIGZyZWUgdG8gYWRkIChhbmQgZW51bWVyYXRlKSBvdGhlcnMgaW4g dGhpcyB0aHJlYWQuDQoNCjEuIE1lc3NhZ2Ugc2l6ZS4gDQoNClRoZXJlIGlzIGEgdHJhZGUtb2Zm IGJldHdlZW4gbWFraW5nIHRoZSBtZXNzYWdlIGZvcm1hdCBhcHBsaWNhYmxlIHRvIG1hbnkNCnNl dHRpbmdzIGFuZCBvcHRpbWl6aW5nIGl0IGZvciBjZXJ0YWluIHNldHRpbmdzLiBEbyB5b3Uga25v dyBvZiBhbg0KaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRpbmcgd2l0aCBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgb24gdXBwZXIgbGltaXQNCm9mIG1lc3NhZ2Ugc2l6ZT8gT25lIHJlbGV2YW50 IHBhcmFtZXRlciBpcyBpZiB0aGUgYXBwbGljYXRpb24gcmVxdWlyZXMNCnNpZ25lZCBtZXNzYWdl cyAoYXN5bW1ldHJpYyBrZXkpIG9yIGlmIE1BQ3MgKHN5bW1ldHJpYyBrZXkpIGlzIHN1ZmZpY2ll bnQsDQpzaW5jZSB0aGUgc2lnbmF0dXJlIGlzIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIE1BQy4NCg0K T25lIGZpZ3VyZSBtZW50aW9uZWQgaW4gdGhlIG1lZXRpbmcgd2FzIDkwIGJ5dGVzIFVEUCBwYXls b2FkIGluIGEgNnRpc2NoDQpzZXR0aW5nIHdoaWNoIG1heSBuZWVkIHNpZ25lZCBtZXNzYWdlcy4N Cg0KDQoyLiBNQUMtb25seT8NCg0KRG8geW91IGtub3cgb2YgYW4gaW1wb3J0YW50IGFwcGxpY2F0 aW9uIG9yIHNldHRpbmcgd2hpY2ggcmVxdWlyZSB0aGF0DQptZXNzYWdlcyBhcmUgb25seSBwcm90 ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUsIGkuZS4gd2hlcmUNCnRoZSBt ZXNzYWdlIG11c3QgYmUgaW4gcGxhaW4gdGV4dCBhbmQgaW50ZWdyaXR5IHByb3RlY3RlZCB1c2lu ZyBhDQpzeW1tZXRyaWMga2V5IGFsZ29yaXRobT8NCg0KQ2xlYXJseSB0aGVyZSBhcmUgYXBwbGlj YXRpb25zIHdoZXJlIGVuY3J5cHRpb24gYW5kIG1lc3NhZ2UgYXV0aGVudGljYXRpb24NCmJhc2Vk IG9uIHN5bW1ldHJpYyBhbGdvcml0aG1zIChhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24pIGlzIG5l ZWRlZC4gVGhlDQpxdWVzdGlvbiBpcyB3aGF0IGlzIGdhaW5lZCBieSBhbGxvd2luZyBNQUMtb25s eSBhbGdvcml0aG1zLCBzaW5jZSBpbiBvcmRlcg0KdG8gdmVyaWZ5IHRoZSBtZXNzYWdlIHlvdSBh bnl3YXkgbmVlZCB0aGUgc3ltbWV0cmljIGtleS4NCg0KDQozLiBTeW1tZXRyaWMgZW5jcnlwdGlv biArIGRpZ2l0YWwgc2lnbmF0dXJlLg0KDQpGb3IgY2xvc2VkIHN1YnNjcmliZXIgZ3JvdXBzLCB3 aGVyZSB0aGUgZGF0YSBtdXN0IGJlIGVuY3J5cHRlZCBhbmQgd2hlcmUNCmVhY2ggc3Vic2NyaWJl ciBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRoYXQgdGhlIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t DQp0aGUgcHVibGlzaGVyLCB0aGVyZSBpcyBhIG5lZWQgdG8gY29tYmluZSBzeW1tZXRyaWMgZW5j cnlwdGlvbiB3aXRoDQpkaWdpdGFsIHNpZ25hdHVyZS4gIFRoaXMgY2FuIGJlIGRvbmUgYnkgZmly c3Qgc3ltbWV0cmljIGVuY3J5cHRpb24gYW5kDQp0aGVuIGRpZ2l0YWwgc2lnbmF0dXJlLCBvciBm aXJzdCBkaWdpdGFsIHNpZ25hdHVyZSBhbmQgdGhlbiBzeW1tZXRyaWMNCmVuY3J5cHRpb24uIERv IHlvdSBrbm93IG9mIGFuIGltcG9ydGFudCBhcHBsaWNhdGlvbiBvciBzZXR0aW5nIHRoYXQNCnJl cXVpcmUgYSBjZXJ0YWluIG9yZGVyIG9mIHRoZSBvcGVyYXRpb25zPw0KDQpPbmUgZXhhbXBsZSBp cyB3aGVyZSB0aGUgcHViLXN1YiBicm9rZXIgc2hvdWxkIGJlIGFibGUgdG8gdmVyaWZ5IHRoZQ0K c2lnbmF0dXJlIG9mIHRoZSBtZXNzYWdlIHdpdGhvdXQgZGlzY2xvc2luZyB0aGUgcGxhaW4gdGV4 dCBwdWJsaWNhdGlvbi4NCg0KDQpUaGFua3MsDQpHw7ZyYW4NCg0KDQoNCg== From nobody Mon Aug 31 04:09:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCDB1B2F13; Mon, 31 Aug 2015 04:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUZGZib7yXZS; Mon, 31 Aug 2015 04:08:55 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (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 BBB281B3F61; Mon, 31 Aug 2015 04:08:54 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id t7VB8pUf022413 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 31 Aug 2015 13:08:51 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.1/8.15.1) with ESMTPS id t7VB8pIP030838 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2015 13:08:51 +0200 Received: from DENBGAT9ERGMSX.ww902.siemens.net (139.22.70.137) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 31 Aug 2015 13:08:50 +0200 Received: from DEFTHW99EI4MSX.ww902.siemens.net ([169.254.9.247]) by DENBGAT9ERGMSX.ww902.siemens.net ([139.22.70.137]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 13:08:50 +0200 From: "Cuellar, Jorge" To: "goran.selander@ericsson.com" , "core@ietf.org" , "ace@ietf.org" Thread-Topic: COSE requirements from CORE/ACE Thread-Index: AQHQ49rkEpGsSdn1LEmcbWdqGxxzHp4l7qQw Date: Mon, 31 Aug 2015 11:08:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] COSE requirements from CORE/ACE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 11:09:00 -0000 RGVhciBHw7ZyYW4gYW5kIGFsbCwNCg0KPiAyLiBNQUMtb25seT8NCj4gRG8geW91IGtub3cgb2Yg YW4gaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRpbmcgd2hpY2ggcmVxdWlyZQ0KPiB0aGF0 IG1lc3NhZ2VzIGFyZSBvbmx5IHByb3RlY3RlZCBieSBhIG1lc3NhZ2UgYXV0aGVudGljYXRpb24g Y29kZS4uLg0KDQpJbmRlZWQsIHRoZXJlIGFyZSBzb21lLiAgRm9yIGluc3RhbmNlLCBzb21lIHVz ZSBjYXNlcyBpbiBTbWFydCBDaXRpZXMgKGJ1c2VzIHNjaGVkdWxpbmcvZGVsYXlzIGluZm9ybWF0 aW9uLCBzb21lIGFzcGVjdHMgb2YgZW52aXJvbm1lbnRhbCBtb25pdG9yaW5nLCBnYXJiYWdlIGNv bGxlY3Rpb24gbWFuYWdlbWVudCwgZXRjKSBkbyBub3QgcmVxdWlyZSBjb25maWRlbnRpYWxpdHkg YnV0IGludGVncml0eS4gIEFzIHRvZGF5IGlzIHRoZSBjYXNlLCB0aGUgZ2VuZXJhbCB1c2VyIG1h eSBiZSB1bmFibGUgdG8gdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGluZm9ybWF0aW9uLCBi dXQgdGhlICJtYWluIHJlY2lwaWVudCIgKHNheSwgdGhlIGNpdHkgY291bmNpbCkgY2FuIHZlcmlm eSBpdC4NCg0KQmVzdCwNCkpvcmdlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEfDtnJhbiBT ZWxhbmRlcg0KU2VudDogMzEgQXVndXN0IDIwMTUgMTI6NTENClRvOiBjb3JlQGlldGYub3JnOyBh Y2VAaWV0Zi5vcmcNCkNjOiBjb3NlQGlldGYub3JnDQpTdWJqZWN0OiBbQWNlXSBDT1NFIHJlcXVp cmVtZW50cyBmcm9tIENPUkUvQUNFDQoNCg0KRGVhciBDT1JFIGFuZCBBQ0UgbWVtYmVycywNCg0K DQpJbiB0aGUgQ09TRSBXRyBtZWV0aW5nIGluIFByYWd1ZSBvbmUgb2YgdGhlIHRvcGljcyB3YXMg cmVxdWlyZW1lbnRzIGZyb20gYSBjb25zdHJhaW5lZCBub2RlIG5ldHdvcmsgcG9pbnQgb2Ygdmll dyBvbiBtZXNzYWdlIGZvcm1hdCwgY3J5cHRvIHN1aXRlcyBldGMuIFNvbWUgaXNzdWVzIHdlcmUg ZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nIGFuZCBzb21lIGluIHNtYWxsZXIgZ3JvdXBzIGFmdGVy IHRoZSBtZWV0aW5nLiBJdCB3b3VsZCBiZSBnb29kIHRvIGNvbGxlY3QgdGhlIHZpZXdzIG9mIHdo YXQgcGVvcGxlIHRoaW5rIGFyZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIGZvciBDT1NFIHRvIGNv bnNpZGVyLiBJIGxpc3QgYSBmZXcgaXNzdWVzIGhlcmUsIGZlZWwgZnJlZSB0byBhZGQgKGFuZCBl bnVtZXJhdGUpIG90aGVycyBpbiB0aGlzIHRocmVhZC4NCg0KMS4gTWVzc2FnZSBzaXplLiANCg0K VGhlcmUgaXMgYSB0cmFkZS1vZmYgYmV0d2VlbiBtYWtpbmcgdGhlIG1lc3NhZ2UgZm9ybWF0IGFw cGxpY2FibGUgdG8gbWFueSBzZXR0aW5ncyBhbmQgb3B0aW1pemluZyBpdCBmb3IgY2VydGFpbiBz ZXR0aW5ncy4gRG8geW91IGtub3cgb2YgYW4gaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRp bmcgd2l0aCBzcGVjaWZpYyByZXF1aXJlbWVudHMgb24gdXBwZXIgbGltaXQgb2YgbWVzc2FnZSBz aXplPyBPbmUgcmVsZXZhbnQgcGFyYW1ldGVyIGlzIGlmIHRoZSBhcHBsaWNhdGlvbiByZXF1aXJl cyBzaWduZWQgbWVzc2FnZXMgKGFzeW1tZXRyaWMga2V5KSBvciBpZiBNQUNzIChzeW1tZXRyaWMg a2V5KSBpcyBzdWZmaWNpZW50LCBzaW5jZSB0aGUgc2lnbmF0dXJlIGlzIG11Y2ggbGFyZ2VyIHRo YW4gdGhlIE1BQy4NCg0KT25lIGZpZ3VyZSBtZW50aW9uZWQgaW4gdGhlIG1lZXRpbmcgd2FzIDkw IGJ5dGVzIFVEUCBwYXlsb2FkIGluIGEgNnRpc2NoIHNldHRpbmcgd2hpY2ggbWF5IG5lZWQgc2ln bmVkIG1lc3NhZ2VzLg0KDQoNCjIuIE1BQy1vbmx5Pw0KDQpEbyB5b3Uga25vdyBvZiBhbiBpbXBv cnRhbnQgYXBwbGljYXRpb24gb3Igc2V0dGluZyB3aGljaCByZXF1aXJlIHRoYXQgbWVzc2FnZXMg YXJlIG9ubHkgcHJvdGVjdGVkIGJ5IGEgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLCBpLmUu IHdoZXJlIHRoZSBtZXNzYWdlIG11c3QgYmUgaW4gcGxhaW4gdGV4dCBhbmQgaW50ZWdyaXR5IHBy b3RlY3RlZCB1c2luZyBhIHN5bW1ldHJpYyBrZXkgYWxnb3JpdGhtPw0KDQpDbGVhcmx5IHRoZXJl IGFyZSBhcHBsaWNhdGlvbnMgd2hlcmUgZW5jcnlwdGlvbiBhbmQgbWVzc2FnZSBhdXRoZW50aWNh dGlvbiBiYXNlZCBvbiBzeW1tZXRyaWMgYWxnb3JpdGhtcyAoYXV0aGVudGljYXRlZCBlbmNyeXB0 aW9uKSBpcyBuZWVkZWQuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IGlzIGdhaW5lZCBieSBhbGxvd2lu ZyBNQUMtb25seSBhbGdvcml0aG1zLCBzaW5jZSBpbiBvcmRlciB0byB2ZXJpZnkgdGhlIG1lc3Nh Z2UgeW91IGFueXdheSBuZWVkIHRoZSBzeW1tZXRyaWMga2V5Lg0KDQoNCjMuIFN5bW1ldHJpYyBl bmNyeXB0aW9uICsgZGlnaXRhbCBzaWduYXR1cmUuDQoNCkZvciBjbG9zZWQgc3Vic2NyaWJlciBn cm91cHMsIHdoZXJlIHRoZSBkYXRhIG11c3QgYmUgZW5jcnlwdGVkIGFuZCB3aGVyZSBlYWNoIHN1 YnNjcmliZXIgbXVzdCBiZSBhYmxlIHRvIHZlcmlmeSB0aGF0IHRoZSBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSB0aGUgcHVibGlzaGVyLCB0aGVyZSBpcyBhIG5lZWQgdG8gY29tYmluZSBzeW1tZXRy aWMgZW5jcnlwdGlvbiB3aXRoIGRpZ2l0YWwgc2lnbmF0dXJlLiAgVGhpcyBjYW4gYmUgZG9uZSBi eSBmaXJzdCBzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQgdGhlbiBkaWdpdGFsIHNpZ25hdHVyZSwg b3IgZmlyc3QgZGlnaXRhbCBzaWduYXR1cmUgYW5kIHRoZW4gc3ltbWV0cmljIGVuY3J5cHRpb24u IERvIHlvdSBrbm93IG9mIGFuIGltcG9ydGFudCBhcHBsaWNhdGlvbiBvciBzZXR0aW5nIHRoYXQg cmVxdWlyZSBhIGNlcnRhaW4gb3JkZXIgb2YgdGhlIG9wZXJhdGlvbnM/DQoNCk9uZSBleGFtcGxl IGlzIHdoZXJlIHRoZSBwdWItc3ViIGJyb2tlciBzaG91bGQgYmUgYWJsZSB0byB2ZXJpZnkgdGhl IHNpZ25hdHVyZSBvZiB0aGUgbWVzc2FnZSB3aXRob3V0IGRpc2Nsb3NpbmcgdGhlIHBsYWluIHRl eHQgcHVibGljYXRpb24uDQoNCg0KVGhhbmtzLA0KR8O2cmFuDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K From nobody Mon Aug 31 05:23:03 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8323F1B2C7F; Mon, 31 Aug 2015 05:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9BAiyJiJt3Y; Mon, 31 Aug 2015 05:22:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC0D1B444E; Mon, 31 Aug 2015 05:22:57 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-5b-55e4471f222d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.1D.27359.F1744E55; Mon, 31 Aug 2015 14:22:56 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 14:22:55 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Cuellar, Jorge" , "core@ietf.org" , "ace@ietf.org" Thread-Topic: COSE requirements from CORE/ACE Thread-Index: AQHQ49rkEpGsSdn1LEmcbWdqGxxzHp4l7qQwgAAZKoA= Date: Mon, 31 Aug 2015 12:22:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+Jvja6C+5NQg0cvmS2+f+thttj3dj2z xbStU1ktbp1dxOrA4rFkyU8mj+0nJzEFMEVx2aSk5mSWpRbp2yVwZcy5u5yloEev4vqxT6wN jF90uhg5OSQETCR6X7cxQ9hiEhfurWfrYuTiEBI4yiixZc0/FpCEkMBiRol5a/hAbDYBF4kH DY+YQGwRgSKJxQv/MILYzALKEo0bLoHVCwvoSBzpO8EIUaMrcfLiTjYI20ri0IrZYDaLgKrE k67JYIt5BSwkDh1dyAixuIVRonXrfFaQBKdAmETD8XtgyxiBrvt+ag0TxDJxiVtP5jNBXC0g sWTPeagPRCVePv4H1isqoCex8noTG0RcUWLn2XagGg6gXk2J9bv0IcZYS/Q/bGSDsBUlpnQ/ ZIe4R1Di5MwnLBMYJWYh2TYLoXsWku5ZSLpnIelewMi6ilG0OLU4KTfdyEgvtSgzubg4P08v L7VkEyMwMg9u+W2wg/Hlc8dDjAIcjEo8vApbH4cKsSaWFVfmHmKU5mBREudtZnoQKiSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoExdOXqs5M2SL5wNjNmWW0bxcPRPOXcNbWu7mVyB0QuvZ9w pHuiWa5dblNKxOrFVY4i6e3TrN4Ilimvzj4Rta9LYI5X3tqvXAm6Yq5mR7zW3G1pmqYlbNW3 aX5vudT/M69cfgo8Npq0cBbfTBa1x3XLxX7IsNvM2vn00qz3HSw7HzB3PtTd+zBbiaU4I9FQ i7moOBEARwQ5Vq0CAAA= Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] COSE requirements from CORE/ACE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 12:23:00 -0000 RGVhciBKb3JnZSwNCg0KVGhhbmtzIGZvciBxdWljayByZXBseS4NCg0KT25lIHF1ZXN0aW9uIHdl IGdvdCBpbiB0aGlzIGNvbnRleHQgd2FzLCBpZiB0aGVyZSBpcyBhICJtYWluIHJlY2lwaWVudCIg YXMNCnlvdSBjYWxsIGl0LCB3aHkgc2hvdWxkIGFueW9uZSBlbHNlIGJlIGFibGUgdG8gcmVhZCBp dD8gRS5nLiBjb25zaWRlciBJQUINCnN0YXRlbWVudCBvbiBjb25maWRlbnRpYWxpdHkuDQoNCkFu ZCBpZiB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgYW4gaW50ZXJtZWRpYXJ5IHRoYXQgc2hvdWxkIGJl IGFibGUgdG8gcmVhZA0KaW4gb3JkZXIgdG8gcGVyZm9ybSBhbiBhY3Rpb24gYmFzZWQgb24gdGhh dCBpbmZvcm1hdGlvbiwgc2hvdWxkIG5vdCB0aGF0DQplbnRpdHkgYWxzbyBiZSBhYmxlIHRvIHZl cmlmeSB0aGUgZGF0YSBiZWZvcmUgcGVyZm9ybWluZyB0aGUgYWN0aW9uPw0KDQpJZiB0aGUgaW50 ZXJtZWRpYXJ5IG5lZWQgdG8gdmVyaWZ5IHRoZSBkYXRhLCB0aGVuIGVpdGhlcg0KDQpBKSBpdCBp cyB0cnVzdGVkIHdpdGggbm90IGFsdGVyaW5nIHRoZSB2YWx1ZSBhbmQgY291bGQgaGF2ZSBhY2Nl c3MgdG8gdGhlDQpzeW1tZXRyaWMga2V5LiBCdXQgdGhlbiB0aGUgZGF0YSBjb3VsZCBqdXN0IGFz IHdlbGwgYWxzbyBoYXZlIGJlZW4NCmVuY3J5cHRlZCwgb3IgDQoNCkIpIGl0IGlzIG5vdCB0cnVz dGVkIHdpdGggYWx0ZXJpbmcgdGhlIHZhbHVlLCBhbmQgdGhlbiB0aGF0IHdvdWxkIHJlcXVpcmUN CmFzeW1tZXRyaWMga2V5cyAoaS5lLiBzaWduYXR1cmUpLCB3aGljaCBpcyBub3QgdGhlIGNhc2Ug d2UgYXJlIGNvbnNpZGVyaW5nDQpoZXJlLg0KDQpDbGVhcmx5IHdlIG5lZWQgdG8gc3VwcG9ydCBz aWduYXR1cmUtb25seSwgYnV0IGRvIHdlIHJlYWxseSBuZWVkIE1BQy1vbmx5Pw0KDQoNClJlZ2Fy ZHMsDQpHw7ZyYW4NCg0KDQpPbiAyMDE1LTA4LTMxIDEzOjA4LCAiQ3VlbGxhciwgSm9yZ2UiIDxq b3JnZS5jdWVsbGFyQHNpZW1lbnMuY29tPiB3cm90ZToNCg0KPkRlYXIgR8O2cmFuIGFuZCBhbGws DQo+DQo+PiAyLiBNQUMtb25seT8NCj4+IERvIHlvdSBrbm93IG9mIGFuIGltcG9ydGFudCBhcHBs aWNhdGlvbiBvciBzZXR0aW5nIHdoaWNoIHJlcXVpcmUNCj4+IHRoYXQgbWVzc2FnZXMgYXJlIG9u bHkgcHJvdGVjdGVkIGJ5IGEgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLi4uDQo+DQo+SW5k ZWVkLCB0aGVyZSBhcmUgc29tZS4gIEZvciBpbnN0YW5jZSwgc29tZSB1c2UgY2FzZXMgaW4gU21h cnQgQ2l0aWVzDQo+KGJ1c2VzIHNjaGVkdWxpbmcvZGVsYXlzIGluZm9ybWF0aW9uLCBzb21lIGFz cGVjdHMgb2YgZW52aXJvbm1lbnRhbA0KPm1vbml0b3JpbmcsIGdhcmJhZ2UgY29sbGVjdGlvbiBt YW5hZ2VtZW50LCBldGMpIGRvIG5vdCByZXF1aXJlDQo+Y29uZmlkZW50aWFsaXR5IGJ1dCBpbnRl Z3JpdHkuICBBcyB0b2RheSBpcyB0aGUgY2FzZSwgdGhlIGdlbmVyYWwgdXNlcg0KPm1heSBiZSB1 bmFibGUgdG8gdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGluZm9ybWF0aW9uLCBidXQgdGhl ICJtYWluDQo+cmVjaXBpZW50IiAoc2F5LCB0aGUgY2l0eSBjb3VuY2lsKSBjYW4gdmVyaWZ5IGl0 Lg0KPg0KPkJlc3QsDQo+Sm9yZ2UNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZy b206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR8O2cmFu IFNlbGFuZGVyDQo+U2VudDogMzEgQXVndXN0IDIwMTUgMTI6NTENCj5UbzogY29yZUBpZXRmLm9y ZzsgYWNlQGlldGYub3JnDQo+Q2M6IGNvc2VAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbQWNlXSBDT1NF IHJlcXVpcmVtZW50cyBmcm9tIENPUkUvQUNFDQo+DQo+DQo+RGVhciBDT1JFIGFuZCBBQ0UgbWVt YmVycywNCj4NCj4NCj5JbiB0aGUgQ09TRSBXRyBtZWV0aW5nIGluIFByYWd1ZSBvbmUgb2YgdGhl IHRvcGljcyB3YXMgcmVxdWlyZW1lbnRzIGZyb20NCj5hIGNvbnN0cmFpbmVkIG5vZGUgbmV0d29y ayBwb2ludCBvZiB2aWV3IG9uIG1lc3NhZ2UgZm9ybWF0LCBjcnlwdG8gc3VpdGVzDQo+ZXRjLiBT b21lIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGluZyBhbmQgc29tZSBpbiBzbWFs bGVyIGdyb3Vwcw0KPmFmdGVyIHRoZSBtZWV0aW5nLiBJdCB3b3VsZCBiZSBnb29kIHRvIGNvbGxl Y3QgdGhlIHZpZXdzIG9mIHdoYXQgcGVvcGxlDQo+dGhpbmsgYXJlIGltcG9ydGFudCByZXF1aXJl bWVudHMgZm9yIENPU0UgdG8gY29uc2lkZXIuIEkgbGlzdCBhIGZldw0KPmlzc3VlcyBoZXJlLCBm ZWVsIGZyZWUgdG8gYWRkIChhbmQgZW51bWVyYXRlKSBvdGhlcnMgaW4gdGhpcyB0aHJlYWQuDQo+ DQo+MS4gTWVzc2FnZSBzaXplLiANCj4NCj5UaGVyZSBpcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIG1h a2luZyB0aGUgbWVzc2FnZSBmb3JtYXQgYXBwbGljYWJsZSB0byBtYW55DQo+c2V0dGluZ3MgYW5k IG9wdGltaXppbmcgaXQgZm9yIGNlcnRhaW4gc2V0dGluZ3MuIERvIHlvdSBrbm93IG9mIGFuDQo+ aW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRpbmcgd2l0aCBzcGVjaWZpYyByZXF1aXJlbWVu dHMgb24gdXBwZXINCj5saW1pdCBvZiBtZXNzYWdlIHNpemU/IE9uZSByZWxldmFudCBwYXJhbWV0 ZXIgaXMgaWYgdGhlIGFwcGxpY2F0aW9uDQo+cmVxdWlyZXMgc2lnbmVkIG1lc3NhZ2VzIChhc3lt bWV0cmljIGtleSkgb3IgaWYgTUFDcyAoc3ltbWV0cmljIGtleSkgaXMNCj5zdWZmaWNpZW50LCBz aW5jZSB0aGUgc2lnbmF0dXJlIGlzIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIE1BQy4NCj4NCj5PbmUg ZmlndXJlIG1lbnRpb25lZCBpbiB0aGUgbWVldGluZyB3YXMgOTAgYnl0ZXMgVURQIHBheWxvYWQg aW4gYSA2dGlzY2gNCj5zZXR0aW5nIHdoaWNoIG1heSBuZWVkIHNpZ25lZCBtZXNzYWdlcy4NCj4N Cj4NCj4yLiBNQUMtb25seT8NCj4NCj5EbyB5b3Uga25vdyBvZiBhbiBpbXBvcnRhbnQgYXBwbGlj YXRpb24gb3Igc2V0dGluZyB3aGljaCByZXF1aXJlIHRoYXQNCj5tZXNzYWdlcyBhcmUgb25seSBw cm90ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUsIGkuZS4gd2hlcmUNCj50 aGUgbWVzc2FnZSBtdXN0IGJlIGluIHBsYWluIHRleHQgYW5kIGludGVncml0eSBwcm90ZWN0ZWQg dXNpbmcgYQ0KPnN5bW1ldHJpYyBrZXkgYWxnb3JpdGhtPw0KPg0KPkNsZWFybHkgdGhlcmUgYXJl IGFwcGxpY2F0aW9ucyB3aGVyZSBlbmNyeXB0aW9uIGFuZCBtZXNzYWdlDQo+YXV0aGVudGljYXRp b24gYmFzZWQgb24gc3ltbWV0cmljIGFsZ29yaXRobXMgKGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlv bikNCj5pcyBuZWVkZWQuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IGlzIGdhaW5lZCBieSBhbGxvd2lu ZyBNQUMtb25seQ0KPmFsZ29yaXRobXMsIHNpbmNlIGluIG9yZGVyIHRvIHZlcmlmeSB0aGUgbWVz c2FnZSB5b3UgYW55d2F5IG5lZWQgdGhlDQo+c3ltbWV0cmljIGtleS4NCj4NCj4NCj4zLiBTeW1t ZXRyaWMgZW5jcnlwdGlvbiArIGRpZ2l0YWwgc2lnbmF0dXJlLg0KPg0KPkZvciBjbG9zZWQgc3Vi c2NyaWJlciBncm91cHMsIHdoZXJlIHRoZSBkYXRhIG11c3QgYmUgZW5jcnlwdGVkIGFuZCB3aGVy ZQ0KPmVhY2ggc3Vic2NyaWJlciBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRoYXQgdGhlIG1lc3Nh Z2Ugb3JpZ2luYXRlcyBmcm9tDQo+dGhlIHB1Ymxpc2hlciwgdGhlcmUgaXMgYSBuZWVkIHRvIGNv bWJpbmUgc3ltbWV0cmljIGVuY3J5cHRpb24gd2l0aA0KPmRpZ2l0YWwgc2lnbmF0dXJlLiAgVGhp cyBjYW4gYmUgZG9uZSBieSBmaXJzdCBzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQNCj50aGVuIGRp Z2l0YWwgc2lnbmF0dXJlLCBvciBmaXJzdCBkaWdpdGFsIHNpZ25hdHVyZSBhbmQgdGhlbiBzeW1t ZXRyaWMNCj5lbmNyeXB0aW9uLiBEbyB5b3Uga25vdyBvZiBhbiBpbXBvcnRhbnQgYXBwbGljYXRp b24gb3Igc2V0dGluZyB0aGF0DQo+cmVxdWlyZSBhIGNlcnRhaW4gb3JkZXIgb2YgdGhlIG9wZXJh dGlvbnM/DQo+DQo+T25lIGV4YW1wbGUgaXMgd2hlcmUgdGhlIHB1Yi1zdWIgYnJva2VyIHNob3Vs ZCBiZSBhYmxlIHRvIHZlcmlmeSB0aGUNCj5zaWduYXR1cmUgb2YgdGhlIG1lc3NhZ2Ugd2l0aG91 dCBkaXNjbG9zaW5nIHRoZSBwbGFpbiB0ZXh0IHB1YmxpY2F0aW9uLg0KPg0KPg0KPlRoYW5rcywN Cj5Hw7ZyYW4NCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPkFjZSBtYWlsaW5nIGxpc3QNCj5BY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= From nobody Mon Aug 31 09:38:57 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07F1B3166 for ; Mon, 31 Aug 2015 09:38:55 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIhl6g1CKT7i for ; Mon, 31 Aug 2015 09:38:54 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE081B3F11 for ; Mon, 31 Aug 2015 09:38:45 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 07D8538F04; Mon, 31 Aug 2015 09:38:44 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E3FE2A.1010807@gmx.net> In-Reply-To: <55E3FE2A.1010807@gmx.net> Date: Mon, 31 Aug 2015 09:36:35 -0700 Message-ID: <05cb01d0e40b$3401c9d0$9c055d70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGSlr840pSkSQo2DpRHB4xtcgniQ56i6FWg Archived-At: Subject: Re: [COSE] Data Types X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 16:38:55 -0000 These are hold overs from when I was planning on making CDDL normative. = Yes I need to do something about this. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Monday, August 31, 2015 12:12 AM > To: cose@ietf.org > Subject: [COSE] Data Types >=20 > Hi Jim, Hi Brian, >=20 > CBOR introduces a couple of data types, such as text string and byte = string. >=20 > COSE-04 uses tstr, bstr, etc. I suspect that they are simply the = short-hand version > of CBOR data types. This could be mentioned in the terminology section = or, > alternatively, you could also use the CBOR defined terms. >=20 > Ciao > Hannes From nobody Mon Aug 31 10:29:17 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89DA1A1B1F for ; Mon, 31 Aug 2015 10:29:15 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to60Q2RTJH7V for ; Mon, 31 Aug 2015 10:29:14 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C351F1B36F7 for ; Mon, 31 Aug 2015 10:28:55 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id AD9BB38F08; Mon, 31 Aug 2015 10:28:54 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E3FE3D.7060400@gmx.net> In-Reply-To: <55E3FE3D.7060400@gmx.net> Date: Mon, 31 Aug 2015 10:26:38 -0700 Message-ID: <05db01d0e412$361c8f50$a255adf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQKyW4dOZ4voGJze5J1/uUOa2Ujuy5xjYAQw Archived-At: Subject: Re: [COSE] alg Header Parameter X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 17:29:16 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Monday, August 31, 2015 12:12 AM > To: cose@ietf.org > Subject: [COSE] alg Header Parameter >=20 > Hi Jim, Hi Brian, >=20 > Is it possible to make the alg parameter optional? >=20 > Reason: When a key id is used then all the necessary information, = including the > algorithm, can be determined from the key id itself. You have a much different view of key ids than what I do. I do not = believe that key ids are unique so I very leery of the idea that = everything necessary can be determined from the key id. Additionally, = while it may be true in your context that algorithm can be determined = from the key id, this is not going to be true in all contexts and = potentially for all key ids. =20 Also, my implementation does not manage the keys and therefore would not = have access to the required information easily. While it make sense to = move keys into recipient structures, adding all of the other information = would be a requirement of the application. =20 >=20 > Table 1 ' Common Header Parameters' defines the alg parameter as = follows: >=20 > = +----------+-------+----------+-----------------+-------------------+ > | name | label | value | value registry | description = | > | | | type | | = | > = +----------+-------+----------+-----------------+-------------------+ > | alg | 1 | int / | COSE Algorithm | Integers are = | > | | | tstr | Registry | taken from table = | > | | | | | --POINT TO = | > | | | | | REGISTRY-- = | >=20 > I would prefer to only have one option to represent the value, namely = as an > integer. >=20 > I also think that you could include a pointer to the appropriate = section. While the > other text in this section points to Section 15.3 I don't believe that = this is actually > correct. No it was wrong - it should have been a pointer to 15.4, my anchor names = were too close together. >=20 > Regarding the fields in the header parameter table I was wondering why = not to > standardize the full list as listed in the table. Currently, a number = of entries are > marked with a "*". These are all items which I personally am not ready to say are going to = make the final cut in the document. Thus item 1 in the Open issues = section below the table. >=20 > Regarding the nonce field do you expect it to also serve as a = container for > sequence numbers or do you plan to add a separate field for it? My initial idea was that it would be able to hold sequence numbers, = however I am no longer sure that I think that is correct. >=20 > What about adding a timestamp field (for an alternative replay = protection > mechanism for those cases where sequences numbers are not = appropriate)? I am very open to defining additional items that are expected to be = commonly used. In terms of timestamps. How do you believe that they should be defined? = As only positive numbers? As strings? Using the Unix time format? Jim >=20 > Ciao > Hannes From nobody Mon Aug 31 11:06:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB21B4462 for ; Mon, 31 Aug 2015 11:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbg9PjXs1HHS for ; Mon, 31 Aug 2015 11:06:33 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70491B4565 for ; Mon, 31 Aug 2015 11:06:32 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 45EF42CA03; Mon, 31 Aug 2015 11:06:32 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , "'Hannes Tschofenig'" References: <55E4030F.5020009@gmx.net> <55E41E38.7030404@tzi.org> In-Reply-To: <55E41E38.7030404@tzi.org> Date: Mon, 31 Aug 2015 11:04:22 -0700 Message-ID: <05f601d0e417$7799e720$66cdb560$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQFgGjGaKkK9vQicv5BBdcdrAPZ/CgJIU8yYnvW3O6A= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] CDDL Grammar Descriptions X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 18:06:35 -0000 If you read the text with the CDDL gone, I don't think that this makes = any sense. There is mention of headers in that case in the resulting = structure or in section 3.0 Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Monday, August 31, 2015 2:28 AM > To: Hannes Tschofenig > Cc: cose@ietf.org > Subject: Re: [COSE] CDDL Grammar Descriptions >=20 > Hannes Tschofenig wrote: > > Header: The header parameter is described in Section 3. >=20 > I would probably write: >=20 > Headers: The common header parameters (protected, unprotected) are > described in Section 3. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Aug 31 11:09:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011B01B4046 for ; Mon, 31 Aug 2015 11:09:15 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2wdX3-VIkeS for ; Mon, 31 Aug 2015 11:09:13 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2111B468B for ; Mon, 31 Aug 2015 11:09:11 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id EF17E38EF6; Mon, 31 Aug 2015 11:09:10 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E40787.6010603@gmx.net> In-Reply-To: <55E40787.6010603@gmx.net> Date: Mon, 31 Aug 2015 11:07:01 -0700 Message-ID: <05f701d0e417$d629d1b0$827d7510$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHM0FC9mPHS0HNNtghxUqMUL7gyaZ4ujmdQ Archived-At: Subject: Re: [COSE] Security Considerations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 18:09:15 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Monday, August 31, 2015 12:52 AM > To: cose@ietf.org > Subject: [COSE] Security Considerations >=20 > Hi Jim, Hi Brian, >=20 > In Section 8 "Signature Algorithms", Section 9 "Message Authentication > (MAC) Algorithms", and Section 10 "Content Encryption Algorithms" > contain algorithm descriptions. Each algorithm description comes with = a security > consideration section. >=20 > Since the COSE specification is just a consumer of already = standardized > cryptographic algorithms I am wondering whether the security = considerations > are needed since their content should already be available with the = documents > that specify the algorithm. Strictly speaking, no it does not need to be there. However, I believe = that it serves a useful purpose as it summarizes some of the security = considerations that need to be taken into account when choosing which = algorithm is going to be used by an application. I think that putting = it into a per algorithm, rather than doing a big summary of some type at = the bottom, makes it clearer which items are applicable to those items. I believe that it should be kept. Jim >=20 > Ciao > Hannes From nobody Mon Aug 31 11:12:51 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA0F1B3A17 for ; Mon, 31 Aug 2015 11:12:50 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqnoyEMMd7Td for ; Mon, 31 Aug 2015 11:12:48 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548451A0366 for ; Mon, 31 Aug 2015 11:12:48 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id BED8838EF6; Mon, 31 Aug 2015 11:12:47 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E4033A.8010409@gmx.net> In-Reply-To: <55E4033A.8010409@gmx.net> Date: Mon, 31 Aug 2015 11:10:34 -0700 Message-ID: <05f801d0e418$5766b040$063410c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIlLOnKlASm1eCzVQiV/rdErWNn95191pZw Archived-At: Subject: Re: [COSE] 'Common Header Parameters' and 'Key Map Labels' X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 18:12:50 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Monday, August 31, 2015 12:33 AM > To: cose@ietf.org > Subject: [COSE] 'Common Header Parameters' and 'Key Map Labels' >=20 > Hi Jim, Hi Brian, >=20 > Table 1 defines 'Common Header Parameters' including kid and alg. = Table > 2 'Key Map Labels' defines further labels, such as kid and alg, but = those appear > to have different semantic. Maybe it is possible to give them = different labels to > reduce confusion. The current naming is based what is present in JOSE. I have no problems = with doing a change of names however. Could you give some suggestions about how you think that might be = re-named? Jim >=20 > Ciao > Hannes >=20 >=20 From nobody Mon Aug 31 11:18:31 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140DC1B3CD3 for ; Mon, 31 Aug 2015 11:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tteom9RN2iyM for ; Mon, 31 Aug 2015 11:18:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DBD1B33D2 for ; Mon, 31 Aug 2015 11:18:26 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 18:18:24 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0243.020; Mon, 31 Aug 2015 18:18:24 +0000 From: Mike Jones To: Jim Schaad , 'Hannes Tschofenig' , "cose@ietf.org" Thread-Topic: [COSE] 'Common Header Parameters' and 'Key Map Labels' Thread-Index: AQHQ479SHVAvQ9H/HUyIA2cAtB/bDp4maSoAgAAB+IA= Date: Mon, 31 Aug 2015 18:18:24 +0000 Message-ID: References: <55E4033A.8010409@gmx.net> <05f801d0e418$5766b040$063410c0$@augustcellars.com> In-Reply-To: <05f801d0e418$5766b040$063410c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:7::69f] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:gVQOE0ajdwfphwmuRL8Ow1FhBgKpiy3HPt+sx1u/4lCnNRf398qyCYk/7MXYcpdCGgBxSBM6E6DnqhXp6llFttWny+OhmhAYv4KflzK3kaocQrvzTYX212zOYBAaGUN8mJ4q2UDlOC6ZU67TYiMbIg==; 24:wsF3/Ei8+6KtVYtqbN8vw/AKZGXzmjcxRj8FpkkXxDupldgXYQ2dOFypCibK3P0n6MX4gCNEI9IW53aE8rlNd2yWB6t1NFmBiNXKSr/0KJE=; 20:svzvUwLnyq8vfHqwsw+WKoq6Mbnd87ZEHlxeT9QyscWJHMp4gsfVvieI5KlXtQyHILKxNBY76sNitlwcuwxn5Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0685122203 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(189002)(8990500004)(5001770100001)(86612001)(5001860100001)(76176999)(106116001)(10090500001)(77096005)(10400500002)(5001830100001)(10290500002)(19580405001)(15975445007)(102836002)(2501003)(189998001)(5003600100002)(2950100001)(2656002)(5005710100001)(19580395003)(33656002)(81156007)(5001960100002)(97736004)(105586002)(86362001)(54356999)(107886002)(87936001)(40100003)(74316001)(92566002)(99286002)(77156002)(46102003)(5007970100001)(106356001)(2900100001)(68736005)(50986999)(76576001)(4001540100001)(62966003)(122556002)(5004730100002)(5002640100001)(64706001)(101416001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 18:18:24.1342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [COSE] 'Common Header Parameters' and 'Key Map Labels' X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 18:18:30 -0000 In earlier comments, I'd suggested renaming "jwk" (JSON Web Key) to "ck" (C= OSE key). The other names seem fine to me. -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, August 31, 2015 11:11 AM To: 'Hannes Tschofenig'; cose@ietf.org Subject: Re: [COSE] 'Common Header Parameters' and 'Key Map Labels' > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes=20 > Tschofenig > Sent: Monday, August 31, 2015 12:33 AM > To: cose@ietf.org > Subject: [COSE] 'Common Header Parameters' and 'Key Map Labels' >=20 > Hi Jim, Hi Brian, >=20 > Table 1 defines 'Common Header Parameters' including kid and alg.=20 > Table > 2 'Key Map Labels' defines further labels, such as kid and alg, but=20 > those appear to have different semantic. Maybe it is possible to give=20 > them different labels to reduce confusion. The current naming is based what is present in JOSE. I have no problems wi= th doing a change of names however. Could you give some suggestions about how you think that might be re-named? Jim >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c3e360bc89b2f4fc73a8808d2b22fc956%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3D%2fV%2fzTJtKQPwHgO2QYRIboyV%2bwd4vEBrf8rp%2f9apXgRs%3d From nobody Mon Aug 31 12:47:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF7C1B5B20 for ; Mon, 31 Aug 2015 12:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYK5kEVIj6O6 for ; Mon, 31 Aug 2015 12:47:02 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC6A1B5B1E for ; Mon, 31 Aug 2015 12:47:02 -0700 (PDT) Received: by iod35 with SMTP id 35so40824678iod.3 for ; Mon, 31 Aug 2015 12:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=28Sq9wdIJWhT3Sx5o1q5YXIfo42FRoOOKmil+sjdzwU=; b=egitPtfzM4/756FIPq7IxEWkI9y04k12X6iBpSDYWCU0peztp0i7h0SOYlZycP6QCR nnukNoDk9BYUho9yIKjU8tDilZCxbz75HpVuQaFsIzLGUn9eSk3x++C+w2ssUTYvQ6Ns mmTa6gLBUsSST6llWe2SkGaiE9i2sEUL+6V+w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=28Sq9wdIJWhT3Sx5o1q5YXIfo42FRoOOKmil+sjdzwU=; b=FaNS31jDwAcvmsZFZiB43otcl0zfHNOK0AVpyRiLS9p0sK/yggBWb8Yww3Z7OgwlxB Bnv6bU8n5XI7wNNa2UzWFloqjCGopYkB47Sw9wwsKeFhZYfRmX3KcHdd4r65mW5GnwZ9 bA7OgRxFUGp7VSHYJPUH+F4aP8kdqCqrM/RVMHI/OSN2cCXLLa/rFtYWJDw4EOfWs/3X X6mXozQTgOXCDMxd+1hmJJ2dARmb0j+dWML4c3WfxXTKE9kZbLtvuLJsPWViYCGjKmg1 H1vcJtUat9uYwTIBDJaXerEo7hWbaFZeHb1kNUbY1EkB56ARU/qzsnKKElMtkHl5DAdz 5CyQ== X-Gm-Message-State: ALoCoQk9hgt7lta7D2xndMr6hOzWQYtOcFvd+wNPWsm7TuWwWsN9S9GJZdg6fxHWVESgnU9bwpj6 X-Received: by 10.107.151.19 with SMTP id z19mr9123245iod.95.1441050421398; Mon, 31 Aug 2015 12:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Mon, 31 Aug 2015 12:46:32 -0700 (PDT) From: Brian Campbell Date: Mon, 31 Aug 2015 13:46:32 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1140b0ec78afa2051ea0b2a5 Archived-At: Cc: Ilari Liusvaara , cose@ietf.org Subject: [COSE] questionable header parameters (was Re: draft -04 published) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:47:04 -0000 --001a1140b0ec78afa2051ea0b2a5 Content-Type: text/plain; charset=UTF-8 Hi Ilari, I'm working to get to some consensus on some of these headers. There's a short thread on it: http://www.ietf.org/mail-archive/web/cose/current/msg00459.html - I'll take your comments here into account but feel free to jump in on that thread as well. I expect the URL-type things like jku (or cku) and x5u to go away in future drafts. Some desire for X509 support in headers has been expressed. The jury is still out on these, I think. I don't believe the jwk header is being used much, if at all, in JOSE. Jim has expressed "an, admittedly small, degree of sympathy for allowing the key to be carried in the message." I do have some sympathy for that sympathy but would personally prefer to get rid of a jwk equivalent header for COSE. I do need to bring up zip for discussion. But agree with your assessment. On Sat, Aug 29, 2015 at 12:22 PM, Jim Schaad wrote: > > > > -----Original Message----- > > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > > Sent: Saturday, August 29, 2015 12:17 AM > > Subject: Re: [COSE] draft -04 published > > > 3) Regarding questionable header parameters: > > - URL-type things: jku and x5u... URL retretival has nontrivial > > security concerns. > > - X509-type things: x5c, x5t, x5t#SHA256, x5u: These assume X.509, > > which is complicated to the point that even full-powered systems > > have problems implementing it. > > - jwk: Apparently this header is used with JOSE, so I would imagine > > equivalent usecases do apply here too. > > - zip: Constrained systems probably don't appreciate compression, > > but it could be nice in full-powered systems. > > Brian is currently working on these issues and should respond. > --001a1140b0ec78afa2051ea0b2a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ilari,

I'm working to get to some consensus on some of these header= s. There's a short thread on it: http://www.ietf.org/mail-archi= ve/web/cose/current/msg00459.html - I'll take your comments here in= to account but feel free to jump in on that thread as well.

I expect the URL-type things like jku (or c= ku) and x5u to go away in future drafts.

Some desire for = X509 support in headers has been expressed. The jury is still out on these,= I think.

I don't believe the jwk header is being use= d much, if at all, in JOSE. Jim has expressed "an, admittedly small, d= egree of sympathy for allowing the key to be carried in the message." = I do have some sympathy for that sympathy but would personally prefer to ge= t rid of a jwk equivalent header for COSE.

I do need to = bring up zip for discussion. But agree with your assessment.








=
On Sat, Aug 29, 2015 at 12:22 PM, Jim Schaad <ietf@augustcellars.com> wrote:


> -----Original Message-----
> From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi]
> Sent: Saturday, August 29, 2015 12:17 AM
> Subject: Re: [COSE] draft -04 published

> 3) Regarding questionable header parameters:
>=C2=A0 =C2=A0 - URL-type things: jku and x5u... URL retretival has nont= rivial
>=C2=A0 =C2=A0 =C2=A0 security concerns.
>=C2=A0 =C2=A0 - X509-type things: x5c, x5t, x5t#SHA256, x5u: These assu= me X.509,
>=C2=A0 =C2=A0 =C2=A0 which is complicated to the point that even full-p= owered systems
>=C2=A0 =C2=A0 =C2=A0 have problems implementing it.
>=C2=A0 =C2=A0 - jwk: Apparently this header is used with JOSE, so I wou= ld imagine
>=C2=A0 =C2=A0 =C2=A0 equivalent usecases do apply here too.
>=C2=A0 =C2=A0 - zip: Constrained systems probably don't appreciate = compression,
>=C2=A0 =C2=A0 =C2=A0 but it could be nice in full-powered systems.

Brian is currently working on these issues and should respond.

=C2=A0
--001a1140b0ec78afa2051ea0b2a5-- From nobody Mon Aug 31 13:05:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232F71B5D8E for ; Mon, 31 Aug 2015 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5X3i60AwtQJ for ; Mon, 31 Aug 2015 13:05:02 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070CB1B5D8F for ; Mon, 31 Aug 2015 13:05:01 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 95E012CA22; Mon, 31 Aug 2015 13:05:00 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E400AC.7090507@gmx.net> In-Reply-To: <55E400AC.7090507@gmx.net> Date: Mon, 31 Aug 2015 13:02:50 -0700 Message-ID: <064c01d0e428$047d2700$0d777500$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQFOSJy01QpTkZygPNqMOVMY93IQJJ8rpxFg Archived-At: Subject: Re: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:05:05 -0000 Hannes, I think that characterizing draft-kumar-dice-multicast-security as some = type of DTLS may be a huge misnomer. On first read it is not matching a = great deal of what I think of as being TLS/DTLS. For example, all of = the record layering that is present in DTLS does not appear to be here, = and I would assume that none of the starting handshaking is going to be = present here. Looking at the figure 2 in that document appears to have an overhead of = 13 bytes, but I am not seeing the sender ID that you are talking about = so I am unsure that your analysis of the sizes is going to be correct = for this. It is definitely not true if the multiple layering of TLS is = going to be used. I am having a hard time with the example you gave, I put it into cbor.me = (after removing comments) and it generated a syntax error. After = generating it on my own, I came up with: [ 2, // encrypted message h'a2010a0547089f52fa000000', // Protected headers // {1: 10, - algorithm AES-CCM-16-64-128 // 5: h'089f52fa000000' - nonce of 7 bytes} { }, // Unprotected headers (none) h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', // = encrypted message + authentication tag [ [ h'', // Protected header - none { // Unprotected headers 1: -6, // Algorithm direct 4: h'01' // sender ID }, h'' // No cipher text ] ] ] Which maps to 56 bytes with a 28 byte message, using my best guess from = what you are saying you get a 42 byte message with you "DTLS" message. = The current difference in overhead thus being 14 bytes rather than the = 19 bytes you have below. I expect that this difference will decrease = as time goes by. We have a proposals on the table which would reduce = the size of the COSE message for handling of single recipient messages, = but it is not clear which, if any, are going to be incorporated into the = document. Part of this is a question of what the implementation sizes = are going to be. =20 Although the kumar document says that there should be significant code = reuse between it and DTLS, I am not sure that I would agree with this. = It seems to be that it is just reusing small portions but it would be a = significant re-write and would need to have a corresponding complete = security review. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Monday, August 31, 2015 12:22 AM > To: cose@ietf.org > Subject: [COSE] Multicast Use Case >=20 > Hi Jim, Brian, all, >=20 > I am trying to compare the work on multicast security done by Sandeed = & co > against an application layer solution using CBOR/COSE. >=20 > The DTLS multicast includes the following relevant components: > - Epoch: 2 Byte > - Sender ID: 1 Byte > - Sequence Number: 5 Byte >=20 > The combination of epoch, sender id and sequence number are used as a = nonce > for the cipher and the use of the sender id ensures that no member of = the group > accidentally selects values that will cause re-use. >=20 > The 1 byte sender id is chosen small to reflect the expected size of a = group in the > professional lighting environment, as explained in the DTLS multicast = document. >=20 > Ciphersuite related information includes: > - Encrypted Content (variable length) > - MAC (variable length) >=20 > Content Type, Version and Length are DTLS-specific aspects that cannot = be > removed without re-design of the record layer. >=20 > Data based on Figure 4 of > http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08.txt. >=20 > Since there is no sequence number defined in COSE I put the epoch and = the > sequence number together into the nonce field. >=20 > Here is the commented version of the COSE message I came up with: >=20 > [ > 2, // Encrypted COSE message > { > 1: 10, // Algorithm - AES-CCM-16-64-128 > 5: h'89f52fa' // 7-byte nonce > }, > h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', > // encrypted payload. > [ > [ > h'', > { > 1: -6, // Direct use of CEK > 4: h'01' // Key ID - 0x01 > }, > h'' > ] > ] > ] >=20 > According to cbor.me the resulting COSE encoding has 59 bytes whereby = 28 > bytes are purely used for message encryption. This means that there = is > 31 bytes overhead with COSE compared to 12 bytes [=3D 8 for Epoch + = Sequence > Number + Sender ID, 3 bytes for Content Type and Version fields]. >=20 > Ciao > Hannes From nobody Mon Aug 31 13:12:48 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D29F1A6FFD for ; Mon, 31 Aug 2015 13:12:46 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeFLVUKCF5he for ; Mon, 31 Aug 2015 13:12:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003CB1B4976 for ; Mon, 31 Aug 2015 13:12:40 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.243.23; Mon, 31 Aug 2015 20:12:36 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0243.020; Mon, 31 Aug 2015 20:12:36 +0000 From: Mike Jones To: Jim Schaad , 'Hannes Tschofenig' , "cose@ietf.org" Thread-Topic: [COSE] alg Header Parameter Thread-Index: AQHQ47xaakbWCOgWL0i5P9hPEHkuTJ4mXOkAgAArA1A= Date: Mon, 31 Aug 2015 20:12:36 +0000 Message-ID: References: <55E3FE3D.7060400@gmx.net> <05db01d0e412$361c8f50$a255adf0$@augustcellars.com> In-Reply-To: <05db01d0e412$361c8f50$a255adf0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:5::521] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:4aYqJGZWbMgS5MMzwOKEDRoioqCyRGLQxYmzxtzbKTjAVVfCIvPCRpu8atc7KSw9Xv2DXJ1OzHGAbtiACW5oBAqL6GZFCkJw3sVt0vgqx3WccF9Y0SEN9l6PqcJ+fua4wUcUxhCCLjWLaxEJkZsI0Q==; 24:1dmQZfTWaf7Gn7iMPU/69BiERMxa9ZzrkScB/odPEMu5bZv8ZTNbpw+ODZc/I1w/D+4+CKR46tchzzQpqOTrlx10gdSgMAN7esFsMmKSHRc=; 20:R9RsiC3e3Sr30VFi3ekx+sl27BFjmdD14swWTTnu6EDOZXCMQ6c2u4s9amSNg5phxHiTNuFrO6yWPKJuasBM4Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(8121501046)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0685122203 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(13464003)(199003)(51444003)(377454003)(107886002)(5001960100002)(122556002)(2900100001)(561944003)(2950100001)(2501003)(99286002)(50986999)(5001770100001)(33656002)(16236675004)(5007970100001)(62966003)(19625215002)(81156007)(4001540100001)(77156002)(5001860100001)(189998001)(74316001)(92566002)(19300405004)(5001830100001)(77096005)(68736005)(86362001)(19580395003)(106356001)(46102003)(10090500001)(101416001)(102836002)(5004730100002)(76576001)(8990500004)(54356999)(87936001)(2656002)(5003600100002)(19580405001)(76176999)(5005710100001)(97736004)(64706001)(40100003)(10400500002)(19617315012)(5002640100001)(15975445007)(106116001)(10290500002)(86612001)(105586002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F7E466CEFBF73810DD1FF56B0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 20:12:36.7514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [COSE] alg Header Parameter X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:12:46 -0000 --_000_BY2PR03MB442F7E466CEFBF73810DD1FF56B0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline below prefixed by Mike> ... -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, August 31, 2015 10:27 AM To: 'Hannes Tschofenig'; cose@ietf.org Subject: Re: [COSE] alg Header Parameter > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > Sent: Monday, August 31, 2015 12:12 AM > To: cose@ietf.org > Subject: [COSE] alg Header Parameter > > Hi Jim, Hi Brian, > > Is it possible to make the alg parameter optional? > > Reason: When a key id is used then all the necessary information, > including the algorithm, can be determined from the key id itself. You have a much different view of key ids than what I do. I do not believe= that key ids are unique so I very leery of the idea that everything necess= ary can be determined from the key id. Additionally, while it may be true = in your context that algorithm can be determined from the key id, this is n= ot going to be true in all contexts and potentially for all key ids. Also, my implementation does not manage the keys and therefore would not ha= ve access to the required information easily. While it make sense to move = keys into recipient structures, adding all of the other information would b= e a requirement of the application. Mike> I am also strongly against making "alg" optional, as Key IDs need not= be unique. Declaring the algorithm and restricting the recipient to using= only that algorithm is key to some of the security guarantees provided by = COSE. > > Table 1 ' Common Header Parameters' defines the alg parameter as follows: > > +----------+-------+----------+-----------------+-------------------+ > | name | label | value | value registry | description | > | | | type | | | > +----------+-------+----------+-----------------+-------------------+ > | alg | 1 | int / | COSE Algorithm | Integers are | > | | | tstr | Registry | taken from table | > | | | | | --POINT TO | > | | | | | REGISTRY-- | > > I would prefer to only have one option to represent the value, namely > as an integer. Mike> Custom algorithms are likely to be best represented as strings, at le= ast during early deployment. Once they're in widespread use, integers can = be assigned via the registry. > I also think that you could include a pointer to the appropriate > section. While the other text in this section points to Section 15.3 I > don't believe that this is actually correct. No it was wrong - it should have been a pointer to 15.4, my anchor names we= re too close together. > > Regarding the fields in the header parameter table I was wondering why > not to standardize the full list as listed in the table. Currently, a > number of entries are marked with a "*". These are all items which I personally am not ready to say are going to mak= e the final cut in the document. Thus item 1 in the Open issues section b= elow the table. > > Regarding the nonce field do you expect it to also serve as a > container for sequence numbers or do you plan to add a separate field for= it? My initial idea was that it would be able to hold sequence numbers, however= I am no longer sure that I think that is correct. > > What about adding a timestamp field (for an alternative replay > protection mechanism for those cases where sequences numbers are not appr= opriate)? I am very open to defining additional items that are expected to be commonl= y used. In terms of timestamps. How do you believe that they should be defined? A= s only positive numbers? As strings? Using the Unix time format? Mike> The timestamp is typically included in the message payload - not as a= header parameter. For instance, while JWT [RFC 7519] defines the "jti" (J= WT ID) claim in http://tools.ietf.org/html/rfc7519#section-4.1.7, this is a= n optional part of the payload - not part of the header. The header parame= ters should normally be just about declaring the cryptographic operations p= erformed on the payload and not used as a general-purpose bag of additional= application data, which this timestamp proposal feels like. The fact that there's not any one clear choice for the representation of th= e timestamp provides a strong hint that this is the province of the applica= tion - not the crypto library. Jim > > Ciao > Hannes _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c04359d5c50104e8bf5c408d2b229b3cd%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3Dry%2fmKA939D2PsC8xJBTRb%2fRMvkWmELwU07VCoBbHGb8%3d --_000_BY2PR03MB442F7E466CEFBF73810DD1FF56B0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Replies inline belo= w prefixed by Mike> …

 

-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 10:27 AM
To: 'Hannes Tschofenig'; cose@ietf.org
Subject: Re: [COSE] alg Header Parameter

 

 

 

> -----Original Message-----

> From: COSE [mailto:cose-= bounces@ietf.org] On Behalf Of Hannes

> Tschofenig

> Sent: Monday, August 31, 2015 12:12 AM<= /o:p>

> To: cose@ietf.org

> Subject: [COSE] alg Header Parameter

>

> Hi Jim, Hi Brian,

>

> Is it possible to make the alg parameter opt= ional?

>

> Reason: When a key id is used then all the n= ecessary information,

> including the algorithm, can be determined f= rom the key id itself.

 

You have a much different view of key ids than wh= at I do.  I do not believe that key ids are unique so I very leery of = the idea that everything necessary can be determined from the key id. = Additionally, while it may be true in your context that algorithm can be determined from the key id, this is not goin= g to be true in all contexts and potentially for all key ids. 

 

Also, my implementation does not manage the keys = and therefore would not have access to the required information easily.&nbs= p; While it make sense to move keys into recipient structures, adding all o= f the other information would be a requirement of the application. 

 

Mike> I am also = strongly against making “alg” optional, as Key IDs need not be = unique.  Declaring the algorithm and restricting the recipient to usin= g only that algorithm is key to some of the security guarantees provided by COSE.

 

>

> Table 1 ' Common Header Parameters' defines = the alg parameter as follows:

>

>    +----------+------= -+----------+-----------------+-------------------+

>    | name   &n= bsp; | label | value    | value registry  | description=        |

>    |    &= nbsp;     |       | type&= nbsp;    |        &n= bsp;        |    &nb= sp;            =   |

>    +----------+------= -+----------+-----------------+-------------------+

>    | alg   &nb= sp;  | 1     | int /    | COSE Algo= rithm  | Integers are      |

>    |    &= nbsp;     |       | tstr&= nbsp;    | Registry       = ; | taken from table  |

>    |    &= nbsp;     |       | =          |    &= nbsp;            | -= -POINT TO        |

>    |    &= nbsp;     |       | =          |    &= nbsp;            | R= EGISTRY--        |

>

> I would prefer to only have one option to re= present the value, namely

> as an integer.

 

Mike> Custom alg= orithms are likely to be best represented as strings, at least during early= deployment.  Once they’re in widespread use, integers can be as= signed via the registry.

 

> I also think that you could include a pointe= r to the appropriate

> section. While the other text in this sectio= n points to Section 15.3 I

> don't believe that this is actually correct.=

No it was wrong - it should have been a pointer t= o 15.4, my anchor names were too close together.

 

>

> Regarding the fields in the header parameter= table I was wondering why

> not to standardize the full list as listed i= n the table. Currently, a

> number of entries are marked with a "*&= quot;.

 

These are all items which I personally am not rea= dy to say are going to make the final cut in the document.   Thus= item 1 in the Open issues section below the table.

 

>

> Regarding the nonce field do you expect it t= o also serve as a

> container for sequence numbers or do you pla= n to add a separate field for it?

 

My initial idea was that it would be able to hold= sequence numbers, however I am no longer sure that I think that is correct= .

 

>

> What about adding a timestamp field (for an = alternative replay

> protection mechanism for those cases where s= equences numbers are not appropriate)?

 

I am very open to defining additional items that = are expected to be commonly used.

 

In terms of timestamps.  How do you believe = that they should be defined?  As only positive numbers? As strings? Us= ing the Unix time format?

 

Mike> The timest= amp is typically included in the message payload – not as a header pa= rameter.  For instance, while JWT [RFC 7519] defines the "jti&quo= t; (JWT ID) claim in http://tools.i= etf.org/html/rfc7519#section-4.1.7, this is an optional part of the pay= load – not part of the header.  The header parameters should nor= mally be just about declaring the cryptographic operations performed on the payload and not used as a general-purpose bag = of additional application data, which this timestamp proposal feels like.

 

The fact that there= ’s not any one clear choice for the representation of the timestamp p= rovides a strong hint that this is the province of the application – = not the crypto library.

 

Jim

 

>

> Ciao

> Hannes

 

 

_______________________________________________

COSE mailing list

COSE@ietf.org

https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%= 2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.= Jones%40microsoft.com%7c04359d5c50104e8bf5c408d2b229b3cd%7c72f988bf86f141af= 91ab2d7cd011db47%7c1&sdata=3Dry%2fmKA939D2PsC8xJBTRb%2fRMvkWmELwU07VCoB= bHGb8%3d

--_000_BY2PR03MB442F7E466CEFBF73810DD1FF56B0BY2PR03MB442namprd_-- From nobody Mon Aug 31 13:49:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696E61B5C2C for ; Mon, 31 Aug 2015 13:49:39 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kh2I5sfZBoV for ; Mon, 31 Aug 2015 13:49:37 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6911B60CE for ; Mon, 31 Aug 2015 13:49:37 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 27F2538F10; Mon, 31 Aug 2015 13:49:37 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <55E326E6.4050107@gmx.net> <040301d0e366$1bdb9890$5392c9b0$@augustcellars.com> <55E3DACA.5000102@gmx.net> In-Reply-To: <55E3DACA.5000102@gmx.net> Date: Mon, 31 Aug 2015 13:47:27 -0700 Message-ID: <065e01d0e42e$3fd88f50$bf89adf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJSIQ7w+k/qCYw/XYnDXOZG5TthswJbKRyiAhHlGpCdALCEMA== Archived-At: Subject: Re: [COSE] cddl X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:49:39 -0000 In my boredom yesterday working at the winery, I kind of obsessed on = this issue. (Not having anything else to think about for some reason.) I have seen a lot of incorrect examples in documents as well. In fact I = probably have seen more incorrect examples than I have cases where = formal language and natural language conflicted. All too often I have = seen informational examples basically become normative language. = Taking your argument to its logical (but extreme) conclusion: We should = eliminate examples from the documents so that incorrect examples do not = mislead people. This is obviously not going to happen. > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Sunday, August 30, 2015 9:41 PM > To: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] cddl >=20 > Hi Jim, >=20 > thanks for your response. >=20 > It is interesting to see how different people are in terms of writing = documents. >=20 > I personally liked the JOSE documents quite a bit -- they are easy to = read and to > understand. They got away without CDDL. >=20 > You asked about the examples. I have just tried to work on the = multicast use > case and found none of the examples applicable. >=20 > It would be interesting to know what IoT use cases you had in mind = when you > added the examples. I don't know that I had any IoT cases specifically in mind when I did = the examples. Many of them either came from or were influenced by the = examples that were donefor JOSE. Jim >=20 > Ciao > Hannes >=20 > On 08/30/2015 10:54 PM, Jim Schaad wrote: > > > > > >> -----Original Message----- From: COSE = [mailto:cose-bounces@ietf.org] > >> On Behalf Of Hannes Tschofenig Sent: > >> Sunday, August 30, 2015 8:53 AM To: cose@ietf.org Subject: [COSE] > >> cddl > >> > >> Dear WG draft authors, Hi all, > >> > >> I have two comments regarding the use of CDDL in the COSE draft. > >> > >> 1) I don't believe it helps anyone to use a (formal) data = definition > >> language. Natural text is sufficient. The COSE specification is > >> hopefully not so complex in the end that such a data definition > >> language is needed. In general, I believe this typically just = creates > >> a misalignment between what is described in the text and what is > >> contained in the formal description. There are many examples where > >> the two descriptions disagree. > >> > >> I don't think it will help a human to understand the specification > >> better (instead focus on better examples) and it will not help to > >> automatically create code (which has often been mentioned as a > >> benefit with other formal languages). > > > > I totally disagree. I think that there are huge advantages to using > > formal languages. And while automatic code creation is a benefit, = it > > is hardly the only one. I find such structures easier to read than > > natural code for many things. When there is formal language in a > > specification, that is generally where I start with understanding = the > > major parts of the document, and use the natural language for finer > > points. It is much easier to locate and skip a formal language > > section than to look through several hundred lines of text to find = the > > one that you need. It was just pointed out to me that I had missed > > some text in the document that is only required because CDDL is not > > normative and thus it needs to be duplicated. > > > > If I could make CDDL normative, then I would start ripping out = natural > > language descriptions are being duplicated by the formal language. > > Where ever possible I would have only one description and it would = be > > the formal language. Having natural language do the same thing = except > > for clarifications is what I would object to. > > > > I have never liked the idea of document by examples. It can be both > > very limiting - I do something that is legal but not in the = examples. > > You do not process it because it is not in the examples. Examples > > should be illustrative not where the specification is understood. > > > > That being said. What examples do you think need to be added to the > > document to improve it. > > > > Jim > > > >> > >> 2) Please explain what the status of CDDL in the IETF is. The COSE > >> spec references it normatively but the specification is an = individual > >> submission. > >> > >> My preferences is to remove the reference to CDDL and remove the = CDDL > >> related content from the draft making the spec shorter and easier = to > >> read. I hope others agree with me. > >> > >> Ciao Hannes > >> > > > > From nobody Mon Aug 31 14:28:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742F1B63CC for ; Mon, 31 Aug 2015 14:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiuzSrzp6a4m for ; Mon, 31 Aug 2015 14:28:16 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 1A1411B63C7 for ; Mon, 31 Aug 2015 14:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1441056492; l=13658; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=/VzHsgLFLWKsRtDRtMmf0AQYVShsrRvIkHf8Zl9ebbQ=; b=wB4Qo6Xpv8EPCZhRE9VzUU17YCVGo1ygHmVkhMDaDHkDbJUtkDem2e1s3LmCv8DG9T5 WvQYscRpmxgw7tNd5c2M1rzRpd6ifdvBLklmXFzDW6UjoU3EMz6LdVSsKj+lUYk63oQDC 1vNGue3BJrZ4ErgMoyot8npoOnj5WCTAJ4U= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQRFYQZmyOG X-RZG-CLASS-ID: mo00 Received: from mail-qk0-f169.google.com ([209.85.220.169]) by smtp.strato.de (RZmta 37.11 AUTH) with ESMTPSA id 60166br7VLSARSD (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified) for ; Mon, 31 Aug 2015 23:28:10 +0200 (CEST) Received: by qkdv1 with SMTP id v1so18387975qkd.0 for ; Mon, 31 Aug 2015 14:28:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.221.137 with SMTP id g131mr24467092ywe.84.1441056490050; Mon, 31 Aug 2015 14:28:10 -0700 (PDT) Received: by 10.37.110.84 with HTTP; Mon, 31 Aug 2015 14:28:10 -0700 (PDT) In-Reply-To: <064c01d0e428$047d2700$0d777500$@augustcellars.com> References: <55E400AC.7090507@gmx.net> <064c01d0e428$047d2700$0d777500$@augustcellars.com> Date: Mon, 31 Aug 2015 23:28:10 +0200 Message-ID: From: Sandeep Kumar To: Jim Schaad Content-Type: multipart/alternative; boundary=94eb2c06e9e430df41051ea21cb9 Archived-At: Cc: Hannes Tschofenig , cose WG Subject: Re: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 21:28:19 -0000 --94eb2c06e9e430df41051ea21cb9 Content-Type: text/plain; charset=UTF-8 Hi Jim You seem to be referring to an alternative version of the draft than Hannes used. The draft Hannes used draft-keoh-dice-multicast-security-08 uses SenderID to separate the nonce, while draft-kumar-dice-multicast-security derives new keys per sender (based on a single key and SenderID). the change was due to a difference is preference in my co-author but should not change the overhead. Finally I disagree on your assessment on code reuse, it had been implemented with minimal changes needed to an existing IoT DTLS library. regards Sandeep On Mon, Aug 31, 2015 at 10:02 PM, Jim Schaad wrote: > Hannes, > > I think that characterizing draft-kumar-dice-multicast-security as some > type of DTLS may be a huge misnomer. On first read it is not matching a > great deal of what I think of as being TLS/DTLS. For example, all of the > record layering that is present in DTLS does not appear to be here, and I > would assume that none of the starting handshaking is going to be present > here. > > Looking at the figure 2 in that document appears to have an overhead of 13 > bytes, but I am not seeing the sender ID that you are talking about so I am > unsure that your analysis of the sizes is going to be correct for this. It > is definitely not true if the multiple layering of TLS is going to be used. > > I am having a hard time with the example you gave, I put it into cbor.me > (after removing comments) and it generated a syntax error. After > generating it on my own, I came up with: > > [ > 2, // encrypted message > h'a2010a0547089f52fa000000', // Protected headers > // {1: 10, - algorithm AES-CCM-16-64-128 > // 5: h'089f52fa000000' - nonce of 7 bytes} > { }, // Unprotected headers (none) > h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', // > encrypted message + authentication tag > [ > [ > h'', // Protected header - none > { // Unprotected headers > 1: -6, // Algorithm direct > 4: h'01' // sender ID > }, > h'' // No cipher text > ] > ] > ] > > Which maps to 56 bytes with a 28 byte message, using my best guess from > what you are saying you get a 42 byte message with you "DTLS" message. The > current difference in overhead thus being 14 bytes rather than the 19 bytes > you have below. I expect that this difference will decrease as time goes > by. We have a proposals on the table which would reduce the size of the > COSE message for handling of single recipient messages, but it is not clear > which, if any, are going to be incorporated into the document. Part of > this is a question of what the implementation sizes are going to be. > > Although the kumar document says that there should be significant code > reuse between it and DTLS, I am not sure that I would agree with this. It > seems to be that it is just reusing small portions but it would be a > significant re-write and would need to have a corresponding complete > security review. > > Jim > > > > > -----Original Message----- > > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Hannes Tschofenig > > Sent: Monday, August 31, 2015 12:22 AM > > To: cose@ietf.org > > Subject: [COSE] Multicast Use Case > > > > Hi Jim, Brian, all, > > > > I am trying to compare the work on multicast security done by Sandeed & > co > > against an application layer solution using CBOR/COSE. > > > > The DTLS multicast includes the following relevant components: > > - Epoch: 2 Byte > > - Sender ID: 1 Byte > > - Sequence Number: 5 Byte > > > > The combination of epoch, sender id and sequence number are used as a > nonce > > for the cipher and the use of the sender id ensures that no member of > the group > > accidentally selects values that will cause re-use. > > > > The 1 byte sender id is chosen small to reflect the expected size of a > group in the > > professional lighting environment, as explained in the DTLS multicast > document. > > > > Ciphersuite related information includes: > > - Encrypted Content (variable length) > > - MAC (variable length) > > > > Content Type, Version and Length are DTLS-specific aspects that cannot be > > removed without re-design of the record layer. > > > > Data based on Figure 4 of > > http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08.txt. > > > > Since there is no sequence number defined in COSE I put the epoch and the > > sequence number together into the nonce field. > > > > Here is the commented version of the COSE message I came up with: > > > > [ > > 2, // Encrypted COSE message > > { > > 1: 10, // Algorithm - AES-CCM-16-64-128 > > 5: h'89f52fa' // 7-byte nonce > > }, > > h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', > > // encrypted payload. > > [ > > [ > > h'', > > { > > 1: -6, // Direct use of CEK > > 4: h'01' // Key ID - 0x01 > > }, > > h'' > > ] > > ] > > ] > > > > According to cbor.me the resulting COSE encoding has 59 bytes whereby 28 > > bytes are purely used for message encryption. This means that there is > > 31 bytes overhead with COSE compared to 12 bytes [= 8 for Epoch + > Sequence > > Number + Sender ID, 3 bytes for Content Type and Version fields]. > > > > Ciao > > Hannes > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --94eb2c06e9e430df41051ea21cb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim

You seem to be ref= erring to an alternative version of the draft than Hannes used. The draft H= annes used draft-keoh-dice-multicast-security-08 uses SenderID to separate = the nonce, while draft-kumar-dice-multicast-security derives new keys per s= ender (based on a single key and SenderID). the change was due to a differe= nce is preference in my co-author but should not change the overhead.
Finally I disagree on your assessment on code reuse, it had been im= plemented with minimal changes needed to an existing IoT DTLS library.
<= br>
regards
Sandeep

<= div class=3D"gmail_quote">On Mon, Aug 31, 2015 at 10:02 PM, Jim Schaad <ietf@augustcellars.com> wrote:
Hannes,

I think that characterizing draft-kumar-dice-multicast-security as some typ= e of DTLS may be a huge misnomer.=C2=A0 On first read it is not matching a = great deal of what I think of as being TLS/DTLS.=C2=A0 =C2=A0For example, a= ll of the record layering that is present in DTLS does not appear to be her= e, and I would assume that none of the starting handshaking is going to be = present here.

Looking at the figure 2 in that document appears to have an overhead of 13 = bytes, but I am not seeing the sender ID that you are talking about so I am= unsure that your analysis of the sizes is going to be correct for this.=C2= =A0 It is definitely not true if the multiple layering of TLS is going to b= e used.

I am having a hard time with the example you gave, I put it into cbor.me (after re= moving comments) and it generated a syntax error.=C2=A0 After generating it= on my own, I came up with:

[
=C2=A0 =C2=A0 =C2=A02,=C2=A0 // encrypted message
=C2=A0 =C2=A0 =C2=A0h'a2010a0547089f52fa000000', //=C2=A0 Protected= headers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 //=C2=A0 {1: 10, - algorithm AES-CCM-16-64-128<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//=C2=A0 =C2=A05: h&= #39;089f52fa000000' - nonce of 7 bytes}
=C2=A0 =C2=A0 =C2=A0{=C2=A0 =C2=A0 =C2=A0},=C2=A0 // Unprotected headers (n= one)
=C2=A0 =C2=A0 =C2=A0h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156= ea6e6e0', // encrypted message + authentication tag
=C2=A0 =C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h'',=C2=A0 // Protected header - = none
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ //=C2=A0 Unprotected headers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01: -6,=C2=A0 // Algorithm direct =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04: h'01' // sender ID
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h'' // No cipher text
=C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0]

Which maps to 56 bytes with a 28 byte message, using my best guess from wha= t you are saying you get a 42 byte message with you "DTLS" messag= e.=C2=A0 The current difference in overhead thus being 14 bytes rather than= the 19 bytes you have below.=C2=A0 =C2=A0I expect that this difference wil= l decrease as time goes by.=C2=A0 We have a proposals on the table which wo= uld reduce the size of the COSE message for handling of single recipient me= ssages, but it is not clear which, if any, are going to be incorporated int= o the document.=C2=A0 Part of this is a question of what the implementation= sizes are going to be.

Although the kumar document says that there should be significant code reus= e between it and DTLS, I am not sure that I would agree with this.=C2=A0 It= seems to be that it is just reusing small portions but it would be a signi= ficant re-write and would need to=C2=A0 have a corresponding complete secur= ity review.

Jim



> -----Original Message-----
> From: COSE [mailto:cose-bounc= es@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, August 31, 2015 12:22 AM
> To: cose@ietf.org
> Subject: [COSE] Multicast Use Case
>
> Hi Jim, Brian, all,
>
> I am trying to compare the work on multicast security done by Sandeed = & co
> against an application layer solution using CBOR/COSE.
>
> The DTLS multicast includes the following relevant components:
> - Epoch: 2 Byte
> - Sender ID: 1 Byte
> - Sequence Number: 5 Byte
>
> The combination of epoch, sender id and sequence number are used as a = nonce
> for the cipher and the use of the sender id ensures that no member of = the group
> accidentally selects values that will cause re-use.
>
> The 1 byte sender id is chosen small to reflect the expected size of a= group in the
> professional lighting environment, as explained in the DTLS multicast = document.
>
> Ciphersuite related information includes:
> - Encrypted Content (variable length)
> - MAC (variable length)
>
> Content Type, Version and Length are DTLS-specific aspects that cannot= be
> removed without re-design of the record layer.
>
> Data based on Figure 4 of
> http://tools.ietf.org/html/= draft-keoh-dice-multicast-security-08.txt.
>
> Since there is no sequence number defined in COSE I put the epoch and = the
> sequence number together into the nonce field.
>
> Here is the commented version of the COSE message I came up with:
>
> [
>=C2=A0 =C2=A0 =C2=A0 2, // Encrypted COSE message
>=C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 1: 10, // Algorithm - AES-CCM-16-64-128
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 5: h'89f52fa' // 7-byte nonce
>=C2=A0 =C2=A0 =C2=A0 },
>=C2=A0 =C2=A0 =C2=A0 h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1= dd156ea6e6e0',
>=C2=A0 =C2=A0 =C2=A0 =C2=A0// encrypted payload.
>=C2=A0 =C2=A0 =C2=A0 [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h'',
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1: -6, // Direct use of CEK >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4: h'01' // Key ID - = 0x01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h''
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
>=C2=A0 =C2=A0 =C2=A0 ]
>=C2=A0 =C2=A0 ]
>
> According to cbor.me the resulting COSE encoding has 59 bytes whereby 28
> bytes are purely used for message encryption.=C2=A0 This means that th= ere is
> 31 bytes overhead with COSE compared to 12 bytes [=3D 8 for Epoch + Se= quence
> Number + Sender ID, 3 bytes for Content Type and Version fields].
>
> Ciao
> Hannes


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

--94eb2c06e9e430df41051ea21cb9-- From nobody Mon Aug 31 15:01:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458401B65E1 for ; Mon, 31 Aug 2015 15:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pnlBXBPGcVq for ; Mon, 31 Aug 2015 15:01:13 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00821B65CC for ; Mon, 31 Aug 2015 15:01:13 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 0D4FF38F10; Mon, 31 Aug 2015 15:01:11 -0700 (PDT) From: "Jim Schaad" To: "'Sandeep Kumar'" References: <55E400AC.7090507@gmx.net> <064c01d0e428$047d2700$0d777500$@augustcellars.com> In-Reply-To: Date: Mon, 31 Aug 2015 14:59:01 -0700 Message-ID: <068701d0e438$3fe18470$bfa48d50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0688_01D0E3FD.93DA4250" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQFOSJy01QpTkZygPNqMOVMY93IQJAHjrdalAqmDSFOfB28TYA== Archived-At: Cc: 'Hannes Tschofenig' , 'cose WG' Subject: Re: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 22:01:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0688_01D0E3FD.93DA4250 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did not find the keoh draft because it expired at the beginning of = July. Which is the draft that I should be looking at? =20 I could easily be wrong about the code reuse. On the other hand I = don=E2=80=99t know what the levels are that are being re-used from TLS, = so it can easily be that I have misunderstood what is going on. On the = other hand, I am not seeing a great deal of overlap with what I think of = as DTLS. I think there is a difference between being able to re-use = some small pieces of a DTLS system and saying that it is easily = adaptable from a DTLS system. =20 Do you use the three layer wrapping of DTLS: TLSPlainText, = TLSCompressed, TLSCiphertext? I assume that you do not use the = handshaking. I don=E2=80=99t think you have any of the fatal error = conditions. I don=E2=80=99t know if this is a unidirectional cast that = people cannot raise fatal alerts from. I assume that you don=E2=80=99t = do the change-cipher, but that is going away in 1.3 anyway so it is not = a big deal. =20 jim =20 =20 From: Sandeep Kumar [mailto:ietf@sandeep.de]=20 Sent: Monday, August 31, 2015 2:28 PM To: Jim Schaad Cc: Hannes Tschofenig ; cose WG = Subject: Re: [COSE] Multicast Use Case =20 Hi Jim You seem to be referring to an alternative version of the draft than = Hannes used. The draft Hannes used draft-keoh-dice-multicast-security-08 = uses SenderID to separate the nonce, while = draft-kumar-dice-multicast-security derives new keys per sender (based = on a single key and SenderID). the change was due to a difference is = preference in my co-author but should not change the overhead. Finally I disagree on your assessment on code reuse, it had been = implemented with minimal changes needed to an existing IoT DTLS library. regards Sandeep =20 On Mon, Aug 31, 2015 at 10:02 PM, Jim Schaad > wrote: Hannes, I think that characterizing draft-kumar-dice-multicast-security as some = type of DTLS may be a huge misnomer. On first read it is not matching a = great deal of what I think of as being TLS/DTLS. For example, all of = the record layering that is present in DTLS does not appear to be here, = and I would assume that none of the starting handshaking is going to be = present here. Looking at the figure 2 in that document appears to have an overhead of = 13 bytes, but I am not seeing the sender ID that you are talking about = so I am unsure that your analysis of the sizes is going to be correct = for this. It is definitely not true if the multiple layering of TLS is = going to be used. I am having a hard time with the example you gave, I put it into cbor.me = (after removing comments) and it generated a syntax = error. After generating it on my own, I came up with: [ 2, // encrypted message h'a2010a0547089f52fa000000', // Protected headers // {1: 10, - algorithm AES-CCM-16-64-128 // 5: h'089f52fa000000' - nonce of 7 bytes} { }, // Unprotected headers (none) h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', // = encrypted message + authentication tag [ [ h'', // Protected header - none { // Unprotected headers 1: -6, // Algorithm direct 4: h'01' // sender ID }, h'' // No cipher text ] ] ] Which maps to 56 bytes with a 28 byte message, using my best guess from = what you are saying you get a 42 byte message with you "DTLS" message. = The current difference in overhead thus being 14 bytes rather than the = 19 bytes you have below. I expect that this difference will decrease = as time goes by. We have a proposals on the table which would reduce = the size of the COSE message for handling of single recipient messages, = but it is not clear which, if any, are going to be incorporated into the = document. Part of this is a question of what the implementation sizes = are going to be. Although the kumar document says that there should be significant code = reuse between it and DTLS, I am not sure that I would agree with this. = It seems to be that it is just reusing small portions but it would be a = significant re-write and would need to have a corresponding complete = security review. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig > Sent: Monday, August 31, 2015 12:22 AM > To: cose@ietf.org =20 > Subject: [COSE] Multicast Use Case > > Hi Jim, Brian, all, > > I am trying to compare the work on multicast security done by Sandeed = & co > against an application layer solution using CBOR/COSE. > > The DTLS multicast includes the following relevant components: > - Epoch: 2 Byte > - Sender ID: 1 Byte > - Sequence Number: 5 Byte > > The combination of epoch, sender id and sequence number are used as a = nonce > for the cipher and the use of the sender id ensures that no member of = the group > accidentally selects values that will cause re-use. > > The 1 byte sender id is chosen small to reflect the expected size of a = group in the > professional lighting environment, as explained in the DTLS multicast = document. > > Ciphersuite related information includes: > - Encrypted Content (variable length) > - MAC (variable length) > > Content Type, Version and Length are DTLS-specific aspects that cannot = be > removed without re-design of the record layer. > > Data based on Figure 4 of > http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08.txt. > > Since there is no sequence number defined in COSE I put the epoch and = the > sequence number together into the nonce field. > > Here is the commented version of the COSE message I came up with: > > [ > 2, // Encrypted COSE message > { > 1: 10, // Algorithm - AES-CCM-16-64-128 > 5: h'89f52fa' // 7-byte nonce > }, > h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', > // encrypted payload. > [ > [ > h'', > { > 1: -6, // Direct use of CEK > 4: h'01' // Key ID - 0x01 > }, > h'' > ] > ] > ] > > According to cbor.me the resulting COSE encoding has = 59 bytes whereby 28 > bytes are purely used for message encryption. This means that there = is > 31 bytes overhead with COSE compared to 12 bytes [=3D 8 for Epoch + = Sequence > Number + Sender ID, 3 bytes for Content Type and Version fields]. > > Ciao > Hannes _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_0688_01D0E3FD.93DA4250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I did not find the keoh draft because it expired at the beginning of = July.=C2=A0=C2=A0 Which is the draft that I should be looking = at?

 

I could easily be wrong about the code reuse.=C2=A0=C2=A0 On the other = hand I don=E2=80=99t know what the levels are that are being re-used = from TLS, so it can easily be that I have misunderstood what is going = on.=C2=A0 On the other hand, I am not seeing a great deal of overlap = with what I think of as DTLS.=C2=A0=C2=A0=C2=A0 I think there is a = difference between being able to=C2=A0 re-use some small pieces of a = DTLS system and saying that it is easily adaptable from a DTLS = system.

 

Do you use the three layer wrapping of DTLS: TLSPlainText, = TLSCompressed, TLSCiphertext?=C2=A0 I assume that you do not use the = handshaking.=C2=A0 I don=E2=80=99t think you have any of the fatal error = conditions.=C2=A0 I don=E2=80=99t know if this is a unidirectional cast = that people cannot raise fatal alerts from. =C2=A0=C2=A0I assume that = you don=E2=80=99t do the change-cipher, but that is going away in 1.3 = anyway so it is not a big deal.

 

jim

 

 

From:<= /b> = Sandeep Kumar [mailto:ietf@sandeep.de]
Sent: Monday, August = 31, 2015 2:28 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Hannes Tschofenig = <hannes.tschofenig@gmx.net>; cose WG = <cose@ietf.org>
Subject: Re: [COSE] Multicast Use = Case

 

Hi = Jim

You seem to be referring to an = alternative version of the draft than Hannes used. The draft Hannes used = draft-keoh-dice-multicast-security-08 uses SenderID to separate the = nonce, while draft-kumar-dice-multicast-security derives new keys per = sender (based on a single key and SenderID). the change was due to a = difference is preference in my co-author but should not change the = overhead.

Finally I disagree on your assessment on = code reuse, it had been implemented with minimal changes needed to an = existing IoT DTLS library.

regards

Sandeep

 

On Mon, = Aug 31, 2015 at 10:02 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

Hannes,

I think that characterizing = draft-kumar-dice-multicast-security as some type of DTLS may be a huge = misnomer.  On first read it is not matching a great deal of what I = think of as being TLS/DTLS.   For example, all of the record = layering that is present in DTLS does not appear to be here, and I would = assume that none of the starting handshaking is going to be present = here.

Looking at the figure 2 in that document appears to have an = overhead of 13 bytes, but I am not seeing the sender ID that you are = talking about so I am unsure that your analysis of the sizes is going to = be correct for this.  It is definitely not true if the multiple = layering of TLS is going to be used.

I am having a hard time with = the example you gave, I put it into cbor.me (after removing comments) and it generated = a syntax error.  After generating it on my own, I came up = with:

[
     2,  // encrypted = message
     h'a2010a0547089f52fa000000', //  = Protected headers
        //  {1: 10, - = algorithm AES-CCM-16-64-128
            =    //   5: h'089f52fa000000' - nonce of 7 = bytes}
     {     },  // = Unprotected headers (none)
    =  h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0', // = encrypted message + authentication tag
    =  [
       [
        =  h'',  // Protected header - none
      =    { //  Unprotected headers
      =      1: -6,  // Algorithm direct
    =        4: h'01' // sender ID
      =    },
         h'' // No cipher = text
       ]
     ]
  =  ]

Which maps to 56 bytes with a 28 byte message, using my = best guess from what you are saying you get a 42 byte message with you = "DTLS" message.  The current difference in overhead thus = being 14 bytes rather than the 19 bytes you have below.   I = expect that this difference will decrease as time goes by.  We have = a proposals on the table which would reduce the size of the COSE message = for handling of single recipient messages, but it is not clear which, if = any, are going to be incorporated into the document.  Part of this = is a question of what the implementation sizes are going to = be.

Although the kumar document says that there should be = significant code reuse between it and DTLS, I am not sure that I would = agree with this.  It seems to be that it is just reusing small = portions but it would be a significant re-write and would need to  = have a corresponding complete security = review.

Jim




> -----Original = Message-----
> From: COSE [mailto:cose-bounces@ietf.org] On = Behalf Of Hannes Tschofenig
> Sent: Monday, August 31, 2015 12:22 = AM
> To: cose@ietf.org
> Subject: [COSE] = Multicast Use Case
>
> Hi Jim, Brian, all,
>
> I = am trying to compare the work on multicast security done by Sandeed = & co
> against an application layer solution using = CBOR/COSE.
>
> The DTLS multicast includes the following = relevant components:
> - Epoch: 2 Byte
> - Sender ID: 1 = Byte
> - Sequence Number: 5 Byte
>
> The combination = of epoch, sender id and sequence number are used as a nonce
> for = the cipher and the use of the sender id ensures that no member of the = group
> accidentally selects values that will cause = re-use.
>
> The 1 byte sender id is chosen small to reflect = the expected size of a group in the
> professional lighting = environment, as explained in the DTLS multicast = document.
>
> Ciphersuite related information = includes:
> - Encrypted Content (variable length)
> - MAC = (variable length)
>
> Content Type, Version and Length are = DTLS-specific aspects that cannot be
> removed without re-design = of the record layer.
>
> Data based on Figure 4 of
> = http://tools.ietf.org/html/draft-keoh-dice-multicast-se= curity-08.txt.
>
> Since there is no sequence number = defined in COSE I put the epoch and the
> sequence number together = into the nonce field.
>
> Here is the commented version of = the COSE message I came up with:
>
> [
>    =   2, // Encrypted COSE message
>      = {
>        1: 10, // Algorithm - = AES-CCM-16-64-128
>        5: h'89f52fa' // = 7-byte nonce
>      },
>      = h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0',
> = ;      // encrypted payload.
>      = [
>        [
>      =     h'',
>          = {
>            1: -6, // Direct use = of CEK
>            4: h'01' // Key = ID - 0x01
>          },
>  =         h''
>        = ]
>      ]
>    ]
>
> = According to cbor.me = the resulting COSE encoding has 59 bytes whereby 28
> bytes are = purely used for message encryption.  This means that there = is
> 31 bytes overhead with COSE compared to 12 bytes [=3D 8 for = Epoch + Sequence
> Number + Sender ID, 3 bytes for Content Type = and Version fields].
>
> Ciao
> = Hannes

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

 

------=_NextPart_000_0688_01D0E3FD.93DA4250-- From nobody Mon Aug 31 15:32:11 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040F41B680F for ; Mon, 31 Aug 2015 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4lbk5T_s4Jh for ; Mon, 31 Aug 2015 15:32:02 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59101B680A for ; Mon, 31 Aug 2015 15:32:01 -0700 (PDT) Received: from AM3PR04CA0121.eurprd04.prod.outlook.com (10.163.180.175) by AM3PR04MB258.eurprd04.prod.outlook.com (10.242.17.141) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 22:31:37 +0000 Received: from AM1FFO11FD006.protection.gbl (2a01:111:f400:7e00::130) by AM3PR04CA0121.outlook.office365.com (2a01:111:e400:5366::47) with Microsoft SMTP Server (TLS) id 15.1.256.15 via Frontend Transport; Mon, 31 Aug 2015 22:31:37 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.180) smtp.mailfrom=philips.com; augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.180) by AM1FFO11FD006.mail.protection.outlook.com (10.174.64.68) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Mon, 31 Aug 2015 22:31:37 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com (141.251.190.211) by DB5PR9001MB0166.MGDPHG.emi.philips.com (141.251.190.210) with Microsoft SMTP Server (TLS) id 15.1.243.23; Mon, 31 Aug 2015 22:31:37 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) by DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) with mapi id 15.01.0243.024; Mon, 31 Aug 2015 22:31:37 +0000 From: "Kumar, Sandeep" To: Jim Schaad , 'Sandeep Kumar' Thread-Topic: [COSE] Multicast Use Case Thread-Index: AQHQ5DQI0HQqxwYTMEKmIHqCQn83rZ4mqBSAgAAGOWA= Date: Mon, 31 Aug 2015 22:31:37 +0000 Message-ID: <8e663e2255cb42a196b444884e8abd99@DB5PR9001MB0167.MGDPHG.emi.philips.com> References: <55E400AC.7090507@gmx.net> <064c01d0e428$047d2700$0d777500$@augustcellars.com> <068701d0e438$3fe18470$bfa48d50$@augustcellars.com> In-Reply-To: <068701d0e438$3fe18470$bfa48d50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: multipart/alternative; boundary="_000_8e663e2255cb42a196b444884e8abd99DB5PR9001MB0167MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD006; 1:NH68CS9Zzi2+/Ha5GN8phvWMoTKus8Xa9Lmc6pS1PLbQaXNWTvZSHwDbh09CQicgw2YeRZbiNA6t608OwTK2Y00LxuhqRRZqvnmMpTdNYmVpMS45Ww4shjW4vbfLx+5AQRY533fh4t3nsGFGbycEcE1huL3II/PmCXAaFmApQaOJEVUGCjjjAvuJ97t3+pwqJrlvJ5W2DJPTMYvQPdy3Nk2Cm/d5o76KzEtlrsafbkHezea4MmWG3rH0eYfFEKBhVYe9PiLDLXtaHfKx7DZV3YLUynwy6ptTfC/fxA/wRHbs+ry1t1AAreGhv8+skxIYQSXSJdYWj/D9Hwh0hs0etxBztJWeTpfIyzCUUCyeYOM= X-Forefront-Antispam-Report: CIP:23.103.247.180; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(428002)(199003)(377454003)(13464003)(24454002)(189002)(85714005)(55904004)(374574003)(51444003)(5001860100001)(101416001)(97736004)(14971765001)(4001540100001)(69596002)(106116001)(81156007)(24736003)(10400500002)(76176999)(5001960100002)(5001830100001)(16236675004)(105586002)(54356999)(16601075003)(84326002)(106466001)(18717965001)(50986999)(62966003)(16796002)(2656002)(87936001)(189998001)(64706001)(19300405004)(86362001)(16297215004)(19625215002)(512874002)(19580395003)(66066001)(46102003)(92566002)(5001770100001)(5007970100001)(77156002)(15975445007)(19617315012)(5004730100002)(93886004)(33646002)(5003600100002)(68736005)(2900100001)(2950100001)(108616004)(102836002)(19580405001)(6806004)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR04MB258; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB258; 2:/mYzu6g/5idvEhc5YQ0FqP6oUQ2cg9RLH5xRn4vfvrnSS1UX41QT0iudoncNUl8MyKKwiJCPleuFBMiN+cUIFqGFTJzfgQnL/jNKzOC3436bxGC6x22NynepmmqPccr64QgPB7guXB7hsRCKi2X/iHA1u8z01kVkKypAHAQpGaI=; 3:bEXnO7207ZWfPO2jnY+lTuMW+1uQSJDpYygwSf1L3NHtgl6TYGrOt/i2lPPrQbiH8Z5rsNNFntmECx3Z36F2xYILFtyHGyp6qggjKb6Uain31/gMhL1/WpL/Q5gLMqRlsLCGerwksYHn7upMt0DM0Bg7fpm/Dp0a5wixKTolWzy/yBhJJ3dWsZ+6TXx3AJejf+3vdxextgkukzp9w584isozlxWeIqQV7tWvChfYt2g=; 25:5EARgzgDSUdfIOQ9l2/wrh6xB6c0czmYc8M+Po1rG2SVvd2ak3Do9p1KH2MYVH8GRLl9wvU7b0x+QRxuLbvkjDlrHzDm2XWRo2QW7TrJS4WfpXrhlF6CBlLEvc7qBDL1WdPKzePeEZoVx9FJnxbZnsOzTLCQ2+Sijt6PjjYAA54BvbhFYSYnpmOxgbht6t1tCQ1CYOzm1cE8wCwoICLWOriMiQSCqBF36PKeKBoZJn8aBGM0zCiBiVL6SW0nhWSK/NM8InHSevT9OC02psgBGA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR04MB258; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB258; 20:izu1IhkI3NWScQujVzoSZJvXJZipy0mzC8ClWbkqnQBbt4KFOpaREUrNgzpAUYGDKhd0h2vCy6z1SKxJ9SjqyGSgp3r7PVB8+K3wbvZyppB+r30K7acD7Pfzni7cXZZDHCKKjPLahotQ1C450IbimntTolIulxE7bA0torurZb8Z/GeQFPrxFZjg/Be4CB/4SzYTPrA+P7Q7QenunU0meMQsx5ywboRTF5woytnzh+JMgMknsWQJJ98bAF90Gr+FhlObZ6skPnE3phc0ic5WyI03y7n1eK67I9QHQSMiUa0RhjA+HzOMW9GvdHuqWmot0T3zyAXpYYqvYihMg5vf0BQyz1aV+rpnhT6Q9eTmm9Bf7h/amdBzpxku4YAbkzHHEj6Yiqrtsk1Em6euB9Po1r3EESsfcJr7tvxET+fk39LePEI4HiqZ812Sn+KDTLpQr0goUgZeH6WLCCobOAYNKdNJn/keW5wml197Q4ryx6tL1dUQTCect3xX0gsCJ2Ss; 4:z9pdyUraMkjhGeSZ3427Fkn6O2aU1bxrVtyEqN0XZZI6Dh3rib1/R/sUGod3xqSJZEk2PDa261+s70xPAUlFVYgek2jE2M0oA2zI92YafkIfFq5k1aI6qmnjlD5PuopmjkT/CxwaeeaV859mwcQkDLa8IxIOBH1gRNY/C2hiZnObY04Jlf6OGJ/18/DxXclO+vUlDNVze7GS+UZFRAN5XZw0HCyF/JtcPXpk9zLUPGz+zgfwwxpsipKDSQgdX34RwF2wtXQN+ysDuWLz//3/5eVpZ5khSGr+rq+SOw0POT7AsaK3KfyrwG1YKKmetHXv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:AM3PR04MB258; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB258; X-Forefront-PRVS: 0685122203 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR04MB258; 23:+Y6/zB8dNX3Muu0+n80qESjVoXcywVTIpUNJKcWeES?= =?us-ascii?Q?GmT7zHr7G5mYAYT2OQ7Bs3LDIjBO/TtohnbZL9tPH+vHfwmWJOj+R0GgEpRA?= =?us-ascii?Q?m9InqP/0MQcg8phPhkbBWDRh8pCHEJ8EPScp0RaXkRiqi1UJH2b36Azw1BYh?= =?us-ascii?Q?8qq8D+00cmqoAazQbFbfBTghNqW1WauG+D9/wnJc9EcLAOhqNdS9Deifj2AY?= =?us-ascii?Q?wjDhRJZ4QiyHoTp+RR6jx9dBWRqZnq/KIvHqHeXIeBFZ6b4umJO9hzZWuhla?= =?us-ascii?Q?2uJcMFztHujuZJNcKUXCKswOHcK/z61/E5myWdVt4NTHO56eY0PySig08vzk?= =?us-ascii?Q?jMa756npxhczGADMNl5kG+ODPOJfWVMGuACbPB9Xo1v4j3Iyv26+qqKVfC7r?= =?us-ascii?Q?oDyPMGlBI1bI38vzQsMXQuI/N3hZFysD1TU4EiVL6pRfv+lZ2C2Vp9tjrpre?= =?us-ascii?Q?D+RSU3aX34RoVeEgSLypwwiSK+2DyjwNi3Fdc5EhDz0JqXKIL4jSZixz9Bp4?= =?us-ascii?Q?fE6NzM1a44t7o0+mw7aaQIyVFisC1Ko3zwxaC0SV34rbmj1Nx3m4h/pmmRqA?= =?us-ascii?Q?BOq8jbg+0sYIRNI7xPuDT/waW9IQFb0pUAppt9kfETtCqfQhEFDK9dpJu9WN?= =?us-ascii?Q?yAUcvpivIiUbMlS4Dp0EgkbCi0sx9W7czGiuM/zHHs7iBlhVE3daFvxEomBs?= =?us-ascii?Q?7JVptj4s9gSQxAwu3pSJooRXJaE3Ud+hPu/oPbsnm42ADUvzRwA9G2DvVpsk?= =?us-ascii?Q?JlsMDhWnz7FRLBHuiH6kcmr0C5SI5gG7OSnx6uu3bdiHUTTJO4LZTGdkGstD?= =?us-ascii?Q?hscdTU3Co4HjOkBZh3vGwagBYjZumMO7hvt8ZSwaTkl/NM0ZAanHv10V45D8?= =?us-ascii?Q?18FHJQkEe+SROQumeG16/++FiABFtcgnxjSu//Rq/ctPWbMnAiz/lLUOLN/c?= =?us-ascii?Q?dYp9SspBf9KCBUYcREMEU54AofQCFG1hpGZXSTklxgZRn73XDhzHBj2bSVoT?= =?us-ascii?Q?/fwUF9aIYuRs74h9A3dIBJOaz7AIVqWsS7H0ngqXmt+o7LgPCk93aP65o5df?= =?us-ascii?Q?Yq+J8J9GF9O3hhYSeftpC4cdwcNVM1K1t6WEsQVJqYl7vOUIyNlhxSq/YGqB?= =?us-ascii?Q?XZcqTtkfFc+OUwVRCUBw1jMTGPW01yh5tpXfZw5oZyPcpYwFeG+T5OUGW+nL?= =?us-ascii?Q?lCLqrA/JEZCL3l6wbL9N2REoY+nOUyK9bAUiMvsW0BtGNeXMp4lgi6oMwsZE?= =?us-ascii?Q?tAM0gHSKJL0b7e9MkOGbqOjAuYlO8Sym9YbMPTkuyhLoPPNHDD1U/fegDn2H?= =?us-ascii?Q?VNs4WPsJqYNM/HqoArrNFX1Iaxs8c1Z1E2NnQdRB5Z49q+Ikv4qmVKoY5f0k?= =?us-ascii?Q?3tu6V9xPk02eOgIXlwQw2xEnA7uAinRWdN45Owy3PQfMhQ90L6kJuzXxUjE1?= =?us-ascii?Q?e1VeE46Aob+RrFclbjyQtR5/utKdz09g7kKuM13gy6PMJvsWqTNvAq5ILK5Q?= =?us-ascii?Q?s0bmBFNxIL7bXWB2Ptp+zeGlEKEfATMlpwhyZeXyMbNSpJ4jD+WyXTAh6aoF?= =?us-ascii?Q?Q85brohsvpaQbNMHSA5/krhhAgodQm3e1reJmTspg3tyHOICFwCS6rLskc0s?= =?us-ascii?Q?UCiu+tGcVpR3cJP5sx1WLBgC5J9tzbPAqwoyPId6yVdNGjownmHTRuscZo7v?= =?us-ascii?Q?1XvlhR9jPvbf5P/9yroPao2ZsMUvGX0L/jkLOB9t/dw78=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB258; 5:CGDIa9dbmBUIIq2WsixoFmcIYd00thXew7ooc3SnbIjHsKGyKa7Ieu8a4dDwfaoTT8iAFsExAtASfoHKOaw1FSzPrBaPZ3rjNQ9T0QeIHgQegaEpYfjAnztjbddFEyUn4p46U5I0qYEodUvSBnTs2Q==; 24:NxWJvxAQmOIwaN9XPAuZ+3W3CGwuy/zEnD1M3kY8ULQTcqCjLTBamaqyT4gzFS6IvpX0swVDWUYgXdDrGHdjRBACo65+RhXHDiscIUuejb8=; 20:ydT8LeqvRR7oFIgXzc/3zOXl2541n2kT5AfRV4TLyn3/V0khwyvwgr944sIASDxxVI3f5tart2FbTKKZeG2dCw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2015 22:31:37.3683 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.180]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR04MB258 Archived-At: Cc: 'Hannes Tschofenig' , 'cose WG' Subject: Re: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 22:32:07 -0000 --_000_8e663e2255cb42a196b444884e8abd99DB5PR9001MB0167MGDPHGem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGtlb2ggZHJhZnQgd291bGQgYmUgYXBwbGljYWJsZSBoZXJlIGZvciBjb21wYXJpc29uLg0K DQpUaGUgb3ZlcmxhcCBpcyBpbiBzZW5zZSBvZiBhZGRpdGlvbmFsIGNvZGUgdG8gZW5hYmxlIHNl Y3VyZSBtdWx0aWNhc3QgaWYgRFRMUyBpcyBhbHJlYWR5IHByZXNlbnQgZm9yIHVuaWNhc3QuIFll cyBhbGVydHMgYW5kIGhhbmRzaGFrZSBmcm9tIHVuaWNhc3QgYXJlIG5vdCB1c2VkIGluIHRoZSBt dWx0aWNhc3QgKGJ1dCBEVExTIHVuaWNhc3QgY2FuIGJlIHVzZWQgdG8gZG8gdGhlIGtleSB1cGRh dGVzIGZvciBtdWx0aWNhc3QpLg0KDQpJIHRoaW5rIHlvdSBhcmUgbWlzcmVhZGluZyB0aGUgVExT UGxhaW5UZXh0LCBUTFNDb21wcmVzc2VkLCBUTFNDaXBoZXJ0ZXh0LiBUaGV5IGFyZSBub3Qgd3Jh cHBlcnMgaW4gdGhlIHNlbnNlIHRoYXQgZWFjaCBvbmUgaXMgZW1iZWRkZWQgaW5zaWRlIGFub3Ro ZXIuIFRoZXkgYXJlIGp1c3Qgc3RydWN0cyB0byBpbmRpY2F0ZSB0aGUgcHJlc2VudCBzdGF0dXMg b2YgdGhlIHByb2Nlc3NpbmcsIG9ubHkgdGhlIGxlbmd0aCBhbmQgdGhlIG9wYXF1ZSBmcmFnbWVu dCAgZ2V0cyBtb2RpZmllZCBhdCBlYWNoIHN0YWdlIHdoaWxlIHRoZSBjb250ZW50IHR5cGUgYW5k IHZlcnNpb24gYXJlIGNvcGllZCB0byB0aGUgbmV4dCBzdHJ1Y3QuIFNlZSBob3cgVExTQ29tcHJl c3NlZCBpcyBjb25zdHJ1Y3RlZCBmcm9tIFRMU1BsYWludGV4dCBpbiA2LjIuMiBpbiBSRkMgNTI0 NiAoVExTQ29tcHJlc3NlZC5mcmFnbWVudCBpcyB0aGUgY29tcHJlc3NlZCBmb3JtIG9mIFRMU1Bs YWludGV4dC5mcmFnbWVudCBhbmQgbm90IFRMU1BsYWludGV4dCkuIFRoZXJlIGFyZSBubyBhZGRp dGlvbmFsIHdyYXBzL2xheWVycyBpbnNpZGUgaWYgeW91IGxvb2sgY2xvc2VseS4NCg0KUmVnYXJk cw0KU2FuZGVlcA0KDQpGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSmltIFNjaGFhZA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMzEsIDIwMTUgMTE6 NTkgUE0NClRvOiAnU2FuZGVlcCBLdW1hcicNCkNjOiAnSGFubmVzIFRzY2hvZmVuaWcnOyAnY29z ZSBXRycNClN1YmplY3Q6IFJlOiBbQ09TRV0gTXVsdGljYXN0IFVzZSBDYXNlDQoNCkkgZGlkIG5v dCBmaW5kIHRoZSBrZW9oIGRyYWZ0IGJlY2F1c2UgaXQgZXhwaXJlZCBhdCB0aGUgYmVnaW5uaW5n IG9mIEp1bHkuICAgV2hpY2ggaXMgdGhlIGRyYWZ0IHRoYXQgSSBzaG91bGQgYmUgbG9va2luZyBh dD8NCg0KSSBjb3VsZCBlYXNpbHkgYmUgd3JvbmcgYWJvdXQgdGhlIGNvZGUgcmV1c2UuICAgT24g dGhlIG90aGVyIGhhbmQgSSBkb27igJl0IGtub3cgd2hhdCB0aGUgbGV2ZWxzIGFyZSB0aGF0IGFy ZSBiZWluZyByZS11c2VkIGZyb20gVExTLCBzbyBpdCBjYW4gZWFzaWx5IGJlIHRoYXQgSSBoYXZl IG1pc3VuZGVyc3Rvb2Qgd2hhdCBpcyBnb2luZyBvbi4gIE9uIHRoZSBvdGhlciBoYW5kLCBJIGFt IG5vdCBzZWVpbmcgYSBncmVhdCBkZWFsIG9mIG92ZXJsYXAgd2l0aCB3aGF0IEkgdGhpbmsgb2Yg YXMgRFRMUy4gICAgSSB0aGluayB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBiZWluZyBh YmxlIHRvICByZS11c2Ugc29tZSBzbWFsbCBwaWVjZXMgb2YgYSBEVExTIHN5c3RlbSBhbmQgc2F5 aW5nIHRoYXQgaXQgaXMgZWFzaWx5IGFkYXB0YWJsZSBmcm9tIGEgRFRMUyBzeXN0ZW0uDQoNCkRv IHlvdSB1c2UgdGhlIHRocmVlIGxheWVyIHdyYXBwaW5nIG9mIERUTFM6IFRMU1BsYWluVGV4dCwg VExTQ29tcHJlc3NlZCwgVExTQ2lwaGVydGV4dD8gIEkgYXNzdW1lIHRoYXQgeW91IGRvIG5vdCB1 c2UgdGhlIGhhbmRzaGFraW5nLiAgSSBkb27igJl0IHRoaW5rIHlvdSBoYXZlIGFueSBvZiB0aGUg ZmF0YWwgZXJyb3IgY29uZGl0aW9ucy4gIEkgZG9u4oCZdCBrbm93IGlmIHRoaXMgaXMgYSB1bmlk aXJlY3Rpb25hbCBjYXN0IHRoYXQgcGVvcGxlIGNhbm5vdCByYWlzZSBmYXRhbCBhbGVydHMgZnJv bS4gICBJIGFzc3VtZSB0aGF0IHlvdSBkb27igJl0IGRvIHRoZSBjaGFuZ2UtY2lwaGVyLCBidXQg dGhhdCBpcyBnb2luZyBhd2F5IGluIDEuMyBhbnl3YXkgc28gaXQgaXMgbm90IGEgYmlnIGRlYWwu DQoNCmppbQ0KDQoNCkZyb206IFNhbmRlZXAgS3VtYXIgW21haWx0bzppZXRmQHNhbmRlZXAuZGVd DQpTZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAxNSAyOjI4IFBNDQpUbzogSmltIFNjaGFhZCA8 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+DQpD YzogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhh bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PjsgY29zZSBXRyA8Y29zZUBpZXRmLm9yZzxtYWlsdG86 Y29zZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0NPU0VdIE11bHRpY2FzdCBVc2UgQ2FzZQ0K DQpIaSBKaW0NCllvdSBzZWVtIHRvIGJlIHJlZmVycmluZyB0byBhbiBhbHRlcm5hdGl2ZSB2ZXJz aW9uIG9mIHRoZSBkcmFmdCB0aGFuIEhhbm5lcyB1c2VkLiBUaGUgZHJhZnQgSGFubmVzIHVzZWQg ZHJhZnQta2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eS0wOCB1c2VzIFNlbmRlcklEIHRvIHNl cGFyYXRlIHRoZSBub25jZSwgd2hpbGUgZHJhZnQta3VtYXItZGljZS1tdWx0aWNhc3Qtc2VjdXJp dHkgZGVyaXZlcyBuZXcga2V5cyBwZXIgc2VuZGVyIChiYXNlZCBvbiBhIHNpbmdsZSBrZXkgYW5k IFNlbmRlcklEKS4gdGhlIGNoYW5nZSB3YXMgZHVlIHRvIGEgZGlmZmVyZW5jZSBpcyBwcmVmZXJl bmNlIGluIG15IGNvLWF1dGhvciBidXQgc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIG92ZXJoZWFkLg0K RmluYWxseSBJIGRpc2FncmVlIG9uIHlvdXIgYXNzZXNzbWVudCBvbiBjb2RlIHJldXNlLCBpdCBo YWQgYmVlbiBpbXBsZW1lbnRlZCB3aXRoIG1pbmltYWwgY2hhbmdlcyBuZWVkZWQgdG8gYW4gZXhp c3RpbmcgSW9UIERUTFMgbGlicmFyeS4NCnJlZ2FyZHMNClNhbmRlZXANCg0KT24gTW9uLCBBdWcg MzEsIDIwMTUgYXQgMTA6MDIgUE0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208 bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+PiB3cm90ZToNCkhhbm5lcywNCg0KSSB0aGlu ayB0aGF0IGNoYXJhY3Rlcml6aW5nIGRyYWZ0LWt1bWFyLWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5 IGFzIHNvbWUgdHlwZSBvZiBEVExTIG1heSBiZSBhIGh1Z2UgbWlzbm9tZXIuICBPbiBmaXJzdCBy ZWFkIGl0IGlzIG5vdCBtYXRjaGluZyBhIGdyZWF0IGRlYWwgb2Ygd2hhdCBJIHRoaW5rIG9mIGFz IGJlaW5nIFRMUy9EVExTLiAgIEZvciBleGFtcGxlLCBhbGwgb2YgdGhlIHJlY29yZCBsYXllcmlu ZyB0aGF0IGlzIHByZXNlbnQgaW4gRFRMUyBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgaGVyZSwgYW5k IEkgd291bGQgYXNzdW1lIHRoYXQgbm9uZSBvZiB0aGUgc3RhcnRpbmcgaGFuZHNoYWtpbmcgaXMg Z29pbmcgdG8gYmUgcHJlc2VudCBoZXJlLg0KDQpMb29raW5nIGF0IHRoZSBmaWd1cmUgMiBpbiB0 aGF0IGRvY3VtZW50IGFwcGVhcnMgdG8gaGF2ZSBhbiBvdmVyaGVhZCBvZiAxMyBieXRlcywgYnV0 IEkgYW0gbm90IHNlZWluZyB0aGUgc2VuZGVyIElEIHRoYXQgeW91IGFyZSB0YWxraW5nIGFib3V0 IHNvIEkgYW0gdW5zdXJlIHRoYXQgeW91ciBhbmFseXNpcyBvZiB0aGUgc2l6ZXMgaXMgZ29pbmcg dG8gYmUgY29ycmVjdCBmb3IgdGhpcy4gIEl0IGlzIGRlZmluaXRlbHkgbm90IHRydWUgaWYgdGhl IG11bHRpcGxlIGxheWVyaW5nIG9mIFRMUyBpcyBnb2luZyB0byBiZSB1c2VkLg0KDQpJIGFtIGhh dmluZyBhIGhhcmQgdGltZSB3aXRoIHRoZSBleGFtcGxlIHlvdSBnYXZlLCBJIHB1dCBpdCBpbnRv IGNib3IubWU8aHR0cDovL2Nib3IubWU+IChhZnRlciByZW1vdmluZyBjb21tZW50cykgYW5kIGl0 IGdlbmVyYXRlZCBhIHN5bnRheCBlcnJvci4gIEFmdGVyIGdlbmVyYXRpbmcgaXQgb24gbXkgb3du LCBJIGNhbWUgdXAgd2l0aDoNCg0KWw0KICAgICAyLCAgLy8gZW5jcnlwdGVkIG1lc3NhZ2UNCiAg ICAgaCdhMjAxMGEwNTQ3MDg5ZjUyZmEwMDAwMDAnLCAvLyAgUHJvdGVjdGVkIGhlYWRlcnMNCiAg ICAgICAgLy8gIHsxOiAxMCwgLSBhbGdvcml0aG0gQUVTLUNDTS0xNi02NC0xMjgNCiAgICAgICAg ICAgICAgIC8vICAgNTogaCcwODlmNTJmYTAwMDAwMCcgLSBub25jZSBvZiA3IGJ5dGVzfQ0KICAg ICB7ICAgICB9LCAgLy8gVW5wcm90ZWN0ZWQgaGVhZGVycyAobm9uZSkNCiAgICAgaCc3YjlkY2Zh NDJjNGUxZDMxODJjNDAyZGMxOGVmOGI1NjM3ZGU0ZmI2MmNmMWRkMTU2ZWE2ZTZlMCcsIC8vIGVu Y3J5cHRlZCBtZXNzYWdlICsgYXV0aGVudGljYXRpb24gdGFnDQogICAgIFsNCiAgICAgICBbDQog ICAgICAgICBoJycsICAvLyBQcm90ZWN0ZWQgaGVhZGVyIC0gbm9uZQ0KICAgICAgICAgeyAvLyAg VW5wcm90ZWN0ZWQgaGVhZGVycw0KICAgICAgICAgICAxOiAtNiwgIC8vIEFsZ29yaXRobSBkaXJl Y3QNCiAgICAgICAgICAgNDogaCcwMScgLy8gc2VuZGVyIElEDQogICAgICAgICB9LA0KICAgICAg ICAgaCcnIC8vIE5vIGNpcGhlciB0ZXh0DQogICAgICAgXQ0KICAgICBdDQogICBdDQoNCldoaWNo IG1hcHMgdG8gNTYgYnl0ZXMgd2l0aCBhIDI4IGJ5dGUgbWVzc2FnZSwgdXNpbmcgbXkgYmVzdCBn dWVzcyBmcm9tIHdoYXQgeW91IGFyZSBzYXlpbmcgeW91IGdldCBhIDQyIGJ5dGUgbWVzc2FnZSB3 aXRoIHlvdSAiRFRMUyIgbWVzc2FnZS4gIFRoZSBjdXJyZW50IGRpZmZlcmVuY2UgaW4gb3Zlcmhl YWQgdGh1cyBiZWluZyAxNCBieXRlcyByYXRoZXIgdGhhbiB0aGUgMTkgYnl0ZXMgeW91IGhhdmUg YmVsb3cuICAgSSBleHBlY3QgdGhhdCB0aGlzIGRpZmZlcmVuY2Ugd2lsbCBkZWNyZWFzZSBhcyB0 aW1lIGdvZXMgYnkuICBXZSBoYXZlIGEgcHJvcG9zYWxzIG9uIHRoZSB0YWJsZSB3aGljaCB3b3Vs ZCByZWR1Y2UgdGhlIHNpemUgb2YgdGhlIENPU0UgbWVzc2FnZSBmb3IgaGFuZGxpbmcgb2Ygc2lu Z2xlIHJlY2lwaWVudCBtZXNzYWdlcywgYnV0IGl0IGlzIG5vdCBjbGVhciB3aGljaCwgaWYgYW55 LCBhcmUgZ29pbmcgdG8gYmUgaW5jb3Jwb3JhdGVkIGludG8gdGhlIGRvY3VtZW50LiAgUGFydCBv ZiB0aGlzIGlzIGEgcXVlc3Rpb24gb2Ygd2hhdCB0aGUgaW1wbGVtZW50YXRpb24gc2l6ZXMgYXJl IGdvaW5nIHRvIGJlLg0KDQpBbHRob3VnaCB0aGUga3VtYXIgZG9jdW1lbnQgc2F5cyB0aGF0IHRo ZXJlIHNob3VsZCBiZSBzaWduaWZpY2FudCBjb2RlIHJldXNlIGJldHdlZW4gaXQgYW5kIERUTFMs IEkgYW0gbm90IHN1cmUgdGhhdCBJIHdvdWxkIGFncmVlIHdpdGggdGhpcy4gIEl0IHNlZW1zIHRv IGJlIHRoYXQgaXQgaXMganVzdCByZXVzaW5nIHNtYWxsIHBvcnRpb25zIGJ1dCBpdCB3b3VsZCBi ZSBhIHNpZ25pZmljYW50IHJlLXdyaXRlIGFuZCB3b3VsZCBuZWVkIHRvICBoYXZlIGEgY29ycmVz cG9uZGluZyBjb21wbGV0ZSBzZWN1cml0eSByZXZpZXcuDQoNCkppbQ0KDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSGFubmVz IFRzY2hvZmVuaWcNCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMzEsIDIwMTUgMTI6MjIgQU0NCj4g VG86IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtDT1NF XSBNdWx0aWNhc3QgVXNlIENhc2UNCj4NCj4gSGkgSmltLCBCcmlhbiwgYWxsLA0KPg0KPiBJIGFt IHRyeWluZyB0byBjb21wYXJlIHRoZSB3b3JrIG9uIG11bHRpY2FzdCBzZWN1cml0eSBkb25lIGJ5 IFNhbmRlZWQgJiBjbw0KPiBhZ2FpbnN0IGFuIGFwcGxpY2F0aW9uIGxheWVyIHNvbHV0aW9uIHVz aW5nIENCT1IvQ09TRS4NCj4NCj4gVGhlIERUTFMgbXVsdGljYXN0IGluY2x1ZGVzIHRoZSBmb2xs b3dpbmcgcmVsZXZhbnQgY29tcG9uZW50czoNCj4gLSBFcG9jaDogMiBCeXRlDQo+IC0gU2VuZGVy IElEOiAxIEJ5dGUNCj4gLSBTZXF1ZW5jZSBOdW1iZXI6IDUgQnl0ZQ0KPg0KPiBUaGUgY29tYmlu YXRpb24gb2YgZXBvY2gsIHNlbmRlciBpZCBhbmQgc2VxdWVuY2UgbnVtYmVyIGFyZSB1c2VkIGFz IGEgbm9uY2UNCj4gZm9yIHRoZSBjaXBoZXIgYW5kIHRoZSB1c2Ugb2YgdGhlIHNlbmRlciBpZCBl bnN1cmVzIHRoYXQgbm8gbWVtYmVyIG9mIHRoZSBncm91cA0KPiBhY2NpZGVudGFsbHkgc2VsZWN0 cyB2YWx1ZXMgdGhhdCB3aWxsIGNhdXNlIHJlLXVzZS4NCj4NCj4gVGhlIDEgYnl0ZSBzZW5kZXIg aWQgaXMgY2hvc2VuIHNtYWxsIHRvIHJlZmxlY3QgdGhlIGV4cGVjdGVkIHNpemUgb2YgYSBncm91 cCBpbiB0aGUNCj4gcHJvZmVzc2lvbmFsIGxpZ2h0aW5nIGVudmlyb25tZW50LCBhcyBleHBsYWlu ZWQgaW4gdGhlIERUTFMgbXVsdGljYXN0IGRvY3VtZW50Lg0KPg0KPiBDaXBoZXJzdWl0ZSByZWxh dGVkIGluZm9ybWF0aW9uIGluY2x1ZGVzOg0KPiAtIEVuY3J5cHRlZCBDb250ZW50ICh2YXJpYWJs ZSBsZW5ndGgpDQo+IC0gTUFDICh2YXJpYWJsZSBsZW5ndGgpDQo+DQo+IENvbnRlbnQgVHlwZSwg VmVyc2lvbiBhbmQgTGVuZ3RoIGFyZSBEVExTLXNwZWNpZmljIGFzcGVjdHMgdGhhdCBjYW5ub3Qg YmUNCj4gcmVtb3ZlZCB3aXRob3V0IHJlLWRlc2lnbiBvZiB0aGUgcmVjb3JkIGxheWVyLg0KPg0K PiBEYXRhIGJhc2VkIG9uIEZpZ3VyZSA0IG9mDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDgudHh0Lg0KPg0KPiBTaW5jZSB0 aGVyZSBpcyBubyBzZXF1ZW5jZSBudW1iZXIgZGVmaW5lZCBpbiBDT1NFIEkgcHV0IHRoZSBlcG9j aCBhbmQgdGhlDQo+IHNlcXVlbmNlIG51bWJlciB0b2dldGhlciBpbnRvIHRoZSBub25jZSBmaWVs ZC4NCj4NCj4gSGVyZSBpcyB0aGUgY29tbWVudGVkIHZlcnNpb24gb2YgdGhlIENPU0UgbWVzc2Fn ZSBJIGNhbWUgdXAgd2l0aDoNCj4NCj4gWw0KPiAgICAgIDIsIC8vIEVuY3J5cHRlZCBDT1NFIG1l c3NhZ2UNCj4gICAgICB7DQo+ICAgICAgICAxOiAxMCwgLy8gQWxnb3JpdGhtIC0gQUVTLUNDTS0x Ni02NC0xMjgNCj4gICAgICAgIDU6IGgnODlmNTJmYScgLy8gNy1ieXRlIG5vbmNlDQo+ICAgICAg fSwNCj4gICAgICBoJzdiOWRjZmE0MmM0ZTFkMzE4MmM0MDJkYzE4ZWY4YjU2MzdkZTRmYjYyY2Yx ZGQxNTZlYTZlNmUwJywNCj4gICAgICAgLy8gZW5jcnlwdGVkIHBheWxvYWQuDQo+ICAgICAgWw0K PiAgICAgICAgWw0KPiAgICAgICAgICBoJycsDQo+ICAgICAgICAgIHsNCj4gICAgICAgICAgICAx OiAtNiwgLy8gRGlyZWN0IHVzZSBvZiBDRUsNCj4gICAgICAgICAgICA0OiBoJzAxJyAvLyBLZXkg SUQgLSAweDAxDQo+ICAgICAgICAgIH0sDQo+ICAgICAgICAgIGgnJw0KPiAgICAgICAgXQ0KPiAg ICAgIF0NCj4gICAgXQ0KPg0KPiBBY2NvcmRpbmcgdG8gY2Jvci5tZTxodHRwOi8vY2Jvci5tZT4g dGhlIHJlc3VsdGluZyBDT1NFIGVuY29kaW5nIGhhcyA1OSBieXRlcyB3aGVyZWJ5IDI4DQo+IGJ5 dGVzIGFyZSBwdXJlbHkgdXNlZCBmb3IgbWVzc2FnZSBlbmNyeXB0aW9uLiAgVGhpcyBtZWFucyB0 aGF0IHRoZXJlIGlzDQo+IDMxIGJ5dGVzIG92ZXJoZWFkIHdpdGggQ09TRSBjb21wYXJlZCB0byAx MiBieXRlcyBbPSA4IGZvciBFcG9jaCArIFNlcXVlbmNlDQo+IE51bWJlciArIFNlbmRlciBJRCwg MyBieXRlcyBmb3IgQ29udGVudCBUeXBlIGFuZCBWZXJzaW9uIGZpZWxkc10uDQo+DQo+IENpYW8N Cj4gSGFubmVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5k ZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0 aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0 cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --_000_8e663e2255cb42a196b444884e8abd99DB5PR9001MB0167MGDPHGem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBr ZW9oIGRyYWZ0IHdvdWxkIGJlIGFwcGxpY2FibGUgaGVyZSBmb3IgY29tcGFyaXNvbi4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIG92ZXJsYXAgaXMgaW4gc2Vuc2Ugb2YgYWRkaXRpb25hbCBjb2RlIHRvIGVuYWJs ZSBzZWN1cmUgbXVsdGljYXN0IGlmIERUTFMgaXMgYWxyZWFkeSBwcmVzZW50IGZvciB1bmljYXN0 LiBZZXMgYWxlcnRzIGFuZCBoYW5kc2hha2UgZnJvbSB1bmljYXN0IGFyZSBub3QNCiB1c2VkIGlu IHRoZSBtdWx0aWNhc3QgKGJ1dCBEVExTIHVuaWNhc3QgY2FuIGJlIHVzZWQgdG8gZG8gdGhlIGtl eSB1cGRhdGVzIGZvciBtdWx0aWNhc3QpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB5b3UgYXJlIG1pc3Jl YWRpbmcgdGhlDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRMU1BsYWluVGV4dCwgVExTQ29tcHJlc3NlZCwgVExTQ2lwaGVydGV4dC4gVGhleSBhcmUg bm90IHdyYXBwZXJzIGluIHRoZSBzZW5zZSB0aGF0IGVhY2ggb25lIGlzIGVtYmVkZGVkIGluc2lk ZSBhbm90aGVyLiBUaGV5IGFyZSBqdXN0IHN0cnVjdHMgdG8gaW5kaWNhdGUgdGhlIHByZXNlbnQg c3RhdHVzDQogb2YgdGhlIHByb2Nlc3NpbmcsIG9ubHkgdGhlIGxlbmd0aCBhbmQgdGhlIG9wYXF1 ZSBmcmFnbWVudCAmbmJzcDtnZXRzIG1vZGlmaWVkIGF0IGVhY2ggc3RhZ2Ugd2hpbGUgdGhlIGNv bnRlbnQgdHlwZSBhbmQgdmVyc2lvbiBhcmUgY29waWVkIHRvIHRoZSBuZXh0IHN0cnVjdC4gU2Vl IGhvdyBUTFNDb21wcmVzc2VkIGlzIGNvbnN0cnVjdGVkIGZyb20gVExTUGxhaW50ZXh0IGluIDYu Mi4yIGluIFJGQyA1MjQ2IChUTFNDb21wcmVzc2VkLmZyYWdtZW50IGlzDQogdGhlIGNvbXByZXNz ZWQgZm9ybSBvZiBUTFNQbGFpbnRleHQuZnJhZ21lbnQgYW5kIG5vdCBUTFNQbGFpbnRleHQpLiBU aGVyZSBhcmUgbm8gYWRkaXRpb25hbCB3cmFwcy9sYXllcnMgaW5zaWRlIGlmIHlvdSBsb29rIGNs b3NlbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNh bmRlZXA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENPU0UgW21h aWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppbSBTY2hh YWQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMzEsIDIwMTUgMTE6NTkgUE08YnI+ DQo8Yj5Ubzo8L2I+ICdTYW5kZWVwIEt1bWFyJzxicj4NCjxiPkNjOjwvYj4gJ0hhbm5lcyBUc2No b2ZlbmlnJzsgJ2Nvc2UgV0cnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ09TRV0gTXVsdGlj YXN0IFVzZSBDYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZGlkIG5vdCBm aW5kIHRoZSBrZW9oIGRyYWZ0IGJlY2F1c2UgaXQgZXhwaXJlZCBhdCB0aGUgYmVnaW5uaW5nIG9m IEp1bHkuJm5ic3A7Jm5ic3A7IFdoaWNoIGlzIHRoZSBkcmFmdCB0aGF0IEkgc2hvdWxkIGJlIGxv b2tpbmcgYXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGNvdWxkIGVhc2lseSBiZSB3cm9uZyBhYm91dCB0aGUgY29k ZSByZXVzZS4mbmJzcDsmbmJzcDsgT24gdGhlIG90aGVyIGhhbmQgSSBkb27igJl0IGtub3cgd2hh dCB0aGUgbGV2ZWxzIGFyZSB0aGF0IGFyZSBiZWluZyByZS11c2VkIGZyb20gVExTLCBzbyBpdCBj YW4gZWFzaWx5IGJlIHRoYXQNCiBJIGhhdmUgbWlzdW5kZXJzdG9vZCB3aGF0IGlzIGdvaW5nIG9u LiZuYnNwOyBPbiB0aGUgb3RoZXIgaGFuZCwgSSBhbSBub3Qgc2VlaW5nIGEgZ3JlYXQgZGVhbCBv ZiBvdmVybGFwIHdpdGggd2hhdCBJIHRoaW5rIG9mIGFzIERUTFMuJm5ic3A7Jm5ic3A7Jm5ic3A7 IEkgdGhpbmsgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gYmVpbmcgYWJsZSB0byZuYnNw OyByZS11c2Ugc29tZSBzbWFsbCBwaWVjZXMgb2YgYSBEVExTIHN5c3RlbSBhbmQgc2F5aW5nIHRo YXQgaXQgaXMgZWFzaWx5DQogYWRhcHRhYmxlIGZyb20gYSBEVExTIHN5c3RlbS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkRvIHlvdSB1c2UgdGhlIHRocmVlIGxheWVyIHdyYXBwaW5nIG9mIERUTFM6IFRMU1BsYWluVGV4 dCwgVExTQ29tcHJlc3NlZCwgVExTQ2lwaGVydGV4dD8mbmJzcDsgSSBhc3N1bWUgdGhhdCB5b3Ug ZG8gbm90IHVzZSB0aGUgaGFuZHNoYWtpbmcuJm5ic3A7IEkgZG9u4oCZdCB0aGluayB5b3UgaGF2 ZQ0KIGFueSBvZiB0aGUgZmF0YWwgZXJyb3IgY29uZGl0aW9ucy4mbmJzcDsgSSBkb27igJl0IGtu b3cgaWYgdGhpcyBpcyBhIHVuaWRpcmVjdGlvbmFsIGNhc3QgdGhhdCBwZW9wbGUgY2Fubm90IHJh aXNlIGZhdGFsIGFsZXJ0cyBmcm9tLiAmbmJzcDsmbmJzcDtJIGFzc3VtZSB0aGF0IHlvdSBkb27i gJl0IGRvIHRoZSBjaGFuZ2UtY2lwaGVyLCBidXQgdGhhdCBpcyBnb2luZyBhd2F5IGluIDEuMyBh bnl3YXkgc28gaXQgaXMgbm90IGEgYmlnIGRlYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5qaW08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gU2FuZGVlcCBLdW1hciBbPGEgaHJlZj0ibWFpbHRvOmlldGZAc2FuZGVl cC5kZSI+bWFpbHRvOmlldGZAc2FuZGVlcC5kZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBBdWd1c3QgMzEsIDIwMTUgMjoyOCBQTTxicj4NCjxiPlRvOjwvYj4gSmltIFNjaGFhZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2Vs bGFycy5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij5oYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0PC9hPiZndDs7IGNvc2UgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYu b3JnIj5jb3NlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDT1NF XSBNdWx0aWNhc3QgVXNlIENhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SGkgSmltPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WW91IHNlZW0gdG8gYmUg cmVmZXJyaW5nIHRvIGFuIGFsdGVybmF0aXZlIHZlcnNpb24gb2YgdGhlIGRyYWZ0IHRoYW4gSGFu bmVzIHVzZWQuIFRoZSBkcmFmdCBIYW5uZXMgdXNlZCBkcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0 LXNlY3VyaXR5LTA4IHVzZXMgU2VuZGVySUQgdG8gc2VwYXJhdGUgdGhlIG5vbmNlLCB3aGlsZSBk cmFmdC1rdW1hci1kaWNlLW11bHRpY2FzdC1zZWN1cml0eQ0KIGRlcml2ZXMgbmV3IGtleXMgcGVy IHNlbmRlciAoYmFzZWQgb24gYSBzaW5nbGUga2V5IGFuZCBTZW5kZXJJRCkuIHRoZSBjaGFuZ2Ug d2FzIGR1ZSB0byBhIGRpZmZlcmVuY2UgaXMgcHJlZmVyZW5jZSBpbiBteSBjby1hdXRob3IgYnV0 IHNob3VsZCBub3QgY2hhbmdlIHRoZSBvdmVyaGVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5GaW5hbGx5 IEkgZGlzYWdyZWUgb24geW91ciBhc3Nlc3NtZW50IG9uIGNvZGUgcmV1c2UsIGl0IGhhZCBiZWVu IGltcGxlbWVudGVkIHdpdGggbWluaW1hbCBjaGFuZ2VzIG5lZWRlZCB0byBhbiBleGlzdGluZyBJ b1QgRFRMUyBsaWJyYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5yZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNhbmRlZXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IE1vbiwgQXVnIDMxLCAyMDE1IGF0IDEwOjAyIFBNLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJt YWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0 Y2VsbGFycy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGFubmVzLDxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBjaGFyYWN0ZXJpemluZyBkcmFmdC1rdW1h ci1kaWNlLW11bHRpY2FzdC1zZWN1cml0eSBhcyBzb21lIHR5cGUgb2YgRFRMUyBtYXkgYmUgYSBo dWdlIG1pc25vbWVyLiZuYnNwOyBPbiBmaXJzdCByZWFkIGl0IGlzIG5vdCBtYXRjaGluZyBhIGdy ZWF0IGRlYWwgb2Ygd2hhdCBJIHRoaW5rIG9mIGFzIGJlaW5nIFRMUy9EVExTLiZuYnNwOyAmbmJz cDtGb3IgZXhhbXBsZSwgYWxsIG9mIHRoZSByZWNvcmQgbGF5ZXJpbmcgdGhhdCBpcyBwcmVzZW50 IGluIERUTFMNCiBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgaGVyZSwgYW5kIEkgd291bGQgYXNzdW1l IHRoYXQgbm9uZSBvZiB0aGUgc3RhcnRpbmcgaGFuZHNoYWtpbmcgaXMgZ29pbmcgdG8gYmUgcHJl c2VudCBoZXJlLjxicj4NCjxicj4NCkxvb2tpbmcgYXQgdGhlIGZpZ3VyZSAyIGluIHRoYXQgZG9j dW1lbnQgYXBwZWFycyB0byBoYXZlIGFuIG92ZXJoZWFkIG9mIDEzIGJ5dGVzLCBidXQgSSBhbSBu b3Qgc2VlaW5nIHRoZSBzZW5kZXIgSUQgdGhhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgc28gSSBh bSB1bnN1cmUgdGhhdCB5b3VyIGFuYWx5c2lzIG9mIHRoZSBzaXplcyBpcyBnb2luZyB0byBiZSBj b3JyZWN0IGZvciB0aGlzLiZuYnNwOyBJdCBpcyBkZWZpbml0ZWx5IG5vdCB0cnVlIGlmIHRoZQ0K IG11bHRpcGxlIGxheWVyaW5nIG9mIFRMUyBpcyBnb2luZyB0byBiZSB1c2VkLjxicj4NCjxicj4N CkkgYW0gaGF2aW5nIGEgaGFyZCB0aW1lIHdpdGggdGhlIGV4YW1wbGUgeW91IGdhdmUsIEkgcHV0 IGl0IGludG8gPGEgaHJlZj0iaHR0cDovL2Nib3IubWUiIHRhcmdldD0iX2JsYW5rIj4NCmNib3Iu bWU8L2E+IChhZnRlciByZW1vdmluZyBjb21tZW50cykgYW5kIGl0IGdlbmVyYXRlZCBhIHN5bnRh eCBlcnJvci4mbmJzcDsgQWZ0ZXIgZ2VuZXJhdGluZyBpdCBvbiBteSBvd24sIEkgY2FtZSB1cCB3 aXRoOjxicj4NCjxicj4NCls8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOzIsJm5ic3A7IC8vIGVu Y3J5cHRlZCBtZXNzYWdlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtoJ2EyMDEwYTA1NDcwODlm NTJmYTAwMDAwMCcsIC8vJm5ic3A7IFByb3RlY3RlZCBoZWFkZXJzPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IC8vJm5ic3A7IHsxOiAxMCwgLSBhbGdvcml0aG0gQUVTLUNDTS0xNi02 NC0xMjg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Ly8mbmJzcDsgJm5ic3A7NTogaCcwODlmNTJmYTAwMDAwMCcgLSBub25jZSBvZiA3 IGJ5dGVzfTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7eyZuYnNwOyAmbmJzcDsgJm5ic3A7fSwm bmJzcDsgLy8gVW5wcm90ZWN0ZWQgaGVhZGVycyAobm9uZSk8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwO2gnN2I5ZGNmYTQyYzRlMWQzMTgyYzQwMmRjMThlZjhiNTYzN2RlNGZiNjJjZjFkZDE1NmVh NmU2ZTAnLCAvLyBlbmNyeXB0ZWQgbWVzc2FnZSAmIzQzOyBhdXRoZW50aWNhdGlvbiB0YWc8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwO1s8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtb PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2gnJywmbmJzcDsgLy8gUHJv dGVjdGVkIGhlYWRlciAtIG5vbmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7eyAvLyZuYnNwOyBVbnByb3RlY3RlZCBoZWFkZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxOiAtNiwmbmJzcDsgLy8gQWxnb3JpdGhtIGRpcmVjdDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7NDogaCcwMScgLy8g c2VuZGVyIElEPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO30sPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2gnJyAvLyBObyBjaXBoZXIgdGV4dDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO108YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw O108YnI+DQombmJzcDsgJm5ic3A7XTxicj4NCjxicj4NCldoaWNoIG1hcHMgdG8gNTYgYnl0ZXMg d2l0aCBhIDI4IGJ5dGUgbWVzc2FnZSwgdXNpbmcgbXkgYmVzdCBndWVzcyBmcm9tIHdoYXQgeW91 IGFyZSBzYXlpbmcgeW91IGdldCBhIDQyIGJ5dGUgbWVzc2FnZSB3aXRoIHlvdSAmcXVvdDtEVExT JnF1b3Q7IG1lc3NhZ2UuJm5ic3A7IFRoZSBjdXJyZW50IGRpZmZlcmVuY2UgaW4gb3ZlcmhlYWQg dGh1cyBiZWluZyAxNCBieXRlcyByYXRoZXIgdGhhbiB0aGUgMTkgYnl0ZXMgeW91IGhhdmUgYmVs b3cuJm5ic3A7ICZuYnNwO0kgZXhwZWN0IHRoYXQgdGhpcw0KIGRpZmZlcmVuY2Ugd2lsbCBkZWNy ZWFzZSBhcyB0aW1lIGdvZXMgYnkuJm5ic3A7IFdlIGhhdmUgYSBwcm9wb3NhbHMgb24gdGhlIHRh YmxlIHdoaWNoIHdvdWxkIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgQ09TRSBtZXNzYWdlIGZvciBo YW5kbGluZyBvZiBzaW5nbGUgcmVjaXBpZW50IG1lc3NhZ2VzLCBidXQgaXQgaXMgbm90IGNsZWFy IHdoaWNoLCBpZiBhbnksIGFyZSBnb2luZyB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgZG9j dW1lbnQuJm5ic3A7IFBhcnQNCiBvZiB0aGlzIGlzIGEgcXVlc3Rpb24gb2Ygd2hhdCB0aGUgaW1w bGVtZW50YXRpb24gc2l6ZXMgYXJlIGdvaW5nIHRvIGJlLjxicj4NCjxicj4NCkFsdGhvdWdoIHRo ZSBrdW1hciBkb2N1bWVudCBzYXlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIHNpZ25pZmljYW50IGNv ZGUgcmV1c2UgYmV0d2VlbiBpdCBhbmQgRFRMUywgSSBhbSBub3Qgc3VyZSB0aGF0IEkgd291bGQg YWdyZWUgd2l0aCB0aGlzLiZuYnNwOyBJdCBzZWVtcyB0byBiZSB0aGF0IGl0IGlzIGp1c3QgcmV1 c2luZyBzbWFsbCBwb3J0aW9ucyBidXQgaXQgd291bGQgYmUgYSBzaWduaWZpY2FudCByZS13cml0 ZSBhbmQgd291bGQgbmVlZCB0byZuYnNwOyBoYXZlDQogYSBjb3JyZXNwb25kaW5nIGNvbXBsZXRl IHNlY3VyaXR5IHJldmlldy48YnI+DQo8YnI+DQpKaW08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyBGcm9tOiBDT1NFIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9y ZyI+Y29zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2Zl bmlnPGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAxNSAxMjoyMiBBTTxicj4N CiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9h Pjxicj4NCiZndDsgU3ViamVjdDogW0NPU0VdIE11bHRpY2FzdCBVc2UgQ2FzZTxicj4NCiZndDs8 YnI+DQomZ3Q7IEhpIEppbSwgQnJpYW4sIGFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFtIHRy eWluZyB0byBjb21wYXJlIHRoZSB3b3JrIG9uIG11bHRpY2FzdCBzZWN1cml0eSBkb25lIGJ5IFNh bmRlZWQgJmFtcDsgY288YnI+DQomZ3Q7IGFnYWluc3QgYW4gYXBwbGljYXRpb24gbGF5ZXIgc29s dXRpb24gdXNpbmcgQ0JPUi9DT1NFLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBEVExTIG11bHRp Y2FzdCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHJlbGV2YW50IGNvbXBvbmVudHM6PGJyPg0KJmd0 OyAtIEVwb2NoOiAyIEJ5dGU8YnI+DQomZ3Q7IC0gU2VuZGVyIElEOiAxIEJ5dGU8YnI+DQomZ3Q7 IC0gU2VxdWVuY2UgTnVtYmVyOiA1IEJ5dGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgY29tYmlu YXRpb24gb2YgZXBvY2gsIHNlbmRlciBpZCBhbmQgc2VxdWVuY2UgbnVtYmVyIGFyZSB1c2VkIGFz IGEgbm9uY2U8YnI+DQomZ3Q7IGZvciB0aGUgY2lwaGVyIGFuZCB0aGUgdXNlIG9mIHRoZSBzZW5k ZXIgaWQgZW5zdXJlcyB0aGF0IG5vIG1lbWJlciBvZiB0aGUgZ3JvdXA8YnI+DQomZ3Q7IGFjY2lk ZW50YWxseSBzZWxlY3RzIHZhbHVlcyB0aGF0IHdpbGwgY2F1c2UgcmUtdXNlLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoZSAxIGJ5dGUgc2VuZGVyIGlkIGlzIGNob3NlbiBzbWFsbCB0byByZWZsZWN0 IHRoZSBleHBlY3RlZCBzaXplIG9mIGEgZ3JvdXAgaW4gdGhlPGJyPg0KJmd0OyBwcm9mZXNzaW9u YWwgbGlnaHRpbmcgZW52aXJvbm1lbnQsIGFzIGV4cGxhaW5lZCBpbiB0aGUgRFRMUyBtdWx0aWNh c3QgZG9jdW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2lwaGVyc3VpdGUgcmVsYXRlZCBpbmZv cm1hdGlvbiBpbmNsdWRlczo8YnI+DQomZ3Q7IC0gRW5jcnlwdGVkIENvbnRlbnQgKHZhcmlhYmxl IGxlbmd0aCk8YnI+DQomZ3Q7IC0gTUFDICh2YXJpYWJsZSBsZW5ndGgpPGJyPg0KJmd0Ozxicj4N CiZndDsgQ29udGVudCBUeXBlLCBWZXJzaW9uIGFuZCBMZW5ndGggYXJlIERUTFMtc3BlY2lmaWMg YXNwZWN0cyB0aGF0IGNhbm5vdCBiZTxicj4NCiZndDsgcmVtb3ZlZCB3aXRob3V0IHJlLWRlc2ln biBvZiB0aGUgcmVjb3JkIGxheWVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IERhdGEgYmFzZWQgb24g RmlndXJlIDQgb2Y8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDgudHh0IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0 LXNlY3VyaXR5LTA4LnR4dDwvYT4uPGJyPg0KJmd0Ozxicj4NCiZndDsgU2luY2UgdGhlcmUgaXMg bm8gc2VxdWVuY2UgbnVtYmVyIGRlZmluZWQgaW4gQ09TRSBJIHB1dCB0aGUgZXBvY2ggYW5kIHRo ZTxicj4NCiZndDsgc2VxdWVuY2UgbnVtYmVyIHRvZ2V0aGVyIGludG8gdGhlIG5vbmNlIGZpZWxk Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEhlcmUgaXMgdGhlIGNvbW1lbnRlZCB2ZXJzaW9uIG9mIHRo ZSBDT1NFIG1lc3NhZ2UgSSBjYW1lIHVwIHdpdGg6PGJyPg0KJmd0Ozxicj4NCiZndDsgWzxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAyLCAvLyBFbmNyeXB0ZWQgQ09TRSBtZXNzYWdlPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDE6IDEwLCAvLyBBbGdvcml0aG0gLSBBRVMtQ0NNLTE2LTY0LTEyODxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNTogaCc4OWY1MmZhJyAvLyA3LWJ5dGUgbm9u Y2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfSw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgaCc3YjlkY2ZhNDJjNGUxZDMxODJjNDAyZGMxOGVmOGI1NjM3ZGU0ZmI2MmNmMWRk MTU2ZWE2ZTZlMCcsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIGVuY3J5 cHRlZCBwYXlsb2FkLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBbPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgaCcnLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgMTogLTYsIC8vIERpcmVjdCB1c2Ugb2YgQ0VLPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDQ6IGgnMDEnIC8vIEtleSBJRCAtIDB4MDE8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9LDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGgnJzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgXTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBdPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgXTxicj4NCiZndDs8YnI+DQomZ3Q7IEFjY29yZGluZyB0byA8YSBocmVmPSJo dHRwOi8vY2Jvci5tZSIgdGFyZ2V0PSJfYmxhbmsiPmNib3IubWU8L2E+IHRoZSByZXN1bHRpbmcg Q09TRSBlbmNvZGluZyBoYXMgNTkgYnl0ZXMgd2hlcmVieSAyODxicj4NCiZndDsgYnl0ZXMgYXJl IHB1cmVseSB1c2VkIGZvciBtZXNzYWdlIGVuY3J5cHRpb24uJm5ic3A7IFRoaXMgbWVhbnMgdGhh dCB0aGVyZSBpczxicj4NCiZndDsgMzEgYnl0ZXMgb3ZlcmhlYWQgd2l0aCBDT1NFIGNvbXBhcmVk IHRvIDEyIGJ5dGVzIFs9IDggZm9yIEVwb2NoICYjNDM7IFNlcXVlbmNlPGJyPg0KJmd0OyBOdW1i ZXIgJiM0MzsgU2VuZGVyIElELCAzIGJ5dGVzIGZvciBDb250ZW50IFR5cGUgYW5kIFZlcnNpb24g ZmllbGRzXS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNPU0UgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciPkNPU0VAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Nl IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+VGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlh bCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdl IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCiB0aGF0IGFu eSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2lu YWwgbWVzc2FnZS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8e663e2255cb42a196b444884e8abd99DB5PR9001MB0167MGDPHGem_-- From nobody Mon Aug 31 15:36:11 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1A1B6822 for ; Mon, 31 Aug 2015 15:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsMb9sM2nHji for ; Mon, 31 Aug 2015 15:36:08 -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 0774E1B681F for ; Mon, 31 Aug 2015 15:36:07 -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 t7VMa12M026445; Tue, 1 Sep 2015 00:36:01 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n4mb532gmzDKPn; Tue, 1 Sep 2015 00:36:01 +0200 (CEST) Message-ID: <55E4D6CF.6080302@tzi.org> Date: Tue, 01 Sep 2015 00:35:59 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Jim Schaad References: <55E400AC.7090507@gmx.net> <064c01d0e428$047d2700$0d777500$@augustcellars.com> <068701d0e438$3fe18470$bfa48d50$@augustcellars.com> In-Reply-To: <068701d0e438$3fe18470$bfa48d50$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Hannes Tschofenig' , 'Sandeep Kumar' , 'cose WG' Subject: Re: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 22:36:10 -0000 Jim Schaad wrote: > I did not find the keoh draft because it expired at the beginning of > July. Which is the draft that I should be looking at? > Now you got me confused. https://tools.ietf.org/html/draft-keoh-dice-multicast-security-08 expired on January 4, 2015. Are we talking about the same documents? Grüße, Carsten From nobody Mon Aug 31 16:17:30 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919131ACE9C for ; Mon, 31 Aug 2015 16:17:26 -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_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LImf5I0Azm4D for ; Mon, 31 Aug 2015 16:17:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DC31ACE32 for ; Mon, 31 Aug 2015 16:17:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70DC3BE9C; Tue, 1 Sep 2015 00:17:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2FLhV27n57a; Tue, 1 Sep 2015 00:17:19 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 32607BE98; Tue, 1 Sep 2015 00:17:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441063039; bh=OBWynycO9qDVjVTVTd7YE7jVzhTG9IKpNa5Em1Aidpo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=F257C+W2jAizzUiO7SPttLblb23H65Oe4MGxDLkLdomQJY208CQ1Tl2TTcbVDpGO0 jtj58rwjWcAbjiX3NILFmMNl/Ya9XdrlSlyT/HMx6O0k4KxWoDFU8DxdJui8OTchBS iKuZn/neTGxfrYlO6QD6x0lLur3DIcRmFhDel5kA= To: Carsten Bormann , Jim Schaad References: <55E400AC.7090507@gmx.net> <064c01d0e428$047d2700$0d777500$@augustcellars.com> <068701d0e438$3fe18470$bfa48d50$@augustcellars.com> <55E4D6CF.6080302@tzi.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E4E07E.5080201@cs.tcd.ie> Date: Tue, 1 Sep 2015 00:17:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E4D6CF.6080302@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Hannes Tschofenig' , 'Sandeep Kumar' , 'cose WG' Subject: Re: [COSE] Multicast Use Case X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 23:17:28 -0000 On 31/08/15 23:35, Carsten Bormann wrote: > Jim Schaad wrote: >> I did not find the keoh draft because it expired at the beginning of >> July. Which is the draft that I should be looking at? >> > > Now you got me confused. > > https://tools.ietf.org/html/draft-keoh-dice-multicast-security-08 > > expired on January 4, 2015. Are we talking about the same documents? And... the proposal for the dice WG to adopt that functionality (regardless of draft) has been controversial. So I think that means that one cannot directly compare encoding sizes, as we do not know that a DTLS approach to multicast is workable. I'n not saying here that one cannot depend on what's in these drafts, but rather that we might not be doing an apples to apples comparison. S. > > Grüße, Carsten > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >