From James.H.Manger@team.telstra.com Mon Apr 1 03:48:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCEF21F88E8 for ; Mon, 1 Apr 2013 03:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRENh7o15mFv for ; Mon, 1 Apr 2013 03:48:37 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5780C21F88D8 for ; Mon, 1 Apr 2013 03:48:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,385,1363093200"; d="scan'208";a="126900823" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 01 Apr 2013 21:48:34 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7031"; a="123295387" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcdvi.tcif.telstra.com.au with ESMTP; 01 Apr 2013 21:48:34 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 1 Apr 2013 21:48:33 +1100 From: "Manger, James H" To: jose issue tracker , "michael.jones@microsoft.com" , "bcampbell@pingidentity.com" Date: Mon, 1 Apr 2013 21:48:32 +1100 Thread-Topic: [jose] #12: x5c incorrect in JWE Thread-Index: Ac4tjS4kfEUHdy3XT6WQdzexh51OEgBMzs+g Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C06EA61@WSMSG3153V.srv.dir.telstra.com> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> <080.fec3c931ff7caa6172df3c6f437eb638@trac.tools.ietf.org> In-Reply-To: <080.fec3c931ff7caa6172df3c6f437eb638@trac.tools.ietf.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 10:48:38 -0000 PiAjMTI6IHg1YyBpbmNvcnJlY3QgaW4gSldFDQo+IA0KPiANCj4gQ29tbWVudCAoYnkgbWljaGFl bC5qb25lc0BtaWNyb3NvZnQuY29tKToNCj4gDQo+ICBGb3IgZ2VuZXJhbGl0eSwgSSdsbCBub3Rl IHRoYXQgaWYgcGVvcGxlIGJlbGlldmUgdGhhdCAieDVjIiBzaG91bGQgYmUNCj4gcmVtb3ZlZCBm cm9tIEpXRSwgdGhlbiB0aGUgc2FtZSBsb2dpYyBwcm9iYWJseSBzdWdnZXN0cyB0aGF0ICJ4NXUi LA0KPiAiamt1Ig0KPiAgc2hvdWxkIGJlIHJlbW92ZWQsIGFzIGFsbCBhcmUgd2F5cyBvZiBpbmNs dWRpbmcgb3IgcmVmZXJlbmNpbmcgcHVibGljDQo+IGtleSAgdmFsdWVzIGNvcnJlc3BvbmRpbmcg dG8gdGhlIHByaXZhdGUga2V5IHVzZWQgdG8gZW5jcnlwdCB0aGUNCj4gY29udGVudC4gIEFuZCAg YnkgdGhhdCBsb2dpYywgaWYgd2UgZG9uJ3QgbmVlZCBhIHdheSB0byByZWZlcmVuY2Ugb3INCj4g aW5jbHVkZSBwdWJsaWMga2V5ICB2YWx1ZXMgZm9yIEpXRXMsIHRoZW4gdGhlICJ4NXQiIGFuZCBw b3NzaWJseSAia2lkIg0KPiBwYXJhbWV0ZXJzIHdvdWxkIHRoZW4gIGFsc28gYmUgb2YgZHViaW91 cyB2YWx1ZS4gIEF0IGxlYXN0IGJ5IHRoYXQNCj4gcmVhc29uaW5nLCB0aGUgaW5jbHVzaW9uIG9m ICBhbGwgdGhlIGtleSByZWZlcmVuY2UgcGFyYW1ldGVycyB3b3VsZA0KPiBsaWtlbHkgc3RhbmQg b3IgZmFsbCB0b2dldGhlci4NCg0KWWF5ISBEcm9wIHRoZSBsb3QgKCJqa3UiLCAiandrIiwgIng1 dSIsICJ4NXQiLCAieDVjIikgZnJvbSBKV0U7IGtlZXAgImtpZCIuDQoNCg0KU2hvdWxkIHdlIGRl c2NyaWJlIGhvdyB0byBnZXQgYSAia2lkIiB2YWx1ZSBmcm9tIGEgY2VydGlmaWNhdGUgb3IgYSBy YXcgcHVibGljIGtleSAoaW4gY2FzZSBhbiBleHBsaWNpdCAia2lkIiB2YWx1ZSBpcyBub3QgYXZh aWxhYmxlIHRvIGEgSldFIG9yaWdpbmF0b3IpPyBJZiB5b3Ugb25seSBoYXZlIGEgY2VydCB5b3Ug Y2FuIGxvb2sgZm9yIGEgc3ViamVjdEtleUlkZW50aWZpZXIgZXh0ZW5zaW9uIC0tIHRob3VnaCB0 aGF0IGlzIGFuIE9DVEVUIFNUUklORyBzbyBpdCBtYXkgbmVlZCB0byBiZSBiYXNlNjR1cmwtZW5j b2RlZCAod2l0aG91dCBwYWRkaW5nKSB0byBnaXZlIGEgImtpZCIgc3RyaW5nLiBBIHJhdyBwdWJs aWMga2V5IGNvdWxkIGJlIGhhc2hlZCB0byBzeW50aGV0aXNlIGEgImtpZCIgdmFsdWUsIGJ1dCB0 aGVuIHlvdSBuZWVkIGEgY2Fub25pY2FsIGZvcm0gb2YgdGhlIHB1YmxpYyBrZXkgdG8gaGFzaC4N Cg0KLS0NCkphbWVzIE1hbmdlcg0K From James.H.Manger@team.telstra.com Mon Apr 1 04:31:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2E21F88D6 for ; Mon, 1 Apr 2013 04:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.073 X-Spam-Level: * X-Spam-Status: No, score=1.073 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofAPcJr3H+xF for ; Mon, 1 Apr 2013 04:31:28 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4B19C21F8564 for ; Mon, 1 Apr 2013 04:31:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,385,1363093200"; d="scan'208";a="126903806" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 01 Apr 2013 22:31:27 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7031"; a="123298574" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 01 Apr 2013 22:31:27 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Mon, 1 Apr 2013 22:31:26 +1100 From: "Manger, James H" To: jose issue tracker , "michael.jones@microsoft.com" Date: Mon, 1 Apr 2013 22:31:25 +1100 Thread-Topic: [jose] #16: URI identifying a specific key in a JWK set Thread-Index: Ac4tnQgWihpBQ9pHTwau2soUHHbaewBKYBvQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C06EA64@WSMSG3153V.srv.dir.telstra.com> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <073.97f52f55118bcf1f267077e78a7fa163@trac.tools.ietf.org> In-Reply-To: <073.97f52f55118bcf1f267077e78a7fa163@trac.tools.ietf.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 11:31:29 -0000 PiAjMTY6IFVSSSBpZGVudGlmeWluZyBhIHNwZWNpZmljIGtleSBpbiBhIEpXSyBzZXQNCj4gDQo+ IA0KPiBDb21tZW50IChieSBtaWNoYWVsLmpvbmVzQG1pY3Jvc29mdC5jb20pOg0KPiANCj4gIEZp cnN0LCBoYXZpbmcganVzdCBhICJqa3UiIHZhbHVlIGlzIG9mdGVuIHN1ZmZpY2llbnQgdG8gZGV0 ZXJtaW5lIHdoaWNoDQo+ICBrZXkgdG8gdXNlLCBhcyBvdGhlciBwYXJhbWV0ZXJzIGluIHRoZSBK V0sgU2V0IHN1Y2ggYXMgdGhlICJ1c2UiIG9yICJhbGciDQo+ICBwYXJhbWV0ZXJzIG1heSBiZSB1 c2VkIHRvIHVuYW1iaWd1b3VzbHkgZGV0ZXJtaW5lIHdoaWNoIGtleSB0byB1c2UuIFRoZXJlDQo+ ICBtYXkgYWxzbyBiZSBvbmx5IG9uZSBrZXkgaW4gdGhlIHNldC4NCg0KUmVxdWlyaW5nIHJlY2lw aWVudHMgdG8gdHJ5IGEgYnVuY2ggb2YgZXh0cmEgcGFyYW1ldGVycyBhbmQgaGV1cmlzdGljcyBp biB0aGUgaG9wZSBvZiB3aXRsaW5nIGRvd24gYSBzZXQgb2Yga2V5cyB0byB0aGUgc2luZ2xlIHB1 YmxpYyBrZXkgbmVlZGVkIHRvIHByb2Nlc3MgYSBKT1NFIG1lc3NhZ2UgaXMgYSBwb29yICJzb2x1 dGlvbiIgZm9yICJqa3UiIG5vdCBiZWluZyBmaXQtZm9yLXB1cnBvc2UuDQoNClRoZSBvcmlnaW5h dG9yIGtub3dzIHdoaWNoIHNwZWNpZmljIGtleSBpcyByZXF1aXJlZCAoaWUgdGhlIHBhaXIgZm9y IHRoZSBwcml2YXRlIGtleSB0aGUgb3JpZ2luYXRvciB1c2VkKSBzbyB3aHkgYm90aGVyIG9ubHkg dGVsbGluZyB0aGUgcmVjaXBpZW50IHdoaWNoIHNldCBjb250YWlucyB0aGUga2V5LCBpbnN0ZWFk IG9mIHdoaWNoIHNwZWNpZmljIGtleSB0byB1c2U/DQoNCkxldHMganVzdCBtYWtlICJqa3UiIGZp dC1mb3ItcHVycG9zZSAob2YgaWRlbnRpZnlpbmcgdGhlIHB1YmxpYyBrZXkgcmVxdWlyZWQgdG8g cHJvY2VzcyBhIEpPU0UgbWVzc2FnZSkuIA0KDQoNCj4gIFNlY29uZCwgd2UgYWxyZWFkeSBzdXBw b3J0IG1vcmUgdGhhbiBvbmUgbWVhbnMgb2YgZGlzYW1iaWd1YXRpbmcga2V5cw0KPiAgd2l0aGlu IEpXSyBTZXRzLCBpbmNsdWRpbmcgdXNpbmcgdGhlICJrdHkiLCAia2lkIiwgInVzZSIsIGFuZCAi YWxnIiB2YWx1ZXMNCj4gIGFzIGlucHV0cyB0byB0aGlzIGRlY2lzaW9uLg0KDQoia3R5IiAtLSB1 bmxlc3MgdGhlcmUgYXJlIDIgUlNBIGtleXMgaW4gdGhlIHNldA0KInVzZSIgLS0gdW5sZXNzIHRo ZXJlIGFyZSAyIGtleXMgdGhhdCBjYW4gYmUgdXNlZCB0byBzaWduDQoiYWxnIiAtLSB1bmxlc3Mg dGhlcmUgYXJlIDIga2V5cyB0aGF0IHdvcmsgd2l0aCAiUlMyNTYiDQpbUm9sbG92ZXIgYSBrZXkg YW5kICJrdHkiLCAidXNlIiwgYW5kICJhbGciIGFyZSBhbGwgbGlrZWx5IHRvIGJlIHRoZSBzYW1l IGZvciBvbGQgYW5kIG5ldyBrZXlzXQ0KImtpZCIgLS0gd29ya3MsIGJ1dCAxIGZpdC1mb3ItcHVy cG9zZSAiamt1IiBmaWVsZCB3b3VsZCBiZSBtdWNoIGJldHRlciB0aGFuIDIgamt1K2tpZA0KDQo+ ICBBbmQgb25jZSB0aGUgc3BlYyBzYXlzIHRoYXQgb3RoZXIgZmllbGRzIG11c3QNCj4gIGJlIGln bm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QsIEknbSBzdXJlIHRoYXQgcGVvcGxlIHdpbGwgdXNlIG90 aGVyIGtleQ0KPiAgcHJvcGVydGllcyB0aGV5J2xsIGludmVudCBzdWNoIGFzICgiY3VycmVudCI6 IHRydWUpIHRvIGFpZCBpbiB0aGUga2V5DQo+ICBzZWxlY3Rpb24gcHJvY2VzcyBmb3IgdGhlaXIg YXBwbGljYXRpb25zLg0KDQpUaGF0J3MgZ3JlYXQgaWYgaXQgaGVscHMgYW4gb3JpZ2luYXRvciBk aXNjb3ZlciBhIGtleS4gVGhlIHJlY2lwaWVudCBzaG91bGRuJ3QgaGF2ZSB0byB1c2Ugc3VjaCBo ZXVyaXN0aWNzLg0KDQoNCj4gIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSByZXF1ZXN0IG1heSBzZWVt IHNpbXBsZSBvbiB0aGUgZmFjZSBvZiBpdCwgYnV0IGRvaW5nDQo+ICB0aGlzIGluIGEgZ2VuZXJh bCB3YXkgd291bGQgaW52b2x2ZSBtb3JlIHRoYW4ganVzdCB1c2luZyBhICJraWQiIHZhbHVlIGFz DQo+ICBhIGZyYWdtZW50IGlkZW50aWZpZXIgZm9yIGEgImprdSIgdmFsdWUuICBBcyBzdWNoLCB0 aGUgcHJvcG9zYWwgc2VlbXMNCj4gIHVuZGVyc3BlY2lmaWVkIHRvIG1lLg0KDQpUaGUgaXRlbSBp biB0aGUgaXNzdWUgdHJhY2tlciBkZWxpYmVyYXRlbHkgZm9jdXNlcyBvbiB0aGUgaXNzdWUsIHdp dGhvdXQgYmVpbmcgcHJlc2NyaXB0aXZlIGFib3V0IHRoZSBzb2x1dGlvbi4NCg0KDQo+ICBGdXJ0 aGVybW9yZSwgaWYgYWxsIHRoYXQncyBiZWluZyBjb252ZXllZCBpcyBhICJqa3UiIHZhbHVlIGFu ZCBhICJraWQiDQo+ICB2YWx1ZSBwYWlyIC0gd2UgYWxyZWFkeSBoYXZlIGEgc3RyYWlnaHRmb3J3 YXJkIHdheSBvZiBkb2luZyB0aGF0IC0gaW5jbHVkZQ0KPiAgYm90aCBwYXJhbWV0ZXJzIGluIHRo ZSBoZWFkZXIuICBXaGVyZWFzIHJlcXVpcmluZyBpbXBsZW1lbnRhdGlvbnMgdG8NCj4gIHN1cHBv cnQgdHdvIHdheXMgb2YgYWNjZXB0aW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGRvZXNuJ3Qgc2Vl bSBsaWtlIGENCj4gIGdvb2QgY29zdC9iZW5lZml0IHRyYWRlb2ZmLg0KDQpUcnlpbmcgImprdSIg KyAoImt0eSIgb3IgInVzZSIgb3IgImFsZyIgb3IgImtpZCIpIGZlZWxzIGV2ZW4gd29yc2UgdGhh biAidHdvIHdheXMiLg0KDQpEcm9wICJraWQiIGluIHRoaXMgY29udGV4dCAoaWRlbnRpZnlpbmcg dGhlIHB1YmxpYyBrZXkgYSByZWNpcGllbnQgbmVlZHMgdG8gdXNlIHRvIHByb2Nlc3MgYSBKT1NF IG1lc3NhZ2UpIGFuZCBvbmx5IHVzZSAiamt1IiAtLSB0aGF0IGdpdmVzIG9uZSB3YXkuIFRoaXMg YWxzbyBzb2x2ZXMgRGljayBIYXJkdCdzIHBvaW50IHRoYXQgYSAia2lkIiBjYW4gYmUgYW1iaWd1 b3VzIHdpdGhvdXQgYW4gaXNzdWVyICh0aGUgVVJJIGlzIGVmZmVjdGl2ZWx5IHRoZSBpc3N1ZXIp Lg0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From rlb@ipv.sx Mon Apr 1 08:57:23 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86A921F8EBB for ; Mon, 1 Apr 2013 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.782 X-Spam-Level: X-Spam-Status: No, score=0.782 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7J5lropOttg for ; Mon, 1 Apr 2013 08:57:21 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3021F8CDF for ; Mon, 1 Apr 2013 08:57:21 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id ni5so2003171obc.12 for ; Mon, 01 Apr 2013 08:57:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cRxzpGQC7emljZEvRmX9+iAnI7yONeTD3/XgReWe150=; b=EW/dB+Q+EVxGEwJfDEOzwz28P/tXWzVEGtHsvadayUZ5nlHoBprVDWyCC2uvCYa1wf PmfRzavPCz9eZ6UcMl2B6NZCSwGM5x1JzQ7+xPyNhGhqxIBgLi6YiFQmsSgLkp9V+Jd4 DLgkGPnoS9S1c0R/MAUpzpuDmZcKMxJZf1+Yo5r8xl7mxvziq1E2K/RPgo5WMF9yRuUU iJ4iUN4m0FeIHIB0rTlzS0T/bIRmCcpXYZB0OSccbq7BArrxA6On6Za0S3SSA1+GtKVo nBFz4+eaJjOHn0kSCOID7H1XvInbJp287ajytqldDFhmksvQlyrCBV40og5y4XIxTxdY A68Q== MIME-Version: 1.0 X-Received: by 10.60.24.197 with SMTP id w5mr4144414oef.6.1364831840641; Mon, 01 Apr 2013 08:57:20 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Mon, 1 Apr 2013 08:57:20 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: Date: Mon, 1 Apr 2013 11:57:20 -0400 Message-ID: From: Richard Barnes To: Mountie Lee Content-Type: multipart/alternative; boundary=e89a8ff1c30e0a35ee04d94eadfb X-Gm-Message-State: ALoCoQmxWcVtBhnahTIT+OJl+OpoKEd6N2217SVc9uK3VI1F2sISnQo98apidjR+Khd8hmJPA/Fh Cc: jose@ietf.org Subject: Re: [jose] JOSE and RFC4210 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:57:24 -0000 --e89a8ff1c30e0a35ee04d94eadfb Content-Type: text/plain; charset=ISO-8859-1 Hi Mountie, JOSE is a cryptographic container format, like PKCS7 / CMS. So it could be used to encapsulate CMP messages, in the same way that PKCS7 or S/MIME is today. --Richard On Sun, Mar 31, 2013 at 9:19 AM, Mountie Lee wrote: > Hi. > I'm Mountie Lee from Korea. > > recently I'm trying to write draft for Web Certificate API as the part of > W3C WebCrypto WG (http://www.w3.org/2012/webcrypto/) > > RFC4210 is the standard for Certificate Management Protocol > and defines list of response data types in their process. > > for example > RFC4210 CMP defines Certificate Reponse data structure as > http://tools.ietf.org/html/rfc4210#section-5.3.4 > > also it defines the Revocation Response data structure as > http://tools.ietf.org/html/rfc4210#section-5.3.10 > > my question is > > in JOSE Working Group > is there any discussion for JOSE data format for RFC4210 data structures? > > if not, where can I start to discuss for these requirements? > > Korea and in some other countries are using RFC4210 as their base pki > standard. > previously and until to now, binary plugins (like ActiveX) are used to > implement CMP. > > already huge infrastructures (legal, physical and services) are > established and operated over 10 years. > > that is the reason why we have interest for JOSE as the data structure of > RFC4210 CMP. > > best regards > mountie. > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8ff1c30e0a35ee04d94eadfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mountie,

JOSE is a cryptographic container format, li= ke PKCS7 / CMS. =A0So it could be used to encapsulate CMP messages, in the = same way that PKCS7 or S/MIME is today.

--Richard<= /div>



On Sun, Mar 31, 2013= at 9:19 AM, Mountie Lee <mountie@paygate.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi.
I'm Mountie Lee from Korea.

recently I'm trying to write draft for Web Certificate API as th= e part=A0of W3C WebCrypto WG (http://www.w3.org/2012/webcrypto/)

RFC4210 is the standard for Certificate Management Prot= ocol
and defines list of response data types in their process.

for example
RFC4210 CMP defines Certificat= e Reponse data structure as
also it defines the Revocation Response data structure as

my question is

in JOSE Working= Group
is there any discussion for JOSE data format for RFC4210 d= ata structures?

if not, where can I start to discu= ss for these requirements?

Korea and in some other countries are using RFC4210 as = their base pki standard.
previously and=A0until=A0to now, binary = plugins (like ActiveX) are used to implement CMP.

already huge infrastructures (legal, physical and services) are established= and operated over 10 years.

that is the reason wh= y we have interest for JOSE as the data structure of RFC4210 CMP.

best regards
mountie.

--
Mountie Lee<= br>
PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@p= aygate.net

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8ff1c30e0a35ee04d94eadfb-- From odonoghue@isoc.org Mon Apr 1 16:30:36 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E421F86C5 for ; Mon, 1 Apr 2013 16:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDuSZ2PqsgND for ; Mon, 1 Apr 2013 16:30:33 -0700 (PDT) Received: from smtp78.ord1c.emailsrvr.com (smtp78.ord1c.emailsrvr.com [108.166.43.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2D311E80FA for ; Mon, 1 Apr 2013 16:30:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 957E71E8075 for ; Mon, 1 Apr 2013 19:30:25 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 2C1631E810F for ; Mon, 1 Apr 2013 19:30:25 -0400 (EDT) Message-ID: <515A188F.6050908@isoc.org> Date: Mon, 01 Apr 2013 19:30:23 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org References: <5159D931.3060401@isoc.org> In-Reply-To: <5159D931.3060401@isoc.org> X-Forwarded-Message-Id: <5159D931.3060401@isoc.org> Content-Type: multipart/alternative; boundary="------------010604010606060600050307" Subject: [jose] interim F2F agenda creation X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:30:36 -0000 This is a multi-part message in MIME format. --------------010604010606060600050307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, As has been previously announced at http://www.ietf.org/mail-archive/web/jose/current/msg01890.html , we are having an interim JOSE WG meeting 29/30 April in Denver. I hope many of you will be able to attend. Please remember to send an email to the jose chairs to confirm your attendance (jose-chairs@tools.ietf.org). In accordance with IETF process, we need to have a draft agenda posted by 15 April for this meeting. As previously stated, the F2F interim will focus on addressing the open issues in the issue tracker. Please review the current documents and ensure all your issues are documented in the tracker. In addition, please send the chairs a ranked list of issues that you believe need to be dealt with at the interim meeting. After we have looked at the issues and tried to guess how long discussions might take, we will then arrange them into the sessions and solicit people for input on the issues (either presentations or suggested text) as is appropriate. We would like to be able to identify blocks of time devoted to particular issues so that we can solicit expert remote participation. Finally, on a personal note, I will be on vacation from 2-13 April, and I expect to have limited if any connectivity. So my apologies in advance for any delays in responding. Regards, Karen --------------010604010606060600050307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,

As has been previously announced at http://www.ietf.org/mail-archive/web/jose/current/msg01890.html, we are having an interim JOSE WG meeting 29/30 April in Denver.  I hope many of you will be able to attend. Please remember to send an email to the jose chairs to confirm your attendance (jose-chairs@tools.ietf.org).

In accordance with IETF process, we need to have a draft agenda posted by 15 April for this meeting. As previously stated, the F2F interim will focus on addressing the open issues in the issue tracker. Please review the current documents and ensure all your issues are documented in the tracker. In addition, please send the chairs a ranked list of issues that you believe need to be dealt with at the interim meeting. After we have looked at the issues and tried to guess how long discussions might take, we will then arrange them into the sessions and solicit people for input on the issues (either presentations or suggested text) as is appropriate. We would like to be able to identify blocks of time devoted to particular issues so that we can solicit expert remote participation.

Finally, on a personal note, I will be on vacation from 2-13 April, and I expect to have limited if any connectivity. So my apologies in advance for any delays in responding.

Regards,
Karen


--------------010604010606060600050307-- From Vijay.Bharadwaj@microsoft.com Tue Apr 2 01:21:54 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4C21F9881 for ; Tue, 2 Apr 2013 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ama7IbZtDuLY for ; Tue, 2 Apr 2013 01:21:44 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.23]) by ietfa.amsl.com (Postfix) with ESMTP id B8B8021F9864 for ; Tue, 2 Apr 2013 01:21:38 -0700 (PDT) Received: from BY2SR01CA103.namsdf01.sdf.exchangelabs.com (10.255.93.148) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.670.5; Tue, 2 Apr 2013 08:21:32 +0000 Received: from SN2FFOFD002.ffo.gbl (157.55.158.29) by BY2SR01CA103.outlook.office365.com (10.255.93.148) with Microsoft SMTP Server (TLS) id 15.0.670.5 via Frontend Transport; Tue, 2 Apr 2013 08:21:32 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by SN2FFOFD002.mail.o365filtering.com (10.111.201.21) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Tue, 2 Apr 2013 08:21:32 +0000 Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.123.1; Tue, 2 Apr 2013 01:21:31 -0700 Received: from DFM-DB3MBX15-05.exchange.corp.microsoft.com (10.166.18.223) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.3.123.1; Tue, 2 Apr 2013 01:21:30 -0700 Received: from DFM-DB3MBX15-07.exchange.corp.microsoft.com (10.166.18.225) by DFM-DB3MBX15-05.exchange.corp.microsoft.com (10.166.18.223) with Microsoft SMTP Server (TLS) id 15.0.620.25; Tue, 2 Apr 2013 01:21:10 -0700 Received: from DFM-DB3MBX15-07.exchange.corp.microsoft.com ([10.166.18.225]) by DFM-DB3MBX15-07.exchange.corp.microsoft.com ([169.254.11.157]) with mapi id 15.00.0620.020; Tue, 2 Apr 2013 01:21:09 -0700 From: Vijay Bharadwaj To: Richard Barnes , Mike Jones Thread-Topic: [jose] FW: GCM nonce reuse question Thread-Index: AQDc/nSECiQAb+v2IzCf58qtgKDeAZqeRckwgAB2xQCAAA1RAIAGKX2g Date: Tue, 2 Apr 2013 08:21:09 +0000 Message-ID: References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <006701ce2c21$65accf10$31066d30$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436759736A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_c0c86017df354a13946d8c3de6a647ecDFMDB3MBX1507exchangeco_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(52604002)(377454001)(66654001)(189002)(199002)(16406001)(63696002)(51856001)(16236675001)(33646001)(5343635001)(44976002)(79102001)(54316002)(76482001)(1511001)(81342001)(56816002)(54356001)(876001)(53806001)(56776001)(31966008)(5343655001)(4396001)(74502001)(77982001)(66066001)(59766001)(20776003)(80022001)(47446002)(74662001)(15202345002)(49866001)(65816001)(47736001)(46102001)(47976001)(71186001)(512954001)(50986001)(564824001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB608; H:hybrid.exchange.microsoft.com; RD:mail7.exchange.microsoft.com; MX:1; A:1; LANG:en; X-Forefront-PRVS: 08041D247D X-OriginatorOrg: DuplicateDomain-7923a859-03c9-4312-a77c-440aa45aaf52.microsoft.com Cc: Jim Schaad , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] FW: GCM nonce reuse question X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:21:55 -0000 --_000_c0c86017df354a13946d8c3de6a647ecDFMDB3MBX1507exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was reading the JWE draft today for different reasons, and came here to p= oint out exactly this issue. It was not clear to me why there were multiple= headers and integrity values. Also, it seems to me the header in JWE is defined in a way that is suboptim= al for the multiple recipient case. It mixes parameters related to the encr= yption of payload with CMK (of which you only need one) with parameters rel= ated to the encryption of the CMK with the recipient's key (of which you ne= ed one per encrypted key). Why not refactor these to look more like CMS? In= other words: Array of recipients, where each is: {alg: , , } Header: Ciphertext: Integrity_value: Putting the integrity check at the end reduces the amount of buffering in t= he implementation that produces the message. Thoughts? From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Thursday, March 28, 2013 7:54 PM To: Mike Jones Cc: Jim Schaad; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] FW: GCM nonce reuse question [trimmed CFRG, since we're talking about JOSE now] Out of curiosity, what text are you planning to add? As I read David's response, he is saying that GCM is unusable with multiple= recipients, because multiple header values are fed into GCM with the same = nonce. Outlawing GCM is not an acceptable outcome. Instead, we should fix the underlying issue. Namely, we should make the he= ader value the same for all recipients. Or, even better, remove the header= from the AAD field. Imagine a world in which the JOSE header is not input as AAD to GCM (i.e., = it receives no integrity protection). Instead, we provide an actual "AAD f= ield" that contains the value for that field in the AEAD computation: OLD: header.key.iv.ciphertext.mac NEW: header.key.iv.aad.ciphertext.mac That world is simpler to write code for (since you don't have to keep the e= ncoded header around), supports more applications (since you can actually u= se the AAD field), and the problems with GCM do not exist. Let's create th= at world! --Richard On Thu, Mar 28, 2013 at 10:06 PM, Mike Jones > wrote: I'll plan to add text to the GCM section of JWA during the current round of= edits pointing this out. David McGrew was also going to get me some text = about constraints on GCM initialization vector values. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, March 28, 2013 7:02 PM To: jose@ietf.org Subject: [jose] FW: GCM nonce reuse question For those people not on the CFRG list - Jim From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Thursday, March 28, 2013 4:15 AM To: Jim Schaad Cc: cfrg@irtf.org Subject: Re: GCM nonce reuse question Hi Jim, From: Jim Schaad = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption mode in the way that the JOSE group is currently using it. There are known problems with not having a unique set of values for IVs and= Key pairings. Do these problems apply to having a different set of auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#section-5.1.1 but apparently they are not described generally enough. = They should read "plaintext or associated data values". Specifically the current way that GCM mode is being used in JOSE is Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_c0c86017df354a13946d8c3de6a647ecDFMDB3MBX1507exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was reading the JWE dra= ft today for different reasons, and came here to point out exactly this iss= ue. It was not clear to me why there were multiple headers and integrity values.

 <= /p>

Also, it seems to me the = header in JWE is defined in a way that is suboptimal for the multiple recip= ient case. It mixes parameters related to the encryption of payload with CMK (of which you only need one) with parameters related t= o the encryption of the CMK with the recipient’s key (of which you ne= ed one per encrypted key). Why not refactor these to look more like CMS? In= other words:

 <= /p>

Array of recipients, wher= e each is: {alg: <alg>, <recipient identifier such as jwk>, <= ;encrypted CMK>}

Header: <parameters re= lated to compression and CMK encryption, including IV>=

Ciphertext: <encoded c= iphertext>

Integrity_value: <enco= ded authentication tag with recipients and header as AAD>

 <= /p>

Putting the integrity che= ck at the end reduces the amount of buffering in the implementation that pr= oduces the message.

 <= /p>

Thoughts?

 <= /p>

From: jose-b= ounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, March 28, 2013 7:54 PM
To: Mike Jones
Cc: Jim Schaad; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] FW: GCM nonce reuse question

 

[trimmed CFRG, since we're talking about JOSE now]

 

Out of curiosity, what text are you planning to add?=

 

As I read David's response, he is saying that GCM is= unusable with multiple recipients, because multiple header values are fed = into GCM with the same nonce. 

 

Outlawing GCM is not an acceptable outcome.

 

Instead, we should fix the underlying issue.  N= amely, we should make the header value the same for all recipients.  O= r, even better, remove the header from the AAD field.

 

Imagine a world in which the JOSE header is not inpu= t as AAD to GCM (i.e., it receives no integrity protection).  Instead,= we provide an actual "AAD field" that contains the value for tha= t field in the AEAD computation:

 

OLD: header.key.iv.ciphertext.mac

NEW: header.key.iv.aad.ciphertext.mac

 

That world is simpler to write code for (since you d= on't have to keep the encoded header around), supports more applications (s= ince you can actually use the AAD field), and the problems with GCM do not = exist.  Let's create that world!

 

--Richard 

 

 

On Thu, Mar 28, 2013 at 10:06 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

I’ll plan to add text to the G= CM section of JWA during the current round of edits pointing this out. = ; David McGrew was also going to get me some text about constraints on GCM initialization vector values.

 

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

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: jose@ietf.org=
Subject: [jose] FW: GCM nonce reuse question

 

For those people not on the CFRG lis= t –

 

Jim

 

 

From: David McGrew (mcgrew) = [mailto:mcgrew@cisco.= com]
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: cfrg@irtf.org=
Subject: Re: GCM nonce reuse question

 

Hi Jim,

 

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisco.com>
Cc: "cfrg@ir= tf.org" <cfr= g@irtf.org>
Subject: GCM nonce reuse question

 

David,

 

In doing a write up I became worried about a security property of = the GCM encryption mode in the way that the JOSE group is currently using i= t.

 

There are known problems with not having a unique set of values fo= r IVs and Key pairings.  Do these problems apply to having a different= set of auxiliary data as well as the plain text?

 

 

 

Specifically the current way that GCM mode is being used in JOSE i= s

 

Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, no= nce, plain text)

Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, no= nce, plain text)

 

As the key, nonce and plain text are fixed it would produce the sa= me encrypted text value but different authentication tags.

 

 

Can't do that.   Each invoca= tion of the encryption operation needs a distinct nonce, unless all of the = encryption operation inputs are identical.

 

Many thanks for calling this out,= Jim.

 

David

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_c0c86017df354a13946d8c3de6a647ecDFMDB3MBX1507exchangeco_-- From ietf@augustcellars.com Tue Apr 2 08:58:55 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDD921F8BD7 for ; Tue, 2 Apr 2013 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL-6HJt9k9K0 for ; Tue, 2 Apr 2013 08:58:54 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8963E21F8B9C for ; Tue, 2 Apr 2013 08:58:54 -0700 (PDT) Received: from Philemon (unknown [207.55.8.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id D808238F0E; Tue, 2 Apr 2013 08:58:53 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 2 Apr 2013 08:58:18 -0700 Message-ID: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CE2F80.3869F2F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4vue6obQLednUzQFaZUQMA+jFf/g== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:58:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01CE2F80.3869F2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard, There is not yet sufficient detail in this document for me to do a proper evaluation of how things are going to work. Example questions that I have. 1. What headers are required and which can be implicit - for example can the algorithm fields be implicit in the SPI? 2. Are the integrity value computed across the fully populated header or the SPI header? 3. Is there a way to forward a message from person A which knows the SPI values and person B which does not? 4. What is the correct algorithm for determining the JWS vs JWE in the event that all of the algorithms are implicit 5. What happens if you have implicit parameters and explicit parameters and they do not match? 6. Is there a recommended way to determine what the SPI parameters are going to be? Does the application need to pre-parse the message to get the SPI value or is there a recommendation that some type of callback be included 7. Can you make things like the IV be implicit? Thus agree on a starting value and an increment and compute the new IV for each new message 8. If you are requiring that the values be populated by the application - does this require that you have a canonical encoding of how those values are placed into the header for the purposes of the integrity check? Jim ------=_NextPart_000_0054_01CE2F80.3869F2F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,

 

There is not = yet sufficient detail in this document for me to do a proper evaluation = of how things are going to work.  Example questions that I = have.

 

1.       =  What headers are required and which = can  be implicit – for example can the algorithm fields be = implicit in the SPI?

2.       Are = the integrity value computed across the fully populated header or the = SPI header?

3.       Is = there a way to forward a message from person A which knows the SPI = values and person B which does not?

4.       = What is the correct algorithm for determining = the JWS vs JWE in the event that all of the algorithms are = implicit

5.       = What happens if you have implicit parameters and = explicit parameters and they do not match?

6.       Is = there a recommended way to determine what the SPI parameters are going = to be?  Does the application need to pre-parse the message to get = the SPI value or is there a recommendation that some type of callback be = included

7.       Can = you make things like the IV be implicit?  Thus agree on a starting = value and an increment and compute the new IV for each new = message

8.       If = you are requiring that the values be populated by the application = – does this require that you have a canonical encoding of how = those values are placed into the header for the purposes of the = integrity check?

 

Jim

 

------=_NextPart_000_0054_01CE2F80.3869F2F0-- From hannes.tschofenig@gmx.net Tue Apr 2 10:42:05 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1177921F8B90 for ; Tue, 2 Apr 2013 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7cYQIz9l4Sn for ; Tue, 2 Apr 2013 10:42:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3921F8AD5 for ; Tue, 2 Apr 2013 10:42:01 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MJqWY-1UOBgK2M32-001DUg for ; Tue, 02 Apr 2013 19:42:00 +0200 Received: (qmail invoked by alias); 02 Apr 2013 17:42:00 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp024) with SMTP; 02 Apr 2013 19:42:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18g3ZJaZ8kg/cXJYy0Xk9eOvZt9DUV6TN0wHDquNV UyFYvG3+QWawh6 Message-ID: <515B1862.2020204@gmx.net> Date: Tue, 02 Apr 2013 20:41:54 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jim Schaad References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> In-Reply-To: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: hannes.tschofenig@gmx.net, jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:42:05 -0000 I don't understand why you need an additional spi parameter when there is already a kid parameter, which serves the same purpose. Here is the kid parameter in the JWE: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.10 Here is the kid parameter in the JWS: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.7 Ciao Hannes On 04/02/2013 06:58 PM, Jim Schaad wrote: > Richard, > > There is not yet sufficient detail in this document for me to do a > proper evaluation of how things are going to work. Example questions > that I have. > > 1. What headers are required and which can be implicit – for example > can the algorithm fields be implicit in the SPI? > > 2.Are the integrity value computed across the fully populated header or > the SPI header? > > 3.Is there a way to forward a message from person A which knows the SPI > values and person B which does not? > > 4.What is the correct algorithm for determining the JWS vs JWE in the > event that all of the algorithms are implicit > > 5.What happens if you have implicit parameters and explicit parameters > and they do not match? > > 6.Is there a recommended way to determine what the SPI parameters are > going to be? Does the application need to pre-parse the message to get > the SPI value or is there a recommendation that some type of callback be > included > > 7.Can you make things like the IV be implicit? Thus agree on a starting > value and an increment and compute the new IV for each new message > > 8.If you are requiring that the values be populated by the application – > does this require that you have a canonical encoding of how those values > are placed into the header for the purposes of the integrity check? > > Jim > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From rbarnes@bbn.com Tue Apr 2 10:55:36 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A224A21F8CEB; Tue, 2 Apr 2013 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5loGLYFqlEd; Tue, 2 Apr 2013 10:55:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BFE4721F8CE9; Tue, 2 Apr 2013 10:55:35 -0700 (PDT) Received: from ros-dhcp192-1-51-16.bbn.com ([192.1.51.16]:49983) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UN5Qb-000PYb-Bi; Tue, 02 Apr 2013 13:55:25 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Richard Barnes In-Reply-To: <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> Date: Tue, 2 Apr 2013 13:55:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com> <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com> <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: "David McGrew \(mcgrew\)" , cfrg@irtf.org, "jose@ietf.org" , Jim Schaad Subject: Re: [jose] [Cfrg] GCM nonce reuse question X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:55:36 -0000 [re-added JOSE, since we're talking design now] On Apr 2, 2013, at 11:59 AM, John Bradley wrote: > Jim, >=20 > I don't think Mike was proposing that as a solution, but rather an = attempt to characterize the issue. >=20 > Yes changing the nonce per recipient would cause the cypher text = produced by GCM to change per recipient and need to be repeated, making = it an array of JWE effectively, and not really anyones idea of = encrypting to multiple recipients. >=20 > In a later email I asked David if we have the same or similar issue = with his AES-CBC+HMAC.=20 >=20 > Perhaps and I think it is too early to go there, perhaps not all = encryption algorithms are equally well suited to using with multiple = recipients. This is the wrong conclusion. GCM is suited just fine to multiple = recipients, as it's use with CMS (AuthEnvelopedData) shows.=20 The problem here is JWE, specifically the fact that the header (with = per-recipient data) is covered by the integrity check. If you remove = the per-recipient data from the integrity check, then this problem goes = away. In that case, there is only one invocation of GCM (not one per = recipient), so there's no problem. So the choice that JOSE faces is from the following options: Option 0. Outlaw GCM for multiple recipients. COST: GCM Option 1. Keep per-recipient info under integrity check, and require a = fresh nonce for each recipient COST: Removes all savings in the multiple recipient case=20 BENEFIT: Doesn't break backward compatibility with current, = single-recipient JWE Option 2. Remove per-recipient info from integrity check COST: Breaks backward compatibility with current, single-recipient JWE BENEFIT: Increases savings in multiple-recipient case (since no = per-recipient integrity check value) Option 0 is clearly not acceptable. So basically, this is a choice = about how much we want to let deployed code keep us from sensible = architecture. To me, the choice is clear. Changing code is minor, short-term pain. = Getting architecture wrong is major, long-term pain. Let's do option = (2). --Richard >=20 > John B. >=20 > On 2013-04-02, at 12:48 PM, "Jim Schaad" = wrote: >=20 >> Mike, >> =20 >> I will note that this is not going to be considered an acceptable = solution for the JOSE group. You don=92t really want to increase the = size of the message by n*base64 encoding where in is the number of = recipients. >> =20 >> Jim >> =20 >> =20 >> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >> Sent: Monday, April 01, 2013 5:55 PM >> To: David McGrew (mcgrew); Jim Schaad >> Cc: cfrg@irtf.org; John Bradley >> Subject: RE: GCM nonce reuse question >> =20 >> Hi David, >> =20 >> In reading this thread and = http://tools.ietf.org/html/draft-mcgrew-iv-gen-02, I believe that it=92s = OK, however if the usage is: >> =20 >> (Recipient #1 ciphertext, Recipient #1 authentication tag) =3D = GCM(Key, Recipient #1 data, nonce #1, plain text) >> (Recipient #2 ciphertext, Recipient #2 authentication tag) =3D = GCM(Key, Recipient #2 data, nonce #2, plain text) >> =20 >> where nonce #1 and nonce #2 are guaranteed to be distinct? Am I = reading things correctly in that regard? >> =20 >> = Thanks, >> -- = Mike >> =20 >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf = Of David McGrew (mcgrew) >> Sent: Thursday, March 28, 2013 4:15 AM >> To: Jim Schaad >> Cc: cfrg@irtf.org >> Subject: Re: [Cfrg] GCM nonce reuse question >> =20 >> Hi Jim, >> =20 >> From: Jim Schaad >> Date: Wednesday, March 27, 2013 6:43 PM >> To: David McGrew >> Cc: "cfrg@irtf.org" >> Subject: GCM nonce reuse question >> =20 >> David, >> =20 >> In doing a write up I became worried about a security property of the = GCM encryption mode in the way that the JOSE group is currently using = it. >> =20 >> There are known problems with not having a unique set of values for = IVs and Key pairings. Do these problems apply to having a different set = of auxiliary data as well as the plain text? >> =20 >> =20 >> Yes. The security issues are summarized in = http://tools.ietf.org/html/rfc5116#section-5.1.1 but apparently they = are not described generally enough. They should read "plaintext or = associated data values". >> =20 >> Specifically the current way that GCM mode is being used in JOSE is >> =20 >> Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, = nonce, plain text) >> Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, = nonce, plain text) >> =20 >> As the key, nonce and plain text are fixed it would produce the same = encrypted text value but different authentication tags. >> =20 >> =20 >> Can't do that. Each invocation of the encryption operation needs a = distinct nonce, unless all of the encryption operation inputs are = identical. >> =20 >> Many thanks for calling this out, Jim. >> =20 >> David >> =20 >> Jim >> =20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From rlb@ipv.sx Tue Apr 2 11:00:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFFE21F8C83 for ; Tue, 2 Apr 2013 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.127 X-Spam-Level: X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp5aTkh+4oaZ for ; Tue, 2 Apr 2013 11:00:03 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBA821F8C74 for ; Tue, 2 Apr 2013 11:00:03 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so671661oag.3 for ; Tue, 02 Apr 2013 11:00:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wQaKJUiJLOXktx0cNA6d6P2wfUYur5czIxDxk/jtPOQ=; b=VR3srOmLA5f4APO+VHlHuHQno7PBDud78UTuT7caRN41WlCWGziY6AstkZTwzFJEqe tguCPwuh0rU4KuPZN8sKShAZ6zbJGrMm50aPXFaK+qklh8CKSBJiCfIPXcv57PVAzLfr KtUkPIP4RawnqqAJTg2qOyIvTwz64E/3BmKQ+Fkry5pP1fhmCtj2gVjBM9hB74vLrZl1 hBAb3u86IJ8E3WYdI5AWDmHZ1JFDdZO0D1DkNNlATDypF9CCb+uRMkTHZPYZYpX49RPf ss/MJ85UQXwQ37JCPhff5aeOS/TFkjCARTf8kOwUmRG1W4B51PDF9Nw3VFRPjGfR4N/Y 8cVw== MIME-Version: 1.0 X-Received: by 10.182.217.10 with SMTP id ou10mr5804655obc.30.1364925602675; Tue, 02 Apr 2013 11:00:02 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Tue, 2 Apr 2013 11:00:02 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <515B1862.2020204@gmx.net> References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> Date: Tue, 2 Apr 2013 14:00:02 -0400 Message-ID: From: Richard Barnes To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=f46d0444709db19fe304d964813a X-Gm-Message-State: ALoCoQl1OgWWjGF+jbkZYhl8qJsRF1dqosF2rZXS0YtXeQZaDsMCNChvrWdCFDSTxG4liQgJAsOT Cc: Jim Schaad , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:00:05 -0000 --f46d0444709db19fe304d964813a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "kid" identifies a key. "spi" identifies anything/everything. Think of it this way: "spi" --> { "alg", "enc", "zip", "kid", ... } On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig wrote: > I don't understand why you need an additional spi parameter when there is > already a kid parameter, which serves the same purpose. > > Here is the kid parameter in the JWE: > http://tools.ietf.org/html/**draft-ietf-jose-json-web-** > encryption-08#section-4.1.10 > > Here is the kid parameter in the JWS: > http://tools.ietf.org/html/**draft-ietf-jose-json-web-** > signature-08#section-4.1.7 > > Ciao > Hannes > > > On 04/02/2013 06:58 PM, Jim Schaad wrote: > >> Richard, >> >> There is not yet sufficient detail in this document for me to do a >> proper evaluation of how things are going to work. Example questions >> that I have. >> >> 1. What headers are required and which can be implicit =96 for example >> can the algorithm fields be implicit in the SPI? >> >> 2.Are the integrity value computed across the fully populated header or >> the SPI header? >> >> 3.Is there a way to forward a message from person A which knows the SPI >> >> values and person B which does not? >> >> 4.What is the correct algorithm for determining the JWS vs JWE in the >> >> event that all of the algorithms are implicit >> >> 5.What happens if you have implicit parameters and explicit parameters >> >> and they do not match? >> >> 6.Is there a recommended way to determine what the SPI parameters are >> >> going to be? Does the application need to pre-parse the message to get >> the SPI value or is there a recommendation that some type of callback be >> included >> >> 7.Can you make things like the IV be implicit? Thus agree on a starting >> >> value and an increment and compute the new IV for each new message >> >> 8.If you are requiring that the values be populated by the application = =96 >> >> does this require that you have a canonical encoding of how those values >> are placed into the header for the purposes of the integrity check? >> >> Jim >> >> >> >> ______________________________**_________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/**listinfo/jose >> >> > ______________________________**_________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/**listinfo/jose > --f46d0444709db19fe304d964813a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "kid" identifies a key. =A0"spi" identifies anything/ev= erything.

Think of it this way:
"spi" --> { "a= lg", "enc", "zip", "kid", ... }=A0

On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> wrote:
I don't understand why you need an additional spi parameter when there = is already a kid parameter, which serves the same purpose.

Here is the kid parameter in the JWE:
http://tools.ietf.org/html/draft= -ietf-jose-json-web-encryption-08#section-4.1.10

Here is the kid parameter in the JWS:
http://tools.ietf.org/html/draft-i= etf-jose-json-web-signature-08#section-4.1.7

Ciao
Hannes


On 04/02/2013 06:58 PM, Jim Schaad wrote:
Richard,

There is not yet sufficient detail in this document for me to do a
proper evaluation of how things are going to work. =A0Example questions
that I have.

1. What headers are required and which can =A0be implicit =96 for example can the algorithm fields be implicit in the SPI?

2.Are the integrity value computed across the fully populated header or
the SPI header?

3.Is there a way to forward a message from person A which knows the SPI
values and person B which does not?

4.What is the correct algorithm for determining the JWS vs JWE in the

event that all of the algorithms are implicit

5.What happens if you have implicit parameters and explicit parameters

and they do not match?

6.Is there a recommended way to determine what the SPI parameters are

going to be? =A0Does the application need to pre-parse the message to get the SPI value or is there a recommendation that some type of callback be included

7.Can you make things like the IV be implicit? =A0Thus agree on a starting<= div class=3D"im">
value and an increment and compute the new IV for each new message

8.If you are requiring that the values be populated by the application =96<= div class=3D"im">
does this require that you have a canonical encoding of how those values are placed into the header for the purposes of the integrity check?

Jim



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d0444709db19fe304d964813a-- From hannes.tschofenig@gmx.net Tue Apr 2 11:08:58 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9F521F8CC9 for ; Tue, 2 Apr 2013 11:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.213 X-Spam-Level: X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mXb0tRZPSAH for ; Tue, 2 Apr 2013 11:08:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 16AF821F8B19 for ; Tue, 2 Apr 2013 11:08:56 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LmQuq-1Uvs9t46R0-00ZuEY for ; Tue, 02 Apr 2013 20:08:55 +0200 Received: (qmail invoked by alias); 02 Apr 2013 18:08:55 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp020) with SMTP; 02 Apr 2013 20:08:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19aDiJ7QkNall8N1vlM8plRwcMvxIJauKZoOxao4c xpali/N1UMF77m Message-ID: <515B1EB1.3090300@gmx.net> Date: Tue, 02 Apr 2013 21:08:49 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Barnes References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Jim Schaad , Hannes Tschofenig , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:08:58 -0000 "kid" vs. "spi" - both are just identifiers that reference something. Only the context gives them a meaning. There is no need to define another parameter. On 04/02/2013 09:00 PM, Richard Barnes wrote: > "kid" identifies a key. "spi" identifies anything/everything. > > Think of it this way: > "spi" --> { "alg", "enc", "zip", "kid", ... } > > > On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig > > wrote: > > I don't understand why you need an additional spi parameter when > there is already a kid parameter, which serves the same purpose. > > Here is the kid parameter in the JWE: > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-08#section-4.1.10 > > > Here is the kid parameter in the JWS: > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__signature-08#section-4.1.7 > > > Ciao > Hannes > > > On 04/02/2013 06:58 PM, Jim Schaad wrote: > > Richard, > > There is not yet sufficient detail in this document for me to do a > proper evaluation of how things are going to work. Example > questions > that I have. > > 1. What headers are required and which can be implicit – for > example > can the algorithm fields be implicit in the SPI? > > 2.Are the integrity value computed across the fully populated > header or > the SPI header? > > 3.Is there a way to forward a message from person A which knows > the SPI > > values and person B which does not? > > 4.What is the correct algorithm for determining the JWS vs JWE > in the > > event that all of the algorithms are implicit > > 5.What happens if you have implicit parameters and explicit > parameters > > and they do not match? > > 6.Is there a recommended way to determine what the SPI > parameters are > > going to be? Does the application need to pre-parse the message > to get > the SPI value or is there a recommendation that some type of > callback be > included > > 7.Can you make things like the IV be implicit? Thus agree on a > starting > > value and an increment and compute the new IV for each new message > > 8.If you are requiring that the values be populated by the > application – > > does this require that you have a canonical encoding of how > those values > are placed into the header for the purposes of the integrity check? > > Jim > > > > _________________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/__listinfo/jose > > > > _________________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/__listinfo/jose > > > From rlb@ipv.sx Tue Apr 2 11:15:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3AD21F8C10 for ; Tue, 2 Apr 2013 11:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFRQ1mFjRbBE for ; Tue, 2 Apr 2013 11:15:50 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 097CD21F8A09 for ; Tue, 2 Apr 2013 11:15:49 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id l10so682394oag.16 for ; Tue, 02 Apr 2013 11:15:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XS9n5knoUeCSOztaGB/q6LRXZJfE4/cEjnzk4ZzHPZ0=; b=dQ6dkPxNgRcQ4L4Yysr2SVwEpsKV0gQvarb+iuaH2iXCqnSweoXdyDeSIZxm3OK53T Orlz1So9uDL5iMO62Mna1BYvLx48lHdx4k95fjEZOaeoJYoWcweSFfqhagmH9fMlDlRN iLIdO666vbnRVY7jVIc8CgwiPdjQ9pHGzhzB2wumjAwpmX0LU1Fmx6QfEJdyE2ThS8rr rZle9RBIReGMH5jeJKLtSqEACncY2QPM7yBo8WUUrzwZwNgHKYB1pAwHGZTKJKxURCvf g+h6vTZYS+zcBQ/Pk6s4P8bpL5rD1Bcogre8oilXw4GJr7BhwlQQ18EuJBRrOYVWfEDm CAeQ== MIME-Version: 1.0 X-Received: by 10.60.24.197 with SMTP id w5mr5846982oef.6.1364926549563; Tue, 02 Apr 2013 11:15:49 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Tue, 2 Apr 2013 11:15:49 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> Date: Tue, 2 Apr 2013 14:15:49 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=e89a8ff1c30e21f86504d964ba0b X-Gm-Message-State: ALoCoQnkr8p2O5zX+U54M47+l4l7MBzEgDA0+4YasZJlf5OvTTUDbivWSrKyGFTVrD/XsYOc1t0h Cc: jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:15:51 -0000 --e89a8ff1c30e21f86504d964ba0b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > 1. ** What headers are required and which can be implicit =96 for > example can the algorithm fields be implicit in the SPI? > If "spi" is present, then everything else is optional. > ** > > **2. **Are the integrity value computed across the fully populated > header or the SPI header? > I would suggest using the SPI header, just because it's simpler, but it doesn't really matter. If you trust the out-of-band process, then the two have equivalent security properties. I don't really care, since we shouldn't be computing integrity values over the header anyway (ISSUE-4). > **** > > **3. **Is there a way to forward a message from person A which > knows the SPI values and person B which does not? > I assume by this you mean 1. C -> A -> B, where C and A share an SPI, and B does not. 2. A does not have to do any cryptographic computations In this case, the answer is "No". The answer would be "Yes" if there were no header integrity check -- A could simply fill in the pre-negotiated parameters. But the fact that the header is integrity-protected means that A cannot do this, so the "spi" remains in place. **** > > **4. **What is the correct algorithm for determining the JWS vs JWE > in the event that all of the algorithms are implicit**** > > ** > Unless you know the SPI, you cannot make that distinction. But you can't reliably distinguish JWS from JWE right now anyway. > 5. **What happens if you have implicit parameters and explicit > parameters and they do not match? > We should specify this, but I don't have a strong feeling for which option we should choose: 1. SPI wins; b/c more trusted 2. Explicit wins; use SPI as default; override when necessary 3. Throw an error; malformed object > **** > > **6. **Is there a recommended way to determine what the SPI > parameters are going to be? Does the application need to pre-parse the > message to get the SPI value or is there a recommendation that some type = of > callback be included > I would expect an API of a JOSE library supporting SPI to provide an interface where an app could specify bindings between an SPI and a set of parameters. That way, the pre-negotiation protocol could use that interface to configure the JOSE library, and the JOSE-using application could just use the normal JOSE interface to process objects. > **** > > **7. **Can you make things like the IV be implicit? Thus agree on > a starting value and an increment and compute the new IV for each new > message > That would be up to the pre-negotiation mechanism. In general, this doesn't seem like a good idea; you could think of secure ways to do it, but it might be fragile. > **** > > **8. **If you are requiring that the values be populated by the > application =96 does this require that you have a canonical encoding of h= ow > those values are placed into the header for the purposes of the integrity > check? > This sounds like a good reason to do the integrity check over the SPI header. --Richard > **** > > ** ** > > Jim**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8ff1c30e21f86504d964ba0b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
1.=A0=A0=A0=A0=A0=A0 =A0What heade= rs are required and which can=A0 be implicit =96 for example can the algori= thm fields be implicit in the SPI?

If "spi" is present, then = everything else is optional. =A0
=A0

= 2.=A0=A0=A0=A0= =A0=A0 Are the integrity value computed across the ful= ly populated header or the SPI header?

I would suggest using the SPI header, just because = it's simpler, but it doesn't really matter. =A0If you trust the out= -of-band process, then the two have equivalent security properties. =A0I do= n't really care, since we shouldn't be computing integrity values o= ver the header anyway (ISSUE-4). =A0
=A0

3.=A0=A0=A0=A0=A0=A0 Is there a way to forward a message from person A which knows the SPI = values and person B which does not?

I assume by this you mean
1. C -> A -&= gt; B, where C and A share an SPI, and B does not.
2. A does not = have to do any cryptographic computations
=A0
In this c= ase, the answer is "No". =A0The answer would be "Yes" i= f there were no header integrity check -- A could simply fill in the pre-ne= gotiated parameters. =A0But the fact that the header is integrity-protected= means that A cannot do this, so the "spi" remains in place.


4= .=A0=A0=A0=A0=A0=A0 = What is the correct algorithm for determining the JWS = vs JWE in the event that all of the algorithms are implicit

Unless you know the SPI,= you cannot make that distinction. =A0But you can't reliably distinguis= h JWS from JWE right now anyway.
=A0

5.=A0=A0=A0=A0=A0=A0 What happens if you have implicit parameters and explicit paramete= rs and they do not match?

We should specify this, but I don't have a stro= ng feeling for which option we should choose:
1. SPI wins; b/c mo= re trusted
2. Explicit wins; use SPI as default; override when ne= cessary
3. Throw an error; malformed object
=A0

6.= =A0=A0=A0=A0=A0=A0 Is there a recommended way to deter= mine what the SPI parameters are going to be?=A0 Does the application need = to pre-parse the message to get the SPI value or is there a recommendation = that some type of callback be included

I would expect an API of a JOSE library supporting = SPI to provide an interface where an app could specify bindings between an = SPI and a set of parameters. =A0That way, the pre-negotiation protocol coul= d use that interface to configure the JOSE library, and the JOSE-using appl= ication could just use the normal JOSE interface to process objects.
=A0

7.=A0=A0=A0=A0=A0=A0 Can you make things like the IV be implicit?=A0 Thus agree on a starti= ng value and an increment and compute the new IV for each new message

That would be up to the pre-negotiation mechanism. = =A0In general, this doesn't seem like a good idea; you could think of s= ecure ways to do it, but it might be fragile.
=A0

= 8.=A0= =A0=A0=A0=A0=A0 If you are requiring that the values b= e populated by the application =96 does this require that you have a canoni= cal encoding of how those values are placed into the header for the purpose= s of the integrity check?

This sounds like a good reason to do the integrity = check over the SPI header.


--Richar= d


=A0

=A0

<= p class=3D"MsoNormal"> Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8ff1c30e21f86504d964ba0b-- From rlb@ipv.sx Tue Apr 2 11:17:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3D21F8CA5 for ; Tue, 2 Apr 2013 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBc2V46sFSDe for ; Tue, 2 Apr 2013 11:17:08 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 250F921F8C78 for ; Tue, 2 Apr 2013 11:17:08 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so630896obc.35 for ; Tue, 02 Apr 2013 11:17:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=e2+baFoAYETOe8gsTrZuIKFIIXowjYzTZSzqLf64o4A=; b=AyBapDlnOxtDvwv0c8gHJSRpDvwIS2ocYb850Cun44XLUdctXEYQ8nQXTYey6nfcgU r4BhVLf5wM3+6BqGXZiG2FMEVwqL41vwjM3YnxMgUl5MexmS9HntQGsuZCSmt+LhRhPm QpdYol3VdbWV61dapBR24fH7fYhIRHhcpfDra9shxG0o+/1pzAi8mTXOXYmA1jY2pdKT jpmjdJ1tJS5TwIFXkmacdlwuotckfzAN8HpqYbCxJ5xdcIOmPX8Ml+ecwtsIN/dcYPFe nkirEEAgdETZKEGWR7WlDzNt81zuPt63fF4IQ5ppWjhVGpXuSput8eb7bBJUC0620J9G pkhQ== MIME-Version: 1.0 X-Received: by 10.60.14.104 with SMTP id o8mr5909729oec.127.1364926627652; Tue, 02 Apr 2013 11:17:07 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Tue, 2 Apr 2013 11:17:07 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <515B1EB1.3090300@gmx.net> References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> <515B1EB1.3090300@gmx.net> Date: Tue, 2 Apr 2013 14:17:07 -0400 Message-ID: From: Richard Barnes To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=e89a8fb1ef16c99dd004d964be18 X-Gm-Message-State: ALoCoQmhBBNIx2Sc7r/eruOZ4hcoqwg8k6u0ZLM6dkmOn217tVloQ8gkz0rFnzVrSiNSCtIMeHl+ Cc: Jim Schaad , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:17:09 -0000 --e89a8fb1ef16c99dd004d964be18 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You would be overloading "kid", since it would mean different things depending on what else is present. It's not even clear to me how a recipient would be able to decide which meaning to use. On Tue, Apr 2, 2013 at 2:08 PM, Hannes Tschofenig wrote: > "kid" vs. "spi" - both are just identifiers that reference something. > Only the context gives them a meaning. > > There is no need to define another parameter. > > > On 04/02/2013 09:00 PM, Richard Barnes wrote: > >> "kid" identifies a key. "spi" identifies anything/everything. >> >> Think of it this way: >> "spi" --> { "alg", "enc", "zip", "kid", ... } >> >> >> On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig >> >> >> wrote: >> >> I don't understand why you need an additional spi parameter when >> there is already a kid parameter, which serves the same purpose. >> >> Here is the kid parameter in the JWE: >> http://tools.ietf.org/html/__**draft-ietf-jose-json-web-__** >> encryption-08#section-4.1.10 >> >> > encryption-08#section-4.1.10 >> > >> >> Here is the kid parameter in the JWS: >> http://tools.ietf.org/html/__**draft-ietf-jose-json-web-__** >> signature-08#section-4.1.7 >> >> > signature-08#section-4.1.7 >> > >> >> Ciao >> Hannes >> >> >> On 04/02/2013 06:58 PM, Jim Schaad wrote: >> >> Richard, >> >> There is not yet sufficient detail in this document for me to do= a >> proper evaluation of how things are going to work. Example >> questions >> that I have. >> >> 1. What headers are required and which can be implicit =96 for >> example >> can the algorithm fields be implicit in the SPI? >> >> 2.Are the integrity value computed across the fully populated >> header or >> the SPI header? >> >> 3.Is there a way to forward a message from person A which knows >> the SPI >> >> values and person B which does not? >> >> 4.What is the correct algorithm for determining the JWS vs JWE >> in the >> >> event that all of the algorithms are implicit >> >> 5.What happens if you have implicit parameters and explicit >> parameters >> >> and they do not match? >> >> 6.Is there a recommended way to determine what the SPI >> parameters are >> >> going to be? Does the application need to pre-parse the message >> to get >> the SPI value or is there a recommendation that some type of >> callback be >> included >> >> 7.Can you make things like the IV be implicit? Thus agree on a >> starting >> >> value and an increment and compute the new IV for each new messa= ge >> >> 8.If you are requiring that the values be populated by the >> application =96 >> >> does this require that you have a canonical encoding of how >> those values >> are placed into the header for the purposes of the integrity >> check? >> >> Jim >> >> >> >> ______________________________**___________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/jose >> >> > >> >> >> ______________________________**___________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/jose >> >> > >> >> >> > --e89a8fb1ef16c99dd004d964be18 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You would be overloading "kid", since it would mean different thi= ngs depending on what else is present. =A0It's not even clear to me how= a recipient would be able to decide which meaning to use.



On Tue, Apr 2, 2013 at 2:08 PM, Han= nes Tschofenig <hannes.tschofenig@gmx.net> wrote:
"kid" vs. "spi" - both are just identifiers that refere= nce something.
Only the context gives them a meaning.

There is no need to define another parameter.


On 04/02/2013 09:00 PM, Richard Barnes wrote:
"kid" identifies a key. =A0"spi" identifies anything/ev= erything.

Think of it this way:
"spi" --> { "alg", "enc", "zip",= "kid", ... }


On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
=A0 =A0 I don't understand why you need an additional spi parameter whe= n
=A0 =A0 there is already a kid parameter, which serves the same purpose.
=A0 =A0 Here is the kid parameter in the JWE:
=A0 =A0 http://tools.ietf.org/html/= __draft-ietf-jose-json-web-__encryption-08#section-4.1.10=

=A0 =A0 <http://tools.ietf.org/html/= draft-ietf-jose-json-web-encryption-08#section-4.1.10>=

=A0 =A0 Here is the kid parameter in the JWS:
=A0 =A0 http://tools.ietf.org/html/__= draft-ietf-jose-json-web-__signature-08#section-4.1.7

=A0 =A0 <http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.7>

=A0 =A0 Ciao
=A0 =A0 Hannes


=A0 =A0 On 04/02/2013 06:58 PM, Jim Schaad wrote:

=A0 =A0 =A0 =A0 Richard,

=A0 =A0 =A0 =A0 There is not yet sufficient detail in this document for me = to do a
=A0 =A0 =A0 =A0 proper evaluation of how things are going to work. =A0Examp= le
=A0 =A0 =A0 =A0 questions
=A0 =A0 =A0 =A0 that I have.

=A0 =A0 =A0 =A0 1. What headers are required and which can =A0be implicit = =96 for
=A0 =A0 =A0 =A0 example
=A0 =A0 =A0 =A0 can the algorithm fields be implicit in the SPI?

=A0 =A0 =A0 =A0 2.Are the integrity value computed across the fully populat= ed
=A0 =A0 =A0 =A0 header or
=A0 =A0 =A0 =A0 the SPI header?

=A0 =A0 =A0 =A0 3.Is there a way to forward a message from person A which k= nows
=A0 =A0 =A0 =A0 the SPI

=A0 =A0 =A0 =A0 values and person B which does not?

=A0 =A0 =A0 =A0 4.What is the correct algorithm for determining the JWS vs = JWE
=A0 =A0 =A0 =A0 in the

=A0 =A0 =A0 =A0 event that all of the algorithms are implicit

=A0 =A0 =A0 =A0 5.What happens if you have implicit parameters and explicit=
=A0 =A0 =A0 =A0 parameters

=A0 =A0 =A0 =A0 and they do not match?

=A0 =A0 =A0 =A0 6.Is there a recommended way to determine what the SPI
=A0 =A0 =A0 =A0 parameters are

=A0 =A0 =A0 =A0 going to be? =A0Does the application need to pre-parse the = message
=A0 =A0 =A0 =A0 to get
=A0 =A0 =A0 =A0 the SPI value or is there a recommendation that some type o= f
=A0 =A0 =A0 =A0 callback be
=A0 =A0 =A0 =A0 included

=A0 =A0 =A0 =A0 7.Can you make things like the IV be implicit? =A0Thus agre= e on a
=A0 =A0 =A0 =A0 starting

=A0 =A0 =A0 =A0 value and an increment and compute the new IV for each new = message

=A0 =A0 =A0 =A0 8.If you are requiring that the values be populated by the<= br> =A0 =A0 =A0 =A0 application =96

=A0 =A0 =A0 =A0 does this require that you have a canonical encoding of how=
=A0 =A0 =A0 =A0 those values
=A0 =A0 =A0 =A0 are placed into the header for the purposes of the integrit= y check?

=A0 =A0 =A0 =A0 Jim



=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 jose mailing list
=A0 =A0 =A0 =A0 jose@iet= f.org <mailto:jos= e@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/jose
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/jose>=


=A0 =A0 _________________________________________________
=A0 =A0 jose mailing list
=A0 =A0 jose@ietf.org <mailto:jose@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/jose
=A0 =A0 <https://www.ietf.org/mailman/listinfo/jose>




--e89a8fb1ef16c99dd004d964be18-- From hannes.tschofenig@gmx.net Tue Apr 2 11:20:33 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CC421F8BBB for ; Tue, 2 Apr 2013 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.277 X-Spam-Level: X-Spam-Status: No, score=-103.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot7ZxB85VK9p for ; Tue, 2 Apr 2013 11:20:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F221F8BC5 for ; Tue, 2 Apr 2013 11:20:32 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MP3Jh-1UIzUB48nv-006Rk9 for ; Tue, 02 Apr 2013 20:20:21 +0200 Received: (qmail invoked by alias); 02 Apr 2013 18:20:20 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp004) with SMTP; 02 Apr 2013 20:20:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/MahZ1kzPMZuj1N3/IoBKPiB5Lc9EhEXfdk6bhZ2 6LObqALHsMAt5F Message-ID: <515B215B.1000104@gmx.net> Date: Tue, 02 Apr 2013 21:20:11 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Barnes References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Jim Schaad , Hannes Tschofenig , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:20:33 -0000 Just to give you two examples: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 uses a JWE protected JWT. The key used to encrypt the JWT needs to be pre-configured between the authorization server and the resource server. This would be a long-term secret. http://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/ uses an alternative design (a bit outdated already; needs to be refreshed) that uses the JOSE work for communication between the client and the resource server. The symmetric key used between these two parties would be short lived but we still use the JOSE work here. http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-02 Whether algorithm information is included in the JWS/JWE structure is a matter of what you agree with the other party and how. A requirement for the current documents, however, would be to ensure that the parameters are not mandatory because in certain situations you may have configured them out of band already. Reading through the JWS/JWE documents I am not sure whether this is allowed or not. Ciao Hannes On 04/02/2013 09:00 PM, Richard Barnes wrote: > "kid" identifies a key. "spi" identifies anything/everything. > > Think of it this way: > "spi" --> { "alg", "enc", "zip", "kid", ... } > > > On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig > > wrote: > > I don't understand why you need an additional spi parameter when > there is already a kid parameter, which serves the same purpose. > > Here is the kid parameter in the JWE: > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-08#section-4.1.10 > > > Here is the kid parameter in the JWS: > http://tools.ietf.org/html/__draft-ietf-jose-json-web-__signature-08#section-4.1.7 > > > Ciao > Hannes > > > On 04/02/2013 06:58 PM, Jim Schaad wrote: > > Richard, > > There is not yet sufficient detail in this document for me to do a > proper evaluation of how things are going to work. Example > questions > that I have. > > 1. What headers are required and which can be implicit – for > example > can the algorithm fields be implicit in the SPI? > > 2.Are the integrity value computed across the fully populated > header or > the SPI header? > > 3.Is there a way to forward a message from person A which knows > the SPI > > values and person B which does not? > > 4.What is the correct algorithm for determining the JWS vs JWE > in the > > event that all of the algorithms are implicit > > 5.What happens if you have implicit parameters and explicit > parameters > > and they do not match? > > 6.Is there a recommended way to determine what the SPI > parameters are > > going to be? Does the application need to pre-parse the message > to get > the SPI value or is there a recommendation that some type of > callback be > included > > 7.Can you make things like the IV be implicit? Thus agree on a > starting > > value and an increment and compute the new IV for each new message > > 8.If you are requiring that the values be populated by the > application – > > does this require that you have a canonical encoding of how > those values > are placed into the header for the purposes of the integrity check? > > Jim > > > > _________________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/__listinfo/jose > > > > _________________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/__listinfo/jose > > > From rlb@ipv.sx Tue Apr 2 11:25:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D421F8D0D for ; Tue, 2 Apr 2013 11:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9bV2e9xq3hD for ; Tue, 2 Apr 2013 11:25:47 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D2D3A21F8D03 for ; Tue, 2 Apr 2013 11:25:46 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uz6so649076obc.36 for ; Tue, 02 Apr 2013 11:25:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=62G8+FQlggjhx7iWhiMJRWz0Jc62oAti6Y8Fc1i9hVg=; b=A3ob1qmpf7ZSAptE7GTAdOpU7NtvWR+dlnpPzJeMu6wejwaZ/RkktMGy0a8FnZ1fyh bmBIM2rzRWNj38KgSeeVsFFGF+JpxMolGJZk0hHrydqCcp9JKZ2OvbmzvyQLIfFdHD0w YIEjGld0FmFF+0ZhpS/WILA34gR+FIy3QhnPsT1DoYInvTC1OZf55U+9qwbFLAsZ16XJ 460/1XW3JZSMF/jLXj5HUaSE+Nqz34+Noqq7JmOOeZAJtVtt1BsHNsOf4rcenkr+sKaG DrDDXo6kq6ZXgYLMSbVQuwxOgw8cJg8FDxMfvN5VQKe0AMsfgjAsyElGSNtuWJiNoh+9 gigQ== MIME-Version: 1.0 X-Received: by 10.60.24.197 with SMTP id w5mr5859892oef.6.1364927146333; Tue, 02 Apr 2013 11:25:46 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Tue, 2 Apr 2013 11:25:46 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <515B215B.1000104@gmx.net> References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> <515B215B.1000104@gmx.net> Date: Tue, 2 Apr 2013 14:25:46 -0400 Message-ID: From: Richard Barnes To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=e89a8ff1c30eb3e8e904d964ddde X-Gm-Message-State: ALoCoQlktJWbGA9i40V/1equKaDYVH0wFrjn15+CzzHQjIEry0NFV+SpNxLG3DLBFBRT4d0Ba0Nr Cc: Jim Schaad , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:25:48 -0000 --e89a8ff1c30eb3e8e904d964ddde Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 2, 2013 at 2:20 PM, Hannes Tschofenig wrote: > Just to give you two examples: > > http://tools.ietf.org/html/**draft-ietf-oauth-v2-http-mac-**03 > uses a JWE protected JWT. > > The key used to encrypt the JWT needs to be pre-configured between the > authorization server and the resource server. This would be a long-term > secret. > > http://datatracker.ietf.org/**doc/draft-tschofenig-oauth-**hotk/ > uses an alternative design (a bit outdated already; needs to be refreshed= ) > that uses the JOSE work for communication between the client and the > resource server. The symmetric key used between these two parties would b= e > short lived but we still use the JOSE work here. > > http://tools.ietf.org/html/**draft-tschofenig-oauth-hotk-02 > > Whether algorithm information is included in the JWS/JWE structure is a > matter of what you agree with the other party and how. > > A requirement for the current documents, however, would be to ensure that > the parameters are not mandatory because in certain situations you may ha= ve > configured them out of band already. > > Reading through the JWS/JWE documents I am not sure whether this is > allowed or not. > This is exactly my point. These pre-negotiation cases prevent us from having clear requirements levels. The goal of SPI is to explicitly say "SPI indicates that pre-negotiated parameters are being used, so some things that are otherwise REQUIRED might be missing." That way, you can still have fields that MUST be included in general, but if you include an SPI, you can omit them. --Richard > > Ciao > Hannes > > > > > On 04/02/2013 09:00 PM, Richard Barnes wrote: > >> "kid" identifies a key. "spi" identifies anything/everything. >> >> Think of it this way: >> "spi" --> { "alg", "enc", "zip", "kid", ... } >> >> >> On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig >> >> >> wrote: >> >> I don't understand why you need an additional spi parameter when >> there is already a kid parameter, which serves the same purpose. >> >> Here is the kid parameter in the JWE: >> http://tools.ietf.org/html/__**draft-ietf-jose-json-web-__** >> encryption-08#section-4.1.10 >> >> > encryption-08#section-4.1.10 >> > >> >> Here is the kid parameter in the JWS: >> http://tools.ietf.org/html/__**draft-ietf-jose-json-web-__** >> signature-08#section-4.1.7 >> >> > signature-08#section-4.1.7 >> > >> >> Ciao >> Hannes >> >> >> On 04/02/2013 06:58 PM, Jim Schaad wrote: >> >> Richard, >> >> There is not yet sufficient detail in this document for me to do= a >> proper evaluation of how things are going to work. Example >> questions >> that I have. >> >> 1. What headers are required and which can be implicit =96 for >> example >> can the algorithm fields be implicit in the SPI? >> >> 2.Are the integrity value computed across the fully populated >> header or >> the SPI header? >> >> 3.Is there a way to forward a message from person A which knows >> the SPI >> >> values and person B which does not? >> >> 4.What is the correct algorithm for determining the JWS vs JWE >> in the >> >> event that all of the algorithms are implicit >> >> 5.What happens if you have implicit parameters and explicit >> parameters >> >> and they do not match? >> >> 6.Is there a recommended way to determine what the SPI >> parameters are >> >> going to be? Does the application need to pre-parse the message >> to get >> the SPI value or is there a recommendation that some type of >> callback be >> included >> >> 7.Can you make things like the IV be implicit? Thus agree on a >> starting >> >> value and an increment and compute the new IV for each new messa= ge >> >> 8.If you are requiring that the values be populated by the >> application =96 >> >> does this require that you have a canonical encoding of how >> those values >> are placed into the header for the purposes of the integrity >> check? >> >> Jim >> >> >> >> ______________________________**___________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/jose >> >> > >> >> >> ______________________________**___________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/jose >> >> > >> >> >> > --e89a8ff1c30eb3e8e904d964ddde Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2013 at 2:20 PM, Hannes T= schofenig <hannes.tschofenig@gmx.net> wrote:
Just to give you two examples:

http://tools.ietf.org/html/draft-ietf-oauth-v2-http-ma= c-03
uses a JWE protected JWT.

The key used to encrypt the JWT needs to be pre-configured between the auth= orization server and the resource server. This would be a long-term secret.=

http://datatracker.ietf.org/doc/draft-tschofenig-oau= th-hotk/
uses an alternative design (a bit outdated already; needs to be refreshed) = that uses the JOSE work for communication between the client and the resour= ce server. The symmetric key used between these two parties would be short = lived but we still use the JOSE work here.

http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-= 02

Whether algorithm information is included in the JWS/JWE structure is a mat= ter of what you agree with the other party and how.

A requirement for the current documents, however, would be to ensure that t= he parameters are not mandatory because in certain situations you may have = configured them out of band already.

Reading through the JWS/JWE documents I am not sure whether this is allowed= or not.

This is exactly my point. =A0T= hese pre-negotiation cases prevent us from having clear requirements levels= . =A0

The goal of SPI is to explicitly say "SPI indicate= s that pre-negotiated parameters are being used, so some things that are ot= herwise REQUIRED might be missing." =A0That way, you can still have fi= elds that MUST be included in general, but if you include an SPI, you can o= mit them.

--Richard


=A0

Ciao
Hannes




On 04/02/2013 09:00 PM, Richard Barnes wrote:
"kid" identifies a key. =A0"spi" identifies anything/ev= erything.

Think of it this way:
"spi" --> { "alg", "enc", "zip",= "kid", ... }


On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
=A0 =A0 I don't understand why you need an additional spi parameter whe= n
=A0 =A0 there is already a kid parameter, which serves the same purpose.
=A0 =A0 Here is the kid parameter in the JWE:
=A0 =A0 http://tools.ietf.org/html/= __draft-ietf-jose-json-web-__encryption-08#section-4.1.10=

=A0 =A0 <http://tools.ietf.org/html/= draft-ietf-jose-json-web-encryption-08#section-4.1.10>=

=A0 =A0 Here is the kid parameter in the JWS:
=A0 =A0 http://tools.ietf.org/html/__= draft-ietf-jose-json-web-__signature-08#section-4.1.7

=A0 =A0 <http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.7>

=A0 =A0 Ciao
=A0 =A0 Hannes


=A0 =A0 On 04/02/2013 06:58 PM, Jim Schaad wrote:

=A0 =A0 =A0 =A0 Richard,

=A0 =A0 =A0 =A0 There is not yet sufficient detail in this document for me = to do a
=A0 =A0 =A0 =A0 proper evaluation of how things are going to work. =A0Examp= le
=A0 =A0 =A0 =A0 questions
=A0 =A0 =A0 =A0 that I have.

=A0 =A0 =A0 =A0 1. What headers are required and which can =A0be implicit = =96 for
=A0 =A0 =A0 =A0 example
=A0 =A0 =A0 =A0 can the algorithm fields be implicit in the SPI?

=A0 =A0 =A0 =A0 2.Are the integrity value computed across the fully populat= ed
=A0 =A0 =A0 =A0 header or
=A0 =A0 =A0 =A0 the SPI header?

=A0 =A0 =A0 =A0 3.Is there a way to forward a message from person A which k= nows
=A0 =A0 =A0 =A0 the SPI

=A0 =A0 =A0 =A0 values and person B which does not?

=A0 =A0 =A0 =A0 4.What is the correct algorithm for determining the JWS vs = JWE
=A0 =A0 =A0 =A0 in the

=A0 =A0 =A0 =A0 event that all of the algorithms are implicit

=A0 =A0 =A0 =A0 5.What happens if you have implicit parameters and explicit=
=A0 =A0 =A0 =A0 parameters

=A0 =A0 =A0 =A0 and they do not match?

=A0 =A0 =A0 =A0 6.Is there a recommended way to determine what the SPI
=A0 =A0 =A0 =A0 parameters are

=A0 =A0 =A0 =A0 going to be? =A0Does the application need to pre-parse the = message
=A0 =A0 =A0 =A0 to get
=A0 =A0 =A0 =A0 the SPI value or is there a recommendation that some type o= f
=A0 =A0 =A0 =A0 callback be
=A0 =A0 =A0 =A0 included

=A0 =A0 =A0 =A0 7.Can you make things like the IV be implicit? =A0Thus agre= e on a
=A0 =A0 =A0 =A0 starting

=A0 =A0 =A0 =A0 value and an increment and compute the new IV for each new = message

=A0 =A0 =A0 =A0 8.If you are requiring that the values be populated by the<= br> =A0 =A0 =A0 =A0 application =96

=A0 =A0 =A0 =A0 does this require that you have a canonical encoding of how=
=A0 =A0 =A0 =A0 those values
=A0 =A0 =A0 =A0 are placed into the header for the purposes of the integrit= y check?

=A0 =A0 =A0 =A0 Jim



=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 jose mailing list
=A0 =A0 =A0 =A0 jose@iet= f.org <mailto:jos= e@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/jose
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/jose>=


=A0 =A0 _________________________________________________
=A0 =A0 jose mailing list
=A0 =A0 jose@ietf.org <mailto:jose@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/jose
=A0 =A0 <https://www.ietf.org/mailman/listinfo/jose>




--e89a8ff1c30eb3e8e904d964ddde-- From hannes.tschofenig@gmx.net Tue Apr 2 11:53:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742321F8D6A for ; Tue, 2 Apr 2013 11:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.823 X-Spam-Level: X-Spam-Status: No, score=-102.823 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbVv3BW8YW6p for ; Tue, 2 Apr 2013 11:53:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2C21F8D3A for ; Tue, 2 Apr 2013 11:53:08 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MQsi0-1UCgUn2GoY-00UFxf for ; Tue, 02 Apr 2013 20:53:07 +0200 Received: (qmail invoked by alias); 02 Apr 2013 18:53:07 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 02 Apr 2013 20:53:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/p7GMgTibprBRCw7APNE67yT8h8c5uzXTnc4hDVS OL/pOUlp60UAU6 Message-ID: <515B2909.901@gmx.net> Date: Tue, 02 Apr 2013 21:52:57 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Barnes References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> <515B215B.1000104@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Jim Schaad , Hannes Tschofenig , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:53:09 -0000 On 04/02/2013 09:25 PM, Richard Barnes wrote: > > This is exactly my point. These pre-negotiation cases prevent us from > having clear requirements levels. > > The goal of SPI is to explicitly say "SPI indicates that pre-negotiated > parameters are being used, so some things that are otherwise REQUIRED > might be missing." That way, you can still have fields that MUST be > included in general, but if you include an SPI, you can omit them. AHA. Now I got it. There are two options to address it: 1) Create a new parameter, as you suggested 2) Fix the specs (to allow parameters like alg to be optional) From turners@ieca.com Tue Apr 2 11:54:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBF221F8D8E for ; Tue, 2 Apr 2013 11:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQK691tDtc4g for ; Tue, 2 Apr 2013 11:54:34 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.10.5]) by ietfa.amsl.com (Postfix) with ESMTP id 77E7421F8267 for ; Tue, 2 Apr 2013 11:54:34 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 3F25ECC5C15EF; Tue, 2 Apr 2013 13:54:26 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 3393ECC5C15CB for ; Tue, 2 Apr 2013 13:54:26 -0500 (CDT) Received: from [108.45.16.214] (port=49446 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UN6Lp-0000c8-NL; Tue, 02 Apr 2013 13:54:33 -0500 Message-ID: <515B2968.7000000@ieca.com> Date: Tue, 02 Apr 2013 14:54:32 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mountie Lee References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:49446 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Richard Barnes , jose@ietf.org Subject: Re: [jose] JOSE and RFC4210 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:54:35 -0000 CMP (RFC 4210) is "a" protocol for certificate management :) Are you saying that's the one they picked? There's more than CMP to choose from: - PKCS#10/PKCS#7 (RFC2986/RFC2315|RFC5751) - CMC (RFC5272) - SCEP (likely to be a historic RFC shortly) - EST (slowly working it's way out of PKIX) The PKIX WG long ago ducted on deciding the one true enrollment protocol. It might have been long enough to restart that debate, but I don't think we should do that on this list. spt On 4/1/13 11:57 AM, Richard Barnes wrote: > Hi Mountie, > > JOSE is a cryptographic container format, like PKCS7 / CMS. So it could > be used to encapsulate CMP messages, in the same way that PKCS7 or > S/MIME is today. > > --Richard > > > > On Sun, Mar 31, 2013 at 9:19 AM, Mountie Lee > wrote: > > Hi. > I'm Mountie Lee from Korea. > > recently I'm trying to write draft for Web Certificate API as the > part of W3C WebCrypto WG (http://www.w3.org/2012/webcrypto/) > > RFC4210 is the standard for Certificate Management Protocol > and defines list of response data types in their process. > > for example > RFC4210 CMP defines Certificate Reponse data structure as > http://tools.ietf.org/html/rfc4210#section-5.3.4 > > also it defines the Revocation Response data structure as > http://tools.ietf.org/html/rfc4210#section-5.3.10 > > my question is > > in JOSE Working Group > is there any discussion for JOSE data format for RFC4210 data > structures? > > if not, where can I start to discuss for these requirements? > > Korea and in some other countries are using RFC4210 as their base > pki standard. > previously and until to now, binary plugins (like ActiveX) are used > to implement CMP. > > already huge infrastructures (legal, physical and services) are > established and operated over 10 years. > > that is the reason why we have interest for JOSE as the data > structure of RFC4210 CMP. > > best regards > mountie. > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 > E-Mail : mountie@paygate.net > > ======================================= > PayGate Inc. > THE STANDARD FOR ONLINE PAYMENT > for Korea, Japan, China, and the World > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From rlb@ipv.sx Tue Apr 2 11:57:51 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EBB21F8C71 for ; Tue, 2 Apr 2013 11:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1k+IbNnC55j for ; Tue, 2 Apr 2013 11:57:50 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 183D121F8B9F for ; Tue, 2 Apr 2013 11:57:50 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j6so708533oag.8 for ; Tue, 02 Apr 2013 11:57:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Y86fRPoET/JCHoeFoNVYU0elnW8w6jCiFGVyzXNhtvs=; b=LBT/onXw9gDAleuIHffqe6kVpszZOXGZ7PT4Qe43BNI4X0hcXHSuf8030g/UrKq/R1 gN/LG92NzTng9J+YgSKK6jSzGIN6SeCrptg5YlExvkhImBb2dUKDBNfcUnb3D19THkwE 0hDlt2nQ2L/+pnlGyGop7hKQYZKn//1dxLZDYlCHrzoei3A6p21H2O6o5miI/9IdcIIW lHxGWkLz/LoVNblS06ggsUiVXHAr2d+5A+PtbAabiCE0uF8IDxJWkVJAT83jRVOn9aUk pgzddSqhoLoX0NB+XEuzyaJQ+INFnsp6wP/kVa+wjczDikuIC172kurYRrhBihjBFPpp 6HQw== MIME-Version: 1.0 X-Received: by 10.182.39.69 with SMTP id n5mr6181424obk.72.1364929069227; Tue, 02 Apr 2013 11:57:49 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Tue, 2 Apr 2013 11:57:49 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <515B2909.901@gmx.net> References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> <515B215B.1000104@gmx.net> <515B2909.901@gmx.net> Date: Tue, 2 Apr 2013 14:57:49 -0400 Message-ID: From: Richard Barnes To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=f46d0447975551020904d96550e3 X-Gm-Message-State: ALoCoQn9QRWz4lfIIeRL3XtxnbT2olyChkXArHMcKOFLaslkvIn+CcYMhHhZIBKbf8Rd8F99QE5P Cc: Jim Schaad , jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org Subject: Re: [jose] Comments on draft-barnes-jose-spi-00 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:57:51 -0000 --f46d0447975551020904d96550e3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 2, 2013 at 2:52 PM, Hannes Tschofenig wrote: > On 04/02/2013 09:25 PM, Richard Barnes wrote: > >> >> This is exactly my point. These pre-negotiation cases prevent us from >> having clear requirements levels. >> >> The goal of SPI is to explicitly say "SPI indicates that pre-negotiated >> parameters are being used, so some things that are otherwise REQUIRED >> might be missing." That way, you can still have fields that MUST be >> included in general, but if you include an SPI, you can omit them. >> > > AHA. Now I got it. > > There are two options to address it: > > 1) Create a new parameter, as you suggested > > 2) Fix the specs > (to allow parameters like alg to be optional) > Option 2 is not good, because it means that if you have an object that's *not* pre-negotiated, you don't know what has to be there. In fact, both types of object (with and without pre-negotiation) benefit from Option 1, since the stronger requirements could be applied in both cases. In the pre-negotiated case, you would just apply the requirements after "rehydrating" the object. --Richard --f46d0447975551020904d96550e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2013 at 2:52 PM, Hannes T= schofenig <hannes.tschofenig@gmx.net> wrote:
On 04/02/2013 09:25 PM, Richard Barnes wrote:

This is exactly my point. =A0These pre-negotiation cases prevent us from having clear requirements levels.

The goal of SPI is to explicitly say "SPI indicates that pre-negotiate= d
parameters are being used, so some things that are otherwise REQUIRED
might be missing." =A0That way, you can still have fields that MUST be=
included in general, but if you include an SPI, you can omit them.

AHA. Now I got it.

There are two options to address it:

1) Create a new parameter, as you suggested

2) Fix the specs
(to allow parameters like alg to be optional)


Option 2 is not good, because it means that if you ha= ve an object that's *not* pre-negotiated, you don't know what has t= o be there. =A0In fact, both types of object (with and without pre-negotiat= ion) benefit from Option 1, since the stronger requirements could be applie= d in both cases. =A0In the pre-negotiated case, you would just apply the re= quirements after "rehydrating" the object.

--Richard=A0
--f46d0447975551020904d96550e3-- From trac+jose@trac.tools.ietf.org Wed Apr 3 11:13:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7045D21F8C3C for ; Wed, 3 Apr 2013 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvNeQaDLdVBD for ; Wed, 3 Apr 2013 11:13:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BB47021F8C1E for ; Wed, 3 Apr 2013 11:13:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:41853 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNSBg-0001xd-88; Wed, 03 Apr 2013 20:13:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, dick.hardt@gmail.com X-Trac-Project: jose Date: Wed, 03 Apr 2013 18:13:32 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/17 Message-ID: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, dick.hardt@gmail.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130403181342.BB47021F8C1E@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 11:13:42 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:13:43 -0000 #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Recipients of an encrypted token sometimes are not the audience, and may not know who the issuer is. Allowing these values to be in the header enables a recipient to have a hint if the token needs to be handed to another party for processing, and a hint of who the issuer was. These values are not confirmed until validation of the token has been performed, but enables the appropriate parties and keys to be used to validate. Suggested added text: 4.1.x The "iss" (issuer) Header Parameter The "iss" (issuer) header parameter identifies the principal that issued the JWT. The processing of this header parameter is generally application specific. The "iss" value is case sensitive. This header parameter is OPTIONAL. 4.1.x The "aud" (audience) Header Parameter The "aud" (audience) header parameter identifies the audience that the JWT is intended for. The principal intended to process the JWT MUST be identified with the value of the audience header parameter. If the principal processing the header parameter does not identify itself with the identifier in the "aud" header parameter value then the JWT MUST be rejected. The interpretation of the audience value is generally application specific. The "aud" value is case sensitive. This header parameter is OPTIONAL. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- dick.hardt@gmail.com | encryption@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 3 12:52:27 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F1721F8C6F for ; Wed, 3 Apr 2013 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp7Q1PIYCgvc for ; Wed, 3 Apr 2013 12:52:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DC7C721F8BF2 for ; Wed, 3 Apr 2013 12:52:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:44899 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNTjB-0001Dc-9i; Wed, 03 Apr 2013 21:52:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 03 Apr 2013 19:52:13 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:3 Message-ID: <069.cb2ef616e569d8dbd7a4f637fa064e1c@trac.tools.ietf.org> References: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130403195226.DC7C721F8BF2@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 12:52:26 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 19:52:27 -0000 #4: Remove wrapped keys from integrity check (allow separation of keys from data) Comment (by michael.jones@microsoft.com): This write-up is missing the fact that even if the wrapped keys were removed from the integrity calculation, there's still per-recipient content in the headers, such as information about the key used for that recipient. So I believe what you're really asking for, Richard, is to remove both the wrapped key and the header from the integrity calculation, so there is no per-recipient information protected. (Please correct me if I'm wrong.) For starters, not protecting the headers could open us up to algorithm substitution attacks, because the "alg" and/or "enc" values could be modified by the attacker. Furthermore, protecting the headers cryptographically binds the information in them to the Ciphertext, which is a very good thing. Especially given that we've now allowed additional information to be passed in the headers (by saying that header parameter values that are not understood must be ignored), I fully expect that some of that information will only be of any value when cryptographically bound to the Ciphertext, so attackers cannot modify it. Protecting the headers values is a "secure by default" architecture. It removes the need to ask questions about what attacks are enabled if header parameter A or header parameter B can be modified by the attacker, because we've taken that possibility away from the attacker. Especially given that we know that we don't know what all the header parameters will be, from a security viewpoint, continuing to protect them seems like the only sensible choice. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 3 13:03:59 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DFE21F8B97 for ; Wed, 3 Apr 2013 13:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU+sumfo3ym0 for ; Wed, 3 Apr 2013 13:03:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B678E21F8A91 for ; Wed, 3 Apr 2013 13:03:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:45660 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNTuR-000682-C7; Wed, 03 Apr 2013 22:03:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 03 Apr 2013 20:03:51 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:1 Message-ID: <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130403200358.B678E21F8A91@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 13:03:58 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 20:03:59 -0000 #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Comment (by michael.jones@microsoft.com): I believe that this is a JWT issue – not a JOSE issue. I'd suggest that you re-file this issue to be considered for the JWT spec, Dick, and close it here, as it's JWT-specific. The OAuth issue tracker (which can be used for the JWT spec, since it's in the OAuth working group) is at http://trac.tools.ietf.org/wg/oauth/trac/. I think the real change you're requesting is to have the JWT spec add the "iss" and "aud" claims, which it defines, to the list of reserved JWE header parameter values, and to say that the "iss" and "aud" claim values defined by the JWT spec may appear in the JWE header. The JWT spec *can* reserve JOSE header fields. (Any spec can, through use of the IANA registry.) This doesn't have to be done in the JWE spec. A processing question you'd need to answer is whether, if present in the JWE header, these claim values must also appear in the JWT Claims Set with identical values, or whether it's your intent to allow or require them to appear in exactly one of the two locations. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- dick.hardt@gmail.com | encryption@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Wed Apr 3 20:04:54 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3A11E80A4 for ; Wed, 3 Apr 2013 20:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkoCnOAn+ahD for ; Wed, 3 Apr 2013 20:04:53 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4920C11E80A2 for ; Wed, 3 Apr 2013 20:04:53 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so2283187oag.19 for ; Wed, 03 Apr 2013 20:04:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=qX8VZhx/vHhVGDGUP73Z93saG3BZp+KplDoclFEb040=; b=HSOPpoyg0d11pbTE9lms4HgclDjuagw1QCPqDTf96CPEAPJe0KhjPBbx/6RYyFMh6t K31JMj4EwLyTfDxR/2THtjTZCtOhe6XfrsId4uCp2CA0qchDlYwZVlHbWIyK3Vjn8Msx 34bXH+kUh7RXgnURexyZxC19kW5hRrB21j/CaJHfAL/4KUbsJjh18NiW7C4aU7oFr8qE 0tiHsGYBiNCwNe5O4Gecq13YLgTIRDjunEC0z9ELcxtrTiG+W5wLd25ibwRhC+OfG0vR RZwInzkFzJJiJDR0RHT7YN9pdFkosC/x9A78XwKIWPERKiY0lfpZTASCRHT26lZGf+6I pXPg== MIME-Version: 1.0 X-Received: by 10.182.52.102 with SMTP id s6mr2810575obo.87.1365044692552; Wed, 03 Apr 2013 20:04:52 -0700 (PDT) Received: by 10.60.37.229 with HTTP; Wed, 3 Apr 2013 20:04:52 -0700 (PDT) X-Originating-IP: [12.104.13.2] In-Reply-To: <20130404025808.14436.13483.idtracker@ietfa.amsl.com> References: <20130404025808.14436.13483.idtracker@ietfa.amsl.com> Date: Wed, 3 Apr 2013 23:04:52 -0400 Message-ID: From: Richard Barnes To: jose@ietf.org Content-Type: multipart/alternative; boundary=14dae939960700ee6904d9803c8c X-Gm-Message-State: ALoCoQlfEXzrPvCUh0yqN8f4fqRpKPbRGJi5UJRo7fCgxESNcFNp2g396bH0yzx2W4DDlTYzwhN+ Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-key-wrapping-00.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:04:54 -0000 --14dae939960700ee6904d9803c8c Content-Type: text/plain; charset=ISO-8859-1 Dear JOSE, At the WG meeting, I agreed to draft an I-D proposing a way to unify JWE key wrapping and JWK key wrapping. I have just posted such an I-D. In short, the proposal is to re-factor JWE so that the wrapped key is effectively the same as a wrapped JWK. Many more details in the document --Richard ---------- Forwarded message ---------- From: Date: Wed, Apr 3, 2013 at 10:58 PM Subject: New Version Notification for draft-barnes-jose-key-wrapping-00.txt To: rlb@ipv.sx A new version of I-D, draft-barnes-jose-key-wrapping-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-jose-key-wrapping Revision: 00 Title: Proposed Refactoring of JOSE to Align Encryption and Key Wrapping Creation date: 2013-04-03 Group: Individual Submission Number of pages: 33 URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-key-wrapping-00.txt Status: http://datatracker.ietf.org/doc/draft-barnes-jose-key-wrapping Htmlized: http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-00 Abstract: The discussions around key wrapping in the JOSE working group have raised new requirements for wrapped keys, namely: (1) Wrapping keys other than symmetric keys, (2) cryptographically binding attributes to keys, and (3) allowing the use of AEAD cryptographic algorithms for key wrapping (other than AES-KW). This document proposes a refactoring of the JOSE document set that provides a cleaner conceptual structure for JWS / JWE and transparent support for wrapped keys, all with a relatively minor impact on the compact form of JWS and JWE objects. The IETF Secretariat --14dae939960700ee6904d9803c8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear JOSE,

At the WG meeting, I agreed to draft an I-D p= roposing a way to unify JWE key wrapping and JWK key wrapping. =A0I have ju= st posted such an I-D.

In short, the proposal is t= o re-factor JWE so that the wrapped key is effectively the same as a wrappe= d JWK. =A0Many more details in the document

--Richard



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Apr 3, 2013 at 10:58 PM
Subject: New Version Notification for= draft-barnes-jose-key-wrapping-00.txt
To: rlb@ipv.sx



A new version of I-D, draft-barnes-jose-key-wrapping-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-barnes-jose-key-wrapping
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Proposed Refactoring of JOSE to Align Encryption= and Key Wrapping
Creation date: =A0 2013-04-03
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 33
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-barnes-jose-key-wrapping-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-barnes-jose-key-wrapping
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-b= arnes-jose-key-wrapping-00


Abstract:
=A0 =A0The discussions around key wrapping in the JOSE working group have =A0 =A0raised new requirements for wrapped keys, namely: (1) Wrapping keys<= br> =A0 =A0other than symmetric keys, (2) cryptographically binding attributes<= br> =A0 =A0to keys, and (3) allowing the use of AEAD cryptographic algorithms =A0 =A0for key wrapping (other than AES-KW). =A0This document proposes a =A0 =A0refactoring of the JOSE document set that provides a cleaner
=A0 =A0conceptual structure for JWS / JWE and transparent support for
=A0 =A0wrapped keys, all with a relatively minor impact on the compact form=
=A0 =A0of JWS and JWE objects.




The IETF Secretariat


--14dae939960700ee6904d9803c8c-- From trac+jose@trac.tools.ietf.org Wed Apr 3 20:26:33 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2B21F93DD for ; Wed, 3 Apr 2013 20:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZC2sJks88zt for ; Wed, 3 Apr 2013 20:26:33 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EF9FA21F93DC for ; Wed, 3 Apr 2013 20:26:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:33925 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNaok-0001yN-U4; Thu, 04 Apr 2013 05:26:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, rlb@ipv.sx X-Trac-Project: jose Date: Thu, 04 Apr 2013 03:26:26 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/10#comment:2 Message-ID: <069.fe26ef59a7f7d2d57208bd0dae93ecd6@trac.tools.ietf.org> References: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130404032632.EF9FA21F93DC@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 20:26:32 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #10: Remove implementation requirements X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:26:33 -0000 #10: Remove implementation requirements Comment (by rlb@ipv.sx): (Speaking as an individual) If you would like to get IESG feedback here, it would better to ask directly, instead of inferring from the OAuth case. The answer might be different. I would propose to solve this problem in two parts: 1. Have JWE / JWS / JWA be completely algorithm agnostic (no MTI) 2. In an "implementation considerations" document, specify a recommended baseline suite of algorithms. (I would prefer RECOMMENDED, but I might acquiesce to REQUIRED if the base specs are agnostic.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: algorithms | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 3 20:30:17 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D001F11E80A2 for ; Wed, 3 Apr 2013 20:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8TTyeujMF-J for ; Wed, 3 Apr 2013 20:30:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0B11E80A4 for ; Wed, 3 Apr 2013 20:30:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:33998 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNasM-0004AW-LV; Thu, 04 Apr 2013 05:30:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Thu, 04 Apr 2013 03:30:10 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/13#comment:3 Message-ID: <064.ce3bcb37d79ccc16fe24f8188caf1ce8@trac.tools.ietf.org> References: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130404033017.44F0B11E80A4@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 20:30:16 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #13: Enable AEAD key wrapping X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:30:17 -0000 #13: Enable AEAD key wrapping Comment (by rlb@ipv.sx): As I understood the feedback from WebCrypto, the desire was for general AEAD algorithms to be usable in both (1) and (2). And as I expressed at IETF86, it would be architecturally simpler if we use the same key wrapping for all wrapped keys, whether attached to JWE or not. A proposed solution has been submitted as http://tools.ietf.org/html /draft-barnes-jose-key-wrapping -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 3 20:35:34 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FF411E80A2 for ; Wed, 3 Apr 2013 20:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 736WuFhEhbFN for ; Wed, 3 Apr 2013 20:35:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0A21E8037 for ; Wed, 3 Apr 2013 20:35:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:34082 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNaxK-0006qH-VK; Thu, 04 Apr 2013 05:35:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx X-Trac-Project: jose Date: Thu, 04 Apr 2013 03:35:18 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:6 Message-ID: <064.978e3e9e44e7ad9e8f0e7f14a9ab1433@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130404033524.A0F0A21E8037@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 20:35:24 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #15: At least one key indicator should be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:35:35 -0000 #15: At least one key indicator should be mandatory Comment (by rlb@ipv.sx): In order for these OAuth JOSE stacks to be interoperable with other JOSE stacks, the non-OAuth stacks need to fail cleanly when they get a OAuth JOSE object using pre-negotiated parameters. So objects that use pre- negotiated parameters need to signal that they are doing so, using something like SPI. If pre-negotiated parameters are being used, then obviously a key indication MUST be present; likewise for algorithms. So the specification should say something like: "At least one key indication field and one algorithm specification field is REQUIRED. If an SPI value is present, then pre-negotiated parameter values are being used, and any field MAY be omitted, even if it would otherwise be REQUIRED." -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Wed Apr 3 20:36:40 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF1511E80A4 for ; Wed, 3 Apr 2013 20:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVIsKRd1js77 for ; Wed, 3 Apr 2013 20:36:40 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0934611E80A2 for ; Wed, 3 Apr 2013 20:36:39 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uz6so2151117obc.36 for ; Wed, 03 Apr 2013 20:36:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tKzSY76ftaa7Utib43UVfau0wTUfP10EwKxNHWI2Uc8=; b=Anhf7b6EVwI+OAHdaMffL4hxqnAAaPIshE+QxZPjLwBUTnCDB7VnFelOqGbyJaniwi jSXqJAe+cvgtRI9mdEc3/9FfVT3U8ODIznunuYVYNvM5dphTRgfov4gIy0jgbPkA0cxV +bH70mZ2sJ8P3gjjFD6mYGzPXnZzHL+giqMIgIC1TbCwC9mLbszUHf+SXoHRp/l7bhsM e4y6QA51UaCNMMfuFt2TjDk9fTtYgCOrHB1mydvcQ+JVxPJuyB5GT5GXgtxEBTARDp+f BpR+7YWKRlyNVlFWDQnHVpub+baX44cGyCQfU/WrMkTrMbMj8w44goYNamnqcHHKjFtD D+mA== MIME-Version: 1.0 X-Received: by 10.60.85.35 with SMTP id e3mr2917672oez.117.1365046599475; Wed, 03 Apr 2013 20:36:39 -0700 (PDT) Received: by 10.60.37.229 with HTTP; Wed, 3 Apr 2013 20:36:39 -0700 (PDT) X-Originating-IP: [12.104.13.2] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C06EA61@WSMSG3153V.srv.dir.telstra.com> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> <080.fec3c931ff7caa6172df3c6f437eb638@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150C06EA61@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 3 Apr 2013 23:36:39 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=089e0111be00aa4d6704d980ad83 X-Gm-Message-State: ALoCoQkIYoVzu6Kv0Q0irW1G/Voptv95b4dEXtdJZDMfkwBLUoR/+KPEFRk7uO2U0DLWcthHrPbR Cc: "michael.jones@microsoft.com" , "bcampbell@pingidentity.com" , jose issue tracker , "jose@ietf.org" Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:36:41 -0000 --089e0111be00aa4d6704d980ad83 Content-Type: text/plain; charset=ISO-8859-1 I don't have much feeling one way or another, especially since header fields are non-critical now. --Richard On Mon, Apr 1, 2013 at 6:48 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > #12: x5c incorrect in JWE > > > > > > Comment (by michael.jones@microsoft.com): > > > > For generality, I'll note that if people believe that "x5c" should be > > removed from JWE, then the same logic probably suggests that "x5u", > > "jku" > > should be removed, as all are ways of including or referencing public > > key values corresponding to the private key used to encrypt the > > content. And by that logic, if we don't need a way to reference or > > include public key values for JWEs, then the "x5t" and possibly "kid" > > parameters would then also be of dubious value. At least by that > > reasoning, the inclusion of all the key reference parameters would > > likely stand or fall together. > > Yay! Drop the lot ("jku", "jwk", "x5u", "x5t", "x5c") from JWE; keep "kid". > > > Should we describe how to get a "kid" value from a certificate or a raw > public key (in case an explicit "kid" value is not available to a JWE > originator)? If you only have a cert you can look for a > subjectKeyIdentifier extension -- though that is an OCTET STRING so it may > need to be base64url-encoded (without padding) to give a "kid" string. A > raw public key could be hashed to synthetise a "kid" value, but then you > need a canonical form of the public key to hash. > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e0111be00aa4d6704d980ad83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't have much feeling one way or another, especially since header f= ields are non-critical now.
--Richard


On Mon, Apr 1, 2013 at 6:48 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> #12: x5c incorrect in= JWE
>
>
> Comment (by michael.jon= es@microsoft.com):
>
> =A0For generality, I'll note that if people believe that "x5c= " should be
> removed from JWE, then the same logic probably suggests that "x5u= ",
> "jku"
> =A0should be removed, as all are ways of including or referencing publ= ic
> key =A0values corresponding to the private key used to encrypt the
> content. =A0And =A0by that logic, if we don't need a way to refere= nce or
> include public key =A0values for JWEs, then the "x5t" and po= ssibly "kid"
> parameters would then =A0also be of dubious value. =A0At least by that=
> reasoning, the inclusion of =A0all the key reference parameters would<= br> > likely stand or fall together.

Yay! Drop the lot ("jku", "jwk", "x5u",= "x5t", "x5c") from JWE; keep "kid".


Should we describe how to get a "kid" value from a certificate or= a raw public key (in case an explicit "kid" value is not availab= le to a JWE originator)? If you only have a cert you can look for a subject= KeyIdentifier extension -- though that is an OCTET STRING so it may need to= be base64url-encoded (without padding) to give a "kid" string. A= raw public key could be hashed to synthetise a "kid" value, but = then you need a canonical form of the public key to hash.

--
James Manger
___________________________________= ____________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e0111be00aa4d6704d980ad83-- From trac+jose@trac.tools.ietf.org Wed Apr 3 20:52:15 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A860111E80A5 for ; Wed, 3 Apr 2013 20:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLt7fqTFDPog for ; Wed, 3 Apr 2013 20:52:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1985611E80A4 for ; Wed, 3 Apr 2013 20:52:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:34503 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNbDd-0003Av-Pm; Thu, 04 Apr 2013 05:52:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Thu, 04 Apr 2013 03:52:09 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:4 Message-ID: <069.60ce5f2cb8cad16f3467698752bb1b5a@trac.tools.ietf.org> References: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130404035215.1985611E80A4@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 20:52:15 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:52:15 -0000 #4: Remove wrapped keys from integrity check (allow separation of keys from data) Comment (by rlb@ipv.sx): Responding to each of your paragraphs in parallel... You are correct. In "wrapped key", I meant to include the parameters involved in key wrapping along with the actual octets of the wrapped key. Russ Housley nicely summarized on CFRG why these "algorithm substitution attacks" are not actually attacks. Whether or not cryptographically binding header information to the ciphertext is a "very good thing" depends on your application. Certainly, there are applications that do not care at all about this binding -- for example, applications that just want to use the header to carry encryption parameters, such as the current XMPP e2e proposal. Applications that do care should just wrap the JWE in a JWS to achieve that binding, instead of burdening every application in the world with their requirements. Header parameters specify inputs to encryption algorithms. If there is an attack that can be accomplished by changing the parameters of an algorithm, that is a flaw in the algorithm, and there's nothing this format can do to help. It's also rather naïve to claim that by adding integrity protection, you've taken away the attacker's ability to change things. The attacker can still change things and cause the recipient to perform unintended cryptographic operations, it's just that this will be detected later on. For example, suppose that an attacker intercepts an object encrypted with GCM, and changes it to use CBC+HMAC. The recipient will pull the "enc" parameter out of the header (the bad one, that says CBC+HMAC) and process the entire object before realizing that he's done the wrong thing. So all you've really done is shift from one class of oracle attacks to another. Taking all the above into consideration, we still have yet to hear a concrete security benefit to header integrity protection. On the other side, the recent CFRG thread demonstrates that there is real harm in header integrity protection, in that it is incompatible with GCM. GCM is not an acceptable cost. We should kill header integrity protection instead. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From dick.hardt@gmail.com Wed Apr 3 20:53:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9226011E80A4 for ; Wed, 3 Apr 2013 20:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRi6QIVSGOog for ; Wed, 3 Apr 2013 20:53:09 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id DCA6111E80A2 for ; Wed, 3 Apr 2013 20:53:09 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rq13so1204089pbb.6 for ; Wed, 03 Apr 2013 20:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=HrUkzqgvplSGC7cQW81WyPtgvJBf9C5BCBsmijnZPxY=; b=jsmknU3i95ZtopRZwSJGjDoVVOW64OEzbDBA29pt/usbKzV7utnZ5wEQla72W6E1Vm iLFybJEbLSlWOBb6MB+mrHPjdMONw4iYVmvBFDEkdgfrgcmYeCBlC2m9HkL0GzcTw742 h03pANnkSJkYVREHqD5NnBFuCM9svXBx6UbQOr/9/sFpjzH1hh5XrxlnPOjMd97EVl5u RcOHDDnkK7Xv2aKxtvWgE+Wx9w9krsEWUd3ILUcyPW0JdH66ldiQlDUlX8jJC/YbFLKO jw/70ifSBDVtrq2hGRpMEZZczGpWIo1lyjsEwW+G7ra2EvwfWBoXtnrA/XdGqahhrQOD VP9A== X-Received: by 10.66.49.229 with SMTP id x5mr7257956pan.185.1365047589508; Wed, 03 Apr 2013 20:53:09 -0700 (PDT) Received: from [10.0.0.58] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id s6sm8387587pbi.37.2013.04.03.20.53.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 20:53:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> Date: Wed, 3 Apr 2013 20:53:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> To: "jose issue tracker" X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:53:10 -0000 I don't think it is a JWT issue. JWT already reserves 'aud' and 'iss' = and defines them. There is a list of reserved header parameter names in JWE, and I would = like 'aud' and 'iss' to be added just like 'tip' is there. Unless the = list of reserved header parameter names in JWE is moving to JWT, then it = would seem REALLY confusing to an implementer to have to look in both = JWT and JWE to see what the list of reserved header parameter names is. = Or am I missing something?=20 As to your processing question, it they are present in the JWE header = and in the payload, then I would think that they must match. -- Dick On Apr 3, 2013, at 1:03 PM, "jose issue tracker" = wrote: > #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names > Comment (by michael.jones@microsoft.com): >=20 > I believe that this is a JWT issue =96 not a JOSE issue. I'd suggest = that > you re-file this issue to be considered for the JWT spec, Dick, and = close > it here, as it's JWT-specific. The OAuth issue tracker (which can be = used > for the JWT spec, since it's in the OAuth working group) is at > http://trac.tools.ietf.org/wg/oauth/trac/. >=20 > I think the real change you're requesting is to have the JWT spec add = the > "iss" and "aud" claims, which it defines, to the list of reserved JWE > header parameter values, and to say that the "iss" and "aud" claim = values > defined by the JWT spec may appear in the JWE header. The JWT spec = *can* > reserve JOSE header fields. (Any spec can, through use of the IANA > registry.) This doesn't have to be done in the JWE spec. >=20 > A processing question you'd need to answer is whether, if present in = the > JWE header, these claim values must also appear in the JWT Claims Set = with > identical values, or whether it's your intent to allow or require them = to > appear in exactly one of the two locations. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-jose-json-web- > dick.hardt@gmail.com | encryption@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > encryption | Resolution: > Severity: - | > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From trac+jose@trac.tools.ietf.org Wed Apr 3 20:57:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95F021E803A for ; Wed, 3 Apr 2013 20:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF0PrPBvJk8J for ; Wed, 3 Apr 2013 20:57:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 25C8321E8039 for ; Wed, 3 Apr 2013 20:57:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:34894 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNbIU-00054C-Sj; Thu, 04 Apr 2013 05:57:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, rlb@ipv.sx X-Trac-Project: jose Date: Thu, 04 Apr 2013 03:57:10 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:2 Message-ID: <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130404035716.25C8321E8039@ietfa.amsl.com> Resent-Date: Wed, 3 Apr 2013 20:57:15 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:57:16 -0000 #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Comment (by rlb@ipv.sx): I agree with Mike that these don't really belong in the core JWE/JWS specs. I would suggest we address this issue more generally, by creating an IANA registry of reserved parameter names, with a fairly liberal inclusion policy. That registry could have a field to indicate whether JOSE implementations are REQUIRED to support a given parameter (MTI parameters). (Note that this is different from whether a JOSE object is REQUIRED to contain a parameter.) Perhaps we could have optional parameters under a fairly liberal policy (e.g., Specification Required), with a higher bar for MTI parameters (e.g., Standards Action). If we set up the registry in this way, then Dick could write a short Informational document that would register these fields. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- dick.hardt@gmail.com | encryption@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From dick.hardt@gmail.com Wed Apr 3 21:29:25 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0221E8039 for ; Wed, 3 Apr 2013 21:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0CuoY19rRvT for ; Wed, 3 Apr 2013 21:29:24 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8C11E80A2 for ; Wed, 3 Apr 2013 21:29:24 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so992054pde.32 for ; Wed, 03 Apr 2013 21:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=pO+9K5fM7M3LloJbEArF3qXxZ8Gy5OKWQ03BxXGlePs=; b=fZKtAFh1nhEuQkPgxLML2vl032D/VBkmnuGIcpXtZ76ssED95oo/Q+ILJRR7W0OXDG 4cQBMEGikN4no8wGoV8e5nW70dyw6NyYFFDAJxcu+1MOLQl3XTFm0FPfDHnXRfsHdn1G zjzgbM317DmZqvZQTVn8exywgpIqaIpVhq9IRG5smFhDdhm9ibFkZ6lA7ZrXXEefkI3d 0W2PuE8h4p2A0+O0WGHnw37qsWoMv0kpIVVfOKRC4pgo4rM1IREaoIft1F9Q0LwcXHCR UZXo2v4OibYfuuoC0MYgaiozNzA2WNq2o5lwgsG9p9tz1ICnt6ZiWucnE4R3QPIhhEMJ 0KNw== X-Received: by 10.68.225.40 with SMTP id rh8mr6691905pbc.137.1365049764342; Wed, 03 Apr 2013 21:29:24 -0700 (PDT) Received: from [10.0.0.58] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id yz4sm3527775pbc.11.2013.04.03.21.29.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 21:29:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> Date: Wed, 3 Apr 2013 21:29:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> To: "jose issue tracker" X-Mailer: Apple Mail (2.1503) Cc: rlb@ipv.sx, draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 04:29:25 -0000 Actually, Mike was suggesting that the issue be moved to the JWT WG.=20 I'll settle with the JWE spec pointing to an IANA registry. Speaking as = an implementer, if there is a list of reserved names in the spec, I'm = likely to think that is all of them. I'm a little unsettled that no one else has had any feedback on having = 'aud' and 'iss' in the JWE header. Is my implementation the only that = has that requirement?=20 -- Dick On Apr 3, 2013, at 8:57 PM, "jose issue tracker" = wrote: > #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names >=20 >=20 > Comment (by rlb@ipv.sx): >=20 > I agree with Mike that these don't really belong in the core JWE/JWS > specs. >=20 > I would suggest we address this issue more generally, by creating an = IANA > registry of reserved parameter names, with a fairly liberal inclusion > policy. That registry could have a field to indicate whether JOSE > implementations are REQUIRED to support a given parameter (MTI > parameters). (Note that this is different from whether a JOSE object = is > REQUIRED to contain a parameter.) Perhaps we could have optional > parameters under a fairly liberal policy (e.g., Specification = Required), > with a higher bar for MTI parameters (e.g., Standards Action). >=20 > If we set up the registry in this way, then Dick could write a short > Informational document that would register these fields. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-jose-json-web- > dick.hardt@gmail.com | encryption@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > encryption | Resolution: > Severity: - | > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From housley@vigilsec.com Thu Apr 4 07:03:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DA721F8C45 for ; Thu, 4 Apr 2013 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmrostlzCPAs for ; Thu, 4 Apr 2013 07:03:18 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8661521F8738 for ; Thu, 4 Apr 2013 07:03:18 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 202B4F2406E; Thu, 4 Apr 2013 10:03:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id rIH-CAg3i-h2; Thu, 4 Apr 2013 10:03:02 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D5B93F2406D; Thu, 4 Apr 2013 10:03:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <064.ce3bcb37d79ccc16fe24f8188caf1ce8@trac.tools.ietf.org> Date: Thu, 4 Apr 2013 10:03:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B1E91BF-6F31-491B-960B-842096E88562@vigilsec.com> References: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> <064.ce3bcb37d79ccc16fe24f8188caf1ce8@trac.tools.ietf.org> To: Richard Barnes X-Mailer: Apple Mail (2.1085) Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, Mike Jones , jose@ietf.org Subject: Re: [jose] #13: Enable AEAD key wrapping X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:03:19 -0000 Richard: We need to make sure that the solution is algorithm agile. No matter = what we pick, it will need to change in some number of years. Also, when I design a cryptographic security solution, I tend to use one = mode for data and another mode for keying material. This approach = ensures that a decrypt operation will never return plaintext keying = material outside the crypto boundary. So, I strongly support the use of = AES-KW or AES-KWP for key wrapping. Russ On Apr 3, 2013, at 11:30 PM, jose issue tracker wrote: > #13: Enable AEAD key wrapping >=20 >=20 > Comment (by rlb@ipv.sx): >=20 > As I understood the feedback from WebCrypto, the desire was for = general > AEAD algorithms to be usable in both (1) and (2). And as I expressed = at > IETF86, it would be architecturally simpler if we use the same key > wrapping for all wrapped keys, whether attached to JWE or not. >=20 > A proposed solution has been submitted as http://tools.ietf.org/html > /draft-barnes-jose-key-wrapping >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > Type: defect | encryption@tools.ietf.org > Priority: major | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > jose From rlb@ipv.sx Thu Apr 4 09:08:41 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B5321F8653 for ; Thu, 4 Apr 2013 09:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m+oINzIAoXn for ; Thu, 4 Apr 2013 09:08:40 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5EC21F8634 for ; Thu, 4 Apr 2013 09:08:40 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uz6so2681903obc.22 for ; Thu, 04 Apr 2013 09:08:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FpPPcbcJIFLwJoRbOgaAQdLwCNJULYFRfc8Vn4jSh5A=; b=LX+0fT5RoS/QURENSk5Gi7bU//zxCA+1VNa3O+mFjs35RNF0/DvEqdPl3It79flDas YkWdZJU3jjmN1clVvisxQByo+hM9tTosyQhQxy9jnZnmtQUp7MvFv4fBmV/muo29kr13 2bZGCLOegClQgd2y4ThQS6JDh/XhD0pWBycvHIjXYeusskFBxxzD/xL5HE0jjsFhLrIZ OAGIWL0uI5cW3XQvk5nC3f+fe1gfdy0f7eySX5VhwHVFo2WHuPHg8v2vnRqFDkiUy7JD RxRlbYQ42uSST8J+N2siZnU9hdLhdbCoXw0kjmePTkAvAiatgDNEa8n6QeTjOA6aFB6u p/gg== MIME-Version: 1.0 X-Received: by 10.60.85.35 with SMTP id e3mr4838067oez.117.1365091719796; Thu, 04 Apr 2013 09:08:39 -0700 (PDT) Received: by 10.60.37.229 with HTTP; Thu, 4 Apr 2013 09:08:39 -0700 (PDT) X-Originating-IP: [128.33.85.80] In-Reply-To: <0B1E91BF-6F31-491B-960B-842096E88562@vigilsec.com> References: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> <064.ce3bcb37d79ccc16fe24f8188caf1ce8@trac.tools.ietf.org> <0B1E91BF-6F31-491B-960B-842096E88562@vigilsec.com> Date: Thu, 4 Apr 2013 12:08:39 -0400 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: multipart/alternative; boundary=089e0111be000bb99504d98b2f1d X-Gm-Message-State: ALoCoQk0mFdr/FsIi6VT6xuOMJ2lgl/f3qK3s02SU5Qe4dpcXnG2FvpIXyZlUkpxQKHa0L2HzlXk Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, Mike Jones , jose@ietf.org Subject: Re: [jose] #13: Enable AEAD key wrapping X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:08:41 -0000 --089e0111be000bb99504d98b2f1d Content-Type: text/plain; charset=ISO-8859-1 Hi Russ, There's no question of dropping support for AES-KW or AES-KWP. As you point out, the desire here is for algorithm agility. Currently, there's no way to support other AEAD algorithms besides those two. --Richard On Thu, Apr 4, 2013 at 10:03 AM, Russ Housley wrote: > Richard: > > We need to make sure that the solution is algorithm agile. No matter what > we pick, it will need to change in some number of years. > > Also, when I design a cryptographic security solution, I tend to use one > mode for data and another mode for keying material. This approach ensures > that a decrypt operation will never return plaintext keying material > outside the crypto boundary. So, I strongly support the use of AES-KW or > AES-KWP for key wrapping. > > Russ > > On Apr 3, 2013, at 11:30 PM, jose issue tracker wrote: > > > #13: Enable AEAD key wrapping > > > > > > Comment (by rlb@ipv.sx): > > > > As I understood the feedback from WebCrypto, the desire was for general > > AEAD algorithms to be usable in both (1) and (2). And as I expressed at > > IETF86, it would be architecturally simpler if we use the same key > > wrapping for all wrapped keys, whether attached to JWE or not. > > > > A proposed solution has been submitted as http://tools.ietf.org/html > > /draft-barnes-jose-key-wrapping > > > > -- > > > -------------------------+------------------------------------------------- > > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > > Type: defect | encryption@tools.ietf.org > > Priority: major | Status: new > > Component: json-web- | Milestone: > > encryption | Version: > > Severity: - | Resolution: > > Keywords: | > > > -------------------------+------------------------------------------------- > > > > Ticket URL: > > > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e0111be000bb99504d98b2f1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Russ,

There's no question of dropping support for= AES-KW or AES-KWP. =A0

As you point out, the desi= re here is for algorithm agility. =A0Currently, there's no way to suppo= rt other AEAD algorithms besides those two.

--Richard



On Thu, Apr 4, 2013 at 10:03 AM, Russ Housley <housley= @vigilsec.com> wrote:
Richard:

We need to make sure that the solution is algorithm agile. =A0No matter wha= t we pick, it will need to change in some number of years.

Also, when I design a cryptographic security solution, I tend to use one mo= de for data and another mode for keying material. This approach ensures tha= t a decrypt operation will never return plaintext keying material outside t= he crypto boundary. =A0So, I strongly support the use of AES-KW or AES-KWP = for key wrapping.

Russ

On Apr 3, 2013, at 11:30 PM, jose issue tracker wrote:

> #13: Enable AEAD key wrapping
>
>
> Comment (by rlb@ipv.sx):
>
> As I understood the feedback from WebCrypto, the desire was for genera= l
> AEAD algorithms to be usable in both (1) and (2). =A0And as I expresse= d at
> IETF86, it would be architecturally simpler if we use the same key
> wrapping for all wrapped keys, whether attached to JWE or not.
>
> A proposed solution has been submitted as http://tools.ietf.org/html
> /draft-barnes-jose-key-wrapping
>
> --
> -------------------------+--------------------------------------------= -----
> Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: =A0draft-ietf-jose-js= on-web-
> =A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
> Priority: =A0major =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
> Component: =A0json-web- =A0 =A0| =A0 Milestone:
> =A0encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac= /ticket/13#comment:3>
> jose <htt= p://tools.ietf.org/jose/>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e0111be000bb99504d98b2f1d-- From trac+jose@trac.tools.ietf.org Thu Apr 4 09:09:00 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DC321F9605 for ; Thu, 4 Apr 2013 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8sFGHN7RMuY for ; Thu, 4 Apr 2013 09:09:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4821F940E for ; Thu, 4 Apr 2013 09:08:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:40681 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNmib-00067l-Cv; Thu, 04 Apr 2013 18:08:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, michael.jones@microsoft.com, ietf@augustcellars.com X-Trac-Project: jose Date: Thu, 04 Apr 2013 16:08:53 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:5 Message-ID: <069.2a1329cf8922ee917257709317af64b8@trac.tools.ietf.org> References: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, michael.jones@microsoft.com, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130404160859.C0E4821F940E@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 09:08:59 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:09:00 -0000 #4: Remove wrapped keys from integrity check (allow separation of keys from data) Comment (by ietf@augustcellars.com): This issue has been refered to the CFRG mailing list in order to get a clearer idea of what the technical requirements are from the cryptographic perspective. After we get the feedback we can make the decision based on both the cryptographic and non-cryptographic criteria we have. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Thu Apr 4 09:11:45 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8B21F9643 for ; Thu, 4 Apr 2013 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z18u1U-KdPkO for ; Thu, 4 Apr 2013 09:11:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46F21F9648 for ; Thu, 4 Apr 2013 09:11:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:40773 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNmlC-0004PL-MW; Thu, 04 Apr 2013 18:11:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, rlb@ipv.sx, ietf@augustcellars.com X-Trac-Project: jose Date: Thu, 04 Apr 2013 16:11:34 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/10#comment:3 Message-ID: <069.86996beb08e2f66ee33cfb39b16c77ed@trac.tools.ietf.org> References: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, rlb@ipv.sx, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130404161144.4F46F21F9648@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 09:11:44 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #10: Remove implementation requirements X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:11:45 -0000 #10: Remove implementation requirements Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => wontfix Comment: The IESG has had a discussion on this issue as part of the recent charter discussions. The chairs believe that is is clear from that discussions that MTI algorithms are going to be required in order for the documents to progress. For that reason we are closing this ticket. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | algorithms@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: json-web- | Version: algorithms | Resolution: wontfix Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From Michael.Jones@microsoft.com Thu Apr 4 09:27:55 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69D921F9425 for ; Thu, 4 Apr 2013 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWTaBkUvWUui for ; Thu, 4 Apr 2013 09:27:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id E942921F93AA for ; Thu, 4 Apr 2013 09:27:54 -0700 (PDT) Received: from BY2FFO11FD027.protection.gbl (10.1.15.200) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.664.0; Thu, 4 Apr 2013 16:27:48 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Thu, 4 Apr 2013 16:27:48 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 4 Apr 2013 16:27:43 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Thread-Index: AQHOMOfwKd8uL4zx4Um/PWKBN2+o4JjGQCtQ Date: Thu, 4 Apr 2013 16:27:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> In-Reply-To: <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(24454001)(13464002)(51704002)(377454001)(199002)(46102001)(33656001)(79102001)(81542001)(50466001)(47976001)(49866001)(54316002)(16406001)(56816002)(46406002)(56776001)(31966008)(44976002)(77982001)(5343635001)(47736001)(59766001)(66066001)(47446002)(4396001)(65816001)(69226001)(63696002)(51856001)(54356001)(20776003)(5343655001)(55846006)(80022001)(74662001)(47776003)(15202345001)(81342001)(74502001)(76482001)(23726001)(50986001)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08062C429B Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose@ietf.org" Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:27:55 -0000 JWT defines "aud" and "iss" and reserves them as claim names but not as JWE= header parameter names, nor does it currently specify their usage in that = location. My point is that I think the best way to accomplish what you're = asking for is to have the JWT spec also reserve these as JWE header paramet= er names and define the semantics and processing rules associated with usin= g them in that location. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Wednesday, April 03, 2013 8:53 PM To: jose issue tracker Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Mike Jones; jose@ie= tf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Paramet= er Names I don't think it is a JWT issue. JWT already reserves 'aud' and 'iss' and d= efines them. There is a list of reserved header parameter names in JWE, and I would like= 'aud' and 'iss' to be added just like 'tip' is there. Unless the list of r= eserved header parameter names in JWE is moving to JWT, then it would seem = REALLY confusing to an implementer to have to look in both JWT and JWE to s= ee what the list of reserved header parameter names is. Or am I missing som= ething?=20 As to your processing question, it they are present in the JWE header and i= n the payload, then I would think that they must match. -- Dick On Apr 3, 2013, at 1:03 PM, "jose issue tracker" wrote: > #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names=20 > Comment (by michael.jones@microsoft.com): >=20 > I believe that this is a JWT issue - not a JOSE issue. I'd suggest=20 > that you re-file this issue to be considered for the JWT spec, Dick,=20 > and close it here, as it's JWT-specific. The OAuth issue tracker=20 > (which can be used for the JWT spec, since it's in the OAuth working=20 > group) is at http://trac.tools.ietf.org/wg/oauth/trac/. >=20 > I think the real change you're requesting is to have the JWT spec add=20 > the "iss" and "aud" claims, which it defines, to the list of reserved=20 > JWE header parameter values, and to say that the "iss" and "aud" claim=20 > values defined by the JWT spec may appear in the JWE header. The JWT=20 > spec *can* reserve JOSE header fields. (Any spec can, through use of=20 > the IANA > registry.) This doesn't have to be done in the JWE spec. >=20 > A processing question you'd need to answer is whether, if present in=20 > the JWE header, these claim values must also appear in the JWT Claims=20 > Set with identical values, or whether it's your intent to allow or=20 > require them to appear in exactly one of the two locations. >=20 > -- > -------------------------+-------------------------------------------- > -------------------------+----- > Reporter: | Owner: draft-ietf-jose-json-web- > dick.hardt@gmail.com | encryption@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > encryption | Resolution: > Severity: - | > Keywords: | > -------------------------+-------------------------------------------- > -------------------------+----- >=20 > Ticket URL:=20 > > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Thu Apr 4 09:33:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DAE21F946C for ; Thu, 4 Apr 2013 09:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Riv0AFv28JyX for ; Thu, 4 Apr 2013 09:33:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32E5521F93A9 for ; Thu, 4 Apr 2013 09:33:10 -0700 (PDT) Received: from BN1BFFO11FD005.protection.gbl (10.58.52.204) by BN1BFFO11HUB027.protection.gbl (10.58.53.137) with Microsoft SMTP Server (TLS) id 15.0.664.0; Thu, 4 Apr 2013 16:33:02 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD005.mail.protection.outlook.com (10.58.53.65) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Thu, 4 Apr 2013 16:32:57 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Thu, 4 Apr 2013 16:32:49 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Thread-Index: AQHOMJb9fKbFmdlEmkmugxkCWq4z8pjFb8gAgAAJAICAAMjAEA== Date: Thu, 4 Apr 2013 16:32:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> In-Reply-To: <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(51704002)(377454001)(13464002)(189002)(24454001)(76482001)(63696002)(56776001)(81342001)(54316002)(46102001)(16406001)(54356001)(74502001)(49866001)(51856001)(46406002)(23726001)(47776003)(59766001)(20776003)(80022001)(55846006)(5343655001)(69226001)(47736001)(77982001)(50986001)(50466001)(31966008)(65816001)(47976001)(47446002)(79102001)(4396001)(66066001)(74662001)(33656001)(56816002)(81542001)(53806001)(5343635001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB027; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08062C429B Cc: "rlb@ipv.sx" , "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose@ietf.org" Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:33:11 -0000 Responding to your "unsettled" remark, I suspect most people are fine with = having the "aud" and "iss" be claims in the JWT where they normally are. Y= es, you have to decrypt the token to get these claim values, but if you're = going to use the token, you'll have to do that anyway. I don't think it's clear to most people what problem is being solved by pot= entially these fields to be present in a different location. Without a com= pelling use case, this just seems like more to implement without a clear be= nefit of doing so. -- Mike -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Wednesday, April 03, 2013 9:29 PM To: jose issue tracker Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Mike Jones; rlb@ipv= .sx; jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Paramet= er Names Actually, Mike was suggesting that the issue be moved to the JWT WG.=20 I'll settle with the JWE spec pointing to an IANA registry. Speaking as an = implementer, if there is a list of reserved names in the spec, I'm likely t= o think that is all of them. I'm a little unsettled that no one else has had any feedback on having 'aud= ' and 'iss' in the JWE header. Is my implementation the only that has that = requirement?=20 -- Dick On Apr 3, 2013, at 8:57 PM, "jose issue tracker" wrote: > #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names >=20 >=20 > Comment (by rlb@ipv.sx): >=20 > I agree with Mike that these don't really belong in the core JWE/JWS=20 > specs. >=20 > I would suggest we address this issue more generally, by creating an=20 > IANA registry of reserved parameter names, with a fairly liberal=20 > inclusion policy. That registry could have a field to indicate=20 > whether JOSE implementations are REQUIRED to support a given parameter=20 > (MTI parameters). (Note that this is different from whether a JOSE=20 > object is REQUIRED to contain a parameter.) Perhaps we could have=20 > optional parameters under a fairly liberal policy (e.g., Specification=20 > Required), with a higher bar for MTI parameters (e.g., Standards Action). >=20 > If we set up the registry in this way, then Dick could write a short=20 > Informational document that would register these fields. >=20 > -- > -------------------------+-------------------------------------------- > -------------------------+----- > Reporter: | Owner: draft-ietf-jose-json-web- > dick.hardt@gmail.com | encryption@tools.ietf.org > Type: enhancement | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > encryption | Resolution: > Severity: - | > Keywords: | > -------------------------+-------------------------------------------- > -------------------------+----- >=20 > Ticket URL:=20 > > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From trac+jose@trac.tools.ietf.org Thu Apr 4 09:42:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8DC21F8D1C for ; Thu, 4 Apr 2013 09:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enS4h6uURf4y for ; Thu, 4 Apr 2013 09:42:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AE5A921F8D05 for ; Thu, 4 Apr 2013 09:42:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:42046 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNnEk-0004ju-TA; Thu, 04 Apr 2013 18:42:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-key@tools.ietf.org, michael.jones@microsoft.com, ietf@augustcellars.com X-Trac-Project: jose Date: Thu, 04 Apr 2013 16:42:06 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/16#comment:2 Message-ID: <073.1dc661959a15caad46917baec89b3440@trac.tools.ietf.org> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-key@tools.ietf.org, michael.jones@microsoft.com, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130404164210.AE5A921F8D05@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 09:42:10 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:42:11 -0000 #16: URI identifying a specific key in a JWK set Comment (by ietf@augustcellars.com): In order to evaluate this, we need to get a more detailed proposal than what we currently have. Examples of issues that have not been dealt with at this point are 1. Syntax of the fragment 2. dealing with duplicate values within a JWK structure 3. Definition of a new media type - is this required or not - justify either postion 4. Explain why the proposal is "better" than the current ability to have a url plus the kid in the message. 5. Discuss what happens if the fragment is not present on the url or if the fragment is not findable in the resultant document. If the fragment is going to be manditory does them mean that we should be doing a new scheme instead as fragments cannot be required under the current URL syntax defintions (or at least that is my reading). Please flesh out your proposal more so that it can be fully evaluated. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- james@manger.com.au | key@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: key | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From matake@gmail.com Thu Apr 4 11:18:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A289821F8BBC for ; Thu, 4 Apr 2013 11:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnGcGFVVkp43 for ; Thu, 4 Apr 2013 11:18:57 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1421F8BBB for ; Thu, 4 Apr 2013 11:18:56 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un15so1577568pbc.12 for ; Thu, 04 Apr 2013 11:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=f2InYMsD9DsMhImFiBIbT7XG6SZU2FZ1MTqQthEZDAU=; b=w+Jfsftk1iz11PR1IA3vgIxy1y9/okx/1KVOfe0QtB+etdvd/RZaYWUeH3vNFambNy sqOuKgAiIDs+sy0/dHOeks2adOq4Se9lfirvuXUGtQiCnyvKsQmm1m6FtK4rTK6GWen2 HXB+Z/eBtShhaWy1/ecCIQqozncQ8Uwc4j3t8TxLqgvSj8Ej87y7lZ24A6Hywyj6Mf3X gcg523fg03js7NR7zNVPtlh5J4pbqtkaHMjxwQHnpQygX7py/RpDy2H6p+NpEFFmkgKN EzZEQ04Zg7MkKbE2/Vyj+VhwNzo59lHnXsnlAoNGy3PB+LhC/HadA1p/O/Txdzh9OReo Zu1Q== X-Received: by 10.68.163.1 with SMTP id ye1mr10274939pbb.135.1365099536754; Thu, 04 Apr 2013 11:18:56 -0700 (PDT) Received: from [192.168.1.35] (ac149127.dynamic.ppp.asahi-net.or.jp. [183.77.149.127]) by mx.google.com with ESMTPS id bs1sm11100515pbc.8.2013.04.04.11.18.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 11:18:55 -0700 (PDT) From: nov matake Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 5 Apr 2013 03:18:52 +0900 Message-Id: <7B140AD1-1885-43FE-B428-792F86AA14D0@gmail.com> To: Mike Jones Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "jose@ietf.org" Subject: [jose] FYI: JWE implementation in Ruby X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:18:57 -0000 Hi Mike, I just added JWE support in my json-jwt ruby gem. https://github.com/nov/json-jwt supported alg: RSA1_5, RSA-OAEP and dir supported enc: A128GCM, A256GCM, A128CBC+HS256 and A256CBC+HS512 Plus, I think you had gathered supported crypto algorithms in each language. If you are still updating that, please let me know the link. Now I can update several fields. cheers, nov From ve7jtb@ve7jtb.com Thu Apr 4 11:53:07 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9951B21F93CC for ; Thu, 4 Apr 2013 11:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P6mQ2gYsO9T for ; Thu, 4 Apr 2013 11:53:06 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id AD99621F93DC for ; Thu, 4 Apr 2013 11:53:06 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so1614917qea.21 for ; Thu, 04 Apr 2013 11:53:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=GaOmBYV8Ysu3b8BL5+gsYMRiP83/Mg8vTQrCzIIuNkI=; b=DmBdXNvxuRMuLl8L4r9gdrMgbs7eh/gVxzL+n9GzWRR7laZBu5sWCuHm/eAHLMl7cb FJmUqcI5uV+J0iG0TYolJaRUjjZkNA4srUE4GsLOzXHW2OWr6KDoBuHSOmcsS/bUzd03 l2HnAFi1b9R6lof1gForqxR2YlAYpeabE6TZVbatRGijx3sr0nQpv+Rn0jeKggl2WURS ZUemkDzwp77NJzhojAjpoHgyYNImW3ZJAF1Fqj8zMl0VEdm5uc4cTLpW2Mz+rY59PGc7 ZDNk/NpcrzLiddKj7sdt20ad64YfM8MJttLeMee8FXUnme5ceIkgWylXkQRuY1BdHfqV SrZQ== X-Received: by 10.49.62.35 with SMTP id v3mr6422364qer.8.1365101586004; Thu, 04 Apr 2013 11:53:06 -0700 (PDT) Received: from [192.168.1.210] (190-20-54-248.baf.movistar.cl. [190.20.54.248]) by mx.google.com with ESMTPS id fr4sm11733535qab.3.2013.04.04.11.53.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 11:53:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EC182935-FABF-42D8-993E-E339462822C8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 4 Apr 2013 15:52:15 -0300 Message-Id: <5447C845-C9B7-4A43-8AFC-69E503B0F908@ve7jtb.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQn3SQBCmdTdOq89O5igMrpghMnSDht0/gmXZdOYZUFLACzUo/yHJZ3ln+YiUJ1wsCK4EccP Cc: "rlb@ipv.sx" , "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:53:07 -0000 --Apple-Mail=_EC182935-FABF-42D8-993E-E339462822C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not against having them as JWE header elements, I have raised the = point in several discussions. However given that the decryption key is generally already in the hands = of the RP it is hard to make the argument that a kid, thumbprint or jwk = object are not enough for the recipient to identify what decryption key = to use. I can see a use in a case like Matt Millers XMPP encryption example = where the sender doesn't know the public key of the recipient only its = name in that case the recipient won't have the decryption key and needs = to know in the unencrypted part of the message who to go and ask for the = key. I think in the XMPP case the recipient sends its public key and the = received "kid" back to the issuer and asks for the decryption key to be = encrypted by its public key and sent back. This is perhaps the sort of = thing where having the iss in the unencrypted envelope is a requirement. "aud" is also arguably useful if you have a multi hop situation where = the client needs to make a forwarding decision without creating yet = another level of wrapping for the token. So I do see uses for them. =20 I do agree with Mike that it may be best to use the definitions in JWT = and have the processing rule about what happens if you get the claim in = the header and in the body or if it is only in the header laid out = there. =20 The thing that is important in a JWE context is if those claims are = going to be integrity protected. There is continued debate about = removing the envelope from the integrity protection. That is a JWE = issue. I also think if they are in JWT as being allowed in the JWE = header referencing that from JWE is not a bad thing.=20 John B. On 2013-04-04, at 1:32 PM, Mike Jones = wrote: > Responding to your "unsettled" remark, I suspect most people are fine = with having the "aud" and "iss" be claims in the JWT where they normally = are. Yes, you have to decrypt the token to get these claim values, but = if you're going to use the token, you'll have to do that anyway. >=20 > I don't think it's clear to most people what problem is being solved = by potentially these fields to be present in a different location. = Without a compelling use case, this just seems like more to implement = without a clear benefit of doing so. >=20 > -- Mike >=20 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Wednesday, April 03, 2013 9:29 PM > To: jose issue tracker > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Mike Jones; = rlb@ipv.sx; jose@ietf.org > Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header = Parameter Names >=20 > Actually, Mike was suggesting that the issue be moved to the JWT WG.=20= >=20 > I'll settle with the JWE spec pointing to an IANA registry. Speaking = as an implementer, if there is a list of reserved names in the spec, I'm = likely to think that is all of them. >=20 > I'm a little unsettled that no one else has had any feedback on having = 'aud' and 'iss' in the JWE header. Is my implementation the only that = has that requirement?=20 >=20 > -- Dick >=20 > On Apr 3, 2013, at 8:57 PM, "jose issue tracker" = wrote: >=20 >> #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names >>=20 >>=20 >> Comment (by rlb@ipv.sx): >>=20 >> I agree with Mike that these don't really belong in the core JWE/JWS=20= >> specs. >>=20 >> I would suggest we address this issue more generally, by creating an=20= >> IANA registry of reserved parameter names, with a fairly liberal=20 >> inclusion policy. That registry could have a field to indicate=20 >> whether JOSE implementations are REQUIRED to support a given = parameter=20 >> (MTI parameters). (Note that this is different from whether a JOSE=20= >> object is REQUIRED to contain a parameter.) Perhaps we could have=20 >> optional parameters under a fairly liberal policy (e.g., = Specification=20 >> Required), with a higher bar for MTI parameters (e.g., Standards = Action). >>=20 >> If we set up the registry in this way, then Dick could write a short=20= >> Informational document that would register these fields. >>=20 >> -- >> = -------------------------+-------------------------------------------- >> -------------------------+----- >> Reporter: | Owner: draft-ietf-jose-json-web- >> dick.hardt@gmail.com | encryption@tools.ietf.org >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: json-web- | Version: >> encryption | Resolution: >> Severity: - | >> Keywords: | >> = -------------------------+-------------------------------------------- >> -------------------------+----- >>=20 >> Ticket URL:=20 >> >> jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_EC182935-FABF-42D8-993E-E339462822C8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDA0MTg1MjE2WjAjBgkqhkiG9w0BCQQxFgQUw2rJvZzz rusu0HfZryf9ag/s2fowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAbmwKBJaT+rcN/QTFfz5AvbnM4qj3d+SGtN7L+YoQ 5bYUflwU0/mJX5exJf9lj8X9pUCnFlw+FCCyTy2w1+vQxIX5AyYbY7rFE+fV+/fFAoLJkBLQVffD x+zDoTL4Iilu+EbSqOvNwdp2TT0yC8U5ZA5Ms+qJbXSCgmUR0DCNOSBo3PPRhZdb9ddr6tjxRvso iMgvctt13sw8/4eJfcv4rPkqrWQe0B0ZD+G78o0+ucyTARgHxVDH3uX3pwJMatTdROv24V3NLLjC Aj5ZmkkZwd44I5RoRCmdzjHP3XW8C5urMjxUfs0PK9DhnDzjY7oWCSaZuK/Ywm2jVd6PIlo0UQAA AAAAAA== --Apple-Mail=_EC182935-FABF-42D8-993E-E339462822C8-- From dick.hardt@gmail.com Thu Apr 4 13:10:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC321F8970 for ; Thu, 4 Apr 2013 13:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdearwwEvVNt for ; Thu, 4 Apr 2013 13:10:03 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95A21F8629 for ; Thu, 4 Apr 2013 13:10:03 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id 5so1623747pdd.3 for ; Thu, 04 Apr 2013 13:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=u62qKNRJSeSavASXcB3nB3b73KRLhVQJsDN0Hz8i1Mk=; b=JEtrijZ8/QNE3NVi3nYcj82XvcM9mn5mPO03xCoeFmUcY68/Sbtm/hFhdlsLuGE9dk mzEi8AQS/CVuOEYAMyHuUl3q9PKqD5rQ4oygRPnVcOmPjAqelOtwdKa+j65oF+ul6/wh y1vQ/dJZE1R+uPF4K/b+Y0gc4/3UHOwAeSvA9rgcL5N9tTEIsksSjuIw6Yne8FQ0rzVg 0+WTzP0Zn/zcReu6kbLzSCLv6sEqcfNUmF1IMiAGAJrNE90UnaDIniR3w+t+5H3jae2p HW59/VLLVv6FY3VT1rqt3KMn+inRaAA2mMgMjqVH6ZgPK2T7s70+KKE9n4DrJ7k1+l9R kFIA== X-Received: by 10.68.247.72 with SMTP id yc8mr10845616pbc.23.1365106203342; Thu, 04 Apr 2013 13:10:03 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id qh4sm12710485pac.8.2013.04.04.13.10.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:10:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 4 Apr 2013 13:09:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:10:04 -0000 On Apr 4, 2013, at 9:27 AM, Mike Jones = wrote: > JWT defines "aud" and "iss" and reserves them as claim names but not = as JWE header parameter names, nor does it currently specify their usage = in that location. My point is that I think the best way to accomplish = what you're asking for is to have the JWT spec also reserve these as JWE = header parameter names and define the semantics and processing rules = associated with using them in that location. Repeating that you think it is "best" is not educating me on *why* you = think it is "best"! The other reserved JWE header parameter names are not reserved in JWT. = The current list of reserved JWE header parameter names are in the JWE = document. Having another place to look for what names are reserved looks = inefficient and error prone unless ALL reserved JWE header parameter = names are listed in JWT. From dick.hardt@gmail.com Thu Apr 4 13:14:22 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2607221F87FB for ; Thu, 4 Apr 2013 13:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQeBLqHvP89R for ; Thu, 4 Apr 2013 13:14:21 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 032FE21F87D3 for ; Thu, 4 Apr 2013 13:14:20 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so1620476pdj.2 for ; Thu, 04 Apr 2013 13:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=49Gve64ay+Lb4Zgbyw/cZVXUAAjFgU/T1p840q+Uh3c=; b=oUDq06RdTQyNibD6G3/45gpwP7C341Aa4Pg/DZ3HEIYTIX7bzfi3lfu8Kmt41RIecv 5irL9iC0ia46timOPH/0ueasLMkcJ0inGgZ7iu5dU4813kkvQBY1omOLXC2Pu2gnc3g7 lvlzDNGz9U8zimfN/R+Fly8wMLE7OfkEXCO2Jukz24875JBv/6JZRBDrmfTNYcAhjrQv lmlikeQod4Mq1orLYtCkV/LuKqz4uFT39dpeJETKpUyeKKfGq1dK9Ee41kzbZ5qNNQoM 969dc2m1IRZnWLK9FL1Uv6faWZ+z3gvrQAu8HpBKJ6ibMWKfau/Dkbymxb6BMXXfaMzb Go0A== X-Received: by 10.68.213.193 with SMTP id nu1mr10609581pbc.178.1365106460760; Thu, 04 Apr 2013 13:14:20 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id fc8sm12681659pad.21.2013.04.04.13.14.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:14:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <5447C845-C9B7-4A43-8AFC-69E503B0F908@ve7jtb.com> Date: Thu, 4 Apr 2013 13:14:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <983B04CA-B478-443E-982D-023C14F06E18@gmail.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> <5447C845-C9B7-4A43-8AFC-69E503B0F908@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: "rlb@ipv.sx" , "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Mike Jones , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:14:22 -0000 On Apr 4, 2013, at 11:52 AM, John Bradley wrote: > I am not against having them as JWE header elements, I have raised the = point in several discussions. >=20 > However given that the decryption key is generally already in the = hands of the RP it is hard to make the argument that a kid, thumbprint = or jwk object are not enough for the recipient to identify what = decryption key to use. See my example >=20 > I can see a use in a case like Matt Millers XMPP encryption example = where the sender doesn't know the public key of the recipient only its = name in that case the recipient won't have the decryption key and needs = to know in the unencrypted part of the message who to go and ask for the = key. >=20 > I think in the XMPP case the recipient sends its public key and the = received "kid" back to the issuer and asks for the decryption key to be = encrypted by its public key and sent back. This is perhaps the sort of = thing where having the iss in the unencrypted envelope is a requirement. >=20 > "aud" is also arguably useful if you have a multi hop situation where = the client needs to make a forwarding decision without creating yet = another level of wrapping for the token. I have potential multi hop that requires "aud" >=20 > So I do see uses for them. =20 >=20 > I do agree with Mike that it may be best to use the definitions in JWT = and have the processing rule about what happens if you get the claim in = the header and in the body or if it is only in the header laid out = there. =20 >=20 > The thing that is important in a JWE context is if those claims are = going to be integrity protected. There is continued debate about = removing the envelope from the integrity protection. That is a JWE = issue. I also think if they are in JWT as being allowed in the JWE = header referencing that from JWE is not a bad thing.=20 I would think it would make sense to have one list of reserved JWE = header parameters, not two. Of course, additional ones may be defined in = an IANA registry.=20= From dick.hardt@gmail.com Thu Apr 4 13:42:31 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AC021F8CB5 for ; Thu, 4 Apr 2013 13:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdwo0f7nAexZ for ; Thu, 4 Apr 2013 13:42:31 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 53F6E21F8C14 for ; Thu, 4 Apr 2013 13:42:31 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so1403203pdj.6 for ; Thu, 04 Apr 2013 13:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=kv1m03fENvd15Ls14HSGYCcDL12m2DZWYyavrhje6D0=; b=ECIPdw12ADmHQpPbw0Jrpevg2ul3K9wu3kQSpSEATAiy/nbEc+bX4aQos/WE90tsuH cvz7YphSGZARHQn0kJL5j9x5lQdz0M6tLSBEBPC2Gta4a6rj4UuYtYG7H4Y1KqbrtHJB fmRf9MhigyIvrWqT2gA91RmxEen30WtGMG2ylCAoODzeXyV9LqydmddRnDzYwtxt85Nt w2XhPJEg7YeP6rz0I7xwZDdUiBtels9dy+weheAwnXKPMpPi32v/AQQX4nSDdHkss3BF 9gwhEsBS7wQpi00zm9kydVlfVv3Cu8z6mj125++YEUHPVHNR4xdrqldyHyvm04c8UFtp jwJw== X-Received: by 10.67.1.39 with SMTP id bd7mr11223538pad.194.1365108151009; Thu, 04 Apr 2013 13:42:31 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id kt5sm11403808pbc.30.2013.04.04.13.42.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:42:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 4 Apr 2013 13:42:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5798695B-C14A-4603-BEB7-18A3354DFB77@gmail.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: rlb@ipv.sx, draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:42:32 -0000 On Apr 4, 2013, at 9:32 AM, Mike Jones = wrote: > Responding to your "unsettled" remark, I suspect most people are fine = with having the "aud" and "iss" be claims in the JWT where they normally = are. Yes, you have to decrypt the token to get these claim values, but = if you're going to use the token, you'll have to do that anyway. >=20 > I don't think it's clear to most people what problem is being solved = by potentially these fields to be present in a different location. = Without a compelling use case, this just seems like more to implement = without a clear benefit of doing so. I will see if I can explain the use case better. Why "iss" is needed: Bob and Charlie each gave Alice a KID and a symmetric key to use to = verify and decrypt tokens from them.=20 The App and Alice share keys so Alice knows it is the App. The User authorizes Bob to give the App a token (which authorizes the = App to do something) The App gives the token to Alice. Since Alice indirectly received the token, the only way for Alice to = know who sent the token, is to look at the KID as the "iss" claim is = encrypted. If the "kid" values are GUIDs, then Alice can just look up = the "kid" and retrieve the associated symmetric key, and then decrypt = and verify the token and THEN see who sent it. If there is a collision = in KID values (Bon and Charlie gave the same KID for different keys), = then Alice will not know which symmetric key to use. Why "aud" is needed: Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and = symmetric key to Gwen.=20 Ellen and Gwen trust each other and know how to talk to each other. Gwen = does not know Dave. Ellen does not know Frank The App and Gwen share keys so Gwen knows it is the App. The User authorizes Dave to give the App a token Dave gives the token to Gwen (Dave does not have a relationship with = Ellen) Gwen now has a token that Ellen can decrypt and verify, but has no = method for knowing that Ellen can do that. The "aud" property would = allow Gwen to give the token to Ellen to decrypt and verify. Feel free to ask for clarifications. This is what is happening in A2P3 that enables a distributed system. -- Dick From Michael.Jones@microsoft.com Thu Apr 4 16:03:52 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE59821F8A52 for ; Thu, 4 Apr 2013 16:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zP9ZuR9zH88 for ; Thu, 4 Apr 2013 16:03:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8C21F8A4E for ; Thu, 4 Apr 2013 16:03:51 -0700 (PDT) Received: from BY2FFO11FD001.protection.gbl (10.1.15.200) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.664.0; Thu, 4 Apr 2013 23:03:38 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Thu, 4 Apr 2013 23:03:38 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Thu, 4 Apr 2013 23:03:36 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Thread-Index: AQHOMOfwKd8uL4zx4Um/PWKBN2+o4JjGQCtQgAA+xwCAAC0UQA== Date: Thu, 4 Apr 2013 23:03:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B568E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(13464002)(377454001)(56816002)(33656001)(81542001)(50466001)(49866001)(56776001)(54316002)(79102001)(47976001)(16406001)(46406002)(31966008)(47446002)(5343635001)(44976002)(77982001)(47736001)(66066001)(65816001)(4396001)(59766001)(80022001)(69226001)(63696002)(51856001)(54356001)(5343655001)(74662001)(20776003)(74502001)(46102001)(15202345001)(76482001)(81342001)(55846006)(23726001)(50986001)(53806001)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; H:TK5EX14HUBC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08062C429B Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose@ietf.org" Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 23:03:53 -0000 I think it's better for three reasons. First, I think it's better to reser= ve the names and define the new processing rules in the document where they= 're defined - the JWT spec. Second, the "iss" and "aud" header values aren't meaningful in JWEs in the = general case - only in JWEs whose message is a JWT Claims Set. That's a sc= oping argument that they shouldn't be defined in the JWE spec. Third, as is normal for IETF specs, the "one place to look for reserved JWE= header names" is the IANA registry for those names. Yes, the JWE spec res= erves an initial set of names, but it won't be the only spec to reserve hea= der parameter names, and so to see the full list, developers have to consul= t the registry. -- Mike P.S. There's already an example of the JWT spec reserving names in a regis= try defined by the JWS spec. See http://tools.ietf.org/html/draft-ietf-oau= th-json-web-token-06#section-9.3.1. Reserving header parameter names in th= e JSON Web Signature and Encryption Header Parameters Registry established = in JWS (see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-0= 8#section-7.1.1) would be done in an analogous manner. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Thursday, April 04, 2013 1:10 PM To: Mike Jones Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Paramet= er Names On Apr 4, 2013, at 9:27 AM, Mike Jones wrote: > JWT defines "aud" and "iss" and reserves them as claim names but not as J= WE header parameter names, nor does it currently specify their usage in tha= t location. My point is that I think the best way to accomplish what you'r= e asking for is to have the JWT spec also reserve these as JWE header param= eter names and define the semantics and processing rules associated with us= ing them in that location. Repeating that you think it is "best" is not educating me on *why* you thin= k it is "best"! The other reserved JWE header parameter names are not reserved in JWT. The = current list of reserved JWE header parameter names are in the JWE document= . Having another place to look for what names are reserved looks inefficien= t and error prone unless ALL reserved JWE header parameter names are listed= in JWT. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Thu Apr 4 16:28:45 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD3621F8C0C for ; Thu, 4 Apr 2013 16:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4-1oonjXFTc for ; Thu, 4 Apr 2013 16:28:43 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7838E21F8C7D for ; Thu, 4 Apr 2013 16:28:42 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bg2so1713703pad.23 for ; Thu, 04 Apr 2013 16:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=M5x7Q67d4JjMKLfrK8w0LST/QpYqaNjspQfhnU81qpM=; b=g8EB0L3QnKQvmQJPkHStIqwNPxjh9Dv1QY+rj2WPMnBHY0GA0SA4V7CimigV9GIlMl t2FiYhLhJ+fJs9TDURRsuVUPUVw/OJtzuTZfqw4DbKHUr27NYRI3drwWDdB2KlabbJR8 iIPkUT2A0In2R1ghFB/cSt/2ONHKWgRgL17HwX8G0YZ9ddYRRWGyiF2ANgAJd6q+miTC MhjLUzNHqt2aGnmq/ErqLf4Ab1d9fLgFP3A9otgHFEM3KrKcRViJvU867oyaRRalz2k1 6774zxS4x2qyfo44LNUbLYutA9VMGwY2JqT/mr2ZYtCyM8xZcwt9dfZn1zZSaSoBkuW7 pTFQ== X-Received: by 10.68.220.230 with SMTP id pz6mr11465058pbc.46.1365118121170; Thu, 04 Apr 2013 16:28:41 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id ri1sm11856231pbc.16.2013.04.04.16.28.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 16:28:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B568E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 4 Apr 2013 16:28:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <341176CF-D47E-4209-A086-3FD9BC4A7BE0@gmail.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B568E@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 23:28:45 -0000 On Apr 4, 2013, at 4:03 PM, Mike Jones = wrote: > I think it's better for three reasons. First, I think it's better to = reserve the names and define the new processing rules in the document = where they're defined - the JWT spec. Um, so why are the other header parameter names in JWT? I'm arguing for = consistency. >=20 > Second, the "iss" and "aud" header values aren't meaningful in JWEs in = the general case - only in JWEs whose message is a JWT Claims Set. = That's a scoping argument that they shouldn't be defined in the JWE = spec. When I look at it as an implementer, the "iss" and "aud" are used to = make a decision in how to process (decrypt) the message and are just as = useful as the "kid" or any of the other crypto fields that are in the = header. >=20 > Third, as is normal for IETF specs, the "one place to look for = reserved JWE header names" is the IANA registry for those names. Yes, = the JWE spec reserves an initial set of names, but it won't be the only = spec to reserve header parameter names, and so to see the full list, = developers have to consult the registry. Sure. When was the last time you looked at the registry? I've looked = once to see all the URI schemes. I understand that is the "official" list, but many people will view the = list in the spec as the list unless there are lots of other ones in the = registry. I'm speaking practically as to what happens. >=20 > -- Mike >=20 > P.S. There's already an example of the JWT spec reserving names in a = registry defined by the JWS spec. See = http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.3.= 1. Reserving header parameter names in the JSON Web Signature and = Encryption Header Parameters Registry established in JWS (see = http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-7= .1.1) would be done in an analogous manner. So why don't we put ALL the reserved header names there so that we are = consistent? >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Thursday, April 04, 2013 1:10 PM > To: Mike Jones > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org > Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header = Parameter Names >=20 >=20 > On Apr 4, 2013, at 9:27 AM, Mike Jones = wrote: >=20 >> JWT defines "aud" and "iss" and reserves them as claim names but not = as JWE header parameter names, nor does it currently specify their usage = in that location. My point is that I think the best way to accomplish = what you're asking for is to have the JWT spec also reserve these as JWE = header parameter names and define the semantics and processing rules = associated with using them in that location. >=20 > Repeating that you think it is "best" is not educating me on *why* you = think it is "best"! >=20 > The other reserved JWE header parameter names are not reserved in JWT. = The current list of reserved JWE header parameter names are in the JWE = document. Having another place to look for what names are reserved looks = inefficient and error prone unless ALL reserved JWE header parameter = names are listed in JWT. >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Apr 4 16:42:02 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2133221F8F0E for ; Thu, 4 Apr 2013 16:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8698H3w29ek for ; Thu, 4 Apr 2013 16:42:01 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17B21F8F08 for ; Thu, 4 Apr 2013 16:42:00 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id EBCE52CA07; Thu, 4 Apr 2013 16:41:57 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Dick Hardt'" References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B568E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B568E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 4 Apr 2013 16:41:20 -0700 Message-ID: <016901ce318d$ea623ee0$bf26bca0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEzXhH2pSU7uxMrGauMbrRnhFTZDAJsycXiAmvRN/gBt3K1ywJkbK2YAWJr2oaZqadQAA== Content-Language: en-us Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 23:42:02 -0000 Mike, I want to make sure that I understand how the registry is going to work. After I get an answer I will go back and review the document to make sure that it is both clear and consistent with your response. It is clear that any document (not just an IETF document) can create a new entry in the header registry. Once this has been done there are two possible results: 1. The resulting registration is for a specific protocol - thus if the JWT document registers iss and aud they would be specific for to the JWT documents or 2. The resulting registration is permitted for any protocol - thus the JWT document would be required to provide clear documentation about how the iss and aud header fields would operate for any potential new protocol that wanted to use these header fields. I think that both you and the WG believe that the second statement is correct. This is just a verification for me personally. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Thursday, April 04, 2013 4:04 PM > To: Dick Hardt > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org > Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter > Names > > I think it's better for three reasons. First, I think it's better to reserve the > names and define the new processing rules in the document where they're > defined - the JWT spec. > > Second, the "iss" and "aud" header values aren't meaningful in JWEs in the > general case - only in JWEs whose message is a JWT Claims Set. That's a > scoping argument that they shouldn't be defined in the JWE spec. > > Third, as is normal for IETF specs, the "one place to look for reserved JWE > header names" is the IANA registry for those names. Yes, the JWE spec > reserves an initial set of names, but it won't be the only spec to reserve > header parameter names, and so to see the full list, developers have to > consult the registry. > > -- Mike > > P.S. There's already an example of the JWT spec reserving names in a registry > defined by the JWS spec. See http://tools.ietf.org/html/draft-ietf-oauth-json- > web-token-06#section-9.3.1. Reserving header parameter names in the JSON > Web Signature and Encryption Header Parameters Registry established in JWS > (see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section- > 7.1.1) would be done in an analogous manner. > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Dick Hardt > Sent: Thursday, April 04, 2013 1:10 PM > To: Mike Jones > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org > Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter > Names > > > On Apr 4, 2013, at 9:27 AM, Mike Jones > wrote: > > > JWT defines "aud" and "iss" and reserves them as claim names but not as > JWE header parameter names, nor does it currently specify their usage in that > location. My point is that I think the best way to accomplish what you're > asking for is to have the JWT spec also reserve these as JWE header > parameter names and define the semantics and processing rules associated > with using them in that location. > > Repeating that you think it is "best" is not educating me on *why* you think it > is "best"! > > The other reserved JWE header parameter names are not reserved in JWT. > The current list of reserved JWE header parameter names are in the JWE > document. Having another place to look for what names are reserved looks > inefficient and error prone unless ALL reserved JWE header parameter > names are listed in JWT. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Apr 4 16:48:45 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB49F21F8BBC for ; Thu, 4 Apr 2013 16:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6yaBDYUGG0Q for ; Thu, 4 Apr 2013 16:48:45 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4252721F8B64 for ; Thu, 4 Apr 2013 16:48:45 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8CFA82CA00 for ; Thu, 4 Apr 2013 16:48:44 -0700 (PDT) From: "Jim Schaad" To: References: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> In-Reply-To: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> Date: Thu, 4 Apr 2013 16:48:05 -0700 Message-ID: <017901ce318e$dc7c6520$95752f60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVtGiZD+ejgU/m+d7nyMc0S6wm15g3tIoQ Content-Language: en-us Subject: Re: [jose] Consensus calls X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 23:48:45 -0000 I have not seen any objections to these resolutions. The document editors should therefore act on them. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:25 PM > To: jose@ietf.org > Subject: [jose] Consensus calls > > > > The following "decisions" were made at the face to face meeting. This > message is to ratify these decisions on the list. You have one week to object > and provide a solid defense of your objection or the actions will be > considered as adopted. Note that for some of these we are running slightly > ahead of our charter changes but this is not expected to be a problem > > 1. Adopt the proposed compromise language from John Bradley's > presentation dealing with the critical language. This is to adopt points 1, 2, 3 > and 4 but not point 5. (presentation is available on the materials website > http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). > > 2. The private fields of public/private key algorithms and the symmetric key > field are to be folded into the mail JWA draft. > > 3. The multiple recipient/signer serialization drafts are to be folded into the > JWE and JWS drafts respectively. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Apr 4 16:51:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0401421F8BF8 for ; Thu, 4 Apr 2013 16:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R915w35DApw for ; Thu, 4 Apr 2013 16:51:46 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id E8E6B21F8AC3 for ; Thu, 4 Apr 2013 16:51:45 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 4D82B38F24 for ; Thu, 4 Apr 2013 16:51:45 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 4 Apr 2013 16:51:07 -0700 Message-ID: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4xjwlItr+CaRraTdmKwkwJbuMokQ== Content-Language: en-us Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 23:51:48 -0000 At the request of the editors, this is a formal consensus call on the first item in the list below. If there are objects to use a single long key rather than a KDF function for the AES-CBC/HMAC algorithm please speak up now. To date nobody has said that I was wrong to assume the consensus on that item. Call ends in one week. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:21 PM > To: jose@ietf.org > Subject: [jose] Use of AES-HMAC algorithm > > > After spending time looking at and thinking about how to resolve this issue > since I was unable to do so at the last F2F meeting. I have come up with the > following set of issues that might need to be addressed as part of resolving > this issue. > > 1. Do we change from using KDC to having a double size key for the > algorithm? I think that there is probably a consensus that this should be done. > > 2. Should IVs be prepended to the encrypted body as part of the encoding > steps? If so then this change should be universal. > > Doing so would eliminate one field from all of the encoding formats which > should be considered a plus. > Doing so would force code writers to understand how large the IV is for all > algorithms as the IV would no longer be a separate item. > > 3. Should Authentication Tags be appended to the encrypted body as part of > the encoding steps? > > Doing so would eliminate one field from all of the encoding formats which > should be considered a plus. > Doing so would force code writers to understand how large the IV is for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case as > either all recipient specific data would need to be excluded from the > authentication step or all of the recipient data would need to be included for > by all recipients. > Changing how the recipient info is process is going to give a performance > benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and different > authentication data needs to have CFRG look at it. I am worried that it might > be a serious security flaw. > > 4. Should we reference the McGrew draft and provide text on how things are > changed or should we "copy" the draft into our text? > > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, > does this change how we think about any of the above questions? > > Allowing for AES-GCM for key wrapping has a benefit for hardware situations > as only the encrypt and not the decrypt functions need to be placed in > hardware. However allowing for this key wrapping give a problem as there is > no way to encode the three fields into the encrypted value unless with use > either a JSON structure in this location or we do use the single appended > binary output stream. The first approach leads to an expansion of the field by > double base64 encoding which is highly undesirable. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Thu Apr 4 16:57:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AB121F8E69 for ; Thu, 4 Apr 2013 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=-1.490, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwo-x99QTJD9 for ; Thu, 4 Apr 2013 16:57:09 -0700 (PDT) Received: from mail-da0-x235.google.com (mail-da0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id B15A721F8DFB for ; Thu, 4 Apr 2013 16:57:09 -0700 (PDT) Received: by mail-da0-f53.google.com with SMTP id n34so1333689dal.26 for ; Thu, 04 Apr 2013 16:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=qe1wIMYE6rDYWEsRAjo4Y4iKXIf0qmC8mx22ttAYozk=; b=Nqu5a493tnzG12CviAAVw5Dq1e3X1hPpqFe3gTVJwtDdv2IpYuBTxKLZ4CM2Zh9/bf t9HS1/6IS8qoFrVCmxvP98xn94YL+2ZtzO/UOp7cCpGCwQ0j4m+hmpPL87QEyAuObZc3 HDCMtLlT5wa+7sFG++I1kYxo4+BhD+v59qcrJ32LTYCKqsDtYZIJObjJEhu7ivx614QN 2Q2IVZOMik9zuS3Lb/ktKSjze3bygsWcc1iyi+oIWZErJJCfjpzKrPj5S0QvwDuL+AyP G7VWVq2/jHKtrHlJBsYztYlQOVGfMC0Igj8mRhG/TB3TS8LUWlRXnPTD73hcrb5h+oe2 9hZA== X-Received: by 10.68.225.73 with SMTP id ri9mr11745184pbc.70.1365119829383; Thu, 04 Apr 2013 16:57:09 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id ql7sm11961043pbb.2.2013.04.04.16.57.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 16:57:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> Date: Thu, 4 Apr 2013 16:57:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1ED8FC21-D2C5-43BA-9E8A-982CB99DB2CC@gmail.com> References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 23:57:10 -0000 Having already implemented the KDF in the spec, I have a minor = preference to keep it how it is, but no animals will need to be = sacrificed if I have to change. =20 On Apr 4, 2013, at 4:51 PM, "Jim Schaad" wrote: > =20 >=20 > At the request of the editors, this is a formal consensus call on the = first > item in the list below. If there are objects to use a single long key > rather than a KDF function for the AES-CBC/HMAC algorithm please speak = up > now. To date nobody has said that I was wrong to assume the consensus = on > that item. >=20 > Call ends in one week. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Jim >> Schaad >> Sent: Wednesday, March 27, 2013 3:21 PM >> To: jose@ietf.org >> Subject: [jose] Use of AES-HMAC algorithm >>=20 >> >> After spending time looking at and thinking about how to resolve this > issue >> since I was unable to do so at the last F2F meeting. I have come up = with > the >> following set of issues that might need to be addressed as part of > resolving >> this issue. >>=20 >> 1. Do we change from using KDC to having a double size key for the >> algorithm? I think that there is probably a consensus that this = should be > done. >>=20 >> 2. Should IVs be prepended to the encrypted body as part of the = encoding >> steps? If so then this change should be universal. >>=20 >> Doing so would eliminate one field from all of the encoding formats = which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is = for > all >> algorithms as the IV would no longer be a separate item. >>=20 >> 3. Should Authentication Tags be appended to the encrypted body as = part of >> the encoding steps? >>=20 >> Doing so would eliminate one field from all of the encoding formats = which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is = for > all >> algorithms as the IV would no longer be a separate item. >> Doing so would force a re-organization for the multiple recipient = case as >> either all recipient specific data would need to be excluded from the >> authentication step or all of the recipient data would need to be = included > for >> by all recipients. >> Changing how the recipient info is process is going to give a = performance >> benefit for sending encrypted items for multiple recipients. >> The current strategy of a single IV and key pair with AES-GCM and > different >> authentication data needs to have CFRG look at it. I am worried that = it > might >> be a serious security flaw. >>=20 >> 4. Should we reference the McGrew draft and provide text on how = things are >> changed or should we "copy" the draft into our text? >>=20 >> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key = wrapping, >> does this change how we think about any of the above questions? >>=20 >> Allowing for AES-GCM for key wrapping has a benefit for hardware > situations >> as only the encrypt and not the decrypt functions need to be placed = in >> hardware. However allowing for this key wrapping give a problem as = there > is >> no way to encode the three fields into the encrypted value unless = with use >> either a JSON structure in this location or we do use the single = appended >> binary output stream. The first approach leads to an expansion of = the > field by >> double base64 encoding which is highly undesirable. >>=20 >> Jim >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Thu Apr 4 17:06:58 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB12B21F8F4A for ; Thu, 4 Apr 2013 17:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuqAkFPqrY48 for ; Thu, 4 Apr 2013 17:06:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id C2BA921F8EF1 for ; Thu, 4 Apr 2013 17:06:57 -0700 (PDT) Received: from BY2FFO11FD019.protection.gbl (10.1.15.203) by BY2FFO11HUB007.protection.gbl (10.1.14.165) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 00:06:44 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 00:06:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 00:06:36 +0000 From: Mike Jones To: Jim Schaad , 'Dick Hardt' Thread-Topic: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Thread-Index: AQHOMY4K/CBXlejW1k6UsatNlgmVrZjGv6cw Date: Fri, 5 Apr 2013 00:06:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B5B79@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.0ab64512938724c4d95e33c537c743e4@trac.tools.ietf.org> <56E2D113-F689-4C41-93AF-3C0DB8E70A6C@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F18@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B568E@TK5EX14MBXC283.redmond.corp.microsoft.com> <016901ce318d$ea623ee0$bf26bca0$@augustcellars.com> In-Reply-To: <016901ce318d$ea623ee0$bf26bca0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(51444002)(13464002)(24454001)(377454001)(54356001)(15202345001)(80022001)(31966008)(63696002)(47976001)(5343635001)(20776003)(49866001)(50986001)(5343655001)(56816002)(77982001)(47776003)(65816001)(81342001)(55846006)(74502001)(50466001)(69226001)(44976002)(56776001)(74662001)(23726001)(16406001)(54316002)(33656001)(47736001)(76482001)(46406002)(4396001)(79102001)(66066001)(81542001)(47446002)(53806001)(59766001)(51856001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB007; H:TK5EX14HUBC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , "jose@ietf.org" Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 00:06:58 -0000 Yes, I believe that the intent is 2 - these are global registrations. -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Thursday, April 04, 2013 4:41 PM To: Mike Jones; 'Dick Hardt' Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: RE: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Paramet= er Names Mike, I want to make sure that I understand how the registry is going to work. After I get an answer I will go back and review the document to make sure t= hat it is both clear and consistent with your response. It is clear that any document (not just an IETF document) can create a new = entry in the header registry. Once this has been done there are two possib= le results: 1. The resulting registration is for a specific protocol - thus if the JWT= document registers iss and aud they would be specific for to the JWT docum= ents or 2. The resulting registration is permitted for any protocol - thus= the JWT document would be required to provide clear documentation about ho= w the iss and aud header fields would operate for any potential new protoco= l that wanted to use these header fields. I think that both you and the WG believe that the second statement is corre= ct. This is just a verification for me personally. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Mike Jones > Sent: Thursday, April 04, 2013 4:04 PM > To: Dick Hardt > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org > Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter > Names >=20 > I think it's better for three reasons. First, I think it's better to reserve the > names and define the new processing rules in the document where=20 > they're defined - the JWT spec. >=20 > Second, the "iss" and "aud" header values aren't meaningful in JWEs in=20 > the general case - only in JWEs whose message is a JWT Claims Set. =20 > That's a scoping argument that they shouldn't be defined in the JWE spec. >=20 > Third, as is normal for IETF specs, the "one place to look for=20 > reserved JWE > header names" is the IANA registry for those names. Yes, the JWE spec=20 > reserves an initial set of names, but it won't be the only spec to=20 > reserve header parameter names, and so to see the full list,=20 > developers have to consult the registry. >=20 > -- Mike >=20 > P.S. There's already an example of the JWT spec reserving names in a registry > defined by the JWS spec. See http://tools.ietf.org/html/draft-ietf-oauth-json- > web-token-06#section-9.3.1. Reserving header parameter names in the=20 > JSON Web Signature and Encryption Header Parameters Registry=20 > established in JWS (see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section- > 7.1.1) would be done in an analogous manner. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Dick Hardt > Sent: Thursday, April 04, 2013 1:10 PM > To: Mike Jones > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org > Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter > Names >=20 >=20 > On Apr 4, 2013, at 9:27 AM, Mike Jones > wrote: >=20 > > JWT defines "aud" and "iss" and reserves them as claim names but not=20 > > as > JWE header parameter names, nor does it currently specify their usage=20 > in that > location. My point is that I think the best way to accomplish what=20 > you're asking for is to have the JWT spec also reserve these as JWE=20 > header parameter names and define the semantics and processing rules=20 > associated with using them in that location. >=20 > Repeating that you think it is "best" is not educating me on *why* you think it > is "best"! >=20 > The other reserved JWE header parameter names are not reserved in JWT. > The current list of reserved JWE header parameter names are in the JWE=20 > document. Having another place to look for what names are reserved=20 > looks inefficient and error prone unless ALL reserved JWE header=20 > parameter names are listed in JWT. >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Thu Apr 4 17:14:00 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5656221F90F1 for ; Thu, 4 Apr 2013 17:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr5eiOXJStwA for ; Thu, 4 Apr 2013 17:13:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 597F421F93C7 for ; Thu, 4 Apr 2013 17:13:59 -0700 (PDT) Received: from BY2FFO11FD002.protection.gbl (10.1.15.202) by BY2FFO11HUB014.protection.gbl (10.1.14.86) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 00:13:46 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 00:13:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 00:13:34 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Use of AES-HMAC algorithm - Consensus Request Thread-Index: Ac4xjwlItr+CaRraTdmKwkwJbuMokQAAzTPg Date: Fri, 5 Apr 2013 00:13:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B5BDC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> In-Reply-To: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(35754002)(377454001)(51444002)(51704002)(47446002)(50466001)(20776003)(80022001)(47976001)(47776003)(47736001)(79102001)(56776001)(59766001)(46102001)(63696002)(31966008)(49866001)(4396001)(51856001)(74662001)(54316002)(77982001)(74502001)(66066001)(81342001)(23726001)(54356001)(44976002)(55846006)(76482001)(33656001)(46406002)(15202345001)(53806001)(69226001)(5343655001)(56816002)(81542001)(50986001)(65816001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB014; H:TK5EX14MLTC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 00:14:00 -0000 I'm in favor of the change. I believe that this equivalent to issue http:/= /trac.tools.ietf.org/wg/jose/trac/ticket/3 - correct? -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Thursday, April 04, 2013 4:51 PM To: jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request =20 At the request of the editors, this is a formal consensus call on the first= item in the list below. If there are objects to use a single long key rat= her than a KDF function for the AES-CBC/HMAC algorithm please speak up now.= To date nobody has said that I was wrong to assume the consensus on that = item. Call ends in one week. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:21 PM > To: jose@ietf.org > Subject: [jose] Use of AES-HMAC algorithm >=20 > > After spending time looking at and thinking about how to resolve this issue > since I was unable to do so at the last F2F meeting. I have come up=20 > with the > following set of issues that might need to be addressed as part of resolving > this issue. >=20 > 1. Do we change from using KDC to having a double size key for the=20 > algorithm? I think that there is probably a consensus that this=20 > should be done. >=20 > 2. Should IVs be prepended to the encrypted body as part of the=20 > encoding steps? If so then this change should be universal. >=20 > Doing so would eliminate one field from all of the encoding formats=20 > which should be considered a plus. > Doing so would force code writers to understand how large the IV is=20 > for all > algorithms as the IV would no longer be a separate item. >=20 > 3. Should Authentication Tags be appended to the encrypted body as=20 > part of the encoding steps? >=20 > Doing so would eliminate one field from all of the encoding formats=20 > which should be considered a plus. > Doing so would force code writers to understand how large the IV is=20 > for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case=20 > as either all recipient specific data would need to be excluded from=20 > the authentication step or all of the recipient data would need to be=20 > included for > by all recipients. > Changing how the recipient info is process is going to give a=20 > performance benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and different > authentication data needs to have CFRG look at it. I am worried that=20 > it might > be a serious security flaw. >=20 > 4. Should we reference the McGrew draft and provide text on how things=20 > are changed or should we "copy" the draft into our text? >=20 > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key=20 > wrapping, does this change how we think about any of the above questions? >=20 > Allowing for AES-GCM for key wrapping has a benefit for hardware situations > as only the encrypt and not the decrypt functions need to be placed in=20 > hardware. However allowing for this key wrapping give a problem as=20 > there is > no way to encode the three fields into the encrypted value unless with=20 > use either a JSON structure in this location or we do use the single=20 > appended binary output stream. The first approach leads to an=20 > expansion of the field by > double base64 encoding which is highly undesirable. >=20 > Jim >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Thu Apr 4 18:55:20 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA121F9678 for ; Thu, 4 Apr 2013 18:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRJTMHb8o4+O for ; Thu, 4 Apr 2013 18:55:19 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 593A921F9677 for ; Thu, 4 Apr 2013 18:55:18 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id q2so488692qch.16 for ; Thu, 04 Apr 2013 18:55:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=LJsKxtyh53TTHoLUMEcsi1NuyN5Y0HMTtDkgDZ0PjHI=; b=TtO/woSX9bKvNWIHWSOmtaJxn4cvVDFoKSwydq+cJP7aYlumyGKiGks7BT9usaBx4Q AKGt4Zo3id3KlgiKZv1mF5eQ/p8K/BT0rcilfZQIKriqCsccM0XOnRg1j5zaazob60SU vgzmrm5MvFq8FQJAvfH9LDd3WPQ2o0wju2r+IzpZeS2S6b9QUO4lgj9VvnlpysarHzJY L3XedtCBm9GbqL3lYmCzdQBrj1gUUesSnWywyNOSY9gB5qo92V/i9OyUXy3e+mZ1Y8fU XP4eLf4cLAm6pCfQUH0yY4P1HgOJekOkfBayNqP/WArrqrYSMXeubFln1KjOQS5/B+CI buDg== X-Received: by 10.229.155.201 with SMTP id t9mr2590444qcw.155.1365126918451; Thu, 04 Apr 2013 18:55:18 -0700 (PDT) Received: from [192.168.1.213] (190-20-54-248.baf.movistar.cl. [190.20.54.248]) by mx.google.com with ESMTPS id eb7sm12782320qab.11.2013.04.04.18.55.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 18:55:17 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8E3F2A1D-5A13-4DB7-B40E-F825E9274F6C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> Date: Thu, 4 Apr 2013 21:53:39 -0400 Message-Id: References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlYUCT0oMXry11kqKDA2bzz8yPNBkeGKpNrtRsXxF774tNZdku+V7g3IcRn4g0TDfyzFEuK Cc: jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 01:55:20 -0000 --Apple-Mail=_8E3F2A1D-5A13-4DB7-B40E-F825E9274F6C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I support the change. On 2013-04-04, at 7:51 PM, "Jim Schaad" wrote: > > > At the request of the editors, this is a formal consensus call on the first > item in the list below. If there are objects to use a single long key > rather than a KDF function for the AES-CBC/HMAC algorithm please speak up > now. To date nobody has said that I was wrong to assume the consensus on > that item. > > Call ends in one week. > > Jim > > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim >> Schaad >> Sent: Wednesday, March 27, 2013 3:21 PM >> To: jose@ietf.org >> Subject: [jose] Use of AES-HMAC algorithm >> >> >> After spending time looking at and thinking about how to resolve this > issue >> since I was unable to do so at the last F2F meeting. I have come up with > the >> following set of issues that might need to be addressed as part of > resolving >> this issue. >> >> 1. Do we change from using KDC to having a double size key for the >> algorithm? I think that there is probably a consensus that this should be > done. >> >> 2. Should IVs be prepended to the encrypted body as part of the encoding >> steps? If so then this change should be universal. >> >> Doing so would eliminate one field from all of the encoding formats which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is for > all >> algorithms as the IV would no longer be a separate item. >> >> 3. Should Authentication Tags be appended to the encrypted body as part of >> the encoding steps? >> >> Doing so would eliminate one field from all of the encoding formats which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is for > all >> algorithms as the IV would no longer be a separate item. >> Doing so would force a re-organization for the multiple recipient case as >> either all recipient specific data would need to be excluded from the >> authentication step or all of the recipient data would need to be included > for >> by all recipients. >> Changing how the recipient info is process is going to give a performance >> benefit for sending encrypted items for multiple recipients. >> The current strategy of a single IV and key pair with AES-GCM and > different >> authentication data needs to have CFRG look at it. I am worried that it > might >> be a serious security flaw. >> >> 4. Should we reference the McGrew draft and provide text on how things are >> changed or should we "copy" the draft into our text? >> >> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, >> does this change how we think about any of the above questions? >> >> Allowing for AES-GCM for key wrapping has a benefit for hardware > situations >> as only the encrypt and not the decrypt functions need to be placed in >> hardware. However allowing for this key wrapping give a problem as there > is >> no way to encode the three fields into the encrypted value unless with use >> either a JSON structure in this location or we do use the single appended >> binary output stream. The first approach leads to an expansion of the > field by >> double base64 encoding which is highly undesirable. >> >> Jim >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_8E3F2A1D-5A13-4DB7-B40E-F825E9274F6C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDA1MDE1NDMxWjAjBgkqhkiG9w0BCQQxFgQU0atrFxQg L1Z34ArodSkemgh0lVwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAC7/e3NZHTedTUiKRthpgPRRNM1ZmIuaOIFqAB6B3 1DDrunf6rWJAi5VwEiTtKcOxE0qOYMzaHyCc9JYRywdaiIwsiZq68wzRPNm3K66faLzsAcejaXcY o1Z2X3YN45FD+zi1Dnx9mrqH18oSZhTop5Mj0DD5RcTR8fQpAL6r22a7b7WG3kamaLk6hELn/oAX wvQwQQj8o7sFKFlSulLxtrUkbR2gZSKXzymOxIcF+lMYnliDH8N9i2N6uY2b64d6+EkJVgfnFaHK qln5ba8DIzWgWDP+y1RwPlcbAz+pybOyhF953ch5Ku2ius1N6eH+TmyrR1oNtLJ9I4ARuBKRTgAA AAAAAA== --Apple-Mail=_8E3F2A1D-5A13-4DB7-B40E-F825E9274F6C-- From vladimir@nimbusds.com Fri Apr 5 01:58:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC21421F9679 for ; Fri, 5 Apr 2013 01:58:38 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqIcEe+Wa8Vd for ; Fri, 5 Apr 2013 01:58:36 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 727C121F89B2 for ; Fri, 5 Apr 2013 01:58:31 -0700 (PDT) Received: (qmail 15390 invoked from network); 5 Apr 2013 08:56:23 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 5 Apr 2013 08:56:22 -0000 Received: (qmail 27565 invoked by uid 99); 5 Apr 2013 08:56:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.43.37.235 User-Agent: Workspace Webmail 5.6.34 Message-Id: <20130405015621.cc40c4f3d92d2001859047cd8cabb9ab.ac83af49ef.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Fri, 05 Apr 2013 01:56:21 -0700 Mime-Version: 1.0 Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 08:58:38 -0000 +1 =0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com= =0A=0A=0A-------- Original Message --------=0ASubject: Re: [jose] Use of AE= S-HMAC algorithm - Consensus Request=0AFrom: Mike Jones =0ADate: Fri, April 05, 2013 1:13 am=0ATo: Jim Schaad , "jose@ietf.org" =0A=0AI'm in favor of the cha= nge. I believe that this equivalent to issue=0Ahttp://trac.tools.ietf.org/w= g/jose/trac/ticket/3 - correct?=0A=0A -- Mike=0A=0A-----Original Message---= --=0AFrom: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf O= f=0AJim Schaad=0ASent: Thursday, April 04, 2013 4:51 PM=0ATo: jose@ietf.org= =0ASubject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request=0A=0A<= chair> =0A=0AAt the request of the editors, this is a formal consensus call= on the=0Afirst item in the list below. If there are objects to use a singl= e long=0Akey rather than a KDF function for the AES-CBC/HMAC algorithm plea= se=0Aspeak up now. To date nobody has said that I was wrong to assume the= =0Aconsensus on that item.=0A=0ACall ends in one week.=0A=0AJim=0A=0A=0A> -= ----Original Message-----=0A> From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf =0A> Of=0AJim=0A> Schaad=0A> Sent: Wednesday, March= 27, 2013 3:21 PM=0A> To: jose@ietf.org=0A> Subject: [jose] Use of AES-HMAC= algorithm=0A> =0A> =0A> After spending time looking at and thinking= about how to resolve this=0Aissue=0A> since I was unable to do so at the l= ast F2F meeting. I have come up =0A> with=0Athe=0A> following set of issues= that might need to be addressed as part of=0Aresolving=0A> this issue.=0A>= =0A> 1. Do we change from using KDC to having a double size key for the = =0A> algorithm? I think that there is probably a consensus that this =0A> s= hould be=0Adone.=0A> =0A> 2. Should IVs be prepended to the encrypted body = as part of the =0A> encoding steps? If so then this change should be univer= sal.=0A> =0A> Doing so would eliminate one field from all of the encoding f= ormats =0A> which should be considered a plus.=0A> Doing so would force cod= e writers to understand how large the IV is =0A> for=0Aall=0A> algorithms a= s the IV would no longer be a separate item.=0A> =0A> 3. Should Authenticat= ion Tags be appended to the encrypted body as =0A> part of the encoding ste= ps?=0A> =0A> Doing so would eliminate one field from all of the encoding fo= rmats =0A> which should be considered a plus.=0A> Doing so would force code= writers to understand how large the IV is =0A> for=0Aall=0A> algorithms as= the IV would no longer be a separate item.=0A> Doing so would force a re-o= rganization for the multiple recipient case =0A> as either all recipient sp= ecific data would need to be excluded from =0A> the authentication step or = all of the recipient data would need to be =0A> included=0Afor=0A> by all r= ecipients.=0A> Changing how the recipient info is process is going to give = a =0A> performance benefit for sending encrypted items for multiple recipie= nts.=0A> The current strategy of a single IV and key pair with AES-GCM and= =0Adifferent=0A> authentication data needs to have CFRG look at it. I am wo= rried that =0A> it=0Amight=0A> be a serious security flaw.=0A> =0A> 4. Shou= ld we reference the McGrew draft and provide text on how things =0A> are ch= anged or should we "copy" the draft into our text?=0A> =0A> 5. If we allow = for the use of AES-GCM or AES-HMAC for doing key =0A> wrapping, does this c= hange how we think about any of the above questions?=0A> =0A> Allowing for = AES-GCM for key wrapping has a benefit for hardware=0Asituations=0A> as onl= y the encrypt and not the decrypt functions need to be placed in =0A> hardw= are. However allowing for this key wrapping give a problem as =0A> there=0A= is=0A> no way to encode the three fields into the encrypted value unless wi= th =0A> use either a JSON structure in this location or we do use the singl= e =0A> appended binary output stream. The first approach leads to an =0A> e= xpansion of the=0Afield by=0A> double base64 encoding which is highly undes= irable.=0A> =0A> Jim=0A> =0A> =0A> ________________________________________= _______=0A> jose mailing list=0A> jose@ietf.org=0A> https://www.ietf.org/ma= ilman/listinfo/jose=0A=0A_______________________________________________=0A= jose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/j= ose=0A_______________________________________________=0Ajose mailing list= =0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose From turners@ieca.com Fri Apr 5 05:29:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343C221F972F for ; Fri, 5 Apr 2013 05:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOZoFQ8nE4bc for ; Fri, 5 Apr 2013 05:29:05 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [67.18.36.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4420121F9724 for ; Fri, 5 Apr 2013 05:29:05 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id D2D1DD5583737; Fri, 5 Apr 2013 07:29:04 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id C601CD55836E5 for ; Fri, 5 Apr 2013 07:29:04 -0500 (CDT) Received: from [108.45.16.214] (port=59639 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UO5lQ-00076D-JV for jose@ietf.org; Fri, 05 Apr 2013 07:29:04 -0500 Message-ID: <515EC38F.2060703@ieca.com> Date: Fri, 05 Apr 2013 08:29:03 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org References: <513CCD31.8050408@isoc.org> In-Reply-To: <513CCD31.8050408@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:59639 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 12:29:06 -0000 Hi, We've gotten what amounts to two discusses on the charter. I wanted to run these by the WG in case there were any violent objections. 1. (easy one first) What does "JSON-structured integrity protection" and "JSON-structured encryption" mean? It was explained "JSON-structured" means that the metadata about how you did the encryption/integrity is expressed in JSON not that the payload itself is JSON. I.e., the algorithm description, key identifiers, etc. are in JSON but not necessary the payload. I proposed: OLD: specifying how to apply JSON-structured integrity protection to data NEW: specifying a JSON structure for integrity-protected data and the same again for encryption: OLD: specifying how to apply a JSON-structured encryption to data NEW: specifying a JSON structure for encrypted data 2. (hard one) Barry's been told by some App folks who are working on new JSON-based protocols that they don't see the applicability of JOSE to their work. I think there is some concern that we're doing our own thing here in security land and not consulting with others. That's not a true characterization based the use case we have from ALTO and XMPP, but nonetheless this feedback worries both Barry and myself. What I'm going to do is prompt/prod the Apps folks to engage and say why/how it won't work for them. What we might also do is some education in the appsawg; one of those here's how it works kind of presentations. We'll reach out, but they need to reach out too because I don't want to have to be pinned waiting on a input that may never come. To that end, putting some wording in the charter earlier than the numbered bullet about the uses cases, I think, solves this dilemma: The WG will strive to gather use cases to ensure the broadest possible applicability of the mechanism. spt On 3/10/13 2:13 PM, Karen O'Donoghue wrote: > Folks, > > Here is the updated charter text based on Sean's comments and Mike's > response. If there are any errors, please identify them asap as I plan > to forward this back to Sean (and thus the IESG) in the very near future. > > Regards, > Karen > > > Description of JOSE Working Group > > JavaScript Object Notation (JSON) is a text format for the serialization > of structured > data described in RFC 4627. The JSON format is often used for > serializing and > transmitting structured data over a network connection. With the > increased usage > of JSON in protocols in the IETF and elsewhere, there is now a desire to > offer > security services for JSON with encryption, digital signatures, and > message authentication > codes (MACs). > > Different proposals for providing such security services have already > been defined > and implemented. This Working Group will standardize the mechanism for > integrity > protection (signature and MAC) and encryption as well as the format for > keys and algorithm > identifiers to support interoperability of security services for > protocols that > use JSON. The Working Group will base its work on well-known message > security primitives > (e.g., CMS), and will solicit input from the rest of the IETF Security > Area to be sure > that the security functionality in the JSON format is sound. > > As JSON adoption expands, the different applications utilizing JSON > security services > will grow and this leads to the need to support different requirements. > The WG will > develop a generic syntax that can be used by applications to secure > JSON-data, but > it will be up to the application to fully specify the use of the WG's > documents much > the same way S/MIME is the application of CMS to MIME-based media types. > > This group is chartered to work on the following deliverables: > > (1) A Standards Track document or documents specifying how to apply > JSON-structured > integrity protection to data, including (but not limited to) JSON data > structures. > "Integrity protection" includes public-key digital signatures as well as > symmetric-key MACs. > > (2) A Standards Track document or documents specifying how to apply a > JSON-structured > encryption to data, including (but not limited to) JSON data structures. > > (3) A Standards Track document specifying how to encode public keys as > JSON- > structured objects. > > (4) A Standards Track document specifying algorithms and algorithm > identifiers for > the previous three documents. > > (5) A Standards Track document specifying how to encode private and > symmetric > keys as JSON-structured objects. This document will build upon the > concepts and > structures in (3). > > (6) A Standards Track document specifying a means of protecting private > and symmetric > keys via encryption. This document will build upon the concepts and > structures in (2) > and (5). This document may register additional algorithms in registries > defined by (4). > > (7) An Informational document detailing Use Cases and Requirements for > JSON Object > Signing and Encryption (JOSE). > > (8) An Informational document that tells an application what needs to be > specified in order > to implement JOSE. > > One or more of these goals may be combined into a single document, in > which case the > concrete milestones for these goals will be satisfied by the > consolidated document(s). > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From Michael.Jones@microsoft.com Fri Apr 5 06:33:47 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1165421F9679 for ; Fri, 5 Apr 2013 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i9aDfK-rLpE for ; Fri, 5 Apr 2013 06:33:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 06D7421F9676 for ; Fri, 5 Apr 2013 06:33:39 -0700 (PDT) Received: from BL2FFO11FD002.protection.gbl (10.173.161.203) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 13:29:16 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 13:29:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 13:28:51 +0000 From: Mike Jones To: Sean Turner , "jose@ietf.org" Thread-Topic: [jose] updated draft charter text incorporating AD's comments Thread-Index: AQHOHbsFzhPDcbJYm0e4TO3t5oFBJZjHttqAgAAMlKA= Date: Fri, 5 Apr 2013 13:28:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> In-Reply-To: <515EC38F.2060703@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675B77BCTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(24454001)(13464002)(60454001)(377454001)(51704002)(52604002)(20776003)(31966008)(4396001)(63696002)(77982001)(53806001)(51856001)(47446002)(56816002)(15202345001)(54356001)(80022001)(44976002)(46102001)(71186001)(54316002)(49866001)(55846006)(47736001)(512954001)(74502001)(33656001)(66066001)(65816001)(76482001)(81542001)(561944001)(79102001)(81342001)(16406001)(59766001)(5343635001)(56776001)(69226001)(5343655001)(47976001)(50986001)(74662001)(16236675001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB010; H:TK5EX14HUBC105.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 13:33:47 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675B77BCTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmmm... I feel really queasy about the proposed rewording for (1), as it c= ould lead to significant unintended consequences and potential obstacles wh= en we go for final approval of the JWS and JWE specs. Here's why... The wording could easily be interpreted as a mandate that the end-represent= ation itself be JSON - not just that the representation utilize JSON for re= presenting structured data, which is what is actually the case now. I coul= d easily imagine the new wording enabling a situation where someone would t= hen file a DISCUSS saying that the current Compact Serialization representa= tions aren't JSON and so don't meet the requirements of the charter. For that reason, I believe we would be FAR better off to leave the first tw= o charter items exactly as they are at http://datatracker.ietf.org/wg/jose/= charter/ than to accept the new wording. The current wording is: 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures. "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. So yes, I strongly object to the new wording, as I don't want to open the d= oor for the current representations to be rejected on charter grounds later= . If it helps, you can reassure objectors that we ARE producing pure JSON = representations too, but that they're not the only JSON-based representatio= ns for integrity protected and encrypted content. Why don't we just scale back the recharter request to only add the new item= s and leave the existing items alone, if that's what it will take to be app= roved. Thanks for aski= ng, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sea= n Turner Sent: Friday, April 05, 2013 5:29 AM To: jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comments Hi, We've gotten what amounts to two discusses on the charter. I wanted to run= these by the WG in case there were any violent objections. 1. (easy one first) What does "JSON-structured integrity protection" and "J= SON-structured encryption" mean? It was explained "JSON-structured" means that the metadata about how you di= d the encryption/integrity is expressed in JSON not that the payload itself= is JSON. I.e., the algorithm description, key identifiers, etc. are in JSON but not necessary the payload. I proposed: OLD: specifying how to apply JSON-structured integrity protection to data NEW: specifying a JSON structure for integrity-protected data and the same again for encryption: OLD: specifying how to apply a JSON-structured encryption to data NEW: specifying a JSON structure for encrypted data 2. (hard one) Barry's been told by some App folks who are working on new JS= ON-based protocols that they don't see the applicability of JOSE to their w= ork. I think there is some concern that we're doing our own thing here in securi= ty land and not consulting with others. That's not a true characterization= based the use case we have from ALTO and XMPP, but nonetheless this feedback worries both Barry and myself. What I'm going to do is prompt/prod the Apps folks to engage and say why/how it won'= t work for them. What we might also do is some education in the appsawg; o= ne of those here's how it works kind of presentations. We'll reach out, bu= t they need to reach out too because I don't want to have to be pinned wait= ing on a input that may never come. To that end, putting some wording in t= he charter earlier than the numbered bullet about the uses cases, I think, = solves this dilemma: The WG will strive to gather use cases to ensure the broadest possible applicability of the mechanism. spt On 3/10/13 2:13 PM, Karen O'Donoghue wrote: > Folks, > > Here is the updated charter text based on Sean's comments and Mike's > response. If there are any errors, please identify them asap as I plan > to forward this back to Sean (and thus the IESG) in the very near future. > > Regards, > Karen > > > Description of JOSE Working Group > > JavaScript Object Notation (JSON) is a text format for the > serialization of structured data described in RFC 4627. The JSON > format is often used for serializing and transmitting structured data > over a network connection. With the increased usage of JSON in > protocols in the IETF and elsewhere, there is now a desire to offer > security services for JSON with encryption, digital signatures, and > message authentication codes (MACs). > > Different proposals for providing such security services have already > been defined and implemented. This Working Group will standardize the > mechanism for integrity protection (signature and MAC) and encryption > as well as the format for keys and algorithm identifiers to support > interoperability of security services for protocols that use JSON. The > Working Group will base its work on well-known message security > primitives (e.g., CMS), and will solicit input from the rest of the > IETF Security Area to be sure that the security functionality in the > JSON format is sound. > > As JSON adoption expands, the different applications utilizing JSON > security services will grow and this leads to the need to support > different requirements. > The WG will > develop a generic syntax that can be used by applications to secure > JSON-data, but it will be up to the application to fully specify the > use of the WG's documents much the same way S/MIME is the application > of CMS to MIME-based media types. > > This group is chartered to work on the following deliverables: > > (1) A Standards Track document or documents specifying how to apply > JSON-structured integrity protection to data, including (but not > limited to) JSON data structures. > "Integrity protection" includes public-key digital signatures as well > as symmetric-key MACs. > > (2) A Standards Track document or documents specifying how to apply a > JSON-structured encryption to data, including (but not limited to) > JSON data structures. > > (3) A Standards Track document specifying how to encode public keys as > JSON- > structured objects. > > (4) A Standards Track document specifying algorithms and algorithm > identifiers for the previous three documents. > > (5) A Standards Track document specifying how to encode private and > symmetric keys as JSON-structured objects. This document will build > upon the concepts and structures in (3). > > (6) A Standards Track document specifying a means of protecting > private and symmetric keys via encryption. This document will build > upon the concepts and structures in (2) and (5). This document may > register additional algorithms in registries defined by (4). > > (7) An Informational document detailing Use Cases and Requirements for > JSON Object Signing and Encryption (JOSE). > > (8) An Informational document that tells an application what needs to > be specified in order to implement JOSE. > > One or more of these goals may be combined into a single document, in > which case the concrete milestones for these goals will be satisfied > by the consolidated document(s). > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943675B77BCTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hmmm...  I feel really queasy about the prop= osed rewording for (1), as it could lead to significant unintended conseque= nces and potential obstacles when we go for final approval of the JWS and J= WE specs.  Here's why...

 

The wording could easily be interpreted as a mand= ate that the end-representation itself be JSON – not just that the re= presentation utilize JSON for representing structured data, which is what i= s actually the case now.  I could easily imagine the new wording enabling a situation where someone would then file= a DISCUSS saying that the current Compact Serialization representations ar= en't JSON and so don't meet the requirements of the charter.

 

For that reason, I believe we would be FAR better= off to leave the first two charter items exactly as they are at http://datatracker= .ietf.org/wg/jose/charter/ than to accept the new wording.  The cu= rrent wording is:

 

1) A Standards Track d= ocument specifying how to apply JSON-structured

 integrity protec= tion to data, including (but not limited to) JSON data

 structures. &quo= t;Integrity protection" includes public-key digital

 signatures as we= ll as symmetric-key MACs.

 

2) A Standards Track d= ocument specifying how to apply a JSON-structured

 encryption to da= ta, including (but not limited to) JSON data structures.

 

So yes, I strongly object to the new wording, as = I don’t want to open the door for the current representations to be r= ejected on charter grounds later.  If it helps, you can reassure objec= tors that we ARE producing pure JSON representations too, but that they’re not the only JSON-based representations for in= tegrity protected and encrypted content.

 

Why don’t we just scale back the recharter = request to only add the new items and leave the existing items alone, if th= at’s what it will take to be approved.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Thanks for asking,

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

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sea= n Turner
Sent: Friday, April 05, 2013 5:29 AM
To: jose@ietf.org
Subject: Re: [jose] updated draft charter text incorporating AD's comments<= /p>

 

Hi,

 

We've gotten what amounts to two discusses on the= charter.  I wanted to run these by the WG in case there were any viol= ent objections.

 

1. (easy one first) What does "JSON-structur= ed integrity protection" and "JSON-structured encryption" me= an?

 

It was explained "JSON-structured" mean= s that the metadata about how you did the encryption/integrity is expressed= in JSON not that the payload itself is JSON.  I.e., the algorithm des= cription, key identifiers, etc.

are in JSON but not necessary the payload.

 

I proposed:

 

OLD:

 

   specifying how to apply JSON-structu= red integrity

   protection to data

 

NEW:

 

   specifying a JSON structure for inte= grity-protected data

 

and the same again for encryption:

 

OLD:

 

   specifying how to apply a JSON-struc= tured encryption to data

 

NEW:

 

   specifying a JSON structure for encr= ypted data

 

2. (hard one) Barry's been told by some App folks= who are working on new JSON-based protocols that they don't see the applic= ability of JOSE to their work.

 

I think there is some concern that we're doing ou= r own thing here in security land and not consulting with others.  Tha= t's not a true characterization based the use case we have from ALTO and XM= PP, but

nonetheless this feedback worries both Barry and = myself.   What I'm

going to do is prompt/prod the Apps folks to enga= ge and say why/how it won't work for them.  What we might also do is s= ome education in the appsawg; one of those here's how it works kind of pres= entations.  We'll reach out, but they need to reach out too because I don't want to have to be pinned waiting on a in= put that may never come.  To that end, putting some wording in the cha= rter earlier than the numbered bullet about the uses cases, I think, solves= this dilemma:

 

   The WG will strive to gather use cas= es to ensure the broadest

   possible applicability of the mechan= ism.

 

spt

 

On 3/10/13 2:13 PM, Karen O'Donoghue wrote:<= /o:p>

> Folks,

> 

> Here is the updated charter text based on Se= an's comments and Mike's

> response. If there are any errors, please id= entify them asap as I plan

> to forward this back to Sean (and thus the I= ESG) in the very near future.

> 

> Regards,

> Karen

> 

> 

> Description of JOSE Working Group=

> 

> JavaScript Object Notation (JSON) is a text = format for the

> serialization of structured data described i= n RFC 4627.  The JSON

> format is often used for serializing and tra= nsmitting structured data

> over a network connection. With the increase= d usage of JSON in

> protocols in the IETF and elsewhere, there i= s now a desire to offer

> security services for JSON with encryption, = digital signatures, and

> message authentication codes (MACs).

> 

> Different proposals for providing such secur= ity services have already

> been defined and implemented.  This Wor= king Group will standardize the

> mechanism for integrity protection (signatur= e and MAC) and encryption

> as well as the format for keys and algorithm= identifiers to support

> interoperability of security services for pr= otocols that use JSON. The

> Working Group will base its work on well-kno= wn message security

> primitives (e.g., CMS), and will solicit inp= ut from the rest of the

> IETF Security Area to be sure that the secur= ity functionality in the

> JSON format is sound.

> 

> As JSON adoption expands, the different appl= ications utilizing JSON

> security services will grow and this leads t= o the need to support

> different requirements.

> The WG will

> develop a generic syntax that can be used by= applications to secure

> JSON-data, but it will be up to the applicat= ion to fully specify the

> use of the WG's documents much the same way = S/MIME is the application

> of CMS to MIME-based media types.=

> 

> This group is chartered to work on the follo= wing deliverables:

> 

> (1) A Standards Track document or documents = specifying how to apply

> JSON-structured integrity protection to data= , including (but not

> limited to) JSON data structures.=

> "Integrity protection" includes pu= blic-key digital signatures as well

> as symmetric-key MACs.

> 

> (2) A Standards Track document or documents = specifying how to apply a

> JSON-structured encryption to data, includin= g (but not limited to)

> JSON data structures.

> 

> (3) A Standards Track document specifying ho= w to encode public keys as

> JSON-

> structured objects.

> 

> (4) A Standards Track document specifying al= gorithms and algorithm

> identifiers for the previous three documents= .

> 

> (5) A Standards Track document specifying ho= w to encode private and

> symmetric keys as JSON-structured objects.&n= bsp; This document will build

> upon the concepts and structures in (3).

> 

> (6) A Standards Track document specifying a = means of protecting

> private and symmetric keys via encryption.&n= bsp; This document will build

> upon the concepts and structures in (2) and = (5).  This document may

> register additional algorithms in registries= defined by (4).

> 

> (7) An Informational document detailing Use = Cases and Requirements for

> JSON Object Signing and Encryption (JOSE).

> 

> (8) An Informational document that tells an = application what needs to

> be specified in order to implement JOSE.

> 

> One or more of these goals may be combined i= nto a single document, in

> which case the concrete milestones for these= goals will be satisfied

> by the consolidated document(s).<= /p>

> 

> ____________________________________________= ___

> jose mailing list

> jose@ietf.org

> https://ww= w.ietf.org/mailman/listinfo/jose

> 

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

--_000_4E1F6AAD24975D4BA5B1680429673943675B77BCTK5EX14MBXC283r_-- From housley@vigilsec.com Fri Apr 5 06:46:26 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0988A21F97AF for ; Fri, 5 Apr 2013 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PETF-anIgqJi for ; Fri, 5 Apr 2013 06:46:24 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF5621F97AE for ; Fri, 5 Apr 2013 06:46:24 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 676B6F2406B; Fri, 5 Apr 2013 09:46:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id YV9DgfsvpfD7; Fri, 5 Apr 2013 09:46:09 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5E1F49A40F4; Fri, 5 Apr 2013 09:46:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> Date: Fri, 5 Apr 2013 09:46:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F8202A1-81B2-474E-A18A-665F9BE7DCD2@vigilsec.com> References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1085) Cc: jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 13:46:26 -0000 I have a minor preference for the KDF. The KDF eliminates any bias in = the base key, and the KDF support the use of a base key with just enough = entropy to be secure. Russ On Apr 4, 2013, at 7:51 PM, Jim Schaad wrote: > =20 >=20 > At the request of the editors, this is a formal consensus call on the = first > item in the list below. If there are objects to use a single long key > rather than a KDF function for the AES-CBC/HMAC algorithm please speak = up > now. To date nobody has said that I was wrong to assume the consensus = on > that item. >=20 > Call ends in one week. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Jim >> Schaad >> Sent: Wednesday, March 27, 2013 3:21 PM >> To: jose@ietf.org >> Subject: [jose] Use of AES-HMAC algorithm >>=20 >> >> After spending time looking at and thinking about how to resolve this > issue >> since I was unable to do so at the last F2F meeting. I have come up = with > the >> following set of issues that might need to be addressed as part of > resolving >> this issue. >>=20 >> 1. Do we change from using KDC to having a double size key for the >> algorithm? I think that there is probably a consensus that this = should be > done. >>=20 >> 2. Should IVs be prepended to the encrypted body as part of the = encoding >> steps? If so then this change should be universal. >>=20 >> Doing so would eliminate one field from all of the encoding formats = which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is = for > all >> algorithms as the IV would no longer be a separate item. >>=20 >> 3. Should Authentication Tags be appended to the encrypted body as = part of >> the encoding steps? >>=20 >> Doing so would eliminate one field from all of the encoding formats = which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is = for > all >> algorithms as the IV would no longer be a separate item. >> Doing so would force a re-organization for the multiple recipient = case as >> either all recipient specific data would need to be excluded from the >> authentication step or all of the recipient data would need to be = included > for >> by all recipients. >> Changing how the recipient info is process is going to give a = performance >> benefit for sending encrypted items for multiple recipients. >> The current strategy of a single IV and key pair with AES-GCM and > different >> authentication data needs to have CFRG look at it. I am worried that = it > might >> be a serious security flaw. >>=20 >> 4. Should we reference the McGrew draft and provide text on how = things are >> changed or should we "copy" the draft into our text? >>=20 >> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key = wrapping, >> does this change how we think about any of the above questions? >>=20 >> Allowing for AES-GCM for key wrapping has a benefit for hardware > situations >> as only the encrypt and not the decrypt functions need to be placed = in >> hardware. However allowing for this key wrapping give a problem as = there > is >> no way to encode the three fields into the encrypted value unless = with use >> either a JSON structure in this location or we do use the single = appended >> binary output stream. The first approach leads to an expansion of = the > field by >> double base64 encoding which is highly undesirable. >>=20 >> Jim >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From barryleiba.mailing.lists@gmail.com Fri Apr 5 07:37:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4CC21F97F0 for ; Fri, 5 Apr 2013 07:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL3Wo+38Mt0H for ; Fri, 5 Apr 2013 07:37:28 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6542A21F97EE for ; Fri, 5 Apr 2013 07:37:28 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ib11so3224234vcb.7 for ; Fri, 05 Apr 2013 07:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fI54+3pEuXAau65A2z1Y53OHHVY3vnv80AUT5T2WI64=; b=0S4gOdWMS0s28VJmmvbxw2fJQBnVDW69gr47IB/qXekKd/gjpM7P9gSI+SPADXIRcj 9SvIK6nUYW0/FljlUlzTIKpQGyu8wVD5n1p/ytU5Lnfb7Qi+Te0nfkXCsZsN2pe9fmy8 hv4Q9g96NVweKMGADKLiq0PqaH+NCPi20r5nVnHPpUWh25ca9eIcSTFmpUehX8vGs1UV N3yEWnb4DnOGxAQNAOzibqQNL6m2qFio9EV4IOx7vH1Uhea+Hl0sZPk983IJHSh5HdOS 6qzhKGa7IqTMX7n6o0wDJ+7KrEmCMCPlFbytFxAXmRS1hyCArsiQvGQuiV1G7GABlRKm r8dg== MIME-Version: 1.0 X-Received: by 10.58.223.134 with SMTP id qu6mr8334042vec.35.1365172647909; Fri, 05 Apr 2013 07:37:27 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 5 Apr 2013 07:37:27 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 10:37:27 -0400 X-Google-Sender-Auth: n2qi2SarhUPWVQqC-UM6nGfOnCY Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Sean Turner , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 14:37:29 -0000 > For that reason, I believe we would be FAR better off to leave the first = two > charter items exactly as they are at > http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wordi= ng. > The current wording is: > > 1) A Standards Track document specifying how to apply JSON-structured > integrity protection to data, including (but not limited to) JSON data > structures. "Integrity protection" includes public-key digital > signatures as well as symmetric-key MACs. > > 2) A Standards Track document specifying how to apply a JSON-structured > encryption to data, including (but not limited to) JSON data structures. The problem is that I do not understand what you mean by "JSON-structured integrity protection" and "JSON-structured encryption". Sean's suggested wording is intended to say this in an understandable way; if it's not correct, please try to come up with an alternative. The existing text doesn't work, because I don't understand how to apply the modifier "JSON-structured" to the noun "encryption" and get anything sensible out of it. What does it mean for *encryption* to be "JSON-structured"? > So yes, I strongly object to the new wording, as I don=92t want to open t= he > door for the current representations to be rejected on charter grounds > later. If it helps, you can reassure objectors that we ARE producing pur= e > JSON representations too, but that they=92re not the only JSON-based > representations for integrity protected and encrypted content. To be clear: what you're producing is not the issue. It's an issue of the wording in the charter. Barry From dick.hardt@gmail.com Fri Apr 5 08:11:12 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22C521F97CA for ; Fri, 5 Apr 2013 08:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn-RTxg7IlJj for ; Fri, 5 Apr 2013 08:11:09 -0700 (PDT) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4E56621F97C3 for ; Fri, 5 Apr 2013 08:11:09 -0700 (PDT) Received: by mail-da0-f51.google.com with SMTP id g27so1610973dan.24 for ; Fri, 05 Apr 2013 08:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=jC2CFFwxnY6U0AQHFwXBxS3PtbqJyp8ivg7yI5yYjyA=; b=BsQ8itKXMX8MoOeyiw+ALNYIkupCb1fpHVERLTyXCITrtvJOOwX70D7Zm5n4iff0sJ rBGxCRz4cI3yHCiVjccV4kPhEEoc/axaYXls3M4nVera5SISygH6cZdt+uvdEPULvQlT pst/ytzHjcsPdH/Vlq9iccKw9jpyGQTH4uQ45NrxCKHMdL8/ER19Bk1RXx3cNEv3jAep qHv0HJWdA0nr0qWNT41Gg5Ubt8xARfWXIZjsOmGj/gysoOFhXfrAnnCdVv7C0M2hD3QB TyaIXl8w1x0NX+nawB8nS7GpZ2PqicLT4dyfKTquJlITt4gAF0YovU9DxvSCOF/5kLxw cGEw== X-Received: by 10.68.212.233 with SMTP id nn9mr14881475pbc.144.1365174669067; Fri, 05 Apr 2013 08:11:09 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id yp2sm16381997pab.10.2013.04.05.08.11.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 08:11:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: Date: Fri, 5 Apr 2013 08:11:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D538EC7-B35B-4E85-9373-A65B885150B0@gmail.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Barry Leiba X-Mailer: Apple Mail (2.1503) Cc: Mike Jones , Sean Turner , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:11:12 -0000 I'm with Mike on not being aligned on the new change. Here is my take on = why yet-another-token-format was desired=20 + Ability to represent complex data =3D> simple name/value pairs in URL query strings and and HTTP headers = led to obtuse, overloaded representations =3D> JSON + Easy to parse using readily available libraries =3D> JSON + Easy to include in URLs and HTTP headers =3D> the token did not require special encoding =3D> the token was short =3D> URL base 64 encoding JSON and separating binary fields with = '.' separator =3D> easy to parse On Apr 5, 2013, at 7:37 AM, Barry Leiba wrote: >> For that reason, I believe we would be FAR better off to leave the = first two >> charter items exactly as they are at >> http://datatracker.ietf.org/wg/jose/charter/ than to accept the new = wording. >> The current wording is: >>=20 >> 1) A Standards Track document specifying how to apply JSON-structured >> integrity protection to data, including (but not limited to) JSON = data >> structures. "Integrity protection" includes public-key digital >> signatures as well as symmetric-key MACs. >>=20 >> 2) A Standards Track document specifying how to apply a = JSON-structured >> encryption to data, including (but not limited to) JSON data = structures. >=20 > The problem is that I do not understand what you mean by > "JSON-structured integrity protection" and "JSON-structured > encryption". Sean's suggested wording is intended to say this in an > understandable way; if it's not correct, please try to come up with an > alternative. The existing text doesn't work, because I don't > understand how to apply the modifier "JSON-structured" to the noun > "encryption" and get anything sensible out of it. What does it mean > for *encryption* to be "JSON-structured"? >=20 >> So yes, I strongly object to the new wording, as I don=92t want to = open the >> door for the current representations to be rejected on charter = grounds >> later. If it helps, you can reassure objectors that we ARE producing = pure >> JSON representations too, but that they=92re not the only JSON-based >> representations for integrity protected and encrypted content. >=20 > To be clear: what you're producing is not the issue. It's an issue of > the wording in the charter. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Apr 5 08:19:05 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9F021F9783 for ; Fri, 5 Apr 2013 08:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juwtsMd3nNFX for ; Fri, 5 Apr 2013 08:19:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id C173521F9724 for ; Fri, 5 Apr 2013 08:19:01 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.202) by BL2FFO11HUB035.protection.gbl (10.173.161.115) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 15:10:05 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 15:10:04 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 15:10:04 +0000 From: Mike Jones To: Barry Leiba Thread-Topic: [jose] updated draft charter text incorporating AD's comments Thread-Index: AQHOHbsFzhPDcbJYm0e4TO3t5oFBJZjHttqAgAAMlKCAABdMgIAAB+EQ Date: Fri, 5 Apr 2013 15:10:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(13464002)(51704002)(377454001)(47976001)(54316002)(81342001)(31966008)(20776003)(50986001)(55846006)(74662001)(47776003)(59766001)(33656001)(23726001)(5343655001)(69226001)(77982001)(51856001)(56816002)(65816001)(53806001)(81542001)(79102001)(15202345001)(49866001)(46406002)(54356001)(74502001)(46102001)(44976002)(80022001)(50466001)(76482001)(66066001)(47446002)(56776001)(47736001)(16406001)(4396001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB035; H:TK5EX14HUBC104.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Cc: Sean Turner , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:19:05 -0000 Thanks Barry. How about "representing integrity-protected data using JSON-based data stru= ctures" and "representing encrypted data using JSON-based data structures"?= That would read better than the original and still not be able to be misc= onstrued to say that what the working group has produced doesn't meet the c= harter goals. Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Friday, April 05, 2013 7:37 AM To: Mike Jones Cc: Sean Turner; jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comments > For that reason, I believe we would be FAR better off to leave the=20 > first two charter items exactly as they are at=20 > http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wordi= ng. > The current wording is: > > 1) A Standards Track document specifying how to apply JSON-structured =20 > integrity protection to data, including (but not limited to) JSON data =20 > structures. "Integrity protection" includes public-key digital =20 > signatures as well as symmetric-key MACs. > > 2) A Standards Track document specifying how to apply a=20 > JSON-structured encryption to data, including (but not limited to) JSON = data structures. The problem is that I do not understand what you mean by "JSON-structured i= ntegrity protection" and "JSON-structured encryption". Sean's suggested wo= rding is intended to say this in an understandable way; if it's not correct= , please try to come up with an alternative. The existing text doesn't wor= k, because I don't understand how to apply the modifier "JSON-structured" t= o the noun "encryption" and get anything sensible out of it. What does it = mean for *encryption* to be "JSON-structured"? > So yes, I strongly object to the new wording, as I don't want to open=20 > the door for the current representations to be rejected on charter=20 > grounds later. If it helps, you can reassure objectors that we ARE=20 > producing pure JSON representations too, but that they're not the only=20 > JSON-based representations for integrity protected and encrypted content. To be clear: what you're producing is not the issue. It's an issue of the = wording in the charter. Barry _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From barryleiba@gmail.com Fri Apr 5 08:20:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC721F9815 for ; Fri, 5 Apr 2013 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKl7Gw3RfrHQ for ; Fri, 5 Apr 2013 08:20:38 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C3B7721F9814 for ; Fri, 5 Apr 2013 08:20:37 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fn20so123345lab.32 for ; Fri, 05 Apr 2013 08:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G3vs1CDvcqY5YW54D64pHtn68cNeTb3FMqBAAIG2xKQ=; b=qlMqf4QtXSyzymDdiTMJZv6VelVg2VRG6gQcsQ6nE2ec+MuKq3NgtANri+MOyVlxzX 6ttOMkQxSTjDv82L4fHjTX/Hyxf1F0EDJpJAv86cQ8BSpyLTZNYAVJ77e+tLcCmOjhTR 4SqtuUUlXsgArcNlUph9lhU/ZWS9dDaHl5tcVYlnVG3q1LVEX6f7ZSCEuVUZzUJxXnTR 2EdNcHLpExn4rnf3AwBiL6JQufhFZN74MrG9k/HGGCxfkwTkH08kAZkeuqDfOrhokiE+ Aysi4/4zYgCqpEhDwCLED0TCzBXSlRvvIVao3p1gwuLIDlMUb0nPy0e5B1uq/G5shDMM 5nkg== MIME-Version: 1.0 X-Received: by 10.152.20.6 with SMTP id j6mr2768456lae.7.1365175236397; Fri, 05 Apr 2013 08:20:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.76.98 with HTTP; Fri, 5 Apr 2013 08:20:36 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 11:20:36 -0400 X-Google-Sender-Auth: hcrolEuvspCwsVwcshuLK0LHZUU Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: Sean Turner , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:20:38 -0000 > How about "representing integrity-protected data using JSON-based data > structures" and "representing encrypted data using JSON-based data structures"? > That would read better than the original and still not be able to be misconstrued > to say that what the working group has produced doesn't meet the charter goals. I can understand that; thanks. Barry From trac+jose@trac.tools.ietf.org Fri Apr 5 15:10:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6921F98CB for ; Fri, 5 Apr 2013 15:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbv+rmgif13P for ; Fri, 5 Apr 2013 15:10:46 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 27CFD21F987C for ; Fri, 5 Apr 2013 15:10:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:58511 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOEq6-0005LS-LV; Sat, 06 Apr 2013 00:10:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-signature@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Fri, 05 Apr 2013 22:10:30 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/18 Message-ID: <049.d29eb38c96b761dee70b1317e2c051c7@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-signature@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com, n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com Resent-Message-Id: <20130405221042.27CFD21F987C@ietfa.amsl.com> Resent-Date: Fri, 5 Apr 2013 15:10:40 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #18: Address MAC key lifetime concerns X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:10:48 -0000 #18: Address MAC key lifetime concerns The point was raised on CFRG that it is beneficial to have short-lived MAC keys. The current JWS specification works against this objective by relying on out-of-band mechanisms for provisioning MAC keys. If there were a mechanism for providing short-lived keys wrapped under a long-lived key, as there is in JWE, this would not be an issue. The working group needs to do one of two things: 1. Add wrapped keys to JWS 2. Add security considerations to JWS REQUIRING that an application protocol ensure that key lifetimes are controlled. In the past, the group has resolved not to do (1) (see ISSUE-2), but it also has not done (2). To resolve this issue, one of the two options above needs to be implemented. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | signature@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: signature | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Fri Apr 5 15:15:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41321F98F8 for ; Fri, 5 Apr 2013 15:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN6DQrOPQjKA for ; Fri, 5 Apr 2013 15:15:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E94D821F98D0 for ; Fri, 5 Apr 2013 15:15:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:58681 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOEup-0007Nm-ID; Sat, 06 Apr 2013 00:15:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-signature@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Fri, 05 Apr 2013 22:15:23 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/18#comment:1 Message-ID: <064.cb00c32d0f9dcf421e1ee2141cb6ca21@trac.tools.ietf.org> References: <049.d29eb38c96b761dee70b1317e2c051c7@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <049.d29eb38c96b761dee70b1317e2c051c7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-signature@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com, n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com Resent-Message-Id: <20130405221526.E94D821F98D0@ietfa.amsl.com> Resent-Date: Fri, 5 Apr 2013 15:15:26 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #18: Address MAC key lifetime concerns X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:15:35 -0000 #18: Address MAC key lifetime concerns Comment (by rlb@ipv.sx): As I have argued before, it is my strong opinion that option (1) is the simpler thing to do. There is no great complexity: The key wrapping mechanism is already defined in JWE, so this would simply apply it to JWS as well. Writing the proper considerations for option (2) would be much harder, because you have to specify what an OOB protocol needs to do. (Easier to just write the protocol!) Option (2) would also fail to address a known security gap in the base protocol, which seems irresponsible. This protocol needs to be secure without having to rely on something external. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | signature@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: signature | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Fri Apr 5 15:43:22 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0421F992B for ; Fri, 5 Apr 2013 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpV7z7iJlmzx for ; Fri, 5 Apr 2013 15:43:21 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4F21F98F4 for ; Fri, 5 Apr 2013 15:43:20 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wm15so1562381obc.19 for ; Fri, 05 Apr 2013 15:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4PgxM2RP5hJkkNIJ6DqrRLYeTRAPF3+rFbqV4ifxfBs=; b=BCFHPpdHqbzHkcFWdmI2JadJt1hDgHVgGAWZShnEFVrUHOjq9si0ioXcj9WaRCdANM K84i/S7BODnMhgJNzLQ4D5AHpvapwedM2bAxhcQNdhfj0CNIZ07q96byJ8EfgkcyzSS0 7a0EE32fRTJVTua9OX2fbqYa+Xt2/ytaz3NsB0o8QRBvXxd7A36oJ8CG3I+s8iioGv58 Iisy25+aQAZw39/ovbhHabYpYD9GqL0eMs7WmXxYIpdgHSYkSVrJL3BcS+P2s76BQiqa 2sKGzwm1VtdPL/mjigEE8Fgs6oE4sxBF2mdsyJ+pDGi/FmBUMvY1SlaWCq3/MjNjFy8S ZOYQ== MIME-Version: 1.0 X-Received: by 10.60.17.132 with SMTP id o4mr9593903oed.12.1365201800130; Fri, 05 Apr 2013 15:43:20 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 5 Apr 2013 15:43:20 -0700 (PDT) X-Originating-IP: [128.89.255.18] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 18:43:20 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e01294d0c58041704d9a4d0c2 X-Gm-Message-State: ALoCoQk4RZTGCdNc8u96BxnTEg3hJsbbpOry1BD9qbGNKotWtdOvknZuSXHUKCuyhUrqaNxQLtIw Cc: Sean Turner , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:43:22 -0000 --089e01294d0c58041704d9a4d0c2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2013 at 9:28 AM, Mike Jones wro= te: > Hmmm... I feel really queasy about the proposed rewording for (1), as > it could lead to significant unintended consequences and potential > obstacles when we go for final approval of the JWS and JWE specs. Here's > why...**** > > ** ** > > The wording could easily be interpreted as a mandate that the > end-representation itself be JSON =96 not just that the representation > utilize JSON for representing structured data, which is what is actually > the case now. I could easily imagine the new wording enabling a situatio= n > where someone would then file a DISCUSS saying that the current Compact > Serialization representations aren't JSON and so don't meet the > requirements of the charter. > That won't be a problem as long as there is *a* JSON representation in the base specification. Which we have agreed to do. --Richard > **** > > ** ** > > For that reason, I believe we would be FAR better off to leave the first > two charter items exactly as they are at > http://datatracker.ietf.org/wg/jose/charter/ than to accept the new > wording. The current wording is:**** > > ** ** > > 1) A Standards Track document specifying how to apply JSON-structured ***= * > > integrity protection to data, including (but not limited to) JSON data *= * > ** > > structures. "Integrity protection" includes public-key digital **** > > signatures as well as symmetric-key MACs. **** > > ** ** > > 2) A Standards Track document specifying how to apply a JSON-structured *= * > ** > > encryption to data, including (but not limited to) JSON data structures.= * > *** > > ** ** > > So yes, I strongly object to the new wording, as I don=92t want to open t= he > door for the current representations to be rejected on charter grounds > later. If it helps, you can reassure objectors that we ARE producing pur= e > JSON representations too, but that they=92re not the only JSON-based > representations for integrity protected and encrypted content.**** > > ** ** > > Why don=92t we just scale back the recharter request to only add the new > items and leave the existing items alone, if that=92s what it will take t= o be > approved.**** > > ** ** > > Thanks for > asking,**** > > -- Mike **** > > ** ** > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Friday, April 05, 2013 5:29 AM > To: jose@ietf.org > Subject: Re: [jose] updated draft charter text incorporating AD's comment= s > > ** ** > > Hi,**** > > ** ** > > We've gotten what amounts to two discusses on the charter. I wanted to > run these by the WG in case there were any violent objections.**** > > ** ** > > 1. (easy one first) What does "JSON-structured integrity protection" and > "JSON-structured encryption" mean?**** > > ** ** > > It was explained "JSON-structured" means that the metadata about how you > did the encryption/integrity is expressed in JSON not that the payload > itself is JSON. I.e., the algorithm description, key identifiers, etc. *= * > ** > > are in JSON but not necessary the payload.**** > > ** ** > > I proposed:**** > > ** ** > > OLD:**** > > ** ** > > specifying how to apply JSON-structured integrity**** > > protection to data**** > > ** ** > > NEW:**** > > ** ** > > specifying a JSON structure for integrity-protected data**** > > ** ** > > and the same again for encryption:**** > > ** ** > > OLD:**** > > ** ** > > specifying how to apply a JSON-structured encryption to data**** > > ** ** > > NEW:**** > > ** ** > > specifying a JSON structure for encrypted data**** > > ** ** > > 2. (hard one) Barry's been told by some App folks who are working on new > JSON-based protocols that they don't see the applicability of JOSE to the= ir > work.**** > > ** ** > > I think there is some concern that we're doing our own thing here in > security land and not consulting with others. That's not a true > characterization based the use case we have from ALTO and XMPP, but **** > > nonetheless this feedback worries both Barry and myself. What I'm **** > > going to do is prompt/prod the Apps folks to engage and say why/how it > won't work for them. What we might also do is some education in the > appsawg; one of those here's how it works kind of presentations. We'll > reach out, but they need to reach out too because I don't want to have to > be pinned waiting on a input that may never come. To that end, putting > some wording in the charter earlier than the numbered bullet about the us= es > cases, I think, solves this dilemma:**** > > ** ** > > The WG will strive to gather use cases to ensure the broadest**** > > possible applicability of the mechanism.**** > > ** ** > > spt**** > > ** ** > > On 3/10/13 2:13 PM, Karen O'Donoghue wrote:**** > > > Folks,**** > > >** ** > > > Here is the updated charter text based on Sean's comments and Mike's **= * > * > > > response. If there are any errors, please identify them asap as I plan = * > *** > > > to forward this back to Sean (and thus the IESG) in the very near futur= e. > **** > > >** ** > > > Regards,**** > > > Karen**** > > >** ** > > >** ** > > > Description of JOSE Working Group**** > > >** ** > > > JavaScript Object Notation (JSON) is a text format for the **** > > > serialization of structured data described in RFC 4627. The JSON **** > > > format is often used for serializing and transmitting structured data *= * > ** > > > over a network connection. With the increased usage of JSON in **** > > > protocols in the IETF and elsewhere, there is now a desire to offer ***= * > > > security services for JSON with encryption, digital signatures, and ***= * > > > message authentication codes (MACs).**** > > >** ** > > > Different proposals for providing such security services have already *= * > ** > > > been defined and implemented. This Working Group will standardize the = * > *** > > > mechanism for integrity protection (signature and MAC) and encryption *= * > ** > > > as well as the format for keys and algorithm identifiers to support ***= * > > > interoperability of security services for protocols that use JSON. The = * > *** > > > Working Group will base its work on well-known message security **** > > > primitives (e.g., CMS), and will solicit input from the rest of the ***= * > > > IETF Security Area to be sure that the security functionality in the **= * > * > > > JSON format is sound.**** > > >** ** > > > As JSON adoption expands, the different applications utilizing JSON ***= * > > > security services will grow and this leads to the need to support **** > > > different requirements.**** > > > The WG will**** > > > develop a generic syntax that can be used by applications to secure ***= * > > > JSON-data, but it will be up to the application to fully specify the **= * > * > > > use of the WG's documents much the same way S/MIME is the application *= * > ** > > > of CMS to MIME-based media types.**** > > >** ** > > > This group is chartered to work on the following deliverables:**** > > >** ** > > > (1) A Standards Track document or documents specifying how to apply ***= * > > > JSON-structured integrity protection to data, including (but not **** > > > limited to) JSON data structures.**** > > > "Integrity protection" includes public-key digital signatures as well *= * > ** > > > as symmetric-key MACs.**** > > >** ** > > > (2) A Standards Track document or documents specifying how to apply a *= * > ** > > > JSON-structured encryption to data, including (but not limited to) **** > > > JSON data structures.**** > > >** ** > > > (3) A Standards Track document specifying how to encode public keys as*= * > ** > > > JSON-**** > > > structured objects.**** > > >** ** > > > (4) A Standards Track document specifying algorithms and algorithm **** > > > identifiers for the previous three documents.**** > > >** ** > > > (5) A Standards Track document specifying how to encode private and ***= * > > > symmetric keys as JSON-structured objects. This document will build **= * > * > > > upon the concepts and structures in (3).**** > > >** ** > > > (6) A Standards Track document specifying a means of protecting **** > > > private and symmetric keys via encryption. This document will build **= * > * > > > upon the concepts and structures in (2) and (5). This document may ***= * > > > register additional algorithms in registries defined by (4).**** > > >** ** > > > (7) An Informational document detailing Use Cases and Requirements for = * > *** > > > JSON Object Signing and Encryption (JOSE).**** > > >** ** > > > (8) An Informational document that tells an application what needs to *= * > ** > > > be specified in order to implement JOSE.**** > > >** ** > > > One or more of these goals may be combined into a single document, in *= * > ** > > > which case the concrete milestones for these goals will be satisfied **= * > * > > > by the consolidated document(s).**** > > >** ** > > > _______________________________________________**** > > > jose mailing list**** > > > jose@ietf.org**** > > > https://www.ietf.org/mailman/listinfo/jose**** > > >** ** > > _______________________________________________**** > > jose mailing list**** > > jose@ietf.org**** > > https://www.ietf.org/mailman/listinfo/jose**** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e01294d0c58041704d9a4d0c2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 5, 2013 at 9:28 AM, Mike Jon= es <Michael.Jones@microsoft.com> wrote:

Hmmm...=A0 I feel really queasy about the proposed rewording for (1), as= it could lead to significant unintended consequences and potential obstacl= es when we go for final approval of the JWS and JWE specs.=A0 Here's wh= y...

=A0

The wording could easily be interpreted as a mandate that the end-repres= entation itself be JSON =96 not just that the representation utilize JSON f= or representing structured data, which is what is actually the case now.=A0= I could easily imagine the new wording enabling a situation where someone would then file= a DISCUSS saying that the current Compact Serialization representations ar= en't JSON and so don't meet the requirements of the charter.


That won't be a problem as= long as there is *a* JSON representation in the base specification. =A0Whi= ch we have agreed to do. =A0

--Richard
<= br>

=A0

=A0

For that reason, I believe we would be FAR better off to leave the first= two charter items exactly as they are at = http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wor= ding.=A0 The current wording is:

=A0

1) A Standards Track document specifying how = to apply JSON-structured

=A0integrity protection to data, including (b= ut not limited to) JSON data

=A0structures. "Integrity protection&quo= t; includes public-key digital

=A0signatures as well as symmetric-key MACs.

=A0

2) A Standards Track document specifyin= g how to apply a JSON-structured

=A0encryption to data, including (but not lim= ited to) JSON data structures.

=A0

So yes, I strongly object to the new wording, as I don=92t want to= open the door for the current representations to be rejected on charter gr= ounds later.=A0 If it helps, you can reassure objectors that we ARE produci= ng pure JSON representations too, but that they=92re not the only JSON-based representations for integr= ity protected and encrypted content.

=A0

Why don=92t we just scale back the recharter request to only add the new= items and leave the existing items alone, if that=92s what it will take to= be approved.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks for asking,

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

=A0

-----Original Message-----
From: jose-bounc= es@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Friday, April 05, 2013 5:29 AM
To: jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comme= nts

=A0

Hi,

=A0

We've gotten what amounts to two discusses on the charter.=A0 I want= ed to run these by the WG in case there were any violent objections.=

=A0

1. (easy one first) What does "JSON-structured integrity protection= " and "JSON-structured encryption" mean?

=A0

It was explained "JSON-structured" means that the metadata abo= ut how you did the encryption/integrity is expressed in JSON not that the p= ayload itself is JSON.=A0 I.e., the algorithm description, key identifiers,= etc.

are in JSON but not necessary the payload.

=A0

I proposed:

=A0

OLD:

=A0

=A0=A0 specifying how to apply JSON-structured integrity

=A0=A0 protection to data

=A0

NEW:

=A0

=A0=A0 specifying a JSON structure for integrity-protected data

=A0

and the same again for encryption:

=A0

OLD:

=A0

=A0=A0 specifying how to apply a JSON-structured encryption to data

=A0

NEW:

=A0

=A0=A0 specifying a JSON structure for encrypted data

=A0

2. (hard one) Barry's been told by some App folks who are working on= new JSON-based protocols that they don't see the applicability of JOSE= to their work.

=A0

I think there is some concern that we're doing our own thing here in= security land and not consulting with others.=A0 That's not a true cha= racterization based the use case we have from ALTO and XMPP, but

nonetheless this feedback worries both Barry and myself.=A0=A0 What I= 9;m

going to do is prompt/prod the Apps folks to engage and say why/how it w= on't work for them.=A0 What we might also do is some education in the a= ppsawg; one of those here's how it works kind of presentations.=A0 We&#= 39;ll reach out, but they need to reach out too because I don't want to have to be pinned waiting on = a input that may never come.=A0 To that end, putting some wording in the ch= arter earlier than the numbered bullet about the uses cases, I think, solve= s this dilemma:

=A0

=A0=A0 The WG will strive to gather use cases to ensure the broadest<= /u>

=A0=A0 possible applicability of the mechanism.

=A0

spt

=A0

On 3/10/13 2:13 PM, Karen O'Donoghue wrote:

> Folks,

>=A0

> Here is the updated charter text based on Sean's comments and M= ike's

> response. If there are any errors, please identify them asap as I p= lan

> to forward this back to Sean (and thus the IESG) in the very near f= uture.

>=A0

> Regards,

> Karen

>=A0

>=A0

> Description of JOSE Working Group

>=A0

> JavaScript Object Notation (JSON) is a text format for the

> serialization of structured data described in RFC 4627.=A0 The JSON

> format is often used for serializing and transmitting structured da= ta

> over a network connection. With the increased usage of JSON in

> protocols in the IETF and elsewhere, there is now a desire to offer

> security services for JSON with encryption, digital signatures, and

> message authentication codes (MACs).

>=A0

> Different proposals for providing such security services have alrea= dy

> been defined and implemented.=A0 This Working Group will standardiz= e the

> mechanism for integrity protection (signature and MAC) and encrypti= on

> as well as the format for keys and algorithm identifiers to support

> interoperability of security services for protocols that use JSON. = The

> Working Group will base its work on well-known message security

> primitives (e.g., CMS), and will solicit input from the rest of the

> IETF Security Area to be sure that the security functionality in th= e

> JSON format is sound.

>=A0

> As JSON adoption expands, the different applications utilizing JSON

> security services will grow and this leads to the need to support

> different requirements.

> The WG will

> develop a generic syntax that can be used by applications to secure

> JSON-data, but it will be up to the application to fully specify th= e

> use of the WG's documents much the same way S/MIME is the appli= cation

> of CMS to MIME-based media types.

>=A0

> This group is chartered to work on the following deliverables:

>=A0

> (1) A Standards Track document or documents specifying how to apply

> JSON-structured integrity protection to data, including (but not

> limited to) JSON data structures.

> "Integrity protection" includes public-key digital signat= ures as well

> as symmetric-key MACs.

>=A0

> (2) A Standards Track document or documents specifying how to apply= a

> JSON-structured encryption to data, including (but not limited to)

> JSON data structures.

>=A0

> (3) A Standards Track document specifying how to encode public keys= as

> JSON-

> structured objects.

>=A0

> (4) A Standards Track document specifying algorithms and algorithm

> identifiers for the previous three documents.

>=A0

> (5) A Standards Track document specifying how to encode private and

> symmetric keys as JSON-structured objects.=A0 This document will bu= ild

> upon the concepts and structures in (3).

>=A0

> (6) A Standards Track document specifying a means of protecting

> private and symmetric keys via encryption.=A0 This document will bu= ild

> upon the concepts and structures in (2) and (5).=A0 This document m= ay

> register additional algorithms in registries defined by (4).=

>=A0

> (7) An Informational document detailing Use Cases and Requirements = for

> JSON Object Signing and Encryption (JOSE).

>=A0

> (8) An Informational document that tells an application what needs = to

> be specified in order to implement JOSE.

>=A0

> One or more of these goals may be combined into a single document, = in

> which case the concrete milestones for these goals will be satisfie= d

> by the consolidated document(s).

>=A0

> _______________________________________________

> jose mailing list

> jose@ietf.org

> https://www.iet= f.org/mailman/listinfo/jose

>=A0

_______________________________________________

jose mailing list

jose@ietf.org

https://www.ietf.org= /mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e01294d0c58041704d9a4d0c2-- From rlb@ipv.sx Fri Apr 5 15:45:40 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450C221F9875 for ; Fri, 5 Apr 2013 15:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muoeXdt8iUYE for ; Fri, 5 Apr 2013 15:45:38 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9601321F986D for ; Fri, 5 Apr 2013 15:45:33 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id l10so4514853oag.30 for ; Fri, 05 Apr 2013 15:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WObknw+Ga+wBrwVRliSrYITFTnNpLYt62XBbl/7SkDE=; b=pLoGPkIW1dRIH9kb2w4onlK471ZVS/twFfsKQE9vDXx8fl7zGLWhLR74ETnfXc7QRP uGsvIN/CcQQM8KYlSm6EcAWoscOeH5RMKa2tzEQfcWu6eF6wujxPIdcewdGYpJ9uPpLr WAvnhgkJu6V9D0XL1Az2j4IIUvRStfUnkbWIqX7LhJEHt/Z97Yu2ofp4aPrsBhV2I8XV GAT9Jlmeaqi/qE+eEY/wSc19LeWTseV56OWwgeFu6YPIOJeDRQNkopFG8nQhRB46d/ZW XC4e/dg/xNxMDLEkL6RejzZZfw1+SbrIHThi/OFPigW3HCiVi9K5PTYTGo4q0Bvp/EJQ iI2g== MIME-Version: 1.0 X-Received: by 10.182.52.102 with SMTP id s6mr9476474obo.87.1365201933215; Fri, 05 Apr 2013 15:45:33 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 5 Apr 2013 15:45:33 -0700 (PDT) X-Originating-IP: [128.89.255.18] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 5 Apr 2013 18:45:33 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=14dae939960746be7704d9a4d896 X-Gm-Message-State: ALoCoQl7nG2WmkG7HtfE/GT2ydSVAeRKWAco2K20RSMwr67hrWunTMp29qpKbuNzyzdzAYTAySKx Cc: Sean Turner , Barry Leiba , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:45:40 -0000 --14dae939960746be7704d9a4d896 Content-Type: text/plain; charset=ISO-8859-1 I could live with that text, but I really dislike weasel words like "JSON-based". What does that mean? Given that we're putting a JSON serialization in the base spec, it doesn't seem like Sean's text would require any change in direction. --Richard On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones wrote: > Thanks Barry. > > How about "representing integrity-protected data using JSON-based data > structures" and "representing encrypted data using JSON-based data > structures"? That would read better than the original and still not be > able to be misconstrued to say that what the working group has produced > doesn't meet the charter goals. > > Thanks, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Barry Leiba > Sent: Friday, April 05, 2013 7:37 AM > To: Mike Jones > Cc: Sean Turner; jose@ietf.org > Subject: Re: [jose] updated draft charter text incorporating AD's comments > > > For that reason, I believe we would be FAR better off to leave the > > first two charter items exactly as they are at > > http://datatracker.ietf.org/wg/jose/charter/ than to accept the new > wording. > > The current wording is: > > > > 1) A Standards Track document specifying how to apply JSON-structured > > integrity protection to data, including (but not limited to) JSON data > > structures. "Integrity protection" includes public-key digital > > signatures as well as symmetric-key MACs. > > > > 2) A Standards Track document specifying how to apply a > > JSON-structured encryption to data, including (but not limited to) JSON > data structures. > > The problem is that I do not understand what you mean by "JSON-structured > integrity protection" and "JSON-structured encryption". Sean's suggested > wording is intended to say this in an understandable way; if it's not > correct, please try to come up with an alternative. The existing text > doesn't work, because I don't understand how to apply the modifier > "JSON-structured" to the noun "encryption" and get anything sensible out of > it. What does it mean for *encryption* to be "JSON-structured"? > > > So yes, I strongly object to the new wording, as I don't want to open > > the door for the current representations to be rejected on charter > > grounds later. If it helps, you can reassure objectors that we ARE > > producing pure JSON representations too, but that they're not the only > > JSON-based representations for integrity protected and encrypted content. > > To be clear: what you're producing is not the issue. It's an issue of the > wording in the charter. > > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --14dae939960746be7704d9a4d896 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I could live with that text, but I really dislike weasel words like "J= SON-based". =A0What does that mean?

Given that we're puttin= g a JSON serialization in the base spec, it doesn't seem like Sean'= s text would require any change in direction.

--Richard


On Fri, Apr = 5, 2013 at 11:10 AM, Mike Jones <Michael.Jones@microsoft.com= > wrote:
Thanks Barry.

How about "representing integrity-protected data using JSON-based data= structures" and "representing encrypted data using JSON-based da= ta structures"? =A0That would read better than the original and still = not be able to be misconstrued to say that what the working group has produ= ced doesn't meet the charter goals.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Barry Leiba
Sent: Friday, April 05, 2013 7:37 AM
To: Mike Jones
Cc: Sean Turner; jose@ietf.org
Subject: Re: [jose] updated draft charter text incorporating AD's comme= nts

> For that reason, I belie= ve we would be FAR better off to leave the
> first two charter items exactly as they are at
> http://datatracker.ietf.org/wg/jose/charter/ than to accept the ne= w wording.
> The current wording is:
>
> 1) A Standards Track document specifying how to apply JSON-structured<= br> > integrity protection to data, including (but not limited to) JSON data=
> structures. "Integrity protection" includes public-key digit= al
> signatures as well as symmetric-key MACs.
>
> 2) A Standards Track document specifying how to apply a
> JSON-structured =A0encryption to data, including (but not limited to) = JSON data structures.

The problem is that I do not understand what you mean by "JSON-structu= red integrity protection" and "JSON-structured encryption". = =A0Sean's suggested wording is intended to say this in an understandabl= e way; if it's not correct, please try to come up with an alternative. = =A0The existing text doesn't work, because I don't understand how t= o apply the modifier "JSON-structured" to the noun "encrypti= on" and get anything sensible out of it. =A0What does it mean for *enc= ryption* to be "JSON-structured"?

> So yes, I strongly object to the new wording, as I don't want to o= pen
> the door for the current representations to be rejected on charter
> grounds later. =A0If it helps, you can reassure objectors that we ARE<= br> > producing pure JSON representations too, but that they're not the = only
> JSON-based representations for integrity protected and encrypted conte= nt.

To be clear: what you're producing is not the issue. =A0It's an iss= ue of the wording in the charter.

Barry
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--14dae939960746be7704d9a4d896-- From Michael.Jones@microsoft.com Fri Apr 5 16:16:00 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9421F98AE for ; Fri, 5 Apr 2013 16:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbAwPjpAn6QX for ; Fri, 5 Apr 2013 16:15:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1833B21F9885 for ; Fri, 5 Apr 2013 16:15:49 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.202) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 5 Apr 2013 23:15:34 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 5 Apr 2013 23:15:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 5 Apr 2013 23:15:09 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] updated draft charter text incorporating AD's comments Thread-Index: AQHOHbsFzhPDcbJYm0e4TO3t5oFBJZjHttqAgAAMlKCAABdMgIAAB+EQgACAfoCAAAgO0A== Date: Fri, 5 Apr 2013 23:15:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675BB269@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675BB269TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(51704002)(24454001)(164054002)(66066001)(53806001)(56776001)(63696002)(5343655001)(65816001)(51856001)(54356001)(54316002)(16236675001)(59766001)(79102001)(55846006)(5343635001)(81542001)(20776003)(81342001)(16406001)(47976001)(33656001)(56816002)(77982001)(50986001)(47446002)(74502001)(47736001)(76482001)(69226001)(44976002)(512954001)(74662001)(15202345001)(4396001)(49866001)(46102001)(31966008)(80022001)(71186001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB025; H:TK5EX14MLTC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08076ABC99 Cc: Sean Turner , Barry Leiba , "jose@ietf.org" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 23:16:00 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675BB269TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you can live with that, let's use it. I remain profoundly uncomfortable= with Sean's wording. Thanks, -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Friday, April 05, 2013 3:46 PM To: Mike Jones Cc: Barry Leiba; Sean Turner; jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comments I could live with that text, but I really dislike weasel words like "JSON-b= ased". What does that mean? Given that we're putting a JSON serialization in the base spec, it doesn't = seem like Sean's text would require any change in direction. --Richard On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones > wrote: Thanks Barry. How about "representing integrity-protected data using JSON-based data stru= ctures" and "representing encrypted data using JSON-based data structures"?= That would read better than the original and still not be able to be misc= onstrued to say that what the working group has produced doesn't meet the c= harter goals. Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Barry Leiba Sent: Friday, April 05, 2013 7:37 AM To: Mike Jones Cc: Sean Turner; jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comments > For that reason, I believe we would be FAR better off to leave the > first two charter items exactly as they are at > http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wordi= ng. > The current wording is: > > 1) A Standards Track document specifying how to apply JSON-structured > integrity protection to data, including (but not limited to) JSON data > structures. "Integrity protection" includes public-key digital > signatures as well as symmetric-key MACs. > > 2) A Standards Track document specifying how to apply a > JSON-structured encryption to data, including (but not limited to) JSON = data structures. The problem is that I do not understand what you mean by "JSON-structured i= ntegrity protection" and "JSON-structured encryption". Sean's suggested wo= rding is intended to say this in an understandable way; if it's not correct= , please try to come up with an alternative. The existing text doesn't wor= k, because I don't understand how to apply the modifier "JSON-structured" t= o the noun "encryption" and get anything sensible out of it. What does it = mean for *encryption* to be "JSON-structured"? > So yes, I strongly object to the new wording, as I don't want to open > the door for the current representations to be rejected on charter > grounds later. If it helps, you can reassure objectors that we ARE > producing pure JSON representations too, but that they're not the only > JSON-based representations for integrity protected and encrypted content. To be clear: what you're producing is not the issue. It's an issue of the = wording in the charter. Barry _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943675BB269TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you can live with that= , let’s use it.  I remain profoundly uncomfortable with SeanR= 17;s wording.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks,

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

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Friday, April 05, 2013 3:46 PM
To: Mike Jones
Cc: Barry Leiba; Sean Turner; jose@ietf.org
Subject: Re: [jose] updated draft charter text incorporating AD's co= mments

 

I could live with that text, but I really dislike we= asel words like "JSON-based".  What does that mean?

Given that we're putting a JSON serialization in the base spec, it doesn't = seem like Sean's text would require any change in direction.

 

--Richard

On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks Barry.

How about "representing integrity-protected data using JSON-based data= structures" and "representing encrypted data using JSON-based da= ta structures"?  That would read better than the original and sti= ll not be able to be misconstrued to say that what the working group has produced doesn't meet the charter goals.

                     = ;           Thanks,
                     = ;           -- Mike


-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Barry Leiba
Sent: Friday, April 05, 2013 7:37 AM
To: Mike Jones
Cc: Sean Turner; jose@ietf.org
Subject: Re: [jose] updated draft charter text incorporating AD's comments<= o:p>

> For that reason, I believe we would be FAR bett= er off to leave the
> first two charter items exactly as they are at
> http://datatracker.ietf.org/wg/jose/charter/ than to accept the ne= w wording.
> The current wording is:
>
> 1) A Standards Track document specifying how to apply JSON-structured<= br> > integrity protection to data, including (but not limited to) JSON data=
> structures. "Integrity protection" includes public-key digit= al
> signatures as well as symmetric-key MACs.
>
> 2) A Standards Track document specifying how to apply a
> JSON-structured  encryption to data, including (but not limited t= o) JSON data structures.

The problem is that I do not understand what you mean by "JSON-structu= red integrity protection" and "JSON-structured encryption". =  Sean's suggested wording is intended to say this in an understandable= way; if it's not correct, please try to come up with an alternative.  The existing text doesn't work, because I don't underst= and how to apply the modifier "JSON-structured" to the noun "= ;encryption" and get anything sensible out of it.  What does it m= ean for *encryption* to be "JSON-structured"?

> So yes, I strongly object to the new wording, as I don't want to open<= br> > the door for the current representations to be rejected on charter
> grounds later.  If it helps, you can reassure objectors that we A= RE
> producing pure JSON representations too, but that they're not the only=
> JSON-based representations for integrity protected and encrypted conte= nt.

To be clear: what you're producing is not the issue.  It's an issue of= the wording in the charter.

Barry
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B1680429673943675BB269TK5EX14MBXC283r_-- From mpeck@mitre.org Sun Apr 7 12:32:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F4821F8A55 for ; Sun, 7 Apr 2013 12:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5ItT21afDYV for ; Sun, 7 Apr 2013 12:32:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0D21F863B for ; Sun, 7 Apr 2013 12:32:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E399B1F0636; Sun, 7 Apr 2013 15:32:04 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D29931F03A6; Sun, 7 Apr 2013 15:32:04 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.190]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Sun, 7 Apr 2013 15:32:04 -0400 From: "Peck, Michael A" To: Jim Schaad Thread-Topic: [jose] Use of AES-HMAC algorithm - Consensus Request Thread-Index: Ac4xjwlItr+CaRraTdmKwkwJbuMokQAdROmA Date: Sun, 7 Apr 2013 19:32:03 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> In-Reply-To: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 19:32:06 -0000 I prefer using a KDF, as I think the approach of using a long key over-comp= licates key management by requiring generation and transport of a longer ke= y than necessary, and it may also provide a false sense of the overall secu= rity level. As previously discussed, the Concat KDF is not appropriate, but there are o= ther NIST KDFs that seem acceptable for this key expansion purpose. For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1, wit= h the PRF algorithm set to the same HMAC algorithm used in the correspondin= g AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SHA-25= 6, and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512). For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128-bit= "master" key: Expanded key =3D HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256" | = 0x00 | 0x00 0x00 0x01 0x00) AES key =3D first 128 bits of expanded key HMAC key =3D second 128 bits of expanded key If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it woul= d be worth discussing with the draft authors whether they are interested in= performing the KDF in the AEAD algorithm itself (for example, input a 128-= bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be responsible= for deriving the 128-bit AES key and 128-bit HMAC key). Mike >-----Original Message----- >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Jim Schaad >Sent: Thursday, April 04, 2013 7:51 PM >To: jose@ietf.org >Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request > > > >At the request of the editors, this is a formal consensus call on the firs= t >item in the list below. If there are objects to use a single long key >rather than a KDF function for the AES-CBC/HMAC algorithm please speak up >now. To date nobody has said that I was wrong to assume the consensus on >that item. > >Call ends in one week. > >Jim > > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Jim >> Schaad >> Sent: Wednesday, March 27, 2013 3:21 PM >> To: jose@ietf.org >> Subject: [jose] Use of AES-HMAC algorithm >> >> >> After spending time looking at and thinking about how to resolve this >issue >> since I was unable to do so at the last F2F meeting. I have come up wit= h >the >> following set of issues that might need to be addressed as part of >resolving >> this issue. >> >> 1. Do we change from using KDC to having a double size key for the >> algorithm? I think that there is probably a consensus that this should = be >done. >> >> 2. Should IVs be prepended to the encrypted body as part of the encoding >> steps? If so then this change should be universal. >> >> Doing so would eliminate one field from all of the encoding formats whic= h >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is for >all >> algorithms as the IV would no longer be a separate item. >> >> 3. Should Authentication Tags be appended to the encrypted body as part = of >> the encoding steps? >> >> Doing so would eliminate one field from all of the encoding formats whic= h >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is for >all >> algorithms as the IV would no longer be a separate item. >> Doing so would force a re-organization for the multiple recipient case a= s >> either all recipient specific data would need to be excluded from the >> authentication step or all of the recipient data would need to be includ= ed >for >> by all recipients. >> Changing how the recipient info is process is going to give a performanc= e >> benefit for sending encrypted items for multiple recipients. >> The current strategy of a single IV and key pair with AES-GCM and >different >> authentication data needs to have CFRG look at it. I am worried that it >might >> be a serious security flaw. >> >> 4. Should we reference the McGrew draft and provide text on how things >are >> changed or should we "copy" the draft into our text? >> >> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrappin= g, >> does this change how we think about any of the above questions? >> >> Allowing for AES-GCM for key wrapping has a benefit for hardware >situations >> as only the encrypt and not the decrypt functions need to be placed in >> hardware. However allowing for this key wrapping give a problem as ther= e >is >> no way to encode the three fields into the encrypted value unless with u= se >> either a JSON structure in this location or we do use the single appende= d >> binary output stream. The first approach leads to an expansion of the >field by >> double base64 encoding which is highly undesirable. >> >> Jim >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > >_______________________________________________ >jose mailing list >jose@ietf.org >https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Sun Apr 7 21:47:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441AD21F9128 for ; Sun, 7 Apr 2013 21:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmcvDLIgD4cs for ; Sun, 7 Apr 2013 21:47:06 -0700 (PDT) Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7D21F9123 for ; Sun, 7 Apr 2013 21:47:06 -0700 (PDT) Received: by mail-da0-f48.google.com with SMTP id p8so2447930dan.21 for ; Sun, 07 Apr 2013 21:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=KRNbhr7ijThhSwbYhymfGXpS/Ap7KRU491sdOnc+QTc=; b=0zlqSvVrG2BKq2t8Ee24lhYJ5ZxUoctmhDO2xJFo9S/jUyXYR9onc0rgSS2YsCJdnw sf4WfytwUZQLYeqg9k3sY0FkW34OGEAxEUlwpSTA5ftAZ4IYMolzfthXZwJClBJDG/9s nlO1L5wmb4rq6kD2O3jUuQJDwURxJUbdRt96sI3J8pZJn7GZllqO9vsZnTLAxH/3jXNS gf8utrtMxSCWgRGl6mWWx0p9wqxoxsB2fAL6SKq0bAXw9NMPsGaIXp4EQVb+yCioyPX/ 9w3h62Kmrgi3r6TH0bYp9XMTWNKc3SQt/1OEmDVhkqJLKWR/FkOQfA9D+xhldemKVGNy c91A== X-Received: by 10.66.122.39 with SMTP id lp7mr9332469pab.116.1365396425766; Sun, 07 Apr 2013 21:47:05 -0700 (PDT) Received: from [10.0.0.58] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id ky10sm35938082pab.23.2013.04.07.21.47.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Apr 2013 21:47:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> Date: Sun, 7 Apr 2013 21:47:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> To: "Peck, Michael A" X-Mailer: Apple Mail (2.1503) Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 04:47:08 -0000 FWIW: I'd strongly prefer a longer key than a different KDF scheme. On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" wrote: > I prefer using a KDF, as I think the approach of using a long key = over-complicates key management by requiring generation and transport of = a longer key than necessary, and it may also provide a false sense of = the overall security level. >=20 > As previously discussed, the Concat KDF is not appropriate, but there = are other NIST KDFs that seem acceptable for this key expansion purpose. > For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section = 5.1, with the PRF algorithm set to the same HMAC algorithm used in the = corresponding AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with = AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + = HMAC-SHA-512). >=20 > For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted = 128-bit "master" key: > Expanded key =3D HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | = "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00) > AES key =3D first 128 bits of expanded key > HMAC key =3D second 128 bits of expanded key >=20 > If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it = would be worth discussing with the draft authors whether they are = interested in performing the KDF in the AEAD algorithm itself (for = example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 = and have it be responsible for deriving the 128-bit AES key and 128-bit = HMAC key). >=20 > Mike >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Jim Schaad >> Sent: Thursday, April 04, 2013 7:51 PM >> To: jose@ietf.org >> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request >>=20 >> >>=20 >> At the request of the editors, this is a formal consensus call on the = first >> item in the list below. If there are objects to use a single long = key >> rather than a KDF function for the AES-CBC/HMAC algorithm please = speak up >> now. To date nobody has said that I was wrong to assume the = consensus on >> that item. >>=20 >> Call ends in one week. >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Jim >>> Schaad >>> Sent: Wednesday, March 27, 2013 3:21 PM >>> To: jose@ietf.org >>> Subject: [jose] Use of AES-HMAC algorithm >>>=20 >>> >>> After spending time looking at and thinking about how to resolve = this >> issue >>> since I was unable to do so at the last F2F meeting. I have come up = with >> the >>> following set of issues that might need to be addressed as part of >> resolving >>> this issue. >>>=20 >>> 1. Do we change from using KDC to having a double size key for the >>> algorithm? I think that there is probably a consensus that this = should be >> done. >>>=20 >>> 2. Should IVs be prepended to the encrypted body as part of the = encoding >>> steps? If so then this change should be universal. >>>=20 >>> Doing so would eliminate one field from all of the encoding formats = which >>> should be considered a plus. >>> Doing so would force code writers to understand how large the IV is = for >> all >>> algorithms as the IV would no longer be a separate item. >>>=20 >>> 3. Should Authentication Tags be appended to the encrypted body as = part of >>> the encoding steps? >>>=20 >>> Doing so would eliminate one field from all of the encoding formats = which >>> should be considered a plus. >>> Doing so would force code writers to understand how large the IV is = for >> all >>> algorithms as the IV would no longer be a separate item. >>> Doing so would force a re-organization for the multiple recipient = case as >>> either all recipient specific data would need to be excluded from = the >>> authentication step or all of the recipient data would need to be = included >> for >>> by all recipients. >>> Changing how the recipient info is process is going to give a = performance >>> benefit for sending encrypted items for multiple recipients. >>> The current strategy of a single IV and key pair with AES-GCM and >> different >>> authentication data needs to have CFRG look at it. I am worried = that it >> might >>> be a serious security flaw. >>>=20 >>> 4. Should we reference the McGrew draft and provide text on how = things >> are >>> changed or should we "copy" the draft into our text? >>>=20 >>> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key = wrapping, >>> does this change how we think about any of the above questions? >>>=20 >>> Allowing for AES-GCM for key wrapping has a benefit for hardware >> situations >>> as only the encrypt and not the decrypt functions need to be placed = in >>> hardware. However allowing for this key wrapping give a problem as = there >> is >>> no way to encode the three fields into the encrypted value unless = with use >>> either a JSON structure in this location or we do use the single = appended >>> binary output stream. The first approach leads to an expansion of = the >> field by >>> double base64 encoding which is highly undesirable. >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From mamille2@cisco.com Mon Apr 8 08:33:31 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF7521F9767 for ; Mon, 8 Apr 2013 08:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6172f7b5wEu5 for ; Mon, 8 Apr 2013 08:33:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 36E7F21F9593 for ; Mon, 8 Apr 2013 08:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9731; q=dns/txt; s=iport; t=1365435210; x=1366644810; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ueLC9939q54h1Xe5Gnd9CpaHDOpxTiaapUE2Eu4sC3w=; b=S3EE09q5h/Wm8SkdbKJH8LorLaqXPKa8Nux05uY3xpO4HnOt6rcfcb28 ZmXu4lzkJ4BM+NgUtUAFQxAOEppRBn9LAd3OQ8DaZiKygl7ppii+e3Xd8 lUgaIz8p6dYMhlOWA/Bf/UpNyBk/L1UjHFadJfWGjVRhhLUB0PC4zoZuX Y=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHniYlGtJV2b/2dsb2JhbABRgwY2wSqBCRZ0gh8BAQEDAQEBAWsLBQcEAgEIEQQBAQEKHQcCHwYLFAkIAQEEDgUIBod0AwkGDLMcDYlZBIxQgiImCwcGglphA49KgSmEII1UhRuDC4Io X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="p7s'?scan'208";a="196226065" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 08 Apr 2013 15:33:29 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r38FXTK2031919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 15:33:29 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.146]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 10:33:29 -0500 From: "Matt Miller (mamille2)" To: Dick Hardt Thread-Topic: [jose] Use of AES-HMAC algorithm - Consensus Request Thread-Index: Ac4xjwlItr+CaRraTdmKwkwJbuMokQAdROmAAI57QgAAFpI5gA== Date: Mon, 8 Apr 2013 15:33:28 +0000 Message-ID: References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.52] Content-Type: multipart/signed; boundary="Apple-Mail=_5A0567A7-1FC2-42D7-A0DA-8CDABE5F53BA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Jim Schaad , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 15:33:31 -0000 --Apple-Mail=_5A0567A7-1FC2-42D7-A0DA-8CDABE5F53BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 on a longer key. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Apr 7, 2013, at 10:47 PM, Dick Hardt wrote: > FWIW: I'd strongly prefer a longer key than a different KDF scheme. >=20 > On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" = wrote: >=20 >> I prefer using a KDF, as I think the approach of using a long key = over-complicates key management by requiring generation and transport of = a longer key than necessary, and it may also provide a false sense of = the overall security level. >>=20 >> As previously discussed, the Concat KDF is not appropriate, but there = are other NIST KDFs that seem acceptable for this key expansion purpose. >> For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section = 5.1, with the PRF algorithm set to the same HMAC algorithm used in the = corresponding AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with = AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + = HMAC-SHA-512). >>=20 >> For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted = 128-bit "master" key: >> Expanded key =3D HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | = "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00) >> AES key =3D first 128 bits of expanded key >> HMAC key =3D second 128 bits of expanded key >>=20 >> If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think = it would be worth discussing with the draft authors whether they are = interested in performing the KDF in the AEAD algorithm itself (for = example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 = and have it be responsible for deriving the 128-bit AES key and 128-bit = HMAC key). >>=20 >> Mike >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >>> Jim Schaad >>> Sent: Thursday, April 04, 2013 7:51 PM >>> To: jose@ietf.org >>> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request >>>=20 >>> >>>=20 >>> At the request of the editors, this is a formal consensus call on = the first >>> item in the list below. If there are objects to use a single long = key >>> rather than a KDF function for the AES-CBC/HMAC algorithm please = speak up >>> now. To date nobody has said that I was wrong to assume the = consensus on >>> that item. >>>=20 >>> Call ends in one week. >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>> Jim >>>> Schaad >>>> Sent: Wednesday, March 27, 2013 3:21 PM >>>> To: jose@ietf.org >>>> Subject: [jose] Use of AES-HMAC algorithm >>>>=20 >>>> >>>> After spending time looking at and thinking about how to resolve = this >>> issue >>>> since I was unable to do so at the last F2F meeting. I have come = up with >>> the >>>> following set of issues that might need to be addressed as part of >>> resolving >>>> this issue. >>>>=20 >>>> 1. Do we change from using KDC to having a double size key for the >>>> algorithm? I think that there is probably a consensus that this = should be >>> done. >>>>=20 >>>> 2. Should IVs be prepended to the encrypted body as part of the = encoding >>>> steps? If so then this change should be universal. >>>>=20 >>>> Doing so would eliminate one field from all of the encoding formats = which >>>> should be considered a plus. >>>> Doing so would force code writers to understand how large the IV is = for >>> all >>>> algorithms as the IV would no longer be a separate item. >>>>=20 >>>> 3. Should Authentication Tags be appended to the encrypted body as = part of >>>> the encoding steps? >>>>=20 >>>> Doing so would eliminate one field from all of the encoding formats = which >>>> should be considered a plus. >>>> Doing so would force code writers to understand how large the IV is = for >>> all >>>> algorithms as the IV would no longer be a separate item. >>>> Doing so would force a re-organization for the multiple recipient = case as >>>> either all recipient specific data would need to be excluded from = the >>>> authentication step or all of the recipient data would need to be = included >>> for >>>> by all recipients. >>>> Changing how the recipient info is process is going to give a = performance >>>> benefit for sending encrypted items for multiple recipients. >>>> The current strategy of a single IV and key pair with AES-GCM and >>> different >>>> authentication data needs to have CFRG look at it. I am worried = that it >>> might >>>> be a serious security flaw. >>>>=20 >>>> 4. Should we reference the McGrew draft and provide text on how = things >>> are >>>> changed or should we "copy" the draft into our text? >>>>=20 >>>> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key = wrapping, >>>> does this change how we think about any of the above questions? >>>>=20 >>>> Allowing for AES-GCM for key wrapping has a benefit for hardware >>> situations >>>> as only the encrypt and not the decrypt functions need to be placed = in >>>> hardware. However allowing for this key wrapping give a problem as = there >>> is >>>> no way to encode the three fields into the encrypted value unless = with use >>>> either a JSON structure in this location or we do use the single = appended >>>> binary output stream. The first approach leads to an expansion of = the >>> field by >>>> double base64 encoding which is highly undesirable. >>>>=20 >>>> Jim >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_5A0567A7-1FC2-42D7-A0DA-8CDABE5F53BA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQwODE1MzMyN1owIwYJKoZIhvcNAQkEMRYEFL55nqPUgkNscEymz5TchEOqbhrnMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCa/N94qX3Ikn63LobmHga2HyucKsVkXz+bI7x8hFtO Xg61bP4j8jgFeEf6t6F6e5iSrNQclDQFy63Sa4JpVUY3iwrhXtXrkdhB/u0TTxb607PiNObmDRG0 gBwIhGy1wwf/ajcanlon2SXcKe7yl04Zjxd2imQOw82ScFsuCy/yEdvLWYw6c3uF7sOESRzaB77D +yH95WMR+Xd/k+9nqDS3hws7QXtZNs0OZoHlw5UrIgq5ghWE5LRra14Uu2/MUBCQyRMF6G5Wxk84 eb0TX5gRcKNfXDamS/JRVcGU6nTsQuvHfPy345SweTvRgam1wrIjondmnRIgLOo8vy7BDVCMAAAA AAAA --Apple-Mail=_5A0567A7-1FC2-42D7-A0DA-8CDABE5F53BA-- From mamille2@cisco.com Mon Apr 8 10:46:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB921F9428 for ; Mon, 8 Apr 2013 10:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOwV-j6YH3Bp for ; Mon, 8 Apr 2013 10:46:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8258921F95ED for ; Mon, 8 Apr 2013 10:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10588; q=dns/txt; s=iport; t=1365443175; x=1366652775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BrTC7aOq/MyGZjkBOlX1G28V/9+27ENQpLbGdxP7CYA=; b=U0lQ0G6oR5ComXtonZj+tAUAfraVrn0ArnEPluaAkoLD4gTZ/VO1dI9E 5sMf2pHNVc+DUQ6CS4WZyJ047xgGAV4YjueZ2Zwdz+IaC/v95kfhNddVG aLOc9w4IlOPMpMauKaY5mxVYoC/Toj9fLMadcymmpBUuD872MNojlbRff U=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJIBY1GtJXG8/2dsb2JhbABHCoMGNsErgQoWdIIfAQEBAwEBAQFrCwUHBAIBCA4DBAEBAQoMARAHAh8GCxQJCAIEDgUIBod0AwkGDLNEDYldjFCBFxR3BiALBwICAgwBgk1hA49KgSmEIIMCilIDhRiDC4FsBxce X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="p7s'?scan'208";a="196299238" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 08 Apr 2013 17:46:15 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r38HkEN2027221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 17:46:14 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.146]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 12:46:14 -0500 From: "Matt Miller (mamille2)" To: John Bradley Thread-Topic: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names Thread-Index: AQHOMWXNnDjlVDM08UGHXBnquKKpX5jM8vKA Date: Mon, 8 Apr 2013 17:46:13 +0000 Message-ID: References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com> <5447C845-C9B7-4A43-8AFC-69E503B0F908@ve7jtb.com> In-Reply-To: <5447C845-C9B7-4A43-8AFC-69E503B0F908@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.52] Content-Type: multipart/signed; boundary="Apple-Mail=_94CAE40D-30B8-4EAC-B37D-A050D81BC295"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rlb@ipv.sx" , "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Mike Jones , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:46:16 -0000 --Apple-Mail=_94CAE40D-30B8-4EAC-B37D-A050D81BC295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To be clear in XMPP, the sender doesn't know the public key of the = recipient(s), but does know the address (not name). XMPP addresses have = very specific semantics (RFC 6122), to the point where aliasing has = proven to be practically impossible to do. At the same time, I don't = want to be concerned with JOSE-level mismatches because of the = addressing semantics. In my opinion, including "iss" and/or "aud" in JWE doesn't buy XMPP = anything, but does introduce a new failure point. I don't think it's = reasonable to expect an XMPP application to store all keys globally. At = most, I expect the key relevant to the user's login would be globally = available, but all session keys would be isolated from each other; "kid" = should be enough to resolve the proper key. I'd rather not add something to JWE/JWS unless there's a broader need. = So far I've only seen mention of JWT use cases that need this, and my = own which I'm currently not in favor of including. Personally, I think the pending changes on JWE/JWS/JWK header = criticality, as well as a decent registry of parameters (which is = defined in JWE, but might need some further definition) means JWT can = add these header parameters without impacting all JOSE-using = applications. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Apr 4, 2013, at 12:52 PM, John Bradley wrote: > I am not against having them as JWE header elements, I have raised the = point in several discussions. >=20 > However given that the decryption key is generally already in the = hands of the RP it is hard to make the argument that a kid, thumbprint = or jwk object are not enough for the recipient to identify what = decryption key to use. >=20 > I can see a use in a case like Matt Millers XMPP encryption example = where the sender doesn't know the public key of the recipient only its = name in that case the recipient won't have the decryption key and needs = to know in the unencrypted part of the message who to go and ask for the = key. >=20 > I think in the XMPP case the recipient sends its public key and the = received "kid" back to the issuer and asks for the decryption key to be = encrypted by its public key and sent back. This is perhaps the sort of = thing where having the iss in the unencrypted envelope is a requirement. >=20 > "aud" is also arguably useful if you have a multi hop situation where = the client needs to make a forwarding decision without creating yet = another level of wrapping for the token. >=20 > So I do see uses for them. =20 >=20 > I do agree with Mike that it may be best to use the definitions in JWT = and have the processing rule about what happens if you get the claim in = the header and in the body or if it is only in the header laid out = there. =20 >=20 > The thing that is important in a JWE context is if those claims are = going to be integrity protected. There is continued debate about = removing the envelope from the integrity protection. That is a JWE = issue. I also think if they are in JWT as being allowed in the JWE = header referencing that from JWE is not a bad thing.=20 >=20 > John B. >=20 >=20 > On 2013-04-04, at 1:32 PM, Mike Jones = wrote: >=20 >> Responding to your "unsettled" remark, I suspect most people are fine = with having the "aud" and "iss" be claims in the JWT where they normally = are. Yes, you have to decrypt the token to get these claim values, but = if you're going to use the token, you'll have to do that anyway. >>=20 >> I don't think it's clear to most people what problem is being solved = by potentially these fields to be present in a different location. = Without a compelling use case, this just seems like more to implement = without a clear benefit of doing so. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Wednesday, April 03, 2013 9:29 PM >> To: jose issue tracker >> Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Mike Jones; = rlb@ipv.sx; jose@ietf.org >> Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header = Parameter Names >>=20 >> Actually, Mike was suggesting that the issue be moved to the JWT WG.=20= >>=20 >> I'll settle with the JWE spec pointing to an IANA registry. Speaking = as an implementer, if there is a list of reserved names in the spec, I'm = likely to think that is all of them. >>=20 >> I'm a little unsettled that no one else has had any feedback on = having 'aud' and 'iss' in the JWE header. Is my implementation the only = that has that requirement?=20 >>=20 >> -- Dick >>=20 >> On Apr 3, 2013, at 8:57 PM, "jose issue tracker" = wrote: >>=20 >>> #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names >>>=20 >>>=20 >>> Comment (by rlb@ipv.sx): >>>=20 >>> I agree with Mike that these don't really belong in the core JWE/JWS=20= >>> specs. >>>=20 >>> I would suggest we address this issue more generally, by creating an=20= >>> IANA registry of reserved parameter names, with a fairly liberal=20 >>> inclusion policy. That registry could have a field to indicate=20 >>> whether JOSE implementations are REQUIRED to support a given = parameter=20 >>> (MTI parameters). (Note that this is different from whether a JOSE=20= >>> object is REQUIRED to contain a parameter.) Perhaps we could have=20= >>> optional parameters under a fairly liberal policy (e.g., = Specification=20 >>> Required), with a higher bar for MTI parameters (e.g., Standards = Action). >>>=20 >>> If we set up the registry in this way, then Dick could write a short=20= >>> Informational document that would register these fields. >>>=20 >>> -- >>> = -------------------------+-------------------------------------------- >>> -------------------------+----- >>> Reporter: | Owner: draft-ietf-jose-json-web- >>> dick.hardt@gmail.com | encryption@tools.ietf.org >>> Type: enhancement | Status: new >>> Priority: major | Milestone: >>> Component: json-web- | Version: >>> encryption | Resolution: >>> Severity: - | >>> Keywords: | >>> = -------------------------+-------------------------------------------- >>> -------------------------+----- >>>=20 >>> Ticket URL:=20 >>> >>> jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_94CAE40D-30B8-4EAC-B37D-A050D81BC295 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQwODE3NDYxNFowIwYJKoZIhvcNAQkEMRYEFKX5MMaKwdXEE74GvyQjGhijyctOMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBfU8y4rXZBfZ03uADibb1EYdHp82+a9nhg9B6uY+X4 KJgRVsjjaRWoCXa5J971afeo9NQ78mwFiW+eactF79ipc9QU6wUr6AdRMuUcuQR/E/rZuLtDqO+q Pml9tN5Q5jOUF3pGtg8Nouwrq9iQ147Tx2r9X5PLznQFT1AyOKh9bnbBqPYLiBFgBNQQ2hZM25xY F/hYf3FaZTCQipTikn+waJe+lPxS1t12FnwGpdQpDIEDE5746xnhPeDA5SuDVE+wRQCgHl0lXE9Y 2iUz464ETmcWP7YJUzqZ0DIVpeVmn3W3a6Qt8sIXKAc3OzB6lAgeb+iIVIw+C1Iezw5vspR0AAAA AAAA --Apple-Mail=_94CAE40D-30B8-4EAC-B37D-A050D81BC295-- From turners@ieca.com Mon Apr 8 13:41:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A121F907E for ; Mon, 8 Apr 2013 13:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ba7JcoQ0wXZ for ; Mon, 8 Apr 2013 13:41:04 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.82.3]) by ietfa.amsl.com (Postfix) with ESMTP id D55CA21F84D9 for ; Mon, 8 Apr 2013 13:41:03 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 9E9CBD00669B7; Mon, 8 Apr 2013 15:40:56 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 8FFEED0066997 for ; Mon, 8 Apr 2013 15:40:56 -0500 (CDT) Received: from [108.45.16.214] (port=53255 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UPIsB-0000aC-DQ for jose@ietf.org; Mon, 08 Apr 2013 15:41:03 -0500 Message-ID: <51632B5E.9070800@ieca.com> Date: Mon, 08 Apr 2013 16:41:02 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "jose@ietf.org" References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <4E1F6AAD24975D4BA5B1680429673943675B77BC@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675B7AF1@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675BB269@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675BB269@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:53255 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 23 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:41:04 -0000 This feedback loop does work ;) I'll put in the modified wording. spt On 4/5/13 7:15 PM, Mike Jones wrote: > If you can live with that, let’s use it. I remain profoundly > uncomfortable with Sean’s wording. > > Thanks, > > -- Mike > > *From:*Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Friday, April 05, 2013 3:46 PM > *To:* Mike Jones > *Cc:* Barry Leiba; Sean Turner; jose@ietf.org > *Subject:* Re: [jose] updated draft charter text incorporating AD's comments > > I could live with that text, but I really dislike weasel words like > "JSON-based". What does that mean? > > Given that we're putting a JSON serialization in the base spec, it > doesn't seem like Sean's text would require any change in direction. > > --Richard > > On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones > wrote: > > Thanks Barry. > > How about "representing integrity-protected data using JSON-based data > structures" and "representing encrypted data using JSON-based data > structures"? That would read better than the original and still not be > able to be misconstrued to say that what the working group has produced > doesn't meet the charter goals. > > Thanks, > -- Mike > > > -----Original Message----- > From: jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org ] On Behalf > Of Barry Leiba > Sent: Friday, April 05, 2013 7:37 AM > To: Mike Jones > Cc: Sean Turner; jose@ietf.org > Subject: Re: [jose] updated draft charter text incorporating AD's comments > > > For that reason, I believe we would be FAR better off to leave the > > first two charter items exactly as they are at > > http://datatracker.ietf.org/wg/jose/charter/ than to accept the new > wording. > > The current wording is: > > > > 1) A Standards Track document specifying how to apply JSON-structured > > integrity protection to data, including (but not limited to) JSON data > > structures. "Integrity protection" includes public-key digital > > signatures as well as symmetric-key MACs. > > > > 2) A Standards Track document specifying how to apply a > > JSON-structured encryption to data, including (but not limited to) > JSON data structures. > > The problem is that I do not understand what you mean by > "JSON-structured integrity protection" and "JSON-structured encryption". > Sean's suggested wording is intended to say this in an understandable > way; if it's not correct, please try to come up with an alternative. > The existing text doesn't work, because I don't understand how to > apply the modifier "JSON-structured" to the noun "encryption" and get > anything sensible out of it. What does it mean for *encryption* to be > "JSON-structured"? > > > So yes, I strongly object to the new wording, as I don't want to open > > the door for the current representations to be rejected on charter > > grounds later. If it helps, you can reassure objectors that we ARE > > producing pure JSON representations too, but that they're not the only > > JSON-based representations for integrity protected and encrypted content. > > To be clear: what you're producing is not the issue. It's an issue of > the wording in the charter. > > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From turners@ieca.com Mon Apr 8 13:49:52 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C6621F8DA4 for ; Mon, 8 Apr 2013 13:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPul667Qrj0m for ; Mon, 8 Apr 2013 13:49:51 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.243.5]) by ietfa.amsl.com (Postfix) with ESMTP id 710CD21F8CEE for ; Mon, 8 Apr 2013 13:49:51 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 0A713BC59203A; Mon, 8 Apr 2013 15:49:27 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id ED0A8BC58E4AB for ; Mon, 8 Apr 2013 15:49:12 -0500 (CDT) Received: from [108.45.16.214] (port=53662 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UPJ0S-0003w8-Jp; Mon, 08 Apr 2013 15:49:36 -0500 Message-ID: <51632D5F.90400@ieca.com> Date: Mon, 08 Apr 2013 16:49:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org, Barry Leiba References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> In-Reply-To: <515EC38F.2060703@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:53662 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 25 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 20:49:52 -0000 #1 is addressed. Any issues with sticking the paragraph in? Barry would that be enough for you to clear? spt On 4/5/13 8:29 AM, Sean Turner wrote: > 2. (hard one) Barry's been told by some App folks who are working on new > JSON-based protocols that they don't see the applicability of JOSE to > their work. > > I think there is some concern that we're doing our own thing here in > security land and not consulting with others. That's not a true > characterization based the use case we have from ALTO and XMPP, but > nonetheless this feedback worries both Barry and myself. What I'm > going to do is prompt/prod the Apps folks to engage and say why/how it > won't work for them. What we might also do is some education in the > appsawg; one of those here's how it works kind of presentations. We'll > reach out, but they need to reach out too because I don't want to have > to be pinned waiting on a input that may never come. To that end, > putting some wording in the charter earlier than the numbered bullet > about the uses cases, I think, solves this dilemma: > > The WG will strive to gather use cases to ensure the broadest > possible applicability of the mechanism. > > spt > > On 3/10/13 2:13 PM, Karen O'Donoghue wrote: >> Folks, >> >> Here is the updated charter text based on Sean's comments and Mike's >> response. If there are any errors, please identify them asap as I plan >> to forward this back to Sean (and thus the IESG) in the very near future. >> >> Regards, >> Karen >> >> >> Description of JOSE Working Group >> >> JavaScript Object Notation (JSON) is a text format for the serialization >> of structured >> data described in RFC 4627. The JSON format is often used for >> serializing and >> transmitting structured data over a network connection. With the >> increased usage >> of JSON in protocols in the IETF and elsewhere, there is now a desire to >> offer >> security services for JSON with encryption, digital signatures, and >> message authentication >> codes (MACs). >> >> Different proposals for providing such security services have already >> been defined >> and implemented. This Working Group will standardize the mechanism for >> integrity >> protection (signature and MAC) and encryption as well as the format for >> keys and algorithm >> identifiers to support interoperability of security services for >> protocols that >> use JSON. The Working Group will base its work on well-known message >> security primitives >> (e.g., CMS), and will solicit input from the rest of the IETF Security >> Area to be sure >> that the security functionality in the JSON format is sound. >> >> As JSON adoption expands, the different applications utilizing JSON >> security services >> will grow and this leads to the need to support different requirements. >> The WG will >> develop a generic syntax that can be used by applications to secure >> JSON-data, but >> it will be up to the application to fully specify the use of the WG's >> documents much >> the same way S/MIME is the application of CMS to MIME-based media types. >> >> This group is chartered to work on the following deliverables: >> >> (1) A Standards Track document or documents specifying how to apply >> JSON-structured >> integrity protection to data, including (but not limited to) JSON data >> structures. >> "Integrity protection" includes public-key digital signatures as well as >> symmetric-key MACs. >> >> (2) A Standards Track document or documents specifying how to apply a >> JSON-structured >> encryption to data, including (but not limited to) JSON data structures. >> >> (3) A Standards Track document specifying how to encode public keys as >> JSON- >> structured objects. >> >> (4) A Standards Track document specifying algorithms and algorithm >> identifiers for >> the previous three documents. >> >> (5) A Standards Track document specifying how to encode private and >> symmetric >> keys as JSON-structured objects. This document will build upon the >> concepts and >> structures in (3). >> >> (6) A Standards Track document specifying a means of protecting private >> and symmetric >> keys via encryption. This document will build upon the concepts and >> structures in (2) >> and (5). This document may register additional algorithms in registries >> defined by (4). >> >> (7) An Informational document detailing Use Cases and Requirements for >> JSON Object >> Signing and Encryption (JOSE). >> >> (8) An Informational document that tells an application what needs to be >> specified in order >> to implement JOSE. >> >> One or more of these goals may be combined into a single document, in >> which case the >> concrete milestones for these goals will be satisfied by the >> consolidated document(s). >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From barryleiba.mailing.lists@gmail.com Mon Apr 8 14:31:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889221F931E for ; Mon, 8 Apr 2013 14:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP6SS87qk+bi for ; Mon, 8 Apr 2013 14:31:43 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id D707F21F8FED for ; Mon, 8 Apr 2013 14:31:42 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id ox1so5745003veb.7 for ; Mon, 08 Apr 2013 14:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xRqCT82HFRcsags2ChJ5u5K6ADYnqD5pTISdTGWwTVw=; b=e07go0VxpeMi58S2XZwues8J+0d5D7KYTY/GrVuQEuzdUktJH3PnZKkoTLX1bpcioP 4vG0PEM/xArgIDgzKraTVt/pqFm2OK68FBGqS87Yak2FcnpN8+sv5GezTwn0+gWc8Gka FCgIU1YYaLG/DKrBhGBn+4HoE8BA0Gaa5yeipapOoqOZm7im+8BPteA2J6FWFIssgZLT TmtgobkIu+rRyh/vvuZwkaxAmYU0MStT7nDxM4ExRLFcKD9D+dHXZrEzhvWcvehpWgWd /b0tsi0+95Xvf1q/OK/g1Dy8dLz6jSJvxeDroFQ4pKdrXLq6eEvc99JWsIsVTT5id5lO 9I3g== MIME-Version: 1.0 X-Received: by 10.58.154.229 with SMTP id vr5mr17365789veb.11.1365456702198; Mon, 08 Apr 2013 14:31:42 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 8 Apr 2013 14:31:42 -0700 (PDT) In-Reply-To: <51632D5F.90400@ieca.com> References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <51632D5F.90400@ieca.com> Date: Mon, 8 Apr 2013 17:31:42 -0400 X-Google-Sender-Auth: sbRcmESbMiJi2cg5ClLOOcIXorM Message-ID: From: Barry Leiba To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 21:31:43 -0000 > #1 is addressed. Yes. > Any issues with sticking the paragraph in? > Barry would that be enough for you to clear? That and the outreach that you and I and the chairs are working on, yes, indeed. Thanks. Barry From sakimura@gmail.com Mon Apr 8 16:29:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1A821F8EDE for ; Mon, 8 Apr 2013 16:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kQefPEGhfMq for ; Mon, 8 Apr 2013 16:29:56 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E757121F8EDB for ; Mon, 8 Apr 2013 16:29:55 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so6282540lbi.3 for ; Mon, 08 Apr 2013 16:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ZBxHRncC4dyRinfj0i1J9bWdviBIUUpk8tcHX93rjUs=; b=oVlZxgzU1hd+e5qHTF6yodXAjbHE9/9s2BZW/gWbH69y6m8S+nWC3t/NGZrxHxg38t 0+gFQLcTc3zOxWlDjFq5wGRX4KhBfqK4MmI22//wO7T6BmEN+po5NvG+3LwwLoTaiQ8V SDpqhFDFgkpZYShbJjDU2AWstgix5ZNvyBF2wBz2zzXFkZmPfyXkT7MFOovzFAg2gOqk uN8nOiZSLnr2+/QhOh9TJlxJkbXVmCo48Y4IGOQ+G7+kZ6g6DHn1DEDi5eIbHV9fhNHj iZ0+ZLDLifxSyOk9TcE+60Wi9U4nSjsha5T3c/LEqTdBlqeJGZ80MWRKoy9Hs3QLnNkh n18g== MIME-Version: 1.0 X-Received: by 10.112.162.40 with SMTP id xx8mr12634345lbb.30.1365463794722; Mon, 08 Apr 2013 16:29:54 -0700 (PDT) Received: by 10.112.19.163 with HTTP; Mon, 8 Apr 2013 16:29:54 -0700 (PDT) In-Reply-To: References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> Date: Tue, 9 Apr 2013 08:29:54 +0900 Message-ID: From: Nat Sakimura To: "Matt Miller (mamille2)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , "Peck, Michael A" , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 23:29:57 -0000 Concat is what McGrew algorithm does it, is it not? I support the move. 2013/4/9 Matt Miller (mamille2) : > +1 on a longer key. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Apr 7, 2013, at 10:47 PM, Dick Hardt wrote: > >> FWIW: I'd strongly prefer a longer key than a different KDF scheme. >> >> On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" wrote: >> >>> I prefer using a KDF, as I think the approach of using a long key over-= complicates key management by requiring generation and transport of a longe= r key than necessary, and it may also provide a false sense of the overall = security level. >>> >>> As previously discussed, the Concat KDF is not appropriate, but there a= re other NIST KDFs that seem acceptable for this key expansion purpose. >>> For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1,= with the PRF algorithm set to the same HMAC algorithm used in the correspo= nding AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SH= A-256, and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512). >>> >>> For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128= -bit "master" key: >>> Expanded key =3D HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256= " | 0x00 | 0x00 0x00 0x01 0x00) >>> AES key =3D first 128 bits of expanded key >>> HMAC key =3D second 128 bits of expanded key >>> >>> If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it = would be worth discussing with the draft authors whether they are intereste= d in performing the KDF in the AEAD algorithm itself (for example, input a = 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be respons= ible for deriving the 128-bit AES key and 128-bit HMAC key). >>> >>> Mike >>> >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf O= f >>>> Jim Schaad >>>> Sent: Thursday, April 04, 2013 7:51 PM >>>> To: jose@ietf.org >>>> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request >>>> >>>> >>>> >>>> At the request of the editors, this is a formal consensus call on the = first >>>> item in the list below. If there are objects to use a single long key >>>> rather than a KDF function for the AES-CBC/HMAC algorithm please speak= up >>>> now. To date nobody has said that I was wrong to assume the consensus= on >>>> that item. >>>> >>>> Call ends in one week. >>>> >>>> Jim >>>> >>>> >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >>>> Jim >>>>> Schaad >>>>> Sent: Wednesday, March 27, 2013 3:21 PM >>>>> To: jose@ietf.org >>>>> Subject: [jose] Use of AES-HMAC algorithm >>>>> >>>>> >>>>> After spending time looking at and thinking about how to resolve this >>>> issue >>>>> since I was unable to do so at the last F2F meeting. I have come up = with >>>> the >>>>> following set of issues that might need to be addressed as part of >>>> resolving >>>>> this issue. >>>>> >>>>> 1. Do we change from using KDC to having a double size key for the >>>>> algorithm? I think that there is probably a consensus that this shou= ld be >>>> done. >>>>> >>>>> 2. Should IVs be prepended to the encrypted body as part of the encod= ing >>>>> steps? If so then this change should be universal. >>>>> >>>>> Doing so would eliminate one field from all of the encoding formats w= hich >>>>> should be considered a plus. >>>>> Doing so would force code writers to understand how large the IV is f= or >>>> all >>>>> algorithms as the IV would no longer be a separate item. >>>>> >>>>> 3. Should Authentication Tags be appended to the encrypted body as pa= rt of >>>>> the encoding steps? >>>>> >>>>> Doing so would eliminate one field from all of the encoding formats w= hich >>>>> should be considered a plus. >>>>> Doing so would force code writers to understand how large the IV is f= or >>>> all >>>>> algorithms as the IV would no longer be a separate item. >>>>> Doing so would force a re-organization for the multiple recipient cas= e as >>>>> either all recipient specific data would need to be excluded from the >>>>> authentication step or all of the recipient data would need to be inc= luded >>>> for >>>>> by all recipients. >>>>> Changing how the recipient info is process is going to give a perform= ance >>>>> benefit for sending encrypted items for multiple recipients. >>>>> The current strategy of a single IV and key pair with AES-GCM and >>>> different >>>>> authentication data needs to have CFRG look at it. I am worried that= it >>>> might >>>>> be a serious security flaw. >>>>> >>>>> 4. Should we reference the McGrew draft and provide text on how thing= s >>>> are >>>>> changed or should we "copy" the draft into our text? >>>>> >>>>> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrap= ping, >>>>> does this change how we think about any of the above questions? >>>>> >>>>> Allowing for AES-GCM for key wrapping has a benefit for hardware >>>> situations >>>>> as only the encrypt and not the decrypt functions need to be placed i= n >>>>> hardware. However allowing for this key wrapping give a problem as t= here >>>> is >>>>> no way to encode the three fields into the encrypted value unless wit= h use >>>>> either a JSON structure in this location or we do use the single appe= nded >>>>> binary output stream. The first approach leads to an expansion of th= e >>>> field by >>>>> double base64 encoding which is highly undesirable. >>>>> >>>>> Jim >>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From stpeter@stpeter.im Mon Apr 8 16:39:24 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1138721F877A for ; Mon, 8 Apr 2013 16:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7CU6EmBCN2f for ; Mon, 8 Apr 2013 16:39:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 188F121F8648 for ; Mon, 8 Apr 2013 16:39:23 -0700 (PDT) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9A51B4004E; Mon, 8 Apr 2013 17:49:24 -0600 (MDT) Message-ID: <51635528.40909@stpeter.im> Date: Mon, 08 Apr 2013 17:39:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sean Turner References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> In-Reply-To: <515EC38F.2060703@ieca.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 23:39:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/5/13 6:29 AM, Sean Turner wrote: > 2. (hard one) Barry's been told by some App folks who are working > on new JSON-based protocols that they don't see the applicability > of JOSE to their work. Have we heard *why*? Do they not need or want signing and encryption? Do they think there are technical problems with the solutions being proposed in the JOSE WG? Do they have aesthetic objections? It would help to know more about the concerns being expressed (and why they are not being expressed in the JOSE WG but instead in private to an area directory). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRY1UoAAoJEOoGpJErxa2psRQP/jxDVhZEzKWJ7Lnz4zrbW9wu 266cYbY+XJxdqHHE0At4kVVPQ/YaV7wPUDOH9owCGLOgQeMGuT4NbaaHgwc5Uw9a RBuW0Aw6/otvdkDwHJWOI8jXgRF7ERUSoDAFYK8ynxY4l9ezngOzgWDpHQOK/tQD Bmr7+hqDJ4vcmklibH4lzHc/uk71d9hiE8PQE5S5KBeGKzWHwwcY8A1q8GKIFHKn eNVEu2yadXqZoFBggtDnAvOiMYN/5BQ3ck7dWWWNgY3ox3g9FHp1F31pJTUEPir/ fgg7dCWQcwmf9UUujxWMDjbfTNvfO7hYPx2Pu1aL69XAQs0qp3eE6glPBs5Y18P8 my8NiGcsCSQl6N3knapXCu1oLQ9BOO6qMRSAx7I839873eb7ZOK+5uDo39/gzt3K 8feRoNCj/nvhnHLFImQeyB6eGnaudiRyylOfuk6vVcg+ccqqepOATGK5mvgJxnRn 7yyVdgU6PcBvjnPJPHp8vObL9FHh+OJRUpozJS1pXHq4SZsIh14z3FYTQafx99XF YxAvAVMduLbw/+FMGCX42cv2rDUKWE3tShWNX2uLYacGmyysoKTqmx5xOx7+BdZQ WxCx1tPGVL1t11Ekgf6Ft3Lc94Kz06LqRD01wgAjIkpuhcDYREYoBXloE17qTz6y zTTNmlmmF9v3x8s9zDPt =NNLU -----END PGP SIGNATURE----- From turners@ieca.com Mon Apr 8 20:20:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E821F8E6E for ; Mon, 8 Apr 2013 20:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAnJk4pYKLf9 for ; Mon, 8 Apr 2013 20:20:09 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.53.20]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD821F8D2A for ; Mon, 8 Apr 2013 20:20:09 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 9BB54DBE3BBA3; Mon, 8 Apr 2013 22:20:04 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 8E9CEDBE3BB57 for ; Mon, 8 Apr 2013 22:20:04 -0500 (CDT) Received: from [108.45.16.214] (port=55296 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UPP6P-00039d-1C; Mon, 08 Apr 2013 22:20:09 -0500 Message-ID: <516388E8.7090707@ieca.com> Date: Mon, 08 Apr 2013 23:20:08 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <513CCD31.8050408@isoc.org> <515EC38F.2060703@ieca.com> <51635528.40909@stpeter.im> In-Reply-To: <51635528.40909@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:55296 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 15 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: jose@ietf.org Subject: Re: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 03:20:10 -0000 I have heard nothing to date, but I get Barry's point we need to reach out and ask. As, I told him though we're going to reach out but we're not going to wait indefinitely for a reply. spt On 4/8/13 7:39 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/5/13 6:29 AM, Sean Turner wrote: > >> 2. (hard one) Barry's been told by some App folks who are working >> on new JSON-based protocols that they don't see the applicability >> of JOSE to their work. > > Have we heard *why*? Do they not need or want signing and encryption? > Do they think there are technical problems with the solutions being > proposed in the JOSE WG? Do they have aesthetic objections? It would > help to know more about the concerns being expressed (and why they are > not being expressed in the JOSE WG but instead in private to an area > directory). > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRY1UoAAoJEOoGpJErxa2psRQP/jxDVhZEzKWJ7Lnz4zrbW9wu > 266cYbY+XJxdqHHE0At4kVVPQ/YaV7wPUDOH9owCGLOgQeMGuT4NbaaHgwc5Uw9a > RBuW0Aw6/otvdkDwHJWOI8jXgRF7ERUSoDAFYK8ynxY4l9ezngOzgWDpHQOK/tQD > Bmr7+hqDJ4vcmklibH4lzHc/uk71d9hiE8PQE5S5KBeGKzWHwwcY8A1q8GKIFHKn > eNVEu2yadXqZoFBggtDnAvOiMYN/5BQ3ck7dWWWNgY3ox3g9FHp1F31pJTUEPir/ > fgg7dCWQcwmf9UUujxWMDjbfTNvfO7hYPx2Pu1aL69XAQs0qp3eE6glPBs5Y18P8 > my8NiGcsCSQl6N3knapXCu1oLQ9BOO6qMRSAx7I839873eb7ZOK+5uDo39/gzt3K > 8feRoNCj/nvhnHLFImQeyB6eGnaudiRyylOfuk6vVcg+ccqqepOATGK5mvgJxnRn > 7yyVdgU6PcBvjnPJPHp8vObL9FHh+OJRUpozJS1pXHq4SZsIh14z3FYTQafx99XF > YxAvAVMduLbw/+FMGCX42cv2rDUKWE3tShWNX2uLYacGmyysoKTqmx5xOx7+BdZQ > WxCx1tPGVL1t11Ekgf6Ft3Lc94Kz06LqRD01wgAjIkpuhcDYREYoBXloE17qTz6y > zTTNmlmmF9v3x8s9zDPt > =NNLU > -----END PGP SIGNATURE----- > From edmundjay@sbcglobal.net Mon Apr 8 23:23:20 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5132621F8F1C for ; Mon, 8 Apr 2013 23:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSXfNqR5qm2b for ; Mon, 8 Apr 2013 23:23:19 -0700 (PDT) Received: from nm28-vm0.access.bullet.mail.mud.yahoo.com (nm28-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2120C21F8F10 for ; Mon, 8 Apr 2013 23:23:19 -0700 (PDT) Received: from [66.94.237.196] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Apr 2013 06:23:18 -0000 Received: from [66.94.237.124] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Apr 2013 06:23:18 -0000 Received: from [127.0.0.1] by omp1029.access.mail.mud.yahoo.com with NNFMP; 09 Apr 2013 06:23:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 647608.47831.bm@omp1029.access.mail.mud.yahoo.com Received: (qmail 6043 invoked by uid 60001); 9 Apr 2013 06:23:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1365488598; bh=WANlsOb9Wq4UOHHOlaiUBqU2rqkf8qSLEz+BGo9WGjY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KlOIgyVwiFjFdNIw1r2EHu/QtJKwAiFGCfN8+7AYOlbMplF7f3/bIFoo3CbA0zZT459tUHDcOflV6oXlJjiSQN4PmublKc3s09Mb9sSv43mnQx1heeIRrNSa4p4VZerkzFy4R5Q0G8eLAx2D+LZaK5h6Clc7qza8Itg84ZnSvRo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6ldvFgfIKsWjit/16t2Z9HCWEhJAnUhxyclVtgKEizez90gUVSpRpQEzrsHu2zhF7t+m6hgnUCzzYjd97DbleCoDzBid9DxEfTfBqzgW4TbZKz7+XWhO0pGQECDiX1Jl+1RFVbejVpFKe77UnwebLoo8o5yIN01Um3cvkbchUjM=; X-YMail-OSG: Ib8sLJoVM1kz5ma_B54vZhTW2HpdpbNT8_pKCbtnj3yI4Ty papeoqKs4has_lRcLDUYDWr39fBddFDaIV25j62_iF0s3kZIbyPtEDT0gMzY bRsyIOMtH7cczAVQo21pg5posphE.b.1dO2aFsGM0uuNsmHpfcj5uX2T.UBv s522QVdz_sp3ZwVyfKfbyFSJ8s1NXSvmSzflTSmwNZY2x_jSGdw3yfRkyam7 ATdQbivCQupyfl6OWS8Clu5ZJFISUGQHy8c0eotclB1PAASB1LbUTkObs8pB mNFoicbsGwiMnSyw99aeJzPyaGlYisxTMO5cWsHfQBM2LY6gd24nbcs2VU6O O0AWllX.umvQ5xNM6HV_V9d1UnW0NJblYiMdDd5FD907G417wevZBmCv3yHt LLSVHqVt_q5t8nernSkLaPWkxwJvF35jPkAbl.pBTJXlRBqs59K7.3ZlwZOX jnC_cUDwRd6A7bFnhzEo84l2xbhvXe9i5PrRZ.Z5lr3zOMOfR9ni5LHRqsf8 RC.7xZDoPKyg- Received: from [70.36.254.42] by web184404.mail.bf1.yahoo.com via HTTP; Mon, 08 Apr 2013 23:23:18 PDT X-Rocket-MIMEInfo: 002.001, KzEgaW4gc3VwcG9ydCBvZiBsb25nZXIga2V5LgoKLS0gRWRtdW5kCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPgpUbzogam9zZUBpZXRmLm9yZwpTZW50OiBUaHUsIEFwcmlsIDQsIDIwMTMgNDo1MjowMSBQTQpTdWJqZWN0OiBSZTogW2pvc2VdIFVzZSBvZiBBRVMtSE1BQyBhbGdvcml0aG0gLSBDb25zZW5zdXMgUmVxdWVzdAoKPGNoYWlyPiAKCkF0IHRoZSByZXF1ZXN0IG9mIHRoZSBlZGl0b3JzLCB0aGlzIGlzIGEBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/728 YahooMailWebService/0.8.140.532 References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> Message-ID: <1365488598.99904.YahooMailRC@web184404.mail.bf1.yahoo.com> Date: Mon, 8 Apr 2013 23:23:18 -0700 (PDT) From: Edmund Jay To: Jim Schaad , jose@ietf.org In-Reply-To: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-420974808-1857979767-1365488598=:99904" Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 06:23:20 -0000 ---420974808-1857979767-1365488598=:99904 Content-Type: text/plain; charset=us-ascii +1 in support of longer key. -- Edmund ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Thu, April 4, 2013 4:52:01 PM Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request At the request of the editors, this is a formal consensus call on the first item in the list below. If there are objects to use a single long key rather than a KDF function for the AES-CBC/HMAC algorithm please speak up now. To date nobody has said that I was wrong to assume the consensus on that item. Call ends in one week. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:21 PM > To: jose@ietf.org > Subject: [jose] Use of AES-HMAC algorithm > > > After spending time looking at and thinking about how to resolve this issue > since I was unable to do so at the last F2F meeting. I have come up with the > following set of issues that might need to be addressed as part of resolving > this issue. > > 1. Do we change from using KDC to having a double size key for the > algorithm? I think that there is probably a consensus that this should be done. > > 2. Should IVs be prepended to the encrypted body as part of the encoding > steps? If so then this change should be universal. > > Doing so would eliminate one field from all of the encoding formats which > should be considered a plus. > Doing so would force code writers to understand how large the IV is for all > algorithms as the IV would no longer be a separate item. > > 3. Should Authentication Tags be appended to the encrypted body as part of > the encoding steps? > > Doing so would eliminate one field from all of the encoding formats which > should be considered a plus. > Doing so would force code writers to understand how large the IV is for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case as > either all recipient specific data would need to be excluded from the > authentication step or all of the recipient data would need to be included for > by all recipients. > Changing how the recipient info is process is going to give a performance > benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and different > authentication data needs to have CFRG look at it. I am worried that it might > be a serious security flaw. > > 4. Should we reference the McGrew draft and provide text on how things are > changed or should we "copy" the draft into our text? > > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, > does this change how we think about any of the above questions? > > Allowing for AES-GCM for key wrapping has a benefit for hardware situations > as only the encrypt and not the decrypt functions need to be placed in > hardware. However allowing for this key wrapping give a problem as there is > no way to encode the three fields into the encrypted value unless with use > either a JSON structure in this location or we do use the single appended > binary output stream. The first approach leads to an expansion of the field by > double base64 encoding which is highly undesirable. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---420974808-1857979767-1365488598=:99904 Content-Type: text/html; charset=us-ascii
+1 in support of longer key.

-- Edmund

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Thu, April 4, 2013 4:52:01 PM
Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request

<chair>

At the request of the editors, this is a formal consensus call on the first
item in the list below.  If there are objects to use a single long key
rather than a KDF function for the AES-CBC/HMAC algorithm please speak up
now.  To date nobody has said that I was wrong to assume the consensus on
that item.

Call ends in one week.

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
Jim
> Schaad
> Sent: Wednesday, March 27, 2013 3:21 PM
> To: jose@ietf.org
> Subject: [jose] Use of AES-HMAC algorithm
>
> <chair>
> After spending time looking at and thinking about how to resolve this
issue
> since I was unable to do so at the last F2F meeting.  I have come up with
the
> following set of issues that might need to be addressed as part of
resolving
> this issue.
>
> 1.  Do we change from using KDC to having a double size key for the
> algorithm?  I think that there is probably a consensus that this should be
done.
>
> 2. Should IVs be prepended to the encrypted body as part of the encoding
> steps?  If so then this change should be universal.
>
> Doing so would eliminate one field from all of the encoding formats which
> should be considered a plus.
> Doing so would force code writers to understand how large the IV is for
all
> algorithms as the IV would no longer be a separate item.
>
> 3. Should Authentication Tags be appended to the encrypted body as part of
> the encoding steps?
>
> Doing so would eliminate one field from all of the encoding formats which
> should be considered a plus.
> Doing so would force code writers to understand how large the IV is for
all
> algorithms as the IV would no longer be a separate item.
> Doing so would force a re-organization for the multiple recipient case as
> either all recipient specific data would need to be excluded from the
> authentication step or all of the recipient data would need to be included
for
> by all recipients.
> Changing how the recipient info is process is going to give a performance
> benefit for sending encrypted items for multiple recipients.
> The current strategy of a single IV and key pair with AES-GCM and
different
> authentication data needs to have CFRG look at it.  I am worried that it
might
> be a serious security flaw.
>
> 4. Should we reference the McGrew draft and provide text on how things are
> changed or should we "copy" the draft into our text?
>
> 5.  If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping,
> does this change how we think about any of the above questions?
>
> Allowing for AES-GCM for key wrapping has a benefit for hardware
situations
> as only the encrypt and not the decrypt functions need to be placed in
> hardware.  However allowing for this key wrapping give a problem as there
is
> no way to encode the three fields into the encrypted value unless with use
> either a JSON structure in this location or we do use the single appended
> binary output stream.  The first approach leads to an expansion of the
field by
> double base64 encoding which is highly undesirable.
>
> Jim
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---420974808-1857979767-1365488598=:99904-- From ve7jtb@ve7jtb.com Tue Apr 9 04:06:56 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7020E21F9156 for ; Tue, 9 Apr 2013 04:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPcLQsokIiV4 for ; Tue, 9 Apr 2013 04:06:55 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 586F721F913C for ; Tue, 9 Apr 2013 04:06:55 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id p13so4567184vbe.35 for ; Tue, 09 Apr 2013 04:06:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=LNbFUKTBJfcoV4mLq0R6M83pgFNZK4jdS4Pq+mkU2Ps=; b=dFX4Bj4FW3sdYOSh/xbCBIxcTJNWPzmWEGByifSE5Q7aFhsQ0AJHelwaTZaKZVzIpC cTGa5Y3CrDXUva9F1clLv0bncyl3BNkFqbPZjK1gmzahOCdVzxk+El9uoTLXfr2ujhKV IX6HFBiJ0BIh8SW6hpGaIvuRTAXKfXYbErrw7uYA9V6vwMeAiIAuK8CtiRtNR2x2dXxv VcJHMGdbBNPkTXIZm+vwaYu1aa1kB6eIBgTU3XSt38Y55YQeBXZY2XjTHYyutHVGc6ak xU4lWFByqnE6x+aVVrRH+LMLQ5iYkJcHOP97zNBQ3G2dCqgt9YsNoDrJglg+jZiFyo08 e6CA== X-Received: by 10.52.183.36 with SMTP id ej4mr5952843vdc.95.1365505614593; Tue, 09 Apr 2013 04:06:54 -0700 (PDT) Received: from [192.168.6.138] (ip-64-134-102-253.public.wayport.net. [64.134.102.253]) by mx.google.com with ESMTPS id s9sm28619871veb.5.2013.04.09.04.06.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 04:06:53 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6D4F3AB3-78A8-495A-B593-77BBC640EF8B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Tue, 9 Apr 2013 07:06:41 -0400 Message-Id: References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> To: Nat Sakimura X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQn6ozH3pokzOh2HVi/kAwUDvI2VHhWBQHOwx7/70QbRbtj6Est02qv66syXDFNf8wtkQGb7 Cc: Jim Schaad , Dick Hardt , "Peck, Michael A" , "jose@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:06:56 -0000 --Apple-Mail=_6D4F3AB3-78A8-495A-B593-77BBC640EF8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Concatenating the keys together as in McGrew, not the Concat KDF as in = the current spec? I think I know what you mean but just double checking. John B. On 2013-04-08, at 7:29 PM, Nat Sakimura wrote: > Concat is what McGrew algorithm does it, is it not? I support the = move. >=20 > 2013/4/9 Matt Miller (mamille2) : >> +1 on a longer key. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >>=20 >> On Apr 7, 2013, at 10:47 PM, Dick Hardt wrote: >>=20 >>> FWIW: I'd strongly prefer a longer key than a different KDF scheme. >>>=20 >>> On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" = wrote: >>>=20 >>>> I prefer using a KDF, as I think the approach of using a long key = over-complicates key management by requiring generation and transport of = a longer key than necessary, and it may also provide a false sense of = the overall security level. >>>>=20 >>>> As previously discussed, the Concat KDF is not appropriate, but = there are other NIST KDFs that seem acceptable for this key expansion = purpose. >>>> For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section = 5.1, with the PRF algorithm set to the same HMAC algorithm used in the = corresponding AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with = AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + = HMAC-SHA-512). >>>>=20 >>>> For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted = 128-bit "master" key: >>>> Expanded key =3D HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | = "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00) >>>> AES key =3D first 128 bits of expanded key >>>> HMAC key =3D second 128 bits of expanded key >>>>=20 >>>> If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think = it would be worth discussing with the draft authors whether they are = interested in performing the KDF in the AEAD algorithm itself (for = example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 = and have it be responsible for deriving the 128-bit AES key and 128-bit = HMAC key). >>>>=20 >>>> Mike >>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>>> Jim Schaad >>>>> Sent: Thursday, April 04, 2013 7:51 PM >>>>> To: jose@ietf.org >>>>> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request >>>>>=20 >>>>> >>>>>=20 >>>>> At the request of the editors, this is a formal consensus call on = the first >>>>> item in the list below. If there are objects to use a single long = key >>>>> rather than a KDF function for the AES-CBC/HMAC algorithm please = speak up >>>>> now. To date nobody has said that I was wrong to assume the = consensus on >>>>> that item. >>>>>=20 >>>>> Call ends in one week. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>>> Jim >>>>>> Schaad >>>>>> Sent: Wednesday, March 27, 2013 3:21 PM >>>>>> To: jose@ietf.org >>>>>> Subject: [jose] Use of AES-HMAC algorithm >>>>>>=20 >>>>>> >>>>>> After spending time looking at and thinking about how to resolve = this >>>>> issue >>>>>> since I was unable to do so at the last F2F meeting. I have come = up with >>>>> the >>>>>> following set of issues that might need to be addressed as part = of >>>>> resolving >>>>>> this issue. >>>>>>=20 >>>>>> 1. Do we change from using KDC to having a double size key for = the >>>>>> algorithm? I think that there is probably a consensus that this = should be >>>>> done. >>>>>>=20 >>>>>> 2. Should IVs be prepended to the encrypted body as part of the = encoding >>>>>> steps? If so then this change should be universal. >>>>>>=20 >>>>>> Doing so would eliminate one field from all of the encoding = formats which >>>>>> should be considered a plus. >>>>>> Doing so would force code writers to understand how large the IV = is for >>>>> all >>>>>> algorithms as the IV would no longer be a separate item. >>>>>>=20 >>>>>> 3. Should Authentication Tags be appended to the encrypted body = as part of >>>>>> the encoding steps? >>>>>>=20 >>>>>> Doing so would eliminate one field from all of the encoding = formats which >>>>>> should be considered a plus. >>>>>> Doing so would force code writers to understand how large the IV = is for >>>>> all >>>>>> algorithms as the IV would no longer be a separate item. >>>>>> Doing so would force a re-organization for the multiple recipient = case as >>>>>> either all recipient specific data would need to be excluded from = the >>>>>> authentication step or all of the recipient data would need to be = included >>>>> for >>>>>> by all recipients. >>>>>> Changing how the recipient info is process is going to give a = performance >>>>>> benefit for sending encrypted items for multiple recipients. >>>>>> The current strategy of a single IV and key pair with AES-GCM and >>>>> different >>>>>> authentication data needs to have CFRG look at it. I am worried = that it >>>>> might >>>>>> be a serious security flaw. >>>>>>=20 >>>>>> 4. Should we reference the McGrew draft and provide text on how = things >>>>> are >>>>>> changed or should we "copy" the draft into our text? >>>>>>=20 >>>>>> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key = wrapping, >>>>>> does this change how we think about any of the above questions? >>>>>>=20 >>>>>> Allowing for AES-GCM for key wrapping has a benefit for hardware >>>>> situations >>>>>> as only the encrypt and not the decrypt functions need to be = placed in >>>>>> hardware. However allowing for this key wrapping give a problem = as there >>>>> is >>>>>> no way to encode the three fields into the encrypted value unless = with use >>>>>> either a JSON structure in this location or we do use the single = appended >>>>>> binary output stream. The first approach leads to an expansion = of the >>>>> field by >>>>>> double base64 encoding which is highly undesirable. >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_6D4F3AB3-78A8-495A-B593-77BBC640EF8B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDA5MTEwNjQyWjAjBgkqhkiG9w0BCQQxFgQUCvzrV/a5 /61b1YFXpOEuXXNFmpowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAU66wJdoKzGSm/wly4NX4IToMm8Bf9kYIj2gTjH30 Mj/GSGwgiUB0srIUauUgmgafmNt1d1JgpkYAaQZ2KkEHxbeS4fTe4wYBxgdwSfOoAMp3KVNEEGd9 jDuV0jlH4rtzTBhQR0/4czyid2vNFG0/in8xCvxb5lFfwjZS6FVI6R2afKHXOYC3ST+1Qkq2rAlr UZ3Tod4CzGXKklodkC1lB7KW661hFvKx8P3/tS+WdK7b4ztJ3cLqnCUTKsStzI92tcmr07OJ8qnj dOnTCuh0XFvgvRpaoi9wEQb2tr6EL1vUJNc77/43z8q3+DkVP85L7dazfTwhSvkdZJfjkAS9SQAA AAAAAA== --Apple-Mail=_6D4F3AB3-78A8-495A-B593-77BBC640EF8B-- From trac+jose@trac.tools.ietf.org Tue Apr 9 12:45:12 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6974521F9915 for ; Tue, 9 Apr 2013 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8sirlvAsQPP for ; Tue, 9 Apr 2013 12:45:12 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1B21F9913 for ; Tue, 9 Apr 2013 12:45:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:60822 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UPeTc-0000CJ-Hx; Tue, 09 Apr 2013 21:45:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, watsonm@netflix.com X-Trac-Project: jose Date: Tue, 09 Apr 2013 19:45:08 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/19 Message-ID: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, watsonm@netflix.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130409194511.9FC1B21F9913@ietfa.amsl.com> Resent-Date: Tue, 9 Apr 2013 12:45:11 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:45:12 -0000 #19: JWA needs to specify an IV for use with JWE AES Key Wrap Section 4.5 of JSON Web Algorithms specifies the use of AES Key Wrap with JWE with reference to RFC3394. The RFC does not require a particular Initial Value to be used, although it defined a "default Initial Value". Either: (a) The JWA specification needs to specify that the default Initial Value from RFC3394 must be used, or (b) The JWE specification needs to include an object member to specify the Initial Value that was used (note that is this distinct from the Initialization Vector used for the payload encryption). I suggest (a) and I am uncertain of the security properties of (b). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- watsonm@netflix.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web- | Version: algorithms | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Tue Apr 9 13:34:21 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29D21F98D5 for ; Tue, 9 Apr 2013 13:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwukDOP-AsV3 for ; Tue, 9 Apr 2013 13:34:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84D21F98B3 for ; Tue, 9 Apr 2013 13:34:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:34795 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UPfFA-0001OA-FG; Tue, 09 Apr 2013 22:34:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Tue, 09 Apr 2013 20:34:16 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/19#comment:1 Message-ID: <073.9260192a1ef18ecd87e34dcfb7b5de8a@trac.tools.ietf.org> References: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130409203420.4F84D21F98B3@ietfa.amsl.com> Resent-Date: Tue, 9 Apr 2013 13:34:20 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:34:21 -0000 #19: JWA needs to specify an IV for use with JWE AES Key Wrap Comment (by rlb@ipv.sx): It turns out that RFC 5649 is actually unambiguous about this: """ [If the input is not exactly 8 bytes long...] Otherwise, apply the wrapping process specified in Section 2.2.1 of [AES-KW2] to the padded plaintext {P[1], ..., P[n]} with K (the KEK) and the AIV as defined in Section 3 above as the initial value. """ So it seems like there's a third course of action here, namely: (c) Upgrade the reference to RFC 3394 to reference RFC 5649 instead. That would also allow us to process inputs that are not 64-bit aligned. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- watsonm@netflix.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web- | Version: algorithms | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From housley@vigilsec.com Wed Apr 10 13:53:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241CD21F936D for ; Wed, 10 Apr 2013 13:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd4zjeLOC8zD for ; Wed, 10 Apr 2013 13:53:12 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2921F92EF for ; Wed, 10 Apr 2013 13:53:12 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5AEB6F2406C for ; Wed, 10 Apr 2013 16:53:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id NIke1PZJpsCW for ; Wed, 10 Apr 2013 16:52:54 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3544EF2406E for ; Wed, 10 Apr 2013 16:53:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> Date: Wed, 10 Apr 2013 16:53:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> To: jose@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 20:53:13 -0000 I encourage the use of only the default IV with AES Key Wrap. Russ On Apr 9, 2013, at 3:45 PM, jose issue tracker wrote: > #19: JWA needs to specify an IV for use with JWE AES Key Wrap > > Section 4.5 of JSON Web Algorithms specifies the use of AES Key Wrap with > JWE with reference to RFC3394. The RFC does not require a particular > Initial Value to be used, although it defined a "default Initial Value". > > Either: > (a) The JWA specification needs to specify that the default Initial Value > from RFC3394 must be used, or > (b) The JWE specification needs to include an object member to specify the > Initial Value that was used (note that is this distinct from the > Initialization Vector used for the payload encryption). > > I suggest (a) and I am uncertain of the security properties of (b). > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-jose-json-web- > watsonm@netflix.com | algorithms@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: json-web- | Version: > algorithms | Keywords: > Severity: - | > -------------------------+------------------------------------------------- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From trac+jose@trac.tools.ietf.org Wed Apr 10 14:31:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FA621F8F1E for ; Wed, 10 Apr 2013 14:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52yFtXnGSicB for ; Wed, 10 Apr 2013 14:31:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8C36421F8ED5 for ; Wed, 10 Apr 2013 14:31:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:46277 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQ2cT-0001WA-FS; Wed, 10 Apr 2013 23:31:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 10 Apr 2013 21:31:53 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/19#comment:2 Message-ID: <073.1f0d40b5075fda6ccd36a1a53aedb9a4@trac.tools.ietf.org> References: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130410213156.8C36421F8ED5@ietfa.amsl.com> Resent-Date: Wed, 10 Apr 2013 14:31:56 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 21:31:57 -0000 #19: JWA needs to specify an IV for use with JWE AES Key Wrap Comment (by michael.jones@microsoft.com): I will add text clarifying that the default IV must be used (which was always the intent) in the upcoming round of edits. RFC 5649 is a different (if related) algorithm, and not the topic of this issue. When last discussed by the working group, the decision made was to have RFC 3394 continue to be in the JWA algorithm set but not RFC 5649. This was recorded in the IETF 83 minutes as "Agreement reached to use 3394 since Schaad said there wasn't likely a need for the arbitrary alignment supported in 5649." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- watsonm@netflix.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web- | Version: algorithms | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From odonoghue@isoc.org Thu Apr 11 16:58:00 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3A921F86B2 for ; Thu, 11 Apr 2013 16:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3frVA+v8jh64 for ; Thu, 11 Apr 2013 16:57:59 -0700 (PDT) Received: from smtp126.ord1c.emailsrvr.com (smtp126.ord1c.emailsrvr.com [108.166.43.126]) by ietfa.amsl.com (Postfix) with ESMTP id C862821F86A6 for ; Thu, 11 Apr 2013 16:57:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6AA4F1A0099 for ; Thu, 11 Apr 2013 19:57:59 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id D94EA1A010D for ; Thu, 11 Apr 2013 19:57:58 -0400 (EDT) Message-ID: <51674E02.30300@isoc.org> Date: Thu, 11 Apr 2013 19:57:54 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] forthcoming polls related to issue tracker X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:58:00 -0000 Folks, I have been talking with the JOSE document editors about gathering input in advance of the upcoming interim meeting. They have proposed a series of polls to gather feedback on existing issues that already have proposals on the table. These polls are not consensus calls, but they are a mechanism to gather information about the sense of the working group on existing proposals and to solicit ideas for alternative proposals. Please take a moment to respond to each poll message, by Friday April 19th (or earlier if possible). They are being sent individually to facilitate collation of responses. Please note I am traveling outside the US and will not be responding to any questions prior to Sunday April 14th. Regards, Karen From odonoghue@isoc.org Thu Apr 11 16:58:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CB021F87C3 for ; Thu, 11 Apr 2013 16:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWZ1Iiq-feRy for ; Thu, 11 Apr 2013 16:58:16 -0700 (PDT) Received: from smtp110.ord1c.emailsrvr.com (smtp110.ord1c.emailsrvr.com [108.166.43.110]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD5821F87B6 for ; Thu, 11 Apr 2013 16:58:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id CE1B09811C for ; Thu, 11 Apr 2013 19:58:15 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id E4FAC980E1 for ; Thu, 11 Apr 2013 19:58:14 -0400 (EDT) Message-ID: <51674E17.5020902@isoc.org> Date: Thu, 11 Apr 2013 19:58:15 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: multipart/alternative; boundary="------------050901060905010902010201" Subject: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:58:16 -0000 This is a multi-part message in MIME format. --------------050901060905010902010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers. The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html . Which of these best describes your preferences on this issue? 1. Continue have the JWA algorithm identifiers be strings, and not objects. Note that WebCrypto may choose to use some of these same strings, where applicable. 2. Switch to using the algorithm identifier structures defined in the WebCrypto draft. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19^th or earlier. --------------050901060905010902010201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.  The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.


Which of these best describes your preferences on this issue?

1.  Continue have the JWA algorithm identifiers be strings, and not objects.  Note that WebCrypto may choose to use some of these same strings, where applicable.

2.  Switch to using the algorithm identifier structures defined in the WebCrypto draft.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.



--------------050901060905010902010201-- From odonoghue@isoc.org Thu Apr 11 16:58:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579D21F86FA for ; Thu, 11 Apr 2013 16:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJL6O5ETA0tB for ; Thu, 11 Apr 2013 16:58:37 -0700 (PDT) Received: from smtp86.ord1c.emailsrvr.com (smtp86.ord1c.emailsrvr.com [108.166.43.86]) by ietfa.amsl.com (Postfix) with ESMTP id A1DD221F86B2 for ; Thu, 11 Apr 2013 16:58:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 615DF501F8 for ; Thu, 11 Apr 2013 19:58:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id D2C3C501EF for ; Thu, 11 Apr 2013 19:58:36 -0400 (EDT) Message-ID: <51674E2D.3040604@isoc.org> Date: Thu, 11 Apr 2013 19:58:37 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: multipart/alternative; boundary="------------040307070906070304010509" Subject: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:58:38 -0000 This is a multi-part message in MIME format. --------------040307070906070304010509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an "spi" (security parameters index) header parameter to the JWS and JWE specifications. This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header. This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19^th or earlier. --------------040307070906070304010509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an “spi” (security parameters index) header parameter to the JWS and JWE specifications.  This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.  This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.

 

Which of these best describes your preferences on this issue?

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.

2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature.

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.
--------------040307070906070304010509-- From odonoghue@isoc.org Thu Apr 11 16:58:54 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7921F87C3 for ; Thu, 11 Apr 2013 16:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ3XZwcuwZOL for ; Thu, 11 Apr 2013 16:58:53 -0700 (PDT) Received: from smtp102.ord1c.emailsrvr.com (smtp102.ord1c.emailsrvr.com [108.166.43.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4700321F86B2 for ; Thu, 11 Apr 2013 16:58:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 13C751B00D2 for ; Thu, 11 Apr 2013 19:58:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 6BC601B00B7 for ; Thu, 11 Apr 2013 19:58:52 -0400 (EDT) Message-ID: <51674E3D.7030004@isoc.org> Date: Thu, 11 Apr 2013 19:58:53 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: multipart/alternative; boundary="------------030901000209030709010909" Subject: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:58:54 -0000 This is a multi-part message in MIME format. --------------030901000209030709010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values. If this proposal is adopted, JWEs would then have three fields -- the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. This issue is also related to issue #3. Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116. Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19^th or earlier. --------------030901000209030709010909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have three fields – the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
 

Which of these best describes your preferences on this issue?

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.  Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.
--------------030901000209030709010909-- From odonoghue@isoc.org Thu Apr 11 16:59:21 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCF21F88A1 for ; Thu, 11 Apr 2013 16:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGhL3ZufBPy0 for ; Thu, 11 Apr 2013 16:59:20 -0700 (PDT) Received: from smtp86.ord1c.emailsrvr.com (smtp86.ord1c.emailsrvr.com [108.166.43.86]) by ietfa.amsl.com (Postfix) with ESMTP id 49B2C21F86B2 for ; Thu, 11 Apr 2013 16:59:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 16BEA501DC for ; Thu, 11 Apr 2013 19:59:20 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 7394850201 for ; Thu, 11 Apr 2013 19:59:19 -0400 (EDT) Message-ID: <51674E58.6000505@isoc.org> Date: Thu, 11 Apr 2013 19:59:20 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: multipart/alternative; boundary="------------080709050104090400050904" Subject: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:59:21 -0000 This is a multi-part message in MIME format. --------------080709050104090400050904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the "x5c" header parameter from JWE, saying that no use case for it has emerged. The same logic may apply to other key specification parameters for JWE. Which of these best describes your preferences on this issue? 1. Retain the "x5c" header parameter in JWE. 2. Remove the "x5c" header parameter (and possibly other related key specification parameters) from JWE. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19^th or earlier. --------------080709050104090400050904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the “x5c” header parameter from JWE, saying that no use case for it has emerged.  The same logic may apply to other key specification parameters for JWE.


Which of these best describes your preferences on this issue?

1.  Retain the “x5c” header parameter in JWE.

2.  Remove the “x5c” header parameter (and possibly other related key specification parameters) from JWE.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.
--------------080709050104090400050904-- From odonoghue@isoc.org Thu Apr 11 16:59:32 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0CF21F890F for ; Thu, 11 Apr 2013 16:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjgfkmRcuun2 for ; Thu, 11 Apr 2013 16:59:31 -0700 (PDT) Received: from smtp102.ord1c.emailsrvr.com (smtp102.ord1c.emailsrvr.com [108.166.43.102]) by ietfa.amsl.com (Postfix) with ESMTP id 81AA421F86B2 for ; Thu, 11 Apr 2013 16:59:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4FA161B0099 for ; Thu, 11 Apr 2013 19:59:31 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id BCC871B0087 for ; Thu, 11 Apr 2013 19:59:30 -0400 (EDT) Message-ID: <51674E63.3050809@isoc.org> Date: Thu, 11 Apr 2013 19:59:31 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: multipart/alternative; boundary="------------000309080501090908000007" Subject: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 23:59:32 -0000 This is a multi-part message in MIME format. --------------000309080501090908000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15 . suggests requiring that a key indicator, such as a "kid" field, be required in all JWS and JWE headers.Are use cases where key information is exchanged by means other than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19^th (or earlier). --------------000309080501090908000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a “kid” field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this issue?

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th (or earlier).
--------------000309080501090908000007-- From dick.hardt@gmail.com Thu Apr 11 17:16:15 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADA621F89A6 for ; Thu, 11 Apr 2013 17:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35DDhMa5rdII for ; Thu, 11 Apr 2013 17:16:14 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id C963821F899E for ; Thu, 11 Apr 2013 17:16:14 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id up7so1116076pbc.15 for ; Thu, 11 Apr 2013 17:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=h08G/1Y6CGAIeBo5P4wmmu8zIkCnuYP0O3jaYJE80PA=; b=PCJTX7nM9ZmSn024zz1zUEiCUW5OCdUiJ44qk54q/p3ZSE9qN3EDfrTTFoVp8SEXHy EbhcbcaabIv0crGcT83GUxkxRuRh1IiFjUQ4+CQTmWKqYWUr8MeF+3jrnh/tN7S2NbRk xXAzS7BcNIWohXwbosqHgkKPjE75kzz/eLLjKRsxOO/5qs9hcCevvQJP3PXg+mtzfVK3 iaOwsvjI9P0HX5S9avMVoCo3Q1Oaceai8Zga2QyBlhQ91OgGkAYrG4tQbprAhKa2Nr/M XtvAo4Y56ARMeNzZuu4BGZ6n9R4DoKt8IuZAkztSQMb+/L8DThTlLkHlv52ZVdITnxew jX5Q== X-Received: by 10.68.247.100 with SMTP id yd4mr11756223pbc.47.1365725774475; Thu, 11 Apr 2013 17:16:14 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id ba10sm6031450pbd.21.2013.04.11.17.16.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 17:16:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_03A66FC7-D3A1-431B-87E3-FE445D5C42C7" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <51674E17.5020902@isoc.org> Date: Thu, 11 Apr 2013 17:16:06 -0700 Message-Id: <35633DAD-58BB-42C3-86BE-81A0FA0402CB@gmail.com> References: <51674E17.5020902@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 00:16:15 -0000 --Apple-Mail=_03A66FC7-D3A1-431B-87E3-FE445D5C42C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 1 On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue = wrote: > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out = that the JWA algorithm identifiers are different than those used by the = W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA = algorithm identifiers are strings, whereas the W3C WebCrypto algorithm = identifiers are structures including string identifiers. The working = group had previously decided to continue representing JOSE algorithms as = strings, as recorded at = http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue have the JWA algorithm identifiers be strings, and not = objects. Note that WebCrypto may choose to use some of these same = strings, where applicable. >=20 > 2. Switch to using the algorithm identifier structures defined in the = WebCrypto draft. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_03A66FC7-D3A1-431B-87E3-FE445D5C42C7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 1

On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.  The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.


Which of these best describes your preferences on this issue?

1.  Continue have the JWA algorithm identifiers be strings, and not objects.  Note that WebCrypto may choose to use some of these same strings, where applicable.

2.  Switch to using the algorithm identifier structures defined in the WebCrypto draft.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.



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

--Apple-Mail=_03A66FC7-D3A1-431B-87E3-FE445D5C42C7-- From dick.hardt@gmail.com Thu Apr 11 17:19:32 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B6F21F87C3 for ; Thu, 11 Apr 2013 17:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k605wzSInuu for ; Thu, 11 Apr 2013 17:19:32 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2A221F87B6 for ; Thu, 11 Apr 2013 17:19:32 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fb10so1167294pad.39 for ; Thu, 11 Apr 2013 17:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=DzusTjz9Udy5qoOz3E+D8OcaJmIuUN0caNonyiwJTq0=; b=q1VJSSBOtwomyhAHiI4sBD65+WCJw8nYCGFXvpmxugE09PSrKno1qX6SsMrZmFJFT1 SCAallywUKPo+NB/daaZnNfYwnewQeGQ6CTS/DhBLaFRCC7Q1lMWYfr+eEvq+dl9lzwL 5C8E9DQdFEN9sO66UCi+gqKiYrutcdVOw+q3X3q+ABaknnkM2JX992vii5h0KOS1Py+U WNiBn5fb2Kce7e2cMRn9TMBdQR6NYj8cY2cDvXJP+trGnAc85utZaAuZHrYFg16cidqz exxLj+Dlmn3d9sY8bgEFsCE6jfQO6GxFv95M0vN4ICADME2K0qw10ApD8jHN96cHxzwd gtKw== X-Received: by 10.68.197.67 with SMTP id is3mr11724879pbc.104.1365725971713; Thu, 11 Apr 2013 17:19:31 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id jk11sm6074204pbb.0.2013.04.11.17.19.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 17:19:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7ED9A430-BDF5-436A-B99E-DA8B9AC9C894" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <51674E2D.3040604@isoc.org> Date: Thu, 11 Apr 2013 17:19:27 -0700 Message-Id: <5BBEA8B4-A790-4AC9-A78F-CCA835850A35@gmail.com> References: <51674E2D.3040604@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 00:19:32 -0000 --Apple-Mail=_7ED9A430-BDF5-436A-B99E-DA8B9AC9C894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 3 On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue = wrote: > Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes = adding an =93spi=94 (security parameters index) header parameter to the = JWS and JWE specifications. This modification to the JOSE formats would = allow for signaling that pre-negotiated cryptographic parameters are = being used, rather than including those parameters in the JWS or JWE = header. This proposal has been written up as = http://tools.ietf.org/html/draft-barnes-jose-spi-00. > =20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Have draft-barnes-jose-spi remain a separate specification that = could optionally also be supported by JWS and JWE implementations. >=20 > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as a mandatory feature. >=20 > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as an optional feature. >=20 > 4. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_7ED9A430-BDF5-436A-B99E-DA8B9AC9C894 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 odonoghue@isoc.org> = wrote:

=20 =20
Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an =93spi=94 (security parameters index) header parameter to = the JWS and JWE specifications.  This modification to the JOSE = formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.  This proposal has been written up as http://tools.= ietf.org/html/draft-barnes-jose-spi-00.

 

Which of these best describes your preferences on this = issue?

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE = implementations.

2.  = Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory = feature.

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_7ED9A430-BDF5-436A-B99E-DA8B9AC9C894-- From dick.hardt@gmail.com Thu Apr 11 17:19:58 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1906B21F89A6 for ; Thu, 11 Apr 2013 17:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-1.823, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wCWhnibYn4b for ; Thu, 11 Apr 2013 17:19:57 -0700 (PDT) Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8572921F87B6 for ; Thu, 11 Apr 2013 17:19:57 -0700 (PDT) Received: by mail-da0-f48.google.com with SMTP id p8so890388dan.21 for ; Thu, 11 Apr 2013 17:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=sUZZyUDhyJWoROQjLadHs0BbccHvDO4KLZrjdLQ+ONg=; b=xfPGShAJCb45ATBk52JxUWiZbOsNnInBSFe2Is1PRe7qic1Dtmi0epc30/VhwCgISr Y6sFpjj9WvSpayL1A5pLkN4ii/Z89xVCab7N+det0UmUC1nj/wFssALLpdU8C0BHwN0x 9yOUyg+7RcQr2GvKzn2zd3Xidjy6j1TNm4DDWqavI7wCZ0qwlJh0rlhxStYIitvW3HnY ZBfXVt+89GG2dgqifbS6AFlMDpc90mLO+ReMR0JZRdcr/AvsduPMxJUMvnK24o9zl6eI se/9gfxdEAPsdOm0xcF9IYmZm3KfbedCKjpZ9GnQt2SXlgy+Mgjqw6B4R+PbU6xlNksD 6b6w== X-Received: by 10.66.84.74 with SMTP id w10mr12181171pay.214.1365725997307; Thu, 11 Apr 2013 17:19:57 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id jk11sm6074204pbb.0.2013.04.11.17.19.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 17:19:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9999262E-8296-4E91-8D99-C0AF10475D16" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <51674E3D.7030004@isoc.org> Date: Thu, 11 Apr 2013 17:19:54 -0700 Message-Id: References: <51674E3D.7030004@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 00:19:58 -0000 --Apple-Mail=_9999262E-8296-4E91-8D99-C0AF10475D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1 On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue = wrote: > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes = restructuring the JWE representation to remove the JWE Integrity Value = field and instead use the RFC 5116 (AEAD) binary serialization to = represent the Ciphertext, Initialization Vector, and Integrity Value = values. If this proposal is adopted, JWEs would then have three fields = =96 the header, the encrypted key, and the RFC 5116 combination of the = Ciphertext, Initialization Vector, and Integrity Value values.=20 > This issue is also related to issue #3. Note that the updated McGrew = draft described there could be used whether or not we switched to using = RFC 5116. > =20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue having separate Ciphertext, Initialization Vector, and = Integrity Value values in the JWE representation. >=20 > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the = combination of these three values. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > =20 >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_9999262E-8296-4E91-8D99-C0AF10475D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 odonoghue@isoc.org> = wrote:
=20 =20
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then = have three fields =96 the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This = issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
 

Which of these best describes your preferences on this = issue?

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.  = Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three = values.

3.  = Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_9999262E-8296-4E91-8D99-C0AF10475D16-- From dick.hardt@gmail.com Thu Apr 11 17:22:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7202121F851C for ; Thu, 11 Apr 2013 17:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe7tBdj8Sb71 for ; Thu, 11 Apr 2013 17:22:15 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id C4D4F21F8517 for ; Thu, 11 Apr 2013 17:22:15 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id x11so1112029pdj.38 for ; Thu, 11 Apr 2013 17:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=WNcrKwn4lBzpTZ1a1UrCtwjoeGFXojbbjNfMdKupba0=; b=cn3u9DbzJhdv3nzx/1n7OFDy5F8++/Wz/Tiz/VG84cKL2VF5SoLUCYm7V/dpdyyx4E /jEFBm1c4H50ISqcncoYv/ia21XNG76cYw2UhnrHCJFOMceM151ONZZktO01GIcxay89 PBQZE3v3wsfJOR/1qscTfxjUfYV8oXLnByFJkhzXWKHBzUAFfZxKpBFrYxoDEKLZT0gJ UiM16YV6y/cSksUA4m8vTK0jKAk10WaoYitNBJxEU9R1PQRtwyxjTRUZbjyZOeth64uz 2kzKfo/ZF3AxYUH38GMFlVBWyVi4h2a+gzF67VvsLPdFgBCkYk+7wmhWL3SCIAlEO3P5 QzXw== X-Received: by 10.66.144.170 with SMTP id sn10mr480508pab.42.1365726135595; Thu, 11 Apr 2013 17:22:15 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id c5sm17394pbl.37.2013.04.11.17.22.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 17:22:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E841D930-5EAF-4BDE-A580-7196B9B87A86" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <51674E63.3050809@isoc.org> Date: Thu, 11 Apr 2013 17:22:11 -0700 Message-Id: References: <51674E63.3050809@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 00:22:16 -0000 --Apple-Mail=_E841D930-5EAF-4BDE-A580-7196B9B87A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1A, a key indicator SHOULD be included. (not a MUST) On Apr 11, 2013, at 4:59 PM, Karen O'Donoghue = wrote: > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests = requiring that a key indicator, such as a =93kid=94 field, be required = in all JWS and JWE headers. Are use cases where key information is = exchanged by means other than the JWS or JWE headers important? > Which of these best describes your preferences on this issue? >=20 > 1. Yes. >=20 > 2. No. >=20 > 0. I need more information to decide. >=20 > =20 >=20 > Your reply is requested by Friday, April 19th (or earlier).=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_E841D930-5EAF-4BDE-A580-7196B9B87A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 1A, =  a key indicator SHOULD be included. (not a = MUST)

On Apr 11, 2013, at 4:59 PM, Karen O'Donoghue = <odonoghue@isoc.org> = wrote:

=20 =20
Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a =93kid=94 field, be = required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this = issue?

1.  Yes.

2.   No. =

0.  I = need more information to decide.

 

Your reply is requested by Friday, April 19th (or earlier).
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_E841D930-5EAF-4BDE-A580-7196B9B87A86-- From James.H.Manger@team.telstra.com Thu Apr 11 18:53:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B8F21F86CE for ; Thu, 11 Apr 2013 18:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZJUgdF8YdYh for ; Thu, 11 Apr 2013 18:53:47 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7A221F86C5 for ; Thu, 11 Apr 2013 18:53:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,460,1363093200"; d="scan'208,217";a="124750539" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 12 Apr 2013 11:53:43 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7042"; a="127041700" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 12 Apr 2013 11:53:43 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Fri, 12 Apr 2013 11:53:42 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Fri, 12 Apr 2013 11:53:41 +1000 Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: Ac43EIJSEZZZDIC4TlacSkd5oe9GgQADt3fw Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C5F132E@WSMSG3153V.srv.dir.telstra.com> References: <51674E2D.3040604@isoc.org> In-Reply-To: <51674E2D.3040604@isoc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150C5F132EWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 01:53:48 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150C5F132EWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MWIuDQpIYXZlIOKAnHNwaeKAnSBhcyBhIHNlcGFyYXRlIChvcHRpb25hbCkgc3BlYy4NCkNoYW5n ZSBpdHMgZGVmaW5pdGlvbiBzbyBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGNyeXB0by4gRm9yIGlu c3RhbmNlLCB0aGUgaGVhZGVyIHRoYXQgaXMgcGFydCBvZiB0aGUgaW50ZWdyaXR5IGNoZWNrIGlz IHRoZSBoZWFkZXIgd2l0aCB0aGUgZnVsbCBhbGcgaWRzLCBhbmQga2V5IGlkcyDigJQgbm90IHRo ZSBoZWFkZXIgd2l0aCBqdXN0IHRoZSDigJxzcGnigJ0gdmFsdWUuIE90aGVyd2lzZSDigJxzcGni gJ0gaXMgY2hhbmdpbmcgdGhlIGNyeXB0byBwcm9wZXJ0aWVzLCBub3QganVzdCBzYXZpbmcgYnl0 ZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2FyZW4gTydEb25vZ2h1 ZQ0KU2VudDogRnJpZGF5LCAxMiBBcHJpbCAyMDEzIDk6NTkgQU0NClRvOiBqb3NlQGlldGYub3Jn DQpTdWJqZWN0OiBbam9zZV0gRmVlZGJhY2sgcmVxdWVzdCBvbiBqb3NlIHRyYWNrZXIgaXNzdWUg Izg6IFNob3VsZCB3ZSBhZGQgYSAic3BpIiBoZWFkZXIgZmllbGQ/DQoNCklzc3VlICM4IGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvOCBwcm9wb3NlcyBhZGRp bmcgYW4g4oCcc3Bp4oCdIChzZWN1cml0eSBwYXJhbWV0ZXJzIGluZGV4KSBoZWFkZXIgcGFyYW1l dGVyIHRvIHRoZSBKV1MgYW5kIEpXRSBzcGVjaWZpY2F0aW9ucy4gIFRoaXMgbW9kaWZpY2F0aW9u IHRvIHRoZSBKT1NFIGZvcm1hdHMgd291bGQgYWxsb3cgZm9yIHNpZ25hbGluZyB0aGF0IHByZS1u ZWdvdGlhdGVkIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVycyBhcmUgYmVpbmcgdXNlZCwgcmF0aGVy IHRoYW4gaW5jbHVkaW5nIHRob3NlIHBhcmFtZXRlcnMgaW4gdGhlIEpXUyBvciBKV0UgaGVhZGVy LiAgVGhpcyBwcm9wb3NhbCBoYXMgYmVlbiB3cml0dGVuIHVwIGFzIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJhcm5lcy1qb3NlLXNwaS0wMC4NCg0KV2hpY2ggb2YgdGhlc2UgYmVz dCBkZXNjcmliZXMgeW91ciBwcmVmZXJlbmNlcyBvbiB0aGlzIGlzc3VlPw0KMS4gIEhhdmUgZHJh ZnQtYmFybmVzLWpvc2Utc3BpIHJlbWFpbiBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gdGhhdCBj b3VsZCBvcHRpb25hbGx5IGFsc28gYmUgc3VwcG9ydGVkIGJ5IEpXUyBhbmQgSldFIGltcGxlbWVu dGF0aW9ucy4NCjIuICBJbmNvcnBvcmF0ZSBkcmFmdC1iYXJuZXMtam9zZS1zcGkgaW50byB0aGUg SldTIGFuZCBKV0Ugc3BlY2lmaWNhdGlvbnMgYXMgYSBtYW5kYXRvcnkgZmVhdHVyZS4NCjMuICBJ bmNvcnBvcmF0ZSBkcmFmdC1iYXJuZXMtam9zZS1zcGkgaW50byB0aGUgSldTIGFuZCBKV0Ugc3Bl Y2lmaWNhdGlvbnMgYXMgYW4gb3B0aW9uYWwgZmVhdHVyZS4NCjQuICBBbm90aGVyIHJlc29sdXRp b24gKHBsZWFzZSBzcGVjaWZ5IGluIGRldGFpbCkuDQowLiAgSSBuZWVkIG1vcmUgaW5mb3JtYXRp b24gdG8gZGVjaWRlLg0KWW91ciByZXBseSBpcyByZXF1ZXN0ZWQgYnkgRnJpZGF5LCBBcHJpbCAx OXRoIG9yIGVhcmxpZXIuDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150C5F132EWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tQVUgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4xYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGF2ZSDigJxzcGnigJ0gYXMg YSBzZXBhcmF0ZSAob3B0aW9uYWwpIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNoYW5nZSBpdHMgZGVmaW5pdGlvbiBz byBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGNyeXB0by4gRm9yIGluc3RhbmNlLCB0aGUgaGVhZGVy IHRoYXQgaXMgcGFydCBvZiB0aGUgaW50ZWdyaXR5IGNoZWNrIGlzIHRoZSBoZWFkZXIgd2l0aCB0 aGUgZnVsbCBhbGcgaWRzLCBhbmQga2V5IGlkcyDigJQgbm90IHRoZSBoZWFkZXIgd2l0aCBqdXN0 IHRoZSDigJxzcGnigJ0gdmFsdWUuIE90aGVyd2lzZSDigJxzcGnigJ0gaXMgY2hhbmdpbmcgdGhl IGNyeXB0byBwcm9wZXJ0aWVzLCBub3QganVzdCBzYXZpbmcgYnl0ZXMuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6 d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRv d3RleHQnPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+S2FyZW4gTydEb25vZ2h1ZTxicj48Yj5TZW50OjwvYj4g RnJpZGF5LCAxMiBBcHJpbCAyMDEzIDk6NTkgQU08YnI+PGI+VG86PC9iPiBqb3NlQGlldGYub3Jn PGJyPjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gRmVlZGJhY2sgcmVxdWVzdCBvbiBqb3NlIHRyYWNr ZXIgaXNzdWUgIzg6IFNob3VsZCB3ZSBhZGQgYSAmcXVvdDtzcGkmcXVvdDsgaGVhZGVyIGZpZWxk PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPklzc3VlICM4IDxhIGhyZWY9Imh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvOCI+aHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC84PC9hPiBwcm9wb3NlcyBhZGRp bmcgYW4g4oCcc3Bp4oCdIChzZWN1cml0eSBwYXJhbWV0ZXJzIGluZGV4KSBoZWFkZXIgcGFyYW1l dGVyIHRvIHRoZSBKV1MgYW5kIEpXRSBzcGVjaWZpY2F0aW9ucy4mbmJzcDsgVGhpcyBtb2RpZmlj YXRpb24gdG8gdGhlIEpPU0UgZm9ybWF0cyB3b3VsZCBhbGxvdyBmb3Igc2lnbmFsaW5nIHRoYXQg cHJlLW5lZ290aWF0ZWQgY3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzIGFyZSBiZWluZyB1c2VkLCBy YXRoZXIgdGhhbiBpbmNsdWRpbmcgdGhvc2UgcGFyYW1ldGVycyBpbiB0aGUgSldTIG9yIEpXRSBo ZWFkZXIuJm5ic3A7IFRoaXMgcHJvcG9zYWwgaGFzIGJlZW4gd3JpdHRlbiB1cCBhcyA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYXJuZXMtam9zZS1zcGktMDAiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhcm5lcy1qb3NlLXNwaS0wMDwvYT4uIDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPldoaWNoIG9mIHRoZXNlIGJlc3QgZGVzY3JpYmVzIHlvdXIgcHJl ZmVyZW5jZXMgb24gdGhpcyBpc3N1ZT88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz4xLiZuYnNwOyBIYXZlIGRyYWZ0LWJhcm5lcy1qb3NlLXNwaSByZW1haW4gYSBzZXBhcmF0ZSBz cGVjaWZpY2F0aW9uIHRoYXQgY291bGQgb3B0aW9uYWxseSBhbHNvIGJlIHN1cHBvcnRlZCBieSBK V1MgYW5kIEpXRSBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+Mi4mbmJzcDsgSW5jb3Jwb3JhdGUgZHJhZnQtYmFybmVzLWpvc2Utc3BpIGludG8gdGhl IEpXUyBhbmQgSldFIHNwZWNpZmljYXRpb25zIGFzIGEgbWFuZGF0b3J5IGZlYXR1cmUuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+My4mbmJzcDsgSW5jb3Jwb3JhdGUgZHJhZnQt YmFybmVzLWpvc2Utc3BpIGludG8gdGhlIEpXUyBhbmQgSldFIHNwZWNpZmljYXRpb25zIGFzIGFu IG9wdGlvbmFsIGZlYXR1cmUuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+NC4m bmJzcDsgQW5vdGhlciByZXNvbHV0aW9uIChwbGVhc2Ugc3BlY2lmeSBpbiBkZXRhaWwpLjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjAuJm5ic3A7IEkgbmVlZCBtb3JlIGluZm9y bWF0aW9uIHRvIGRlY2lkZS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+WW91ciBy ZXBseSBpcyByZXF1ZXN0ZWQgYnkgRnJpZGF5LCBBcHJpbCAxOTxzdXA+dGg8L3N1cD4gb3IgZWFy bGllci4gPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150C5F132EWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Thu Apr 11 19:37:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF41321E803A for ; Thu, 11 Apr 2013 19:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtz74Ea-1TFx for ; Thu, 11 Apr 2013 19:37:37 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4D12821E8042 for ; Thu, 11 Apr 2013 19:37:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,460,1363093200"; d="scan'208,217";a="129417113" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 12 Apr 2013 12:37:35 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7042"; a="124972259" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 12 Apr 2013 12:37:35 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 12 Apr 2013 12:37:34 +1000 From: "Manger, James H" To: "odonoghue@isoc.org" , "jose@ietf.org" Date: Fri, 12 Apr 2013 12:37:34 +1000 Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: Ac43EJSRagaqhpUVQeO8f/LbwpXZBAAEXPFw Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C5F1446@WSMSG3153V.srv.dir.telstra.com> References: <51674E3D.7030004@isoc.org> In-Reply-To: <51674E3D.7030004@isoc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150C5F1446WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 02:37:38 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150C5F1446WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2FyZW4sDQpJIHRoaW5rIHRoaXMgcG9sbCBjb25mbGF0ZXMgMiBpc3N1ZXM6IGEpIG1ha2luZyB0 aGUgaW50ZWdyaXR5IGNoZWNrIHZhbHVlIHBhcnQgb2YgdGhlIGNpcGhlcnRleHQgKGFzIHBlciBS RkMgNTExNik7IGFuZCBiKSBub3QgdHJlYXRpbmcgdGhlIElWIGluIENCQy1ITUFDIGFzIGFuIChh cHAtc3VwcGxpZWQpIEFFQUQgbm9uY2UsIGJ1dCBhcyBwYXJ0IG9mIHRoZSByYW5kb21pemVkIChj cnlwdG8tbGlicmFyeS1zdXBwbGllZCkgY2lwaGVydGV4dCAoYXMgcGVyIGRyYWZ0LW1jZ3Jldy1h ZWFkLWFlcy1jYmMtaG1hYy1zaGEyKS4NCg0KUkZDIDUxMTYg4oCcQW4gaW50ZXJmYWNlIGFuZCBh bGdvcml0aG1zIGZvciBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb27igJ0gaGFzIGEgbm9uY2UgKE4p IGFuZCBhIHNlcGFyYXRlIGZpZWxkIHRvIHRoZSBjaXBoZXJ0ZXh0LiBOIGlzIGEgc2VwYXJhdGUg aW5wdXQgdG8gdGhlIGVuY3J5cHRpb24gYW5kIGRlY3J5cHRpb24gb3BlcmF0aW9ucy4NCmRyYWZ0 LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGRlZmluZXMgQUVBRCBhbGdvcml0aG1zIHRo YXQgdGFrZSBhIHplcm8tbGVuZ3RoIG5vbmNlLCBidXQgcHJlZml4IHRoZSBjaXBoZXJ0ZXh0IHdp dGggYSByYW5kb20gSVYuDQoNCg0KU28gbXkgYW5zd2VyIHRvIHRoZSBwb2xsOg0KDQoyYi4NClN3 aXRjaCB0byB1c2luZyBSRkMgNTExNi4NCkEgSldFIHNob3VsZCBoYXZlIHNlcGFyYXRlIG5vbmNl IGFuZCBjaXBoZXJ0ZXh0IGZpZWxkcyAoYnV0IG5vIHNlcGFyYXRlIGludGVncml0eSB2YWx1ZSBm aWVsZCkuDQpKV0Ugc2hvdWxkIHVzZSB0aGUgdGVybSDigJxub25jZeKAnSwgaW5zdGVhZCBvZiDi gJxpbml0aWFsaXphdGlvbiB2ZWN0b3LigJ0uDQpBbnkgaW50ZWdyaXR5IHZhbHVlIHRoYXQgYW4g YWxnb3JpdGhtIGNyZWF0ZXMgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGNpcGhlcnRleHQuDQpXaGVu IGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGlzIHVzZWQgYXMgdGhlIEFFQUQg YWxnb3JpdGhtIHRoZSBub25jZSBmaWVsZCB3aWxsIGJlIGVtcHR5LCBhbmQgdGhlIGNpcGhlcnRl eHQgZmllbGQgd2lsbCBiZSBhIGNvbmNhdGVuYXRpb24gb2YgYW4gSVYsIEFFUyBvdXRwdXQsIGFu ZCB0aGUgdHJ1bmNhdGVkIEhNQUMgb3V0cHV0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206 IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEthcmVuIE8nRG9ub2dodWUNClNlbnQ6IEZyaWRheSwgMTIgQXByaWwgMjAxMyA5 OjU5IEFNDQpUbzogam9zZUBpZXRmLm9yZw0KU3ViamVjdDogW2pvc2VdIEZlZWRiYWNrIHJlcXVl c3Qgb24gam9zZSB0cmFja2VyIGlzc3VlIzExOiBTaG91bGQgd2UgdXNlIFJGQyA1MTE2IGFuZCBy ZW1vdmUgdGhlIEpXRSBJbnRlZ3JpdHkgVmFsdWUgZmllbGQ/DQoNCklzc3VlICMxMSBodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzExIHByb3Bvc2VzIHJlc3Ry dWN0dXJpbmcgdGhlIEpXRSByZXByZXNlbnRhdGlvbiB0byByZW1vdmUgdGhlIEpXRSBJbnRlZ3Jp dHkgVmFsdWUgZmllbGQgYW5kIGluc3RlYWQgdXNlIHRoZSBSRkMgNTExNiAoQUVBRCkgYmluYXJ5 IHNlcmlhbGl6YXRpb24gdG8gcmVwcmVzZW50IHRoZSBDaXBoZXJ0ZXh0LCBJbml0aWFsaXphdGlv biBWZWN0b3IsIGFuZCBJbnRlZ3JpdHkgVmFsdWUgdmFsdWVzLiAgSWYgdGhpcyBwcm9wb3NhbCBp cyBhZG9wdGVkLCBKV0VzIHdvdWxkIHRoZW4gaGF2ZSB0aHJlZSBmaWVsZHMg4oCTIHRoZSBoZWFk ZXIsIHRoZSBlbmNyeXB0ZWQga2V5LCBhbmQgdGhlIFJGQyA1MTE2IGNvbWJpbmF0aW9uIG9mIHRo ZSBDaXBoZXJ0ZXh0LCBJbml0aWFsaXphdGlvbiBWZWN0b3IsIGFuZCBJbnRlZ3JpdHkgVmFsdWUg dmFsdWVzLg0KVGhpcyBpc3N1ZSBpcyBhbHNvIHJlbGF0ZWQgdG8gaXNzdWUgIzMuICBOb3RlIHRo YXQgdGhlIHVwZGF0ZWQgTWNHcmV3IGRyYWZ0IGRlc2NyaWJlZCB0aGVyZSBjb3VsZCBiZSB1c2Vk IHdoZXRoZXIgb3Igbm90IHdlIHN3aXRjaGVkIHRvIHVzaW5nIFJGQyA1MTE2Lg0KDQpXaGljaCBv ZiB0aGVzZSBiZXN0IGRlc2NyaWJlcyB5b3VyIHByZWZlcmVuY2VzIG9uIHRoaXMgaXNzdWU/DQox LiAgQ29udGludWUgaGF2aW5nIHNlcGFyYXRlIENpcGhlcnRleHQsIEluaXRpYWxpemF0aW9uIFZl Y3RvciwgYW5kIEludGVncml0eSBWYWx1ZSB2YWx1ZXMgaW4gdGhlIEpXRSByZXByZXNlbnRhdGlv bi4NCjIuICBTd2l0Y2ggdG8gdXNpbmcgdGhlIFJGQyA1MTE2IChBRUFEKSBzZXJpYWxpemF0aW9u IHRvIHJlcHJlc2VudCB0aGUgY29tYmluYXRpb24gb2YgdGhlc2UgdGhyZWUgdmFsdWVzLg0KMy4g IEFub3RoZXIgcmVzb2x1dGlvbiAocGxlYXNlIHNwZWNpZnkgaW4gZGV0YWlsKS4NCjAuICBJIG5l ZWQgbW9yZSBpbmZvcm1hdGlvbiB0byBkZWNpZGUuDQoNCllvdXIgcmVwbHkgaXMgcmVxdWVzdGVk IGJ5IEZyaWRheSwgQXByaWwgMTl0aCBvciBlYXJsaWVyLg0K --_000_255B9BB34FB7D647A506DC292726F6E1150C5F1446WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tQVUgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5LYXJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB0aGluayB0aGlzIHBv bGwgY29uZmxhdGVzIDIgaXNzdWVzOiBhKSBtYWtpbmcgdGhlIGludGVncml0eSBjaGVjayB2YWx1 ZSBwYXJ0IG9mIHRoZSBjaXBoZXJ0ZXh0IChhcyBwZXIgUkZDIDUxMTYpOyBhbmQgYikgbm90IHRy ZWF0aW5nIHRoZSBJViBpbiBDQkMtSE1BQyBhcyBhbiAoYXBwLXN1cHBsaWVkKSBBRUFEIG5vbmNl LCBidXQgYXMgcGFydCBvZiB0aGUgcmFuZG9taXplZCAoY3J5cHRvLWxpYnJhcnktc3VwcGxpZWQp IGNpcGhlcnRleHQgKGFzIHBlciBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiku PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5SRkMgNTExNiDigJxBbiBpbnRlcmZhY2UgYW5kIGFsZ29yaXRo bXMgZm9yIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbuKAnSBoYXMgYSBub25jZSAoTikgYW5kIGEg c2VwYXJhdGUgZmllbGQgdG8gdGhlIGNpcGhlcnRleHQuIE4gaXMgYSBzZXBhcmF0ZSBpbnB1dCB0 byB0aGUgZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBvcGVyYXRpb25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5kcmFmdC1t Y2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiBkZWZpbmVzIEFFQUQgYWxnb3JpdGhtcyB0aGF0 IHRha2UgYSB6ZXJvLWxlbmd0aCBub25jZSwgYnV0IHByZWZpeCB0aGUgY2lwaGVydGV4dCB3aXRo IGEgcmFuZG9tIElWLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvIG15IGFuc3dl ciB0byB0aGUgcG9sbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjJiLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Td2l0Y2ggdG8gdXNp bmcgUkZDIDUxMTYuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkEgSldFIHNob3VsZCBoYXZlIHNlcGFyYXRlIG5vbmNlIGFuZCBj aXBoZXJ0ZXh0IGZpZWxkcyAoYnV0IG5vIHNlcGFyYXRlIGludGVncml0eSB2YWx1ZSBmaWVsZCku PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkpXRSBzaG91bGQgdXNlIHRoZSB0ZXJtIOKAnG5vbmNl4oCdLCBpbnN0ZWFkIG9mIOKA nGluaXRpYWxpemF0aW9uIHZlY3RvcuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QW55IGludGVncml0eSB2YWx1ZSB0aGF0 IGFuIGFsZ29yaXRobSBjcmVhdGVzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBjaXBoZXJ0ZXh0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5XaGVuIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGlzIHVzZWQgYXMg dGhlIEFFQUQgYWxnb3JpdGhtIHRoZSBub25jZSBmaWVsZCB3aWxsIGJlIGVtcHR5LCBhbmQgdGhl IGNpcGhlcnRleHQgZmllbGQgd2lsbCBiZSBhIGNvbmNhdGVuYXRpb24gb2YgYW4gSVYsIEFFUyBv dXRwdXQsIGFuZCB0aGUgdHJ1bmNhdGVkIEhNQUMgb3V0cHV0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRv d3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0 Jz4gam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPkthcmVuIE8nRG9ub2dodWU8YnI+PGI+U2VudDo8L2I+IEZyaWRh eSwgMTIgQXByaWwgMjAxMyA5OjU5IEFNPGJyPjxiPlRvOjwvYj4gam9zZUBpZXRmLm9yZzxicj48 Yj5TdWJqZWN0OjwvYj4gW2pvc2VdIEZlZWRiYWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlz c3VlIzExOiBTaG91bGQgd2UgdXNlIFJGQyA1MTE2IGFuZCByZW1vdmUgdGhlIEpXRSBJbnRlZ3Jp dHkgVmFsdWUgZmllbGQ/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SXNzdWUg IzExIDxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNr ZXQvMTEiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMTE8 L2E+IHByb3Bvc2VzIHJlc3RydWN0dXJpbmcgdGhlIEpXRSByZXByZXNlbnRhdGlvbiB0byByZW1v dmUgdGhlIEpXRSBJbnRlZ3JpdHkgVmFsdWUgZmllbGQgYW5kIGluc3RlYWQgdXNlIHRoZSBSRkMg NTExNiAoQUVBRCkgYmluYXJ5IHNlcmlhbGl6YXRpb24gdG8gcmVwcmVzZW50IHRoZSBDaXBoZXJ0 ZXh0LCBJbml0aWFsaXphdGlvbiBWZWN0b3IsIGFuZCBJbnRlZ3JpdHkgVmFsdWUgdmFsdWVzLiZu YnNwOyBJZiB0aGlzIHByb3Bvc2FsIGlzIGFkb3B0ZWQsIEpXRXMgd291bGQgdGhlbiBoYXZlIHRo cmVlIGZpZWxkcyDigJMgdGhlIGhlYWRlciwgdGhlIGVuY3J5cHRlZCBrZXksIGFuZCB0aGUgUkZD IDUxMTYgY29tYmluYXRpb24gb2YgdGhlIENpcGhlcnRleHQsIEluaXRpYWxpemF0aW9uIFZlY3Rv ciwgYW5kIEludGVncml0eSBWYWx1ZSB2YWx1ZXMuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPlRoaXMgaXNzdWUgaXMgYWxzbyByZWxhdGVkIHRvIGlzc3VlICMzLiZu YnNwOyBOb3RlIHRoYXQgdGhlIHVwZGF0ZWQgTWNHcmV3IGRyYWZ0IGRlc2NyaWJlZCB0aGVyZSBj b3VsZCBiZSB1c2VkIHdoZXRoZXIgb3Igbm90IHdlIHN3aXRjaGVkIHRvIHVzaW5nIFJGQyA1MTE2 Ljxicj4mbmJzcDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+V2hpY2ggb2Yg dGhlc2UgYmVzdCBkZXNjcmliZXMgeW91ciBwcmVmZXJlbmNlcyBvbiB0aGlzIGlzc3VlPzxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjEuJm5ic3A7IENvbnRpbnVlIGhhdmluZyBz ZXBhcmF0ZSBDaXBoZXJ0ZXh0LCBJbml0aWFsaXphdGlvbiBWZWN0b3IsIGFuZCBJbnRlZ3JpdHkg VmFsdWUgdmFsdWVzIGluIHRoZSBKV0UgcmVwcmVzZW50YXRpb24uPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+Mi4mbmJzcDsgU3dpdGNoIHRvIHVzaW5nIHRoZSBSRkMgNTExNiAo QUVBRCkgc2VyaWFsaXphdGlvbiB0byByZXByZXNlbnQgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZXNl IHRocmVlIHZhbHVlcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4zLiZuYnNw OyBBbm90aGVyIHJlc29sdXRpb24gKHBsZWFzZSBzcGVjaWZ5IGluIGRldGFpbCkuPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+MC4mbmJzcDsgSSBuZWVkIG1vcmUgaW5mb3JtYXRp b24gdG8gZGVjaWRlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5Zb3VyIHJlcGx5IGlzIHJlcXVlc3RlZCBi eSBGcmlkYXksIEFwcmlsIDE5PHN1cD50aDwvc3VwPiBvciBlYXJsaWVyLiA8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E1150C5F1446WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Thu Apr 11 19:54:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1201D21F8712 for ; Thu, 11 Apr 2013 19:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2C+GlshhLnG for ; Thu, 11 Apr 2013 19:54:49 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id F22A921F86FA for ; Thu, 11 Apr 2013 19:54:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,460,1363093200"; d="scan'208,217";a="123601540" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Apr 2013 12:54:47 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7042"; a="127051521" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 12 Apr 2013 12:54:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 12 Apr 2013 12:54:46 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Fri, 12 Apr 2013 12:54:44 +1000 Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: Ac43EJ6R37T2ze6TT5W+mv0DLipkTQAF4Fng Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C5F1498@WSMSG3153V.srv.dir.telstra.com> References: <51674E63.3050809@isoc.org> In-Reply-To: <51674E63.3050809@isoc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150C5F1498WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 02:54:50 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150C5F1498WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MUEuIEEga2V5IGluZGljYXRpb24gU0hPVUxEIGJlIGluY2x1ZGVkIChhbmQgY2VydGFpbmx5IG11 c3QgYmUgcHJlc2VudCBpbiBhbGwgdGhlIGV4YW1wbGVzIGluIHRoZSBzcGVjKS4NCg0KDQpQLlMu IERvZXMg4oCcWWVz4oCdIG1lYW4g4oCcWWVzLCBhIGtleSBpbmRpY2F0b3IgaXMgcmVxdWlyZWTi gJ0sIG9yIGRvZXMgaXQgbWVhbiDigJxZZXMsIHVzZSBjYXNlcyB3aGVyZSBrZXkgaW5mb3JtYXRp b24gaXMgZXhjaGFuZ2VkIGJ5IG1lYW5zIG90aGVyIHRoYW4gdGhlIEpXUyBvciBKV0UgaGVhZGVy cyBhcmUgaW1wb3J0YW504oCdICh3aGljaCBpbXBsaWVzIGEga2V5IGluZGljYXRvciBpcyBOT1Qg cmVxdWlyZWQpPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthcmVuIE8n RG9ub2dodWUNClNlbnQ6IEZyaWRheSwgMTIgQXByaWwgMjAxMyAxMDowMCBBTQ0KVG86IGpvc2VA aWV0Zi5vcmcNClN1YmplY3Q6IFtqb3NlXSBGZWVkYmFjayByZXF1ZXN0IG9uIGpvc2UgdHJhY2tl ciBpc3N1ZSAjMTU6IFNob3VsZCBhdCBsZWFzdCBvbiBrZXkgaW5kaWNhdG9yIGJlIG1hbmRhdG9y eQ0KDQpJc3N1ZSAjMTUgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3Rp Y2tldC8xNS4gc3VnZ2VzdHMgcmVxdWlyaW5nIHRoYXQgYSBrZXkgaW5kaWNhdG9yLCBzdWNoIGFz IGEg4oCca2lk4oCdIGZpZWxkLCBiZSByZXF1aXJlZCBpbiBhbGwgSldTIGFuZCBKV0UgaGVhZGVy cy4gQXJlIHVzZSBjYXNlcyB3aGVyZSBrZXkgaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIGJ5IG1l YW5zIG90aGVyIHRoYW4gdGhlIEpXUyBvciBKV0UgaGVhZGVycyBpbXBvcnRhbnQ/DQpXaGljaCBv ZiB0aGVzZSBiZXN0IGRlc2NyaWJlcyB5b3VyIHByZWZlcmVuY2VzIG9uIHRoaXMgaXNzdWU/DQox LiAgWWVzLg0KMi4gICBOby4NCjAuICBJIG5lZWQgbW9yZSBpbmZvcm1hdGlvbiB0byBkZWNpZGUu DQoNCllvdXIgcmVwbHkgaXMgcmVxdWVzdGVkIGJ5IEZyaWRheSwgQXByaWwgMTl0aCAob3IgZWFy bGllcikuDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150C5F1498WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tQVUgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4xQS4gQSBrZXkgaW5kaWNhdGlvbiBTSE9VTEQg YmUgaW5jbHVkZWQgKGFuZCBjZXJ0YWlubHkgbXVzdCBiZSBwcmVzZW50IGluIGFsbCB0aGUgZXhh bXBsZXMgaW4gdGhlIHNwZWMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlAuUy4g RG9lcyDigJxZZXPigJ0gbWVhbiDigJxZZXMsIGEga2V5IGluZGljYXRvciBpcyByZXF1aXJlZOKA nSwgb3IgZG9lcyBpdCBtZWFuIOKAnFllcywgdXNlIGNhc2VzIHdoZXJlIGtleSBpbmZvcm1hdGlv biBpcyBleGNoYW5nZWQgYnkgbWVhbnMgb3RoZXIgdGhhbiB0aGUgSldTIG9yIEpXRSBoZWFkZXJz IGFyZSBpbXBvcnRhbnTigJ0gKHdoaWNoIGltcGxpZXMgYSBrZXkgaW5kaWNhdG9yIGlzIE5PVCBy ZXF1aXJlZCk/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+S2FyZW4gTydE b25vZ2h1ZTxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCAxMiBBcHJpbCAyMDEzIDEwOjAwIEFNPGJy PjxiPlRvOjwvYj4gam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW2pvc2VdIEZlZWRi YWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlzc3VlICMxNTogU2hvdWxkIGF0IGxlYXN0IG9u IGtleSBpbmRpY2F0b3IgYmUgbWFuZGF0b3J5PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+SXNzdWUgIzE1IDxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pv c2UvdHJhYy90aWNrZXQvMTUiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJh Yy90aWNrZXQvMTU8L2E+LiBzdWdnZXN0cyByZXF1aXJpbmcgdGhhdCBhIGtleSBpbmRpY2F0b3Is IHN1Y2ggYXMgYSDigJxraWTigJ0gZmllbGQsIGJlIHJlcXVpcmVkIGluIGFsbCBKV1MgYW5kIEpX RSBoZWFkZXJzLiBBcmUgdXNlIGNhc2VzIHdoZXJlIGtleSBpbmZvcm1hdGlvbiBpcyBleGNoYW5n ZWQgYnkgbWVhbnMgb3RoZXIgdGhhbiB0aGUgSldTIG9yIEpXRSBoZWFkZXJzIGltcG9ydGFudD8g PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+V2hpY2ggb2YgdGhlc2UgYmVzdCBk ZXNjcmliZXMgeW91ciBwcmVmZXJlbmNlcyBvbiB0aGlzIGlzc3VlPzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjEuJm5ic3A7IFllcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz4yLiZuYnNwOyZuYnNwOyBOby4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+MC4mbmJzcDsgSSBuZWVkIG1vcmUgaW5mb3JtYXRpb24gdG8gZGVjaWRlLjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD5Zb3VyIHJlcGx5IGlzIHJlcXVlc3RlZCBieSBGcmlkYXksIEFwcmlsIDE5 PHN1cD50aDwvc3VwPiAob3IgZWFybGllcikuIDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjwv Ym9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E1150C5F1498WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Thu Apr 11 22:25:21 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36AE21F86DC for ; Thu, 11 Apr 2013 22:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUWwoQan3sCp for ; Thu, 11 Apr 2013 22:25:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA4C21F86B2 for ; Thu, 11 Apr 2013 22:25:20 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.15.202) by BY2FFO11HUB030.protection.gbl (10.1.14.115) with Microsoft SMTP Server (TLS) id 15.0.664.0; Fri, 12 Apr 2013 05:25:18 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Fri, 12 Apr 2013 05:25:18 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 12 Apr 2013 05:25:04 +0000 From: Mike Jones To: "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: AQHONxCooSd2LAEBTkqzIVwx4JWauZjSDFgA Date: Fri, 12 Apr 2013 05:25:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> In-Reply-To: <51674E63.3050809@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367615F37TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(5383001)(189002)(199002)(74502001)(79102001)(5343635001)(55846006)(4396001)(15202345001)(81542001)(16236675001)(74662001)(54356001)(53806001)(71186001)(564824004)(47976001)(18277545001)(65816001)(33656001)(76482001)(16406001)(49866001)(59766001)(66066001)(512954001)(69226001)(16297215001)(44976002)(56776001)(46102001)(80022001)(31966008)(63696002)(81342001)(47446002)(77982001)(5343655001)(20776003)(18276755001)(54316002)(47736001)(56816002)(51856001)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB030; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0814A2C7A3 Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 05:25:21 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367615F37TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reading this question, I believe that there's a possibility for the questio= n to be misinterpreted, since the sense of the question in the subject is o= pposite of the sense of the question in the body. I believe that the inten= t of 1 and 2 were as follows: 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. 2. No - Use cases where key information is exchanged by means other than t= he JWS and JWE headers ARE NOT important. Maybe people could reply with 1 and 2 as above, so that their answers to th= e question of whether these use cases are important are not are unambiguous= . -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 5:00 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19th (or earlier). --_000_4E1F6AAD24975D4BA5B168042967394367615F37TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reading this question, I = believe that there’s a possibility for the question to be misinterpre= ted, since the sense of the question in the subject is opposite of the sense of the question in the body.  I believe that the intent = of 1 and 2 were as follows:

 <= /p>

1.  Yes – Use = cases where key information is exchanged by means other than the JWS and JW= E headers ARE important.

2.  No – Use c= ases where key information is exchanged by means other than the JWS and JWE= headers ARE NOT important.

 <= /p>

Maybe people could reply = with 1 and 2 as above, so that their answers to the question of whether the= se use cases are important are not are unambiguous.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.o= rg] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM
To: jose@ietf.org
Subject: [jose] Feedback request on jose tracker issue #15: Should a= t least on key indicator be mandatory

 

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring t= hat a key indicator, such as a “kid” field, be required in all = JWS and JWE headers. Are use cases where key information is exchanged by me= ans other than the JWS or JWE headers important?

Which of these best describes your preferences on this issue?=

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th (or earlier).

--_000_4E1F6AAD24975D4BA5B168042967394367615F37TK5EX14MBXC283r_-- From Axel.Nennker@telekom.de Thu Apr 11 23:12:39 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D721F877B for ; Thu, 11 Apr 2013 23:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CgKKLdgUocV for ; Thu, 11 Apr 2013 23:12:39 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39321F8691 for ; Thu, 11 Apr 2013 23:12:38 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 12 Apr 2013 08:12:34 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%14]) with mapi; Fri, 12 Apr 2013 08:12:34 +0200 From: To: , Date: Fri, 12 Apr 2013 08:12:31 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto Thread-Index: Ac43EvbX7ooddM85S2K5PB+a3Gvw+QAMb1Ug Message-ID: References: <51674E17.5020902@isoc.org> <35633DAD-58BB-42C3-86BE-81A0FA0402CB@gmail.com> In-Reply-To: <35633DAD-58BB-42C3-86BE-81A0FA0402CB@gmail.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16219HE111541eme_" MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 06:12:39 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16219HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Friday, April 12, 2013 2:16 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm id= entifiers/parameters incompatible with WebCrypto 1 On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue > wrote: Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that t= he JWA algorithm identifiers are different than those used by the W3C WebCr= ypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identi= fiers are strings, whereas the W3C WebCrypto algorithm identifiers are stru= ctures including string identifiers. The working group had previously deci= ded to continue representing JOSE algorithms as strings, as recorded at htt= p://www.ietf.org/mail-archive/web/jose/current/msg01219.html. Which of these best describes your preferences on this issue? 1. Continue have the JWA algorithm identifiers be strings, and not objects= . Note that WebCrypto may choose to use some of these same strings, where = applicable. 2. Switch to using the algorithm identifier structures defined in the WebC= rypto draft. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16219HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1

 

=

From: jose-bounces@ietf.org [mailto:jose-bounce= s@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, April 12= , 2013 2:16 AM
To: odonoghue@isoc.org
Cc: jose@ietf.org=
Subject: Re: [jose] Feedback request on jose tracker issue #7: A= lgorithm identifiers/parameters incompatible with WebCrypto

 

1

 

<= div>

On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue <= odonoghue@isoc.org> wrote:



Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out tha= t the JWA algorithm identifiers are different than those used by the W3C We= bCrypto draft at http://www.= w3.org/TR/WebCryptoAPI/.  The JWA algorithm identifiers are string= s, whereas the W3C WebCrypto algorithm identifiers are structures including= string identifiers.  The working group had previously decided to cont= inue representing JOSE algorithms as strings, as recorded at http://www.ie= tf.org/mail-archive/web/jose/current/msg01219.html.

<= /p>


Which of these best describes your preferences on this issue?=

1.  Continue have the JWA algorithm identifiers = be strings, and not objects.  Note that WebCrypto may choose to use so= me of these same strings, where applicable.

2.  S= witch to using the algorithm identifier structures defined in the WebCrypto= draft.

3.  Another resolution (please specify in= detail).

0.  I need more information to decide.<= o:p>

Your reply is requested by Friday, April 19th or earlier.

 

_______________________________________________
jose mailing listjose@ietf.org
https://www.ietf.org/mailman/listinfo/jo= se

 

= = --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16219HE111541eme_-- From Axel.Nennker@telekom.de Thu Apr 11 23:13:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3199321F8AA8 for ; Thu, 11 Apr 2013 23:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2abCA+TOhbE for ; Thu, 11 Apr 2013 23:13:48 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 37C7321F8A4F for ; Thu, 11 Apr 2013 23:13:47 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 12 Apr 2013 08:13:46 +0200 Received: from HE100018.emea1.cds.t-internal.com (10.125.65.199) by HE111527.EMEA1.CDS.T-INTERNAL.COM (10.125.90.86) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 12 Apr 2013 08:13:45 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE100018.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 12 Apr 2013 08:13:45 +0200 From: To: , Date: Fri, 12 Apr 2013 08:13:44 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: Ac43E2ss5aEtddY/SN6L2z1Hf+/jvQAMW/+A Message-ID: References: <51674E2D.3040604@isoc.org> <5BBEA8B4-A790-4AC9-A78F-CCA835850A35@gmail.com> In-Reply-To: <5BBEA8B4-A790-4AC9-A78F-CCA835850A35@gmail.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621AHE111541eme_" MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 06:13:50 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621AHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Friday, April 12, 2013 2:19 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? 3 On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue > wrote: Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding a= n "spi" (security parameters index) header parameter to the JWS and JWE spe= cifications. This modification to the JOSE formats would allow for signali= ng that pre-negotiated cryptographic parameters are being used, rather than= including those parameters in the JWS or JWE header. This proposal has be= en written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621AHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1

 

From: jose-bounces@ietf.org= [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent:<= /b> Friday, April 12, 2013 2:19 AM
To: odonoghue@isoc.org
C= c: jose@ietf.org
Subject: Re: [jose] Feedback request on jose= tracker issue #8: Should we add a "spi" header field?=

 

3

 

On Apr 11, 2013, at 4:58 PM, Karen O'Donogh= ue <odonoghue@isoc.org> wro= te:



Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes= adding an “spi” (security parameters index) header parameter t= o the JWS and JWE specifications.  This modification to the JOSE forma= ts would allow for signaling that pre-negotiated cryptographic parameters a= re being used, rather than including those parameters in the JWS or JWE hea= der.  This proposal has been written up as http://tools.ietf.org/html/draft-barne= s-jose-spi-00.

 

Which o= f these best describes your preferences on this issue?

1.  Have draft-barnes-jose-spi remain a separate specification that c= ould optionally also be supported by JWS and JWE implementations.

2.  Incorporate draft-barnes-jose-spi into the JWS and JWE= specifications as a mandatory feature.

3.  Incor= porate draft-barnes-jose-spi into the JWS and JWE specifications as an opti= onal feature.

4.  Another resolution (please spec= ify in detail).

0.  I need more information to de= cide.

Your reply is requested by Friday,= April 19th or earlier.

_______________________________________________
jose mailing list
<= a href=3D"mailto:jose@ietf.org">jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621AHE111541eme_-- From Axel.Nennker@telekom.de Thu Apr 11 23:15:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA321F8ACD for ; Thu, 11 Apr 2013 23:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH0t8JsgifJW for ; Thu, 11 Apr 2013 23:15:02 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id F401821F8AA8 for ; Thu, 11 Apr 2013 23:15:01 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 12 Apr 2013 08:15:00 +0200 Received: from HE100013.emea1.cds.t-internal.com (10.125.65.196) by HE113414.emea1.cds.t-internal.com (10.125.65.80) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 12 Apr 2013 08:15:00 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE100013.emea1.cds.t-internal.com ([2002:769:41c4::769:41c4]) with mapi; Fri, 12 Apr 2013 08:14:59 +0200 From: To: , Date: Fri, 12 Apr 2013 08:14:58 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: Ac43EIh1/Gy/W75BRgu5A6YmGwHVRgANIRjg Message-ID: References: <51674E3D.7030004@isoc.org> In-Reply-To: <51674E3D.7030004@isoc.org> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621CHE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 06:15:04 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621CHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Friday, April 12, 2013 1:59 AM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue#11: Should we use RF= C 5116 and remove the JWE Integrity Value field? Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restru= cturing the JWE representation to remove the JWE Integrity Value field and = instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphe= rtext, Initialization Vector, and Integrity Value values. If this proposal= is adopted, JWEs would then have three fields - the header, the encrypted = key, and the RFC 5116 combination of the Ciphertext, Initialization Vector,= and Integrity Value values. This issue is also related to issue #3. Note that the updated McGrew draft= described there could be used whether or not we switched to using RFC 5116= . Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the comb= ination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621CHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= 1

 =

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind= owtext'> jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Karen O'Donoghue
Sent: Friday, April 12, 2013 1:59 AM
<= b>To: jose@ietf.org
Subject: [jose] Feedback request on jose = tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value= field?

 

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11= proposes restructuring the JWE representation to remove the JWE Integr= ity Value field and instead use the RFC 5116 (AEAD) binary serialization to= represent the Ciphertext, Initialization Vector, and Integrity Value value= s.  If this proposal is adopted, JWEs would then have three fields = 211; the header, the encrypted key, and the RFC 5116 combination of the Cip= hertext, Initialization Vector, and Integrity Value values. 

This issue is also related to issue #3.  Note that the up= dated McGrew draft described there could be used whether or not we switched= to using RFC 5116.
 

Which of these best des= cribes your preferences on this issue?

1.  Contin= ue having separate Ciphertext, Initialization Vector, and Integrity Value v= alues in the JWE representation.

2.  Switch to = using the RFC 5116 (AEAD) serialization to represent the combination of the= se three values.

3.  Another resolution (please s= pecify in detail).

0.  I need more information to= decide.

 

You= r reply is requested by Friday, April 19th or earlier.

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF1621CHE111541eme_-- From Axel.Nennker@telekom.de Thu Apr 11 23:23:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2421F8A68 for ; Thu, 11 Apr 2013 23:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.081 X-Spam-Level: X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTKJXuy4zalM for ; Thu, 11 Apr 2013 23:23:42 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFFB21F8A38 for ; Thu, 11 Apr 2013 23:23:41 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 12 Apr 2013 08:23:40 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Fri, 12 Apr 2013 08:23:39 +0200 From: To: , Date: Fri, 12 Apr 2013 08:23:36 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: Ac43EJ+ImXSR2dOzS4mWTRvutlg73AANN2VQ Message-ID: References: <51674E63.3050809@isoc.org> In-Reply-To: <51674E63.3050809@isoc.org> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16243HE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 06:23:43 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16243HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please reissue this question. This is ambiguous. 1A: A key indicator SHOULD be included but can be omitted because use case= s where key information is exchanged by means other than the JWS or JWE hea= ders are important. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Friday, April 12, 2013 2:00 AM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19th (or earlier). --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16243HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Please reissue this question. This is ambiguous.

 

1A: A key indicator SHOULD  be included but can be omitted = because use cases where key information is exchanged by means other than th= e JWS or JWE headers are important.

 

From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Friday, = April 12, 2013 2:00 AM
To: jose@ietf.org
Subject: [jose= ] Feedback request on jose tracker issue #15: Should at least on key indica= tor be mandatory

 

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/= ticket/15. suggests requiring that a key indicator, such as a “ki= d” field, be required in all JWS and JWE headers. Are use cases where= key information is exchanged by means other than the JWS or JWE headers im= portant?

Which of these best describes your preferenc= es on this issue?

1.  Yes.

2= .   No.

0.  I need more information to= decide.

 

You= r reply is requested by Friday, April 19th (or earlier).

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16243HE111541eme_-- From Axel.Nennker@telekom.de Thu Apr 11 23:32:22 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8721F8540 for ; Thu, 11 Apr 2013 23:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mizdvgvOmo7U for ; Thu, 11 Apr 2013 23:32:19 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8290B21F8511 for ; Thu, 11 Apr 2013 23:32:18 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 12 Apr 2013 08:32:14 +0200 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE111528.EMEA1.CDS.T-INTERNAL.COM (10.125.90.87) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 12 Apr 2013 08:32:12 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113559.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 12 Apr 2013 08:32:12 +0200 From: To: , Date: Fri, 12 Apr 2013 08:32:10 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , Thread-Index: Ac43EJixGyODwcXYQ8aYWCdXOwfElQANn6tg Message-ID: References: <51674E58.6000505@isoc.org> In-Reply-To: <51674E58.6000505@isoc.org> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16251HE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 06:32:22 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16251HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 x5c is the most explicit way to describe which private key is the right one= . It is an alternative to kid which is another reason why kid must not be = mandatory. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Friday, April 12, 2013 1:59 AM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #12: Should the x5c = field be removed from JWE?, , Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removi= ng the "x5c" header parameter from JWE, saying that no use case for it has = emerged. The same logic may apply to other key specification parameters fo= r JWE. Which of these best describes your preferences on this issue? 1. Retain the "x5c" header parameter in JWE. 2. Remove the "x5c" header parameter (and possibly other related key speci= fication parameters) from JWE. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16251HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= 1

 =

x5c is the most explicit way to desc= ribe which private key is the right one. It is an alternative to kid which = is another reason why  kid must not be mandatory.

 

From: jose-bounces@ietf.or= g [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Friday, April 12, 2013 1:59 AM
To: jose@ietf.org
Subject: [jose] Feedback request on jose tracker issue #12: Should the= x5c field be removed from JWE?, ,

 

Issue #12 http://trac.tools.ie= tf.org/wg/jose/trac/ticket/12 suggests removing the “x5c” h= eader parameter from JWE, saying that no use case for it has emerged. = The same logic may apply to other key specification parameters for JWE.



Which of these best descr= ibes your preferences on this issue?

1.  Retain t= he “x5c” header parameter in JWE.

2. = Remove the “x5c” header parameter (and possibly other related = key specification parameters) from JWE.

3.  Anoth= er resolution (please specify in detail).

0.  I n= eed more information to decide.

 

<= p class=3DMsoNormal>Your reply is requested by Friday, April 19th or earlier.

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402553CF16251HE111541eme_-- From Michael.Jones@microsoft.com Sat Apr 13 11:48:33 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6F321F8D86 for ; Sat, 13 Apr 2013 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BcTBwtZd6hW for ; Sat, 13 Apr 2013 11:48:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6122921F8605 for ; Sat, 13 Apr 2013 11:48:30 -0700 (PDT) Received: from BN1AFFO11FD016.protection.gbl (10.58.52.202) by BN1AFFO11HUB008.protection.gbl (10.58.52.118) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sat, 13 Apr 2013 18:48:59 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD016.mail.protection.outlook.com (10.58.52.76) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sat, 13 Apr 2013 18:48:59 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Sat, 13 Apr 2013 18:47:29 +0000 From: Mike Jones To: Jim Schaad , Karen O'Donoghue Thread-Topic: Proposed Agenda for Interim Working Group Meeting Thread-Index: Ac44d1jWKgMVlUPqSZCKazcg+mJZHg== Date: Sat, 13 Apr 2013 18:47:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436761CA72@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436761CA72TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(4396001)(81542001)(54316002)(66066001)(81342001)(47976001)(49866001)(33656001)(80022001)(16406001)(53806001)(55846006)(31966008)(18277545001)(564824004)(54356001)(77982001)(46102001)(74502001)(76482001)(5343635001)(56816002)(56776001)(59766001)(15202345001)(18276755001)(74662001)(79102001)(51856001)(69226001)(5343655001)(71186001)(65816001)(20776003)(16236675001)(512954001)(47446002)(63696002)(50986001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB008; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0815F8251E Cc: "jose@ietf.org" Subject: [jose] Proposed Agenda for Interim Working Group Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 18:48:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436761CA72TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Knowing that we need to publish an agenda for the interim meeting soon, I t= hought I'd propose a starting point to kick off the agenda discussions. My= goal is to have us make the most progress possible towards resolving open = issues. -- Mike MONDAY, APRIL 29 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 9:00-9:30: Note Well, Introductions, Logistics, Goals, Day 1 Agenda Overvi= ew - Jim Schaad and Karen O'Donoghue 9:30-9:50: Overview of Recent changes to JWS, JWE, JWK, and JWA documents = - Mike Jones The goal of this brief session is for attendees to understan= d the changes made and issues addressed by those changes 9:50-10:05: Break 10:05-12:00: Existing Open Issues Session 1 The goal of this session, and the other open issues sessions= , is, for each issue to: - Identify possible resolutions - Determine support in the room for each of t= he resolutions - Determine what specific question(s) to ask = the working group on the list - Propose closure of the issue with a specifi= c resolution if consensus is apparent (with actual closure happening after confi= rming the consensus on the mailing list) - Issue #7: Algorithm identifiers/parameters incompatible w= ith WebCrypto - Issue #11: Should we use RFC 5116 and remove the JWE Inte= grity Value field? - Issue #12: Should the x5c field be removed from JWE? - Issue #15: Should at least one key indicator be mandatory= ? 12:00-12:45: Lunch 12:45-2:45: Existing Open Issues Session 2 - Presentation by Richard Barnes on draft-barnes-jose-key-wr= apping (assuming he's willing!) - Review by Matt Miller of draft-miller-jose-jwe-protected-j= wk (assuming he's willing!) - Issue #13: Enable AEAD key wrapping - Issue #14: Support longer wrapped keys than OAEP allows 2:45-3:05: Break 3:05-5:00: Existing Open Issues Session 3 - Issue #4: Remove wrapped keys from integrity check (allow= separation of keys from data) - Issue #9: Should we add a "spi" header field? - Issue #16: URI identifying a specific key in a JWK set - Issue #17: Add 'aud' and 'iss' to 4.1 Reserved Header Par= ameter Names - Issue #18: Address MAC key lifetime concerns - Issue #8: Direct mode for key agreement needs security an= alysis TUESDAY, APRIL 30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 9:00-9:20: Note Well, Day 2 Agenda Overview - Jim Schaad and Karen O'Donog= hue 9:20-10:20: W3C WebCrypto Coordination Discuss touch points between WebCrypto and JOSE and determin= e feedback to give WebCrypto 10:20-10:35: Break 10:35-11:15: Use Cases Discuss issues with the Use Cases specification and possible= changes needed 11:15-12:00: Next Steps Session 1 - Status of Key Wrapping Drafts Determine next steps for issues covered in draft-barnes-jose= -key-wrapping and draft-miller-jose-jwe-protected-jwk In particular, should either become WG drafts? 12:00-12:45: Lunch 12:45-1:45: Next Steps Session 2 - Discuss actions needed to bring JWS, JW= E, JWK, and JWA to Working Group Last Call The goal of this session is to determine specific steps need= ed to achieve WGLC and assign owners and timelines 1:45-2:45: Next Steps Session 3 - Polls and Consensus Calls Determine specific wording for polls and consensus calls nee= ded to gather input on remaining open issues 2:45-3:00: Break 3:00-3:20: Next Steps Session 4 - Next Meetings and Phone Calls Decide when our next meetings will be and at what times to s= chedule recurring WG phone calls 3:20-4:00: Summarize of Next Steps Review next steps, owners, and timelines for those steps to = occur 4:00-5:00: Other Topics This time is reserved to consider other issues or topics tha= t may arise --_000_4E1F6AAD24975D4BA5B16804296739436761CA72TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Knowing that we need to publish an agenda for the in= terim meeting soon, I thought I’d propose a starting point to kick of= f the agenda discussions.  My goal is to have us make the most progres= s possible towards resolving open issues.

 

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

 

MONDAY, APRIL 29

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

9:00-9:30:  Note Well, Introductions, Logistics= , Goals, Day 1 Agenda Overview – Jim Schaad and Karen O’Donoghu= e

9:30-9:50:  Overview of Recent changes to JWS, = JWE, JWK, and JWA documents – Mike Jones

        &nbs= p;      The goal of this brief session is for atte= ndees to understand the changes made and issues addressed by those changes<= o:p>

9:50-10:05:  Break

10:05-12:00:  Existing Open Issues Session 1

        &nbs= p;      The goal of this session, and the other op= en issues sessions, is, for each issue to:

        &nbs= p;            &= nbsp;        - Identify possible resolut= ions

        &nbs= p;            &= nbsp;        - Determine support in the = room for each of the resolutions

        &nbs= p;            &= nbsp;        - Determine what specific q= uestion(s) to ask the working group on the list

        &nbs= p;            &= nbsp;        - Propose closure of the is= sue with a specific resolution if consensus is apparent

        &nbs= p;            &= nbsp;           (with actual c= losure happening after confirming the consensus on the mailing list)

        &nbs= p;      - Issue #7:  Algorithm identifiers/parameters incompatible with WebCrypto=

    =            - Issue #11:  Should we use RFC 5116 and remove the JWE Integ= rity Value field?

    =            - Issue= #12:  Should the x5c field be removed from JWE?

        &nbs= p;      - Issue #15:  Should at least one key indicator be mandatory?

12:00-12:45:  Lunch

12:45-2:45:  Existing Open Issues Session 2

        &nbs= p;      - Presentation by Richard Barnes on draft-= barnes-jose-key-wrapping (assuming he’s willing!)

        &nbs= p;      - Review by Matt Miller of draft-miller-jo= se-jwe-protected-jwk (assuming he’s willing!)

    =            - Issue #13:&n= bsp; Enable AEAD key wrapping

    =            - Issue #14:&n= bsp; Support longer wrapped keys than OAEP allows

2:45-3:05:  Break

3:05-5:00:  Existing Open Issues Session 3=

    =            - Issue #4:&nb= sp; Remove wrapped keys from integrity check (allow separation of keys from= data)

    =            - Issue= #9:  Should we add a "spi" header field?

    =            - Issue #16:&n= bsp; URI identifying a specific key in a JWK set

    =            - Issue #17:&n= bsp; Add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names<= /span>

    =            - Issue #18:&n= bsp; Address MAC key lifetime concerns

    =            - Issue #8:&nb= sp; Direct mode for key agreement needs security analysis=

 

TUESDAY, APRIL 30

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

9:00-9:20:  Note Well, Day 2 Agenda Overview &#= 8211; Jim Schaad and Karen O’Donoghue

9:20-10:20:  W3C WebCrypto Coordination

        &nbs= p;      Discuss touch points between WebCrypto and= JOSE and determine feedback to give WebCrypto

10:20-10:35:  Break

10:35-11:15:  Use Cases

        &nbs= p;      Discuss issues with the Use Cases specific= ation and possible changes needed

11:15-12:00:  Next Steps Session 1 – Stat= us of Key Wrapping Drafts

        &nbs= p;      Determine next steps for issues covered in= draft-barnes-jose-key-wrapping and draft-miller-jose-jwe-protected-jwk

        &nbs= p;      In particular, should either become WG dra= fts?

12:00-12:45:  Lunch

12:45-1:45:  Next Steps Session 2 – Discu= ss actions needed to bring JWS, JWE, JWK, and JWA to Working Group Last Cal= l

        &nbs= p;      The goal of this session is to determine s= pecific steps needed to achieve WGLC and assign owners and timelines

1:45-2:45:  Next Steps Session 3 – Polls = and Consensus Calls

        &nbs= p;      Determine specific wording for polls and c= onsensus calls needed to gather input on remaining open issues

2:45-3:00:  Break

3:00-3:20:  Next Steps Session 4 – Next M= eetings and Phone Calls

        &nbs= p;      Decide when our next meetings will be and = at what times to schedule recurring WG phone calls

3:20-4:00:  Summarize of Next Steps<= /p>

        &nbs= p;      Review next steps, owners, and timelines f= or those steps to occur

4:00-5:00:  Other Topics

        &nbs= p;      This time is reserved to consider other is= sues or topics that may arise

 

--_000_4E1F6AAD24975D4BA5B16804296739436761CA72TK5EX14MBXC283r_-- From roland.hedberg@adm.umu.se Sat Apr 13 12:17:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C321F8E62 for ; Sat, 13 Apr 2013 12:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Om8QdJzgEk for ; Sat, 13 Apr 2013 12:17:06 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch1.ad.umu.se [130.239.1.246]) by ietfa.amsl.com (Postfix) with ESMTP id 1188C21F8E59 for ; Sat, 13 Apr 2013 12:17:05 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.1.121]) by UMDAC-CH1.ad.umu.se ([130.239.1.246]) with mapi; Sat, 13 Apr 2013 21:16:28 +0200 From: Roland Hedberg To: "odonoghue@isoc.org" Date: Sat, 13 Apr 2013 21:17:03 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto Thread-Index: Ac44e2V7Wo7109PlQwm64YIiynv90w== Message-ID: <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> References: <51674E17.5020902@isoc.org> In-Reply-To: <51674E17.5020902@isoc.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 19:17:06 -0000 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that= the JWA algorithm identifiers are different than those used by the W3C Web= Crypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm iden= tifiers are strings, whereas the W3C WebCrypto algorithm identifiers are st= ructures including string identifiers. The working group had previously de= cided to continue representing JOSE algorithms as strings, as recorded at h= ttp://www.ietf.org/mail-archive/web/jose/current/msg01219.html. >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue have the JWA algorithm identifiers be strings, and not objec= ts. Note that WebCrypto may choose to use some of these same strings, wher= e applicable. >=20 > 2. Switch to using the algorithm identifier structures defined in the We= bCrypto draft. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From roland.hedberg@adm.umu.se Sat Apr 13 12:19:34 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484D621F8E8E for ; Sat, 13 Apr 2013 12:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1LjwrAko4QW for ; Sat, 13 Apr 2013 12:19:33 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch2.ad.umu.se [130.239.1.247]) by ietfa.amsl.com (Postfix) with ESMTP id E6C5F21F8E6D for ; Sat, 13 Apr 2013 12:19:17 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.1.121]) by UMDAC-CH2.ad.umu.se ([130.239.1.247]) with mapi; Sat, 13 Apr 2013 21:18:26 +0200 From: Roland Hedberg To: "odonoghue@isoc.org" Date: Sat, 13 Apr 2013 21:19:03 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: Ac44e6ypF+sL5MyOQAed3Rlf+wrAbQ== Message-ID: <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> References: <51674E3D.7030004@isoc.org> In-Reply-To: <51674E3D.7030004@isoc.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 19:19:34 -0000 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes rest= ructuring the JWE representation to remove the JWE Integrity Value field an= d instead use the RFC 5116 (AEAD) binary serialization to represent the Cip= hertext, Initialization Vector, and Integrity Value values. If this propos= al is adopted, JWEs would then have three fields =96 the header, the encryp= ted key, and the RFC 5116 combination of the Ciphertext, Initialization Vec= tor, and Integrity Value values.=20 > This issue is also related to issue #3. Note that the updated McGrew dra= ft described there could be used whether or not we switched to using RFC 51= 16. > =20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue having separate Ciphertext, Initialization Vector, and Integ= rity Value values in the JWE representation. >=20 > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the co= mbination of these three values. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > =20 >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From roland.hedberg@adm.umu.se Sat Apr 13 12:20:24 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6013C21F8E59 for ; Sat, 13 Apr 2013 12:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdD8cqqOjiHd for ; Sat, 13 Apr 2013 12:20:23 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch2.ad.umu.se [130.239.1.247]) by ietfa.amsl.com (Postfix) with ESMTP id D88D621F8BF8 for ; Sat, 13 Apr 2013 12:20:22 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.1.121]) by UMDAC-CH2.ad.umu.se ([130.239.1.247]) with mapi; Sat, 13 Apr 2013 21:19:47 +0200 From: Roland Hedberg To: "odonoghue@isoc.org" Date: Sat, 13 Apr 2013 21:20:22 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , Thread-Index: Ac44e9v5UHJq1z01S4aE5tGEP+aPYQ== Message-ID: <897FE510-0FC4-4061-9FA4-52E248B451E3@adm.umu.se> References: <51674E58.6000505@isoc.org> In-Reply-To: <51674E58.6000505@isoc.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 19:20:24 -0000 1 12 apr 2013 kl. 01:59 skrev Karen O'Donoghue : > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests remo= ving the =93x5c=94 header parameter from JWE, saying that no use case for i= t has emerged. The same logic may apply to other key specification paramet= ers for JWE. >=20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Retain the =93x5c=94 header parameter in JWE. >=20 > 2. Remove the =93x5c=94 header parameter (and possibly other related key= specification parameters) from JWE. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > =20 >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From roland.hedberg@adm.umu.se Sat Apr 13 12:22:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543A921F8E6E for ; Sat, 13 Apr 2013 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkPK3mjOo3TM for ; Sat, 13 Apr 2013 12:22:08 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch2.ad.umu.se [130.239.1.247]) by ietfa.amsl.com (Postfix) with ESMTP id 4F67421F8E6D for ; Sat, 13 Apr 2013 12:22:08 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.1.121]) by UMDAC-CH2.ad.umu.se ([130.239.1.247]) with mapi; Sat, 13 Apr 2013 21:21:32 +0200 From: Roland Hedberg To: "Axel.Nennker@telekom.de" Date: Sat, 13 Apr 2013 21:22:08 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , Thread-Index: Ac44fBsxmCQD++o1QbWrNL68mMR05A== Message-ID: <4E289D7B-BB53-412A-AE3F-8CD08E45205A@adm.umu.se> References: <51674E58.6000505@isoc.org> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 19:22:09 -0000 +1 12 apr 2013 kl. 08:32 skrev Axel.Nennker@telekom.de: > 1 > =20 > x5c is the most explicit way to describe which private key is the right o= ne. It is an alternative to kid which is another reason why kid must not b= e mandatory. > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of K= aren O'Donoghue > Sent: Friday, April 12, 2013 1:59 AM > To: jose@ietf.org > Subject: [jose] Feedback request on jose tracker issue #12: Should the x5= c field be removed from JWE?, , > =20 > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests remo= ving the =93x5c=94 header parameter from JWE, saying that no use case for i= t has emerged. The same logic may apply to other key specification paramet= ers for JWE. >=20 >=20 > Which of these best describes your preferences on this issue? > 1. Retain the =93x5c=94 header parameter in JWE. > 2. Remove the =93x5c=94 header parameter (and possibly other related key= specification parameters) from JWE. > 3. Another resolution (please specify in detail). > 0. I need more information to decide. > =20 > Your reply is requested by Friday, April 19th or earlier. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From roland.hedberg@adm.umu.se Sun Apr 14 01:33:24 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264BE21F8F6E for ; Sun, 14 Apr 2013 01:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBNSiy8gG8oA for ; Sun, 14 Apr 2013 01:33:23 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch2.ad.umu.se [130.239.1.247]) by ietfa.amsl.com (Postfix) with ESMTP id 57EEB21F8ED6 for ; Sun, 14 Apr 2013 01:33:22 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.1.121]) by UMDAC-CH2.ad.umu.se ([130.239.1.247]) with mapi; Sun, 14 Apr 2013 10:32:37 +0200 From: Roland Hedberg To: "odonoghue@isoc.org" Date: Sun, 14 Apr 2013 10:33:13 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: Ac446p6csLz+RpQVTSKOBZZPMKMq8Q== Message-ID: References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 08:33:24 -0000 I support 1 as defined by Mike. 12 apr 2013 kl. 07:25 skrev Mike Jones : > 1. Yes =96 Use cases where key information is exchanged by means other t= han the JWS and JWE headers ARE important -- Roland= From roland.hedberg@adm.umu.se Sun Apr 14 01:34:37 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAC221F8F76 for ; Sun, 14 Apr 2013 01:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ5eTBKP43Q0 for ; Sun, 14 Apr 2013 01:34:37 -0700 (PDT) Received: from mail.ad.umu.se (umdac-ch1.ad.umu.se [130.239.1.246]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6EC21F8F6E for ; Sun, 14 Apr 2013 01:34:35 -0700 (PDT) Received: from UMDAC-CCR1.ad.umu.se ([169.254.1.121]) by UMDAC-CH1.ad.umu.se ([130.239.1.246]) with mapi; Sun, 14 Apr 2013 10:33:59 +0200 From: Roland Hedberg To: "odonoghue@isoc.org" Date: Sun, 14 Apr 2013 10:34:33 +0200 Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: Ac446s7vqPLohDG6TMqFqCxxF18upA== Message-ID: References: <51674E2D.3040604@isoc.org> In-Reply-To: <51674E2D.3040604@isoc.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 08:34:37 -0000 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : > Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding= an =93spi=94 (security parameters index) header parameter to the JWS and J= WE specifications. This modification to the JOSE formats would allow for s= ignaling that pre-negotiated cryptographic parameters are being used, rathe= r than including those parameters in the JWS or JWE header. This proposal = has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. > =20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Have draft-barnes-jose-spi remain a separate specification that could= optionally also be supported by JWS and JWE implementations. >=20 > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications= as a mandatory feature. >=20 > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications= as an optional feature. >=20 > 4. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sun Apr 14 17:35:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F021F8EAC for ; Sun, 14 Apr 2013 17:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGlmWg92FBRw for ; Sun, 14 Apr 2013 17:35:07 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5721F8CEC for ; Sun, 14 Apr 2013 17:35:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,472,1363093200"; d="scan'208";a="123885177" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 15 Apr 2013 10:35:05 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7045"; a="75801493" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 15 Apr 2013 10:35:05 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 15 Apr 2013 10:35:05 +1000 From: "Manger, James H" To: jose issue tracker , "draft-ietf-jose-json-web-key@tools.ietf.org" , "ietf@augustcellars.com" Date: Mon, 15 Apr 2013 10:35:04 +1000 Thread-Topic: [jose] #16: URI identifying a specific key in a JWK set Thread-Index: Ac4xU15fNfmsQ7yYSqO2+X7moy0zYgHux8yg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C74DB3E@WSMSG3153V.srv.dir.telstra.com> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <073.1dc661959a15caad46917baec89b3440@trac.tools.ietf.org> In-Reply-To: <073.1dc661959a15caad46917baec89b3440@trac.tools.ietf.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 00:35:08 -0000 PiAjMTY6IFVSSSBpZGVudGlmeWluZyBhIHNwZWNpZmljIGtleSBpbiBhIEpXSyBzZXQNCj4+IGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMTYNCg0KPiAgSW4g b3JkZXIgdG8gZXZhbHVhdGUgdGhpcywgd2UgbmVlZCB0byBnZXQgYSBtb3JlIGRldGFpbGVkIHBy b3Bvc2FsDQoNCkJlbG93IGlzIGEgbW9yZSBkZXRhaWxlZCBwcm9wb3NhbC4gVGhlIGJhc2ljIGlk ZWEgaXMgdG8gbWFrZSB0aGUgSldLIGtleSBzZXQgc3ludGF4IGEgYml0IG1vcmUgc2Vuc2libGUg KGtleXMgbmFtZWQgYnkgdGhlaXIgaWRzOyBpbnN0ZWFkIG9mIGEgImtleXMiIGVsZW1lbnQgaG9s ZGluZyBhbiBhcnJheSBvZiBrZXlzKTsgZ2l2ZSBrZXkgc2V0cyBhIG1lZGlhIHR5cGU7IGFuZCBk ZWZpbmUgdGhlIGZyYWdtZW50IHRvIGJlIGEgSlNPTiBwb2ludGVyIFtSRkMgNjkwMV0uIFRoZW4g YSBVUkkgY2FuIGlkZW50aWZ5IGEgc3BlY2lmaWMga2V5LiBBICJqa3UiIHZhbHVlIGNhbiBwcmVj aXNlbHkgaW5kaWNhdGUgdGhlIGtleSBuZWVkZWQgdG8gcHJvY2VzcyBhIEpPU0UgbWVzc2FnZSwg ZWcgImprdSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vYWxpY2Uua2V5cyMvazEiLg0KDQoNCj4gIDEu ICBTeW50YXggb2YgdGhlIGZyYWdtZW50DQoNClRoZSBmcmFnbWVudCwgaWYgcHJlc2VudCwgaWRl bnRpZmllcyBhIHNwZWNpZmljIGtleSBpbiB0aGUgSldLIGtleSBzZXQuDQoNClRoZSBmcmFnbWVu dCBTSEFMTCBiZSBhIEpTT04gUG9pbnRlciBbUkZDIDY5MDFdLCBwb2ludGluZyB0byB0aGUgSlNP TiBvYmplY3QgaG9sZGluZyB0aGUgc3BlY2lmaWMga2V5IG9mIGludGVyZXN0IHdpdGhpbiB0aGUg c2V0IG9mIGtleXMuDQoNClRoZSBmcmFnbWVudCBTSEFMTCBiZSBhICIvIiBjaGFyYWN0ZXIgZm9s bG93ZWQgYnkgdGhlIGtleSBpZGVudGlmaWVyICgia2lkIiB2YWx1ZSkgZm9yIHRoZSBzcGVjaWZp YyBrZXkuDQoNCltUaGlzIGltcGxpZXMgdGhlIHRvcC1sZXZlbCBzdHJ1Y3R1cmUgb2YgYSBKV0sg a2V5IHNldCBpcyBjaGFuZ2VkIHRvIGJlIGEgSlNPTiBvYmplY3Qgd2hvc2UgZWxlbWVudHMgYXJl IGluZGl2aWR1YWwga2V5cy4gQW4gZWxlbWVudCdzIG5hbWUgaXMgdGhlIGlkZW50aWZpZXIgb2Yg dGhlIGtleSAoImtpZCIgdmFsdWUpOyBhbiBlbGVtZW50J3MgdmFsdWUgaXMgYSBzaW5nbGUgSldL IG9iamVjdC4gT25lIGVsZW1lbnQgKG5hbWVkICJtZXRhIikgaXMgc3BlY2lhbDogaXQgaXMgbm90 IGEgImtpZCIgdmFsdWUsIGJ1dCBhIHBsYWNlIHRvIGhvbGQgYW55IG1ldGFkYXRhIGFib3V0IHRo ZSB3aG9sZSBzZXQgb2Yga2V5cy4NCg0KRXhhbXBsZToNCiAgew0KICAgICJrMSIgOiB7Imt0eSI6 IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjrigKYsInkiOuKApn0sDQogICAgIDIwMTEtMDQtMjkiIDog eyJrdHkiOlJTQSIsIm4iOuKApiwiZSI6IkFRQUIifQ0KICB9DQpdDQoNCg0KPiAgMi4gIGRlYWxp bmcgd2l0aCBkdXBsaWNhdGUgdmFsdWVzIHdpdGhpbiBhIEpXSyBzdHJ1Y3R1cmUNCg0KSSdtIG5v dCBzdXJlIHdoYXQgdGhpcyBpc3N1ZSBpcy4gSSBzdXNwZWN0IGl0IGlzIHNvbHZlZCBieSBzdG9y aW5nIGtleXMgYXMgb2JqZWN0IGVsZW1lbnRzIGFzIG9wcG9zZWQgdG8gYXJyYXkgaXRlbXMuDQoN Cj4gIDMuICBEZWZpbml0aW9uIG9mIGEgbmV3IG1lZGlhIHR5cGUgLSBpcyB0aGlzIHJlcXVpcmVk IG9yIG5vdCAtIGp1c3RpZnkNCj4gIGVpdGhlciBwb3N0aW9uDQoNClRoZSBKV0sgc3BlYyBzaG91 bGQgZGVmaW5lIGEgbWVkaWEgdHlwZSwgc3VjaCBhcyBhcHBsaWNhdGlvbi9rZXlzK2pzb24uDQpG cmFnbWVudHMgYXJlIHNwZWNpZmljIHRvIGEgbWVkaWEgdHlwZSBzbyBhIG1lZGlhIHR5cGUgbmVl ZHMgdG8gYmUgZGVmaW5lZC4NCg0KPiAgNC4gIEV4cGxhaW4gd2h5IHRoZSBwcm9wb3NhbCBpcyAi YmV0dGVyIiB0aGFuIHRoZSBjdXJyZW50IGFiaWxpdHkgdG8NCj4gaGF2ZSBhIHVybCBwbHVzIHRo ZSBraWQgaW4gdGhlIG1lc3NhZ2UuDQoNClRoZSB3aG9sZSBjb25jZXB0IG9mIGEgVVJJIGlzIHRv IGJlIGFuIGlkZW50aWZpZXIgaXRzZWxmIChub3QganVzdCB3aGVuIGNvbWJpbmVkIHdpdGggYSBz ZWNvbmQgZmllbGQpLiBNYW55LCBtYW55IHN5c3RlbXMgYW5kIHByb3RvY29scyB0aGF0IHN1cHBv cnQgVVJJcyBhc3N1bWUgdGhhdCB0aGUgVVJJIGFsb25lIGlzIHN1ZmZpY2llbnQgdG8gaWRlbnRp ZnkgdGhlIGl0ZW0gb2YgaW50ZXJlc3QuDQpJdCBzaW1wbGlmaWVzIEFQSXMgYW5kIHByb3RvY29s czoganVzdCBwYXNzIDEgdmFsdWUuDQoNCj4gIDUuICBEaXNjdXNzIHdoYXQgaGFwcGVucyBpZiB0 aGUgZnJhZ21lbnQgaXMgbm90IHByZXNlbnQgb24gdGhlIHVybA0KDQpUaGUgc3BlY3Mgc2hvdWxk IGJlIHdyaXR0ZW4gc28gdGhhdCBpZiB0aGVyZSBpcyBubyBmcmFnbWVudCBidXQgdGhlcmUgaXMg b25seSAxIGtleSBpbiB0aGUgaWRlbnRpZmllZCBKV0sga2V5IHNldCwgdGhlbiB0aGluZ3Mgc3Rp bGwgd29yay4NCg0KSSBzdWdnZXN0IHNheWluZyBhICpjcmVhdG9yKiBvZiBhICJqa3UiIFVSSSB2 YWx1ZSAodG8gaWRlbnRpZnkgdGhlIHNwZWNpZmljIGtleSByZXF1aXJlZCB0byBwcm9jZXNzIGEg Sk9TRSBtZXNzYWdlKSBNVVNUIGluY2x1ZGUgYSBmcmFnbWVudCB0byBpZGVudGlmeSBhIHNpbmds ZSBrZXkuIFdoZW4gYSBrZXkgc2V0IGhhcyBvbmx5IDEga2V5LCBhICpyZWNlaXZlciogTVVTVCBh Y2NlcHQgYSAiamt1IiBVUkkgYXMgYW4gaWRlbnRpZmllciBvZiB0aGF0IDEga2V5IGV2ZW4gaWYg dGhlIFVSSSBoYXMgbm8gZnJhZ21lbnQuDQoNCj4gb3IgaWYgdGhlIGZyYWdtZW50IGlzIG5vdCBm aW5kYWJsZSBpbiB0aGUgcmVzdWx0YW50IGRvY3VtZW50Lg0KDQpUaGVuIHRoZSBVUkkgaWRlbnRp ZmllcyBhIGtleSB0aGF0IGlzIG5vdCBwcmVzZW50IHNvIGFuIGVycm9yIHJlc3VsdHMgKHNpbWls YXIgdG8gZ2V0dGluZyBhIDQwNCBOb3QgRm91bmQgZm9yIHRoZSB3aG9sZSBrZXkgc2V0KS4NCg0K PiAgSWYgdGhlIGZyYWdtZW50DQo+ICBpcyBnb2luZyB0byBiZSBtYW5kaXRvcnkgZG9lcyB0aGVt IG1lYW4gdGhhdCB3ZSBzaG91bGQgYmUgZG9pbmcgYSBuZXcNCj4gIHNjaGVtZSBpbnN0ZWFkIGFz IGZyYWdtZW50cyBjYW5ub3QgYmUgcmVxdWlyZWQgdW5kZXIgdGhlIGN1cnJlbnQgVVJMDQo+ICBz eW50YXggZGVmaW50aW9ucyAob3IgYXQgbGVhc3QgdGhhdCBpcyBteSByZWFkaW5nKS4NCg0KRGVm aW5pdGVseSBubyBuZXcgVVJJIHNjaGVtZS4NCkEgVVJJIHdpdGhvdXQgYSBmcmFnbWVudCBpcyBz dGlsbCBhIHZhbGlkIFVSSS4gVGhhdCBkb2Vzbid0IHN0b3AgdXMgc2F5aW5nIGEgImprdSIgVVJJ IHZhbHVlIE1VU1QgY29udGFpbiBhIGZyYWdtZW50Lg0KDQo+ICBQbGVhc2UgZmxlc2ggb3V0IHlv dXIgcHJvcG9zYWwgbW9yZSBzbyB0aGF0IGl0IGNhbiBiZSBmdWxseSBldmFsdWF0ZWQuDQoNCkkg aG9wZSB0aGlzIGVtYWlsIGhhcyBmbGVzaGVkIG91dCBhIHByb3Bvc2FsIHN1ZmZpY2llbnRseS4N Cg0KLS0NCkphbWVzIE1hbmdlcg0K From James.H.Manger@team.telstra.com Sun Apr 14 18:55:39 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5911621F92C2 for ; Sun, 14 Apr 2013 18:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL+Fdw7xAAQS for ; Sun, 14 Apr 2013 18:55:38 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 514E221F92BD for ; Sun, 14 Apr 2013 18:55:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,472,1363093200"; d="scan'208";a="129445907" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 15 Apr 2013 11:55:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7045"; a="125367304" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Apr 2013 11:55:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 15 Apr 2013 11:55:36 +1000 From: "Manger, James H" To: "cfrg@irtf.org" , "jose@ietf.org" Date: Mon, 15 Apr 2013 11:55:34 +1000 Thread-Topic: [jose] [Cfrg] GCM nonce reuse question Thread-Index: Ac4vy0pZp5NcBv21Sdau+wVKi4QJGQJp0EiA Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com> <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com> <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> In-Reply-To: <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] [Cfrg] GCM nonce reuse question X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 01:55:39 -0000 SSB0aGluayB0aGVyZSBhcmUgbW9yZSBvcHRpb25zIGZvciBoYW5kbGluZyBtdWx0aXBsZSByZWNp cGllbnRzIG9mIEFFQUQtc2VjdXJlZCBjb250ZW50Og0KDQoNCk9wdGlvbiAzOiBQdXQgYWxsIHBl ci1yZWNpcGllbnQgaW5mbyBpbnRvIG9uZSBoZWFkZXI7IGtlZXAgdGhpcyBoZWFkZXIgdW5kZXIg dGhlIEFFQUQgaW50ZWdyaXR5IGNoZWNrOyBoYXZlIG9uZSBub25jZS4NCiAgQ09TVDogQWxsIHJl Y2lwaWVudHMgbmVlZCB0byBiZSBrbm93biAoYW5kIHRoZWlyIGtleSBleGNoYW5nZSBpbmZvIGNy ZWF0ZWQpIGJlZm9yZSB0aGUgQUVBRCBhbGdvcml0aG0gaXMgYXBwbGllZC4NCiAgQ09TVDogVGhl IEpXRSBKU09OIGhlYWRlciBzdHJ1Y3R1cmUgbmVlZHMgdG8gYmUgYWRqdXN0ZWQgKGVnIHRvIGhh dmUgYW4gYXJyYXkgb2YgcmVjaXBpZW50IGluZm8pIHNvIGl0IGlzIG5vdCBiYWNrd2FyZCBjb21w YXRpYmxlIHdpdGggY3VycmVudCBkcmFmdHMuDQogIENPU1Q6IERvZXNuJ3QgaGVscCB1c2UgY2Fz ZXMgd2hlcmUgb25lIHJlY2lwaWVudCBmb3J3YXJkcyBhbiBBRUFELXNlY3VyZWQgbWVzc2FnZSBv biB0byBhIG5ldyByZWNpcGllbnQgKGVnIGFuIFhNUFAgc3lzdGVtIHJlY2VpdmVzIGEgbWVzc2Fn ZSBzZWN1cmVkIGZvciBhIHVzZXIgYW5kIHJlLXNlY3VyZXMgaXQgZm9yIGEgc3BlY2lmaWMgZGV2 aWNlIG9mIHRoYXQgdXNlcikuIENoYW5naW5nIHJlY2lwaWVudHMgcmVxdWlyZXMgcmVhcHBseWlu ZyB0aGUgQUVBRCBvcGVyYXRpb25zLg0KICBDT1NUOiBFYWNoIHJlY2lwaWVudCBuZWVkcyB0byBz ZWUga2V5IGV4Y2hhbmdlIGluZm8gb2YgYWxsIHJlY2lwaWVudHMgKHByaXZhY3kgaW1wYWN0Pyku DQogIFBPU1NJQkxFLUJFTkVGSVQ6IFJlY2lwaWVudHMsIGtleSBleGNoYW5nZXMsIHBhcmFtZXRl cnMsIGFuZCBjb250ZW50IGlzIHNlY3VyZWQgYXMgYSBjb21wbGV0ZSB1bml0Lg0KIA0KDQpPcHRp b24gMmI6IFJlbW92ZSBwZXItcmVjaXBpZW50IGluZm8gZnJvbSBBRUFEIGludGVncml0eSBjaGVj azsgYnV0IGFkZCBBRUFEIGRldGFpbHMgdG8gZWFjaCBrZXkgZXhjaGFuZ2UuIEZvciBpbnN0YW5j ZSwgaW5mbyBhYm91dCBhbiBBRUFEIG9wZXJhdGlvbiAoYWxnIGlkLCBrZXkgaWQgZXRjKSBwb3Rl bnRpYWxseSBldmVuIGluY2x1ZGluZyB0aGUgd2hvbGUgY2lwaGVydGV4dCBpcyB1c2VkIGFzIHRo ZSAibGFiZWwiIGZvciB0aGUgUlNBRVMtT0FFUC1FTkNSWVBUIG9wZXJhdGlvbiB0aGF0IGVuY3J5 cHRzIHRoZSBBRUFEIHNlY3JldCBrZXkgZm9yIGEgcmVjaXBpZW50Lg0KICBCRU5FRklUOiBUaGUg a2V5IGV4Y2hhbmdlIGlzIHRpZWQgdG8gYSBzcGVjaWZpYyBBRUFEIG9wZXJhdGlvbi4NCiAgQ09T VDogQ3J5cHRvIGlzIG5vdCB0eXBpY2FsbHkgZG9uZSBsaWtlIHRoaXM7IHVuY2VydGFpbiBhcyB0 byB3aGF0IGV4YWN0IHNlY3VyaXR5IHByb3BlcnRpZXMgeW91IGFyZSBnZXR0aW5nLiBQZXJoYXBz IHRoZXJlIGFyZSBzb21lIHNpbWlsYXJpdGllcyB0byBOSVNUIENvbmNhdCBLREYgdGhhdCBhZGRz ICJjb250ZXh0IiB0byBrZXkgZGVyaXZhdGlvbjogdGhpcyBhZGRzICJjb250ZXh0IiBhYm91dCBh biBBRUFEIG9wZXJhdGlvbiB0byB0aGUga2V5IGV4Y2hhbmdlLg0KDQoNCkkgYWdyZWUgd2l0aCBS aWNoYXJkIEJhcm5lcyB0aGF0IHRoZSBwZXItcmVjaXBpZW50IGtleSBleGNoYW5nZSBkZXRhaWxz IHNob3VsZCBiZSBvdXRzaWRlIHRoZSBBRUFEIG9wZXJhdGlvbiAobm90IGNvdmVyZWQgYnkgdGhl IEFFQUQgaW50ZWdyaXR5IGNoZWNrKS4gR28gd2l0aCBvcHRpb24gMiBvciAyYi4NClRoZW4sIHNl cGFyYXRlbHksIHdlIGNhbiBkZWNpZGUgd2hpY2ggZGV0YWlscyBvZiB0aGUgQUVBRCBvcGVyYXRp b24gc2hvdWxkIGJlIGJvdW5kIHRvIGVhY2gga2V5IGV4Y2hhbmdlOiBub25lPyBBRUFEIGtleSBs ZW5ndGg/IEFFQUQgYWxnIGlkPyB3aG9sZSBBRUFEIGhlYWRlcj8gQUVBRCBjaXBoZXJ0ZXh0PyBv dGhlciBjb250ZXh0Pw0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KPiAtLS0tLS0tLS0tDQo+IEZy b206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IFJpY2hhcmQgQmFybmVzDQo+IFNlbnQ6IFdlZG5lc2RheSwgMyBBcHJp bCAyMDEzIDQ6NTUgQU0NCj4g4oCmIA0KPiBUaGUgcHJvYmxlbSBoZXJlIGlzIEpXRSwgc3BlY2lm aWNhbGx5IHRoZSBmYWN0IHRoYXQgdGhlIGhlYWRlciAod2l0aA0KPiBwZXItcmVjaXBpZW50IGRh dGEpIGlzIGNvdmVyZWQgYnkgdGhlIGludGVncml0eSBjaGVjay4gIElmIHlvdSByZW1vdmUNCj4g dGhlIHBlci1yZWNpcGllbnQgZGF0YSBmcm9tIHRoZSBpbnRlZ3JpdHkgY2hlY2ssIHRoZW4gdGhp cyBwcm9ibGVtIGdvZXMNCj4gYXdheS4gIEluIHRoYXQgY2FzZSwgdGhlcmUgaXMgb25seSBvbmUg aW52b2NhdGlvbiBvZiBHQ00gKG5vdCBvbmUgcGVyDQo+IHJlY2lwaWVudCksIHNvIHRoZXJlJ3Mg bm8gcHJvYmxlbS4NCj4gDQo+IFNvIHRoZSBjaG9pY2UgdGhhdCBKT1NFIGZhY2VzIGlzIGZyb20g dGhlIGZvbGxvd2luZyBvcHRpb25zOg0KPiANCj4gT3B0aW9uIDAuIE91dGxhdyBHQ00gZm9yIG11 bHRpcGxlIHJlY2lwaWVudHMuDQo+ICAgQ09TVDogR0NNDQo+IA0KPiBPcHRpb24gMS4gS2VlcCBw ZXItcmVjaXBpZW50IGluZm8gdW5kZXIgaW50ZWdyaXR5IGNoZWNrLCBhbmQgcmVxdWlyZSBhDQo+ IGZyZXNoIG5vbmNlIGZvciBlYWNoIHJlY2lwaWVudA0KPiAgIENPU1Q6IFJlbW92ZXMgYWxsIHNh dmluZ3MgaW4gdGhlIG11bHRpcGxlIHJlY2lwaWVudCBjYXNlDQo+ICAgQkVORUZJVDogRG9lc24n dCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggY3VycmVudCwgc2luZ2xlLQ0KPiBy ZWNpcGllbnQgSldFDQo+IA0KPiBPcHRpb24gMi4gUmVtb3ZlIHBlci1yZWNpcGllbnQgaW5mbyBm cm9tIGludGVncml0eSBjaGVjaw0KPiAgIENPU1Q6IEJyZWFrcyBiYWNrd2FyZCBjb21wYXRpYmls aXR5IHdpdGggY3VycmVudCwgc2luZ2xlLXJlY2lwaWVudA0KPiBKV0UNCj4gICBCRU5FRklUOiBJ bmNyZWFzZXMgc2F2aW5ncyBpbiBtdWx0aXBsZS1yZWNpcGllbnQgY2FzZSAoc2luY2Ugbm8gcGVy LQ0KPiByZWNpcGllbnQgaW50ZWdyaXR5IGNoZWNrIHZhbHVlKQ0KPiANCj4gT3B0aW9uIDAgaXMg Y2xlYXJseSBub3QgYWNjZXB0YWJsZS4gIFNvIGJhc2ljYWxseSwgdGhpcyBpcyBhIGNob2ljZQ0K PiBhYm91dCBob3cgbXVjaCB3ZSB3YW50IHRvIGxldCBkZXBsb3llZCBjb2RlIGtlZXAgdXMgZnJv bSBzZW5zaWJsZQ0KPiBhcmNoaXRlY3R1cmUuDQo+IA0KPiBUbyBtZSwgdGhlIGNob2ljZSBpcyBj bGVhci4gIENoYW5naW5nIGNvZGUgaXMgbWlub3IsIHNob3J0LXRlcm0gcGFpbi4NCj4gR2V0dGlu ZyBhcmNoaXRlY3R1cmUgd3JvbmcgaXMgbWFqb3IsIGxvbmctdGVybSBwYWluLiAgTGV0J3MgZG8g b3B0aW9uDQo+ICgyKS4NCg== From hdknr@ic-tact.co.jp Mon Apr 15 00:01:20 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7821F9305 for ; Mon, 15 Apr 2013 00:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB+kU8idTUcm for ; Mon, 15 Apr 2013 00:01:20 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2B921F92E9 for ; Mon, 15 Apr 2013 00:01:17 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id j5so3535800iaf.32 for ; Mon, 15 Apr 2013 00:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=DM9kvvvtWmWVqvbKh7Twf0o+yJZkUUtoBC0DjI7FHK0=; b=jLCDRvZZU3e9m7HQBm9cgE4zKPE2Ly6mhSEG4WMZfAm5j5vWMvj8vio7LLqTAlK+wv wg3VZAA4P32mGlEYQKS8GR6pFPMaP+FrZzvj+GKY5A2xthmYJzWFHYVQ5ujrekKAukRh I519XOa06JaQg7QrxHxPbQvYwpCpyJOjr5DUqaNAeYevZlbIPjmcH6V2v2LzAIk0lmRL WZwlmEp1d7yyzed7mjGMVCCV+/DrYBYrgThcK/xPfKwY6ktlejsGlQ83ciufXykgdw2r 3rkYhAT/QAL7LLYT7qumt5AV8vD0FxqY/BRCqJy/Vj5UoWsCcN8dfSkIGBMVeTkFekMu uTug== MIME-Version: 1.0 X-Received: by 10.50.7.3 with SMTP id f3mr4790337iga.50.1366009276741; Mon, 15 Apr 2013 00:01:16 -0700 (PDT) Received: by 10.64.103.194 with HTTP; Mon, 15 Apr 2013 00:01:16 -0700 (PDT) In-Reply-To: <51674E2D.3040604@isoc.org> References: <51674E2D.3040604@isoc.org> Date: Mon, 15 Apr 2013 16:01:16 +0900 Message-ID: From: hideki nara To: Karen ODonoghue Content-Type: multipart/alternative; boundary=089e0122f7b0b34bdc04da60d13d X-Gm-Message-State: ALoCoQnDPodsGLg4wLNNmDY/ennWEjNg2ecqx3Emfy+7LhQ6iTkP2TWlj9NNo/XDdR2+q2uQ4TCW Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 07:01:21 -0000 --089e0122f7b0b34bdc04da60d13d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 1 2013/4/12 Karen O'Donoghue > ****Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes > adding an =93spi=94 (security parameters index) header parameter to the J= WS and > JWE specifications. This modification to the JOSE formats would allow fo= r > signaling that pre-negotiated cryptographic parameters are being used, > rather than including those parameters in the JWS or JWE header. This > proposal has been written up as > http://tools.ietf.org/html/draft-barnes-jose-spi-00.**** > > ** ** > > Which of these best describes your preferences on this issue?**** > > 1. Have draft-barnes-jose-spi remain a separate specification that could > optionally also be supported by JWS and JWE implementations.**** > > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as a mandatory feature.**** > > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as an optional feature.**** > > 4. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > Your reply is requested by Friday, April 19th or earlier. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e0122f7b0b34bdc04da60d13d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
1


2013/4/12 Karen O'Donoghue <odonoghue@isoc.org>
=20 =20 =20
Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an =93spi=94 (security parameters index) header parameter to the JWS and JWE specifications.=A0 This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.=A0 This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.=

=A0

Which of these best describes your preferences on this issue?

1.=A0 Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.=

2.=A0 Incorporate draft-barnes-jose-= spi into the JWS and JWE specifications as a mandatory feature.<= u>

3.=A0 Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e0122f7b0b34bdc04da60d13d-- From hdknr@ic-tact.co.jp Mon Apr 15 00:02:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E208821F92FC for ; Mon, 15 Apr 2013 00:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WlTHg3qGS+p for ; Mon, 15 Apr 2013 00:02:11 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F85221F92E9 for ; Mon, 15 Apr 2013 00:02:11 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id o25so1229433iad.5 for ; Mon, 15 Apr 2013 00:02:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ShvJG6J8blGtvuLB6x6xYPXkiwM4/K+WvKkoa14y0NI=; b=HSarosxjFa0gVRHfQmkxIacjWRO1ZJbZI7zhHmjfPdHx727/yKulf3wEiB/Zo1dQns Du5JtAIEI9fTXZA1+aHq+rTcF4bafMEIzpGlTH8Qlz9AEt0yuxSYLmEY7DKQHCGTDS0k hNuuQa17JmWJjbMHZXwGXiTIEFDYOANDBJVbojUN0HS5lS7Jb/jUqDHXLboyv81LseBX t4CWbcrP3fvV6Flxl9a29Fbu/xAELbd0CE6DyO2JX5zHLOwyvAcmO80fLZU22PgRkIUA tUjGGwVG3VA9kauBhNPgVIS020CW9WRGbi0cLAfXJ61SvoxVrNvryFpwZoEStrRCdsOs 6QgQ== MIME-Version: 1.0 X-Received: by 10.50.112.100 with SMTP id ip4mr4695653igb.87.1366009330975; Mon, 15 Apr 2013 00:02:10 -0700 (PDT) Received: by 10.64.103.194 with HTTP; Mon, 15 Apr 2013 00:02:10 -0700 (PDT) In-Reply-To: <51674E63.3050809@isoc.org> References: <51674E63.3050809@isoc.org> Date: Mon, 15 Apr 2013 16:02:10 +0900 Message-ID: From: hideki nara To: Karen ODonoghue Content-Type: multipart/alternative; boundary=047d7b3a9ad2eed82304da60d497 X-Gm-Message-State: ALoCoQk5PrCvU11Gu81O9RhyXT+N1N/ubOpNvMbH//MDpaKA81b9okaZpc+R37FgzvJuOdfsOS9d Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 07:02:12 -0000 --047d7b3a9ad2eed82304da60d497 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 1 2013/4/12 Karen O'Donoghue > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests > requiring that a key indicator, such as a =93kid=94 field, be required in= all > JWS and JWE headers.****** Are use cases where key information is > exchanged by means other than the JWS or JWE headers important?** > > Which of these best describes your preferences on this issue?**** > > 1. Yes.**** > > 2. No. **** > > 0. I need more information to decide.**** > > ** ** > Your reply is requested by Friday, April 19th (or earlier). > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7b3a9ad2eed82304da60d497 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
1


2013/4/12 Karen O'Donoghue <odonoghue@isoc.org>
=20 =20 =20
Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a =93kid=94 field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this issue?

1.=A0 Yes.

2.=A0=A0 No.

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th (or earlier).

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--047d7b3a9ad2eed82304da60d497-- From hdknr@ic-tact.co.jp Mon Apr 15 00:02:44 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2FF21F85C9 for ; Mon, 15 Apr 2013 00:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxshPGtrHrAo for ; Mon, 15 Apr 2013 00:02:43 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id BD69021F85C4 for ; Mon, 15 Apr 2013 00:02:43 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id w21so2221141iac.37 for ; Mon, 15 Apr 2013 00:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=xChi1Je5WuX/oU0SUnZpanSGL4kcJyDyiMlCZd12NMk=; b=lRXOVDOmHgFfzsHKJv281Qx6Xs8kLNDVUoBeNn2ryP97snJtcTSp8MG0HHvWXYuA3/ 8RygykFgAhC/bLHPCxYk8ppU0fta2OBwOLa/MGq8hZY988DQ+HtqZ5duhEKkO48InEKh YyJXbPDanXLsYnmeFjNoeWQ4uRqlQ3TMCuvMiNaVEJ7XzLlJ0dsQI/7PMEuHwIPGSdg0 KGGjMHuQIv/T8Q+pz6ElW09MxDCxzzbXor56GdN3msmG3r7MajMh6VnW9b0Cv5pMePy1 nPikCNS4HF6sw/G3VRh1nQBgr5gDuY6nj2+DR7t9B+ZXeBXIDl5XIZkkOVCF6PzUY2ud 0faA== MIME-Version: 1.0 X-Received: by 10.50.7.3 with SMTP id f3mr4792511iga.50.1366009363326; Mon, 15 Apr 2013 00:02:43 -0700 (PDT) Received: by 10.64.103.194 with HTTP; Mon, 15 Apr 2013 00:02:43 -0700 (PDT) In-Reply-To: <51674E58.6000505@isoc.org> References: <51674E58.6000505@isoc.org> Date: Mon, 15 Apr 2013 16:02:43 +0900 Message-ID: From: hideki nara To: Karen ODonoghue Content-Type: multipart/alternative; boundary=089e0122f7b0dc82e704da60d665 X-Gm-Message-State: ALoCoQkK4Tz3dyuatDmmQn3MgyAj5VKSeelOBAd5cyDJdEIaH4GE7JmsxxnIiJpJdzeeNy8iKkpK Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 07:02:44 -0000 --089e0122f7b0dc82e704da60d665 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 1 2013/4/12 Karen O'Donoghue > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests > removing the =93x5c=94 header parameter from JWE, saying that no use case= for > it has emerged. The same logic may apply to other key specification > parameters for JWE.**** > > ** > ** > > Which of these best describes your preferences on this issue?**** > > 1. Retain the =93x5c=94 header parameter in JWE.**** > > 2. Remove the =93x5c=94 header parameter (and possibly other related key > specification parameters) from JWE.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > ** ** > Your reply is requested by Friday, April 19th or earlier. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e0122f7b0dc82e704da60d665 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
1


2013/4/12 Karen O'Donoghue <odonoghue@isoc.org>
=20 =20 =20
Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the =93x5c=94 header parameter from JWE, saying that no use case for it has emerged.=A0 The same logic may apply to other key specification parameters for JWE.


Which of these best describes your preferences on this issue?

1.=A0 Retain the =93x5c=94 header parameter in JWE.

2.=A0 Remove the =93x5c=94 header parameter (and possibly other related key specification parameters) from JWE.

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th or earlier.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e0122f7b0dc82e704da60d665-- From hdknr@ic-tact.co.jp Mon Apr 15 00:04:14 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EF221F930C for ; Mon, 15 Apr 2013 00:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVdDz91IrUpk for ; Mon, 15 Apr 2013 00:04:13 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C8ADF21F9309 for ; Mon, 15 Apr 2013 00:04:13 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id at1so5427037iec.27 for ; Mon, 15 Apr 2013 00:04:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EVLGgl/zh9/fWqzPs/zpk0Brac22WpFrJIWmUD/arto=; b=na0O93IJmAWpoMNB0utfSTC72n54qAGGAcMGJCB6t+v2aTTtn4JqVOLQsvFuTxFPdM z/zonJ+hXwXG/SZ1/RrgRfzKs3nBO3wm59+HC5N1a9X5nqMTaJyuhEIoHT3GIU4DF1UK eC+ON0Ubo/bxT7j1QTO9JiZ+FxKtDrmrvedis0Yh1K92LKPskLBGiR2TtShL+iPWF9pl BsUGYpdjtQnP0HEZQVR9rDjGsZ5Vmagv5PxjpgBPrNx23CVnApR/Qc9MWuwEJPMGS6vq 15Kio3KY/1gEFI9vHdypBVfFWNTqkT4Az0aaiPyjcixLUFzHa9tmm6q7HENpAuLXS0Qd 43qQ== MIME-Version: 1.0 X-Received: by 10.50.126.5 with SMTP id mu5mr4631084igb.50.1366009453370; Mon, 15 Apr 2013 00:04:13 -0700 (PDT) Received: by 10.64.103.194 with HTTP; Mon, 15 Apr 2013 00:04:13 -0700 (PDT) In-Reply-To: <51674E3D.7030004@isoc.org> References: <51674E3D.7030004@isoc.org> Date: Mon, 15 Apr 2013 16:04:13 +0900 Message-ID: From: hideki nara To: Karen ODonoghue Content-Type: multipart/alternative; boundary=047d7b1604313a860e04da60dcc3 X-Gm-Message-State: ALoCoQnltuhAIo9vPfalC4NRV4qFwjj8Q8Y2nVLeuKpONImUEgDhuSKknc3TABBINBZT2fkK9ydU Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 07:04:14 -0000 --047d7b1604313a860e04da60dcc3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 1 2013/4/12 Karen O'Donoghue > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes > restructuring the JWE representation to remove the JWE Integrity Value > field and instead use the RFC 5116 (AEAD) binary serialization to represe= nt > the Ciphertext, Initialization Vector, and Integrity Value values. If th= is > proposal is adopted, JWEs would then have three fields =96 the header, th= e > encrypted key, and the RFC 5116 combination of the Ciphertext, > Initialization Vector, and Integrity Value values.****** ** > > This issue is also related to issue #3. Note that the updated McGrew > draft described there could be used whether or not we switched to using R= FC > 5116.****** > ** > > Which of these best describes your preferences on this issue?**** > > 1. Continue having separate Ciphertext, Initialization Vector, and > Integrity Value values in the JWE representation.**** > > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the > combination of these three values.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > ** ** > Your reply is requested by Friday, April 19th or earlier. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7b1604313a860e04da60dcc3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
1


2013/4/12 Karen O'Donoghue <odonoghue@isoc.org>
=20 =20 =20
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.=A0 If this proposal is adopted, JWEs would then have three fields =96 the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values.=A0

This issue is also related to issue #3.=A0 Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
=A0

Which of these best describes your preferences on this issue?

1.=A0 Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.=A0 Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.<= /u>

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th or earlier.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--047d7b1604313a860e04da60dcc3-- From hdknr@ic-tact.co.jp Mon Apr 15 00:04:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3591021F9305 for ; Mon, 15 Apr 2013 00:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ble-2xj424Y for ; Mon, 15 Apr 2013 00:04:47 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A070521F84E9 for ; Mon, 15 Apr 2013 00:04:47 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e14so5434872iej.16 for ; Mon, 15 Apr 2013 00:04:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=bo4pIcrOBUbV2kzc9pVa7Wh6w6Je7rQcWusHi4m+lL0=; b=Cv9dwD5O5d6rc8VKIILpuW+kO08tOnnZHJJq/bUUBBMh1n7CgdW81iY3euqoEzBio1 wu9Qu35+RpUNnagYtSXMZgB82Of+2BB0CgAElP135R0qjnlXzn9bqr8m5GYxC24Ed3wb T9Ds6BCXkjGJiXfkmU5E6zx2cFuDVMmOKgUuCU8ku8RwgOw3G2vFQ6X8qwVcjibZig/O lr+wWpnHTSqYTssEZrn5XV0nVv2ANeQZrsXWs0e/vHdniXb5JoZxvRELwwEMhvUnlu7M 9WlBZBZGVphpgei1OyjZuZxDtr292bZvP2+Gz8Spziezie1r7rwFRiOYyyXfiKkifb2L zG5Q== MIME-Version: 1.0 X-Received: by 10.43.78.77 with SMTP id zl13mr11096556icb.55.1366009487251; Mon, 15 Apr 2013 00:04:47 -0700 (PDT) Received: by 10.64.103.194 with HTTP; Mon, 15 Apr 2013 00:04:47 -0700 (PDT) In-Reply-To: <51674E17.5020902@isoc.org> References: <51674E17.5020902@isoc.org> Date: Mon, 15 Apr 2013 16:04:47 +0900 Message-ID: From: hideki nara To: Karen ODonoghue Content-Type: multipart/alternative; boundary=047d7b5d29743f6b5004da60de63 X-Gm-Message-State: ALoCoQlOivzYeDjI3FYy492XOrslfesk2KpA3oWfHdhQssiVf7qUAKfUr61PmCzwyHQRbQMrwPub Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 07:04:48 -0000 --047d7b5d29743f6b5004da60de63 Content-Type: text/plain; charset=ISO-8859-1 1 2013/4/12 Karen O'Donoghue > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out > that the JWA algorithm identifiers are different than those used by the W3C > WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm > identifiers are strings, whereas the W3C WebCrypto algorithm identifiers > are structures including string identifiers. The working group had > previously decided to continue representing JOSE algorithms as strings, as > recorded at > http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. > **** > > > Which of these best describes your preferences on this issue?**** > > 1. Continue have the JWA algorithm identifiers be strings, and not > objects. Note that WebCrypto may choose to use some of these same strings, > where applicable.**** > > 2. Switch to using the algorithm identifier structures defined in the > WebCrypto draft.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > Your reply is requested by Friday, April 19th or earlier. > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7b5d29743f6b5004da60de63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1


2013/4/12 Karen O'Donoghue <odonoghue@isoc.org>
=20 =20 =20
Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http:/= /www.w3.org/TR/WebCryptoAPI/.=A0 The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.=A0 The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.<= br>


Which of these best describes your preferences on this issue?

1.=A0 Continue have the JWA algorithm identifiers be strings, and not objects.=A0 Note that WebCrypto may choose to use some of these same strings, where applicable.

2.=A0 Switch to using the algorithm identifier structures defined in the WebCrypto draft.<= /span>

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--047d7b5d29743f6b5004da60de63-- From jricher@mitre.org Mon Apr 15 07:00:25 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A974B21F93EC for ; Mon, 15 Apr 2013 07:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8-g5njbFoI1 for ; Mon, 15 Apr 2013 07:00:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8C21F93E5 for ; Mon, 15 Apr 2013 07:00:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C33762500AE; Mon, 15 Apr 2013 10:00:24 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DDC401F0DB5; Mon, 15 Apr 2013 10:00:23 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 15 Apr 2013 10:00:23 -0400 Message-ID: <516C07EE.8000306@mitre.org> Date: Mon, 15 Apr 2013 10:00:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <073.1dc661959a15caad46917baec89b3440@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150C74DB3E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C74DB3E@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.58] Cc: "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:00:25 -0000 I like this structural proposal with one caveat: moving the key ID out of the key structure means that a JWK can no longer be a self-contained unit with all of the metadata that it contains today. Is that what we want? Do we want to declare that a key id only makes sense in the context of a JWK Set and not an individual JWK? A simple workaround would be to have both the object-based structure as well as the value within the JWK itself and that they MUST match. -- Justin On 04/14/2013 08:35 PM, Manger, James H wrote: >> #16: URI identifying a specific key in a JWK set >>> http://trac.tools.ietf.org/wg/jose/trac/ticket/16 >> In order to evaluate this, we need to get a more detailed proposal > Below is a more detailed proposal. The basic idea is to make the JWK key set syntax a bit more sensible (keys named by their ids; instead of a "keys" element holding an array of keys); give key sets a media type; and define the fragment to be a JSON pointer [RFC 6901]. Then a URI can identify a specific key. A "jku" value can precisely indicate the key needed to process a JOSE message, eg "jku":"https://example.com/alice.keys#/k1". > > >> 1. Syntax of the fragment > The fragment, if present, identifies a specific key in the JWK key set. > > The fragment SHALL be a JSON Pointer [RFC 6901], pointing to the JSON object holding the specific key of interest within the set of keys. > > The fragment SHALL be a "/" character followed by the key identifier ("kid" value) for the specific key. > > [This implies the top-level structure of a JWK key set is changed to be a JSON object whose elements are individual keys. An element's name is the identifier of the key ("kid" value); an element's value is a single JWK object. One element (named "meta") is special: it is not a "kid" value, but a place to hold any metadata about the whole set of keys. > > Example: > { > "k1" : {"kty":"EC","crv":"P-256","x":…,"y":…}, > 2011-04-29" : {"kty":RSA","n":…,"e":"AQAB"} > } > ] > > >> 2. dealing with duplicate values within a JWK structure > I'm not sure what this issue is. I suspect it is solved by storing keys as object elements as opposed to array items. > >> 3. Definition of a new media type - is this required or not - justify >> either postion > The JWK spec should define a media type, such as application/keys+json. > Fragments are specific to a media type so a media type needs to be defined. > >> 4. Explain why the proposal is "better" than the current ability to >> have a url plus the kid in the message. > The whole concept of a URI is to be an identifier itself (not just when combined with a second field). Many, many systems and protocols that support URIs assume that the URI alone is sufficient to identify the item of interest. > It simplifies APIs and protocols: just pass 1 value. > >> 5. Discuss what happens if the fragment is not present on the url > The specs should be written so that if there is no fragment but there is only 1 key in the identified JWK key set, then things still work. > > I suggest saying a *creator* of a "jku" URI value (to identify the specific key required to process a JOSE message) MUST include a fragment to identify a single key. When a key set has only 1 key, a *receiver* MUST accept a "jku" URI as an identifier of that 1 key even if the URI has no fragment. > >> or if the fragment is not findable in the resultant document. > Then the URI identifies a key that is not present so an error results (similar to getting a 404 Not Found for the whole key set). > >> If the fragment >> is going to be manditory does them mean that we should be doing a new >> scheme instead as fragments cannot be required under the current URL >> syntax defintions (or at least that is my reading). > Definitely no new URI scheme. > A URI without a fragment is still a valid URI. That doesn't stop us saying a "jku" URI value MUST contain a fragment. > >> Please flesh out your proposal more so that it can be fully evaluated. > I hope this email has fleshed out a proposal sufficiently. > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Apr 15 08:17:41 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB6F21F86E6 for ; Mon, 15 Apr 2013 08:17:41 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq8W2CnpH1fN for ; Mon, 15 Apr 2013 08:17:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id CE81D21F8488 for ; Mon, 15 Apr 2013 08:17:35 -0700 (PDT) Received: from BY2FFO11FD004.protection.gbl (10.1.15.203) by BY2FFO11HUB026.protection.gbl (10.1.14.112) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 15:17:27 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 15:17:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 15:17:23 +0000 From: Mike Jones To: "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto Thread-Index: AQHONxCAPjjZdTGUGUijfWxegbQpcZjUiNSAgALfLeA= Date: Mon, 15 Apr 2013 15:17:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676410C1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E17.5020902@isoc.org> <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> In-Reply-To: <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(5383001)(13464002)(4396001)(16406001)(47736001)(50466001)(49866001)(47976001)(81542001)(50986001)(54356001)(74502001)(46102001)(53806001)(66066001)(44976003)(80022001)(23726002)(47446002)(55846006)(74662001)(5343655001)(56816002)(31966008)(65816001)(46406003)(69226001)(33656001)(59766001)(77982001)(63696002)(79102001)(56776001)(15202345002)(54316002)(76482001)(20776003)(47776003)(81342001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB026; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:17:41 -0000 1. Continue have the JWA algorithm identifiers be strings, and not objects= . Note that WebCrypto may choose to use some of these same strings, where = applicable. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Saturday, April 13, 2013 12:17 PM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm id= entifiers/parameters incompatible with WebCrypto 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that t= he JWA algorithm identifiers are different than those used by the W3C WebCr= ypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identi= fiers are strings, whereas the W3C WebCrypto algorithm identifiers are stru= ctures including string identifiers. The working group had previously deci= ded to continue representing JOSE algorithms as strings, as recorded at htt= p://www.ietf.org/mail-archive/web/jose/current/msg01219.html. Which of these best describes your preferences on this issue? 1. Continue have the JWA algorithm identifiers be strings, and not objects= . Note that WebCrypto may choose to use some of these same strings, where = applicable. 2. Switch to using the algorithm identifier structures defined in the WebC= rypto draft. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier.=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Apr 15 08:19:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEF21F8F4A for ; Mon, 15 Apr 2013 08:19:16 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X3gP0TlrRfz for ; Mon, 15 Apr 2013 08:19:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id B111E21F8AD5 for ; Mon, 15 Apr 2013 08:19:14 -0700 (PDT) Received: from BN1AFFO11FD011.protection.gbl (10.58.52.203) by BN1BFFO11HUB030.protection.gbl (10.58.53.140) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 15:19:12 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD011.mail.protection.outlook.com (10.58.52.71) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 15:19:43 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 15:18:43 +0000 From: Mike Jones To: "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: AQHONxC00YowpNiVekuEgBwlBm4BWJjVZ6WAgAIBZvA= Date: Mon, 15 Apr 2013 15:18:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676410FC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E2D.3040604@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(13464002)(199002)(5383001)(47776003)(46102001)(81342001)(47446002)(54316002)(47976001)(49866001)(76482001)(63696002)(59766001)(65816001)(33656001)(5343655001)(50986001)(53806001)(74502001)(16406001)(51856001)(20776003)(31966008)(80022001)(23726002)(79102001)(50466001)(47736001)(4396001)(81542001)(15202345002)(56816002)(69226001)(54356001)(56776001)(66066001)(46406003)(77982001)(74662001)(561944001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB030; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:19:16 -0000 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Sunday, April 14, 2013 1:35 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding a= n "spi" (security parameters index) header parameter to the JWS and JWE spe= cifications. This modification to the JOSE formats would allow for signali= ng that pre-negotiated cryptographic parameters are being used, rather than= including those parameters in the JWS or JWE header. This proposal has be= en written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. =20 Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier.=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Apr 15 08:20:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAF621F8F4A for ; Mon, 15 Apr 2013 08:20:50 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o18FC0jYovy6 for ; Mon, 15 Apr 2013 08:20:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0E21F8AD5 for ; Mon, 15 Apr 2013 08:20:48 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.1.15.201) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 15:21:11 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 15:20:40 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 15:20:09 +0000 From: Mike Jones To: "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: AQHONxCatRlv3atUREqdqm0NbKM8V5jUiWOAgALe6hA= Date: Mon, 15 Apr 2013 15:20:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E3D.7030004@isoc.org> <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> In-Reply-To: <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(13464002)(377454001)(81342001)(50986001)(74502001)(54356001)(47976001)(4396001)(47776003)(15202345002)(47736001)(46102001)(23726002)(80022001)(74662001)(44976003)(76482001)(33656001)(63696002)(56776001)(81542001)(69226001)(55846006)(66066001)(51856001)(65816001)(53806001)(47446002)(77982001)(31966008)(56816002)(50466001)(5343655001)(20776003)(54316002)(49866001)(561944001)(46406003)(16406001)(59766001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB006; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:20:50 -0000 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Saturday, April 13, 2013 12:19 PM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we us= e RFC 5116 and remove the JWE Integrity Value field? 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restru= cturing the JWE representation to remove the JWE Integrity Value field and = instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphe= rtext, Initialization Vector, and Integrity Value values. If this proposal= is adopted, JWEs would then have three fields - the header, the encrypted = key, and the RFC 5116 combination of the Ciphertext, Initialization Vector,= and Integrity Value values.=20 This issue is also related to issue #3. Note that the updated McGrew draft= described there could be used whether or not we switched to using RFC 5116= . =20 Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the comb= ination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. =20 Your reply is requested by Friday, April 19th or earlier.=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Apr 15 08:23:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6525721F93B2 for ; Mon, 15 Apr 2013 08:23:38 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amP3givuBO1q for ; Mon, 15 Apr 2013 08:23:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 18B8521F90D5 for ; Mon, 15 Apr 2013 08:23:37 -0700 (PDT) Received: from BY2FFO11FD002.protection.gbl (10.1.15.202) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 15:23:34 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 15:23:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 15:22:44 +0000 From: Mike Jones To: "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , Thread-Index: AQHONxCexXvwFe7nYkCTqSJ8uBDKI5jSIMoAgAJpdQCAAt47MA== Date: Mon, 15 Apr 2013 15:22:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641257@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E58.6000505@isoc.org> <4E289D7B-BB53-412A-AE3F-8CD08E45205A@adm.umu.se> In-Reply-To: <4E289D7B-BB53-412A-AE3F-8CD08E45205A@adm.umu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5383001)(199002)(189002)(13464002)(377454001)(15202345002)(65816001)(69226001)(20776003)(81542001)(47776003)(47446002)(81342001)(55846006)(63696002)(80022001)(66066001)(50466001)(50986001)(47976001)(4396001)(49866001)(16406001)(59766001)(77982001)(46406003)(79102001)(56776001)(47736001)(74662001)(54316002)(51856001)(23726002)(74502001)(31966008)(5343655001)(76482001)(33656001)(44976003)(56816002)(54356001)(46102001)(53806001)(42413001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:23:38 -0000 1. Retain the "x5c" header parameter in JWE. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Saturday, April 13, 2013 12:22 PM To: Axel.Nennker@telekom.de Cc: jose@ietf.org; odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the = x5c field be removed from JWE?, ,=20 +1 12 apr 2013 kl. 08:32 skrev Axel.Nennker@telekom.de: 1 =20 x5c is the most explicit way to describe which private key is the right one= . It is an alternative to kid which is another reason why kid must not be = mandatory. =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Friday, April 12, 2013 1:59 AM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #12: Should the x5c = field be removed from JWE?, , =20 Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removi= ng the "x5c" header parameter from JWE, saying that no use case for it has = emerged. The same logic may apply to other key specification parameters fo= r JWE. Which of these best describes your preferences on this issue? 1. Retain the "x5c" header parameter in JWE. 2. Remove the "x5c" header parameter (and possibly other related key speci= fication parameters) from JWE. 3. Another resolution (please specify in detail). 0. I need more information to decide. =20 Your reply is requested by Friday, April 19th or earlier. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From rlb@ipv.sx Mon Apr 15 08:25:58 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C467A21F93D2 for ; Mon, 15 Apr 2013 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beJbL21R3PGR for ; Mon, 15 Apr 2013 08:25:57 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 759AD21F8E6A for ; Mon, 15 Apr 2013 08:25:57 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so4580006oag.1 for ; Mon, 15 Apr 2013 08:25:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wli3klY2CK5b1cQr/cy4xn7tq3cRaTccszlY4OcknZo=; b=EoVQCSf/JGukgymDeqCV0Wq8lDN3wzfnA0zJsDBVibpZfM/ZvAtpCVGBOzvdQ30szd k4ovf8AklOURyvvZTo/hu0se4PLtwXGoqyFiRriT75VCMXCVbXSCoplagUaJOBkMZT5c zM4qZ+DqFI9xjj0/gDtEmEgewS9bROQNIJ7CCrjTUGSBN8ARrfABZomWMSFoBC15XlT2 lqkgNIAGd7UPZAREJ2H/HDvNvMUCLnWlTG/2sSo7V0GRZuL6KfbKDhbVIwYy5TC2Zm4+ xUL4TTyXdknivvtQ1PaFI7ME5XTxD5Dtwg6ozYFIxTrdyI3I7rtpLtFFYMIfUqB/OrZU xe0Q== MIME-Version: 1.0 X-Received: by 10.60.62.39 with SMTP id v7mr2429326oer.5.1366039556989; Mon, 15 Apr 2013 08:25:56 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:25:56 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com> <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com> <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 15 Apr 2013 11:25:56 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=089e013a005a8b409104da67dec7 X-Gm-Message-State: ALoCoQn9HT8PayyIS///krwXNp7JmDU7phCjNf+NFhcbMibPs+bQihHYU6B6wYoMrOBN5T37NaYN Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] GCM nonce reuse question X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:25:58 -0000 --089e013a005a8b409104da67dec7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > I think there are more options for handling multiple recipients of > AEAD-secured content: > > > Option 3: Put all per-recipient info into one header; keep this header > under the AEAD integrity check; have one nonce. > COST: All recipients need to be known (and their key exchange info > created) before the AEAD algorithm is applied. > COST: The JWE JSON header structure needs to be adjusted (eg to have an > array of recipient info) so it is not backward compatible with current > drafts. > COST: Doesn't help use cases where one recipient forwards an > AEAD-secured message on to a new recipient (eg an XMPP system receives a > message secured for a user and re-secures it for a specific device of tha= t > user). Changing recipients requires reapplying the AEAD operations. > COST: Each recipient needs to see key exchange info of all recipients > (privacy impact?). > POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is > secured as a complete unit. > > > Option 2b: Remove per-recipient info from AEAD integrity check; but add > AEAD details to each key exchange. For instance, info about an AEAD > operation (alg id, key id etc) potentially even including the whole > ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT operation th= at > encrypts the AEAD secret key for a recipient. > BENEFIT: The key exchange is tied to a specific AEAD operation. > COST: Crypto is not typically done like this; uncertain as to what exac= t > security properties you are getting. Perhaps there are some similarities = to > NIST Concat KDF that adds "context" to key derivation: this adds "context= " > about an AEAD operation to the key exchange. > > > I agree with Richard Barnes that the per-recipient key exchange details > should be outside the AEAD operation (not covered by the AEAD integrity > check). Go with option 2 or 2b. > Then, separately, we can decide which details of the AEAD operation shoul= d > be bound to each key exchange: none? AEAD key length? AEAD alg id? whole > AEAD header? AEAD ciphertext? other context? > > > -- > James Manger > > Hey James, Thanks for this. I agree that Option 3 is a valid possibility, but not a desirable one. Option 2b is an interesting possibility. Effectively, you would be including a hash of the JWE (sans key) under the key wrap integrity check, binding the key to the JWE. I would note that we're already talking about adding the ability to bind attributes to wrapped keys (for WebCrypto). In light of that, the "JWE digest" could just be included as one of those attributes. At the same time, this attribute should be optional, since I think there are use cases where the CMK is not entirely ephemeral. For example, I think the current XMPP e2e document uses it as a session key rather than an individual message key, so you wouldn't want to limit the key to a single JWE. So I think that lands us back at Option 2, with one more reason to make JWE key wrapping the same as general key wrapping [draft-barnes-jose-key-wrapping]. --Richard > > ---------- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Richard Barnes > > Sent: Wednesday, 3 April 2013 4:55 AM > > =85 > > The problem here is JWE, specifically the fact that the header (with > > per-recipient data) is covered by the integrity check. If you remove > > the per-recipient data from the integrity check, then this problem goes > > away. In that case, there is only one invocation of GCM (not one per > > recipient), so there's no problem. > > > > So the choice that JOSE faces is from the following options: > > > > Option 0. Outlaw GCM for multiple recipients. > > COST: GCM > > > > Option 1. Keep per-recipient info under integrity check, and require a > > fresh nonce for each recipient > > COST: Removes all savings in the multiple recipient case > > BENEFIT: Doesn't break backward compatibility with current, single- > > recipient JWE > > > > Option 2. Remove per-recipient info from integrity check > > COST: Breaks backward compatibility with current, single-recipient > > JWE > > BENEFIT: Increases savings in multiple-recipient case (since no per- > > recipient integrity check value) > > > > Option 0 is clearly not acceptable. So basically, this is a choice > > about how much we want to let deployed code keep us from sensible > > architecture. > > > > To me, the choice is clear. Changing code is minor, short-term pain. > > Getting architecture wrong is major, long-term pain. Let's do option > > (2). > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --089e013a005a8b409104da67dec7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <James.H.Ma= nger@team.telstra.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I think there are more options for handling multiple recipients of AEAD-sec= ured content:


Option 3: Put all per-recipient info into one header; keep this header unde= r the AEAD integrity check; have one nonce.
=A0 COST: All recipients need to be known (and their key exchange info crea= ted) before the AEAD algorithm is applied.
=A0 COST: The JWE JSON header structure needs to be adjusted (eg to have an= array of recipient info) so it is not backward compatible with current dra= fts.
=A0 COST: Doesn't help use cases where one recipient forwards an AEAD-s= ecured message on to a new recipient (eg an XMPP system receives a message = secured for a user and re-secures it for a specific device of that user). C= hanging recipients requires reapplying the AEAD operations.
=A0 COST: Each recipient needs to see key exchange info of all recipients (= privacy impact?).
=A0 POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is= secured as a complete unit.


Option 2b: Remove per-recipient info from AEAD integrity check; but add AEA= D details to each key exchange. For instance, info about an AEAD operation = (alg id, key id etc) potentially even including the whole ciphertext is use= d as the "label" for the RSAES-OAEP-ENCRYPT operation that encryp= ts the AEAD secret key for a recipient.
=A0 BENEFIT: The key exchange is tied to a specific AEAD operation.
=A0 COST: Crypto is not typically done like this; uncertain as to what exac= t security properties you are getting. Perhaps there are some similarities = to NIST Concat KDF that adds "context" to key derivation: this ad= ds "context" about an AEAD operation to the key exchange.


I agree with Richard Barnes that the per-recipient key exchange details sho= uld be outside the AEAD operation (not covered by the AEAD integrity check)= . Go with option 2 or 2b.
Then, separately, we can decide which details of the AEAD operation should = be bound to each key exchange: none? AEAD key length? AEAD alg id? whole AE= AD header? AEAD ciphertext? other context?


--
James Manger



Hey James,
Thanks for this. =A0I agree that Option 3 is a valid possibili= ty, but not a desirable one.

Option 2b is an inter= esting possibility. =A0Effectively, you would be including a hash of the JW= E (sans key) under the key wrap integrity check, binding the key to the JWE= . =A0 I would note that we're already talking about adding the ability = to bind attributes to wrapped keys (for WebCrypto). =A0In light of that, th= e "JWE digest" could just be included as one of those attributes.= =A0

At the same time, this attribute should be optional, si= nce I think there are use cases where the CMK is not entirely ephemeral. = =A0For example, I think the current XMPP e2e document uses it as a session = key rather than an individual message key, so you wouldn't want to limi= t the key to a single JWE.

So I think that lands us back at Option 2, with one mor= e reason to make JWE key wrapping the same as general key wrapping [draft-b= arnes-jose-key-wrapping].

--Richard


=A0
> ----------
> From: jose-= bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of
> Richard Barnes
> Sent: Wednesday, 3 April 2013 4:55 AM
> =85
> The problem here is JWE, specifically the fact that the header (with > per-recipient data) is covered by the integrity check. =A0If you remov= e
> the per-recipient data from the integrity check, then this problem goe= s
> away. =A0In that case, there is only one invocation of GCM (not one pe= r
> recipient), so there's no problem.
>
> So the choice that JOSE faces is from the following options:
>
> Option 0. Outlaw GCM for multiple recipients.
> =A0 COST: GCM
>
> Option 1. Keep per-recipient info under integrity check, and require a=
> fresh nonce for each recipient
> =A0 COST: Removes all savings in the multiple recipient case
> =A0 BENEFIT: Doesn't break backward compatibility with current, si= ngle-
> recipient JWE
>
> Option 2. Remove per-recipient info from integrity check
> =A0 COST: Breaks backward compatibility with current, single-recipient=
> JWE
> =A0 BENEFIT: Increases savings in multiple-recipient case (since no pe= r-
> recipient integrity check value)
>
> Option 0 is clearly not acceptable. =A0So basically, this is a choice<= br> > about how much we want to let deployed code keep us from sensible
> architecture.
>
> To me, the choice is clear. =A0Changing code is minor, short-term pain= .
> Getting architecture wrong is major, long-term pain. =A0Let's do o= ption
> (2).
_____________________________= __________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg

--089e013a005a8b409104da67dec7-- From Michael.Jones@microsoft.com Mon Apr 15 08:26:22 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483F021F93B1 for ; Mon, 15 Apr 2013 08:26:22 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyPY8Fnyx9Dj for ; Mon, 15 Apr 2013 08:26:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8021F8E6A for ; Mon, 15 Apr 2013 08:26:21 -0700 (PDT) Received: from BY2FFO11FD002.protection.gbl (10.1.15.202) by BY2FFO11HUB013.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 15:26:51 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 15:26:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 15:24:43 +0000 From: Mike Jones To: "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: AQHONxCooSd2LAEBTkqzIVwx4JWauZjSDFgAgANa7oCAAgFzQA== Date: Mon, 15 Apr 2013 15:24:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5383001)(377454001)(189002)(13464002)(199002)(63696002)(54316002)(65816001)(47976001)(50466001)(31966008)(81542001)(20776003)(69226001)(56816002)(81342001)(5343635001)(5343655001)(47736001)(50986001)(46406003)(56776001)(66066001)(76482001)(47776003)(79102001)(49866001)(55846006)(77982001)(16406001)(80022001)(4396001)(53806001)(59766001)(33656001)(46102001)(51856001)(74662001)(47446002)(54356001)(15202345002)(74502001)(23726002)(44976003); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB013; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:26:22 -0000 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. -----Original Message----- From: Roland Hedberg [mailto:roland.hedberg@adm.umu.se]=20 Sent: Sunday, April 14, 2013 1:33 AM To: odonoghue@isoc.org Cc: jose@ietf.org; Mike Jones Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory I support 1 as defined by Mike. 12 apr 2013 kl. 07:25 skrev Mike Jones : > 1. Yes - Use cases where key information is exchanged by means other tha= n the JWS and JWE headers ARE important -- Roland From: Mike Jones=20 Sent: Thursday, April 11, 2013 10:25 PM To: 'odonoghue@isoc.org'; jose@ietf.org Subject: RE: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory Reading this question, I believe that there's a possibility for the questio= n to be misinterpreted, since the sense of the question in the subject is o= pposite of the sense of the question in the body. I believe that the inten= t of 1 and 2 were as follows: 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. 2. No - Use cases where key information is exchanged by means other than t= he JWS and JWE headers ARE NOT important. Maybe people could reply with 1 and 2 as above, so that their answers to th= e question of whether these use cases are important are not are unambiguous= . -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 5:00 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important?=20 Which of these best describes your preferences on this issue? 1. Yes. 2. No.=20 0. I need more information to decide. =20 Your reply is requested by Friday, April 19th (or earlier). From rlb@ipv.sx Mon Apr 15 08:29:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7421F9339 for ; Mon, 15 Apr 2013 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqrp0z-DwoCF for ; Mon, 15 Apr 2013 08:29:07 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7035021F8DA6 for ; Mon, 15 Apr 2013 08:29:07 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id un3so4139437obb.25 for ; Mon, 15 Apr 2013 08:29:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+cvsrzvMmePIZUdoho+CgEGDXgXGX0QtJqad8d8Jr1A=; b=P2XpYnmY5NiJfjGFEg49V79fQ/7MigQBj35GJ0WIu7T7mpTcCkyyZifllGQjEZ3hn1 Ela+fNrdBSiko1iZxjX53HHq7juZk6Cvrgt1ULx2CSz8Z2zpJ6wuOtlkUgGoP7qufSwP IyNQGjfzXlV4/8hjQMYvGZ5JGIgWtsA0Aa1+Zx58JaGt9Lby4pF7fPYWJra+yvWTTmRY 1GSaCuF1e5Q2AIRxH/Puk0+08Du2PWsq4wYnUx9XhaNOvbCEociFXPxnAo74eXwtoPD2 eTgGsK92WWvG7x2jZS40hQW1Mx17tcLTslIx+NvTfZTEIQXMnzgwYDNvjMnQvwycRHzX 8Eng== MIME-Version: 1.0 X-Received: by 10.60.57.200 with SMTP id k8mr7875236oeq.117.1366039746815; Mon, 15 Apr 2013 08:29:06 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:29:06 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: <51674E58.6000505@isoc.org> References: <51674E58.6000505@isoc.org> Date: Mon, 15 Apr 2013 11:29:06 -0400 Message-ID: From: Richard Barnes To: odonoghue@isoc.org Content-Type: multipart/alternative; boundary=089e01536604dbb87004da67e943 X-Gm-Message-State: ALoCoQkX86md2hsSIslLlyiDbVkT1gnQlP5CVd9gNui2Emse4sg2o2EyGMA69LrBlUeLRvNOqwdM Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:29:08 -0000 --089e01536604dbb87004da67e943 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Count me as "don't really care", modulo ISSUE-15. On Thu, Apr 11, 2013 at 7:59 PM, Karen O'Donoghue wrote= : > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests > removing the =93x5c=94 header parameter from JWE, saying that no use case= for > it has emerged. The same logic may apply to other key specification > parameters for JWE.**** > > ** > ** > > Which of these best describes your preferences on this issue?**** > > 1. Retain the =93x5c=94 header parameter in JWE.**** > > 2. Remove the =93x5c=94 header parameter (and possibly other related key > specification parameters) from JWE.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > ** ** > Your reply is requested by Friday, April 19th or earlier. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e01536604dbb87004da67e943 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Count me as "don't really care", modulo ISSUE-15.

On Thu, Apr 11, 2013 at 7:59 PM, Karen O'Do= noghue <odonoghue@isoc.org> wrote:
=20 =20 =20
Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the =93x5c=94 header parameter from JWE, saying that no use case for it has emerged.=A0 The same logic may apply to other key specification parameters for JWE.


Which of these best describes your preferences on this issue?

1.=A0 Retain the =93x5c=94 header parameter in JWE.

2.=A0 Remove the =93x5c=94 header parameter (and possibly other related key specification parameters) from JWE.

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th or earlier.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e01536604dbb87004da67e943-- From rlb@ipv.sx Mon Apr 15 08:34:33 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164B621F93D8 for ; Mon, 15 Apr 2013 08:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRo2ba5QirLW for ; Mon, 15 Apr 2013 08:34:32 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADEA21F93C6 for ; Mon, 15 Apr 2013 08:34:32 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wc20so1199302obb.16 for ; Mon, 15 Apr 2013 08:34:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xlvGasAf/vnbwx0dL8bZAprLZmgiHqjAhr6JnEZMlVs=; b=DDhIzYZRroJGhmlFXL3aQLhmyg1VCShhDlbZt2Dj4VZoZZBeyZ1+9L18GBmt5Gj7vG mZ/1AFCVca5lJ8NTHJYh8vOYaxO8uYzqRhwJfttLS4l72VQ/FDG3qP8kyjFNWkyjJ4CY xWjzbcx27bkab1IE0kSlk9EVSyIRXWE/2/crio1qozaAowXupkCTZjL5G1opudXysjua s6mqKeFGgDE88Cc2mr8G9vx8zk0iTuOTfUqxGFQZVckxUtjq3uKtJEmhzzcbBC96+el2 h8fw1rxSxKPJjbIgMQ7Uh/jH5a81cjQerhUYq2JkXEXKQZBJJYMU/pbfts/S+yHllzQe la6Q== MIME-Version: 1.0 X-Received: by 10.182.27.40 with SMTP id q8mr7804382obg.100.1366040071739; Mon, 15 Apr 2013 08:34:31 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:34:31 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: References: <51674E63.3050809@isoc.org> Date: Mon, 15 Apr 2013 11:34:31 -0400 Message-ID: From: Richard Barnes To: Dick Hardt Content-Type: multipart/alternative; boundary=089e0122976239acef04da67fd3e X-Gm-Message-State: ALoCoQlCXg66Zi4gesX9vGwd29yThoL4wUgkkgGWy828TnbsACZaUNwGEx8sTNZ2Y1NZzjvwnfIN Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:34:33 -0000 --089e0122976239acef04da67fd3e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If including a key indicator is not a MUST, then you have to specify what the receiver does when a key indicator is not present. Could you suggest text for that? Thanks, --Richard On Thu, Apr 11, 2013 at 8:22 PM, Dick Hardt wrote: > 1A, a key indicator SHOULD be included. (not a MUST) > > On Apr 11, 2013, at 4:59 PM, Karen O'Donoghue wrote: > > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests > requiring that a key indicator, such as a =93kid=94 field, be required in= all > JWS and JWE headers.**** Are use cases where key information is exchanged > by means other than the JWS or JWE headers important? > > Which of these best describes your preferences on this issue?**** > > 1. Yes.**** > > 2. No. **** > > 0. I need more information to decide.**** > > > Your reply is requested by Friday, April 19th (or earlier). > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e0122976239acef04da67fd3e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If including a key indicator is not a MUST, then you have to specify what t= he receiver does when a key indicator is not present. =A0Could you suggest = text for that?

Thanks,
--Richard


On Thu, Apr 11, 2013 at 8:22 = PM, Dick Hardt <dick.hardt@gmail.com> wrote:
1A, =A0a key indicator SHOULD be includ= ed. (not a MUST)

On Apr 11, 2013, = at 4:59 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

=20 =20 =20
Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a =93kid=94 field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this issue?

<= p class=3D"MsoNormal">1.=A0 Yes.

2.=A0=A0 No.

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th (or earlier).
_______________________________________________
jose mailing list
jose@ietf.org
https://= www.ietf.org/mailman/listinfo/jose


____________________________________= ___________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e0122976239acef04da67fd3e-- From rlb@ipv.sx Mon Apr 15 08:40:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD02821F9404 for ; Mon, 15 Apr 2013 08:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUFa6OoR49Xb for ; Mon, 15 Apr 2013 08:40:43 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CC97521F9401 for ; Mon, 15 Apr 2013 08:40:42 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id va7so4188306obc.6 for ; Mon, 15 Apr 2013 08:40:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=eYVbsb8z9rtHiQWbJ+yLXziBkoOjS970euOPlh3YXt0=; b=W3EOjrQGUmvqPFgtYsPUDFEPyzbcC55/WOy3FawJziYEFqanlyfZJbG/oJh6Cda7RH G9mQx1CiHhGzV+HxYJWr/dcjOm/AkhN/p26UCjrMxiB942ij2Ntn2fT7CUgunwIsvt3p Ab5T/osdQmuAUFxk05ost8d9URHTZcbFKI9pkucIhf/fmzOnL+8uLxsrYZmUB0mbJEN2 49PkJZN3dB+20SKARA3cGzxPoG3OPknaaidBP9vBCvXsFgTs56N7abjONr8tK6efDRvi Cu1ASmPDze3wcwkePyy9udjZD+JWnR8ntaOkJUPCAC6q9HZ2/q+mgpZ2UVOwlC3hAj8W BoEA== MIME-Version: 1.0 X-Received: by 10.182.129.101 with SMTP id nv5mr3607360obb.56.1366040442255; Mon, 15 Apr 2013 08:40:42 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:40:42 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 11:40:42 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8fb1ebe44f4d8004da6813f4 X-Gm-Message-State: ALoCoQkXpLoAqH5KTdaxryBILmqtcbMHos+mTdd2YM0XmSXE8hUCfqCu8trxFijiDfNzXHofR18/ Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:40:43 -0000 --e89a8fb1ebe44f4d8004da6813f4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nice straw man, Mike :) Nobody is arguing that cases with out-of-band negotiation are not important. The question is how they should be supported. What ISSUE-9 and ISSUE-15 are about is saying that the default assumption should be that all communication is via JW* headers. Otherwise, we're not designing a stand-alone protocol, we're designing an adjunct to something else, and we should do it in that WG. That default assumption means that you have to have certain contraints, like a key indicator being REQUIRED. The SPI header is then the "get out of jail free card", releasing you from those constraints. Let's design a real protocol first, then let people cheat. --Richard On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones wr= ote: > Reading this question, I believe that there=92s a possibility for the > question to be misinterpreted, since the sense of the question in the > subject is opposite of the sense of the question in the body. I believe > that the intent of 1 and 2 were as follows:**** > > ** ** > > 1. Yes =96 Use cases where key information is exchanged by means other t= han > the JWS and JWE headers ARE important.**** > > 2. No =96 Use cases where key information is exchanged by means other th= an > the JWS and JWE headers ARE NOT important.**** > > ** ** > > Maybe people could reply with 1 and 2 as above, so that their answers to > the question of whether these use cases are important are not are > unambiguous.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Karen O'Donoghue > *Sent:* Thursday, April 11, 2013 5:00 PM > > *To:* jose@ietf.org > *Subject:* [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory**** > > ** ** > > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests > requiring that a key indicator, such as a =93kid=94 field, be required in= all > JWS and JWE headers. Are use cases where key information is exchanged by > means other than the JWS or JWE headers important? **** > > Which of these best describes your preferences on this issue?**** > > 1. Yes.**** > > 2. No. **** > > 0. I need more information to decide.**** > > **** > > Your reply is requested by Friday, April 19th (or earlier). **** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8fb1ebe44f4d8004da6813f4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nice straw man, Mike =A0:) =A0

Nobody is arguing that ca= ses with out-of-band negotiation are not important. =A0The question is how = they should be supported.

What ISSUE-9 and ISSUE-1= 5 are about is saying that the default assumption should be that all commun= ication is via JW* headers. =A0Otherwise, we're not designing a stand-a= lone protocol, we're designing an adjunct to something else, and we sho= uld do it in that WG. =A0That default assumption means that you have to hav= e certain contraints, like a key indicator being REQUIRED. =A0The SPI heade= r is then the "get out of jail free card", releasing you from tho= se constraints.

Let's design a real protocol first, then let people= cheat.

--Richard


On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Reading this question, I = believe that there=92s a possibility for the question to be misinterpreted,= since the sense of the question in the subject is opposite of the sense of the question in the body.=A0 I believe that the intent of = 1 and 2 were as follows:

=A0<= /p>

1.=A0 Yes =96 Use cases w= here key information is exchanged by means other than the JWS and JWE heade= rs ARE important.

2.=A0 No =96 Use cases wh= ere key information is exchanged by means other than the JWS and JWE header= s ARE NOT important.

=A0<= /p>

Maybe people could reply = with 1 and 2 as above, so that their answers to the question of whether the= se use cases are important are not are unambiguous.

=A0<= /p>

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

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM

<= br> To: jose@ietf.org=
Subject: [jose] Feedback request on jose tracker issue #15: Should a= t least on key indicator be mandatory

=A0

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring t= hat a key indicator, such as a =93kid=94 field, be required in all JWS and = JWE headers. Are use cases where key information is exchanged by means othe= r than the JWS or JWE headers important?

Which of these best describes your preferences on th= is issue?

1.=A0 Yes.

2.=A0=A0 No.

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th (or earlier).


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8fb1ebe44f4d8004da6813f4-- From rlb@ipv.sx Mon Apr 15 08:41:53 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8AA21F93F4 for ; Mon, 15 Apr 2013 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BguxDmKTR3ZU for ; Mon, 15 Apr 2013 08:41:52 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A753E21F9401 for ; Mon, 15 Apr 2013 08:41:48 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id un3so4306923obb.11 for ; Mon, 15 Apr 2013 08:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Q69tuIPBbAEzxG1EQ6teUHOFgwvdmo+Bzvuz87wNr9U=; b=YvGYntpmQeIsg+IrEt9QYEVfjvAWF6Jy7wpWSEHr3yjTV5x1ZsGU+WsB28KDTL2kZg rkaERo2Xg1IoWSD3YfA2BJ2Qegrg8D1MVYO1ewpsQKTOBzqtpVf0ay0dKGzOJGdrmWEo 8BFELcQmI22zeh6DDU9kvdy703RDRdb5KLU5hjt6gEyHan4EQc9Oao9j0w0BMbgwBIQP bNm7VNTBcLdepffxMLOmfc+fNswuKu8yaz/PozJQp8ej0rgCWd8if2RwbgcopDBNeNT4 tXzjHZ214eaCO/ldCz51j5vw/gUvMsnwyZ75f1DLyiSzecszdqs+leMDsJgfwUn0YDqq HsOw== MIME-Version: 1.0 X-Received: by 10.60.15.98 with SMTP id w2mr7869110oec.128.1366040503354; Mon, 15 Apr 2013 08:41:43 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:41:43 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: <35633DAD-58BB-42C3-86BE-81A0FA0402CB@gmail.com> References: <51674E17.5020902@isoc.org> <35633DAD-58BB-42C3-86BE-81A0FA0402CB@gmail.com> Date: Mon, 15 Apr 2013 11:41:43 -0400 Message-ID: From: Richard Barnes To: Dick Hardt Content-Type: multipart/alternative; boundary=089e013a0a1ef3954a04da6816f5 X-Gm-Message-State: ALoCoQkWnwwcYd9//qKUYWi/K/NygYTD3Gd9EQh7Wk8Z+RrC0z0pDfuRT2ni2FEB8HH0khBnxsZo Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:41:53 -0000 --089e013a0a1ef3954a04da6816f5 Content-Type: text/plain; charset=ISO-8859-1 If people could say why they have certain opinions, that would be helpful. --Richard On Thu, Apr 11, 2013 at 8:16 PM, Dick Hardt wrote: > 1 > > On Apr 11, 2013, at 4:58 PM, Karen O'Donoghue wrote: > > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out > that the JWA algorithm identifiers are different than those used by the W3C > WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm > identifiers are strings, whereas the W3C WebCrypto algorithm identifiers > are structures including string identifiers. The working group had > previously decided to continue representing JOSE algorithms as strings, as > recorded at > http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. > **** > > > Which of these best describes your preferences on this issue?**** > > 1. Continue have the JWA algorithm identifiers be strings, and not > objects. Note that WebCrypto may choose to use some of these same strings, > where applicable.**** > > 2. Switch to using the algorithm identifier structures defined in the > WebCrypto draft.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > Your reply is requested by Friday, April 19th or earlier. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e013a0a1ef3954a04da6816f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If people could say why they have certain opinions, that would be helpful.<= div>--Richard


On Thu, Apr 11, = 2013 at 8:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:=
1
On Apr 11, 2013, at 4:58 PM, Karen O'= ;Donoghue <odono= ghue@isoc.org> wrote:

=20 =20 =20
Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http:/= /www.w3.org/TR/WebCryptoAPI/.=A0 The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.=A0 The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.<= br>


Which of these best describes your preferences on this issue?

1.=A0 Continue have the JWA algorithm identifiers be strings, and not objects.=A0 Note that WebCrypto may choose to use some of these same strings, where applicable.

2.= =A0 Switch to using the algorithm identifier structures defined in the WebCrypto draft.=

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.



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


____________________________________= ___________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e013a0a1ef3954a04da6816f5-- From rlb@ipv.sx Mon Apr 15 08:43:14 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A3421F93CC for ; Mon, 15 Apr 2013 08:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDl5KFn765yG for ; Mon, 15 Apr 2013 08:43:13 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BC94121F912C for ; Mon, 15 Apr 2013 08:43:13 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id dn14so99208obc.27 for ; Mon, 15 Apr 2013 08:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=QMOioU9/NIvPitQNg+M9ZfFuVJUn3p8nLyLXgVsd75g=; b=aBkvyAqbRPTyv426EPYt+8X4YqsmkUcSnDMKmqnwblhN+ek5k73ONtcd/NSTSyM8ab V00yJywhMGmyEsFxQLjjdZDvv9qzDPfd9+xnUbGD5GH3N7T1kNBX46lpeqCIKwjUpvM7 kn5+w3j0cqSokAmewXTAzJKDr1DQh/FKMUYH+zXi7AKBmu4diCTnX7ov4GHeDfUsHRQ6 ldzoVT2MdpFkOrU4b5e9YPS4dYubYCOyH3qSQ0pDLyW0aO4zMeNFtFWPwpItmz6GlUUb PCimJxDEwF9uigxnYl3OeqxpAO9y06MB8hFkGolEAtXohw/Im0fhw5Lg9iLkBOtem3lw B7Lw== MIME-Version: 1.0 X-Received: by 10.60.62.39 with SMTP id v7mr2452795oer.5.1366040593279; Mon, 15 Apr 2013 08:43:13 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 08:43:13 -0700 (PDT) X-Originating-IP: [66.207.95.33] In-Reply-To: <51674E17.5020902@isoc.org> References: <51674E17.5020902@isoc.org> Date: Mon, 15 Apr 2013 11:43:13 -0400 Message-ID: From: Richard Barnes To: odonoghue@isoc.org Content-Type: multipart/alternative; boundary=089e013a005a4fb5b404da681c81 X-Gm-Message-State: ALoCoQlj49l7ua6UMuC16Audbbl9S9f7pSQTqxA521tQ7xchRmfOv04AiRnkp1ZdWQuBdRKFXiVh Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:43:14 -0000 --089e013a005a4fb5b404da681c81 Content-Type: text/plain; charset=ISO-8859-1 2b. Switch to a structure more like the WebCrypto structure, in which algorithm parameters are collected alongside the algorithm name -- and separately from key encipherment parameters. Cf. [draft-barnes-jose-key-wrapping] On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue wrote: > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out > that the JWA algorithm identifiers are different than those used by the W3C > WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm > identifiers are strings, whereas the W3C WebCrypto algorithm identifiers > are structures including string identifiers. The working group had > previously decided to continue representing JOSE algorithms as strings, as > recorded at > http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. > **** > > > Which of these best describes your preferences on this issue?**** > > 1. Continue have the JWA algorithm identifiers be strings, and not > objects. Note that WebCrypto may choose to use some of these same strings, > where applicable.**** > > 2. Switch to using the algorithm identifier structures defined in the > WebCrypto draft.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > Your reply is requested by Friday, April 19th or earlier. > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e013a005a4fb5b404da681c81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2b. Switch to a structure more like the WebCrypto structure, in which = algorithm parameters are collected alongside the algorithm name -- and sepa= rately from key encipherment parameters.

Cf. [draft-bar= nes-jose-key-wrapping]



On Thu, Apr 11= , 2013 at 7:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:
=20 =20 =20
Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http:/= /www.w3.org/TR/WebCryptoAPI/.=A0 The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.=A0 The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.<= br>


Which of these best describes your preferences on this issue?

1.=A0 Continue have the JWA algorithm identifiers be strings, and not objects.=A0 Note that WebCrypto may choose to use some of these same strings, where applicable.

2.=A0 Switch to using the algorithm identifier structures defined in the WebCrypto draft.<= /span>

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e013a005a4fb5b404da681c81-- From Michael.Jones@microsoft.com Mon Apr 15 08:45:21 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4B721F9409 for ; Mon, 15 Apr 2013 08:45:21 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fe7ckBGx0Pw for ; Mon, 15 Apr 2013 08:45:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD3721F9404 for ; Mon, 15 Apr 2013 08:45:18 -0700 (PDT) Received: from BL2FFO11FD015.protection.gbl (10.173.161.202) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 15:45:17 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 15:45:16 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 15:45:01 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: AQHONxCooSd2LAEBTkqzIVwx4JWauZjSDFgAgAVkswCAAABasA== Date: Mon, 15 Apr 2013 15:45:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641542@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367641542TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(5383001)(24454001)(199002)(377454001)(20776003)(18277545001)(564824004)(56776001)(31966008)(16406001)(18276755001)(55846006)(5343655001)(47446002)(33656001)(53806001)(54356001)(80022001)(4396001)(59766001)(50986001)(77982001)(51856001)(47976001)(74662001)(81542001)(512954001)(76482001)(63696002)(81342001)(79102001)(74502001)(66066001)(46102001)(47736001)(49866001)(71186001)(56816002)(5343635001)(44976003)(69226001)(15202345002)(54316002)(65816001)(16236675002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB030; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:45:21 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367641542TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You could say "nice straw man, Jim", as it was Jim Schaad who proposed that= the right question to ask was whether such use cases are important or not.= I agree with Jim that clearly if they are important/in scope, then key in= dicators in the headers can't be mandatory. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, April 15, 2013 8:41 AM To: Mike Jones Cc: odonoghue@isoc.org; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory Nice straw man, Mike :) Nobody is arguing that cases with out-of-band negotiation are not important= . The question is how they should be supported. What ISSUE-9 and ISSUE-15 are about is saying that the default assumption s= hould be that all communication is via JW* headers. Otherwise, we're not d= esigning a stand-alone protocol, we're designing an adjunct to something el= se, and we should do it in that WG. That default assumption means that you= have to have certain contraints, like a key indicator being REQUIRED. The= SPI header is then the "get out of jail free card", releasing you from tho= se constraints. Let's design a real protocol first, then let people cheat. --Richard On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones > wrote: Reading this question, I believe that there's a possibility for the questio= n to be misinterpreted, since the sense of the question in the subject is o= pposite of the sense of the question in the body. I believe that the inten= t of 1 and 2 were as follows: 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. 2. No - Use cases where key information is exchanged by means other than t= he JWS and JWE headers ARE NOT important. Maybe people could reply with 1 and 2 as above, so that their answers to th= e question of whether these use cases are important are not are unambiguous= . -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Thursday, April 11, 2013 5:00 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19th (or earlier). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367641542TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You could say “nice= straw man, Jim”, as it was Jim Schaad who proposed that the right qu= estion to ask was whether such use cases are important or not.  I agre= e with Jim that clearly if they are important/in scope, then key indicators = in the headers can’t be mandatory.

 <= /p>

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

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, April 15, 2013 8:41 AM
To: Mike Jones
Cc: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Shou= ld at least on key indicator be mandatory

 

Nice straw man, Mike  :)  

 

Nobody is arguing that cases with out-of-band negoti= ation are not important.  The question is how they should be supported= .

 

What ISSUE-9 and ISSUE-15 are about is saying that t= he default assumption should be that all communication is via JW* headers. =  Otherwise, we're not designing a stand-alone protocol, we're designin= g an adjunct to something else, and we should do it in that WG.  That default assumption means that you have= to have certain contraints, like a key indicator being REQUIRED.  The= SPI header is then the "get out of jail free card", releasing yo= u from those constraints.

 

Let's design a real protocol first, then let people = cheat.

 

--Richard

 

 

On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Reading this question, I believe that t= here’s a possibility for the question to be misinterpreted, since the sense of the question in the subject is opposite of the sense of= the question in the body.  I believe that the intent of 1 and 2 were = as follows:

 

1.  Yes – Use cases where ke= y information is exchanged by means other than the JWS and JWE headers ARE important.

2.  No – Use cases where key= information is exchanged by means other than the JWS and JWE headers ARE NOT important.

 

Maybe people could reply with 1 and 2 a= s above, so that their answers to the question of whether these use cases are important are not are unambiguous.

 

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

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM


To: jose@ietf.org=
Subject: [jose] Feedback request on jose tracker issue #15: Should a= t least on key indicator be mandatory

 

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requir= ing that a key indicator, such as a “kid” field, be required in= all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers import= ant?

Which of these best describes your preferences on this issue?=

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th (or earli= er).


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367641542TK5EX14MBXC283r_-- From mamille2@cisco.com Mon Apr 15 08:51:03 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221121F940E for ; Mon, 15 Apr 2013 08:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFWOFTWVBHWP for ; Mon, 15 Apr 2013 08:51:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6E71121F940A for ; Mon, 15 Apr 2013 08:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6551; q=dns/txt; s=iport; t=1366041061; x=1367250661; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Wdf6pyRSDzVfRYkMolT8qdDE7X7M8u79f+EOcGOWlfI=; b=Zbcg5YPpRxG9nP8Xps5svfJzic4waxxQ4kfz3tklLfcuBUs6Ds3+lVir tEIYU85120Q/CpT27STDdMz9EkHTDEfHR7Rfgc4DxRFaGPqsy/vdAh3EE J0kkOOJxofJD8v7nVUr01qOEwsvuFdkcL+MXaz8+G9jbAMG5SwL8iGfsf 4=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAAUhbFGrRDoI/2dsb2JhbABQgwbBOoEHFnSCHwEBAQR5BQsLDgouAlUGE4gCAw6yDR2JTY1ggTcHgmBhA4kFhk+HMYYFiwyDKh2BLw X-IronPort-AV: E=Sophos;i="4.87,476,1363132800"; d="p7s'?scan'208";a="76142439" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Apr 2013 15:51:00 +0000 Received: from [10.129.24.59] ([10.129.24.59]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3FFowAC020233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Apr 2013 15:50:58 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_2AF97ACA-A06A-4A34-9077-7DFC3AB0E11A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Matt Miller In-Reply-To: Date: Mon, 15 Apr 2013 09:50:57 -0600 Message-Id: <57A12B7F-30D2-4406-A66F-1FA0B03B4313@cisco.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com> <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com> <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) Cc: "cfrg@irtf.org" , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] GCM nonce reuse question X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 15:51:03 -0000 --Apple-Mail=_2AF97ACA-A06A-4A34-9077-7DFC3AB0E11A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 15, 2013, at 9:25 AM, Richard Barnes wrote: > On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: >=20 >> I think there are more options for handling multiple recipients of >> AEAD-secured content: >>=20 >>=20 >> Option 3: Put all per-recipient info into one header; keep this = header >> under the AEAD integrity check; have one nonce. >> COST: All recipients need to be known (and their key exchange info >> created) before the AEAD algorithm is applied. >> COST: The JWE JSON header structure needs to be adjusted (eg to have = an >> array of recipient info) so it is not backward compatible with = current >> drafts. >> COST: Doesn't help use cases where one recipient forwards an >> AEAD-secured message on to a new recipient (eg an XMPP system = receives a >> message secured for a user and re-secures it for a specific device of = that >> user). Changing recipients requires reapplying the AEAD operations. >> COST: Each recipient needs to see key exchange info of all = recipients >> (privacy impact?). >> POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content = is >> secured as a complete unit. >>=20 >>=20 >> Option 2b: Remove per-recipient info from AEAD integrity check; but = add >> AEAD details to each key exchange. For instance, info about an AEAD >> operation (alg id, key id etc) potentially even including the whole >> ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT = operation that >> encrypts the AEAD secret key for a recipient. >> BENEFIT: The key exchange is tied to a specific AEAD operation. >> COST: Crypto is not typically done like this; uncertain as to what = exact >> security properties you are getting. Perhaps there are some = similarities to >> NIST Concat KDF that adds "context" to key derivation: this adds = "context" >> about an AEAD operation to the key exchange. >>=20 >>=20 >> I agree with Richard Barnes that the per-recipient key exchange = details >> should be outside the AEAD operation (not covered by the AEAD = integrity >> check). Go with option 2 or 2b. >> Then, separately, we can decide which details of the AEAD operation = should >> be bound to each key exchange: none? AEAD key length? AEAD alg id? = whole >> AEAD header? AEAD ciphertext? other context? >>=20 >>=20 >> -- >> James Manger >>=20 >>=20 >=20 > At the same time, this attribute should be optional, since I think = there > are use cases where the CMK is not entirely ephemeral. For example, I > think the current XMPP e2e document uses it as a session key rather = than an > individual message key, so you wouldn't want to limit the key to a = single > JWE. >=20 XMPP e2e has both a session key and a per-message key. The per-message = key is protected by the session key. That said, I also think Option 2 or 2b makes the most sense. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_2AF97ACA-A06A-4A34-9077-7DFC3AB0E11A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQxNTE1NTA1OFowIwYJKoZIhvcNAQkEMRYEFA9xySUejeUd5B3OIPs2Pp0DCSAWMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBHBj6pCJL/Jzt9tZr0hIC4uJ2Cj1FxtgEMsuKHPPiD LQtu04+q7/J9nyEHpItUom/usZdjicBK8zowme3PSA1UKp1Kry2Eazx+HCw7vQwAH2cO1YlzYp9A MyXg1zo8NIyzaq2mWjGWx/FyxFerFNXVwMG2zoa54B3fhpSObOVlFzRnxDN3wFBdLuxPjHDshicG bjjcQYePLjgcrm3u1xwakdZH+nz1tP/bXQGHO7bSOrZXA/EvXK8xzG7fx6JaHhb1qE2g8ChRtqgY yztWyd93Cxe7i9z1BM1c1DSceFfHGab+zpP2/QZ0mXYW8d15AOXlA6iYX82Ina2NFdJCpRXOAAAA AAAA --Apple-Mail=_2AF97ACA-A06A-4A34-9077-7DFC3AB0E11A-- From matake@gmail.com Mon Apr 15 09:00:31 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE0821F8F50 for ; Mon, 15 Apr 2013 09:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, RELAY_IS_220=2.118] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1fSaSAjjQTl for ; Mon, 15 Apr 2013 09:00:28 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 332EB21F944B for ; Mon, 15 Apr 2013 08:59:11 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id p1so2134703dad.13 for ; Mon, 15 Apr 2013 08:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=ua5OaInblB85fB0NMz51GQvmFm9JP9kdGmKWv3n61Cw=; b=SRfJTX07R4qLOvfz0SxibvyqAI1hwSe/+Bq0hFhV/Wduo2+0o8RJxcbaTn/kEiTIU8 WMv7VvTN8NhwwR+tv+ioYVwGnEh3Gyug4l9aBIDlzs1wy4UiM0JrzzvhSiWWa8xi8Anu B3O4TBGfNI8/WuhSsC8aNUl/8Jw7fPH3kiwcFY2cd2LbHe8klKKxU/FtKVsF4kI9b3Ft PXtFfj9qZjINNfsCkpjy/AXEfiEWMW6z0wmsqJ076XmRSaqShHAiJuCKl+YIV0pio0Ok MP3BHtJTf4GQsK1YXoyW8FDaPoORap/LUqvJo+ElCV4S5zeBq7pHWfDm6I+HhWkyQ61C GKcA== X-Received: by 10.68.130.194 with SMTP id og2mr30227528pbb.101.1366041549501; Mon, 15 Apr 2013 08:59:09 -0700 (PDT) Received: from [192.168.1.33] (s146003.dynamic.ppp.asahi-net.or.jp. [220.157.146.3]) by mx.google.com with ESMTPS id fq1sm20781140pbb.33.2013.04.15.08.59.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:59:08 -0700 (PDT) References: <51674E2D.3040604@isoc.org> <4E1F6AAD24975D4BA5B1680429673943676410FC@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676410FC@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <72C48E43-190F-4CBA-8757-404FD9BBF774@gmail.com> X-Mailer: iPhone Mail (10B329) From: nov matake Date: Tue, 16 Apr 2013 00:59:03 +0900 To: Mike Jones Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:00:31 -0000 1 nov On Apr 16, 2013, at 12:18 AM, Mike Jones wrote= : > 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ro= land Hedberg > Sent: Sunday, April 14, 2013 1:35 AM > To: odonoghue@isoc.org > Cc: jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we a= dd a "spi" header field? >=20 > 1 >=20 > 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : >=20 > Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding a= n "spi" (security parameters index) header parameter to the JWS and JWE spec= ifications. This modification to the JOSE formats would allow for signaling= that pre-negotiated cryptographic parameters are being used, rather than in= cluding those parameters in the JWS or JWE header. This proposal has been w= ritten up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. >=20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. >=20 > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. >=20 > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. >=20 > 4. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Mon Apr 15 09:01:31 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BECA21F95DE for ; Mon, 15 Apr 2013 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.142 X-Spam-Level: X-Spam-Status: No, score=-0.142 tagged_above=-999 required=5 tests=[AWL=2.061, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSTi4XVUWlPv for ; Mon, 15 Apr 2013 09:01:30 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF521F949F for ; Mon, 15 Apr 2013 08:59:56 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id kq13so2618919pab.29 for ; Mon, 15 Apr 2013 08:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=inFdmUhkKV5fY7Q4US2kHVsqHGoh8VPl9W59giNayTo=; b=zImJhwxthU9f9NlL4nZBV30yWVvz7yLaOBDXMCStTYT6Fa7C9Ffxg95hRFsyq7YdoS +9uqUgNUiWT77mTWTs/QNciIfnr1KrdEK/QwEDBgmDEVXCeut7slpVnskjkwYJO9vk0S aBkr9m3VdpmjdV8B1ayUMqba54MB+EyQSy+PKixJUa8q1ru8NDsEPyw07bOd2USe2B/5 k+cAbw4UwK3rCW/y8P92Bn/zBPd73gRdPtish/43auVl8f2umiupXzvfuru0Fad5diFv JghuzBhpoV+Jwz9DvIQOC7Hx8rx9Bx0l9DnpuZAeIUxrKM3dID37E1vTiB41017duu4O NpOA== X-Received: by 10.66.175.73 with SMTP id by9mr30017027pac.191.1366041595733; Mon, 15 Apr 2013 08:59:55 -0700 (PDT) Received: from [192.168.1.33] (s146003.dynamic.ppp.asahi-net.or.jp. [220.157.146.3]) by mx.google.com with ESMTPS id fq1sm20781140pbb.33.2013.04.15.08.59.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:59:54 -0700 (PDT) References: <51674E3D.7030004@isoc.org> <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8AE6429D-18F0-4479-9D40-314C5CE87841@gmail.com> X-Mailer: iPhone Mail (10B329) From: nov matake Date: Tue, 16 Apr 2013 00:59:52 +0900 To: Mike Jones Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:01:31 -0000 1 nov On Apr 16, 2013, at 12:20 AM, Mike Jones wrote= : > 1. Continue having separate Ciphertext, Initialization Vector, and Integr= ity Value values in the JWE representation. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ro= land Hedberg > Sent: Saturday, April 13, 2013 12:19 PM > To: odonoghue@isoc.org > Cc: jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we u= se RFC 5116 and remove the JWE Integrity Value field? >=20 > 1 >=20 > 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : >=20 > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restr= ucturing the JWE representation to remove the JWE Integrity Value field and i= nstead use the RFC 5116 (AEAD) binary serialization to represent the Ciphert= ext, Initialization Vector, and Integrity Value values. If this proposal is= adopted, JWEs would then have three fields - the header, the encrypted key,= and the RFC 5116 combination of the Ciphertext, Initialization Vector, and I= ntegrity Value values.=20 > This issue is also related to issue #3. Note that the updated McGrew draf= t described there could be used whether or not we switched to using RFC 5116= . >=20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue having separate Ciphertext, Initialization Vector, and Integr= ity Value values in the JWE representation. >=20 > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the com= bination of these three values. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 >=20 >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Mon Apr 15 09:03:49 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9721F93C8 for ; Mon, 15 Apr 2013 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QntSbqMDEdcp for ; Mon, 15 Apr 2013 09:03:49 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6900521F958B for ; Mon, 15 Apr 2013 09:03:45 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id mc17so2614462pbc.28 for ; Mon, 15 Apr 2013 09:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=dAxdHOJalXSAp99aLyUBD/5TmA/4TpvAHdIgFVAuxaE=; b=nvzadSaOA0ZOuj73svetGf86uiVdpYHK/3yho+CFsDOQ4YgbvkpSHldeZARHSDHOJH I/QHiLRtsL+/vMohaoaM3g+WxQ9MH5Un5MDCOp+zs17di6GiMUwR9lIERSMHsNe5OH7U +r5jRv0QtS1O1S2ZblOXYWmjGVc6jshZ2YUDo9E/eWUhywto11SawlYtsWxCCCnghqpP 0FE07ozLFTCr2TBOWp88hknYAXJkN/9JuDbWlcn1uXaM8HV+e+AZhUoL3g/I7eGetnf6 tckEzMzEdBL+kmJxFLBRoCfOkwX4wruitqqAYIMOtZxuBjHMgXzKqqRAWdvBOMjc/TEp h5Ng== X-Received: by 10.69.0.226 with SMTP id bb2mr11982555pbd.34.1366041825202; Mon, 15 Apr 2013 09:03:45 -0700 (PDT) Received: from [192.168.1.33] (s146003.dynamic.ppp.asahi-net.or.jp. [220.157.146.3]) by mx.google.com with ESMTPS id n6sm5932053pbn.6.2013.04.15.09.03.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 09:03:44 -0700 (PDT) References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: nov matake Date: Tue, 16 Apr 2013 01:03:39 +0900 To: Mike Jones Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:03:49 -0000 1 nov On Apr 16, 2013, at 12:24 AM, Mike Jones wrote= : > 1. Yes - Use cases where key information is exchanged by means other than= the JWS and JWE headers ARE important. >=20 > -----Original Message----- > From: Roland Hedberg [mailto:roland.hedberg@adm.umu.se]=20 > Sent: Sunday, April 14, 2013 1:33 AM > To: odonoghue@isoc.org > Cc: jose@ietf.org; Mike Jones > Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory >=20 > I support 1 as defined by Mike. >=20 > 12 apr 2013 kl. 07:25 skrev Mike Jones : >=20 >> 1. Yes - Use cases where key information is exchanged by means other tha= n the JWS and JWE headers ARE important >=20 > -- Roland >=20 > From: Mike Jones=20 > Sent: Thursday, April 11, 2013 10:25 PM > To: 'odonoghue@isoc.org'; jose@ietf.org > Subject: RE: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory >=20 > Reading this question, I believe that there's a possibility for the questi= on to be misinterpreted, since the sense of the question in the subject is o= pposite of the sense of the question in the body. I believe that the intent= of 1 and 2 were as follows: >=20 > 1. Yes - Use cases where key information is exchanged by means other than= the JWS and JWE headers ARE important. > 2. No - Use cases where key information is exchanged by means other than t= he JWS and JWE headers ARE NOT important. >=20 > Maybe people could reply with 1 and 2 as above, so that their answers to t= he question of whether these use cases are important are not are unambiguous= . >=20 > -- Mike >=20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ka= ren O'Donoghue > Sent: Thursday, April 11, 2013 5:00 PM > To: jose@ietf.org > Subject: [jose] Feedback request on jose tracker issue #15: Should at leas= t on key indicator be mandatory >=20 > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requ= iring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means oth= er than the JWS or JWE headers important?=20 > Which of these best describes your preferences on this issue? > 1. Yes. > 2. No.=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th (or earlier). > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Mon Apr 15 09:05:39 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6221F95EA for ; Mon, 15 Apr 2013 09:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHkbbCQNRZGC for ; Mon, 15 Apr 2013 09:05:39 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2B71221F95E9 for ; Mon, 15 Apr 2013 09:05:39 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so2587933pdj.20 for ; Mon, 15 Apr 2013 09:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=70pj55g416fRDf62ZtFsHfhMlCu/l6O1Mw17N4Kkohk=; b=Pxi26YZ6x+6fHVlsZiOndv8DNkp3P6R3fhuCOl1XzwIU5occToZWOcbsAzHGapP3os jlhRgVp9tSUoa3DH+vzIEZB4ltqxo1M0Zs+0vCTFWuk0zVSff5/rlpZoteZ8A3YAbWlL sbhkNKy10d/ieJBYIPlYvN0HjvHPVGVt87cqy0cSxCbkeaicYBMyDG9Yorsg3hUR4T1l bjArDxLkWdKAp3qo4IR59E/ojVmUzij1FcKNmgfQ70IUoIVLtVdBiTKFtIe508FXZSAw 9yxry/ikaAGiqiGfaeEjIOpHehbm8YsrOXX47ogzdXlLbXcFGdOspRk5Apf7blSPLleZ 1zGQ== X-Received: by 10.66.8.34 with SMTP id o2mr29909292paa.182.1366041938909; Mon, 15 Apr 2013 09:05:38 -0700 (PDT) Received: from [192.168.1.33] (s146003.dynamic.ppp.asahi-net.or.jp. [220.157.146.3]) by mx.google.com with ESMTPS id ef4sm20791301pbd.38.2013.04.15.09.05.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 09:05:37 -0700 (PDT) References: <51674E17.5020902@isoc.org> <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> Mime-Version: 1.0 (1.0) In-Reply-To: <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2EC89E23-1BAB-4BFB-B489-B9C73776AB0E@gmail.com> X-Mailer: iPhone Mail (10B329) From: nov matake Date: Tue, 16 Apr 2013 01:05:33 +0900 To: Roland Hedberg Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:05:39 -0000 1 nov On Apr 14, 2013, at 4:17 AM, Roland Hedberg wrot= e: > 1 >=20 > 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : >=20 >> Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that= the JWA algorithm identifiers are different than those used by the W3C WebC= rypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identi= fiers are strings, whereas the W3C WebCrypto algorithm identifiers are struc= tures including string identifiers. The working group had previously decide= d to continue representing JOSE algorithms as strings, as recorded at http:/= /www.ietf.org/mail-archive/web/jose/current/msg01219.html. >>=20 >> Which of these best describes your preferences on this issue? >>=20 >> 1. Continue have the JWA algorithm identifiers be strings, and not objec= ts. Note that WebCrypto may choose to use some of these same strings, where= applicable. >>=20 >> 2. Switch to using the algorithm identifier structures defined in the We= bCrypto draft. >>=20 >> 3. Another resolution (please specify in detail). >>=20 >> 0. I need more information to decide. >>=20 >> Your reply is requested by Friday, April 19th or earlier.=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Apr 15 09:25:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6497B21F93DF for ; Mon, 15 Apr 2013 09:25:29 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KabKMcKhcaJ3 for ; Mon, 15 Apr 2013 09:25:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 94ADC21F912C for ; Mon, 15 Apr 2013 09:25:11 -0700 (PDT) Received: from BY2FFO11FD022.protection.gbl (10.1.15.204) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 16:25:33 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:25:33 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 16:24:45 +0000 From: Mike Jones To: "Manger, James H" Thread-Topic: [jose] #16: URI identifying a specific key in a JWK set Thread-Index: AQHOKPFt1UwdLuDfz0WljLLGMUo+yJjGVMwAgBA7dQCAAOD2AIAAFguQ Date: Mon, 15 Apr 2013 16:24:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367641877@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <073.1dc661959a15caad46917baec89b3440@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150C74DB3E@WSMSG3153V.srv.dir.telstra.com> <516C07EE.8000306@mitre.org> In-Reply-To: <516C07EE.8000306@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(20776003)(55846006)(33656001)(46102001)(73894001)(54316002)(69226001)(31966008)(621065001)(50986001)(16406001)(74502001)(50466001)(66066001)(47446002)(23676002)(47736001)(74662001)(59766001)(79102001)(56816002)(76482001)(81542001)(49866001)(53806001)(47776003)(77982001)(65816001)(54356001)(81342001)(56776001)(44976003)(80022001)(63696002)(4396001)(47976001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB020; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:25:29 -0000 UmVxdWlyaW5nIGltcGxlbWVudGF0aW9uIG9mIEpTT04tUG9pbnRlciBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2OTAxIGp1c3QgdG8gdXNlIGEgSldLIFNldCBzZWVtcyBXQVkgb3ZlciB0 aGUgdG9wIHRvIG1lLiAgUGxlYXNlIGhhdmUgc29tZSBjb25zaWRlcmF0aW9uIGZvciB0aGUgZGV2 ZWxvcGVycyB3aG8gd2FudCB0byBhY3R1YWxseSBidWlsZCBhbmQgdXNlIHRoZSBKT1NFIHNwZWNz ISAgQWN0dWFsIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IGlzIGEgZ29hbCBoZXJlLg0K DQpJIG9iamVjdCB0byBtb3ZpbmcgdGhlIEtleSBJRCBmaWVsZCBvdXQgb2YgdGhlIEpXSyBmb3Ig dGhlIHJlYXNvbnMgaWRlbnRpZmllZCBieSBKdXN0aW4uICBTcGVjaWZpY2FsbHksIHdlIHdhbnQg dGhlIEtleSBJRCB0byBiZSB1c2FibGUgZm9yIEpXS3MgLSBub3QganVzdCBKV0sgU2V0cy4NCg0K SSBhbHNvIG9iamVjdCB0byB0aGUgYXN5bW1ldHJ5IG9mIHRoaXMgcHJvcG9zYWwuICBIYXZpbmcg b25lIGtleSBhdHRyaWJ1dGUgKHRoZSBLZXkgSUQpIG5vdCBiZSBwYXJ0IG9mIHRoZSBKV0ssIHdo ZXJlIG90aGVycyBzdWNoIGFzICJ1c2UiIGFuZCAiYWxnIiBhcmUganVzdCBtYWtlcyB0aGluZ3Mg bW9yZSBjb21wbGljYXRlZC4gIEFsbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBK V0sgc3RydWN0dXJlIC0gbm90IGp1c3Qgc29tZSBvZiB0aGVtLg0KDQpUaGF0J3MgaG93IEkgc2Vl IGl0LCBhbnl3YXkuLi4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IE1vbmRheSwgQXByaWwgMTUs IDIwMTMgNzowMCBBTQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6IGpvc2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbam9zZV0gIzE2OiBVUkkgaWRlbnRpZnlpbmcgYSBzcGVjaWZpYyBrZXkgaW4g YSBKV0sgc2V0DQoNCkkgbGlrZSB0aGlzIHN0cnVjdHVyYWwgcHJvcG9zYWwgd2l0aCBvbmUgY2F2 ZWF0OiBtb3ZpbmcgdGhlIGtleSBJRCBvdXQgb2YgdGhlIGtleSBzdHJ1Y3R1cmUgbWVhbnMgdGhh dCBhIEpXSyBjYW4gbm8gbG9uZ2VyIGJlIGEgc2VsZi1jb250YWluZWQgdW5pdCB3aXRoIGFsbCBv ZiB0aGUgbWV0YWRhdGEgdGhhdCBpdCBjb250YWlucyB0b2RheS4gSXMgdGhhdCB3aGF0IHdlIHdh bnQ/IERvIHdlIHdhbnQgdG8gZGVjbGFyZSB0aGF0IGEga2V5IGlkIG9ubHkgbWFrZXMgc2Vuc2Ug aW4gdGhlIGNvbnRleHQgb2YgYSBKV0sgU2V0IGFuZCBub3QgYW4gaW5kaXZpZHVhbCBKV0s/IEEg c2ltcGxlIHdvcmthcm91bmQgd291bGQgYmUgdG8gaGF2ZSBib3RoIHRoZSBvYmplY3QtYmFzZWQg c3RydWN0dXJlIGFzIHdlbGwgYXMgdGhlIHZhbHVlIHdpdGhpbiB0aGUgSldLIGl0c2VsZiBhbmQg dGhhdCB0aGV5IE1VU1QgbWF0Y2guDQoNCiAgLS0gSnVzdGluDQoNCk9uIDA0LzE0LzIwMTMgMDg6 MzUgUE0sIE1hbmdlciwgSmFtZXMgSCB3cm90ZToNCj4+ICMxNjogVVJJIGlkZW50aWZ5aW5nIGEg c3BlY2lmaWMga2V5IGluIGEgSldLIHNldA0KPj4+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL2pvc2UvdHJhYy90aWNrZXQvMTYNCj4+ICAgSW4gb3JkZXIgdG8gZXZhbHVhdGUgdGhpcywg d2UgbmVlZCB0byBnZXQgYSBtb3JlIGRldGFpbGVkIHByb3Bvc2FsDQpCZWxvdyBpcyBhIG1vcmUg ZGV0YWlsZWQgcHJvcG9zYWwuIFRoZSBiYXNpYyBpZGVhIGlzIHRvIG1ha2UgdGhlIEpXSyBrZXkg c2V0IHN5bnRheCBhIGJpdCBtb3JlIHNlbnNpYmxlIChrZXlzIG5hbWVkIGJ5IHRoZWlyIGlkczsg aW5zdGVhZCBvZiBhICJrZXlzIiBlbGVtZW50IGhvbGRpbmcgYW4gYXJyYXkgb2Yga2V5cyk7IGdp dmUga2V5IHNldHMgYSBtZWRpYSB0eXBlOyBhbmQgZGVmaW5lIHRoZSBmcmFnbWVudCB0byBiZSBh IEpTT04gcG9pbnRlciBbUkZDIDY5MDFdLiBUaGVuIGEgVVJJIGNhbiBpZGVudGlmeSBhIHNwZWNp ZmljIGtleS4gQSAiamt1IiB2YWx1ZSBjYW4gcHJlY2lzZWx5IGluZGljYXRlIHRoZSBrZXkgbmVl ZGVkIHRvIHByb2Nlc3MgYSBKT1NFIG1lc3NhZ2UsIGVnICJqa3UiOiJodHRwczovL2V4YW1wbGUu Y29tL2FsaWNlLmtleXMjL2sxIi4NCg0KDQo+PiAgIDEuICBTeW50YXggb2YgdGhlIGZyYWdtZW50 DQpUaGUgZnJhZ21lbnQsIGlmIHByZXNlbnQsIGlkZW50aWZpZXMgYSBzcGVjaWZpYyBrZXkgaW4g dGhlIEpXSyBrZXkgc2V0Lg0KDQpUaGUgZnJhZ21lbnQgU0hBTEwgYmUgYSBKU09OIFBvaW50ZXIg W1JGQyA2OTAxXSwgcG9pbnRpbmcgdG8gdGhlIEpTT04gb2JqZWN0IGhvbGRpbmcgdGhlIHNwZWNp ZmljIGtleSBvZiBpbnRlcmVzdCB3aXRoaW4gdGhlIHNldCBvZiBrZXlzLg0KDQpUaGUgZnJhZ21l bnQgU0hBTEwgYmUgYSAiLyIgY2hhcmFjdGVyIGZvbGxvd2VkIGJ5IHRoZSBrZXkgaWRlbnRpZmll ciAoImtpZCIgdmFsdWUpIGZvciB0aGUgc3BlY2lmaWMga2V5Lg0KDQpbVGhpcyBpbXBsaWVzIHRo ZSB0b3AtbGV2ZWwgc3RydWN0dXJlIG9mIGEgSldLIGtleSBzZXQgaXMgY2hhbmdlZCB0byBiZSBh IEpTT04gb2JqZWN0IHdob3NlIGVsZW1lbnRzIGFyZSBpbmRpdmlkdWFsIGtleXMuIEFuIGVsZW1l bnQncyBuYW1lIGlzIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBrZXkgKCJraWQiIHZhbHVlKTsgYW4g ZWxlbWVudCdzIHZhbHVlIGlzIGEgc2luZ2xlIEpXSyBvYmplY3QuIE9uZSBlbGVtZW50IChuYW1l ZCAibWV0YSIpIGlzIHNwZWNpYWw6IGl0IGlzIG5vdCBhICJraWQiIHZhbHVlLCBidXQgYSBwbGFj ZSB0byBob2xkIGFueSBtZXRhZGF0YSBhYm91dCB0aGUgd2hvbGUgc2V0IG9mIGtleXMuDQoNCkV4 YW1wbGU6DQogICB7DQogICAgICJrMSIgOiB7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4Ijri gKYsInkiOuKApn0sDQogICAgICAyMDExLTA0LTI5IiA6IHsia3R5IjpSU0EiLCJuIjrigKYsImUi OiJBUUFCIn0NCiAgIH0NCl0NCg0KDQo+PiAgIDIuICBkZWFsaW5nIHdpdGggZHVwbGljYXRlIHZh bHVlcyB3aXRoaW4gYSBKV0sgc3RydWN0dXJlDQpJJ20gbm90IHN1cmUgd2hhdCB0aGlzIGlzc3Vl IGlzLiBJIHN1c3BlY3QgaXQgaXMgc29sdmVkIGJ5IHN0b3Jpbmcga2V5cyBhcyBvYmplY3QgZWxl bWVudHMgYXMgb3Bwb3NlZCB0byBhcnJheSBpdGVtcy4NCg0KPj4gICAzLiAgRGVmaW5pdGlvbiBv ZiBhIG5ldyBtZWRpYSB0eXBlIC0gaXMgdGhpcyByZXF1aXJlZCBvciBub3QgLSBqdXN0aWZ5DQo+ PiAgIGVpdGhlciBwb3N0aW9uDQpUaGUgSldLIHNwZWMgc2hvdWxkIGRlZmluZSBhIG1lZGlhIHR5 cGUsIHN1Y2ggYXMgYXBwbGljYXRpb24va2V5cytqc29uLg0KRnJhZ21lbnRzIGFyZSBzcGVjaWZp YyB0byBhIG1lZGlhIHR5cGUgc28gYSBtZWRpYSB0eXBlIG5lZWRzIHRvIGJlIGRlZmluZWQuDQoN Cj4+ICAgNC4gIEV4cGxhaW4gd2h5IHRoZSBwcm9wb3NhbCBpcyAiYmV0dGVyIiB0aGFuIHRoZSBj dXJyZW50IGFiaWxpdHkgDQo+PiB0byBoYXZlIGEgdXJsIHBsdXMgdGhlIGtpZCBpbiB0aGUgbWVz c2FnZS4NClRoZSB3aG9sZSBjb25jZXB0IG9mIGEgVVJJIGlzIHRvIGJlIGFuIGlkZW50aWZpZXIg aXRzZWxmIChub3QganVzdCB3aGVuIGNvbWJpbmVkIHdpdGggYSBzZWNvbmQgZmllbGQpLiBNYW55 LCBtYW55IHN5c3RlbXMgYW5kIHByb3RvY29scyB0aGF0IHN1cHBvcnQgVVJJcyBhc3N1bWUgdGhh dCB0aGUgVVJJIGFsb25lIGlzIHN1ZmZpY2llbnQgdG8gaWRlbnRpZnkgdGhlIGl0ZW0gb2YgaW50 ZXJlc3QuDQpJdCBzaW1wbGlmaWVzIEFQSXMgYW5kIHByb3RvY29sczoganVzdCBwYXNzIDEgdmFs dWUuDQoNCj4+ICAgNS4gIERpc2N1c3Mgd2hhdCBoYXBwZW5zIGlmIHRoZSBmcmFnbWVudCBpcyBu b3QgcHJlc2VudCBvbiB0aGUgdXJsDQpUaGUgc3BlY3Mgc2hvdWxkIGJlIHdyaXR0ZW4gc28gdGhh dCBpZiB0aGVyZSBpcyBubyBmcmFnbWVudCBidXQgdGhlcmUgaXMgb25seSAxIGtleSBpbiB0aGUg aWRlbnRpZmllZCBKV0sga2V5IHNldCwgdGhlbiB0aGluZ3Mgc3RpbGwgd29yay4NCg0KSSBzdWdn ZXN0IHNheWluZyBhICpjcmVhdG9yKiBvZiBhICJqa3UiIFVSSSB2YWx1ZSAodG8gaWRlbnRpZnkg dGhlIHNwZWNpZmljIGtleSByZXF1aXJlZCB0byBwcm9jZXNzIGEgSk9TRSBtZXNzYWdlKSBNVVNU IGluY2x1ZGUgYSBmcmFnbWVudCB0byBpZGVudGlmeSBhIHNpbmdsZSBrZXkuIFdoZW4gYSBrZXkg c2V0IGhhcyBvbmx5IDEga2V5LCBhICpyZWNlaXZlciogTVVTVCBhY2NlcHQgYSAiamt1IiBVUkkg YXMgYW4gaWRlbnRpZmllciBvZiB0aGF0IDEga2V5IGV2ZW4gaWYgdGhlIFVSSSBoYXMgbm8gZnJh Z21lbnQuDQoNCj4+IG9yIGlmIHRoZSBmcmFnbWVudCBpcyBub3QgZmluZGFibGUgaW4gdGhlIHJl c3VsdGFudCBkb2N1bWVudC4NClRoZW4gdGhlIFVSSSBpZGVudGlmaWVzIGEga2V5IHRoYXQgaXMg bm90IHByZXNlbnQgc28gYW4gZXJyb3IgcmVzdWx0cyAoc2ltaWxhciB0byBnZXR0aW5nIGEgNDA0 IE5vdCBGb3VuZCBmb3IgdGhlIHdob2xlIGtleSBzZXQpLg0KDQo+PiAgIElmIHRoZSBmcmFnbWVu dA0KPj4gICBpcyBnb2luZyB0byBiZSBtYW5kaXRvcnkgZG9lcyB0aGVtIG1lYW4gdGhhdCB3ZSBz aG91bGQgYmUgZG9pbmcgYSBuZXcNCj4+ICAgc2NoZW1lIGluc3RlYWQgYXMgZnJhZ21lbnRzIGNh bm5vdCBiZSByZXF1aXJlZCB1bmRlciB0aGUgY3VycmVudCBVUkwNCj4+ICAgc3ludGF4IGRlZmlu dGlvbnMgKG9yIGF0IGxlYXN0IHRoYXQgaXMgbXkgcmVhZGluZykuDQpEZWZpbml0ZWx5IG5vIG5l dyBVUkkgc2NoZW1lLg0KQSBVUkkgd2l0aG91dCBhIGZyYWdtZW50IGlzIHN0aWxsIGEgdmFsaWQg VVJJLiBUaGF0IGRvZXNuJ3Qgc3RvcCB1cyBzYXlpbmcgYSAiamt1IiBVUkkgdmFsdWUgTVVTVCBj b250YWluIGEgZnJhZ21lbnQuDQoNCj4+ICAgUGxlYXNlIGZsZXNoIG91dCB5b3VyIHByb3Bvc2Fs IG1vcmUgc28gdGhhdCBpdCBjYW4gYmUgZnVsbHkgZXZhbHVhdGVkLg0KSSBob3BlIHRoaXMgZW1h aWwgaGFzIGZsZXNoZWQgb3V0IGEgcHJvcG9zYWwgc3VmZmljaWVudGx5Lg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K am9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vam9zZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0K From matiasw@gmail.com Mon Apr 15 09:37:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE6C21F9600 for ; Mon, 15 Apr 2013 09:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhXefL2krcao for ; Mon, 15 Apr 2013 09:37:12 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id E279321F9458 for ; Mon, 15 Apr 2013 09:37:11 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id d49so2300538eek.5 for ; Mon, 15 Apr 2013 09:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HwQGIjMWlHkM/t54AzKNL5PYxWoJqgm27mFG6Pm/jF4=; b=FDPG85CHzJuXTXtECiW3n35CzTPGpTA5yuiCPTVbJA7lVX82k7P9F9PpwoKTs0b68s 74z87eO/QJEXn/STFE4FSiqr5TfHiJ1xN4KSUCqziEVlHRSZlx6HO7J26ItsHiZgO1/i gqTBYXNETMrpX3x75zhBhcJms/GlmBfjHxPIx0JlLroqXqUXf9dyInw0JGBLO3wb36xm yLVNErlydXM7aRyw950jgGCH3RkDz+cKIKqkPMIv0t8cbXyDKdbsKBnMOigvPGBLJt9u KMl51OqlYq4X0CiBXZhOmOt8b5+qCDLtgfzSAwk82ivxH0tXOInXpOtsWwgNK31/zR+0 03Aw== X-Received: by 10.14.87.199 with SMTP id y47mr40446976eee.17.1366043830881; Mon, 15 Apr 2013 09:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.15.33.198 with HTTP; Mon, 15 Apr 2013 09:36:49 -0700 (PDT) In-Reply-To: <72C48E43-190F-4CBA-8757-404FD9BBF774@gmail.com> References: <51674E2D.3040604@isoc.org> <4E1F6AAD24975D4BA5B1680429673943676410FC@TK5EX14MBXC283.redmond.corp.microsoft.com> <72C48E43-190F-4CBA-8757-404FD9BBF774@gmail.com> From: Matias Woloski Date: Mon, 15 Apr 2013 13:36:49 -0300 Message-ID: To: nov matake Content-Type: multipart/alternative; boundary=001a11c29c6049b32304da68dd10 Cc: Mike Jones , "odonoghue@isoc.org" , "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:37:13 -0000 --001a11c29c6049b32304da68dd10 Content-Type: text/plain; charset=ISO-8859-1 1 On Mon, Apr 15, 2013 at 12:59 PM, nov matake wrote: > 1 > > nov > > On Apr 16, 2013, at 12:18 AM, Mike Jones > wrote: > > > 1. Have draft-barnes-jose-spi remain a separate specification that > could optionally also be supported by JWS and JWE implementations. > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Roland Hedberg > > Sent: Sunday, April 14, 2013 1:35 AM > > To: odonoghue@isoc.org > > Cc: jose@ietf.org > > Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we > add a "spi" header field? > > > > 1 > > > > 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : > > > > Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes > adding an "spi" (security parameters index) header parameter to the JWS and > JWE specifications. This modification to the JOSE formats would allow for > signaling that pre-negotiated cryptographic parameters are being used, > rather than including those parameters in the JWS or JWE header. This > proposal has been written up as > http://tools.ietf.org/html/draft-barnes-jose-spi-00. > > > > > > Which of these best describes your preferences on this issue? > > > > 1. Have draft-barnes-jose-spi remain a separate specification that > could optionally also be supported by JWS and JWE implementations. > > > > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE > specifications as a mandatory feature. > > > > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE > specifications as an optional feature. > > > > 4. Another resolution (please specify in detail). > > > > 0. I need more information to decide. > > > > Your reply is requested by Friday, April 19th or earlier. > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --001a11c29c6049b32304da68dd10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1


On Mon, Apr 15, 2013 at 12:59 PM, nov matake &= lt;matake@gmail.com> wrote:
1

nov

On Apr 16, 2013, at 12:18 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> 1. =A0Have draft-barnes-jose-spi remain a separate specification that = could optionally also be supported by JWS and JWE implementations.
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Roland Hedberg
> Sent: Sunday, April 14, 2013 1:35 AM
> To: odonoghue@isoc.org
> Cc: jose@ietf.org
> Subject: Re: [jose] Feedback request on jose tracker issue #8: Should = we add a "spi" header field?
>
> 1
>
> 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue <odonoghue@isoc.org>:
>
> Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 prop= oses adding an "spi" (security parameters index) header parameter= to the JWS and JWE specifications. =A0This modification to the JOSE format= s would allow for signaling that pre-negotiated cryptographic parameters ar= e being used, rather than including those parameters in the JWS or JWE head= er. =A0This proposal has been written up as http://tools.ietf.org/ht= ml/draft-barnes-jose-spi-00.
>
>
> Which of these best describes your preferences on this issue?
>
> 1. =A0Have draft-barnes-jose-spi remain a separate specification that = could optionally also be supported by JWS and JWE implementations.
>
> 2. =A0Incorporate draft-barnes-jose-spi into the JWS and JWE specifica= tions as a mandatory feature.
>
> 3. =A0Incorporate draft-barnes-jose-spi into the JWS and JWE specifica= tions as an optional feature.
>
> 4. =A0Another resolution (please specify in detail).
>
> 0. =A0I need more information to decide.
>
> Your reply is requested by Friday, April 19th or earlier.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--001a11c29c6049b32304da68dd10-- From tonynad@microsoft.com Mon Apr 15 09:45:18 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360FC21F95CE for ; Mon, 15 Apr 2013 09:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctCsuAUFBxBx for ; Mon, 15 Apr 2013 09:45:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9F021F9577 for ; Mon, 15 Apr 2013 09:45:17 -0700 (PDT) Received: from BL2FFO11FD014.protection.gbl (10.173.161.202) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.675.0; Mon, 15 Apr 2013 16:45:16 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:45:15 +0000 Received: from CO9EHSOBE006.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 15 Apr 2013 16:45:03 +0000 Received: from mail115-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 16:44:45 +0000 Received: from mail115-co9 (localhost [127.0.0.1]) by mail115-co9-R.bigfish.com (Postfix) with ESMTP id EA468140668 for ; Mon, 15 Apr 2013 16:44:44 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -18 X-BigFish: PS-18(z21aIL1091v3c23mz9371I542Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kz97hz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail115-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail115-co9 (localhost.localdomain [127.0.0.1]) by mail115-co9 (MessageSwitch) id 1366044283468422_30830; Mon, 15 Apr 2013 16:44:43 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.251]) by mail115-co9.bigfish.com (Postfix) with ESMTP id 7065C600057; Mon, 15 Apr 2013 16:44:43 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 16:44:43 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.299.2; Mon, 15 Apr 2013 16:44:42 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.670.13; Mon, 15 Apr 2013 16:44:39 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Mon, 15 Apr 2013 16:44:39 +0000 From: Anthony Nadalin To: Mike Jones , "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , Thread-Index: AQHONxCut0KhFoO8rUKRsOA43kjz9ZjSIMoAgAJpdQCAAuHGAIAAFuBw Date: Mon, 15 Apr 2013 16:44:39 +0000 Message-ID: <3d7aa65fdb52440c8d4ec87dbd2bc1d7@BY2PR03MB041.namprd03.prod.outlook.com> References: <51674E58.6000505@isoc.org> <4E289D7B-BB53-412A-AE3F-8CD08E45205A@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641257@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641257@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.48.62.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB041.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454001)(5383001)(13464002)(47446002)(47776003)(33646001)(66066001)(80022001)(54316002)(76482001)(79102001)(5343655001)(59766001)(16676001)(46406003)(77982001)(50986001)(56776001)(47976001)(1511001)(23726002)(46102001)(74662001)(56816002)(44976003)(69226001)(53806001)(65816001)(54356001)(74502001)(4396001)(81542001)(20776003)(31966008)(63696002)(15202345002)(49866001)(81342001)(6806002)(51856001)(50466001)(47736001)(42413001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:45:18 -0000 1 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, April 15, 2013 8:23 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the = x5c field be removed from JWE?, ,=20 1. Retain the "x5c" header parameter in JWE. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Saturday, April 13, 2013 12:22 PM To: Axel.Nennker@telekom.de Cc: jose@ietf.org; odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the = x5c field be removed from JWE?, ,=20 +1 12 apr 2013 kl. 08:32 skrev Axel.Nennker@telekom.de: 1 =20 x5c is the most explicit way to describe which private key is the right one= . It is an alternative to kid which is another reason why kid must not be = mandatory. =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Friday, April 12, 2013 1:59 AM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #12: Should the x5c = field be removed from JWE?, , =20 Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removi= ng the "x5c" header parameter from JWE, saying that no use case for it has = emerged. The same logic may apply to other key specification parameters fo= r JWE. Which of these best describes your preferences on this issue? 1. Retain the "x5c" header parameter in JWE. 2. Remove the "x5c" header parameter (and possibly other related key speci= fication parameters) from JWE. 3. Another resolution (please specify in detail). 0. I need more information to decide. =20 Your reply is requested by Friday, April 19th or earlier. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Mon Apr 15 09:46:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E087421F95CE for ; Mon, 15 Apr 2013 09:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2qQgLJl5Chw for ; Mon, 15 Apr 2013 09:46:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5933A21F9577 for ; Mon, 15 Apr 2013 09:46:03 -0700 (PDT) Received: from BY2FFO11FD023.protection.gbl (10.1.15.203) by BY2FFO11HUB029.protection.gbl (10.1.14.114) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 16:46:01 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:46:01 +0000 Received: from CO9EHSOBE013.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 15 Apr 2013 16:45:31 +0000 Received: from mail195-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 16:44:21 +0000 Received: from mail195-co9 (localhost [127.0.0.1]) by mail195-co9-R.bigfish.com (Postfix) with ESMTP id 2F620C80678 for ; Mon, 15 Apr 2013 16:44:21 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -37 X-BigFish: PS-37(z21aILz9371I542Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kz97hz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail195-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail195-co9 (localhost.localdomain [127.0.0.1]) by mail195-co9 (MessageSwitch) id 1366044259175780_9019; Mon, 15 Apr 2013 16:44:19 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.241]) by mail195-co9.bigfish.com (Postfix) with ESMTP id 28B26140174; Mon, 15 Apr 2013 16:44:19 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 16:44:18 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.299.2; Mon, 15 Apr 2013 16:44:08 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.670.13; Mon, 15 Apr 2013 16:44:06 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Mon, 15 Apr 2013 16:44:06 +0000 From: Anthony Nadalin To: Mike Jones , "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto Thread-Index: AQHONxCPfX/VS5lsIE+LiMstMfNJ9JjUiNSAgALhsgCAABgo4A== Date: Mon, 15 Apr 2013 16:44:05 +0000 Message-ID: References: <51674E17.5020902@isoc.org> <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> <4E1F6AAD24975D4BA5B1680429673943676410C1@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676410C1@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.48.62.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB041.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(5383001)(377454001)(199002)(13464002)(63696002)(80022001)(46406003)(20776003)(33646001)(15202345002)(47976001)(53806001)(31966008)(81342001)(49866001)(16676001)(66066001)(23726002)(50986001)(47776003)(76482001)(59766001)(1511001)(79102001)(47736001)(46102001)(74662001)(56776001)(81542001)(4396001)(47446002)(50466001)(56816002)(54356001)(6806002)(54316002)(77982001)(74502001)(69226001)(44976003)(51856001)(5343655001)(65816001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB029; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:46:05 -0000 1 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, April 15, 2013 8:17 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm id= entifiers/parameters incompatible with WebCrypto 1. Continue have the JWA algorithm identifiers be strings, and not objects= . Note that WebCrypto may choose to use some of these same strings, where = applicable. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Saturday, April 13, 2013 12:17 PM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm id= entifiers/parameters incompatible with WebCrypto 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that t= he JWA algorithm identifiers are different than those used by the W3C WebCr= ypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identi= fiers are strings, whereas the W3C WebCrypto algorithm identifiers are stru= ctures including string identifiers. The working group had previously deci= ded to continue representing JOSE algorithms as strings, as recorded at htt= p://www.ietf.org/mail-archive/web/jose/current/msg01219.html. Which of these best describes your preferences on this issue? 1. Continue have the JWA algorithm identifiers be strings, and not objects= . Note that WebCrypto may choose to use some of these same strings, where = applicable. 2. Switch to using the algorithm identifier structures defined in the WebC= rypto draft. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier.=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Mon Apr 15 09:46:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8035321F95B4 for ; Mon, 15 Apr 2013 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[AWL=-1.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, RELAY_IS_220=2.118] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tan94AG7xSd for ; Mon, 15 Apr 2013 09:46:30 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F38F021F9577 for ; Mon, 15 Apr 2013 09:46:29 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id s35so2155533dak.20 for ; Mon, 15 Apr 2013 09:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=hksxlikSYsa/bhfnSrRk5wPftQMhoMCOzmpcTJdtHRY=; b=Jq6Hou3rdB40PAaRsq2s7lqOianFng1MpYrw3FqutnYTGaHAyRJ/RosM9TY/78k34h aLPQI+T62n9wyINMbVdy2UVxOcywRy0JSjCPa92w4ZS9EeqdMl6Px53VNwNPYHx7QdAj RuvyzqqP0I+SHaHPvdkQHi7e9nFsCee3k63wS82LcLy3wDEYRXWKOh1DKoArv47bOG4I 1N19XvoFBsfztV/svKFgvkbIHLAh6h2cJs7GH8iDfx8UbkA/Jtlf/iOlAVbvPtfAayHE KkAz21ZHngtQZBbi8Yhay6qgMPXl23MCs0YrmriMDVKQbzMZ1jJXrh5F8b4xNcr3I21i MqYw== X-Received: by 10.66.233.9 with SMTP id ts9mr30972150pac.15.1366044389673; Mon, 15 Apr 2013 09:46:29 -0700 (PDT) Received: from [192.168.1.33] (s146003.dynamic.ppp.asahi-net.or.jp. [220.157.146.3]) by mx.google.com with ESMTPS id to7sm22719274pab.0.2013.04.15.09.46.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 09:46:28 -0700 (PDT) References: <51674E58.6000505@isoc.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1DB9B32D-437C-416E-86C2-AD01E309FE61 Content-Transfer-Encoding: 7bit Message-Id: <99F27FBA-4EFC-4092-89A0-8C0684B29456@gmail.com> X-Mailer: iPhone Mail (10B329) From: nov matake Date: Tue, 16 Apr 2013 01:41:19 +0900 To: Richard Barnes Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:46:30 -0000 --Apple-Mail-1DB9B32D-437C-416E-86C2-AD01E309FE61 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable I don't care too. nov On Apr 16, 2013, at 12:29 AM, Richard Barnes wrote: > Count me as "don't really care", modulo ISSUE-15. >=20 >=20 > On Thu, Apr 11, 2013 at 7:59 PM, Karen O'Donoghue wro= te: >> Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests remo= ving the =81gx5c=81h header parameter from JWE, saying that no use case for i= t has emerged. The same logic may apply to other key specification paramete= rs for JWE. >>=20 >>=20 >> Which of these best describes your preferences on this issue? >>=20 >> 1. Retain the =81gx5c=81h header parameter in JWE. >>=20 >> 2. Remove the =81gx5c=81h header parameter (and possibly other related k= ey specification parameters) from JWE. >>=20 >> 3. Another resolution (please specify in detail). >>=20 >> 0. I need more information to decide. >>=20 >> =20 >>=20 >> Your reply is requested by Friday, April 19th or earlier.=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-1DB9B32D-437C-416E-86C2-AD01E309FE61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't care too.

nov

On Apr 16, 2013, at 12:29 AM, Richard Barnes <rlb@ipv.sx> wrote:

Count me as "don't really care", modulo ISSUE-15.


On Thu, Apr 11, 2013 at 7:59 PM, Karen O'Donoghue <odonoghue@= isoc.org> wrote:
=20 =20 =20
Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the =E2=80=9Cx5c=E2=80=9D header parameter from JWE, saying tha= t no use case for it has emerged.  The same logic may apply to other key specification parameters for JWE.


Which of these best describes your preferences on this issue?

1.  Retain the =E2=80= =9Cx5c=E2=80=9D header parameter in JWE.

2.  Remove the =E2=80= =9Cx5c=E2=80=9D header parameter (and possibly other related key specification parameters) from JWE.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.

_______________________________________________
jose mailing list
jose@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/jose


____________________= ___________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman= /listinfo/jose
= --Apple-Mail-1DB9B32D-437C-416E-86C2-AD01E309FE61-- From tonynad@microsoft.com Mon Apr 15 09:46:49 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DDB21F95CE for ; Mon, 15 Apr 2013 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhxXEUXy0jwU for ; Mon, 15 Apr 2013 09:46:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80F21F95B4 for ; Mon, 15 Apr 2013 09:46:48 -0700 (PDT) Received: from BL2FFO11FD009.protection.gbl (10.173.161.204) by BL2FFO11HUB008.protection.gbl (10.173.160.228) with Microsoft SMTP Server (TLS) id 15.0.675.0; Mon, 15 Apr 2013 16:46:46 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:46:45 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 15 Apr 2013 16:46:16 +0000 Received: from mail93-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 16:44:27 +0000 Received: from mail93-va3 (localhost [127.0.0.1]) by mail93-va3-R.bigfish.com (Postfix) with ESMTP id 854FA340152 for ; Mon, 15 Apr 2013 16:44:27 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz9371I542Idb82hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kz97hz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail93-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail93-va3 (localhost.localdomain [127.0.0.1]) by mail93-va3 (MessageSwitch) id 1366044265895533_21460; Mon, 15 Apr 2013 16:44:25 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.239]) by mail93-va3.bigfish.com (Postfix) with ESMTP id D594E4E004C; Mon, 15 Apr 2013 16:44:25 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 16:44:25 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.299.2; Mon, 15 Apr 2013 16:44:25 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.670.13; Mon, 15 Apr 2013 16:44:23 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Mon, 15 Apr 2013 16:44:23 +0000 From: Anthony Nadalin To: Mike Jones , "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: AQHONxCrjB2uAx910k6YT26ah4boZ5jUiWKAgALh6QCAABeFEA== Date: Mon, 15 Apr 2013 16:44:22 +0000 Message-ID: <354223120e2d40b0aea99253c7a15400@BY2PR03MB041.namprd03.prod.outlook.com> References: <51674E3D.7030004@isoc.org> <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.48.62.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(199002)(189002)(377454001)(31966008)(79102001)(46406003)(15202345002)(54356001)(6806002)(50986001)(1511001)(33646001)(63696002)(47976001)(46102001)(81542001)(53806001)(47446002)(59766001)(49866001)(5343655001)(51856001)(54316002)(56776001)(56816002)(74502001)(81342001)(561944001)(20776003)(74662001)(47776003)(66066001)(4396001)(69226001)(80022001)(77982001)(65816001)(50466001)(23726002)(16676001)(47736001)(44976003)(76482001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB008; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:46:49 -0000 1 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, April 15, 2013 8:20 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we us= e RFC 5116 and remove the JWE Integrity Value field? 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Saturday, April 13, 2013 12:19 PM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we us= e RFC 5116 and remove the JWE Integrity Value field? 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restru= cturing the JWE representation to remove the JWE Integrity Value field and = instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphe= rtext, Initialization Vector, and Integrity Value values. If this proposal= is adopted, JWEs would then have three fields - the header, the encrypted = key, and the RFC 5116 combination of the Ciphertext, Initialization Vector,= and Integrity Value values.=20 This issue is also related to issue #3. Note that the updated McGrew draft= described there could be used whether or not we switched to using RFC 5116= . =20 Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the comb= ination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. =20 Your reply is requested by Friday, April 19th or earlier.=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Mon Apr 15 09:46:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBEB21F95B4 for ; Mon, 15 Apr 2013 09:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIeonAh3ExfZ for ; Mon, 15 Apr 2013 09:46:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 69A7B21F9577 for ; Mon, 15 Apr 2013 09:46:49 -0700 (PDT) Received: from BL2FFO11FD004.protection.gbl (10.173.161.203) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 16:46:48 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:46:48 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 15 Apr 2013 16:45:29 +0000 Received: from mail79-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE031.bigfish.com (10.243.66.96) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 16:44:19 +0000 Received: from mail79-co1 (localhost [127.0.0.1]) by mail79-co1-R.bigfish.com (Postfix) with ESMTP id A79CCB401B1 for ; Mon, 15 Apr 2013 16:44:19 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -37 X-BigFish: PS-37(z21aILz9371I542Idb82hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kz97hz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail79-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail79-co1 (localhost.localdomain [127.0.0.1]) by mail79-co1 (MessageSwitch) id 1366044257825583_23321; Mon, 15 Apr 2013 16:44:17 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.246]) by mail79-co1.bigfish.com (Postfix) with ESMTP id C61F638004A; Mon, 15 Apr 2013 16:44:17 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 16:44:17 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.299.2; Mon, 15 Apr 2013 16:44:16 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.670.13; Mon, 15 Apr 2013 16:44:14 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Mon, 15 Apr 2013 16:44:14 +0000 From: Anthony Nadalin To: Mike Jones , "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: AQHONxDDyzpTU/h4s0WdWZzY41Xj45jVZ6WAgAIDQACAABfg0A== Date: Mon, 15 Apr 2013 16:44:13 +0000 Message-ID: References: <51674E2D.3040604@isoc.org> <4E1F6AAD24975D4BA5B1680429673943676410FC@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676410FC@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.48.62.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(189002)(5383001)(199002)(377454001)(77982001)(81542001)(74662001)(69226001)(4396001)(47776003)(33646001)(6806002)(74502001)(51856001)(66066001)(56776001)(1511001)(44976003)(65816001)(47736001)(54356001)(15202345002)(5343655001)(16676001)(20776003)(50466001)(47976001)(81342001)(76482001)(59766001)(53806001)(50986001)(561944001)(80022001)(56816002)(46406003)(49866001)(79102001)(46102001)(23726002)(47446002)(63696002)(31966008)(54316002)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:46:50 -0000 1 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, April 15, 2013 8:19 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rol= and Hedberg Sent: Sunday, April 14, 2013 1:35 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? 1 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding a= n "spi" (security parameters index) header parameter to the JWS and JWE spe= cifications. This modification to the JOSE formats would allow for signali= ng that pre-negotiated cryptographic parameters are being used, rather than= including those parameters in the JWS or JWE header. This proposal has be= en written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. =20 Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier.=20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Mon Apr 15 09:46:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976C421F95B4 for ; Mon, 15 Apr 2013 09:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU4c4z15Vy7Z for ; Mon, 15 Apr 2013 09:46:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id B420E21F9615 for ; Mon, 15 Apr 2013 09:46:49 -0700 (PDT) Received: from BY2FFO11FD019.protection.gbl (10.1.15.200) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 16:47:18 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 16:46:47 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 15 Apr 2013 16:46:34 +0000 Received: from mail187-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 16:45:26 +0000 Received: from mail187-ch1 (localhost [127.0.0.1]) by mail187-ch1-R.bigfish.com (Postfix) with ESMTP id 429812013D for ; Mon, 15 Apr 2013 16:45:26 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -37 X-BigFish: PS-37(z21aILz9371I542Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1082kz97hz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail187-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1 (MessageSwitch) id 1366044324547250_18718; Mon, 15 Apr 2013 16:45:24 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail187-ch1.bigfish.com (Postfix) with ESMTP id 80E9B46004F; Mon, 15 Apr 2013 16:45:24 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 16:45:24 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.299.2; Mon, 15 Apr 2013 16:45:21 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.670.13; Mon, 15 Apr 2013 16:45:19 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.18]) with mapi id 15.00.0670.000; Mon, 15 Apr 2013 16:45:19 +0000 From: Anthony Nadalin To: Mike Jones , "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: AQHONxC5wP3auePN60uUMbzexd7pcJjSDgmAgANZPYCAAgVLgIAAFoBw Date: Mon, 15 Apr 2013 16:45:18 +0000 Message-ID: <074f8f5e0dad44509e5fe16b3b9ad818@BY2PR03MB041.namprd03.prod.outlook.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.48.62.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(5383001)(377454001)(199002)(13464002)(77982001)(47736001)(46102001)(54316002)(33646001)(47776003)(20776003)(47446002)(5343655001)(47976001)(53806001)(46406003)(76482001)(50986001)(65816001)(63696002)(50466001)(79102001)(69226001)(44976003)(15202345002)(56776001)(6806002)(80022001)(23726002)(16676001)(74502001)(51856001)(56816002)(81342001)(5343635001)(4396001)(49866001)(74662001)(31966008)(81542001)(54356001)(59766001)(66066001)(1511001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:46:50 -0000 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, April 15, 2013 8:25 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. -----Original Message----- From: Roland Hedberg [mailto:roland.hedberg@adm.umu.se]=20 Sent: Sunday, April 14, 2013 1:33 AM To: odonoghue@isoc.org Cc: jose@ietf.org; Mike Jones Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory I support 1 as defined by Mike. 12 apr 2013 kl. 07:25 skrev Mike Jones : > 1. Yes - Use cases where key information is exchanged by means other tha= n the JWS and JWE headers ARE important -- Roland From: Mike Jones=20 Sent: Thursday, April 11, 2013 10:25 PM To: 'odonoghue@isoc.org'; jose@ietf.org Subject: RE: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory Reading this question, I believe that there's a possibility for the questio= n to be misinterpreted, since the sense of the question in the subject is o= pposite of the sense of the question in the body. I believe that the inten= t of 1 and 2 were as follows: 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. 2. No - Use cases where key information is exchanged by means other than t= he JWS and JWE headers ARE NOT important. Maybe people could reply with 1 and 2 as above, so that their answers to th= e question of whether these use cases are important are not are unambiguous= . -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 5:00 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important?=20 Which of these best describes your preferences on this issue? 1. Yes. 2. No.=20 0. I need more information to decide. =20 Your reply is requested by Friday, April 19th (or earlier). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From matiasw@gmail.com Mon Apr 15 09:48:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EFF21F95B4 for ; Mon, 15 Apr 2013 09:48:19 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D-YzLkSRreL for ; Mon, 15 Apr 2013 09:48:18 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 19D9621F958A for ; Mon, 15 Apr 2013 09:48:17 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id f15so2273489eak.24 for ; Mon, 15 Apr 2013 09:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sxfolIvqsqtzh4F2Ek+tHBl9QxDri7cpggX89De/K1c=; b=MUK6ja5c5Z8vMl7XVgCXGIjsyYjJ49CH2QSy18fzgo/lXTANbhbvRxAt2finXZdqRp LaIyGVvqTGnBliExZW42c1wMnh3lDPF1FSn92JaDVT3RUAVKIzvfPvYCEnA4lGxDuC6p bsFjF+hqu5QNe7sjzR69p86iYJsx7CFeXrhCaA9pGu2BhY6BP2oiUBQf3+i/K85krztm 3zVZmEjZWW87opt7C9PEixW1jyiKN+EtoRTdLiAJxt6qj2USFsQRa1951Kk8CERon87P yJGcm/mogHOlkI9Xgikk5OvRYkx9cS4sO5d7D7crJ1nrulT17mQILYCVhB8v3HnvexQ4 gYqQ== X-Received: by 10.15.83.73 with SMTP id b49mr63711870eez.25.1366044497199; Mon, 15 Apr 2013 09:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.15.33.198 with HTTP; Mon, 15 Apr 2013 09:47:57 -0700 (PDT) In-Reply-To: <2EC89E23-1BAB-4BFB-B489-B9C73776AB0E@gmail.com> References: <51674E17.5020902@isoc.org> <38F5AA61-76DC-44E7-866B-E7977D033083@adm.umu.se> <2EC89E23-1BAB-4BFB-B489-B9C73776AB0E@gmail.com> From: Matias Woloski Date: Mon, 15 Apr 2013 13:47:57 -0300 Message-ID: To: nov matake Content-Type: multipart/alternative; boundary=089e0163448800f30e04da6905f5 Cc: "odonoghue@isoc.org" , "jose@ietf.org" , Roland Hedberg Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:48:19 -0000 --089e0163448800f30e04da6905f5 Content-Type: text/plain; charset=ISO-8859-1 1 I like the simplicity of just strings. I like to see a library source code, and easily find what is supported or not. This is easy to read: "switch (alg) case "HS256": ..." On Mon, Apr 15, 2013 at 1:05 PM, nov matake wrote: > 1 > > nov > > On Apr 14, 2013, at 4:17 AM, Roland Hedberg > wrote: > > > 1 > > > > 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : > > > >> Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out > that the JWA algorithm identifiers are different than those used by the W3C > WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm > identifiers are strings, whereas the W3C WebCrypto algorithm identifiers > are structures including string identifiers. The working group had > previously decided to continue representing JOSE algorithms as strings, as > recorded at > http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. > >> > >> Which of these best describes your preferences on this issue? > >> > >> 1. Continue have the JWA algorithm identifiers be strings, and not > objects. Note that WebCrypto may choose to use some of these same strings, > where applicable. > >> > >> 2. Switch to using the algorithm identifier structures defined in the > WebCrypto draft. > >> > >> 3. Another resolution (please specify in detail). > >> > >> 0. I need more information to decide. > >> > >> Your reply is requested by Friday, April 19th or earlier. > >> > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e0163448800f30e04da6905f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1
I like the simplicity of just strings. I like to see= a library source code, and easily find what is supported or not. This is e= asy to read: "switch (alg) case "HS256": ..."


On Mon, Apr 15, 2013 at 1:05 PM, nov mat= ake <matake@gmail.com> wrote:
1

nov

On Apr 14, 2013, at 4:17 AM, Roland Hedberg <roland.hedberg@adm.umu.se> wrote= :

> 1
>
> 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue <odonoghue@isoc.org>:
>
>> Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 = points out that the JWA algorithm identifiers are different than those used= by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. =A0The JWA alg= orithm identifiers are strings, whereas the W3C WebCrypto algorithm identif= iers are structures including string identifiers. =A0The working group had = previously decided to continue representing JOSE algorithms as strings, as = recorded at http://www.ietf.org/mail-archive/web/jose/cu= rrent/msg01219.html.
>>
>> Which of these best describes your preferences on this issue?
>>
>> 1. =A0Continue have the JWA algorithm identifiers be strings, and = not objects. =A0Note that WebCrypto may choose to use some of these same st= rings, where applicable.
>>
>> 2. =A0Switch to using the algorithm identifier structures defined = in the WebCrypto draft.
>>
>> 3. =A0Another resolution (please specify in detail).
>>
>> 0. =A0I need more information to decide.
>>
>> Your reply is requested by Friday, April 19th or earlier.
>>
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e0163448800f30e04da6905f5-- From matiasw@gmail.com Mon Apr 15 09:53:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A140921F93E5 for ; Mon, 15 Apr 2013 09:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1VIcQEG3Zme for ; Mon, 15 Apr 2013 09:53:34 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 500B421F8F70 for ; Mon, 15 Apr 2013 09:53:34 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id l10so2316567eei.22 for ; Mon, 15 Apr 2013 09:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FAVp1gfH2cJBhnKOIlypgldAuVFGjbd3xECrZqvLZTA=; b=EP5KvIEngh3MInLqYG0CMRI+zZ8QeTlsi46B0rZiiw8BUl7SeBgL8QCybhZebdLTLd 3B2x1Mtkfyk5EHQGActc37BqwgUulBaGDW8c2ZFCnz810qUr4SBA+mVXeOA1pLWOZVXK pHi1X/LuAV8GLDVrJXIu4L8hhydvXDlHsNhUtjkrU1GZ1M1IBFm9HALlTUQz8GoYx7g2 2yeAYhqikxXCimBy/oE4qKWDGQUiHnWsg598D90hbEeCrMPBJMrVgs4F7NMmHZpW+/fX 004r4/gYA9/OMiuKta+oXVgh418FjERrGPmivWKLLsqEKfCaQO7uYqXPC8sy98QuOdvW NGUw== X-Received: by 10.15.83.73 with SMTP id b49mr63760131eez.25.1366044813444; Mon, 15 Apr 2013 09:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.15.33.198 with HTTP; Mon, 15 Apr 2013 09:53:13 -0700 (PDT) In-Reply-To: <354223120e2d40b0aea99253c7a15400@BY2PR03MB041.namprd03.prod.outlook.com> References: <51674E3D.7030004@isoc.org> <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> <354223120e2d40b0aea99253c7a15400@BY2PR03MB041.namprd03.prod.outlook.com> From: Matias Woloski Date: Mon, 15 Apr 2013 13:53:13 -0300 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=089e01634488da6d6f04da6917d0 Cc: Mike Jones , "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:53:35 -0000 --089e01634488da6d6f04da6917d0 Content-Type: text/plain; charset=ISO-8859-1 1 Rationale: simplicity again. As an implementer I don't want to do an extra step of binary serialize something. Also, strings are easier to debug with fiddler. On Mon, Apr 15, 2013 at 1:44 PM, Anthony Nadalin wrote: > 1 > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Monday, April 15, 2013 8:20 AM > To: odonoghue@isoc.org > Cc: jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we > use RFC 5116 and remove the JWE Integrity Value field? > > 1. Continue having separate Ciphertext, Initialization Vector, and > Integrity Value values in the JWE representation. > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Roland Hedberg > Sent: Saturday, April 13, 2013 12:19 PM > To: odonoghue@isoc.org > Cc: jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we > use RFC 5116 and remove the JWE Integrity Value field? > > 1 > > 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : > > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes > restructuring the JWE representation to remove the JWE Integrity Value > field and instead use the RFC 5116 (AEAD) binary serialization to represent > the Ciphertext, Initialization Vector, and Integrity Value values. If this > proposal is adopted, JWEs would then have three fields - the header, the > encrypted key, and the RFC 5116 combination of the Ciphertext, > Initialization Vector, and Integrity Value values. > This issue is also related to issue #3. Note that the updated McGrew > draft described there could be used whether or not we switched to using RFC > 5116. > > > Which of these best describes your preferences on this issue? > > 1. Continue having separate Ciphertext, Initialization Vector, and > Integrity Value values in the JWE representation. > > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the > combination of these three values. > > 3. Another resolution (please specify in detail). > > 0. I need more information to decide. > > > > Your reply is requested by Friday, April 19th or earlier. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e01634488da6d6f04da6917d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1

Rationale: simplicity again. As= an implementer I don't want to do an extra step of binary serialize so= mething. Also, strings are easier to debug with fiddler.


On Mon, Apr 15, 2013 at 1:44 PM, Anthony= Nadalin <tonynad@microsoft.com> wrote:
1

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Mike Jones
Sent: Monday, April 15, 2013 8:20 AM
To: odonoghue@isoc.org
Cc: jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we us= e RFC 5116 and remove the JWE Integrity Value field?

1. =A0Continue having separate Ciphertext, Initialization Vector, and Integ= rity Value values in the JWE representation.

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Roland Hedberg
Sent: Saturday, April 13, 2013 12:19 PM
To: odonoghue@isoc.org
Cc: jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we us= e RFC 5116 and remove the JWE Integrity Value field?

1

12 apr 2013 kl. 01:58 skrev Karen O'Donoghue <odonoghue@isoc.org>:

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 propos= es restructuring the JWE representation to remove the JWE Integrity Value f= ield and instead use the RFC 5116 (AEAD) binary serialization to represent = the Ciphertext, Initialization Vector, and Integrity Value values. =A0If th= is proposal is adopted, JWEs would then have three fields - the header, the= encrypted key, and the RFC 5116 combination of the Ciphertext, Initializat= ion Vector, and Integrity Value values.
This issue is also related to issue #3. =A0Note that the updated McGrew dra= ft described there could be used whether or not we switched to using RFC 51= 16.


Which of these best describes your preferences on this issue?

1. =A0Continue having separate Ciphertext, Initialization Vector, and Integ= rity Value values in the JWE representation.

2. =A0Switch to using the RFC 5116 (AEAD) serialization to represent the co= mbination of these three values.

3. =A0Another resolution (please specify in detail).

0. =A0I need more information to decide.



Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e01634488da6d6f04da6917d0-- From mamille2@cisco.com Mon Apr 15 09:58:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3695B21F95DF for ; Mon, 15 Apr 2013 09:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJUQtW3np0Nq for ; Mon, 15 Apr 2013 09:58:15 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15F21F9590 for ; Mon, 15 Apr 2013 09:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5012; q=dns/txt; s=iport; t=1366045095; x=1367254695; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Cs6J/dXTWh/iW/jah1GLKe57u70eL/wbwAC9+ifSODw=; b=FUat68F7dCt81bI8EnCZoC67Waua/s7na4MD6f0/SmRS8GbKdLF+orru Tfsl8rHUDn/mVFhDCdBJ0o5NkW+DyAzq+LSDdINex7UA/pX4a/3xqZYtR De3JeC0uA5+VgXVvMLowMllH4cLzBgDp93PjcTDtOu2uAPgiuNiY8H8aQ I=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAIowbFGrRDoJ/2dsb2JhbABQgwbBOoEHFnSCHwEBAQMBeQULCzsLAlUGE4gCAwkFsg4diU2PFweCYGEDiQWGT4cxhgWLDIFVgVUd X-IronPort-AV: E=Sophos;i="4.87,476,1363132800"; d="p7s'?scan'208";a="76146801" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 15 Apr 2013 16:58:13 +0000 Received: from [10.129.24.59] ([10.129.24.59]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3FGwCOh013167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Apr 2013 16:58:12 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_42251A08-1271-45C1-8DDC-EBD1FCB964A5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Matt Miller In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C5F1446@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 15 Apr 2013 10:58:11 -0600 Message-Id: References: <51674E3D.7030004@isoc.org> <255B9BB34FB7D647A506DC292726F6E1150C5F1446@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1503) Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:58:16 -0000 --Apple-Mail=_42251A08-1271-45C1-8DDC-EBD1FCB964A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 11, 2013, at 8:37 PM, "Manger, James H" = wrote: > Karen, > I think this poll conflates 2 issues: a) making the integrity check = value part of the ciphertext (as per RFC 5116); and b) not treating the = IV in CBC-HMAC as an (app-supplied) AEAD nonce, but as part of the = randomized (crypto-library-supplied) ciphertext (as per = draft-mcgrew-aead-aes-cbc-hmac-sha2). >=20 > RFC 5116 =93An interface and algorithms for authenticated encryption=94 = has a nonce (N) and a separate field to the ciphertext. N is a separate = input to the encryption and decryption operations. > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines AEAD algorithms that take = a zero-length nonce, but prefix the ciphertext with a random IV. >=20 >=20 > So my answer to the poll: >=20 > 2b. > Switch to using RFC 5116. > A JWE should have separate nonce and ciphertext fields (but no = separate integrity value field). > JWE should use the term =93nonce=94, instead of =93initialization = vector=94. > Any integrity value that an algorithm creates should be part of the = ciphertext. > When draft-mcgrew-aead-aes-cbc-hmac-sha2 is used as the AEAD algorithm = the nonce field will be empty, and the ciphertext field will be a = concatenation of an IV, AES output, and the truncated HMAC output. >=20 My preference is also this 2b (or would it be 3?). - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_42251A08-1271-45C1-8DDC-EBD1FCB964A5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQxNTE2NTgxMlowIwYJKoZIhvcNAQkEMRYEFJT0o8ym0xYmFbEsZDuoes5qpQ+KMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBc7Z2KlEJTVzxbsg5sIY4qtO1rmNFH4ZHvhpMmB4d5 f28KYffFBlX2sOkVXJ9go2TkDkdCT1NXVLtnyfd1XnVmY4ypzYiRyFn/lr5sp2kvaXHDMnIy5ksM O/gVkn4Yxk75Rp0SHLOPFQ3orCBvZtzSyWswUMax6ZDpJSvygPZoNAfTM/M5XHKRQXBF+yyYe4dx HUtvlFPb+yOuuuyEStMRmKlO7H/QC+F/V9k9nWvQH9knCTyDr7EHX58Jpxb6HnMzmz7eW68oqA6S Kjs1a/NOgX+CjkhXG5Uk0qQeGwL36ViTXRC+r1q7lDvOGNQfSeL3BW5C9tfDRfGEp8XUl6g1AAAA AAAA --Apple-Mail=_42251A08-1271-45C1-8DDC-EBD1FCB964A5-- From matiasw@gmail.com Mon Apr 15 10:08:01 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C5121F9381 for ; Mon, 15 Apr 2013 10:08:01 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXOeFixgDpJi for ; Mon, 15 Apr 2013 10:08:00 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6A21F937E for ; Mon, 15 Apr 2013 10:07:54 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id k11so2272186eaj.18 for ; Mon, 15 Apr 2013 10:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IRiKf3VefsArkZ6BRLQJKZRJ06T5CFKzvZr2S9GiYcI=; b=oNhtr9LXFN/YMgbKZj4XCi7Q60k4AiyV6jyHQcutVbuCeXGWLiQB25iTGYC6gpuLqX K5bxmbuby67MBOIQyc6eO2Ty9QCILrzW4E++JFyzzQUvajBJPWv4zwcJOnAZl4RcCbLD KSFzXxng8DmAmV1xYGHVpc9XE6WhNr+rolBpD7IFCyWcPWM6HQNNvzuMQF8AvOe5Xcuw qYO/MXuhkZMFBbXEQrtSiiBb6rKyAbZ5xThKrPIp2RmXOgCv/VFx4lxBqGDpSGMtmGqH jcbv/QfLQ8xk2ob25hnUSToytdz+AYCxBGXjY6aTfg0OhuFOExnfPCWEaI1Ja9mY0JMG OnCg== X-Received: by 10.15.27.195 with SMTP id p43mr63859014eeu.8.1366045668514; Mon, 15 Apr 2013 10:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.15.33.198 with HTTP; Mon, 15 Apr 2013 10:07:28 -0700 (PDT) In-Reply-To: <3d7aa65fdb52440c8d4ec87dbd2bc1d7@BY2PR03MB041.namprd03.prod.outlook.com> References: <51674E58.6000505@isoc.org> <4E289D7B-BB53-412A-AE3F-8CD08E45205A@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641257@TK5EX14MBXC283.redmond.corp.microsoft.com> <3d7aa65fdb52440c8d4ec87dbd2bc1d7@BY2PR03MB041.namprd03.prod.outlook.com> From: Matias Woloski Date: Mon, 15 Apr 2013 14:07:28 -0300 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=089e0163450ad1ce2004da694afa Cc: Mike Jones , "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:08:01 -0000 --089e0163450ad1ce2004da694afa Content-Type: text/plain; charset=ISO-8859-1 1. In some cases, it is simpler for me to just put the whole base64 public key. For instance, in some platforms is not straightforward to parse an X509 cert and extract the serial number, hence being able to send the public key blob there, makes it easier for interop. On Mon, Apr 15, 2013 at 1:44 PM, Anthony Nadalin wrote: > 1 > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Monday, April 15, 2013 8:23 AM > To: odonoghue@isoc.org > Cc: jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the > x5c field be removed from JWE?, , > > 1. Retain the "x5c" header parameter in JWE. > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Roland Hedberg > Sent: Saturday, April 13, 2013 12:22 PM > To: Axel.Nennker@telekom.de > Cc: jose@ietf.org; odonoghue@isoc.org > Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the > x5c field be removed from JWE?, , > > +1 > > 12 apr 2013 kl. 08:32 skrev Axel.Nennker@telekom.de: > > 1 > > x5c is the most explicit way to describe which private key is the right > one. It is an alternative to kid which is another reason why kid must not > be mandatory. > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Karen O'Donoghue > Sent: Friday, April 12, 2013 1:59 AM > To: jose@ietf.org > Subject: [jose] Feedback request on jose tracker issue #12: Should the x5c > field be removed from JWE?, , > > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests > removing the "x5c" header parameter from JWE, saying that no use case for > it has emerged. The same logic may apply to other key specification > parameters for JWE. > > > Which of these best describes your preferences on this issue? > 1. Retain the "x5c" header parameter in JWE. > 2. Remove the "x5c" header parameter (and possibly other related key > specification parameters) from JWE. > 3. Another resolution (please specify in detail). > 0. I need more information to decide. > > Your reply is requested by Friday, April 19th or earlier. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e0163450ad1ce2004da694afa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1.=A0

In some cases, it is simpler for = me to just put the whole base64 public key. For instance, in some platforms= is not straightforward to parse an X509 cert and extract the serial number= , hence being able to send the public key blob there, makes it easier for i= nterop.


On Mon,= Apr 15, 2013 at 1:44 PM, Anthony Nadalin <tonynad@microsoft.com&g= t; wrote:
1

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Mike Jones
Sent: Monday, April 15, 2013 8:23 AM
To: odonoghue@isoc.org
Cc: jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the = x5c field be removed from JWE?, ,

1. =A0Retain the "x5c" header parameter in JWE.

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Roland Hedberg
Sent: Saturday, April 13, 2013 12:22 PM
To: Axel.Nennker@telekom.de<= br> Cc: jose@ietf.org; odonoghue@isoc.org
Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the = x5c field be removed from JWE?, ,

+1

12 apr 2013 kl. 08:32 skrev Axel= .Nennker@telekom.de:

1

x5c is the most explicit way to describe which private key is the right one= . It is an alternative to kid which is another reason why =A0kid must not b= e mandatory.

From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Karen O'Donoghue
Sent: Friday, April 12, 2013 1:59 AM
To: jose@ietf.org
Subject: [jose] Feedback request on jose tracker issue #12: Should the x5c = field be removed from JWE?, ,

Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 sugges= ts removing the "x5c" header parameter from JWE, saying that no u= se case for it has emerged. =A0The same logic may apply to other key specif= ication parameters for JWE.


Which of these best describes your preferences on this issue?
1. =A0Retain the "x5c" header parameter in JWE.
2. =A0Remove the "x5c" header parameter (and possibly other relat= ed key specification parameters) from JWE.
3. =A0Another resolution (please specify in detail).
0. =A0I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e0163450ad1ce2004da694afa-- From matiasw@gmail.com Mon Apr 15 10:12:28 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FA621F9652 for ; Mon, 15 Apr 2013 10:12:28 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW4irn-JKE7a for ; Mon, 15 Apr 2013 10:12:27 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EEBDC21F9638 for ; Mon, 15 Apr 2013 10:12:26 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id f15so2283659eak.24 for ; Mon, 15 Apr 2013 10:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UY1JI0RiZ2iNZ6eyT86RNgYn7qk7mR021VwYz+hp4Gk=; b=FQSM5JCFg2RrBCA7JBKvcAU/fGEHvZpLtvC3GW1Fb8GuDLP8EpFjs6K0LFLHkROmIf dwR7zy1j7NYCNYIDV37KhJImqvM75lJsK1dMDq8qvu0Jz8mYlinPqh7bpkL0msSGrfFv QlWKc1jeP9APnju5pDhHvNS96zNwPdkklX1V+5RavN7cPK5FBX8FJ1QYAjqkrF/GKmo3 buOf15sA08AQ7gV5iR99Whj5f5gE2LE02krjFwauXu2o5NsxsEly86Tn78gzOuPcE0wE HBeYvdZK3IuyzeNRkkpmuTEHBzLPKUuEW8wYReC6AwVFuRUe/TNxTqK0ybqjvqWX4Has sIuw== X-Received: by 10.15.24.71 with SMTP id i47mr52997374eeu.0.1366045945974; Mon, 15 Apr 2013 10:12:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.15.33.198 with HTTP; Mon, 15 Apr 2013 10:12:05 -0700 (PDT) In-Reply-To: <074f8f5e0dad44509e5fe16b3b9ad818@BY2PR03MB041.namprd03.prod.outlook.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> <074f8f5e0dad44509e5fe16b3b9ad818@BY2PR03MB041.namprd03.prod.outlook.com> From: Matias Woloski Date: Mon, 15 Apr 2013 14:12:05 -0300 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=089e016344c85b7f4404da695bde Cc: Mike Jones , "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:12:28 -0000 --089e016344c85b7f4404da695bde Content-Type: text/plain; charset=ISO-8859-1 1. Yes - Use cases where key information is exchanged by means other than the JWS and JWE headers ARE important. On Mon, Apr 15, 2013 at 1:45 PM, Anthony Nadalin wrote: > 1. Yes - Use cases where key information is exchanged by means other than > the JWS and JWE headers ARE important. > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Monday, April 15, 2013 8:25 AM > To: odonoghue@isoc.org > Cc: jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory > > 1. Yes - Use cases where key information is exchanged by means other than > the JWS and JWE headers ARE important. > > -----Original Message----- > From: Roland Hedberg [mailto:roland.hedberg@adm.umu.se] > Sent: Sunday, April 14, 2013 1:33 AM > To: odonoghue@isoc.org > Cc: jose@ietf.org; Mike Jones > Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory > > I support 1 as defined by Mike. > > 12 apr 2013 kl. 07:25 skrev Mike Jones : > > > 1. Yes - Use cases where key information is exchanged by means other > than the JWS and JWE headers ARE important > > -- Roland > > From: Mike Jones > Sent: Thursday, April 11, 2013 10:25 PM > To: 'odonoghue@isoc.org'; jose@ietf.org > Subject: RE: [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory > > Reading this question, I believe that there's a possibility for the > question to be misinterpreted, since the sense of the question in the > subject is opposite of the sense of the question in the body. I believe > that the intent of 1 and 2 were as follows: > > 1. Yes - Use cases where key information is exchanged by means other than > the JWS and JWE headers ARE important. > 2. No - Use cases where key information is exchanged by means other than > the JWS and JWE headers ARE NOT important. > > Maybe people could reply with 1 and 2 as above, so that their answers to > the question of whether these use cases are important are not are > unambiguous. > > -- Mike > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Karen O'Donoghue > Sent: Thursday, April 11, 2013 5:00 PM > To: jose@ietf.org > Subject: [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory > > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests > requiring that a key indicator, such as a "kid" field, be required in all > JWS and JWE headers. Are use cases where key information is exchanged by > means other than the JWS or JWE headers important? > Which of these best describes your preferences on this issue? > 1. Yes. > 2. No. > 0. I need more information to decide. > > Your reply is requested by Friday, April 19th (or earlier). > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e016344c85b7f4404da695bde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1. =A0Yes - Use cases where key information is exchang= ed by means other than the JWS and JWE headers ARE important.


On Mon, Apr 1= 5, 2013 at 1:45 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
1. =A0Yes - Use cas= es where key information is exchanged by means other than the JWS and JWE h= eaders ARE important.

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, April 15, 2013 8:25 AM
To: odonoghue@isoc.org
Cc: jose@ietf.org
Subject: Re: [jose] Feedback = request on jose tracker issue #15: Should at least on key indicator be mand= atory

1. =A0Yes - Use cases where key information is exchanged by means other tha= n the JWS and JWE headers ARE important.

-----Original Message-----
From: Roland Hedberg [mailto:r= oland.hedberg@adm.umu.se]
Sent: Sunday, April 14, 2013 1:33 AM
To: odonoghue@isoc.org
Cc: jose@ietf.org; Mike Jones
Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory

I support 1 as defined by Mike.

12 apr 2013 kl. 07:25 skrev Mike Jones <Michael.Jones@microsoft.com>:

> 1. =A0Yes - Use cases where key information is exchanged by means othe= r than the JWS and JWE headers ARE important

-- Roland

From: Mike Jones
Sent: Thursday, April 11, 2013 10:25 PM
To: 'odonoghue@isoc.org';= jose@ietf.org
Subject: RE: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory

Reading this question, I believe that there's a possibility for the que= stion to be misinterpreted, since the sense of the question in the subject = is opposite of the sense of the question in the body. =A0I believe that the= intent of 1 and 2 were as follows:

1. =A0Yes - Use cases where key information is exchanged by means other tha= n the JWS and JWE headers ARE important.
2. =A0No - Use cases where key information is exchanged by means other than= the JWS and JWE headers ARE NOT important.

Maybe people could reply with 1 and 2 as above, so that their answers to th= e question of whether these use cases are important are not are unambiguous= .

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

From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM
To: jose@ietf.org
Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. sugge= sts requiring that a key indicator, such as a "kid" field, be req= uired in all JWS and JWE headers. Are use cases where key information is ex= changed by means other than the JWS or JWE headers important?
Which of these best describes your preferences on this issue?
1. =A0Yes.
2. =A0 No.
0. =A0I need more information to decide.

Your reply is requested by Friday, April 19th (or earlier).
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e016344c85b7f4404da695bde-- From breno@google.com Mon Apr 15 10:16:07 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0221F9613 for ; Mon, 15 Apr 2013 10:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF1l32JCJXWV for ; Mon, 15 Apr 2013 10:16:06 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D421F9602 for ; Mon, 15 Apr 2013 10:16:06 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id j1so4644578oag.35 for ; Mon, 15 Apr 2013 10:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5KBxHR8X9lMXXKE2SkutIr2nbivP4gtdehEbpPcqjAE=; b=T2Gze1BL+wplZEmOuYRIig0ExiAeHOkQgs3J0J83va1y+kqoM+PJ86Ck1tdyOltnc6 pkx1C3/9Is2nLYC3z0hta0aMBFDOg9HqxkzV4mERhGhcefVHezoE6NDdbPlQagUqjR+B w3fEy1nRUA0h6GHpk9cjcofDLBcyTxk4VG/9pmkeRtbQb76K7x5DM+imXM+RFXEUmRTE SrMv98vW/z2p5tb7axfW7nQy3mGL1FupkbLDV98LmRUteaH8zel1YxtHBW+7inMsLb+s dzQwu5+bO9liYwRouwFA7JjoHPHh+6s45Kerxv6vpXyg8i28+NPNbyU/iPMIISnCJXjF 2/Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=5KBxHR8X9lMXXKE2SkutIr2nbivP4gtdehEbpPcqjAE=; b=pOu0kIRdTHkecSFwEqUNfW2+Fu1KLAXmCwwJzNOtPsXYYIZxDc52n6zt358ZIITcIt luQkoTFjVc+8ub2Jd+phb6Ne9DDfMEm0TW9E5TMmJPLE8O0pY3uXJKNseFygxYk95ghH vA0oaqwpG27u6XGKur8j1to+tf6qf9tY3YHZr11OxA5l60MDEjf+HfszhLDPaazuhcmg dXiYjgrnX0AZhcxRASCNksMZK7UdtjHpEVW7o7033jJcQr7nZR6VJ/r9T9j5VYb7WJMn NBjGLkuO0L0F3Fc9KZt/EaAIrO08wd4Ui/NozJNIK0T3hMwB3wjTQbX2l26InXVcV9RH /3BA== MIME-Version: 1.0 X-Received: by 10.60.93.105 with SMTP id ct9mr7699307oeb.70.1366046165753; Mon, 15 Apr 2013 10:16:05 -0700 (PDT) Received: by 10.182.89.162 with HTTP; Mon, 15 Apr 2013 10:16:05 -0700 (PDT) In-Reply-To: References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641294@TK5EX14MBXC283.redmond.corp.microsoft.com> <074f8f5e0dad44509e5fe16b3b9ad818@BY2PR03MB041.namprd03.prod.outlook.com> Date: Mon, 15 Apr 2013 10:16:05 -0700 Message-ID: From: Breno de Medeiros To: Matias Woloski Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkMF6UJ/7lRFBOdTnwZp4hKfVkduSQz8qFwo2h56k+PXSD/etEC6a43efBCGbLG5ZHNu2CGjr5ARC4YCsAzQHqBD9T2ZuXfYRpNOnSV/Ekc4OCUId56/pnZih22By//Wb0OIV5ooOprm07TxSEk9T5T9PaMT1N4G/JZPWkjptkuERpAsiacmF7QwudxMxnX5xKkG2OU Cc: Anthony Nadalin , Mike Jones , "odonoghue@isoc.org" , "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:16:07 -0000 1. Use cases where key information is exchanged by means other than the JWS and JWE headers ARE important On Mon, Apr 15, 2013 at 10:12 AM, Matias Woloski wrote: > 1. Yes - Use cases where key information is exchanged by means other than > the JWS and JWE headers ARE important. > > > On Mon, Apr 15, 2013 at 1:45 PM, Anthony Nadalin > wrote: >> >> 1. Yes - Use cases where key information is exchanged by means other than >> the JWS and JWE headers ARE important. >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Mike Jones >> Sent: Monday, April 15, 2013 8:25 AM >> To: odonoghue@isoc.org >> Cc: jose@ietf.org >> Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at >> least on key indicator be mandatory >> >> 1. Yes - Use cases where key information is exchanged by means other than >> the JWS and JWE headers ARE important. >> >> -----Original Message----- >> From: Roland Hedberg [mailto:roland.hedberg@adm.umu.se] >> Sent: Sunday, April 14, 2013 1:33 AM >> To: odonoghue@isoc.org >> Cc: jose@ietf.org; Mike Jones >> Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at >> least on key indicator be mandatory >> >> I support 1 as defined by Mike. >> >> 12 apr 2013 kl. 07:25 skrev Mike Jones : >> >> > 1. Yes - Use cases where key information is exchanged by means other >> > than the JWS and JWE headers ARE important >> >> -- Roland >> >> From: Mike Jones >> Sent: Thursday, April 11, 2013 10:25 PM >> To: 'odonoghue@isoc.org'; jose@ietf.org >> Subject: RE: [jose] Feedback request on jose tracker issue #15: Should at >> least on key indicator be mandatory >> >> Reading this question, I believe that there's a possibility for the >> question to be misinterpreted, since the sense of the question in the >> subject is opposite of the sense of the question in the body. I believe >> that the intent of 1 and 2 were as follows: >> >> 1. Yes - Use cases where key information is exchanged by means other than >> the JWS and JWE headers ARE important. >> 2. No - Use cases where key information is exchanged by means other than >> the JWS and JWE headers ARE NOT important. >> >> Maybe people could reply with 1 and 2 as above, so that their answers to >> the question of whether these use cases are important are not are >> unambiguous. >> >> -- Mike >> >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Karen O'Donoghue >> Sent: Thursday, April 11, 2013 5:00 PM >> To: jose@ietf.org >> Subject: [jose] Feedback request on jose tracker issue #15: Should at >> least on key indicator be mandatory >> >> Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests >> requiring that a key indicator, such as a "kid" field, be required in all >> JWS and JWE headers. Are use cases where key information is exchanged by >> means other than the JWS or JWE headers important? >> Which of these best describes your preferences on this issue? >> 1. Yes. >> 2. No. >> 0. I need more information to decide. >> >> Your reply is requested by Friday, April 19th (or earlier). >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- --Breno From rlb@ipv.sx Mon Apr 15 10:31:27 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC2E21F95E9 for ; Mon, 15 Apr 2013 10:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.875 X-Spam-Level: * X-Spam-Status: No, score=1.875 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_SPICE=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvcuH5RlV02E for ; Mon, 15 Apr 2013 10:31:26 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B53B321F95EC for ; Mon, 15 Apr 2013 10:31:20 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wc20so1312167obb.16 for ; Mon, 15 Apr 2013 10:31:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Ink+8Lw5mX3IQHwerGzx41lTUpF4/Ri+9YWNWMkJqpU=; b=FzY59j0qnduW+p0xqCa2YmBW7DDLPpzAEVr6QWjupg8HaC6wNO7gB5uC6/NQhpq5Sp aWt5+Uq0I260S3WMcnBMQ9GWXcd01WXjt3foIR97dZqWlVFW1hP1fK91+RZZEq2/ZH/V QE6i4i1WlE4ZAS9IRMp6NAM/280W1+IBOXxgBDcr6EDCiHKWrFoAVYSHCs+B3vsELp4J 9R6NQdOEUIeNiOIzCZfyzWLc+vK2IT5X/lK0Vjw9W3jo6UCLEa1gqTsvEijar/DJGnPW 6q9yRD6AtsaKM4FVnu6v1Q+u5i+LeUwWsifB3VCs7IxoOM8HXrEcB3r21jMhc5IV1B+4 i+DQ== MIME-Version: 1.0 X-Received: by 10.182.235.49 with SMTP id uj17mr3782869obc.18.1366047080093; Mon, 15 Apr 2013 10:31:20 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 10:31:19 -0700 (PDT) X-Originating-IP: [137.54.9.111] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641542@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641542@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 13:31:19 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec5396952f4aa0104da699e3f X-Gm-Message-State: ALoCoQktAgsYpgVWiQCLPLJVVFHZgpjH5ouUdnDBRaV189I3XTn0Hfw3I9mNL+sxKaNdfOZs+Sxt Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:31:27 -0000 --bcaec5396952f4aa0104da699e3f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're making the same false argument I just addressed. Covering use cases involving pre-negotiation does not imply that headers can't be mandatory. It implies that they can't be mandatory in all cases -- that is, that there needs to be a "pre-negotiated mode" in which headers are not mandatory in addition to the "stand-alone mode" where everything needs to be expressed in the headers (no pre-negotiation). I am completely fine with supporting both modes, but in order to do that, it needs to be clear to a recipient which mode is in use. So we need to: (1) Choose a default mode, (2) Have a switch that indicates when the non-default mode is being used, and (3) Define generation and processing rules for both modes. What I'm saying here is that: (1) The default mode should be "stand-alone" (2) The switch is SPI (3) The processing rules for the stand-alone mode should REQUIRE at least one key indicator What you're arguing is that there should not be a well-defined stand-alone mode, effectively that the recipient always does some pre-negotiation in order to know what fields it needs. So you're arguing that the following basic requirements from the use cases document aren't actually requirements= : """ o The JOSE encrypted object format must support object encryption in the case where the sender and receiver share a symmetric key. o The JOSE encrypted object format must support object encryption in the case where the sender has only a public key for the receiver. o The JOSE signed object format must integrity protection using Message Authentication Codes (MACs), for the case where the sender and receiver share only a symmetric key. o The JOSE signed object format must integrity protection using digital signatures, for the case where the receiver has only a public key for the sender. """ The implication of all those "only"s is that everything else has to be defined by the protocol specification, including which fields are mandatory= . --Richard On Mon, Apr 15, 2013 at 11:45 AM, Mike Jones w= rote: > You could say =93nice straw man, Jim=94, as it was Jim Schaad who propos= ed > that the right question to ask was whether such use cases are important o= r > not. I agree with Jim that clearly if they are important/in scope, then > key indicators in the headers can=92t be mandatory.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Monday, April 15, 2013 8:41 AM > *To:* Mike Jones > *Cc:* odonoghue@isoc.org; jose@ietf.org > *Subject:* Re: [jose] Feedback request on jose tracker issue #15: Should > at least on key indicator be mandatory**** > > ** ** > > Nice straw man, Mike :) **** > > ** ** > > Nobody is arguing that cases with out-of-band negotiation are not > important. The question is how they should be supported.**** > > ** ** > > What ISSUE-9 and ISSUE-15 are about is saying that the default assumption > should be that all communication is via JW* headers. Otherwise, we're no= t > designing a stand-alone protocol, we're designing an adjunct to something > else, and we should do it in that WG. That default assumption means that > you have to have certain contraints, like a key indicator being REQUIRED. > The SPI header is then the "get out of jail free card", releasing you fr= om > those constraints.**** > > ** ** > > Let's design a real protocol first, then let people cheat.**** > > ** ** > > --Richard**** > > ** ** > > ** ** > > On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones > wrote:**** > > Reading this question, I believe that there=92s a possibility for the > question to be misinterpreted, since the sense of the question in the > subject is opposite of the sense of the question in the body. I believe > that the intent of 1 and 2 were as follows:**** > > **** > > 1. Yes =96 Use cases where key information is exchanged by means other t= han > the JWS and JWE headers ARE important.**** > > 2. No =96 Use cases where key information is exchanged by means other th= an > the JWS and JWE headers ARE NOT important.**** > > **** > > Maybe people could reply with 1 and 2 as above, so that their answers to > the question of whether these use cases are important are not are > unambiguous.**** > > **** > > -- Mike**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Karen O'Donoghue > *Sent:* Thursday, April 11, 2013 5:00 PM**** > > > *To:* jose@ietf.org > *Subject:* [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory**** > > **** > > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests > requiring that a key indicator, such as a =93kid=94 field, be required in= all > JWS and JWE headers. Are use cases where key information is exchanged by > means other than the JWS or JWE headers important? ** ** > > Which of these best describes your preferences on this issue?**** > > 1. Yes.**** > > 2. No. **** > > 0. I need more information to decide.**** > > **** > > Your reply is requested by Friday, April 19th (or earlier). **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --bcaec5396952f4aa0104da699e3f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're making the same false argument I just addressed. =A0Covering use= cases involving pre-negotiation does not imply that headers can't be m= andatory. =A0It implies that they can't be mandatory in all cases -- th= at is, that there needs to be a "pre-negotiated mode" in which he= aders are not mandatory in addition to the "stand-alone mode" whe= re everything needs to be expressed in the headers (no pre-negotiation).
I am completely fine with supporting both modes, but in orde= r to do that, it needs to be clear to a recipient which mode is in use. =A0= So we need to:
(1) Choose a default mode,
(2) Have a sw= itch that indicates when the non-default mode is being used, and
(3) Define generation and processing rules for both modes.
<= br>
What I'm saying here is that:
(1) The default m= ode should be "stand-alone"
(2) The switch is SPI
(3) The processing rules for the stand-alone mode should REQUIRE at le= ast one key indicator

What you're arguing is t= hat there should not be a well-defined stand-alone mode, effectively that t= he recipient always does some pre-negotiation in order to know what fields = it needs. =A0So you're arguing that the following basic requirements fr= om the use cases document aren't actually requirements:
"""
   o  The JOSE encrypted object form=
at must support object encryption in
      the case where the sender and receiver share a symmetric key.

   o  The JOSE encrypted object format must support object encryption in
      the case where the sender has only a public key for the receiver.

   o  The JOSE signed object format must integrity protection using
      Message Authentication Codes (MACs), for the case where the sender
      and receiver share only a symmetric key.

   o  The JOSE signed object format must integrity protection using
      digital signatures, for the case where the receiver has only a
      public key for the sender.
"""
The implication of all those "only"s is that everything else h= as to be defined by the protocol specification, including which fields are = mandatory.

--Richard


=

On Mon, Apr 15, 2013 at 11:45 AM, Mike J= ones <Michael.Jones@microsoft.com> wrote:

You could say =93nice str= aw man, Jim=94, as it was Jim Schaad who proposed that the right question t= o ask was whether such use cases are important or not.=A0 I agree with Jim that clearly if they are important/in scope, then key indicators = in the headers can=92t be mandatory.

=A0<= /p>

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

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, April 15, 2013 8:41 AM
To: Mike Jones
Cc: odonoghu= e@isoc.org; jose@iet= f.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Shou= ld at least on key indicator be mandatory

=A0

Nice straw man, Mike =A0:) =A0

=A0

Nobody is arguing that cases with out-of-band negoti= ation are not important. =A0The question is how they should be supported.

=A0

What ISSUE-9 and ISSUE-15 are about is saying that t= he default assumption should be that all communication is via JW* headers. = =A0Otherwise, we're not designing a stand-alone protocol, we're des= igning an adjunct to something else, and we should do it in that WG. =A0That default assumption means that you have to= have certain contraints, like a key indicator being REQUIRED. =A0The SPI h= eader is then the "get out of jail free card", releasing you from= those constraints.

=A0

Let's design a real protocol first, then let peo= ple cheat.

=A0

--Richard

=A0

=A0

On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Reading this question, I = believe that there=92s a possibility for the question to be misinterpreted, since the sense of the question in the subject is opposite of the sense of= the question in the body.=A0 I believe that the intent of 1 and 2 were as = follows:

=A0<= /p>

1.=A0 Yes =96 Use cases w= here key information is exchanged by means other than the JWS and JWE heade= rs ARE important.

2.=A0 No =96 Use cases wh= ere key information is exchanged by means other than the JWS and JWE header= s ARE NOT important.

=A0<= /p>

Maybe people could reply = with 1 and 2 as above, so that their answers to the question of whether these use cases are important are not are unambiguous.

=A0<= /p>

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

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM


To: jose@ietf.org=
Subject: [jose] Feedback request on jose tracker issue #15: Should a= t least on key indicator be mandatory

=A0

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requir= ing that a key indicator, such as a =93kid=94 field, be required in all JWS= and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers import= ant?

Which of these best describes your preferences on th= is issue?

1.=A0 Yes.

2.=A0=A0 No.

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th (or earlier).


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--bcaec5396952f4aa0104da699e3f-- From rlb@ipv.sx Mon Apr 15 10:37:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0321F9628 for ; Mon, 15 Apr 2013 10:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxJrgo7ZyISG for ; Mon, 15 Apr 2013 10:37:12 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5626121F9588 for ; Mon, 15 Apr 2013 10:37:12 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id x4so2135774obh.1 for ; Mon, 15 Apr 2013 10:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=c42z6Ez4l1kbgkzHd1Qvpdn2EwL6CBVCNkTAlM7sXFE=; b=AhhnclHzrHnLz2dcWNGYWgB4+G8oM9CnU0NnbHJwFXSHJRj8Kznbei4cowW5INz0We CxfXctyuxRw7Qvj1FBx1paVVK+f5OA+YJHBaLDCg17104p8Jr+xSY6m8KK5tkOlEKK8D En49/vrws59IscU3rhFGlKQjVGbJ/XYlP45lbCCFJi4a3+Mgy5tadEvSjX/Pvr9ew+dh /o1rRukhRrJYb7X5X09TUFrDUWvSuKYbnGxC8RFJm3wsWSnPxHmGCHObCviroI22CUlJ PJ+8hd+Kmdj1ufdL2jy9GULviROtMo0zqL4U2hI5oDx/4CZniSby6sHeKmjkBfP2FHyF vdZA== MIME-Version: 1.0 X-Received: by 10.182.96.1 with SMTP id do1mr7719744obb.17.1366047431631; Mon, 15 Apr 2013 10:37:11 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 10:37:11 -0700 (PDT) X-Originating-IP: [137.54.9.111] In-Reply-To: <51674E2D.3040604@isoc.org> References: <51674E2D.3040604@isoc.org> Date: Mon, 15 Apr 2013 13:37:11 -0400 Message-ID: From: Richard Barnes To: odonoghue@isoc.org Content-Type: multipart/alternative; boundary=001a11c2fa02e8ba7b04da69b36e X-Gm-Message-State: ALoCoQlp47cTXBzIqT05PWTWnBFbtL3kLUqL2CI88tgM4AEbuuE/nGAEHjdCgv3Qahxpev/mJuRx Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:37:13 -0000 --001a11c2fa02e8ba7b04da69b36e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2 or 3 All of the "1" responses are missing the point of SPI -- if you want to be able to omit fields (as people seem to want to do), then you need a switch to turn off "stand-alone mode". So responding "1" here is the same as responding "1" on the ISSUE-15 poll, that at least one key indicator MUST be present. On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue wrote= : > ****Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes > adding an =93spi=94 (security parameters index) header parameter to the J= WS and > JWE specifications. This modification to the JOSE formats would allow fo= r > signaling that pre-negotiated cryptographic parameters are being used, > rather than including those parameters in the JWS or JWE header. This > proposal has been written up as > http://tools.ietf.org/html/draft-barnes-jose-spi-00.**** > > ** ** > > Which of these best describes your preferences on this issue?**** > > 1. Have draft-barnes-jose-spi remain a separate specification that could > optionally also be supported by JWS and JWE implementations.**** > > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as a mandatory feature.**** > > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as an optional feature.**** > > 4. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > Your reply is requested by Friday, April 19th or earlier. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a11c2fa02e8ba7b04da69b36e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2 or 3

All of the "1" responses are missing th= e point of SPI -- if you want to be able to omit fields (as people seem to = want to do), then you need a switch to turn off "stand-alone mode"= ;. =A0

So responding "1" here is the same as respond= ing "1" on the ISSUE-15 poll, that at least one key indicator MUS= T be present. =A0



On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue <= ;odonoghue@isoc.org= > wrote:
=20 =20 =20
Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an =93spi=94 (security parameters index) header parameter to the JWS and JWE specifications.=A0 This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.=A0 This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.=

=A0

Which of these best describes your preferences on this issue?

1.=A0 Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.=

2.=A0 Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature.<= u>

3.=A0 Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--001a11c2fa02e8ba7b04da69b36e-- From rlb@ipv.sx Mon Apr 15 10:39:05 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799F121F9641 for ; Mon, 15 Apr 2013 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=1.851, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYBigcqlidxD for ; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24C21F9635 for ; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id n1so4665856oag.37 for ; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6xMlGhKVdhpotrFRk3uRrjKNddHS/gpb8oVoPXpCTqk=; b=IPB5XsEJU02ZX1myIIGPBwOcLr/lcwZMEgXKuRjMDoKAI4mV9L7S2muPn2aDyPweEz cLga5L4VqqhrlQWWOHIqn3dgURiVgP4HCazmGhqQ61QryVriW+yYuzBRLfj+OGQsTRye 0dXfRzmhFYJEUiqlie6c51rUbZg0+mfWHccV+N7POhfTLKmosC6mUpKM/KWsOO28Bp2I Q6EO+nxDWoSVinDHrLzn8VztTBmvICQymIFZJFBVxephObdCjw8jje3j6DttnH0rEDtu RHQGKHbrthwSNuA+RuycWV9oXRNWbUAGTGFPsEkkcsXTx06T6fT8CdNmN+6QeE4Jx1hh vCCA== MIME-Version: 1.0 X-Received: by 10.60.62.39 with SMTP id v7mr2608509oer.5.1366047544040; Mon, 15 Apr 2013 10:39:04 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 10:39:03 -0700 (PDT) X-Originating-IP: [137.54.9.111] In-Reply-To: <57A12B7F-30D2-4406-A66F-1FA0B03B4313@cisco.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943675A0978@TK5EX14MBXC283.redmond.corp.microsoft.com> <004e01ce2fb9$74979730$5dc6c590$@augustcellars.com> <4EC6AC2C-8EE6-4433-8302-E884DD0B3C06@ve7jtb.com> <734D4714-BEF1-4E0C-8DB4-6753083F0F11@bbn.com> <255B9BB34FB7D647A506DC292726F6E1150C74DDCF@WSMSG3153V.srv.dir.telstra.com> <57A12B7F-30D2-4406-A66F-1FA0B03B4313@cisco.com> Date: Mon, 15 Apr 2013 13:39:03 -0400 Message-ID: From: Richard Barnes To: Matt Miller Content-Type: multipart/alternative; boundary=089e013a005a9bf1df04da69ba4e X-Gm-Message-State: ALoCoQkIzZt+Ke3siJbbYEJR5wbxIi7ySKKCS+G3X5RioiYI77mPTft213lkk2QAp0xm1SYzZVjw Cc: "cfrg@irtf.org" , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] GCM nonce reuse question X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:39:05 -0000 --089e013a005a9bf1df04da69ba4e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 11:50 AM, Matt Miller wrote: > > On Apr 15, 2013, at 9:25 AM, Richard Barnes > wrote: > > > On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H < > > James.H.Manger@team.telstra.com> wrote: > > > >> I think there are more options for handling multiple recipients of > >> AEAD-secured content: > >> > >> > >> Option 3: Put all per-recipient info into one header; keep this header > >> under the AEAD integrity check; have one nonce. > >> COST: All recipients need to be known (and their key exchange info > >> created) before the AEAD algorithm is applied. > >> COST: The JWE JSON header structure needs to be adjusted (eg to have an > >> array of recipient info) so it is not backward compatible with current > >> drafts. > >> COST: Doesn't help use cases where one recipient forwards an > >> AEAD-secured message on to a new recipient (eg an XMPP system receives a > >> message secured for a user and re-secures it for a specific device of > that > >> user). Changing recipients requires reapplying the AEAD operations. > >> COST: Each recipient needs to see key exchange info of all recipients > >> (privacy impact?). > >> POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is > >> secured as a complete unit. > >> > >> > >> Option 2b: Remove per-recipient info from AEAD integrity check; but add > >> AEAD details to each key exchange. For instance, info about an AEAD > >> operation (alg id, key id etc) potentially even including the whole > >> ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT operation > that > >> encrypts the AEAD secret key for a recipient. > >> BENEFIT: The key exchange is tied to a specific AEAD operation. > >> COST: Crypto is not typically done like this; uncertain as to what > exact > >> security properties you are getting. Perhaps there are some > similarities to > >> NIST Concat KDF that adds "context" to key derivation: this adds > "context" > >> about an AEAD operation to the key exchange. > >> > >> > >> I agree with Richard Barnes that the per-recipient key exchange details > >> should be outside the AEAD operation (not covered by the AEAD integrity > >> check). Go with option 2 or 2b. > >> Then, separately, we can decide which details of the AEAD operation > should > >> be bound to each key exchange: none? AEAD key length? AEAD alg id? whole > >> AEAD header? AEAD ciphertext? other context? > >> > >> > >> -- > >> James Manger > >> > >> > > > > At the same time, this attribute should be optional, since I think there > > are use cases where the CMK is not entirely ephemeral. For example, I > > think the current XMPP e2e document uses it as a session key rather than > an > > individual message key, so you wouldn't want to limit the key to a single > > JWE. > > > > XMPP e2e has both a session key and a per-message key. The per-message key > is protected by the session key. > > That said, I also think Option 2 or 2b makes the most sense. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > Thanks for the clarification. I think the point stands, however, that the "JWE-digest" attribute can be added as a protected attribute to the wrapped key -- if we do wrapped keys right! --Richard --089e013a005a9bf1df04da69ba4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 11:50 AM, Matt Miller <mamille2@cisco.com>= wrote:

On Apr 15, 2013, at 9:25 AM, Richard Barnes <rlb@ipv.sx>
=A0wrote:

> On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <
> James.H.Manger@team= .telstra.com> wrote:
>
>> I think there are more options for handling multiple recipients of=
>> AEAD-secured content:
>>
>>
>> Option 3: Put all per-recipient info into one header; keep this he= ader
>> under the AEAD integrity check; have one nonce.
>> =A0COST: All recipients need to be known (and their key exchange i= nfo
>> created) before the AEAD algorithm is applied.
>> =A0COST: The JWE JSON header structure needs to be adjusted (eg to= have an
>> array of recipient info) so it is not backward compatible with cur= rent
>> drafts.
>> =A0COST: Doesn't help use cases where one recipient forwards a= n
>> AEAD-secured message on to a new recipient (eg an XMPP system rece= ives a
>> message secured for a user and re-secures it for a specific device= of that
>> user). Changing recipients requires reapplying the AEAD operations= .
>> =A0COST: Each recipient needs to see key exchange info of all reci= pients
>> (privacy impact?).
>> =A0POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and co= ntent is
>> secured as a complete unit.
>>
>>
>> Option 2b: Remove per-recipient info from AEAD integrity check; bu= t add
>> AEAD details to each key exchange. For instance, info about an AEA= D
>> operation (alg id, key id etc) potentially even including the whol= e
>> ciphertext is used as the "label" for the RSAES-OAEP-ENC= RYPT operation that
>> encrypts the AEAD secret key for a recipient.
>> =A0BENEFIT: The key exchange is tied to a specific AEAD operation.=
>> =A0COST: Crypto is not typically done like this; uncertain as to w= hat exact
>> security properties you are getting. Perhaps there are some simila= rities to
>> NIST Concat KDF that adds "context" to key derivation: t= his adds "context"
>> about an AEAD operation to the key exchange.
>>
>>
>> I agree with Richard Barnes that the per-recipient key exchange de= tails
>> should be outside the AEAD operation (not covered by the AEAD inte= grity
>> check). Go with option 2 or 2b.
>> Then, separately, we can decide which details of the AEAD operatio= n should
>> be bound to each key exchange: none? AEAD key length? AEAD alg id?= whole
>> AEAD header? AEAD ciphertext? other context?
>>
>>
>> --
>> James Manger
>>
>>
>
> At the same time, this attribute should = be optional, since I think there
> are use cases where the CMK is not entirely ephemeral. =A0For example,= I
> think the current XMPP e2e document uses it as a session key rather th= an an
> individual message key, so you wouldn't want to limit the key to a= single
> JWE.
>

XMPP e2e has both a session key and a per-message key. The per-messag= e key is protected by the session key.

That said, I also think Option 2 or 2b makes the most sense.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.



--Richard
=A0
--089e013a005a9bf1df04da69ba4e-- From Michael.Jones@microsoft.com Mon Apr 15 10:45:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541721F9415 for ; Mon, 15 Apr 2013 10:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cILe9zFfGByh for ; Mon, 15 Apr 2013 10:45:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id A582921F941A for ; Mon, 15 Apr 2013 10:45:03 -0700 (PDT) Received: from BL2FFO11FD010.protection.gbl (10.173.161.204) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 17:45:02 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 17:45:01 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 17:44:38 +0000 From: Mike Jones To: Richard Barnes , "odonoghue@isoc.org" Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: AQHONxC00YowpNiVekuEgBwlBm4BWJjXkZaAgAAAggA= Date: Mon, 15 Apr 2013 17:44:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436764218A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E2D.3040604@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436764218ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(189002)(5383001)(199002)(377454001)(77982001)(5343635001)(81542001)(74502001)(74662001)(69226001)(16406001)(4396001)(33656001)(51856001)(66066001)(56776001)(55846006)(44976003)(54356001)(65816001)(47736001)(16236675002)(5343655001)(16297215002)(20776003)(512954001)(50986001)(47976001)(76482001)(81342001)(53806001)(71186001)(59766001)(564824004)(63696002)(561944001)(18277545001)(80022001)(18276755001)(56816002)(49866001)(15202345002)(79102001)(47446002)(46102001)(31966008)(54316002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:45:06 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436764218ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Use of "spi" is one such possible "switch". Use of the OAuth Dynamic Clien= t Registration specification to obtain keys or key references is another. = Other applications may choose exchange the keys other ways. The "switch" doesn't have to be a JOSE protocol element. Although you coul= d consider the lack of a key indicator in the JOSE header to be a clear ind= ication in the JOSE protocol elements that the switch has been thrown, mean= ing that it's up to the application to use its logical to determine which k= ey(s) to use - which is a normal use case. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, April 15, 2013 10:37 AM To: odonoghue@isoc.org Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? 2 or 3 All of the "1" responses are missing the point of SPI -- if you want to be = able to omit fields (as people seem to want to do), then you need a switch = to turn off "stand-alone mode". So responding "1" here is the same as responding "1" on the ISSUE-15 poll, = that at least one key indicator MUST be present. On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue > wrote: Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding a= n "spi" (security parameters index) header parameter to the JWS and JWE spe= cifications. This modification to the JOSE formats would allow for signali= ng that pre-negotiated cryptographic parameters are being used, rather than= including those parameters in the JWS or JWE header. This proposal has be= en written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436764218ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Use of “spi” = is one such possible “switch”.  Use of the OAuth Dynamic C= lient Registration specification to obtain keys or key references is anothe= r.  Other applications may choose exchange the keys other ways.

 <= /p>

The “switch” = doesn’t have to be a JOSE protocol element.  Although you could = consider the lack of a key indicator in the JOSE header to be a clear indic= ation in the JOSE protocol elements that the switch has been thrown, meaning tha= t it’s up to the application to use its logical to determine which ke= y(s) to use – which is a normal use case.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, April 15, 2013 10:37 AM
To: odonoghue@isoc.org
Cc: jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #8: Shoul= d we add a "spi" header field?

 

2 or 3

 

All of the "1" responses are missing the p= oint of SPI -- if you want to be able to omit fields (as people seem to wan= t to do), then you need a switch to turn off "stand-alone mode". =  

 

So responding "1" here is the same as resp= onding "1" on the ISSUE-15 poll, that at least one key indicator = MUST be present.  

 

 

On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue &l= t;odonoghue@isoc.or= g> wrote:

Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an = 220;spi” (security parameters index) header parameter to the JWS and = JWE specifications.  This modification to the JOSE formats would allow= for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the J= WS or JWE header.  This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.

 

Which of these best describes your preferences on this issue?=

1.  Have draft-barnes-jose-spi remain a separate specificatio= n that could optionally also be supported by JWS and JWE implementations.

2.  Incorporate draft-barnes-jose-spi into the JWS and JWE sp= ecifications as a mandatory feature.

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE sp= ecifications as an optional feature.

4.  Another resolution (please specify in detail).=

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436764218ATK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Apr 15 10:47:56 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4516B21F90FD for ; Mon, 15 Apr 2013 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SPICE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOkiEYsiTrEz for ; Mon, 15 Apr 2013 10:47:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29821F8EC3 for ; Mon, 15 Apr 2013 10:47:52 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.203) by BL2FFO11HUB022.protection.gbl (10.173.161.46) with Microsoft SMTP Server (TLS) id 15.0.675.0; Mon, 15 Apr 2013 17:47:50 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 17:47:50 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 17:47:31 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: AQHONxCooSd2LAEBTkqzIVwx4JWauZjSDFgAgAVkswCAAABasIAAHo2AgAADoBA= Date: Mon, 15 Apr 2013 17:47:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676421F3@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641542@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676421F3TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5383001)(377454001)(199002)(189002)(24454001)(20776003)(46102001)(81542001)(16236675002)(63696002)(81342001)(18277545001)(33656001)(49866001)(56816002)(69226001)(512954001)(50986001)(54356001)(51856001)(47736001)(54316002)(15202345002)(55846006)(80022001)(56776001)(59766001)(71186001)(4396001)(564824004)(79102001)(5343655001)(47446002)(65816001)(53806001)(77982001)(47976001)(74502001)(74662001)(76482001)(5343635001)(16406001)(31966008)(44976003)(18276755001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB022; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:47:56 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676421F3TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll plan on reviewing the Use Cases document after finishing the current s= pec updates to the other specs. If you believe that the use Cases Document= as written precludes use cases where keys are exchanged by mechanisms othe= r than the JOSE headers, that's an indication that some use cases are missi= ng from the document. Best wishes, -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, April 15, 2013 10:31 AM To: Mike Jones Cc: odonoghue@isoc.org; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory You're making the same false argument I just addressed. Covering use cases= involving pre-negotiation does not imply that headers can't be mandatory. = It implies that they can't be mandatory in all cases -- that is, that ther= e needs to be a "pre-negotiated mode" in which headers are not mandatory in= addition to the "stand-alone mode" where everything needs to be expressed = in the headers (no pre-negotiation). I am completely fine with supporting both modes, but in order to do that, i= t needs to be clear to a recipient which mode is in use. So we need to: (1) Choose a default mode, (2) Have a switch that indicates when the non-default mode is being used, a= nd (3) Define generation and processing rules for both modes. What I'm saying here is that: (1) The default mode should be "stand-alone" (2) The switch is SPI (3) The processing rules for the stand-alone mode should REQUIRE at least o= ne key indicator What you're arguing is that there should not be a well-defined stand-alone = mode, effectively that the recipient always does some pre-negotiation in or= der to know what fields it needs. So you're arguing that the following bas= ic requirements from the use cases document aren't actually requirements: """ o The JOSE encrypted object format must support object encryption in the case where the sender and receiver share a symmetric key. o The JOSE encrypted object format must support object encryption in the case where the sender has only a public key for the receiver. o The JOSE signed object format must integrity protection using Message Authentication Codes (MACs), for the case where the sender and receiver share only a symmetric key. o The JOSE signed object format must integrity protection using digital signatures, for the case where the receiver has only a public key for the sender. """ The implication of all those "only"s is that everything else has to be defi= ned by the protocol specification, including which fields are mandatory. --Richard On Mon, Apr 15, 2013 at 11:45 AM, Mike Jones > wrote: You could say "nice straw man, Jim", as it was Jim Schaad who proposed that= the right question to ask was whether such use cases are important or not.= I agree with Jim that clearly if they are important/in scope, then key in= dicators in the headers can't be mandatory. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, April 15, 2013 8:41 AM To: Mike Jones Cc: odonoghue@isoc.org; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at l= east on key indicator be mandatory Nice straw man, Mike :) Nobody is arguing that cases with out-of-band negotiation are not important= . The question is how they should be supported. What ISSUE-9 and ISSUE-15 are about is saying that the default assumption s= hould be that all communication is via JW* headers. Otherwise, we're not d= esigning a stand-alone protocol, we're designing an adjunct to something el= se, and we should do it in that WG. That default assumption means that you= have to have certain contraints, like a key indicator being REQUIRED. The= SPI header is then the "get out of jail free card", releasing you from tho= se constraints. Let's design a real protocol first, then let people cheat. --Richard On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones > wrote: Reading this question, I believe that there's a possibility for the questio= n to be misinterpreted, since the sense of the question in the subject is o= pposite of the sense of the question in the body. I believe that the inten= t of 1 and 2 were as follows: 1. Yes - Use cases where key information is exchanged by means other than = the JWS and JWE headers ARE important. 2. No - Use cases where key information is exchanged by means other than t= he JWS and JWE headers ARE NOT important. Maybe people could reply with 1 and 2 as above, so that their answers to th= e question of whether these use cases are important are not are unambiguous= . -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Thursday, April 11, 2013 5:00 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19th (or earlier). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676421F3TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll plan on review= ing the Use Cases document after finishing the current spec updates to the = other specs.  If you believe that the use Cases Document as written precludes use cases where keys are exchanged by mechanisms other than the = JOSE headers, that’s an indication that some use cases are missing fr= om the document.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Best wishes,

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

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, April 15, 2013 10:31 AM
To: Mike Jones
Cc: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Shou= ld at least on key indicator be mandatory

 

You're making the same false argument I just address= ed.  Covering use cases involving pre-negotiation does not imply that = headers can't be mandatory.  It implies that they can't be mandatory i= n all cases -- that is, that there needs to be a "pre-negotiated mode" in which headers are not mandatory in= addition to the "stand-alone mode" where everything needs to be = expressed in the headers (no pre-negotiation).

 

I am completely fine with supporting both modes, but= in order to do that, it needs to be clear to a recipient which mode is in = use.  So we need to:

(1) Choose a default mode,

(2) Have a switch that indicates when the non-defaul= t mode is being used, and

(3) Define generation and processing rules for both = modes.

 

What I'm saying here is that:

(1) The default mode should be "stand-alone&quo= t;

(2) The switch is SPI

(3) The processing rules for the stand-alone mode sh= ould REQUIRE at least one key indicator

 

What you're arguing is that there should not be a we= ll-defined stand-alone mode, effectively that the recipient always does som= e pre-negotiation in order to know what fields it needs.  So you're ar= guing that the following basic requirements from the use cases document aren't actually requirements:

"""

   o  The JOSE encrypt=
ed object format must support object encryption in
      the ca=
se where the sender and receiver share a symmetric key.

 


   o  The JOSE encrypt=
ed object format must support object encryption in


      the ca=
se where the sender has only a public key for the receiver.


 


   o  The JOSE signed =
object format must integrity protection using


      Messag=
e Authentication Codes (MACs), for the case where the sender


      and re=
ceiver share only a symmetric key.


 


   o  The JOSE signed =
object format must integrity protection using


      digita=
l signatures, for the case where the receiver has only a<=
/pre>

      public=
 key for the sender.

"""

The implication of all those "only"s is th= at everything else has to be defined by the protocol specification, includi= ng which fields are mandatory.

 

--Richard

 

 

 

On Mon, Apr 15, 2013 at 11:45 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

You could say “nice straw man, Ji= m”, as it was Jim Schaad who proposed that the right question to ask was whether such use cases are important or not.  I agree with Ji= m that clearly if they are important/in scope, then key indicators in the h= eaders can’t be mandatory.

 

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

 

From: Richard Barnes [mailto= :rlb@ipv.sx]
Sent: Monday, April 15, 2013 8:41 AM
To: Mike Jones
Cc: odonoghu= e@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Shou= ld at least on key indicator be mandatory

 

Nice straw man, Mike  :)  

 

Nobody is arguing that cases with out-of-band negotiation are not = important.  The question is how they should be supported.

 

What ISSUE-9 and ISSUE-15 are about is saying that the default ass= umption should be that all communication is via JW* headers.  Otherwis= e, we're not designing a stand-alone protocol, we're designing an adjunct to something else, and we should do it in that = WG.  That default assumption means that you have to have certain contr= aints, like a key indicator being REQUIRED.  The SPI header is then th= e "get out of jail free card", releasing you from those constraints.

 

Let's design a real protocol first, then let people cheat.

 

--Richard

 

 

On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones <Michael.Jones@microsoft.com<= /a>> wrote:

Reading this question, I believe that t= here’s a possibility for the question to be misinterpreted, since the sense of the question in the subject is opposite of the sense of= the question in the body.  I believe that the intent of 1 and 2 were = as follows:

 

1.  Yes – Use cases where ke= y information is exchanged by means other than the JWS and JWE headers ARE important.

2.  No – Use cases where key= information is exchanged by means other than the JWS and JWE headers ARE NOT important.

 

Maybe people could reply with 1 and 2 a= s above, so that their answers to the question of whether these use cases are important are not are unambiguous.

 

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

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM


To: jose@ietf.org=
Subject: [jose] Feedback request on jose tracker issue #15: Should a= t least on key indicator be mandatory

 

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requir= ing that a key indicator, such as a “kid” field, be required in= all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers import= ant?

Which of these best describes your preferences on this issue?=

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th (or earli= er).


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943676421F3TK5EX14MBXC283r_-- From rlb@ipv.sx Mon Apr 15 10:57:18 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB6521F940B for ; Mon, 15 Apr 2013 10:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=1.244, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTZi-+L8Pxm7 for ; Mon, 15 Apr 2013 10:57:16 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 14DEF21F90B9 for ; Mon, 15 Apr 2013 10:57:16 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id g12so4641728oah.24 for ; Mon, 15 Apr 2013 10:57:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=0iQ2GkYecC9RqvIje3eywCOmY+9IxD9ln35tic3Wfsc=; b=D860byh3X37S8a9w7MQ3O7ryf3ikzW5i16rPDQZCBiLTmgH0I3WLOARYos+PXdMp8H qs8do4CcLTYfXDmNpK6663dxocyA1XjVQN89NkcwVb329euewKN+6Q3l+DeTqr7swCuR DYc7c2AINKxURasVWITPkphDGYSZF+EQcBdCPZzkTVCaERSfQkw2yyEkPxkd+87S/mxR X/+rSwS+C5NAXSGPkaKWiL+geokYITa2kYks8epalE4+wSp5f++CHWQXu9DdP6ISWk1t GdLFHD7u8tNIrOgl0CfLaMveSf6Hmn/1zzkU7o/HGcC2jywN5w5pRqkXXh8x8okqernv 7txg== MIME-Version: 1.0 X-Received: by 10.60.121.104 with SMTP id lj8mr8205509oeb.83.1366048635606; Mon, 15 Apr 2013 10:57:15 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 10:57:15 -0700 (PDT) X-Originating-IP: [137.54.9.111] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436761CA72@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436761CA72@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 13:57:15 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b3a9734abe8be04da69fbb4 X-Gm-Message-State: ALoCoQk8vkJ2ZYjySR6SruDNbzN6xE6OTXcGK9DwtKXVozKipa0TMmjreTLu722zG8LEbXny/ogq Cc: Jim Schaad , "jose@ietf.org" , Karen O'Donoghue Subject: Re: [jose] Proposed Agenda for Interim Working Group Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:57:18 -0000 --047d7b3a9734abe8be04da69fbb4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for putting together this initial proposal, Mike. I might propose to organize things a little differently, as I think there are a few major issues that will drive resolutions to the individual issues in the tracker, and get us much closer to WGLC. My list of critical issues right now is: 1. What should be covered by header integrity protection? 2. What should the wrapped key formats be (JWE and stand-alone)? 3. Which fields are required under which circumstances (pre-negotiated / stand-alone modes)? I think we could probably spend 2-4 hours on each of those questions, but if we come to some resolution, then by my count, we would be very close to resolving issues 4, 5, 6, 9, 2, 13, 14, 15, 16, 17, and 18. All of those issues are decided, at least at a high level, by the answers to the above questions. Another 4 issues fall under what I'll call "crypto usage issues", namely 3, 8, 11, and 19. So maybe we could divide the agenda roughly in 4, and have one large discussion on each of the above topics, with the goal of getting consensus on some answers to the above questions. --Richard On Sat, Apr 13, 2013 at 2:47 PM, Mike Jones wr= ote: > Knowing that we need to publish an agenda for the interim meeting soon, > I thought I=92d propose a starting point to kick off the agenda discussio= ns. > My goal is to have us make the most progress possible towards resolving > open issues.**** > > ** ** > > -- Mike**** > > ** ** > > MONDAY, APRIL 29**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > ** ** > > 9:00-9:30: Note Well, Introductions, Logistics, Goals, Day 1 Agenda > Overview =96 Jim Schaad and Karen O=92Donoghue**** > > 9:30-9:50: Overview of Recent changes to JWS, JWE, JWK, and JWA document= s > =96 Mike Jones**** > > The goal of this brief session is for attendees to > understand the changes made and issues addressed by those changes**** > > 9:50-10:05: Break**** > > 10:05-12:00: Existing Open Issues Session 1**** > > The goal of this session, and the other open issues > sessions, is, for each issue to:**** > > - Identify possible resolutions**** > > - Determine support in the room for each of > the resolutions**** > > - Determine what specific question(s) to as= k > the working group on the list**** > > - Propose closure of the issue with a > specific resolution if consensus is apparent**** > > (with actual closure happening after > confirming the consensus on the mailing list)**** > > - Issue #7: Algorithm identifiers/parameters incompatible > with WebCrypto**** > > - Issue #11: Should we use RFC 5116 and remove the JWE > Integrity Value field?**** > > - Issue #12: Should the x5c field be removed from JWE?***= * > > - Issue #15: Should at least one key indicator be > mandatory?**** > > 12:00-12:45: Lunch**** > > 12:45-2:45: Existing Open Issues Session 2**** > > - Presentation by Richard Barnes on > draft-barnes-jose-key-wrapping (assuming he=92s willing!)**** > > - Review by Matt Miller of > draft-miller-jose-jwe-protected-jwk (assuming he=92s willing!)**** > > - Issue #13: Enable AEAD key wrapping**** > > - Issue #14: Support longer wrapped keys than OAEP allows= * > *** > > 2:45-3:05: Break**** > > 3:05-5:00: Existing Open Issues Session 3**** > > - Issue #4: Remove wrapped keys from integrity check > (allow separation of keys from data)**** > > - Issue #9: Should we add a "spi" header field?**** > > - Issue #16: URI identifying a specific key in a JWK set*= * > ** > > - Issue #17: Add 'aud' and 'iss' to 4.1 Reserved Header > Parameter Names**** > > - Issue #18: Address MAC key lifetime concerns**** > > - Issue #8: Direct mode for key agreement needs security > analysis**** > > ** ** > > TUESDAY, APRIL 30**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > ** ** > > 9:00-9:20: Note Well, Day 2 Agenda Overview =96 Jim Schaad and Karen > O=92Donoghue**** > > 9:20-10:20: W3C WebCrypto Coordination**** > > Discuss touch points between WebCrypto and JOSE and > determine feedback to give WebCrypto**** > > 10:20-10:35: Break**** > > 10:35-11:15: Use Cases**** > > Discuss issues with the Use Cases specification and > possible changes needed**** > > 11:15-12:00: Next Steps Session 1 =96 Status of Key Wrapping Drafts**** > > Determine next steps for issues covered in > draft-barnes-jose-key-wrapping and draft-miller-jose-jwe-protected-jwk***= * > > In particular, should either become WG drafts?**** > > 12:00-12:45: Lunch**** > > 12:45-1:45: Next Steps Session 2 =96 Discuss actions needed to bring JWS= , > JWE, JWK, and JWA to Working Group Last Call**** > > The goal of this session is to determine specific steps > needed to achieve WGLC and assign owners and timelines**** > > 1:45-2:45: Next Steps Session 3 =96 Polls and Consensus Calls**** > > Determine specific wording for polls and consensus calls > needed to gather input on remaining open issues**** > > 2:45-3:00: Break**** > > 3:00-3:20: Next Steps Session 4 =96 Next Meetings and Phone Calls**** > > Decide when our next meetings will be and at what times to > schedule recurring WG phone calls**** > > 3:20-4:00: Summarize of Next Steps**** > > Review next steps, owners, and timelines for those steps t= o > occur**** > > 4:00-5:00: Other Topics**** > > This time is reserved to consider other issues or topics > that may arise**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7b3a9734abe8be04da69fbb4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for putting together this initial proposal, Mike. =A0I might propose= to organize things a little differently, as I think there are a few major = issues that will drive resolutions to the individual issues in the tracker,= and get us much closer to WGLC. =A0My list of critical issues right now is= :

1. What should be covered by header integrity protection? = =A0
2. What should the wrapped key formats be (JWE and stand-alon= e)?=A0
3. Which fields are required under which circumstances (pr= e-negotiated / stand-alone modes)?=A0

I think we could probably spend 2-4 hours on each of th= ose questions, but if we come to some resolution, then by my count, we woul= d be very close to resolving issues 4, 5, 6, 9, 2, 13, 14, 15, 16, 17, and = 18. =A0All of those issues are decided, at least at a high level, by the an= swers to the above questions.

Another 4 issues fall under what I'll call "cr= ypto usage issues", namely 3, 8, 11, and 19. =A0

<= div>So maybe we could divide the agenda roughly in 4, and have one large di= scussion on each of the above topics, with the goal of getting consensus on= some answers to the above questions.

--Richard



<= /div>


On Sat, Apr 13, 2013 at 2:47 P= M, Mike Jones <Michael.Jones@microsoft.com> wrote:=

Knowing that we need to publish an agenda for the in= terim meeting soon, I thought I=92d propose a starting point to kick off th= e agenda discussions.=A0 My goal is to have us make the most progress possi= ble towards resolving open issues.

=A0

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

=A0

MONDAY, APRIL 29

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=A0

9:00-9:30:=A0 Note Well, Introductions, Logistics, G= oals, Day 1 Agenda Overview =96 Jim Schaad and Karen O=92Donoghue=

9:30-9:50:=A0 Overview of Recent changes to JWS, JWE= , JWK, and JWA documents =96 Mike Jones

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The goal = of this brief session is for attendees to understand the changes made and i= ssues addressed by those changes

9:50-10:05:=A0 Break

10:05-12:00:=A0 Existing Open Issues Session 1

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The goal = of this session, and the other open issues sessions, is, for each issue to:=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Identify possible resolutions=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Determine support in the room for ea= ch of the resolutions

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Determine what specific question(s) = to ask the working group on the list

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Propose closure of the issue with a = specific resolution if consensus is apparent

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 (with actual closure happening = after confirming the consensus on the mailing list)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Issue #= 7:=A0 Algorithm identifiers/parameters incompatible with WebCry= pto

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #11:=A0 Should we use RFC 5116 and remove the JWE Integrity Value field= ?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #12:=A0 Should the x5c field be removed from JWE?=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Issue #= 15:=A0 Should at least one key indicator be mandatory?

12:00-12:45:=A0 Lunch

12:45-2:45:=A0 Existing Open Issues Session 2=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Present= ation by Richard Barnes on draft-barnes-jose-key-wrapping (assuming he=92s = willing!)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Review = by Matt Miller of draft-miller-jose-jwe-protected-jwk (assuming he=92s will= ing!)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #13:=A0 Enable AEAD key wrapping

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #14:=A0 Support longer wrapped keys than OAEP allows<= /u>

2:45-3:05:=A0 Break

3:05-5:00:=A0 Existing Open Issues Session 3<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #4:=A0 Remove wrapped keys from integrity check (allow separati= on of keys from data)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #9:=A0 Should we add a "spi" header field?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #16:=A0 URI identifying a specific key in a JWK set

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #17:=A0 Add 'aud' and 'iss' to 4.1 Reserved Hea= der Parameter Names

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #18:=A0 Address MAC key lifetime concerns<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 - Issue #8:=A0 Direct mode for key agreement needs security analysis=

=A0

TUESDAY, APRIL 30

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=A0

9:00-9:20:=A0 Note Well, Day 2 Agenda Overview =96 J= im Schaad and Karen O=92Donoghue

9:20-10:20:=A0 W3C WebCrypto Coordination<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Discuss t= ouch points between WebCrypto and JOSE and determine feedback to give WebCr= ypto

10:20-10:35:=A0 Break

10:35-11:15: =A0Use Cases

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Discuss i= ssues with the Use Cases specification and possible changes needed

11:15-12:00:=A0 Next Steps Session 1 =96 Status of K= ey Wrapping Drafts

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Determine= next steps for issues covered in draft-barnes-jose-key-wrapping and draft-= miller-jose-jwe-protected-jwk

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In partic= ular, should either become WG drafts?

12:00-12:45:=A0 Lunch

12:45-1:45:=A0 Next Steps Session 2 =96 Discuss acti= ons needed to bring JWS, JWE, JWK, and JWA to Working Group Last Call

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The goal = of this session is to determine specific steps needed to achieve WGLC and a= ssign owners and timelines

1:45-2:45:=A0 Next Steps Session 3 =96 Polls and Con= sensus Calls

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Determine= specific wording for polls and consensus calls needed to gather input on r= emaining open issues

2:45-3:00:=A0 Break

3:00-3:20:=A0 Next Steps Session 4 =96 Next Meetings= and Phone Calls

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Decide wh= en our next meetings will be and at what times to schedule recurring WG pho= ne calls

3:20-4:00:=A0 Summarize of Next Steps<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Review ne= xt steps, owners, and timelines for those steps to occur

4:00-5:00:=A0 Other Topics

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This time= is reserved to consider other issues or topics that may arise

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--047d7b3a9734abe8be04da69fbb4-- From edmundjay@sbcglobal.net Mon Apr 15 11:03:40 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A475521F9473 for ; Mon, 15 Apr 2013 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYyVx4yxupxM for ; Mon, 15 Apr 2013 11:03:40 -0700 (PDT) Received: from nm22.access.bullet.mail.mud.yahoo.com (nm22.access.bullet.mail.mud.yahoo.com [66.94.237.223]) by ietfa.amsl.com (Postfix) with ESMTP id EFBC021F9457 for ; Mon, 15 Apr 2013 11:03:39 -0700 (PDT) Received: from [66.94.237.193] by nm22.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:03:39 -0000 Received: from [66.94.237.123] by tm4.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:03:39 -0000 Received: from [127.0.0.1] by omp1028.access.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:03:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 565089.73981.bm@omp1028.access.mail.mud.yahoo.com Received: (qmail 42304 invoked by uid 60001); 15 Apr 2013 18:03:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1366049019; bh=w16xHXHVluVuKlVNhvQZdZBejqL1PJFEVNXmDZQpaFY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Cf3GPe75nWWA8ydGmlzSi79IQlnw2U3Xb5qXmiF8aDhMuYdIXy8AreAi0JekPrLkDgtGJw1HjoHa4knNuxMLN4ofznJHXTqrVKTal0oxvFABKqA1/axTWScb0fF2AHynM0/588qXxcQ1V6Tism/OlWb1Jc60lrY4NcL+q4S8f3I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Rv9QHdLig88oSpjwMRiqIUp+uW3wwV+5obm2PX1MqDb042+LMEOEG9BGyHbZjKYVh1lswtubqGTRAm86XdQhmcFh6irzUQJdeUZy1uevKRXoHWz6okG7aZSWJy1sQprau4FDMcdbft7Ba14GofgsFT7stvZ6bvMCS8EONhohO84=; X-YMail-OSG: ggutNG0VM1n7.om7EgQDgJp3syOgz.3xJZ6uKq7MWEt0E3R 0I_t0op9Lw9I37TKovpN4mVrTkHfitdODI6KfHFn8bTkGinSy0jHjYwrWNMW Cf23QlT9P0QM4erEJIyyplWdzzHUH8vuH5VG3oxpfIXP4lRwK.PIsWcLWp_4 4b_3BKY178VB4eIkruN9nCS99Mey.UpE6Z14fiIqfsX40fPOgO2n2oAF5Utv l.RW0l68Qe9UwjsZnZxXbApQ376F5T6VK8HsDiKdQQ3.m2.T3pEskWB2xANr yzK.OLymHv4qPW4UyV.8tII7T1FtOX426N06Q0_zYDXISSkLffSHhP3spPhy SeVe.gLSFT4fqQP4JU6x02VL1NJ.B0ltVwXstC7JqRtJLQW_RVsSzt4P8Owj BsWi.mqpx77AukBS0ICK_jlUibAnQ_ZYPG2OS1KHX0_Dk.XeXmox8_BBakUm Y9wwNn.ibERYZ6ho88EJHIHqRuFOePNUlLHJO3Bqabs5G2J0_8Jjsi.B.xIM SlamoE9f57yXnEnxIrAgbw7VA2tt2j4RMugkpI57q7mGBwisj68q1rSrd3Ec 43QE_NZOEN5ZiWX6gkdc- Received: from [70.36.254.42] by web184401.mail.bf1.yahoo.com via HTTP; Mon, 15 Apr 2013 11:03:38 PDT X-Rocket-MIMEInfo: 002.001, MQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPgpUbzogam9zZUBpZXRmLm9yZwpTZW50OiBUaHUsIEFwcmlsIDExLCAyMDEzIDQ6NTg6MjAgUE0KU3ViamVjdDogW2pvc2VdIEZlZWRiYWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlzc3VlICM3OiBBbGdvcml0aG0gCmlkZW50aWZpZXJzL3BhcmFtZXRlcnMgaW5jb21wYXRpYmxlIHdpdGggV2ViQ3J5cHRvCgpJc3N1ZSAjNyBodHRwOi8vdHJhYy50b29scy5pZXQBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/728 YahooMailWebService/0.8.140.532 References: <51674E17.5020902@isoc.org> Message-ID: <1366049018.34273.YahooMailRC@web184401.mail.bf1.yahoo.com> Date: Mon, 15 Apr 2013 11:03:38 -0700 (PDT) From: Edmund Jay To: odonoghue@isoc.org, jose@ietf.org In-Reply-To: <51674E17.5020902@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1009959307-1232555541-1366049018=:34273" Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:03:40 -0000 --1009959307-1232555541-1366049018=:34273 Content-Type: text/plain; charset=us-ascii 1 ________________________________ From: Karen O'Donoghue To: jose@ietf.org Sent: Thu, April 11, 2013 4:58:20 PM Subject: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers. The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. Which of these best describes your preferences on this issue? 1. Continue have the JWA algorithm identifiers be strings, and not objects. Note that WebCrypto may choose to use some of these same strings, where applicable. 2. Switch to using the algorithm identifier structures defined in the WebCrypto draft. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. --1009959307-1232555541-1366049018=:34273 Content-Type: text/html; charset=us-ascii
1

From: Karen O'Donoghue <odonoghue@isoc.org>
To: jose@ietf.org
Sent: Thu, April 11, 2013 4:58:20 PM
Subject: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto

Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.  The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.


Which of these best describes your preferences on this issue?

1.  Continue have the JWA algorithm identifiers be strings, and not objects.  Note that WebCrypto may choose to use some of these same strings, where applicable.

2.  Switch to using the algorithm identifier structures defined in the WebCrypto draft.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.



--1009959307-1232555541-1366049018=:34273-- From edmundjay@sbcglobal.net Mon Apr 15 11:04:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5143C21F9473 for ; Mon, 15 Apr 2013 11:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF+rHJapb9aZ for ; Mon, 15 Apr 2013 11:04:28 -0700 (PDT) Received: from nm24-vm0.access.bullet.mail.mud.yahoo.com (nm24-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55C21F9457 for ; Mon, 15 Apr 2013 11:04:28 -0700 (PDT) Received: from [66.94.237.192] by nm24.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:04:28 -0000 Received: from [66.94.237.111] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:04:28 -0000 Received: from [127.0.0.1] by omp1016.access.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:04:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 120855.5016.bm@omp1016.access.mail.mud.yahoo.com Received: (qmail 42762 invoked by uid 60001); 15 Apr 2013 18:04:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1366049067; bh=t9vOQsSTectDYbuZMuWslr9PVw19nrb/Iuz1o3CdMCc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PhbBPWzz5khf7EUw3xW0WPPw0mmAi6ehd4voAvupQc25ksYGQlVXlug9opPVC7vIUgBYIG9Q/GAyBlnTlqqZDqxZZSMfWHTkYFEdoasZc0xT46iznw9TZJnp1YXJld+SoblKt+m+4ULLcJDC9hempQIMLlBwwNUU/oxMdehu4Yc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=i6mN6WD5RAthq+j0pIT5ZMJTwYetRRHtXR76nC6lJts8Fn4HgKiX7BD5fWetKduhUIvx270rObSDKTKDp/jd2hKc51A4tBnjtC8NN0u5xXqVWj7WD1pyVqXeZEamCBNqJIFwNfPUcjcTy/UwvkKB0g5VgG9VladfFqwYBvMgY74=; X-YMail-OSG: 4CG5R7kVM1nnZKVChV11oXMH0.tR25MhsNTUwaO83NBXcoY JKax1Ri44_Iaf67_aPFKW9WgRrrnIc_WAv_uDy.L9OV9qjW_dJzbvs1c8.hz G2392MSZis1rXX4kOF2a8Q2ni8FB9SHy27ptSI_QmERt07XspRiw64oFI6Rs mEuGD1HGP7nqw6QsRHDsIqGOjNpAgjN2VBHCJJkVk3EM2UrUdebqX2l8WCWV osGTKJjDrt2uFM4jKidj2DtpWq85jima3cIPtCZ661yYANXyUHUi1Pd5y_ns epjy6O0_BHq3yJRldf1oXNtakICEHIcpJCR0GQrf_8YPE68any0Syr2QVVGr sCtHZDd8PhHeetRbiN9csH19LMuOiH03kkAPbmdqHaec19JHL_PDnlbL_FqY 6boUKETangrodeZkHx2w3fEBHvRnl3ERMajyypPAKZaNWHtN3b_B7w08KxLq .gMT20jcGLh5Dlqtf7dAClQBWKWOg.YespceuDpgozagE4xBry31V3vkgpG_ e8_lKejPX2VA- Received: from [70.36.254.42] by web184401.mail.bf1.yahoo.com via HTTP; Mon, 15 Apr 2013 11:04:27 PDT X-Rocket-MIMEInfo: 002.001, MQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPgpUbzogam9zZUBpZXRmLm9yZwpTZW50OiBUaHUsIEFwcmlsIDExLCAyMDEzIDQ6NTg6NDUgUE0KU3ViamVjdDogW2pvc2VdIEZlZWRiYWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlzc3VlICM4OiBTaG91bGQgd2UgYWRkIGEgInNwaSIgCmhlYWRlciBmaWVsZD8KCklzc3VlICM4IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/728 YahooMailWebService/0.8.140.532 References: <51674E2D.3040604@isoc.org> Message-ID: <1366049067.38201.YahooMailRC@web184401.mail.bf1.yahoo.com> Date: Mon, 15 Apr 2013 11:04:27 -0700 (PDT) From: Edmund Jay To: odonoghue@isoc.org, jose@ietf.org In-Reply-To: <51674E2D.3040604@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1009959307-156234040-1366049067=:38201" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:04:29 -0000 --1009959307-156234040-1366049067=:38201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1=0A=0A=0A=0A=0A________________________________=0AFrom: Karen O'Donoghue <= odonoghue@isoc.org>=0ATo: jose@ietf.org=0ASent: Thu, April 11, 2013 4:58:45= PM=0ASubject: [jose] Feedback request on jose tracker issue #8: Should we = add a "spi" =0Aheader field?=0A=0AIssue #8 http://trac.tools.ietf.org/wg/jo= se/trac/ticket/8 proposes adding an =0A=E2=80=9Cspi=E2=80=9D (security = parameters index) header parameter to the JWS and JWE =0Aspecifications= . This modification to the JOSE formats would allow for =0Asignaling t= hat pre-negotiated cryptographic parameters are being used, =0Arather t= han including those parameters in the JWS or JWE header. This =0Apropo= sal has been written up as =0Ahttp://tools.ietf.org/html/draft-barnes-jose-= spi-00. =0A=0A =0AWhich of these best describes your preferences on= this issue?=0A1. Have draft-barnes-jose-spi remain a separate spe= cification that =0Acould optionally also be supported by JWS and JW= E implementations.=0A2. Incorporate draft-barnes-jose-spi into the= JWS and JWE =0Aspecifications as a mandatory feature.=0A3. Incorporate = draft-barnes-jose-spi into the JWS and JWE =0Aspecifications as an = optional feature.=0A4. Another resolution (please specify in= detail).=0A0. I need more information to decide.Your reply is req= uested by Friday, =0AApril 19th or earlier. --1009959307-156234040-1366049067=:38201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
1

From: Karen O'Donoghue &= lt;odonoghue@isoc.org>
To: jose@ietf.org
Sent:<= /b> Thu, April 11, 2013 4:58:45 PM
Subject: [jose] Feedback request on jose tracker issue #8: Shou= ld we add a "spi" header field?

=0A =0A=0A =0A =0A =0A = Issue #8 =0A http://trac.tools.ietf.org/wg/jos= e/trac/ticket/8 proposes=0A adding an =E2=80=9Cspi=E2=80=9D (securit= y parameters index) header parameter to the=0A JWS and JWE specification= s.  This modification to the JOSE formats=0A would allow for signal= ing that pre-negotiated cryptographic=0A parameters are being used, rath= er than including those parameters in=0A the JWS or JWE header.  Th= is proposal has been written up as=0A http://too= ls.ietf.org/html/draft-barnes-jose-spi-00. =0A

 

=0A

Which of these best=0A describes y= our preferences on this issue?

=0A

1.  Have=0A draft-barnes-jose-spi rem= ain a separate specification that could=0A optionally also be suppor= ted by JWS and JWE implementations.

=0A

2.  Incorporate draft-barnes-jose-spi= =0A into the JWS and JWE specifications as a mandatory feature.

=0A

3.  = Incorporate=0A draft-barnes-jose-spi into the JWS and JWE specificat= ions as an=0A optional feature.

=0A

4.  Another=0A resolution (pl= ease specify in detail).

=0A

0.  I need more=0A information to decide.

=0A Your reply is requested by Fr= iday, April=0A 19th or earlier.
=0A =0A =0A= =0A
=0A=0A=0A=0A
--1009959307-156234040-1366049067=:38201-- From edmundjay@sbcglobal.net Mon Apr 15 11:04:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1740C21F95C3 for ; Mon, 15 Apr 2013 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4CFaKtXnW7A for ; Mon, 15 Apr 2013 11:04:56 -0700 (PDT) Received: from nm23.access.bullet.mail.mud.yahoo.com (nm23.access.bullet.mail.mud.yahoo.com [66.94.237.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3F99F21F958B for ; Mon, 15 Apr 2013 11:04:56 -0700 (PDT) Received: from [66.94.237.126] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:04:55 -0000 Received: from [66.94.237.116] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:04:55 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:04:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556492.10176.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 65732 invoked by uid 60001); 15 Apr 2013 18:04:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1366049095; bh=FNNUVRpFlhMtqYuzuInKao5+R6eXcNEkD9YtTg+/dN0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZPU5QjSiQsYKWBi2YYXXJZrdRctplzFAatLzaKuhdhCmcYcg2PLJptcIreu3VfM4lNN12KNyHrPQZ+yTAaLYVPXg48KyCrrWaRMBwJTh4ADJjqMre8JeIpL4uypRQS8bR7vH/rvHFD/Umprpyr4PqAul2w8rn7blvsDITjHc/8g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KcCgFDHB2YYp7mV9kuEDO+lVQRsLx1a9x++dPNt+bVz3sgF4xOYOA+5ik87482nzHwIV7pmfqdnlk0q1ubLD7/6XzvfCCSdv+M3fHjF/mdDZiTU33u7e4z79UAMlLzR+KMfmLAzMq4SFmowwZdZnHggS3znBaDLCoevdeGiFVn0=; X-YMail-OSG: hEhOogAVM1kwqfS3fapSqI7pOrGCEzTE2ZQKgNpvgn3Ig9B sahdBaG8cihD.o_2NRXVf3QgmYwgLeMBCeTTRuy5V0zLhr_nPq5OM8TPI3rk P8OUIcehZE7ybx5TBX1pJLj3sPIN5ySUJSaYZRRR_2kjTqOe0zTseYDbFZ6H moknBSwPnHCJxAWyzIsSJkjk2pIZ_qOdxyaRA7Rpkk2fTQfUpa.MhfRMKaDx 7rrgcP_ekFW_4IHSydv7h80utRiO.RIsOpaue5EjZWcHfVL90ZDlxdJRUd36 ljQrsP.I2AYpCqm77vzhEy9oPHfVfzglaXL6y6WjhdDz28pTOSmeI9Z..F7n qXYeivYg3e5H.PIxbMQu.mvFM165Rj5urFdeYlJz5MDmxhcV5Kfs5cXNck5d 26GXhiNV7CZ1EHVJhinVAE7DUPwkH7sOb6yyvmmeDEZMTsT9P30yvHwlleVv Ol0inn3PCK28xuIXb63Q9i5zcxKu17g5n6p5dK97GrIs.Uq_3.foTLc6teUd PkwqaI1kbsl12 Received: from [70.36.254.42] by web184402.mail.bf1.yahoo.com via HTTP; Mon, 15 Apr 2013 11:04:54 PDT X-Rocket-MIMEInfo: 002.001, MQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPgpUbzogam9zZUBpZXRmLm9yZwpTZW50OiBUaHUsIEFwcmlsIDExLCAyMDEzIDQ6NTg6NTYgUE0KU3ViamVjdDogW2pvc2VdIEZlZWRiYWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlzc3VlIzExOiBTaG91bGQgd2UgdXNlIFJGQyAKNTExNiBhbmQgcmVtb3ZlIHRoZSBKV0UgSW50ZWdyaXR5IFZhbHVlIGZpZWxkPwoKSXNzdWUgIzExIGh0dHA6Ly90cmFjLnRvb2wBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/728 YahooMailWebService/0.8.140.532 References: <51674E3D.7030004@isoc.org> Message-ID: <1366049094.57379.YahooMailRC@web184402.mail.bf1.yahoo.com> Date: Mon, 15 Apr 2013 11:04:54 -0700 (PDT) From: Edmund Jay To: odonoghue@isoc.org, jose@ietf.org In-Reply-To: <51674E3D.7030004@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-334495122-499660441-1366049094=:57379" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:04:57 -0000 ---334495122-499660441-1366049094=:57379 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1=0A=0A=0A=0A=0A________________________________=0AFrom: Karen O'Donoghue <= odonoghue@isoc.org>=0ATo: jose@ietf.org=0ASent: Thu, April 11, 2013 4:58:56= PM=0ASubject: [jose] Feedback request on jose tracker issue#11: Should we = use RFC =0A5116 and remove the JWE Integrity Value field?=0A=0AIssue #11 ht= tp://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes =0Arestructuri= ng the JWE representation to remove the JWE Integrity Value field =0Aan= d instead use the RFC 5116 (AEAD) binary serialization to represent the= =0ACiphertext, Initialization Vector, and Integrity Value values. If = this =0Aproposal is adopted, JWEs would then have three fields =E2=80= =93 the header, the =0Aencrypted key, and the RFC 5116 combination of t= he Ciphertext, =0AInitialization Vector, and Integrity Value values. = =0A=0AThis issue is also related to issue #3. Note that the updated = McGrew =0Adraft described there could be used whether or not we switc= hed to using =0ARFC 5116.=0A =0AWhich of these best describes your= preferences on this issue?=0A1. Continue having separate Cipherte= xt, Initialization Vector, and =0AIntegrity Value values in the JWE r= epresentation.=0A2. Switch to using the RFC 5116 (AEAD) serializatio= n to represent the =0Acombination of these three values.=0A3. Another = resolution (please specify in detail).=0A0. I need more inform= ation to decide.=0A Your reply is requested by Friday, April 19th or = earlier. ---334495122-499660441-1366049094=:57379 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
1

From: Karen O'Donoghue &= lt;odonoghue@isoc.org>
To: jose@ietf.org
Sent:<= /b> Thu, April 11, 2013 4:58:56 PM
Subject: [jose] Feedback request on jose tracker issue#11: Shou= ld we use RFC 5116 and remove the JWE Integrity Value field?

= =0A =0A=0A =0A =0A =0A Issue #11 =0A ht= tp://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes=0A restruct= uring the JWE representation to remove the JWE Integrity=0A Value field = and instead use the RFC 5116 (AEAD) binary serialization=0A to represent= the Ciphertext, Initialization Vector, and Integrity=0A Value values.&n= bsp; If this proposal is adopted, JWEs would then have=0A three fields = =E2=80=93 the header, the encrypted key, and the RFC 5116=0A combination= of the Ciphertext, Initialization Vector, and Integrity=0A Value values= .   =0A

This issue is also related to issue = #3.  Note=0A that the updated McGrew draft described there could = be used=0A whether or not we switched to using RFC 5116.
=0A   =0A

=0A

Which of these best=0A desc= ribes your preferences on this issue?

=0A

1.  Continue having=0A separat= e Ciphertext,=0A Initialization Vector, and Integrity Value val= ues in the=0A JWE representation.

=0A

2.=   Switch to using the RFC 5116 (AEAD)=0A serialization to represe= nt the combination of these three values.

=0A

3.  Another=0A resolution (please= specify in detail).

=0A

0.  I need more=0A information to decide.

=0A

 <= /span>

=0A Your reply is requested by F= riday, April=0A 19th or earlier.
=0A =0A =0A= =0A
=0A=0A=0A=0A
---334495122-499660441-1366049094=:57379-- From edmundjay@sbcglobal.net Mon Apr 15 11:05:25 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1128121F95CE for ; Mon, 15 Apr 2013 11:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrjXcdXSwa5n for ; Mon, 15 Apr 2013 11:05:24 -0700 (PDT) Received: from nm2-vm0.access.bullet.mail.mud.yahoo.com (nm2-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.66]) by ietfa.amsl.com (Postfix) with ESMTP id 389FF21F8FC0 for ; Mon, 15 Apr 2013 11:05:24 -0700 (PDT) Received: from [66.94.237.194] by nm2.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:05:23 -0000 Received: from [66.94.237.111] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:05:23 -0000 Received: from [127.0.0.1] by omp1016.access.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:05:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 895999.32393.bm@omp1016.access.mail.mud.yahoo.com Received: (qmail 28854 invoked by uid 60001); 15 Apr 2013 18:05:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1366049123; bh=HCr783WPiM6PsbvCszokeU+09FDuxL6ELa1rwv7Bh2I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=phvV/sTOS40P5zB5tD59RrQBPp9DAdJW3ukOcx9ul+V8Bweh0pHsg7sMe2LnLxLnRn6/0yvUs4p6ih2ifRzhalaDILm1XaYgkuOmDlUz704J7JsFh0Z6x0cIVuTcukOPQQX3hmfkvfkKeuN/uHZN5EVYRNKaduZSpQYYicHsSJ0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NJCuXW/set5NaeK1evIsNVdihiFv2ozoWtOZ5FxIUDeoJ8SbWJCwCGdDMIrLFsrC/oX6rlZI+MMqZ+Fm/RxAsUFlundZ+8JViHVeaC3kanlgm2jvra7L4sNqXl6dn51ZhdNnDzSS6KYMovp4ePI2WMXnnfGQctsNSpf2ZiOpAes=; X-YMail-OSG: VXNC9fgVM1mKRyqyOe1ghxchsxZPaGjss307l9Vn.eOi_e5 YAFmFgtBL0eQP20fLkNF4JUpjfIOv10kFlZG1lB1b_UU2HUwjbG5ys_r8gwW OztcJhRPI6p5vhiLoRD3yFLCxdMX_EJfzj1Y_jkVaThjsF9JG57qdpM5Ov42 6McVY6Yc_KFbWXbOxdJ1Lhmkh2MsBdpNZwvPTV6r93tXkjjSDuORwjh0tupL GIf5it3n3IK1So.l.O.tAl4UigVz4uZX9BWmJ24mTolNYbPy0EyKo0v62oFl eWpsgLvrQMznLyPe7APL.kwQ3I9H6fi3aCgoTfJvQRH96uyT21tF6KMyP6BH ..LHmoLVWhyht3KC.sD0nI6dO6HMXHjDl8uZhP_v2KLBjaeTSXDAhUV3umsa TE3LF81TSV6YCmqOgeD56137UiHopCJNmCgReo8X8DsXB0XeoO__lpzBv9BK FiazFY92PTiYz2aEObdlsbqdkBzhISj0D0l4EitDtMsLlFZ3ivB5pQu.M_q7 GBQbyvWs2AX75 Received: from [70.36.254.42] by web184405.mail.bf1.yahoo.com via HTTP; Mon, 15 Apr 2013 11:05:23 PDT X-Rocket-MIMEInfo: 002.001, MQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPgpUbzogam9zZUBpZXRmLm9yZwpTZW50OiBUaHUsIEFwcmlsIDExLCAyMDEzIDQ6NTk6MzIgUE0KU3ViamVjdDogW2pvc2VdIEZlZWRiYWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlzc3VlICMxMjogU2hvdWxkIHRoZSB4NWMgZmllbGQgCmJlIHJlbW92ZWQgZnJvbSBKV0U_LCAsIAoKCklzc3VlICMxMiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3MBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/728 YahooMailWebService/0.8.140.532 References: <51674E58.6000505@isoc.org> Message-ID: <1366049123.15044.YahooMailRC@web184405.mail.bf1.yahoo.com> Date: Mon, 15 Apr 2013 11:05:23 -0700 (PDT) From: Edmund Jay To: odonoghue@isoc.org, jose@ietf.org In-Reply-To: <51674E58.6000505@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1412092350-1322002271-1366049123=:15044" Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:05:25 -0000 ---1412092350-1322002271-1366049123=:15044 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1=0A=0A=0A=0A=0A________________________________=0AFrom: Karen O'Donoghue <= odonoghue@isoc.org>=0ATo: jose@ietf.org=0ASent: Thu, April 11, 2013 4:59:32= PM=0ASubject: [jose] Feedback request on jose tracker issue #12: Should th= e x5c field =0Abe removed from JWE?, , =0A=0A=0AIssue #12 http://trac.tools= .ietf.org/wg/jose/trac/ticket/12 suggests =0Aremoving the =E2=80=9Cx5c= =E2=80=9D header parameter from JWE, saying that no use case for it =0A= has emerged. The same logic may apply to other key specification param= eters =0Afor JWE. =0A=0A=0AWhich of these best describes your prefe= rences on this issue?=0A1. Retain the =E2=80=9Cx5c=E2=80=9D header p= arameter in JWE.=0A2. Remove the =E2=80=9Cx5c=E2=80=9D header parame= ter (and possibly other related key =0Aspecification parameters) from= JWE.=0A3. Another resolution (please specify in detail).=0A0. I = need more information to decide.=0A Your reply is requested by Frid= ay, April 19th or earlier. ---1412092350-1322002271-1366049123=:15044 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
1

From: Karen O'Donoghue &= lt;odonoghue@isoc.org>
To: jose@ietf.org
Sent:<= /b> Thu, April 11, 2013 4:59:32 PM
Subject: [jose] Feedback request on jose tracker issue #12: Sho= uld the x5c field be removed from JWE?, ,

=0A =0A=0A =0A= =0A =0A Issue #12 =0A http://trac.tools.ie= tf.org/wg/jose/trac/ticket/12 suggests=0A removing the =E2=80=9Cx5c= =E2=80=9D header parameter from JWE, saying that no use=0A case for it h= as emerged.  The same logic may apply to other key=0A specification= parameters for JWE. =0A


=0A

=0A

Which of these best=0A describes your preferences = on this issue?

=0A

1.  Retain the =E2=80=9Cx5c=E2=80=9D=0A header p= arameter in JWE.

=0A

2.  Remove the =E2=80=9Cx5c=E2=80=9D=0A header parame= ter (and possibly other related key specification=0A parameters) from = JWE.

=0A

3. = ; Another=0A resolution (please specify in detail).

=0A =

0.  I need more= =0A information to decide.

=0A

=  

=0A Your reply is requested by Friday, April=0A 19th o= r earlier.
=0A =0A =0A=0A
=0A=0A=0A=0A
---1412092350-1322002271-1366049123=:15044-- From edmundjay@sbcglobal.net Mon Apr 15 11:06:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CE021F9577 for ; Mon, 15 Apr 2013 11:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+fn726ejHTe for ; Mon, 15 Apr 2013 11:06:10 -0700 (PDT) Received: from nm23-vm0.access.bullet.mail.mud.yahoo.com (nm23-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8AB21F8FC0 for ; Mon, 15 Apr 2013 11:06:10 -0700 (PDT) Received: from [66.94.237.197] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:06:10 -0000 Received: from [66.94.237.112] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:06:10 -0000 Received: from [127.0.0.1] by omp1017.access.mail.mud.yahoo.com with NNFMP; 15 Apr 2013 18:06:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 38025.28740.bm@omp1017.access.mail.mud.yahoo.com Received: (qmail 44104 invoked by uid 60001); 15 Apr 2013 18:06:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1366049169; bh=XwMx77UqLPChNYOytgS7YhVmtRFS9ZNRHZeWjaFUkTA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=V/loOmNYIFNTn1peqHgC4TdOr+Ydde9VkKV8Ri10X4+303dAlOsS2TXVAUOhoGAJer/Oxd5v0+b5IH+HWvwGtIs3YqhYy6lXcV+SkVIzH9iYzIvBYa1DySFkVXxIB3nRF4k9L6nn6h0dku9+V61pO2BmoQ+ccDydtjG5CtbBBts= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2/ZOansBve1oAZUI3x9bFFeFObmijnwWlih6MLQ+kOg3G6buxOZ4n6plpaHevd7MU0LYPYCz+b9z8OfoAF/Vx11E82A0AySN/TF4kBiJJ18sr9D9OjRqiMm8KrqkIEOBbdwlCU17RkLYHpWCoIvK2BuvatnTJpnhEz1Pw/g1L1Y=; X-YMail-OSG: FwvCn0MVM1lYTzSt3XCGe5f0XV8Zv4p1Q_E9qv0Su6r0knL 0TwxNRW6sry9V_ad_eBicSvdk.h0FkQrVi8aVCH3CajUhpVKE0kRYwWMm6a5 Fgm3DCDBwOH2MMW1BrCMuNnLh5JQZRWknyecRqNIrS2mFa7mjG98mt70C.Uy Vgg4gKTzjTItKUl_YC_SSRG.XZ5Dum_1Or.diIXXJ4161Koq45nbp8oReXjP u5C.f8skiTqIYg3atQks_7CKvGRqg1jeNKHoXrNMLXnDY8ICFNhq5fzTggpk P28zgb1pbR14a6jzOhDYF94e5PU7TxYTi2ZUox7cqwOU0x_EuyTdfTmH1v8X Um..ID1p2x39PgvbMRYxegME7g85ufXrotge_kDvoU2la_maWTHpdFUT.kRh cjR2.ZIxL2yMz75ahlwRoNNkUQOOMLOHPXOFcBKBVZlsdGXt0ogSvzDnpVKV 6Q5A1hxbqGzN4m66fM08._o7Ckkmj9Q6XuQGISMQhxoV.efRiVLF0XqqW5Ab DvrhcXhVqwHHu Received: from [70.36.254.42] by web184401.mail.bf1.yahoo.com via HTTP; Mon, 15 Apr 2013 11:06:09 PDT X-Rocket-MIMEInfo: 002.001, MQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPgpUbzogam9zZUBpZXRmLm9yZwpTZW50OiBUaHUsIEFwcmlsIDExLCAyMDEzIDQ6NTk6MzUgUE0KU3ViamVjdDogW2pvc2VdIEZlZWRiYWNrIHJlcXVlc3Qgb24gam9zZSB0cmFja2VyIGlzc3VlICMxNTogU2hvdWxkIGF0IGxlYXN0IG9uIAprZXkgaW5kaWNhdG9yIGJlIG1hbmRhdG9yeQoKSXNzdWUgIzE1IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UBMAEBAQE- X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/728 YahooMailWebService/0.8.140.532 References: <51674E63.3050809@isoc.org> Message-ID: <1366049169.19442.YahooMailRC@web184401.mail.bf1.yahoo.com> Date: Mon, 15 Apr 2013 11:06:09 -0700 (PDT) From: Edmund Jay To: odonoghue@isoc.org, jose@ietf.org In-Reply-To: <51674E63.3050809@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1009959307-372641467-1366049169=:19442" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:06:11 -0000 --1009959307-372641467-1366049169=:19442 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1=0A=0A=0A=0A=0A________________________________=0AFrom: Karen O'Donoghue <= odonoghue@isoc.org>=0ATo: jose@ietf.org=0ASent: Thu, April 11, 2013 4:59:35= PM=0ASubject: [jose] Feedback request on jose tracker issue #15: Should at= least on =0Akey indicator be mandatory=0A=0AIssue #15 http://trac.tools.ie= tf.org/wg/jose/trac/ticket/15. suggests =0Arequiring that a key indicat= or, such as a =E2=80=9Ckid=E2=80=9D field, be required in all =0AJWS an= d JWE headers.Are use cases where key information is exchanged by means =0A= other than the JWS or JWE headers important? =0A=0AWhich of these b= est describes your preferences on this issue?=0A1. Yes.=0A2. No.= =0A0. I need more information to decide.=0A Your reply is request= ed by Friday, April 19th (or earlier). --1009959307-372641467-1366049169=:19442 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
1

From: Karen O'Donoghue &= lt;odonoghue@isoc.org>
To: jose@ietf.org
Sent:<= /b> Thu, April 11, 2013 4:59:35 PM
Subject: [jose] Feedback request on jose tracker issue #15: Sho= uld at least on key indicator be mandatory

=0A =0A=0A =0A= =0A =0A Issue #15 =0A http://trac.tools.ie= tf.org/wg/jose/trac/ticket/15. suggests=0A requiring that a key indi= cator, such as a =E2=80=9Ckid=E2=80=9D field, be required=0A in all JWS = and JWE headers. =0A Are use cases wher= e key information is exchanged by means other=0A than the JWS or JWE= headers important? =0A

Which of these best=0A describes your preferences on this= issue?

=0A

1.  Yes.

=0A

2.   No.

=0A

0.  I need more=0A information to de= cide.

=0A

 

=0A Your reply is reque= sted by Friday, April=0A 19th (or earlier).
=0A =0A =0A=0A
=0A=0A=0A=0A
--1009959307-372641467-1366049169=:19442-- From rlb@ipv.sx Mon Apr 15 11:20:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2A21F9675 for ; Mon, 15 Apr 2013 11:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NquzmgK1G-vf for ; Mon, 15 Apr 2013 11:20:27 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3013321F9670 for ; Mon, 15 Apr 2013 11:20:27 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wd20so1434243obb.21 for ; Mon, 15 Apr 2013 11:20:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZbF/6mwrZbXT/Pyt9wOO6ia71feShmrGHz3Q6q5cmQc=; b=Rr76Fmyv/Ov/Ii9HNAJ/Cczb4iek2XOYQaRV/JgYfY01x5AwOeXxLfYOT4rY83+91V zNPb4TU/E1pyaVT7RasvWNOd36j0wN3yn5HasTVW+pIt5n4YWezTCVg7gpKpw+tc1X6/ mEqo5VoO4C+sRCBRx4fd5bdBVNmHiBNXL2MHRhARLdbsNTPG4271vryhC17Mv0hG3q1j gkdrtMWiKOm9VTbkstzBoAMElt6+Bl2E2OIIcX2JAe0GPeXEYr2H3ZdYd1YmD7hD5pki O1ey61cINwNS2asY2sh8PRbrfEwoOp8x/WVLJqmQc0SXBfqaJnh8EF414nqKd/BoPF4p 67Xg== MIME-Version: 1.0 X-Received: by 10.60.15.98 with SMTP id w2mr8092961oec.128.1366050026605; Mon, 15 Apr 2013 11:20:26 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 11:20:26 -0700 (PDT) X-Originating-IP: [128.89.255.241] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676421F3@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E63.3050809@isoc.org> <4E1F6AAD24975D4BA5B168042967394367615F37@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367641542@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676421F3@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 14:20:26 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e013a0a1e94dd1504da6a4e01 X-Gm-Message-State: ALoCoQlwNdMMvj5WKOoILBPcDA9o1FTIcTJuZ2SHRlqrQZ2CSx+qPwovPjyNzWM4hX/C9xqqfp0/ Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:20:30 -0000 --089e013a0a1e94dd1504da6a4e01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Let me reiterate! I don't think pre-negotiated use cases are precluded, I just think that by default, the protocol should not rely on pre-negotiated parameters, including what key to use. --Richard On Mon, Apr 15, 2013 at 1:47 PM, Mike Jones wr= ote: > I=92ll plan on reviewing the Use Cases document after finishing the > current spec updates to the other specs. If you believe that the use Cas= es > Document as written precludes use cases where keys are exchanged by > mechanisms other than the JOSE headers, that=92s an indication that some = use > cases are missing from the document.**** > > ** ** > > Best wishes,*= * > ** > > -- Mike**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Monday, April 15, 2013 10:31 AM > > *To:* Mike Jones > *Cc:* odonoghue@isoc.org; jose@ietf.org > *Subject:* Re: [jose] Feedback request on jose tracker issue #15: Should > at least on key indicator be mandatory**** > > ** ** > > You're making the same false argument I just addressed. Covering use > cases involving pre-negotiation does not imply that headers can't be > mandatory. It implies that they can't be mandatory in all cases -- that > is, that there needs to be a "pre-negotiated mode" in which headers are n= ot > mandatory in addition to the "stand-alone mode" where everything needs to > be expressed in the headers (no pre-negotiation).**** > > ** ** > > I am completely fine with supporting both modes, but in order to do that, > it needs to be clear to a recipient which mode is in use. So we need to:= * > *** > > (1) Choose a default mode,**** > > (2) Have a switch that indicates when the non-default mode is being used, > and**** > > (3) Define generation and processing rules for both modes.**** > > ** ** > > What I'm saying here is that:**** > > (1) The default mode should be "stand-alone"**** > > (2) The switch is SPI**** > > (3) The processing rules for the stand-alone mode should REQUIRE at least > one key indicator**** > > ** ** > > What you're arguing is that there should not be a well-defined stand-alon= e > mode, effectively that the recipient always does some pre-negotiation in > order to know what fields it needs. So you're arguing that the following > basic requirements from the use cases document aren't actually requiremen= ts: > **** > > """**** > > o The JOSE encrypted object format must support object encryption in*= *** > > the case where the sender and receiver share a symmetric key.**** > > ** ** > > o The JOSE encrypted object format must support object encryption in*= *** > > the case where the sender has only a public key for the receiver.**= ** > > ** ** > > o The JOSE signed object format must integrity protection using**** > > Message Authentication Codes (MACs), for the case where the sender*= *** > > and receiver share only a symmetric key.**** > > ** ** > > o The JOSE signed object format must integrity protection using**** > > digital signatures, for the case where the receiver has only a**** > > public key for the sender.**** > > """**** > > The implication of all those "only"s is that everything else has to be > defined by the protocol specification, including which fields are mandato= ry. > **** > > ** ** > > --Richard**** > > ** ** > > ** ** > > ** ** > > On Mon, Apr 15, 2013 at 11:45 AM, Mike Jones > wrote:**** > > You could say =93nice straw man, Jim=94, as it was Jim Schaad who propose= d > that the right question to ask was whether such use cases are important o= r > not. I agree with Jim that clearly if they are important/in scope, then > key indicators in the headers can=92t be mandatory.**** > > **** > > -- Mike**** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Monday, April 15, 2013 8:41 AM > *To:* Mike Jones > *Cc:* odonoghue@isoc.org; jose@ietf.org > *Subject:* Re: [jose] Feedback request on jose tracker issue #15: Should > at least on key indicator be mandatory**** > > **** > > Nice straw man, Mike :) **** > > **** > > Nobody is arguing that cases with out-of-band negotiation are not > important. The question is how they should be supported.**** > > **** > > What ISSUE-9 and ISSUE-15 are about is saying that the default assumption > should be that all communication is via JW* headers. Otherwise, we're no= t > designing a stand-alone protocol, we're designing an adjunct to something > else, and we should do it in that WG. That default assumption means that > you have to have certain contraints, like a key indicator being REQUIRED. > The SPI header is then the "get out of jail free card", releasing you fr= om > those constraints.**** > > **** > > Let's design a real protocol first, then let people cheat.**** > > **** > > --Richard**** > > **** > > **** > > On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones > wrote:**** > > Reading this question, I believe that there=92s a possibility for the > question to be misinterpreted, since the sense of the question in the > subject is opposite of the sense of the question in the body. I believe > that the intent of 1 and 2 were as follows:**** > > **** > > 1. Yes =96 Use cases where key information is exchanged by means other t= han > the JWS and JWE headers ARE important.**** > > 2. No =96 Use cases where key information is exchanged by means other th= an > the JWS and JWE headers ARE NOT important.**** > > **** > > Maybe people could reply with 1 and 2 as above, so that their answers to > the question of whether these use cases are important are not are > unambiguous.**** > > **** > > -- Mike**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Karen O'Donoghue > *Sent:* Thursday, April 11, 2013 5:00 PM**** > > > *To:* jose@ietf.org > *Subject:* [jose] Feedback request on jose tracker issue #15: Should at > least on key indicator be mandatory**** > > **** > > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests > requiring that a key indicator, such as a =93kid=94 field, be required in= all > JWS and JWE headers. Are use cases where key information is exchanged by > means other than the JWS or JWE headers important? ** ** > > Which of these best describes your preferences on this issue?**** > > 1. Yes.**** > > 2. No. **** > > 0. I need more information to decide.**** > > **** > > Your reply is requested by Friday, April 19th (or earlier). **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** > --089e013a0a1e94dd1504da6a4e01 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Let me reiterate! =A0I don't think pre-negotiated use cases are preclud= ed, I just think that by default, the protocol should not rely on pre-negot= iated parameters, including what key to use. =A0

--Richa= rd


On Mon, Apr 15, 2013 at 1:47 PM, Mi= ke Jones <Michael.Jones@microsoft.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I=92ll plan on reviewing = the Use Cases document after finishing the current spec updates to the othe= r specs.=A0 If you believe that the use Cases Document as written precludes use cases where keys are exchanged by mechanisms other than the = JOSE headers, that=92s an indication that some use cases are missing from t= he document.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Best wishes,

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

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, April 15, 2013 10:31 AM


To: Mike Jones
Cc: odonoghu= e@isoc.org; jose@iet= f.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Shou= ld at least on key indicator be mandatory

<= div>

=A0

You're making the same false argument I just add= ressed. =A0Covering use cases involving pre-negotiation does not imply that= headers can't be mandatory. =A0It implies that they can't be manda= tory in all cases -- that is, that there needs to be a "pre-negotiated mode" in which headers are not mandatory in= addition to the "stand-alone mode" where everything needs to be = expressed in the headers (no pre-negotiation).

=A0

I am completely fine with supporting both modes, but= in order to do that, it needs to be clear to a recipient which mode is in = use. =A0So we need to:

(1) Choose a default mode,

(2) Have a switch that indicates when the non-defaul= t mode is being used, and

(3) Define generation and processing rules for both = modes.

=A0

What I'm saying here is that:

(1) The default mode should be "stand-alone&quo= t;

(2) The switch is SPI

(3) The processing rules for the stand-alone mode sh= ould REQUIRE at least one key indicator

=A0

What you're arguing is that there should not be = a well-defined stand-alone mode, effectively that the recipient always does= some pre-negotiation in order to know what fields it needs. =A0So you'= re arguing that the following basic requirements from the use cases document aren't actually requirements:

"""

=A0=A0 o=A0 The JOSE encrypted object=
 format must support object encryption in
=A0=A0=A0=A0=A0 the case where the se=
nder and receiver share a symmetric key.
=A0
=A0=A0 o=A0 The JOSE encrypted object=
 format must support object encryption in
=A0=A0=A0=A0=A0 the case where the se=
nder has only a public key for the receiver.
=A0
=A0=A0 o=A0 The JOSE signed object fo=
rmat must integrity protection using
=A0=A0=A0=A0=A0 Message Authenticatio=
n Codes (MACs), for the case where the sender
=A0=A0=A0=A0=A0 and receiver share on=
ly a symmetric key.
=A0
=A0=A0 o=A0 The JOSE signed object fo=
rmat must integrity protection using
=A0=A0=A0=A0=A0 digital signatures, f=
or the case where the receiver has only a
=A0=A0=A0=A0=A0 public key for the se=
nder.

"""

The implication of all those "only"s is th= at everything else has to be defined by the protocol specification, includi= ng which fields are mandatory.

=A0

--Richard

=A0

=A0

=A0

On Mon, Apr 15, 2013 at 11:45 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

You could say =93nice str= aw man, Jim=94, as it was Jim Schaad who proposed that the right question t= o ask was whether such use cases are important or not.=A0 I agree with Jim t= hat clearly if they are important/in scope, then key indicators in the head= ers can=92t be mandatory.

=A0<= /p>

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

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, April 15, 2013 8:41 AM
To: Mike Jones
Cc: odonoghu= e@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Shou= ld at least on key indicator be mandatory

=A0

Nice straw man, Mike =A0:) =A0

=A0

Nobody is arguing that cases with out-of-band negoti= ation are not important. =A0The question is how they should be supported.

=A0

What ISSUE-9 and ISSUE-15 are about is saying that t= he default assumption should be that all communication is via JW* headers. = =A0Otherwise, we're not designing a stand-alone protocol, we're designing an adjunct to something else, and we should do it in t= hat WG. =A0That default assumption means that you have to have certain cont= raints, like a key indicator being REQUIRED. =A0The SPI header is then the = "get out of jail free card", releasing you from those constraints.

=A0

Let's design a real protocol first, then let peo= ple cheat.

=A0

--Richard

=A0

=A0

On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Reading this question, I = believe that there=92s a possibility for the question to be misinterpreted, since the sense of the question in the subject is opposite of the sense of= the question in the body.=A0 I believe that the intent of 1 and 2 were as = follows:

=A0<= /p>

1.=A0 Yes =96 Use cases w= here key information is exchanged by means other than the JWS and JWE heade= rs ARE important.

2.=A0 No =96 Use cases wh= ere key information is exchanged by means other than the JWS and JWE header= s ARE NOT important.

=A0<= /p>

Maybe people could reply = with 1 and 2 as above, so that their answers to the question of whether these use cases are important are not are unambiguous.

=A0<= /p>

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

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM


To: jose@ietf.org=
Subject: [jose] Feedback request on jose tracker issue #15: Should a= t least on key indicator be mandatory

=A0

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requir= ing that a key indicator, such as a =93kid=94 field, be required in all JWS= and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers import= ant?

Which of these best describes your preferences on th= is issue?

1.=A0 Yes.

2.=A0=A0 No.

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th (or earlier).


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0


--089e013a0a1e94dd1504da6a4e01-- From rlb@ipv.sx Mon Apr 15 11:22:28 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04921F9677 for ; Mon, 15 Apr 2013 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDzCGPpo3w3i for ; Mon, 15 Apr 2013 11:22:27 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0180321F9676 for ; Mon, 15 Apr 2013 11:22:26 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id va7so4467669obc.34 for ; Mon, 15 Apr 2013 11:22:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=X1ywbollcjEmNTNtR6R6vSrfI4CG8JRAEqgzixP2/p4=; b=TGHFSS0CvvzUmXzbO2UQTsitUNRGsaX0b2nxhVhhJlAPzbThMzb4Fs2p+W4mcV1XSX Ruh+u1RgqeU6XJW6IhFHR2aHj06jY8DxHF0otK6pwhVp+b0/mu1UgpPTRP5RDqdp8+dl +Q/9U3xi+F2Nuj4/k875MpNnBgAuxdnu1Oi2ukknkmuD9mQfPctQTyszr7woL4T0+6gb 3oy5pGEPlh7OVf6tDj2iX/ZgO3/OvgS7FyuvJSuKNYl3QrUgmF+NbO3dxCTusMsUW7DH YAVCxFBHy3ArmIldO1fRjAUR3znVHozEld0N/xEQif2x/VxtRgADWDPerWyVCrtFLHui LvtQ== MIME-Version: 1.0 X-Received: by 10.60.17.132 with SMTP id o4mr2895640oed.12.1366050146404; Mon, 15 Apr 2013 11:22:26 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Mon, 15 Apr 2013 11:22:26 -0700 (PDT) X-Originating-IP: [128.89.255.241] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436764218A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <51674E2D.3040604@isoc.org> <4E1F6AAD24975D4BA5B16804296739436764218A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 15 Apr 2013 14:22:26 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e01294d0cb8d9ea04da6a55cb X-Gm-Message-State: ALoCoQnN10JZB9GItMe6LFY0bkcV6cb3d+Id0hxmcXZexbVLngsTDSvpVkpYy2NksAPqUXQ5bdqc Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:22:28 -0000 --089e01294d0cb8d9ea04da6a55cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The "switch" does have to be a JOSE protocol element, because the JOSE protocol logic has to be self-contained. --Richard On Mon, Apr 15, 2013 at 1:44 PM, Mike Jones wr= ote: > Use of =93spi=94 is one such possible =93switch=94. Use of the OAuth Dy= namic > Client Registration specification to obtain keys or key references is > another. Other applications may choose exchange the keys other ways.**** > > ** ** > > The =93switch=94 doesn=92t have to be a JOSE protocol element. Although = you > could consider the lack of a key indicator in the JOSE header to be a cle= ar > indication in the JOSE protocol elements that the switch has been thrown, > meaning that it=92s up to the application to use its logical to determine > which key(s) to use =96 which is a normal use case.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, April 15, 2013 10:37 AM > > *To:* odonoghue@isoc.org > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Feedback request on jose tracker issue #8: Should > we add a "spi" header field?**** > > ** ** > > 2 or 3**** > > ** ** > > All of the "1" responses are missing the point of SPI -- if you want to b= e > able to omit fields (as people seem to want to do), then you need a switc= h > to turn off "stand-alone mode". **** > > ** ** > > So responding "1" here is the same as responding "1" on the ISSUE-15 poll= , > that at least one key indicator MUST be present. **** > > ** ** > > ** ** > > On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue > wrote:**** > > Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding > an =93spi=94 (security parameters index) header parameter to the JWS and = JWE > specifications. This modification to the JOSE formats would allow for > signaling that pre-negotiated cryptographic parameters are being used, > rather than including those parameters in the JWS or JWE header. This > proposal has been written up as > http://tools.ietf.org/html/draft-barnes-jose-spi-00. **** > > **** > > Which of these best describes your preferences on this issue?**** > > 1. Have draft-barnes-jose-spi remain a separate specification that could > optionally also be supported by JWS and JWE implementations.**** > > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as a mandatory feature.**** > > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as an optional feature.**** > > 4. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > Your reply is requested by Friday, April 19th or earlier. **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --089e01294d0cb8d9ea04da6a55cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The "switch" does have to be a JOSE protocol element, because the= JOSE protocol logic has to be self-contained. =A0
--Richard
=


On Mon, Apr 15, 2013 at 1= :44 PM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

Use of =93spi=94 is one s= uch possible =93switch=94.=A0 Use of the OAuth Dynamic Client Registration = specification to obtain keys or key references is another.=A0 Other applications may choose exchange the keys other ways.=

=A0<= /p>

The =93switch=94 doesn=92= t have to be a JOSE protocol element.=A0 Although you could consider the la= ck of a key indicator in the JOSE header to be a clear indication in the JOSE protocol elements that the switch has been thrown, meaning tha= t it=92s up to the application to use its logical to determine which key(s)= to use =96 which is a normal use case.

=A0<= /p>

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

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, April 15, 2013 10:37 AM

To: odonoghu= e@isoc.org
Cc: jose@ietf.org=
Subject: Re: [jose] Feedback request on jose tracker issue #8: Shoul= d we add a "spi" header field?

=A0

2 or 3

=A0

All of the "1" responses are missing the p= oint of SPI -- if you want to be able to omit fields (as people seem to wan= t to do), then you need a switch to turn off "stand-alone mode". = =A0

=A0

So responding "1" here is the same as resp= onding "1" on the ISSUE-15 poll, that at least one key indicator = MUST be present. =A0

=A0

=A0

On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghu= e <odonoghue@iso= c.org> wrote:

Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an =93= spi=94 (security parameters index) header parameter to the JWS and JWE spec= ifications.=A0 This modification to the JOSE formats would allow for signal= ing that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the J= WS or JWE header.=A0 This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.

=A0

Which of these best describes your preferences on th= is issue?

1.=A0 Have draft-barnes-jose-spi remain a separate s= pecification that could optionally also be supported by JWS and JWE impleme= ntations.

2.=A0 Incorporate draft-barnes-jose-spi into the JWS= and JWE specifications as a mandatory feature.

3.=A0 Incorporate draft-barnes-jose-spi into the JWS= and JWE specifications as an optional feature.

4.=A0 Another resolution (please specify in detail).=

0.=A0 I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--089e01294d0cb8d9ea04da6a55cb-- From stpeter@stpeter.im Mon Apr 15 11:39:15 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AEF21F96C6 for ; Mon, 15 Apr 2013 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XQA76RUsMAY for ; Mon, 15 Apr 2013 11:39:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 91D0921F968E for ; Mon, 15 Apr 2013 11:39:14 -0700 (PDT) Received: from squire.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0A27440FA1; Mon, 15 Apr 2013 12:49:37 -0600 (MDT) Message-ID: <516C4947.7070303@stpeter.im> Date: Mon, 15 Apr 2013 12:39:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Richard Barnes References: <4E1F6AAD24975D4BA5B16804296739436761CA72@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mike Jones , Karen O'Donoghue , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Proposed Agenda for Interim Working Group Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:39:15 -0000 On 4/15/13 11:57 AM, Richard Barnes wrote: > So maybe we could divide the agenda roughly in 4, and have one large > discussion on each of the above topics, with the goal of getting > consensus on some answers to the above questions. +1 to using the in-person meeting for generating agreement on thorny issues... Peter From ve7jtb@ve7jtb.com Mon Apr 15 11:42:24 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8D21F96D7 for ; Mon, 15 Apr 2013 11:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTInuWYN8Ovq for ; Mon, 15 Apr 2013 11:42:24 -0700 (PDT) Received: from mail-gg0-x232.google.com (mail-gg0-x232.google.com [IPv6:2607:f8b0:4002:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E7A9E21F96D5 for ; Mon, 15 Apr 2013 11:42:23 -0700 (PDT) Received: by mail-gg0-f178.google.com with SMTP id e5so789114ggh.23 for ; Mon, 15 Apr 2013 11:42:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=10vN2nFOkKzgIGwttCCTDNtj2diRzBDm2xJ5YT9FhgQ=; b=jA8uW3R9LvY4qpEwNv2CLFrtX1iuZznwsugyMCcLrFEQlxq6de9QUHtYmXGUDQXO6L +UziWgfWKV5+OICfg0/mBXM0DUwUb4EZva1D394DvT2ZEfa4VS1X2vNwrWQdWSMLgX1q 3t+4o3h6Lq6/04rEtGFGec1Ibjk/YQ6wBm3Q/Hj5CryOk1ikAYuG+q8iv2swdWRGslBC /IVx/qnVRyfaDsJwVys9Lz4NwRSesASL7VjjVNHAph4fQI8gCmsn9cRerafX3b4qpfqS RuMI4PPHU4XSLp6b+zluXU0mJC8ULEQCfdCkcBcilY9QMLYYjNgxCu5KZgwNbpnQ9S/v uzaA== X-Received: by 10.236.71.227 with SMTP id r63mr12816862yhd.182.1366051343458; Mon, 15 Apr 2013 11:42:23 -0700 (PDT) Received: from [192.168.1.39] (190-20-46-232.baf.movistar.cl. [190.20.46.232]) by mx.google.com with ESMTPS id s45sm29753018yhk.22.2013.04.15.11.42.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 11:42:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CDF8EA04-8905-472D-B7F6-9E7C66873AA6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51674E3D.7030004@isoc.org> Date: Mon, 15 Apr 2013 15:41:59 -0300 Message-Id: <71C65BBC-A7CB-4A5A-AE85-20650203F2FB@ve7jtb.com> References: <51674E3D.7030004@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnPgqJhjbTpOgCz1tBtS733QDg4q1DEIkYGuChWfLqNLiRtA3MDlmz2pCBRh9//6uiWMDEr Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:42:24 -0000 --Apple-Mail=_CDF8EA04-8905-472D-B7F6-9E7C66873AA6 Content-Type: multipart/alternative; boundary="Apple-Mail=_C1E2DD80-B0F6-4954-AB16-0CFB66FF9693" --Apple-Mail=_C1E2DD80-B0F6-4954-AB16-0CFB66FF9693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1 ish. Representing the nonce/IV separately should not preclude using a crypto = library generated nonce/IV , as may be done in some libraries = implementing draft-mcgrew-aead-aes-cbc-hmac-sha2. So I am in favour of the current serialization while wanting to support = the crypto from draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the = particular serialization which is optimized for a different use-case. = The current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and = serialization. I am hoping we can resolve that so the crypto can be = supported. John B. On 2013-04-11, at 8:58 PM, Karen O'Donoghue wrote: > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes = restructuring the JWE representation to remove the JWE Integrity Value = field and instead use the RFC 5116 (AEAD) binary serialization to = represent the Ciphertext, Initialization Vector, and Integrity Value = values. If this proposal is adopted, JWEs would then have three fields = =96 the header, the encrypted key, and the RFC 5116 combination of the = Ciphertext, Initialization Vector, and Integrity Value values.=20 > This issue is also related to issue #3. Note that the updated McGrew = draft described there could be used whether or not we switched to using = RFC 5116. > =20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue having separate Ciphertext, Initialization Vector, and = Integrity Value values in the JWE representation. >=20 > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the = combination of these three values. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > =20 >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_C1E2DD80-B0F6-4954-AB16-0CFB66FF9693 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 1 = ish.

Representing the nonce/IV separately should not = preclude using a crypto library generated nonce/IV , as may be done in = some libraries implementing 
So I am in favour of the current serialization = while wanting to support the crypto = from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the = particular serialization which is optimized for = a different use-case.   The = current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto = and serialization.  I am hoping we can resolve that so the crypto = can be supported.

John = B.

On 2013-04-11, at 8:58 PM, Karen = O'Donoghue <odonoghue@isoc.org> = wrote:

=20 =20
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then = have three fields =96 the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This = issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
 

Which of these best describes your preferences on this = issue?

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.  = Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three = values.

3.  = Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_C1E2DD80-B0F6-4954-AB16-0CFB66FF9693-- --Apple-Mail=_CDF8EA04-8905-472D-B7F6-9E7C66873AA6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE1MTg0MTYwWjAjBgkqhkiG9w0BCQQxFgQU04l95k+u 75ybDsv7Tb7pbw/68P0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAf6v4bnhHGtqqcgsHyqtDKSemQTCUKj0BIPSWWFXz o1tbza+l7kxjhXd8kjdx701b+ADIyGGl4hqN9ZhoapsfKmHOnuddSEkCoSTq8LMW71nREC1QN0yr roxCv5lHAv34+X9bcN9yY79QVJHs9cJzRTxeig13+lAk1wAU+fRDC6YHlYo7wPVfrLa8V6b2tnMU N6aApU8TYxjpChf7Ehn+KnZdXyWEQ8zqWzKEAk8HZ+hYVSru75NT6rhHcvy7CtHN0SL3ixYUXUCg u3rUdAvS82v/qg2Qd5jllagTbaeXLgCrqCRqSwV2Rhhi3hWAoqqb/I9a/+yWsuNWYzDqgUjzsAAA AAAAAA== --Apple-Mail=_CDF8EA04-8905-472D-B7F6-9E7C66873AA6-- From Michael.Jones@microsoft.com Mon Apr 15 11:49:18 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9366421F95F8 for ; Mon, 15 Apr 2013 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LDqO4zKgi7t for ; Mon, 15 Apr 2013 11:49:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D921F9640 for ; Mon, 15 Apr 2013 11:49:17 -0700 (PDT) Received: from BY2FFO11FD024.protection.gbl (10.1.15.204) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.664.0; Mon, 15 Apr 2013 18:49:39 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Mon, 15 Apr 2013 18:49:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 15 Apr 2013 18:48:39 +0000 From: Mike Jones To: Peter Saint-Andre , Richard Barnes Thread-Topic: [jose] Proposed Agenda for Interim Working Group Meeting Thread-Index: Ac44d1jWKgMVlUPqSZCKazcg+mJZHgBi1DCAAAF1uYAAAD11gA== Date: Mon, 15 Apr 2013 18:48:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367642704@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436761CA72@TK5EX14MBXC283.redmond.corp.microsoft.com> <516C4947.7070303@stpeter.im> In-Reply-To: <516C4947.7070303@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(479174001)(199002)(51444002)(13464002)(189002)(24454001)(33656001)(59766001)(54356001)(20776003)(46102001)(74502001)(56776001)(79102001)(16406001)(66066001)(63696002)(50466001)(65816001)(46406003)(77982001)(56816002)(44976003)(47446002)(31966008)(80022001)(54316002)(49866001)(47736001)(53806001)(47776003)(5343655001)(69226001)(47976001)(55846006)(76482001)(4396001)(81342001)(51856001)(81542001)(23726002)(74662001)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0817737FD1 Cc: Jim Schaad , "jose@ietf.org" , Karen O'Donoghue Subject: Re: [jose] Proposed Agenda for Interim Working Group Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:49:18 -0000 Beyond just dividing the agenda into four pieces, I believe we need some "h= ousekeeping" time in the agenda so that we leave with concrete and recorded= next steps with owners, including the wording for polls/consensus call que= stions, so we don't lose time after the meeting for those to be formulated = out of band before we're able to involve the whole working group. It will = be easy to focus on generating those proposed resolutions and questions whi= le we're in the same room together. Not so much once people have parted wa= ys... I'd want us to also leave some time near the end to discuss WebCrypto/JOSE = interactions, if we have time to do so. And Use Cases discussions would be= a nice-to-have as well. I support Peter St. Andre's sentiment that the using the in-person meeting = for generating agreement on thorny issues is key. I think that was always = the intent of the interim meeting. Cheers, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Monday, April 15, 2013 11:39 AM To: Richard Barnes Cc: Mike Jones; Karen O'Donoghue; Jim Schaad; jose@ietf.org Subject: Re: [jose] Proposed Agenda for Interim Working Group Meeting On 4/15/13 11:57 AM, Richard Barnes wrote: > So maybe we could divide the agenda roughly in 4, and have one large=20 > discussion on each of the above topics, with the goal of getting=20 > consensus on some answers to the above questions. +1 to using the in-person meeting for generating agreement on thorny issues... Peter _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From trac+jose@trac.tools.ietf.org Mon Apr 15 11:53:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6621F95DE for ; Mon, 15 Apr 2013 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHRHtiKzf8ni for ; Mon, 15 Apr 2013 11:53:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4084521F958A for ; Mon, 15 Apr 2013 11:53:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:54950 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URoWh-00057Q-Bt; Mon, 15 Apr 2013 20:53:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: jose Date: Mon, 15 Apr 2013 18:53:15 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/8#comment:1 Message-ID: <069.14ddb6e5b2f85a9114e66558c07bea6c@trac.tools.ietf.org> References: <054.96c0b71d4934f695a54309d767dbf877@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <054.96c0b71d4934f695a54309d767dbf877@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130415185332.4084521F958A@ietfa.amsl.com> Resent-Date: Mon, 15 Apr 2013 11:53:31 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #8: Direct mode for key agreement needs security analysis X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:53:39 -0000 #8: Direct mode for key agreement needs security analysis Comment (by ietf@augustcellars.com): Personal Opinion - I have no problems with using the key that is the output of a key agreement directly as the content encryption key. The rules here are going to be the standard ones such as you must make sure that the same key is not going to be generated each time and thus there is a requirement for a random value to be included from the senders side. However there is not going to be a significant difference between the case of using this output to wrap a key vs using this output to wrap a body. I have no issues with this mode of encryption from a cryptography standpoint. I think that a more significant question deals with the processing. Allowing this generates a new path for dealing with processing of messages which potentially complicates the analysis of the code. The requirement exists for doing the key wrap state in the event of multiple recipients and potentially should be a requirement for even the single recipient case. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From ietf@augustcellars.com Mon Apr 15 18:19:02 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4431C21F9436 for ; Mon, 15 Apr 2013 18:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpELZucsL0PH for ; Mon, 15 Apr 2013 18:19:01 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D131021F9434 for ; Mon, 15 Apr 2013 18:19:01 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 641382CA15 for ; Mon, 15 Apr 2013 18:19:01 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 15 Apr 2013 18:18:19 -0700 Message-ID: <02e701ce3a40$485326d0$d8f97470$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E8_01CE3A05.9BF53930" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac46QEZVOFHKxSmTSva1ifMOaDPoRw== Subject: [jose] Preliminary Agenda for Interim Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 01:19:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E8_01CE3A05.9BF53930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The chairs have posted their first cut at an agenda for the Interim meeting. It can be found at http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-interi m-2013-jose-1 Jim ------=_NextPart_000_02E8_01CE3A05.9BF53930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The chairs = have posted their first cut at an agenda for the Interim = meeting.

 

It can be found at http://www.ietf.org/proceedings/interim/2013/04= /29/jose/agenda/agenda-interim-2013-jose-1

 

 

Jim

 

------=_NextPart_000_02E8_01CE3A05.9BF53930-- From James.H.Manger@team.telstra.com Mon Apr 15 21:07:26 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4558E21F8EDF for ; Mon, 15 Apr 2013 21:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HusV-2a-1fck for ; Mon, 15 Apr 2013 21:07:22 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id B7A8421F8E9A for ; Mon, 15 Apr 2013 21:07:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,482,1363093200"; d="scan'208";a="129426241" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 16 Apr 2013 14:07:18 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7046"; a="125824825" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcdvi.tcif.telstra.com.au with ESMTP; 16 Apr 2013 14:07:18 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 16 Apr 2013 14:07:18 +1000 From: "Manger, James H" To: Mike Jones Date: Tue, 16 Apr 2013 14:07:17 +1000 Thread-Topic: [jose] #16: URI identifying a specific key in a JWK set Thread-Index: AQHOKPFt1UwdLuDfz0WljLLGMUo+yJjGVMwAgBA7dQCAAOD2AIAAFguQgADK9VA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C8130DF@WSMSG3153V.srv.dir.telstra.com> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <073.1dc661959a15caad46917baec89b3440@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150C74DB3E@WSMSG3153V.srv.dir.telstra.com> <516C07EE.8000306@mitre.org> <4E1F6AAD24975D4BA5B168042967394367641877@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367641877@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 04:07:26 -0000 PiBSZXF1aXJpbmcgaW1wbGVtZW50YXRpb24gb2YgSlNPTi1Qb2ludGVyDQo+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY5MDEganVzdCB0byB1c2UgYSBKV0sgU2V0IHNlZW1zIFdBWSBv dmVyDQo+IHRoZSB0b3AgdG8gbWUuICBQbGVhc2UgaGF2ZSBzb21lIGNvbnNpZGVyYXRpb24gZm9y IHRoZSBkZXZlbG9wZXJzIHdobw0KPiB3YW50IHRvIGFjdHVhbGx5IGJ1aWxkIGFuZCB1c2UgdGhl IEpPU0Ugc3BlY3MhICBBY3R1YWwgaW1wbGVtZW50YXRpb24NCj4gYW5kIGRlcGxveW1lbnQgaXMg YSBnb2FsIGhlcmUuDQoNCk1pa2UsIHRoaXMgb2JqZWN0aW9uIGlzIOKAnFdBWSBvdmVyIHRoZSB0 b3DigJ0uDQpJIHByb3Bvc2VkIHRoYXQgdGhlIGZyYWdtZW50IGZpZWxkIG9mIGEgamt1IFVSSSBz aG91bGQgYmU6IGEgIi8iIGNoYXJhY3RlciBmb2xsb3dlZCBieSB0aGUga2V5LWlkICgia2lkIiB2 YWx1ZSkuDQpIb3cgc2ltcGxlIGRvIHlvdSBuZWVkIGl0Pw0KDQpUaGUgZmFjdCB0aGF0IHRoaXMg c3ludGF4IG1hdGNoZXMgUkZDIDY5MDEgIkpTT04gUG9pbnRlciIgKDggcGFnZXMsIGluY2x1ZGlu ZyBib2lsZXJwbGF0ZSwgcmVmZXJlbmNlcywgZXhhbXBsZXMpIGlzIG5vdCBnb2luZyB0byBzY2Fy ZSBhbnkgZGV2ZWxvcGVyLCBub3IgaG9sZCB0aGVtIHVwIGZvciBtb3JlIHRoYW4gYW4gaG91ci4g SXQgd2lsbCBwcm9iYWJseSBiZSBidWlsdC1pbiB0byBtYW55IEpTT04gbGlicmFyaWVzIHNob3J0 bHkuDQpPbmUgbGluZSBvZiBjb2RlIHdvdWxkIHN1ZmZpY2UgdG8gZ2V0IHRoZSBrZXktaWQgZnJv bSBhICJqa3UiIFVSSSAoZXhhbXBsZSBpbiBKYXZhKToNCiAgU3RyaW5nIGtpZCA9IHVyaS5nZXRG cmFnbWVudCgpLnN1YnN0cmluZygxKS5yZXBsYWNlQWxsKCJ+MSIsIi8iKS5yZXBsYWNlQWxsKCJ+ MCIsIn4iKTsNCltyZWFsIGNvZGUgc2hvdWxkIGFkZCBhbiBleHRyYSBsaW5lIHRvIGRvIGEgYml0 IG1vcmUgaW5wdXQgdmFsaWRhdGlvbl0NCg0KSG93IGRvZXMgdGhlIGN1cnJlbnQgc3lzdGVtIHNo b3cgY29uc2lkZXJhdGlvbiBmb3IgZGV2ZWxvcGVycz8gVGhleSBoYXZlIHRvIG1ha2UgdXAgdGhl aXIgb3duIGhldXJpc3RpY3MgYmFzZWQgb24gImtpZCIsIG9yICJhbGciLCBvciAidXNlIiwgb3Ig Imt0eSIsIG9yICJleHAiLCBvciB0cmlhbC1hbmQtZXJyb3IgdG8gZmluZCB0aGUgcmlnaHQga2V5 IGZyb20gYSBzZXQ/DQoNCg0KPiBJIG9iamVjdCB0byBtb3ZpbmcgdGhlIEtleSBJRCBmaWVsZCBv dXQgb2YgdGhlIEpXSyBmb3IgdGhlIHJlYXNvbnMNCj4gaWRlbnRpZmllZCBieSBKdXN0aW4uICBT cGVjaWZpY2FsbHksIHdlIHdhbnQgdGhlIEtleSBJRCB0byBiZSB1c2FibGUNCj4gZm9yIEpXS3Mg LSBub3QganVzdCBKV0sgU2V0cy4NCg0KSSBoYXZlIG5vIHByb2JsZW0gd2l0aCBkZWZpbmluZyAi a2lkIiBhcyBhIGZpZWxkIHRoYXQgY2FuIGNvbnZleSB0aGUga2V5LWlkIGluc2lkZSBhIHNpbmds ZSBKV0suIEl0IHdvdWxkIGJlIHVubmVjZXNzYXJ5IHRvIGluY2x1ZGUgdGhpcyBmaWVsZCB3aGVu IHRoZSBKV0sgd2FzIG5hbWVkIGJ5IHRoZSBrZXktaWQgYXMgcGFydCBvZiBhIEpXSyBzZXQsIGJ1 dCBub3QgaGFybWZ1bC4NCg0KPiBJIGFsc28gb2JqZWN0IHRvIHRoZSBhc3ltbWV0cnkgb2YgdGhp cyBwcm9wb3NhbC4gIEhhdmluZyBvbmUga2V5DQo+IGF0dHJpYnV0ZSAodGhlIEtleSBJRCkgbm90 IGJlIHBhcnQgb2YgdGhlIEpXSywgd2hlcmUgb3RoZXJzIHN1Y2ggYXMNCj4gInVzZSIgYW5kICJh bGciIGFyZSBqdXN0IG1ha2VzIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGVkLiAgQWxsIGF0dHJpYnV0 ZXMNCj4gc2hvdWxkIGJlIHBhcnQgb2YgdGhlIEpXSyBzdHJ1Y3R1cmUgLSBub3QganVzdCBzb21l IG9mIHRoZW0uDQoNCktleS1pZCBpcyBzaW5nbGVkIG91dCBhcyBpdCBpcyB0aGUgaWRlbnRpZmll ciBmb3IgdGhlIGtleS4gQSBmaWxlbmFtZSBpc24ndCBpbiBhIGZpbGXigJlzIGNvbnRlbnQ7IGEg ZG9jdW1lbnTigJlzIHdlYiBhZGRyZXNzIGlzbuKAmXQgaW4gaXRzIGJvZHkuDQoNCi0tDQpKYW1l cyBNYW5nZXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3NlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zg0KPiBKdXN0aW4gUmljaGVyDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgNzowMCBB TQ0KPiBUbzogTWFuZ2VyLCBKYW1lcyBIDQo+IENjOiBqb3NlQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbam9zZV0gIzE2OiBVUkkgaWRlbnRpZnlpbmcgYSBzcGVjaWZpYyBrZXkgaW4gYSBKV0sg c2V0DQo+IA0KPiBJIGxpa2UgdGhpcyBzdHJ1Y3R1cmFsIHByb3Bvc2FsIHdpdGggb25lIGNhdmVh dDogbW92aW5nIHRoZSBrZXkgSUQgb3V0DQo+IG9mIHRoZSBrZXkgc3RydWN0dXJlIG1lYW5zIHRo YXQgYSBKV0sgY2FuIG5vIGxvbmdlciBiZSBhIHNlbGYtY29udGFpbmVkDQo+IHVuaXQgd2l0aCBh bGwgb2YgdGhlIG1ldGFkYXRhIHRoYXQgaXQgY29udGFpbnMgdG9kYXkuIElzIHRoYXQgd2hhdCB3 ZQ0KPiB3YW50PyBEbyB3ZSB3YW50IHRvIGRlY2xhcmUgdGhhdCBhIGtleSBpZCBvbmx5IG1ha2Vz IHNlbnNlIGluIHRoZQ0KPiBjb250ZXh0IG9mIGEgSldLIFNldCBhbmQgbm90IGFuIGluZGl2aWR1 YWwgSldLPyBBIHNpbXBsZSB3b3JrYXJvdW5kDQo+IHdvdWxkIGJlIHRvIGhhdmUgYm90aCB0aGUg b2JqZWN0LWJhc2VkIHN0cnVjdHVyZSBhcyB3ZWxsIGFzIHRoZSB2YWx1ZQ0KPiB3aXRoaW4gdGhl IEpXSyBpdHNlbGYgYW5kIHRoYXQgdGhleSBNVVNUIG1hdGNoLg0KPiANCj4gICAtLSBKdXN0aW4N Cj4gDQo+IE9uIDA0LzE0LzIwMTMgMDg6MzUgUE0sIE1hbmdlciwgSmFtZXMgSCB3cm90ZToNCj4g Pj4gIzE2OiBVUkkgaWRlbnRpZnlpbmcgYSBzcGVjaWZpYyBrZXkgaW4gYSBKV0sgc2V0DQo+ID4+ PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzE2DQo+ID4+ ICAgSW4gb3JkZXIgdG8gZXZhbHVhdGUgdGhpcywgd2UgbmVlZCB0byBnZXQgYSBtb3JlIGRldGFp bGVkIHByb3Bvc2FsDQo+IEJlbG93IGlzIGEgbW9yZSBkZXRhaWxlZCBwcm9wb3NhbC4gVGhlIGJh c2ljIGlkZWEgaXMgdG8gbWFrZSB0aGUgSldLDQo+IGtleSBzZXQgc3ludGF4IGEgYml0IG1vcmUg c2Vuc2libGUgKGtleXMgbmFtZWQgYnkgdGhlaXIgaWRzOyBpbnN0ZWFkIG9mDQo+IGEgImtleXMi IGVsZW1lbnQgaG9sZGluZyBhbiBhcnJheSBvZiBrZXlzKTsgZ2l2ZSBrZXkgc2V0cyBhIG1lZGlh IHR5cGU7DQo+IGFuZCBkZWZpbmUgdGhlIGZyYWdtZW50IHRvIGJlIGEgSlNPTiBwb2ludGVyIFtS RkMgNjkwMV0uIFRoZW4gYSBVUkkgY2FuDQo+IGlkZW50aWZ5IGEgc3BlY2lmaWMga2V5LiBBICJq a3UiIHZhbHVlIGNhbiBwcmVjaXNlbHkgaW5kaWNhdGUgdGhlIGtleQ0KPiBuZWVkZWQgdG8gcHJv Y2VzcyBhIEpPU0UgbWVzc2FnZSwgZWcNCj4gImprdSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vYWxp Y2Uua2V5cyMvazEiLg0KPiANCj4gDQo+ID4+ICAgMS4gIFN5bnRheCBvZiB0aGUgZnJhZ21lbnQN Cj4gVGhlIGZyYWdtZW50LCBpZiBwcmVzZW50LCBpZGVudGlmaWVzIGEgc3BlY2lmaWMga2V5IGlu IHRoZSBKV0sga2V5IHNldC4NCj4gDQo+IFRoZSBmcmFnbWVudCBTSEFMTCBiZSBhIEpTT04gUG9p bnRlciBbUkZDIDY5MDFdLCBwb2ludGluZyB0byB0aGUgSlNPTg0KPiBvYmplY3QgaG9sZGluZyB0 aGUgc3BlY2lmaWMga2V5IG9mIGludGVyZXN0IHdpdGhpbiB0aGUgc2V0IG9mIGtleXMuDQo+IA0K PiBUaGUgZnJhZ21lbnQgU0hBTEwgYmUgYSAiLyIgY2hhcmFjdGVyIGZvbGxvd2VkIGJ5IHRoZSBr ZXkgaWRlbnRpZmllcg0KPiAoImtpZCIgdmFsdWUpIGZvciB0aGUgc3BlY2lmaWMga2V5Lg0KPiAN Cj4gW1RoaXMgaW1wbGllcyB0aGUgdG9wLWxldmVsIHN0cnVjdHVyZSBvZiBhIEpXSyBrZXkgc2V0 IGlzIGNoYW5nZWQgdG8gYmUNCj4gYSBKU09OIG9iamVjdCB3aG9zZSBlbGVtZW50cyBhcmUgaW5k aXZpZHVhbCBrZXlzLiBBbiBlbGVtZW50J3MgbmFtZSBpcw0KPiB0aGUgaWRlbnRpZmllciBvZiB0 aGUga2V5ICgia2lkIiB2YWx1ZSk7IGFuIGVsZW1lbnQncyB2YWx1ZSBpcyBhIHNpbmdsZQ0KPiBK V0sgb2JqZWN0LiBPbmUgZWxlbWVudCAobmFtZWQgIm1ldGEiKSBpcyBzcGVjaWFsOiBpdCBpcyBu b3QgYSAia2lkIg0KPiB2YWx1ZSwgYnV0IGEgcGxhY2UgdG8gaG9sZCBhbnkgbWV0YWRhdGEgYWJv dXQgdGhlIHdob2xlIHNldCBvZiBrZXlzLg0KPiANCj4gRXhhbXBsZToNCj4gICAgew0KPiAgICAg ICJrMSIgOiB7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjrigKYsInkiOuKApn0sDQo+ICAg ICAgIDIwMTEtMDQtMjkiIDogeyJrdHkiOlJTQSIsIm4iOuKApiwiZSI6IkFRQUIifQ0KPiAgICB9 DQo+IF0NCj4gDQo+IA0KPiA+PiAgIDIuICBkZWFsaW5nIHdpdGggZHVwbGljYXRlIHZhbHVlcyB3 aXRoaW4gYSBKV0sgc3RydWN0dXJlDQo+IEknbSBub3Qgc3VyZSB3aGF0IHRoaXMgaXNzdWUgaXMu IEkgc3VzcGVjdCBpdCBpcyBzb2x2ZWQgYnkgc3RvcmluZyBrZXlzDQo+IGFzIG9iamVjdCBlbGVt ZW50cyBhcyBvcHBvc2VkIHRvIGFycmF5IGl0ZW1zLg0KPiANCj4gPj4gICAzLiAgRGVmaW5pdGlv biBvZiBhIG5ldyBtZWRpYSB0eXBlIC0gaXMgdGhpcyByZXF1aXJlZCBvciBub3QgLQ0KPiBqdXN0 aWZ5DQo+ID4+ICAgZWl0aGVyIHBvc3Rpb24NCj4gVGhlIEpXSyBzcGVjIHNob3VsZCBkZWZpbmUg YSBtZWRpYSB0eXBlLCBzdWNoIGFzIGFwcGxpY2F0aW9uL2tleXMranNvbi4NCj4gRnJhZ21lbnRz IGFyZSBzcGVjaWZpYyB0byBhIG1lZGlhIHR5cGUgc28gYSBtZWRpYSB0eXBlIG5lZWRzIHRvIGJl DQo+IGRlZmluZWQuDQo+IA0KPiA+PiAgIDQuICBFeHBsYWluIHdoeSB0aGUgcHJvcG9zYWwgaXMg ImJldHRlciIgdGhhbiB0aGUgY3VycmVudCBhYmlsaXR5DQo+ID4+IHRvIGhhdmUgYSB1cmwgcGx1 cyB0aGUga2lkIGluIHRoZSBtZXNzYWdlLg0KPiBUaGUgd2hvbGUgY29uY2VwdCBvZiBhIFVSSSBp cyB0byBiZSBhbiBpZGVudGlmaWVyIGl0c2VsZiAobm90IGp1c3Qgd2hlbg0KPiBjb21iaW5lZCB3 aXRoIGEgc2Vjb25kIGZpZWxkKS4gTWFueSwgbWFueSBzeXN0ZW1zIGFuZCBwcm90b2NvbHMgdGhh dA0KPiBzdXBwb3J0IFVSSXMgYXNzdW1lIHRoYXQgdGhlIFVSSSBhbG9uZSBpcyBzdWZmaWNpZW50 IHRvIGlkZW50aWZ5IHRoZQ0KPiBpdGVtIG9mIGludGVyZXN0Lg0KPiBJdCBzaW1wbGlmaWVzIEFQ SXMgYW5kIHByb3RvY29sczoganVzdCBwYXNzIDEgdmFsdWUuDQo+IA0KPiA+PiAgIDUuICBEaXNj dXNzIHdoYXQgaGFwcGVucyBpZiB0aGUgZnJhZ21lbnQgaXMgbm90IHByZXNlbnQgb24gdGhlIHVy bA0KPiBUaGUgc3BlY3Mgc2hvdWxkIGJlIHdyaXR0ZW4gc28gdGhhdCBpZiB0aGVyZSBpcyBubyBm cmFnbWVudCBidXQgdGhlcmUNCj4gaXMgb25seSAxIGtleSBpbiB0aGUgaWRlbnRpZmllZCBKV0sg a2V5IHNldCwgdGhlbiB0aGluZ3Mgc3RpbGwgd29yay4NCj4gDQo+IEkgc3VnZ2VzdCBzYXlpbmcg YSAqY3JlYXRvciogb2YgYSAiamt1IiBVUkkgdmFsdWUgKHRvIGlkZW50aWZ5IHRoZQ0KPiBzcGVj aWZpYyBrZXkgcmVxdWlyZWQgdG8gcHJvY2VzcyBhIEpPU0UgbWVzc2FnZSkgTVVTVCBpbmNsdWRl IGENCj4gZnJhZ21lbnQgdG8gaWRlbnRpZnkgYSBzaW5nbGUga2V5LiBXaGVuIGEga2V5IHNldCBo YXMgb25seSAxIGtleSwgYQ0KPiAqcmVjZWl2ZXIqIE1VU1QgYWNjZXB0IGEgImprdSIgVVJJIGFz IGFuIGlkZW50aWZpZXIgb2YgdGhhdCAxIGtleSBldmVuDQo+IGlmIHRoZSBVUkkgaGFzIG5vIGZy YWdtZW50Lg0KPiANCj4gPj4gb3IgaWYgdGhlIGZyYWdtZW50IGlzIG5vdCBmaW5kYWJsZSBpbiB0 aGUgcmVzdWx0YW50IGRvY3VtZW50Lg0KPiBUaGVuIHRoZSBVUkkgaWRlbnRpZmllcyBhIGtleSB0 aGF0IGlzIG5vdCBwcmVzZW50IHNvIGFuIGVycm9yIHJlc3VsdHMNCj4gKHNpbWlsYXIgdG8gZ2V0 dGluZyBhIDQwNCBOb3QgRm91bmQgZm9yIHRoZSB3aG9sZSBrZXkgc2V0KS4NCj4gDQo+ID4+ICAg SWYgdGhlIGZyYWdtZW50DQo+ID4+ICAgaXMgZ29pbmcgdG8gYmUgbWFuZGl0b3J5IGRvZXMgdGhl bSBtZWFuIHRoYXQgd2Ugc2hvdWxkIGJlIGRvaW5nIGENCj4gbmV3DQo+ID4+ICAgc2NoZW1lIGlu c3RlYWQgYXMgZnJhZ21lbnRzIGNhbm5vdCBiZSByZXF1aXJlZCB1bmRlciB0aGUgY3VycmVudA0K PiBVUkwNCj4gPj4gICBzeW50YXggZGVmaW50aW9ucyAob3IgYXQgbGVhc3QgdGhhdCBpcyBteSBy ZWFkaW5nKS4NCj4gRGVmaW5pdGVseSBubyBuZXcgVVJJIHNjaGVtZS4NCj4gQSBVUkkgd2l0aG91 dCBhIGZyYWdtZW50IGlzIHN0aWxsIGEgdmFsaWQgVVJJLiBUaGF0IGRvZXNuJ3Qgc3RvcCB1cw0K PiBzYXlpbmcgYSAiamt1IiBVUkkgdmFsdWUgTVVTVCBjb250YWluIGEgZnJhZ21lbnQuDQo+IA0K PiA+PiAgIFBsZWFzZSBmbGVzaCBvdXQgeW91ciBwcm9wb3NhbCBtb3JlIHNvIHRoYXQgaXQgY2Fu IGJlIGZ1bGx5DQo+IGV2YWx1YXRlZC4NCj4gSSBob3BlIHRoaXMgZW1haWwgaGFzIGZsZXNoZWQg b3V0IGEgcHJvcG9zYWwgc3VmZmljaWVudGx5Lg0KPiANCj4gLS0NCj4gSmFtZXMgTWFuZ2VyDQoN Cg== From rlb@ipv.sx Tue Apr 16 07:24:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CEB21F9702 for ; Tue, 16 Apr 2013 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPUTftXHGCja for ; Tue, 16 Apr 2013 07:24:14 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0461521F96FA for ; Tue, 16 Apr 2013 07:24:13 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id x4so488456obh.1 for ; Tue, 16 Apr 2013 07:24:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T+RRBD0ZnBkL5C/iuHq8wG+j/JGS6yRTk0FeCI9rvJ8=; b=MTmKeKe3+cqtzYCQnfXHsPi3Erzd/ARB9kCWHxoaVMZF/SjHhCm1RhF94Dywi+pvRa l9SmQwNqMzvW8sQ9s54fBNQCY6/EbQFGzxX/+jbizDETBK/BmX0abYZSnAmJWUHjJ7Cx WM9bUjPqhn6+VJRf2BzlZ/XNVBDBN3dQw0coTc2W6aDAUUqbrZgmwdbGABfVEAwNKurM KzCPRvvFIOr3HBxPZy5498e/tFi3EtuWCu+s+aR80chu+O3kjx/6rft2ZjrLjCtE1hcD bYVi/Kh10WYTIvwVod1DnVEMQ12vJhiLMX2dnPXxNNwvuY4yGAIKJiXrNTjVsFBEsYz9 V3GQ== MIME-Version: 1.0 X-Received: by 10.60.62.39 with SMTP id v7mr941636oer.5.1366122252796; Tue, 16 Apr 2013 07:24:12 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Tue, 16 Apr 2013 07:24:12 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <71C65BBC-A7CB-4A5A-AE85-20650203F2FB@ve7jtb.com> References: <51674E3D.7030004@isoc.org> <71C65BBC-A7CB-4A5A-AE85-20650203F2FB@ve7jtb.com> Date: Tue, 16 Apr 2013 10:24:12 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=089e013a005a99657604da7b1fbe X-Gm-Message-State: ALoCoQnwfpnW9S+5tVvXwUphqBP/4PBqOg7eOVbgp8wLjqoGnOTKFyRgQDsIdv3DqOO2tKM/8xSb Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:24:16 -0000 --089e013a005a99657604da7b1fbe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm confused. This is not about the IV =3D=3D Initialization Vector, it's about the JWE Integrity Value (inconveniently also "IV"). I don't think anyone has proposed merging in the initialization vector, both because that's not what RFC 5116 does and because it's a terrible idea :) On Mon, Apr 15, 2013 at 2:41 PM, John Bradley wrote: > 1 ish. > > Representing the nonce/IV separately should not preclude using a crypto > library generated nonce/IV , as may be done in some libraries implementin= g > draft-mcgrew-aead-aes-cbc-hmac-sha2. > > So I am in favour of the current serialization while wanting to support > the crypto from draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the particula= r > serialization which is optimized for a different use-case. The current = draft-mcgrew-aead-aes-cbc-hmac-sha2 > conflates crypto and serialization. I am hoping we can resolve that so t= he > crypto can be supported. > > John B. > > On 2013-04-11, at 8:58 PM, Karen O'Donoghue wrote: > > Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes > restructuring the JWE representation to remove the JWE Integrity Value > field and instead use the RFC 5116 (AEAD) binary serialization to represe= nt > the Ciphertext, Initialization Vector, and Integrity Value values. If th= is > proposal is adopted, JWEs would then have three fields =96 the header, th= e > encrypted key, and the RFC 5116 combination of the Ciphertext, > Initialization Vector, and Integrity Value values.****** ** > > This issue is also related to issue #3. Note that the updated McGrew > draft described there could be used whether or not we switched to using R= FC > 5116.**** > > > Which of these best describes your preferences on this issue?**** > > 1. Continue having separate Ciphertext, Initialization Vector, and > Integrity Value values in the JWE representation.**** > > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the > combination of these three values.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > > Your reply is requested by Friday, April 19th or earlier. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e013a005a99657604da7b1fbe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm confused. =A0This is not about the IV =3D=3D Initialization Vector,= it's about the JWE Integrity Value (inconveniently also "IV"= ). =A0I don't think anyone has proposed merging in the initialization v= ector, both because that's not what RFC 5116 does and because it's = a terrible idea :)


On Mon, Apr 15, 2013 at 2:41 PM, John Br= adley <ve7jtb@ve7jtb.com> wrote:
1 ish.

Representing = the nonce/IV separately should not preclude using a crypto library generate= d nonce/IV , as may be done in some libraries implementing=A0=A0dra= ft-mcgrew-aead-aes-cbc-hmac-sha2.

So I am in=A0favour=A0of the current serialization while wanti= ng to support the crypto from=A0=A0draft-mcgrew-aead-aes-cbc-hmac-sha2 if n= ot the particular serialization which is=A0optimized=A0for a=A0different=A0= use-case. =A0 The current=A0draft-mcgrew-aead-aes-cbc-hmac-sha2 conf= lates crypto and serialization. =A0I am hoping we can resolve that so the c= rypto can be supported.

John B.

On 2013-04-11, = at 8:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

=20 =20 =20
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.=A0 If this proposal is adopted, JWEs would then have three fields =96 the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values.=A0

This= issue is also related to issue #3.=A0 Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
=A0

Which of these best describes your preferences on this issue?

<= p class=3D"MsoNormal">1.=A0 Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.=A0 Swi= tch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.<= /u>

3.=A0 Another resolution (please specify in detail).

0.=A0 I need more information to decide.

=A0

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing list
jose@ietf.org
https://= www.ietf.org/mailman/listinfo/jose


______________________________= _________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e013a005a99657604da7b1fbe-- From mamille2@cisco.com Tue Apr 16 08:52:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE7021F9780 for ; Tue, 16 Apr 2013 08:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkXxMzWrAGEi for ; Tue, 16 Apr 2013 08:52:03 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7260221F973B for ; Tue, 16 Apr 2013 08:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5794; q=dns/txt; s=iport; t=1366127523; x=1367337123; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=vOU95dCN3HduJCMMjab2hGGF6BeTqxDX6aDkEVxZzu0=; b=SIYQSLe0mPp0+1vQKVdOeJ0RxGJkoq3m5ShN4ttEEjl3IMoDNcpp/QIB fic4KL+vh6f2v/hPrrZhdkZZ7K1zXShRC3viIGNrMxuslr6Q0xeis8R8Q /3cN9o644spAHuAr8n76wR0PorLz6o0ZboWpM9xynhmyqrUPr9ZCrer6S U=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAMhybVGrRDoI/2dsb2JhbABQgwY2AcEFgQkWdIIfAQEBAwEBAQFrCwULCw4tCwIlMAYTCYgFBQ2sTZBMjV0KgSgHgmFhA4kFhk+HMYEjhGSLDYFVgVUdgTc X-IronPort-AV: E=Sophos;i="4.87,486,1363132800"; d="p7s'?scan'208";a="78733277" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 16 Apr 2013 15:52:00 +0000 Received: from [10.129.24.107] ([10.129.24.107]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3GFpvEt010366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Apr 2013 15:51:58 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_FDFDA656-6A65-4931-8C21-1F0CFF61B80B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Matt Miller In-Reply-To: Date: Tue, 16 Apr 2013 09:51:57 -0600 Message-Id: References: <51674E17.5020902@isoc.org> To: Richard Barnes X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 15:52:06 -0000 --Apple-Mail=_FDFDA656-6A65-4931-8C21-1F0CFF61B80B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If we're just talking about how the algorithm in use is determined, then = I would prefer (1). While I see value in better separating key encipherment parameters from = content encipherment parameters, that seems like a separate question. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Apr 15, 2013, at 9:43 AM, Richard Barnes wrote: > 2b. Switch to a structure more like the WebCrypto structure, in which > algorithm parameters are collected alongside the algorithm name -- and > separately from key encipherment parameters. >=20 > Cf. [draft-barnes-jose-key-wrapping] >=20 >=20 >=20 > On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue = wrote: >=20 >> Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out >> that the JWA algorithm identifiers are different than those used by = the W3C >> WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA = algorithm >> identifiers are strings, whereas the W3C WebCrypto algorithm = identifiers >> are structures including string identifiers. The working group had >> previously decided to continue representing JOSE algorithms as = strings, as >> recorded at >> http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. >> **** >>=20 >>=20 >> Which of these best describes your preferences on this issue?**** >>=20 >> 1. Continue have the JWA algorithm identifiers be strings, and not >> objects. Note that WebCrypto may choose to use some of these same = strings, >> where applicable.**** >>=20 >> 2. Switch to using the algorithm identifier structures defined in = the >> WebCrypto draft.**** >>=20 >> 3. Another resolution (please specify in detail).**** >>=20 >> 0. I need more information to decide.**** >>=20 >> Your reply is requested by Friday, April 19th or earlier. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_FDFDA656-6A65-4931-8C21-1F0CFF61B80B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQxNjE1NTE1OFowIwYJKoZIhvcNAQkEMRYEFAdDRIJskXsror0AnG3LLXq2xPdgMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBkFXvGEljoJD2o7wjZDCLxhGNRW96I88hOBULfTZge pC5KrhUIBM9DFGJjQ1SfiWUvOxCqAiN8JwMqqXZ7b3xJJY7CdW6kuF6UqbR0W8pLi6e2UR+DtI9q DbJKIedIHkhPebgnCmY3ZPWznPSCT9ti510h1n6oAz2F8P/837y9AkSoOyKn5qSHkISS1s6QehRc CX/R9wvrdZvs4l2g/DzEbi7wPl++Gieg3Qrew10pKbplbwtc3HLncIjaiobbz/ua/yNJyRqU3W16 oN36wEiYsJbwbcauknheW9hCFeOme7wShJnk5MmqshwfUnGoEgzInJipNZw0Aa5AbQbeCYV9AAAA AAAA --Apple-Mail=_FDFDA656-6A65-4931-8C21-1F0CFF61B80B-- From mamille2@cisco.com Tue Apr 16 08:57:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2621F9765 for ; Tue, 16 Apr 2013 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbkxnVlQvilJ for ; Tue, 16 Apr 2013 08:57:15 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD62821F971A for ; Tue, 16 Apr 2013 08:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4777; q=dns/txt; s=iport; t=1366127836; x=1367337436; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=zBV7bLC8Nm4wY/jpxPB6iudR1t8keWs8yG5braA2Alo=; b=OzqIQ/WieY+3v/ZZvjPGiN8eHibl+nzoUFl9n3YwCuhucAfr7s0Uv0pM ToLv6NKOXggJ15zKcYlhiLtRBCH+E5IHghwE+0eicKs8zTuC+EhTa7WNe vmfXKfTmlop155FBy+J8Ub6hv62ozO/3KHSZw0o0vYZa7R7tsc3ghEUm1 U=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAFp0bVGrRDoH/2dsb2JhbABQgwY2AcEFgQkWdIIfAQEBAwEBAQFrCwULC0YCJTAGE4gOBQ2sUZBKjVgPgSgHFoJLYQOJBYMKg0WHMYEjhGRyihuBVYFVHYEv X-IronPort-AV: E=Sophos;i="4.87,486,1363132800"; d="p7s'?scan'208";a="78805397" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 16 Apr 2013 15:57:14 +0000 Received: from [10.129.24.107] ([10.129.24.107]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3GFvBd5015580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Apr 2013 15:57:12 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_44333992-6B56-422E-B544-323C93FF8C7E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Matt Miller In-Reply-To: <51674E58.6000505@isoc.org> Date: Tue, 16 Apr 2013 09:57:11 -0600 Message-Id: References: <51674E58.6000505@isoc.org> To: X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 15:57:16 -0000 --Apple-Mail=_44333992-6B56-422E-B544-323C93FF8C7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have a slight preference for (2), assuming JWE retains the "kid" = parameter. I personally would rather limit key indication to a JWK (and = wrapping "x5c" in a JWK), or a reference to a JWK ("kid", and maybe = "jku"). - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue = wrote: > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 = suggests removing = the "x5c" header parameter from JWE, saying that no use case for it has = emerged. The same logic may apply to other key specification parameters = for JWE. >=20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Retain the "x5c" header parameter in JWE. >=20 > 2. Remove the "x5c" header parameter (and possibly other related key = specification parameters) from JWE. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19^th or earlier. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_44333992-6B56-422E-B544-323C93FF8C7E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQxNjE1NTcxMlowIwYJKoZIhvcNAQkEMRYEFPBX6j73b4JGToqGHrjfEfbP0P74MIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQATFDDIZ8v1Cf3+wMya/xIdhyTsZSEm1742XqAZTOW5 bknIQOyFGOvSRCQOBfDi4pz0uXyLy51hntXhZrZsvMFNg8YwIDPTu9vU7u40CtvaI1/FQERr/ZX2 6EZZQ8LyqUWG1JGhohUlUOEkyLJ3JiunpYi7yPpZFjaODSOat1Mj5R5G8UlKOD4+x/Cr9MOOvy4m 4CpTMFPoaR9KV5ZVoFacV7geuUl3wj3onPO0SXRHmNi0iOxTHr8yA4NxSczjSDDPYAsozwaNP67+ DzXcAItGAnqlBp2axXd0u0+thg+9dqVq778JGvG1Mh0LhQg/Kv3WEp3Hsq1+xOs/JmzonCDZAAAA AAAA --Apple-Mail=_44333992-6B56-422E-B544-323C93FF8C7E-- From rlb@ipv.sx Tue Apr 16 09:48:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4521F9701 for ; Tue, 16 Apr 2013 09:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNBPDtH083KK for ; Tue, 16 Apr 2013 09:48:30 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8021F96FF for ; Tue, 16 Apr 2013 09:48:29 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id un3so619833obb.25 for ; Tue, 16 Apr 2013 09:48:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=h9CEUEyJ8kfhAUfXjPlgxM0LGMo5L8Q4buQH7Bpo2Ho=; b=C99DVEUojUCBrQ29I9XxWYVCAskM+e9qypwpqB3r+I3NM6cskvrbjhp7RMX06N3i9N ohsfV5iOu7faGKU5qrK3I5smdpy+QZvepRHuE7cYrjd1pOyL0oUqxk4lXz7VAhXUbhfO pP0RSb+hRdfI4oRn5aBO89KupYMxBR3cbA8AwZFGH4ZVf5phr5C44s+S5ECBiiHudLVw asTJfqmwsgg3dOpPc2U5pi//uMrnGbjBmxGxGmdExOnsQmg4SfYgk9aEh/0pZfSKrvyI 2RT+A+7DONeN8cnqQVrAUFbLzSId2rU4c7bGSkVxBHIk29P9tLg66cApdvXOsnywQsbt jzyQ== MIME-Version: 1.0 X-Received: by 10.182.129.101 with SMTP id nv5mr1061804obb.56.1366130909151; Tue, 16 Apr 2013 09:48:29 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Tue, 16 Apr 2013 09:48:29 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: <51674E58.6000505@isoc.org> Date: Tue, 16 Apr 2013 12:48:29 -0400 Message-ID: From: Richard Barnes To: Matt Miller Content-Type: multipart/alternative; boundary=e89a8fb1ebe48e961604da7d2379 X-Gm-Message-State: ALoCoQl72eaq1GJ05Dmb+yNDOnq8o7l9z0XF7hG64RCezspSy25t4zOinnnpZE8rYJ3GrCp2N9sr Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:48:30 -0000 --e89a8fb1ebe48e961604da7d2379 Content-Type: text/plain; charset=ISO-8859-1 That limitation seems very sensible to me. It would be a large simplification over current JWE, with its abundance of key identifiers. --Richard On Tue, Apr 16, 2013 at 11:57 AM, Matt Miller wrote: > I have a slight preference for (2), assuming JWE retains the "kid" > parameter. I personally would rather limit key indication to a JWK (and > wrapping "x5c" in a JWK), or a reference to a JWK ("kid", and maybe "jku"). > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue wrote: > > > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 < > http://trac.tools.ietf.org/wg/jose/trac/ticket/12> suggests removing the > "x5c" header parameter from JWE, saying that no use case for it has > emerged. The same logic may apply to other key specification parameters > for JWE. > > > > > > Which of these best describes your preferences on this issue? > > > > 1. Retain the "x5c" header parameter in JWE. > > > > 2. Remove the "x5c" header parameter (and possibly other related key > specification parameters) from JWE. > > > > 3. Another resolution (please specify in detail). > > > > 0. I need more information to decide. > > > > Your reply is requested by Friday, April 19^th or earlier. > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8fb1ebe48e961604da7d2379 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That limitation seems very sensible to me. =A0It would be a large simplific= ation over current JWE, with its abundance of key identifiers.
--Richar= d


On Tue, Apr 16, 2013 at 11:5= 7 AM, Matt Miller <mamille2@cisco.com> wrote:
I have a slight preference for (2), assuming= JWE retains the "kid" parameter. =A0I personally would rather li= mit key indication to a JWK (and wrapping "x5c" in a JWK), or a r= eference to a JWK ("kid", and maybe "jku").


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

> Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 &= lt;http://trac.tools.ietf.org/wg/jose/trac/ticket/12> suggests = removing the "x5c" header parameter from JWE, saying that no use = case for it has emerged. =A0The same logic may apply to other key specifica= tion parameters for JWE.
>
>
> Which of these best describes your preferences on this issue?
>
> 1. =A0Retain the "x5c" header parameter in JWE.
>
> 2. Remove the "x5c" header parameter (and possibly other rel= ated key specification parameters) from JWE.
>
> 3. =A0Another resolution (please specify in detail).
>
> 0. =A0I need more information to decide.
>
> Your reply is requested by Friday, April 19^th or earlier.=
> ______________________________= _________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8fb1ebe48e961604da7d2379-- From jricher@mitre.org Tue Apr 16 09:56:02 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7221F970C for ; Tue, 16 Apr 2013 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHyJVr0Gp8HJ for ; Tue, 16 Apr 2013 09:56:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26421F970A for ; Tue, 16 Apr 2013 09:56:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 064171F04EB; Tue, 16 Apr 2013 12:56:00 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E42781F0349; Tue, 16 Apr 2013 12:55:59 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 16 Apr 2013 12:55:59 -0400 Message-ID: <516D8295.2030501@mitre.org> Date: Tue, 16 Apr 2013 12:55:49 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Barnes References: <51674E58.6000505@isoc.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010600090808020300000506" X-Originating-IP: [129.83.31.58] Cc: odonoghue@isoc.org, jose@ietf.org, Matt Miller Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:56:02 -0000 --------------010600090808020300000506 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I also like this approach. -- Justin On 04/16/2013 12:48 PM, Richard Barnes wrote: > That limitation seems very sensible to me. It would be a large > simplification over current JWE, with its abundance of key identifiers. > --Richard > > > On Tue, Apr 16, 2013 at 11:57 AM, Matt Miller > wrote: > > I have a slight preference for (2), assuming JWE retains the "kid" > parameter. I personally would rather limit key indication to a > JWK (and wrapping "x5c" in a JWK), or a reference to a JWK ("kid", > and maybe "jku"). > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue > wrote: > > > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 > suggests > removing the "x5c" header parameter from JWE, saying that no use > case for it has emerged. The same logic may apply to other key > specification parameters for JWE. > > > > > > Which of these best describes your preferences on this issue? > > > > 1. Retain the "x5c" header parameter in JWE. > > > > 2. Remove the "x5c" header parameter (and possibly other related > key specification parameters) from JWE. > > > > 3. Another resolution (please specify in detail). > > > > 0. I need more information to decide. > > > > Your reply is requested by Friday, April 19^th or earlier. > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------010600090808020300000506 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I also like this approach.

 -- Justin

On 04/16/2013 12:48 PM, Richard Barnes wrote:
That limitation seems very sensible to me.  It would be a large simplification over current JWE, with its abundance of key identifiers.
--Richard


On Tue, Apr 16, 2013 at 11:57 AM, Matt Miller <mamille2@cisco.com> wrote:
I have a slight preference for (2), assuming JWE retains the "kid" parameter.  I personally would rather limit key indication to a JWK (and wrapping "x5c" in a JWK), or a reference to a JWK ("kid", and maybe "jku").


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

> Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 <http://trac.tools.ietf.org/wg/jose/trac/ticket/12> suggests removing the "x5c" header parameter from JWE, saying that no use case for it has emerged.  The same logic may apply to other key specification parameters for JWE.
>
>
> Which of these best describes your preferences on this issue?
>
> 1.  Retain the "x5c" header parameter in JWE.
>
> 2. Remove the "x5c" header parameter (and possibly other related key specification parameters) from JWE.
>
> 3.  Another resolution (please specify in detail).
>
> 0.  I need more information to decide.
>
> Your reply is requested by Friday, April 19^th or earlier.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


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




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

--------------010600090808020300000506-- From rlb@ipv.sx Tue Apr 16 10:03:40 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF89B21F938E for ; Tue, 16 Apr 2013 10:03:39 -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=[AWL=-0.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqD2hnvA1e05 for ; Tue, 16 Apr 2013 10:03:39 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2421F8E9A for ; Tue, 16 Apr 2013 10:03:38 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wn14so656220obc.32 for ; Tue, 16 Apr 2013 10:03:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PUl2F41cL1dO3nXeU9qwHSXZVj0ypSdn4Iy6jggNB2E=; b=VMtmHbi+CUa/0TNkHKt6BBk+OyOzOsZAem04lwzF6hcOMnAFhsqaibYlgtUjNn+h7B LFUd5VsJwiRudSIv8HHTsxMz1X377WHLwn91ytlJrTQ063SVk8vujNaLIyqQfXtkGUxs p7n9J7VxA4uWeax6GlGa7+z5ovgtLQSwsbU/BLQk3soaHjyxM8nWvN5Ff1Smd823ohBn cHGvSGr86/e5WiSGdj+ksRILitcVhWy9y2M3GtMLT/mbuquK4LuDt6hB4LBK9Iysq8VQ TOVEOthH6PxwlI0Y5bGIfdxKh3zaqRk/l/r1WD5IFHw8+VYCTuuNIuredcBVvSEQXJGr GLyA== MIME-Version: 1.0 X-Received: by 10.60.34.98 with SMTP id y2mr1136108oei.74.1366131818394; Tue, 16 Apr 2013 10:03:38 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Tue, 16 Apr 2013 10:03:38 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <516D8295.2030501@mitre.org> References: <51674E58.6000505@isoc.org> <516D8295.2030501@mitre.org> Date: Tue, 16 Apr 2013 13:03:38 -0400 Message-ID: From: Richard Barnes To: Justin Richer Content-Type: multipart/alternative; boundary=089e01175d07c0898404da7d59a1 X-Gm-Message-State: ALoCoQlC7xhB4jswavEirD9cT2jHwOPJDPnVFu65SJrb5ahzNRv3rKQU7R8wD+AIPFhmatrK9o+b Cc: odonoghue@isoc.org, jose@ietf.org, Matt Miller Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 17:03:40 -0000 --089e01175d07c0898404da7d59a1 Content-Type: text/plain; charset=ISO-8859-1 So, just so we're clear on what we're talking about, the proposal would be something like the following? 1. Have one/two fields in JWE/JWS that can hold a reference a [JW]Key, namely "kid" and/or "jku" 2. Move the other key labeling fields under JWK, namely "x5u", "x5t", "x5c" 3. Keep the "jwk" field in JWE/JWS to contains the JWK, possibly with identifiers from (2) For that matter, I would be OK moving "kid" inside the JWE/JWS "jwk" parameter as well, and just having a "jwk" element at the top level. On Tue, Apr 16, 2013 at 12:55 PM, Justin Richer wrote: > I also like this approach. > > -- Justin > > > On 04/16/2013 12:48 PM, Richard Barnes wrote: > > That limitation seems very sensible to me. It would be a large > simplification over current JWE, with its abundance of key identifiers. > --Richard > > > On Tue, Apr 16, 2013 at 11:57 AM, Matt Miller wrote: > >> I have a slight preference for (2), assuming JWE retains the "kid" >> parameter. I personally would rather limit key indication to a JWK (and >> wrapping "x5c" in a JWK), or a reference to a JWK ("kid", and maybe "jku"). >> >> >> - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >> On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue wrote: >> >> > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 < >> http://trac.tools.ietf.org/wg/jose/trac/ticket/12> suggests removing the >> "x5c" header parameter from JWE, saying that no use case for it has >> emerged. The same logic may apply to other key specification parameters >> for JWE. >> > >> > >> > Which of these best describes your preferences on this issue? >> > >> > 1. Retain the "x5c" header parameter in JWE. >> > >> > 2. Remove the "x5c" header parameter (and possibly other related key >> specification parameters) from JWE. >> > >> > 3. Another resolution (please specify in detail). >> > >> > 0. I need more information to decide. >> > >> > Your reply is requested by Friday, April 19^th or earlier. >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > > > _______________________________________________ > jose mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose > > > --089e01175d07c0898404da7d59a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, just so we're clear on what we're talking about, the proposal w= ould be something like the following?

1. Have one/two fi= elds in JWE/JWS that can hold a reference a [JW]Key, namely "kid"= and/or "jku"
2. Move the other key labeling fields under JWK, namely "x5u"= ;, "x5t", "x5c"
3. Keep the "jwk" f= ield in JWE/JWS to contains the JWK, possibly with identifiers from (2)

For that matter, I would be OK moving "kid" i= nside the JWE/JWS "jwk" parameter as well, and just having a &quo= t;jwk" element at the top level.


On Tue, Apr 16, 2013 at 12:55 PM, Justin Richer <jricher@mitre.org>= wrote:
=20 =20 =20
I also like this approach.

=A0-- Justin


On 04/16/2013 12:48 PM, Richard Barnes wrote:
=20 That limitation seems very sensible to me. =A0It would be a large simplification over current JWE, with its abundance of key identifiers.
--Richard


On Tue, Apr 16, 2013 at 11:57 AM, Matt Miller <mamille2@cisco.com> wrote:
I have a slight preference for (2), assuming JWE retains the "kid&q= uot; parameter. =A0I personally would rather limit key indication to a JWK (and wrapping "x5c" in a JWK), or a referenc= e to a JWK ("kid", and maybe "jku").


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

> Issue #12 http://trac.tools.ietf.org/wg/jose/trac/tic= ket/12 <http://trac.tools.ietf.org/wg/jose/trac/ticket/12&= gt; suggests removing the "x5c" header parameter from JWE= , saying that no use case for it has emerged. =A0The same logic may apply to other key specification parameters for JWE.
>
>
> Which of these best describes your preferences on this issue?
>
> 1. =A0Retain the "x5c" header parameter in J= WE.
>
> 2. Remove the "x5c" header parameter (and po= ssibly other related key specification parameters) from JWE.
>
> 3. =A0Another resolution (please specify in detail). >
> 0. =A0I need more information to decide.
>
> Your reply is requested by Friday, April 19^th or earlier.
> _______________________________________________
> jose mailing list
> jos= e@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.or= g
https://www.ietf.org/mailman/listinfo/jose




_______________________________________________
jose mailing list
jose@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/jose


--089e01175d07c0898404da7d59a1-- From housley@vigilsec.com Tue Apr 16 10:46:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0021F9708 for ; Tue, 16 Apr 2013 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBIYrb7OLGH2 for ; Tue, 16 Apr 2013 10:46:29 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 76BCC21F96FA for ; Tue, 16 Apr 2013 10:46:29 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B789FF24077; Tue, 16 Apr 2013 13:46:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id YWpqfcOVh7fY; Tue, 16 Apr 2013 13:46:24 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7E3F5F24070; Tue, 16 Apr 2013 13:46:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-44--867353032 From: Russ Housley In-Reply-To: Date: Tue, 16 Apr 2013 13:46:27 -0400 Message-Id: <56FE5AD2-5A94-4548-B9C1-48A27EE5EA5D@vigilsec.com> References: <51674E3D.7030004@isoc.org> <71C65BBC-A7CB-4A5A-AE85-20650203F2FB@ve7jtb.com> To: jose@ietf.org X-Mailer: Apple Mail (2.1085) Cc: John Bradley Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 17:46:30 -0000 --Apple-Mail-44--867353032 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Other protocols use ICV (Integrity Check Value) to avoid this confusion. ICV also avoids the confusion with the many different interpretations of = MAC. Russ On Apr 16, 2013, at 10:24 AM, Richard Barnes wrote: > I'm confused. This is not about the IV =3D=3D Initialization Vector, = it's about the JWE Integrity Value (inconveniently also "IV"). I don't = think anyone has proposed merging in the initialization vector, both = because that's not what RFC 5116 does and because it's a terrible idea = :) >=20 >=20 > On Mon, Apr 15, 2013 at 2:41 PM, John Bradley = wrote: > 1 ish. >=20 > Representing the nonce/IV separately should not preclude using a = crypto library generated nonce/IV , as may be done in some libraries = implementing draft-mcgrew-aead-aes-cbc-hmac-sha2. >=20 > So I am in favour of the current serialization while wanting to = support the crypto from draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the = particular serialization which is optimized for a different use-case. = The current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and = serialization. I am hoping we can resolve that so the crypto can be = supported. >=20 > John B. >=20 > On 2013-04-11, at 8:58 PM, Karen O'Donoghue = wrote: >=20 >> Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes = restructuring the JWE representation to remove the JWE Integrity Value = field and instead use the RFC 5116 (AEAD) binary serialization to = represent the Ciphertext, Initialization Vector, and Integrity Value = values. If this proposal is adopted, JWEs would then have three fields = =96 the header, the encrypted key, and the RFC 5116 combination of the = Ciphertext, Initialization Vector, and Integrity Value values.=20 >> This issue is also related to issue #3. Note that the updated McGrew = draft described there could be used whether or not we switched to using = RFC 5116. >> =20 >>=20 >> Which of these best describes your preferences on this issue? >>=20 >> 1. Continue having separate Ciphertext, Initialization Vector, and = Integrity Value values in the JWE representation. >>=20 >> 2. Switch to using the RFC 5116 (AEAD) serialization to represent = the combination of these three values. >>=20 >> 3. Another resolution (please specify in detail). >>=20 >> 0. I need more information to decide. >>=20 >> =20 >> Your reply is requested by Friday, April 19th or earlier.=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-44--867353032 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Other = protocols use ICV (Integrity Check Value) to avoid this = confusion.

ICV also avoids the confusion with the = many different interpretations of = MAC.

Russ


= On Apr 16, 2013, at 10:24 AM, Richard Barnes wrote:

I'm = confused.  This is not about the IV =3D=3D Initialization Vector, = it's about the JWE Integrity Value (inconveniently also "IV").  I = don't think anyone has proposed merging in the initialization vector, = both because that's not what RFC 5116 does and because it's a terrible = idea :)


On Mon, Apr 15, 2013 at 2:41 PM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
1 = ish.

Representing the nonce/IV separately should not = preclude using a crypto library generated nonce/IV , as may be done in = some libraries implementing  draft-mcgrew-aead-aes-cbc-hmac-sha2.

So I am in favour of = the current serialization while wanting to support the crypto = from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the = particular serialization which is optimized for = a different use-case.   The = current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto = and serialization.  I am hoping we can resolve that so the crypto = can be supported.

John B.

On 2013-04-11, at 8:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

=20 =20 =20
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then = have three fields =96 the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC = 5116.
 

Which of these best describes your preferences on this = issue?

1.  = Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2. = Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three = values.

3.  Another resolution (please specify in = detail).

0.  I = need more information to = decide.

 
Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
=


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


_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose

= --Apple-Mail-44--867353032-- From charles.marais@orange.com Wed Apr 17 05:38:56 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A921F8D8D for ; Wed, 17 Apr 2013 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+21FiEplolq for ; Wed, 17 Apr 2013 05:38:56 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id B332721F8DC1 for ; Wed, 17 Apr 2013 05:38:55 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D8F7BFC48CB for ; Wed, 17 Apr 2013 14:38:54 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id D1B9EFC48C9 for ; Wed, 17 Apr 2013 14:38:54 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:38:54 +0200 Received: from [10.193.13.83] ([10.193.13.83]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:38:54 +0200 Message-ID: <516E97DE.3050507@orange.com> Date: Wed, 17 Apr 2013 14:38:54 +0200 From: "charles.marais@orange.com" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org References: <51674E63.3050809@isoc.org> In-Reply-To: <51674E63.3050809@isoc.org> Content-Type: multipart/related; boundary="------------000905070101010301090109" X-OriginalArrivalTime: 17 Apr 2013 12:38:54.0780 (UTC) FILETIME=[85CD87C0:01CE3B68] Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:38:57 -0000 This is a multi-part message in MIME format. --------------000905070101010301090109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 1.Yes, Use cases where key information is exchanged by means other than JWS and JWE headers are important.

Charles Marais.
Le 12/04/2013 01:59, Karen O'Donoghue a écrit :
Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a “kid” field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this issue?

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th (or earlier). 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France



--------------000905070101010301090109 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="orange_logo.gif" R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------000905070101010301090109 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ampersand.gif" R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------000905070101010301090109-- From charles.marais@orange.com Wed Apr 17 05:40:07 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725D121F8D8D for ; Wed, 17 Apr 2013 05:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7vgTRDLlCVi for ; Wed, 17 Apr 2013 05:40:06 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 624AE21F8D86 for ; Wed, 17 Apr 2013 05:40:06 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C28BFFC495A for ; Wed, 17 Apr 2013 14:40:05 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id B73E5FC4945 for ; Wed, 17 Apr 2013 14:40:05 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:40:06 +0200 Received: from [10.193.13.83] ([10.193.13.83]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:40:05 +0200 Message-ID: <516E9824.9020508@orange.com> Date: Wed, 17 Apr 2013 14:40:04 +0200 From: "charles.marais@orange.com" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org References: <51674E58.6000505@isoc.org> In-Reply-To: <51674E58.6000505@isoc.org> Content-Type: multipart/related; boundary="------------070809030000090509050001" X-OriginalArrivalTime: 17 Apr 2013 12:40:05.0520 (UTC) FILETIME=[AFF79900:01CE3B68] Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:40:07 -0000 This is a multi-part message in MIME format. --------------070809030000090509050001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

1. Retain the “x5c” header parameter in JWE.

Br,

Charles Marais.
Le 12/04/2013 01:59, Karen O'Donoghue a écrit :
Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the “x5c” header parameter from JWE, saying that no use case for it has emerged.  The same logic may apply to other key specification parameters for JWE.


Which of these best describes your preferences on this issue?

1.  Retain the “x5c” header parameter in JWE.

2.  Remove the “x5c” header parameter (and possibly other related key specification parameters) from JWE.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier. 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France



--------------070809030000090509050001 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="orange_logo.gif" R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------070809030000090509050001 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ampersand.gif" R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------070809030000090509050001-- From charles.marais@orange.com Wed Apr 17 05:41:03 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101A721F8DC1 for ; Wed, 17 Apr 2013 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwulR-LMfOSj for ; Wed, 17 Apr 2013 05:41:01 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94221F8D8D for ; Wed, 17 Apr 2013 05:41:01 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 689141074DDD for ; Wed, 17 Apr 2013 14:47:20 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6186F1074CC5 for ; Wed, 17 Apr 2013 14:47:20 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:40:59 +0200 Received: from [10.193.13.83] ([10.193.13.83]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:40:59 +0200 Message-ID: <516E985B.3050903@orange.com> Date: Wed, 17 Apr 2013 14:40:59 +0200 From: "charles.marais@orange.com" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org References: <51674E3D.7030004@isoc.org> In-Reply-To: <51674E3D.7030004@isoc.org> Content-Type: multipart/related; boundary="------------060907020703080102000905" X-OriginalArrivalTime: 17 Apr 2013 12:40:59.0776 (UTC) FILETIME=[D04E6800:01CE3B68] Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:41:03 -0000 This is a multi-part message in MIME format. --------------060907020703080102000905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

Br,

Charles Marais.

Le 12/04/2013 01:58, Karen O'Donoghue a écrit :
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have three fields – the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
 

Which of these best describes your preferences on this issue?

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.  Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier. 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France



--------------060907020703080102000905 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="orange_logo.gif" R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------060907020703080102000905 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ampersand.gif" R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------060907020703080102000905-- From charles.marais@orange.com Wed Apr 17 05:41:51 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7621F8DC1 for ; Wed, 17 Apr 2013 05:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0fphEe4kDOg for ; Wed, 17 Apr 2013 05:41:49 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C521F8D8D for ; Wed, 17 Apr 2013 05:41:49 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0FE1CDE57A7 for ; Wed, 17 Apr 2013 14:43:31 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0595ADE57AE for ; Wed, 17 Apr 2013 14:43:31 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:41:48 +0200 Received: from [10.193.13.83] ([10.193.13.83]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:41:47 +0200 Message-ID: <516E988B.2050304@orange.com> Date: Wed, 17 Apr 2013 14:41:47 +0200 From: "charles.marais@orange.com" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org References: <51674E2D.3040604@isoc.org> In-Reply-To: <51674E2D.3040604@isoc.org> Content-Type: multipart/related; boundary="------------050900030308060003050202" X-OriginalArrivalTime: 17 Apr 2013 12:41:47.0976 (UTC) FILETIME=[ED092480:01CE3B68] Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:41:51 -0000 This is a multi-part message in MIME format. --------------050900030308060003050202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.

Br,

Charles Marais.

Le 12/04/2013 01:58, Karen O'Donoghue a écrit :
Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an “spi” (security parameters index) header parameter to the JWS and JWE specifications.  This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.  This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.

 

Which of these best describes your preferences on this issue?

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.

2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature.

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier. 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France



--------------050900030308060003050202 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="orange_logo.gif" R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------050900030308060003050202 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ampersand.gif" R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------050900030308060003050202-- From charles.marais@orange.com Wed Apr 17 05:43:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05921E8055 for ; Wed, 17 Apr 2013 05:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x24jrKeBkoHt for ; Wed, 17 Apr 2013 05:43:08 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id E23B721E8054 for ; Wed, 17 Apr 2013 05:43:07 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 34ABEFC4984 for ; Wed, 17 Apr 2013 14:43:07 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 2D818FC497C for ; Wed, 17 Apr 2013 14:43:07 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:43:06 +0200 Received: from [10.193.13.83] ([10.193.13.83]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 14:43:06 +0200 Message-ID: <516E98DA.3030104@orange.com> Date: Wed, 17 Apr 2013 14:43:06 +0200 From: "charles.marais@orange.com" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: jose@ietf.org References: <51674E17.5020902@isoc.org> In-Reply-To: <51674E17.5020902@isoc.org> Content-Type: multipart/related; boundary="------------080401090807030808080600" X-OriginalArrivalTime: 17 Apr 2013 12:43:06.0852 (UTC) FILETIME=[1C0CAA40:01CE3B69] Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:43:09 -0000 This is a multi-part message in MIME format. --------------080401090807030808080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

1.  Continue have the JWA algorithm identifiers be strings, and not objects.  Note that WebCrypto may choose to use some of these same strings, where applicable.

Br,

Charles Marais.
Le 12/04/2013 01:58, Karen O'Donoghue a écrit :
Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.  The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.


Which of these best describes your preferences on this issue?

1.  Continue have the JWA algorithm identifiers be strings, and not objects.  Note that WebCrypto may choose to use some of these same strings, where applicable.

2.  Switch to using the algorithm identifier structures defined in the WebCrypto draft.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier. 





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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France



--------------080401090807030808080600 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="orange_logo.gif" R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------080401090807030808080600 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ampersand.gif" R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------080401090807030808080600-- From spreibisch@layer7tech.com Wed Apr 17 09:01:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8D121F86D5 for ; Wed, 17 Apr 2013 09:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK8aAD8vqxfV for ; Wed, 17 Apr 2013 09:01:03 -0700 (PDT) Received: from smtp126.dfw.emailsrvr.com (smtp126.dfw.emailsrvr.com [67.192.241.126]) by ietfa.amsl.com (Postfix) with ESMTP id B947621F86D2 for ; Wed, 17 Apr 2013 09:01:03 -0700 (PDT) Received: from smtp12.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 198283C03A5 for ; Wed, 17 Apr 2013 12:01:03 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox 2.7.4 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 052263C03B5 for ; Wed, 17 Apr 2013 12:01:03 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex07a.mlsrvr.com (unknown [67.192.133.128]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id D74FD3C03A5 for ; Wed, 17 Apr 2013 12:01:02 -0400 (EDT) Received: from DFW1MBX21.mex07a.mlsrvr.com ([192.168.1.235]) by DFW1HUB09.mex07a.mlsrvr.com ([fe80::222:19ff:fe91:f83a%11]) with mapi; Wed, 17 Apr 2013 11:01:02 -0500 From: Sascha Preibisch To: "jose@ietf.org" Date: Wed, 17 Apr 2013 11:01:02 -0500 Thread-Topic: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory Thread-Index: Ac43EJ4jOlR90PnMQKa8jB7FjMoH0QEdBwng Message-ID: <260FAD4C9002884C89DF49EF8776EB9B2A9811506E@DFW1MBX21.mex07a.mlsrvr.com> References: <51674E63.3050809@isoc.org> In-Reply-To: <51674E63.3050809@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_260FAD4C9002884C89DF49EF8776EB9B2A9811506EDFW1MBX21mex0_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:01:04 -0000 --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811506EDFW1MBX21mex0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 5:00 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #15: Should at least= on key indicator be mandatory Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requi= ring that a key indicator, such as a "kid" field, be required in all JWS an= d JWE headers. Are use cases where key information is exchanged by means ot= her than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19th (or earlier). --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811506EDFW1MBX21mex0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= 1

 =

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind= owtext'> jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PMTo: jose@ietf.org
Subject: [jose] Feedback request on jos= e tracker issue #15: Should at least on key indicator be mandatory

 

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests r= equiring that a key indicator, such as a “kid” field, be requir= ed in all JWS and JWE headers. Are use cases where key information is excha= nged by means other than the JWS or JWE headers important?

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Which of these best describes your preferences on this issue?

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by F= riday, April 19th (or earlier).

= --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811506EDFW1MBX21mex0_-- From ve7jtb@ve7jtb.com Wed Apr 17 11:29:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2666621E8048 for ; Wed, 17 Apr 2013 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7qKkcyA3q7V for ; Wed, 17 Apr 2013 11:29:34 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBC721E8042 for ; Wed, 17 Apr 2013 11:29:33 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so1072895qen.37 for ; Wed, 17 Apr 2013 11:29:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ftulnL1A8TjoFi9QyQL6imz6wyijF2gnbrSjC5IlU5Q=; b=l5Ap0gOm6uLjicgNbuXonOpkANcANR//86h0/imnSu6RlewHsQ0b7Qzg1290Ed721W 5YMEydf+K7+xZJiMNrEy22Qb4L1spe9ibpBon0Py4IIb3YQVMGv01XcCU4z6GB3bW8+T iF52keUgE/rQ+vlCW1MGk6tCIdccKNfvJaE5wTiOyDy9GK1YF0afZQZQAsjYLzDKha+l 3fbNzi2Csxvu0KJiodw/5rypfDVRqSCtZjpDMVX3qM3IL5nxy6dZhUO1utP5fS1RhMsH zr+BWekEKGb2XUADa6/Hcvu8Gy7A/GqNzR/creRZr0CzhPQyQc4ZNqfY50+dvkjq5B8X 237Q== X-Received: by 10.224.51.18 with SMTP id b18mr7721390qag.50.1366223373002; Wed, 17 Apr 2013 11:29:33 -0700 (PDT) Received: from [192.168.1.39] (190-20-57-18.baf.movistar.cl. [190.20.57.18]) by mx.google.com with ESMTPS id bv6sm8533256qab.5.2013.04.17.11.29.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 11:29:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_878466EC-BDF2-4170-BAFE-DD383C0BD54E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Wed, 17 Apr 2013 15:29:15 -0300 Message-Id: References: <51674E3D.7030004@isoc.org> <71C65BBC-A7CB-4A5A-AE85-20650203F2FB@ve7jtb.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmeczcbheQm9ckJphlaWokkxSxCrP8nD/0gHxE/+n7ws07eYWjdYTpoydsHjFc6JeT0DTgL Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:29:35 -0000 --Apple-Mail=_878466EC-BDF2-4170-BAFE-DD383C0BD54E Content-Type: multipart/alternative; boundary="Apple-Mail=_8EBD5C7F-CA50-4D12-9BFF-C0AF6419311D" --Apple-Mail=_8EBD5C7F-CA50-4D12-9BFF-C0AF6419311D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Richard, I don't understand your comment about merging the IV.=20 To be clear I am asking to keep the current serialization with separate = elements for Ciphertext, Initialization Vector, and Integrity Value. I think there is some confusion around a subtle difference between RFC = 5116 and draft-mcgrew-aead-aes-cbc-hmac-sha2.(Or perhaps it is just me:) RFC 5116 has a nonce as a separate input and output I am fine with that, = however it also implicitly assumes that T (Tag) is a fixed length value = concatenated to the end of the cypher-text. I am opposed to binary = concatenation of the values. draft-mcgrew goes a step further than RFC 5116 where it basically fakes = out the RFC 5116 interface by specifying the use of a zero length nonce = (Sec 2.1) It then creates a random IV that is included as a prefix to = the cypher-text (Sec 2.1-4 & 2.2-4). By listing the IV as one of the elements that would be affected by the = change some people may be thinking that the poll question also includes = changing the serialization of the IV. I am however OK with having the underlying library produce the IV as = long as it provides that as an output to JWE. As a matter of principal I prefer separating the crypto from the = serialization. Perhaps I am over thinking the question and my answer is 1. John B. On 2013-04-16, at 11:24 AM, Richard Barnes wrote: > I'm confused. This is not about the IV =3D=3D Initialization Vector, = it's about the JWE Integrity Value (inconveniently also "IV"). I don't = think anyone has proposed merging in the initialization vector, both = because that's not what RFC 5116 does and because it's a terrible idea = :) >=20 >=20 > On Mon, Apr 15, 2013 at 2:41 PM, John Bradley = wrote: > 1 ish. >=20 > Representing the nonce/IV separately should not preclude using a = crypto library generated nonce/IV , as may be done in some libraries = implementing draft-mcgrew-aead-aes-cbc-hmac-sha2. >=20 > So I am in favour of the current serialization while wanting to = support the crypto from draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the = particular serialization which is optimized for a different use-case. = The current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and = serialization. I am hoping we can resolve that so the crypto can be = supported. >=20 > John B. >=20 > On 2013-04-11, at 8:58 PM, Karen O'Donoghue = wrote: >=20 >> Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes = restructuring the JWE representation to remove the JWE Integrity Value = field and instead use the RFC 5116 (AEAD) binary serialization to = represent the Ciphertext, Initialization Vector, and Integrity Value = values. If this proposal is adopted, JWEs would then have three fields = =96 the header, the encrypted key, and the RFC 5116 combination of the = Ciphertext, Initialization Vector, and Integrity Value values.=20 >> This issue is also related to issue #3. Note that the updated McGrew = draft described there could be used whether or not we switched to using = RFC 5116. >> =20 >>=20 >> Which of these best describes your preferences on this issue? >>=20 >> 1. Continue having separate Ciphertext, Initialization Vector, and = Integrity Value values in the JWE representation. >>=20 >> 2. Switch to using the RFC 5116 (AEAD) serialization to represent = the combination of these three values. >>=20 >> 3. Another resolution (please specify in detail). >>=20 >> 0. I need more information to decide. >>=20 >> =20 >> Your reply is requested by Friday, April 19th or earlier.=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 --Apple-Mail=_8EBD5C7F-CA50-4D12-9BFF-C0AF6419311D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 RFC = 5116 and dr= aft-mcgrew-aead-aes-cbc-hmac-sha2.(Or perhaps it is just = me:)
RFC 5116 has a nonce as a separate input and = output I am = fine with that, however it also implicitly assumes that T (Tag) is a = fixed length value concatenated to the end of = the cypher-text.   I am opposed = to binary concatenation of the = values.

draft-mcgrew goes a step further = than  RFC 5116 where it basically fakes out the RFC 5116 interface = by specifying the use of a zero length nonce (Sec 2.1)  It then = creates a random IV  that is included as a prefix to the = cypher-text (Sec 2.1-4 & 2.2-4).

By listing = the IV as one of the elements that would be affected by the change some = people may be thinking that the poll question also includes changing the = serialization of the IV.

I am however OK with = having the underlying library produce the IV as long as it provides that = as an output to JWE.

As a matter of principal I = prefer separating the crypto from the = serialization.

Perhaps I am over thinking the = question and my answer is 1.

John = B.

On 2013-04-16, at 11:24 AM, Richard Barnes = <rlb@ipv.sx> wrote:

I'm = confused.  This is not about the IV =3D=3D Initialization Vector, = it's about the JWE Integrity Value (inconveniently also "IV").  I = don't think anyone has proposed merging in the initialization vector, = both because that's not what RFC 5116 does and because it's a terrible = idea :)


On Mon, Apr 15, 2013 at 2:41 PM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
1 = ish.

Representing the nonce/IV separately should not = preclude using a crypto library generated nonce/IV , as may be done in = some libraries implementing  draft-mcgrew-aead-aes-cbc-hmac-sha2.

So I am in favour of = the current serialization while wanting to support the crypto = from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the = particular serialization which is optimized for = a different use-case.   The = current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto = and serialization.  I am hoping we can resolve that so the crypto = can be supported.

John B.

On 2013-04-11, at 8:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

=20 =20 =20
Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then = have three fields =96 the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC = 5116.
 

Which of these best describes your preferences on this = issue?

1.  = Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2. = Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three = values.

3.  Another resolution (please specify in = detail).

0.  I = need more information to = decide.

 
Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
=


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



= --Apple-Mail=_8EBD5C7F-CA50-4D12-9BFF-C0AF6419311D-- --Apple-Mail=_878466EC-BDF2-4170-BAFE-DD383C0BD54E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE3MTgyOTE1WjAjBgkqhkiG9w0BCQQxFgQUUUoAvKmE 1dY48FENohcau7J26UgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAO9gwdxnJFzm6M7I9sfIrFK/0AD/XeUVr9PxID4Sl 9T56Jchd9heJA9UxP99ZBTW1TGl/DEKxPMjhaQenYD6gCnv8LGUbBdFe3NZautw19IWNGzOMKBIq +iknXHtmRPlZB3tOQjZbJaKe89hYzt5UapMUMUBt9fnbCI1lvqfIASK04648IJwGAmSLRJAxQdEE wP+5Jhd9IGhLoy4sDBF7384LKcq5lCKDk6tbArOY9+RNPDzMyt4jW68p0wODCKuW62rKaeVPMNkn MTpso9JpqxCOS67G/tYCBf8/zoVQ8cJ0pKI4HQttViyLXdmw0Y1eIgQzmvNcUH++oF3GbR1tpQAA AAAAAA== --Apple-Mail=_878466EC-BDF2-4170-BAFE-DD383C0BD54E-- From spreibisch@layer7tech.com Wed Apr 17 12:02:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304CB21F8CEE for ; Wed, 17 Apr 2013 12:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1QBdZLgYc6t for ; Wed, 17 Apr 2013 12:02:09 -0700 (PDT) Received: from smtp186.dfw.emailsrvr.com (smtp186.dfw.emailsrvr.com [67.192.241.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2175D21F8C9B for ; Wed, 17 Apr 2013 12:02:09 -0700 (PDT) Received: from smtp18.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 949D52682D9 for ; Wed, 17 Apr 2013 15:02:08 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox 2.7.4 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 91C392682D0 for ; Wed, 17 Apr 2013 15:02:08 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex07a.mlsrvr.com (unknown [67.192.133.128]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id 7CD6B26818C for ; Wed, 17 Apr 2013 15:02:08 -0400 (EDT) Received: from DFW1MBX21.mex07a.mlsrvr.com ([192.168.1.235]) by DFW1HUB05.mex07a.mlsrvr.com ([fe80::222:19ff:fe23:70dc%13]) with mapi; Wed, 17 Apr 2013 14:02:08 -0500 From: Sascha Preibisch To: "jose@ietf.org" Date: Wed, 17 Apr 2013 14:02:09 -0500 Thread-Topic: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto Thread-Index: Ac43EHB9puirB5rqQLWRbnTwlof5UwEjXDSg Message-ID: <260FAD4C9002884C89DF49EF8776EB9B2A9811513B@DFW1MBX21.mex07a.mlsrvr.com> References: <51674E17.5020902@isoc.org> In-Reply-To: <51674E17.5020902@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513BDFW1MBX21mex0_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 19:02:10 -0000 --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513BDFW1MBX21mex0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Continue have the JWA algorithm identifiers be strings, and not objects= . From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 4:58 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #7: Algorithm identi= fiers/parameters incompatible with WebCrypto Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that t= he JWA algorithm identifiers are different than those used by the W3C WebCr= ypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm identi= fiers are strings, whereas the W3C WebCrypto algorithm identifiers are stru= ctures including string identifiers. The working group had previously deci= ded to continue representing JOSE algorithms as strings, as recorded at htt= p://www.ietf.org/mail-archive/web/jose/current/msg01219.html. Which of these best describes your preferences on this issue? 1. Continue have the JWA algorithm identifiers be strings, and not objects= . Note that WebCrypto may choose to use some of these same strings, where = applicable. 2. Switch to using the algorithm identifier structures defined in the WebC= rypto draft. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513BDFW1MBX21mex0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= 1.  Continue have the JWA algorithm identifiers be strin= gs, and not objects.

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf= .org] On Behalf Of Karen O'Donoghue
Sent: Thursday, April = 11, 2013 4:58 PM
To: jose@ietf.org
Subject: [jose] Feed= back request on jose tracker issue #7: Algorithm identifiers/parameters inc= ompatible with WebCrypto

 

Issue #7 http://trac.tools.ietf.org/wg/jose= /trac/ticket/7 points out that the JWA algorithm identifiers are differ= ent than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA= algorithm identifiers are strings, whereas the W3C WebCrypto algorithm ide= ntifiers are structures including string identifiers.  The working gro= up had previously decided to continue representing JOSE algorithms as strin= gs, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01= 219.html.


Which of these best describe= s your preferences on this issue?

1.  Continue h= ave the JWA algorithm identifiers be strings, and not objects.  Note t= hat WebCrypto may choose to use some of these same strings, where applicabl= e.

2.  Switch to using the algorithm identifier s= tructures defined in the WebCrypto draft.

3.  Ano= ther resolution (please specify in detail).

0.  I= need more information to decide.

Your reply is reque= sted by Friday, April 19th or earlier.

&n= bsp;

= --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513BDFW1MBX21mex0_-- From spreibisch@layer7tech.com Wed Apr 17 12:03:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6834C21F89D8 for ; Wed, 17 Apr 2013 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjNg11hj4sDn for ; Wed, 17 Apr 2013 12:03:12 -0700 (PDT) Received: from smtp156.dfw.emailsrvr.com (smtp156.dfw.emailsrvr.com [67.192.241.156]) by ietfa.amsl.com (Postfix) with ESMTP id CE98321F89AF for ; Wed, 17 Apr 2013 12:03:11 -0700 (PDT) Received: from smtp5.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B4D0E583D5 for ; Wed, 17 Apr 2013 15:03:10 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox 2.7.4 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 70295583E5 for ; Wed, 17 Apr 2013 15:03:10 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex07a.mlsrvr.com (unknown [67.192.133.128]) by smtp5.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id A2977583E3 for ; Wed, 17 Apr 2013 15:03:07 -0400 (EDT) Received: from DFW1MBX21.mex07a.mlsrvr.com ([192.168.1.235]) by DFW1HUB09.mex07a.mlsrvr.com ([fe80::222:19ff:fe91:f83a%11]) with mapi; Wed, 17 Apr 2013 14:03:07 -0500 From: Sascha Preibisch To: "jose@ietf.org" Date: Wed, 17 Apr 2013 14:03:08 -0500 Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: Ac43EH3ej2pBU0sqSayKI+vKv2l/xQEjaVew Message-ID: <260FAD4C9002884C89DF49EF8776EB9B2A9811513C@DFW1MBX21.mex07a.mlsrvr.com> References: <51674E2D.3040604@isoc.org> In-Reply-To: <51674E2D.3040604@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513CDFW1MBX21mex0_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 19:03:16 -0000 --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513CDFW1MBX21mex0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1 - It causes no problems to have spi remain in a separate spec as an optio= nal feature From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 4:59 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #8: Should we add a = "spi" header field? Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding a= n "spi" (security parameters index) header parameter to the JWS and JWE spe= cifications. This modification to the JOSE formats would allow for signali= ng that pre-negotiated cryptographic parameters are being used, rather than= including those parameters in the JWS or JWE header. This proposal has be= en written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513CDFW1MBX21mex0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= 1 - It causes no problems to have spi remain in a separate spec as a= n optional feature

&n= bsp;

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 = 4:59 PM
To: jose@ietf.org
Subject: [jose] Feedback requ= est on jose tracker issue #8: Should we add a "spi" header field?=

 

Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 propo= ses adding an “spi” (security parameters index) header paramete= r to the JWS and JWE specifications.  This modification to the JOSE fo= rmats would allow for signaling that pre-negotiated cryptographic parameter= s are being used, rather than including those parameters in the JWS or JWE = header.  This proposal has been written up as http://tools.ietf.org/html/draft-ba= rnes-jose-spi-00.

 

W= hich of these best describes your preferences on this issue?

=

1.  Have draft-barnes-jose-spi remain a separate specification = that could optionally also be supported by JWS and JWE implementations.

2.  Incorporate draft-barnes-jose-spi into the JWS a= nd JWE specifications as a mandatory feature.

3. = Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a= n optional feature.

4.  Another resolution (pleas= e specify in detail).

0.  I need more information= to decide.

Your reply is requested by F= riday, April 19th or earlier.

= --_000_260FAD4C9002884C89DF49EF8776EB9B2A9811513CDFW1MBX21mex0_-- From ve7jtb@ve7jtb.com Wed Apr 17 12:08:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B992121E804D for ; Wed, 17 Apr 2013 12:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhu3fdNcUEXE for ; Wed, 17 Apr 2013 12:08:48 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id E618721F8576 for ; Wed, 17 Apr 2013 12:08:47 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 6so1101229qeb.22 for ; Wed, 17 Apr 2013 12:08:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=I0ca2kO/Cc65AFRzkuEMu3SVy9D/OmKsmZBorNREu+8=; b=X6EZUH49z8P9PnSucgpYwHPIgmyTEMhQLIgfkTYICEcC39layGFaXQGsDbP4OXfNTP +fRQ+nMsyXaWCjF+D/0z9foMM/oUUHSUH7fnDQHgRNKTgje+TK+DFstyM1sh3a2X8QOe AEA1I4h1dULZQ8KUJDtsCtgjceUo0ziToZ2/BSSRq+/VwVSay61nMHEw3y+cobte8x7n RZ6HEmfCwRQl7/W0fT5m4c74GpQ/qVtkZ3+tcQFljPKbktVK1vkxtIXeD0Hfywh5vD6a lY6J5hjKqioNrxMYpqPWcpw5WwEc17OGcLSgNNgWH3HzoACqDoYTI4LsOjQDSn4nddHy m2jg== X-Received: by 10.229.102.101 with SMTP id f37mr2812873qco.112.1366225727315; Wed, 17 Apr 2013 12:08:47 -0700 (PDT) Received: from [192.168.1.39] (190-20-57-18.baf.movistar.cl. [190.20.57.18]) by mx.google.com with ESMTPS id bv6sm8737907qab.5.2013.04.17.12.08.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 12:08:46 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_96A7138C-5F44-4A5B-9CA5-5E5CC5A5D444"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51674E17.5020902@isoc.org> Date: Wed, 17 Apr 2013 16:08:23 -0300 Message-Id: <6B4B79AC-8D10-40EE-B7F7-F159CD9B5B0E@ve7jtb.com> References: <51674E17.5020902@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQm8UO4QJYh3QI0B0OZC8FKdCNmQpvjo4eGKeZjS3xTHIL2uXQomCpjiY0nnL1DhK9jdEDT8 Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 19:08:48 -0000 --Apple-Mail=_96A7138C-5F44-4A5B-9CA5-5E5CC5A5D444 Content-Type: multipart/alternative; boundary="Apple-Mail=_1841ECAE-B460-4606-980D-A8D20FC37B0F" --Apple-Mail=_1841ECAE-B460-4606-980D-A8D20FC37B0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 1 While Web crypto may want flexibility on mixing and matching parameters, = it is safer to have JOSE users pick from a predefined set defined by a = string. While I understand the flexibility argument, it also allows encourages = people to do potentially unsafe things. If they need a new combination then they can register a new string and = that will at least have some oversight. John B. On 2013-04-11, at 8:58 PM, Karen O'Donoghue wrote: > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out = that the JWA algorithm identifiers are different than those used by the = W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA = algorithm identifiers are strings, whereas the W3C WebCrypto algorithm = identifiers are structures including string identifiers. The working = group had previously decided to continue representing JOSE algorithms as = strings, as recorded at = http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Continue have the JWA algorithm identifiers be strings, and not = objects. Note that WebCrypto may choose to use some of these same = strings, where applicable. >=20 > 2. Switch to using the algorithm identifier structures defined in the = WebCrypto draft. >=20 > 3. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_1841ECAE-B460-4606-980D-A8D20FC37B0F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 1

While Web crypto may want flexibility on mixing and matching parameters, it is safer to have JOSE users pick from a predefined set defined by a string.
While I understand the flexibility argument,  it also allows encourages people to do potentially unsafe things.

If they need a new combination then they can register a new string and that will at least have some oversight.

John B.


On 2013-04-11, at 8:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out that the JWA algorithm identifiers are different than those used by the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA algorithm identifiers are strings, whereas the W3C WebCrypto algorithm identifiers are structures including string identifiers.  The working group had previously decided to continue representing JOSE algorithms as strings, as recorded at http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.


Which of these best describes your preferences on this issue?

1.  Continue have the JWA algorithm identifiers be strings, and not objects.  Note that WebCrypto may choose to use some of these same strings, where applicable.

2.  Switch to using the algorithm identifier structures defined in the WebCrypto draft.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.



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

--Apple-Mail=_1841ECAE-B460-4606-980D-A8D20FC37B0F-- --Apple-Mail=_96A7138C-5F44-4A5B-9CA5-5E5CC5A5D444 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE3MTkwODI0WjAjBgkqhkiG9w0BCQQxFgQURy6JPbS3 ObMjdHYsb7f5UrFCTEQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAoA9bmEDK6ATs/7AXhA4S1vjqW8cvtPpgVuzJ/ZVH JjZ9+o2SYNZrp6OwMQrkKdc8SnszuBRz/yeQamG7Ic2TMVQGg4p+LceQdGjsVdnfPxhHrG/1P8hk /4sUEPYKGUDnSCM74wD+abvYEaceRI6zuaZP7MGrEjeTbxfTJFWhyk/0dr/TpCoIE79/AcZMCrB9 NV7Wmk6hklOASyZfzwRLoapSu8It+gu2LCGHpGVC0A98eAuPCFGSkFuyZiAvyataXsgVyt5GBKjv xMB4e5yKtMq77ThU2Jrlkf9Sd3p2gaofAxY5UmGPTmkaDhT7qOoEuG+SJ3L56UItkZ4qeg/3EgAA AAAAAA== --Apple-Mail=_96A7138C-5F44-4A5B-9CA5-5E5CC5A5D444-- From ve7jtb@ve7jtb.com Wed Apr 17 13:44:18 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7852721F86CA for ; Wed, 17 Apr 2013 13:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5UUBHcPkUfH for ; Wed, 17 Apr 2013 13:44:17 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9B621F86DE for ; Wed, 17 Apr 2013 13:44:07 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id p6so1131495qad.12 for ; Wed, 17 Apr 2013 13:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=JJcr+S9LZznQvNSnD7DfwR0suNUyGXTvVTLx1pJUVvw=; b=A6V2ugWZRBO9v0u9kZmn3P8dqxcf1yYcv0X5zbzN9m/vt3LLbjs9vnQ4vMFaBGQcvR kNNBj4rSpXOFlUzAd8NPR77pCwhtKk1P9e27l5JlS56upnpIAEbnV7otetVZYzg1OtG6 d7n4C2Os9+W+8Pp5vC1ALHqkNtGRFtaj3lLKn7HJImOzLjqz0wvjxa5ky5WeIm2+hXOu FkCYUqnJMttYD5WT9+ZpUaEyub11dMuDOWRb8aPr0mAwjZu+iYLvkIdzFrtAqOVTY8Wt qB5Uf73Lw1LENA9zDBQLYsrYzq72nIdNWUNJGTDSjk0S4u9IWsEWxbc7xtYrKnNxK8h8 470g== X-Received: by 10.224.17.2 with SMTP id q2mr2497809qaa.59.1366231447317; Wed, 17 Apr 2013 13:44:07 -0700 (PDT) Received: from [192.168.1.39] (190-20-57-18.baf.movistar.cl. [190.20.57.18]) by mx.google.com with ESMTPS id k8sm9345077qej.2.2013.04.17.13.44.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 13:44:06 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FD077C09-505D-4277-9A41-30A68FA10E9C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51674E2D.3040604@isoc.org> Date: Wed, 17 Apr 2013 17:43:56 -0300 Message-Id: <454CF566-07DE-4B80-8324-2C08422D3A87@ve7jtb.com> References: <51674E2D.3040604@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQm5PoT2Dqq8cT4MnCQOm8zdQdtrtaDpllvPRee2qGk1bMmaDJ3o2JvI4ayxFBZRwwR/oeOd Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 20:44:18 -0000 --Apple-Mail=_FD077C09-505D-4277-9A41-30A68FA10E9C Content-Type: multipart/alternative; boundary="Apple-Mail=_83FF7140-83BB-4D08-B248-C866255DF8F4" --Apple-Mail=_83FF7140-83BB-4D08-B248-C866255DF8F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1 I think this needs more work and time before trying to move it into the = base spec. On 2013-04-11, at 8:58 PM, Karen O'Donoghue wrote: > Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes = adding an =93spi=94 (security parameters index) header parameter to the = JWS and JWE specifications. This modification to the JOSE formats would = allow for signaling that pre-negotiated cryptographic parameters are = being used, rather than including those parameters in the JWS or JWE = header. This proposal has been written up as = http://tools.ietf.org/html/draft-barnes-jose-spi-00. > =20 >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Have draft-barnes-jose-spi remain a separate specification that = could optionally also be supported by JWS and JWE implementations. >=20 > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as a mandatory feature. >=20 > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as an optional feature. >=20 > 4. Another resolution (please specify in detail). >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19th or earlier.=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_83FF7140-83BB-4D08-B248-C866255DF8F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 odonoghue@isoc.org> = wrote:
=20 =20
Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an =93spi=94 (security parameters index) header parameter to = the JWS and JWE specifications.  This modification to the JOSE = formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.  This proposal has been written up as http://tools.= ietf.org/html/draft-barnes-jose-spi-00.

 

Which of these best describes your preferences on this = issue?

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE = implementations.

2.  = Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory = feature.

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_83FF7140-83BB-4D08-B248-C866255DF8F4-- --Apple-Mail=_FD077C09-505D-4277-9A41-30A68FA10E9C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE3MjA0MzU2WjAjBgkqhkiG9w0BCQQxFgQUCN1g8W9a 7knwWyEA4UjMJYeUBzYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAnu1ZlL+2cueEdZcQseBctgdoNZixgnxWWLoBYGn0 3OrzgkxjzwIBAlzp/V8AtjcdTl4H0o7g/JbkEyCYpiyyvHX6+06MoCQuYUdZTWGIg8yOY4Vlpqia 0Htgo8ty8TbFLyjNrJKcX0XTD/rVbkbMJbMFCPOcNdhSZwEbBOJw+UfkmY/i+LS/N5vb4drumg09 I/sVWNbS4omR6tRqhJIGXFyBa6gj1Lw2Yk8CnQgeugvNZkYhtI5cYO6vJX+oAD7U4CXdbQPlP/Y7 DUqR0d64sSezxSg6APtiQxUmgjQtZ/6XCTnrSoeeE2QQD4NG10Z7L1EgmnW6sMcMKGD2hnanegAA AAAAAA== --Apple-Mail=_FD077C09-505D-4277-9A41-30A68FA10E9C-- From ve7jtb@ve7jtb.com Wed Apr 17 13:56:27 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E886F21E8091 for ; Wed, 17 Apr 2013 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le+vkwmrH7Ay for ; Wed, 17 Apr 2013 13:56:25 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 93D2F21E80A7 for ; Wed, 17 Apr 2013 13:56:21 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id f6so1186290qej.30 for ; Wed, 17 Apr 2013 13:56:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=VDAKbHb7VWWHY1f0MKch9Em9DsbvFORfhACWNlmuOms=; b=Rq++oYXqZOxVZEH4LuCOHMMRvqaFgf3m/61blVX4SUnSEHAMumxDjIVdxI2N43FUrt C0WOVVwnUPpxMMVc91AJoimrLDBmi60ViClsxxYMpOnYcamNfKYqweqc4619HSUqVO2A BswYWhca+2ZPit7ZZzA0bh0UJ924exYKkqPea/HYzuot29AIWG328juhLvL4Rt8x7UI8 TcUd3u0hNv0kxzggpbmvjgnIgfl9fgz4ImiPGjskQZTM94W/Ifskf0aiG/u4sBdk8xCT 8Ke4KV3Cn2NjPsc3rDpsVvVJS4AccTVcDZC5yyPWENmqnegZifY/0YDD8kET9dhpBJCD CV8g== X-Received: by 10.229.52.4 with SMTP id f4mr2772901qcg.18.1366232179484; Wed, 17 Apr 2013 13:56:19 -0700 (PDT) Received: from [192.168.1.39] (190-20-57-18.baf.movistar.cl. [190.20.57.18]) by mx.google.com with ESMTPS id ei3sm10208602qab.10.2013.04.17.13.56.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 13:56:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8B2ABF2E-3DFC-42F3-8771-9A4EA417F7DB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <51674E63.3050809@isoc.org> Date: Wed, 17 Apr 2013 17:56:08 -0300 Message-Id: <8ACF653B-8300-45F9-9030-2C5B3BE271E9@ve7jtb.com> References: <51674E63.3050809@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnr3TQDGS87ep7+4bHedh1KwTLQKhesYxIY4OUm9ounRlT07cGBQiWJH3rt1u4cvGDV4G47 Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 20:56:27 -0000 --Apple-Mail=_8B2ABF2E-3DFC-42F3-8771-9A4EA417F7DB Content-Type: multipart/alternative; boundary="Apple-Mail=_EF8E9930-5AC3-4E02-AF11-D1E0521D6B75" --Apple-Mail=_EF8E9930-5AC3-4E02-AF11-D1E0521D6B75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1. Yes =96 Use cases where key information is exchanged by means other = than the JWS and JWE headers ARE important. I also think the KID or other method of identifying the key is a SHOULD. = It might be that there is only one key so identifying it is a touch = redundant. We have methods other than kid to identify the key as well. On 2013-04-11, at 8:59 PM, Karen O'Donoghue wrote: > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests = requiring that a key indicator, such as a =93kid=94 field, be required = in all JWS and JWE headers. Are use cases where key information is = exchanged by means other than the JWS or JWE headers important? > Which of these best describes your preferences on this issue? >=20 > 1. Yes. >=20 > 2. No. >=20 > 0. I need more information to decide. >=20 > =20 >=20 > Your reply is requested by Friday, April 19th (or earlier).=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_EF8E9930-5AC3-4E02-AF11-D1E0521D6B75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 1.  Yes =96 = Use cases where key information is exchanged by means other than the JWS = and JWE headers ARE important.

I also = think the KID or other method of identifying the key is a SHOULD. =  It might be that there is only one key so identifying it is a = touch redundant.
We have = methods other than kid to identify the key as = well.


On 2013-04-11, at 8:59 PM, Karen = O'Donoghue <odonoghue@isoc.org> = wrote:


=20 =20
Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a =93kid=94 field, be = required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this = issue?

1.  Yes.

2.   No. =

0.  I = need more information to decide.

 

Your reply is requested by Friday, April 19th (or earlier).
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_EF8E9930-5AC3-4E02-AF11-D1E0521D6B75-- --Apple-Mail=_8B2ABF2E-3DFC-42F3-8771-9A4EA417F7DB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE3MjA1NjA4WjAjBgkqhkiG9w0BCQQxFgQUu2hwvjDM vj4oxgZ9gep/K3xRgSIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAsfQn5tY6Tl6BhwIYxnfhGUzUQ29Ubyuf2ZwSUDou 3uHWD+NHITTyIPR4JLlRRxrQSYoRyvbZVe5IwRRoPtZKSIotlSM2JSwHO3OwSMZQEid/xTMHQlsl 7e0C0/a8Qp/MmtVrAbS+yHnk9+R+porVpLRxeUBDZbnWwVVVYSz5VBaRTUhtG3yO4L1BYnCG51ii clpJ5tuUZxo7NK+kyOtBwjoStMRmGfphkf5XVl8vg5rK6Vy6Lh6P1N63HhMhWhV+eaxgeFW9CTM+ ceogxh6Wjbr8TdxD+kEPwMen4sc/no0dMmANdSXk9sfyj9wIXrjB1gQv50dv1LLc/KDWVb/gIwAA AAAAAA== --Apple-Mail=_8B2ABF2E-3DFC-42F3-8771-9A4EA417F7DB-- From James.H.Manger@team.telstra.com Wed Apr 17 18:56:26 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2421F8E94 for ; Wed, 17 Apr 2013 18:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-2.275, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2VyNdw10lmk for ; Wed, 17 Apr 2013 18:56:25 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECAD21F8E8F for ; Wed, 17 Apr 2013 18:56:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,496,1363093200"; d="scan'208";a="124742409" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 18 Apr 2013 11:56:22 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7048"; a="76708310" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcani.tcif.telstra.com.au with ESMTP; 18 Apr 2013 11:56:22 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 18 Apr 2013 11:56:21 +1000 From: "Manger, James H" To: Matias Woloski Date: Thu, 18 Apr 2013 11:56:20 +1000 Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: Ac45+ceuqPVs8idKTXWEuo5DQZLBRQB2LxsQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C90EC77@WSMSG3153V.srv.dir.telstra.com> References: <51674E3D.7030004@isoc.org> <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> <354223120e2d40b0aea99253c7a15400@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 01:56:26 -0000 TWF0aWFzICh0aGFua3MgZm9yIGluY2x1ZGluZyBhIHJhdGlvbmFsZSB3aXRoIHlvdXIgdm90ZSks DQoNCkkgc3VzcGVjdCB5b3Ugd2lsbCBoYXZlIHRvIGRvICJhbiBleHRyYSBzdGVwIG9mIGJpbmFy eSBzZXJpYWxpemF0aW9uIiBtb3JlIG9mdGVuIGlmIEpXRSBrZWVwcyB0aGUgY2lwaGVydGV4dCBh bmQgSUNWIHNlcGFyYXRlLg0KDQpDb25zaWRlciB0aGUgV2ViIENyeXB0byBBUEkgPGh0dHA6Ly93 d3cudzMub3JnL1RSL1dlYkNyeXB0b0FQSS8jYWVzLWdjbT4uIEl0IHN1cHBvcnRzIGFuIEFFQUQg YWxnb3JpdGhtOiBBRVMgR0NNLiBUbyBkZWNyeXB0OiBzdGFydCB3aXRoIGEga2V5IGFuZCBwYXJh bWV0ZXJzIChBQUQsIGl2LCAqbGVuZ3RoKiBvZiB0YWcpOyB0aGVuIHByb2Nlc3MgY2h1bmtzIG9m IGNpcGhlcnRleHQ7IHRoZW4gZmluaXNoLg0KDQpZb3UgZG9uJ3QgcGFzcyB0aGUgYXV0aGVudGlj YXRpb24gdGFnIChJQ1YpIHRvIHRoZSBBUEkgYXMgYSBzZXBhcmF0ZSBmaWVsZC4gSXQgaXMgYXNz dW1lZCB0byBiZSB0aGUgbGFzdCBieXRlcyBvZiB0aGUgY2lwaGVydGV4dC4NCg0KU2ltaWxhcmx5 IGZvciBKYXZhLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXRp YXMgV29sb3NraQ0KU2VudDogVHVlc2RheSwgMTYgQXByaWwgMjAxMyAyOjUzIEFNDQoNCjENCg0K UmF0aW9uYWxlOiBzaW1wbGljaXR5IGFnYWluLiBBcyBhbiBpbXBsZW1lbnRlciBJIGRvbid0IHdh bnQgdG8gZG8gYW4gZXh0cmEgc3RlcCBvZiBiaW5hcnkgc2VyaWFsaXplIHNvbWV0aGluZy4gQWxz bywgc3RyaW5ncyBhcmUgZWFzaWVyIHRvIGRlYnVnIHdpdGggZmlkZGxlci4NCg0KT24gTW9uLCBB cHIgMTUsIDIwMTMgYXQgMTo0NCBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29m dC5jb20+IHdyb3RlOg0KMQ0KDQotLS0tLS0tLS0tDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVz DQpTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDg6MjAgQU0NCg0KMS4gwqBDb250aW51ZSBo YXZpbmcgc2VwYXJhdGUgQ2lwaGVydGV4dCwgSW5pdGlhbGl6YXRpb24gVmVjdG9yLCBhbmQgSW50 ZWdyaXR5IFZhbHVlIHZhbHVlcyBpbiB0aGUgSldFIHJlcHJlc2VudGF0aW9uLg0KDQotLS0tLS0t LS0tDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2xhbmQgSGVkYmVyZw0KU2VudDogU2F0dXJkYXksIEFwcmls IDEzLCAyMDEzIDEyOjE5IFBNDQoNCjENCg0KMTIgYXByIDIwMTMga2wuIDAxOjU4IHNrcmV2IEth cmVuIE8nRG9ub2dodWUgPG9kb25vZ2h1ZUBpc29jLm9yZz46DQoNCklzc3VlICMxMSBodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzExIHByb3Bvc2VzIHJlc3Ry dWN0dXJpbmcgdGhlIEpXRSByZXByZXNlbnRhdGlvbiB0byByZW1vdmUgdGhlIEpXRSBJbnRlZ3Jp dHkgVmFsdWUgZmllbGQgYW5kIGluc3RlYWQgdXNlIHRoZSBSRkMgNTExNiAoQUVBRCkgYmluYXJ5 IHNlcmlhbGl6YXRpb24gdG8gcmVwcmVzZW50IHRoZSBDaXBoZXJ0ZXh0LCBJbml0aWFsaXphdGlv biBWZWN0b3IsIGFuZCBJbnRlZ3JpdHkgVmFsdWUgdmFsdWVzLiDCoElmIHRoaXMgcHJvcG9zYWwg aXMgYWRvcHRlZCwgSldFcyB3b3VsZCB0aGVuIGhhdmUgdGhyZWUgZmllbGRzIC0gdGhlIGhlYWRl ciwgdGhlIGVuY3J5cHRlZCBrZXksIGFuZCB0aGUgUkZDIDUxMTYgY29tYmluYXRpb24gb2YgdGhl IENpcGhlcnRleHQsIEluaXRpYWxpemF0aW9uIFZlY3RvciwgYW5kIEludGVncml0eSBWYWx1ZSB2 YWx1ZXMuDQpUaGlzIGlzc3VlIGlzIGFsc28gcmVsYXRlZCB0byBpc3N1ZSAjMy4gwqBOb3RlIHRo YXQgdGhlIHVwZGF0ZWQgTWNHcmV3IGRyYWZ0IGRlc2NyaWJlZCB0aGVyZSBjb3VsZCBiZSB1c2Vk IHdoZXRoZXIgb3Igbm90IHdlIHN3aXRjaGVkIHRvIHVzaW5nIFJGQyA1MTE2Lg0KDQoNCldoaWNo IG9mIHRoZXNlIGJlc3QgZGVzY3JpYmVzIHlvdXIgcHJlZmVyZW5jZXMgb24gdGhpcyBpc3N1ZT8N Cg0KMS4gwqBDb250aW51ZSBoYXZpbmcgc2VwYXJhdGUgQ2lwaGVydGV4dCwgSW5pdGlhbGl6YXRp b24gVmVjdG9yLCBhbmQgSW50ZWdyaXR5IFZhbHVlIHZhbHVlcyBpbiB0aGUgSldFIHJlcHJlc2Vu dGF0aW9uLg0KDQoyLiDCoFN3aXRjaCB0byB1c2luZyB0aGUgUkZDIDUxMTYgKEFFQUQpIHNlcmlh bGl6YXRpb24gdG8gcmVwcmVzZW50IHRoZSBjb21iaW5hdGlvbiBvZiB0aGVzZSB0aHJlZSB2YWx1 ZXMuDQoNCjMuIMKgQW5vdGhlciByZXNvbHV0aW9uIChwbGVhc2Ugc3BlY2lmeSBpbiBkZXRhaWwp Lg0KDQowLiDCoEkgbmVlZCBtb3JlIGluZm9ybWF0aW9uIHRvIGRlY2lkZS4NCg0KDQoNCllvdXIg cmVwbHkgaXMgcmVxdWVzdGVkIGJ5IEZyaWRheSwgQXByaWwgMTl0aCBvciBlYXJsaWVyLg0K From ietf@augustcellars.com Thu Apr 18 14:50:02 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A404F21F8FF5 for ; Thu, 18 Apr 2013 14:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pw5PFPQ6-8B for ; Thu, 18 Apr 2013 14:50:02 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2000F21F8FD7 for ; Thu, 18 Apr 2013 14:50:02 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E996B2CA49; Thu, 18 Apr 2013 14:50:00 -0700 (PDT) From: "Jim Schaad" To: "Mike Jones" Date: Thu, 18 Apr 2013 14:49:18 -0700 Message-ID: <04e401ce3c7e$94bfd9b0$be3f8d10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E5_01CE3C43.E861EC10" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac48fneRecweZdqnT5+h9BcteEyq3A== Cc: jose@ietf.org Subject: [jose] OAUTH and implicit key identifiers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 21:50:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04E5_01CE3C43.E861EC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike, I have tried to go through the OAuth documents in order to find where and how they have implicit key identifiers set up for tokens. I was unable to find this. Can you please give me a concrete pointer to where this text is? Jim ------=_NextPart_000_04E5_01CE3C43.E861EC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

 

I have tried = to go through the OAuth documents in order to find where and how they = have implicit key identifiers set up for tokens.   I was = unable to find this.  Can you please give me a concrete pointer to = where this text is?

 

Jim

 

------=_NextPart_000_04E5_01CE3C43.E861EC10-- From Michael.Jones@microsoft.com Thu Apr 18 18:56:27 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F5721F8FF1 for ; Thu, 18 Apr 2013 18:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.573 X-Spam-Level: X-Spam-Status: No, score=0.573 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.572] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI6BzUY5WoLX for ; Thu, 18 Apr 2013 18:56:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 22DAC21F8FD9 for ; Thu, 18 Apr 2013 18:56:22 -0700 (PDT) Received: from BY2FFO11FD001.protection.gbl (10.1.15.200) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.675.0; Fri, 19 Apr 2013 01:56:22 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Fri, 19 Apr 2013 01:56:21 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 19 Apr 2013 01:56:13 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] OAUTH and implicit key identifiers Thread-Index: Ac48fneRecweZdqnT5+h9BcteEyq3AAIL/KQ Date: Fri, 19 Apr 2013 01:56:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367670B65@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <04e401ce3c7e$94bfd9b0$be3f8d10$@augustcellars.com> In-Reply-To: <04e401ce3c7e$94bfd9b0$be3f8d10$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367670B65TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(47446002)(564824004)(66066001)(69226001)(20776003)(50986001)(49866001)(47736001)(47976001)(4396001)(71186001)(33656001)(80022001)(65816001)(81542001)(81342001)(74662001)(31966008)(74502001)(44976003)(6806003)(512954001)(77982001)(59766001)(46102001)(79102001)(51856001)(54316002)(56776001)(56816002)(16406001)(63696002)(16236675002)(15202345002)(76482001)(54356001)(53806001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08213D42D3 Cc: "jose@ietf.org" Subject: Re: [jose] OAUTH and implicit key identifiers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 01:56:27 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367670B65TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09, see the definiti= on of "jwks_uri", which enables the client's JWK Set document to be communi= cated to the OAuth server out of band from the JWTs (and JOSE objects under= lying them) later used. Also see "token_endpoint_auth_method" and especial= ly the "client_secret_jwt" and "private_key_jwt" authentication methods. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Thursday, April 18, 2013 2:49 PM To: Mike Jones Cc: jose@ietf.org Subject: [jose] OAUTH and implicit key identifiers Mike, I have tried to go through the OAuth documents in order to find where and h= ow they have implicit key identifiers set up for tokens. I was unable to = find this. Can you please give me a concrete pointer to where this text is= ? Jim --_000_4E1F6AAD24975D4BA5B168042967394367670B65TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
In http://tools.ietf.org/html/dra=
ft-ietf-oauth-dyn-reg-09, see the definition of “jwks_uri”, which enables the client’s=
 JWK Set document to be communicated to the OAuth server out of band from t=
he JWTs (and JOSE objects underlying them) later used.  Also see ̶=
0;token_endpoint_auth_method̶=
1; and especially the “client_secret_jwt” and “private_key_jwt” authentication methods.

 

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, April 18, 2013 2:49 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: [jose] OAUTH and implicit key identifiers=

 

Mike,

 

I have tried to go through the OAuth documents in or= der to find where and how they have implicit key identifiers set up for tok= ens.   I was unable to find this.  Can you please give me a = concrete pointer to where this text is?

 

Jim

 

--_000_4E1F6AAD24975D4BA5B168042967394367670B65TK5EX14MBXC284r_-- From javier@gluu.org Thu Apr 18 19:55:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DA921F9349 for ; Thu, 18 Apr 2013 19:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqxqOBggrGv6 for ; Thu, 18 Apr 2013 19:55:13 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.93.179.23]) by ietfa.amsl.com (Postfix) with ESMTP id EDCCE21F91B2 for ; Thu, 18 Apr 2013 19:55:11 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 4004817B75B92; Thu, 18 Apr 2013 21:55:11 -0500 (CDT) Received: from gator405.hostgator.com (gator405.hostgator.com [184.172.165.9]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 329BF17B75B5D for ; Thu, 18 Apr 2013 21:55:11 -0500 (CDT) Received: from [190.186.177.27] (port=40707 helo=localhost.localdomain) by gator405.hostgator.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UT1Ti-0007Ee-Kn; Thu, 18 Apr 2013 21:55:10 -0500 Message-ID: <5170B20D.8040305@gluu.org> Date: Thu, 18 Apr 2013 22:55:09 -0400 From: Javier Rojas Blum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matt Miller References: <51674E17.5020902@isoc.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040003020102070901070307" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator405.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gluu.org X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost.localdomain) [190.186.177.27]:40707 X-Source-Auth: javier+gluu.org X-Email-Count: 2 X-Source-Cap: ZGlnaW1vbjtkaWdpbW9uO2dhdG9yNDA1Lmhvc3RnYXRvci5jb20= Cc: Richard Barnes , odonoghue@isoc.org, jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 02:55:13 -0000 This is a multi-part message in MIME format. --------------040003020102070901070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 1 On 04/16/2013 11:51 AM, Matt Miller wrote: > If we're just talking about how the algorithm in use is determined, then I would prefer (1). > > While I see value in better separating key encipherment parameters from content encipherment parameters, that seems like a separate question. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > On Apr 15, 2013, at 9:43 AM, Richard Barnes wrote: > >> 2b. Switch to a structure more like the WebCrypto structure, in which >> algorithm parameters are collected alongside the algorithm name -- and >> separately from key encipherment parameters. >> >> Cf. [draft-barnes-jose-key-wrapping] >> >> >> >> On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue wrote: >> >>> Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out >>> that the JWA algorithm identifiers are different than those used by the W3C >>> WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm >>> identifiers are strings, whereas the W3C WebCrypto algorithm identifiers >>> are structures including string identifiers. The working group had >>> previously decided to continue representing JOSE algorithms as strings, as >>> recorded at >>> http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. >>> **** >>> >>> >>> Which of these best describes your preferences on this issue?**** >>> >>> 1. Continue have the JWA algorithm identifiers be strings, and not >>> objects. Note that WebCrypto may choose to use some of these same strings, >>> where applicable.**** >>> >>> 2. Switch to using the algorithm identifier structures defined in the >>> WebCrypto draft.**** >>> >>> 3. Another resolution (please specify in detail).**** >>> >>> 0. I need more information to decide.**** >>> >>> Your reply is requested by Friday, April 19th or earlier. >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------040003020102070901070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
1

On 04/16/2013 11:51 AM, Matt Miller wrote:
If we're just talking about how the algorithm in use is determined, then I would prefer (1).

While I see value in better separating key encipherment parameters from content encipherment parameters, that seems like a separate question.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


On Apr 15, 2013, at 9:43 AM, Richard Barnes <rlb@ipv.sx> wrote:


2b. Switch to a structure more like the WebCrypto structure, in which
algorithm parameters are collected alongside the algorithm name -- and
separately from key encipherment parameters.

Cf. [draft-barnes-jose-key-wrapping]



On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue <odonoghue@isoc.org>wrote:


Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out
that the JWA algorithm identifiers are different than those used by the W3C
WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/.  The JWA algorithm
identifiers are strings, whereas the W3C WebCrypto algorithm identifiers
are structures including string identifiers.  The working group had
previously decided to continue representing JOSE algorithms as strings, as
recorded at
http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.
****


Which of these best describes your preferences on this issue?****

1.  Continue have the JWA algorithm identifiers be strings, and not
objects.  Note that WebCrypto may choose to use some of these same strings,
where applicable.****

2.  Switch to using the algorithm identifier structures defined in the
WebCrypto draft.****

3.  Another resolution (please specify in detail).****

0.  I need more information to decide.****

Your reply is requested by Friday, April 19th or earlier.




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



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

- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.




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

--------------040003020102070901070307-- From javier@gluu.org Thu Apr 18 20:00:33 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610E821F8D00 for ; Thu, 18 Apr 2013 20:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=0.167, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcYHhCkxZsqi for ; Thu, 18 Apr 2013 20:00:31 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [70.85.130.16]) by ietfa.amsl.com (Postfix) with ESMTP id 437A321F8C30 for ; Thu, 18 Apr 2013 20:00:31 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 36105D2CFAA68; Thu, 18 Apr 2013 22:00:27 -0500 (CDT) Received: from gator405.hostgator.com (gator405.hostgator.com [184.172.165.9]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 25EFED2CFAA40 for ; Thu, 18 Apr 2013 22:00:27 -0500 (CDT) Received: from [190.186.177.27] (port=40851 helo=localhost.localdomain) by gator405.hostgator.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UT1Ys-0000YC-52; Thu, 18 Apr 2013 22:00:30 -0500 Message-ID: <5170B34C.6050806@gluu.org> Date: Thu, 18 Apr 2013 23:00:28 -0400 From: Javier Rojas Blum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Barnes References: <51674E3D.7030004@isoc.org> <71C65BBC-A7CB-4A5A-AE85-20650203F2FB@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060306040704060608060008" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator405.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gluu.org X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost.localdomain) [190.186.177.27]:40851 X-Source-Auth: javier+gluu.org X-Email-Count: 2 X-Source-Cap: ZGlnaW1vbjtkaWdpbW9uO2dhdG9yNDA1Lmhvc3RnYXRvci5jb20= Cc: John Bradley , odonoghue@isoc.org, jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:00:33 -0000 This is a multi-part message in MIME format. --------------060306040704060608060008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 1 On 04/16/2013 10:24 AM, Richard Barnes wrote: > I'm confused. This is not about the IV == Initialization Vector, it's > about the JWE Integrity Value (inconveniently also "IV"). I don't > think anyone has proposed merging in the initialization vector, both > because that's not what RFC 5116 does and because it's a terrible idea :) > > > On Mon, Apr 15, 2013 at 2:41 PM, John Bradley > wrote: > > 1 ish. > > Representing the nonce/IV separately should not preclude using a > crypto library generated nonce/IV , as may be done in some > libraries implementing draft-mcgrew-aead-aes-cbc-hmac-sha2. > > So I am in favour of the current serialization while wanting to > support the crypto from draft-mcgrew-aead-aes-cbc-hmac-sha2 if > not the particular serialization which is optimized for > a different use-case. The current > draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and > serialization. I am hoping we can resolve that so the crypto can > be supported. > > John B. > > On 2013-04-11, at 8:58 PM, Karen O'Donoghue > wrote: > >> Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 >> proposes >> restructuring the JWE representation to remove the JWE Integrity >> Value field and instead use the RFC 5116 (AEAD) binary >> serialization to represent the Ciphertext, Initialization Vector, >> and Integrity Value values. If this proposal is adopted, JWEs >> would then have three fields -- the header, the encrypted key, >> and the RFC 5116 combination of the Ciphertext, Initialization >> Vector, and Integrity Value values. >> >> This issue is also related to issue #3. Note that the updated >> McGrew draft described there could be used whether or not we >> switched to using RFC 5116. >> >> Which of these best describes your preferences on this issue? >> >> 1. Continue having separate Ciphertext, Initialization Vector, >> and Integrity Value values in the JWE representation. >> >> 2. Switch to using the RFC 5116 (AEAD) serialization to >> represent the combination of these three values. >> >> 3. Another resolution (please specify in detail). >> >> 0. I need more information to decide. >> >> Your reply is requested by Friday, April 19^th or earlier. >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------060306040704060608060008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
1


On 04/16/2013 10:24 AM, Richard Barnes wrote:
I'm confused.  This is not about the IV == Initialization Vector, it's about the JWE Integrity Value (inconveniently also "IV").  I don't think anyone has proposed merging in the initialization vector, both because that's not what RFC 5116 does and because it's a terrible idea :)


On Mon, Apr 15, 2013 at 2:41 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
1 ish.

Representing the nonce/IV separately should not preclude using a crypto library generated nonce/IV , as may be done in some libraries implementing  draft-mcgrew-aead-aes-cbc-hmac-sha2.

So I am in favour of the current serialization while wanting to support the crypto from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the particular serialization which is optimized for a different use-case.   The current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and serialization.  I am hoping we can resolve that so the crypto can be supported.

John B.
On 2013-04-11, at 8:58 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have three fields – the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 

This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
 

Which of these best describes your preferences on this issue?

1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.

2.  Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


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




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

--------------060306040704060608060008-- From javier@gluu.org Thu Apr 18 20:08:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53B221F9376 for ; Thu, 18 Apr 2013 20:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=-0.084, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJfB9NJmpApy for ; Thu, 18 Apr 2013 20:08:08 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.139.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDC121F9370 for ; Thu, 18 Apr 2013 20:08:08 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 2359DF33B8785; Thu, 18 Apr 2013 22:08:03 -0500 (CDT) Received: from gator405.hostgator.com (gator405.hostgator.com [184.172.165.9]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 1706AF33B8754 for ; Thu, 18 Apr 2013 22:08:03 -0500 (CDT) Received: from [190.186.177.27] (port=40996 helo=localhost.localdomain) by gator405.hostgator.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UT1gF-0003Ou-Fo; Thu, 18 Apr 2013 22:08:07 -0500 Message-ID: <5170B516.4050604@gluu.org> Date: Thu, 18 Apr 2013 23:08:06 -0400 From: Javier Rojas Blum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "charles.marais@orange.com" References: <51674E2D.3040604@isoc.org> <516E988B.2050304@orange.com> In-Reply-To: <516E988B.2050304@orange.com> Content-Type: multipart/alternative; boundary="------------030906050505040907050203" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator405.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gluu.org X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost.localdomain) [190.186.177.27]:40996 X-Source-Auth: javier+gluu.org X-Email-Count: 5 X-Source-Cap: ZGlnaW1vbjtkaWdpbW9uO2dhdG9yNDA1Lmhvc3RnYXRvci5jb20= Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:08:10 -0000 This is a multi-part message in MIME format. --------------030906050505040907050203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 1 On 04/17/2013 08:41 AM, charles.marais@orange.com wrote: > Hi, > > 1. Have draft-barnes-jose-spi remain a separate specification that > could optionally also be supported by JWS and JWE implementations. > > Br, > > Charles Marais. > > Le 12/04/2013 01:58, Karen O'Donoghue a écrit : >> Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 >> proposes adding an >> "spi" (security parameters index) header parameter to the JWS and JWE >> specifications. This modification to the JOSE formats would allow >> for signaling that pre-negotiated cryptographic parameters are being >> used, rather than including those parameters in the JWS or JWE >> header. This proposal has been written up as >> http://tools.ietf.org/html/draft-barnes-jose-spi-00. >> >> Which of these best describes your preferences on this issue? >> >> 1. Have draft-barnes-jose-spi remain a separate specification that >> could optionally also be supported by JWS and JWE implementations. >> >> 2. Incorporate draft-barnes-jose-spi into the JWS and JWE >> specifications as a mandatory feature. >> >> 3. Incorporate draft-barnes-jose-spi into the JWS and JWE >> specifications as an optional feature. >> >> 4. Another resolution (please specify in detail). >> >> 0. I need more information to decide. >> >> Your reply is requested by Friday, April 19^th or earlier. >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > -- > > *MARAIS Charles* > *FT/OLNC/OLPS/ASE/IDEA/UED * > Tel : 02.96.05.24.18 > charles.marais@orange.com > WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex > - France > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------030906050505040907050203 Content-Type: multipart/related; boundary="------------060300030303040203050104" --------------060300030303040203050104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
1


On 04/17/2013 08:41 AM, charles.marais@orange.com wrote:
Hi,

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.

Br,

Charles Marais.

Le 12/04/2013 01:58, Karen O'Donoghue a écrit :
Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an “spi” (security parameters index) header parameter to the JWS and JWE specifications.  This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header.  This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00.

 

Which of these best describes your preferences on this issue?

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.

2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature.

3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.

4.  Another resolution (please specify in detail).

0.  I need more information to decide.

Your reply is requested by Friday, April 19th or earlier. 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France 





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

--------------060300030303040203050104 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------060300030303040203050104 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------060300030303040203050104-- --------------030906050505040907050203-- From javier@gluu.org Thu Apr 18 20:20:49 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13A41F0D11 for ; Thu, 18 Apr 2013 20:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=1.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ih6BQOxb+-M for ; Thu, 18 Apr 2013 20:20:47 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [69.93.179.18]) by ietfa.amsl.com (Postfix) with ESMTP id 776F81F0D10 for ; Thu, 18 Apr 2013 20:20:47 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 126EB2B1D769; Thu, 18 Apr 2013 22:20:47 -0500 (CDT) Received: from gator405.hostgator.com (gator405.hostgator.com [184.172.165.9]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 0409E2B1D72F for ; Thu, 18 Apr 2013 22:20:47 -0500 (CDT) Received: from [190.186.177.27] (port=41237 helo=localhost.localdomain) by gator405.hostgator.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UT1sU-0007cl-FI; Thu, 18 Apr 2013 22:20:46 -0500 Message-ID: <5170B80D.5070908@gluu.org> Date: Thu, 18 Apr 2013 23:20:45 -0400 From: Javier Rojas Blum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "charles.marais@orange.com" References: <51674E63.3050809@isoc.org> <516E97DE.3050507@orange.com> In-Reply-To: <516E97DE.3050507@orange.com> Content-Type: multipart/alternative; boundary="------------070008050100090403000704" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator405.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gluu.org X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost.localdomain) [190.186.177.27]:41237 X-Source-Auth: javier+gluu.org X-Email-Count: 7 X-Source-Cap: ZGlnaW1vbjtkaWdpbW9uO2dhdG9yNDA1Lmhvc3RnYXRvci5jb20= Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:20:49 -0000 This is a multi-part message in MIME format. --------------070008050100090403000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 1 Yes, Use cases where key information is exchanged by means other than the JWS and JWE headers are important. Also they should be included in the examples in the spec. On 04/17/2013 08:38 AM, charles.marais@orange.com wrote: > 1.Yes, Use cases where key information is exchanged by means other > than JWS and JWE headers are important. > > Charles Marais. > Le 12/04/2013 01:59, Karen O'Donoghue a écrit : >> Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15 >> . suggests >> requiring that a key indicator, such as a "kid" field, be required in >> all JWS and JWE headers.Are use cases where key information is >> exchanged by means other than the JWS or JWE headers important? >> >> Which of these best describes your preferences on this issue? >> >> 1. Yes. >> >> 2. No. >> >> 0. I need more information to decide. >> >> Your reply is requested by Friday, April 19^th (or earlier). >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > -- > > *MARAIS Charles* > *FT/OLNC/OLPS/ASE/IDEA/UED * > Tel : 02.96.05.24.18 > charles.marais@orange.com > WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex > - France > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------070008050100090403000704 Content-Type: multipart/related; boundary="------------020207000302020106000703" --------------020207000302020106000703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
1

Yes, Use cases where key information is exchanged by means other than the JWS and JWE headers are important.
Also they should be included in the examples in the spec.


On 04/17/2013 08:38 AM, charles.marais@orange.com wrote:
1.Yes, Use cases where key information is exchanged by means other than JWS and JWE headers are important.

Charles Marais.
Le 12/04/2013 01:59, Karen O'Donoghue a écrit :
Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a “kid” field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?

Which of these best describes your preferences on this issue?

1.  Yes.

2.   No.

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th (or earlier). 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France 





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

--------------020207000302020106000703 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------020207000302020106000703 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------020207000302020106000703-- --------------070008050100090403000704-- From javier@gluu.org Thu Apr 18 20:26:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D90C21F93AA for ; Thu, 18 Apr 2013 20:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqsHaguCM41Q for ; Thu, 18 Apr 2013 20:26:09 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.56.148.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4DE21E8053 for ; Thu, 18 Apr 2013 20:26:08 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 60283E7F833AE; Thu, 18 Apr 2013 22:26:00 -0500 (CDT) Received: from gator405.hostgator.com (gator405.hostgator.com [184.172.165.9]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 49FE1E7F83338 for ; Thu, 18 Apr 2013 22:26:00 -0500 (CDT) Received: from [190.186.177.27] (port=41360 helo=localhost.localdomain) by gator405.hostgator.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UT1xe-00012w-SX; Thu, 18 Apr 2013 22:26:07 -0500 Message-ID: <5170B94D.2060601@gluu.org> Date: Thu, 18 Apr 2013 23:26:05 -0400 From: Javier Rojas Blum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "charles.marais@orange.com" References: <51674E58.6000505@isoc.org> <516E9824.9020508@orange.com> In-Reply-To: <516E9824.9020508@orange.com> Content-Type: multipart/alternative; boundary="------------070701080805090705020805" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator405.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gluu.org X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost.localdomain) [190.186.177.27]:41360 X-Source-Auth: javier+gluu.org X-Email-Count: 9 X-Source-Cap: ZGlnaW1vbjtkaWdpbW9uO2dhdG9yNDA1Lmhvc3RnYXRvci5jb20= Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:26:11 -0000 This is a multi-part message in MIME format. --------------070701080805090705020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 2 But keeping the "kid" header param On 04/17/2013 08:40 AM, charles.marais@orange.com wrote: > Hi, > > 1. Retain the "x5c" header parameter in JWE. > > Br, > > Charles Marais. > Le 12/04/2013 01:59, Karen O'Donoghue a écrit : >> Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 >> suggests removing >> the "x5c" header parameter from JWE, saying that no use case for it >> has emerged. The same logic may apply to other key specification >> parameters for JWE. >> >> >> Which of these best describes your preferences on this issue? >> >> 1. Retain the "x5c" header parameter in JWE. >> >> 2. Remove the "x5c" header parameter (and possibly other related key >> specification parameters) from JWE. >> >> 3. Another resolution (please specify in detail). >> >> 0. I need more information to decide. >> >> Your reply is requested by Friday, April 19^th or earlier. >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > -- > > *MARAIS Charles* > *FT/OLNC/OLPS/ASE/IDEA/UED * > Tel : 02.96.05.24.18 > charles.marais@orange.com > WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex > - France > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------070701080805090705020805 Content-Type: multipart/related; boundary="------------040209030701010000050506" --------------040209030701010000050506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
2

But keeping the "kid" header param


On 04/17/2013 08:40 AM, charles.marais@orange.com wrote:
Hi,

1. Retain the “x5c” header parameter in JWE.

Br,

Charles Marais.
Le 12/04/2013 01:59, Karen O'Donoghue a écrit :
Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests removing the “x5c” header parameter from JWE, saying that no use case for it has emerged.  The same logic may apply to other key specification parameters for JWE.


Which of these best describes your preferences on this issue?

1.  Retain the “x5c” header parameter in JWE.

2.  Remove the “x5c” header parameter (and possibly other related key specification parameters) from JWE.

3.  Another resolution (please specify in detail).

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier. 


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

--

MARAIS Charles
FT/OLNC/OLPS/ASE/IDEA/UED
Tel : 02.96.05.24.18
charles.marais@orange.com
WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307 LANNION Cedex - France 





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

--------------040209030701010000050506 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --------------040209030701010000050506 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --------------040209030701010000050506-- --------------070701080805090705020805-- From ietf@augustcellars.com Thu Apr 18 22:22:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AC021F942B for ; Thu, 18 Apr 2013 22:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9ptZ-XDa-BO for ; Thu, 18 Apr 2013 22:22:06 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 80FD221F93D7 for ; Thu, 18 Apr 2013 22:22:06 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D2D4D2C9BB; Thu, 18 Apr 2013 22:22:05 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <04e401ce3c7e$94bfd9b0$be3f8d10$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367670B65@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367670B65@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 18 Apr 2013 22:21:23 -0700 Message-ID: <003601ce3cbd$bbe7cfe0$33b76fa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01CE3C83.0F8B68E0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQKdjnb20fF3C0w1MlrWxRbg4O0ruQKqPhoJlykL+oA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] OAUTH and implicit key identifiers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 05:22:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01CE3C83.0F8B68E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ok - I have read through this document - my gut feeling is that I understood enough about OAuth to comment I would create a massive mail message of comments. This does not make it clear to me how this would work. After several reads of the document my best guess is that one says - If you go digging through the content of the message then you might find something that will give you a hint about what key to use when combined with your database. Do you have any better cases that make it clear how this is supposed to work? Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, April 18, 2013 6:56 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] OAUTH and implicit key identifiers In http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09, see the definition of "jwks_uri", which enables the client's JWK Set document to be communicated to the OAuth server out of band from the JWTs (and JOSE objects underlying them) later used. Also see "token_endpoint_auth_method" and especially the "client_secret_jwt" and "private_key_jwt" authentication methods. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, April 18, 2013 2:49 PM To: Mike Jones Cc: jose@ietf.org Subject: [jose] OAUTH and implicit key identifiers Mike, I have tried to go through the OAuth documents in order to find where and how they have implicit key identifiers set up for tokens. I was unable to find this. Can you please give me a concrete pointer to where this text is? Jim ------=_NextPart_000_0037_01CE3C83.0F8B68E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok – I have read through this document = – my gut feeling is that I understood enough about OAuth to = comment I would create a massive mail message of = comments.

 

This does not make it = clear to me how this would work.  After several reads of the = document my best guess is that one says – If you go digging = through the content of the message then you might find something that = will give you a hint about what key to use when combined with your = database.  

 

Do you have any better = cases that make it clear how this is supposed to = work?

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Thursday, April 18, 2013 6:56 PM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: RE: [jose] OAUTH and implicit key = identifiers

 

In http://to=
ols.ietf.org/html/draft-ietf-oauth-dyn-reg-09, see the definition of =
“jwks_uri”, =
which enables the client’s JWK Set document to be communicated to =
the OAuth server out of band from the JWTs (and JOSE objects underlying =
them) later used.  Also see “token_endpoint_auth_method” and =
especially the “client_secret_jwt” and =
“private_key_jwt” =
authentication methods.

 

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

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Thursday, April 18, 2013 = 2:49 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: = [jose] OAUTH and implicit key = identifiers

 

Mike,

 

I have tried = to go through the OAuth documents in order to find where and how they = have implicit key identifiers set up for tokens.   I was = unable to find this.  Can you please give me a concrete pointer to = where this text is?

 

Jim

 

------=_NextPart_000_0037_01CE3C83.0F8B68E0-- From sakimura@gmail.com Fri Apr 19 02:15:44 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0FE21F9416 for ; Fri, 19 Apr 2013 02:15:44 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv797Hi8bXBz for ; Fri, 19 Apr 2013 02:15:40 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3391021F940E for ; Fri, 19 Apr 2013 02:15:35 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id ej20so1184239lab.19 for ; Fri, 19 Apr 2013 02:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=d2eUYpAsKymY7lzmN9e+/0Z92zDFirun97pkJ4VTo7Y=; b=eOmV7IaMy5SMzHFa8s3PkU/thoF/VuV/Djc1qPpJ5S9JU+L1MQ/NtNQx1Rql5qqQsS U2S1gsZPf6HBoFfNY9m5hEcXn0znPXuLiJPcXk8li89JpWByawN/H5PgITIjp8Utnts8 jOJBJu3CLOy5p0vNwYBLHUhsZ72WS1Q+QZqpe3yb9Bk3eF+KKipfw4pqoTe82Ej8wiMS tW7yCNLuvlRFA2nKs0AZnQLHEhBryxw79njTHltb74fNiXTOnrEMUeumYooLBlNmfzTv trhrRS8/gioaoSdXbeaMhXcdA+RlvXH0zNCmrNC+mK7FxPHEvqzrp+CwQMhOVaxJBcFR 8h4g== MIME-Version: 1.0 X-Received: by 10.112.132.227 with SMTP id ox3mr7700761lbb.108.1366362934041; Fri, 19 Apr 2013 02:15:34 -0700 (PDT) Received: by 10.112.19.163 with HTTP; Fri, 19 Apr 2013 02:15:33 -0700 (PDT) In-Reply-To: <5170B20D.8040305@gluu.org> References: <51674E17.5020902@isoc.org> <5170B20D.8040305@gluu.org> Date: Fri, 19 Apr 2013 18:15:33 +0900 Message-ID: From: Nat Sakimura To: Javier Rojas Blum Content-Type: text/plain; charset=ISO-8859-1 Cc: Richard Barnes , "jose@ietf.org" , Karen ODonoghue , Matt Miller Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 09:15:44 -0000 1 as what we want here is a set of safe presets shorthands. 2013/4/19 Javier Rojas Blum : > 1 > > > On 04/16/2013 11:51 AM, Matt Miller wrote: > > If we're just talking about how the algorithm in use is determined, then I > would prefer (1). > > While I see value in better separating key encipherment parameters from > content encipherment parameters, that seems like a separate question. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > On Apr 15, 2013, at 9:43 AM, Richard Barnes wrote: > > 2b. Switch to a structure more like the WebCrypto structure, in which > algorithm parameters are collected alongside the algorithm name -- and > separately from key encipherment parameters. > > Cf. [draft-barnes-jose-key-wrapping] > > > > On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue wrote: > > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out > that the JWA algorithm identifiers are different than those used by the W3C > WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The JWA algorithm > identifiers are strings, whereas the W3C WebCrypto algorithm identifiers > are structures including string identifiers. The working group had > previously decided to continue representing JOSE algorithms as strings, as > recorded at > http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. > **** > > > Which of these best describes your preferences on this issue?**** > > 1. Continue have the JWA algorithm identifiers be strings, and not > objects. Note that WebCrypto may choose to use some of these same strings, > where applicable.**** > > 2. Switch to using the algorithm identifier structures defined in the > WebCrypto draft.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > Your reply is requested by Friday, April 19th or earlier. > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From vladimir@nimbusds.com Fri Apr 19 07:39:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBB521F87B1 for ; Fri, 19 Apr 2013 07:39:19 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LORL7L7EAubD for ; Fri, 19 Apr 2013 07:39:18 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 6DDB921F8771 for ; Fri, 19 Apr 2013 07:39:18 -0700 (PDT) Received: (qmail 5937 invoked from network); 19 Apr 2013 14:39:16 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 19 Apr 2013 14:39:16 -0000 Received: (qmail 17041 invoked by uid 99); 19 Apr 2013 14:39:16 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.85.163 User-Agent: Workspace Webmail 5.6.36 Message-Id: <20130419073915.cc40c4f3d92d2001859047cd8cabb9ab.f57de353f1.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: odonoghue@isoc.org, jose@ietf.org Date: Fri, 19 Apr 2013 07:39:15 -0700 Mime-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:39:19 -0000 1. algorithm identifiers remain strings=0A=0A--=0AVladimir Dzhuvinov : www.= NimbusDS.com : vladimir@nimbusds.com=0A=0A 1. Continue have the JWA algori= thm identifiers be strings, and not=0Aobjects. Note that WebCrypto may cho= ose to use some of these same=0Astrings, where applicable.=0A 2. Switch to= using the algorithm identifier structures defined in the=0AWebCrypto draft= .=0A 3. Another resolution (please specify in detail).=0A 0. I need more = information to decide.=0A Your reply is requested by Friday, April 19th or = earlier. =0A =0A =0A =0A From vladimir@nimbusds.com Fri Apr 19 07:43:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8965921F8A08 for ; Fri, 19 Apr 2013 07:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB-U3AxKaX+J for ; Fri, 19 Apr 2013 07:43:35 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 971F221F8952 for ; Fri, 19 Apr 2013 07:43:34 -0700 (PDT) Received: (qmail 16385 invoked from network); 19 Apr 2013 14:43:33 -0000 Received: from unknown (HELO localhost) (188.121.52.243) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 19 Apr 2013 14:43:33 -0000 Received: (qmail 745 invoked by uid 99); 19 Apr 2013 14:43:33 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.85.163 User-Agent: Workspace Webmail 5.6.36 Message-Id: <20130419074332.cc40c4f3d92d2001859047cd8cabb9ab.f81e51ef42.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: odonoghue@isoc.org, jose@ietf.org Date: Fri, 19 Apr 2013 07:43:32 -0700 Mime-Version: 1.0 Subject: Re: [jose] =?utf-8?q?Feedback_request_on_jose_tracker_issue_=238=3A_S?= =?utf-8?q?hould_we_add_a_=22spi=22_header_field=3F?= X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:43:35 -0000 1. Separate optional SPI spec.=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.= com : vladimir@nimbusds.com=0A =0A=0A 1. Have draft-barnes-jose-spi remain= a separate specification that=0Acould optionally also be supported by JWS = and JWE implementations.=0A 2. Incorporate draft-barnes-jose-spi into the = JWS and JWE=0Aspecifications as a mandatory feature.=0A 3. Incorporate dra= ft-barnes-jose-spi into the JWS and JWE=0Aspecifications as an optional fea= ture.=0A 4. Another resolution (please specify in detail).=0A 0. I need m= ore information to decide. From vladimir@nimbusds.com Fri Apr 19 07:49:23 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4F21F86CA for ; Fri, 19 Apr 2013 07:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sns1OwcKZhNg for ; Fri, 19 Apr 2013 07:49:23 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id A2A8821F86AE for ; Fri, 19 Apr 2013 07:49:22 -0700 (PDT) Received: (qmail 28753 invoked from network); 19 Apr 2013 14:49:21 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 19 Apr 2013 14:49:21 -0000 Received: (qmail 24356 invoked by uid 99); 19 Apr 2013 14:49:21 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.85.163 User-Agent: Workspace Webmail 5.6.36 Message-Id: <20130419074920.cc40c4f3d92d2001859047cd8cabb9ab.466b8f0310.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: odonoghue@isoc.org, jose@ietf.org Date: Fri, 19 Apr 2013 07:49:20 -0700 Mime-Version: 1.0 Subject: Re: [jose] =?utf-8?q?Feedback_request_on_jose_tracker_issue=2311=3A_S?= =?utf-8?q?hould_we_use_RFC_5116_and_remove_the_JWE_Integrity_Value_field?= =?utf-8?q?=3F?= X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:49:23 -0000 1. Separate ciphertext, IV and integrity value fields.=0A=0A--=0AVladimir D= zhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A =0A=0A =0A Which o= f these best describes your preferences on this issue?=0A 1. Continue havi= ng separate Ciphertext, Initialization Vector, and=0AIntegrity Value values= in the JWE representation.=0A 2. Switch to using the RFC 5116 (AEAD) seri= alization to represent the=0Acombination of these three values.=0A 3. Anot= her resolution (please specify in detail).=0A 0. I need more information t= o decide.=0A From vladimir@nimbusds.com Fri Apr 19 07:52:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2313E21F8FA4 for ; Fri, 19 Apr 2013 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSSLFD+1RUR8 for ; Fri, 19 Apr 2013 07:52:33 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id BD13A21F8F6E for ; Fri, 19 Apr 2013 07:52:32 -0700 (PDT) Received: (qmail 2379 invoked from network); 19 Apr 2013 14:52:30 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 19 Apr 2013 14:52:30 -0000 Received: (qmail 12738 invoked by uid 99); 19 Apr 2013 14:52:30 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.85.163 User-Agent: Workspace Webmail 5.6.36 Message-Id: <20130419075229.cc40c4f3d92d2001859047cd8cabb9ab.54b9d18380.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: odonoghue@isoc.org, jose@ietf.org Date: Fri, 19 Apr 2013 07:52:29 -0700 Mime-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:52:38 -0000 2. No key indicator should be mandatory. The app / higher-level=0Aprotocols= should decide on that.=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : v= ladimir@nimbusds.com=0A=0A 1. Yes.=0A 2. No. =0A 0. I need more informa= tion to decide.=0A From mamille2@cisco.com Fri Apr 19 08:07:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE32321F9590 for ; Fri, 19 Apr 2013 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pP81bm2kO5x for ; Fri, 19 Apr 2013 08:07:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8654C21F9545 for ; Fri, 19 Apr 2013 08:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4638; q=dns/txt; s=iport; t=1366384050; x=1367593650; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=pw3S6mXBF+V1CblluHv/YPaxTUGWUjXh7kD2qC/xZH8=; b=Mp+UERhgWdgIblobklt6a+XZy0JbLzlXrldDwPvxvX/x8eEzsOa6jW6y sa6uD8gArfFfscgTgGmcN7qVow8eIlU0YRb7MSNhoGz0vv5/DXJ7FsdOK O2BW6Izrqbk4eVt23d7rdbYPKzvUYR408XKDxs5F6mq6niey0z2ZIP0+F g=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FACBccVGrRDoH/2dsb2JhbABQgwY2AcBlgQYWdIIfAQEBAwEBAQFrCwULCzsLAiUwBhOIDgUNvTKNfYEoBxaCUGEDiQuGU4czgSOEZIsNgVaBVR0 X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="p7s'?scan'208";a="79095629" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 19 Apr 2013 15:07:30 +0000 Received: from [10.129.24.59] ([10.129.24.59]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3JF7S35027062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Apr 2013 15:07:29 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_D2EFF3BC-2804-429B-8F97-7B7CA68A6366"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Matt Miller In-Reply-To: <51674E63.3050809@isoc.org> Date: Fri, 19 Apr 2013 09:07:28 -0600 Message-Id: <8FF379B1-6E1A-40FF-A0E7-3970DB60C881@cisco.com> References: <51674E63.3050809@isoc.org> To: X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:07:31 -0000 --Apple-Mail=_D2EFF3BC-2804-429B-8F97-7B7CA68A6366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I suppose my answer to this poll (either Karen's or Mike's wording) is = "Yes". However, while I do think that key information exchanges outside of the = JWE/JWS headers are important, I do think a reference to the resultant = key is mandatory. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue = wrote: > Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15 = . suggests requiring = that a key indicator, such as a "kid" field, be required in all JWS and = JWE headers.Are use cases where key information is exchanged by means = other than the JWS or JWE headers important? >=20 > Which of these best describes your preferences on this issue? >=20 > 1. Yes. >=20 > 2. No. >=20 > 0. I need more information to decide. >=20 > Your reply is requested by Friday, April 19^th (or earlier). > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_D2EFF3BC-2804-429B-8F97-7B7CA68A6366 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQxOTE1MDcyOFowIwYJKoZIhvcNAQkEMRYEFGsbvgN9BWcc6i063DXT/5VI+kcYMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQAi8htAn8petPPNFzLTWoYqKi5fdnTh+LxZogDlvR02 Ht67I6TBRwdiE5K680m47M5G0a/8Qgb2dWGvgAp6g884lMpC14yt6io30/va61mTCBXOZbaIsYOm jfamNA0vbNzAEGpRDwPugaXx87G8l10YXV0Dq/x4ASAqUJmzFhYlwg18vnenT0QAVWLAfh0sCdyr vH79QMsthhicp8RKBdwlM0K2uPjpc17PX6NY9EkOHuMWmj7gT0xcdeHHLa1oUOU/PZtQLUFbxCT0 AGfkY4kFJBgpwgPY5b4wD10ULqG49TLx+bk4XLZGWOT56OiCbPElFzBpFQ86D05wEOUeCpd0AAAA AAAA --Apple-Mail=_D2EFF3BC-2804-429B-8F97-7B7CA68A6366-- From vladimir@nimbusds.com Fri Apr 19 08:13:12 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E273821F95D7 for ; Fri, 19 Apr 2013 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joPueHs9eyVM for ; Fri, 19 Apr 2013 08:13:12 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 2DFA821F95D2 for ; Fri, 19 Apr 2013 08:13:03 -0700 (PDT) Received: (qmail 13721 invoked from network); 19 Apr 2013 15:13:02 -0000 Received: from unknown (HELO localhost) (188.121.52.243) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 19 Apr 2013 15:13:02 -0000 Received: (qmail 26817 invoked by uid 99); 19 Apr 2013 15:13:02 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.85.163 User-Agent: Workspace Webmail 5.6.36 Message-Id: <20130419081301.cc40c4f3d92d2001859047cd8cabb9ab.804efec55b.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: odonoghue@isoc.org, jose@ietf.org Date: Fri, 19 Apr 2013 08:13:01 -0700 Mime-Version: 1.0 Subject: Re: [jose] =?utf-8?q?Feedback_request_on_jose_tracker_issue_=2312=3A_?= =?utf-8?q?Should_the_x5c_field_be_removed_from_JWE=3F=2C_=2C?= X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:13:13 -0000 0. Need more information.=0A=0A Which of these best describes your preferen= ces on this issue?=0A 1. Retain the =E2=80=9Cx5c=E2=80=9D header parameter= in JWE.=0A 2. Remove the =E2=80=9Cx5c=E2=80=9D header parameter (and poss= ibly other related=0Akey specification parameters) from JWE.=0A 3. Another= resolution (please specify in detail).=0A 0. I need more information to d= ecide.=0A From housley@vigilsec.com Fri Apr 19 08:36:42 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7B21F9610 for ; Fri, 19 Apr 2013 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jje24-EGbjS for ; Fri, 19 Apr 2013 08:36:41 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id DE1AB21F961A for ; Fri, 19 Apr 2013 08:36:40 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 42CC1F2406E; Fri, 19 Apr 2013 11:36:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id wRsZ9bF-lARF; Fri, 19 Apr 2013 11:36:29 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 02201F2407F; Fri, 19 Apr 2013 11:36:46 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Apr 2013 11:36:31 -0400 Message-Id: To: odonoghue@isoc.org, jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:36:42 -0000 Combination of 1 and 2. The field needs to be in the base = specifications, but the only rule that needs to be included in the base = specification is an exact match of the identifier. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D 1. Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature. 4. Another resolution (please specify in detail). From Michael.Jones@microsoft.com Fri Apr 19 09:07:32 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190B321F8FD3 for ; Fri, 19 Apr 2013 09:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=1.586, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3ESuruTya5R for ; Fri, 19 Apr 2013 09:07:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0321F8F9D for ; Fri, 19 Apr 2013 09:07:30 -0700 (PDT) Received: from BN1BFFO11FD016.protection.gbl (10.58.52.204) by BN1BFFO11HUB020.protection.gbl (10.58.53.130) with Microsoft SMTP Server (TLS) id 15.0.675.0; Fri, 19 Apr 2013 16:07:29 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD016.mail.protection.outlook.com (10.58.53.76) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Fri, 19 Apr 2013 16:07:28 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 19 Apr 2013 16:06:47 +0000 From: Mike Jones To: Russ Housley , "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: AQHOPROqHDBQ9x2uwEWdVoWSp7L0YZjds0bw Date: Fri, 19 Apr 2013 16:06:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5383001)(199002)(189002)(13464002)(377454001)(50986001)(56816002)(76482001)(46102001)(50466001)(16406001)(54316002)(4396001)(51856001)(74502001)(81542001)(47736001)(56776001)(77982001)(54356001)(46406003)(33656001)(63696002)(80022001)(55846006)(47446002)(47976001)(69226001)(66066001)(23726002)(49866001)(53806001)(74662001)(81342001)(31966008)(47776003)(65816001)(6806003)(59766001)(79102001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB020; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08213D42D3 Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:07:32 -0000 Russ, I'm curious why you say that the "spi" field needs to be in the base = spec. From a spec factoring point of view, even if SPI remains a completel= y separate spec and nothing is said in the base spec, there would be no con= fusion or conflicts, including for implementations. Here's why: - A header without an "alg" field is not recognized as a JWS or JWE, so t= here's no conflict there - A JWS or JWE can legally contain a "spi" header field and a registry is= already provided to define the meanings of additional header fields, so th= ere's no conflict there either Therefore, it seems like the separate spec could use the registry to define= the meaning of "spi" in a JWS and JWE and could furthermore define the sem= antics of objects using headers without an "alg" field but including a "spi= " field. No conflicts. And clear separation of concerns. Those wanting the SPI functionality could use it. Those not needing it wou= ld need to do nothing - which I think is as it should be. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Friday, April 19, 2013 8:37 AM To: odonoghue@isoc.org; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? Combination of 1 and 2. The field needs to be in the base specifications, = but the only rule that needs to be included in the base specification is an= exact match of the identifier. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From sakimura@gmail.com Fri Apr 19 09:34:20 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A422D21F8633 for ; Fri, 19 Apr 2013 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbzrDgpoNQoW for ; Fri, 19 Apr 2013 09:34:19 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7519321F8605 for ; Fri, 19 Apr 2013 09:34:19 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id r11so3906508lbv.40 for ; Fri, 19 Apr 2013 09:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=nv8YR39XA3fd7Kt7/IowbB+gvA6wyBOZ6kjTvz73txc=; b=kyzXLfWB+go5I8zR4ONMM1JHCvtmbGRnx5bkLmfTR2MteUWZcbZySvpo268/kWlRSU b0d3b4CW6ZH5sLFvnIf/FC8QujCf44XG1+zvFvMQsorGIlDH9RLZmLDElNEznmIx+tau 1l0uOdzzgYapUIBe7UhdaX17Chk25xujBwOTQEUx4QgjoivOeM24jlcxbEBG3oXYWLmH vrhymk53Gdxu4x6IOMo6y/baSd/aNLwUBbH02COg6l6rHWNPuhdzi0PEmMkSTAPTgudp v0YCgnjRUFBXKqsiYtm0lfZRfNxrqC41hf1vo8k89drsrFOn+KDpMB04SrWPmVvR9lJo 3MPA== MIME-Version: 1.0 X-Received: by 10.112.162.40 with SMTP id xx8mr8450541lbb.30.1366389256828; Fri, 19 Apr 2013 09:34:16 -0700 (PDT) Received: by 10.112.19.163 with HTTP; Fri, 19 Apr 2013 09:34:16 -0700 (PDT) In-Reply-To: <8FF379B1-6E1A-40FF-A0E7-3970DB60C881@cisco.com> References: <51674E63.3050809@isoc.org> <8FF379B1-6E1A-40FF-A0E7-3970DB60C881@cisco.com> Date: Sat, 20 Apr 2013 01:34:16 +0900 Message-ID: From: Nat Sakimura To: Matt Miller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "jose@ietf.org" , Karen ODonoghue Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:34:20 -0000 1 as it is important to be able to support oob cases. 2013/4/20 Matt Miller : > I suppose my answer to this poll (either Karen's or Mike's wording) is "Y= es". > > However, while I do think that key information exchanges outside of the J= WE/JWS headers are important, I do think a reference to the resultant key i= s mandatory. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > On Apr 11, 2013, at 5:59 PM, Karen O'Donoghue wrote: > >> Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15 . suggests requiring that a key indi= cator, such as a "kid" field, be required in all JWS and JWE headers.Are us= e cases where key information is exchanged by means other than the JWS or J= WE headers important? >> >> Which of these best describes your preferences on this issue? >> >> 1. Yes. >> >> 2. No. >> >> 0. I need more information to decide. >> >> Your reply is requested by Friday, April 19^th (or earlier). >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From sakimura@gmail.com Fri Apr 19 09:36:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1F521F8F05 for ; Fri, 19 Apr 2013 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA43-YoN4H4V for ; Fri, 19 Apr 2013 09:36:47 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 639C021F8EF7 for ; Fri, 19 Apr 2013 09:36:47 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id t1so3846420lbd.24 for ; Fri, 19 Apr 2013 09:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=5cRk8pWKUVjs+EXBU9SkGgVJX6iW5SB1W51dGKISdeE=; b=W+4drE1sdaIQMB3nhPQFHpDTCWi3ZBWXFpdzpdFvkCWbx4vRLUOeQK+6pV7kYxnRVw KR2CPzGrfn/lS0iM5Z9lZzBqDLH9cb/q1pC1bopctRq20YyAzG0ESwNqg5FgtRnm1nUf daQGcck+TomZ7C/auIKiW6CFnSAPnvDgVu4VkR3xsrYUNQMhYVKiwbb6cw8rre2rC8KT wueanBHck0pO6PTFXkOfy70A19cpbZ0UAsaHo1VQqlLc/n2pnUF4OUwqFAUVzfLnS+XW f5Y2S/IUBVRFSJhI7kkR3TmcaSkR5ZqR6ZNiFuJ2AKQcvexdJuPnWsrFVPUJwRBqOWbf 0ipQ== MIME-Version: 1.0 X-Received: by 10.112.162.40 with SMTP id xx8mr8454783lbb.30.1366389406350; Fri, 19 Apr 2013 09:36:46 -0700 (PDT) Received: by 10.112.19.163 with HTTP; Fri, 19 Apr 2013 09:36:46 -0700 (PDT) In-Reply-To: References: <51674E58.6000505@isoc.org> Date: Sat, 20 Apr 2013 01:36:46 +0900 Message-ID: From: Nat Sakimura To: Axel Nennker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "jose@ietf.org" , Karen ODonoghue Subject: Re: [jose] Feedback request on jose tracker issue #12: Should the x5c field be removed from JWE?, , X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:36:48 -0000 +1 2013/4/12 : > 1 > > > > x5c is the most explicit way to describe which private key is the right o= ne. > It is an alternative to kid which is another reason why kid must not be > mandatory. > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Karen O'Donoghue > Sent: Friday, April 12, 2013 1:59 AM > To: jose@ietf.org > Subject: [jose] Feedback request on jose tracker issue #12: Should the x5= c > field be removed from JWE?, , > > > > Issue #12 http://trac.tools.ietf.org/wg/jose/trac/ticket/12 suggests > removing the =93x5c=94 header parameter from JWE, saying that no use case= for it > has emerged. The same logic may apply to other key specification paramet= ers > for JWE. > > > > Which of these best describes your preferences on this issue? > > 1. Retain the =93x5c=94 header parameter in JWE. > > 2. Remove the =93x5c=94 header parameter (and possibly other related key > specification parameters) from JWE. > > 3. Another resolution (please specify in detail). > > 0. I need more information to decide. > > > > Your reply is requested by Friday, April 19th or earlier. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From housley@vigilsec.com Fri Apr 19 10:00:05 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D1121F9423 for ; Fri, 19 Apr 2013 10:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOktN3yXUNh4 for ; Fri, 19 Apr 2013 10:00:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE021F944A for ; Fri, 19 Apr 2013 10:00:05 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 679A2F2407E; Fri, 19 Apr 2013 13:00:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id AgTX0nZAM4mt; Fri, 19 Apr 2013 12:59:47 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 50999F24078; Fri, 19 Apr 2013 13:00:22 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Apr 2013 13:00:00 -0400 Message-Id: To: odonoghue@isoc.org, jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:00:05 -0000 As I have said in the past, this is the wrong question. The document = should be structured in a manner that tell which things are mandatory = based on the use of particular types of key management. Russ From Michael.Jones@microsoft.com Fri Apr 19 10:17:34 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6068E21F9617 for ; Fri, 19 Apr 2013 10:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G+9NWX-f1EZ for ; Fri, 19 Apr 2013 10:17:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6721F9616 for ; Fri, 19 Apr 2013 10:17:31 -0700 (PDT) Received: from BY2FFO11FD020.protection.gbl (10.1.15.201) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.675.0; Fri, 19 Apr 2013 17:12:52 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Fri, 19 Apr 2013 17:12:52 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Fri, 19 Apr 2013 17:11:51 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] OAUTH and implicit key identifiers Thread-Index: Ac48fneRecweZdqnT5+h9BcteEyq3AAIL/KQAAehAIAAGFtyoA== Date: Fri, 19 Apr 2013 17:11:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367678E1D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <04e401ce3c7e$94bfd9b0$be3f8d10$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367670B65@TK5EX14MBXC284.redmond.corp.microsoft.com> <003601ce3cbd$bbe7cfe0$33b76fa0$@augustcellars.com> In-Reply-To: <003601ce3cbd$bbe7cfe0$33b76fa0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367678E1DTK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(44976003)(6806003)(77982001)(51856001)(76482001)(54356001)(63696002)(56816002)(56776001)(54316002)(16406001)(59766001)(55846006)(46102001)(79102001)(16297215002)(15395725003)(53806001)(512954001)(15202345002)(16236675002)(4396001)(564824004)(49866001)(47736001)(47976001)(50986001)(47446002)(66066001)(20776003)(69226001)(33656001)(81542001)(74502001)(31966008)(81342001)(71186001)(74662001)(65816001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB038; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08213D42D3 Cc: "jose@ietf.org" Subject: Re: [jose] OAUTH and implicit key identifiers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:17:34 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367678E1DTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure. One use case that's fully specified and has been demonstrated to pro= duce interoperable implementations is the OpenID Connect use case. You can= read the key management instructions for that use case at http://openid.ne= t/specs/openid-connect-messages-1_0.html#sigenc. Note that this uses disco= very to determine the algorithms supported by the server using the discover= y fields at http://openid.net/specs/openid-connect-discovery-1_0.html#Provi= derMetadata and uses client registration http://openid.net/specs/openid-con= nect-registration-1_0.html (which is based on the OAuth Dynamic Client Regi= stration spec) to exchange algorithm and key information. I know that Dick Hardt has a different key management scheme that's used in= the British Columbia Government identity system. Maybe he would like to d= escribe that as well. I'm sure that the Mozilla Persona system has to have one too. (I think it'= s a simple one based on domain names, but I'm not an expert here.) Cheers, -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Thursday, April 18, 2013 10:21 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: [jose] OAUTH and implicit key identifiers Ok - I have read through this document - my gut feeling is that I understoo= d enough about OAuth to comment I would create a massive mail message of co= mments. This does not make it clear to me how this would work. After several reads= of the document my best guess is that one says - If you go digging through= the content of the message then you might find something that will give yo= u a hint about what key to use when combined with your database. Do you have any better cases that make it clear how this is supposed to wor= k? Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, April 18, 2013 6:56 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] OAUTH and implicit key identifiers In http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-09, see the definiti= on of "jwks_uri", which enables the client's JWK Set document to be communi= cated to the OAuth server out of band from the JWTs (and JOSE objects under= lying them) later used. Also see "token_endpoint_auth_method" and especial= ly the "client_secret_jwt" and "private_key_jwt" authentication methods. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, April 18, 2013 2:49 PM To: Mike Jones Cc: jose@ietf.org Subject: [jose] OAUTH and implicit key identifiers Mike, I have tried to go through the OAuth documents in order to find where and h= ow they have implicit key identifiers set up for tokens. I was unable to = find this. Can you please give me a concrete pointer to where this text is= ? Jim --_000_4E1F6AAD24975D4BA5B168042967394367678E1DTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure.  One use ca= se that’s fully specified and has been demonstrated to produce intero= perable implementations is the OpenID Connect use case.  You can read = the key management instructions for that use case at http://openid.net/specs/openid-connect-messages-1_0.html#sigenc. = Note that this uses discovery to determine the algorithms supported by the= server using the discovery fields at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata<= /a> and uses client registration ht= tp://openid.net/specs/openid-connect-registration-1_0.html (which is ba= sed on the OAuth Dynamic Client Registration spec) to exchange algorithm an= d key information.

 

I know that Dick Hardt= has a different key management scheme that’s used in the British Col= umbia Government identity system.  Maybe he would like to describe tha= t as well.

 

I’m sure that th= e Mozilla Persona system has to have one too.  (I think it’s a s= imple one based on domain names, but I’m not an expert here.)

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Cheers,=

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Thursday, April 18, 2013 10:21 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: [jose] OAUTH and implicit key identifiers

 

Ok – I have read= through this document – my gut feeling is that I understood enough a= bout OAuth to comment I would create a massive mail message of comments.

 

This does not make it = clear to me how this would work.  After several reads of the document = my best guess is that one says – If you go digging through the conten= t of the message then you might find something that will give you a hint about what key to use when combined with your da= tabase.  

 

Do you have any better= cases that make it clear how this is supposed to work?

 

Jim<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Thursday, April 18, 2013 6:56 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] OAUTH and implicit key identifiers

 

In http://tools.ietf.org/html/dra=
ft-ietf-oauth-dyn-reg-09, see the definition of “jwks_uri”, which enables the client’s=
 JWK Set document to be communicated to the OAuth server out of band from t=
he JWTs (and JOSE objects underlying them) later used.  Also see ̶=
0;token_endpoint_auth_method̶=
1; and especially the “client_secret_jwt” and “private_key_jwt” authentication methods.

 

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

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, April 18, 2013 2:49 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: [jose] OAUTH and implicit key identifiers=

 

Mike,

 

I have tried to go through the OAuth documents in or= der to find where and how they have implicit key identifiers set up for tok= ens.   I was unable to find this.  Can you please give me a = concrete pointer to where this text is?

 

Jim

 

--_000_4E1F6AAD24975D4BA5B168042967394367678E1DTK5EX14MBXC284r_-- From rlb@ipv.sx Fri Apr 19 10:36:47 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9684E21F93B4 for ; Fri, 19 Apr 2013 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK6ZdHYn6zXx for ; Fri, 19 Apr 2013 10:36:46 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78521F92E8 for ; Fri, 19 Apr 2013 10:36:46 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wc20so746541obb.19 for ; Fri, 19 Apr 2013 10:36:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=F11j5/w+U5wJhff9p8rWYFhptPoik4CEQrhBHaQ4/7U=; b=oSyXiTxozp0ACf/qoVF6I+RT8NIFXcc+eXHPRkZtJr/+8B+mO6FwX20t5uAY4vxyXM oLWOPjrLqZ1i04zGJkbHP/Gp4N7KNqEubx4AGNHtEExokAzcNvG9PQ7btiJax77xGn/l 7IrFQSuAmNdyz5VZO3Hq2OPYi/kOFTU29h92Rwb/z2CnExwoVfqpZWcI5VNLFl05vXS1 s1clCOe0yxrNVV+YG72mFe3QVjO0PES4MeacCBRZzBj3jr2v6UgzNjKnUJlIzwIBQib/ /z+06YFweaqDYRoD9sCRg8PmyKYURpVXyBn6QVrHGf2IiUQv4+9MryToC5xrwZhGhEZ1 NJKw== MIME-Version: 1.0 X-Received: by 10.60.17.132 with SMTP id o4mr9624984oed.12.1366393005870; Fri, 19 Apr 2013 10:36:45 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 19 Apr 2013 10:36:45 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: Date: Fri, 19 Apr 2013 13:36:45 -0400 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: multipart/alternative; boundary=089e01294d0cbd214104daba29e3 X-Gm-Message-State: ALoCoQlgNhTjZ7wBbvzJtENpGXRwnoC6OQ+shSBItgbQEE1lktr2g+OhZA9GORrM+nRb3CYIe6Ed Cc: "jose@ietf.org" , Karen ODonoghue Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:36:47 -0000 --089e01294d0cbd214104daba29e3 Content-Type: text/plain; charset=ISO-8859-1 Definitely agree with this statement. That was the underlying intent of ISSUE-6 (Unclear requirements levels on fields). Because the document isn't structured in the way Russ describes, everything has to be optional. If it were structured according to key management, you could have a clear set of REQUIRED fields based on the mode (indicated by "alg"): -- Key transport (asymmetric) => kid / jku -- Key encipherment (symmetric) => kid -- Key agreement => kid, epk, apu, apv Of course, these could be omitted if pre-negotiation is going on, but you would need to signal that, e.g., with SPI. --Richard On Fri, Apr 19, 2013 at 1:00 PM, Russ Housley wrote: > As I have said in the past, this is the wrong question. The document > should be structured in a manner that tell which things are mandatory based > on the use of particular types of key management. > > Russ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e01294d0cbd214104daba29e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Definitely agree with this statement. =A0

That was the underlying intent of ISSUE-6 (Unclear requirements levels o= n fields). =A0Because the document isn't structured in the way Russ des= cribes, everything has to be optional. =A0 =A0If it were structured accordi= ng to key management, you could have a clear set of REQUIRED fields based o= n the mode (indicated by "alg"):
-- Key transport (asymmetric) =3D> kid / jku=A0
-- Key encipherment (symmetric) =3D> kid
-- Key agree= ment =3D> kid, epk, apu, apv=A0

Of = course, these could be omitted if pre-negotiation is going on, but you woul= d need to signal that, e.g., with SPI.

--Richard




On Fri, Apr 19, 2013 at 1:00 PM, Russ Housley <= housley@vigilsec.= com> wrote:
As I have said in the past, this is the wron= g question. =A0The document should be structured in a manner that tell whic= h things are mandatory based on the use of particular types of key manageme= nt.

Russ

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e01294d0cbd214104daba29e3-- From rlb@ipv.sx Fri Apr 19 10:43:01 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BA321F93AA for ; Fri, 19 Apr 2013 10:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLkcfNOD1TPr for ; Fri, 19 Apr 2013 10:43:00 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 80E1321F92E8 for ; Fri, 19 Apr 2013 10:43:00 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so2345927oah.21 for ; Fri, 19 Apr 2013 10:43:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rTv7z5V1MvmjZp6Z4ypWSDsi6UfLQga8ZCriDzhdPIw=; b=M+MHUfaPExrNAs/35iagpka9QYPir3m2I9y5CJu9XFfe5+kObTkfuZD10u4+JdEINO d1ODLv7iZ353Am2I7lg2jfFfljk0Ab+K+SN3ytC26oMMlhRbOGAMtXEdcLzbzBA2vZVj kYKt9jEXfSNFZW4POQbkGxH5zuWEg+0XdfmtQKLyj8BlANDkNG+FPAYKYGLZ/Z+4aqdq Zk/DbVfnms8jelPJPzY+Xfze5/ExVOIogwIkSlYd2Rn6b0bUSqNIwk6PvUTz+uM0qBj7 is5DXkVzVW8DaNnfglYxrBb+O3zmZ5OBjIWck4UNgtQOJCdh236asNdSTHlrc7gF4Xl7 2yOA== MIME-Version: 1.0 X-Received: by 10.182.106.16 with SMTP id gq16mr4644108obb.27.1366393380033; Fri, 19 Apr 2013 10:43:00 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 19 Apr 2013 10:42:59 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 19 Apr 2013 13:42:59 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8fb1fc6e0a7ac504daba40d0 X-Gm-Message-State: ALoCoQlhxuG/npuQowSUYWqhLDP+Y+3eOD2xbane2GomXCTJ1KSUf5oIpGkO+PJTAvWiBsxnYNFm Cc: Russ Housley , "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:43:01 -0000 --e89a8fb1fc6e0a7ac504daba40d0 Content-Type: text/plain; charset=ISO-8859-1 In principle, you could use the omission of the "alg" field as a signal that pre-negotiation is going on. However, that seems like not the most useful way to do it, and it conflicts with current practice -- namely the examples currently in the JWE and JWS specs. Those examples use pre-negotiation, but they also have an "alg" field. It's not very useful because it doesn't provide the recipient any clue about how to populate the missing fields. There's a semantic mis-match here as well, since a JWE with pre-negotiation is still a JWE, just an incomplete one. A dedicated flag field like SPI provides a clearer indication, and it also provides a hook that out-of-band protocols can use to connect in the pre-negotiated parameters. --Richard On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones wrote: > Russ, I'm curious why you say that the "spi" field needs to be in the base > spec. From a spec factoring point of view, even if SPI remains a > completely separate spec and nothing is said in the base spec, there would > be no confusion or conflicts, including for implementations. Here's why: > - A header without an "alg" field is not recognized as a JWS or JWE, so > there's no conflict there > - A JWS or JWE can legally contain a "spi" header field and a registry > is already provided to define the meanings of additional header fields, so > there's no conflict there either > > Therefore, it seems like the separate spec could use the registry to > define the meaning of "spi" in a JWS and JWE and could furthermore define > the semantics of objects using headers without an "alg" field but including > a "spi" field. No conflicts. And clear separation of concerns. > > Those wanting the SPI functionality could use it. Those not needing it > would need to do nothing - which I think is as it should be. > > Best wishes, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Russ Housley > Sent: Friday, April 19, 2013 8:37 AM > To: odonoghue@isoc.org; jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we > add a "spi" header field? > > Combination of 1 and 2. The field needs to be in the base specifications, > but the only rule that needs to be included in the base specification is an > exact match of the identifier. > > Russ > > = = = = = = = = = = > > 1. Have draft-barnes-jose-spi remain a separate specification that could > optionally also be supported by JWS and JWE implementations. > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as a mandatory feature. > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications > as an optional feature. > 4. Another resolution (please specify in detail). > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --e89a8fb1fc6e0a7ac504daba40d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In principle, you could use the omission of the "alg&= quot; field as a signal that pre-negotiation is going on. =A0However, that = seems like not the most useful way to do it, and it conflicts with current = practice -- namely the examples currently in the JWE and JWS specs. =A0Thos= e examples use pre-negotiation, but they also have an "alg" field= . =A0It's not very useful because it doesn't provide the recipient = any clue about how to populate the missing fields. =A0There's a semanti= c mis-match here as well, since a JWE with pre-negotiation is still a JWE, = just an incomplete one. =A0

A dedicated flag field like SPI provides a clearer ind= ication, and it also provides a hook that out-of-band protocols can use to = connect in the pre-negotiated parameters.

--Richard

<= br>
On Fri, Apr 19, 2013 at 12:06 PM, Mike Jo= nes <Michael.Jones@microsoft.com> wrote:
Russ, I'm curious why you say that the &= quot;spi" field needs to be in the base spec. =A0From a spec factoring= point of view, even if SPI remains a completely separate spec and nothing = is said in the base spec, there would be no confusion or conflicts, includi= ng for implementations. =A0Here's why:
=A0 - A header without an "alg" field is not recognized as a JWS = or JWE, so there's no conflict there
=A0 - A JWS or JWE can legally contain a "spi" header field and a= registry is already provided to define the meanings of additional header f= ields, so there's no conflict there either

Therefore, it seems like the separate spec could use the registry to define= the meaning of "spi" in a JWS and JWE and could furthermore defi= ne the semantics of objects using headers without an "alg" field = but including a "spi" field. =A0No conflicts. =A0And clear separa= tion of concerns.

Those wanting the SPI functionality could use it. =A0Those not needing it w= ould need to do nothing - which I think is as it should be.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best wishes= ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Russ Housley
Sent: Friday, April 19, 2013 8:37 AM
To: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field?

Combination of 1 and 2. =A0The field needs to be in the base specifications= , but the only rule that needs to be included in the base specification is = an exact match of the identifier.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

1. =A0Have draft-barnes-jose-spi remain a separate specification that could= optionally also be supported by JWS and JWE implementations.
2. =A0Incorporate draft-barnes-jose-spi into the JWS and JWE specifications= as a mandatory feature.
3. =A0Incorporate draft-barnes-jose-spi into the JWS and JWE specifications= as an optional feature.
4. =A0Another resolution (please specify in detail).

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--e89a8fb1fc6e0a7ac504daba40d0-- From housley@vigilsec.com Fri Apr 19 10:51:14 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6488C21F95D2 for ; Fri, 19 Apr 2013 10:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpaorHZFbmrO for ; Fri, 19 Apr 2013 10:51:13 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 10FAC21F944A for ; Fri, 19 Apr 2013 10:51:07 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 4662BF2407E; Fri, 19 Apr 2013 13:51:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id tq5iuzpWZT0u; Fri, 19 Apr 2013 13:50:39 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BB7CCF24078; Fri, 19 Apr 2013 13:51:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-19--607879797 From: Russ Housley In-Reply-To: Date: Fri, 19 Apr 2013 13:51:00 -0400 Message-Id: <0072E7B1-1CD4-46DB-8954-52E795B5C861@vigilsec.com> References: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Richard Barnes , Mike Jones X-Mailer: Apple Mail (2.1085) Cc: jose@ietf.org, Karen O'Donoghue Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:51:14 -0000 --Apple-Mail-19--607879797 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote: > In principle, you could use the omission of the "alg" field as a = signal that pre-negotiation is going on. However, that seems like not = the most useful way to do it, and it conflicts with current practice -- = namely the examples currently in the JWE and JWS specs. Those examples = use pre-negotiation, but they also have an "alg" field. It's not very = useful because it doesn't provide the recipient any clue about how to = populate the missing fields. There's a semantic mis-match here as well, = since a JWE with pre-negotiation is still a JWE, just an incomplete one. = =20 >=20 > A dedicated flag field like SPI provides a clearer indication, and it = also provides a hook that out-of-band protocols can use to connect in = the pre-negotiated parameters. >=20 > --Richard >=20 >=20 >=20 > On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones = wrote: > Russ, I'm curious why you say that the "spi" field needs to be in the = base spec. =46rom a spec factoring point of view, even if SPI remains a = completely separate spec and nothing is said in the base spec, there = would be no confusion or conflicts, including for implementations. = Here's why: > - A header without an "alg" field is not recognized as a JWS or JWE, = so there's no conflict there > - A JWS or JWE can legally contain a "spi" header field and a = registry is already provided to define the meanings of additional header = fields, so there's no conflict there either >=20 > Therefore, it seems like the separate spec could use the registry to = define the meaning of "spi" in a JWS and JWE and could furthermore = define the semantics of objects using headers without an "alg" field but = including a "spi" field. No conflicts. And clear separation of = concerns. >=20 > Those wanting the SPI functionality could use it. Those not needing = it would need to do nothing - which I think is as it should be. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Friday, April 19, 2013 8:37 AM > To: odonoghue@isoc.org; jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #8: Should = we add a "spi" header field? >=20 > Combination of 1 and 2. The field needs to be in the base = specifications, but the only rule that needs to be included in the base = specification is an exact match of the identifier. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > 1. Have draft-barnes-jose-spi remain a separate specification that = could optionally also be supported by JWS and JWE implementations. > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as a mandatory feature. > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as an optional feature. > 4. Another resolution (please specify in detail). >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail-19--607879797 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1


On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote:

In principle, you could use the omission of the "alg" field as a signal that pre-negotiation is going on.  However, that seems like not the most useful way to do it, and it conflicts with current practice -- namely the examples currently in the JWE and JWS specs.  Those examples use pre-negotiation, but they also have an "alg" field.  It's not very useful because it doesn't provide the recipient any clue about how to populate the missing fields.  There's a semantic mis-match here as well, since a JWE with pre-negotiation is still a JWE, just an incomplete one.  

A dedicated flag field like SPI provides a clearer indication, and it also provides a hook that out-of-band protocols can use to connect in the pre-negotiated parameters.

--Richard



On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Russ, I'm curious why you say that the "spi" field needs to be in the base spec.  From a spec factoring point of view, even if SPI remains a completely separate spec and nothing is said in the base spec, there would be no confusion or conflicts, including for implementations.  Here's why:
  - A header without an "alg" field is not recognized as a JWS or JWE, so there's no conflict there
  - A JWS or JWE can legally contain a "spi" header field and a registry is already provided to define the meanings of additional header fields, so there's no conflict there either

Therefore, it seems like the separate spec could use the registry to define the meaning of "spi" in a JWS and JWE and could furthermore define the semantics of objects using headers without an "alg" field but including a "spi" field.  No conflicts.  And clear separation of concerns.

Those wanting the SPI functionality could use it.  Those not needing it would need to do nothing - which I think is as it should be.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, April 19, 2013 8:37 AM
To: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field?

Combination of 1 and 2.  The field needs to be in the base specifications, but the only rule that needs to be included in the base specification is an exact match of the identifier.

Russ

= = = = = = = = = =

1.  Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations.
2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature.
3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature.
4.  Another resolution (please specify in detail).

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


--Apple-Mail-19--607879797-- From mpeck@mitre.org Fri Apr 19 10:53:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C0121F944A for ; Fri, 19 Apr 2013 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqyKtfNZZ9u9 for ; Fri, 19 Apr 2013 10:53:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9098F21F95D2 for ; Fri, 19 Apr 2013 10:53:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 11E03226013B; Fri, 19 Apr 2013 13:53:33 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 04DE51F03DD; Fri, 19 Apr 2013 13:53:33 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.181]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Fri, 19 Apr 2013 13:53:32 -0400 From: "Peck, Michael A" To: "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? Thread-Index: AQHONxCG+liEGw63Vkeb+6qrTbq//5jd3lhQ Date: Fri, 19 Apr 2013 17:53:32 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321F018865@IMCMBX04.MITRE.ORG> References: <51674E3D.7030004@isoc.org> In-Reply-To: <51674E3D.7030004@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321F018865IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:53:35 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321F018865IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2 Some cryptographic modes don't have a separate initialization vector or don= 't have a separate integrity check value. The RFC5116 approach encourages shifting the complexity of handling crypto = to the crypto library rather than the JOSE implementation. i.e. Give the crypto library a ciphertext with embedded integrity check val= ue and know that the crypto library will reject decryption if the integrity= check fails, rather than trusting each JOSE implementation to properly che= ck the integrity check value. As already pointed out the question isn't quite phrased correctly because R= FC 5116 has a separate initialization vector field, it's just not used by d= raft-mcgrew-aead-aes-cbc-hmac-sha2-01. Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Thursday, April 11, 2013 7:59 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue#11: Should we use RF= C 5116 and remove the JWE Integrity Value field? Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restru= cturing the JWE representation to remove the JWE Integrity Value field and = instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphe= rtext, Initialization Vector, and Integrity Value values. If this proposal= is adopted, JWEs would then have three fields - the header, the encrypted = key, and the RFC 5116 combination of the Ciphertext, Initialization Vector,= and Integrity Value values. This issue is also related to issue #3. Note that the updated McGrew draft= described there could be used whether or not we switched to using RFC 5116= . Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the comb= ination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. --_000_8B4C063947CD794BB6FF90C78BAE9B321F018865IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2

 <= /p>

Some cryptographic modes = don’t have a separate initialization vector or don’t have a sep= arate integrity check value.

 <= /p>

The RFC5116 approach enco= urages shifting the complexity of handling crypto to the crypto library rat= her than the JOSE implementation.

i.e. Give the crypto libr= ary a ciphertext with embedded integrity check value and know that the cryp= to library will reject decryption if the integrity check fails, rather than trusting each JOSE implementation to properly check the= integrity check value.

 <= /p>

As already pointed out th= e question isn’t quite phrased correctly because RFC 5116 has a separ= ate initialization vector field, it’s just not used by draft-mcgrew-a= ead-aes-cbc-hmac-sha2-01.

 <= /p>

Mike

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.o= rg] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 7:59 PM
To: jose@ietf.org
Subject: [jose] Feedback request on jose tracker issue#11: Should we= use RFC 5116 and remove the JWE Integrity Value field?

 

Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructurin= g the JWE representation to remove the JWE Integrity Value field and instea= d use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext,= Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have thre= e fields – the header, the encrypted key, and the RFC 5116 combinatio= n of the Ciphertext, Initialization Vector, and Integrity Value values.&nbs= p;

This issue is also related to issue #3.  Note that the update= d McGrew draft described there could be used whether or not we switched to = using RFC 5116.
 

Which of these best describes your preferences on this issue?=

1.  Continue having separate Ciphertext, Initialization Vecto= r, and Integrity Value values in the JWE representation.

2.  Switch to using the RFC 5116 (AEAD) serialization to repr= esent the combination of these three values.

3.  Another resolution (please specify in detail).=

0.  I need more information to decide.

 

Your reply is requested by Friday, April 19th or earlier.

--_000_8B4C063947CD794BB6FF90C78BAE9B321F018865IMCMBX04MITREOR_-- From Michael.Jones@microsoft.com Fri Apr 19 11:12:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5721F95F1 for ; Fri, 19 Apr 2013 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y30-q7hNdTHA for ; Fri, 19 Apr 2013 11:12:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA921F95FF for ; Fri, 19 Apr 2013 11:12:06 -0700 (PDT) Received: from BL2FFO11FD026.protection.gbl (10.173.161.200) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.675.0; Fri, 19 Apr 2013 18:11:02 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Fri, 19 Apr 2013 18:11:01 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 19 Apr 2013 18:10:51 +0000 From: Mike Jones To: Russ Housley , Richard Barnes Thread-Topic: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Thread-Index: AQHOPSVm7DnzVSbi5kmXcobFAhsY3Jjd0pwAgAAEzwA= Date: Fri, 19 Apr 2013 18:10:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436767934E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <0072E7B1-1CD4-46DB-8954-52E795B5C861@vigilsec.com> In-Reply-To: <0072E7B1-1CD4-46DB-8954-52E795B5C861@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436767934ETK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377454001)(24454001)(5383001)(189002)(13464002)(47446002)(55846006)(74662001)(20776003)(71186001)(81342001)(81542001)(80022001)(54356001)(53806001)(69226001)(77982001)(512954001)(79102001)(47736001)(4396001)(56816002)(15202345002)(56776001)(65816001)(47976001)(66066001)(50986001)(74502001)(46102001)(564824004)(6806003)(16406001)(31966008)(44976003)(54316002)(49866001)(16236675002)(63696002)(76482001)(33656001)(59766001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB024; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08213D42D3 Cc: "jose@ietf.org" , Karen O'Donoghue Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:12:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436767934ETK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW, in terms of a "dedicated flag", I'd previously suggested to Richard in= private communication that one way for the SPI spec to do his cleanly woul= d be to use "alg": "spi", rather than omitting the "alg" field entirely. T= he "spi" value would then be registered by the SPI spec in the algorithms r= egistry - pointing back to the SPI spec. I personally think that this is cleaner than just omitting "alg", since it = maintains the invariant that all JWS and JWE representations have an "alg" = value that is used to determine the processing rules. Cheers, -- Mike From: Russ Housley [mailto:housley@vigilsec.com] Sent: Friday, April 19, 2013 10:51 AM To: Richard Barnes; Mike Jones Cc: Karen O'Donoghue; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? +1 On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote: In principle, you could use the omission of the "alg" field as a signal tha= t pre-negotiation is going on. However, that seems like not the most usefu= l way to do it, and it conflicts with current practice -- namely the exampl= es currently in the JWE and JWS specs. Those examples use pre-negotiation,= but they also have an "alg" field. It's not very useful because it doesn'= t provide the recipient any clue about how to populate the missing fields. = There's a semantic mis-match here as well, since a JWE with pre-negotiatio= n is still a JWE, just an incomplete one. A dedicated flag field like SPI provides a clearer indication, and it also = provides a hook that out-of-band protocols can use to connect in the pre-ne= gotiated parameters. --Richard On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones > wrote: Russ, I'm curious why you say that the "spi" field needs to be in the base = spec. From a spec factoring point of view, even if SPI remains a completel= y separate spec and nothing is said in the base spec, there would be no con= fusion or conflicts, including for implementations. Here's why: - A header without an "alg" field is not recognized as a JWS or JWE, so t= here's no conflict there - A JWS or JWE can legally contain a "spi" header field and a registry is= already provided to define the meanings of additional header fields, so th= ere's no conflict there either Therefore, it seems like the separate spec could use the registry to define= the meaning of "spi" in a JWS and JWE and could furthermore define the sem= antics of objects using headers without an "alg" field but including a "spi= " field. No conflicts. And clear separation of concerns. Those wanting the SPI functionality could use it. Those not needing it wou= ld need to do nothing - which I think is as it should be. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Russ Housley Sent: Friday, April 19, 2013 8:37 AM To: odonoghue@isoc.org; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field? Combination of 1 and 2. The field needs to be in the base specifications, = but the only rule that needs to be included in the base specification is an= exact match of the identifier. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 4. Another resolution (please specify in detail). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436767934ETK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BTW, in terms of a “= ;dedicated flag”, I’d previously suggested to Richard in privat= e communication that one way for the SPI spec to do his cleanly would be to use “alg”: “spi”, rather than omitting the “= alg” field entirely.  The “spi” value would then be = registered by the SPI spec in the algorithms registry – pointing back= to the SPI spec.

 <= /p>

I personally think that t= his is cleaner than just omitting “alg”, since it maintains the= invariant that all JWS and JWE representations have an “alg” v= alue that is used to determine the processing rules.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Cheers,

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

 <= /p>

From: Russ Hou= sley [mailto:housley@vigilsec.com]
Sent: Friday, April 19, 2013 10:51 AM
To: Richard Barnes; Mike Jones
Cc: Karen O'Donoghue; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #8: Shoul= d we add a "spi" header field?

 

+1

 

 

On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote:



In principle, you could use the omission of the &quo= t;alg" field as a signal that pre-negotiation is going on.  Howev= er, that seems like not the most useful way to do it, and it conflicts with= current practice -- namely the examples currently in the JWE and JWS specs.  Those examples use pre-negotiation, but th= ey also have an "alg" field.  It's not very useful because i= t doesn't provide the recipient any clue about how to populate the missing = fields.  There's a semantic mis-match here as well, since a JWE with pre-negotiation is still a JWE, just an incomplete one. &= nbsp;

 

A dedicated flag field like SPI provides a clearer i= ndication, and it also provides a hook that out-of-band protocols can use t= o connect in the pre-negotiated parameters.

 

--Richard

 

 

On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Russ, I'm curious why you say that the "spi&quo= t; field needs to be in the base spec.  From a spec factoring point of= view, even if SPI remains a completely separate spec and nothing is said i= n the base spec, there would be no confusion or conflicts, including for implementations.  Here's why:
  - A header without an "alg" field is not recognized as a J= WS or JWE, so there's no conflict there
  - A JWS or JWE can legally contain a "spi" header field an= d a registry is already provided to define the meanings of additional heade= r fields, so there's no conflict there either

Therefore, it seems like the separate spec could use the registry to define= the meaning of "spi" in a JWS and JWE and could furthermore defi= ne the semantics of objects using headers without an "alg" field = but including a "spi" field.  No conflicts.  And clear separation of concerns.

Those wanting the SPI functionality could use it.  Those not needing i= t would need to do nothing - which I think is as it should be.

                     = ;           Best wishes,
                     = ;           -- Mike


-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Russ Housley
Sent: Friday, April 19, 2013 8:37 AM
To: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field?

Combination of 1 and 2.  The field needs to be in the base specificati= ons, but the only rule that needs to be included in the base specification = is an exact match of the identifier.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

1.  Have draft-barnes-jose-spi remain a separate specification that co= uld optionally also be supported by JWS and JWE implementations.
2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specificati= ons as a mandatory feature.
3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specificati= ons as an optional feature.
4.  Another resolution (please specify in detail).

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436767934ETK5EX14MBXC284r_-- From housley@vigilsec.com Fri Apr 19 11:25:12 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96A821F87D2 for ; Fri, 19 Apr 2013 11:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBbLsWC-Ybwd for ; Fri, 19 Apr 2013 11:25:12 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7D21F8630 for ; Fri, 19 Apr 2013 11:25:12 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C2A29F24078; Fri, 19 Apr 2013 14:25:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ghmr9hQikxJu; Fri, 19 Apr 2013 14:25:07 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 28DD2F2406E; Fri, 19 Apr 2013 14:25:17 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 Apr 2013 14:25:10 -0400 Message-Id: <44ED17C2-D855-4549-B098-96515D4AE954@vigilsec.com> To: odonoghue@isoc.org, jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:25:13 -0000 2. Switch to using the RFC 5116 (AEAD) serialization ... And, when using a mode like CBC, simply prepend the IV to the ciphertext. Russ = = = = = = = = = Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. From ve7jtb@ve7jtb.com Fri Apr 19 11:34:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBADA21F8551 for ; Fri, 19 Apr 2013 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U5rXBoRbvT2 for ; Fri, 19 Apr 2013 11:34:08 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id A509421F854D for ; Fri, 19 Apr 2013 11:34:08 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 1so2888378qee.18 for ; Fri, 19 Apr 2013 11:34:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=UewrcElcwB6lYzbMRbdyZb+BdMB1JFwYu4Z4ff83wTc=; b=XeYhotOWT6ZiCg511eXtT9h+wUaMbgbo09KHi0wJ5S6yOqB2XSnjsnOp+Z6tPJ1JMh tS89WeK4YNzvviYcFavhnkBC4THySekM+scaLjKt5eXxXLmFgmGkpkLNEQJJTMgGRMDZ HXhNjqCK8J4jkqxgpWlpWGLGzIeSTg/+TS12+Rw3zw3ACJ2dgWbfknWqeqk2eV+Io/WJ AM4Xeu3DvnTAaspZfqS9vYzccMBPMl5ATQk60bitnzDhB3kWzhJTaaWN9mLe8ET+r0QU SDyRY9ra1zgsaco4v/aN745Q6xybSThFrrOUkMX8yWCRSCZ8MvEYRt8pVCtZ/8wQMIp3 zQRw== X-Received: by 10.49.74.226 with SMTP id x2mr16846661qev.63.1366396447767; Fri, 19 Apr 2013 11:34:07 -0700 (PDT) Received: from [192.168.1.39] (190-20-56-217.baf.movistar.cl. [190.20.56.217]) by mx.google.com with ESMTPS id u3sm19271738qab.1.2013.04.19.11.34.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 11:34:06 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_792D59CA-9110-45EA-8BE4-5DF12B790F36"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436767934E@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 19 Apr 2013 15:33:57 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <0072E7B1-1CD4-46DB-8954-52E795B5C861@vigilsec.com> <4E1F6AAD24975D4BA5B16804296739436767934E@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnPFMTuvECj9aJUsMus0NbIuwex4Fv5gdcE7M7EF3onVr0WMoEG2OOrMz71C2VGRDp+jTDl Cc: Richard Barnes , Russ Housley , Karen O'Donoghue , "jose@ietf.org" Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:34:11 -0000 --Apple-Mail=_792D59CA-9110-45EA-8BE4-5DF12B790F36 Content-Type: multipart/alternative; boundary="Apple-Mail=_5FB27783-ADCC-4A94-8BED-495A7B17465E" --Apple-Mail=_5FB27783-ADCC-4A94-8BED-495A7B17465E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes using "alg":"spi" is cleaner and allowed by the current spec. I am = not keen on omitting alg as a flag. On 2013-04-19, at 3:10 PM, Mike Jones = wrote: > BTW, in terms of a =93dedicated flag=94, I=92d previously suggested to = Richard in private communication that one way for the SPI spec to do his = cleanly would be to use =93alg=94: =93spi=94, rather than omitting the = =93alg=94 field entirely. The =93spi=94 value would then be registered = by the SPI spec in the algorithms registry =96 pointing back to the SPI = spec. > =20 > I personally think that this is cleaner than just omitting =93alg=94, = since it maintains the invariant that all JWS and JWE representations = have an =93alg=94 value that is used to determine the processing rules. > =20 > = Cheers, > -- = Mike > =20 > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Friday, April 19, 2013 10:51 AM > To: Richard Barnes; Mike Jones > Cc: Karen O'Donoghue; jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #8: Should = we add a "spi" header field? > =20 > +1 > =20 > =20 > On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote: >=20 >=20 > In principle, you could use the omission of the "alg" field as a = signal that pre-negotiation is going on. However, that seems like not = the most useful way to do it, and it conflicts with current practice -- = namely the examples currently in the JWE and JWS specs. Those examples = use pre-negotiation, but they also have an "alg" field. It's not very = useful because it doesn't provide the recipient any clue about how to = populate the missing fields. There's a semantic mis-match here as well, = since a JWE with pre-negotiation is still a JWE, just an incomplete one. = =20 > =20 > A dedicated flag field like SPI provides a clearer indication, and it = also provides a hook that out-of-band protocols can use to connect in = the pre-negotiated parameters. > =20 > --Richard > =20 > =20 >=20 > On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones = wrote: > Russ, I'm curious why you say that the "spi" field needs to be in the = base spec. =46rom a spec factoring point of view, even if SPI remains a = completely separate spec and nothing is said in the base spec, there = would be no confusion or conflicts, including for implementations. = Here's why: > - A header without an "alg" field is not recognized as a JWS or JWE, = so there's no conflict there > - A JWS or JWE can legally contain a "spi" header field and a = registry is already provided to define the meanings of additional header = fields, so there's no conflict there either >=20 > Therefore, it seems like the separate spec could use the registry to = define the meaning of "spi" in a JWS and JWE and could furthermore = define the semantics of objects using headers without an "alg" field but = including a "spi" field. No conflicts. And clear separation of = concerns. >=20 > Those wanting the SPI functionality could use it. Those not needing = it would need to do nothing - which I think is as it should be. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Friday, April 19, 2013 8:37 AM > To: odonoghue@isoc.org; jose@ietf.org > Subject: Re: [jose] Feedback request on jose tracker issue #8: Should = we add a "spi" header field? >=20 > Combination of 1 and 2. The field needs to be in the base = specifications, but the only rule that needs to be included in the base = specification is an exact match of the identifier. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > 1. Have draft-barnes-jose-spi remain a separate specification that = could optionally also be supported by JWS and JWE implementations. > 2. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as a mandatory feature. > 3. Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as an optional feature. > 4. Another resolution (please specify in detail). >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_5FB27783-ADCC-4A94-8BED-495A7B17465E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes using "alg":"spi" is = cleaner and allowed by the current spec.  I am not keen on omitting = alg as a flag.

On 2013-04-19, at 3:10 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

BTW, in terms of a = =93dedicated flag=94, I=92d previously suggested to Richard in private = communication that one way for the SPI spec to do his cleanly would be = to use =93alg=94: =93spi=94, rather than omitting the =93alg=94 field = entirely.  The =93spi=94 value would then be registered by the SPI = spec in the algorithms registry =96 pointing back to the SPI = spec.
 
I personally think that this is cleaner than = just omitting =93alg=94, since it maintains the invariant that all JWS = and JWE representations have an =93alg=94 value that is used to = determine the processing rules.
 
 
From: Russ Housley = [mailto:housley@vigilsec.com] 
Sent: Friday, April 19, 2013 = 10:51 AM
To: Richard Barnes; Mike = Jones
Cc: Karen O'Donoghue; jose@ietf.org
Subject: Re: [jose] Feedback request = on jose tracker issue #8: Should we add a "spi" header = field?
On = Apr 19, 2013, at 1:42 PM, Richard Barnes = wrote:
In principle, = you could use the omission of the "alg" field as a signal that = pre-negotiation is going on.  However, that seems like not the most = useful way to do it, and it conflicts with current practice -- namely = the examples currently in the JWE and JWS specs.  Those examples = use pre-negotiation, but they also have an "alg" field.  It's not = very useful because it doesn't provide the recipient any clue about how = to populate the missing fields.  There's a semantic mis-match here = as well, since a JWE with pre-negotiation is still a JWE, just an = incomplete one.  
A = dedicated flag field like SPI provides a clearer indication, and it also = provides a hook that out-of-band protocols can use to connect in the = pre-negotiated parameters.
 
--Richard
 

 

On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones <Russ, I'm curious why you say that the "spi" field = needs to be in the base spec.  =46rom a spec factoring point of = view, even if SPI remains a completely separate spec and nothing is said = in the base spec, there would be no confusion or conflicts, including = for implementations.  Here's why:
  - A header without an = "alg" field is not recognized as a JWS or JWE, so there's no conflict = there
  - A JWS or JWE can legally contain a "spi" header field = and a registry is already provided to define the meanings of additional = header fields, so there's no conflict there either

Therefore, it = seems like the separate spec could use the registry to define the = meaning of "spi" in a JWS and JWE and could furthermore define the = semantics of objects using headers without an "alg" field but including = a "spi" field.  No conflicts.  And clear separation of = concerns.

Those wanting the SPI functionality could use it. =  Those not needing it would need to do nothing - which I think is = as it should be.

              =                   Best = wishes,
                =                 -- = Mike
 jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Russ Housley
Sent: Friday, April 19, 2013 8:37 AM
To: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request = on jose tracker issue #8: Should we add a "spi" header = field?

Combination of 1 and 2.  The field needs to be in the = base specifications, but the only rule that needs to be included in the = base specification is an exact match of the = identifier.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D

1.  Have draft-barnes-jose-spi remain a separate = specification that could optionally also be supported by JWS and JWE = implementations.
2.  Incorporate draft-barnes-jose-spi into the = JWS and JWE specifications as a mandatory feature.
3. =  Incorporate draft-barnes-jose-spi into the JWS and JWE = specifications as an optional feature.
4.  Another resolution = (please specify in = detail).

_______________________________________________
jose = mailing list
jose@ietf.org
jose@ietf.org
 
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_5FB27783-ADCC-4A94-8BED-495A7B17465E-- --Apple-Mail=_792D59CA-9110-45EA-8BE4-5DF12B790F36 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDE5MTgzMzU4WjAjBgkqhkiG9w0BCQQxFgQU3zKEi/rn HRdZnITpyWYM9nlF6SYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEANDFkEFUGvmuvwHxzaRMKfGdXOQFzXs1wNfqUs1z9 khgPEXmxxBJlRdNCuNlZ0E6byAVY2CW5V4lWSjJ9vMxfJUOSWDvBQtwB5eAixHb3VhuUTJID719n 9b4iwi2v4Kvf1P5GRQHm+eg7ZIITL/Un/uTbiBrSvMbqbfZSn6OaJG/le1HKrE9Mv23OS8LTlXBd n6dIqlmbnwqaAUnwkmHKzllrw94Vux+8Z4bsF0RBnoykvqDlejR+JcNODSKwAAbrPV5XCK0sY1zc JJIcWNRVlGRGjwPeSCtdSNC/+20ooDwii3pKUbRwGgxVt4UQ1e08wheNkUuFRI7eM5brv1bEUgAA AAAAAA== --Apple-Mail=_792D59CA-9110-45EA-8BE4-5DF12B790F36-- From rlb@ipv.sx Fri Apr 19 11:46:46 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D62821F92B2 for ; Fri, 19 Apr 2013 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI-1ffzIdBrM for ; Fri, 19 Apr 2013 11:46:45 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8721F925B for ; Fri, 19 Apr 2013 11:46:45 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h2so554720oag.17 for ; Fri, 19 Apr 2013 11:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=f4KgXa9qXTLCtIZns4nHZYPAkX6qozNtKIlH+EuEEE4=; b=hx0QbKrVT52+G2Qz8tMOIgjyss1+17ixmDz7Li0LBUsng7w4ov0lUwcWMcGMt/UJzm 09DFrW/bpL/lATHPPvbv4SB9rPP3sW9eqrZVypi8FTlOtcZ6KrN9plPhdWg8eroUPv8y 8BKtXi6Qa62osCDKCr+UT6xA20LCZLFnttf2RBaXlFMJxqm43TXMuVZLUvKeamVzK7AZ za+oSQ/KNoI8DraW88najIuDE5iCN4ODHWGsWkpVAV2pXTLBLJmxJQ/uwqK5Ih01UwDO 8IjAWoVcosxmOvs7A1PbKkBIt5gLfBQROMG7I2CL3UIc8Wege9P92h5M9Fk2p9UxH/VF /WGQ== MIME-Version: 1.0 X-Received: by 10.60.15.98 with SMTP id w2mr4627282oec.128.1366397205099; Fri, 19 Apr 2013 11:46:45 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Fri, 19 Apr 2013 11:46:44 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <44ED17C2-D855-4549-B098-96515D4AE954@vigilsec.com> References: <44ED17C2-D855-4549-B098-96515D4AE954@vigilsec.com> Date: Fri, 19 Apr 2013 14:46:44 -0400 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: multipart/alternative; boundary=089e013a0a1e084c1804dabb2470 X-Gm-Message-State: ALoCoQk3aSEUrJKRLzJWqUpuuI/+3u+mrdW6+MvWjskqkjCfXNLS6+jhbqPWMpNoEZh+MX95iyog Cc: "jose@ietf.org" , Karen ODonoghue Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:46:46 -0000 --089e013a0a1e084c1804dabb2470 Content-Type: text/plain; charset=ISO-8859-1 IV should not be at issue here. RFC 5116 doesn't do anything with IVs, and all libraries I know of have a separate IV and cipher text fields. So we let's keep those separate. On Fri, Apr 19, 2013 at 2:25 PM, Russ Housley wrote: > 2. Switch to using the RFC 5116 (AEAD) serialization ... > > And, when using a mode like CBC, simply prepend the IV to the ciphertext. > > Russ > > = = = = = = = = = > > > Which of these best describes your preferences on this issue? > 1. Continue having separate Ciphertext, Initialization Vector, and > Integrity Value values in the JWE representation. > 2. Switch to using the RFC 5116 (AEAD) serialization to represent the > combination of these three values. > 3. Another resolution (please specify in detail). > 0. I need more information to decide. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e013a0a1e084c1804dabb2470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IV should not be at issue here. =A0RFC 5116 doesn't do= anything with IVs, and all libraries I know of have a separate IV and ciph= er text fields. =A0So we let's keep those separate.


On Fri, Apr 19, 2013 at 2:25 PM, Russ Ho= usley <housley@vigilsec.com> wrote:
2. =A0Switch to using the RFC 5116 (AEAD) serialization ...

And, when using a mode like CBC, simply prepend the IV to the ciphertext.
Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D


Which of these best describes your preferences on this issue?
1. =A0Continue having separate Ciphertext, Initialization Vector, and
Integrity Value values in the JWE representation.
2. =A0Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.
3. =A0Another resolution (please specify in detail).
0. =A0I need more information to decide.

_____________________________= __________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e013a0a1e084c1804dabb2470-- From sal@idmachines.com Fri Apr 19 19:38:36 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826B821F9265 for ; Fri, 19 Apr 2013 19:38:36 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYgHhdSInIaR for ; Fri, 19 Apr 2013 19:38:35 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 932DE21F91CA for ; Fri, 19 Apr 2013 19:38:35 -0700 (PDT) Received: from mailpod1.hostingplatform.com ([10.30.71.118]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r3K2cX1q029341 for ; Fri, 19 Apr 2013 22:38:33 -0400 Received: (qmail 19951 invoked by uid 0); 20 Apr 2013 02:38:32 -0000 Received: from unknown (HELO salPC) (sal@idmachines.com@74.104.35.96) by 0 with ESMTPA; 20 Apr 2013 02:38:32 -0000 From: "Salvatore D'Agostino" To: "'Karen ODonoghue'" References: <51674E17.5020902@isoc.org> <5170B20D.8040305@gluu.org> In-Reply-To: Date: Fri, 19 Apr 2013 22:38:31 -0400 Message-ID: <06a201ce3d70$25f7c770$71e75650$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac483nHNftXn/DWRSEGbdq3RutLsdwAkUyEQ Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_069E_01CE3D4E.8FC8D490"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #7: Algorithm identifiers/parameters incompatible with WebCrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 02:38:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_069E_01CE3D4E.8FC8D490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1 Salvatore D'Agostino, CSCIP IDmachines LLC |1264 Beacon Street, #5 | Brookline, MA 02446 | USA http:\\www.idmachines.com | http:\\idmachines.blogspot.com | @idmachines +1 617.201.4809 ph | +1 617.812.6495 fax > > > On Thu, Apr 11, 2013 at 7:58 PM, Karen O'Donoghue wrote: > > Issue #7 http://trac.tools.ietf.org/wg/jose/trac/ticket/7 points out > that the JWA algorithm identifiers are different than those used by > the W3C WebCrypto draft at http://www.w3.org/TR/WebCryptoAPI/. The > JWA algorithm identifiers are strings, whereas the W3C WebCrypto > algorithm identifiers are structures including string identifiers. > The working group had previously decided to continue representing JOSE > algorithms as strings, as recorded at > http://www.ietf.org/mail-archive/web/jose/current/msg01219.html. > **** > > > Which of these best describes your preferences on this issue?**** > > 1. Continue have the JWA algorithm identifiers be strings, and not > objects. Note that WebCrypto may choose to use some of these same > strings, where applicable.**** > > 2. Switch to using the algorithm identifier structures defined in the > WebCrypto draft.**** > > 3. Another resolution (please specify in detail).**** > > 0. I need more information to decide.**** > > Your reply is requested by Friday, April 19th or earlier. > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > ------=_NextPart_000_069E_01CE3D4E.8FC8D490 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAxNisl hAwmPFmhraHt/QtWMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEyMTAyMjAwMDAwMFoXDTEzMTAyMjIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyMUItbfY tMuC9vO6iN41DxtnlxM682Fr96jQQGvpQzUrj4tNMHUlad9Fge5rCHPryqG2bEATpf/fCunOsV9C 9D5+khqCpZlQzk6vdKxnHgv4tFv7KAv+6DxS9GCqgbNSLo1WSh16FnlwRAZT4jUd59GB5uHjxvEZ E4eOAEKL+izQIEBzpMMDxDOS4J2wU3W88mCPLcuEESGKE5QUgRV2ARmyWMPdJhpFUpZGJv183zYf JLLa6+mgd+cWbfPp3GUs+/xdpSd3gRY64XCsyPmygWC+zrw2XJW+bL1Ge+m5sUJ5DJSGE1XENdvj 2z6j0q56G1Q8SJrAY76XrTrNnGrMiwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFGSBNSyMTkmxv/++DoKmF05IEiYnMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQA+jYBRYaQc2qf+SipdyHuI7A9W76ZCWAqCmeez66TNECSjbcvA pw1HEKiehUGT4BiGSqTEBLnXM4pqsD5vUZLMiFnVAXhkgkNAOBZFq9G/bJSPW6pW9cNIjWifyAtn wdqYXakYWQIuws08lYfGM/751/DXPioEuFSv0pqfCm/r9ashpU9+qMSmX4+nmS5VuUtRrVsyujq9 lQ0Jic737mkW6iVDIJzg4oE2ujL7l6dJBM5VdbCJns4y/R2iBn5JfIcO8ZACDuw/If558mBvhRzI K5iBLkgqVKM6C/XTQ9Z+rc0YOaooiOn2CO4hILdhicFwr8M6V5cTBMltmrfOLqwyMYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39 C1YwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNDIwMDIzODA2WjAjBgkqhkiG9w0BCQQxFgQUe6my3O/DJK83DxvhTBWOip42BjAwgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMTYrJYQMJjxZoa2h7f0LVjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39C1YwDQYJKoZIhvcN AQEBBQAEggEAKxJyA6HRbDjr1KXufNXo2rvNkiXpekgb/rtbU4mmFnN1BRcMupBo4sSNPSO9nqMj Vujcb4Bx8IZPCkrwKXlUzOMKH5VPRAtfBKMHdZxroM5TVPdeaB/yEx0GvpYfvMW4n9Xsi7Mmx2Lf J11oqD76hfukAMaDgMEUMuxPDO9U+wRkznTSCZ1bJ3dHGfN4VEXtzCgMdTZ+8yUVWgYxeFQRCcAj atVhsza4FZmbcjbI/uz+8xyARftbttQGUvtJ0kRi9W7Lo5rVk7edlXCzSnsmvL+cyzmK9CGx2bSs lrJJmE0VtLrkj+83mMl2IyfeNfk5zvnxmYWfv34MJDwRHgty6gAAAAAAAA== ------=_NextPart_000_069E_01CE3D4E.8FC8D490-- From sal@idmachines.com Fri Apr 19 19:39:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632A621F8F0F for ; Fri, 19 Apr 2013 19:39:38 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys8ClOYsCaLp for ; Fri, 19 Apr 2013 19:39:37 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5DA21F8EC6 for ; Fri, 19 Apr 2013 19:39:36 -0700 (PDT) Received: from mailpod1.hostingplatform.com ([10.30.71.113]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r3K2dYeE011777 for ; Fri, 19 Apr 2013 22:39:34 -0400 Received: (qmail 4494 invoked by uid 0); 20 Apr 2013 02:39:33 -0000 Received: from unknown (HELO salPC) (sal@idmachines.com@74.104.35.96) by 0 with ESMTPA; 20 Apr 2013 02:39:33 -0000 From: "Salvatore D'Agostino" To: References: <51674E2D.3040604@isoc.org> <260FAD4C9002884C89DF49EF8776EB9B2A9811513C@DFW1MBX21.mex07a.mlsrvr.com> In-Reply-To: <260FAD4C9002884C89DF49EF8776EB9B2A9811513C@DFW1MBX21.mex07a.mlsrvr.com> Date: Fri, 19 Apr 2013 22:39:32 -0400 Message-ID: <06ad01ce3d70$4a406a10$dec13e30$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac47njKX6TxLCycWTrauXYRaLSmvWgB0gQoQ Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_06A5_01CE3D4E.BE90FF00"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 02:39:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06A5_01CE3D4E.BE90FF00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06A6_01CE3D4E.BE90FF00" ------=_NextPart_001_06A6_01CE3D4E.BE90FF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1 Salvatore D'Agostino, CSCIP IDmachines LLC |1264 Beacon Street, #5 | Brookline, MA 02446 | USA http:\\www.idmachines.com | http:\\idmachines.blogspot.com | @idmachines +1 617.201.4809 ph | +1 617.812.6495 fax From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Thursday, April 11, 2013 4:59 PM To: jose@ietf.org Subject: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Issue #8 http://trac.tools.ietf.org/wg/jose/trac/ticket/8 proposes adding an "spi" (security parameters index) header parameter to the JWS and JWE specifications. This modification to the JOSE formats would allow for signaling that pre-negotiated cryptographic parameters are being used, rather than including those parameters in the JWS or JWE header. This proposal has been written up as http://tools.ietf.org/html/draft-barnes-jose-spi-00. Which of these best describes your preferences on this issue? 1. Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature. 4. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. ------=_NextPart_001_06A6_01CE3D4E.BE90FF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1

 

 

 

Salvatore D'Agostino, = CSCIP

IDmachines LLC |1264 Beacon Street, #5 | = Brookline, MA  02446 | USA

http:\\www.idmachines.com | http:\\idmachines.blogspot.com | = @idmachines

+1 617.201.4809 ph | +1 617.812.6495 = fax

 

From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] = On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, = 2013 4:59 PM
To: jose@ietf.org
Subject: = [jose] Feedback request on jose tracker issue #8: Should we add a = "spi" header field?

 

Issue #8 http://trac.too= ls.ietf.org/wg/jose/trac/ticket/8 proposes adding an = “spi” (security parameters index) header parameter to the = JWS and JWE specifications.  This modification to the JOSE formats = would allow for signaling that pre-negotiated cryptographic parameters = are being used, rather than including those parameters in the JWS or JWE = header.  This proposal has been written up as http://tools= .ietf.org/html/draft-barnes-jose-spi-00.

 <= /o:p>

Which of = these best describes your preferences on this issue?

1.  = Have draft-barnes-jose-spi remain a separate specification that could = optionally also be supported by JWS and JWE = implementations.

2.  = Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as = a mandatory feature.

3.  = Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as = an optional feature.

4.  = Another resolution (please specify in detail).

0.  I = need more information to decide.

Your = reply is requested by Friday, April 19th or earlier. =

------=_NextPart_001_06A6_01CE3D4E.BE90FF00-- ------=_NextPart_000_06A5_01CE3D4E.BE90FF00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAxNisl hAwmPFmhraHt/QtWMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEyMTAyMjAwMDAwMFoXDTEzMTAyMjIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyMUItbfY tMuC9vO6iN41DxtnlxM682Fr96jQQGvpQzUrj4tNMHUlad9Fge5rCHPryqG2bEATpf/fCunOsV9C 9D5+khqCpZlQzk6vdKxnHgv4tFv7KAv+6DxS9GCqgbNSLo1WSh16FnlwRAZT4jUd59GB5uHjxvEZ E4eOAEKL+izQIEBzpMMDxDOS4J2wU3W88mCPLcuEESGKE5QUgRV2ARmyWMPdJhpFUpZGJv183zYf JLLa6+mgd+cWbfPp3GUs+/xdpSd3gRY64XCsyPmygWC+zrw2XJW+bL1Ge+m5sUJ5DJSGE1XENdvj 2z6j0q56G1Q8SJrAY76XrTrNnGrMiwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFGSBNSyMTkmxv/++DoKmF05IEiYnMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQA+jYBRYaQc2qf+SipdyHuI7A9W76ZCWAqCmeez66TNECSjbcvA pw1HEKiehUGT4BiGSqTEBLnXM4pqsD5vUZLMiFnVAXhkgkNAOBZFq9G/bJSPW6pW9cNIjWifyAtn wdqYXakYWQIuws08lYfGM/751/DXPioEuFSv0pqfCm/r9ashpU9+qMSmX4+nmS5VuUtRrVsyujq9 lQ0Jic737mkW6iVDIJzg4oE2ujL7l6dJBM5VdbCJns4y/R2iBn5JfIcO8ZACDuw/If558mBvhRzI K5iBLkgqVKM6C/XTQ9Z+rc0YOaooiOn2CO4hILdhicFwr8M6V5cTBMltmrfOLqwyMYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39 C1YwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNDIwMDIzOTI1WjAjBgkqhkiG9w0BCQQxFgQU0dxvc0iXEH3oQgLMFvyzbEBFvRwwgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMTYrJYQMJjxZoa2h7f0LVjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39C1YwDQYJKoZIhvcN AQEBBQAEggEAiL6EWhmflF6nUnd27Q/903KHbRrxM3D4jkEBUf7OA+NS/lGRh++z3TmTRxW08l/5 c/kSDITRunebhh8bf1d2lv0hQQGnlk9B0ofJvgEMgrOoK6iC4spqBuRAXCfbOcs6tjKTGsqE3cuC rc9QV7HWCSEIcifA9G4oQg8D6ua4qzBcxJTqE43w9yaR9qU5CPRcSXQnqMzf+/rAJJhBtbETH5pA zz4pBQK7febP1Et0UprrtwBSuiH07lpqx372XTHu9N7FiVWHMFuoCzZ06Qyu1PH45hzASylVQtIy 5J4d+Yga2vD4Y3XUDnsqcmf812rw5nEQRg2Q4LOlYd9TPthBWwAAAAAAAA== ------=_NextPart_000_06A5_01CE3D4E.BE90FF00-- From sal@idmachines.com Fri Apr 19 19:41:28 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7E021F9164 for ; Fri, 19 Apr 2013 19:41:28 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUibSgYqCIea for ; Fri, 19 Apr 2013 19:41:27 -0700 (PDT) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id A68A821F8F0F for ; Fri, 19 Apr 2013 19:41:27 -0700 (PDT) Received: from mailpod1.hostingplatform.com ([10.30.71.116]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r3K2fQIp008856 for ; Fri, 19 Apr 2013 22:41:26 -0400 Received: (qmail 32431 invoked by uid 0); 20 Apr 2013 02:41:26 -0000 Received: from unknown (HELO salPC) (sal@idmachines.com@74.104.35.96) by 0 with ESMTPA; 20 Apr 2013 02:41:26 -0000 From: "Salvatore D'Agostino" To: References: <51674E3D.7030004@isoc.org> <92D56D5A-C8E3-4143-9976-409D3E6975C3@adm.umu.se> <4E1F6AAD24975D4BA5B168042967394367641218@TK5EX14MBXC283.redmond.corp.microsoft.com> <354223120e2d40b0aea99253c7a15400@BY2PR03MB041.namprd03.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E1150C90EC77@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C90EC77@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 19 Apr 2013 22:41:25 -0400 Message-ID: <06b501ce3d70$8d50fe50$a7f2faf0$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac471+vG40O8lGoASna9eh8B7NcgiQBmHDtA Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_06B1_01CE3D4F.01F30EA0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Subject: Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 02:41:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06B1_01CE3D4F.01F30EA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 1 Sal D'Agostino 12 apr 2013 kl. 01:58 skrev Karen O'Donoghue : Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values. If this proposal is adopted, JWEs would then have three fields - the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. This issue is also related to issue #3. Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116. Which of these best describes your preferences on this issue? 1. Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation. 2. Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values. 3. Another resolution (please specify in detail). 0. I need more information to decide. Your reply is requested by Friday, April 19th or earlier. ------=_NextPart_000_06B1_01CE3D4F.01F30EA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAxNisl hAwmPFmhraHt/QtWMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEyMTAyMjAwMDAwMFoXDTEzMTAyMjIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyMUItbfY tMuC9vO6iN41DxtnlxM682Fr96jQQGvpQzUrj4tNMHUlad9Fge5rCHPryqG2bEATpf/fCunOsV9C 9D5+khqCpZlQzk6vdKxnHgv4tFv7KAv+6DxS9GCqgbNSLo1WSh16FnlwRAZT4jUd59GB5uHjxvEZ E4eOAEKL+izQIEBzpMMDxDOS4J2wU3W88mCPLcuEESGKE5QUgRV2ARmyWMPdJhpFUpZGJv183zYf JLLa6+mgd+cWbfPp3GUs+/xdpSd3gRY64XCsyPmygWC+zrw2XJW+bL1Ge+m5sUJ5DJSGE1XENdvj 2z6j0q56G1Q8SJrAY76XrTrNnGrMiwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFGSBNSyMTkmxv/++DoKmF05IEiYnMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQA+jYBRYaQc2qf+SipdyHuI7A9W76ZCWAqCmeez66TNECSjbcvA pw1HEKiehUGT4BiGSqTEBLnXM4pqsD5vUZLMiFnVAXhkgkNAOBZFq9G/bJSPW6pW9cNIjWifyAtn wdqYXakYWQIuws08lYfGM/751/DXPioEuFSv0pqfCm/r9ashpU9+qMSmX4+nmS5VuUtRrVsyujq9 lQ0Jic737mkW6iVDIJzg4oE2ujL7l6dJBM5VdbCJns4y/R2iBn5JfIcO8ZACDuw/If558mBvhRzI K5iBLkgqVKM6C/XTQ9Z+rc0YOaooiOn2CO4hILdhicFwr8M6V5cTBMltmrfOLqwyMYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39 C1YwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNDIwMDI0MTE4WjAjBgkqhkiG9w0BCQQxFgQU5XSIzvYTmpL+xWKmJhL4Vyegc0YwgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMTYrJYQMJjxZoa2h7f0LVjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39C1YwDQYJKoZIhvcN AQEBBQAEggEAOfxTZHaPvZFeycRlc//e6J6VROjM4mkR4sPCOvsxP6lafd09RJNw5LJpHvXTyEVT GKJdYyDiXoQbWarfpMBx7PyTGqQWipLFiID6U8YJ9orFJFnaQbQ4D37yb7Lzv/CJoug+gJVdfDtq 1i7Lz4l4BS2fw09uymUQpV6z5fP8rZrdnjvemVlaSzEh7T1ogejYwh5uMuIbVcAjzDA4wnzTPPMc UUADaAeB4kipxIGZE2UPrayEXaii1dpMqHXz/Dkjj/5a2xB8mLpRLFnZVIzu5ZQXIaW1omE1gmLZ bygTL0yTE//KBkoxsOvvZur1HsmyiZiShHY8aFh0xaeq/dC+ZwAAAAAAAA== ------=_NextPart_000_06B1_01CE3D4F.01F30EA0-- From sal@idmachines.com Fri Apr 19 19:42:49 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66921F92F2 for ; Fri, 19 Apr 2013 19:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3CCzyNUNYo5 for ; Fri, 19 Apr 2013 19:42:48 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3419A21F9265 for ; Fri, 19 Apr 2013 19:42:48 -0700 (PDT) Received: from mailpod1.hostingplatform.com ([10.30.71.120]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r3K2glU1024840 for ; Fri, 19 Apr 2013 22:42:47 -0400 Received: (qmail 15724 invoked by uid 0); 20 Apr 2013 02:42:46 -0000 Received: from unknown (HELO salPC) (sal@idmachines.com@74.104.35.96) by 0 with ESMTPA; 20 Apr 2013 02:42:46 -0000 From: "Salvatore D'Agostino" To: References: <51674E63.3050809@isoc.org> <8ACF653B-8300-45F9-9030-2C5B3BE271E9@ve7jtb.com> In-Reply-To: <8ACF653B-8300-45F9-9030-2C5B3BE271E9@ve7jtb.com> Date: Fri, 19 Apr 2013 22:42:45 -0400 Message-ID: <06c601ce3d70$bd2eb770$378c2650$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac47rfvJtH0yY0FKQG6H4VkhQfg56gBwptfg Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_06BE_01CE3D4F.317169B0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Cc: jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 02:42:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06BE_01CE3D4F.317169B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06BF_01CE3D4F.317169B0" ------=_NextPart_001_06BF_01CE3D4F.317169B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1, sorry for late replies hectic week here in Boston. Sal D'Agostino On 2013-04-11, at 8:59 PM, Karen O'Donoghue wrote: Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a "kid" field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important? Which of these best describes your preferences on this issue? 1. Yes. 2. No. 0. I need more information to decide. Your reply is requested by Friday, April 19th (or earlier). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_001_06BF_01CE3D4F.317169B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1, sorry for late replies hectic week here in = Boston.

 

Sal D’Agostino

 

On = 2013-04-11, at 8:59 PM, Karen O'Donoghue <odonoghue@isoc.org> = wrote:

 



Issue = #15 http://trac.to= ols.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key = indicator, such as a “kid” field, be required in all JWS and = JWE headers. Are use cases where key information is exchanged by means = other than the JWS or JWE headers important?

Which of = these best describes your preferences on this issue?

1.  = Yes.

2. &nbs= p; No.

0.  I = need more information to decide.

 <= /o:p>

Your reply is requested by Friday, April = 19th (or earlier).

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

 

------=_NextPart_001_06BF_01CE3D4F.317169B0-- ------=_NextPart_000_06BE_01CE3D4F.317169B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAxNisl hAwmPFmhraHt/QtWMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEyMTAyMjAwMDAwMFoXDTEzMTAyMjIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyMUItbfY tMuC9vO6iN41DxtnlxM682Fr96jQQGvpQzUrj4tNMHUlad9Fge5rCHPryqG2bEATpf/fCunOsV9C 9D5+khqCpZlQzk6vdKxnHgv4tFv7KAv+6DxS9GCqgbNSLo1WSh16FnlwRAZT4jUd59GB5uHjxvEZ E4eOAEKL+izQIEBzpMMDxDOS4J2wU3W88mCPLcuEESGKE5QUgRV2ARmyWMPdJhpFUpZGJv183zYf JLLa6+mgd+cWbfPp3GUs+/xdpSd3gRY64XCsyPmygWC+zrw2XJW+bL1Ge+m5sUJ5DJSGE1XENdvj 2z6j0q56G1Q8SJrAY76XrTrNnGrMiwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFGSBNSyMTkmxv/++DoKmF05IEiYnMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQA+jYBRYaQc2qf+SipdyHuI7A9W76ZCWAqCmeez66TNECSjbcvA pw1HEKiehUGT4BiGSqTEBLnXM4pqsD5vUZLMiFnVAXhkgkNAOBZFq9G/bJSPW6pW9cNIjWifyAtn wdqYXakYWQIuws08lYfGM/751/DXPioEuFSv0pqfCm/r9ashpU9+qMSmX4+nmS5VuUtRrVsyujq9 lQ0Jic737mkW6iVDIJzg4oE2ujL7l6dJBM5VdbCJns4y/R2iBn5JfIcO8ZACDuw/If558mBvhRzI K5iBLkgqVKM6C/XTQ9Z+rc0YOaooiOn2CO4hILdhicFwr8M6V5cTBMltmrfOLqwyMYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39 C1YwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNDIwMDI0MjM4WjAjBgkqhkiG9w0BCQQxFgQU94fNJuBFeNIpGpftGHolPDbwFbgwgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMTYrJYQMJjxZoa2h7f0LVjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39C1YwDQYJKoZIhvcN AQEBBQAEggEAuvbwmHHn9Km9tsROAT/QozMLs8/EaCmrp8m2u07bOPkHbfsmADj0/yNFHw42KAor MlFqngRVj+/rgaiyQ7tSDU0tU6CtVDJm9rl/puq2Adkw9dgBMKCRgFGRI7wOA9lHaz0wLiyhB2l1 rYKnhmTK9LfwhANtQm3lSPe6Ms5rDViZwYCLRRnEU994eB7JmNyG1MiawWk5HGKjoNWJaIsToHUW cXkB06x8M4nGzsM4pXaOB+mNqGB+ITDYal0CINcJ6OVyGHSTFwB21RkLofXGBsVFEmGrRlWpNdXN PunlTkceRBjIVv8gfkGDVqIG/BIgvyVte6XcXzajF+P9/jknPwAAAAAAAA== ------=_NextPart_000_06BE_01CE3D4F.317169B0-- From vladimir@nimbusds.com Sat Apr 20 04:19:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B44921F86EA for ; Sat, 20 Apr 2013 04:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL3una2rCygM for ; Sat, 20 Apr 2013 04:19:28 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 1F53121F86D3 for ; Sat, 20 Apr 2013 04:19:27 -0700 (PDT) Received: (qmail 10935 invoked from network); 20 Apr 2013 11:19:26 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 20 Apr 2013 11:19:25 -0000 Received: (qmail 8122 invoked by uid 99); 20 Apr 2013 11:19:26 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.85.163 User-Agent: Workspace Webmail 5.6.36 Message-Id: <20130420041925.cc40c4f3d92d2001859047cd8cabb9ab.8f64bcaad5.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Mike Jones" , jose@ietf.org Date: Sat, 20 Apr 2013 04:19:25 -0700 Mime-Version: 1.0 Subject: Re: [jose] =?utf-8?q?Feedback_request_on_jose_tracker_issue_=238=3A_S?= =?utf-8?q?hould_we_add_a_=22spi=22_header_field=3F?= X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 11:19:30 -0000 +1 This looks like a neat way to link the proposed SPI spec to the base=0AJ= WS/JWE specs without requiring the latter to be changed (or be aware of=0At= he SPI extension). In terms of coding in SPI support, I also imagine=0Athat= to be easier to implement with our Nimbus JOSE+JWT library in mind=0A- by = simply adding a new JWS/JWE handler for "spi" algs, with none of=0Athe core= JOSE classes needing to be reworked.=0A=0AVladimir=0A=0A--=0AVladimir Dzhu= vinov : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A-------- Original = Message --------=0ASubject: Re: [jose] Feedback request on jose tracker iss= ue #8: Should we=0Aadd a "spi" header field?=0AFrom: Mike Jones =0ADate: Fri, April 19, 2013 7:10 pm=0ATo: Russ Housley <= housley@vigilsec.com>, Richard Barnes =0ACc: "jose@ietf.org" , Karen O'Donoghue=0A=0A=0A BTW, in terms= of a =E2=80=9Cdedicated flag=E2=80=9D, I=E2=80=99d previously suggested to= =0ARichard in private communication that one way for the SPI spec to do his= =0Acleanly would be to use =E2=80=9Calg=E2=80=9D: =E2=80=9Cspi=E2=80=9D, ra= ther than omitting the=0A=E2=80=9Calg=E2=80=9D field entirely. The =E2=80= =9Cspi=E2=80=9D value would then be registered=0Aby the SPI spec in the alg= orithms registry =E2=80=93 pointing back to the SPI=0Aspec.=0A =0A I perso= nally think that this is cleaner than just omitting =E2=80=9Calg=E2=80=9D,= =0Asince it maintains the invariant that all JWS and JWE representations=0A= have an =E2=80=9Calg=E2=80=9D value that is used to determine the processin= g rules.=0A =0A = Cheers,=0A = -- Mike=0A =0A From: Russ Housley [mailto:housley@vigilsec.com] = =0A Sent: Friday, April 19, 2013 10:51 AM=0A To: Richard Barnes; Mike Jones= =0A Cc: Karen O'Donoghue; jose@ietf.org=0A Subject: Re: [jose] Feedback req= uest on jose tracker issue #8: Should=0Awe add a "spi" header field?=0A =0A= =0A =0A +1=0A =0A =0A =0A On Apr 19, 2013, at 1:42 PM, Richard Barnes w= rote:=0A =0A=0A =0A =0A In principle, you could use the omission of the "a= lg" field as a=0Asignal that pre-negotiation is going on. However, that se= ems like not=0Athe most useful way to do it, and it conflicts with current = practice --=0Anamely the examples currently in the JWE and JWS specs. Thos= e examples=0Ause pre-negotiation, but they also have an "alg" field. It's = not very=0Auseful because it doesn't provide the recipient any clue about h= ow to=0Apopulate the missing fields. There's a semantic mis-match here as = well,=0Asince a JWE with pre-negotiation is still a JWE, just an incomplete= one.=0A =0A =0A =0AA dedicated flag field like SPI provides a clearer in= dication, and it=0Aalso provides a hook that out-of-band protocols can use = to connect in=0Athe pre-negotiated parameters.=0A =0A =0A =0A--Richard=0A = =0A =0A =0A=0A=0A =0A On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones=0A wrote:=0A Russ, I'm curious why you say that the "= spi" field needs to be in the=0Abase spec. From a spec factoring point of = view, even if SPI remains a=0Acompletely separate spec and nothing is said = in the base spec, there=0Awould be no confusion or conflicts, including for= implementations. =0AHere's why:=0A - A header without an "alg" field is = not recognized as a JWS or JWE,=0Aso there's no conflict there=0A - A JWS= or JWE can legally contain a "spi" header field and a=0Aregistry is alread= y provided to define the meanings of additional header=0Afields, so there's= no conflict there either=0A =0A Therefore, it seems like the separate spec= could use the registry to=0Adefine the meaning of "spi" in a JWS and JWE a= nd could furthermore=0Adefine the semantics of objects using headers withou= t an "alg" field but=0Aincluding a "spi" field. No conflicts. And clear s= eparation of=0Aconcerns.=0A =0A Those wanting the SPI functionality could u= se it. Those not needing it=0Awould need to do nothing - which I think is = as it should be.=0A =0A Best wishes,=0A = -- Mike=0A =0A -----Original Message-----=0A= From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of=0A= Russ Housley=0A Sent: Friday, April 19, 2013 8:37 AM=0A To: odonoghue@isoc.= org; jose@ietf.org=0A Subject: Re: [jose] Feedback request on jose tracker= issue #8: Should=0Awe add a "spi" header field?=0A =0A Combination of 1 an= d 2. The field needs to be in the base=0Aspecifications, but the only rule= that needs to be included in the base=0Aspecification is an exact match of= the identifier.=0A =0A Russ=0A =0A =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D= =0A =0A 1. Have draft-barnes-jose-spi remain a separate specification that= =0Acould optionally also be supported by JWS and JWE implementations.=0A 2.= Incorporate draft-barnes-jose-spi into the JWS and JWE=0Aspecifications a= s a mandatory feature.=0A 3. Incorporate draft-barnes-jose-spi into the JW= S and JWE=0Aspecifications as an optional feature.=0A 4. Another resolutio= n (please specify in detail).=0A =0A ______________________________________= _________=0A jose mailing list=0A jose@ietf.org=0A https://www.ietf.org/mai= lman/listinfo/jose=0A _______________________________________________=0A jo= se mailing list=0A jose@ietf.org=0A https://www.ietf.org/mailman/listinfo/j= ose=0A =0A=0A=0A =0A =0A=0A =0A =0A=0A_____________________________________= __________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailm= an/listinfo/jose From sakimura@gmail.com Sat Apr 20 08:03:01 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E644B21F91BF for ; Sat, 20 Apr 2013 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVx1MWrDry-N for ; Sat, 20 Apr 2013 08:03:00 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id D57C921F91B2 for ; Sat, 20 Apr 2013 08:02:59 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id o10so4490867lbi.20 for ; Sat, 20 Apr 2013 08:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=0b3UQ/wNLqwiZ0TPeUsqVW4hZ+0mCVfvpLyVenwZTXI=; b=ufk0BvcS9I1k+Kl/BuU6DYr0zLwZRv3bifGQ2vyibcHWE3Iii9vtq1vsgg00w0C2v4 OHyAoB2a8omPnmzMAeNKYyhTGVvaSObHx49FV9ELLW1lDowq3iFZcAZKaX215akYf5F9 aRcW+hl0HqPJoWzy9nbOOU/nTUHdK7n0MmaoUdqBbDvtFr4PTARdBottrERwun0qpXxW 4SKUGHORloBmw61kDCswbnaY+fRE7vYdGPjk5v9IMU2SxRFZdICNt1ILYE4acr/GjX75 y60J80Iy4BNIeOgx0IZdoJjS7zjHvMb+iRTyit4IpFmr8lN2o8L1ZHRmuW9Ai9HE2dBl s7Kg== X-Received: by 10.112.141.38 with SMTP id rl6mr9300341lbb.101.1366470178782; Sat, 20 Apr 2013 08:02:58 -0700 (PDT) References: <4E1F6AAD24975D4BA5B1680429673943676776F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <0072E7B1-1CD4-46DB-8954-52E795B5C861@vigilsec.com> <4E1F6AAD24975D4BA5B16804296739436767934E@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: Date: Sat, 20 Apr 2013 22:54:12 +0900 Message-ID: <-5894109702243771834@unknownmsgid> To: John Bradley Content-Type: multipart/alternative; boundary=001a11c2605a9a43c604dacc21db Cc: Richard Barnes , Mike Jones , Russ Housley , "jose@ietf.org" , Karen O'Donoghue Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 15:03:02 -0000 --001a11c2605a9a43c604dacc21db Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit +1 =nat via iPhone Apr 20, 2013 3:34$B!"(BJohn Bradley $B$N%a%C%;!<%8(B: Yes using "alg":"spi" is cleaner and allowed by the current spec. I am not keen on omitting alg as a flag. On 2013-04-19, at 3:10 PM, Mike Jones wrote: BTW, in terms of a $B!H(Bdedicated flag$B!I(B, I$B!G(Bd previously suggested to Richard in private communication that one way for the SPI spec to do his cleanly would be to use $B!H(Balg$B!I(B: $B!H(Bspi$B!I(B, rather than omitting the $B!H(Balg$B!I(B field entirely. The $B!H(Bspi$B!I(B value would then be registered by the SPI spec in the algorithms registry - pointing back to the SPI spec. I personally think that this is cleaner than just omitting $B!H(Balg$B!I(B, since it maintains the invariant that all JWS and JWE representations have an $B!H(Balg$B!I(B value that is used to determine the processing rules. Cheers, -- Mike *From:* Russ Housley [mailto:housley@vigilsec.com] *Sent:* Friday, April 19, 2013 10:51 AM *To:* Richard Barnes; Mike Jones *Cc:* Karen O'Donoghue; jose@ietf.org *Subject:* Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? +1 On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote: In principle, you could use the omission of the "alg" field as a signal that pre-negotiation is going on. However, that seems like not the most useful way to do it, and it conflicts with current practice -- namely the examples currently in the JWE and JWS specs. Those examples use pre-negotiation, but they also have an "alg" field. It's not very useful because it doesn't provide the recipient any clue about how to populate the missing fields. There's a semantic mis-match here as well, since a JWE with pre-negotiation is still a JWE, just an incomplete one. A dedicated flag field like SPI provides a clearer indication, and it also provides a hook that out-of-band protocols can use to connect in the pre-negotiated parameters. --Richard On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones wrote: Russ, I'm curious why you say that the "spi" field needs to be in the base spec. From a spec factoring point of view, even if SPI remains a completely separate spec and nothing is said in the base spec, there would be no confusion or conflicts, including for implementations. Here's why: - A header without an "alg" field is not recognized as a JWS or JWE, so there's no conflict there - A JWS or JWE can legally contain a "spi" header field and a registry is already provided to define the meanings of additional header fields, so there's no conflict there either Therefore, it seems like the separate spec could use the registry to define the meaning of "spi" in a JWS and JWE and could furthermore define the semantics of objects using headers without an "alg" field but including a "spi" field. No conflicts. And clear separation of concerns. Those wanting the SPI functionality could use it. Those not needing it would need to do nothing - which I think is as it should be. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Russ Housley Sent: Friday, April 19, 2013 8:37 AM To: odonoghue@isoc.org; jose@ietf.org Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Combination of 1 and 2. The field needs to be in the base specifications, but the only rule that needs to be included in the base specification is an exact match of the identifier. Russ = = = = = = = = = = 1. Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature. 4. Another resolution (please specify in detail). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --001a11c2605a9a43c604dacc21db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

=3Dnat via iPhone
<= div>
Apr 20, 2013 3:34=E3=80=81John Bradley <ve7jtb@ve7jtb.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8:

Ye= s using "alg":"spi" is cleaner and allowed by the curre= nt spec. =C2=A0I am not keen on omitting alg as a flag.

On 2013-04-19, at 3:10 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
BTW, in te= rms of a =E2=80=9Cdedicated flag=E2=80=9D, I=E2=80=99d previously suggested= to Richard in private communication that one way for the SPI spec to do hi= s cleanly would be to use =E2=80=9Calg=E2=80=9D: =E2=80=9Cspi=E2=80=9D, rat= her than omitting the =E2=80=9Calg=E2=80=9D field entirely.=C2=A0 The =E2= =80=9Cspi=E2=80=9D value would then be registered by the SPI spec in the al= gorithms registry =E2=80=93 pointing back to the SPI spec.
=C2=A0
I personally think that this is cleaner than just omitting =E2=80= =9Calg=E2=80=9D, since it maintains the invariant that all JWS and JWE repr= esentations have an =E2=80=9Calg=E2=80=9D value that is used to determine t= he processing rules.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Cheers,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -- Mike
=C2=A0
From:=C2=A0Russ Housley [mailto:housley@vigilsec.com]=C2=A0
Sent:=C2=A0Friday, Apri= l 19, 2013 10:51 AM
To:=C2= =A0Richard Barnes; Mike Jones
Cc:=C2=A0Karen O'Donoghue; jose@ietf.org
Subject:=C2=A0Re: [jose= ] Feedback request on jose tracker issue #8: Should we add a "spi"= ; header field?
=C2=A0
+1
=C2= =A0
=C2=A0
On= Apr 19, 2013, at 1:42 PM, Richard Barnes wrote:


In p= rinciple, you could use the omission of the "alg" field as a sign= al that pre-negotiation is going on. =C2=A0However, that seems like not the= most useful way to do it, and it conflicts with current practice -- namely= the examples currently in the JWE and JWS specs. =C2=A0Those examples use = pre-negotiation, but they also have an "alg" field. =C2=A0It'= s not very useful because it doesn't provide the recipient any clue abo= ut how to populate the missing fields. =C2=A0There's a semantic mis-mat= ch here as well, since a JWE with pre-negotiation is still a JWE, just an i= ncomplete one. =C2=A0
=C2=A0
A= dedicated flag field like SPI provides a clearer indication, and it also p= rovides a hook that out-of-band protocols can use to connect in the pre-neg= otiated parameters.
=C2=A0
--Richard
=C2=A0

=C2=A0

On Fri, Apr 19, 2013 at 12:06 PM, Mik= e Jones <Michael.Jones@microsoft.= com> wrote:
Russ, I'm curious why you say that the "spi= " field needs to be in the base spec. =C2=A0From a spec factoring poin= t of view, even if SPI remains a completely separate spec and nothing is sa= id in the base spec, there would be no confusion or conflicts, including fo= r implementations. =C2=A0Here's why:
=C2=A0 - A header without an "alg" field is not recognized as a J= WS or JWE, so there's no conflict there
=C2=A0 - A JWS or JWE can le= gally contain a "spi" header field and a registry is already prov= ided to define the meanings of additional header fields, so there's no = conflict there either

Therefore, it seems like the separate spec could use the registry to de= fine the meaning of "spi" in a JWS and JWE and could furthermore = define the semantics of objects using headers without an "alg" fi= eld but including a "spi" field. =C2=A0No conflicts. =C2=A0And cl= ear separation of concerns.

Those wanting the SPI functionality could use it. =C2=A0Those not needi= ng it would need to do nothing - which I think is as it should be.

= =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 Best wishes,
=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:=C2=A0jose-bounces@ietf= .org=C2=A0[mailto:jose-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Friday, April 19, 2013 8:37 AM
To:=C2=A0odonoghue@isoc.org;=C2=A0jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we ad= d a "spi" header field?

Combination of 1 and 2. =C2=A0The = field needs to be in the base specifications, but the only rule that needs = to be included in the base specification is an exact match of the identifie= r.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

1. =C2=A0Hav= e draft-barnes-jose-spi remain a separate specification that could optional= ly also be supported by JWS and JWE implementations.
2. =C2=A0Incorporat= e draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory = feature.
3. =C2=A0Incorporate draft-barnes-jose-spi into the JWS and JWE specificati= ons as an optional feature.
4. =C2=A0Another resolution (please specify = in detail).

_______________________________________________
jose = mailing list
jose@ietf.org
= https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/jose
=C2=A0
=C2=A0
_______________________________________________
= jose mailing list
jose@ietf.org
= https://www.ietf.org= /mailman/listinfo/jose

<= div>_______________________________________________
j= ose mailing list
jose@ietf= .org
https://www.ie= tf.org/mailman/listinfo/jose
--001a11c2605a9a43c604dacc21db-- From internet-drafts@ietf.org Tue Apr 23 17:26:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7B721F8B64; Tue, 23 Apr 2013 17:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOH5djOpWjfu; Tue, 23 Apr 2013 17:26:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8521F8C14; Tue, 23 Apr 2013 17:26:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424002618.19375.35009.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 17:26:18 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:26:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-09.txt Pages : 47 Date : 2013-04-23 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Apr 23 17:29:02 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A3221F94D9; Tue, 23 Apr 2013 17:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8rmrab7TVTS; Tue, 23 Apr 2013 17:29:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F53821F958D; Tue, 23 Apr 2013 17:29:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 17:29:01 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:29:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-09.txt Pages : 54 Date : 2013-04-23 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Apr 23 17:32:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6343B21F960A; Tue, 23 Apr 2013 17:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWpf1JqhE5Yr; Tue, 23 Apr 2013 17:32:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C740521F960C; Tue, 23 Apr 2013 17:32:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424003207.19375.86799.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 17:32:07 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:32:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-09.txt Pages : 16 Date : 2013-04-23 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Apr 23 17:33:58 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CEE21F966B; Tue, 23 Apr 2013 17:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm6PNlelsijQ; Tue, 23 Apr 2013 17:33:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FBE21F966C; Tue, 23 Apr 2013 17:33:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424003357.19375.28305.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 17:33:57 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:33:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-09.txt Pages : 51 Date : 2013-04-23 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Tue Apr 23 19:12:55 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BCD21F96C8; Tue, 23 Apr 2013 19:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp5iHiEXuukB; Tue, 23 Apr 2013 19:12:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2147A21F96C6; Tue, 23 Apr 2013 19:12:54 -0700 (PDT) Received: from BN1AFFO11FD011.protection.gbl (10.58.52.202) by BN1AFFO11HUB015.protection.gbl (10.58.52.125) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 24 Apr 2013 02:07:38 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD011.mail.protection.outlook.com (10.58.52.71) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 24 Apr 2013 02:07:38 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 24 Apr 2013 02:06:47 +0000 From: Mike Jones To: "jose@ietf.org" , "oauth@ietf.org" Thread-Topic: JOSE and JWT specs incorporating decisions from IETF 86 Thread-Index: Ac5AkF8GEZkzSCsYTlWpjIlvBF/zSA== Date: Wed, 24 Apr 2013 02:06:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676AA515@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(512954001)(16406001)(20776003)(4396001)(81542001)(47976001)(54316002)(47736001)(46102001)(66066001)(76482001)(50986001)(53806001)(564824004)(47446002)(74662001)(56816002)(54356001)(15202345002)(31966008)(63696002)(77982001)(59766001)(33656001)(6806003)(69226001)(74502001)(71186001)(79102001)(56776001)(51856001)(49866001)(80022001)(81342001)(16236675002)(65816001)(55846006)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB015; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0826B2F01B Subject: [jose] JOSE and JWT specs incorporating decisions from IETF 86 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 02:12:55 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JSON Object Signing and Encryption (JOSE) specification= s JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), = and JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification ha= ve been released that incorporate the working group decisions made during a= nd since IETF 86. The primary new features in these working group drafts are: * adding support for private and symmetric keys to JWK and JWA, * adding support for JSON Serializations to JWS and JWE, * replacing the custom JOSE CBC+HMAC algorithms with ones compatible= with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2, * defining that the default action for header parameters and claims = that are not understood is to ignore them, while providing a way to designa= te that some extension header parameters must be understood. More details on the changes made can be found in the Document History entri= es. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07 HTML formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-09= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 9.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-09.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 9.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-07.ht= ml -- Mike P.S. This notice has also been posted at http://self-issued.info/?p=3D1008= . --_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ne= w versions of the JSON Object Signing and Encryption (JOSE) specifications = JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), an= d JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification have been released that incorporate the= working group decisions made during and since IETF 86.

 

Th= e primary new features in these working group drafts are:

·        adding support for private and symmetric key= s to JWK and JWA,

·        adding support for JSON Serializations to JW= S and JWE,

·        replacing the custom JOSE CBC+HMAC algor= ithms with ones compatible with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2,

·        defining that the default action for header = parameters and claims that are not understood is to ignore them, while prov= iding a way to designate that some extension header parameters must be unde= rstood.

 

Mo= re details on the changes made can be found in the Document History entries= .

 

Th= e specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-09

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-09

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-09

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-09

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-07

 

HT= ML formatted versions are also available at:

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-09.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-09.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-09.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-09.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-07.html

 

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

 

P.= S.  This notice has also been posted at http://self-issued.info/?p=3D= 1008.

 

--_000_4E1F6AAD24975D4BA5B1680429673943676AA515TK5EX14MBXC284r_-- From trac+jose@trac.tools.ietf.org Wed Apr 24 11:29:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346B121F896E for ; Wed, 24 Apr 2013 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMmKQdZ-UGb for ; Wed, 24 Apr 2013 11:29:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7B921F896B for ; Wed, 24 Apr 2013 11:29:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:50919 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV4Rf-0002ff-56; Wed, 24 Apr 2013 20:29:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 24 Apr 2013 18:29:31 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/3#comment:3 Message-ID: <069.4a4c3325ceb27e8ab3c1e7ec55c4b75f@trac.tools.ietf.org> References: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130424182942.9A7B921F896B@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 11:29:42 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #3: Concat used outside of key agreement X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:29:43 -0000 #3: Concat used outside of key agreement Comment (by michael.jones@microsoft.com): draft-ietf-jose-json-web-algorithms-09 removes the use of the Concat KDF outside of key agreement in favor of using a CBC/HMAC SHA-2 encryption algorithm compatible with draft-mcgrew-aead-aes-cbc-hmac-sha2-01. I therefore believe that this issue should be closed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 24 11:36:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C6821F8DFC for ; Wed, 24 Apr 2013 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtAXfDWkIlS1 for ; Wed, 24 Apr 2013 11:36:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1DA21F8624 for ; Wed, 24 Apr 2013 11:36:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:51377 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV4YU-00037x-Fg; Wed, 24 Apr 2013 20:36:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 24 Apr 2013 18:36:34 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/5#comment:3 Message-ID: <069.30a85fe9014e6a9179d3169dc07e995d@trac.tools.ietf.org> References: <054.f240878e1815afe10f9256d1163853c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <054.f240878e1815afe10f9256d1163853c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130424183643.2A1DA21F8624@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 11:36:43 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #5: Unclear instructions for key management X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:36:44 -0000 #5: Unclear instructions for key management Comment (by michael.jones@microsoft.com): draft-ietf-jose-json-web-encryption-09 adds clear instructions for using each key management mode. See the Key Management Mode definitions in the Terminology section (Section 2) and the uses of these definitions in the Encryption and Decryption instructions in Sections 5.1 and 5.2. I therefore believe that this issue should be closed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 24 11:40:24 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7178D21F896D for ; Wed, 24 Apr 2013 11:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwxbIZD3rENO for ; Wed, 24 Apr 2013 11:40:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C89BF21F8738 for ; Wed, 24 Apr 2013 11:40:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:51455 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV4c6-0007KN-AP; Wed, 24 Apr 2013 20:40:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 24 Apr 2013 18:40:18 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/6#comment:2 Message-ID: <069.9e749f14b7284fa44bae26e9db99e999@trac.tools.ietf.org> References: <054.162afb78c358483db55af2b36ee8f61d@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <054.162afb78c358483db55af2b36ee8f61d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130424184023.C89BF21F8738@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 11:40:23 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #6: Unclear requirements levels on fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:40:24 -0000 #6: Unclear requirements levels on fields Comment (by michael.jones@microsoft.com): As part of the resolution to the "must understand" issue, draft-ietf-jose- json-web-signature-09 and draft-ietf-jose-json-web-encryption-09 now say which fields are required and optional under what circumstances. Furthermore, for algorithms requiring the use of specific additional header parameter fields, draft-ietf-jose-json-web-algorithms-09 clearly calls those fields out. Therefore, I believe that this issue should be closed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 24 11:44:56 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B7D21F8793 for ; Wed, 24 Apr 2013 11:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRJIU4NZFBR4 for ; Wed, 24 Apr 2013 11:44:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9D21F845A for ; Wed, 24 Apr 2013 11:44:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:51824 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV4gT-0003T6-HM; Wed, 24 Apr 2013 20:44:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com X-Trac-Project: jose Date: Wed, 24 Apr 2013 18:44:49 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/12#comment:4 Message-ID: <080.d547c42b8fc19d53d58ed7298e2ddfcb@trac.tools.ietf.org> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130424184455.1FD9D21F845A@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 11:44:55 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:44:56 -0000 #12: x5c incorrect in JWE Comment (by michael.jones@microsoft.com): draft-ietf-jose-json-web-encryption-09 now uniformly uses the language "the key to which the JWE was encrypted" when describing the key - not just for "x5c" but for all the key specification parameters. This is now both correct and clear. Therefore, I believe that this issue should be closed. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-jose-json- bcampbell@pingidentity.com | web-encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web-encryption | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Apr 24 11:49:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FAA21F8C14 for ; Wed, 24 Apr 2013 11:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtEtzQjq8koC for ; Wed, 24 Apr 2013 11:49:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 74A3021F8550 for ; Wed, 24 Apr 2013 11:49:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:51981 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV4l0-0005BL-Vu; Wed, 24 Apr 2013 20:49:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 24 Apr 2013 18:49:30 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/19#comment:3 Message-ID: <073.d94c65fa19622af3395d9371ec2d0ef8@trac.tools.ietf.org> References: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130424184934.74A3021F8550@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 11:49:34 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:49:35 -0000 #19: JWA needs to specify an IV for use with JWE AES Key Wrap Comment (by michael.jones@microsoft.com): draft-ietf-jose-json-web-algorithms-09 now includes this text when describing AES Key Wrap "Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using the default initial value specified in Section 2.2.3.1". I therefore believe that this issue should be closed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- watsonm@netflix.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web- | Version: algorithms | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From ve7jtb@ve7jtb.com Wed Apr 24 12:43:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879D521F8D90 for ; Wed, 24 Apr 2013 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoPxLlfXyxbP for ; Wed, 24 Apr 2013 12:43:50 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E657921F8E9E for ; Wed, 24 Apr 2013 12:43:49 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 10so2643707ied.33 for ; Wed, 24 Apr 2013 12:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=EkWlqWUUFZCI4Qk6BKatqBBZA0EDoijKeXO+A8Rbd/M=; b=DAFaoHOvsGI0goIWMVOIFWzNb1i8ho2hXrsUvZZwtO+lWJzK+kn13yMWGHeknA0QI8 Mx+foxSvF48xnXTUVw3HUu/UtbZoBkzI3eNNoB7EhaGzeOqo55RVEt5JN4dUsTlW8E/q zWB5kTGLkpmFUfloYHV5uiG79XGNeAJjqCBS46GbrbnDI21PWRXKkSDaDCprrR4xPdLh e27cPzLIQ+vWROWOFLjKsP+qgZDT8w1cmng2bX01vs2a+ITm4Vllh+yn6sPP2PoA1pOx p9t/hMIm0D3zJ/iKjAFd9reZF60+xtiXaYydoNG4hH1BneORCU+vdCZMmiXeYQr7WvAS 68RQ== X-Received: by 10.43.148.71 with SMTP id kf7mr19363212icc.42.1366832629398; Wed, 24 Apr 2013 12:43:49 -0700 (PDT) Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id b6sm7300166igv.5.2013.04.24.12.43.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 12:43:47 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CF1C8986-4FCC-4F9A-960D-F09B1C007D23"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <069.4a4c3325ceb27e8ab3c1e7ec55c4b75f@trac.tools.ietf.org> Date: Wed, 24 Apr 2013 16:43:25 -0300 Message-Id: References: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> <069.4a4c3325ceb27e8ab3c1e7ec55c4b75f@trac.tools.ietf.org> To: jose issue tracker X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmevPQBOo3LhSTBhK09aLBD1XB+x3EHS3fh/G2kS6ps/EjJMnofFUK4Tvw5GbCPcWVZCsiy Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, sakimura@gmail.com, jose@ietf.org Subject: Re: [jose] #3: Concat used outside of key agreement X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 19:43:50 -0000 --Apple-Mail=_CF1C8986-4FCC-4F9A-960D-F09B1C007D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree the change addresses this issue by removing the KDF. On 2013-04-24, at 3:29 PM, jose issue tracker = wrote: > #3: Concat used outside of key agreement >=20 >=20 > Comment (by michael.jones@microsoft.com): >=20 > draft-ietf-jose-json-web-algorithms-09 removes the use of the Concat = KDF > outside of key agreement in favor of using a CBC/HMAC SHA-2 encryption > algorithm compatible with draft-mcgrew-aead-aes-cbc-hmac-sha2-01. I > therefore believe that this issue should be closed. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-jose-json-web- > rbarnes@bbn.com | encryption@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > encryption | Resolution: > Severity: Active WG | > Document | > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_CF1C8986-4FCC-4F9A-960D-F09B1C007D23 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI0MTk0MzI2WjAjBgkqhkiG9w0BCQQxFgQUbJ71LYw3 DX+iXx2AybheSr3YYfMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAIbT9fiyU3eOu5qjAw55e55ZGT9BBY5XrQnMUzFgO RWqIW5A2p9yjLOyJzyKHN1EpicsgK0u77ZQFRETARz78xsdyvCKbDEyYTfJ8PgZUXzs8gbOw5ZOJ Diqm6I4tvor3yad11dQXHsy5EWabMvG8+oBHmEMNWH0VzFQZO1h3BpgxyRb7pE2uCdiG8oeEilq1 EPwNpX9dw2fxJNHiWQCiXN1+BlWu/Yc6r9VFTIsxu8I/mhYmxRqC0lwf+Ou5pARg08lnMVRUtHjG jaa8jVvFWLPvCafWVgrcp9OTNzwKShPxc5Fo9GY5924mHD8LU2mv9xEH602W3XsfnLt4cOS2DAAA AAAAAA== --Apple-Mail=_CF1C8986-4FCC-4F9A-960D-F09B1C007D23-- From nichole.richardson.27@facebook.com Wed Apr 24 13:10:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EB321F8E79 for ; Wed, 24 Apr 2013 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.664 X-Spam-Level: X-Spam-Status: No, score=-101.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hczZsd5cYTwg for ; Wed, 24 Apr 2013 13:10:49 -0700 (PDT) Received: from smtpout.mx.facebook.com (smtpout001.ash3.facebook.com [69.171.244.64]) by ietfa.amsl.com (Postfix) with ESMTP id F254321F9120 for ; Wed, 24 Apr 2013 13:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=facebook.com; s=s1024-2010-q3; c=relaxed/simple; q=dns/txt; i=@facebook.com; t=1366834235; h=From:Subject:X-:Date:To:MIME-Version:Content-Type; bh=J0OjXeCuM4N5uzx09l2E0YwE7/3gnaSz5UE9hh25U0w=; b=CnT8e0xFzkKIwvRmRtGSk4XhQZp8SLvaKlLVnRYZ/xExnALoUqr/HHXyDl9qGsHN rsA7siOk+TYz/n4cPUxJUVrl0eQfsqxnLy8AJNo/APce+lSTR6OfEG4LkTPXys5F /GBaDbrhnJQysISL+u67fLNOjdFrJbePLAB9BW0SHPI=; Received: from [10.148.86.69] ([10.148.86.69:46605] helo=www.facebook.com) by 10.148.128.29 (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id EC/32-03944-B3C38715; Wed, 24 Apr 2013 13:10:35 -0700 Date: Wed, 24 Apr 2013 13:10:35 -0700 From: Nichole Richardson To: Mike Jones , "oauth@ietf.org" , "jose@ietf.org" Message-ID: <6ba33a1284334c0497f0d4e3cb2cf2ad-0@mail.projektitan.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676AA515@TK5EX14MBXC284.redmond.corp.microsoft.com> References: , <4E1F6AAD24975D4BA5B1680429673943676AA515@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13410_1224209555.1366834235476" X-Mailman-Approved-At: Wed, 24 Apr 2013 13:13:45 -0700 Subject: Re: [jose] [OAUTH-WG] JOSE and JWT specs incorporating decisions from IETF 86 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 20:10:50 -0000 ------=_Part_13410_1224209555.1366834235476 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Auto-generated message: Nichole Richardson has left this conversation and will no longer see your messages On April 23, 2013 7:06:47 PM PDT, Mike Jones wrote: > New versions of the JSON Object Signing and Encryption (JOSE) specifications JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification have been released that incorporate the working group decisions made during and since IETF 86. > > The primary new features in these working group drafts are: > > * adding support for private and symmetric keys to JWK and JWA, > > * adding support for JSON Serializations to JWS and JWE, > > * replacing the custom JOSE CBC+HMAC algorithms with ones compatible with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2, > > * defining that the default action for header parameters and claims that are not understood is to ignore them, while providing a way to designate that some extension header parameters must be understood. > > More details on the changes made can be found in the Document History entries. > > The specifications are available at: > > * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09 > > * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 > > * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09 > > * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07 > > HTML formatted versions are also available at: > > * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-09..html > > * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-09.html > > * http://self-issued.info/docs/draft-ietf-jose-json-web-key-09.html > > * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-09.html > > * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-07.html > > -- Mike > > P.S. This notice has also been posted at http://self-issued.info/?p=1008.. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------=_Part_13410_1224209555.1366834235476 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Auto-generated message: Nichole Richardson has left this conversation and will no longer see your messages

On April 23, 2013 7:06:47 PM PDT, Mike Jones wrote:

New versions of the JSON Object Signing and Encryption (JOSE) specifications JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification have been released that incorporate the working group decisions made during and since IETF 86.

 

The primary new features in these working group drafts are:

·        adding support for private and symmetric keys to JWK and JWA,

·        adding support for JSON Serializations to JWS and JWE,

·        replacing the custom JOSE CBC+HMAC algorithms with ones compatible with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2,

·        defining that the default action for header parameters and claims that are not understood is to ignore them, while providing a way to designate that some extension header parameters must be understood.

 

More details on the changes made can be found in the Document History entries..

 

The specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-09

·        http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09

·        http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09

·        http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-09

·        http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-07

 

HTML formatted versions are also available at:

·        http://self-issued.info/docs/draft-ietf-jose-json-web-signature-09.html

·        http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-09.html

·        http://self-issued.info/docs/draft-ietf-jose-json-web-key-09.html

·        http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-09.html

·        http://self-issued.info/docs/draft-ietf-oauth-json-web-token-07.html

 

                                                            -- Mike

 

P.S.  This notice has also been posted at http://self-issued.info/?p=1008.

 


------=_Part_13410_1224209555.1366834235476-- From rlb@ipv.sx Wed Apr 24 15:15:41 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AA221F8793 for ; Wed, 24 Apr 2013 15:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lkNtdNLqWWq for ; Wed, 24 Apr 2013 15:15:40 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AB60921F877B for ; Wed, 24 Apr 2013 15:15:40 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id xn12so2022366obc.18 for ; Wed, 24 Apr 2013 15:15:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=RrgvRTDZG1A+Y5GiJDD4IMcU8BLP7mjf32Ms5pcZmv4=; b=aUiOJR4XpoAsvxY0X5cWwwl/FizhWJOkpHv0UnnDJZ7rj0qu7YF63HG7BC3y9VaSIq WIxkAyINoiFO9wmhNWrtlIZEUvXJj7aeQO9QHiiMmBxwaYuEwU5JcPfWCKlMxwPDZXvv kh48xzCNDAdNTs1sKXZ5VNTemvsfhI2zZGp7ruNPE9LdLAezGUEdPMZBpJCB8qxiiFF+ pNheBPb3YvMSY6QvFpJjMV3a+r8N1RoGyg6brAmR2S78K4PT7W92kBkhlbptO9j9w3Ht X5fbijy+0adss0/SsIra6oVul1fU00vnK9xZrzYWG37/3p5RhSdpx2/o/TE4icG8ooys NksA== MIME-Version: 1.0 X-Received: by 10.182.129.101 with SMTP id nv5mr18373709obb.56.1366841740314; Wed, 24 Apr 2013 15:15:40 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Wed, 24 Apr 2013 15:15:40 -0700 (PDT) X-Originating-IP: [128.89.253.75] Date: Wed, 24 Apr 2013 18:15:40 -0400 Message-ID: From: Richard Barnes To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=e89a8fb1ebe4654fb104db22a4fa X-Gm-Message-State: ALoCoQkkUrycIUDMazsh5d7IKi9mabGkKDThs9xiU7WTwnkEEHK2a1qeFxuZEJ5jlyb0I/VI1cos Subject: [jose] One word review of JWE -09 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:15:41 -0000 --e89a8fb1ebe4654fb104db22a4fa Content-Type: text/plain; charset=ISO-8859-1 "AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients" Unacceptable. --e89a8fb1ebe4654fb104db22a4fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"AES G= CM MUST NOT be used when using the JWE JSON Serialization for=A0multiple recipients"=

Unacceptable.
--e89a8fb1ebe4654fb104db22a4fa-- From rlb@ipv.sx Wed Apr 24 15:16:22 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167DE21F8793 for ; Wed, 24 Apr 2013 15:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vivuvlnTLosx for ; Wed, 24 Apr 2013 15:16:21 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8836021F898B for ; Wed, 24 Apr 2013 15:16:21 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id dn14so1979103obc.41 for ; Wed, 24 Apr 2013 15:16:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=0gLgAa0FvwfOK85WQYNTmr2vw4nqS7KZkgi0Iccls2M=; b=CBaogLnfDQ8gnEvWOFStrkbRkWHRTISSQX17EoQWXOngSGYbCQHrXwROa3M9pQoal1 zGGVdP7nBbSnP2y03IEzFQnr1hoovYBmABL2UBLKCcoHu1GBREgB1pZAuvSBh0YlTHNf apx/N+dWNfbAQUh5/VjP1QMfv7MMTv4qlkcOgpNlI71eyYyPoioqS4J4fON++GMSR4hp Jqoo1lLmTcyIAnG3+A9ajDZQ+3vA5dEMVCycfHU+94ABegy1Sow7YSKApLJbUzOSgpGR ycddeXKmpRAZeAPB9tLq6HevsJ+brT4+PIok82m3slDBk4zrG4bcoK9Pd/kDtiKbdh2v btZQ== MIME-Version: 1.0 X-Received: by 10.60.121.104 with SMTP id lj8mr15250169oeb.83.1366841781166; Wed, 24 Apr 2013 15:16:21 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Wed, 24 Apr 2013 15:16:21 -0700 (PDT) X-Originating-IP: [128.89.253.75] In-Reply-To: <073.d94c65fa19622af3395d9371ec2d0ef8@trac.tools.ietf.org> References: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> <073.d94c65fa19622af3395d9371ec2d0ef8@trac.tools.ietf.org> Date: Wed, 24 Apr 2013 18:16:21 -0400 Message-ID: From: Richard Barnes To: jose issue tracker Content-Type: multipart/alternative; boundary=047d7b3a9734d4b7e804db22a6e2 X-Gm-Message-State: ALoCoQmQnX5m3VPIRlJcZ/RiVDBvEhWvgf2+gVP8uuA3pv4QOkriDQGVUn5zLFWatiCgRozdvLz6 Cc: Michael Jones , "jose@ietf.org" , draft-ietf-jose-json-web-algorithms@tools.ietf.org Subject: Re: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:16:22 -0000 --047d7b3a9734d4b7e804db22a6e2 Content-Type: text/plain; charset=ISO-8859-1 +1 to closing. On Wed, Apr 24, 2013 at 2:49 PM, jose issue tracker < trac+jose@trac.tools.ietf.org> wrote: > #19: JWA needs to specify an IV for use with JWE AES Key Wrap > > > Comment (by michael.jones@microsoft.com): > > draft-ietf-jose-json-web-algorithms-09 now includes this text when > describing AES Key Wrap "Advanced Encryption Standard (AES) Key Wrap > Algorithm [RFC3394] using the default initial value specified in Section > 2.2.3.1". I therefore believe that this issue should be closed. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-jose-json-web- > watsonm@netflix.com | algorithms@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: json-web- | Version: > algorithms | Resolution: > Severity: - | > Keywords: | > -------------------------+------------------------------------------------- > > Ticket URL: > jose > > --047d7b3a9734d4b7e804db22a6e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 to closing.


On Wed, Apr 24, 2013 at 2:49 PM, jose issue tracker= <trac+jose@trac.tools.ietf.org> wrote:
#19: JWA needs to specify = an IV for use with JWE AES Key Wrap


Comment (by michael.jo= nes@microsoft.com):

=A0draft-ietf-jose-json-web-algorithms-09 now includes this text when
=A0describing AES Key Wrap "Advanced Encryption Standard (AES) Key Wra= p
=A0Algorithm [RFC3394] using the default initial value specified in Section=
=A02.2.3.1". =A0I therefore believe that this issue should be closed.<= br>

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0draft-ietf= -jose-json-web-
=A0 watsonm@netflix.com =A0 =A0|= =A0algorithms@tools.ietf.org<= /a>
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 Milestone:
Component: =A0json-web- =A0 =A0| =A0 =A0 Version:
=A0 algorithms =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolut= ion:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0|
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/jose/tra= c/ticket/19#comment:3>
jose <http://t= ools.ietf.org/jose/>


--047d7b3a9734d4b7e804db22a6e2-- From rlb@ipv.sx Wed Apr 24 15:17:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C3D21F923C for ; Wed, 24 Apr 2013 15:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o58xdyYQrtqe for ; Wed, 24 Apr 2013 15:17:50 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 357B121F920B for ; Wed, 24 Apr 2013 15:17:50 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j1so2295077oag.36 for ; Wed, 24 Apr 2013 15:17:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5ppjJOmGT9gHdJNT1TJe8ihQCpShxUEZNFzRZHlG7nY=; b=cNmnGAsdGYs6yScpRqq3lS0gUw0mGSxZ443EeJ8ckGal6GmJ5qP8jpRestpNRetkxZ RRj7rtT+N5yXhnuiFvWZaY9uSEM6C0f0eOIxfkQYxMCaUpSYAQqgTk+F64eN8yRFYlxp RNeGoTqF5VqFclx99G1VWNCYtz2g7WjVwMoyMl2R54xuAUgny2yiFpEtt4d1BE+c6KI5 M5O31msi6MkLgHmXnjZFMOwWOuo/g5bheMrNwxvfD5d4ul20ueOWeUbuKumaJXN6XQd7 7D8QUlK4KrpmMRifv8/M6Mnc1oMoAxRgVlHQlhPMeGVsVP+RX2m9rwwEGLR2B+PUY4ON izhw== MIME-Version: 1.0 X-Received: by 10.60.59.197 with SMTP id b5mr2544923oer.4.1366841869846; Wed, 24 Apr 2013 15:17:49 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Wed, 24 Apr 2013 15:17:49 -0700 (PDT) X-Originating-IP: [128.89.253.75] In-Reply-To: <080.d547c42b8fc19d53d58ed7298e2ddfcb@trac.tools.ietf.org> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> <080.d547c42b8fc19d53d58ed7298e2ddfcb@trac.tools.ietf.org> Date: Wed, 24 Apr 2013 18:17:49 -0400 Message-ID: From: Richard Barnes To: jose issue tracker Content-Type: multipart/alternative; boundary=089e0149d1b61ddddd04db22ac1f X-Gm-Message-State: ALoCoQmcL7/0p+Yqjf7LC+zoLgAH1QLA90mvkcaV8SN+vYtD3gynmXl7xuBkxLQP8eWFrky/uHLH Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Michael Jones , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:17:51 -0000 --089e0149d1b61ddddd04db22ac1f Content-Type: text/plain; charset=ISO-8859-1 I don't object to closing this. I don't really think that "x5c" is that useful, but at least it's properly specified now. On Wed, Apr 24, 2013 at 2:44 PM, jose issue tracker < trac+jose@trac.tools.ietf.org> wrote: > #12: x5c incorrect in JWE > > > Comment (by michael.jones@microsoft.com): > > draft-ietf-jose-json-web-encryption-09 now uniformly uses the language > "the key to which the JWE was encrypted" when describing the key - not > just for "x5c" but for all the key specification parameters. This is now > both correct and clear. Therefore, I believe that this issue should be > closed. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-jose-json- > bcampbell@pingidentity.com | web-encryption@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: json-web-encryption | Version: > Severity: Submitted WG Document | Resolution: > Keywords: | > -------------------------------------+------------------------------------- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e0149d1b61ddddd04db22ac1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't object to closing this. =A0I don't really = think that "x5c" is that useful, but at least it's properly s= pecified now.


On Wed, Apr 24, 2013 at 2:44 PM, jose issue tracker <<= a href=3D"mailto:trac+jose@trac.tools.ietf.org" target=3D"_blank">trac+jose= @trac.tools.ietf.org> wrote:
#12: x5c incorrect in JWE


Comment (by michael.jo= nes@microsoft.com):

=A0draft-ietf-jose-json-web-encryption-09 now uniformly uses the language =A0"the key to which the JWE was encrypted" when describing the k= ey - not
=A0just for "x5c" but for all the key specification parameters. = =A0This is now
=A0both correct and clear. =A0Therefore, I believe that this issue should b= e
=A0closed.

--
-------------------------------------+-------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner: =A0draft-ietf-jose-json-
=A0 bcampbell@pingidentity.co= m =A0 =A0 =A0 =A0 | =A0web-encryption@tools.ietf.org
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Status: =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Mileston= e:
Component: =A0json-web-encryption =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Submitted WG Document =A0 =A0| =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/tick= et/12#comment:4>
jose <http://tools.ietf.org/jose/>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e0149d1b61ddddd04db22ac1f-- From ve7jtb@ve7jtb.com Wed Apr 24 15:50:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760EE21F8793 for ; Wed, 24 Apr 2013 15:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPOnuTKbf29O for ; Wed, 24 Apr 2013 15:50:10 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8730821F863B for ; Wed, 24 Apr 2013 15:50:10 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id r13so2036023iar.30 for ; Wed, 24 Apr 2013 15:50:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=7WEAPa1nQJ5JCnoSomqMDFiT5hJfegIavYDxfXn8+Gs=; b=Yk0S5FQQwM4pBwWmEsuOjA8D8SyLptOJQyzctzzYCAdemkNpoYl6VZHT+9QW7dy1U4 xBSVQAIf0BG/FxwujhSVgyF/603+KWU+PhufexyvSTeT+VQj7SGLvX9npDcdcnFbA9fd C4mDQ0aDXvm0ixSN+bXmgsl0TOX6vEH5NAiOp6oFfkvyqz5jVcmpP/LYNL17SVUpCU95 zPE0h2bt5WZSN6O7uDq95jhZebWxyNO3t0Ais19rlyx0ZT1esgJtlcUtlCO1iINVdulk PxyPeTnfchMthscrtulgPQn9sHFR5g1A0DPEJkRSLoL75MjXWu2eP/83VnSjeuJjh4x0 7zaw== X-Received: by 10.50.97.65 with SMTP id dy1mr5116212igb.109.1366843809920; Wed, 24 Apr 2013 15:50:09 -0700 (PDT) Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id d4sm30162639igc.3.2013.04.24.15.50.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 15:50:08 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E3F214E0-E170-4FC4-9A2F-15D9FF261633"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Wed, 24 Apr 2013 19:49:48 -0300 Message-Id: <72786B82-6E82-42B0-ACA6-EEE65C11E6B2@ve7jtb.com> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> <080.d547c42b8fc19d53d58ed7298e2ddfcb@trac.tools.ietf.org> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnkAtNd8nVV3/r1d0u18lRimPMvffeGg8mVuBsnDHwtwclhMEcHLAsDxRxdAJxdfaK4tcy7 Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Michael Jones , Brian Campbell , jose issue tracker , "jose@ietf.org" Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 22:50:11 -0000 --Apple-Mail=_E3F214E0-E170-4FC4-9A2F-15D9FF261633 Content-Type: multipart/alternative; boundary="Apple-Mail=_68A9786F-52B2-4892-8737-1DBF46C03FCF" --Apple-Mail=_68A9786F-52B2-4892-8737-1DBF46C03FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Agreed On 2013-04-24, at 7:17 PM, Richard Barnes wrote: > I don't object to closing this. I don't really think that "x5c" is = that useful, but at least it's properly specified now. >=20 >=20 > On Wed, Apr 24, 2013 at 2:44 PM, jose issue tracker = wrote: > #12: x5c incorrect in JWE >=20 >=20 > Comment (by michael.jones@microsoft.com): >=20 > draft-ietf-jose-json-web-encryption-09 now uniformly uses the = language > "the key to which the JWE was encrypted" when describing the key - = not > just for "x5c" but for all the key specification parameters. This is = now > both correct and clear. Therefore, I believe that this issue should = be > closed. >=20 > -- > = -------------------------------------+------------------------------------= - > Reporter: | Owner: = draft-ietf-jose-json- > bcampbell@pingidentity.com | web-encryption@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: json-web-encryption | Version: > Severity: Submitted WG Document | Resolution: > Keywords: | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: = > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_68A9786F-52B2-4892-8737-1DBF46C03FCF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Agreed

On 2013-04-24, at 7:17 PM, Richard Barnes <rlb@ipv.sx> wrote:

I don't object to closing this.  I don't really think that "x5c" is that useful, but at least it's properly specified now.


On Wed, Apr 24, 2013 at 2:44 PM, jose issue tracker <trac+jose@trac.tools.ietf.org> wrote:
#12: x5c incorrect in JWE


Comment (by michael.jones@microsoft.com):

 draft-ietf-jose-json-web-encryption-09 now uniformly uses the language
 "the key to which the JWE was encrypted" when describing the key - not
 just for "x5c" but for all the key specification parameters.  This is now
 both correct and clear.  Therefore, I believe that this issue should be
 closed.

--
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-jose-json-
  bcampbell@pingidentity.com         |  web-encryption@tools.ietf.org
     Type:  defect                   |      Status:  new
 Priority:  minor                    |   Milestone:
Component:  json-web-encryption      |     Version:
 Severity:  Submitted WG Document    |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/12#comment:4>
jose <http://tools.ietf.org/jose/>

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

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

--Apple-Mail=_68A9786F-52B2-4892-8737-1DBF46C03FCF-- --Apple-Mail=_E3F214E0-E170-4FC4-9A2F-15D9FF261633 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI0MjI0OTQ5WjAjBgkqhkiG9w0BCQQxFgQUDsi3Zknm MiLpy6MdgOKhvZFGeXUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAkV2NkwmWLfAg5yj/X7I/uXx96KC0RlKavQVQALsb u/9yZe1qHMg8OHTAW4UjamLhSIz67eLggNkXmbrwTYXMsE97m6/UYwLRR4oVS8/Oxu5wuiWFz4WI AlehoNx8RPjVnR4jXaG+QuHwIQxoNnz4xS5ZPMdu4WBlpF4Roz6OVFeX4q0PRTpye1Y8VN2r+RV/ V/uxWHRpM05J8KuWPYfZGj9YS+qvE/ulSkG+XJLrsLoBajvVCXSEMDcPj3y0j9i9na2HffaJ8MZ8 wRXnQMkzYaK9bo19Bnaa1iTxMSMcA9cpefCRwzmUFTu9YLSo11oEJfwbbFBmpcQ/nSIW49zwVQAA AAAAAA== --Apple-Mail=_E3F214E0-E170-4FC4-9A2F-15D9FF261633-- From ietf@augustcellars.com Wed Apr 24 21:09:01 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3622921F8BE9 for ; Wed, 24 Apr 2013 21:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgSKoN63NQ9P for ; Wed, 24 Apr 2013 21:09:00 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id B377521F8AD5 for ; Wed, 24 Apr 2013 21:09:00 -0700 (PDT) Received: from Philemon (unknown [207.239.114.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B641738F19; Wed, 24 Apr 2013 21:08:51 -0700 (PDT) From: "Jim Schaad" To: "Mike Jones" References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> In-Reply-To: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 21:07:19 -0700 Message-ID: <014201ce416a$82761a80$87624f80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGMAkutZDO/mM1MbqdkRoeXZXifIZlqz8aA Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 04:09:01 -0000 Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict that the AD and IESG along with the security directorate would crucify me if I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and Encryption > Working Group of the IETF. > > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 > > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Apr 24 23:48:52 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE95721F9381 for ; Wed, 24 Apr 2013 23:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaYZ-cH5OeV8 for ; Wed, 24 Apr 2013 23:48:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 5861821F937E for ; Wed, 24 Apr 2013 23:48:50 -0700 (PDT) Received: from BN1BFFO11FD017.protection.gbl (10.58.52.202) by BN1AFFO11HUB009.protection.gbl (10.58.52.119) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 06:48:49 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD017.mail.protection.outlook.com (10.58.53.77) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 06:48:49 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.245]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 06:48:29 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgAAqctA= Date: Thu, 25 Apr 2013 06:48:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> In-Reply-To: <014201ce416a$82761a80$87624f80$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(189002)(199002)(377424002)(51704004)(56776001)(20776003)(47446002)(46406003)(69226001)(47776003)(51856001)(74662001)(4396001)(50466002)(74502001)(76482001)(81542001)(66066001)(6806003)(56816002)(79102001)(46102001)(54356001)(53806001)(16406001)(81342001)(80022001)(55846006)(33656001)(15202345002)(63696002)(49866001)(65816001)(59766001)(23726002)(77982001)(47976001)(74366001)(31966008)(54316002)(50986001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB009; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 06:48:52 -0000 Jim - I am surprised that you would say that my co-authors Eric Rescorla or= Joe Hildebrand or the working group would advocate using AES GCM in a way = that would result in severe security vulnerabilities - in particular, allow= ing attackers to obtain the XOR of the messages to multiple recipients encr= ypted using GCM - a vulnerability identified by the CFRG. Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = As I said to Richard Barnes over dinner last night, while unpleasant, and = possibly surprising to those who aren't familiar to how GCM actually works,= as an editor, I viewed including the statement that "AES GCM MUST NOT be u= sed when using the JWE JSON Serialization for multiple recipients, since th= is would result in the same Initialization Vector and Plaintext values bein= g used for multiple GCM encryptions" as necessary, and "truth in advertisin= g". -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Wednesday, April 24, 2013 9:07 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and=20 > Encryption Working Group of the IETF. >=20 > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 >=20 > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > 9 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From housley@vigilsec.com Thu Apr 25 10:31:20 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F9921F961D for ; Thu, 25 Apr 2013 10:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dkf9Zmfm-u1q for ; Thu, 25 Apr 2013 10:30:49 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 64B7421F9457 for ; Thu, 25 Apr 2013 10:30:47 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 13243F2407F; Thu, 25 Apr 2013 13:30:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id a6T5eaKL94rt; Thu, 25 Apr 2013 13:30:17 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-221-210.washdc.fios.verizon.net [96.241.221.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 36C0DF24082; Thu, 25 Apr 2013 13:30:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <014201ce416a$82761a80$87624f80$@augustcellars.com> Date: Thu, 25 Apr 2013 13:30:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 17:31:20 -0000 Mike: Like Jim, I cannot support this statement: AES GCM MUST NOT be used when = using the JWE JSON Serialization for multiple recipients All recipients ought to be performing decryption and integrity checking = with the same GCM key. The manner in which they obtain that key may be = different (key transport: decrypt the GCM key with the recipient's = private key, key agreement: agreement of a pairwise KEK and then = unwrapping the GCM key with the KEK, pre-shared KEK: unwrapping the GCM = key with the already known KEK, etc). Russ On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > Mike, >=20 > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. >=20 > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this > I can predict that the AD and IESG along with the security directorate = would > crucify me if I allowed this to stand in the document.. >=20 > Jim >=20 >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> internet-drafts@ietf.org >> Sent: Tuesday, April 23, 2013 5:29 PM >> To: i-d-announce@ietf.org >> Cc: jose@ietf.org >> Subject: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Javascript Object Signing and = Encryption >> Working Group of the IETF. >>=20 >> Title : JSON Web Encryption (JWE) >> Author(s) : Michael B. Jones >> Eric Rescorla >> Joe Hildebrand >> Filename : draft-ietf-jose-json-web-encryption-09.txt >> Pages : 54 >> Date : 2013-04-23 >>=20 >> Abstract: >> JSON Web Encryption (JWE) is a means of representing encrypted >> content using JavaScript Object Notation (JSON) data structures. >> Cryptographic algorithms and identifiers for use with this >> specification are described in the separate JSON Web Algorithms = (JWA) >> specification. Related digital signature and MAC capabilities are >> described in the separate JSON Web Signature (JWS) specification. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-09 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rlb@ipv.sx Thu Apr 25 11:13:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46021F9677 for ; Thu, 25 Apr 2013 11:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtXJJlbvKtlp for ; Thu, 25 Apr 2013 11:13:49 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F32F721F9675 for ; Thu, 25 Apr 2013 11:13:48 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp18so2749019obc.20 for ; Thu, 25 Apr 2013 11:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Mf36HMOR//eNldjX6zRcEPaTe7oPDQkYBcbT+w7y8SQ=; b=c+fcZLaiJT8olrWBFX5aajhhU7hRnYnvRyAER2qYaikUQXFeg4vHl/RFFKDk4iou99 Rxm5PV+WEsmVTS/cbLkr+km2D0uEzaHQOYMqmckhrKcLnVzaBOAMqSHO4mdB0Lgq1eZY cFfXTViZk06a3wl9JUdHUp9qD0QbVzDV64YBPj4i7nKpaeUyuYSR4PypCyyoocf08V48 ajGPFDrNG/MYKYeF5TbDqpc37SedHpRbv4ocnOLal0zQM/Bj/cgNVLn7YtJADAJMml+B W9rXJepmshSOoFXMH7vTFjwNZx5KR3xKtRbjBy8KuLQlO2jGPOU7kJ2fVF3NsuoEWB0b jwFw== MIME-Version: 1.0 X-Received: by 10.182.64.74 with SMTP id m10mr15471057obs.61.1366913628448; Thu, 25 Apr 2013 11:13:48 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 11:13:48 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 14:13:48 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=14dae93b5e36433c6f04db336188 X-Gm-Message-State: ALoCoQkFhG50KZJa8pIjCUNDVRYWwPaiJWk/MuG8qPV62pTJdewDLrIp5hEWVRn8DdNbenIy55HK Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 18:13:50 -0000 --14dae93b5e36433c6f04db336188 Content-Type: text/plain; charset=ISO-8859-1 Mike, Your facts are right, but your conclusions are wrong. We have three mutually incompatible goals here: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity We can have any two of these, but not all three. If we try to do all three (JWE-08), then we end up with the vulnerability identified in the CFRG thread. So we need to choose which one to get rid of. Getting rid of GCM is clearly not the right answer, as evidenced by the reaction in this thread. There are clear, concrete use reasons to support multiple recipients, but not for header integrity. And header integrity can be "polyfilled" with an optional feature, for those who are willing to break the multiple recipient case. Clearly, header integrity is the weakest link here. JWE-09 is the reductio ad absurdum of header integrity. Let's do the logical thing and stop the absurdity. --Richard On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones wrote: > Jim - I am surprised that you would say that my co-authors Eric Rescorla > or Joe Hildebrand or the working group would advocate using AES GCM in a > way that would result in severe security vulnerabilities - in particular, > allowing attackers to obtain the XOR of the messages to multiple recipients > encrypted using GCM - a vulnerability identified by the CFRG. > > Not stating this in the document would seem to me to be highly > irresponsible, given the brittleness of GCM in this regard, as identified > by the CRFG. As I said to Richard Barnes over dinner last night, while > unpleasant, and possibly surprising to those who aren't familiar to how GCM > actually works, as an editor, I viewed including the statement that "AES > GCM MUST NOT be used when using the JWE JSON Serialization for multiple > recipients, since this would result in the same Initialization Vector and > Plaintext values being used for multiple GCM encryptions" as necessary, and > "truth in advertising". > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > Mike, > > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. > > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can predict > that the AD and IESG along with the security directorate would crucify me > if I allowed this to stand in the document.. > > Jim > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: i-d-announce@ietf.org > > Cc: jose@ietf.org > > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms (JWA) > > specification. Related digital signature and MAC capabilities are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --14dae93b5e36433c6f04db336188 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mike,=A0

Your facts are right, bu= t your conclusions are wrong.

We have = three mutually incompatible goals here:
1. GCM
2. Efficient encoding for multiple recipients
3. Header int= egrity

We can have any two of these, b= ut not all three. =A0If we try to do all three (JWE-08), then we end up wit= h the vulnerability identified in the CFRG thread. =A0So we need to choose = which one to get rid of.

Getting rid of GCM is clearly not the right= answer, as evidenced by the reaction in this thread. =A0There are clear, c= oncrete use reasons to support multiple recipients, but not for header inte= grity. =A0And header integrity can be "polyfilled" with an option= al feature, for those who are willing to break the multiple recipient case.= =A0Clearly, header integrity is the weakest link here.

JWE-09 is the reductio ad absurdum of heade= r integrity. =A0Let's do the logical thing and stop the absurdity.

--Richard




On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:
Jim - I am surprised that you would say that= my co-authors Eric Rescorla or Joe Hildebrand or the working group would a= dvocate using AES GCM in a way that would result in severe security vulnera= bilities - in particular, allowing attackers to obtain the XOR of the messa= ges to multiple recipients encrypted using GCM - a vulnerability identified= by the CFRG.

Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = =A0As I said to Richard Barnes over dinner last night, while unpleasant, an= d possibly surprising to those who aren't familiar to how GCM actually = works, as an editor, I viewed including the statement that "AES GCM MU= ST NOT be used when using the JWE JSON Serialization for multiple recipient= s, since this would result in the same Initialization Vector and Plaintext = values being used for multiple GCM encryptions" as necessary, and &quo= t;truth in advertising".

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

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
=A0 =A0multiple recipients, since this would result in the same
=A0 =A0Initialization Vector and Plaintext values being used for multiple =A0 =A0GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.or= g
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org=
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt=
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> =A0This draft is a work item of the Javascript Object Signing and
> Encryption Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE)
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Michael B. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joe Hildebrand
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-encrypt= ion-09.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 54
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>
> Abstract:
> =A0 =A0JSON Web Encryption (JWE) is a means of representing encrypted<= br> > =A0 =A0content using JavaScript Object Notation (JSON) data structures= .
> =A0 =A0Cryptographic algorithms and identifiers for use with this
> =A0 =A0specification are described in the separate JSON Web Algorithms= (JWA)
> =A0 =A0specification. =A0Related digital signature and MAC capabilitie= s are
> =A0 =A0described in the separate JSON Web Signature (JWS) specificatio= n.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jo= se-json-web-encryption
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-encryption-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-jose-json-web-encryption-0
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--14dae93b5e36433c6f04db336188-- From Michael.Jones@microsoft.com Thu Apr 25 12:10:02 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7021F8E76 for ; Thu, 25 Apr 2013 12:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krWUUaETSHtR for ; Thu, 25 Apr 2013 12:10:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id E2F1A21F8B07 for ; Thu, 25 Apr 2013 12:10:00 -0700 (PDT) Received: from BL2FFO11FD015.protection.gbl (10.173.161.201) by BL2FFO11HUB023.protection.gbl (10.173.161.47) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 19:09:59 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 19:09:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 19:09:40 +0000 From: Mike Jones To: Russ Housley Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgADgbwCAABQ8wA== Date: Thu, 25 Apr 2013 19:09:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(377424002)(189002)(199002)(24454001)(51704004)(4396001)(66066001)(6806003)(55846006)(77982001)(59766001)(79102001)(49866001)(63696002)(74366001)(33656001)(15202345002)(47736001)(50986001)(81542001)(50466002)(81342001)(54356001)(16406001)(74502001)(74662001)(31966008)(20776003)(56776001)(56816002)(23726002)(47446002)(47776003)(65816001)(46406003)(54316002)(51856001)(69226001)(53806001)(46102001)(47976001)(80022001)(76482001)(44976003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB023; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 19:10:02 -0000 Hi Russ, I agree that enabling GCM to be safely used in the multiple recipients case= would be highly desirable. It is currently prohibited because if the reci= pients share a common key and initialization vector (IV) but use different = AAD values, this results in the identified vulnerability. One possible sol= ution that continues integrity protecting the headers but enables the safe = use of GCM was identified off-list by John Bradley. =20 That solution is to have each recipient always use the same key, IV, and AA= D values. This could be accomplished by including all the header values in= a single combined AAD value, rather than having the integrity protection f= or each recipient's headers be independent. This change could be done in a manner that doesn't affect the computation f= or the single recipients case. Given the upcoming interim JOSE meeting nex= t week, and given the (understandable) strong negative reaction to the unus= ability of GCM with the current multiple recipients processing rules, I'll = plan on quickly producing a draft -10 that changes the processing rules in = the manner described above, so that idea can be concretely considered by th= e working group next week. Just so people are clear on the properties on the new processing rules - th= is would mean that the integrity computations for each recipients would no = longer be independent. The only downside of this (which could be an upside= in some ways) is that it would no longer be possible to add recipients ove= r time without performing a new encryption computation with a new CEK and I= V. Cheers, -- Mike -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Thursday, April 25, 2013 10:31 AM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike: Like Jim, I cannot support this statement: AES GCM MUST NOT be used when us= ing the JWE JSON Serialization for multiple recipients All recipients ought to be performing decryption and integrity checking wit= h the same GCM key. The manner in which they obtain that key may be differ= ent (key transport: decrypt the GCM key with the recipient's private key, k= ey agreement: agreement of a pairwise KEK and then unwrapping the GCM key w= ith the KEK, pre-shared KEK: unwrapping the GCM key with the already known = KEK, etc). Russ On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > Mike, >=20 > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. >=20 > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can=20 > predict that the AD and IESG along with the security directorate would=20 > crucify me if I allowed this to stand in the document.. >=20 > Jim >=20 >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >> Of internet-drafts@ietf.org >> Sent: Tuesday, April 23, 2013 5:29 PM >> To: i-d-announce@ietf.org >> Cc: jose@ietf.org >> Subject: [jose] I-D Action:=20 >> draft-ietf-jose-json-web-encryption-09.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Javascript Object Signing and=20 >> Encryption Working Group of the IETF. >>=20 >> Title : JSON Web Encryption (JWE) >> Author(s) : Michael B. Jones >> Eric Rescorla >> Joe Hildebrand >> Filename : draft-ietf-jose-json-web-encryption-09.txt >> Pages : 54 >> Date : 2013-04-23 >>=20 >> Abstract: >> JSON Web Encryption (JWE) is a means of representing encrypted >> content using JavaScript Object Notation (JSON) data structures. >> Cryptographic algorithms and identifiers for use with this >> specification are described in the separate JSON Web Algorithms (JWA) >> specification. Related digital signature and MAC capabilities are >> described in the separate JSON Web Signature (JWS) specification. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption- >> 09 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Thu Apr 25 12:15:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5821F9612 for ; Thu, 25 Apr 2013 12:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+kBreSZgPgU for ; Thu, 25 Apr 2013 12:15:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8467E21F93F0 for ; Thu, 25 Apr 2013 12:15:13 -0700 (PDT) Received: from BN1BFFO11FD018.protection.gbl (10.58.52.200) by BN1BFFO11HUB001.protection.gbl (10.58.53.111) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 19:15:05 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD018.mail.protection.outlook.com (10.58.53.78) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 19:15:04 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 19:14:30 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgAAqctCAAMIPAIAAB4vg Date: Thu, 25 Apr 2013 19:14:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676C0128TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377424002)(377454001)(24454001)(189002)(51704004)(13464002)(59766001)(54316002)(47736001)(20776003)(54356001)(47446002)(49866001)(79102001)(47976001)(50986001)(56776001)(63696002)(4396001)(76482001)(53806001)(66066001)(55846006)(15202345002)(71186001)(81542001)(46102001)(77982001)(74366001)(512954001)(65816001)(33656001)(16406001)(69226001)(51856001)(16236675002)(81342001)(74662001)(564824004)(74502001)(16297215002)(56816002)(6806003)(80022001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB001; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 19:15:19 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676C0128TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, Actually, there are four goals in play: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity protection 4. Independent protection of each recipient's headers Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. (Cred= it goes to John Bradley for this solution.) -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 11:14 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, Your facts are right, but your conclusions are wrong. We have three mutually incompatible goals here: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity We can have any two of these, but not all three. If we try to do all three= (JWE-08), then we end up with the vulnerability identified in the CFRG thr= ead. So we need to choose which one to get rid of. Getting rid of GCM is clearly not the right answer, as evidenced by the rea= ction in this thread. There are clear, concrete use reasons to support mul= tiple recipients, but not for header integrity. And header integrity can b= e "polyfilled" with an optional feature, for those who are willing to break= the multiple recipient case. Clearly, header integrity is the weakest lin= k here. JWE-09 is the reductio ad absurdum of header integrity. Let's do the logic= al thing and stop the absurdity. --Richard On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones > wrote: Jim - I am surprised that you would say that my co-authors Eric Rescorla or= Joe Hildebrand or the working group would advocate using AES GCM in a way = that would result in severe security vulnerabilities - in particular, allow= ing attackers to obtain the XOR of the messages to multiple recipients encr= ypted using GCM - a vulnerability identified by the CFRG. Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = As I said to Richard Barnes over dinner last night, while unpleasant, and = possibly surprising to those who aren't familiar to how GCM actually works,= as an editor, I viewed including the statement that "AES GCM MUST NOT be u= sed when using the JWE JSON Serialization for multiple recipients, since th= is would result in the same Initialization Vector and Plaintext values bein= g used for multiple GCM encryptions" as necessary, and "truth in advertisin= g". -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 24, 2013 9:07 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF. > > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 > > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > 9 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676C0128TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 <= /p>

Actually, there are four = goals in play:

 <= /p>

1.  GCM

2.  Efficient encodi= ng for multiple recipients

3.  Header integrity= protection

4.  Independent prot= ection of each recipient’s headers

 <= /p>

Per my response to Russ, = by giving up 4, we can achieve 1, 2, and 3.  (Credit goes to John Brad= ley for this solution.)

 <= /p>

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

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 11:14 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

Mike, 

 

Your facts are right, but your conclusions are wrong= .

 

We have three mutually incompatible goals here:=

1. GCM

2. Efficient encoding for multiple recipients

3. Header integrity

 

We can have any two of these, but not all three. &nb= sp;If we try to do all three (JWE-08), then we end up with the vulnerabilit= y identified in the CFRG thread.  So we need to choose which one to ge= t rid of.

 

Getting rid of GCM is clearly not the right answer, = as evidenced by the reaction in this thread.  There are clear, concret= e use reasons to support multiple recipients, but not for header integrity.=  And header integrity can be "polyfilled" with an optional feature, for those who are willing to break the multiple = recipient case.  Clearly, header integrity is the weakest link here.

 

JWE-09 is the reductio ad absurdum of header integri= ty.  Let's do the logical thing and stop the absurdity.

 

--Richard

 

 

 

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Jim - I am surprised that you would say that my co-a= uthors Eric Rescorla or Joe Hildebrand or the working group would advocate = using AES GCM in a way that would result in severe security vulnerabilities= - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using G= CM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. =  As I said to Richard Barnes over dinner last night, while unpleasant,= and possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed includin= g the statement that "AES GCM MUST NOT be used when using the JWE JSON= Serialization for multiple recipients, since this would result in the same= Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and &qu= ot;truth in advertising".

              &nb= sp;                 -- Mike<= /span>


-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the same
   Initialization Vector and Plaintext values being used for mult= iple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.or= g
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org=
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt=
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>  This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF.
>
>       Title           : JSON W= eb Encryption (JWE)
>       Author(s)       : Michael B. Jones=
>                     =       Eric Rescorla
>                     =       Joe Hildebrand
>       Filename        : draft-ietf-= jose-json-web-encryption-09.txt
>       Pages           : 54
>       Date            : 2= 013-04-23
>
> Abstract:
>    JSON Web Encryption (JWE) is a means of representing encr= ypted
>    content using JavaScript Object Notation (JSON) data stru= ctures.
>    Cryptographic algorithms and identifiers for use with thi= s
>    specification are described in the separate JSON Web Algo= rithms (JWA)
>    specification.  Related digital signature and MAC ca= pabilities are
>    described in the separate JSON Web Signature (JWS) specif= ication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B1680429673943676C0128TK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Thu Apr 25 13:41:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2121F96CD for ; Thu, 25 Apr 2013 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 052f7TMSf4Fk for ; Thu, 25 Apr 2013 13:41:12 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4021F96CC for ; Thu, 25 Apr 2013 13:41:09 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id j5so3115639iaf.32 for ; Thu, 25 Apr 2013 13:41:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Eq96Pfs/h7N9lGNeCnOcnWJjinEZY/iFPBTVEiA64H0=; b=kJKTvL0BE/iFhnwt8fznmeMWX3Mh67HfQAKwyyJRv5I6KVTq/bhWaFP8RFBToj68qf tlsbWoTSdP1Px8s8P8RR4rmyUUgRwWYMorbi+SpXGPP+RT60RgzdM5dP1vAhbZQQnvxx gAEuHCLyIAQNwxIGyxwINQQ/D3dZrk+oguyAnEnrUe2hnR7u1AKB8KE3kNz9w5GC880G /qPpU/yXBCG9/hl585sL5cqzL24RZ0jrBCCOp4/R0xSO5Xlvp7tIB4+HH5RMqPcZEFeE XYWZCLB5nTVaCNkKaDgjo+QfNeUkBGGfmqrOYf91unukdre+oQunzodkcpHJTAExoNoM iLgw== X-Received: by 10.42.155.66 with SMTP id t2mr22374476icw.10.1366922468735; Thu, 25 Apr 2013 13:41:08 -0700 (PDT) Received: from [192.168.1.39] (190-20-16-122.baf.movistar.cl. [190.20.16.122]) by mx.google.com with ESMTPSA id p9sm36041384iga.7.2013.04.25.13.40.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 13:41:05 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8AD86A83-989E-4F2A-A03C-0C2D05A2F56A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 17:40:47 -0300 Message-Id: References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlmQs8f6paxvVQjHjhN24xpQRn/vxRYClR5twZToHngsYcWDmUXvTxY+DQ0/RxJGKVXSzll Cc: Richard Barnes , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 20:41:13 -0000 --Apple-Mail=_8AD86A83-989E-4F2A-A03C-0C2D05A2F56A Content-Type: multipart/alternative; boundary="Apple-Mail=_4AD00014-CB3C-4054-9E8F-3E3ABCCF4B7B" --Apple-Mail=_4AD00014-CB3C-4054-9E8F-3E3ABCCF4B7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For multiple recipients using GCM with a single CEK and IV we can = logically have 0 AAD segments or 1 AAD segment. That is just the reality of the situation. =20 One possible solution is to the GCM issue is to have 1 AAD segment = containing the envelope information for all recipients. I understand for people wanting 0 AAD segments that will not be there = first choice. The downside of this is that you can't incrementally add recipients, = they all need to be known upfront to include the info in the AAD. What I don't know is if there is really any compelling use-case for = incremental addition of recipients without re-encrypting (changing the = IV atleast) John B. . =20 On 2013-04-25, at 4:14 PM, Mike Jones = wrote: > Hi Richard, > =20 > Actually, there are four goals in play: > =20 > 1. GCM > 2. Efficient encoding for multiple recipients > 3. Header integrity protection > 4. Independent protection of each recipient=92s headers > =20 > Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. = (Credit goes to John Bradley for this solution.) > =20 > -- Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Thursday, April 25, 2013 11:14 AM > To: Mike Jones > Cc: Jim Schaad; jose@ietf.org > Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt > =20 > Mike,=20 > =20 > Your facts are right, but your conclusions are wrong. > =20 > We have three mutually incompatible goals here: > 1. GCM > 2. Efficient encoding for multiple recipients > 3. Header integrity > =20 > We can have any two of these, but not all three. If we try to do all = three (JWE-08), then we end up with the vulnerability identified in the = CFRG thread. So we need to choose which one to get rid of. > =20 > Getting rid of GCM is clearly not the right answer, as evidenced by = the reaction in this thread. There are clear, concrete use reasons to = support multiple recipients, but not for header integrity. And header = integrity can be "polyfilled" with an optional feature, for those who = are willing to break the multiple recipient case. Clearly, header = integrity is the weakest link here. > =20 > JWE-09 is the reductio ad absurdum of header integrity. Let's do the = logical thing and stop the absurdity. > =20 > --Richard > =20 > =20 > =20 >=20 > On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones = wrote: > Jim - I am surprised that you would say that my co-authors Eric = Rescorla or Joe Hildebrand or the working group would advocate using AES = GCM in a way that would result in severe security vulnerabilities - in = particular, allowing attackers to obtain the XOR of the messages to = multiple recipients encrypted using GCM - a vulnerability identified by = the CFRG. >=20 > Not stating this in the document would seem to me to be highly = irresponsible, given the brittleness of GCM in this regard, as = identified by the CRFG. As I said to Richard Barnes over dinner last = night, while unpleasant, and possibly surprising to those who aren't = familiar to how GCM actually works, as an editor, I viewed including the = statement that "AES GCM MUST NOT be used when using the JWE JSON = Serialization for multiple recipients, since this would result in the = same Initialization Vector and Plaintext values being used for multiple = GCM encryptions" as necessary, and "truth in advertising". >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Jim Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt >=20 > Mike, >=20 > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. >=20 > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can = predict that the AD and IESG along with the security directorate would = crucify me if I allowed this to stand in the document.. >=20 > Jim >=20 >=20 >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: i-d-announce@ietf.org > > Cc: jose@ietf.org > > Subject: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms = (JWA) > > specification. Related digital signature and MAC capabilities = are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_4AD00014-CB3C-4054-9E8F-3E3ABCCF4B7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 For multiple recipients using = GCM with a single CEK and IV we can logically have 0 AAD segments or 1 = AAD segment.

That is just the reality of the = situation.  

One possible solution is to = the GCM issue is to have 1 AAD segment containing the envelope = information for all recipients.
I understand for people = wanting 0 AAD segments that will not be there first = choice.

The downside of this is that you can't = incrementally add recipients, they all need to be known upfront to = include the info in the AAD.

What I don't know = is if there is really any compelling use-case for incremental addition = of recipients without re-encrypting (changing the IV = atleast)

John B.
 . =  

On 2013-04-25, at 4:14 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Hi = Richard,
 
Actually, there are four goals in = play:
 
1.  GCM
2.  Efficient = encoding for multiple recipients
3.  Header = integrity protection
4.  Independent protection of each = recipient=92s headers
 
Per my response to Russ, by giving up 4, we = can achieve 1, 2, and 3.  (Credit goes to John Bradley for this = solution.)
 
 
 
Mike, 
Your = facts are right, but your conclusions are = wrong.
We = have three mutually incompatible goals = here:
1. = GCM
2. Efficient = encoding for multiple recipients
3. Header integrity
 
We can have any two of these, but not all three. =  If we try to do all three (JWE-08), then we end up with the = vulnerability identified in the CFRG thread.  So we need to choose = which one to get rid of.
 
 

On = Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Jim - I am surprised that you would say that my = co-authors Eric Rescorla or Joe Hildebrand or the working group would = advocate using AES GCM in a way that would result in severe security = vulnerabilities - in particular, allowing attackers to obtain the XOR of = the messages to multiple recipients encrypted using GCM - a = vulnerability identified by the CFRG.

Not stating this in the = document would seem to me to be highly irresponsible, given the = brittleness of GCM in this regard, as identified by the CRFG.  As I = said to Richard Barnes over dinner last night, while unpleasant, and = possibly surprising to those who aren't familiar to how GCM actually = works, as an editor, I viewed including the statement that "AES GCM MUST = NOT be used when using the JWE JSON Serialization for multiple = recipients, since this would result in the same Initialization Vector = and Plaintext values being used for multiple GCM encryptions" as = necessary, and "truth in advertising".

        =                     =     -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt

Mike,

AES GCM = MUST NOT be used when using the JWE JSON Serialization for
  =  multiple recipients, since this would result in the same
  =  Initialization Vector and Plaintext values being used for = multiple
   GCM encryptions.

I doubt your co-authors = would agree with this.
I doubt the working group with agree with = this.
I know that at least one co-chair does not agree with this I = can predict that the AD and IESG along with the security directorate = would crucify me if I allowed this to stand in the = document..

Jim



> -----Original = Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf
> Of internet-drafts@ietf.org
> Sent: = Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt
>
>
> A New = Internet-Draft is available from the on-line = Internet-Drafts
directories.
>  This draft is a work item = of the Javascript Object Signing and
> Encryption Working Group of = the IETF.
>
>       Title     =       : JSON Web Encryption (JWE)
>     =   Author(s)       : Michael B. Jones
>   =                     =     Eric Rescorla
>           =                 Joe = Hildebrand
>       Filename       =  : draft-ietf-jose-json-web-encryption-09.txt
>     =   Pages           : 54
>   =     Date            : = 2013-04-23
>
> Abstract:
>    JSON Web = Encryption (JWE) is a means of representing encrypted
>   =  content using JavaScript Object Notation (JSON) data = structures.
>    Cryptographic algorithms and = identifiers for use with this
>    specification are = described in the separate JSON Web Algorithms (JWA)
>   =  specification.  Related digital signature and MAC = capabilities are
>    described in the separate JSON Web = Signature (JWS) specification.
>
>
> The IETF = datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption=
>
> There's also a htmlized version available = at:
>  http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0=
> 9
>
>
> Internet-Drafts are also = available by anonymous FTP at:
>  jose@ietf.org
> jose@ietf.org
jose@ietf.org
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_4AD00014-CB3C-4054-9E8F-3E3ABCCF4B7B-- --Apple-Mail=_8AD86A83-989E-4F2A-A03C-0C2D05A2F56A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MjA0MDUwWjAjBgkqhkiG9w0BCQQxFgQULa0OV9ww Se5CrnB9Y887jNloqFUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAToxziJ2FcieZVyMYb42eo9lDHzfXsLWMm613hqgO BLnSDCalyMuC8FDQw68H6hIfFJwMk/tjsyx5jl2MHse4pGxbUwMW6hFpyjcoklrNkSAgLJmdxUIa 8JD3qzzxRXH3IoVZAvcn6qDUyEgIMwyAAgfMb2JuMWx+6RfQ0qOIya+T89ZFn0f6XvDQ5JH3r3lK fOMtQTzAAChY9tfjn84N4Otj1Z9pyd07BoGM6l7uTuLUr6tAD4JQg8KFulnsVcFX+e+IW0pwsvaq /7vDpD2F/is+rYgW7BM0kDUWUT7A9TqVrhrlOwej4C6jrVpNQvgFBR+idcNKG3kSH4joZAirQQAA AAAAAA== --Apple-Mail=_8AD86A83-989E-4F2A-A03C-0C2D05A2F56A-- From ietf@augustcellars.com Thu Apr 25 13:55:53 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6921F9671 for ; Thu, 25 Apr 2013 13:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-boO0+wCZKb for ; Thu, 25 Apr 2013 13:55:52 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7021F965F for ; Thu, 25 Apr 2013 13:55:52 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 291132CA43; Thu, 25 Apr 2013 13:55:52 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 13:55:08 -0700 Message-ID: <01d401ce41f7$2c1982c0$844c8840$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGMAkutZDO/mM1MbqdkRoeXZXifIQLyRoVOAcuhJmmZRfkRgA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 20:55:53 -0000 Mike, There are two possible reasons for me to make the statement. First - that it is unacceptable that we are making the statement that the use of AES-GCM - the current standard AEAD algorithm - cannot be used with this or Second - that the statement of non-use is insufficiently broad to cover the needed cases. The correct statement would be that This JSON serialization format re-uses the same IV/Key pair for multiple recipients. This means that the algorithm used MUST NOT have any issues with IV/Key pair re-use. It is known at this time this will eliminate the ability to use any algorithm which uses counter mode for encryption. Among the AEAD algorithms that use counter mode for their encryption mode is AES-GCM and thus AES-GCM MUST NOT be used with multiple recipients. It is noted that almost all (if not all) of the current crop of AEAD algorithms are using CTR mode and thus cannot be used with this specification. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, April 24, 2013 11:48 PM > To: Jim Schaad > Cc: jose@ietf.org > Subject: RE: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > Jim - I am surprised that you would say that my co-authors Eric Rescorla or Joe > Hildebrand or the working group would advocate using AES GCM in a way that > would result in severe security vulnerabilities - in particular, allowing > attackers to obtain the XOR of the messages to multiple recipients encrypted > using GCM - a vulnerability identified by the CFRG. > > Not stating this in the document would seem to me to be highly irresponsible, > given the brittleness of GCM in this regard, as identified by the CRFG. As I said > to Richard Barnes over dinner last night, while unpleasant, and possibly > surprising to those who aren't familiar to how GCM actually works, as an > editor, I viewed including the statement that "AES GCM MUST NOT be used > when using the JWE JSON Serialization for multiple recipients, since this would > result in the same Initialization Vector and Plaintext values being used for > multiple GCM encryptions" as necessary, and "truth in advertising". > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim > Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > Mike, > > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. > > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can predict that the > AD and IESG along with the security directorate would crucify me if I allowed > this to stand in the document.. > > Jim > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: i-d-announce@ietf.org > > Cc: jose@ietf.org > > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms (JWA) > > specification. Related digital signature and MAC capabilities are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Apr 25 14:04:39 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FFF21F963C for ; Thu, 25 Apr 2013 14:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaulklkrxH0K for ; Thu, 25 Apr 2013 14:04:38 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 398D021F961B for ; Thu, 25 Apr 2013 14:04:38 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1F83038F37 for ; Thu, 25 Apr 2013 14:04:33 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 25 Apr 2013 14:03:49 -0700 Message-ID: <01d501ce41f8$6288cb30$279a6190$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D6_01CE41BD.B62B79D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5B+GHqjBCgIi1BRFe4bs1BS13MmQ== Content-Language: en-us Subject: [jose] Theroetical use of SIV AEAD mode in JOSE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:04:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D6_01CE41BD.B62B79D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First, I am not advocating that we should add SIV mode as a standard encryption algorithm to the JOSE specifications. However SIV mode has some interesting properties and has been publicly declared as being IP free so I want to make sure that we do not preclude the use of SIV mode if somebody else wants to play with it. A quick primer on how SIV mode works: 1. Compute the IV to be used for the message. IV = F(Authenticated Data, Plain Text, Encryption Key) 2. Encrypt the Plain Text CipherText = AES-CTR(Plain Text, IV, Encryption Key) Note that I have not looked it up and it has been a while, but I am pretty sure that it does use CTR mode. 3. Compute the authentication Tag AT = IV There are no problems with doing the encoding in that one can present the IV as both the IV and the AT in the encoding so it is not as if one of these fields becomes implicit. However it does mean that the current encoding format for multiple recipients is completely un-usable. One could use the format but it would need to be in a single recipient mode only. This is because the IV and the encrypted text would, of necessity, be unique for each recipient. Jim ------=_NextPart_000_01D6_01CE41BD.B62B79D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First, I = am not advocating that we should add SIV mode as a standard encryption = algorithm to the JOSE specifications.  However SIV mode has some = interesting properties and has been publicly declared as being IP free = so I want to make sure that we do not preclude the use of SIV mode if = somebody else wants to play with it.

 

A quick = primer on how SIV mode works:

 

1.       =  Compute the IV to be used for the = message.  IV =3D F(Authenticated Data, Plain Text, Encryption = Key)

2.       = Encrypt the Plain Text     = CipherText =3D AES-CTR(Plain Text, IV, Encryption Key) 
Note = that I have not looked it up and it has been a while, but I am pretty = sure that it does use CTR mode.

3.       = Compute the authentication Tag    = AT =3D IV

 

 

There are no = problems with doing the encoding in that one can present the IV as both = the IV and the AT in the encoding so it is not as if one of these fields = becomes implicit.  However it does mean that the current encoding = format for multiple recipients is completely un-usable.  One could = use the format but it would need to be in a single recipient mode = only.  This is because the IV and the encrypted text would, of = necessity, be unique for each recipient.

 

Jim

 

------=_NextPart_000_01D6_01CE41BD.B62B79D0-- From housley@vigilsec.com Thu Apr 25 14:40:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445B221F96CB for ; Thu, 25 Apr 2013 14:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[AWL=-0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8j7BXRvzk+n for ; Thu, 25 Apr 2013 14:40:29 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6642421F9716 for ; Thu, 25 Apr 2013 14:40:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B9014F24081; Thu, 25 Apr 2013 17:40:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id FAo66pwIkF1W; Thu, 25 Apr 2013 17:40:01 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D5165F2407E; Thu, 25 Apr 2013 17:40:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-7--75723780 From: Russ Housley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 17:40:16 -0400 Message-Id: <74C39AC5-0C6B-4DC1-A273-3996D97D90A9@vigilsec.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:40:30 -0000 --Apple-Mail-7--75723780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mike: The same message encrypted with different GCM keys is a problem, but = that is not what ought to be going on here. I tried to explain that in = my previous message. The same GCM key is delivered to multiple = recipients, perhaps using different key management techniques. Since = the originator and all of the recipients use exactly the same key = stream, this XOR concern does not arise. Russ On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones = wrote: Jim - I am surprised that you would say that my co-authors Eric Rescorla = or Joe Hildebrand or the working group would advocate using AES GCM in a = way that would result in severe security vulnerabilities - in = particular, allowing attackers to obtain the XOR of the messages to = multiple recipients encrypted using GCM - a vulnerability identified by = the CFRG. Not stating this in the document would seem to me to be highly = irresponsible, given the brittleness of GCM in this regard, as = identified by the CRFG. As I said to Richard Barnes over dinner last = night, while unpleasant, and possibly surprising to those who aren't = familiar to how GCM actually works, as an editor, I viewed including the = statement that "AES GCM MUST NOT be used when using the JWE JSON = Serialization for multiple recipients, since this would result in the = same Initialization Vector and Plaintext values being used for multiple = GCM encryptions" as necessary, and "truth in advertising". -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Jim Schaad Sent: Wednesday, April 24, 2013 9:07 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict = that the AD and IESG along with the security directorate would crucify = me if I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF. > > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 > > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms = (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0= > 9 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-7--75723780 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Mike:

The same message encrypted with different GCM keys is a problem, but that is not what ought to be going on here.  I tried to explain that in my previous message.  The same GCM key is delivered to multiple recipients, perhaps using different key management techniques.  Since the originator and all of the recipients use exactly the same key stream, this XOR concern does not arise.

Russ


On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Jim - I am surprised that you would say that my co-authors Eric Rescorla or Joe Hildebrand or the working group would advocate using AES GCM in a way that would result in severe security vulnerabilities - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using GCM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsible, given the brittleness of GCM in this regard, as identified by the CRFG.  As I said to Richard Barnes over dinner last night, while unpleasant, and possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed including the statement that "AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and "truth in advertising".

                                -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the same
   Initialization Vector and Plaintext values being used for multiple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict that the AD and IESG along with the security directorate would crucify me if I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>  This draft is a work item of the Javascript Object Signing and
> Encryption Working Group of the IETF.
>
>       Title           : JSON Web Encryption (JWE)
>       Author(s)       : Michael B. Jones
>                           Eric Rescorla
>                           Joe Hildebrand
>       Filename        : draft-ietf-jose-json-web-encryption-09.txt
>       Pages           : 54
>       Date            : 2013-04-23
>
> Abstract:
>    JSON Web Encryption (JWE) is a means of representing encrypted
>    content using JavaScript Object Notation (JSON) data structures.
>    Cryptographic algorithms and identifiers for use with this
>    specification are described in the separate JSON Web Algorithms (JWA)
>    specification.  Related digital signature and MAC capabilities are
>    described in the separate JSON Web Signature (JWS) specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-0
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--Apple-Mail-7--75723780-- From housley@vigilsec.com Thu Apr 25 14:45:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F74F21F96C8 for ; Thu, 25 Apr 2013 14:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[AWL=0.000, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUfAgSTNewNH for ; Thu, 25 Apr 2013 14:45:29 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7C21F96C4 for ; Thu, 25 Apr 2013 14:45:26 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D1945F24082; Thu, 25 Apr 2013 17:45:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id zyM2nLhrIxfg; Thu, 25 Apr 2013 17:45:06 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 958EBF2407E; Thu, 25 Apr 2013 17:45:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 17:45:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:45:30 -0000 Mike: If the header is protected with the AAD mechanism in GCM, then it must = cover exactly the same bits for all recipients. I do not see the need for JOSE header integrity. I have said this in = the past. I'm saying it again.... Russ On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > Hi Russ, >=20 > I agree that enabling GCM to be safely used in the multiple recipients = case would be highly desirable. It is currently prohibited because if = the recipients share a common key and initialization vector (IV) but use = different AAD values, this results in the identified vulnerability. One = possible solution that continues integrity protecting the headers but = enables the safe use of GCM was identified off-list by John Bradley. >=20 > That solution is to have each recipient always use the same key, IV, = and AAD values. This could be accomplished by including all the header = values in a single combined AAD value, rather than having the integrity = protection for each recipient's headers be independent. >=20 > This change could be done in a manner that doesn't affect the = computation for the single recipients case. Given the upcoming interim = JOSE meeting next week, and given the (understandable) strong negative = reaction to the unusability of GCM with the current multiple recipients = processing rules, I'll plan on quickly producing a draft -10 that = changes the processing rules in the manner described above, so that idea = can be concretely considered by the working group next week. >=20 > Just so people are clear on the properties on the new processing rules = - this would mean that the integrity computations for each recipients = would no longer be independent. The only downside of this (which could = be an upside in some ways) is that it would no longer be possible to add = recipients over time without performing a new encryption computation = with a new CEK and IV. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Thursday, April 25, 2013 10:31 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt >=20 > Mike: >=20 > Like Jim, I cannot support this statement: AES GCM MUST NOT be used = when using the JWE JSON Serialization for multiple recipients >=20 > All recipients ought to be performing decryption and integrity = checking with the same GCM key. The manner in which they obtain that = key may be different (key transport: decrypt the GCM key with the = recipient's private key, key agreement: agreement of a pairwise KEK and = then unwrapping the GCM key with the KEK, pre-shared KEK: unwrapping the = GCM key with the already known KEK, etc). >=20 > Russ >=20 >=20 > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: >=20 >> Mike, >>=20 >> AES GCM MUST NOT be used when using the JWE JSON Serialization for >> multiple recipients, since this would result in the same >> Initialization Vector and Plaintext values being used for multiple >> GCM encryptions. >>=20 >> I doubt your co-authors would agree with this. >> I doubt the working group with agree with this. >> I know that at least one co-chair does not agree with this I can=20 >> predict that the AD and IESG along with the security directorate = would=20 >> crucify me if I allowed this to stand in the document.. >>=20 >> Jim >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20= >>> Of internet-drafts@ietf.org >>> Sent: Tuesday, April 23, 2013 5:29 PM >>> To: i-d-announce@ietf.org >>> Cc: jose@ietf.org >>> Subject: [jose] I-D Action:=20 >>> draft-ietf-jose-json-web-encryption-09.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Javascript Object Signing and=20 >>> Encryption Working Group of the IETF. >>>=20 >>> Title : JSON Web Encryption (JWE) >>> Author(s) : Michael B. Jones >>> Eric Rescorla >>> Joe Hildebrand >>> Filename : draft-ietf-jose-json-web-encryption-09.txt >>> Pages : 54 >>> Date : 2013-04-23 >>>=20 >>> Abstract: >>> JSON Web Encryption (JWE) is a means of representing encrypted >>> content using JavaScript Object Notation (JSON) data structures. >>> Cryptographic algorithms and identifiers for use with this >>> specification are described in the separate JSON Web Algorithms = (JWA) >>> specification. Related digital signature and MAC capabilities are >>> described in the separate JSON Web Signature (JWS) specification. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption- >>> 09 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From rlb@ipv.sx Thu Apr 25 14:46:12 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B6F21F96D8 for ; Thu, 25 Apr 2013 14:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT-2WrUqAaRH for ; Thu, 25 Apr 2013 14:46:11 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1966B21F96C4 for ; Thu, 25 Apr 2013 14:46:11 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id l20so3374566oag.13 for ; Thu, 25 Apr 2013 14:46:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZQddKEZmGybpZOv3T5MkxBCxtuWdNPNbT+Jwe+PtZY4=; b=cTUfo5Wyck4rf8hqWmbwGwOH0/dplIajbNYoIvgH+ccGcYtDccbMaQM4JBKm4YsAHN pirgeNVw1u4NFmnhiSew8QW6yS+y4XSRyomRjvMNf6iyAwSZjEOP3X3LG1ZwmToTVyi5 Ky7dQEfidxECm0NofdTzrmCx+7PaZqLyCOtczFBQQoQjeSTrFoE/GjJb5DmuasC2GIc+ AU4KJdtvyKUlGkkrhzDeugNNf717+P2qj0xRTezjJKKoO7heqHTZTRvt5uIa4qW0VMa5 k7nyzwn8d4V2XajIHECgP6lHDLMvq8nzRfBaJwMkFB43ynvPtrSxj1CCSyHpesx9Vnu1 ZEOw== MIME-Version: 1.0 X-Received: by 10.60.15.98 with SMTP id w2mr17228518oec.128.1366926370597; Thu, 25 Apr 2013 14:46:10 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 14:46:10 -0700 (PDT) X-Originating-IP: [128.89.253.101] In-Reply-To: <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> Date: Thu, 25 Apr 2013 17:46:10 -0400 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: multipart/alternative; boundary=089e013a0a1ec0fdb504db365819 X-Gm-Message-State: ALoCoQnNibazWdZcc3Nx0ZIq/7TyUMf65MmgvB1lxMWoV+mvYnNCWAFMIH1ADiY1pYy4Nje0r9IJ Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:46:12 -0000 --089e013a0a1ec0fdb504db365819 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley wrote: > Mike: > > If the header is protected with the AAD mechanism in GCM, then it must > cover exactly the same bits for all recipients. > > I do not see the need for JOSE header integrity. I have said this in the > past. I'm saying it again.... > +much_more_than_one > > Russ > > > On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > > > Hi Russ, > > > > I agree that enabling GCM to be safely used in the multiple recipients > case would be highly desirable. It is currently prohibited because if the > recipients share a common key and initialization vector (IV) but use > different AAD values, this results in the identified vulnerability. One > possible solution that continues integrity protecting the headers but > enables the safe use of GCM was identified off-list by John Bradley. > > > > That solution is to have each recipient always use the same key, IV, and > AAD values. This could be accomplished by including all the header values > in a single combined AAD value, rather than having the integrity protection > for each recipient's headers be independent. > > > > This change could be done in a manner that doesn't affect the > computation for the single recipients case. Given the upcoming interim > JOSE meeting next week, and given the (understandable) strong negative > reaction to the unusability of GCM with the current multiple recipients > processing rules, I'll plan on quickly producing a draft -10 that changes > the processing rules in the manner described above, so that idea can be > concretely considered by the working group next week. > > > > Just so people are clear on the properties on the new processing rules - > this would mean that the integrity computations for each recipients would > no longer be independent. The only downside of this (which could be an > upside in some ways) is that it would no longer be possible to add > recipients over time without performing a new encryption computation with a > new CEK and IV. > > > > Cheers, > > -- Mike > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Thursday, April 25, 2013 10:31 AM > > To: Mike Jones > > Cc: jose@ietf.org > > Subject: Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt > > > > Mike: > > > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used when > using the JWE JSON Serialization for multiple recipients > > > > All recipients ought to be performing decryption and integrity checking > with the same GCM key. The manner in which they obtain that key may be > different (key transport: decrypt the GCM key with the recipient's private > key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM > key with the KEK, pre-shared KEK: unwrapping the GCM key with the already > known KEK, etc). > > > > Russ > > > > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > > > >> Mike, > >> > >> AES GCM MUST NOT be used when using the JWE JSON Serialization for > >> multiple recipients, since this would result in the same > >> Initialization Vector and Plaintext values being used for multiple > >> GCM encryptions. > >> > >> I doubt your co-authors would agree with this. > >> I doubt the working group with agree with this. > >> I know that at least one co-chair does not agree with this I can > >> predict that the AD and IESG along with the security directorate would > >> crucify me if I allowed this to stand in the document.. > >> > >> Jim > >> > >> > >> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>> Of internet-drafts@ietf.org > >>> Sent: Tuesday, April 23, 2013 5:29 PM > >>> To: i-d-announce@ietf.org > >>> Cc: jose@ietf.org > >>> Subject: [jose] I-D Action: > >>> draft-ietf-jose-json-web-encryption-09.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the Javascript Object Signing and > >>> Encryption Working Group of the IETF. > >>> > >>> Title : JSON Web Encryption (JWE) > >>> Author(s) : Michael B. Jones > >>> Eric Rescorla > >>> Joe Hildebrand > >>> Filename : draft-ietf-jose-json-web-encryption-09.txt > >>> Pages : 54 > >>> Date : 2013-04-23 > >>> > >>> Abstract: > >>> JSON Web Encryption (JWE) is a means of representing encrypted > >>> content using JavaScript Object Notation (JSON) data structures. > >>> Cryptographic algorithms and identifiers for use with this > >>> specification are described in the separate JSON Web Algorithms (JWA) > >>> specification. Related digital signature and MAC capabilities are > >>> described in the separate JSON Web Signature (JWS) specification. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption- > >>> 09 > >>> > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e013a0a1ec0fdb504db365819 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <housley= @vigilsec.com> wrote:
Mike:

If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients.

I do not see the need for JOSE header integrity. =A0I have said this in the= past. =A0I'm saying it again....

+much_more_than_one


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Russ


On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:

> Hi Russ,
>
> I agree that enabling GCM to be safely used in the multiple recipients= case would be highly desirable. =A0It is currently prohibited because if t= he recipients share a common key and initialization vector (IV) but use dif= ferent AAD values, this results in the identified vulnerability. =A0One pos= sible solution that continues integrity protecting the headers but enables = the safe use of GCM was identified off-list by John Bradley.
>
> That solution is to have each recipient always use the same key, IV, a= nd AAD values. =A0This could be accomplished by including all the header va= lues in a single combined AAD value, rather than having the integrity prote= ction for each recipient's headers be independent.
>
> This change could be done in a manner that doesn't affect the comp= utation for the single recipients case. =A0Given the upcoming interim JOSE = meeting next week, and given the (understandable) strong negative reaction = to the unusability of GCM with the current multiple recipients processing r= ules, I'll plan on quickly producing a draft -10 that changes the proce= ssing rules in the manner described above, so that idea can be concretely c= onsidered by the working group next week.
>
> Just so people are clear on the properties on the new processing rules= - this would mean that the integrity computations for each recipients woul= d no longer be independent. =A0The only downside of this (which could be an= upside in some ways) is that it would no longer be possible to add recipie= nts over time without performing a new encryption computation with a new CE= K and IV.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cheers, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: Russ Housley [mailto:hou= sley@vigilsec.com]
> Sent: Thursday, April 25, 2013 10:31 AM
> To: Mike Jones
> Cc: jose@ietf.org
> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09= .txt
>
> Mike:
>
> Like Jim, I cannot support this statement: AES GCM MUST NOT be used wh= en using the JWE JSON Serialization for multiple recipients
>
> All recipients ought to be performing decryption and integrity checkin= g with the same GCM key. =A0The manner in which they obtain that key may be= different (key transport: decrypt the GCM key with the recipient's pri= vate key, key agreement: agreement of a pairwise KEK and then unwrapping th= e GCM key with the KEK, pre-shared KEK: unwrapping the GCM key with the alr= eady known KEK, etc).
>
> Russ
>
>
> On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:
>
>> Mike,
>>
>> AES GCM MUST NOT be used when using the JWE JSON Serialization for=
>> =A0multiple recipients, since this would result in the same
>> =A0Initialization Vector and Plaintext values being used for multi= ple
>> =A0GCM encryptions.
>>
>> I doubt your co-authors would agree with this.
>> I doubt the working group with agree with this.
>> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate w= ould
>> crucify me if I allowed this to stand in the document..
>>
>> Jim
>>
>>
>>
>>> -----Original Message-----
>>> From: jose-bounces@ie= tf.org [mailto:jose-bounces@ie= tf.org] On Behalf
>>> Of internet-drafts= @ietf.org
>>> Sent: Tuesday, April 23, 2013 5:29 PM
>>> To: i-d-announce@ietf= .org
>>> Cc: jose@ietf.org
>>> Subject: [jose] I-D Action:
>>> draft-ietf-jose-json-web-encryption-09.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Javascript Object Signing and=
>>> Encryption Working Group of the IETF.
>>>
>>> =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE)<= br> >>> =A0 =A0 Author(s) =A0 =A0 =A0 : Michael B. Jones
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla<= br> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joe Hildebrand=
>>> =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-enc= ryption-09.txt
>>> =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 54
>>> =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>>>
>>> Abstract:
>>> =A0JSON Web Encryption (JWE) is a means of representing encryp= ted
>>> =A0content using JavaScript Object Notation (JSON) data struct= ures.
>>> =A0Cryptographic algorithms and identifiers for use with this<= br> >>> =A0specification are described in the separate JSON Web Algori= thms (JWA)
>>> =A0specification. =A0Related digital signature and MAC capabil= ities are
>>> =A0described in the separate JSON Web Signature (JWS) specific= ation.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft= -ietf-jose-json-web-encryption
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-jose-json-web-encryption-
>>> 09
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e013a0a1ec0fdb504db365819-- From rlb@ipv.sx Thu Apr 25 14:50:51 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D8921F96F8 for ; Thu, 25 Apr 2013 14:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=-1.276, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZGDpXJzE2VS for ; Thu, 25 Apr 2013 14:50:50 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1571F21F96F2 for ; Thu, 25 Apr 2013 14:50:49 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id 16so2973648obc.37 for ; Thu, 25 Apr 2013 14:50:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Rf3KTcByvq/UEhjsCuMUFjvgwaE9W4FBTPrDXGsKyrw=; b=g36MtzvbvNMqgq5oyMjlrikeVSzirjkX2i6i1/FO0iUAALa/UWtT/e1pONpX1O3Wpt hDrLMkB6xxhow7Ga4WcfpIFxLliDp1NUBfn8w+PJMuBcNI9X//wFTP75n67u9jj9o4WR ZLvwACjq/ZZ+4Z3gDERqOgVhKtpol8bWuX/c020I1jyj0V6uvKXeJZG+gMe517oX25eA LPimMpBwDhE2uE9a5HdrlJuZgblKjCajrEHZQfElD8TpHS07VT0AX6epPmttOPZ2na3c ndH47+ie6jG2A7Bn36NPcgTKY4BiGOkbk9CB5YxJGUc29OIapDYwnb5F6Dt+RiCaO3cA 0CqA== MIME-Version: 1.0 X-Received: by 10.60.121.104 with SMTP id lj8mr17505783oeb.83.1366926649605; Thu, 25 Apr 2013 14:50:49 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 14:50:49 -0700 (PDT) X-Originating-IP: [128.89.253.101] In-Reply-To: References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 17:50:49 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=047d7b3a9734624dc404db36697b X-Gm-Message-State: ALoCoQk/yaPVhyneKauzWK0A/OsCs7xvlgXDyYdt44dA4QCq/W7QTUKnHC7EOFdDm/bMOzg/whzp Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:50:51 -0000 --047d7b3a9734624dc404db36697b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2013 at 4:40 PM, John Bradley wrote: > For multiple recipients using GCM with a single CEK and IV we can > logically have 0 AAD segments or 1 AAD segment. > > That is just the reality of the situation. > I would also note that taking the JOSE overhead out of the AAD segment frees it up for the application to use. > One possible solution is to the GCM issue is to have 1 AAD segment > containing the envelope information for all recipients. > I understand for people wanting 0 AAD segments that will not be there > first choice. > > The downside of this is that you can't incrementally add recipients, they > all need to be known upfront to include the info in the AAD. > > What I don't know is if there is really any compelling use-case for > incremental addition of recipients without re-encrypting (changing the IV > atleast) > The XMPP use case is precisely this. When the sender encrypts the message, it doesn't know the set of public keys that it's sending it to. So the only other possible alternative is taking the per-recipient info out of the integrity check. But if we're going to do that, we might as well go all the way and get rid of the integrity check altogether. Applications that want to integrity protect information can put it in the AAD segment on their own. --Richard > > John B. > . > > On 2013-04-25, at 4:14 PM, Mike Jones wrote= : > > Hi Richard,**** > > Actually, there are four goals in play:**** > > 1. GCM**** > 2. Efficient encoding for multiple recipients**** > 3. Header integrity protection**** > 4. Independent protection of each recipient=92s headers**** > > Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. > (Credit goes to John Bradley for this solution.)**** > > -- Mike**** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Thursday, April 25, 2013 11:14 AM > *To:* Mike Jones > *Cc:* Jim Schaad; jose@ietf.org > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > ** ** > Mike, **** > ** ** > Your facts are right, but your conclusions are wrong.**** > ** ** > We have three mutually incompatible goals here:**** > 1. GCM**** > 2. Efficient encoding for multiple recipients**** > 3. Header integrity**** > ** ** > We can have any two of these, but not all three. If we try to do all > three (JWE-08), then we end up with the vulnerability identified in the > CFRG thread. So we need to choose which one to get rid of.**** > ** ** > Getting rid of GCM is clearly not the right answer, as evidenced by the > reaction in this thread. There are clear, concrete use reasons to suppor= t > multiple recipients, but not for header integrity. And header integrity > can be "polyfilled" with an optional feature, for those who are willing t= o > break the multiple recipient case. Clearly, header integrity is the > weakest link here.**** > ** ** > JWE-09 is the reductio ad absurdum of header integrity. Let's do the > logical thing and stop the absurdity.**** > ** ** > --Richard**** > ** ** > ** ** > > ** ** > On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones > wrote:**** > Jim - I am surprised that you would say that my co-authors Eric Rescorla > or Joe Hildebrand or the working group would advocate using AES GCM in a > way that would result in severe security vulnerabilities - in particular, > allowing attackers to obtain the XOR of the messages to multiple recipien= ts > encrypted using GCM - a vulnerability identified by the CFRG. > > Not stating this in the document would seem to me to be highly > irresponsible, given the brittleness of GCM in this regard, as identified > by the CRFG. As I said to Richard Barnes over dinner last night, while > unpleasant, and possibly surprising to those who aren't familiar to how G= CM > actually works, as an editor, I viewed including the statement that "AES > GCM MUST NOT be used when using the JWE JSON Serialization for multiple > recipients, since this would result in the same Initialization Vector and > Plaintext values being used for multiple GCM encryptions" as necessary, a= nd > "truth in advertising". > > -- Mike**** > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.tx= t > > Mike, > > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. > > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can predict > that the AD and IESG along with the security directorate would crucify me > if I allowed this to stand in the document.. > > Jim > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: i-d-announce@ietf.org > > Cc: jose@ietf.org > > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms (JWA= ) > > specification. Related digital signature and MAC capabilities are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-= 0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > ** ** > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > --047d7b3a9734624dc404db36697b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <ve7jtb@ve7= jtb.com> wrote:
For mult= iple recipients using GCM with a single CEK and IV we can logically have 0 = AAD segments or 1 AAD segment.

That is just the reality of the situation.=A0

I would also note that taking the JOSE = overhead out of the AAD segment frees it up for the application to use.

=A0
One possible solution is to the GCM issue = is to have 1 AAD segment containing the envelope information for all recipi= ents.
I understand for people wanting 0 AAD segments that will not be there = first choice.

The downside of this is that you can= 't incrementally add recipients, they all need to be known upfront to i= nclude the info in the AAD.

What I don't know is if there is really any compell= ing use-case for incremental addition of recipients without re-encrypting (= changing the IV atleast)

The XMPP use case is precisely this. =A0When the sender encrypts the messag= e, it doesn't know the set of public keys that it's sending it to.<= /div>

So the only other possible alternative is ta= king the per-recipient info out of the integrity check. =A0But if we're= going to do that, we might as well go all the way and get rid of the integ= rity check altogether. =A0 Applications that want to integrity protect info= rmation can put it in the AAD segment on their own.=A0

--Richard


=A0

John B.
=A0. =A0
=
On 2013-04-25, at 4:14 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Richard,
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif"> =A0
Actually, there are = four goals in play:
=A0
1.=A0 GCM
= 2.=A0 Efficient encoding for multiple recipients
3.=A0 Header integrity protection<= /u>
4.=A0 Independent protection of each recipie= nt=92s headers
=A0
Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3= .=A0 (Credit goes to John Bradley for this solution.)<= /div>
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
=A0
From:=A0Richard Barnes [mailt= o:rlb@ipv.sx]=A0<= /span>
Sent:=A0Thursday, April 25, 2013 11:14 AM
To:= =A0Mike Jones
Cc:=A0Jim Schaad; jose@ietf.org
Subject= :=A0Re: [jose] I-D Action: draft-ietf-jose-json-web-encryp= tion-09.txt
=A0
M= ike,=A0
=A0
Your facts are right, but your conclusions are wrong.
=A0
We have three mutually incompatible goals here:
1. GCM
2. Efficient encoding for multiple recipients
3. Header integrity
=A0
We can have any two of these, but not all three. =A0If we try to do all thr= ee (JWE-08), then we end up with the vulnerability identified in the CFRG t= hread. =A0So we need to choose which one to get rid of.
=A0
Getting rid of GCM is clearly not the right answer, as evidenced by the rea= ction in this thread. =A0There are clear, concrete use reasons to support m= ultiple recipients, but not for header integrity. =A0And header integrity c= an be "polyfilled" with an optional feature, for those who are wi= lling to break the multiple recipient case. =A0Clearly, header integrity is= the weakest link here.
=A0
JWE-09 is the reductio ad absurdum of header integrity. =A0Let's do the= logical thing and stop the absurdity.
=A0
--Richard
=A0
=A0<= /div>

=A0

On Thu, Apr 25, 2013 at 2:= 48 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:
Jim - I am surprised that you would say that my co-a= uthors Eric Rescorla or Joe Hildebrand or the working group would advocate = using AES GCM in a way that would result in severe security vulnerabilities= - in particular, allowing attackers to obtain the XOR of the messages to m= ultiple recipients encrypted using GCM - a vulnerability identified by the = CFRG.

Not stating this in the document would seem to me to be highly irrespon= sible, given the brittleness of GCM in this regard, as identified by the CR= FG. =A0As I said to Richard Barnes over dinner last night, while unpleasant= , and possibly surprising to those who aren't familiar to how GCM actua= lly works, as an editor, I viewed including the statement that "AES GC= M MUST NOT be used when using the JWE JSON Serialization for multiple recip= ients, since this would result in the same Initialization Vector and Plaint= ext values being used for multiple GCM encryptions" as necessary, and = "truth in advertising".

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

-----Original Message-----
From:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc:=A0jose@ietf.org
Subject: Re: [jose] I-D = Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

AES GCM MUST NOT be used when using the JWE JSON Serializa= tion for
=A0 =A0multiple recipients, since this would result in the same=
=A0 =A0Initialization Vector and Plaintext values being used for multip= le
=A0 =A0GCM encryptions.

I doubt your co-authors would agree with thi= s.
I doubt the working group with agree with this.
I know that at lea= st one co-chair does not agree with this I can predict that the AD and IESG= along with the security directorate would crucify me if I allowed this to = stand in the document..

Jim



> -----Original Message-----
> From:= =A0jose-bounces@ietf.org= =A0[mailto:jose-bounces@ietf.org] On Behalf
> Of=A0internet-drafts@= ietf.org
> Sent: Tuesday, April 23, 2013 5:29 PM
> To:=A0i-d-announce@ietf.org
> Cc:=A0jose@ietf.org
> = Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
&= gt;
>
> A New Internet-Draft is available from the on-line Internet-Dr= afts
directories.
> =A0This draft is a work item of the Javascript= Object Signing and
> Encryption Working Group of the IETF.
> > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE)
&= gt; =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Michael B. Jones
> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla
> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joe Hildebrand
> =A0 =A0 = =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-encryption-09.txt > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 54
> =A0 =A0 =A0 Date = =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>
> Abstract:
> =A0 = =A0JSON Web Encryption (JWE) is a means of representing encrypted
> = =A0 =A0content using JavaScript Object Notation (JSON) data structures.
> =A0 =A0Cryptographic algorithms and identifiers for use with this
&= gt; =A0 =A0specification are described in the separate JSON Web Algorithms = (JWA)
> =A0 =A0specification. =A0Related digital signature and MAC ca= pabilities are
> =A0 =A0described in the separate JSON Web Signature (JWS) specificatio= n.
>
>
> The IETF datatracker status page for this draft = is:
>=A0https://datatracker.ietf.org/doc/draft-ietf-jose-j= son-web-encryption
>
> There's also a htmlized version available at:
>=A0http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09=
>
> A diff from the previous version is available at:
>=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-en= cryption-0
> 9
>
>
> Internet-Drafts are also available by anonym= ous FTP at:
>=A0= ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose m= ailing list
>=A0jose@ietf.org=
>=A0https://= www.ietf.org/mailman/listinfo/jose

_____________________________= __________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listin= fo/jose
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=
=A0
_____= __________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--047d7b3a9734624dc404db36697b-- From rlb@ipv.sx Thu Apr 25 14:56:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216F621F970E for ; Thu, 25 Apr 2013 14:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.536 X-Spam-Level: * X-Spam-Status: No, score=1.536 tagged_above=-999 required=5 tests=[AWL=-0.638, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcVYTHC1VKku for ; Thu, 25 Apr 2013 14:56:34 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC021F9706 for ; Thu, 25 Apr 2013 14:56:33 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2991532obq.3 for ; Thu, 25 Apr 2013 14:56:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=d0tRU484BNmL5jNB/ugamvZXOCSfGs8FEA5PBnnn9XQ=; b=Kvbow/4+BLC/s3kApstcKXaT19/cFF2Vp2JC5xEpNAUYgcPhn9W6HOnuAVwbwNdlPP XMfhG0sHDUetD7RM3UXwyANYY281L/6x6+a5fSyBgLfQD1r6QbN+t+EEOC4a7bb+NS4t NLE5c1aPJwnGII5kigFUSnYrn3xI9erCdqVWQaFxCKfapKfXv1OJeneYpVCNE33O2z0A EXlXqm6zLapk5zuGHUWyUee9V/PufzHnquQz4KyszA2G9VfezsCNjCIlN2WOPpVlH7JK xjLDLgtISq25YvGfvd8fZhx8rnlmDrl5/v55z6LlBhLqOg34G8fHoJD7hos1lKlOyKdK OGNA== MIME-Version: 1.0 X-Received: by 10.60.34.98 with SMTP id y2mr21329762oei.74.1366926993538; Thu, 25 Apr 2013 14:56:33 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 14:56:33 -0700 (PDT) X-Originating-IP: [128.89.253.101] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 17:56:33 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e01175d07e2529b04db367d4a X-Gm-Message-State: ALoCoQmsfzMyI+7EualpkJJHkOUsa3IF/FB6Q8OfAdp9Bl3VhIF9ZV6lsbFZ/OMGGCDmhV1Mmnr5 Cc: Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 21:56:35 -0000 --089e01175d07e2529b04db367d4a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones wrote: > Hi Russ, > > I agree that enabling GCM to be safely used in the multiple recipients > case would be highly desirable. It is currently prohibited because if the > recipients share a common key and initialization vector (IV) but use > different AAD values, this results in the identified vulnerability. One > possible solution that continues integrity protecting the headers but > enables the safe use of GCM was identified off-list by John Bradley. > > That solution is to have each recipient always use the same key, IV, and > AAD values. This could be accomplished by including all the header values > in a single combined AAD value, rather than having the integrity protection > for each recipient's headers be independent. > > This change could be done in a manner that doesn't affect the computation > for the single recipients case. Given the upcoming interim JOSE meeting > next week, and given the (understandable) strong negative reaction to the > unusability of GCM with the current multiple recipients processing rules, > I'll plan on quickly producing a draft -10 that changes the processing > rules in the manner described above, so that idea can be concretely > considered by the working group next week. > > Just so people are clear on the properties on the new processing rules - > this would mean that the integrity computations for each recipients would > no longer be independent. The only downside of this (which could be an > upside in some ways) is that it would no longer be possible to add > recipients over time without performing a new encryption computation with a > new CEK and IV. > As I said to John, that is not an acceptable solution because it breaks the XMPP use case. The minimum sensible change is to remove the per-recipient info from the integrity check. --Richard > > Cheers, > -- Mike > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Thursday, April 25, 2013 10:31 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > Mike: > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used when > using the JWE JSON Serialization for multiple recipients > > All recipients ought to be performing decryption and integrity checking > with the same GCM key. The manner in which they obtain that key may be > different (key transport: decrypt the GCM key with the recipient's private > key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM > key with the KEK, pre-shared KEK: unwrapping the GCM key with the already > known KEK, etc). > > Russ > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > > > Mike, > > > > AES GCM MUST NOT be used when using the JWE JSON Serialization for > > multiple recipients, since this would result in the same > > Initialization Vector and Plaintext values being used for multiple > > GCM encryptions. > > > > I doubt your co-authors would agree with this. > > I doubt the working group with agree with this. > > I know that at least one co-chair does not agree with this I can > > predict that the AD and IESG along with the security directorate would > > crucify me if I allowed this to stand in the document.. > > > > Jim > > > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of internet-drafts@ietf.org > >> Sent: Tuesday, April 23, 2013 5:29 PM > >> To: i-d-announce@ietf.org > >> Cc: jose@ietf.org > >> Subject: [jose] I-D Action: > >> draft-ietf-jose-json-web-encryption-09.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> This draft is a work item of the Javascript Object Signing and > >> Encryption Working Group of the IETF. > >> > >> Title : JSON Web Encryption (JWE) > >> Author(s) : Michael B. Jones > >> Eric Rescorla > >> Joe Hildebrand > >> Filename : draft-ietf-jose-json-web-encryption-09.txt > >> Pages : 54 > >> Date : 2013-04-23 > >> > >> Abstract: > >> JSON Web Encryption (JWE) is a means of representing encrypted > >> content using JavaScript Object Notation (JSON) data structures. > >> Cryptographic algorithms and identifiers for use with this > >> specification are described in the separate JSON Web Algorithms (JWA) > >> specification. Related digital signature and MAC capabilities are > >> described in the separate JSON Web Signature (JWS) specification. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption- > >> 09 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --089e01175d07e2529b04db367d4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <Mi= chael.Jones@microsoft.com> wrote:
Hi Russ,

I agree that enabling GCM to be safely used in the multiple recipients case= would be highly desirable. =A0It is currently prohibited because if the re= cipients share a common key and initialization vector (IV) but use differen= t AAD values, this results in the identified vulnerability. =A0One possible= solution that continues integrity protecting the headers but enables the s= afe use of GCM was identified off-list by John Bradley.

That solution is to have each recipient always use the same key, IV, and AA= D values. =A0This could be accomplished by including all the header values = in a single combined AAD value, rather than having the integrity protection= for each recipient's headers be independent.

This change could be done in a manner that doesn't affect the computati= on for the single recipients case. =A0Given the upcoming interim JOSE meeti= ng next week, and given the (understandable) strong negative reaction to th= e unusability of GCM with the current multiple recipients processing rules,= I'll plan on quickly producing a draft -10 that changes the processing= rules in the manner described above, so that idea can be concretely consid= ered by the working group next week.

Just so people are clear on the properties on the new processing rules - th= is would mean that the integrity computations for each recipients would no = longer be independent. =A0The only downside of this (which could be an upsi= de in some ways) is that it would no longer be possible to add recipients o= ver time without performing a new encryption computation with a new CEK and= IV.

As I said to John, that is not an ac= ceptable solution because it breaks the XMPP use case. =A0The minimum sensi= ble change is to remove the per-recipient info from the integrity check. = =A0

--Richard


=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cheers,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: Russ Housley [mailto:housley@= vigilsec.com]
Sent: Thursday, April 25, 2013 10:31 AM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike:

Like Jim, I cannot support this statement: AES GCM MUST NOT be used when us= ing the JWE JSON Serialization for multiple recipients

All recipients ought to be performing decryption and integrity checking wit= h the same GCM key. =A0The manner in which they obtain that key may be diff= erent (key transport: decrypt the GCM key with the recipient's private = key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM= key with the KEK, pre-shared KEK: unwrapping the GCM key with the already = known KEK, etc).

Russ


On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:

> Mike,
>
> AES GCM MUST NOT be used when using the JWE JSON Serialization for
> =A0 multiple recipients, since this would result in the same
> =A0 Initialization Vector and Plaintext values being used for multiple=
> =A0 GCM encryptions.
>
> I doubt your co-authors would agree with this.
> I doubt the working group with agree with this.
> I know that at least one co-chair does not agree with this I can
> predict that the AD and IESG along with the security directorate would=
> crucify me if I allowed this to stand in the document..
>
> Jim
>
>
>
>> -----Original Message-----
>> From: jose-bounces@ietf.o= rg [mailto:jose-bounces@ietf.o= rg] On Behalf
>> Of internet-drafts@iet= f.org
>> Sent: Tuesday, April 23, 2013 5:29 PM
>> To: i-d-announce@ietf.org=
>> Cc: jose@ietf.org
>> Subject: [jose] I-D Action:
>> draft-ietf-jose-json-web-encryption-09.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
> directories.
>> This draft is a work item of the Javascript Object Signing and
>> Encryption Working Group of the IETF.
>>
>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE) >> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Michael B. Jones
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Eric Rescorla >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe Hildebrand<= br> >> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-encr= yption-09.txt
>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 54
>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>>
>> Abstract:
>> =A0 JSON Web Encryption (JWE) is a means of representing encrypted=
>> =A0 content using JavaScript Object Notation (JSON) data structure= s.
>> =A0 Cryptographic algorithms and identifiers for use with this
>> =A0 specification are described in the separate JSON Web Algorithm= s (JWA)
>> =A0 specification. =A0Related digital signature and MAC capabiliti= es are
>> =A0 described in the separate JSON Web Signature (JWS) specificati= on.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-iet= f-jose-json-web-encryption
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-jose-js= on-web-encryption-09
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-jose-json-web-encryption-
>> 09
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> = ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--089e01175d07e2529b04db367d4a-- From mamille2@cisco.com Thu Apr 25 15:02:22 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B67121F9716 for ; Thu, 25 Apr 2013 15:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR87uUkAp+Ql for ; Thu, 25 Apr 2013 15:02:21 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A92C821F9715 for ; Thu, 25 Apr 2013 15:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6001; q=dns/txt; s=iport; t=1366927341; x=1368136941; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=vufrh5bX0Ca2oVWtAT2byblob3rk6eIoT3NrPigIL+8=; b=JyOBarZsE+5UasZHDCyUT/oWnOZzak1bHsGCOKhYGnY4xrUy5H47Hkk6 02pIoamtbuKBv1YIxfVWNftqkeMx0zaF+Q6/t9mMSExXSgJtT887EEP96 cFoXqM9CknsYGP6ZV1zi2lVzJ5nGU+crd85QtMhLvsWRHS/s6u4UKKhjR Q=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMameVGrRDoH/2dsb2JhbABRgwY3vjCBBBZ0gh8BAQEDAXkFCwsOOAJVBhMbh3MFvk+PNQeCbWEDiRGGV4c0hg+LE4MtHQ X-IronPort-AV: E=Sophos;i="4.87,553,1363132800"; d="p7s'?scan'208";a="79631373" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 25 Apr 2013 22:02:21 +0000 Received: from [10.129.24.59] ([10.129.24.59]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3PM2J8E027248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 22:02:20 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_BCFFE21A-D509-480D-9DC6-7362B2DF69B0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Matt Miller In-Reply-To: Date: Thu, 25 Apr 2013 16:02:19 -0600 Message-Id: <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) Cc: Mike Jones , Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:02:22 -0000 --Apple-Mail=_BCFFE21A-D509-480D-9DC6-7362B2DF69B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 25, 2013, at 3:56 PM, Richard Barnes wrote: > On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones = wrote: >=20 >> Hi Russ, >>=20 >> I agree that enabling GCM to be safely used in the multiple = recipients >> case would be highly desirable. It is currently prohibited because = if the >> recipients share a common key and initialization vector (IV) but use >> different AAD values, this results in the identified vulnerability. = One >> possible solution that continues integrity protecting the headers but >> enables the safe use of GCM was identified off-list by John Bradley. >>=20 >> That solution is to have each recipient always use the same key, IV, = and >> AAD values. This could be accomplished by including all the header = values >> in a single combined AAD value, rather than having the integrity = protection >> for each recipient's headers be independent. >>=20 >> This change could be done in a manner that doesn't affect the = computation >> for the single recipients case. Given the upcoming interim JOSE = meeting >> next week, and given the (understandable) strong negative reaction to = the >> unusability of GCM with the current multiple recipients processing = rules, >> I'll plan on quickly producing a draft -10 that changes the = processing >> rules in the manner described above, so that idea can be concretely >> considered by the working group next week. >>=20 >> Just so people are clear on the properties on the new processing = rules - >> this would mean that the integrity computations for each recipients = would >> no longer be independent. The only downside of this (which could be = an >> upside in some ways) is that it would no longer be possible to add >> recipients over time without performing a new encryption computation = with a >> new CEK and IV. >>=20 >=20 > As I said to John, that is not an acceptable solution because it = breaks the > XMPP use case. The minimum sensible change is to remove the = per-recipient > info from the integrity check. >=20 It is not clear to me how John's suggestion utterly breaks the XMPP use = case, unless you have this alternate-reality version of XMPP-E2E you've = not yet told me about (-: The current XMPP document already separates per-recipient info from the = actual protected content. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_BCFFE21A-D509-480D-9DC6-7362B2DF69B0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQyNTIyMDIxOVowIwYJKoZIhvcNAQkEMRYEFEnEpd692AE+gOh2OX05rwRahe+WMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBKlsR87DFTXR5GMdv7dWqVyXHZinV4FEE5cbjXptRb 1+8aYNcqC1TxCBUYnxikuJ8NfmiGOtSWPpLKKqWTBoZqVoSmAd+OrBhq/3Xm1n0bYIoeB7B/cqZG +nHQLCAWPnKk2Hb62SgpR6f6gY4vBy8t16YcifxhJuBLGmPouNe8Cj2s9OVR0UuwuQB0JuRbdIFN JjSTs3WqscPxeoL2oue9lG8MpDAb5/aJhZeTv19DX7+i+FtRkKSOP+SOKOaGc4qImjY/7DLF2hdW 0j9aZlAsWIl0ko1uwVGfGACeAJZjhRjH701ycdsNRLeSPESzTh2fVo2ZfZxZ4XU0TgKenDsSAAAA AAAA --Apple-Mail=_BCFFE21A-D509-480D-9DC6-7362B2DF69B0-- From rlb@ipv.sx Thu Apr 25 15:10:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF0221F970D for ; Thu, 25 Apr 2013 15:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.898 X-Spam-Level: **** X-Spam-Status: No, score=4.898 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R84Qz8EyDL-E for ; Thu, 25 Apr 2013 15:10:08 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 82C2521F9709 for ; Thu, 25 Apr 2013 15:10:08 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp18so3029851obc.34 for ; Thu, 25 Apr 2013 15:10:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vepGnlhwWjqOYl8i6pq7qHFAVv0wrTZzVXM85g+PDpQ=; b=bJiNpq89SBEluCwW1zXAsGC+DAOwpFk4viyaVKGi0iQ+24mE9uXOLjp3RPMwxI/7g3 2EGwDAKr1QDBqsYNBdS4JE50EjL5ndj3Q7NjV2Qb3QonWFlHxD5THIxdP+vb1lw9n/VO p6FxHHOULebj4HlHBpwYuWVUs1nw2YCeAtna4ZX/fGdFh4WGArHyngFVarpUJuj4bj8/ mYUOF2L9MStamOu1wdFnqcgmb3I90Qq4uzDY1DgN8Mzn0CKosuDoEr7dtYM6aoLryZFY ESq39YpgeTr4hkObB/oan7Vx8K+dGBtmmr69Q+LTV0bRRiS9aQ6aEea4WEBbg6Ai9A6r JnSQ== MIME-Version: 1.0 X-Received: by 10.60.56.168 with SMTP id b8mr13363592oeq.5.1366927808004; Thu, 25 Apr 2013 15:10:08 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 15:10:07 -0700 (PDT) X-Originating-IP: [76.21.182.222] In-Reply-To: <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> Date: Thu, 25 Apr 2013 18:10:07 -0400 Message-ID: From: Richard Barnes To: Matt Miller Content-Type: multipart/alternative; boundary=089e0149ca966e137304db36ae85 X-Gm-Message-State: ALoCoQk7uiBbU6Lls//yIHCwyOQhFl9mtpgLk0Jl3dyyYPOVUaNu4mIdHu0Am6GBZ0g5mIXOM4Xc Cc: Mike Jones , Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:10:09 -0000 --089e0149ca966e137304db36ae85 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 6:02 PM, Matt Miller wrote: > > On Apr 25, 2013, at 3:56 PM, Richard Barnes > wrote: > > > On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones >wrote: > > > >> Hi Russ, > >> > >> I agree that enabling GCM to be safely used in the multiple recipients > >> case would be highly desirable. It is currently prohibited because if > the > >> recipients share a common key and initialization vector (IV) but use > >> different AAD values, this results in the identified vulnerability. One > >> possible solution that continues integrity protecting the headers but > >> enables the safe use of GCM was identified off-list by John Bradley. > >> > >> That solution is to have each recipient always use the same key, IV, and > >> AAD values. This could be accomplished by including all the header > values > >> in a single combined AAD value, rather than having the integrity > protection > >> for each recipient's headers be independent. > >> > >> This change could be done in a manner that doesn't affect the > computation > >> for the single recipients case. Given the upcoming interim JOSE meeting > >> next week, and given the (understandable) strong negative reaction to > the > >> unusability of GCM with the current multiple recipients processing > rules, > >> I'll plan on quickly producing a draft -10 that changes the processing > >> rules in the manner described above, so that idea can be concretely > >> considered by the working group next week. > >> > >> Just so people are clear on the properties on the new processing rules - > >> this would mean that the integrity computations for each recipients > would > >> no longer be independent. The only downside of this (which could be an > >> upside in some ways) is that it would no longer be possible to add > >> recipients over time without performing a new encryption computation > with a > >> new CEK and IV. > >> > > > > As I said to John, that is not an acceptable solution because it breaks > the > > XMPP use case. The minimum sensible change is to remove the > per-recipient > > info from the integrity check. > > > > It is not clear to me how John's suggestion utterly breaks the XMPP use > case, unless you have this alternate-reality version of XMPP-E2E you've not > yet told me about (-: > > The current XMPP document already separates per-recipient info from the > actual protected content. > I reject your reality and substitute my own! [1] In my preferred reality, XMPP E2E doesn't have to do the alg=dir hack that it does now. The base format will support multiple recipients cleanly enough to support the XMPP case as well. In any case, preventing incremental addition of recipients is an arbitrary and capricious restriction in the name of a non-existent security benefit. --Richard [1] http://www.youtube.com/watch?v=W8qcccZy03s > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > --089e0149ca966e137304db36ae85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 6:02 PM, Matt Miller <mamille2@c= isco.com> wrote:

On Apr 25, 2013, at 3:56 PM, Richard Barnes <rlb@ipv.sx>
=A0wrote:

> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:
>
>> Hi Russ,
>>
>> I agree that enabling GCM to be safely used in the multiple recipi= ents
>> case would be highly desirable. =A0It is currently prohibited beca= use if the
>> recipients share a common key and initialization vector (IV) but u= se
>> different AAD values, this results in the identified vulnerability= . =A0One
>> possible solution that continues integrity protecting the headers = but
>> enables the safe use of GCM was identified off-list by John Bradle= y.
>>
>> That solution is to have each recipient always use the same key, I= V, and
>> AAD values. =A0This could be accomplished by including all the hea= der values
>> in a single combined AAD value, rather than having the integrity p= rotection
>> for each recipient's headers be independent.
>>
>> This change could be done in a manner that doesn't affect the = computation
>> for the single recipients case. =A0Given the upcoming interim JOSE= meeting
>> next week, and given the (understandable) strong negative reaction= to the
>> unusability of GCM with the current multiple recipients processing= rules,
>> I'll plan on quickly producing a draft -10 that changes the pr= ocessing
>> rules in the manner described above, so that idea can be concretel= y
>> considered by the working group next week.
>>
>> Just so people are clear on the properties on the new processing r= ules -
>> this would mean that the integrity computations for each recipient= s would
>> no longer be independent. =A0The only downside of this (which coul= d be an
>> upside in some ways) is that it would no longer be possible to add=
>> recipients over time without performing a new encryption computati= on with a
>> new CEK and IV.
>>
>
> As I said to John, that is not an acceptable solution because it break= s the
> XMPP use case. =A0The minimum sensible change is to remove the per-rec= ipient
> info from the integrity check.
>

It is not clear to me how John's suggestion utterly breaks = the XMPP use case, unless you have this alternate-reality version of XMPP-E= 2E you've not yet told me about (-:

The current XMPP document already separates per-recipient info from the act= ual protected content.


I reject your reality and substitute my own! [1]

In my preferred reality, XMPP E2E doesn't have to do the alg= =3Ddir hack that it does now. =A0The base format will support multiple reci= pients cleanly enough to support the XMPP case as well.
In any case, preventing incremental addition of recipients= is an arbitrary and capricious restriction in the name of a non-existent s= ecurity benefit.

--Richard


=
=A0


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


--089e0149ca966e137304db36ae85-- From housley@vigilsec.com Thu Apr 25 15:26:15 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ED121F96F8 for ; Thu, 25 Apr 2013 15:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[AWL=-0.000, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oavL5RZgOcBh for ; Thu, 25 Apr 2013 15:26:14 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9421F96F0 for ; Thu, 25 Apr 2013 15:26:14 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 85447F2407E; Thu, 25 Apr 2013 18:26:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 49EWC2amjT-s; Thu, 25 Apr 2013 18:26:05 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 6ACAFF24072; Thu, 25 Apr 2013 18:26:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-12--72969397 From: Russ Housley In-Reply-To: <01d501ce41f8$6288cb30$279a6190$@augustcellars.com> Date: Thu, 25 Apr 2013 18:26:10 -0400 Message-Id: References: <01d501ce41f8$6288cb30$279a6190$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1085) Cc: jose@ietf.org Subject: Re: [jose] Theroetical use of SIV AEAD mode in JOSE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:26:15 -0000 --Apple-Mail-12--72969397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim: I think that the advocates for SIV need to show how to apply it to = multiple recipients and produce the same ciphertext. Otherwise, it is = equivalent to a separate message per recipient. This is worse that the = S/MIME solution for BCC recipients. Russ On Apr 25, 2013, at 5:03 PM, Jim Schaad wrote: > First, I am not advocating that we should add SIV mode as a standard = encryption algorithm to the JOSE specifications. However SIV mode has = some interesting properties and has been publicly declared as being IP = free so I want to make sure that we do not preclude the use of SIV mode = if somebody else wants to play with it. > =20 > A quick primer on how SIV mode works: > =20 > 1. Compute the IV to be used for the message. IV =3D = F(Authenticated Data, Plain Text, Encryption Key) > 2. Encrypt the Plain Text CipherText =3D AES-CTR(Plain Text, = IV, Encryption Key) =20 > Note that I have not looked it up and it has been a while, but I am = pretty sure that it does use CTR mode. > 3. Compute the authentication Tag AT =3D IV > =20 > =20 > There are no problems with doing the encoding in that one can present = the IV as both the IV and the AT in the encoding so it is not as if one = of these fields becomes implicit. However it does mean that the current = encoding format for multiple recipients is completely un-usable. One = could use the format but it would need to be in a single recipient mode = only. This is because the IV and the encrypted text would, of = necessity, be unique for each recipient. > =20 > Jim > =20 --Apple-Mail-12--72969397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
First, I am not advocating = that we should add SIV mode as a standard encryption algorithm to the = JOSE specifications.  However SIV mode has some interesting = properties and has been publicly declared as being IP free so I want to = make sure that we do not preclude the use of SIV mode if somebody else = wants to play with it.
 
A quick primer on how SIV mode works:
 
        Compute = the IV to be used for the message.  IV =3D F(Authenticated Data, = Plain Text, Encryption Key)
       Encrypt the = Plain Text     CipherText =3D AES-CTR(Plain Text, = IV, Encryption Key)  
Note that I have not = looked it up and it has been a while, but I am pretty sure that it does = use CTR mode.
       Compute the = authentication Tag    AT =3D IV
 
 
There are no problems with doing the encoding in that one = can present the IV as both the IV and the AT in the encoding so it is = not as if one of these fields becomes implicit.  However it does = mean that the current encoding format for multiple recipients is = completely un-usable.  One could use the format but it would need = to be in a single recipient mode only.  This is because the IV and = the encrypted text would, of necessity, be unique for each = recipient.
 
Jim
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:29:17 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676C0535TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The same message isn't being encrypted with multiple GCM keys. It is only = encrypted with one key. Indeed, the proposed change that I discussed in my= earlier message to you that would enable the use of GCM with multiple reci= pients would only encrypt the plaintext once. The originator and all recip= ients use exactly the key stream - just as you said. -- Mike From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, April 25, 2013 2:40 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike: The same message encrypted with different GCM keys is a problem, but that i= s not what ought to be going on here. I tried to explain that in my previo= us message. The same GCM key is delivered to multiple recipients, perhaps = using different key management techniques. Since the originator and all of= the recipients use exactly the same key stream, this XOR concern does not = arise. Russ On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones > wrote: Jim - I am surprised that you would say that my co-authors Eric Rescorla or= Joe Hildebrand or the working group would advocate using AES GCM in a way = that would result in severe security vulnerabilities - in particular, allow= ing attackers to obtain the XOR of the messages to multiple recipients encr= ypted using GCM - a vulnerability identified by the CFRG. Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = As I said to Richard Barnes over dinner last night, while unpleasant, and = possibly surprising to those who aren't familiar to how GCM actually works,= as an editor, I viewed including the statement that "AES GCM MUST NOT be u= sed when using the JWE JSON Serialization for multiple recipients, since th= is would result in the same Initialization Vector and Plaintext values bein= g used for multiple GCM encryptions" as necessary, and "truth in advertisin= g". -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 24, 2013 9:07 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF. > > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 > > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > 9 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676C0535TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The same message isn̵= 7;t being encrypted with multiple GCM keys.  It is only encrypted with= one key.  Indeed, the proposed change that I discussed in my earlier message to you that would enable the use of GCM with multiple recipients w= ould only encrypt the plaintext once.  The originator and all recipien= ts use exactly the key stream – just as you said.

 <= /p>

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

 <= /p>

From: Russ Hou= sley [mailto:housley@vigilsec.com]
Sent: Thursday, April 25, 2013 2:40 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

Mike:

 

The same message encrypted with different GCM keys i= s a problem, but that is not what ought to be going on here.  I tried = to explain that in my previous message.  The same GCM key is delivered= to multiple recipients, perhaps using different key management techniques.  Since the originator and all of the recip= ients use exactly the same key stream, this XOR concern does not arise.

 

Russ

 

 

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Jim - I am surprised that you would say that my co-a= uthors Eric Rescorla or Joe Hildebrand or the working group would advocate = using AES GCM in a way that would result in severe security vulnerabilities= - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using G= CM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. =  As I said to Richard Barnes over dinner last night, while unpleasant,= and possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed includin= g the statement that "AES GCM MUST NOT be used when using the JWE JSON= Serialization for multiple recipients, since this would result in the same= Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and &qu= ot;truth in advertising".

              &nb= sp;                 -- Mike<= /span>


-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the same
   Initialization Vector and Plaintext values being used for mult= iple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.or= g
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org=
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt=
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>  This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF.
>
>       Title           : JSON W= eb Encryption (JWE)
>       Author(s)       : Michael B. Jones=
>                     =       Eric Rescorla
>                     =       Joe Hildebrand
>       Filename        : draft-ietf-= jose-json-web-encryption-09.txt
>       Pages           : 54
>       Date            : 2= 013-04-23
>
> Abstract:
>    JSON Web Encryption (JWE) is a means of representing encr= ypted
>    content using JavaScript Object Notation (JSON) data stru= ctures.
>    Cryptographic algorithms and identifiers for use with thi= s
>    specification are described in the separate JSON Web Algo= rithms (JWA)
>    specification.  Related digital signature and MAC ca= pabilities are
>    described in the separate JSON Web Signature (JWS) specif= ication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

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

--_000_4E1F6AAD24975D4BA5B1680429673943676C0535TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Thu Apr 25 15:43:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB56321F972E for ; Thu, 25 Apr 2013 15:43:11 -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=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZPpP-qyDBou for ; Thu, 25 Apr 2013 15:43:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0921F972B for ; Thu, 25 Apr 2013 15:43:08 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.203) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 22:43:07 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 22:43:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 22:42:47 +0000 From: Mike Jones To: Richard Barnes , Russ Housley Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgADgbwCAABQ8wIAAMvAAgAAAOwCAAAvb8A== Date: Thu, 25 Apr 2013 22:42:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676C058BTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(24454001)(377424002)(36944002)(199002)(189002)(13464002)(51704004)(79102001)(564824004)(55846006)(6806003)(512954001)(15202345002)(74662001)(80022001)(4396001)(50986001)(44976003)(65816001)(66066001)(47736001)(16236675002)(74366001)(33656001)(16297215002)(49866001)(77982001)(53806001)(81542001)(16406001)(81342001)(54316002)(20776003)(76482001)(56816002)(74502001)(71186001)(56776001)(63696002)(59766001)(69226001)(46102001)(47446002)(31966008)(47976001)(51856001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB038; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:43:13 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676C058BTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As background on the decision to integrity protect the headers - this didn'= t come out of a vacuum. The JWT designers sought out Ben Laurie's advice i= n 2010 and he'd suggested that the best thing would be to protect everythin= g. Indeed, Ben restated exactly the same position in a CRFG discussion on = the topic earlier this month, writing "Why even discuss these? What is wron= g with the answer "all parameters should be protected"?". Ben's not the only one who believes that it's appropriate to protect the me= tadata. For instance, the abstract of RFC 6211 "Cryptographic Message Synt= ax (CMS) Algorithm Identifier Protection Attribute" begins "The Cryptograph= ic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to a= lgorithm substitution attacks". Like RFC 6211 does for CMS, some would als= o like to prevent those attacks for JOSE. Best wishes= , -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 2:46 PM To: Russ Housley Cc: Mike Jones; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley > wrote: Mike: If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients. I do not see the need for JOSE header integrity. I have said this in the p= ast. I'm saying it again.... +much_more_than_one Russ On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > Hi Russ, > > I agree that enabling GCM to be safely used in the multiple recipients ca= se would be highly desirable. It is currently prohibited because if the re= cipients share a common key and initialization vector (IV) but use differen= t AAD values, this results in the identified vulnerability. One possible s= olution that continues integrity protecting the headers but enables the saf= e use of GCM was identified off-list by John Bradley. > > That solution is to have each recipient always use the same key, IV, and = AAD values. This could be accomplished by including all the header values = in a single combined AAD value, rather than having the integrity protection= for each recipient's headers be independent. > > This change could be done in a manner that doesn't affect the computation= for the single recipients case. Given the upcoming interim JOSE meeting n= ext week, and given the (understandable) strong negative reaction to the un= usability of GCM with the current multiple recipients processing rules, I'l= l plan on quickly producing a draft -10 that changes the processing rules i= n the manner described above, so that idea can be concretely considered by = the working group next week. > > Just so people are clear on the properties on the new processing rules - = this would mean that the integrity computations for each recipients would n= o longer be independent. The only downside of this (which could be an upsi= de in some ways) is that it would no longer be possible to add recipients o= ver time without performing a new encryption computation with a new CEK and= IV. > > Cheers, > -- Mike > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Thursday, April 25, 2013 10:31 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.tx= t > > Mike: > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used when = using the JWE JSON Serialization for multiple recipients > > All recipients ought to be performing decryption and integrity checking w= ith the same GCM key. The manner in which they obtain that key may be diff= erent (key transport: decrypt the GCM key with the recipient's private key,= key agreement: agreement of a pairwise KEK and then unwrapping the GCM key= with the KEK, pre-shared KEK: unwrapping the GCM key with the already know= n KEK, etc). > > Russ > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > >> Mike, >> >> AES GCM MUST NOT be used when using the JWE JSON Serialization for >> multiple recipients, since this would result in the same >> Initialization Vector and Plaintext values being used for multiple >> GCM encryptions. >> >> I doubt your co-authors would agree with this. >> I doubt the working group with agree with this. >> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate would >> crucify me if I allowed this to stand in the document.. >> >> Jim >> >> >> >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf >>> Of internet-drafts@ietf.org >>> Sent: Tuesday, April 23, 2013 5:29 PM >>> To: i-d-announce@ietf.org >>> Cc: jose@ietf.org >>> Subject: [jose] I-D Action: >>> draft-ietf-jose-json-web-encryption-09.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Javascript Object Signing and >>> Encryption Working Group of the IETF. >>> >>> Title : JSON Web Encryption (JWE) >>> Author(s) : Michael B. Jones >>> Eric Rescorla >>> Joe Hildebrand >>> Filename : draft-ietf-jose-json-web-encryption-09.txt >>> Pages : 54 >>> Date : 2013-04-23 >>> >>> Abstract: >>> JSON Web Encryption (JWE) is a means of representing encrypted >>> content using JavaScript Object Notation (JSON) data structures. >>> Cryptographic algorithms and identifiers for use with this >>> specification are described in the separate JSON Web Algorithms (JWA) >>> specification. Related digital signature and MAC capabilities are >>> described in the separate JSON Web Signature (JWS) specification. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption- >>> 09 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676C058BTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As background on th= e decision to integrity protect the headers – this didn’t come = out of a vacuum.  The JWT designers sought out Ben Laurie’s advi= ce in 2010 and he’d suggested that the best thing would be to protect everything.  Indeed, Ben restated exactly the same positio= n in a CRFG discussion on the topic earlier this month, writing “Why even discuss these? What is wrong with the answer "all paramete= rs should be protected"?”.

 

Ben’s not the only one who believes that it’s ap=
propriate to protect the metadata.  For instance, the abstract of RFC =
6211 “Cryptographic Message Syntax (CMS) Algorithm Identifier Protect=
ion Attribute” begins “The Cryptograph=
ic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to a=
lgorithm substitution attacks”.  Like RFC 6211 =
does for CMS, some would also like to prevent those attacks for JOSE.<=
/o:p>

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          Best wishes,

   &= nbsp;            &nb= sp;            =             &nb= sp;            =           -- Mike<= /o:p>

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 2:46 PM
To: Russ Housley
Cc: Mike Jones; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <housley@vigilsec.co= m> wrote:

Mike:

If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients.

I do not see the need for JOSE header integrity.  I have said this in = the past.  I'm saying it again....

 

+much_more_than_one

 

 

 


Russ



On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:

> Hi Russ,
>
> I agree that enabling GCM to be safely used in the multiple recipients= case would be highly desirable.  It is currently prohibited because i= f the recipients share a common key and initialization vector (IV) but use = different AAD values, this results in the identified vulnerability.  One possible solution that continues integ= rity protecting the headers but enables the safe use of GCM was identified = off-list by John Bradley.
>
> That solution is to have each recipient always use the same key, IV, a= nd AAD values.  This could be accomplished by including all the header= values in a single combined AAD value, rather than having the integrity pr= otection for each recipient's headers be independent.
>
> This change could be done in a manner that doesn't affect the computat= ion for the single recipients case.  Given the upcoming interim JOSE m= eeting next week, and given the (understandable) strong negative reaction t= o the unusability of GCM with the current multiple recipients processing rules, I'll plan on quickly producing a dra= ft -10 that changes the processing rules in the manner described above, so = that idea can be concretely considered by the working group next week.
>
> Just so people are clear on the properties on the new processing rules= - this would mean that the integrity computations for each recipients woul= d no longer be independent.  The only downside of this (which could be= an upside in some ways) is that it would no longer be possible to add recipients over time without performing a new= encryption computation with a new CEK and IV.
>
>                     =           Cheers,
>                     =           -- Mike
>
> -----Original Message-----
> From: Russ Housley [mailto:hou= sley@vigilsec.com]
> Sent: Thursday, April 25, 2013 10:31 AM
> To: Mike Jones
> Cc: jose@ietf.org
> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09= .txt
>
> Mike:
>
> Like Jim, I cannot support this statement: AES GCM MUST NOT be used wh= en using the JWE JSON Serialization for multiple recipients
>
> All recipients ought to be performing decryption and integrity checkin= g with the same GCM key.  The manner in which they obtain that key may= be different (key transport: decrypt the GCM key with the recipient's priv= ate key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM key with the KEK, pre-shared KEK: unwrappi= ng the GCM key with the already known KEK, etc).
>
> Russ
>
>
> On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:
>
>> Mike,
>>
>> AES GCM MUST NOT be used when using the JWE JSON Serialization for=
>>  multiple recipients, since this would result in the same
>>  Initialization Vector and Plaintext values being used for mu= ltiple
>>  GCM encryptions.
>>
>> I doubt your co-authors would agree with this.
>> I doubt the working group with agree with this.
>> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate w= ould
>> crucify me if I allowed this to stand in the document..
>>
>> Jim
>>
>>
>>
>>> -----Original Message-----
>>> From: jose-bounces@ie= tf.org [mailto:jose-bounces@ie= tf.org] On Behalf
>>> Of internet-drafts= @ietf.org
>>> Sent: Tuesday, April 23, 2013 5:29 PM
>>> To: i-d-announce@ietf= .org
>>> Cc: jose@ietf.org
>>> Subject: [jose] I-D Action:
>>> draft-ietf-jose-json-web-encryption-09.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Javascript Object Signing and=
>>> Encryption Working Group of the IETF.
>>>
>>>     Title           : JSON = Web Encryption (JWE)
>>>     Author(s)       : Michael B. Jone= s
>>>                  =       Eric Rescorla
>>>                  =       Joe Hildebrand
>>>     Filename        : draft-ietf= -jose-json-web-encryption-09.txt
>>>     Pages           : 54 >>>     Date            : = 2013-04-23
>>>
>>> Abstract:
>>>  JSON Web Encryption (JWE) is a means of representing enc= rypted
>>>  content using JavaScript Object Notation (JSON) data str= uctures.
>>>  Cryptographic algorithms and identifiers for use with th= is
>>>  specification are described in the separate JSON Web Alg= orithms (JWA)
>>>  specification.  Related digital signature and MAC c= apabilities are
>>>  described in the separate JSON Web Signature (JWS) speci= fication.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-=
>>> 09
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B1680429673943676C058BTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Thu Apr 25 15:46:24 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD25621F9729 for ; Thu, 25 Apr 2013 15:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsH6R7Oh6M-D for ; Thu, 25 Apr 2013 15:46:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA5D21F9726 for ; Thu, 25 Apr 2013 15:46:19 -0700 (PDT) Received: from BY2FFO11FD027.protection.gbl (10.1.15.201) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 22:46:11 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 22:46:11 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 22:46:02 +0000 From: Mike Jones To: Richard Barnes , John Bradley Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgAAqctCAAMIPAIAAB4vggAAhhoCAABORgIAADu7A Date: Thu, 25 Apr 2013 22:46:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C05E5@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676C05E5TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704004)(377424002)(377454001)(24454001)(13464002)(199002)(189002)(63696002)(81342001)(76482001)(53806001)(79102001)(65816001)(74366001)(54316002)(15202345002)(44976003)(46102001)(47446002)(56816002)(55846006)(81542001)(80022001)(51856001)(59766001)(6806003)(50986001)(77982001)(47736001)(16236675002)(69226001)(512954001)(20776003)(564824004)(4396001)(47976001)(31966008)(16406001)(49866001)(56776001)(74502001)(33656001)(66066001)(74662001)(71186001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:46:25 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676C05E5TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Applications are now free to add their own AAD information to the JWE heade= r, now that not-understood header parameters must be ignored. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Thursday, April 25, 2013 2:51 PM To: John Bradley Cc: Mike Jones; Jim Schaad; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt On Thu, Apr 25, 2013 at 4:40 PM, John Bradley > wrote: For multiple recipients using GCM with a single CEK and IV we can logically= have 0 AAD segments or 1 AAD segment. That is just the reality of the situation. I would also note that taking the JOSE overhead out of the AAD segment free= s it up for the application to use. One possible solution is to the GCM issue is to have 1 AAD segment containi= ng the envelope information for all recipients. I understand for people wanting 0 AAD segments that will not be there first= choice. The downside of this is that you can't incrementally add recipients, they a= ll need to be known upfront to include the info in the AAD. What I don't know is if there is really any compelling use-case for increme= ntal addition of recipients without re-encrypting (changing the IV atleast) The XMPP use case is precisely this. When the sender encrypts the message,= it doesn't know the set of public keys that it's sending it to. So the only other possible alternative is taking the per-recipient info out= of the integrity check. But if we're going to do that, we might as well g= o all the way and get rid of the integrity check altogether. Applications= that want to integrity protect information can put it in the AAD segment o= n their own. --Richard John B. . On 2013-04-25, at 4:14 PM, Mike Jones > wrote: Hi Richard, Actually, there are four goals in play: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity protection 4. Independent protection of each recipient's headers Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. (Cred= it goes to John Bradley for this solution.) -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 11:14 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, Your facts are right, but your conclusions are wrong. We have three mutually incompatible goals here: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity We can have any two of these, but not all three. If we try to do all three= (JWE-08), then we end up with the vulnerability identified in the CFRG thr= ead. So we need to choose which one to get rid of. Getting rid of GCM is clearly not the right answer, as evidenced by the rea= ction in this thread. There are clear, concrete use reasons to support mul= tiple recipients, but not for header integrity. And header integrity can b= e "polyfilled" with an optional feature, for those who are willing to break= the multiple recipient case. Clearly, header integrity is the weakest lin= k here. JWE-09 is the reductio ad absurdum of header integrity. Let's do the logic= al thing and stop the absurdity. --Richard On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones > wrote: Jim - I am surprised that you would say that my co-authors Eric Rescorla or= Joe Hildebrand or the working group would advocate using AES GCM in a way = that would result in severe security vulnerabilities - in particular, allow= ing attackers to obtain the XOR of the messages to multiple recipients encr= ypted using GCM - a vulnerability identified by the CFRG. Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = As I said to Richard Barnes over dinner last night, while unpleasant, and = possibly surprising to those who aren't familiar to how GCM actually works,= as an editor, I viewed including the statement that "AES GCM MUST NOT be u= sed when using the JWE JSON Serialization for multiple recipients, since th= is would result in the same Initialization Vector and Plaintext values bein= g used for multiple GCM encryptions" as necessary, and "truth in advertisin= g". -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 24, 2013 9:07 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF. > > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 > > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > 9 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676C05E5TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Applications are now free= to add their own AAD information to the JWE header, now that not-understoo= d header parameters must be ignored.

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2013 2:51 PM
To: John Bradley
Cc: Mike Jones; Jim Schaad; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

For multiple recipients using GCM with a single CEK = and IV we can logically have 0 AAD segments or 1 AAD segment.

 

That is just the reality of the situation. 

 

I would also note that taking the JOSE overhead out = of the AAD segment frees it up for the application to use.

 

 

One possible solution is to the GCM issue is to have= 1 AAD segment containing the envelope information for all recipients.=

I understand for people wanting 0 AAD segments that = will not be there first choice.

 

The downside of this is that you can't incrementally= add recipients, they all need to be known upfront to include the info in t= he AAD.

 

What I don't know is if there is really any compelli= ng use-case for incremental addition of recipients without re-encrypting (c= hanging the IV atleast)

 

The XMPP use case is precisely this.  When the = sender encrypts the message, it doesn't know the set of public keys that it= 's sending it to.

 

So the only other possible alternative is taking the= per-recipient info out of the integrity check.  But if we're going to= do that, we might as well go all the way and get rid of the integrity chec= k altogether.   Applications that want to integrity protect information can put it in the AAD segment on their ow= n. 

 

--Richard

 

 

 

 

John B.

 .  

 

On 2013-04-25, at 4:14 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:



Hi Richard,

 <= /p>

Actually, there are four = goals in play:

 <= /p>

1.  GCM<= /o:p>

2.  Efficient encodi= ng for multiple recipients

3.  Header integrity= protection

4.  Independent prot= ection of each recipient’s headers

 <= /p>

Per my response to Russ, = by giving up 4, we can achieve 1, 2, and 3.  (Credit goes to John Brad= ley for this solution.)

 <= /p>

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

 <= /p>

From: Ric= hard Barnes [mailto:rlb@ipv= .sx] 
Sent: Thursday, April 25, 2013 11:14 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryp= tion-09.txt

 

Mike, 

 

Your facts are right, but your conclusions are wrong= .

 

We have three mutually incompatible goals here:=

1. GCM

2. Efficient encoding for multiple recipients

3. Header integrity

 

We can have any two of these, but not all three. &nb= sp;If we try to do all three (JWE-08), then we end up with the vulnerabilit= y identified in the CFRG thread.  So we need to choose which one to ge= t rid of.

 

Getting rid of GCM is clearly not the right answer, = as evidenced by the reaction in this thread.  There are clear, concret= e use reasons to support multiple recipients, but not for header integrity.=  And header integrity can be "polyfilled" with an optional feature, for those who are willing to break the multiple = recipient case.  Clearly, header integrity is the weakest link here.

 

JWE-09 is the reductio ad absurdum of header integri= ty.  Let's do the logical thing and stop the absurdity.

 

--Richard

 

 

 

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

Jim - I am surprised that you would say that my co-a= uthors Eric Rescorla or Joe Hildebrand or the working group would advocate = using AES GCM in a way that would result in severe security vulnerabilities= - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using G= CM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. =  As I said to Richard Barnes over dinner last night, while unpleasant,= and possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed includin= g the statement that "AES GCM MUST NOT be used when using the JWE JSON= Serialization for multiple recipients, since this would result in the same= Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and &qu= ot;truth in advertising".

                     = ;           -- Mike


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the same
   Initialization Vector and Plaintext values being used for mult= iple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: = jose-bounces@ietf.org [mailto:= jose-bounces@ietf.org] On Behalf
> Of = internet-drafts@ietf.org
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt=
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>  This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF.
>
>       Title           : JSON W= eb Encryption (JWE)
>       Author(s)       : Michael B. Jones=
>                     =       Eric Rescorla
>                     =       Joe Hildebrand
>       Filename        : draft-ietf-= jose-json-web-encryption-09.txt
>       Pages           : 54
>       Date            : 2= 013-04-23
>
> Abstract:
>    JSON Web Encryption (JWE) is a means of representing encr= ypted
>    content using JavaScript Object Notation (JSON) data stru= ctures.
>    Cryptographic algorithms and identifiers for use with thi= s
>    specification are described in the separate JSON Web Algo= rithms (JWA)
>    specification.  Related digital signature and MAC ca= pabilities are
>    described in the separate JSON Web Signature (JWS) specif= ication.
>
>
> The IETF datatracker status page for this draft is:
> https://data= tracker.ietf.org/doc/draft-ietf-jose-json-web-encryption
>
> There's also a htmlized version available at:
> http://tools.ie= tf.org/html/draft-ietf-jose-json-web-encryption-09
>
> A diff from the previous version is available at:
> http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0=
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/= jose

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

 

_____________________________________= __________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943676C05E5TK5EX14MBXC283r_-- From ietf@augustcellars.com Thu Apr 25 15:52:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3CD21F9729 for ; Thu, 25 Apr 2013 15:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7tpqVvCU8g9 for ; Thu, 25 Apr 2013 15:52:46 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B921F970F for ; Thu, 25 Apr 2013 15:52:46 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 637382CA64; Thu, 25 Apr 2013 15:52:46 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" References: <01d501ce41f8$6288cb30$279a6190$@augustcellars.com> In-Reply-To: Date: Thu, 25 Apr 2013 15:52:03 -0700 Message-ID: <022801ce4207$81579cd0$8406d670$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0229_01CE41CC.D4FB35D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSF/1VPh9FLwNXZ9yx8wmrHsESAQIAxGPAmc/YYxA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Theroetical use of SIV AEAD mode in JOSE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 22:52:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0229_01CE41CC.D4FB35D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Russ, I don't understand this comment. SIV can be used in CMS today without this problem. Since the encryption key would be common to all of the recipients in CMS Authenticated Enveloped Data there are no problems with using it. Thus it would be equivalent to the S/MIME BCC recipients solution. This would only be an issue for CMS if all of the key management data were included in the authentication process which it is not. Jim From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, April 25, 2013 3:26 PM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Theroetical use of SIV AEAD mode in JOSE Jim: I think that the advocates for SIV need to show how to apply it to multiple recipients and produce the same ciphertext. Otherwise, it is equivalent to a separate message per recipient. This is worse that the S/MIME solution for BCC recipients. Russ On Apr 25, 2013, at 5:03 PM, Jim Schaad wrote: First, I am not advocating that we should add SIV mode as a standard encryption algorithm to the JOSE specifications. However SIV mode has some interesting properties and has been publicly declared as being IP free so I want to make sure that we do not preclude the use of SIV mode if somebody else wants to play with it. A quick primer on how SIV mode works: 1. Compute the IV to be used for the message. IV = F(Authenticated Data, Plain Text, Encryption Key) 2. Encrypt the Plain Text CipherText = AES-CTR(Plain Text, IV, Encryption Key) Note that I have not looked it up and it has been a while, but I am pretty sure that it does use CTR mode. 3. Compute the authentication Tag AT = IV There are no problems with doing the encoding in that one can present the IV as both the IV and the AT in the encoding so it is not as if one of these fields becomes implicit. However it does mean that the current encoding format for multiple recipients is completely un-usable. One could use the format but it would need to be in a single recipient mode only. This is because the IV and the encrypted text would, of necessity, be unique for each recipient. Jim ------=_NextPart_000_0229_01CE41CC.D4FB35D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,

 

I don’t understand this comment.  SIV can be used in CMS = today without this problem.  Since the encryption key would be = common to all of the recipients in CMS Authenticated Enveloped Data = there are no problems with using it.  Thus it would be equivalent = to the S/MIME BCC recipients solution.

 

This would only be an issue for CMS if all of the key management data = were included in the authentication process which it is = not.

 

Jim

 

 

From:= = Russ Housley [mailto:housley@vigilsec.com]
Sent: Thursday, = April 25, 2013 3:26 PM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: Re: [jose] Theroetical use of SIV AEAD = mode in JOSE

 

Jim:

 

I = think that the advocates for SIV need to show how to apply it to = multiple recipients and produce the same ciphertext.  Otherwise, it = is equivalent to a separate message per recipient.  This is worse = that the S/MIME solution for BCC recipients.

 

Russ

 

 

On = Apr 25, 2013, at 5:03 PM, Jim Schaad wrote:



First, I = am not advocating that we should add SIV mode as a standard encryption = algorithm to the JOSE specifications.  However SIV mode has some = interesting properties and has been publicly declared as being IP free = so I want to make sure that we do not preclude the use of SIV mode if = somebody else wants to play with it.

 =

A quick = primer on how SIV mode works:

 =

1.        Compu= te the IV to be used for the message.  IV =3D F(Authenticated Data, = Plain Text, Encryption Key)

2.       Encrypt = the Plain Text     CipherText =3D AES-CTR(Plain = Text, IV, Encryption Key)  
Note that I have not = looked it up and it has been a while, but I am pretty sure that it does = use CTR mode.

3.       Compute = the authentication Tag    AT =3D = IV

 =

 =

There are = no problems with doing the encoding in that one can present the IV as = both the IV and the AT in the encoding so it is not as if one of these = fields becomes implicit.  However it does mean that the current = encoding format for multiple recipients is completely un-usable.  = One could use the format but it would need to be in a single recipient = mode only.  This is because the IV and the encrypted text would, of = necessity, be unique for each = recipient.

 =

Jim

 =

------=_NextPart_000_0229_01CE41CC.D4FB35D0-- From dick.hardt@gmail.com Thu Apr 25 16:01:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DB821F96B3 for ; Thu, 25 Apr 2013 16:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hlc25TYuLSZ for ; Thu, 25 Apr 2013 16:01:27 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1621F8E4C for ; Thu, 25 Apr 2013 16:01:27 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r11so2070680pdi.35 for ; Thu, 25 Apr 2013 16:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=dEy8YhOGoeYJGlkvojNkB0vkjleNEkrZeOGJjaoG/uc=; b=Bej5LqFnZ3Sl3VSO+HWdFUWFPo0r2ozPOFUr/pJ0phnqVQQXkSnmxYMWlLNUSwuGvj KQqrDsnIeT1DSr9g7Oh0p5ZcXCzPE/xUCwb4NOEVgx8uRN/HnP9Snx+HkyNCwR5s3OPk mXzc50/VqHlLlrM6Yt5QoplQBskXUUTbH3HWMZp7+tGGkF0S0pNMFjywB6BjYOBfcca7 Nwt6KHPt2/xTwfnExJiAZALKi0skFj8dDBt2D6Z2cfnEfpfjz77AVVPCtvJ5YAG0ZTkc EpbpQqW5f7+JNtZ5AtWLqSgZ/C1mY0iPpMFB86X9CrmCaZs2xmYV8kcMEvW7LpmO8K5Y FENw== X-Received: by 10.68.88.129 with SMTP id bg1mr55158510pbb.10.1366930887447; Thu, 25 Apr 2013 16:01:27 -0700 (PDT) Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPSA id g8sm9902784pae.7.2013.04.25.16.01.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 16:01:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_217B81D3-FD19-41D7-A11B-506CF316A187" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 16:01:22 -0700 Message-Id: <9335C55E-35A5-457E-960E-4138AA080ACC@gmail.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: Richard Barnes , Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:01:29 -0000 --Apple-Mail=_217B81D3-FD19-41D7-A11B-506CF316A187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FWIW, as an implementor, I would like the headers protected. I don't = require multiple recipients. On Apr 25, 2013, at 3:42 PM, Mike Jones = wrote: > As background on the decision to integrity protect the headers =96 = this didn=92t come out of a vacuum. The JWT designers sought out Ben = Laurie=92s advice in 2010 and he=92d suggested that the best thing would = be to protect everything. Indeed, Ben restated exactly the same = position in a CRFG discussion on the topic earlier this month, writing = =93Why even discuss these? What is wrong with the answer "all parameters = should be protected"?=94. > =20 > Ben=92s not the only one who believes that it=92s appropriate to = protect the metadata. For instance, the abstract of RFC 6211 = =93Cryptographic Message Syntax (CMS) Algorithm Identifier Protection = Attribute=94 begins =93The Cryptographic Message Syntax (CMS), unlike = X.509/PKIX certificates, is vulnerable to algorithm substitution = attacks=94. Like RFC 6211 does for CMS, some would also like to prevent = those attacks for JOSE. > =20 > Best = wishes, > -- = Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Thursday, April 25, 2013 2:46 PM > To: Russ Housley > Cc: Mike Jones; jose@ietf.org > Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt > =20 > On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley = wrote: > Mike: >=20 > If the header is protected with the AAD mechanism in GCM, then it must = cover exactly the same bits for all recipients. >=20 > I do not see the need for JOSE header integrity. I have said this in = the past. I'm saying it again.... > =20 > +much_more_than_one > =20 > =20 > =20 >=20 > Russ >=20 >=20 > On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: >=20 > > Hi Russ, > > > > I agree that enabling GCM to be safely used in the multiple = recipients case would be highly desirable. It is currently prohibited = because if the recipients share a common key and initialization vector = (IV) but use different AAD values, this results in the identified = vulnerability. One possible solution that continues integrity = protecting the headers but enables the safe use of GCM was identified = off-list by John Bradley. > > > > That solution is to have each recipient always use the same key, IV, = and AAD values. This could be accomplished by including all the header = values in a single combined AAD value, rather than having the integrity = protection for each recipient's headers be independent. > > > > This change could be done in a manner that doesn't affect the = computation for the single recipients case. Given the upcoming interim = JOSE meeting next week, and given the (understandable) strong negative = reaction to the unusability of GCM with the current multiple recipients = processing rules, I'll plan on quickly producing a draft -10 that = changes the processing rules in the manner described above, so that idea = can be concretely considered by the working group next week. > > > > Just so people are clear on the properties on the new processing = rules - this would mean that the integrity computations for each = recipients would no longer be independent. The only downside of this = (which could be an upside in some ways) is that it would no longer be = possible to add recipients over time without performing a new encryption = computation with a new CEK and IV. > > > > Cheers, > > -- Mike > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Thursday, April 25, 2013 10:31 AM > > To: Mike Jones > > Cc: jose@ietf.org > > Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt > > > > Mike: > > > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used = when using the JWE JSON Serialization for multiple recipients > > > > All recipients ought to be performing decryption and integrity = checking with the same GCM key. The manner in which they obtain that = key may be different (key transport: decrypt the GCM key with the = recipient's private key, key agreement: agreement of a pairwise KEK and = then unwrapping the GCM key with the KEK, pre-shared KEK: unwrapping the = GCM key with the already known KEK, etc). > > > > Russ > > > > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > > > >> Mike, > >> > >> AES GCM MUST NOT be used when using the JWE JSON Serialization for > >> multiple recipients, since this would result in the same > >> Initialization Vector and Plaintext values being used for multiple > >> GCM encryptions. > >> > >> I doubt your co-authors would agree with this. > >> I doubt the working group with agree with this. > >> I know that at least one co-chair does not agree with this I can > >> predict that the AD and IESG along with the security directorate = would > >> crucify me if I allowed this to stand in the document.. > >> > >> Jim > >> > >> > >> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf > >>> Of internet-drafts@ietf.org > >>> Sent: Tuesday, April 23, 2013 5:29 PM > >>> To: i-d-announce@ietf.org > >>> Cc: jose@ietf.org > >>> Subject: [jose] I-D Action: > >>> draft-ietf-jose-json-web-encryption-09.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the Javascript Object Signing and > >>> Encryption Working Group of the IETF. > >>> > >>> Title : JSON Web Encryption (JWE) > >>> Author(s) : Michael B. Jones > >>> Eric Rescorla > >>> Joe Hildebrand > >>> Filename : draft-ietf-jose-json-web-encryption-09.txt > >>> Pages : 54 > >>> Date : 2013-04-23 > >>> > >>> Abstract: > >>> JSON Web Encryption (JWE) is a means of representing encrypted > >>> content using JavaScript Object Notation (JSON) data structures. > >>> Cryptographic algorithms and identifiers for use with this > >>> specification are described in the separate JSON Web Algorithms = (JWA) > >>> specification. Related digital signature and MAC capabilities = are > >>> described in the separate JSON Web Signature (JWS) specification. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> = https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > >>> > >>> A diff from the previous version is available at: > >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption- > >>> 09 > >>> > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_217B81D3-FD19-41D7-A11B-506CF316A187 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 FWIW, as an implementor, I = would like the headers protected. I don't require multiple = recipients.

On Apr 25, 2013, at 3:42 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

As = background on the decision to integrity protect the headers =96 this = didn=92t come out of a vacuum.  The JWT designers sought out Ben = Laurie=92s advice in 2010 and he=92d suggested that the best thing would = be to protect everything.  Indeed, Ben restated exactly the same = position in a CRFG discussion on the topic earlier this month, writing = =93Why even discuss these? What is wrong with the answer "all = parameters should be protected"? 
The Cryptographic =
Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to =
algorithm substitution attacks=94.  Like RFC 6211 =
does for CMS, some would also like to prevent those attacks for =
JOSE.
 
 
 
On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <housley@vigilsec.com> = wrote:
Mike:

If the header is = protected with the AAD mechanism in GCM, then it must cover exactly the = same bits for all recipients.

I do not see the need for JOSE = header integrity.  I have said this in the past.  I'm saying = it again....
 

Russ


On Apr 25, 2013, at 3:09 PM, Mike Jones = wrote:

> Hi Russ,
>
> I agree that enabling GCM to = be safely used in the multiple recipients case would be highly = desirable.  It is currently prohibited because if the recipients = share a common key and initialization vector (IV) but use different AAD = values, this results in the identified vulnerability.  One possible = solution that continues integrity protecting the headers but enables the = safe use of GCM was identified off-list by John Bradley.
>
> = That solution is to have each recipient always use the same key, IV, and = AAD values.  This could be accomplished by including all the header = values in a single combined AAD value, rather than having the integrity = protection for each recipient's headers be independent.
>
> = This change could be done in a manner that doesn't affect the = computation for the single recipients case.  Given the upcoming = interim JOSE meeting next week, and given the (understandable) strong = negative reaction to the unusability of GCM with the current multiple = recipients processing rules, I'll plan on quickly producing a draft -10 = that changes the processing rules in the manner described above, so that = idea can be concretely considered by the working group next = week.
>
> Just so people are clear on the properties on the = new processing rules - this would mean that the integrity computations = for each recipients would no longer be independent.  The only = downside of this (which could be an upside in some ways) is that it = would no longer be possible to add recipients over time without = performing a new encryption computation with a new CEK and = IV.
>
>               =                 Cheers,
> =                     =           -- Mike
>
> -----Original = Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: = Thursday, April 25, 2013 10:31 AM
> To: Mike Jones
> = Cc: jose@ietf.org
> Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt
>
> = Mike:
>
> Like Jim, I cannot support this statement: AES GCM = MUST NOT be used when using the JWE JSON Serialization for multiple = recipients
>
> All recipients ought to be performing = decryption and integrity checking with the same GCM key.  The = manner in which they obtain that key may be different (key transport: = decrypt the GCM key with the recipient's private key, key agreement: = agreement of a pairwise KEK and then unwrapping the GCM key with the = KEK, pre-shared KEK: unwrapping the GCM key with the already known KEK, = etc).
>
> Russ
>
>
> On Apr 25, 2013, at = 12:07 AM, Jim Schaad wrote:
>
>> = Mike,
>>
>> AES GCM MUST NOT be used when using the = JWE JSON Serialization for
>>  multiple recipients, since = this would result in the same
>>  Initialization Vector = and Plaintext values being used for multiple
>>  GCM = encryptions.
>>
>> I doubt your co-authors would agree = with this.
>> I doubt the working group with agree with = this.
>> I know that at least one co-chair does not agree with = this I can
>> predict that the AD and IESG along with the = security directorate would
>> crucify me if I allowed this to = stand in the document..
>>
>> = Jim
>>
>>
>>
>>> -----Original = Message-----
>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf
>>> Of  i-d-announce@ietf.org
>>> = Cc: jose@ietf.org
>>> Subject: [jose] I-D = Action:
>>> = draft-ietf-jose-json-web-encryption-09.txt
>>>
>>>=
>>> A New Internet-Draft is available from the on-line = Internet-Drafts
>> directories.
>>> This draft is a = work item of the Javascript Object Signing and
>>> = Encryption Working Group of the IETF.
>>>
>>> =     Title           : JSON Web = Encryption (JWE)
>>>     Author(s)     =   : Michael B. Jones
>>>         =                 Eric = Rescorla
>>>             =             Joe Hildebrand
>>> =     Filename        : = draft-ietf-jose-json-web-encryption-09.txt
>>>     = Pages           : 54
>>>   =   Date            : = 2013-04-23
>>>
>>> Abstract:
>>> =  JSON Web Encryption (JWE) is a means of representing = encrypted
>>>  content using JavaScript Object Notation = (JSON) data structures.
>>>  Cryptographic algorithms = and identifiers for use with this
>>>  specification = are described in the separate JSON Web Algorithms (JWA)
>>> =  specification.  Related digital signature and MAC = capabilities are
>>>  described in the separate JSON = Web Signature (JWS) = specification.
>>>
>>>
>>> The IETF = datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption=
>>>
>>> There's also a htmlized version = available at:
>>>  http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-<= /a>
>>> 09
>>>
>>>
>>> = Internet-Drafts are also available by anonymous FTP = at:
>>>  jose@ietf.org
>>>  jose@ietf.org
>> jose@ietf.org
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_217B81D3-FD19-41D7-A11B-506CF316A187-- From rlb@ipv.sx Thu Apr 25 16:05:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F8021F9722 for ; Thu, 25 Apr 2013 16:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[AWL=3.937, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXaUGyMsrhoQ for ; Thu, 25 Apr 2013 16:05:03 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0736721F971B for ; Thu, 25 Apr 2013 16:05:02 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o17so3358892oag.4 for ; Thu, 25 Apr 2013 16:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Ik1NyoRfrLT34FX/WJXkV9IJ5UM+XfMd2MDzBiv4yh4=; b=D9NsVatb0GaFM4Ny81zu7a1Z5xgia8dYvLXtv4+ZRa2AK28RtsHZjuVwfRmfwZIN1R nYfqQ/oRI4eeL9h9RJ7zzKgcJta712JTmy0/elXJjG6U7B4U/XHeeAF0LlAkmoKseL3r jn+eFmpA8TM3e/F/P4raE/+BXs/a11Yq+enWtfi0TTkl3VHar+smr99PiNpuKBE6dm4i vi8mt0G1fPphhPnhpfOktQWUxPX0BDnJk3N/9lu+Vvr+MCe9yGb40bloijnfzgn3wVU3 g2Uo2HVP+2YXc0N41Sk5O+vFMxp0cWx2L/JwtjpZ6HnmLODcNwAvKuFTi4weG74gA8TZ jXIw== MIME-Version: 1.0 X-Received: by 10.60.59.197 with SMTP id b5mr4917491oer.4.1366931100676; Thu, 25 Apr 2013 16:05:00 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 16:05:00 -0700 (PDT) X-Originating-IP: [76.21.182.222] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 19:05:00 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e0149d1b6b043be04db3772b4 X-Gm-Message-State: ALoCoQn9zll5I2cU0INyg/RZYueSWbTTnZuXP+uSHEw3JOuezLuI+GV+QhZYgDmFTTJsOuFMiXnV Cc: Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:05:05 -0000 --089e0149d1b6b043be04db3772b4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones wr= ote: > As background on the decision to integrity protect the headers =96 this > didn=92t come out of a vacuum. The JWT designers sought out Ben Laurie= =92s > advice in 2010 and he=92d suggested that the best thing would be to prote= ct > everything. Indeed, Ben restated exactly the same position in a CRFG > discussion on the topic earlier this month, writing =93Why even discuss > these? What is wrong with the answer "all parameters should be protected"= ? > =94. > You should also note that I answered that question, and Ben backed off significantly from his initial position. There were also several other commenters on the CFRG thread, who did not see utility in mandatory header protection. > Ben=92s not the only one who believes that it=92s appropriate to protect = the metadata. For instance, the abstract of RFC 6211 =93Cryptographic Mess= age Syntax (CMS) Algorithm Identifier Protection Attribute=94 begins =93The= Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vul= nerable to algorithm substitution attacks=94. Like RFC 6211 does for CMS, = some would also like to prevent those attacks for JOSE. > > I agree! There should be an *option* for integrity-protecting parameters, in the limited cases where such protection is necessary. It is not necessary with PKCS#1 v1.5 signatures, since the signature algorithm encodes an OID for the hash algorithm. It is not necessary for JWE. I would be happy to discuss the shape of such an option at the interim next week. --Richard > **** > > ** ** > > Best > wishes,**** > > -- Mike**= * > * > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Thursday, April 25, 2013 2:46 PM > *To:* Russ Housley > *Cc:* Mike Jones; jose@ietf.org > > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > ** ** > > On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley > wrote:**** > > Mike: > > If the header is protected with the AAD mechanism in GCM, then it must > cover exactly the same bits for all recipients. > > I do not see the need for JOSE header integrity. I have said this in the > past. I'm saying it again....**** > > ** ** > > +much_more_than_one**** > > ** ** > > ** ** > > **** > > > Russ**** > > > > On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > > > Hi Russ, > > > > I agree that enabling GCM to be safely used in the multiple recipients > case would be highly desirable. It is currently prohibited because if th= e > recipients share a common key and initialization vector (IV) but use > different AAD values, this results in the identified vulnerability. One > possible solution that continues integrity protecting the headers but > enables the safe use of GCM was identified off-list by John Bradley. > > > > That solution is to have each recipient always use the same key, IV, an= d > AAD values. This could be accomplished by including all the header value= s > in a single combined AAD value, rather than having the integrity protecti= on > for each recipient's headers be independent. > > > > This change could be done in a manner that doesn't affect the > computation for the single recipients case. Given the upcoming interim > JOSE meeting next week, and given the (understandable) strong negative > reaction to the unusability of GCM with the current multiple recipients > processing rules, I'll plan on quickly producing a draft -10 that changes > the processing rules in the manner described above, so that idea can be > concretely considered by the working group next week. > > > > Just so people are clear on the properties on the new processing rules = - > this would mean that the integrity computations for each recipients would > no longer be independent. The only downside of this (which could be an > upside in some ways) is that it would no longer be possible to add > recipients over time without performing a new encryption computation with= a > new CEK and IV. > > > > Cheers, > > -- Mike > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Thursday, April 25, 2013 10:31 AM > > To: Mike Jones > > Cc: jose@ietf.org > > Subject: Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt > > > > Mike: > > > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used whe= n > using the JWE JSON Serialization for multiple recipients > > > > All recipients ought to be performing decryption and integrity checking > with the same GCM key. The manner in which they obtain that key may be > different (key transport: decrypt the GCM key with the recipient's privat= e > key, key agreement: agreement of a pairwise KEK and then unwrapping the G= CM > key with the KEK, pre-shared KEK: unwrapping the GCM key with the already > known KEK, etc). > > > > Russ > > > > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > > > >> Mike, > >> > >> AES GCM MUST NOT be used when using the JWE JSON Serialization for > >> multiple recipients, since this would result in the same > >> Initialization Vector and Plaintext values being used for multiple > >> GCM encryptions. > >> > >> I doubt your co-authors would agree with this. > >> I doubt the working group with agree with this. > >> I know that at least one co-chair does not agree with this I can > >> predict that the AD and IESG along with the security directorate would > >> crucify me if I allowed this to stand in the document.. > >> > >> Jim > >> > >> > >> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>> Of internet-drafts@ietf.org > >>> Sent: Tuesday, April 23, 2013 5:29 PM > >>> To: i-d-announce@ietf.org > >>> Cc: jose@ietf.org > >>> Subject: [jose] I-D Action: > >>> draft-ietf-jose-json-web-encryption-09.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the Javascript Object Signing and > >>> Encryption Working Group of the IETF. > >>> > >>> Title : JSON Web Encryption (JWE) > >>> Author(s) : Michael B. Jones > >>> Eric Rescorla > >>> Joe Hildebrand > >>> Filename : draft-ietf-jose-json-web-encryption-09.txt > >>> Pages : 54 > >>> Date : 2013-04-23 > >>> > >>> Abstract: > >>> JSON Web Encryption (JWE) is a means of representing encrypted > >>> content using JavaScript Object Notation (JSON) data structures. > >>> Cryptographic algorithms and identifiers for use with this > >>> specification are described in the separate JSON Web Algorithms (JWA= ) > >>> specification. Related digital signature and MAC capabilities are > >>> described in the separate JSON Web Signature (JWS) specification. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryptio= n- > >>> 09 > >>> > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --089e0149d1b6b043be04db3772b4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones <Mi= chael.Jones@microsoft.com> wrote:

As background on the decision to integrity= protect the headers =96 this didn=92t come out of a vacuum.=A0 The JWT des= igners sought out Ben Laurie=92s advice in 2010 and he=92d suggested that t= he best thing would be to protect everything. =A0Indeed, Ben restated exactly the same position i= n a CRFG discussion on the topic earlier this month, writing =93Why = even discuss these? What is wrong with the answer "all parameters shou= ld be protected"?=94.

You should also note that I answered th= at question, and Ben backed off significantly from his initial position. = =A0There were also several other commenters on the CFRG thread, who did not= see utility in mandatory header protection.
=A0
Ben=92s not the only one who believes that it=92s appropriat=
e to protect the metadata.=A0 For instance, the abstract of RFC 6211 =93Cry=
ptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute=
=94 begins =93The Cryptographic Message Syntax (CM=
S), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution=
 attacks=94.=A0 Like RFC 6211 does for CMS, some would als=
o like to prevent those attacks for JOSE.
I agree! There should be an *option* fo= r integrity-protecting parameters, in the limited cases where such protecti= on is necessary. =A0It is not necessary with PKCS#1 v1.5 signatures, since = the signature algorithm encodes an OID for the hash algorithm. =A0It is not= necessary for JWE. =A0I would be happy to discuss the shape of such an opt= ion at the interim next week.=A0

--Richard

=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Be= st wishes,

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

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 2:46 PM
To: Russ Housley
Cc: Mike Jones; j= ose@ietf.org


Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

=A0

On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <housley@vigilsec.co= m> wrote:

Mike:

If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients.

I do not see the need for JOSE header integrity. =A0I have said this in the= past. =A0I'm saying it again....

=A0

+much_more_than_one

=A0

=A0

=A0


Russ



On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:

> Hi Russ,
>
> I agree that enabling GCM to be safely used in the multiple recipients= case would be highly desirable. =A0It is currently prohibited because if t= he recipients share a common key and initialization vector (IV) but use dif= ferent AAD values, this results in the identified vulnerability. =A0One possible solution that continues integrit= y protecting the headers but enables the safe use of GCM was identified off= -list by John Bradley.
>
> That solution is to have each recipient always use the same key, IV, a= nd AAD values. =A0This could be accomplished by including all the header va= lues in a single combined AAD value, rather than having the integrity prote= ction for each recipient's headers be independent.
>
> This change could be done in a manner that doesn't affect the comp= utation for the single recipients case. =A0Given the upcoming interim JOSE = meeting next week, and given the (understandable) strong negative reaction = to the unusability of GCM with the current multiple recipients processing rules, I'll plan on quickly producing a= draft -10 that changes the processing rules in the manner described above,= so that idea can be concretely considered by the working group next week.<= br> >
> Just so people are clear on the properties on the new processing rules= - this would mean that the integrity computations for each recipients woul= d no longer be independent. =A0The only downside of this (which could be an= upside in some ways) is that it would no longer be possible to add recipients over time without performing a new= encryption computation with a new CEK and IV.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cheers, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Thursday, April 25, 2013 10:31 AM
> To: Mike Jones
> Cc: jose@ietf.org
> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09= .txt
>
> Mike:
>
> Like Jim, I cannot support this statement: AES GCM MUST NOT be used wh= en using the JWE JSON Serialization for multiple recipients
>
> All recipients ought to be performing decryption and integrity checkin= g with the same GCM key. =A0The manner in which they obtain that key may be= different (key transport: decrypt the GCM key with the recipient's pri= vate key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM key with the KEK, pre-shared KEK: unwrappi= ng the GCM key with the already known KEK, etc).
>
> Russ
>
>
> On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:
>
>> Mike,
>>
>> AES GCM MUST NOT be used when using the JWE JSON Serialization for=
>> =A0multiple recipients, since this would result in the same
>> =A0Initialization Vector and Plaintext values being used for multi= ple
>> =A0GCM encryptions.
>>
>> I doubt your co-authors would agree with this.
>> I doubt the working group with agree with this.
>> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate w= ould
>> crucify me if I allowed this to stand in the document..
>>
>> Jim
>>
>>
>>
>>> -----Original Message-----
>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
>>> Of internet-drafts@ietf.org
>>> Sent: Tuesday, April 23, 2013 5:29 PM
>>> To: i-d-announce@ietf.org
>>> Cc: jose@ie= tf.org
>>> Subject: [jose] I-D Action:
>>> draft-ietf-jose-json-web-encryption-09.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Javascript Object Signing and=
>>> Encryption Working Group of the IETF.
>>>
>>> =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE)<= br> >>> =A0 =A0 Author(s) =A0 =A0 =A0 : Michael B. Jones
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla<= br> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joe Hildebrand=
>>> =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-enc= ryption-09.txt
>>> =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 54
>>> =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>>>
>>> Abstract:
>>> =A0JSON Web Encryption (JWE) is a means of representing encryp= ted
>>> =A0content using JavaScript Object Notation (JSON) data struct= ures.
>>> =A0Cryptographic algorithms and identifiers for use with this<= br> >>> =A0specification are described in the separate JSON Web Algori= thms (JWA)
>>> =A0specification. =A0Related digital signature and MAC capabil= ities are
>>> =A0described in the separate JSON Web Signature (JWS) specific= ation.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-=
>>> 09
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--089e0149d1b6b043be04db3772b4-- From rlb@ipv.sx Thu Apr 25 16:06:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD721F9722 for ; Thu, 25 Apr 2013 16:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.159 X-Spam-Level: * X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz+LZg3siaGE for ; Thu, 25 Apr 2013 16:06:15 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF2921F9726 for ; Thu, 25 Apr 2013 16:06:13 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id tb18so3005580obb.28 for ; Thu, 25 Apr 2013 16:06:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cYPX+/KKse8X6H7IHyijlB8lc4h4CFEfh8zEaQuUBwM=; b=Rs36T4Yk5tjLSU8q5nURF5a7P4ZTBQoOAogUwNrGKwaDqnKNVnMxmap60qOJVj+PxT wF7wRrQzb0BXOcgRLF8KnvSTheRerb02jkTB8M8QuaqItwnp2dEyRGwoT7nbDuWwYv/Z LyWXcIdCBdWg434tSqq94q17Wj2PBtL+nM8SnwZEDpAlQJLkVmlyOVRa5B3mW7fhsiMY NTrdRL7HAyOOG82RCR870hUXAEFXecv9P2CwQNc8DldiFGvV47CxOZDQiKa3QmQI0QVf CxslBXiTEYZnGox2Wip4QXQVHTBHcBfeMV3M/2hDAqVJhm5B7AxcJ5eivMXZskoWvjdT iCrA== MIME-Version: 1.0 X-Received: by 10.60.121.104 with SMTP id lj8mr17635998oeb.83.1366931172160; Thu, 25 Apr 2013 16:06:12 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 16:06:12 -0700 (PDT) X-Originating-IP: [76.21.182.222] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C05E5@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C05E5@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 19:06:12 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b3a9734f355b204db377697 X-Gm-Message-State: ALoCoQnm3ZS0//LitO3mW3Kr0I6SIG7tognhFRRJZHregBjQC1XCLVqFe7dMKCJODKJqIvjLXdtc Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:06:16 -0000 --047d7b3a9734f355b204db377697 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, if the application is willing to accept the horrendous inefficiency of double-base64 encoding. Again, arbitrary and capricious restriction in the name of a non-existent security benefit. --Richard On Thu, Apr 25, 2013 at 6:46 PM, Mike Jones wr= ote: > Applications are now free to add their own AAD information to the JWE > header, now that not-understood header parameters must be ignored.**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, April 25, 2013 2:51 PM > *To:* John Bradley > *Cc:* Mike Jones; Jim Schaad; jose@ietf.org > > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > ** ** > > On Thu, Apr 25, 2013 at 4:40 PM, John Bradley wrote:*= * > ** > > For multiple recipients using GCM with a single CEK and IV we can > logically have 0 AAD segments or 1 AAD segment.**** > > ** ** > > That is just the reality of the situation. **** > > ** ** > > I would also note that taking the JOSE overhead out of the AAD segment > frees it up for the application to use.**** > > ** ** > > **** > > One possible solution is to the GCM issue is to have 1 AAD segment > containing the envelope information for all recipients.**** > > I understand for people wanting 0 AAD segments that will not be there > first choice.**** > > ** ** > > The downside of this is that you can't incrementally add recipients, they > all need to be known upfront to include the info in the AAD.**** > > ** ** > > What I don't know is if there is really any compelling use-case for > incremental addition of recipients without re-encrypting (changing the IV > atleast)**** > > ** ** > > The XMPP use case is precisely this. When the sender encrypts the > message, it doesn't know the set of public keys that it's sending it to.*= * > ** > > ** ** > > So the only other possible alternative is taking the per-recipient info > out of the integrity check. But if we're going to do that, we might as > well go all the way and get rid of the integrity check altogether. > Applications that want to integrity protect information can put it in the > AAD segment on their own. **** > > ** ** > > --Richard**** > > ** ** > > ** ** > > **** > > ** ** > > John B.**** > > . **** > > ** ** > > On 2013-04-25, at 4:14 PM, Mike Jones wrote= : > **** > > > > **** > > Hi Richard,**** > > **** > > Actually, there are four goals in play:**** > > **** > > 1. GCM**** > > 2. Efficient encoding for multiple recipients**** > > 3. Header integrity protection**** > > 4. Independent protection of each recipient=92s headers**** > > **** > > Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. > (Credit goes to John Bradley for this solution.)**** > > **** > > -- Mike**** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Thursday, April 25, 2013 11:14 AM > *To:* Mike Jones > *Cc:* Jim Schaad; jose@ietf.org > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > **** > > Mike, **** > > **** > > Your facts are right, but your conclusions are wrong.**** > > **** > > We have three mutually incompatible goals here:**** > > 1. GCM**** > > 2. Efficient encoding for multiple recipients**** > > 3. Header integrity**** > > **** > > We can have any two of these, but not all three. If we try to do all > three (JWE-08), then we end up with the vulnerability identified in the > CFRG thread. So we need to choose which one to get rid of.**** > > **** > > Getting rid of GCM is clearly not the right answer, as evidenced by the > reaction in this thread. There are clear, concrete use reasons to suppor= t > multiple recipients, but not for header integrity. And header integrity > can be "polyfilled" with an optional feature, for those who are willing t= o > break the multiple recipient case. Clearly, header integrity is the > weakest link here.**** > > **** > > JWE-09 is the reductio ad absurdum of header integrity. Let's do the > logical thing and stop the absurdity.**** > > **** > > --Richard**** > > **** > > **** > > **** > > On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones > wrote:**** > > Jim - I am surprised that you would say that my co-authors Eric Rescorla > or Joe Hildebrand or the working group would advocate using AES GCM in a > way that would result in severe security vulnerabilities - in particular, > allowing attackers to obtain the XOR of the messages to multiple recipien= ts > encrypted using GCM - a vulnerability identified by the CFRG. > > Not stating this in the document would seem to me to be highly > irresponsible, given the brittleness of GCM in this regard, as identified > by the CRFG. As I said to Richard Barnes over dinner last night, while > unpleasant, and possibly surprising to those who aren't familiar to how G= CM > actually works, as an editor, I viewed including the statement that "AES > GCM MUST NOT be used when using the JWE JSON Serialization for multiple > recipients, since this would result in the same Initialization Vector and > Plaintext values being used for multiple GCM encryptions" as necessary, a= nd > "truth in advertising". > > -- Mike**** > > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.tx= t > > Mike, > > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. > > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can predict > that the AD and IESG along with the security directorate would crucify me > if I allowed this to stand in the document.. > > Jim > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: i-d-announce@ietf.org > > Cc: jose@ietf.org > > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms (JWA= ) > > specification. Related digital signature and MAC capabilities are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-= 0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > ** ** > --047d7b3a9734f355b204db377697 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes, if the application is willing to accept the horrendou= s inefficiency of double-base64 encoding.

Again,= =A0arbitrary an= d capricious restriction in the name of a non-existent security benefit.

--Richard
<= br>
On Thu, Apr 25, 2013 at 6:46 PM, Mike Jon= es <Michael.Jones@microsoft.com> wrote:

Applications are now free= to add their own AAD information to the JWE header, now that not-understoo= d header parameters must be ignored.

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2013 2:51 PM
To: John Bradley
Cc: Mike Jones; Jim Schaad; jose@ietf.org


Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

=A0

On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

For multiple recipients using GCM with a single CEK = and IV we can logically have 0 AAD segments or 1 AAD segment.=

=A0

That is just the reality of the situation.=A0=

=A0

I would also note that taking the JOSE overhead out = of the AAD segment frees it up for the application to use.

=A0

=A0

One possible solution is to the GCM issue is to have= 1 AAD segment containing the envelope information for all recipients.

I understand for people wanting 0 AAD segments that = will not be there first choice.

=A0

The downside of this is that you can't increment= ally add recipients, they all need to be known upfront to include the info = in the AAD.

=A0

What I don't know is if there is really any comp= elling use-case for incremental addition of recipients without re-encryptin= g (changing the IV atleast)

=A0

The XMPP use case is precisely this. =A0When the sen= der encrypts the message, it doesn't know the set of public keys that i= t's sending it to.

=A0

So the only other possible alternative is taking the= per-recipient info out of the integrity check. =A0But if we're going t= o do that, we might as well go all the way and get rid of the integrity che= ck altogether. =A0 Applications that want to integrity protect information can put it in the AAD segment on their ow= n.=A0

=A0

--Richard

=A0

=A0

=A0

=A0

John B.

=A0. =A0

=A0

On 2013-04-25, at 4:14 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:



Hi Richard,=

=A0<= /p>

Actually, there are four = goals in play:

=A0<= /p>

1.=A0 GCM

2.=A0 Efficient encoding = for multiple recipients

3.=A0 Header integrity pr= otection

4.=A0 Independent protect= ion of each recipient=92s headers

=A0<= /p>

Per my response to Russ, = by giving up 4, we can achieve 1, 2, and 3.=A0 (Credit goes to John Bradley= for this solution.)

=A0<= /p>

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

=A0<= /p>

From:=A0Richar= d Barnes [mailto:rlb@ipv.sx= ]=A0
Sent:=A0Thursday, April 25, 2013 11:14 AM
To:=A0Mike Jones
Cc:=A0Jim Schaad; jose@ietf.org
Subject:=A0Re: [jose] I-D Action: draft-ietf-jose-json-web-encryptio= n-09.txt

=A0

Mike,=A0

=A0

Your facts are right, but your conclusions are wrong= .

=A0

We have three mutually incompatible goals here:

1. GCM

2. Efficient encoding for multiple recipients=

3. Header integrity

=A0

We can have any two of these, but not all three. =A0= If we try to do all three (JWE-08), then we end up with the vulnerability i= dentified in the CFRG thread. =A0So we need to choose which one to get rid = of.

=A0

Getting rid of GCM is clearly not the right answer, = as evidenced by the reaction in this thread. =A0There are clear, concrete u= se reasons to support multiple recipients, but not for header integrity. = =A0And header integrity can be "polyfilled" with an optional feature, for those who are willing to break the multiple = recipient case. =A0Clearly, header integrity is the weakest link here.

=A0

JWE-09 is the reductio ad absurdum of header integri= ty. =A0Let's do the logical thing and stop the absurdity.=

=A0

--Richard

=A0

=A0

=A0

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:<= /u>

Jim - I am surprised that you would say that my co-a= uthors Eric Rescorla or Joe Hildebrand or the working group would advocate = using AES GCM in a way that would result in severe security vulnerabilities= - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using G= CM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = =A0As I said to Richard Barnes over dinner last night, while unpleasant, an= d possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed incl= uding the statement that "AES GCM MUST NOT be used when using the JWE = JSON Serialization for multiple recipients, since this would result in the = same Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and &qu= ot;truth in advertising".

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


-----Original Message-----
From:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc:=A0jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
=A0 =A0multiple recipients, since this would result in the same
=A0 =A0Initialization Vector and Plaintext values being used for multiple =A0 =A0GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document..

Jim



> -----Original Message-----
> From:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org] On Behalf
> Of=A0internet-drafts@ietf.org
> Sent: Tuesday, April 23, 2013 5:29 PM
> To:=A0i-d-announce@ietf.org
> Cc:=A0jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt=
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> =A0This draft is a work item of the Javascript Object Signing and
> Encryption Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE)
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Michael B. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joe Hildebrand
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-encrypt= ion-09.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 54
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>
> Abstract:
> =A0 =A0JSON Web Encryption (JWE) is a means of representing encrypted<= br> > =A0 =A0content using JavaScript Object Notation (JSON) data structures= .
> =A0 =A0Cryptographic algorithms and identifiers for use with this
> =A0 =A0specification are described in the separate JSON Web Algorithms= (JWA)
> =A0 =A0specification. =A0Related digital signature and MAC capabilitie= s are
> =A0 =A0described in the separate JSON Web Signature (JWS) specificatio= n.
>
>
> The IETF datatracker status page for this draft is:
>=A0https://datatra= cker.ietf.org/doc/draft-ietf-jose-json-web-encryption
>
> There's also a htmlized version available at:
>=A0http://tools.ietf.= org/html/draft-ietf-jose-json-web-encryption-09
>
> A diff from the previous version is available at:
>=A0http://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
>=A0ftp://ftp.ietf.org/internet-drafts/ >
> _______________________________________________
> jose mailing list
>=A0jose@ietf.org
>=A0https://www.ietf.org/mailman/listinfo/jos= e

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

=A0

_____________________________________= __________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0


--047d7b3a9734f355b204db377697-- From ve7jtb@ve7jtb.com Thu Apr 25 16:09:11 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DB021F91A3 for ; Thu, 25 Apr 2013 16:09:11 -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=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13x6EsGpTH8D for ; Thu, 25 Apr 2013 16:09:10 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9521F96AB for ; Thu, 25 Apr 2013 16:09:09 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id r13so3090471iar.16 for ; Thu, 25 Apr 2013 16:09:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=WsyecNnr8i8/8+cgCG66DoNmG0eUZoS9pRmhJIw5tVY=; b=fRPRIDZZKG7oWD628CQ/DhU+jeiKXzafRlQ2aPS0xIl2Cz+DCpP2FosShEib1G0okD /gPQ84SVTwd58tNAZRRRUAPzS/5AKMDvMx9zqpiSKRpjtdwmncBPP2COpVgDqGtzDbGH fUOP5upxyUPzmiF3B17WPUNPJ9tDlXjX0Kvd+x8ei+DP+y4oqYC1PclnlGPwPl9GroIm nkJU/b2+ISenAzJ1X7VCv/DVk3Lz3c3NnuSZ1J/9+QibnaYTrJtwU87NQd6dkR176AVw fqjnoKJ4a0z1i/DKHhxZD5J7yu03JeZWE3H84WpzQU+yX/3HrUjGI7FN2UGTz5VkMvIa XaMQ== X-Received: by 10.50.153.232 with SMTP id vj8mr358274igb.2.1366931342620; Thu, 25 Apr 2013 16:09:02 -0700 (PDT) Received: from [192.168.1.39] (190-20-37-138.baf.movistar.cl. [190.20.37.138]) by mx.google.com with ESMTPSA id 9sm126862igy.7.2013.04.25.16.08.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 16:09:01 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_17895419-E7E5-4D32-A088-9B0BE20BE54A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <74C39AC5-0C6B-4DC1-A273-3996D97D90A9@vigilsec.com> Date: Thu, 25 Apr 2013 20:08:25 -0300 Message-Id: <53360D8F-6AB2-4F8F-A73D-CDDD5FE2E00E@ve7jtb.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <74C39AC5-0C6B-4DC1-A273-3996D97D90A9@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQleaPdi+PjWvEIBP+X9MYALvIQ0JAYUc2f76pI24XOwnTm/GX8hHSl04kRuEYVCwHHg5rRZ Cc: Mike Jones , jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:09:11 -0000 --Apple-Mail=_17895419-E7E5-4D32-A088-9B0BE20BE54A Content-Type: multipart/alternative; boundary="Apple-Mail=_0AECE84C-7A98-45BA-9AB4-2DD93DA03181" --Apple-Mail=_0AECE84C-7A98-45BA-9AB4-2DD93DA03181 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think there were two issues identified. 1. Encrypting multiple plain texts with the same key and IV is = defiantly a bad thing., and it is relatively easy to see why. 2. Encrypting the same plaintext multiple times with the same IV and = CMK but changing the AAD. The problem with this is slightly less = clear. There will be multiple tags generated one for each different = AAD. To produce the tag you encrypt the final hash value with the block = is xored with the IV block encrypted with the CMK. =20 I don't personally know of an attack that can exploit having multiple = tags xored with the same value. My take on it from Mc Grew's comment = on the list was it is probably not a good thing. I think Mike and I = both took from the conversation that producing multiple tag values that = are xord with the same encrypted value is not something that was = recommended. If I have that wrong now would be a good time to say that the practice = is OK. =20 Regards John B. On 2013-04-25, at 6:40 PM, Russ Housley wrote: > Mike: >=20 > The same message encrypted with different GCM keys is a problem, but = that is not what ought to be going on here. I tried to explain that in = my previous message. The same GCM key is delivered to multiple = recipients, perhaps using different key management techniques. Since = the originator and all of the recipients use exactly the same key = stream, this XOR concern does not arise. >=20 > Russ >=20 >=20 > On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones = wrote: > Jim - I am surprised that you would say that my co-authors Eric = Rescorla or Joe Hildebrand or the working group would advocate using AES = GCM in a way that would result in severe security vulnerabilities - in = particular, allowing attackers to obtain the XOR of the messages to = multiple recipients encrypted using GCM - a vulnerability identified by = the CFRG. >=20 > Not stating this in the document would seem to me to be highly = irresponsible, given the brittleness of GCM in this regard, as = identified by the CRFG. As I said to Richard Barnes over dinner last = night, while unpleasant, and possibly surprising to those who aren't = familiar to how GCM actually works, as an editor, I viewed including the = statement that "AES GCM MUST NOT be used when using the JWE JSON = Serialization for multiple recipients, since this would result in the = same Initialization Vector and Plaintext values being used for multiple = GCM encryptions" as necessary, and "truth in advertising". >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Jim Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt >=20 > Mike, >=20 > AES GCM MUST NOT be used when using the JWE JSON Serialization for > multiple recipients, since this would result in the same > Initialization Vector and Plaintext values being used for multiple > GCM encryptions. >=20 > I doubt your co-authors would agree with this. > I doubt the working group with agree with this. > I know that at least one co-chair does not agree with this I can = predict that the AD and IESG along with the security directorate would = crucify me if I allowed this to stand in the document.. >=20 > Jim >=20 >=20 >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Tuesday, April 23, 2013 5:29 PM > > To: i-d-announce@ietf.org > > Cc: jose@ietf.org > > Subject: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Javascript Object Signing and > > Encryption Working Group of the IETF. > > > > Title : JSON Web Encryption (JWE) > > Author(s) : Michael B. Jones > > Eric Rescorla > > Joe Hildebrand > > Filename : draft-ietf-jose-json-web-encryption-09.txt > > Pages : 54 > > Date : 2013-04-23 > > > > Abstract: > > JSON Web Encryption (JWE) is a means of representing encrypted > > content using JavaScript Object Notation (JSON) data structures. > > Cryptographic algorithms and identifiers for use with this > > specification are described in the separate JSON Web Algorithms = (JWA) > > specification. Related digital signature and MAC capabilities = are > > described in the separate JSON Web Signature (JWS) specification. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > > > A diff from the previous version is available at: > > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > > 9 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0AECE84C-7A98-45BA-9AB4-2DD93DA03181 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think there were two issues identified.

1. =  Encrypting multiple plain texts with the same key and IV is = defiantly a bad thing., and it is relatively easy to see = why.
2.  Encrypting the same plaintext multiple times = with the same IV and CMK but changing the AAD.   The problem with = this is slightly less clear.   There will be multiple tags = generated one for each different AAD.  To produce the tag you = encrypt the final hash value with the block is xored with the IV block = encrypted with the CMK.  

 I don't = personally know of an attack that can exploit having multiple tags xored = with the same value.   My take on it from Mc Grew's comment on the = list was it is probably not a good thing.   I think Mike and I both = took from the conversation that producing multiple tag values that are = xord with the same encrypted value is not something that was = recommended.

If I have that wrong now would be = a good time to say that the practice is OK. =   

Regards
John = B.



On = 2013-04-25, at 6:40 PM, Russ Housley <housley@vigilsec.com> = wrote:

Mike:

The = same message encrypted with different GCM keys is a problem, but that is = not what ought to be going on here.  I tried to explain that in my = previous message.  The same GCM key is delivered to multiple = recipients, perhaps using different key management techniques. =  Since the originator and all of the recipients use exactly the = same key stream, this XOR concern does not arise.

Russ


On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Jim - I am surprised = that you would say that my co-authors Eric Rescorla or Joe Hildebrand or = the working group would advocate using AES GCM in a way that would = result in severe security vulnerabilities - in particular, allowing = attackers to obtain the XOR of the messages to multiple recipients = encrypted using GCM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly = irresponsible, given the brittleness of GCM in this regard, as = identified by the CRFG.  As I said to Richard Barnes over dinner = last night, while unpleasant, and possibly surprising to those who = aren't familiar to how GCM actually works, as an editor, I viewed = including the statement that "AES GCM MUST NOT be used when using the = JWE JSON Serialization for multiple recipients, since this would result = in the same Initialization Vector and Plaintext values being used for = multiple GCM encryptions" as necessary, and "truth in advertising".

                    =             -- Mike

-----Original Message-----
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On = Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt

Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the = same
   Initialization Vector and Plaintext values being used for = multiple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict = that the AD and IESG along with the security directorate would crucify = me if I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On = Behalf
> Of internet-drafts@ietf.org
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: = draft-ietf-jose-json-web-encryption-09.txt
>
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
directories.
>  This draft is a work item of the Javascript Object Signing = and
> Encryption Working Group of the IETF.
>
>       Title           : = JSON Web Encryption (JWE)
>       Author(s)       : Michael B. = Jones
>                   =         Eric Rescorla
>                   =         Joe Hildebrand
>       Filename        : = draft-ietf-jose-json-web-encryption-09.txt
>       Pages           : = 54
>       Date           =  : 2013-04-23
>
> Abstract:
>    JSON Web Encryption (JWE) is a means of representing = encrypted
>    content using JavaScript Object Notation (JSON) data = structures.
>    Cryptographic algorithms and identifiers for use with = this
>    specification are described in the separate JSON Web = Algorithms (JWA)
>    specification.  Related digital signature and MAC = capabilities are
>    described in the separate JSON Web Signature (JWS) = specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-we= b-encryption
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encr= yption-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-= web-encryption-0
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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

_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose
________________________________________= _______
jose mailing list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_0AECE84C-7A98-45BA-9AB4-2DD93DA03181-- --Apple-Mail=_17895419-E7E5-4D32-A088-9B0BE20BE54A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MjMwODI2WjAjBgkqhkiG9w0BCQQxFgQUdhyU76Cq WIN0uFXZp7E8kI9auS8wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAMgna9As6iScN243ejf3BdeKUE5y0JCvcySWTWX3x UCqHNq2xkjwFcWiFhhqQiqXoB3q+wp92ksyB5UlncWTr/9+wSB+H1PXbFb6eXb13hH2v0kzl5Uzz hXFAms7qMHUtxsqEGGWFeuiCWElGRfrmr1Az/XiRRtCWjFQsXppJldWsegUrJk7BkrD9wX8mmL/H xaCqUCMSfo2sS8NjKCsBnB7ASKMY/odDXDWtaNE41rpg0Eg+nKzhEEDwOfCYEoJHjdQARN4Jmbbu eHJg5dQ7pR7ho78rFxsLskkwSYVmagFxtFRJYjD2g9oHuOGU8X4KhOjRTfYc+EgZoMQyh5VFJwAA AAAAAA== --Apple-Mail=_17895419-E7E5-4D32-A088-9B0BE20BE54A-- From rlb@ipv.sx Thu Apr 25 16:11:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF921F96AB for ; Thu, 25 Apr 2013 16:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRHcKGEH2HP0 for ; Thu, 25 Apr 2013 16:11:37 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 249EC21F926E for ; Thu, 25 Apr 2013 16:11:37 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id tb18so3060508obb.14 for ; Thu, 25 Apr 2013 16:11:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NSfXQsfz5c+FEcC2YNwZgCmRDfYo14wH29e7mcMw2bc=; b=B3CxPlnb+//hrLOgOhAJQnQDRgbJ+/9Nt+x7M3ha22d7OH9lelD6fm80I6OG+1lOpT VtRPnfpt21l01QcLxH5r7ETWb37UArFz6ayjAIt2mBxm3yWXodJKQLOAkDBNMag8mwOW 8+V/WiDXOzaqj8lpgEMy91Hwf2LYCajLWX0nvmqIEOvhSvoPVn2PoXlCfiMmZCNkV1Pi rTHBipCtDDkEO0gLXMdKHphTv7l3LF5gj9jF4cDXXTrCn4OJShXJCV3xe7HdsNu+Ijlw AIFe+oaa6uANAtH9k9qZsXUCPebHAnG06avr5TVyNGM3wF6/NJjAtIhNk1dxZI0ktbFG 11qA== MIME-Version: 1.0 X-Received: by 10.60.121.104 with SMTP id lj8mr17644439oeb.83.1366931496727; Thu, 25 Apr 2013 16:11:36 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 16:11:36 -0700 (PDT) X-Originating-IP: [76.21.182.222] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C07DF@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C07DF@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 25 Apr 2013 19:11:36 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b3a97344b7d2f04db378a9f X-Gm-Message-State: ALoCoQl+yRANaqbv0z3D3DTZLtwifHNljvWLZwCPPKFLpzdl//qGYyDFlYSpvFnjvuIq8o5ZE8D2 Cc: Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:11:38 -0000 --047d7b3a97344b7d2f04db378a9f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is not complicated. There are some algorithms that will REQUIRE the integrity option, and others that will not. We can clearly specify in JWA. The complication imposed by mandatory header integrity is far greater. --Richard On Thu, Apr 25, 2013 at 7:07 PM, Mike Jones wr= ote: > Options just complicate things, and give developers additional > opportunities to make the wrong choices.**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Thursday, April 25, 2013 4:05 PM > *To:* Mike Jones > *Cc:* Russ Housley; jose@ietf.org > > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > ** ** > > On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones > wrote:**** > > As background on the decision to integrity protect the headers =96 this > didn=92t come out of a vacuum. The JWT designers sought out Ben Laurie= =92s > advice in 2010 and he=92d suggested that the best thing would be to prote= ct > everything. Indeed, Ben restated exactly the same position in a CRFG > discussion on the topic earlier this month, writing =93Why even discuss > these? What is wrong with the answer "all parameters should be protected"= ? > =94.**** > > You should also note that I answered that question, and Ben backed off > significantly from his initial position. There were also several other > commenters on the CFRG thread, who did not see utility in mandatory heade= r > protection.**** > > **** > > Ben=92s not the only one who believes that it=92s appropriate to protect= the metadata. For instance, the abstract of RFC 6211 =93Cryptographic Mes= sage Syntax (CMS) Algorithm Identifier Protection Attribute=94 begins =93Th= e Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vu= lnerable to algorithm substitution attacks=94. Like RFC 6211 does for CMS,= some would also like to prevent those attacks for JOSE.**** > > I agree! There should be an *option* for integrity-protecting > parameters, in the limited cases where such protection is necessary. It = is > not necessary with PKCS#1 v1.5 signatures, since the signature algorithm > encodes an OID for the hash algorithm. It is not necessary for JWE. I > would be happy to discuss the shape of such an option at the interim next > week. **** > > ** ** > > --Richard**** > > ** ** > > **** > > **** > > Best > wishes,**** > > -- Mike**= * > * > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Thursday, April 25, 2013 2:46 PM > *To:* Russ Housley > *Cc:* Mike Jones; jose@ietf.org**** > > > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > **** > > On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley > wrote:**** > > Mike: > > If the header is protected with the AAD mechanism in GCM, then it must > cover exactly the same bits for all recipients. > > I do not see the need for JOSE header integrity. I have said this in the > past. I'm saying it again....**** > > **** > > +much_more_than_one**** > > **** > > **** > > **** > > > Russ**** > > > > On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > > > Hi Russ, > > > > I agree that enabling GCM to be safely used in the multiple recipients > case would be highly desirable. It is currently prohibited because if th= e > recipients share a common key and initialization vector (IV) but use > different AAD values, this results in the identified vulnerability. One > possible solution that continues integrity protecting the headers but > enables the safe use of GCM was identified off-list by John Bradley. > > > > That solution is to have each recipient always use the same key, IV, an= d > AAD values. This could be accomplished by including all the header value= s > in a single combined AAD value, rather than having the integrity protecti= on > for each recipient's headers be independent. > > > > This change could be done in a manner that doesn't affect the > computation for the single recipients case. Given the upcoming interim > JOSE meeting next week, and given the (understandable) strong negative > reaction to the unusability of GCM with the current multiple recipients > processing rules, I'll plan on quickly producing a draft -10 that changes > the processing rules in the manner described above, so that idea can be > concretely considered by the working group next week. > > > > Just so people are clear on the properties on the new processing rules = - > this would mean that the integrity computations for each recipients would > no longer be independent. The only downside of this (which could be an > upside in some ways) is that it would no longer be possible to add > recipients over time without performing a new encryption computation with= a > new CEK and IV. > > > > Cheers, > > -- Mike > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Thursday, April 25, 2013 10:31 AM > > To: Mike Jones > > Cc: jose@ietf.org > > Subject: Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt > > > > Mike: > > > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used whe= n > using the JWE JSON Serialization for multiple recipients > > > > All recipients ought to be performing decryption and integrity checking > with the same GCM key. The manner in which they obtain that key may be > different (key transport: decrypt the GCM key with the recipient's privat= e > key, key agreement: agreement of a pairwise KEK and then unwrapping the G= CM > key with the KEK, pre-shared KEK: unwrapping the GCM key with the already > known KEK, etc). > > > > Russ > > > > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > > > >> Mike, > >> > >> AES GCM MUST NOT be used when using the JWE JSON Serialization for > >> multiple recipients, since this would result in the same > >> Initialization Vector and Plaintext values being used for multiple > >> GCM encryptions. > >> > >> I doubt your co-authors would agree with this. > >> I doubt the working group with agree with this. > >> I know that at least one co-chair does not agree with this I can > >> predict that the AD and IESG along with the security directorate would > >> crucify me if I allowed this to stand in the document.. > >> > >> Jim > >> > >> > >> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>> Of internet-drafts@ietf.org > >>> Sent: Tuesday, April 23, 2013 5:29 PM > >>> To: i-d-announce@ietf.org > >>> Cc: jose@ietf.org > >>> Subject: [jose] I-D Action: > >>> draft-ietf-jose-json-web-encryption-09.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the Javascript Object Signing and > >>> Encryption Working Group of the IETF. > >>> > >>> Title : JSON Web Encryption (JWE) > >>> Author(s) : Michael B. Jones > >>> Eric Rescorla > >>> Joe Hildebrand > >>> Filename : draft-ietf-jose-json-web-encryption-09.txt > >>> Pages : 54 > >>> Date : 2013-04-23 > >>> > >>> Abstract: > >>> JSON Web Encryption (JWE) is a means of representing encrypted > >>> content using JavaScript Object Notation (JSON) data structures. > >>> Cryptographic algorithms and identifiers for use with this > >>> specification are described in the separate JSON Web Algorithms (JWA= ) > >>> specification. Related digital signature and MAC capabilities are > >>> described in the separate JSON Web Signature (JWS) specification. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryptio= n- > >>> 09 > >>> > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** > --047d7b3a97344b7d2f04db378a9f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
This is not complicated. =A0There are some algorithms that= will REQUIRE the integrity option, and others that will not. =A0We can cle= arly specify in JWA.

The complication imposed by m= andatory header integrity is far greater.

--Richard
<= br>
On Thu, Apr 25, 2013 at 7:07 PM, Mike Jon= es <Michael.Jones@microsoft.com> wrote:

Options just complicate t= hings, and give developers additional opportunities to make the wrong choic= es.

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 4:05 PM
To: Mike Jones
Cc: Russ Housley; jose@ietf.org


Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

=A0

On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

As background on the decision to integrity= protect the headers =96 this didn=92t come out of a vacuum.=A0 The JWT des= igners sought out Ben Laurie=92s advice in 2010 and he=92d suggested that t= he best thing would be to protect everything. =A0Indeed, Ben restated exactly the same position in a CRFG discussion on = the topic earlier this month, writing =93Why even discuss these? Wha= t is wrong with the answer "all parameters should be protected"?<= span style=3D"color:#1f497d">=94.

You should also note that I answered that question, = and Ben backed off significantly from his initial position. =A0There were a= lso several other commenters on the CFRG thread, who did not see utility in= mandatory header protection.

=A0

Ben=92s not the only one who believes that it=92s appropriat=
e to protect the metadata.=A0 For instance, the abstract of RFC 6211 =93Cry=
ptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute=
=94 begins =93The Cryptographic Message Syntax (CM=
S), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution=
 attacks=94.=A0 Like RFC 6211 does for CMS, some would als=
o like to prevent those attacks for JOSE.

I agree! There should be an *option* for integrity-p= rotecting parameters, in the limited cases where such protection is necessa= ry. =A0It is not necessary with PKCS#1 v1.5 signatures, since the signature= algorithm encodes an OID for the hash algorithm. =A0It is not necessary for JWE. =A0I would be happy to discuss = the shape of such an option at the interim next week.=A0

=A0

--Richard

=A0

=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Be= st wishes,

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

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 2:46 PM
To: Russ Housley
Cc: Mike Jones; j= ose@ietf.org


Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

=A0

On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <housley@vigilsec.co= m> wrote:

Mike:

If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients.

I do not see the need for JOSE header integrity. =A0I have said this in the= past. =A0I'm saying it again....

=A0

+much_more_than_one

=A0

=A0

=A0


Russ



On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:

> Hi Russ,
>
> I agree that enabling GCM to be safely used in the multiple recipients= case would be highly desirable. =A0It is currently prohibited because if t= he recipients share a common key and initialization vector (IV) but use dif= ferent AAD values, this results in the identified vulnerability. =A0One possible solution that continues integrit= y protecting the headers but enables the safe use of GCM was identified off= -list by John Bradley.
>
> That solution is to have each recipient always use the same key, IV, a= nd AAD values. =A0This could be accomplished by including all the header va= lues in a single combined AAD value, rather than having the integrity prote= ction for each recipient's headers be independent.
>
> This change could be done in a manner that doesn't affect the comp= utation for the single recipients case. =A0Given the upcoming interim JOSE = meeting next week, and given the (understandable) strong negative reaction = to the unusability of GCM with the current multiple recipients processing rules, I'll plan on quickly producing a= draft -10 that changes the processing rules in the manner described above,= so that idea can be concretely considered by the working group next week.<= br> >
> Just so people are clear on the properties on the new processing rules= - this would mean that the integrity computations for each recipients woul= d no longer be independent. =A0The only downside of this (which could be an= upside in some ways) is that it would no longer be possible to add recipients over time without performing a new= encryption computation with a new CEK and IV.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cheers, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Thursday, April 25, 2013 10:31 AM
> To: Mike Jones
> Cc: jose@ietf.org
> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09= .txt
>
> Mike:
>
> Like Jim, I cannot support this statement: AES GCM MUST NOT be used wh= en using the JWE JSON Serialization for multiple recipients
>
> All recipients ought to be performing decryption and integrity checkin= g with the same GCM key. =A0The manner in which they obtain that key may be= different (key transport: decrypt the GCM key with the recipient's pri= vate key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM key with the KEK, pre-shared KEK: unwrappi= ng the GCM key with the already known KEK, etc).
>
> Russ
>
>
> On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:
>
>> Mike,
>>
>> AES GCM MUST NOT be used when using the JWE JSON Serialization for=
>> =A0multiple recipients, since this would result in the same
>> =A0Initialization Vector and Plaintext values being used for multi= ple
>> =A0GCM encryptions.
>>
>> I doubt your co-authors would agree with this.
>> I doubt the working group with agree with this.
>> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate w= ould
>> crucify me if I allowed this to stand in the document..
>>
>> Jim
>>
>>
>>
>>> -----Original Message-----
>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
>>> Of internet-drafts@ietf.org
>>> Sent: Tuesday, April 23, 2013 5:29 PM
>>> To: i-d-announce@ietf.org
>>> Cc: jose@ie= tf.org
>>> Subject: [jose] I-D Action:
>>> draft-ietf-jose-json-web-encryption-09.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Javascript Object Signing and=
>>> Encryption Working Group of the IETF.
>>>
>>> =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : JSON Web Encryption (JWE)<= br> >>> =A0 =A0 Author(s) =A0 =A0 =A0 : Michael B. Jones
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Rescorla<= br> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joe Hildebrand=
>>> =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-jose-json-web-enc= ryption-09.txt
>>> =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 54
>>> =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-23
>>>
>>> Abstract:
>>> =A0JSON Web Encryption (JWE) is a means of representing encryp= ted
>>> =A0content using JavaScript Object Notation (JSON) data struct= ures.
>>> =A0Cryptographic algorithms and identifiers for use with this<= br> >>> =A0specification are described in the separate JSON Web Algori= thms (JWA)
>>> =A0specification. =A0Related digital signature and MAC capabil= ities are
>>> =A0described in the separate JSON Web Signature (JWS) specific= ation.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-=
>>> 09
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0


--047d7b3a97344b7d2f04db378a9f-- From ve7jtb@ve7jtb.com Thu Apr 25 16:13:37 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7687621F96AB for ; Thu, 25 Apr 2013 16:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqXLEON207-7 for ; Thu, 25 Apr 2013 16:13:36 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1521F8808 for ; Thu, 25 Apr 2013 16:13:36 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so4362958iej.30 for ; Thu, 25 Apr 2013 16:13:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=YEeXDjvlOZmKVpEVt1vGSbuso0awVVDsOZH1KHfJ6y0=; b=RmbuX/IHZb8338axHO5Mc2OZFBuvgA+6E+gq7sSZeLQt0zk9RSSR24O8n0aVI4wnju XBBOLT2+f2UK0sSG8sFDGcYR5rcBqW2Yq55Gq79ZRsERI3vf1hFactV05zoBjdkDbvYC 83j7VfI6Flnd3R7zRR9zCrFM5lZrunUEVEKjFABpGfKG6rJo4xwLjv2B/q30bCHVNf4k KGek16A5xHwUQcMxo2pjDSyNPmOGPQTSeZSWxIDZevX+tnNmLCGvmatAmCKi/O9/82e2 d5w5aq0aSHvytdo5IOHYwqQxxiaJ+Da3Ba/BtKJ19bCNNk/SYSISAVNbjNtKPMmLW780 ePoA== X-Received: by 10.50.129.69 with SMTP id nu5mr253805igb.106.1366931615831; Thu, 25 Apr 2013 16:13:35 -0700 (PDT) Received: from [192.168.1.39] (190-20-37-138.baf.movistar.cl. [190.20.37.138]) by mx.google.com with ESMTPSA id xc3sm115919igb.10.2013.04.25.16.13.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 16:13:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_440B6DA6-A608-4CF2-9656-AE9511D827B4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> Date: Thu, 25 Apr 2013 20:13:23 -0300 Message-Id: <18BB8C27-5373-40A3-B1F6-F21F66B5BF75@ve7jtb.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnjixwtlCMahlVDxvUvSwqvowO6hLhol92Kz/eV2T5JFDdEEkp0TG93zQfqqM2qlNBvw4rA Cc: Richard Barnes , Mike Jones , Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:13:37 -0000 --Apple-Mail=_440B6DA6-A608-4CF2-9656-AE9511D827B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree with Matt. I don't think there is anything in the XMPP use = case that would break if the envelope is integrity protected. =20 I think there is only a single envelope anyway as I understand it. =20 John B. On 2013-04-25, at 7:02 PM, Matt Miller wrote: >=20 > On Apr 25, 2013, at 3:56 PM, Richard Barnes > wrote: >=20 >> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones = wrote: >>=20 >>> Hi Russ, >>>=20 >>> I agree that enabling GCM to be safely used in the multiple = recipients >>> case would be highly desirable. It is currently prohibited because = if the >>> recipients share a common key and initialization vector (IV) but use >>> different AAD values, this results in the identified vulnerability. = One >>> possible solution that continues integrity protecting the headers = but >>> enables the safe use of GCM was identified off-list by John Bradley. >>>=20 >>> That solution is to have each recipient always use the same key, IV, = and >>> AAD values. This could be accomplished by including all the header = values >>> in a single combined AAD value, rather than having the integrity = protection >>> for each recipient's headers be independent. >>>=20 >>> This change could be done in a manner that doesn't affect the = computation >>> for the single recipients case. Given the upcoming interim JOSE = meeting >>> next week, and given the (understandable) strong negative reaction = to the >>> unusability of GCM with the current multiple recipients processing = rules, >>> I'll plan on quickly producing a draft -10 that changes the = processing >>> rules in the manner described above, so that idea can be concretely >>> considered by the working group next week. >>>=20 >>> Just so people are clear on the properties on the new processing = rules - >>> this would mean that the integrity computations for each recipients = would >>> no longer be independent. The only downside of this (which could be = an >>> upside in some ways) is that it would no longer be possible to add >>> recipients over time without performing a new encryption computation = with a >>> new CEK and IV. >>>=20 >>=20 >> As I said to John, that is not an acceptable solution because it = breaks the >> XMPP use case. The minimum sensible change is to remove the = per-recipient >> info from the integrity check. >>=20 >=20 > It is not clear to me how John's suggestion utterly breaks the XMPP = use case, unless you have this alternate-reality version of XMPP-E2E = you've not yet told me about (-: >=20 > The current XMPP document already separates per-recipient info from = the actual protected content. >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_440B6DA6-A608-4CF2-9656-AE9511D827B4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MjMxMzI0WjAjBgkqhkiG9w0BCQQxFgQUm6xUcK5G QuvAb1kYdDfj2Jki+XgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAlnFFMRPS9DtM4OjeIGhsD4MLfTmkOIUQL9nsjNp8 L7Jy4Wr/xjCJTMs/O+baA+DnBJKy3bx8w0RLGsJsXOdMEuxDPhTaVy/mDeBul7XqEG2WeoTZF6SE uQ8ZzInpcHxtabbNs6An/ObJN+iTyFawH66TNEevxfCrmmFhyqJGM00H9YRtLMB2LIYIhPB4AXdV yPBbVMLXmtYpbipBGcj4B0+J5IstZ1KykaoT0NUGHySwX6nXbPnYR4rzVCPSiXH9RR+y3pOEB1Um A4mryuP1MVIBFDMrpuUunlhaWotiQ0sbzqmvAI1Mtr6yCM4GWT6YX9xWBrYHrBKGWdPEe2UW3gAA AAAAAA== --Apple-Mail=_440B6DA6-A608-4CF2-9656-AE9511D827B4-- From rlb@ipv.sx Thu Apr 25 16:16:40 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A021F972B for ; Thu, 25 Apr 2013 16:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=2.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rFe1pZsbJpK for ; Thu, 25 Apr 2013 16:16:38 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id BFB9521F972C for ; Thu, 25 Apr 2013 16:16:37 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id k7so3413920oag.16 for ; Thu, 25 Apr 2013 16:16:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=660kqby2XSBYxI1qREUH0s7qvKTz/VtwyrW0PhdUcOQ=; b=QG92YtuF0LY4aMBMmrtbNLKhvmiXTDo1bMY5TRQViTdTEDU7nk5rHhtFxJWy8qvKxn WtQfcV93vSYY9x+HX4Wo+pvZkkKhXwxMYQlo3UFZds0M+EcWGuRZP8jJBKZhtg8LUqz6 jN13y29rCXzxaY0bvXuOzvub3Z8eyKhgTlAnASFfvpgq4JFNA5w/LOW2PdkrmmE1OFYS zfq+oVMfp6C67/c6/N8flgeGRsARF7gv9gbzBQNW3M4pj5PLI70PeDEMSQ1pYpinYdVF 6wYsPIsiOCsOCUEnu10lrWFmlWhbz8J7VlwdJEj6gIxytpjItF0vND+GUBweHJ1Gu7Qb RsPg== MIME-Version: 1.0 X-Received: by 10.182.171.8 with SMTP id aq8mr10056959obc.27.1366931797330; Thu, 25 Apr 2013 16:16:37 -0700 (PDT) Received: by 10.60.41.225 with HTTP; Thu, 25 Apr 2013 16:16:37 -0700 (PDT) X-Originating-IP: [76.21.182.222] In-Reply-To: <18BB8C27-5373-40A3-B1F6-F21F66B5BF75@ve7jtb.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> <18BB8C27-5373-40A3-B1F6-F21F66B5BF75@ve7jtb.com> Date: Thu, 25 Apr 2013 19:16:37 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=e89a8ff1ccaa365b3904db379c13 X-Gm-Message-State: ALoCoQlG5sQoMNbPxKMl9isnKrqld9lzdWcAe+Xpe7TBxFOs60FaZ7yswzPeBIbgKlNi4/wPpc13 Cc: Mike Jones , Russ Housley , "jose@ietf.org" , Matt Miller Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:16:41 -0000 --e89a8ff1ccaa365b3904db379c13 Content-Type: text/plain; charset=ISO-8859-1 Again, this is because Matt has hacked around the current system to remove per-recipient data from integrity protection. And the fact that you're OK with that would mean that you would be OK with removing per-recipient data from integrity protection in general, if you were to be logically consistent ;) --Richard On Thu, Apr 25, 2013 at 7:13 PM, John Bradley wrote: > I agree with Matt. I don't think there is anything in the XMPP use case > that would break if the envelope is integrity protected. > I think there is only a single envelope anyway as I understand it. > > John B. > > On 2013-04-25, at 7:02 PM, Matt Miller wrote: > > > > > On Apr 25, 2013, at 3:56 PM, Richard Barnes > > wrote: > > > >> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones < > Michael.Jones@microsoft.com>wrote: > >> > >>> Hi Russ, > >>> > >>> I agree that enabling GCM to be safely used in the multiple recipients > >>> case would be highly desirable. It is currently prohibited because if > the > >>> recipients share a common key and initialization vector (IV) but use > >>> different AAD values, this results in the identified vulnerability. > One > >>> possible solution that continues integrity protecting the headers but > >>> enables the safe use of GCM was identified off-list by John Bradley. > >>> > >>> That solution is to have each recipient always use the same key, IV, > and > >>> AAD values. This could be accomplished by including all the header > values > >>> in a single combined AAD value, rather than having the integrity > protection > >>> for each recipient's headers be independent. > >>> > >>> This change could be done in a manner that doesn't affect the > computation > >>> for the single recipients case. Given the upcoming interim JOSE > meeting > >>> next week, and given the (understandable) strong negative reaction to > the > >>> unusability of GCM with the current multiple recipients processing > rules, > >>> I'll plan on quickly producing a draft -10 that changes the processing > >>> rules in the manner described above, so that idea can be concretely > >>> considered by the working group next week. > >>> > >>> Just so people are clear on the properties on the new processing rules > - > >>> this would mean that the integrity computations for each recipients > would > >>> no longer be independent. The only downside of this (which could be an > >>> upside in some ways) is that it would no longer be possible to add > >>> recipients over time without performing a new encryption computation > with a > >>> new CEK and IV. > >>> > >> > >> As I said to John, that is not an acceptable solution because it breaks > the > >> XMPP use case. The minimum sensible change is to remove the > per-recipient > >> info from the integrity check. > >> > > > > It is not clear to me how John's suggestion utterly breaks the XMPP use > case, unless you have this alternate-reality version of XMPP-E2E you've not > yet told me about (-: > > > > The current XMPP document already separates per-recipient info from the > actual protected content. > > > > > > - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > --e89a8ff1ccaa365b3904db379c13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Again, this is because Matt has hacked around the current = system to remove per-recipient data from integrity protection. =A0And the f= act that you're OK with that would mean that you would be OK with remov= ing per-recipient data from integrity protection in general, if you were to= be logically consistent ;)

--Richard

On Thu, Apr 25, 2013 at 7:13 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I agree with Matt. =A0 I don't think the= re is anything in the XMPP use case that would break if the envelope is int= egrity protected.
I think there is only a single envelope anyway as I understand it.

John B.

On 2013-04-25, at 7:02 PM, Matt Miller <mamille2@cisco.com> wrote:

>
> On Apr 25, 2013, at 3:56 PM, Richard Barnes <rlb@ipv.sx>
> wrote:
>
>> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:
>>
>>> Hi Russ,
>>>
>>> I agree that enabling GCM to be safely used in the multiple re= cipients
>>> case would be highly desirable. =A0It is currently prohibited = because if the
>>> recipients share a common key and initialization vector (IV) b= ut use
>>> different AAD values, this results in the identified vulnerabi= lity. =A0One
>>> possible solution that continues integrity protecting the head= ers but
>>> enables the safe use of GCM was identified off-list by John Br= adley.
>>>
>>> That solution is to have each recipient always use the same ke= y, IV, and
>>> AAD values. =A0This could be accomplished by including all the= header values
>>> in a single combined AAD value, rather than having the integri= ty protection
>>> for each recipient's headers be independent.
>>>
>>> This change could be done in a manner that doesn't affect = the computation
>>> for the single recipients case. =A0Given the upcoming interim = JOSE meeting
>>> next week, and given the (understandable) strong negative reac= tion to the
>>> unusability of GCM with the current multiple recipients proces= sing rules,
>>> I'll plan on quickly producing a draft -10 that changes th= e processing
>>> rules in the manner described above, so that idea can be concr= etely
>>> considered by the working group next week.
>>>
>>> Just so people are clear on the properties on the new processi= ng rules -
>>> this would mean that the integrity computations for each recip= ients would
>>> no longer be independent. =A0The only downside of this (which = could be an
>>> upside in some ways) is that it would no longer be possible to= add
>>> recipients over time without performing a new encryption compu= tation with a
>>> new CEK and IV.
>>>
>>
>> As I said to John, that is not an acceptable solution because it b= reaks the
>> XMPP use case. =A0The minimum sensible change is to remove the per= -recipient
>> info from the integrity check.
>>
>
> It is not clear to me how John's suggestion utterly breaks the XMP= P use case, unless you have this alternate-reality version of XMPP-E2E you&= #39;ve not yet told me about (-:
>
> The current XMPP document already separates per-recipient info from th= e actual protected content.
>
>
> - m&m
>
> Matt Miller < mamille2@cisco.= com >
> Cisco Systems, Inc.
>
> __________________= _____________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


--e89a8ff1ccaa365b3904db379c13-- From Michael.Jones@microsoft.com Thu Apr 25 16:19:28 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701AF21F970E for ; Thu, 25 Apr 2013 16:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd8y25gVt7UQ for ; Thu, 25 Apr 2013 16:19:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3484F21F9708 for ; Thu, 25 Apr 2013 16:19:25 -0700 (PDT) Received: from BL2FFO11FD006.protection.gbl (10.173.161.201) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 23:07:40 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 23:07:40 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 23:07:31 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgADgbwCAABQ8wIAAMvAAgAAAOwCAAAvb8IAACiwAgAAAbIA= Date: Thu, 25 Apr 2013 23:07:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C07DF@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676C07DFTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704004)(36944002)(24454001)(377424002)(377454001)(13464002)(189002)(199002)(66066001)(80022001)(65816001)(81542001)(47976001)(74366001)(564824004)(512954001)(55846006)(59766001)(47736001)(4396001)(63696002)(69226001)(71186001)(77982001)(50986001)(79102001)(49866001)(51856001)(81342001)(54316002)(54356001)(56776001)(47446002)(76482001)(53806001)(16297215002)(16406001)(16236675002)(56816002)(74662001)(74502001)(46102001)(31966008)(15202345002)(44976003)(33656001)(6806003)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB030; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: Russ Housley , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:19:28 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676C07DFTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Options just complicate things, and give developers additional opportunitie= s to make the wrong choices. From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 4:05 PM To: Mike Jones Cc: Russ Housley; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones > wrote: As background on the decision to integrity protect the headers - this didn'= t come out of a vacuum. The JWT designers sought out Ben Laurie's advice i= n 2010 and he'd suggested that the best thing would be to protect everythin= g. Indeed, Ben restated exactly the same position in a CRFG discussion on = the topic earlier this month, writing "Why even discuss these? What is wron= g with the answer "all parameters should be protected"?". You should also note that I answered that question, and Ben backed off sign= ificantly from his initial position. There were also several other comment= ers on the CFRG thread, who did not see utility in mandatory header protect= ion. Ben's not the only one who believes that it's appropriate to protect the me= tadata. For instance, the abstract of RFC 6211 "Cryptographic Message Synt= ax (CMS) Algorithm Identifier Protection Attribute" begins "The Cryptograph= ic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to a= lgorithm substitution attacks". Like RFC 6211 does for CMS, some would als= o like to prevent those attacks for JOSE. I agree! There should be an *option* for integrity-protecting parameters, i= n the limited cases where such protection is necessary. It is not necessar= y with PKCS#1 v1.5 signatures, since the signature algorithm encodes an OID= for the hash algorithm. It is not necessary for JWE. I would be happy to= discuss the shape of such an option at the interim next week. --Richard Best wishes= , -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 2:46 PM To: Russ Housley Cc: Mike Jones; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley > wrote: Mike: If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients. I do not see the need for JOSE header integrity. I have said this in the p= ast. I'm saying it again.... +much_more_than_one Russ On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > Hi Russ, > > I agree that enabling GCM to be safely used in the multiple recipients ca= se would be highly desirable. It is currently prohibited because if the re= cipients share a common key and initialization vector (IV) but use differen= t AAD values, this results in the identified vulnerability. One possible s= olution that continues integrity protecting the headers but enables the saf= e use of GCM was identified off-list by John Bradley. > > That solution is to have each recipient always use the same key, IV, and = AAD values. This could be accomplished by including all the header values = in a single combined AAD value, rather than having the integrity protection= for each recipient's headers be independent. > > This change could be done in a manner that doesn't affect the computation= for the single recipients case. Given the upcoming interim JOSE meeting n= ext week, and given the (understandable) strong negative reaction to the un= usability of GCM with the current multiple recipients processing rules, I'l= l plan on quickly producing a draft -10 that changes the processing rules i= n the manner described above, so that idea can be concretely considered by = the working group next week. > > Just so people are clear on the properties on the new processing rules - = this would mean that the integrity computations for each recipients would n= o longer be independent. The only downside of this (which could be an upsi= de in some ways) is that it would no longer be possible to add recipients o= ver time without performing a new encryption computation with a new CEK and= IV. > > Cheers, > -- Mike > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Thursday, April 25, 2013 10:31 AM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.tx= t > > Mike: > > Like Jim, I cannot support this statement: AES GCM MUST NOT be used when = using the JWE JSON Serialization for multiple recipients > > All recipients ought to be performing decryption and integrity checking w= ith the same GCM key. The manner in which they obtain that key may be diff= erent (key transport: decrypt the GCM key with the recipient's private key,= key agreement: agreement of a pairwise KEK and then unwrapping the GCM key= with the KEK, pre-shared KEK: unwrapping the GCM key with the already know= n KEK, etc). > > Russ > > > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote: > >> Mike, >> >> AES GCM MUST NOT be used when using the JWE JSON Serialization for >> multiple recipients, since this would result in the same >> Initialization Vector and Plaintext values being used for multiple >> GCM encryptions. >> >> I doubt your co-authors would agree with this. >> I doubt the working group with agree with this. >> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate would >> crucify me if I allowed this to stand in the document.. >> >> Jim >> >> >> >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf >>> Of internet-drafts@ietf.org >>> Sent: Tuesday, April 23, 2013 5:29 PM >>> To: i-d-announce@ietf.org >>> Cc: jose@ietf.org >>> Subject: [jose] I-D Action: >>> draft-ietf-jose-json-web-encryption-09.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Javascript Object Signing and >>> Encryption Working Group of the IETF. >>> >>> Title : JSON Web Encryption (JWE) >>> Author(s) : Michael B. Jones >>> Eric Rescorla >>> Joe Hildebrand >>> Filename : draft-ietf-jose-json-web-encryption-09.txt >>> Pages : 54 >>> Date : 2013-04-23 >>> >>> Abstract: >>> JSON Web Encryption (JWE) is a means of representing encrypted >>> content using JavaScript Object Notation (JSON) data structures. >>> Cryptographic algorithms and identifiers for use with this >>> specification are described in the separate JSON Web Algorithms (JWA) >>> specification. Related digital signature and MAC capabilities are >>> described in the separate JSON Web Signature (JWS) specification. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption- >>> 09 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676C07DFTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Options just complicate t= hings, and give developers additional opportunities to make the wrong choic= es.

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 4:05 PM
To: Mike Jones
Cc: Russ Housley; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

As background on the decision to integrity= protect the headers – this didn’t come out of a vacuum.  = The JWT designers sought out Ben Laurie’s advice in 2010 and he’= ;d suggested that the best thing would be to protect everything.  Indeed, Ben restated exactly the same position in a CRFG discussion = on the topic earlier this month, writing “Why even discuss the= se? What is wrong with the answer "all parameters should be protected&= quot;?”.

You should also note that I answered that question, = and Ben backed off significantly from his initial position.  There wer= e also several other commenters on the CFRG thread, who did not see utility= in mandatory header protection.

 

Ben’s not the only one who believes that it’s ap=
propriate to protect the metadata.  For instance, the abstract of RFC =
6211 “Cryptographic Message Syntax (CMS) Algorithm Identifier Protect=
ion Attribute” begins “The Cryptograph=
ic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to a=
lgorithm substitution attacks”.  Like RFC 6211 =
does for CMS, some would also like to prevent those attacks for JOSE.

I agree! There should be an *option* for integrity-p= rotecting parameters, in the limited cases where such protection is necessa= ry.  It is not necessary with PKCS#1 v1.5 signatures, since the signat= ure algorithm encodes an OID for the hash algorithm.  It is not necessary for JWE.  I would be happy to di= scuss the shape of such an option at the interim next week. 

 

--Richard

 

 

 

       =             &nb= sp;            =             &nb= sp;            =        Best wishes,

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

 

From: Richard Barnes [mailto= :rlb@ipv.sx]
Sent: Thursday, April 25, 2013 2:46 PM
To: Russ Housley
Cc: Mike Jones; j= ose@ietf.org


Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <housley@vigilsec.com> wrot= e:

Mike:

If the header is protected with the AAD mechanism in GCM, then it must cove= r exactly the same bits for all recipients.

I do not see the need for JOSE header integrity.  I have said this in = the past.  I'm saying it again....

 

+much_more_than_one

 

 

 


Russ



On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:

> Hi Russ,
>
> I agree that enabling GCM to be safely used in the multiple recipients= case would be highly desirable.  It is currently prohibited because i= f the recipients share a common key and initialization vector (IV) but use = different AAD values, this results in the identified vulnerability.  One possible solution that continues integ= rity protecting the headers but enables the safe use of GCM was identified = off-list by John Bradley.
>
> That solution is to have each recipient always use the same key, IV, a= nd AAD values.  This could be accomplished by including all the header= values in a single combined AAD value, rather than having the integrity pr= otection for each recipient's headers be independent.
>
> This change could be done in a manner that doesn't affect the computat= ion for the single recipients case.  Given the upcoming interim JOSE m= eeting next week, and given the (understandable) strong negative reaction t= o the unusability of GCM with the current multiple recipients processing rules, I'll plan on quickly producing a dra= ft -10 that changes the processing rules in the manner described above, so = that idea can be concretely considered by the working group next week.
>
> Just so people are clear on the properties on the new processing rules= - this would mean that the integrity computations for each recipients woul= d no longer be independent.  The only downside of this (which could be= an upside in some ways) is that it would no longer be possible to add recipients over time without performing a new= encryption computation with a new CEK and IV.
>
>                     =           Cheers,
>                     =           -- Mike
>
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Thursday, April 25, 2013 10:31 AM
> To: Mike Jones
> Cc: jose@ietf.org
> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09= .txt
>
> Mike:
>
> Like Jim, I cannot support this statement: AES GCM MUST NOT be used wh= en using the JWE JSON Serialization for multiple recipients
>
> All recipients ought to be performing decryption and integrity checkin= g with the same GCM key.  The manner in which they obtain that key may= be different (key transport: decrypt the GCM key with the recipient's priv= ate key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM key with the KEK, pre-shared KEK: unwrappi= ng the GCM key with the already known KEK, etc).
>
> Russ
>
>
> On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:
>
>> Mike,
>>
>> AES GCM MUST NOT be used when using the JWE JSON Serialization for=
>>  multiple recipients, since this would result in the same
>>  Initialization Vector and Plaintext values being used for mu= ltiple
>>  GCM encryptions.
>>
>> I doubt your co-authors would agree with this.
>> I doubt the working group with agree with this.
>> I know that at least one co-chair does not agree with this I can >> predict that the AD and IESG along with the security directorate w= ould
>> crucify me if I allowed this to stand in the document..
>>
>> Jim
>>
>>
>>
>>> -----Original Message-----
>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
>>> Of internet-drafts@ietf.org
>>> Sent: Tuesday, April 23, 2013 5:29 PM
>>> To: i-d-announce@ietf.org
>>> Cc: jose@ie= tf.org
>>> Subject: [jose] I-D Action:
>>> draft-ietf-jose-json-web-encryption-09.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Javascript Object Signing and=
>>> Encryption Working Group of the IETF.
>>>
>>>     Title           : JSON = Web Encryption (JWE)
>>>     Author(s)       : Michael B. Jone= s
>>>                  =       Eric Rescorla
>>>                  =       Joe Hildebrand
>>>     Filename        : draft-ietf= -jose-json-web-encryption-09.txt
>>>     Pages           : 54 >>>     Date            : = 2013-04-23
>>>
>>> Abstract:
>>>  JSON Web Encryption (JWE) is a means of representing enc= rypted
>>>  content using JavaScript Object Notation (JSON) data str= uctures.
>>>  Cryptographic algorithms and identifiers for use with th= is
>>>  specification are described in the separate JSON Web Alg= orithms (JWA)
>>>  specification.  Related digital signature and MAC c= apabilities are
>>>  described in the separate JSON Web Signature (JWS) speci= fication.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption >>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-=
>>> 09
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943676C07DFTK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Thu Apr 25 16:26:31 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAAE21F972B for ; Thu, 25 Apr 2013 16:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7tNI9uL0wRq for ; Thu, 25 Apr 2013 16:26:31 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id B950521F9732 for ; Thu, 25 Apr 2013 16:26:30 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id p22so3188866iad.24 for ; Thu, 25 Apr 2013 16:26:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=wzH64KlJez2Sm1Yr1kbmRVmnMnUl1cKRd8R4JAGVhRY=; b=MWK8aDkNk68Q3f8WKhyAtqC0/vmCXCj9K2+3UhvdDpNoMYTPgQVYVpMuOK9H9/454w 6MEkQZ6W8KjDxJWm5TJWc8dbddGEDQmIvcI3oUhl1qh8nsmvfg6hIoSUBCAkCtC1AxIC HI1C1k8KZIEwhzHqGPNl3FoBdW/vzcJBcUtb5xFnXVsHLOyj6DvuESHg/xXUsgkEN/sn taExFFsixPp30i7ByE2cVtokrvQq7wpKaM5FRAs0PILGoKvLXeYZh7otraJmHhOOPMj0 LrH1N14F6s+Jsc4StkVFn49QxurJF0tALIpij1jjYGFIjRUZb7VHph+GOUpli/HRAxih Tj1A== X-Received: by 10.50.77.110 with SMTP id r14mr299397igw.85.1366932388488; Thu, 25 Apr 2013 16:26:28 -0700 (PDT) Received: from [192.168.1.39] (190-20-37-138.baf.movistar.cl. [190.20.37.138]) by mx.google.com with ESMTPSA id q3sm297267igw.0.2013.04.25.16.26.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 16:26:27 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9ADB272D-A61B-42AB-A35E-81FA76B9F319"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Thu, 25 Apr 2013 20:26:15 -0300 Message-Id: <96BF09A5-22AC-4FE9-A28C-746D8D269F06@ve7jtb.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <95BF000E-50B4-4D42-8F21-A6D5BE9D7A59@cisco.com> <18BB8C27-5373-40A3-B1F6-F21F66B5BF75@ve7jtb.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQn7oyG0T4xFTO8l8cBFgqrr3ZkWabbyd7T1z4gOygI9kWl76RWX7ZdjN565cLffHqZQHqaD Cc: Mike Jones , Russ Housley , "jose@ietf.org" , Matt Miller Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:26:32 -0000 --Apple-Mail=_9ADB272D-A61B-42AB-A35E-81FA76B9F319 Content-Type: multipart/alternative; boundary="Apple-Mail=_B0960B43-B532-44EA-937F-F0D614613B0C" --Apple-Mail=_B0960B43-B532-44EA-937F-F0D614613B0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I suspect you are overstating the case:) It is hard to have per endpoint recipient information in the header when = the sender doesn't know what the endpoints that are going to receive the = JWE are before it sends it. I would prefer to avoid using XMPP as a football for this. There is probably a better use case someplace that would show how a = sender knowing beforehand the information for multiple recipients would = encrypt the same plain text to all of them. Mostly what I would like = to understand is if there is a real requirement for incremental = encryption to new recipients after the fact using the same CMK & IV, or = can the CMK & IV change for additional recipients. John B. On 2013-04-25, at 8:16 PM, Richard Barnes wrote: > Again, this is because Matt has hacked around the current system to = remove per-recipient data from integrity protection. And the fact that = you're OK with that would mean that you would be OK with removing = per-recipient data from integrity protection in general, if you were to = be logically consistent ;) >=20 > --Richard >=20 >=20 > On Thu, Apr 25, 2013 at 7:13 PM, John Bradley = wrote: > I agree with Matt. I don't think there is anything in the XMPP use = case that would break if the envelope is integrity protected. > I think there is only a single envelope anyway as I understand it. >=20 > John B. >=20 > On 2013-04-25, at 7:02 PM, Matt Miller wrote: >=20 > > > > On Apr 25, 2013, at 3:56 PM, Richard Barnes > > wrote: > > > >> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones = wrote: > >> > >>> Hi Russ, > >>> > >>> I agree that enabling GCM to be safely used in the multiple = recipients > >>> case would be highly desirable. It is currently prohibited = because if the > >>> recipients share a common key and initialization vector (IV) but = use > >>> different AAD values, this results in the identified = vulnerability. One > >>> possible solution that continues integrity protecting the headers = but > >>> enables the safe use of GCM was identified off-list by John = Bradley. > >>> > >>> That solution is to have each recipient always use the same key, = IV, and > >>> AAD values. This could be accomplished by including all the = header values > >>> in a single combined AAD value, rather than having the integrity = protection > >>> for each recipient's headers be independent. > >>> > >>> This change could be done in a manner that doesn't affect the = computation > >>> for the single recipients case. Given the upcoming interim JOSE = meeting > >>> next week, and given the (understandable) strong negative reaction = to the > >>> unusability of GCM with the current multiple recipients processing = rules, > >>> I'll plan on quickly producing a draft -10 that changes the = processing > >>> rules in the manner described above, so that idea can be = concretely > >>> considered by the working group next week. > >>> > >>> Just so people are clear on the properties on the new processing = rules - > >>> this would mean that the integrity computations for each = recipients would > >>> no longer be independent. The only downside of this (which could = be an > >>> upside in some ways) is that it would no longer be possible to add > >>> recipients over time without performing a new encryption = computation with a > >>> new CEK and IV. > >>> > >> > >> As I said to John, that is not an acceptable solution because it = breaks the > >> XMPP use case. The minimum sensible change is to remove the = per-recipient > >> info from the integrity check. > >> > > > > It is not clear to me how John's suggestion utterly breaks the XMPP = use case, unless you have this alternate-reality version of XMPP-E2E = you've not yet told me about (-: > > > > The current XMPP document already separates per-recipient info from = the actual protected content. > > > > > > - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 --Apple-Mail=_B0960B43-B532-44EA-937F-F0D614613B0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = suspect you are overstating the case:)

It is hard to = have per endpoint recipient information in the header when the sender = doesn't know what the endpoints that are going to receive the JWE are = before it sends it.

I would prefer to avoid = using XMPP as a football for this.

There is = probably a better use case someplace that would show how a sender = knowing beforehand the information for multiple recipients would encrypt = the same plain text to all of them.   Mostly what I would like to = understand is if there is a real requirement for incremental encryption = to new recipients after the fact using the same CMK & IV, or can the = CMK & IV change for additional = recipients.

John B.

On = 2013-04-25, at 8:16 PM, Richard Barnes <rlb@ipv.sx> wrote:

Again, this is because Matt has hacked around the current = system to remove per-recipient data from integrity protection.  And = the fact that you're OK with that would mean that you would be OK with = removing per-recipient data from integrity protection in general, if you = were to be logically consistent ;)

--Richard


On Thu, Apr 25, = 2013 at 7:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree with Matt. =   I don't think there is anything in the XMPP use case that would = break if the envelope is integrity protected.
I think there is only a single envelope anyway as I understand it.

John B.

On 2013-04-25, at 7:02 PM, Matt Miller <mamille2@cisco.com> wrote:

>
> On Apr 25, 2013, at 3:56 PM, Richard Barnes <rlb@ipv.sx>
> wrote:
>
>> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:
>>
>>> Hi Russ,
>>>
>>> I agree that enabling GCM to be safely used in the multiple = recipients
>>> case would be highly desirable.  It is currently = prohibited because if the
>>> recipients share a common key and initialization vector = (IV) but use
>>> different AAD values, this results in the identified = vulnerability.  One
>>> possible solution that continues integrity protecting the = headers but
>>> enables the safe use of GCM was identified off-list by John = Bradley.
>>>
>>> That solution is to have each recipient always use the same = key, IV, and
>>> AAD values.  This could be accomplished by including = all the header values
>>> in a single combined AAD value, rather than having the = integrity protection
>>> for each recipient's headers be independent.
>>>
>>> This change could be done in a manner that doesn't affect = the computation
>>> for the single recipients case.  Given the upcoming = interim JOSE meeting
>>> next week, and given the (understandable) strong negative = reaction to the
>>> unusability of GCM with the current multiple recipients = processing rules,
>>> I'll plan on quickly producing a draft -10 that changes the = processing
>>> rules in the manner described above, so that idea can be = concretely
>>> considered by the working group next week.
>>>
>>> Just so people are clear on the properties on the new = processing rules -
>>> this would mean that the integrity computations for each = recipients would
>>> no longer be independent.  The only downside of this = (which could be an
>>> upside in some ways) is that it would no longer be possible = to add
>>> recipients over time without performing a new encryption = computation with a
>>> new CEK and IV.
>>>
>>
>> As I said to John, that is not an acceptable solution because = it breaks the
>> XMPP use case.  The minimum sensible change is to remove = the per-recipient
>> info from the integrity check.
>>
>
> It is not clear to me how John's suggestion utterly breaks the XMPP = use case, unless you have this alternate-reality version of XMPP-E2E = you've not yet told me about (-:
>
> The current XMPP document already separates per-recipient info from = the actual protected content.
>
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
>
> = _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose



= --Apple-Mail=_B0960B43-B532-44EA-937F-F0D614613B0C-- --Apple-Mail=_9ADB272D-A61B-42AB-A35E-81FA76B9F319 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDI1MjMyNjE1WjAjBgkqhkiG9w0BCQQxFgQUJZlunCgp +UpWqDavjkffTrWyV2swgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEATyJsI4Q7AJqEFnXdX+WoLYOEYSCg+0ki1hkSiR2L PgQpQYKS747Y4WNtPFiQjMLAbPjEyYEuSCbV49zc7SyLmOB47sr2WQpHclCXk8fOsuFm6MwR3Rzh 7btuVECPgnlhuXh10Q0HEgzRC7TYyA0prfUV4i0P9kXc3SwvD4JZMDXx1qmeJ5NG82bJKqIpKvxm tVSpebmXQ/r1qnAV3FwAba9fgnRow97bow/PiwyEcX601a2Kd6mMFdj1ShCNKeiwLXT6Z12YnC7q Y3aFVltHFPo8emCBSKWMeMsM3UPNxmY6TA/f+d7AvBh2LGg0vQIsOKZNf4TEhWnuSNl7F43FzgAA AAAAAA== --Apple-Mail=_9ADB272D-A61B-42AB-A35E-81FA76B9F319-- From Michael.Jones@microsoft.com Thu Apr 25 16:48:03 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9C21F973D for ; Thu, 25 Apr 2013 16:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrDukzGKhN4J for ; Thu, 25 Apr 2013 16:47:58 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1A61B21F973C for ; Thu, 25 Apr 2013 16:47:57 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.202) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 23:47:56 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 23:47:56 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 23:47:49 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgAAqctCAAMIPAIAAB4vggAAhhoCAABORgIAADu7AgAAGIgCAAAtfoA== Date: Thu, 25 Apr 2013 23:47:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C0973@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676C05E5@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676C0973TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454001)(377424002)(13464002)(51704004)(24454001)(50986001)(53806001)(44976003)(56816002)(20776003)(59766001)(51856001)(80022001)(63696002)(15202345002)(66066001)(54316002)(16406001)(56776001)(16236675002)(81342001)(79102001)(74366001)(74502001)(6806003)(71186001)(76482001)(33656001)(55846006)(81542001)(47736001)(564824004)(54356001)(74662001)(47976001)(47446002)(49866001)(512954001)(4396001)(65816001)(46102001)(31966008)(77982001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 Cc: John Bradley , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 23:48:03 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676C0973TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not all AAD data will be binary. For instance, if it's already JSON object= , no base64url encoding would be necessary. From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 4:06 PM To: Mike Jones Cc: John Bradley; Jim Schaad; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Yes, if the application is willing to accept the horrendous inefficiency of= double-base64 encoding. Again, arbitrary and capricious restriction in the name of a non-existent s= ecurity benefit. --Richard On Thu, Apr 25, 2013 at 6:46 PM, Mike Jones > wrote: Applications are now free to add their own AAD information to the JWE heade= r, now that not-understood header parameters must be ignored. From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, April 25, 2013 2:51 PM To: John Bradley Cc: Mike Jones; Jim Schaad; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt On Thu, Apr 25, 2013 at 4:40 PM, John Bradley > wrote: For multiple recipients using GCM with a single CEK and IV we can logically= have 0 AAD segments or 1 AAD segment. That is just the reality of the situation. I would also note that taking the JOSE overhead out of the AAD segment free= s it up for the application to use. One possible solution is to the GCM issue is to have 1 AAD segment containi= ng the envelope information for all recipients. I understand for people wanting 0 AAD segments that will not be there first= choice. The downside of this is that you can't incrementally add recipients, they a= ll need to be known upfront to include the info in the AAD. What I don't know is if there is really any compelling use-case for increme= ntal addition of recipients without re-encrypting (changing the IV atleast) The XMPP use case is precisely this. When the sender encrypts the message,= it doesn't know the set of public keys that it's sending it to. So the only other possible alternative is taking the per-recipient info out= of the integrity check. But if we're going to do that, we might as well g= o all the way and get rid of the integrity check altogether. Applications= that want to integrity protect information can put it in the AAD segment o= n their own. --Richard John B. . On 2013-04-25, at 4:14 PM, Mike Jones > wrote: Hi Richard, Actually, there are four goals in play: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity protection 4. Independent protection of each recipient's headers Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. (Cred= it goes to John Bradley for this solution.) -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, April 25, 2013 11:14 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, Your facts are right, but your conclusions are wrong. We have three mutually incompatible goals here: 1. GCM 2. Efficient encoding for multiple recipients 3. Header integrity We can have any two of these, but not all three. If we try to do all three= (JWE-08), then we end up with the vulnerability identified in the CFRG thr= ead. So we need to choose which one to get rid of. Getting rid of GCM is clearly not the right answer, as evidenced by the rea= ction in this thread. There are clear, concrete use reasons to support mul= tiple recipients, but not for header integrity. And header integrity can b= e "polyfilled" with an optional feature, for those who are willing to break= the multiple recipient case. Clearly, header integrity is the weakest lin= k here. JWE-09 is the reductio ad absurdum of header integrity. Let's do the logic= al thing and stop the absurdity. --Richard On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones > wrote: Jim - I am surprised that you would say that my co-authors Eric Rescorla or= Joe Hildebrand or the working group would advocate using AES GCM in a way = that would result in severe security vulnerabilities - in particular, allow= ing attackers to obtain the XOR of the messages to multiple recipients encr= ypted using GCM - a vulnerability identified by the CFRG. Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. = As I said to Richard Barnes over dinner last night, while unpleasant, and = possibly surprising to those who aren't familiar to how GCM actually works,= as an editor, I viewed including the statement that "AES GCM MUST NOT be u= sed when using the JWE JSON Serialization for multiple recipients, since th= is would result in the same Initialization Vector and Plaintext values bein= g used for multiple GCM encryptions" as necessary, and "truth in advertisin= g". -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 24, 2013 9:07 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Mike, AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions. I doubt your co-authors would agree with this. I doubt the working group with agree with this. I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document.. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Tuesday, April 23, 2013 5:29 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF. > > Title : JSON Web Encryption (JWE) > Author(s) : Michael B. Jones > Eric Rescorla > Joe Hildebrand > Filename : draft-ietf-jose-json-web-encryption-09.txt > Pages : 54 > Date : 2013-04-23 > > Abstract: > JSON Web Encryption (JWE) is a means of representing encrypted > content using JavaScript Object Notation (JSON) data structures. > Cryptographic algorithms and identifiers for use with this > specification are described in the separate JSON Web Algorithms (JWA) > specification. Related digital signature and MAC capabilities are > described in the separate JSON Web Signature (JWS) specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0 > 9 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676C0973TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not all AAD data will be = binary.  For instance, if it’s already JSON object, no base64url= encoding would be necessary.

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, April 25, 2013 4:06 PM
To: Mike Jones
Cc: John Bradley; Jim Schaad; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

Yes, if the application is willing to accept the hor= rendous inefficiency of double-base64 encoding.

 

Again, arbitrary and capricious rest= riction in the name of a non-existent security benefit.

 

--Richard

 

On Thu, Apr 25, 2013 at 6:46 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Applications are now free to add their = own AAD information to the JWE header, now that not-understood header parameters must be ignored.

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2013 2:51 PM
To: John Bradley
Cc: Mike Jones; Jim Schaad; jose@ietf.org


Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-= 09.txt

 

On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

For multiple recipients using GCM with a single CEK and IV we can = logically have 0 AAD segments or 1 AAD segment.

 

That is just the reality of the situation. 

 

I would also note that taking the JOSE overhead out of the AAD seg= ment frees it up for the application to use.

 

 

One possible solution is to the GCM issue is to have 1 AAD segment= containing the envelope information for all recipients.

I understand for people wanting 0 AAD segments that will not be th= ere first choice.

 

The downside of this is that you can't incrementally add recipient= s, they all need to be known upfront to include the info in the AAD.

 

What I don't know is if there is really any compelling use-case fo= r incremental addition of recipients without re-encrypting (changing the IV= atleast)

 

The XMPP use case is precisely this.  When the sender encrypt= s the message, it doesn't know the set of public keys that it's sending it = to.

 

So the only other possible alternative is taking the per-recipient= info out of the integrity check.  But if we're going to do that, we m= ight as well go all the way and get rid of the integrity check altogether.   Applications that want to integrity= protect information can put it in the AAD segment on their own. =

 

--Richard

 

 

 

 

John B.

 .  

 

On 2013-04-25, at 4:14 PM, Mike Jones <Michael.Jones@microsoft.com>= ; wrote:

 

Hi Richard,

 

Actually, there are four goals in play:=

 

1.  GCM

2.  Efficient encoding for multipl= e recipients

3.  Header integrity protection

4.  Independent protection of each= recipient’s headers

 

Per my response to Russ, by giving up 4= , we can achieve 1, 2, and 3.  (Credit goes to John Bradley for this solution.)

 

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

 

From: Richard Barnes [m= ailto:rlb@ipv.sx] =
Sent: Thursday, April 25, 2013 11:14 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryp= tion-09.txt

 

Mike, 

 

Your facts are right, but your conclusions are wrong.

 

We have three mutually incompatible goals here:

1. GCM

2. Efficient encoding for multiple recipients

3. Header integrity

 

We can have any two of these, but not all three.  If we try t= o do all three (JWE-08), then we end up with the vulnerability identified i= n the CFRG thread.  So we need to choose which one to get rid of.

 

Getting rid of GCM is clearly not the right answer, as evidenced b= y the reaction in this thread.  There are clear, concrete use reasons = to support multiple recipients, but not for header integrity.  And header integrity can be "polyfilled"= with an optional feature, for those who are willing to break the multiple = recipient case.  Clearly, header integrity is the weakest link here.

 

JWE-09 is the reductio ad absurdum of header integrity.  Let'= s do the logical thing and stop the absurdity.

 

--Richard

 

 

 

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Jim - I am surprised that you would say that my co-authors Eric Re= scorla or Joe Hildebrand or the working group would advocate using AES GCM = in a way that would result in severe security vulnerabilities - in particular, allowing attackers to obtain the= XOR of the messages to multiple recipients encrypted using GCM - a vulnera= bility identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsibl= e, given the brittleness of GCM in this regard, as identified by the CRFG. =  As I said to Richard Barnes over dinner last night, while unpleasant,= and possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed includin= g the statement that "AES GCM MUST NOT be used when using the JWE JSON= Serialization for multiple recipients, since this would result in the same= Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and &qu= ot;truth in advertising".

                     = ;           -- Mike


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt<= br>
Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the same
   Initialization Vector and Plaintext values being used for mult= iple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict th= at the AD and IESG along with the security directorate would crucify me if = I allowed this to stand in the document..

Jim



> -----Original Message-----
> From: = jose-bounces@ietf.org [mailto:= jose-bounces@ietf.org] On Behalf
> Of = internet-drafts@ietf.org
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org
> Cc: jose@ietf.org
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt=
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>  This draft is a work item of the Javascript Object Signing and > Encryption Working Group of the IETF.
>
>       Title           : JSON W= eb Encryption (JWE)
>       Author(s)       : Michael B. Jones=
>                     =       Eric Rescorla
>                     =       Joe Hildebrand
>       Filename        : draft-ietf-= jose-json-web-encryption-09.txt
>       Pages           : 54
>       Date            : 2= 013-04-23
>
> Abstract:
>    JSON Web Encryption (JWE) is a means of representing encr= ypted
>    content using JavaScript Object Notation (JSON) data stru= ctures.
>    Cryptographic algorithms and identifiers for use with thi= s
>    specification are described in the separate JSON Web Algo= rithms (JWA)
>    specification.  Related digital signature and MAC ca= pabilities are
>    described in the separate JSON Web Signature (JWS) specif= ication.
>
>
> The IETF datatracker status page for this draft is:
> https://data= tracker.ietf.org/doc/draft-ietf-jose-json-web-encryption
>
> There's also a htmlized version available at:
> http://tools.ie= tf.org/html/draft-ietf-jose-json-web-encryption-09
>
> A diff from the previous version is available at:
> http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-0=
> 9
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/= jose

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

 

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943676C0973TK5EX14MBXC283r_-- From James.H.Manger@team.telstra.com Fri Apr 26 00:32:45 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780D921F8555 for ; Fri, 26 Apr 2013 00:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tDuO+AC5c0U for ; Fri, 26 Apr 2013 00:32:45 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7AC21F97C9 for ; Fri, 26 Apr 2013 00:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,556,1363093200"; d="scan'208";a="132157798" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 26 Apr 2013 17:32:41 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7056"; a="180205803" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 26 Apr 2013 17:32:40 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 26 Apr 2013 17:32:40 +1000 From: "Manger, James H" To: John Bradley , "jose@ietf.org" Date: Fri, 26 Apr 2013 17:32:39 +1000 Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt Thread-Index: Ac5CCejdywkfLxV3S3KABOzbVsDo4QAPzBFg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150CD91AEA@WSMSG3153V.srv.dir.telstra.com> References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <74C39AC5-0C6B-4DC1-A273-3996D97D90A9@vigilsec.com> <53360D8F-6AB2-4F8F-A73D-CDDD5FE2E00E@ve7jtb.com> In-Reply-To: <53360D8F-6AB2-4F8F-A73D-CDDD5FE2E00E@ve7jtb.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:32:45 -0000 PiBGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNCj4gU2VudDogRnJpZGF5LCAyNiBBcHJpbCAy MDEzIDk6MDggQU0NCj4NCj4gSSB0aGluayB0aGVyZSB3ZXJlIHR3byBpc3N1ZXMgaWRlbnRpZmll ZC4NCj4NCj4gLi4uDQo+IDIuIMKgRW5jcnlwdGluZyB0aGUgc2FtZSBwbGFpbnRleHQgbXVsdGlw bGUgdGltZXMgd2l0aCB0aGUgc2FtZSBJViBhbmQgQ01LIGJ1dCBjaGFuZ2luZyB0aGUgQUFELiDC oCBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgc2xpZ2h0bHkgbGVzcyBjbGVhci4gwqAgVGhlcmUg d2lsbCBiZSBtdWx0aXBsZSB0YWdzIGdlbmVyYXRlZCBvbmUgZm9yIGVhY2ggZGlmZmVyZW50IEFB RC4gwqBUbyBwcm9kdWNlIHRoZSB0YWcgeW91IGVuY3J5cHQgdGhlIGZpbmFsIGhhc2ggdmFsdWUg d2l0aCB0aGUgYmxvY2sgaXMgeG9yZWQgd2l0aCB0aGUgSVYgYmxvY2sgZW5jcnlwdGVkIHdpdGgg dGhlIENNSy4gwqANCj4NCj7CoEkgZG9uJ3QgcGVyc29uYWxseSBrbm93IG9mIGFuIGF0dGFjayB0 aGF0IGNhbiBleHBsb2l0IGhhdmluZyBtdWx0aXBsZSB0YWdzIHhvcmVkIHdpdGggdGhlIHNhbWUg dmFsdWUuIMKgIE15IHRha2Ugb24gaXQgZnJvbSBNYyBHcmV3J3MgY29tbWVudCBvbiB0aGUgbGlz dCB3YXMgaXQgaXMgcHJvYmFibHkgbm90IGEgZ29vZCB0aGluZy4gwqAgSSB0aGluayBNaWtlIGFu ZCBJIGJvdGggdG9vayBmcm9tIHRoZSBjb252ZXJzYXRpb24gdGhhdCBwcm9kdWNpbmcgbXVsdGlw bGUgdGFnIHZhbHVlcyB0aGF0IGFyZSB4b3JkIHdpdGggdGhlIHNhbWUgZW5jcnlwdGVkIHZhbHVl IGlzIG5vdCBzb21ldGhpbmcgdGhhdCB3YXMgcmVjb21tZW5kZWQuDQo+DQo+IElmIEkgaGF2ZSB0 aGF0IHdyb25nIG5vdyB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byBzYXkgdGhhdCB0aGUgcHJhY3Rp Y2UgaXMgT0suIMKgwqANCg0KDQpSZW5hbWUgIklWIiB0byAiTm9uY2UiIChhcyBpdCBpcyBsYWJl bGxlZCBpbiBSRkMgNTExNiAiQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIiBmb3IgaW5zdGFuY2Up IGFuZCB0aGUgcHJvYmxlbSBpcyBjbGVhcmVyOiB0aGUgcG9pbnQgb2YgYSBub25jZSBpcyB0aGF0 IGl0IGlzIG9ubHkgdXNlZCBvbmNlIChwZXIga2V5KS4NCg0KSk9TRSBjYW5ub3Qga2VlcCBpdHMg Y3VycmVudCBtdWx0aXBsZSByZWNpcGllbnQgbW9kZSBhcyBpdCBicmVha3MgdGhlIGdlbmVyYWwg bW9kZWwgb2YgYW4gQUVBRCBhbGdvcml0aG0uIFJGQyA1MTE2IHNlY3Rpb24gMi4xOiAiRWFjaCBu b25jZSBwcm92aWRlZCB0byBkaXN0aW5jdCBpbnZvY2F0aW9ucyBvZiB0aGUgQXV0aGVudGljYXRl ZCBFbmNyeXB0aW9uIG9wZXJhdGlvbiBNVVNUIGJlIGRpc3RpbmN0LCBmb3IgYW55IHBhcnRpY3Vs YXIgdmFsdWUgb2YgdGhlIGtleSwgdW5sZXNzIGVhY2ggYW5kIGV2ZXJ5IG5vbmNlIGlzIHplcm8t bGVuZ3RoIi4gUmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB1c2luZyBHQ00gd2l0aCBzYW1l LW5vbmNlLWFuZC1wbGFpbnRleHQtZGlmZmVyZW50LUFBRCBpcyBvaywgaXQgd2lsbCBub3QgYmUg b2sgd2l0aCBvdGhlciBBRUFEIGFsZ3MsIHN1Y2ggYXMgU0lWIFtSRkMgNTI5N10uIENvbnNpZGVy aW5nIGFueSBhdXRoZW50aWNhdGlvbiB0YWcgdG8gYmUgcGFydCBvZiB0aGUgY2lwaGVydGV4dCAo Sk9TRSBpc3N1ZSAjMTEpIHdvdWxkIGF2b2lkIHRoaXMgc29ydCBvZiBjcnlwdG8gY3JhemluZXNz Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From internet-drafts@ietf.org Fri Apr 26 00:34:37 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B507921F97F4; Fri, 26 Apr 2013 00:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXF4QRrGOA2H; Fri, 26 Apr 2013 00:34:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 569A321F97ED; Fri, 26 Apr 2013 00:34:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426073437.10647.61123.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 00:34:37 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-10.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:34:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-10.txt Pages : 48 Date : 2013-04-26 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Apr 26 00:37:07 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F263121F9809; Fri, 26 Apr 2013 00:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNMGgoeQk08U; Fri, 26 Apr 2013 00:37:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5721F9808; Fri, 26 Apr 2013 00:37:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426073704.29926.36695.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 00:37:04 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-10.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:37:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-10.txt Pages : 57 Date : 2013-04-26 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Apr 26 00:38:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1C921F9199; Fri, 26 Apr 2013 00:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcOnvf3OFNq7; Fri, 26 Apr 2013 00:38:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1647E21F9743; Fri, 26 Apr 2013 00:38:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426073848.29310.32255.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 00:38:48 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-10.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:38:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-10.txt Pages : 16 Date : 2013-04-26 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Apr 26 00:41:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72CD21F9815; Fri, 26 Apr 2013 00:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeaKza2K8Avl; Fri, 26 Apr 2013 00:41:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2785521F9816; Fri, 26 Apr 2013 00:41:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426074129.3639.24707.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 00:41:29 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-10.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 07:41:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-10.txt Pages : 51 Date : 2013-04-26 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Fri Apr 26 01:25:10 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02F521F97BB for ; Fri, 26 Apr 2013 01:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJLeI3RQ+-o5 for ; Fri, 26 Apr 2013 01:25:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0DABE21F93E1 for ; Fri, 26 Apr 2013 01:25:04 -0700 (PDT) Received: from BL2FFO11FD022.protection.gbl (10.173.161.203) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.675.0; Fri, 26 Apr 2013 08:24:57 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD022.mail.protection.outlook.com (10.173.161.101) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Fri, 26 Apr 2013 08:24:57 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 26 Apr 2013 08:24:47 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Draft -10 of the JOSE Specifications Thread-Index: Ac5CV4GGnwFrDigGRRe4831w/fZ3Tw== Date: Fri, 26 Apr 2013 08:24:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676D2022@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676D2022TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(44976003)(31966008)(79102001)(66066001)(47446002)(76482001)(77982001)(47736001)(74502001)(51856001)(54316002)(56816002)(71186001)(53806001)(49866001)(80022001)(16406001)(55846006)(20776003)(63696002)(50986001)(16236675002)(59766001)(65816001)(74366001)(74662001)(54356001)(512954001)(4396001)(15202345002)(33656001)(6806003)(81542001)(69226001)(46102001)(564824004)(47976001)(81342001)(56776001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB010; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08286A0BE2 Subject: [jose] Draft -10 of the JOSE Specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 08:25:10 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676D2022TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based upon working group feedback on the -09 drafts, I've released an updat= e to the JSON Object Signing and Encryption (JOSE) specifications that chan= ges the processing rules for JWEs encrypted to multiple recipients. The ne= w processing rules enable using AES GCM for multiple-recipient JWE objects.= This update makes no changes to the single-recipient case. The updated specification versions are: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-10 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-10 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-10 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10 HTML formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-10= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-1= 0.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-10.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-1= 0.html -- Mike P.S. Also posted at http://self-issued.info/?p=3D1012. --_000_4E1F6AAD24975D4BA5B1680429673943676D2022TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ba= sed upon working group feedback on the -09 drafts, I’ve released an u= pdate to the JSON Object Signing and Encryption (JOSE) specifications that = changes the processing rules for JWEs encrypted to multiple recipients.  The new processing rules enable using AES GC= M for multiple-recipient JWE objects.  This update makes no changes to= the single-recipient case.

 

Th= e updated specification versions are:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-10

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-10

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-10

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-10

 

HT= ML formatted versions are also available at:

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-10.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-10.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-10.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-10.html

 

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

 

P.= S.  Also posted at http://self-issued.info/?p=3D= 1012.

 

--_000_4E1F6AAD24975D4BA5B1680429673943676D2022TK5EX14MBXC283r_-- From matake@gmail.com Fri Apr 26 01:48:41 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A509D21F97F7 for ; Fri, 26 Apr 2013 01:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmT4EBpXM90I for ; Fri, 26 Apr 2013 01:48:40 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8A21F91A2 for ; Fri, 26 Apr 2013 01:48:40 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id lf10so2380731pab.18 for ; Fri, 26 Apr 2013 01:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=GblRCtOCXh9lQeTaxIKRp/ojs47fYSxt5QvOoUHJUEM=; b=C5UfzDxX2oqISrqjZInbqsBbjqhbCScKC+ubEI5zDjr5Kjj8579YXBuu+SVEQibHPp 2Q6YwSRzejs+ZieDVqgo7DQfJBi/UeLyR+Mk/Mk5tYutyZJ3kIIv49lGOhKvkJOW0Aww XfYKP5yodklaPTWzH03PZ4FsUrq9W2+D3M4A9GfxC6ma7R4ry505VdSrD9puvCma832U EElPKpbqat1O7LrS1uwHJXstSv1HCA0mYq9jBXMT3V8hyq8EzIKrNq80cYSkB0ELbyfe 1H0vhlOstRjN8gXgBd3DkSACDYP+o3GcPt4lUdyXedDqzAZY+CQAs2966ABmD4ktpabT 19+A== X-Received: by 10.66.152.173 with SMTP id uz13mr30051192pab.73.1366966120630; Fri, 26 Apr 2013 01:48:40 -0700 (PDT) Received: from air.dev.gree.jp (124x35x46x13.ap124.ftth.ucom.ne.jp. [124.35.46.13]) by mx.google.com with ESMTPSA id w8sm2518079pbo.9.2013.04.26.01.48.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 01:48:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_16383831-BADF-461D-8322-FE67169D36E4" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: nov matake In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676D2022@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 26 Apr 2013 17:48:40 +0900 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943676D2022@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: "jose@ietf.org" Subject: Re: [jose] Draft -10 of the JOSE Specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 08:48:41 -0000 --Apple-Mail=_16383831-BADF-461D-8322-FE67169D36E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, The 2nd recipient described in Section 7.1 uses RSA-OAEP for key = encryption, but the encrypted key value seems to be encrypted using = A128KW. Isn't it? On Apr 26, 2013, at 5:24 PM, Mike Jones = wrote: > Based upon working group feedback on the -09 drafts, I=E2=80=99ve = released an update to the JSON Object Signing and Encryption (JOSE) = specifications that changes the processing rules for JWEs encrypted to = multiple recipients. The new processing rules enable using AES GCM for = multiple-recipient JWE objects. This update makes no changes to the = single-recipient case. > =20 > The updated specification versions are: > =C2=B7 = http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-10 > =C2=B7 = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-10 > =C2=B7 = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-10 > =C2=B7 = http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10 > =20 > HTML formatted versions are also available at: > =C2=B7 = http://self-issued.info/docs/draft-ietf-jose-json-web-signature-10.html > =C2=B7 = http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-10.html > =C2=B7 = http://self-issued.info/docs/draft-ietf-jose-json-web-key-10.html > =C2=B7 = http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-10.html > =20 > -- Mike > =20 > P.S. Also posted at http://self-issued.info/?p=3D1012. > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_16383831-BADF-461D-8322-FE67169D36E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Mike,

The 2nd recipient described in Section 7.1 = uses RSA-OAEP for key encryption, but the encrypted key value seems = to be encrypted using A128KW.
Isn't it?

On Apr = 26, 2013, at 5:24 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Based upon working group feedback on = the -09 drafts, I=E2=80=99ve released an update to the JSON Object = Signing and Encryption (JOSE) specifications that changes the processing = rules for JWEs encrypted to multiple recipients.  The new = processing rules enable using AES GCM for multiple-recipient JWE = objects.  This update makes no changes to the single-recipient = case.
=C2=B7 =C2=B7 =C2=B7 =C2=B7 =C2=B7                 =C2=B7   Subject: Re: [jose] Draft -10 of the JOSE Specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 09:02:08 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676D5286TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T29wcyDigJMgdGhlIEVuY29kZWQgSldFIEhlYWRlciB2YWx1ZSBmb3IgdGhlIHNlY29uZCByZWNp cGllbnQgaXMgY29ycmVjdCDigJMgZGVjb2RpbmcgdG8geyJhbGciOiJBMTI4S1ciLCJlbmMiOiJB MTI4Q0JDLUhTMjU2In0uICBCdXQgSeKAmWQgZmFpbGVkIHRvIHVwZGF0ZSB0aGUgdW5lbmNvZGVk IGhlYWRlciB0ZXh0IHdoZW4gSSB1cGRhdGVkIHRoZSBleGFtcGxlLiAgVGhhbmtzIGZvciBwb2lu dGluZyB0aGlzIG91dCwgTm92LiAgSeKAmWxsIHB1dCBpdCBpbiBteSB0by1kbyBsaXN0Lg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCkZyb206IG5vdiBtYXRha2UgW21haWx0bzptYXRha2VAZ21haWwuY29tXQ0K U2VudDogRnJpZGF5LCBBcHJpbCAyNiwgMjAxMyAxOjQ5IEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6 IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbam9zZV0gRHJhZnQgLTEwIG9mIHRoZSBKT1NF IFNwZWNpZmljYXRpb25zDQoNCkhpIE1pa2UsDQoNClRoZSAybmQgcmVjaXBpZW50IGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDcuMSB1c2VzIFJTQS1PQUVQIGZvciBrZXkgZW5jcnlwdGlvbiwgYnV0IHRo ZSBlbmNyeXB0ZWQga2V5IHZhbHVlIHNlZW1zIHRvIGJlIGVuY3J5cHRlZCB1c2luZyBBMTI4S1cu DQpJc24ndCBpdD8NCg0KT24gQXByIDI2LCAyMDEzLCBhdCA1OjI0IFBNLCBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KDQoNCkJhc2VkIHVwb24gd29ya2luZyBncm91cCBmZWVkYmFjayBvbiB0 aGUgLTA5IGRyYWZ0cywgSeKAmXZlIHJlbGVhc2VkIGFuIHVwZGF0ZSB0byB0aGUgSlNPTiBPYmpl Y3QgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoSk9TRSkgc3BlY2lmaWNhdGlvbnMgdGhhdCBjaGFu Z2VzIHRoZSBwcm9jZXNzaW5nIHJ1bGVzIGZvciBKV0VzIGVuY3J5cHRlZCB0byBtdWx0aXBsZSBy ZWNpcGllbnRzLiAgVGhlIG5ldyBwcm9jZXNzaW5nIHJ1bGVzIGVuYWJsZSB1c2luZyBBRVMgR0NN IGZvciBtdWx0aXBsZS1yZWNpcGllbnQgSldFIG9iamVjdHMuICBUaGlzIHVwZGF0ZSBtYWtlcyBu byBjaGFuZ2VzIHRvIHRoZSBzaW5nbGUtcmVjaXBpZW50IGNhc2UuDQoNClRoZSB1cGRhdGVkIHNw ZWNpZmljYXRpb24gdmVyc2lvbnMgYXJlOg0K4oCiICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTEwDQrigKIgICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNy eXB0aW9uLTEwDQrigKIgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1rZXktMTANCuKAoiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMTANCg0KSFRNTCBmb3Jt YXR0ZWQgdmVyc2lvbnMgYXJlIGFsc28gYXZhaWxhYmxlIGF0Og0K4oCiICAgICAgICBodHRwOi8v c2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUt MTAuaHRtbA0K4oCiICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTEwLmh0bWwNCuKAoiAgICAgICAgaHR0cDovL3Nl bGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTEwLmh0bWwN CuKAoiAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItYWxnb3JpdGhtcy0xMC5odG1sDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgQWxzbyBw b3N0ZWQgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTAxMi4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpq b3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_4E1F6AAD24975D4BA5B1680429673943676D5286TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly8yMTk5LyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9vcHMg4oCTIHRoZSBFbmNvZGVk IEpXRSBIZWFkZXIgdmFsdWUgZm9yIHRoZSBzZWNvbmQgcmVjaXBpZW50IGlzIGNvcnJlY3Qg4oCT IGRlY29kaW5nIHRvIHsmcXVvdDthbGcmcXVvdDs6JnF1b3Q7QTEyOEtXJnF1b3Q7LCZxdW90O2Vu YyZxdW90OzomcXVvdDtBMTI4Q0JDLUhTMjU2JnF1b3Q7fS4mbmJzcDsgQnV0IEnigJlkIGZhaWxl ZCB0byB1cGRhdGUgdGhlDQogdW5lbmNvZGVkIGhlYWRlciB0ZXh0IHdoZW4gSSB1cGRhdGVkIHRo ZSBleGFtcGxlLiZuYnNwOyBUaGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0LCBOb3YuJm5ic3A7 IEnigJlsbCBwdXQgaXQgaW4gbXkgdG8tZG8gbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbm92IG1hdGFrZSBbbWFpbHRvOm1hdGFrZUBnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAyNiwgMjAxMyAxOjQ5IEFN PGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBqb3NlQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gRHJhZnQgLTEwIG9mIHRoZSBKT1NFIFNw ZWNpZmljYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIE1pa2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIDJuZCByZWNpcGllbnQgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4xIHVzZXMg UlNBLU9BRVAgZm9yIGtleSBlbmNyeXB0aW9uLCZuYnNwO2J1dCB0aGUgZW5jcnlwdGVkIGtleSB2 YWx1ZSBzZWVtcyB0byBiZSBlbmNyeXB0ZWQgdXNpbmcgQTEyOEtXLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzbid0IGl0PzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMjYsIDIwMTMsIGF0IDU6MjQgUE0sIE1p a2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i Pk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEyLjc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmFzZWQgdXBvbiB3b3JraW5n IGdyb3VwIGZlZWRiYWNrIG9uIHRoZSAtMDkgZHJhZnRzLCBJ4oCZdmUgcmVsZWFzZWQgYW4gdXBk YXRlIHRvIHRoZSBKU09OIE9iamVjdCBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChKT1NFKSBzcGVj aWZpY2F0aW9ucyB0aGF0DQogY2hhbmdlcyB0aGUgcHJvY2Vzc2luZyBydWxlcyBmb3IgSldFcyBl bmNyeXB0ZWQgdG8gbXVsdGlwbGUgcmVjaXBpZW50cy4mbmJzcDsgVGhlIG5ldyBwcm9jZXNzaW5n IHJ1bGVzIGVuYWJsZSB1c2luZyBBRVMgR0NNIGZvciBtdWx0aXBsZS1yZWNpcGllbnQgSldFIG9i amVjdHMuJm5ic3A7IFRoaXMgdXBkYXRlIG1ha2VzIG5vIGNoYW5nZXMgdG8gdGhlIHNpbmdsZS1y ZWNpcGllbnQgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuNzVwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuNzVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgdXBkYXRlZCBzcGVjaWZpY2F0aW9uIHZlcnNp b25zIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjtsaW5lLWhlaWdodDoxMi43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTEwIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2ln bmF0dXJlLTEwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjtsaW5lLWhlaWdodDoxMi43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0xMCI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3Nl LWpzb24td2ViLWVuY3J5cHRpb24tMTA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMTAiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1rZXktMTA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTEw Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0xMDwvc3Bhbj48L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SFRNTCBmb3JtYXR0ZWQgdmVyc2lvbnMgYXJlIGFsc28gYXZhaWxhYmxlIGF0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0 OjEyLjc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxh IGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24t d2ViLXNpZ25hdHVyZS0xMC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8v c2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUt MTAuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6MTIuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8v ZG9jcy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0xMC5odG1sIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTEwLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjEy Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+ wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhy ZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2Vi LWtleS0xMC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMTAuaHRtbDwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bGluZS1oZWlnaHQ6MTIuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRm LWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0xMC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdl Yi1hbGdvcml0aG1zLTEwLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi43 NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMi43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjc1cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+UC5TLiZuYnNwOyBBbHNvIHBvc3RlZCBhdDxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby8/cD0xMDEyIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby8/cD0xMDEyPC9zcGFuPjwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEy Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qb3NlQGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2Ui PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B1680429673943676D5286TK5EX14MBXC283r_-- From ietf@augustcellars.com Fri Apr 26 15:01:55 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AAE21F99AD for ; Fri, 26 Apr 2013 15:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-ePq0OXv1SD for ; Fri, 26 Apr 2013 15:01:53 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 683FD21F99AA for ; Fri, 26 Apr 2013 15:01:53 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id BA8CF38EA5 for ; Fri, 26 Apr 2013 15:01:51 -0700 (PDT) From: "Jim Schaad" To: References: <1897900238.6466.1366828777317.JavaMail.nobody@jva2tc003.webex.com> In-Reply-To: <1897900238.6466.1366828777317.JavaMail.nobody@jva2tc003.webex.com> Date: Fri, 26 Apr 2013 15:01:07 -0700 Message-ID: <02d301ce42c9$8e4e7810$aaeb6830$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D4_01CE428E.E1F174D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0GQmyYzLBDfWHor9Ih2Ig1svDzZidYOEQ Content-Language: en-us Subject: [jose] FW: Meeting invitation: JOSE WG Interim X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 22:01:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D4_01CE428E.E1F174D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 The Interim meeting will have a web ex bridge for use. =20 Here are the detais. =20 Jim =20 From: Cindy Morgan [mailto:messenger@webex.com]=20 Sent: Wednesday, April 24, 2013 11:40 AM To: ietf@augustcellars.com Subject: Meeting invitation: JOSE WG Interim =20 Hello ,=20 Cindy Morgan invites you to attend this online meeting.=20 Topic: JOSE WG Interim=20 Date: Every 1 day, from Monday, April 29, 2013 to Tuesday, April 30, = 2013=20 Time: 9:00 am, Mountain Daylight Time (Denver, GMT-06:00)=20 Meeting Number: 642 526 666=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://ietf.webex.com/ietf/j.php?ED=3D178670557 = &UID=3D1375177062&PW=3DNNTlmZDE2MmI3&RT=3DMiM2=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 https://ietf.webex.com/ietf/j.php?ED=3D178670557 = &UID=3D1375177062&PW=3DNNTlmZDE2MmI3&ORT=3DMiM2 = -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 Call-in toll number (US/Canada): 1-650-479-3208=20 Access code:642 526 666=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://ietf.webex.com/ietf/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 cmorgan@amsl.com=20 1-510-492-4085=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 https://ietf.webex.com/ietf/j.php?ED=3D178670557 = = &UID=3D1375177062&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAiFyKP0o76vJ9m= F5/1q5nWS/C2cYPFGJGKW5ePqVZIkx&RT=3DMiM2=20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 CCP:+16504793208x642526666#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 ------=_NextPart_000_02D4_01CE428E.E1F174D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

<chair>

 

The Interim meeting will have a web ex bridge for = use.

 

Here are the detais.

 

Jim

 

From:= = Cindy Morgan [mailto:messenger@webex.com]
Sent: Wednesday, = April 24, 2013 11:40 AM
To: = ietf@augustcellars.com
Subject: Meeting invitation: JOSE WG = Interim

 


Hello , =

Cindy Morgan invites you to attend this online meeting. =

Topic: JOSE WG Interim
Date: Every 1 day, from Monday, April = 29, 2013 to Tuesday, April 30, 2013
Time: 9:00 am, Mountain Daylight = Time (Denver, GMT-06:00)
Meeting Number: 642 526 666
Meeting = Password: 1234 =


------------------------------------------------------- =
To join the online meeting (Now from mobile devices!) =
-------------------------------------------------------
1. Go to = https://ietf.webex.com/ietf/j.php?ED=3D178670557&UI= D=3D1375177062&PW=3DNNTlmZDE2MmI3&RT=3DMiM2
2. If = requested, enter your name and email address.
3. If a password is = required, enter the meeting password: 1234
4. Click = "Join".

To view in other time zones or languages, = please click the link:
https://ietf.webex.com/ietf/j.php?ED=3D178670557&UI= D=3D1375177062&PW=3DNNTlmZDE2MmI3&ORT=3DMiM2 =

-------------------------------------------------------
To = join the audio conference only =
-------------------------------------------------------
Call-in = toll number (US/Canada): 1-650-479-3208

Access code:642 526 666 =

-------------------------------------------------------
For = assistance
------------------------------------------------------- =
1. Go to https://ietf.webex.com/ietf/mc
2. On the left = navigation bar, click "Support".

You can contact me = at:
cmorgan@amsl.com =
1-510-492-4085

To add this meeting to your calendar program = (for example Microsoft Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=3D178670557&UI= D=3D1375177062&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DA= AAAAiFyKP0o76vJ9mF5/1q5nWS/C2cYPFGJGKW5ePqVZIkx&RT=3DMiM2 =

The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going to https://ietf.web= ex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of = WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com =

CCP:+16504793208x642526666#

IMPORTANT NOTICE: This WebEx = service includes a feature that allows audio and any documents and other = materials exchanged or viewed during the session to be recorded. By = joining this session, you automatically consent to such recordings. If = you do not consent to the recording, discuss your concerns with the = meeting host prior to the start of the recording or do not join the = session. Please note that any such recordings may be subject to = discovery in the event of litigation. =

------=_NextPart_000_02D4_01CE428E.E1F174D0-- From rlb@ipv.sx Sat Apr 27 11:40:28 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB75B21F98AF for ; Sat, 27 Apr 2013 11:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w163HJJUiqNG for ; Sat, 27 Apr 2013 11:40:28 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id E8A3C21F982B for ; Sat, 27 Apr 2013 11:40:27 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so4948253oah.21 for ; Sat, 27 Apr 2013 11:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OVm35ptxs6rKp88070TWEV7FpDaCPXWVXGNR0eDt2gE=; b=ZPe55lXesiZfR5MtYvtIRuovNTdGU2o/KKac2XnjseP2uN2ySL1zI7ux4h0NpgQ/2e /YW+GG34AmvWorWu9r3k+dNQpisebKQvPClFaw7sLSwoCj9jfSXPLylfaiSWpmg+rc2a sfUnzAHEFHj30gCqxx6iecKaIVxOas3FAe9VykLyDVvJzhlxgk1v2Ul568fYcszj/zkb lZvitGuUmd0wHhENQfPapnJW3NrLFFjkFRMQMFQGij6n9Qxh8ZbP6UjSgL3N7MRVZVqp BDJvAyna3eIwDoLPOlohFECX5BHLfW1p0jZ2vK02/7Wg8IuBkBstL+ppQGLsFwOQCIkQ xxLw== MIME-Version: 1.0 X-Received: by 10.60.63.73 with SMTP id e9mr20856362oes.87.1367088027474; Sat, 27 Apr 2013 11:40:27 -0700 (PDT) Received: by 10.60.20.99 with HTTP; Sat, 27 Apr 2013 11:40:27 -0700 (PDT) X-Originating-IP: [128.89.253.157] In-Reply-To: <02e701ce3a40$485326d0$d8f97470$@augustcellars.com> References: <02e701ce3a40$485326d0$d8f97470$@augustcellars.com> Date: Sat, 27 Apr 2013 14:40:27 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11c21d1a41720a04db5bfc82 X-Gm-Message-State: ALoCoQn55wbw707QE8ubErjhB1kC84rqJdyySO+z+V+hhlQwXic3rpp3rXdSX3t0VSHMTnoI9LXl Cc: "jose@ietf.org" Subject: Re: [jose] Preliminary Agenda for Interim Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:40:28 -0000 --001a11c21d1a41720a04db5bfc82 Content-Type: text/plain; charset=ISO-8859-1 Dear chairs, As I suggested earlier, I think we should organize this meeting around the few big questions we need to get resolved, from which the answers to individual issues will follow. So I would like to propose that we re-organize the agenda in the following way: 1. Mon. AM: Which fields are required / how to handle pre-negotiation? 2. Mon. PM: How should header parameter integrity protection be done? 3. Tue. AM: How should we do key wrapping, for JWE, JWS, and beyond? 4. Tue. PM: Review / close issues and wrap up Also, Based on some side discussions, I've put together some slides that try to summarize the state of the art and proposals for (2). < https://docs.google.com/presentation/d/1HlBYEiwBFYUBA5751Q8U1GXD-W0cgdCZwpVMRdUkK2c/edit?usp=sharing > Thanks, --Richard On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad wrote: > The chairs have posted their first cut at an agenda for the Interim > meeting.**** > > ** ** > > It can be found at > http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-interim-2013-jose-1 > **** > > ** ** > > ** ** > > Jim**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a11c21d1a41720a04db5bfc82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear chairs,

As I suggested= earlier, I think we should organize this meeting around the few big questi= ons we need to get resolved, from which the answers to individual issues wi= ll follow. =A0So I would like to propose that we re-organize the agenda in = the following way:

1. Mon. AM: Which fields are required / how= to handle pre-negotiation? =A0
2. Mon. PM: How should head= er parameter integrity protection be done?
3. Tue. AM: How = should we do key wrapping, for JWE, JWS, and beyond?
4. Tue. PM: Review / close issues and wrap up
= =A0
Also, Based on some side discussions, I've put = together some slides that try to summarize the state of the art and proposa= ls for (2).

Thanks,
--Richard



On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad <ietf@augustcellars.c= om> wrote:

The chairs have posted their first cut a= t an agenda for the Interim meeting.

=A0

It can b= e found at http://www.ietf.org= /proceedings/interim/2013/04/29/jose/agenda/agenda-interim-2013-jose-1<= span class=3D"HOEnZb"><= /p>

=A0

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--001a11c21d1a41720a04db5bfc82-- From Michael.Jones@microsoft.com Sat Apr 27 12:54:51 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681B21F96FC for ; Sat, 27 Apr 2013 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pedDSByW9UGi for ; Sat, 27 Apr 2013 12:54:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD1521F938F for ; Sat, 27 Apr 2013 12:54:39 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.204) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sat, 27 Apr 2013 19:54:36 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sat, 27 Apr 2013 19:54:36 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Sat, 27 Apr 2013 19:53:42 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Collated Responses to April 11, 2013 JOSE Questions Thread-Index: Ac5DgORZorsI2XDhSICr+YZkdP+YQA== Date: Sat, 27 Apr 2013 19:53:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676E89C3@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(51414002)(189002)(69226001)(44976003)(81542001)(79102001)(512954001)(31966008)(54316002)(55846006)(77982001)(74502001)(15202345002)(66066001)(49866001)(16406001)(76482001)(54356001)(47446002)(63696002)(46102001)(74662001)(59766001)(564824004)(71186001)(56776001)(47736001)(20776003)(56816002)(80022001)(16236675002)(561944001)(50986001)(4396001)(65816001)(53806001)(81342001)(74366001)(33656001)(47976001)(51856001)(6806003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB027; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08296C9B35 Subject: [jose] Collated Responses to April 11, 2013 JOSE Questions X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 19:54:51 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So that it will be easy for us to use to the data gathered in response to q= uestions that Karen sent to the working group on April 11, 2013 during the = interim meeting next week, I took a stab at collating all the responses and= extracting the additional proposals and comments made. What follows is a = reporting of the data from the responses sent - with no conclusions drawn. If any of you believe that I incorrectly or incompletely captured your resp= onses, please reply and I'll correct the spreadsheet accordingly, ideally i= n time for the working group meetings on Monday and Tuesday. I'll look forward to seeing many of you next week! -- Mike Collated Responses to April 11, 2013 JOSE Questions #7 - Alg IDs Tally Response 17 1. Continue have the JWA algorithm identifiers be strings, and not objects= . 1 2. Switch to using the algorithm identifier structures defined in the WebC= rypto draft. 0 3. Another resolution (please specify in detail). 0 0. I need more information to decide. #8 - spi 14 1. Have draft-barnes-jose-spi remain a separate specification that could o= ptionally also be supported by JWS and JWE implementations. 0.5 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s a mandatory feature. 1.5 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications a= s an optional feature. 1 4. Another resolution (please specify in detail). 0 0. I need more information to decide. #11 - 5116 14 1. Continue having separate Ciphertext, Initialization Vector, and Integri= ty Value values in the JWE representation. 3 2. Switch to using the RFC 5116 (AEAD) serialization to represent the comb= ination of these three values. 1 3. Another resolution (please specify in detail). 0 0. I need more information to decide. #12 - x5c 9 1. Retain the "x5c" header parameter in JWE. 3 2. Remove the "x5c" header parameter (and possibly other related key speci= fication parameters) from JWE. 0 3. Another resolution (please specify in detail). 0 0. I need more information to decide. 2 Don't care #15 - Key ID 19 1. Yes - Use cases where key information is exchanged by means other than = the JWS or JWE headers are important. 0 2. No - Use cases where key information is exchanged by means other than t= he JWS or JWE headers are not important. 0 0. I need more information to decide. 1 Other Individual Responses #7 - Alg IDs #8 - spi #11 - 5116 #12 - x5c #15 - Key ID Dick Hardt 1 3 1 1A James Manger 1b 2b 1A Axel Nennker 1 1 1 1 1A Roland Hedberg 1 1 1 1 1 Hideki Nara 1 1 1 1 1 Mike Jones 1 1 1 1 1 Richard Barnes 2b 2 or 3 3 Don't care Other Nov Matake 1 1 1 Don't care 1 Anthony Nadalin 1 1 1 1 1 Matias Woloski 1 1 1 1 Breno de Medeiros 1 Edmund Jay 1 1 1 1 1 John Bradley 1 1 1 1 Matt Miller 1 2 1* Justin Richer 2 Charles Marais 1 1 1 1 1 Sascha Preibisch 1 1 1 Javier Rojas Blum 1 1 1 2 1 Nat Sakimura 1 1 1 Vladimir Dzhuvinov 1 1 1 0 1* Russ Housley 4 2 Michael Peck 2 Salvatore D'Agostino 1 1 1 1 Additional Proposals and Comments #7 - Alg IDs Richard Barnes 2b - Switch to a structure more like the WebCrypto structure, in which algo= rithm parameters are collected alongside the algorithm name #8 - spi James Manger 1b - Have "spi" as a separate (optional) spec. Change its definition so it= does not change the crypto. Russ Housley 4 - Combination of 1 and 2. The field needs to be in the base specificatio= ns, but the only rule that needs to be included in the base specification i= s an exact match of the identifier. #11 - 5116 James Manger 2b - Switch to using RFC 5116. A JWE should have separate nonce and cipher= text fields (but no separate integrity value field). Richard Barnes 3 - RFC 5116 doesn't do anything with IVs, and all libraries I know of have= a separate IV and cipher text fields. So we let's keep those separate. John Bradley 1 ish - in favour of the current serialization while wanting to support the= crypto from draft-mcgrew-aead-aes-cbc-hmac-sha2 #12 - x5c Matt Miller I personally would rather limit key indication to a JWK (and wrapping "x5c"= in a JWK), or a reference to a JWK ("kid", and maybe "jku") #15 - Key ID Dick Hardt 1A - a key indicator SHOULD be included. (not a MUST) James Manger 1A - A key indication SHOULD be included (and certainly must be present in = all the examples in the spec) Axel Nennker 1A - A key indicator SHOULD be included but can be omitted because use cas= es where key information is exchanged by means other than the JWS or JWE he= aders are important. Richard Barnes Other - there needs to be a "pre-negotiated mode" in which headers are not = mandatory in addition to the "stand-alone mode" where everything needs to b= e expressed in the headers Matt Miller 1* - while I do think that key information exchanges outside of the JWE/JWS= headers are important, I do think a reference to the resultant key is mand= atory Vladimir Dzhuvinov 1* - No key indicator should be mandatory. The app / higher-level protocols= should decide on that. --_000_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So that it will be easy for us to use to the data ga= thered in response to questions that Karen sent to the working group on Apr= il 11, 2013 during the interim meeting next week, I took a stab at collatin= g all the responses and extracting the additional proposals and comments made.  What follows is a report= ing of the data from the responses sent – with no conclusions drawn.<= o:p>

 

If any of you believe that I incorrectly or incomple= tely captured your responses, please reply and I’ll correct the sprea= dsheet accordingly, ideally in time for the working group meetings on Monda= y and Tuesday.

 

I’ll look forward to seeing many of you next w= eek!

 

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

 

Coll= ated Responses to April 11, 2013 JOSE Questions

#7 - Alg IDs

Tally

Response

17

1.  Continue have t= he JWA algorithm identifiers be strings, and not objects.=

1

2.  Switch to using= the algorithm identifier structures defined in the WebCrypto draft.

0

3.  Another resolut= ion (please specify in detail).

0

0.  I need more inf= ormation to decide.

#8 - spi

14

1.  Have draft-barn= es-jose-spi remain a separate specification that could optionally also be s= upported by JWS and JWE implementations.

0.5

2.  Incorporate dra= ft-barnes-jose-spi into the JWS and JWE specifications as a mandatory featu= re.

1.5

3.  Incorporate dra= ft-barnes-jose-spi into the JWS and JWE specifications as an optional featu= re.

1

4.  Another resolut= ion (please specify in detail).

0

0.  I need more inf= ormation to decide.

#11 - 5116

14

1.  Continue having= separate Ciphertext, Initialization Vector, and Integrity Value values in = the JWE representation.

3

2.  Switch to using= the RFC 5116 (AEAD) serialization to represent the combination of these th= ree values.

1

3.  Another resolut= ion (please specify in detail).

0

0.  I need more inf= ormation to decide.

#12 - x5c

9

1.  Retain the R= 20;x5c” header parameter in JWE.

3

2.  Remove the R= 20;x5c” header parameter (and possibly other related key specificatio= n parameters) from JWE.

0

3.  Another resolut= ion (please specify in detail).

0

0.  I need more inf= ormation to decide.

2

Don't care

#15 - Key ID

19

1.  Yes - Use cases= where key information is exchanged by means other than the JWS or JWE head= ers are important.

0

2.  No - Use cases = where key information is exchanged by means other than the JWS or JWE heade= rs are not important.

0

0.  I need more inf= ormation to decide.

1

Other<= /p>

Indi= vidual Responses

#7 - Alg IDs

#8 - spi

#11 - 5116

#12 - x5c

#15 - Key ID

Dick Hardt

1

3

1

1A

James Manger<= /span>

1b

2b

1A

Axel Nennker<= /span>

1

1

1

1

1A

Roland Hedberg

1

1

1

1

1

Hideki Nara

1

1

1

1

1

Mike Jones

1

1

1

1

1

Richard Barnes

2b

2 or 3

3

Don't care

Other

Nov Matake

1

1

1

Don't care

1

Anthony Nadalin

1

1

1

1

1

Matias Woloski

1

1

1

1

Breno de Medeiros

1

Edmund Jay

1

1

1

1

1

John Bradley<= /span>

1

1

1

1

Matt Miller

1

2

1*

Justin Richer=

2

Charles Marais

1

1

1

1

1

Sascha Preibisch

1

1

1

Javier Rojas Blum

1

1

1

2

1

Nat Sakimura<= /span>

1

1

1

Vladimir Dzhuvinov<= /o:p>

1

1

1

0

1*

Russ Housley<= /span>

4

2

Michael Peck<= /span>

2

Salvatore D'Agostino

1

1

1

1

Addi= tional Proposals and Comments

#7 - Alg IDs

Richard Barnes

2b - Switch to a structu= re more like the WebCrypto structure, in which algorithm parameters are col= lected alongside the algorithm name

#8 - spi

James Manger<= /span>

1b - Have “spiR= 21; as a separate (optional) spec.  Change its definition so it does n= ot change the crypto.

Russ Housley<= /span>

4 - Combination of 1 and= 2.  The field needs to be in the base specifications, but the only ru= le that needs to be included in the base specification is an exact match of= the identifier.

#11 - 5116

James Manger<= /span>

2b - Switch to using RFC= 5116.  A JWE should have separate nonce and ciphertext fields (but no= separate integrity value field).

Richard Barnes

3 - RFC 5116 doesn't do = anything with IVs, and all libraries I know of have a separate IV and ciphe= r text fields.  So we let's keep those separate.

John Bradley<= /span>

1 ish - in favour of the= current serialization while wanting to support the crypto from  draft= -mcgrew-aead-aes-cbc-hmac-sha2

#12 - x5c

Matt Miller

I personally would rathe= r limit key indication to a JWK (and wrapping "x5c" in a JWK), or= a reference to a JWK ("kid", and maybe "jku")

#15 - Key ID

Dick Hardt

1A -  a key indicat= or SHOULD be included. (not a MUST)

James Manger<= /span>

1A - A key indication SH= OULD be included (and certainly must be present in all the examples in the = spec)

Axel Nennker<= /span>

1A - A key indicator SHO= ULD  be included but can be omitted because use cases where key inform= ation is exchanged by means other than the JWS or JWE headers are important= .

Richard Barnes

Other - there needs to b= e a "pre-negotiated mode" in which headers are not mandatory in a= ddition to the "stand-alone mode" where everything needs to be ex= pressed in the headers

Matt Miller

1* - while I do think th= at key information exchanges outside of the JWE/JWS headers are important, = I do think a reference to the resultant key is mandatory<= /p>

Vladimir Dzhuvinov<= /o:p>

1* - No key indicator sh= ould be mandatory. The app / higher-level protocols should decide on that.<= o:p>

 

--_000_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Responses to April 11, 2013 JOSE Questions.xlsx" Content-Description: Responses to April 11, 2013 JOSE Questions.xlsx Content-Disposition: attachment; filename="Responses to April 11, 2013 JOSE Questions.xlsx"; size=15444; creation-date="Sat, 27 Apr 2013 01:54:02 GMT"; modification-date="Sat, 27 Apr 2013 19:51:15 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBBN4LPcgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtEvQDTDwkFo5teQYKf99JeKhCPBSVTaLYnnvudTwejNa1 TVYQ0XiXi37WEwm4wmvjylx8Tz/SZ5EgKaeV9Q5ysQEUo+H93WC6CYAJVzvMRUUUXqTEooJaYeYD OJ6Z+1gr4s9YyqCKhSpBPvZ6T7LwjsBRSo2GGA7eYK6WlpL3NQ9vncyME8nrdl2DyoUKwZpCERuV K6ePIKmfz00B2hfLmqUzDBGUxgqAapuFaJgYJ0DEwVDIk8wIFrtBd6kyrmyNYWUCPnD0M4Rm5nyq Xd0X/45oNCRjFelT1Zxdrq388XEx836RXRbpujXtFmW1Mm7v+wK/XYyyffVvbKTJ1wpf8UF8xkC2 z/9baGWuAJE2FvDGabei18iViqAnxKe3vLmBv9qXfHBLjaMPyF0bofsu7FukqU4DC0EkA4cmOXXY DkRu+e7Ao4sAmjtFgz7Blu0dNvwFAAD//wMAUEsDBBQABgAIAAAAIQC1VTAj9QAAAEwCAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLPTsMwDMbvSLxD5PvqbkgIoaW7TEi7IVQewCTuH7WNoyRA9/aE A4JKY9vR9ufPP1ve7uZpVB8cYi9Ow7ooQbEzYnvXanitn1YPoGIiZ2kUxxqOHGFX3d5sX3iklJti 1/uosouLGrqU/CNiNB1PFAvx7HKlkTBRymFo0ZMZqGXclOU9hr8eUC081cFqCAd7B6o++jz5src0 TW94L+Z9YpdOjECeEzvLduVDZgupz9uomkLLSYMV85zTEcn7ImMDnibaXE/0/7Y4cSJLidBI4PM8 34pzQOvrgS6faKn4vc484qeE4U1k+GHBxQ9UXwAAAP//AwBQSwMEFAAGAAgAAAAhAIE+lJf0AAAA ugIAABoACAF4bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKySz0rEMBDG74LvEOZu064iIpvuRYS9an2AkEybsm0SMuOfvr2hotuFZb30 EvhmyPf9Mpnt7mscxAcm6oNXUBUlCPQm2N53Ct6a55sHEMTaWz0EjwomJNjV11fbFxw050vk+kgi u3hS4Jjjo5RkHI6aihDR504b0qg5y9TJqM1Bdyg3ZXkv09ID6hNPsbcK0t7egmimmJP/9w5t2xt8 CuZ9RM9nIiTxNOQHiEanDlnBjy4yI8jz8Zs14zmPBY/ps5TzWV1iqNZk+AzpQA6Rjxx/JZJz5yLM 3Zow5HRC+8opr9vyW5bl38nIk42rvwEAAP//AwBQSwMEFAAGAAgAAAAhAB8rvnlJAQAAFgIAAA8A AAB4bC93b3JrYm9vay54bWyMkU1PwzAMhu9I/Icod9avtRrV2kkIELsgJMZ2Do27RkuTKknp9u9x WpXBjZPj2Hni9/V6c24l+QJjhVYFjRYhJaAqzYU6FvRj93y3osQ6pjiTWkFBL2Dppry9WQ/anD61 PhEEKFvQxrkuDwJbNdAyu9AdKKzU2rTMYWqOge0MMG4bANfKIA7DLGiZUHQi5OY/DF3XooJHXfUt KDdBDEjmcHzbiM7Scl0LCftJEWFd98panPssKZHMuicuHPCCppjqAf5cmL576IXE6n0SJjQof0S+ GcKhZr10O5Q309GveBnHme/0VuwFDPb6yKfkfBCK66GgSYbWXuYsSjNKhrF0ENw1BY2T+Hr3AuLY OM9PVyuPD37xRwfxnzESNcp7965GuCoft6gAzyYXeDBbHo2E+VnFZIV6fBgbl2kWTx3zSstvAAAA //8DAFBLAwQUAAYACAAAACEAFs/b81sHAABTEgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1stFjN UiNHEr47Yt8ho/cw4EAIgWfs2GBwaGAmkGyYWcRA+FjqLqlrVF3VrqqWkE9+kN0IP4sfxU+yX1YL teiGvdi+END1k5lffvllFqffPxSaltJ5Zc3bZHB4lJA0qc2Umb9NPt9+6H2XkA/CZEJbI98ma+mT 78/+8dWp94Fw1vi3SR5C+a9+36e5LIQ/tKU0WJlZV4iAP92870snReZzKUOh+8dHR2/6hVAmodRW JsDu0UlClVE/V/K8/vLm2+Ts1Kuz03B2odIFXQqXhdN+ODvt89d65Z/fUo+Gek6jC99Z+w5rvlSd 74MBFl4PBm+6K8dYeXiddhdeY+EHuYad9tpg2P4yFoX0dCXMXLr22mDa/YKrL8VS0h+//gfu/vHr f0l4EuRlKZwIkvZsGZAcofcRjkwPic5zvpxU8JTJmTKK18lbfKHMwrixgdJ6U8glpW5dBnvYMT2E aVhaIDBlMpWKYB1NLj9+/vGCprjfpLrKZHZIe3yhoKvPk9v99i3HnZCOp7h3slIhzSlYqjy4RDcf ziPocH9I4/v35HNb6YxyDn0bq7EmlQS2UarKXLogHwLNlNSZp71pFRBZs1mZIOdOhTUtha5kvW// +TCHu1EyWt0waS/ahVEwU6+pqMBwwADqemkC4CChNTGg8kEUpQbQ+MZ/c146wAwfpKZracziGR4w 9E98apDfhZ445lQY/mYLFYLM8GsqKi+BKzIrPLxYASm5CbCuOo5QefhZswCHEI8UxpOFvw5O4072 fHw/IZjmhOSoUOgACdylitICBxM6aN5YzTBdymwq3bxNhkuVyYWiazC3vXSlFjAHDelU6o2Cly6j d8I9s3phzSvGwMn2jS2eoWSCq9JQwf/C4odmixzkvZyexxJodhxw6lY5LCOpcwsW5QVxwRUyPIKQ Wq1lypCz9s09YovXNQcMtre9urZLFH8Qi87K0ITcmjXQgZgq0z6IQwqVf2+19YuObL1zEtyHB1cy k8rZDoofObHtO485uSftr++zokIOx2LdXhnb3NA7JzItO2sDMCoHbQHcTCxt5cjOIh5p5eBcQGE6 hcB+QRygH8DVklbgEJc/dMBXJZOqPlKnY+ZsQZQ5MQu9Ip07ueoJsBA/fC+dpr28EGnP5+K47Sew CnSlkJ9OyGOULVxkUnUXR1QiuyymKPBVFCBoLFeEViivtkjAa4Ha+KGWhpUTZcnBJOgRCeMQF/cP GGRBTs5QhqxfzbFkobLkIApaIdZTScmXRZV0pOIc/Gc5uQIBVSezE4HOKuiTk2qq8GsbjLFYKkRw Y7+APu90VbQ3XItAE7FQRdUtyzstMoTu6OKXvFoqY5ft04Ovu19Ag2u7ixYQ2Ag6gix4XEAvWR/S LcoPqFGfcjUHzj0tl5DF0tlgUV/+8VQmUy4v8AbS1FWdwdewWDNqhBaHTcos4taO7D1qHqSuCrFm NzSFxvVZ7p7VuQPaubeVS5YQ9IBKsyDW9nwTYxucm8p7urSVf6aErljpEP4nmS7a5yZCLxk0SRev hnPLJLbtPbfM2/bHG+lLa3xHbgY8KVguP/TG2GY5kPH9cEfxgDk2oMFC95E4CCj47WvCGvR8O/0C BfSdLnCMu9sdnm9vpLG5uRHdzbgCQUXt8PZGmKMGdMyc8LQAP7hAkQGrqygte+i9aHyx7aoZDy8Q RnRt3W3+R7hhREbCZuwJyjQNEmVa065jl6GLM1ktTdPYmHpfrJc9jGhwhYdXlPx2buEBADBigmLp YwrzZIvx5nF2g9wIjQmNQa51kDv5OvZf7qfcgNF0tSyQkHjL86CPMJs7yCgPhs87h6mI66Nu7Y9X P/EPLZ4HzG2V0kwK7podGBj+v86g2YLxosFvDn//7U8mvM161uttms63QyXqncfmpl3dgefW1cwf bQfLuzhYxvFyO+xxqpws66kwpqoD3Evl8TgE097w/fAC8/yTjom8be+NGUxtMVWm5lQtYiB9yJ2U 9cTbpQhHf8OlUNcXnhRoVfykqEWvmXC4ZhDIs57fyMJiKGcO/Z8L4rRcWu/VFOR+rFENYmZRI59Q rjHs9yl2/ZeMo6306PPfONqyrL083jKAP6ET/70+vGz/G1g+f5r2QRwfmFK3yEh8DEVB8zxnQE82 uZ42irjRIeg4Px84j5YfNK7CQBa1ifWwOV6/8l6+h18SeC7g0ZMGqAY/6zYttRH5DpFGeFAuVVYJ DULWDaoz2AyzLD5dseeTs+ASJDIGCwRYBzsH4owLhBAS+uRuFIISVGTPyLlFVTMHC5vJOKTVU/5u 12cKNOrHSr5xhBFluJL4H49e/JfH5qL6jYXhxa15+Jg/sS4fWA48rG6SsbF22vp/xTleFNG5LSRs cVg6pWkwOKDjo8EJjT9O3tO/K4kJAG29fcUJwt/KCD/2+XWUYU41G7/w7s5pdLdp4vxi1WrqhFNg 9YgWxq44e3Ee2Glgo7sIfP3qpp1nN2g3sbTCa0qGVx6VLUtAhE64VdWd1PfxT6Gz/wEAAP//AwBQ SwMEFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54 bWwucmVsc4SPwYrCMBRF9wP+Q3h7k9aFDENTNyK4VecDYvraBtuXkPcU/XuzHGXA5eVwz+U2m/s8 qRtmDpEs1LoCheRjF2iw8HvaLb9BsTjq3BQJLTyQYdMuvpoDTk5KiceQWBULsYVRJP0Yw37E2bGO CamQPubZSYl5MMn5ixvQrKpqbfJfB7QvTrXvLOR9V4M6PVJZ/uyOfR88bqO/zkjyz4RJOZBgPqJI OchF7fKAYkHrd/aea30OBKZtzMvz9gkAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMA AAB4bC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhT okDSSX0b2uOAAcO6YZcBu+0wbCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqD iKFDIiTlcdurXa56iMQ+H9M4aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVK JZuVivRhGMvLPCExzE24iLCCVxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK 6gGfiYEmTZwVBjue1jRCzmWXCXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zS demC8XTN8BTBKGda69dbV3Zy+gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27 +AL99SWZW51Op9FKZbFEDcg+1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIa T5fQ2qH9fko9h0w42y2FbwB8o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaC Ys0AbxJcmLFDvlwa0ryQ9AVNVNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6O g+LCl99+9ufXH6M/nn7z8vEX5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4 kEZEolvkCB3wCHQzhnElJyNxvhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKm aAnnG2HkAPc4Zx0uSg1wQ/MqWHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQ mCik5/iUkBLt7lHq2HWP+oJLPlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpI SAjMSoQfEuaY8TqeKRyVkRziiBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7 HptHLlIoOi2jeRNzXkTu8Gk3xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7 NHBEWgSInpmJEl9eJ9yJ38GcTTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5bo HTyL9wlkxfIW9a5Cv6vQ3ltfoVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdB vc4cOkl+EEtCeNSZDAwcXCCwWYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/oc YiuHxGqPj+3wuh7Ojhs5GSNVYM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8Hk uWowmFsTOhsE/RBYuQnHfs0azjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrs eIrVCtxamuwbcDuLk4rs6ivYZd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGv S91MYhbAfZOvhA37U5PZZPnCm61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEK lFSjs0mxvgHB8K9JAXZ0XUsmE+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ ges5bW0z5RbnNOmKl2IGZ8cxS0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0Xv J3AFsT7WHvDhdlhgpDOl7XGhQg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUB DZCgsB+pUBCyD2XJRN8pxGrp3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9p Bo0C3eQU882pZPnea3Pgn+58bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0Er TfvXFOGcW62tWEsarzUy4cCLyxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYe SBdIOziCxskO2mDSpKxp09ZJWy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZ kykKQ5PsIGMcY76UFT9m8dF9cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQU AAYACAAAACEAtta/FsgCAACsCAAADQAAAHhsL3N0eWxlcy54bWzMVslu2zAQvRfoPxC8O1pip7Eh KajjGAiQFgWSAr3SEiUT4SKQVCql6L93SMmyg7Rp06DLxSKHw8eZx3kcJ2et4OiOasOUTHF0FGJE Za4KJqsUf7xZT04xMpbIgnAlaYo7avBZ9vpVYmzH6fWWUosAQpoUb62tF0Fg8i0VxBypmkpYKZUW xMJUV4GpNSWFcZsED+IwPAkEYRL3CAuR/wqIIPq2qSe5EjWxbMM4s53Hwkjki8tKKk02HEJtoynJ d9h+8ghesFwro0p7BHCBKkuW08dRzoN5AEhZUippDcpVI22KjwHanbC4leqzXLslIHDwyhJzj+4I B0uEgyzJFVcaWWAGAvMWSQTtPc4JZxvNnFtJBONdb46dwZM5+AkGqTlj4OLoo8mSjfP6F2f5+P5E Xj49A/kxzke2Y0csGLIEbt1SLdcwQcP4pquBVgkF2tPj/X7iXWnSRfHsYEPgDwRGlS5AELt7dlfa m7KE09IC35pVW/e1qobfjbIWqidLCkYqJQmHYbDbMQwgnZxyfu1E86l8gN2WSDZiLexlkWKQn7vc 3RASGYY9Xj9x+IdoPfYB7BxCfj4sassR/wW7Ealr3r3lrJKCOqE4AqHE+ynaKs3uIUWnjRzWaV/S bfnjkCMg5ftMjCH3hzoRuvP+gxDgjv4Oh64ksXvBLcsdp1CTvqafIjR+LqEvy+aJ3c++2iewficr ryNQzoE8H4hzlBly73WK37tuxuHlH6SCNg3jlslROHthAmbR7qUeuluxrjP5R2A8BRRf0JI03N6M iynej9/RgjUCchu8PrA7ZT1EivfjK/ciRSfuDNraKwPtAb6o0SzFXy6Wb+ari3U8OQ2Xp5PpMZ1N 5rPlajKbni9Xq/U8jMPzrweN8gVt0rdzKP1oujAcmqkekh2Cv97bUnww6cP3dQthw/O2SyIw49+M 7BsAAAD//wMAUEsDBBQABgAIAAAAIQDb2iMrVQ8AAHpWAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVl dDEueG1slJzJcuM4EobvEzHvoNB9bFOrS2G7Q1zAnVU9PctZJctVirYtj6Tq6n77SRAECORPUdLF YX+ZAJE/lkzSEh9++fPtdfDHZn/Y7t4fh97N3XCweV/vnrfv3x6H//6X+Mf9cHA4rt6fV6+7983j 8K/NYfjL09//9vBzt//98H2zOQ6oh/fD4/D78fixuL09rL9v3laHm93H5p0sL7v92+pIf+6/3R4+ 9pvVc93o7fV2dHc3u31bbd+HqofF/pI+di8v2/Um3K1/vG3ej6qT/eZ1daTxH75vPw66t7f1Jd29 rfa///j4x3r39kFdfN2+bo9/1Z0OB2/rRfrtfbdffX2luP/0Jqu17rv+A7p/2673u8Pu5XhD3d2q gWLMn24/3VJPTw/PW4pAyj7Yb14eh0tv8eu9N7x9eqgF+s928/Ng/T44rr7+tnndrI+bZ5qn4UDq /3W3+106poTuqMtD7SC7PPxPdxrVfd6aTp8e2t/1BUQ9SV/2g+fNy+rH6/Gfu5/JZvvt+5GuNLmZ UNgy+sXzX+HmsCbZ6Wo3YznU9e6V+qCfg7etXD6k2upPNbzt8/E7/XZ/M5/Px5PxfDocrH8cjru3 /zaWpr1qOWpaziiwxu71trxVl67DClfH1dPDfvdzQEuIxnD4WMkF6S08Gjr9Yi6t4qx96timN3S9 ztgoKNnZUvb2OKQ9QDEfSOE/nmbTh9s/SMR14+JrFymHbBNwEHJAU6J6pSa3NGwz9jEbe+/QpPPj kIQzQ/PYyJQH/TQeEzb4QLnMbZeZ20uoXXR8EQeCg5iDhIOUg4yDnIOCg5KDygKOrHIV2EuiT1Zf LZlJPdfe3NUiUEZaNK2izCXULkYuDgQHMQcJBykHGQc5BwUHJQeVBRy5aLtcLpd0fhw2cjG1lM1R 6951CbWLUYsDwUHMQcJBykHGQc5BwUHJQWUBRy0K73K1pLNW686VIlA2R61PrkuoXYxaHAgOYg4S DlIOMg5yDgoOSg4qCzhq0UlzuVrS+ZRaykaXMTtxygQNtYtRiwPBQcxBwkHKQcZBzkHBQclBZQFH LVl7XXpwLaWzmw9G7vLxlcekTrx1plJgZkDIQcSB4CDmIOEg5SDjIOeg4KDkoLKAI9mnaySTzlIy vUJ8BZrTbOLKFyijs+RYxg21i+4w4kBwEHOQcJBykHGQc1BwUHJQWcDRz6MbgIvXnF97my16w6uL xuxIxhZlaHyMZkAEkBhIAiQFkgHJgRRASiCVTVz1ZGV36Y71PVUHNssN1VNmR72xuybDpot2C0dA BJAYSAIkBZIByYEUQEoglU1c9aiYvUI96a3XHtuIgaeMjnZsP4fGp115upUmAnxiIAmQFEgGJAdS ACmBVDZxtZPF7+UrT5XKauWxvBl4yuhox3xC46OVioAIIDGQBEgKJAOSAymAlEAqm7jayUr4Uu2W zU0lLRVTerBd6TcuVqZtSLtPQyAREAEkBpIASYFkQHIgBZASSGUTV0FZHV+qoO+pWvpEmm2szvJj iSU0Pu3ys+rz+jZcgE8MJAGSAsmA5EAKICWQyiaueBTqFeJJb33ssYUXeMroaMfv541Pq51upYkA nxhIAiQFkgHJgRRASiCVTVztZOl8+cJThXaz8NxUGni6Cm/39YTfgBkfrVQERACJgSRAUiAZkBxI AaQEUtnE1U7W0JdrpyruEylDl+OtdnA75mmfVjtOBPjEQBIgKZAMSA6kAFICqWziaifr50u1W3qq 2rZTBitG/MalThnOlUbXFOTL2tu5pWmImje2noPG6JwX/IGW8THzBkQAiYEkQFIgGZAcSAGkBFLZ xFXzmgJ9OVIVuHWD2BClJj99G6OjJn/gZXxaNXWZr4kAnxhIAiQFkgHJgRRASiCVTVw1Zb188S4Y qeraVlOR7jOlcbfVhPPY+GjtIiACSAwkAZICyYDkQAogJZDKJq6aV5Xwo74SvjHa2sF5bHxa7XTh r4kAnxhIAiQFkgHJgRRASiCVTVztrinh/ZF69K3WHXsgETRGW7sRv/0xPlqpCIgAEgNJgKRAMiA5 kAJICaSyiavdNcX7cqQKbTuXsercb1ys25+GWLc/QCIgAkgMJAGSAsmA5EAKICWQyiaugrRYrjgH pbeboxVR69GDJK2s9NPccM5gQWqfdkFyIkacxEASICmQDEgOpABSAqls4sp5TVG/HKm63U4rdpnP lAoad1vNKVM8ND6tmvrmQBMBPjGQBEgKJAOSAymAlEAqm7hqyir70iTtj1RNfiIl64K9XYmYVrSP Vipqumw3vwASA0mApEAyIDmQAkgJpLKJq901Zb4/UmV+s43Z7WVjtNfdiN+aG59WO9WlrR0nMbRK gKRAMiA5kAJICaSyiaPd+JobF7/2lo81KHS3G16xX/jJjbEqq2k1tqcmS/W+8dF6B0BCIJFN3KHa BRxNdO/nDMaq2LLzKH+I3eHCIgg7XNhdSdThwm4+RYdLm9PdEO0660yIyzE5G/HZOexLI2VBT33Q gm0Wx8gCCh0j0ywyRj2lwpB2LO2+c4OzC6GzwZGzCY7dM/tjVSTVH71SHwoypG3Ebw07XDwIj3cs OlqdCo9CMongbHjkYMLz2ILxx7Krk5PXYwz7WkZ9RmGM7bhOBWrXD2cDJec20LbHetr8scr7J1Zp jzHsaxn1GcUJo7tUZZbVSf1siPYhyD/T5I9Vwj4RYo8x7GsZ9RnFCaMbop17z4ZIzu0ssp3lj1XO PBFijzHsaxn1GcUJoxPixE6R50KUzm2IrGT1667qTza2PuzwCDp8RuzkCo2P/KwjO3kjY2wHwm+N RZdPu6vc8O3UfjZ8cjahjVge9Ccq23fPcJ8x7DNGxmhdmiUyYXykYq3kbqTyQdel23Vi1wQjNge+ tJ48evuMYZ8x6jOKE0Y3xCuKn+WEnNvJ5NlFWk+HqI06wYd97lGfUZwwunFdU/FM7Ipn1NZQKplI ax2XHnoAJAQSARGG9K24a2qZiV3LjPjpKa2np6PHGPa1jPqM4oTRnRk6Mi7fVOTcrjg4PWVXp+qZ SY8x7DNGxqgnXBjSN3XXlC8Tu3wZt8dPs+J6KpRANnWWYwgkMkSOlx26whhbZcetsu5cXVOvTOx6 Zcyu6kurM+wASAgkMqQzEKtLd9h2DSI/P9J3S7ec2EXIGE61njojkE1PLcCwzxj1GcUJoxPj1C5C zsYovc0+GvMTru7r1D7qM4bGqLdKBEQY0rN5pnZNcT4au6gYt2WK2j11Xyej6ak4wr6WkWNkq1s4 xnY7uzNmVxPnY7TLiTGr9/xpXzlhjHpSQiCRIe6k1AqKE0Y3GpnQdW10PhrybtcfT1VTXRx0DCbo M4Z9xsgx8vrPGK1xnTgFp3YtcT5Uu5iYsIXi133JxannJjBEBs9On9Axsr4iY9R9CZu4s2XXFedD sAuLCS9lp7p20JcNgISGyKBg3LwDYdypS3fcdrFwftx2tTBhWvrTnoIg6DOGfcbIGLUcwhB3ObuB 2dXCucD8Kc/5AZAQSARE2MQdjp3o5XAufFw7VSmYfprdPYP1on20QIFppUkIJAIiGqK+GGl//256 Tbr3a293B+os3g6HkwhaCZs4Ws6uysy1t/sFkDZ/qITWuFhnBpAQSARE2MQd8VXZd2ZnX/5vT19a qSSyd+KIBRQYHyM4kAiIABIDSYCkQDIgOZACSGkTV7xr0ro/04lbhx4ACYFEQIRN3OFclZdnKvPa tQY7rf3GxV59Ol3rGELwiYAIm7gjviq9zuz0yssiaWSLr83p9WYKjEs7eN1Ikwh8BJAYSAIkBZLZ xBXBSdB03PfessycBA0zpvKrvQVnsAW1jw46lH3W2mkSARFAYiAJkBRIBiQHUgApgVRAPgP5AuRX m7iTICsEU9OemQR/pusJLVgAJAQSARE2cYfj1AhnhrOcSW83kfBM3LjYW1k1akkIPhEQYRN3xE4Z cXbEdtkAW1lVDfYi9thCD2baR89ACCQCIoDEQBIgKZAMSA6ksImrlFOznFWKvE2BhSlXVSu2VDN2 UxzMtE8rFScR+AggMZAESAokA5IDKYCUQCqbOHLOnZrrnJzS28g5YhnCr/tyK5gxu3sMjI+RE0gE RACJgSRAUiAZkBxIYRNXKqfYOyOVP1flXHtABEBCIBEQYRN3OE75dGY4y7kqn+x6hd/mNS72iFWj loTgEwERNnFH7FRYZ0dM3matwZPeuSql7K07Zqd2YHzataZbaRKBjwASA0mApEAyIDmQAkgJpLKJ K6dT/p2R05+rYq2dywBICCQCImziDkeWQZfWAEv5fhyWdPnD1cbFHrFq1JIQfCIgwibuiGUdcvmI 7bXGjjV/Lrtyjz6P+QTGRy++EEgERACJgSRAUiCZTVwVaOVcoQJ5m13JS4+57IqpAJtS+7QqcBKZ frSPABIDSYCkQDKbuCpcVYDN7QIMPi0krVwGtrgD46NDDIFEQASQGEgCJAWSAcmBFEBKIBWQz0C+ APnVJu4kyMrq8g1J3mYpQm0311Va6zNjGS8wPu0k6FaaROAjgMRAEiApkAxIDqQAUgKpgHwG8gXI rzZxJuH+qopQeptJgCxd9+UeCBN+Q218tOQhkAiIABIDSYCkQDIgOZACSAmkAvLZJq7ATh1J+vU+ saB35FkC838ASSs7aiY87xifVmDdSpMIfASQGEgCJAWS2UTJoN7Hp15i97bZf9sEm9fXw2C9+yHf tEefvXl6MFi9K9C/9xayIxout8zuF/JescMyv1vIWr7LMl7IqqrLMlvIRNll+bSQW6bLck+WzhHM Pi3kjVdHm/u7hVwfHZaZt5BPTLssk4V8CtZhmc9p1PMOSzC6X8gP+2ObYERjo4+yo4Xeyxh1XX85 JgN9FLyjxfR+If/rgBZ/Nl3Ih0ZoCUYjun79HRY2o8GIZoe+99bVZkKWLgWC0ZQs3deZkaVrRumL MWTpVM2j3ujtBR0j8Kg3+m5+l4V6o2+ed1loDuh71R2W0R2NoGsVBCOPLF1aBx5pQK+l6OiNZOtU jRp0+lOQnTFSiJ0RUoCd8dFC6lpHgUfR0YuDOkbqUXT0UpwuC60KeuVLl4XCo3+vdVhI3lrdW7OQ 6BWdH6tvm3K1/7Z9PwxeNy90rtzdUJm5Vy/5rH8/7j5qSvcUX3dHelGn/us7vbR1Qy+2lO/8HLzs dkf9B11c9vvb5vjjY7Dbb+nNoPV7WB+HH7v9cb/aHukKi+3z43CfPtfx3Zq3xj79HwAA//8DAFBL AwQUAAYACAAAACEAgLOciEYBAABlAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJRT8MgFIXfTfwPDe8tpXNTSdslavZgXGLijMY3Ancb WaEE0Lp/L2232mU++Mg9h49zbsjn36qKvsA6WesCkSRFEWheC6k3BXpdLeIbFDnPtGBVraFAe3Bo Xl5e5NxQXlt4trUB6yW4KJC0o9wUaOu9oRg7vgXFXBIcOojr2irmw9FusGF8xzaAszSdYQWeCeYZ boGxGYjogBR8QJpPW3UAwTFUoEB7h0lC8K/Xg1XuzwudMnIq6fcmdDrEHbMF78XB/e3kYGyaJmkm XYyQn+D35dNLVzWWut0VB1TmglNugfnalku5g+gxrM/leDRuV1gx55dh22sJ4m5/4jxXA7Or0INB RCEU7SsclbfJ/cNqgcosJZM4vYqz61Wa0umMZrOP9vGT+23IfqAOEf5HJLd0SiiZjohHQJnjs49R /gAAAP//AwBQSwMEFAAGAAgAAAAhAB7WSxxBBwAA9B4AACcAAAB4bC9wcmludGVyU2V0dGluZ3Mv cHJpbnRlclNldHRpbmdzMS5iaW7smWlQU1kWxy8YWS1kERBEISIi3UAAAYVmBMJikCVMCDabxkgS CGISQ8IiJIEGFJq2m2ArYoEM3TRMW9IoKg5CEY0oO0QYFllE6LAKAYEGEQLzIo5ldc1UTVV/63n3 1bn/807uue+e36tT+fAwwB8YASygQBcVhAMyiIKMBcX8ARPQIT0M7IAVdBkBV+AAqQOgQX4AtEo2 5BBAYQDs3OO2kawoB+TAlApdiQTpdhAkLw/p5uzzfk8WNDPfZ/2xSe5DukzlIZPpBjQ+hD+Ku5df 4F4wB8y3TOvzX3c5fPzhPziKn8T+vf8nIdj9PyDw6Xufg+oN8MUfk5WtDl6BP9InTKizyCAG2smL xmCz0FQa8MTifAOwgTg3D4DzCHD38QGBNCqTHCPz/IkMMjOAep4MfDzweA8cwDKpZBqLyKLSacAf i8PjXL3wAEeOoUez38fsraxIDCpwo0fTmb50EnnTs7EFGP8A6llGNJVCJZMCvQCeyd5sWllRvxvT +tDpAv0xckATGP79IEKI8nb7WxRH6YCoExkENZnM/KAcmflrAWCuB8A0pA2Qfsrtd9t+vJWt+UYo D9wcw+KoNBI9LiYshhEdR4+zt7Ukx//XY33Mhx2YwJ+NwPGtUD9BtvAMgPi+mYLZM7vYBvXOubZe X/Rbrg6H9f3SvIM96H692LlDuY3lzXt0PLrMf3e4TchjQoyfoiSzf4srZ8zY0OyIhuG7OsV3LY/U 05BvFZU+y9DW+OZwPvpOraBxPKd5tOLkWc1piVSlMElSG1dlWFidOGiSW7JXk1BRLOT78aV9UvsR 872pVr8adC2ZuefiVw+l5nF3dOq7LlvUPSDyw48n3Jj4nqPBp4mJ7ns74h0pL2KRFOs29fmjGaXG o6N25RuKg9Zi89NH79WolfA0B/9asG7u+IvRO+tTv3nznbmhZT6CtxfuWz4dKt19N6kknl0ae8FQ K2F8TVi/O3F/d/cuRpjk8Nc9FtHGt6qTeEkz9H2vr79goylPMidDuqMxEzr3aVpIwyeDw+Ps7v1f tkTNL66jbG+Wdj27PT4ZEUwfmUTV+cYUj1jd8BDTtZBU3rXRpMfPh4rOUgj1RHperw9noL/xMMUM z3PKqzSxKJ7ZWd2qVsqbfnNEj6n9cONuk1OrWCX9ZXYm4bm0tnI5uIutUq59MO+gA5+uXpAxPDCe yj9agGTOqEaEXfIicrSx1zw1mJwAg9Xk1bfaZcN+hqsNikGGceavrRJD6ww6JaLYgItBqb86FJc7 3JJuXVw8ttIypz4f2sBpKIxaD1mIwvcYl0SgxIwEuZzzOOusJcx2e9+TYjcxrWW5+6uGL8tP/dOD L7dNkKLVbhbM75kL4ntHJqAtm5rja4KmsD9sVOTXL2gn3Ldt845sJuZn7Yzz3JMbQZZzu2hyqWh7 s5fPDJ7ccMvnkEFO+a7TV0lq3+XnPxPFRLYTazojsU16Vcnkh8krhdqathSSZuILlcqNCsmVrAYK b5/rK8S30uZeSfvPP2JuW9F7XsbkP/I2bUIX5fSfQ+oNPdMdKV4Rj/7WcaXDJD+9rdHp9NceykbI q8nxjkQ568YfENlW3i76jsh6yFOTRZFYU8T3St4uTgW3MaYi5TQ/hkNK4abjOIzIQpuqOz4eRrzM KtZSKnjFEtp+iKTp6aT7GbHkZ79A5B+QZc/tKHCRrR1Nu2x+DGTeQdR1KmPnHVOgRV81K6+14dQn ScoZpVpjCagcdXTGvp/eVX+2RDfr5Tmf3Wgt5ghsps4Lnv9cPtNR47Zw4nq13XKk5MrUdwN5CU/t ZjtqQhf2tCbaDZUlFI4l2s725IsGSqsIC8ljWx76pT70U2QXqFVF8RllG55JuqiIaq5xDp81We+h rLGydbW+8E2U8/K2kcUpzzXxZO45nWwRqhjJFRCWUksJNuZGRQSM2xoX9bQfRdXJxq+NpHGRCoLl u7zFxeYDqph4KVp/ZPnl2/Yb3LxTcl6ZK1blBMxfThypT6wt7Ub9aCIgBbvg+kyX9k/o4rDC8fie uOpyQkXvRU/xtRZkE+dJ3yG1VdLng+F2M+F9JzjaQ+GDmSJUnajHUyAyW1RV1pFaLKuWB0/oauIV QqZ1HdO5yMejLpelwvZQJSk6WiF0YjM2dqpTKjyjgxZk2zRarJAHFhZyo7wrO+yGI7Fdl/KETyTH cvsalx6tnxzEH5KipxzubRUU71swrH2Tc7Nq6g5nJLbVwOJu2dq8pUDg7fSPBz9xiwKgZ5IkZ1II 8a1oAXQkBu/ymnDZfVFVih5wErHeH0+KbnLqvbd8tIZSRIDqax6GHn1vjMa6WYKaSXjQt2hxfNvB yqKUhqU51VmsFupCyCtd/XRuESFjGKMlFX6u8w4qx+9b+6eoQOc556uITpTC+rolMi07llglbBQE a3ac+7P9U8D1wARgAjABmABMACYAE4AJwARgAjABmABMACYAE4AJ/K8EZN+g/gUAAP//AwBQSwME FAAGAAgAAAAhAFwEmn6SAQAAJgMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnJLBbtswDIbvA/YOhu6NnK4ohkBWMaQbemixAEm7sybTsVBZ EkTWSPb0o21kcbqddiP5E78+kVR3h84XPWR0MVRiuShFAcHG2oV9JZ53364+iwLJhNr4GKASR0Bx pz9+UJscE2RygAVbBKxES5RWUqJtoTO4YDmw0sTcGeI072VsGmfhPtq3DgLJ67K8lXAgCDXUV+mP oZgcVz39r2kd7cCHL7tjYmCtvqTknTXEv9RPzuaIsaHi68GCV3IuKqbbgn3Ljo66VHKeqq01HtZs rBvjEZQ8F9QDmGFoG+MyatXTqgdLMRfofvHYrkXx0yAMOJXoTXYmEGMNbVMyxj4hZf0j5ldsAQiV 5IapOIbz3nnsbvRybODgsnEwmEBYuETcOfKA35uNyfQP4uWceGSYeCec7cA3vTnnG7/ML73zXscu mXCcTX4dc4p53IeSJ1k9uvCKz2kX7w3BacaXRbVtTYaa13LSzwX1wOPNfjBZtybsoT71/C0MF/Ey nb1e3izKTyUve1ZT8nzg+jcAAAD//wMAUEsBAi0AFAAGAAgAAAAhAEE3gs9yAQAABAUAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAtVUwI/UAAABM AgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAgT6Ul/QAAAC6 AgAAGgAAAAAAAAAAAAAAAADRBgAAeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAHyu+eUkBAAAWAgAADwAAAAAAAAAAAAAAAAAFCQAAeGwvd29ya2Jvb2sueG1sUEsBAi0A FAAGAAgAAAAhABbP2/NbBwAAUxIAABQAAAAAAAAAAAAAAAAAewoAAHhsL3NoYXJlZFN0cmluZ3Mu eG1sUEsBAi0AFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAAAAAAAAAAAAAAACBIAAHhsL3dvcmtz aGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPtipW2UBgAApxsAABMA AAAAAAAAAAAAAAAAChMAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAtta/FsgC AACsCAAADQAAAAAAAAAAAAAAAADPGQAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQDb2iMr VQ8AAHpWAAAYAAAAAAAAAAAAAAAAAMIcAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAU AAYACAAAACEAgLOciEYBAABlAgAAEQAAAAAAAAAAAAAAAABNLAAAZG9jUHJvcHMvY29yZS54bWxQ SwECLQAUAAYACAAAACEAHtZLHEEHAAD0HgAAJwAAAAAAAAAAAAAAAADKLgAAeGwvcHJpbnRlclNl dHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAFwEmn6SAQAAJgMAABAA AAAAAAAAAAAAAAAAUDYAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAwADAAmAwAAGDkAAAAA --_004_4E1F6AAD24975D4BA5B1680429673943676E89C3TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Sat Apr 27 13:05:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B06321F98A7 for ; Sat, 27 Apr 2013 13:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QZuc1Z-wXUX for ; Sat, 27 Apr 2013 13:05:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id B1BFD21F98A3 for ; Sat, 27 Apr 2013 13:05:17 -0700 (PDT) Received: from BN1BFFO11FD014.protection.gbl (10.58.52.202) by BN1AFFO11HUB017.protection.gbl (10.58.52.127) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sat, 27 Apr 2013 20:05:16 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD014.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sat, 27 Apr 2013 20:05:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Sat, 27 Apr 2013 20:05:13 +0000 From: Mike Jones To: Richard Barnes , Jim Schaad Thread-Topic: [jose] Preliminary Agenda for Interim Meeting Thread-Index: Ac46QEZVOFHKxSmTSva1ifMOaDPoRwJNmkuAAAK9wQA= Date: Sat, 27 Apr 2013 20:05:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676E8B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <02e701ce3a40$485326d0$d8f97470$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676E8B1FTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(189002)(69234004)(199002)(377454001)(24454001)(46102001)(4396001)(16297215002)(51856001)(50986001)(20776003)(74662001)(56816002)(16236675002)(66066001)(6806003)(79102001)(564824004)(55846006)(53806001)(56776001)(47736001)(512954001)(15202345002)(74366001)(65816001)(31966008)(49866001)(71186001)(47446002)(63696002)(54316002)(54356001)(80022001)(81542001)(47976001)(16406001)(74502001)(69226001)(77982001)(59766001)(561944001)(76482001)(81342001)(33656001)(15940465002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB017; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08296C9B35 Cc: "jose@ietf.org" Subject: Re: [jose] Preliminary Agenda for Interim Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 20:05:19 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676E8B1FTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard, it would be good if you could update your slides to reflect JWE-10= , which should now be what's on your "State of the Art" and "Current -09" s= lides. You should say that -10 it is compatible with all major AEAD algori= thms and no longer say that the current format causes GCM nonce re-use. FYI, -10 uses what you called the "Everyone Together" approach. In your "Only what's needed" slide, you should point out that when applicat= ions are free to add header parameter values (which they now are), it's ess= entially impossible to know needs to be protected, in the general case. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Saturday, April 27, 2013 11:40 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Preliminary Agenda for Interim Meeting Dear chairs, As I suggested earlier, I think we should organize this meeting around the = few big questions we need to get resolved, from which the answers to indivi= dual issues will follow. So I would like to propose that we re-organize th= e agenda in the following way: 1. Mon. AM: Which fields are required / how to handle pre-negotiation? 2. Mon. PM: How should header parameter integrity protection be done? 3. Tue. AM: How should we do key wrapping, for JWE, JWS, and beyond? 4. Tue. PM: Review / close issues and wrap up Also, Based on some side discussions, I've put together some slides that tr= y to summarize the state of the art and proposals for (2). Thanks, --Richard On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad > wrote: The chairs have posted their first cut at an agenda for the Interim meeting= . It can be found at http://www.ietf.org/proceedings/interim/2013/04/29/jose/= agenda/agenda-interim-2013-jose-1 Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676E8B1FTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard, it would be good= if you could update your slides to reflect JWE-10, which should now be wha= t’s on your “State of the Art” and “Current -09R= 21; slides.  You should say that -10 it is compatible with all major AEAD algorithms an= d no longer say that the current format causes GCM nonce re-use.=

 <= /p>

FYI, -10 uses what you ca= lled the “Everyone Together” approach.

 <= /p>

In your “Only what&= #8217;s needed” slide, you should point out that when applications ar= e free to add header parameter values (which they now are), it’s esse= ntially impossible to know needs to be protected, in the general case.<= /span>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Cheers,

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Saturday, April 27, 2013 11:40 AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] Preliminary Agenda for Interim Meeting

 

Dear chairs,

 

As I suggested earlier, I think we should organize t= his meeting around the few big questions we need to get resolved, from whic= h the answers to individual issues will follow.  So I would like to pr= opose that we re-organize the agenda in the following way:

 

1. Mon. AM: Which fields are required / how to handl= e pre-negotiation?  

2. Mon. PM: How should header parameter integrity pr= otection be done?

3. Tue. AM: How should we do key wrapping, for JWE, = JWS, and beyond?

4. Tue. PM: Review / close issues and wrap up

 

Also, Based on some side discussions, I've put toget= her some slides that try to summarize the state of the art and proposals fo= r (2).

 

Thanks,

--Richard

 

 

On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

The chairs have posted their first cut at an agenda for the Interi= m meeting.

 

It can be found at http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-inter= im-2013-jose-1

 

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B1680429673943676E8B1FTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Sat Apr 27 13:38:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7F221F98DB for ; Sat, 27 Apr 2013 13:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq7ASEkiWnuH for ; Sat, 27 Apr 2013 13:38:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0F621F98D5 for ; Sat, 27 Apr 2013 13:38:05 -0700 (PDT) Received: from BY2FFO11FD023.protection.gbl (10.1.15.201) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sat, 27 Apr 2013 20:35:54 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sat, 27 Apr 2013 20:35:54 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Sat, 27 Apr 2013 20:34:50 +0000 From: Mike Jones To: Richard Barnes , Jim Schaad Thread-Topic: [jose] Preliminary Agenda for Interim Meeting Thread-Index: Ac46QEZVOFHKxSmTSva1ifMOaDPoRwJNmkuAAAK9wQAAATkBoA== Date: Sat, 27 Apr 2013 20:34:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676E8E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <02e701ce3a40$485326d0$d8f97470$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676E8B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676E8B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676E8E7CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(69234004)(24454001)(199002)(189002)(164054002)(377454001)(80022001)(16297215002)(54356001)(71186001)(6806003)(76482001)(47736001)(564824004)(4396001)(65816001)(47976001)(49866001)(69226001)(47446002)(77982001)(31966008)(55846006)(46102001)(74662001)(512954001)(54316002)(51856001)(50986001)(81542001)(56816002)(20776003)(63696002)(44976003)(53806001)(74502001)(79102001)(66066001)(16236675002)(33656001)(59766001)(561944001)(74366001)(81342001)(56776001)(16406001)(15202345002)(15940465002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08296C9B35 Cc: "jose@ietf.org" Subject: Re: [jose] Preliminary Agenda for Interim Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 20:38:08 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943676E8E7CTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding missing word ... "when applications are free to add header parameter= values (which they now are), it's essentially impossible to know what need= s to be protected, in the general case". From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Saturday, April 27, 2013 1:05 PM To: Richard Barnes; Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Preliminary Agenda for Interim Meeting Richard, it would be good if you could update your slides to reflect JWE-10= , which should now be what's on your "State of the Art" and "Current -09" s= lides. You should say that -10 it is compatible with all major AEAD algori= thms and no longer say that the current format causes GCM nonce re-use. FYI, -10 uses what you called the "Everyone Together" approach. In your "Only what's needed" slide, you should point out that when applicat= ions are free to add header parameter values (which they now are), it's ess= entially impossible to know needs to be protected, in the general case. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Saturday, April 27, 2013 11:40 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Preliminary Agenda for Interim Meeting Dear chairs, As I suggested earlier, I think we should organize this meeting around the = few big questions we need to get resolved, from which the answers to indivi= dual issues will follow. So I would like to propose that we re-organize th= e agenda in the following way: 1. Mon. AM: Which fields are required / how to handle pre-negotiation? 2. Mon. PM: How should header parameter integrity protection be done? 3. Tue. AM: How should we do key wrapping, for JWE, JWS, and beyond? 4. Tue. PM: Review / close issues and wrap up Also, Based on some side discussions, I've put together some slides that tr= y to summarize the state of the art and proposals for (2). Thanks, --Richard On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad > wrote: The chairs have posted their first cut at an agenda for the Interim meeting= . It can be found at http://www.ietf.org/proceedings/interim/2013/04/29/jose/= agenda/agenda-interim-2013-jose-1 Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943676E8E7CTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adding missing word ̷= 0; “when applications are free to a= dd header parameter values (which they now are), it’s essentially impossible to know = what needs to be protected, in the general case”.

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, April 27, 2013 1:05 PM
To: Richard Barnes; Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] Preliminary Agenda for Interim Meeting

 

Richard, it would be good= if you could update your slides to reflect JWE-10, which should now be wha= t’s on your “State of the Art” and “Current -09R= 21; slides.  You should say that -10 it is compatible with all major AEAD algorithms an= d no longer say that the current format causes GCM nonce re-use.=

 <= /p>

FYI, -10 uses what you ca= lled the “Everyone Together” approach.

 <= /p>

In your “Only what&= #8217;s needed” slide, you should point out that when applications ar= e free to add header parameter values (which they now are), it’s esse= ntially impossible to know needs to be protected, in the general case.<= /span>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Cheers,

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Saturday, April 27, 2013 11:40 AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] Preliminary Agenda for Interim Meeting

 

Dear chairs,

 

As I suggested earlier, I think we should organize t= his meeting around the few big questions we need to get resolved, from whic= h the answers to individual issues will follow.  So I would like to pr= opose that we re-organize the agenda in the following way:

 

1. Mon. AM: Which fields are required / how to handl= e pre-negotiation?  

2. Mon. PM: How should header parameter integrity pr= otection be done?

3. Tue. AM: How should we do key wrapping, for JWE, = JWS, and beyond?

4. Tue. PM: Review / close issues and wrap up

 

Also, Based on some side discussions, I've put toget= her some slides that try to summarize the state of the art and proposals fo= r (2).

 

Thanks,

--Richard

 

 

On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

The chairs have posted their first cut at an agenda for the Interi= m meeting.

 

It can be found at http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-inter= im-2013-jose-1

 

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B1680429673943676E8E7CTK5EX14MBXC283r_-- From rlb@ipv.sx Sat Apr 27 14:59:47 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BC421F99C0 for ; Sat, 27 Apr 2013 14:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT4Z3XqRw5uR for ; Sat, 27 Apr 2013 14:59:46 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id ED67521F99BF for ; Sat, 27 Apr 2013 14:59:45 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id l20so5003898oag.27 for ; Sat, 27 Apr 2013 14:59:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=L8JkXu+VPs2tPS2iy209w0ltELvP70ndKyOEXHjt7CQ=; b=Xdsm6z9+/D3m61O2/WcKsYbHKdPYSizv4D1t+bTxwehNeX5YmU8pT1RlzLtrAlKegw RVT/wT8+LYsINitCZFjnknWzw40ZX/kYLTR8qfPe7f4IXdTo7E2agX1RLBg4DozcHvn4 +2XiEyLmfkLJui9RALiL5C/ptb0bW5Dcr56p8+bDzALlHD5W15/yKOyHGb2fwO6m2SB7 7OsohMkMDzeqStcoqYz1VUq9EF9AUkcARP5oFkdx0JWMC6eD9qeN9QarELddEyYRIW40 ZQ9E8/5MHHmaZi2ozzgggPVWKGXPayJFzUXGmB7sfoaPucrfH9FFqI9bODAL7yf0S9Sa 5f5A== MIME-Version: 1.0 X-Received: by 10.60.37.36 with SMTP id v4mr4532653oej.53.1367099985366; Sat, 27 Apr 2013 14:59:45 -0700 (PDT) Received: by 10.60.20.99 with HTTP; Sat, 27 Apr 2013 14:59:45 -0700 (PDT) X-Originating-IP: [128.89.253.157] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676E8E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <02e701ce3a40$485326d0$d8f97470$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676E8B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943676E8E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 27 Apr 2013 17:59:45 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e013d09b800691b04db5ec561 X-Gm-Message-State: ALoCoQk7bttRU1mqr2Q8UnzVjMcfi+SLCA7Spu3xkQk/NM0C8jGnb90r6gJLSctfdLPZO588kiXs Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Preliminary Agenda for Interim Meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:59:47 -0000 --089e013d09b800691b04db5ec561 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not to have technical discussion on the agenda thread, but: That seems like a decision for application designers to make. They can always choose to protect everything. --Richard On Sat, Apr 27, 2013 at 4:34 PM, Mike Jones wr= ote: > Adding missing word =85 =93when applications are free to add header > parameter values (which they now are), it=92s essentially impossible to k= now > *what* needs to be protected, in the general case=94.**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Saturday, April 27, 2013 1:05 PM > *To:* Richard Barnes; Jim Schaad > > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Preliminary Agenda for Interim Meeting**** > > ** ** > > Richard, it would be good if you could update your slides to reflect > JWE-10, which should now be what=92s on your =93State of the Art=94 and = =93Current > -09=94 slides. You should say that -10 it is compatible with all major A= EAD > algorithms and no longer say that the current format causes GCM nonce > re-use.**** > > ** ** > > FYI, -10 uses what you called the =93Everyone Together=94 approach.**** > > ** ** > > In your =93Only what=92s needed=94 slide, you should point out that when > applications are free to add header parameter values (which they now are)= , > it=92s essentially impossible to know needs to be protected, in the gener= al > case.**** > > ** ** > > Cheers,**** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] > *On Behalf Of *Richard Barnes > *Sent:* Saturday, April 27, 2013 11:40 AM > *To:* Jim Schaad > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Preliminary Agenda for Interim Meeting**** > > ** ** > > Dear chairs,**** > > ** ** > > As I suggested earlier, I think we should organize this meeting around th= e > few big questions we need to get resolved, from which the answers to > individual issues will follow. So I would like to propose that we > re-organize the agenda in the following way:**** > > ** ** > > 1. Mon. AM: Which fields are required / how to handle pre-negotiation? *= * > ** > > 2. Mon. PM: How should header parameter integrity protection be done?**** > > 3. Tue. AM: How should we do key wrapping, for JWE, JWS, and beyond?**** > > 4. Tue. PM: Review / close issues and wrap up**** > > **** > > Also, Based on some side discussions, I've put together some slides that > try to summarize the state of the art and proposals for (2).**** > > < > https://docs.google.com/presentation/d/1HlBYEiwBFYUBA5751Q8U1GXD-W0cgdCZw= pVMRdUkK2c/edit?usp=3Dsharing > >**** > > ** ** > > Thanks,**** > > --Richard**** > > ** ** > > ** ** > > On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad > wrote:**** > > The chairs have posted their first cut at an agenda for the Interim > meeting.**** > > **** > > It can be found at > http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-int= erim-2013-jose-1 > **** > > **** > > **** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --089e013d09b800691b04db5ec561 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Not to have technical discussion on the agenda thread, but= : That seems like a decision for application designers to make. =A0They can= always choose to protect everything.
--Richard


On Sat, Apr 27, 2013 at 4:34 PM, Mike Jo= nes <Michael.Jones@microsoft.com> wrote:

Adding missing word =85 = =93when applications are free to add head= er parameter values (which they now are), it=92s essentially impossible to know what= needs to be protected, in the general case=94.

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, April 27, 2013 1:05 PM
To: Richard Barnes; Jim Schaad


Cc: jose@ietf.org=
Subject: Re: [jose] Preliminary Agenda for Interim Meeting=

=A0

Richard, it would be good= if you could update your slides to reflect JWE-10, which should now be wha= t=92s on your =93State of the Art=94 and =93Current -09=94 slides.=A0 You should say that -10 it is compatible with all major AEAD algorithms an= d no longer say that the current format causes GCM nonce re-use.<= /u>

=A0<= /p>

FYI, -10 uses what you ca= lled the =93Everyone Together=94 approach.

=A0<= /p>

In your =93Only what=92s = needed=94 slide, you should point out that when applications are free to ad= d header parameter values (which they now are), it=92s essentially impossible to know needs to be protected, in the general case.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Cheers,

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

=A0<= /p>

From: jose-bounces@iet= f.org [mailt= o:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Saturday, April 27, 2013 11:40 AM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Preliminary Agenda for Interim Meeting=

=A0

Dear chairs,

=A0

As I suggested earlier, I think we should organize t= his meeting around the few big questions we need to get resolved, from whic= h the answers to individual issues will follow. =A0So I would like to propo= se that we re-organize the agenda in the following way:

=A0

1. Mon. AM: Which fields are required / how to handl= e pre-negotiation? =A0

2. Mon. PM: How should header parameter integrity pr= otection be done?

3. Tue. AM: How should we do key wrapping, for JWE, = JWS, and beyond?

4. Tue. PM: Review / close issues and wrap up=

=A0

Also, Based on some side discussions, I've put t= ogether some slides that try to summarize the state of the art and proposal= s for (2).

=A0

Thanks,

--Richard

=A0

=A0

On Mon, Apr 15, 2013 at 9:18 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

The chairs have posted their first cut at an agenda = for the Interim meeting.

=A0

It can be found at http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-inter= im-2013-jose-1

=A0

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--089e013d09b800691b04db5ec561-- From johnsonhammond1@hushmail.com Sat Apr 27 17:29:30 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D721F9933 for ; Sat, 27 Apr 2013 17:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJXP-hWJTEiD for ; Sat, 27 Apr 2013 17:29:30 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6DA21F9977 for ; Sat, 27 Apr 2013 17:29:30 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id ED5811B531A for ; Sat, 27 Apr 2013 17:45:55 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:45:55 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id BA2E4E6739; Sat, 27 Apr 2013 17:45:55 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:45:55 -0400 To: jose@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174555.BA2E4E6739@smtp.hushmail.com> Subject: [jose] Biggest Fake Conference in Computer Science X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 00:29:30 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From Michael.Jones@microsoft.com Sun Apr 28 01:13:08 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABED21F994B for ; Sun, 28 Apr 2013 01:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbvwQ5MW1Dow for ; Sun, 28 Apr 2013 01:13:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1967F21F9957 for ; Sun, 28 Apr 2013 01:13:04 -0700 (PDT) Received: from BN1BFFO11FD021.protection.gbl (10.58.52.200) by BN1BFFO11HUB031.protection.gbl (10.58.53.141) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sun, 28 Apr 2013 08:12:56 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD021.mail.protection.outlook.com (10.58.53.81) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sun, 28 Apr 2013 08:12:55 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Sun, 28 Apr 2013 08:11:59 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Updated JOSE Use Cases document Thread-Index: Ac5D6Av28wjy1o6yR4ySUVGjSQDTuQ== Date: Sun, 28 Apr 2013 08:11:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676F9ABF@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/mixed; boundary="_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(53754004)(564824004)(55846006)(4396001)(56816002)(15202345002)(49866001)(46102001)(47736001)(16236675002)(47976001)(51856001)(50986001)(16406001)(77982001)(59766001)(54316002)(6806003)(69226001)(54356001)(63696002)(20776003)(53806001)(56776001)(512954001)(74366001)(74662001)(76482001)(81342001)(47446002)(74502001)(71186001)(33656001)(66066001)(65816001)(81542001)(80022001)(79102001)(31966008)(563144001)(552614005); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB031; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0830866D19 Subject: [jose] Updated JOSE Use Cases document X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 08:13:08 -0000 --_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I took some time today and produced a revised copy of the JOSE Use Cases do= cument, both to use as a discussion tool during the first agenda item at ou= r interim meeting on Monday, and to apply corrections/clarifications that I= came across during my review of the -00 specification. Changes range from= additions, to semantic clarifications, to spelling and grammar corrections= . You can see the differences from the -00 version as tracked changes in the = attached "draft-ietf-jose-use-cases-00+Mike diffs.docx" document. XML sour= ce, .txt output, and .html output are also attached. I'm looking forward to seeing many of you on Monday! -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I took some time today and produced a revised copy o= f the JOSE Use Cases document, both to use as a discussion tool during the = first agenda item at our interim meeting on Monday, and to apply correction= s/clarifications that I came across during my review of the -00 specification.  Changes range from additi= ons, to semantic clarifications, to spelling and grammar corrections.<= /o:p>

 

You can see the differences from the -00 version as = tracked changes in the attached “draft-ietf-jose-use-cases-00+Mik= e diffs.docx” document.  XML source, .txt output, and .html outp= ut are also attached.

 

I’m looking forward to seeing many of you on M= onday!

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_-- --_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-jose-use-cases-00+Mike diffs.docx" Content-Description: draft-ietf-jose-use-cases-00+Mike diffs.docx Content-Disposition: attachment; filename="draft-ietf-jose-use-cases-00+Mike diffs.docx"; size=81761; creation-date="Sun, 28 Apr 2013 07:59:06 GMT"; modification-date="Sun, 28 Apr 2013 07:59:06 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBJn4PiqwEAAJcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lc1u2zAQhO8B+g4Cr4FEJ4eiKCznkCbH1EAdpFeaWtlE+QfuOrHfvivZFpxWtdw4uQiQyJ35OOCu xjdrZ7NnSGiCL8VVMRIZeB0q4xeleJzd519EhqR8pWzwUIoNoLiZfLoYzzYRMONqj6VYEsWvUqJe glNYhAieV+qQnCJ+TQsZlf6lFiCvR6PPUgdP4CmnRkNMxt+gVitL2d2aP29JElgU2e12Y+NVChWj NVoRk8pnX/3hku8cCq5s9+DSRLxkDCF7HZqVfxvs6r5zNMlUkE1VogflGEO+hFTJKuiV4zMUx2V6 OENdGw1dfaMWU9CAyJk7W3QrThm/5+/j0Cuk4H46Kw2Bm6YQ8epsnE600YNEBroM+xjaLPzKzSEx /dnuf4XRSR8LooVA2ljA9yfY6p5o/2RoeVfXoPnWD18Mh3mDXmwtDmqH3YCI8z7F5HUv5kO3D3fK gwgvMP/xYRQH4oMgNc+ImZpbOCHx/wyjkx6EIB58INvn+T3Yyhyz5BHRtjsP0vSGY+8nZVOd8+w5 oc87Rx7CZ+cMzZivoOrxlu1vZfIbAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQBT2g2w/AUAAKM1 AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAMRb32/bNhB+H7D/IdC7RP12UtStga4DumEvWYbtbZAlymYjiSpJxc5/3yNt Oc5qOT7PooEksChbPpLffffdHfP+47qubp6okIw3UyfwfOeGNjkvWLOYOn89/OreOjdSZU2RVbyh U+eZSufjh59/en9Pq0zBh+SStfIGntLIqbNUqn1HiMyXtM6kx1vawJ2SizpTcCkWpM3yx2xBSej7 KRH7z3A+vHrmzZdi6ogvRRA5Nw/PLXz12w/nZcly+gvPu5o26sB3kCU8SVSseYSHZmJB1e6xivNK eoyq0ti5VHVFCpGVyq1ZVVHhruu2dWlIXT/uP/wHL8Cuz2tFRZNVDhmYASyhjRmsVitPlLlLC6a4 MLOASwK/cRrfemqtcHaH6bXtToPQx9sd3dmxW6ObFV5DFZEtzSXZDLg5bxqaA26olAB16Qb/+p7G E3L5AzvTOAR8wEzi32rPM05yGs4j7RdjemqdsUrxd3nWaHyHMy47jxYdzso4tGNlzRddNVuJyito 7uW8Rpo5GdnMLZsO7H6YBtr7EbufQOQYdfe3Bg+znLbZa4sSaXdix+6BhY5CX+80YqFTSwFxeKHj yA/wtJxePQwmURji7Z5cNAwqUEa03/CpYy6J+Rt4IJWGNMQV2WAjgrQwcjOgX7cVXPGcV26A1EGT Kwe0SaINQHjaRSNF09VzKkBW9zZMnd3QsZ03PDxmVH2TV+M0nODdJrSkwjRNrSKjdh/uQfIHIfl0 D2K9KiRbgBYTNHT1KPwg8RpcEa/7TgfelrmCfuuYAO5olHR9pDIzM78qhpI0OYN6o4t64HDuN4gh SIUNhIINhCKTjCIYJBqbt7eSmD5Rr84gS53JrjlDbI6t3bZmloxWurIwY7n0upydod7HVmtbS9us g6R/VrNccMlLhV/TxJJMG9CV4W2g9RYCq4klfTZgcHQXIlktvagwO8AOPRYElQ3LH2ffuqyCRK7G g2FiKTUW1XzG2idPrpF7D2+/WHyQVClwctmbMHX6kaM6Z2zPPp7wapHTG3xaucPA9WKLdgB+xw3W ERVpsCUHH04c00l8h1eSkSU/F+2SVS1XaiZkJmneCaae8b4eWxS+h8u9m0LIzv9Og3NiSapI1VKo l8++ZnPIh7Rux6E4taTKIYPwgPh5J3Jqsou2m1fMlNMJ3NNldR2yDKWh4mwwttjaS+h27QzW6B4F Va5JLOS2s/GS1EN6AXXqFO+cgSW0D6iG+M64G0LmRJbwM1pOEVvSEtDAM6iZtZnIvTUVfI0nQxOj LATJE7zVsCK8D0k3lrz12ARML7LnG3wjKbWkrIbjfhLGZ1DLxFIGVXDIRjmgXbq6g2fIfiVLWhD4 pcJ0uclT4IWES7KS7suoC4Ou7v25XJ7R4Rty5FdZJ9k0tXUze/K6YU6keq6o/Jup5eeyhI7jLuKD 4v7vrWPS+4oUvl/n0sXlbRzC+agpRFsgGQ3wNyLqj2cF8CE1tFj1Oiwgde/3DLvHVpDHEyKdXOBw E1ni9kEp8L9L1NHY1L4tgfzGl433O63bWcMfWYbXAfHYXN5XGMUzUN/jbNMRwMEhvnp+bCQK+pxO MnZ+vJdQHOYL3cTG80U6FP8OHBu79MkumIcWJTiApJYC5Sla0PSy8VrQIsTfiJQvuedeQxkPItPT tRD7T9kT4774PZlcP95Daxy/9Bel9I1g7f2xF7DHVGtgcdlOwvKhPi1+VYPrqih9VLTfhdMKh+HY GuQN2QetfZzB0UWBO1y4fy37gru7W3L/+ZM+muDqCz8MfIK03BJ9H8qI+4I4kRlUP59CzzevTHvc hSudAqMP35kIPCZ7b2WhYvUcDmOaYyK4JU8sxfzh4ompMqNFYXpdGtHyBLfQxovHhMKbKlbXkvF8 HY9dT95C+OviPPxaEtnD+NUnEfDLmlqK7kN9BTjiisPvxFIx4ZgQhXu6L2VyA3iNnMBF43jJG/WQ zSvaGzF1dkNHVR28/2IskHdS8fqfl5WYOp5HdqOEKVofPXZ70cx6Red//nA0Ym+wXxby6l+rPnwH AAD//wMAUEsDBBQABgAIAAAAIQAD6fQrf+sAABf2CAARAAAAd29yZC9kb2N1bWVudC54bWzsfdty 21iW5ftEzD8g2A9lR0g075RUJXbwprSclu2xVOWq7p6oAMFDESkQYAGgZOVTfUh3RL7Nf+Sn1JfM 2vsAIAACFCVRJCDD1Z3iBQTOZV/Wvp4//fv3maHcCtvRLfO0VC1XSoowNWusm9enpT9fnR0elRTH Vc2xalimOC3dC6f0753//b/+dHcytrTFTJiugluYzsndXDstTV13fvLunaNNxUx1yjNdsy3Hmrhl zZq9syYTXRPv7ix7/K5WqVb41dy2NOE4eF5fNW9Vp+TdbrZ6N2suTDxrYtkz1XXKln39bqbaN4v5 Ie4+V119pBu6e497V1r+bazT0sI2T7wBHQYDop+cyAF5f/xf2CuzSHiu/OXAWwF+4jtbGBiDZTpT fb6cxlPvhilO/SHdrpvE7czwr7ubVxsrzwumvMkeDGz1DluxvOHK7RIWYyx/NDPkOtD+Lnc1fsdq Zd1kvB2hWwRj2GQI0Wf6I5mpuhnc5mlLE15ccMRz6Psn21rMg+HM9efd7dy8Ce5FjPmIkVVazHnh qTmPusEK615O1bkoKTPt5PzatGx1ZGBEd9WGQhRZ6kBYjFTt5hoLYI6VuxPNMiyw2Rn/K73j763x Pf11R4b354vtvZh/sfEbQ0zcM9uaXYnv7mmpDga/O7H16+nKhxBmbtfUpvQEFxfThbjr/K+XcwGZ wr/xP/ub/EyDFBO2HAgu/YZf3J2WGk0IQ/z2fo7JjL+rwfd9YRiXc1UDo8grq7X0Cy9UngcNX16c dFMeVNrX73j89FDvXhjiR8u6wfW3qnFaqjS6fM+JbjvuVwsjr9JwDNV7t/yybxmLGYl5/3v/A77E tN73IOhxQ/ratP4i31WDeQ+Eo9n6nGSc/2xDvbcWLl0hRxls2k+2Pqb9u8ZfPAXXY1ytxvHyUv8K 18aX0D/jr3iy9w8DqDZO5qqtnmM8jUF9eNzt05bjU9pT+rTt/WPycm355LF+e04UxgvTah3XqkeV tjcB+70gevG/rdWawcw22VGaoPcUV2PS1LzZamsJxpkGA9IModq0uB4DqAvXorcT3cA+Hh/T7OWY bruGfh2scpg+p/pYgA5uvCX3xjACPZAuvHRVm2aoB9uozkC9f//J6oEB5b39a4fMi/JK5sF5ZNVb vcGwVa0SMSStOh6yumnyo4GYqAvDpe08qtZrrR5vEdiYVs0JGGckoMkxOCY3+aaLBfEu8D5XJ+DM 8OvVSwyd5B9tJ8ZEb74uSPyo7kcBFpBz/kXDd0wU4bX0ttM+s0zXwQWqo+kQy38R9lg1Vbod3aHr 6Opp6UqfCUf5JO6Ur9ZMhVq5O5l2TSd0Oa8h76z/rKWAA/Hww/DXWwdejN0PAMRmjPtT1cYYvVdX LOBG4hrKUlKVHBvt1j4GqJuOa5OYJyTI9ILdnNvCEfatKHUUEjXBNSx4MjLezvu/fRl+/Xj+6Wel VFL+y1BKrqWVMjvcnCxvCr06gtSDKzYl2QvLVDWWtpvwtHc1s/RI/rfvrGNwCLZffbaveULc+bVP UoXFjvzMFwNQJZ3ff7v63P/9N1acGaDilGUW5ni5wiS9pKaHAsQbF4xHfwLMxmpxZAQowFOM9Tr0 GlZCQqm55gll/G5F8Yaui0OuAkmFkFS1feTtC1ZxcyjVah/XzirDPnYjSanz/nkyfx2U2mjjmEB8 iMR3jgOm0GYzFGIGeyz0WVJfnOyaBKc2Izs2J5KRvg+6LcAjArG1xvKeAYku4X3i1yPLda3Zmt+H DICEG0geew0WQL1yxCZAzDDwP5YT3Zycm+2j4/awUd+AnJOEzequP0yz1VbYLAxk2cYov8X/iHcB IBOxfBSGt5v9RrvSSuNY0FQWYDhPJwUsdm1dhYtqMzAdXKzBJSHfbE/tYnc3QN/BEDYBCsHFLzFe ggkfPl8OIxiBJhEoYVyRbIvumkwr/erxYDjspnBiQaaPQId5JNOvZaWn2qZw0mmVZatEGInkEPL4 tKpn9WHzaJBCTWGYkle53qz0Bv3WcZrqSlyh3btXCrn+UnL9nFzOpnAPESCZuOlckxkJX+2128N2 8yyFJwuCfeUSvtf7pFwJbWoieHOtb0vQD4+bzXaNAhIP2aN5FfStRq9b7zURR0+cYsE3r5xvSNCb YzGmNAp34Zwo56bMYEAYTTVyIPhhZNePj6sxaF9vD48awyMi68ICjTh5yRWc5vhdQvuxoKAoRd9I +J3A/8UR6wv9RigfkGrj0KdjOLjhcapU64eVxmHt6KpSOWkenVQq/1EiDCzjHtLtFQ9iBYZpBqxY zJXiOR240rSpUqsS0fuf0WvpRsYnNCmEdryF4aj6q14Yt9Od27qh1I7icgCrkKcddjsHCpFpfBpL T8UjrL9Kt3U2qPTTkOZrsP7atXr/qNogB2QI97Ra1eN2t8IO5sKrFw6cbSZT8yIPUyLbw+9zHWHu E45wu+zj4xktVQV5C34MVXEp5q6YjYSt1Gobqgtmm1euLj5rrkWLUq/EJe2rUxjZcXy06kfNdiWG f4P0M3BkIatfsaxGokac11ZQDYEbmQQRC94Nu91ms5aGZHJAOlvLhZOZnX4uCdksWDSOxtHfIKDl wcS0Ba306tXW8VEMN7W7re6g3eUEwCfx4vzSvTcEtoNzdd4LleofvMTXNXkQ8YBnuqnFfnRD5YRh foYIcu3CS5Fi0j35vsi7tvnRbufPjlD6qoMcRuT4Kl/FPxbAGlS+4ShwRygfLj9/Uj6PfhGaq1wi 9ZRym+nCoanZ9zLl9w2FIt9GeOGFxovdl1COTaCYffuMxXA7KFWYuIe6cCeHv1iOOFzg/zValcPY vJaYi6lqe7DiGcP3TeZKpex+55CB/wkNXnIUPoka0cQqW4SMzxi+26mw5R8gWwyaUQv+QgDgP2wM +VnflWq3W6n02lET6dlqN5HV6zIfI9+sDmfCCJmzqpYUTYqvbrs67NbabXKxhAzQLa/uJ6rUMr6J 0aOXdzUT+8Fk66WCodqHJ0raF3suAEJyvu2Fat7DJSyDgYo6nxu6JsvIlKl6KxRVMQWcxySjLRbP hyPIK3iThbawUe2mzBCTUU3dmTmKbirqeKxzgYZrJV6iuoo7Fbini5KpGwX1G7AmcG/QjenMLRQP 8EdlDIkvnCMB/oBf9UkPWNe2Op/qmnKBmj31WiiX96arfsdQnbjVKiV4THi/5Pp2UHR2i4yqMdZs pJuqfS9XQHgLR2uIqjpFrh9qWLqXn8rVsvIZFUOKi/R+OU+oBMWa+HeQax7URDqKs4ALE7PlH/O8 R0KYikVlR+oNXo3uFSpR8bbJL6Z0DngLxXd1NgfS+KDeqpdcTOMr3U8WwgMICZSVq6nuKEFx5VhM UNIArY3JuDQwGh+rLNbPdkiRx1TYzjcgmcB53jR60Gt8K3h1sGELqv9csygHChT3nalMUACGlbhV bajwe1qNEMMk0jseagPkGPfEHGNxKwxrTqinHCXXZBVUH54d1Ye9bcP316yCUICEIBftjEtkfCFm VoQskxe62TjqDQeDl9X1hTZimCglcoo2YtnjayOZmqJgG53FaKa7LjgVXDRZGIaiWTKKaWowm3R3 yioistNAHLZlTYa2DQAqU6uhPGZcoSbxwM4FlNQQVOoeTVNLGSoK5PY00BRJCq7q9b/8/lv7KCq9 fHNpl8qWjEM5mONyZN+TObzarlca9T7l4xd48yQerA15WbaEc8FynSgfA0JA/xLqI13r4wtPVIsl BB2aKAQUwqarrlTnRjmzbDD5m/Ph1dnbsgKcIsDswFEWgKStUFH33FFm6r2iGo6ljHXYIPpogatW nwXcFBsUwR2hGPgR6QxPW8cvIhGEB3ol7giKq2Tm3Ai7TJY8N4IAPpi4zjstQor74AuJN95twhP1 arfe7/e3nRkUhReF1ntY68VokhmFCSrEJvDa6dIMU0Hs3/XZYkYU6+jflRnKh6fSr0ZsMBLKYg4i FeMDxRZzQ9XoFdtvjmUI0qKwEST3LNkQ9E2WINkhML5cInnYMHPoUGQI4GYKDDqC/nsmcO4qQPlM thh/gQHYs4VKteiJ8sbB/Ce4kkACLC/IFNVgY9NSNJ3FiMAishiBRIHx6ij/+ud/s2Gq73mebsdU sPbXiMc65X/9838iw0lWce36WX1w1IupOKQynA0r9R4U39PiRAU7U5eNBKd5qkslCcTeocWCIjjA rsD0j2wnJyPhGZSMRSbIFt2lL+jv8H2/T4iUc9Le9lzaLzhJt/OsiPfL4CqZ6rSJhm9BvQ+a7bT0 5u2IBC9c9Up82H1rfi+rYYE00S4swqnJgrdyXGvW6+1tl0gWgjdd8HaW2/RGe8upfwoZCMqVvQCU J+OQ3MxzNJaDsa3AK2u6+kQn36zD3/jAR5FiyCkrXQho3nhCDdzrY7wJi7Xr9cagWqEoXWFY7siw jHqopX+II8fAqPAJKPBP+BSwJIo/OMpHcQ0A+IXc9HDCRDh7H6YaCPMr9+yDpYuR81AHXks/R3nj mZsuUbQQS1MTARphIm6swwP2lhxiYjKhsDlgBdE8IX+yDOaLkR/KCdyhPtWXlS9oBQU0b4tbHS2F 8Du88b914N8HcIab7f7A45d7+K6p+RZsCzTcsn1GoVUGs8Dg1rjzoHTF4RO0OkOgx8KNsTv+fctK 3xojCwDNEpFgbkbDhPvYAAeIjCx5MonYtR8ZrjIjUaKbmrHAqC91BE6kCOldDpSPchM41EJr5C8P eygvMXtqUtYo807Qrki5FCVA7D8tILlFAPVl6Ih8mehoptypNiJiiDHE7003Sx7LJtKq0W/Uj1t9 SlXcprTaclMttuceEQxfBYDpaQLAPFtycREYkB5Pv6NZuPvZMQF5k7ufuejCxFPyr4NjF18S3Pf7 0SXkHzTbZ71eZRhPNfK7zj0Vu/3gW7Whz38X9APygdjs/On2xCZpSeTw9++URfB3vVqhbnIOJYWh j6U+dqcnlT9OuX3gSbndnLslxTqZ2nAJXaOdotdSjj9yXNzG+5pfUG8/r93fv6kV+h/d2LZuBC6c EF0SHfNA8ALLk4xxW4PesD5ovCzMeV2WxBW1ISXV24d/DuouGvNJXuZ6q4HOSu1Yrm+jX221G0PO vt9CfmEgj54lYrcuRafoA2ijfyI1FlW9Bqq6CVI9ROyepCmwhGvZ91Sxxol5/B8v5hRNoPTv5IXP 0vsrJk1iJGW1128tPZWHXI7VFaUbzGJliI8bRaSR42a5RTSg33+j4IVtjRcMQfaMcTn7U4oVbJ+/ K6H9RXZJhne3lrHdTQ7LYstj2ww0mbHAN1qy6iYnhkWl4O5Rf4Qk4cMEMXIRLHdqy4VPMqVT4lMb qCaJwCcJHyzm+QatU8OXMdqQkCwszHcgKSOjWOmbKtVPlXunRq4kRtv7eJPFAAuBbAw2hUIfbJm6 FyWOJePi8DoLe//d3jY6Ze0Q8vSwuoToGCdxDPLXfQH2MmX8LxHBSJni3gUYFvMFGz9vTc4Gw1zt 94zUYl1jQEX0u7xwb9QcDGGNzAqu2Z82SKHIbAostyNFVVDHkrX0wZTVjIsw7PtebKRkUswDiu4R eyNmsKydI8YO0YGEJrtLw0wD0y/TOeVH0kVhIJdMsBnCe+HBriol7jEVuWRv6igyCku7CVRl5ItM DC/zm54i5bOpM7G/DPIbOQf5L9OA5UcSrAHaXMNgwTX7Q6TBEJKHGfdYkMgKfpKBUXdKSB0+RHFg IGGzNLrkNWWFmoFh5kqwuh0pUkMgNNH7jJC3F4zZsaMvZTUjxojv09sdcE4pf8uDEdJdlohz+grS qRBQxBF7WbVLdm0UpVBc4d6iKKYUAuuCqksJHFdyJdSfeN1SKCKcNZ1XaJUHcORjAutNBuq51ioS ku3FxUVpAH9GRic3XCI+CS3krsVh0AHq99/k/2LjgWnmhzBepoPiA1T5pFhnVmV82I+xRh6FL9uf tRAZxYqwlzHYWhGDlaf1gke4Bm3TVKAUCs26e0YmVIEy2F1DokLKqwxaDRgbxkkDA2TxRdiWu7Wt ZjZvLYyYQiAFTH02TAU4PXSRYGsWzg/7VYstt9NEA68Yntk1vkrh44iDY89QFPUwslfcFXFFPAMQ QtSXnltuFvmC0tPTUCkYi8p6unyihv4rd1UjGtm7UvOQuD+OMB73P8uawt27NsLCnG+QFhS+LNuA ul4A6h8KUMsc9qzyd1xLYZwxQJ2fhhgPOToyAgz2LlIDB2+K8iQdFFyzP2G6HMKKa8KiOoEC3L9+ cB8rAPKdEbuLE24C7nc/qhxHLz8TLN+zxVYoike6WHKrKCZiTGqCmkEU4crX674mP9AryMkvFElp 0+iK2zkT6EEZ+HYyHF8tzA4J1wI8n1tt8n2GnMoi8+XVhxReQUblHgMOyeydh8zKv158+ZJx0wT+ OT9Wk58mrilG9N4dYeGgQTLV5qbGSybrNIrYwg8VW8h7ywTu0Vf0fJE52U/Kg8w/qFYNVzYYy1rY YY1GCFZ9f9GRFJ2azfRC8s8UCeXPYPMcO/y7H68+5wZU14ouZPZYNdVnkOqrA9XNAlT/UKA65y0K akUfsueKsADeZRsCBsNcbfmioiJYLVzVrz9BphXPfs9f8X/hqn40mbqd4UzY1zhX7x7H5uDgcZzV mR+MXTQne66CenUYu1Vg7B8KY0tnEMg4n1WmtaIN2HNFWABec4ux78RIs+/nhffawNHGr7k4nrzX 7QJn86ksTwpS5dh7/U2MlD5z+bWtzqf3WUDZMJg4pxDq08sFqRWNW56rj14dpG4XkPoHgtR5B9RF 25bnCrD8A2rqVpu1JJBOke79yrF94UF/RrA/x8g+a91y5eGRD3RorOWnQU9KglqR9K0apxuXuYWt koQoLx/SelQA/R8K6Oe8Q2MtPw1lsirC8g/1JwuTi/JVo0hSee3O89Zqi8YiSWVzCJBjiH0WcHnm zqbYDG0XJZbP9UqFAeyaSG/4sv3V1ERGsdJ0TJZYHhdo+4dC2zlv31grSiyfK8Lyj7bhwy6OgntS 5kKKBZjVKstWeaVhYgG1fwiofel3eM+lW7telF0+V0uFseurANrVSoG0fyiknfNmJvWi7vK5Miz/ SHssHJ3bUhbFl68+Kbz1GlrOFsWXjw6/uJ1BwOWxdHCAMC8ju56fIkfuhu7nlO+6Wa2hOu5XHEIi bDH+ol6Lni3UG640SDG9i/yRLeaPaDdB+DVsP2TDA595KyaFQrPpHML+cq2lTHf035H8kiyfwfM9 /aHt7rQPf1nQrLar3ZjWnSHG12ImTJfPzPO/9lYNa4dPeOF2vHoRkT29nwvb0M0bqB4Zozot6ejh xKyNz6a641r2/WmpWloZ66V7bwg/wfe9fyOZEGqfWZg33dTRdP209MAxziOW2qO+w3/XHTDvdh5V TYdlDqa4MoHHjfFJPuAcB+DPu5+6St8yPaMEp2DEz37ctb5/kHIpVqFhnBmm3qPH1IIW1Hv3NC+W 2wl82vmiYHuilW0xAaI1NeGwVyiDIvi4IOJd6I7O14ASYrbiXiTvmrSnQMeGYEReSHnlDOh1Uc+9 S+QO4OUny57h8Jpbgcw4X1TknkDY55FJWRcLi2eCBM7NyZ533O1klAqxPyweERCANNLHp6V60XGn iK6oIX9VECvan7MqGMIaT1Vwzf6GmSs3ldvpzufwB+vff/+tG4eou4ZMKSsXOTN7904ql/BDkntq 32fg+VI7I9u090hBwPvZlg/BMFcLTAnLBRGC5XWe/3P3pB8MIdsrmiI3shkYCEvcXiFxKbomTPKA kziToQeWuANLW1AkQHkv/el7xu4hRyoGCsYg13iaDS+PWHJKANMZNM9+/3+RtcR0gnnsxd/P+hWn lFv2HxylOx7bwom6zTHCOY1srtxVGydz1VbPYaJUjnrtXqtBrdjwqSu+u/Rp2/tHa2/DD//VT0eu cM4rfzQQE3VhuPTNUbVea/VKfHdJfM5c1dDeGT8fiYllC1xF95JvcJi65V3gfa5OXGGHX8cu4ejM WL89H+MmfCJ0q3Vcqx5V2l7U58Fom0DIvuvo6mnpSp8JR/kk7pSv1kw1mby6CDYsY0X8tCdEXWiF vYEwCWRiUFh0G4vmIkx2WqL9/YaWgHPsDU1cM4SKdVcNw5cdNPCRZd3MVPvm0lVtF1exKcvN+kx1 hrvopmvL0694pfzLhybtjnexFEVJBNcdHFXOGj08viA48TzzOKMEN9c1oPrbExtn2CtED3//Tidk /12vVqgVjEPh29PSnT52pyeVP06Ffj11T8rt5twtKdbJ1FYN/do8LWnQW8KWHzkubuN9zS8mumEw i56W/k2t0P/oxrZ1I3DhxKNmORCsEsC9L/7cEQe/8UeyJ16AaUG4hpi4Z7Y1o4QDuG64Z41NQ4t/ eIvW9V1uYiIZihiJ7vLXy7nQTkv8G/+zv8nPvKkwu+DSb/jF3Wmp0WShKFlz/N07vwjf94VhXAYS FFdW2UmZfOGFyqYLDV/eNummPKi0r7E03kO9e+HdR8gAXM+yttLo8j0nuo28J4vGQ/PjLCh6t/yy bxmLGbYu+N7/gC8xrfc91cT+eO/+It9VpQzHQ5Giptn63EXI13+2od5bC9fbT1wSbNpPtj4mYXWN v3iKnFurcby81L/Cpd1d1WIhJVjvtYfHvUEfs0qSSfQY10NVa5SQa79nUvaHXqs1g5ltsqO0DT52 0/iZmjdbbS3BONNAK7I8p73xWAMQyqK3xC2npeNjYkM5ptsuMZk/1DB9TpELDDqgfDYakTeGKGqo Dvpn7eM+bXPSguG2q+stP9olasAwkGECUUM74b35uiDZo7ofCRDIpfhFS1oGbyfW5JM8D1Kc8T+P WvlhJKHkhgdIEgPzk2NwNg7NYR0SjoUGLyxT1Xj7Nxmpd7XU6PK/XlYM05K/RMth3504v/qf4gQ6 /onza5983yw15GeYlE/TQKhXn/u//7YGN9MSeGQn/0jBDb4nfojSYKVeG1aOzwZbpsF5NLtIqGNg pbqc3hrmj5NL+pLzQqVnGi2pwMdVERjGhCxhGMU5kXhC0rLsyVD/JyEo5skg1hFbGyTkQqdahkfv nKDgeMGDiO9rAvirHjWqg+qAsOQ25UZ0zzhKaaAH9qM3bbOcsQg/kET1Zeomm5q4Dy/2XNonbJGw TeEqgP2GriF+i0QlBeahq0DNulOhQMdSJrOi2tpUd0FRC1so1oS/8399oEBzK656IxR1fKuaLtKe 6RoQ4MLW3XtlJrSpaurOzFFUPMsw5G2dsnKhmvfxhxv3ytzWYWToeIVh0G9NYRyOVAcDCW6KwUxN y7CudeEcKHdTXZsqGpKtXYxCXiX8n9JTaTLnX+SDFZRyuLa699yxlES8uQXTihdesQAovbmFtkgZ q66qaKqpTAzrjo90D7nKkzTE17N+o17ZZerOwpf1pmUKyW3pPEC0+J/eGP9vRFYwPg/0hB0VwM9K 7wSh6s6UJe5jx5rirH3zM6ySA+WyzPzwc1m5FNaB8q9//velzwjdMBfB9xFhI+WLbUGTW8bBv/75 P8pAaGI2Evbvv9UqlWb5bWRVoAiCXSbtF7zBovugAMvZrDXYVFkHDLa4oo9dRt5yGmOOt3ygC/sG 8udKbvqwjPQXR7NsQ+Wdv4LUuSJJM4/sXyapGrkTrvKR5D0I15Pcb64+Xr4NCFP5iwB2h0iulmtM pN3F9cJxmUSPHiDR3Su3soLVd0RI+xwoU+tOQKQekPA0LReKxrqFTaMgAnqIc2/wZ6lgdFNxrBmU CPQOVNUZ2FV8V2dzQxwo+A4/ZW4FqNXdaViJHUrZDVeYsGdirEOTkYpK0WOh+1gLY8z3JecIPJFR J22MaGKIHlvD5xxDAky347KEUE4WdFDvjjKBOwR61UUKA4hCGQn3TggTCxOd9GjhKrTQfDnp4OgF JABnjjBuaYXldvFyA4P8Y6ET1Bj9gsXYRPeTtAROWQIZqSVpc7BbASSQN8RzgQlIg46E4qgTAagB mDFGeYQyulcWgK4gbLyBRNddbF85qmWlMRI3O6Bh4S2oU4eiAsKerDGPX5pCQUnKzAKKXSd198dA d/DhHVI1julLFIbLCyBYNZArimuN1XtFdxgkLCDIAKlZMIt3Fwiu6POFPbfwsQ/DAaZ1Qxl+dwUi FoTj31y+uzi/GL71RQp/6PEDsaKY0Q+cexD6LL5SaYii3cw8iGxijDlGFF/VmYMqLONA6UlMcQnJ uICVBq3lY8kHKWAd3W8R8T0DQ3fiROpji3q5plxA95ERSR5yfeIZpow4PqjmQrXvCXJUKw9AjjQa rtd2mdf7NFSMMeaZhoVj6trNgfKlfKAMx/gPKHcpp7zdBaJCyjhv62fNtXxjJ3NIMhkFlZUuxDeL UIJqRK4IwoBWDXJgqA5AIyS3bS2uSao7gkAgifAlAIKngkU2GwgTwO4uDkBGgeI65t2f0npzcdV1 3gIQKZgThu5aio7BokEIDmtmz1EMIwEd2ZY1GdrwYHgxZhw5N2OXpXQI7NwmSN7Jb1MdNaPQiFCm NEnsEnQoQ8n7dagdwJRVKlYCP9ZtubWq9+kbUb4G4cc2M0Um1WtIVyDovpvS1ifJJBpjjmXSe2sy QU6HlEmkSC+uvgBP2be6JpaoSSGvjERZCl/BHjhpwq/axyy7zmJbHKHqjChbMbJ9tVmpPaA2I+Pf hbzpvD3wuI9sYZ+rxhYbjnMbBjuS1AiwMnOyJclCFCKT84jI/KavPTFcju1HohRCFCRTMggoHl7p MZQApAlGnOqVCC8R7FqaN5bIodJM0i5Ly5UW60Bh/QTjASY6WbtkRkirgJ4jTWZfe42sMamo2Ort mhrS+6e4nQQ7HuwKDLHnMaf4SbA5npPB31DUgU/gboJPAXks7j35kVyBLAV6STEU9utbSMigmSJh j66UUZmYbk32P9SO+61qpU8+38L/sE//g8disN1l0MoLpoXO3dW1pZFzj4jZd1Y8DvldfacXDPj+ BbyvMeJOQRDNVjP7Vg3GmGsEsXAMAVb9Kg2atdvJe8f44FLM4WAZidg+RgRrRmCCjDYdZw0gJMP2 sgL2IP/YWEyQyjOGciM40B0h1w8gXLmUfPXJctk6UarKm+7lp3L1rQxX28jeIPzO9hrUpzUObkFK lS9VBsDjuOkCkUJ8O6Sr6BmUKQT2HAy/ArrI0LMcBCy9Eawh+x52knctlLJU0gxtcBdf35LAh5lo aTpi1vD7I+t6JuA9X1HBSRx/fvXn8l9bx5Vy9fiYUiayazlERppj7j/nXAkmJdVQroQhNGs2W8DP 4aVN/NkENXmeDglL8B4XemkK98qhR1QBadhERidRLxeBuJ7qQD/Eqa3H1NZXEVAnL8PK9318z6S9 AdFShJkoJ2uc3ikTEEZyMEH+eySgA8IuHHWd6NyFhZIsgGSWixQUU5XkEOWfUJLKG9WwqMKBLBML 3G/HpQLiZ7Az4e4RyGj2glyOlCVwRcxQFRGOZDmITaGxAuiN3S42RasIUiAb2YuMSXpzFIdjCDJk 4EUCRrgh5Wwu5gjuQpSRo+rNXy8+vuUsGEi6D+qtesm5tcpnjrahl4MnMt98uPz8aSME8q3eL38d 9g+/z4xDEBafM5RZZ4Y32HVUtUWF/Ehni2lxy8j393PAf05PcTtY1fwMlrY/x3K+Z6uAeFeAeF9U y9APlA94Sbq6j4QeNKaDm/r68EL7PwuEu1naP8hn1XJFOooCLwwt0QOiN0npU4ZUSx43mVne8saY YwLo25Z2A4E6PlAG2Hq4Cq8gJUOJBe9+cSB9LyizQ7lCDhrL8nQpuiPOfUYsLlm9KVL6M+l+WBgc c6u0HiDbiFWzP9W8mbtkiGSNXoXSpkPukmq9fXbWaLI7/kmVCkXGMdV2cp7/at0xJ/zCyYFecsgE XibrEGRZeDhnRiCGMZBtjRbI4nAWc86JJcwEVxqa0LGlJ1N5HDjRyMKCZzMBEMEFZ3qw27v8j7h+ LAS4G9GAe+TZajdsoKkjnXxynv+VnhH9nZe6jGC8pTg60sD0CS4myTCWhiQhd/kMgLJ1TL8LtuhE cqUnSIuGYwmLzKEqLFV46dn7rpwPr84Uwns+CrxEERAZu6T7YIvY97L46s2Hz5fIKbmz7Bv69hrR wDnwKaWAIWiGJDcbNiwwMB41huvesOYryVcSrS59Y/TUshKE4egL2D9eChg3q2URi0QuxOYkRPVu oQIok7lPtXj46E61x8rhoYIiiH1vQLJMBXJHImDUC8wLHDiCI+mKbCliLUHhvDOYWmxeyBQBs3Fh Laf6ktfYQtnuhY5s/A9IveYaefiVqdSpUq0fVhqHtaOrSuWkeXRSqfxHidKHdy20MWiqpExZItWG eUPT9C7jah8MUX6yj/GmjHSsO9oCoohyraQMinEFBA15B4gZKBKQvnX5OUHc3xOSnWv3CA0cfMLM z6GzbmesTxBWhHKKbBZIz2tIsWtWSSG9iPxGVvOcRDEkLsX3SCdJ8bjiSQxJi/wco+mTnOdh1c0N 6a7BpcS5EIigO8+HPWKuCqp5skd4pP2lOyrCISytPYZvcIpoLhbepy0fw6nsZ/E/pRlGFM9SqDU4 2JaLOeZHqIURH5UDUGzHb1LkLGZUEvgrgVgIOBJ0slIAok5hoozRY0YktTBvdYIIAAEoLAA4w8Bj Iw1RVZ1COfmgqmT0NkeUi9MbopPMnBwL2z8MwImoYCFRYj1UaZgS2fbgyHy8lhWGkWeOxHZ0qWe5 e1I+dtSXen54iubkf0av0yQhl53ng2Y7/tyilVWZo86N3Ff1XrdXabUIXYfcV82z9lFrcMSYu3Bf qRwa31o9XOeSQnCyYob0EIw6UkSIpklI5Mh6BTb4pI6CTwjfxuvXQgXxpL48IeLLmAPyX1CMj+47 QDKYixgheWM8J47KCDjAiLu331OMkjEPOOQqiknFXWvklK6VRRvVTdpSsMXr2uSnWW2jSgHU/lcK 9o4d/RrH29iidgj3Ev1fg085Bqbxfuypjt1TaTCEZKTCACW4xncy7X6YKVS6y96qj4xQo1eDJIB1 /J25ADpRan4GzCyVn+H6vJ/jsG9ssUMQfkuO9S1yxNNjvR6gTxaJyC3DwXrUwQQ5rhYiYAYVnVIq xN/0xYHyM30s1GtqgEBJEZfoviNj5LR2qaZCRO1nYhFS8MsQbd8MdDFazimEsUJG+pa89VleivA2 B3sf3e9gbVKspyxPb0CNK2QlWDrbbylskYl1WMv2FOA9kyZn/pn4PRqRatOVussQ+24p8pGJfU2R ZGeQzmFhTjuMDkVLmR6h+kwzcAf5V2QHB/avn9dPc/qyTAbx2wfUvGQ72SggMs8Yts/GBnZkL4N4 UWZsrDtIGUmxQ9ASiQolQSOsx5PSEpfWINxrbAxWpTFYr7I/O7O5ijm0YrDCO6LpRxqFSWnLZMRU 8zNcNmJAszk2YqIQNozilrKf8Lyn8n1l6cnYkOvOK55KEbLVcpXTQlFXoE25F0tcfkFeBKIiQyk7 FFWkTMGQA5ZSyPzo+zpa3YEIdjvkDSaPMleOONSqDq5f3y+MBI8bpNj57mevwcRl9+JjbNxAcV4o XnaRz0VwxoeeB8q3y8MzgVJ4rquStPp5LszzAWXO0VT9S+m1tC6ZxGSD7F20HfMHYKJZQcKA5BAz RPbRYGyINSna7B1X8Ll7eX5ZdlQU8JDcPgSQOrQ4ezCz+ns55BgDvJTLYUs6MT+jBRHkZ7CWk2PN HTbXfhazuXSxfUFrIqRUoKsw1ZyTNkaH2QuV/XJQ2l10mbJlEyJPU3NLUi9bWijMILKdDeUuBJev FgQmaJGXYqKnOy/dzlvlL76BF2CPB7sjL21/2bwwF+owxbJnGogoyKhsh+rBdEn1BPArJOMjP+TQ eFb7TX27zI/cWYKVHMufn6VQ6UPMXGiodbccONEu8O4nyxpz80l6Q1KmW1Y+qWM0sDG5OM6DZn0L TfrRdeECYQOUGDvoES2rHi9UWTn2UFeJEGjNT25litNk7ykGWMxzPwKfHOthsRG+bOnjiQj+HZg9 kVG8/9uX4deP559+Vkol5b8MpSTpq+zTFWcXRH5BgmJfVkB+FjmFUjOcZoBN5uyT/4xRAAtZ/8vk zc+Ea9cbYgr7vblUb/TZwkYY6hMEK6rO0XwcxWEUWOW6LSl90ZsehcZoLmmhE0YP312gC6FOxZHw 8OOtBwk/oGadliL3ywJQ+5BC+bAwRdjntH7OO5BfKawV8ZxnziXgdUFC1nO/+wWdANHVAL5lHMYD 24JToGUJURRdJqNK3CDTWLKfTSiJc6q/5Bgw9mCWolKOGpUDEfpyiCpOGRb20RwJXRK6PjkhVCdt 01vfeRzu+fzQATe7hiQp1hd3J5pTdzE0jQ2dJoIAZTjF1+/gF5ThobqXj0JD7rA+0w3VVgwqjeZ+ 0OjqgyNFvnul59xN6AAHj/jF09QPjBONg0J117Lol3acNXe9Rms6dSbrvJnl6reyFxtKFeVxG16N PZzw5h/WVMg281MY46sjFY2XElTyUhGE3BLcwS0fbomOgcpyI+tVil4pLCUOBNETgW5cwvbqyhzd XUhS9KjSqyvjE+SobxsS91Uuul/D2JIxUaXG/SDoFCHu9o6HU38I6FTqcQGLeSzmhkXFX6gX0INj Z9AqjE64U8cW+kNydZjXL4FYngNAM93EOXiGIiZQxvJWzPwblYfUerVqt3u87Waw3uHscCr9kKe3 +6dohg/ebIYO3kQk8RAUJ3tL+xej2bQfj2t6yRQJB2A2msfHZzj/PFrP0/b+EcJ6Uj3PD75hG2pF MKPbdXT1tHSlo0Gn8kncIV0KXQ4Y2W6rgGjd6efIKnWK089B5cXp51ZmTj+voFFdr9vvpsgkijP4 55KvOQD5Bzr9vD7sDxuVfj9lwTIixDGM4vRzkuybiP3cnX7eqDdqR9VmrDD42UAi2tfufcZOP29y lY6JwtnTUvj081oqFGvJbxIBQjpdPHBEO51kXKPTzwfU0IUbjK/Umidgv9Zx62jQrxSHn8vd2IHT NsXDE206MkM1kIMzGvlIRXRgptQ8GIaOC6uOWs0FtiU8YTDW6DRy2bosKI5J9phSk9TjBhciZDa5 yhtjjj2Ul1OcIIuQindcg2zgjsPuL/3TjX8yLASrbVwSVA9wWmvoWON21vqdyg7pfr+iA3Rd1FQi y5SmOOR+oGMSuFGi9D3ixAJKMDUMPt4YwaR17vH9cSIYj9gPDhQ0U7+mk4ngV3Go/wLNB5mgGs7V WOlwlpT1AkouTkcpgcT5gGhWYM/IwUr27Spv3lvPOh0lZ0ePRHgGPt0End5u9QcAXcMtmwJRGPaJ zr8yvomRBDNrjDB7V+nRtBres3aclu12kN0vm4FF29N6XWnRMcxA6ISS7Elcyta1kCoy/R+f2UJ4 zWe53Wqk16xzssGeN+qtYeWoFmsp/WzobS5mckV145ZS+7m5ckVuOb47J/cif1alz7AByx+w69EQ E/e0hPYc3BIR54tN8bZx5N3hWUSTjpQxpi2d8/1oitrFoAjpI+ktOM8tQh1+RtKDPLejkSYLbcQc D9FPm45cRAAiQu3R4GKygGud1XvNo6NtGy1L2i2IHXSUbRIiUM0HGD6HkJq13lm/2oppylq3MhwM jzjy+6TIR0FIj9PDe5VFXS9ZgrWz+D5HL0Zu8h8Tq4iuQ69Qv3N5QsNLBs13sx5evkCyhJ4vRgZa 4dMi+HkF9BpeEvnJI2rMdjObFLfKjbiPmWrJKqVWbfWBoCgBPNTTsNpu96qNwd56GoYyNZ7WFIRt rpcvTKQ1leoixCZbanexA0fAWk7AsXCE2Uc4UOJu6cGwxUQemYzv4ATBKRR0UQmZjHRcxRLUJDDQ xhBtSyA24OBkTpfpliV5FkcJvcqoY3AEkuE78ubwBMFPnrzEpxCV6DuJ3Crk5TzQxmVJya0cdUdP XjGmiFCL6AepImVRkykm2I9N1zzk8k0MKaiOpuungRtme9YRDJHkBbryjeFkcqKjU9nMhfcg1F7l zYdvq4cO73pGKSnVe6+rAf/ItpbJK86KOrhmfxU1yyGslNOcHw7KunAnh7+gE/khnWR2eCdGh8Qb 3F626N4pnSvUI9Xzjxg4NtN3sMRPtEoh1AyX1aB75zmpwzR5tcXamS2Uy0tizc94iatyNFqwf35G CzmVn8EGAjXHAdRQHVqkPo0gEQ5sW1awoWorDUnIgOrc1g2u2arH4qm7R+EpEjtSrbX7UbmI6y7x Wth+WUfyOzDKUrDlL1Tr7WHkCJAM9ZACksRBgXsef8p2F0hyM3zzeCTp0S5qKAooWUBJHD7vhSbf 46RkG1mnN17a3eNkVwElV1y92QLqZEmuE/XZGm2uoORSor4OLPlVOOgwZ6DzwdDrYPChrLzXjbEY 2YCWXD4cwMk4nijw5EZ+iRTYFgaZIR9yBMGt4+LHCW0NCbG2L/8Jb2ziUUkZ+c/weBeuyTWeqACp vTbXJOi0QJIFkiyQJHprSOy8ziGd1Ie7cEqmRNu2YFXkCklClL4OCBl2OHrI4Oe3BTR8DsAqo1fP tWWjScbM4UQD1X+r6GM603eiU2MK1JpwrwpEidGo7NtQJiV8+PYzl5j4jdR1cxlaDt22AHCvCMAl 48x4wJmsiQCaZiEiXkqJgAfk7hRos0CbBdos0CZ7XAu/5ZMJYSlRXx/ojIKaboE9n+XcW21oBsjA YCGhrrLZ7jfO+q1Yi5VWe9BrVZo96urxpGqRoq4yNcktxSWLBFz0jKUjipB6i9Z6XISO/yKv1LQU U8BQoOJKHDGgm9cL3Zkie9u9EzjCSHXuZzPh2ihtoFySbHqcl2O0ELnkZoFoberXzvs199T5wVE4 wxazRDY2v5SplAeKcLUyLwJaA7rIXrfcqeLaC5w4pV/rLlr7BWlCjqKbt5Zxi5vE12OZzN+qEnm/ ZM3LtpPdO7zVtNO0yak1LGB3TIzKelr5af7vyskxHUdIWJo8KwHb/QVPFC6HsK5tdT5Fx8lYKc7u s50e3Tr2Dn2GadxozUenSyjEAuST0GQPT80aoz/EggvGlmwLb5ejvLno9p23qwomQbHUUWR0dDbY dj1roVjSFUvHK+sx9AmKWFSv7Sq31fGbKHNFjB3hr90TrNsBzZGCu7O8BgG2ZVCnawyZ6BCHK3F3 V24fS61KUHrhFe94x/T5QXyId8RESeyTpFeVuXpvWOr4rfSjxW4HJRO911gwJ+OnBwoOB9Qn93gJ 6v6GNBvq6BKrh+JBEt+UHOQ3CrvE6rZkC02f6xj3SvHQJ9JSPJM7nDyFdtXUb8UW/1jo+96AZG+T zU12pb+SNLKm0orN1Pv4SmANSDpgSrxdaCcD5axqU3+X6CdTFS2eZgvD1dG8N7gOelleSYtZVs6w e+K7Sv19sWWBQKLfj6i9N9dtje6X95Erj8fhh972SQ9q8KRgO5yNxFQVVdHHjS5BgVCN5LN7TPzg fWL9Xr3hxr4trj2XPeVG6Nasrbb2jVzObbzl5fJURW7HgU7JlnUzU+2bZR9g3JlrQhO+aXgtPBIU VLN3dtTttWPVscXOnzwh0QQYLYvV8es6BKP22Ck6BMNOKDoEZ6dDMLoIVfsNNkyTtBEZQUWHYFLU c9VWz8nAHQxalWE/4335wWVFh2BytmzSNiN3HYIrrUG7W6lTa4gkpsW0t+BCzVqH4FbomIZwh+B0 KNb0ShXYkxPrw5ROFwzs1qVouZ06dQjuEaJUvpJx5ZkxERuLAAo9eM575EuP6nGt2+zX0hqyb2fn iqaCtBNe5y2383l0q1NzS/SJRcUb2/aeNQ9DjvzXntUX6dYBg4+cADgTlVxW9r3iNVpDXRSd7gJb HeaidBeMPc+VOsc1qJRUYYOHHHYgkplAB0NTd2bOibL0b2EsIUe672DA2TU0Si3Umo7cEzROcoWx GbrqfKaf4JQq2csrNFY68SpClnvwvSSb/tKZzgb/AZ2qQ1GHYLH9ffrw+XLolSly+9jFfE4n6bAf frmQtDahlVy6+8uRqSdzZOW4Omy16rHmZc82yjZuXsYNzjG05Q8wG2jvouXjCxzgkhIJCyp3l3Ih IgzgDXJcxfGoz/sqxLBwMZGwIGJeRtLQXZx8dsy5cBEJ9PeB43BKbkg1JAXg5d7IbdQaNpqVdm/b mmNJdg90ayzoVN0UT0ZaNT/Bt0HNPdJIMiLRNhbm6WgHomZrMcMU7vILzZ/FRVN4gC2TzltTvKZ6 YJxAn/v8tRknHTdazWaFUg22iZ4LTsqiQy7ESUkwj2kyxlOhYDYfSvKS8fq9Mqav0SLzBxTh5J18 yJZE0Ovhce/IeaUbDTb3Odgs48pLi+AB3R1ZonwszRJueHJzCZg3xRyNbv241awV2Hir5wiSHeJ5 I5I8E6uNBvcqJAIgkio+4/lOIfmJQxFfNt9pr0vjGwQR4ZAv+fn/2fvW5baxY91XQWlXZcs1kkLw Ts2WqniN5bFsl6XEyc4+JwWRoIgxSTAgKFlT8yMPcnbVPMs8Sp7kfN1r4bJAgCIpkARlOpURLwC4 Lr36+nV3nM9Ass95iFsit/TUL4TgF2lpwiBaSkdDNfFGpdGOWDsFvZqrll5QUvyA5VmM5RH4CwkG BVbGA1sweObeJsgLIKHwfJnfyKN1Tx9M0QodGFLlECwtITdte4huIsJih0sPfqYRdc+gKQzM4aQ/ G9KEJo55Ojbv0d+cfHcMmiGHLSCulDKHZu4MqYGJ/6T1gIy1XYE1EUtBfNEYwpUIL8COF2FlXB5t 3VN4jVDIw36kT0+icwmhWNcros2ybjmBlxpVeIBVbI3tkDPGtWmLvI/ptVKLPSS69qfutnsJCjXm 2hSupsWntuQJTgA+NZHjEZBUZX+qWXu0A8kZQ0rbZ3zeeEynTxB+ajwfMy5B9HT6AhKv6JvWztIj qkvwWgqJACSoENHK2lZ6Q0oIa8DpO4GgRGs7FhpSXniqYljSIJTkRT6UOTF/gt5McHoGi+1XxoAf xVmWDBmlt0knS3p7fgn6g86gbFf2SBBnRSglFIwYq9pND4hl0myUKWyfa7mXrFpRMASyOXqqFS7F qMz9II8ElsDhIRSWFvBmZeUzRzxLWWflfKdVy1UjfqFcvVNuNmtbaPjEkA8sXeByf10x05BixKCX TVL/djwonpYCb9KyYuG1+N4vrxA6HtizIequmNoELYutO+QngElzY2rREQbwdJUlr8wYtrOPSdo9 AzWkh5DgGAmB9LnMtRClvxJfoUfpDBmwxt3hrEcBf1TfAQGwSmiNe5T4ZrLF5l1OpyLBFK1s3N7e Eu2QEu9N/mVScEsDTpDnvIthTR7On5C/iBPN2EsGvYZzqIELIxgZg0SEL4oKeQLxpKyCovdv3P2w nSX0yFuQP7KsluT+6G37OiIHl8zkp7D1pBBQtnzPuLwxhKcJxPyAimLJtFvduF9hu7SLpE7JtbCL y9LvxtPgt7MGyJEHetUA5tXu+6swvt9nIsZElOEvbfxuacXjhQ7yeZHtmihlljLbCsVap9Kopg18 OgTVFgTVKHw+mTlQ+5FR3mcNQALXRgaDnqETeRwVASbkPcvcbvbkAqHT71tdyvXG6QMqGjeRKMFN 0C34adC0AWjpafRU8SxWNaIAdK67gATl28EMpUrolyOHIPALi/jqJm3O9Bxy8YeFQ3iuhWoTyiRX lrYbH6fvK6Wt842FXs+iXTaGynkf2gi2knuftl2Z19IcbOPzuSPdd1l0EUCYhWK+2VFxmPlcpZVD jjzpf2tlMQVOoWcQzV6mdnDD6/IiLdn0c6dijdgj+w5CTJEt5wiBB36C6sb9wdtZEM8ykqee5ut9 RK8TfAHVV+IPREGWsUFuMJ4+m0d2X9nzlZn1drYtyQFmUIEjv+JySE9TJhU28auvxMHpUa2QZZQr tywtvxKPn3vpi3Fls/eMguN1SkSo2YdJSC8yhP1S4n7uRUD1rJwIQ4VUWWLp8HGxEwy4QK8GmDFG EkesisOFihzosqi/Qw8InuwVYVLWd2m1Z6ecYTi0Jih0pnVnDsoTBYxhuZpmxXIBSMjGoWRMqPU6 J2ivkVaF8yhx117ZnnD1nyp72WX1n8nkFMQ4Xy4oqACEyzEOeiSBatQk72Kh02yX9Qh49cUppd95 hadMqbOL6vzAdX+o8/MF5tuhzk926vzonWKl2CgmlQwhJnao8xOu81Oq6sVSmeNQaWaJpszEccoO dX7IVbSMjrd/dX5aedRlb0Q8ZJVyo1MrdjjCtJaHTHXYZ63OT5VD30IRC9f5YXddXDFG3MAqYayC kEwXz9f5iXcuF6n4T8QQCZzntZQD1y8Z/2V9Mhl6NZYJlfPJsV0bmrO2qGqRzBsY2Q9mx7FHn5Hm Y4YV5dp64V2cUbGn9OBCqVitFHN5LirxeO79Fq4h0HMt5eDpi9bwz4izNKksrbLlUPy9QZPo9F7z YgVGApYq0UjQO81asd0hqyMkX/LtJr4oE7JyPe+3erZXrgQVIuT1YNniJG68VHpgywWe4drGPcOp xU88nxlqiMHdgYCeaTiobYFeC90Z8IFUY0q4Q70LifgSXMK1jbuEU5u2q2IhZ1QfZ+ratgTGcc3q 6DGT7CiWuc+nSqc31Hjmz8EKZYhhrHpt4y7djc8PDjuuakb+vp7hArjIQWeRO0k1upD86F+AwDXL E1Ar6hwFwgZx5s8GPHjIIiQ/Hgd4wg/TBO7fRa6MAMgBGMtuQiDlg2eSxIInUH3u7cAEQw5fFNmN jBAKKpKF1kNUjJtOENzvK95P6fIcIcCPRaRMCM6xjV00P40ATkR4FGdDg8vEuUCYcWCfFibkWFUe zRXrZKjpRLububwFtJlDa2S5vAvnqlYDjsNnj1jtvI8L6H8I8AZpOyHx9WIfVxCLfSZ4y7UdMbTg hlSCtyH5t1504jn5l6yLQOKndLppx0SBidB0XguIOJ4vK8SOc+Q1GkHOILiMC/alsInFtJ2v12vF gk5y9ZXS9nro4qzStp5L2eia1yu2cWzhgVuOuP24mAiurUTbhXqlU6iUXy/f1nPr2afZJe6UreGd EfclM2mFD+9HCNfrUgO5gpj2OoeuVWnmc53XfOg24y3YBtuN05b03MZ9CduY2tIShaAa1OjRsWAa EMAYpW8Gdg9qExlhypFdrDqV2rlqOVch3fl1qk56bj13S7bEC+xnu992HNgc7tPEvDhCa8ERO3mF Kz2wG/Tcxn0a2zkJC2ojCcEUV8QfhlTcSsHDuyDksDMBG689kluBzvfUHJrd8OGezxlZZO/ny7V6 pUmw7DQPdsrhUD5lPevhikqoPxhDtGsp1/KoGleR+xXpArGbrQokThwQScdgMXoRLIFX7JSLsi3C ItEdPHMKQ9zacxEbPbee8e+Pgp7rhWwK9FM0g3mfEFpbVHJNjt8daMR0esbYEPvyIrCa2FTsBYXG 9Nx6pjtt1pKe0e2w4wUAqgL05J0BqMRqBxTu3g1p7fBHsA68gG8Nu0ENGig+egv368VRgaWkQ7UF ox+imJ5bH3cHtnNxRL5aOtz0lL/ewB18ccT3eJ/9TXzWhcsK3T75TOPSA5aKOFF2sFSldqFay7Uo SBvH55heZPeZBbLIdd6aXItSSqp8XvYrwo430S/5ZmJ0KRjAODqdnQBCV+t9Y7YCHuwhttwu/2ZX kmh3IcFMB75w7A4RdyTaYwZ1cYScP5ve9tHfBmH4GsAnOUGFD/UhylziKxaqYfocABJ+jeaYQiq4 cgwqILZcraLxJed0xS0YHrsWjiVl5QHD2E8slSoh9Iw7Qzv8T2oR8pj0h70mOqMQ6YlXt2yV3Jmo MOtduTURFjdAaMauQ6w+Qccmjci/hqWHkLY86A0rnQvHe/n2b5/an99fffhJOzrS/meoHSFie5TZ 4e7J8ibQ69Sk/A7XXJZkJSARZL+M0rUj+OKWFMc4Kk5YZsAGghXGwVN1NpKLkIcsHsUfocKpIqnQ 0OuVfIXUtpBIosJ2zWaLIwhriSQVfrUqtDLkdtHTiGIkUxWrlslNDrF4C1JldKGNzEM0pQLjWbVw k4C02WzBHfyTYqsiMDmyT/nb8PzXcygnCom1lwLUFM+USnM4UKwaZkBDCE0zDJ3U9fXcyljFhdjJ W9tf5/W8kxtZtss/L4JO3tqRhQpTi8T6Btg+Xd+4GzIl8EWQxn0SLo2fAOSjg0broDKnXK5eajUL DZU5vRhcozKnlbGhzhZRnWFOsB4QJ5Gk531+qe28e3kT0wwhYAtLemDSG08859IebecrmZb3jj2b TLUeBs3ycmXFddMjHdoTGmcISnc6NJ5Qxz8AAA4MpNWa31COb0pYWgOzmaIhr1ciJzKvMF2t5xTd CV3F7yNhK5X57ZDSLgnkqQyGhaEvlzbuttw0KSpoWGWiO1z1eLpAyj7hbi2Hz8I9wOTUTxda86lr n+IP5BKy0amrcN803BlODrUJxi3A9+IrihGdIF0fxadGI8OxfhGFphCKEAWs6fBRPSsvTx+fS0ZC wWKJYWfgr4LKC3qoWKMJwO4Yk7KMS9sZG99pH7OsNIHFIinjjRfdlVKnXc0XImkdLxbdKbu6WNte 4JuUbpkFEj9Zn8aRT2mHaIWF78SzKBRlOs+OLqEYg2xB3F/N8XycTL2HzSpxj8FOeWmYeL8Q0kLx fF6nuK8WJPYUOq1yvdysp6y8fecUsKTqtA2yBFVaXffyvx7OUawPlfQQlvvHN3KV/8PScwUQ2M6C V2xKIHxAOgr+HCJWoVCJCKogUiEX571tfwWr4nhGrlhnXtK3kI702UbdAmYTDBmhd8GXTXs4G41D 33sfCF5kv21ABsobshSxyrf0Rq6TZFDykhwiVnAEkv/2ChuYrzZr5U4z7RSAlJk46Hc/I1YDhHcc DJ1OoBDDiI0jLkG6A2CItvNER+w5U2sv3OdQYvzZsn0NJo3PlnBRl/RKp1Jok+UUclGX6s12qS36 Qu3ARe2rhMmSlpWmtX3LyAkHFcT4ls9Y54orAKB7eeQhf2E+O/5jz/VXpH333tBriCLxCRF6yDOR X89LnHhc1t4qkOllianV8wxhvNLFHauQveiXznTyqN94tuktqfNq1n24fKIOuARxDzT3JmTNtfUV iab22JzSp0g2Bag1n9MLp7niab56m8udl6rnudx/JzOVF4xdbmqCNU5WcZ2Haf3C5ZsX0AHWN8Yf DARjGwKpqXKCFxuVe+QPjqW2DXtypY+Ezcop5csqJyE77goDnRFHI6B8PQ8Nu3uE7+KUGgsFDh/R wdn8ZsADY55oN/Xr9+gcOgVCjWsORCboyy06ZxLB9rF+c3VzNjVGw9Oujba5+bPcqc1nbpHgvnGf UOtVattvPeEvzGtfoiy3nTPvMWMcdvGEZFlDDOzvwZAj81OIandDHNsNxzS+YlnQrY+Fp3tJa7s/ owUR7M9g7en/2dJgH4yxNR3wjq5KtQmi5LhpjKEd4+SenWg/maPJifYOrz4NrOHEdt0T7TPekbxp n2nXaEqNK//9r/+X/ele1gMmRMP/5BUqIsc1uWP5DAe6gX85Zul8nU2096hSNDPuTe2YeNob7S8g yZN//+t/6fvu4PffUEerdPZGWQiIWp/BJapOy/GkNfDd4Ezxe3wWzDKQPKI6Bir0Ip/9gcrqhnpB GHc2lXOAt/7uZ/JHATtMrv3jo+7QsEZgzVjCo4DJH73R+oAtczHf6XTGPbFxt993glpEwPXvaWFe hICaVxiqAzwzEpDXSRYqwfS5rjgRjT8nCgYChk21N7wohCZWBxGNkSkWhO6wxIqABFH3WHTrkDEA qouC/sOi/rExxAqfUgwSC27iWu+pTwibIPZIdTUeLL/Pn41HI2RJVTso1BKlwjiFr1Ov1PKNJIQx RGAKpt8iAEClqFdQAREFbZh9eb4hc4ifZkBPfj08hnjaFoEEiozf+O+SvuEbMNHji6hc30TFI9HC JYhgT2fo7IMC2ayNzYvSsFG7P1AIz8490b7cnHb8aQvp9HFijq9aWtMeo3J6XBv1wCze+v7Fc2X1 0IYkB87DQTVGcffz5STlinrQQTXe6tJ+f6qxr0jCwN+R3hl2/O09JCnC7lW2GTgPfcU7xD4VOUFO vMw6FL7cKCpcRA/OliMhEL17bPX+JEzZJozb6+4VLODpAK/w7k+oHTkmK5fe0AGun2kfjB708zFb vqqioV0DIwgjcarpvnX4xLZh7RnbMKyD7Q+SLSF9Yt2sqpRQPezEv1oinwqL7l/mxR8iZ20LCr0y irlkKkFgZx5hcWKVcgdxCqHDso/h2VSw73OREyj12Xyq3fFabDKlA8K7zLaMTwHMZb0v4zc/xUGv 72GUQ0ywdo5vjK/WaOYYJ9oHcNaGY/SG5pNwNnKQTXBcdIG+hmlnOTYqBTVw4bUNH8cIvusTjZg1 cWR4It8ZuBV+yOe48bvZ2CR2rOcFO168jFs4+wlkCQgtuUV2eLKZ9LC+QVctOBeA47VnThdFYP1g I41x56u4kNSo2NS8K+QjxUs1+EJYgdz5DBLo4CBIqcIOIR+9MgGLInHYxUCczwnSz6h6X0F7Gkmx wZW7PGb+KBLYZHYGm0Ch+yBA5c6/EsH51nB6iMO1IP0g8SiUEvAyBQSidVByzaRMLI5Tfey69p3p HMQfRwie4SPJhRg4kWVqI6bDVbMoBXMOxiGCaRRZ7A65szrJS4qadYVnnrQW+tboik7qKCHtoGdK JmRpwjk/SKL0JNHVaevMMt3+aXa4uyI6bSLX058f3dM7VO9BmahsjvMgMkMtS8mbWR9PQ58wm1sx GuLpwX+/ep4XpWhkrjjK+ZiNN25xrvZz7Hzq9nPoYBX7OXDB316JYhhymzQBv7xDhTfhMyF1owm4 VuA6geL47ubjB+2LeafdEgpaO3735faN1mB+Lz8CRApl2uDLJlXF1zFZl2yZXXN0UCaXMUoP+tTR X15YqVT158/XG/P1KaG4EHQ4f1BdXlAa1i+SB61C0q8ol7cP1v5BddkaVMZTu/ZYdWFmcVBeliWZ jYWDhMay1Y148VwuhYLFQag5/crDWno6lY8DIuh5kl71AWXQD3rVss7+RU66GEoSkSqOqsUAotG7 vpQrNAn/GsqFLdRzdb3Q4kTADQOiY/sIWCitI/HQVLQcx5QjbytkI24dDx0eMhc5WHnIGcqVoIDz L6hVbWif0EjWHu88QSGr5gR2fYPli+NcW2ulxPjDnLci5AazszO4jPjITtA1/hAWuDn9a3YHFUig xwwbCkDUyK1mvw/K7MRucYruzfUVjYQMLu1YciUOAUY4FDto6hPHGnKorxABHnrkvD2cWAKJ7Bjj krC0cekjKsY4Mwu485Ccz36yzaL8Yc7zfMKL0fEPLolnBltAggVDuGr5WL+DMBLVs5YEACVwmmwL ozh4534KpZ1AOv30a/0g6UStOdNvaCLL88Wz5yXAnctAJ5NIdQssM+G4H+TicnDJQOIsxEoGl+1e NsZTMutnGRhmAj1mW/yEwZFJZznbtlCKgMikBdgdM8uqlWSNu8NZj0rnB+gAgaZAKQwqq3YwmuKl sc+nss3L/GHOG03MMUq5g23y+m0TudV77CjzQVEcpWudaVJaLAudP/fidwIm9WfK7k2C0x+kR9Ty uDwjnXGH65Lg5aNmFJvD8O9wvsk96BOU04Ox9GJjKQI/i+DmA0F6MJ9QTBxV9BDFZskZ9VMkUGi2 zSdGmyUd+BTtphdD5N3LABy/H+P1UWX7MVwJgt+PwYaA71sY8AYCoL5ehzoAa4LdJQ4rZMBSOnhz uEhlSfFEv2BRLjmpsD6fVEgf2einJdIM/+SgluuUtdWDl5xARWtIn4N+lLZ+NAfPP2hIHN6UvcDW oNGDhkSH+6AhzePUUhRXKSyvj7XfgsqRwnD3XkdSFaNQ+p9XOekalZOooQnDyHzAepJetKTSsQfq 00EvWr6oToIHbb7IOMQ4QyljsPWlTqnd0msRbP2uu8tgwD62nltCrQxU3ym2vrBWOkCGsPWxGciL uMfuorAHKyBtK+BnJFOcPpp3oqfuIZb4+mOJB09pKiVa5oufuJf75inF2V/E57NltYBJ7c9gGXvz GsL1kZKwVMLkAxoX+UVjEyqYHJJfIKiX6FmXAD5CDyK0eVIK2pF7fGS4u4ZzuZeizyCKubLeSATx 7uMNav9eoUH6VFTce7RQ0zWaDqWpRYFlgg95ylVwgkgDIf14hCzsW/szQpXmjYueSr6VsF7XVNw+ RiHGiyN6bqFUrFaKOTRgZeNB/JT/Ayk3HF2uY8paiZQJZiHQMl2DukSinBB3tERXLxflhfBRDz3F qMOVi6LWMLxoq4bWyEJ3K42aVqOxmnl2j6KWb29vP2n/RNuwJ2pohYVzkXn7Bt2yeJ+pFSX6Xznm P2eWY45QVJHjN/RzYmfdwWzKlIGeWbY2MB5QrRj3jPATXKTK9z1hv8XqR7a8DcryUq7lLoUtxfW6 Uu3E7Lo80f78+f3p1OjTgk2cRWJsC7ZVAsmYU2wiB6xW8ykUao1qVaek+FC+/ot9Cin3T+dD3rMe roimWMd/Ns1/vQ5cz7kiknsPY2AppVfjRE1EysmdbX8doW+iyj6594xghbJSk9kVbNC7Pnz2qrIC eow/Sc81Og29Qs97XXu/XuePbO19iFkW1ytZsQKz3AZZg6qtLsTGwznaPUII9S6O/vGN/CH/sPRc AZ7DKfUevjh6tHru4Dz348C07gfu+VmlNHHRG/N84KBbzP344qgLRodqqvzR1MVj5Nf8AiVhhiyJ L47+w8jR/+jBDrD0uLDvnQUeCM4ZQj2evkKnjlbMvRvKPzLt626I04jTPTT7bgcNOalcysVRgQWY Q0OMfogGlm5ddmEmKU0ORjx18tebidm9OOJ7vM/+Jj6TU2IKxKVfcMfjxVER6HC6F22YL4563wxx yPF9EzUJbyCJKW+Ar9TZ8Rp/ITALNCEavrg47qE8qKSvsTTyR+Wz8O49WBOuF/6WYp2f2becqfvZ xsi5YAmDKOld8GXTHs5G2EL/e+8DvmRsv21AIZU3jO2/iHe6P++WOe061oR6YHu/PTSe0FVV7ivG 5W/anxyrR/O+x1/8iphbGYXrschiQt4VLu3ufFUasERSnK4wnqLeKNdr9aS27kwvXufNZCHlOm+Z pL2h5/Mlf2bL7WiYJ6xXE0ZOXg7W7fLQu3LRugvpbjrwhW93iAKXRJrypMHjb9NbOnwXR7Va4OV8 qNOZ9WYcJvMBOrSCnL7KEckxTFgUeeueL+Wqer5MRy3DAgqzQxsrHFHaUPnm84xYmeG+J84qdvnn btwyyJ0I7yyf5dSDKC9j8R3+J88Oj5n4paCb8Ng3Hk1Jexp+ZUZsjkTOihqN68Yq0h8g1neDNYE2 ON75nCfX7r4wRrHB4SY4c6SGILaAZcc8QCTZ7Et/vOviuyNjvEYVri5z7WWGKK9mBeVO/Lc55b8s AjzOFrCJx/PpL96neelKm/7SpFAx6wziMzARTxRd/v7b7cfm77+tZ10vM4fk+rnBsIMBJSyzkkiK q3E4mSagO+IdCVT6I/RKqCMkX1WZpldq1Vyx3EpZpk1Ub79pUFJpQUielQznYpFk2AvFT/J2MM0k g/OweIts3yILWGH7Ov3uGXyspAyelc7yYqoxFjDu4R8Ni6mUvU9rTxekcomxn/3+m6gMrhC/Sl1R Oiq02u1asUyKc5q6kUpHizrPx3pgnAiX8c4cSCp174hgw0IH2fzvYqviBUTQOmji2BBwsDV6Zh8K IQUBRmZ3YIyt6Yjdqz0Lkty6m7lkuJHrfTblVwrcXOZ9i6/Yi6tQBRYS9qADjZPsL6+luSw/QEc3 s914DyUSQi0Tw/5zf0NJWmSEqs+0OnI4GKvoDhC3erSmA1A0YgGy25LB3QDBfxF48BsaUjzBnCIu IeSHl0HRh9tEQ+sm7bPX+fDjI7oBI+jUj/lYM4ZD+xG/BUqWv3ai4eYeIhVdevZYqysn5sZ04HOh sVnT6czceYwtnk9g2HLp+ITTcGlJxCKfaV/Q2Sr0wfyC08XEYdQl55WZYAPgFKMlM/FcakQhn+6Y QxMZMm6w8mKxTrTHgdUdaFg3q2/RxuJOKGZWz3KfEGwKPenOROiSf/oB3xLjEu225C/MD2k+/hDj e84VG51co5TkUgEfm/fIiI9aZt+YDeGCy8E5UMiXG0esZAk5sJu4wwLpk6wapC8SSXmaVzgLuXyh 3GjWU1YUvuuVXppNb2P7sesLHOvwyCiO9WKucJafuDHu9UkXh6oK3MMyzvYxWrsbPfi4kpzv3W73 ec97DLmWau16p5hLOyil6rVvb6/ff3KIsQGTAQkWYyeVqvlyFf+RNpQ0U9e3XDgeKSyXvnXPfYCS TZaK+CqsCyT/cqJmqin/fjhV//0QfDv3laJxxrOVfKmeaxQ6e7xPqa7ur8Fq8qvQ+9BL8dUyq6vn i51GdbPW3UZPQeqr6+uOWERlBVVmvPCcXP76h6H745n894d798dfI7rkr8qjE0g/39L1DrBHmzS9 92tzNKmDE4GH6F28DL5bZnWLjTrcGrkNO8g2KQBSJ31mG/I/c6sbfLnM6laaOTDuSudAu7xuc5Iv WM25r5bgDJV2u6GXmwfaDZbRf/V//VfyxTLkqjda5aZea3/X5KoQ3grSLt4PEd0Gbzeiny+1PdVm u1prbDYjcX8kobKEIUYtPl9mQYuwOTqV2nfAQJJLrCX42ZXFVd+stdR6s1LD/9P2i2zR0ExVz1BW dK0FLbeK5QKgfN81rw6WUdEffj09Ve1tfBD8+0Hh8PFGR6HaKujt9sEiFCsMClUWLUWxqGwcbVJo 52DdKD8bv1d6uVQsVuvfARdfildHuUnoPb0MG/bLrG6hXik2G2WCAmwu8r0/SodYTRmrw3JGVlfT ONbGp2aZ1c236o1msZo25nJfxWJoNcUS8n+jL5de3YJe6+j56sH8FssYZbWS0yosNhXOPvdDyk94 XFwCtsIwcgmJJrErgfgIbdvCPR+P6MXdy6G55YWvA5+PJQwvm4etV9D3+XJpLfh9WW9XGq1aEkui kKcr4zMLoG5L70vcttL0PKRiPGg+lkJeBn8vtGuVVqlK2UxpCrpNRG7j1gwH91lwVlrxUewP/xid ZPmjDKaJH8BGsK+U9OAljQfYV12iD8PYV/GZN2RQFrCvHet+5pi//6afa7eAYnB8kOAeXXM6jYBi aY5Lo03zZV1HQ+Y9IKEFR3d7dLSouOlytBVCPKZF3IsGtTj4X9yz4H9BL3eaiP+nTK6q8nkAtZLy 40mzS/RwMPt9oMqQ6U+IO8l0NMrqDyPKfBBfLPju2CC4K1BoPSDxJH7MvvsZj33jYdF8O0/GA48B 57MmBDFEWYIHy2DMmbRj8LRHJDlq+EvINP9WYcsc02dDQm442p2slCB/kwGzEnXbRT2LcU/R9FRl cgFuKyW0Mph7vBceCN4nAtPRTAhCR7jhN6jMAnzlvYEKD4+mX3TBQB2Ix4EJDB5BCCeTodUVhanF +lLZDhelGKcT2yEwJq3kbOw6sym9syhXdmT2LMMBzG8paF6+VqoijLVZT9PhECqH8JaxrqG9HRDl P9oaxD8OiGUMg3oyoaId03O0YHFNaNlAbRKgvGe4hobS5fcgIcLg0r2CWgC29a+UmE1KowXxyOeh foidzbOCQwIEcgwfoBnTx5JpdI3x2HbBuHpW/0mcLNA+MME0UXPctXt8IPgbRsmeaa3E9YqsDG6K jkGyMfyqgNHST8prBAb3EXvIiOSedoftwSkVZzKOgZ5pTXvcR04sbzZtZ7BJGd2VkYFJDac2WLA2 Nk0sLqrLCORw3AxpQVG3pms6Y2yDcYe0bd6JB2tq3VlDiTtGaoPcMazdWAD0aPsk2jgiCGzHx093 8Nr8hh4GQ/NECz8FEGiDOCGeMLW7dJLGJk6W85XY74gS+GkCGNkUq+/gQvR8f8Ad4Z8/0z4AeA2s tf1oAjJNktLI5q640nQwhg5ywJ68w01iVNImRKInfFhYsuxAVR+s8pRWQtIdFgJEe/v+5gTLRsuT QJy0rXTqKLOl6w6fsLpksxioO4Tdw8/ie6pk1IUYW0r8lAqwe8ulzbp3D+InIn74BChbTMyVtAch XOiAQ8ODEoJKUkQZxHdRS8zqeiRGRaSmvOdTpPzTEccDwHWdp4laMSo7OlhPkyqU4DMofQU9CxMj sjU1mgbnOwTzIE5Ea4AzgmQIzFEmcE2fRlgWHADIXi14w3O37x1jMng6Y7u+O7At1OiCsiryL3bM RBYE4S+D1DWcYFY7Md9HVHhAetsEer5GXBnLxPyVmMfAmoB/uI+mTGQh9WXKqTlYWEI+gzmE1vdJ A4IcawmrwV+9ryaST2A/jHe8LglKOyYwmd1B/9Yw0CWV6YJezzcbVNMh5MMr1hulUqvTxKfr5bkc LFqqfMOZ5NH+Z+4laR+B4qvyJyZg1loCKsarof3ERfCQrelAFiIragrFGVuMtCzQKPEEKARk4gpy fyBiprpC0CHurDHnRYVp3/ES3cQBYF5Ih4V08qCzkPiSa/KRMjWd9fvEHYTcNCPI5BuR5UYKJXMl KDQi0SubZ4VUCaHOIr+MdQmaPx1wLmJI2hhVhqEPpS7ONpA0RkL6SmR6PZNq+VD1KL3IldDEkl4c XVtfUS+R+jDQqYIhRBVZcnrhNFc8zVdvc7nzUvU8l/vvI3YML/AOhzx4qXkBMGqqG3XJU6UZeR/Q a+B4xCc0qHCa+np1zHYxP/eS1EZyYijbhWlxgYTMiHyooQ40UxNlM6WUDxi657aKNV4glWDn+QTt +IdU3q/IfVD5mbIOyraKql57QbYJcpD6vrJiT0o9GUOBD0tDwilzUrlUvpOLTj4OPbgCn39rGlmg MJhth345nsyioal1NpBGQOWCHuGAQUm6Z4pbUKSnyznV/7Ay6pYMasVSNvDMVMk4e8dZ2SkMLyah sNAu6JVOPqKBvbjC6UEDS9bA4l3et6xEhb1GI0osN3pIUO9CRSBmIkwwfEo8JY4R/+eUdQjpdPg6 th/BlWGUiYcQh6E7fTeRUJrI9sId9NMDWDLm+ITZN0STSz/Nbitwd9IZ4XgTH8PnSl4jKno8HCKM QaYfzDaF4DIj1uJWaqodTzFhUiaHtgENzEBqHJWMRLTFNJD77xuh5Gsm4QbHEBl2WAZe44lhUYkG 1tGkAwfbg/rRtI7g44GjB6vOKrU17g5nPTLpuqiBicICcD3D2HWUt1CxsWGLdFz2OPn+qshegkzm /a37sytsRPikxpPEirJneLqUeyzXaFdy5WjhhHy9XajUc1weaa3CCQd2tgY7E0XW/eAbE7VAblij iQ1uhpOAWpawJGdDA6cAThJcDKea5zvhoASOpHfMAtwH69JUex02HrxqXFhlLNyr4EpCkZoYCA6B RU3n6rwTS2Tn7p8/X02jPMsvNwMzKVQ/CEgRQlhlun4QjXGP23J0LHNIroIT7fPZifYn03WfwFHf 4fW1fT8bipcd5wkFG76igj99Dg8rRXBPtPd4h2qi3cGJ9gkvybl6e4Y+AYimONPT9yakGJp5vKXa UFR0WLulkHAfRs4nryrV6SnTxB/1M537e7ybjQlwVKvVzt4oDBR6lE8jOzEm4/UHTBpNEByKi5MD 5I78jNTNolycOUMIbxHfU2YSmohK7MWycB5ALXBt54kqEs/NVNX0vaJbsjLDanXOVmyj6V7+HcWy aIx7TOzvwAD706k9PtFuQLAgztvI3igmX4qrDX0S1arYGFt54aE8NkBTehmdc/C3kBdHjV6XiyJc 3CZKAwWKluAfu659Zzq/o7ZXrrwfB4m8mtYw5NUcwxmH2uRUCaonuol4Ampoju/RYQSqIkuSYxFx n03pk7jmImOERiiWCC8m34DLWMmHojOOyqGQJ6+0XjXruSO72qmEZg/d1CtiHoJvLqoh4TnuDMdG JFXLn+A+omvvc3qd5NArrVfaeRfTdC/zuWJVObCYWNaceZ63HooWbEbHJLwZSBjhyak9Yk8T3Hb3 FJhUZqK64wgcu3rB091siuBGZDzxBEc2kBOIwzqolxeZocJct3Au3EvoIRJCyA2JyNIBWGKsTUco 6GeqbXMyR0sMvVPACl7cSIYiDO6G5AWMuSGSiNcQgJGCQTRLxDR+McWsha4iY8hApNiAId3hOhkR Zy0QMWDsHiJNuPPOJKVmCsOBODNKGUpbmpwbgTIfZbpLmYwFwPnqRR1g4HAM8sUesE3kETwPAgcL wnHl+E+JZrT6yWXFYIGLeRuwbdD/ojrHjH6R7c76Zu9U1jkWumdMjWNcj1nRQ4ktqQWniygAWCl3 0sZU73732VpdOYySrd0PU/N6HatWkEPbIGxQ34JihPBPwbY9dPlBJOjQ5Ycz5jLU5SdXaTQbnXoS 8JAOmpcDuEBMpdrlp7QewkHIAm+wWe/yU8rVGu1SOeNpjtA00uzyg0zY7Oku830wAj0lJKm46cDq etfWJNX8NPzePljzQ5cfxCU+mI/aZ3tkjIkKn0U5xS0o6EG2xHn7t0/tz++vPvykHR1p/zPUjhC7 OHT5eeHyJrSfmZqIJyGoKtV9YeTzwdpipnNADocuP6zJ0QaoRle5o+eanXbaJrcapX27fpef8noO V9V4SrYn+LpkL2ogVTxbVulwW2Y3qaiVrXb5kcW4vbvacMBKXwDu4R8Ni6mUHXtrT5dwX6WzAnX5 6SBNCucXYBLFXYcFwcCTLPhKIVcsNipRBFOh2WwVmqxFH0L+xlKCjH38shtZMnlSvj0amRIUBvlg n+BAbiCZijpVYifjY5O3yHVQdpQDAj5xrueoWkFhelaELztzL4zhZc3B8zTj7FKBNp8iNm2O2Nfs XUnTTgp4cJGujWqKqU3cvYSjjc4m4gcCuypzMAnUrDrXvdOaGfiXSBWH79gimImaH6xQJTHeeWFV yNVRFZp7CIdyVF7sHx7PRkIpsYYPhNnnbA15+PBd0Mtd5w6/GFtwBzN2almMyDwCq3S4uUUxevGi KD6fRMUGrxT1Sqmqo0YQfyeLG4BE/SP4GryF4fm8Em+h5CIJXBXR+Hc3Hz9oX8w77ZbTXRD6QssO 7fjdl9s3IiEnwqHkBQQM4RQ1vp/C1u8+3rSZR0cY19KnOFn+g8hS40MJiv9u2tGuIDWuPHswfiu9 lfcvY2XnWfsllIuzneUHcQRDnLNsr05bZ5bp9k9tijuc/gx0y+kjcVjlNikRM0ZYyhDNu1MW6Gyn K99kf/D7TWAJ5/tZw35NfNTKp2ZFxBRohxPb/n4ljwG/iyeijE5hbLN6D+gkskaFaiEnJQ77K5wY s69XOC9iyK9wWo/m3SucFQsgBrh6TIQmOa8SbIttrA8bleNPEEzHnJQMLDdQsA3H6A3NJ4H0Jq30 A4BHxldrNHMMxshG1F3Wcxmt3UJZlZEEmup5ATRdvG7JoK+VhcJaSMkESQe3yrLe611ofyy/kI/h knXBqaqPSBbW7mz85yPSo65aVKkJuU8uY/A53eMs5nQKpZCMbSqk10EH3M/G+N5UHZ3rhXdhbgjn KD25UCpWK8UcupGx6PJ+zLd714sz7sL1lOBaQ45D16AKQjD5BM7TRhrAWKYRjymrhhIegAqjfWLo ISw/gieZ2rF5do9Tx6kwcXBl3mRK8WP06D9n6DDMycsEsKSfE3BLdwDAM5mPlI/jl+WzR/gJtbIN 9txb/7mND/uqq9KDEbgnKuziWBnMtMI2befML+aEjjlBYQzgJdkDLrCLER7mHRv8jfFU5crNDmqn NOAPCnmqSvlio1TOMaWv5QkP/E7PeKrYvYShBTes6qgql2t5vZrzGnzGR+22zPdoreVAmKAyMahk VzucQhFG7NWeiLrgEVPx+GBlvYBX5g5YglDNtnsI+yCwAgkaEolP/5qMOoaC8c15hQQ1nl1T2bt7 lJ/Zq+ns8ZYknIV9daUg6y9CSZvI/ltZD1jfLEpS6I4Di+dD1CYK2UooJHCNkJzl2NDDGrjwGgWO LUonO9GaeEvmU/tMe2fAnEJ2YUQmeKdR089ybEChz0Z3QGl6eiGSpucZnRmRewlknWW7KWmniRO6 HkMXTD5zEtW9hKGHIoSceYPM7PbN7R/JCj8VISQ/FizCw8qMMkY4KC9GVUp8bWhoPBGAgXI5RVWC /FkuMn5o376GxKib126C0PwjJkfGdjHh+Gdbw8OSXi2h5IUv89hCxpZfGaKq6kna8Se6DzMAHDei VBxCfqbTM8YMGFtZGUrTEbqveqrHPmO1Ve9LOiuv0JW/E81VFGqB4npw+6+Wt7ACfEW4/WO0A6Ev kNYKD4CvK6UMLTamXcu6ONqy34908zOacuZV9AQnBYI0CAxQgj5HB9giZJiXAIGhnQFFbeCz9x3P QRcVjj5C8YcRiQugM1NB9+BrigDgZpQb8tXpkfTvaMfKmqmEsXGk73ZEVoJBh+JStLRUqUBZA9AQ TkcGTbtwDX97QuYRqjQERRjs8Rv1AKibyeX09t8iStjMqBd9bN7bXPVSHChjeI9K5e5ghLdB3d41 255siWovcZp7KOnlWHczF4wh3EEm6DhDxfvDcxJNHPxzLisY0yoAaUqFZai/CdXxo6pHc7xmgCwc YhPIy0IPCBRBUSkqq0cjgaVGj3VMEK5Uq+RrxQIBkENBuO3BxTcUhAuL99cAFg/P55WAxRMY2S3E /7X9C6roGNonHEAweVU8eaZIth282fbwgJxecwxP0s0hdne+HVGd4OXcV58IYneSgl5rzE4yWA61 RZgth9fqaJs3PITXVqqrsKx/IkHuoXEWZWPKNChROU7R3zIm99xLFDO+H5qnZJWdIip1fHPz8U1g YLO+zQY9Q/189ZsuRxiLLft3X25kDT5W4QPDfl7Vl5E7tL1FrDhorSpBfWwEkJVPir2FRsTApMGs BTjNcrlTrqdJhO0JUv75RoySC293h4YFAwlF+jBktMYTCBD2KpDRgEKUwrjgsQ/MTO9OvEUQNW5U zcqzbvA3xlLQG/Vmu1Zopmwp7Kb0XLYrBlYYSixgwd9GkwmVDBQoU69YgoI8rjBYUlwuasAnl1bA oxla7D0ohGTFY/BV/OaXCpVmWW8RsDVNM/E733wRU8mIIbOo1B9M6J2V+mNWhAp75JDEH7FaeAGU Kzz4lFZOeHxy+V8cFdjW5+Ty6IcPKKVfH6Nlp3NxRBBzUDI9bvLXGxTLvjjie7zP/iY+60J+eI2g cOkX3PGInHXR8stFDfmLo943Q5wnfN9Ej/sbwMhJ8vCVnIR/Hn8hAEw0IRq+uJgx45FreVBJX+Og yh+Vz8K797b9FdeL5PxinZ/ZtxzUv7AxckbNcjUMehd82bSHs9E49L33AV8ytt824FiXN2SoxF8x 12jU64m1UJlevNoB1kNQoUBFbb+0xB9tg/yVrNfmQ6MZvVDLd7LNxEG/L67NtzHxHlTLwr7ztpO8 FDzJb7OBGXitWKh6Gt4u6kwRyey6hsOra9NNy9ju8moh0sV/m1P+q4AbgmGnU+QLk/Zn66kMdBC6 /MYFa6N3gmertbQq9VqjVS8QKwopEvlOIVfJoeAHpr1W0sfLamn55JK85LymyVWGAirwFCtFQ0OZ E8xMaGhqESyZ6eXdFVLHvNIoIddvNeW8h7Wni81FESzFAMIKYKSJUcMX/VRR/SmlHFM1ZaTjCwbq wWXyPFzvHa2SOBD4ZDPrg1pkf73+9Cm6HzFGHArutCvletpGnHr8PlBZlyHKvAjVSKntowpfKTj9 8zcPnUipFEtwPpfUuVP6XRyUeEucwhztb0h9pEYChI0nZwNpjoRh+MSJdUh5/OS1ezqm/X2joU0J RUJ910Qfmi8QwehSgLtEN1KKhRpwVxDaAR6LR7T3Q6CTbvf6t6tGf4iTg0V5cgsdi8qo1URca5Hs WjObO25xVyxVIboq0Rg34aONG+AGUieUAxvx76W4tC8Y+eUNdbg7rY97lKhBvcqQnLEy3Z4jyxr3 //tf/4seaF7ihh5J3MARDekUkdWIKEkhbFXcVim6zwv9stRulPrFE3QA5hm6YBLmxEWJQNHwnfyF D/bwAS5EOA7B4i1YmuIgP2n3eDP2jus5PUljc8w7q8f1IborvcGjxj3KW5AHm3sPeodYHuvjxhs6 2nSsxQ9rx/U3qDcgGsnXo4c6I2yOHcAN+w6dXv3cC0ZpYSVaH25oRkObG4uCYXkTI0euuKeHqsZY VcydG1P760twDtNfLTyE3ctiXfw1adBFY49nRm7A85dqt1JutRuVBnvYQvrqi/ER37Xji4QxKUIR y6DVbjabjbRVk+96pZfmoslaL2kAdWgpAaB13rxclsWy7wmsbr4S6yLnI/AuivOxmCuc5SfujwPT uh+452eV0gTePPt84Ey68AFWqcIkvTOGCDVdHEkvHn80deHHkheP7ekA8RD/Pb/oA3fC0uPi6D+6 XdjuwEmgVCHu6nvOce6I4uv0MYScy1UqxUahoJq4L2YZqo79Fs3qoSYSgNNwUeY0RtVGZQIdO1Mu cj8hkIJwU6xvxNKMvD5G1v0pRSbEz8ZZrxyCSDjpjWqzXmBrP02eus0FCovX5AVN1P41798Pp+Lf D/jAe41PEt/+oKiM8ctbapWbjVYxbTffPi7vrxorWNqvp6d/uHd//DVQl6KfNIJroBpovy6xzvlO vVLOt5JazOCspOHK2ug5zxYZS4ch/vhBHhlzYUNUBEeA4LYF1/m5iyXmUEckUPMdBmLACcLL9ifH 6pGGdY+/COZgnRDwKRTRlgfCW1zrXeI6sYQKxkwg6CtIvkKlXM6V65E6Pb48o9/xIiALXD0Y3nL7 EretNOTFQZZYCnnA6b8fx1HJANYITFEqA0/P7gqCUxXSYgG1uIrNtM/3JhTSuDXzBf4C71paah/W MBIMCXOW6AA2EuII66DTX7w916XuM/2lSflezC3EZ96QsfuXv//Wse5nDhqo58+1VtiEF44zaZb/ /luMVGDyEVSEOdO7uLBHOafX60UuDJamyrMJWlpwhp9316ZFUNS1gcPovGPmWPKtFYgs5CLaxqBg zS5olQg8z16ZMJVavlDM6a2NmjCHMAGxC0+sJYcJZmPXmQEb2juFK9Z0RmbPMpwnQloicgC8Inkm FcaEh3KcSQi1KPcNHYzUDHv0i+ae8+wbNboIUrALk6MOd7LiI/x4aFH2pKEFiQNgDVylk6H9RBUa AeIk79zAHsIzQNEK9EjmW6X7D0GPqT1zujI51J7IrjteBpe4DC5GzyNLIRCkjvX7cDTgl/B/y31C GdAxfocaWY8fUIdoTD/Nv4z146ox3aFJHTes6Vd6svkNbZ7JkUtjkyMRQ8QvAR/9gO4iQU7arjcg nnwAy2XnqD8BsXa2cyYW2BiiF07vCWUwyfvcM/sWYXNHZndgjK3piDcR/hqUlz+lCJPfnUHgYG/+ eH11jTqaSM/TLJcf0jfQBJuTcO/JcfsINWuKMpEGMvn87Y4Sq+/1h4AOxZ+AVGGHQ5bjTzTGPY4/ xQZ3xHa3sd03UJ69kOTHu5+pSm573HWeOPWWacMdLKL7jISw1gi0cqjqY9e1ZY3mXHE/glUnFIMi DDw60Is6u2BkwLgT50U1Qy6Hi7M9HJqoXizy5UMXMqMD17S6syH6JeFWyBhwXeaC4rB7cP2lYiel aqlTq+cJnRxWenOlRkdvkHsqDQfJQYtYTotggfpoO1/pRN8DSDAhoQdyoV2X+0xb3jMfzKE94XOv jZEBE+L/iw777iK0ZsCTZA4NF4+GEoFv7B7NJGggRH2DKACJOtEk7aFvRI6HfERkqnEyivrHoEnX 0HTYFX5q5k2i6czKK27q4VcHiSiJKfLqFZEc8x073EtvYSO7oKi12RoxBUP2Z7Qg1T1WW6750KGE qISjBBpLkpayrgrQMe+cLe3qS0A6M9iDsdmasC99zsUm4dbtQobPhOULQV2EUknsmZRJtjg4106I I4glLxdSIGuA9iC4jWtOpudah9IZhMFIjwIDvzfH3OqRTJjp0wh1OxyrS30dgK5TNNafoAgdN9s/ AUwif1rFkXDzAbIJSUDQw8XX88P0bCpzih4DdCkXE3FMJB5a+E21wWSE0e5OThIwBlPsYfZGd4Ay SnK42hEcCkPUVzK6X488e1Gs7QntHGop0YaR5TyZ3QGwRCLzR9Yb5A5AhQDOBpYeng43K7VuIK0i cnKAjYJ4tBBR0KtFkpSbLMaTmmsDo+ZyYuihCs1ozD0ivM9ogsLpi0/oaIWx2huvN5TaFN1Lnpwh JudrCJjcIkT3xrC6cKHHezM0nN0T7dFB/i9OnU9mPiGTX8Yn0KUslHK5XuvUWmmHyr9rtzzIJgYU k9fbhVY7mvfhBxHXtQW/65VeWrLsPgACH8BeBUAKrWanVcinHftdA0ODoGG1nK/lBeZBRguWCY55 oCw1EYlTrEQiUl9iuOazy9vQfzxJ7RXoijnT5er/Z+9bm9tGkmz/CkMf7rpjLA0f4Mu7VgSfa/fY bYelne7ZeyMmIBKSMCIJDghKVkf/mPkt88vuOVlVeJAABUukRNqYiWhLJAUCVVlZWZnnnBxY5VaZ BJx4fkcv6i3ld3IB3R49SPETZfagZu9Iu8RxlYcVqzKsMVT60Yc3xHH9n0nwn2tQrvUXgeaKXlwJ Q5865XnhYZXKsN+rd4rpi5CNmbBGAUFG7+ZBOVrDdq3fb+4BynbnzicbNp0VKBu3xH//iP+y8lvi 1zyYR3AHa5CMXKHvPjmMe8598anrPz6cQJFG/xuYdMbxsQYMhe8J+DThh9Kj5Gat07X6w0Hh8mWU t2q65X6/O6y2dotpOYxohYMrG2TCJJPHiY3R0Glo2eqHz3LsPkZeKPlGHpditYdWr1Hsk9qvbNXm rUGzXsdJpvAnyp8krfP4V51KQl4p8U5edw2iT99q7AMDYOcxyDNEGho4G8exF/B/EWYScPsmHSZE E/FhM9j+BPzfKqOp7mPg/+V6s1YeZgXaTHsbbP4G6DBu78Dg/w2IJZWrW2ep7SJjWcD/j7YD/68l 4f8K8OhsiwQA0FO/0xps+/C0C4vasJJ1CnIDrPg50s08P2l8c76a9nPc1EYSgAUvflA58EbfslrN 4bZbQyTP+gV8T4rImvCYXvc8Ry1ddDCAXhc8OjqZCJBdwyR8559LABEWJZEDYuU90TcJdXuU/S+V /gZI8YB2oqofAM7LBqO3LqBwGiuhkQ54GYX/yZIAUUAyAgdxBP5ow2FxgzPYYpV6dO2MbuSG7dLH Tg9QRaDwUQkOH3uBpi0xCAiOowp+ooXo+bhAOHKA8BYA/oS5X4GqQBUlvhr49mwxdQF4jT4ZoT9C eMi1dwcogP8akAc98CI/Eg589CeeQk0rln4JuFvvLqxfR1AV3AyQJtKWZ2T7viuQErIvAwdSM+Hd PVJwensTkG6dJusF3PH9xLPHwrOwx2Mob9OOOCprA3IHBBfApXhQPPa1fQt5nVJgX2lMuZoeGdM7 EBNEnhuf01eRK4ZzsdDaL/yaEAgAwRjv4qfSCOY7FyktrhdML75BQ3c0cMXo79wpAMs/l85ChMP5 aYMzECtK2H5G7q5drVSq/aw4+bEV7sJdUk03hQaYWZTraPUzaOijxzhQLaVLxw5A73x5DwbvIzhs uGQxb7BmxCnAdUPziFaHztUA39szx4P7BaqIalICxY/EoWDC/Iw7h25caPILTW8C08e1r9C9Cs77 wruFaFeoEDXylhPycOSa8mVGborq9t6Mslae+Xi39ErLMP0k/B4AxLDSzNuLUu91qf+6BPKPE4xO 5O6V5BwWK5pmkWq1WAJkNrLR0g9OAISsW88dJ5ZRMt/4LFtIugdTY2GGVNBwBgzHDcGWjRJY+el8 Qt8MVT3OlAxvxJV6rWZWbckEwcHDTdwbevAR4HbA2IfQJDXbwBfGpu91yXiymN/Bxg0XdkFhLFix PfGw+wvsyWzY2KYul2Laeiox9OcE6ql71VbGu5WIYM0Pq41pT2dlulwEsKI5V7GMuGARzd4cLgEs EL62MFu7BAFmEJHZK72a0hKF4db7eAYKkxAcnHHfDgAYBbdyJCPIoXZno8kSnSPDi38xIMn3s0tC UPWHF1BeS4xa+pZQtvq9WqXf2Wn69Zsj6DhI8XG9xEQBavcLNjrjxW9ZeiMcBHQ0OO1ghU8QxiFG 1VtQ9g7AVWocspHIY5hqwp+xI2jpuONOmOAeuVMJZfVGg2d/4dvcUD4/NS2qJnJSoONcjzeNayU6 3Y5cNtjY4LQSgs4Iw15c89CgiLH4FGbQm8L3G3D6eCMgXR1T6KwkMgCaOnLV2DvxTS5Q2Et7En09 dlVaSTTK+Fxw7S3iMQHv2Dyh2NYLz0RGEQHMRLNv6ROVEBXl4CPh0hStTEm3xnEBi6SPs26Sispl EmM4Tj24cH3Q27TvlV79/OsgxZML6jnDow+alUq3t2ce/TldcRw+sfvvRZB/iliS0x7qBvg2embo 6RXzwBpcY6irOExTHciIvReO/xJXghoAFUclkIMQQLAMjUX3iOangSUX1YWS+9Jr5lQ9vloIqidV iTrQTAWppzRJDmHDwIFwc4yeUvyCeAWHh4mQGcwhRciDtcTXzdYTnURUvujSxZ8ciYraUekV/AnH kgRhG/kPTgtXLE7NcgQwURcTGiDZ0D/xK9B5GNLWGPLVL0EeK/Ytr3i52CWwMj8ggL578QlwFzhG qWeVsfLXTUkPsk4rXGjytQyP/InyXHogJjHvHt/xw3FSn84YWdB46OlxAImmmVuPqBSHGanoSMe+ x2I8xmhwnhhTMxzhNJQ0JvdKwEEd8Pjh8w9nPHNI3IHrOrcvPQHppzaei6+9+Qm6xfoOTrqwRxyn wwEIU3J8HCb6Zg44TpJroqYnFk9y/HAAQ/TPRBR2Em6cHOKpOx7jlI1RoHKJ9jnBte9QrWSujmdT e4EV4ENKlGcMokNp995FQAEMXkTtTlBuActKlgmuH23v2gBynSeqllXrV9tFikltQs9BpTvt6rUs CfekydANIAEMv3bn2DelVwwHX3qtoGk6NwZYLE0Pa1islmkMHqOPJ/Y9/Hmo4yIfM9b8kxjuEsdj 3710bbYl0KkObLBzD4UAxJxYYnhqKOOovgXhKhMPk5QXkBSIKh/Q9y88Jud5lsc6GoE3yS2KvEPm mVaTIVg6d9euTiDxUZC9u5P8lckaw0PZ0t0ArtdeLLyRyy/ZLEjyHAaT4awwEfFnliyOxKaqRLDI tf7rrWG1Wq2sCmpsl3DxzfmE3UeBUSLg2aPP9OkcIpxBGwAuBwSKMHswXrHjhtU5WQ1YJ6HuxG8f P7zmJ0o/n336RXZwLK2om6hOHsqKgWGzCnTPi/HTRnJFMn9YF7gU8quyDINr1uhwBgQPWdar2tIR 63JNxc2LGVhcGNsOzkZjORdKUkxWELYt9fbCvnz5JHn6iPOBJDsn+T8zDJ/oGe4kPuOm+hUJ2hE8 VK/fOe/g42MG+oyNJJWI51f9GHSwhkgWyWo+uv4k3QdDUhlbTpYaFfmcNIiVof+E0IldVfDm1AHz WzYGHXbIuVX5KXwbPsFWtfdiBg1r6UvgJ4okKubiQ8XjeslhUt9tOeWBBjE2qpML93eEny+9r6TP ijy7qiuw2gInZyMV4vowyStuK/D0jMyuIQCWz8ERc9UZbtvB/eAImXQmIAdZq7nbE1jb5h6zbYVB RIH97ZESabMUI9FcfICg13AGBWd49yblLVxGQRDT6ISVdqs3HGybMPWDT37OHfPl4VGAxSXgUeWU Bg9Ar2xq6bDWwsEu8/+8cI4uDin4Y0DMYNRFj9nJ5AftMVvvtlqDrtXLqODlBT/776RXiQEyVEEs lxpaTlQ04l8Dsd73HrO1QaNndSvbTlFs2YlzUUPq9O0RZ0L/8mU54d4WfKArVNPzMrjqqFkr5l3Q ttH5J1Rzwk0brdSix+xKJ6kqWnZ1qv0VXYJKtd6oVlVP7G005kBMiyOatLlBQ9LsBtOreOnsnVZc QjbvLrICE1glpB3axJWn9pjVzsb8VSxSw9/Il6KKiL8VaSYoTdC2kFtmp/SPSMCXfka2eMFXx0ix YM2UK7XjsnVcbZ2Xy2/qrTfl8v8eCQg7DYn96MeVLq8ivWSd1Hj8wU3Kr/wZUY16hV8ZQwdIbnQ/ 7p4dcuuJYxvuWEqLGZX6J4xUcHqCHrCdD+efVr8wJc6u1wcDdIHdrbZJkUUSM9W47tMO8gA6GXH8 QXKw5yhjQmm39AlqyolJy7CO55fbmrq/q+zJKxrWT1L00hVHyS+NXYTVLsS/mamaOdDo82+Q85h7 E+8K1VYAptibjOkXJEKY4IW0LLpdIolsoG4Kr6BfllIhSvfupeDrkES4cFCucZEjwd9rkDAA1EjZ INcAUJ5JcpuvXhnFtK2Skq2uE1wey4kXSRtxa4ViK3y7IGxn8PRqR8jehrDHeF1Iut+8u5+jzKzi WCi2clxXpiBx9twvvVYawOHcLS31gAVbn2mgnyKh+hfXWTgToKVP0ObYh6Mau+qXs8CFbrqP48KV Upz91VvOxkj9f8EnWen920npb6CRSGfkzW5+1aF+UfQRJo0Xojj/83LGHkTlSvUw5OYV8IS7A8EE OIeg1Vi4K4CPlLoZ6Ko4dwfmhxMlDkN/wWfenZ9/Xs16p7l0dCqvNioia7a3flzf4wGv4KHrTHjc UWb/304Q3GMf/xlL4KN3tcS64Y9D/x4ZvJvXpXd83QaeAqCH16UP+A2H6tG1aiDONXN+Uuo6PmR7 F8cfHFQ30FQcu4njB85X4E9Yrb7ENv/Z2NTxsZjDnysnldg6qbTb7QfWSZrBJGMAY7c83uyt/RyU cnsRB9CUOustk5dPj7KMtR6wJwGUcIqtlbvnZ2d2AJHBzMvY67ntGRclbolq8fsrxZ5ewVVbOHAK OIqiUmvYNbKnA8AAOhoL2OyWQWVzFAl9fCrc7eUoJ58JsUbct89A2+HhFiEAS9yqSgwmWN79vFUR ksfe+mPu57jHA16FX5zFyPMnNih8WIjcfhlufeLcAi8p1vzRlp4C5fIDe2zikPdyCKuT0jtDy97k VJ7jBk8VXo34HwfAZ+mhhRQGECGCgUOEPFqGHHNC9IQlKUtFrTsDfsN18G4iQjYQoSjMJlgY0N4r UNxA5Ec7GsXrR2gt8Ze0CyT8TlYubwlLkrBtBGRM3OA79OKGtPo1urehWEru4pzEaf/WfMS+cEU5 AJeN/oKJmRgkkvgZYD78Pc1nEYM+wRSwk6CgInmzQtA/KQ0g7S93T8SWJFJDH0fYFs8yhAYdyfwo XwiwjmB8OUJ62qKMlwEcCSoLo4TsisvsuXyHhtyP1/8Mn3RmC1KVDRKJBPiIQwTQGHBOABUBug04 Ma4n36zm9uQo6V+Rbk7J/lZbnX6zOiCcY3eqwkX2lz5IV340gwXugOtcMQlCBO7G9jLP4qxiSYgS W4kiqWu7V9cBjPnO9oHbSuAIQ2iiGJ6WfNB05wiaizaaY3A+Aq43IDaEfY9YwOhsGKIDl472S+J8 gPc1/u2CWRb6lxFOhYAjk7EDrGOA/yqYpeJAKPoIUjQR/Vf5OYlr8DQY9ZlnWAGKVoaIBPzpUA/l pXeL9LiMgiuSKQnNRtET1jwN3lf+AXhUzTHPBbWDWEUP5OSiCqTil+dYaukzfY5taMotWbZrbd5K iYSsdi5Jge1ysYQvnyjHr8Hj8iEtNoAlc4ELEt0r+FGG39gzwpWq02/sqKTCDi0TIYh0Yk1lJaE7 IC60oMwN1vDUubIv7rH0TnjgMR0hEQqIxsN+LiAFnjUDpHUUhPckgw3exugGK8ZFmBRI6QmjJm9j gCALgNFGKDQHs8B4pikwv/hMSH3AXyY8o4YAl6QRMit7nk+BotmVDCh4dBPdG0nPgIR1cLZKfiDX mm00m1ZvOFwBNmxZfbvYu1f37kjMyBD7xAsb2+IKFfacQdcjZOPkyk6PgE3eZg/k+9KedgYj7J8H 9QTA3o6bNygL2MfBHEiYvGzWocgJOAsS3nLHxycR7trcwkRjg85L9EsW2LHDT0lcgAAjznKQQi/P EYxxsffzmoi88QqFVJQaCu4XS9cMN77DrCWuNrhGHF/k82ZJYo+UiyxBAqT3Yvt0nHV4KkIheS0t sScnWjgb35kCP4+ObWAl0qOrVAtcuqTIo/o6PDxSMXRQiDCTTAMGQnh+xHQLOcW8+NNukGNI3yDN psczG4S6MLOw1ADcTASpCY+MHcsDmgJlNmViYqvh3kkDZzBJWuYRDeaYdJcjtQvmcr/lZr3TbLS2 HTJtGduoAF358WjrwJJsIFJGZhtpBwyuxhDElVizUQQ8nCpwjIGlJcFsZAEYdgIKi/ZD9AROivn8 bATsWl3hGMzV46C3bOZCW/4q/eBcs5Dy67W7Wz44/+Czn9PXPodJblZvRdBV0BO0HrtVFzZQgJLt 26PxV1sttZxgdmDZlRa4phSQXYG1e/f2KO2ikI6Al894Gws1eS389sHzbvB5gTOVLQX3vWTP2C8e vkIwsrID8Tf5Qnmz501EaT1837wgH9kkvS630Ec63Xex9wDspr8bTGuIdHBk1F1qJODFJFWcvWE9 Spu9Wqu3mn1B/qYl8wp6Ata05DnnUFN9j86zjdawO+hY226IsWUnDhsq6Anc0PO4/Y/ezB55ereX 4Oeit5B/E2FJxKq4e7P43azSqvAR+UoPSUzlNdRrWLVh/vbf/zr/1Pv3vxKJDrwfoktkjSPXzpU+ Uv9gX1PrnmswaYMVq18f1GuDZCBR7je7lWGX4cWb75KeEOs86V+OTpABp7s8qZ9Ih8l0tqh+K05P eJxioTAT5D/KD4eaBdkWJiaUHcBGfATrxOJc56InbFm88Al3T3pCY9Wid0pPGABGiVT16B4HdCb1 Z1erX59Srmr0eq1qr0XjSdvhtrNYipQXZ8K4u/RTeDR7tp49IQRAdYHTyvyOqWRLKun9Z0MJWCSr kjG3ickzHLYIlCeHPZ24EWQsHeLeIkEKZN7OsG42LSHhIWCicRe+X4SCuMkeMDDobHS9nPyOssUM lWrieOEbfcj5KTD8F0h8INPYxeuE8b5DcnGBZMulM3MVAP5LrJr8unTu+FN3pvhA/PwQuuSO0ISY jBt8dbEdQK3Fm06XM82OUkB4HA1H1/uJhD9lflltX5oMhRqdNHZQnEk32GSzL1dmZIkcCVKU9KlS C6Qf06lA94GYRec9ZicMUK5Qo9CviJuPFBvxt6iaI39O5UxN2TopDTGPzlcbIEGYiy5soWiIWcXV r5doZoGcPWA25HD5M3sMLKVcdxGlb0XbHFfHIJrrmivNbegq4UIsByxwgWmuNG290aiUW0Oe3IuQ 4U0Y6a7nedNAyokzU75ULg49p+dSxIYMKNIglFcF7sOBYCtRDDHHKJFBGD4YqXxTnWFOf4lLUHkp Xmilr0DhB9gPe3QDG4Wt0EYhNDQBVkubE14MjfJMSVuN7LlBrSlJpjmAXKI5R0SrWrLJy0KhjZiq O9SojhcAwNljVIDhmaSfwdxnI4AR7FytDHP7+NztHsj+SYmM4yHDBJwfxGy5nNkqwPcgs4fUlFna oaI1CmtK2I+FFalTwrMpzIHB6Ej1CWdjB8sThU1ckaRMeAyg2Nw5QcHiSfQ0AC+g+JuqZKeHiiA2 Web4a86kkMtRpRlrNJ4CIWOeEUqWmFXkotc3Lq0MEGOCSwKBIRcPNUFcELMvPBdkr/fT6WJsBPSk tAz1GOkqZjTA6vEnBDfpxyfq2jwzxiwFS4WnVmYYzuUrJSenpU6PWQkc0/GqMrX+ferwfXcxzdnB oFHrlHv91kquokAcLEau+/bor46PfdOWE0oK4eORvrTD8AKb9f2cjhS+SrC6KHfH+4XoNljYyDX2 LQL78pWVnVkBe+0SkHjIueznWsGahoyqVHfxVGSK6xghXCiogkchhVi/6JGqQrCk8blvIA9DnWsY P4MK/ci4+BVcO3T7VOSKrxFauuGOE2qAA4e/INoHCCofjawAjxIxQFyGY79YXjDJf4HQKVcYUu0M O51hjxmfHzIMQUYhLZ8zqDXqVqNQ+Iu5j/Vkdb7AiyOs05nxc3H2GSM7Xcgcy7Y8GNxWcPpft28Q IGD9oOjy9698nr+7lbIFXahEFdUq106q8yBF6m0+Ct4etcqI4r031wAhbhR+m3mLawhwi/4bP74m BDcajXKqwCVz9bV6vVJtZep/bSf9+O7844fPPnkZ0MtAmKNqGQlJIQ5duYIqoa5X6Fxddno6sg2D gEjiK2Lqj5fu1bEkW9YxFgP4PaMLpEUd4ymY7K/HmSA9jai73Jf+FG+4/ie++tAriV0r3bmU661a t7J1gE6yBd9uZ2tLw/tH6ZNuuoAI8A8O70Ov5Bjeaqs2KJd33M7qIIb3IVtdt+ccw9vod2tNqzbc acBwEMPL4aPFrv7vJPlCYkyTyeHHeaaTxBXTfUwFLZHbrUHnB5ilb0ZqJqcnsUjE3f/pZO1/OUa8 CcX74aCx2zPoAa2L5Cjztz9yjGKjY+FEUt82fPEA98b18VOv/DXHKFa61qDSbBBturtD3aHaYrTg /5RnKPsDqzo86NB6S8FaikH+Ufpvla7Itbbr9WGzVtsxSOLHsMpys4XaUb0IwrRRJhbyNmKsFWPP t3VhSqx6EQDExy5ytgitkr8k5iw9im1a7Vq3ueNOYofmMdYPHGbAc1lpZQhuUJX4xCI0MAP3V/PD 2r95oi2rXR+WK53dptAPyEqjZS4Zs9iYxt7Jsfrrvd6w2ez+CGfYB9KQagj/KP2i5YtXXQDeSYzn N+yAp+aSiQuku+PKoFYeVhrFhGiTjplzzMj5Y+ydHONab3Q6tcZw23SPwz70rtp4NMJ5trl6t9xr 9Lq7RVcdjE/W5qj+STjl5Ds5bLXc6FJUrkjQiD0mjHTDL3kGtl0tN8udwrnKwCYisrVfEsP5DZvd 5mJfKU+wV+u1BoPKcNvt3w7QV4d7HB1Knl8Ss5YeYdTLzWGtXAeL+Uc/nfxR6ksfCqkv5fklx+jW Oo1+uyeqpT/42S+PuSasOsfoVjrlTrXTOtwozixJ0NMJ1ME/IRtcM+qFZq749EDHajZrevsxzXg/ g3INYbhCja9wXb9Z5+O/F/wGmO5WK/YNq4z974OIj0GOD2wqzb7WrD2KZ29Z5bbVy0xEyKRqSE4C ttNotKuVVrn5jQIJaRPPxzMMPXCM8dtIG9Fokw3dQm/7KhQlGBFG7au7uQbKHTN/A/QZr62vloQ/ oRvvsFIebDsbvmW6vODn0sYMAcwK3XedBLEtTBzGUL4M/+YA5WnSOhZtnu/PSXGPowYjijskHmWA 4hR39Zq5Zcz+6b//NXSvIDz7739Zb7BBCoSW7gVwfSF4Cm9XMLfrPPjczPdarTfo9PrbJvPuwpw2 LOPnsynIQICWBSMRNRNnxok0k5bPzmII9TyGZj4uBvMo+Pom8CdC+4MCf1Y6vXaj3uwlY2ar2eyX G9KjfBtCDQX3PDRp+qH3M6WbSfA+UPwkEymeS6Qj/DpOPTJC21ALvHXZvcCwhMgZVBKCWhW3dAMa qzDQoLm5IJtIXdjQNoU1IVp58n5J630egeM0co7vIJ93hL/wsB7l0qQm8gd1kT0lfdo3a1SQ6J59 BxpFIG8J9QHDAaKRpkMYdqZuune5BPdr4QinMxGui+gF3BNB3lVCtbfZOHR9q94aQt1IdUAOEGxF LS7NJzNviEmKr8UrDLaiFqPoznUwzxmc4gkTDwhgPjcQ+e8msY8dDn5WRUZoniQZkv4EJwD9cNCV NCWHfQlIwjG9Irk4vRm4UWqtwqjRL1IRA9Xfi3GfAAUd/YkoiWk2qtIDtfWbpA1p1dI1hmJ0Iyum Hwf/PAvJNiPHRmI97toFZUwNgF7E/wHRT67wXGSlWtdqVqzGylZX8Px2yfOTvWaBI5ntuyDXC/cY 3Fs4YThjrobpchK4IILGNfRD3ufYGy1V58CwnSqptbJ4FMMUIvzRpql4qPYMywZsaiwzTasnIVrk 80UgFxsm9XHx/SBjJzc74UCLpDW3Zsg6KJ3VkUeq6lcQvUXuGARk+c79XCsBDjhgIl97ywnWjFM6 QrvZJYTCj0LtArCU8QgyFpyIu2gEjfgwxKAxPCQiQ97PzBaZhhOydzG4oD1hTJbgkc/ZR9JbsouS 6YGQbzGiO7PVG2w73/WDH5PSeFDVsiTOZpAleXt051yM/Pt54K3zoOLcqWoZJLak1mymghmvL2cp 8+URoYqXUce5FJZkzWoOBrX+tmHGP7gF5NyxX/6gjHlPHJTLKfzIBxiRawxIu8z/5yRBpiSqkdSC 1VOsdYg2Ludo1Pn2qMZMzhuRaF19EWe3oCNCzLgTfJgfxFXnv53NndHbI/kb89rf1Gvx5CQ+qrOa hdYsAjwK14ofwbi8lNZsozoEChcE1PQKYt4cuP/O0ZK+ktSqVnV6Ek/Wg8bI2QNlDZxeHkiDpxvM 4ppMVvnK0cTBlo/fJMH19kgKLvj1Em3P3h6120yjqtF+WvK8XB02UThA1murJdctO3E8eKE1S2vI 4/ZzJuL3R2u2XOt1a5XmCvalCqBRowmxezz2d6g1W5U1p7sBJLVmdSUuLRyz1JpHwgejojJaMkAq P/j26KN7g16MSDAuOGxs5sekV6V2XLaOq63zcvlNvfWmXP7fI3rC1FAj28LEt2fn+qPElHXCk1Vm mmrbX0uR2JWjXDwTJtv/XoxPcNpM3ihGaVN+6wlTwVpZ6VfnotSTw8KVb8+v7xODhO9Oiemr9Vq9 b/VWlE+qrUatPhAx6G0sxaKawJkwdfL0jNk5sva/1nprc1jqfH6PhOCliyWOg/0iQOCFBojIzPBQ KPOMrl78EJMzzKMnZl2WZeg6tixTvcN8rHEmOP7yecyvMo6SJ8YrqynwLctY7/DpglMs1cQ8PeAZ dnkv6fa4akahrDyMyegj4yGUu+Hes7dqyOFdHrAAbsJWVjbyLSoO31KF71r2/SWmVA4mMwQXKgjZ FAoEp2cTB4lFdqUHPGNc6p+U+vb1RNp4YwYS+xLdlXTz/tmeHV5r+veX8MPQYruDIBxkZtF6kSK2 bGfGx6ILRus3+9Y+k+YrLPfeAtSEwu4Cup0sIvHvVyYU3ix00iKCtL34ZYeuw3jlu/xOunI49dhD cNJz+4qN2lFiWdzI5m/sErl/VNAREkxXIgVVWAckAaKC0igVZgklT2cRvC597PReo6ApoQU+8ZqF g7jKJ6BXuUoFlT4Qes3KbkmnRVApwZCGW55+mr243G9GIKFregC6oAplL9g+GNYZdtQ0FvuQua54 zNiJr3JA2IeMMXKTUsH7Fw2ylnjruYQnTbw7YjBjW9zIY/tUfGLEOq34Icw2PwTpQKBZoHMKcXdV Psb2iFpm5IVWNGFlH1047Iyl+pZJVZQ1S9SEob6ML3Jn/1B678G17y2vrrGbjnxvsTheSO9U1fIM 3/1qxWJS0xA73B0zICW/nZ39pPWwVfmbit4K1DpGOIF8L/qoSjd5gYZRYV6XdqFkHwYeJ6Vfrwk/ 4YFviqrLSEq6Mj4jGTI0pEc9nd1P+BEuPiW366PdLL9Ny+Lr1cewBQHM7XIyg+TshTuhRjr3FYGz oCjtfHX8EdBmyFeH32s+LS2psQ/hAhQjv+UU4U6p5w+4h/6GXBtHs9OqDYetAvChbDVbM3VroLPg 9J13tw9S8b5Ezkx/xDNYktiQNtY6jGYOhMbMuBux9OVyJg27sAKI9YBtoh+xxEOipB/zUXBPKPhR LV9fQSTQuTaYO4HB3iFlNldOarrmlJBjjSJ6Je2sbwhXmy8vsADltpiDUTfBK4/YpWQx91Qzi7nv 3sIdyuewVK7Rep0QKRudBSBzv5/OSkPRlBa8GSGOf3iqwROYQVSOB79JP2zx+Bh19jMWSJw9w1Bg zvhxXgLv8UfiWRSALvJpGB51sfXmCCvOTqZVLit2oYwoxCqRJ/B1Tu8YGIsJdx7zCLQoo+ovbQfY SkHvcZf7OSswMjpX9qRQOFEE64zV8RiACgUKoqxb1+TyuzVrMOyQEbTdomCS5VoE7LSmHFnglGwJ THJBNBfsMtxRJYxGTwbkH0oT4N4CiZikpQbX1XLBs2EUfC+InkObhfFkDX2NtPL9dOoE6IsjKzNs Yj4FEwsuEUdEXO0C+7yEA3Ry8VMi0z1sj8LXcYTkMoYLUH56PxcQ/IvaQPBwK65fPAhGFJrXkNUH YC4OzRvZ6B3EARHEvfT9cINcK6zRLvcHPWu3okHFCnvCCguugYnUQGxhZODsIksMloJdnL1iAB/C UYZJFekug01sATD3hcApJwpqmggGAEkiVc1Orq65DVS4AsPiAOBwc+Qq9kn+wHbG1RQa5wsvnw1a u6eXexqyYMzp/sKDDfwmfvcZaDhjmVAcZ2yZRbQDos+K4jdM57l8lkcZ8bgR7jn8ExVyiEnEQjr8 ASYuMdO42hCXRwL9OPYVKkTBX8K5kttCF6QYQHYiBmU0y9vmw2Bjv0QOWdpE8WTGr2JrlSvpZRX5 eF7phU0m49RrLxaAOa+ULbGf3f8nHxD+FgFloJrvhg5XzcB8zuiR6wLPHTnl6KGBAUePLlAv5POY XMRGIAfxb1TdFLM9dtn34XVpOTNBLFexjVdoAPgDwU7LsTVsEXbhLVlqzUdVqDeqg2ZnUGBjt9pB xCBiEkhnJSug0NHw1w/goitruOhstA2uLLUv87UxXDQug7cQv6VgKOrlar/ZGzALuU2djS1D6uTJ CgKxwlea4macnL6pvLmJQAy8UYGLLnDRMKmZ99cutuZ9wEU3axb0NDMVowtcNDy5uGtWGt5jypq9 Sq/T33dyC4yswEUTbZQNlcSbOjt+cLjoerM7sHqNFYpduVmt1cC942N/j7joijyZjucuRycIwFn6 O8nmr+EvVDQToWagHYPh2R5qJtu+5Js3xQoGFVNnuGh+4c8o6qhXVoCLlX1CLDd4j3kJ+U8YpeD0 BIjlL7HO7KtfnBJp1zotqLw2V9g+Vr/S7FsWs9fbWCBFFk2MVQNL0gELiiWuFipgRFPkMtA5WZX+ dQ5NaOCqws0Uhn3hoTCMkzZKO2gCDPQRkxiJOZcVgv88qI61vepn+tNN3AVSf5dLHzdO6vQ/l0gf qOdhnlslE5CVGAPbcIukRlhKDB9SPaPJJtlI40hyYuFNJZmzQCES+RuOF3JQfJvXvSaue2VEYsBA wVNt0cXtEPpgvB6Hzjdjxyczb4iFZbnDQ8Jxx40jMXV42E1Ujx0OfkYG7nUJ1QxdnKbFKYBI4p4T ZIHK4eFQx84CxsZCVV5bqx4SHFUezzxd3i36+Q2NqVyA+US/g9lVev+fP50NkByHwBWy8wr8l69s Vq416+36tgFBP3hqzeQ3E2nVqqAoVRgewWoeyK5WY0oVihXSykyh4gskdjbfHsuu4jJ4Cy4zJeaz Go3uEOJ2iO6K7Krjj+2ZrcbxEUqIHGEdXQkf9MFIKzvAj47Zu5VnRFRfZFeL7CrMbY+yq1an1mnW qywtpfmkIru6ml2tNcuDLrSqMwbssQf3Le/juI0iu8osSh63f3DZ1dqw02t1uytl2mqj1mw1qwM+ 9veYXRUnlaI60TjZEI5JsTtxGqxKkvYw86sQ88Hk7sW9B6fPmF+tMMM6DBHy35psrbebzQH0lfbb Z6tCgHv7PlRSqpTr9XqrVatroMfD+cQ87u6pUe6eht7B6bCSyAGlH8IazV4DzWS2DRDf8v4ttuAi rawk4VDURX6nMJAnHBhRCkpPkfdFkUSjKBV8UYBzgIhfkJ6nU9uGJMMc0KVnaBUhxC7KFL1JJr7T rdCqNpqQq1mpjz5ZD3i2nKqDsDu5JQ1fZA+04eC9yLOIQ8GtRX8Qs7UKGrpJEEEhOdXbpjC9nZge NLgD4LBD/drSqxAL+2fu8sTJjhR9FAhOVHDSMdg/5TG5cq+FLk9b7/IdWVBhcvuUicrwdh+B/yeb ZsW6HrS7JB48l8FVu61Wudvb9k5bGNx+pj4zDG4QinDkcVLQ22i1Oq1tZ1cKm9lTmzntRLucM06E 77kxFM9x5smMHmP0wXz2XW12KlsnzxWnD6m5yfl4X4+n6aePc8JmXGCIeK5YOXcozo9Q60XT4s7z byh4cQWxkLlps2DOJYT2INwnaTrlUMJSNb+h9/GsdIZuCc64bwf261Ji+amX9nkRbmDxpQ/vYHbr TFDD149LoBYfOXy5NMYwhAe9lUdPEwr8MuzVG9Lmdxcygd/syr5Z2+7/6gfYhYLgN9/9E0T60qe7 9Ood+oFMHDBYv6xMZkIz55FCg8/5gKcnIjgYkxABpd1E72f3s8D+WnqF5fyTyA+eOXMAUi4c/9// QqOw9slPiaeHSwxtWc4oB3BQSe6msQdgAlw3PqAtl1tCi9uBZuc3z/bjFiMe4PtfjHmNObkhHYd+ +ph7U6nngSmMDe78fu6I2f8CJG5o9c3vwOpzQcnQSKxWaQhgKa1mjwXyqPLfLoLIBEuzKGeg/0Ve nibKGdVVJ56CKau16la/K1qk+24LRTmDSfXtIf5PdeUilHMgRDUmzyC0BK3rkLCkAzlZU5RERA1i qiMi6BpqxduTK7SPDK6nOD+JhA20GbyRC2kyCNuEAgtsPjeaLJUyYUKYQq4eV77I5X6rnYbV7Q+J F933JVe4X/QKeQS6lLyxYS2xaNLreM16v9npVrddx9vFVly43+263/QTaJpPTkrpbPRUkV4ffPkF 5BRDf8XURaT5ogSbchhoo49Gl93GwWHOi1jx22JFK4ct1Gq9an/YWVH2qVj1Rqsz7ErFf+GOv5gY VTUcl6MErNpGs1y+06rUqo3uETMIGoBfOKtDTT5rZ5UwnSRWcst87nUK1zcnWR61m2uyZrrLVi0s MvmcicRhto7x8zxIRpH157NPv6wmzPBAOG5Io7WqEMpZ8vf8bTRae+FpPIViLJTY3d8FGUPrzZy8 mLZ+dedk3GcygejxVxbuflnqKaUvntgM4JlGNN0vyOmQRTPFhddowJNSBwrFggyk4KoU5iAh68nx crpcBGx8jkIcGwyMIJstr+vqmyzTTveXIdA0ksBfmcAwSZ/McVsNtYAPNsfNB/hec9w93xvdIPMy fo1GUVKyOafJQOtRI/f+/I8FNK0/OmPXlsS1mFVMg/2TsqVfvEAB/V7RSlRV5+fl5F4KOo3vILWd 3J/Sj9P1RrnT7vSz2GhFZttAeiWLrADh2QI+HOM95MgitSKCQnHef0pmuzEcoI1ufUVn2mq1uu2a JTW/valyFKmVZ0ytrOyZ8TB35zofzxOP6Gg2PSr5Dk4rI286R/eS16X/+fLhmE01SgEamiT3h8Qx tLZzbZNnndgogGeInPf8UhNVi8M/xAXJx/8eTwgJF5UR6QxbrcFAUmxFEeno+6UkrpFkUyKdaq0y BM1zJdJ5MhmsyMseal62Iy2/WM6PqtjovRHWtpFOMOL/UiTH70g6iMq/Bvqu9Eple4Lk/prulcpW 26r2e4dgiUVp+wml7WaOHcqqdXrD2kHsUMX5a7vnr9PIAaX4Gd3T1KiFouWWM0JHFJMUFSFQUUdd acaF7iYz1ahZyaYmbPBAMElJ/BEPMugpT/lT3cQlORTSDhEpYrB2mUeOjWXplXNyhXThyJ1DmJXH H+lZzcTx0ln8VDKJZFi2M3fwH6Be9VeYq2B7mJrXsAusNHp00ZodLQMV+Q5TZTLW6NzusyctZw/7 yxRVXXeOdmhoKuPOXT6KUFF0u9TVuz7AKWM7nVv0vnktwrR8oGjMc8G96vCClY5QPg4qUm802tUK OyEKd3/fpEOMdGJCuLEW02DESjqGJO0Dqo01SQQqqUfFCmir5zXXj0kz4uoyFGlvbeiJ06xb0O3c ekfJXUTniZhov+d/r2qVm3riIBYuVBsL1UaUnvZItbEy6HfajSrz3Wl7EsFZgfb4G3xC4L9zKPGC ZxOhmCrkxcRDBheTnjOZnCFLS77p3Zs7NAIS3xyAefP2aPxVhFtxhjTfEozkO0eq3BSMNhrM4jpU uBpNHNtn8CqwnrdHSG96/BW944F/a7dZ51L3dNuZgLdqbnWESMXx1TvX6Cf4Ee1dceu8I30PyZ44 5XazVrFkt0gbMFx2H4pJuI1CtZHTnycdf3CqjVa1O2wMKisqdNV+u281y3z1cTaYbE39zrGJODGy h3E1uc0BQfaQi0vIU2U2gVUypsvqiXOyIRxb74pT2x/lQwM2y90Vp7ZlFOWjp4q0hrWE9KbeDk/6 ppMqVRvPmBxgp9cvseYjiXNkeirSsoZgxkrlb489tqyNxBZbqVvVcsUCRkHtTvt28NqrwDs4Pcuj 2VhvD+rtYW+FZVOud7vIVSupugMCrhcGYhgGaoVkby3wV+kgiM++d4uor4S8F/olzyBoxp5G6HM0 k4ZrijaYcDJJPMF3hodGeYcPazYm/oxlrl5hXB5DQddY29migvBLQcGDUweZ0ynb2CfmGQ+9aUN7 sdtNt+Okqh5SrxFTVaduXS/xeIeRJp9xYao28h87PflFWpsvrr3lBHpG6JHuLRYuuhuxXMme5WyJ HvVBj69ptFK/nrn/RFac3Xi46tkwXoSMVkYmAz1dyPWgPIElvxi5sY7mOQ9ZCWDGTuV68iqEfKdy N7lUg+vtWrlZ65Kqt82YOLc6onREgoeN/uCbVYOL4Cd/8PPNamd/QTiEfoyzxdzzg9IrqRQygSdI kpg0RC751lq1b3W7tcLYPESYDJq2pNyB9bOXqPz0CIUmhVBEytQSY69aVYLcnsuwqo0KwI9Wr/Bi P7ph2Ve+o05uq1bVf/et7qpa7fbareZKjuDJIMpoq3tA3rzYG9nO7zFh5aMY3VmJAaAkIZM6Pr5A Z+axwb8AZR/bDbWSftjzGGeVXH6r1qpVu9ZBkNNyAOLSA7F4puBxbBrJiPovy5OPtlgcGb3Lge/D LlXp8sq3p1KfULmn2PNa3wnJJDi1k5wKxBtpowBkjM5QM0W0H2nqzIRf6Q71aECgBUfXR2vkUVAa RMryWMKpOYN1gJckh2gffOiVGnHPGvZ6FRZrtnm62jnQp6g4fJNUzlkeWcVGr16vdHusXe67LTza 1++Nk96zktT/IB+ZxPlGOoNMPdp0NTNpzB5SmA8jL+uXhHoZSOZVBBOn9j+AAha5CqU+gK1ihBYx ziIFT1wavv98BjQcpMhsH/IWZKkgy2tEGEsdZnOR3EVCV6GL50sfiV6n9FvpYhkI/ta88jeNMlbd 1FVaeOYFhCF7U5wzoXW2YOYifnFmMcK/X/fsKR690qo0sYoPT/wsPTgrFqwNT+/MGLZgC9chC2rI eZQaLYDJ6v3OCrWp3KwOB4Dl8OCyDwgwiZ4Lj87p2FK6jZiXs+VcMqJoBOErNyfOD/6E/3rwTSBF HM+cKy+AeKy7Ulfar+0pPU3nzaTAZmgj8fLayHcgiFui81S+PUkETBTGre+EY/69KyhomtGKoeKp sW5E8c0StO7hiwUYSIOiL/F5zSuyA2SAHJQ8zOE/fXCqnjt5nscgHBLEwbhYlvhH3uzSvVpqJ3zh 3HuI9Hh4h2u6dRfI0yHogye7LLnsipSACRj3DPCAjSSOA/w3aHfw3cANXCAk1RHlhjUhSNTDtwqz Ashl+8Z1sWUQ7RYwBY9L/p66QWKeD2xJcJtO3H8ComVtGS78YrOUHqqswH8S43Bg8yh9eyck+CYj SBx/Yz4KZNvYwTjXwRWFhnqzWRscQPopAX7eTDF4GUOETel6eyo/wRIsqGKQjh3AiHlEsB+gnUoD xzdx2ik6sMjZzXxHjHeKb8h8S6qGd2+m6GM09L3pF3t25SToE9bjqjCIA9Xd8cq1utVqWuXqJpJr o9Nr1Borp+MnV093nvveb4Mz02qi8vp3UmIiX1YS44py/X789qhuNZFG6faOTv/r9o2UZ3gO+ftX Evj+7kLN/yV5tGYe5LggeUIwHIWweDHRjMWLCZwE5mniXAZcieeQZHh7pJg7PkmSqy/eQraho/vQ Ub+BKQtcdf7b2dwZvT2SvzGv/U29Fict4qMbOZI5KZjyneRqggDJB+Lt40bA1xRTS9A1keHSbM/U t+En9Zfqa+G3D553g8sJO7RsdeSal66/CL54pITy+QSkxt+iN3veZDmdxd43L8hHZt67LsJ1/Qd7 RKptDvvlRneYhUsSeylItSiHMbbhmrcGjUGz38xiIcM49iGlSht1Z2Atk96sf/mynOAFO/hAgpva nf8xwnti6PFluuuy+FD+F09oR+GK8Vq4L8np1Pc8Obf+LOBxT8a9a9vHI+if2Lrx7dGFc+WGaXwu rGfJsabdIDIpgU9nn3FY4fEk/IwqO+zH/Z6++9vnwZcP73/5S+noqPT/JqWjwBsd7e3tHsjwZtir kbwyC/UhE9DcdJh9NoMWb+oSxwsx2V9w1WUMM+q+0Qhj4RkPaOI2higQmuA/cBj8R4Vx5nNyfIqf vLQYUBLnY1Ub9V69R28ax3a0e91Ot0786F5sW3JkfPhwDd+EG1b7w+Ny/vJFe1NajtUw6qLttL18 bfZSlCHYREM1KddNlH+YYwoEoY6WBo1K9RCARN9mbI9Lpu+XscUXz3eSGt8kZYVA/cWkrDDUxouH bhveuzh9x7SUlOrSD3r6rrUqw1qzzWUY35V1ChJpJW76ylw2OKqnSlolCjH1xxVi4OMkQjFaWHLr e6uM1eg3u61B9wc4xMe9/eMEIHa7e60fTxlSKCuK3/ueKzisP0Z4+EekWqQBIGTwi3NX+pKbVpo2 oLAHlbYo0gD5ztgJIYME6CBteDPOp0UaoLNw7bdH5+50K1acMcyraYBY7MiNNS0DkDzhV8sdq9op Z8USjz3h77nSXl1Kxars61+OTgASZH+hk8aJVgNMqU3jb2RTi+0v0it8iwpBTzh2P6taXY1qdf0Q ASAxnERyKtWUdra3BuCLDQ/ubF+ptarldrUKkKiKaFSMsTc5oGcpBrAwbbRlN6V+gtN+Hom6Srvf bncqK0nFstUrd5pVKdzsQy1Mr3XK77JS/PaoWdW4lcSZqjCQb2EUppc2Ptpf3an7O6hk7HYHypU7 oQqmEA+I3Py11iv96lz0/Ps5WFMJb5OA5Df2vOqXdx2ZFOoC8Aj3UvfG5WObN/izcrV4hWfm+J70 uNT2Q2UaExRiOWTvUnhzi1SUxOMfMq77dUl1MLlYaSyVnLctp/BfBkGImDN9jY886e+N1U2VdFCJ hJ4erWooUdzwrSvfW87BbaSKnXxWEKPwAvfoh6OoSQkHgJUgMe8zVejyLuGMUVBMTfq0xEMkDeFx 5YI9XMAhI3VRmjkO1QixAoTG6k7RSIcaSUIxg5gj3lgsr67W5pyCh/IXYyBNKc41tSnRh0ZAAApf O4tDpBaDE33joBPUbOG8hpqjjErmw6/ZymEZ/ALskxKAwrMAGxlZKCt2v1fx6wYRuVPRhTP07eRm lIxBvpPimAk1Tjhh5hf+nBl3PK4CsH9uK33/oqAKHRF1Z0vSlC30QiBfcUUv1JKWAQvFDg5rtSZX J+495SRvdYctaDsdHPy9OKh9y0HttJ9H+qXc6VTqZan9xQqRjX6/VS+3JMVWnOQdf0y1N0knJJLp +UJJLkKdcxJXuRf5J0T5p51bzx2Xfj779Avc4Qxs1JE9cX+XeI4ULsYtgIpSat4w7Fe2fmwqOC8K HKvxuBrj3u0dep/M2EHi45C5o+5VQBScnpTOydhzEaJDw6ZkunTipLYAOZEHNpzU7AkIxZH2uJzY fAdtlKEleOl+5afY+dR37RUT2K+HTZ+20KjBnUabUN0cVPckxbGF6okNa+lPqKDosaEQCNk/lchk hFLGpeOzfyiYZT6WBAV+9Oj8cwllNpK88Y6cc6NrY/XY0ZqSQ08uJmSj3a51usKCi3njgpimGqbB 1yhujvhd5Y+zk9mR2zWVoATVUNh/mjbowr2vcyBj0Fp8GN4/PZpqVCpD7KJk+xRz9n1ulRtghiQ5 vhjMsCD3pXP/sFB/bHJfpQbUf7u9Up8L9xFGXc8AL+Q0GNmyPe+Y2RwMmq1Gp7vfThwb4GGS+9Ka 1ZDAxWqTuwg8/5782YcOAwfBM4LRh09rQgYuhIdxPI1apzmsD4dbtsE9x/E0MnA82TIS+As5isdO n03hWu8VeaaxOe2aIHElAtPm40rgWErrGhi6w7H5MnxGDuvNLReYs8vJMlHZMTrWxSlwSJ3Rzcy7 mzhj1dkumZvH4jH3b9YTEioSbBtqdq3frlerlSwuOx77UUms5Mr5hZWrCcqd2vryN5tdr+NuqcSO odGZJTNC4QzvvBS9pUeABaQf2pG0mN1AAd0rfbSDoPQRLbJxAGcNZ+wuRks0VPNABkSOAnKPY37s t4+fP+MAPz4OvGP8k0yE564t7/qxRMuQ0JipB/+liod8Rhf1xJ+9GUoQfEQkFbQ2z+pThn8feDco P0rx8bePH5CbUY1nJdsTDpx/U/oV1VYmcXBV34boHJIbTOyxmqtedJDjQCVTMhiJ9jbq4hfQZ5X0 TxD4LoSNcYe4X1xiup7RMFaYtU4rfavT6BTpjUWsNd1Ts8r/n71vXU4cS9Z9FYX3n6oIQ+mKwDvs CCGg7epylY/xTFXvjhMTMshGbRkRQtjl/jUPcnZEP0s/yjzJycwlCQkkLChRsLB6ptsGC6G1Mlfm l3eUAQic0hJRNTqm3G5wl6zJV4cj/UDyPDI6HEmyLPd60Mwrr8MRwLad+T2W5UxYGl/VWEK7karG kjXs0U3TaHQUDExlOWYrJ8ii0tDbeqvR63VzNmxTGF1yWzx4DD6dIJHUijH6nucZrVEqVnU4AqK+ ajpkbShkvlaljZReATuY70fYdHtzau6q0sadlDZGEjCyD/P8otF1ix2OwDVG5tKCrSOpDVNtLgRg pW6r0WqYlNJYgvfn3LbQDA5rC1P1Q6ttlnyefsU3NnfuZOZYbHxf9LnpWP13YXw2BDPlaUgld2Rb lprc7SjdJvqXslAVHNQSdnuvfW2Z5Niaj2+FgwyyVofeYEaDiln66tiL6i5wTgASeNlJk+Et0OWm KipNPCtl0rRk4EfnZY2Tt0yS/DNTRL+sm+2XmXaik0Binnrw2dXQ07cy9QQ+AAvPPotqp9mUdbHs s/jG6VbwfP8MZgILDZpP57lgIFC0MxdMlXpSpZ4wgRjirigW19C6MPC+0cnRJZXXZdnronZ0Xc7b sE0BVclCHB6DT69LnIwBK2AN/E+pdzBq/Cr1JOxtLrdEVW11ygaA6QD6Lk2obCyWGIaSbCETjimJ PpPIA9bDrJRMiJAPCF6x9NAia6JF1g+DuOtbZbLakhqSgrk0ZSL4NAErqwxxeJTReHYDYfSJ7zxa /gtE0iElAW2uAITK3CqD3zHYjrXwUCuAhhqL71tUdVPDwoMhC90nh5vFpYd7k7WAmQJQtl0XjIAW 5NpPUPoDy723xzBByI3TDxYzFzDtgNVbJBeL+Q9UbeK53r1jQ2UK7lKUwpB1D9pW9hBUl0HXY2Ey 1HTid5iX/cWEjyzBf90ztYZG2U+rhH8/eHFtUBBUbXAOPfx90H0PzPe0om9QlgN4Ft0G6qtsdofV 6VC/h8/4f1O+mAVOKPEBn6yxMx2RhFr3WbMTd4R3595s6tovx8J1/Vj4z7//H+v6cu9bk5EzEC5h 4LZ1bwv9F+gd8F14B6R7f/yff/8vt+vt25PAfry1/b//kkWxVX+fWglIjJgTX0twTXRoyeKlDWoP UbVgStBcUg2dO6hogkInG6q/gmfbHtPhow4N0QGD7Ck8UCS9oHSM9XuAajESV5BMhCWDx1A87QxG IOsgIwiHmY+sJziOiaonP8osoopC9hSuNXhAuZG8Dr9VeLQtyGaiyio2DBOf0xnMXBA4njDE+ZeP MNcEK7bh7EMl1rPHKhfDmaEgY8M8ptTuL5ybnocSGIDgdOAkcnAQCxqQcXV6FFGAzsNm+51zKmKJ tePnW9EhIfvJnTFjC8hEi2g+8GbuUHDBJY7EeZq5qASo5RMIc6yun3ogmmd4zEkpIgMVc0Q21TZA 0V7JMKZkW4iYg3tHJDXWnfdPpEJHFAtTpqWy0O+KKjhR65qyzl9PgdXBm2U5kQ/yyxMi6Ozdw4Lx Va5IgFSVK7IacQdnYI9G3IlaW2yr7bwk2MoVueiKVHtGu2X28soGgbobxXZLVr/wGJUrEhBSoXSZ HU3bSls9qNAohlmkCk6XJBEbtW7Tk7V/rsicKriw1C0LjIV/Kt8V2UJX5DX2vSA4mLJXGCUX5Yak qG1Fh4nL5dKsZLlxELCd0pzCSj/0Wc9he5gblcEq8BlYezbpVL3Z7VaFIqUY/7jDnOF2OLIVbq9w +37hdlmEjjp6Ly+YVeH2Rf2rid2WqrX2XP9WuN0aeIeL26WmZIjtw8Xt2wDaEkBtiqoHDgRPXsHc GTWOkeZqYRsqiPXQuPHJIBzyHvZA6k+sAVZwP2PGmkRFR+zCsFAQPpeexehBfn3utThJY8Wfb70g 8B5XXOA796P8GwCEWniYW/eT5z3ADVnrN5UarZ3cOf40uPZwQbhwCmrgK9oG+qPpubPHceLv0Rt0 ydg7b0Pf7vADaZ8VewYG5OBhfvGdIaqce/gJ92BLkyUxxNupt3VZo5Yb7BbRJwMfPrTsOYFEjShp TmyIcq+r/ainipHxNXrjw0VJDNltmRLMBD1VPBYQGEEPcJjW+cBMiSAc8bhQiqH2ujrMhgGalJmG sg1DMNyBFeH88lz90z8j/o0G0Ez/NDEOSTzN3gOq0CPBz9CIiCy5VHeYJvE7C9tc1Dp1xw7uapYL PS8mvgctlTyXUStTWpUQzrglK/rWnNJP+DpIvojOZqIt4zorBnY8+z17LYtJENGWJFKyYENi4xY5 O+RoAomLY0gz+frJcJ37cbSIAeTo2H5xjtellqZKLbPi+KNkfcQ69J9z/LaYtjQ2BVZ5dFhey5U9 HnvsVxwA8Vtd+M0a31O+S8pjlkj/EHxqv+RfDCnxcAsZSGuLrHXohOfU+HTzRbgKJU1qnUDFTfJc 1n7i0miJOUfC0LfugtqyEK1JqvAOB9pgNgNI1nvokTN9fyz07Ft/Bgl/mOojKcK71BYkdmBOagqz 80jqm283qdVxR+D39cXnXwpCIBICyb8am5mqoptSXm50UW/EzrGZ0u4qzTaNzaywGeoqpuTXkYBz TRUBkTQ2o8TSLGwGCcBhWs22VNzPwWW4jiKYjEZt4m7FUb85MgsNq0Fou24Bk8kKNL81e3mNXzIP PJMBHfvOgpRDMAvFJvbQbR/h8Q7x+Nu0QrbFsKXp8V8h5xA76fUh2fjKt5+cISA0fNEPHEi5x9Rt gGWX8MZXbzYehmnJ62M2itDyqMiNycQNJ1DWPlkvkDx7A6gHkmuFL5MAp3ayiR/vENu9ByfUvFZh UX8eAMBDCVaTGpng7uNsbBOwk4sAO4kkF48MUSE71iBMFQ1oEZI70ZobZCcpPVPs7nvfLnIY8ep1 w9BamHUx91SBu82qgUCJa7sYotyWxtw+xFtaUBGsp+Cqd4b1VL2jdxsKyuLKqvlRq2ZbnFsa1usP RjP3T98Zj2Hu6jlAus9eCqOAKY9Se1+lDHrQYJjUCxQ8IkC9hmFS42OhDb8iHD2HEqnpYOTd2WOn qCNRonAAjyAkiTOPhRsq78Jy0Bfai54PxZ3kf8Pqzu53BwpNAyiLfnyc4Zi6ANtipyjPnXdqyf24 JHxrIjgYM3yQEIQbjNbAqdsqd13bdbuOqwWPSoVTGU4VVV3ttX+4jqGYBzI1yLyJEemTtedqMECw rSCzJvVaMK6HoyAzNPmEbaTRG83Nmr4y8Jxfvrr2WSxFJb/mD030OotR8x+g9Gp/wEiC2rN9C5Hr e893gtFj6B5N7hQFydbmPdL/WwIBW0fgeZtTBIdHfeJgC3eIx3VT6epdEXUOJ3g8yXIUrFub5fb9 cCZXSF7MtVe4zUNViiRCuEDjU5inF5pOpNDh3tsFOX2Kd9NXe9NEDoIOrJt1disBatEC3Bh2vEYS MXttS/K6JNaaP/H5b1fd608Xn38VjkZBMDn58CHwPHdKWVh1z7//MAoe3Q+JpII8gV4D7zEuf35r 7jbjoEicc/5e7RO+YSOeteHauqYTDXWHWWWCEQMs4d3Hr0a6N010/MKipX2Dl88nOWSB8V6h05EH 8RGchbY+XyopOItTo1ZIsUwPhQFt0dycFKk9d9DlcFyliOPWSGDJri2+foIifn5+nqthB5N4x3ZQ I1U8LaiR68H3oNLKGc2xdkXvnMPIrVZedGhW+vfae7TG6GNcq//ammgoG6keLzaMrDTTz6BGbPFk U+UATcQyNNOEc2PxbHhXadZKs54e3TiP0BPys/0M0e8Von9NCX921enxZV3lQBveLNvlGguQ7wvh B3BzBaRbX6+1kDTI59FyB0SjmzCKKq7ov1m47hmeNYrLtSibc23H+HYjnVKjC9151D0fDcHCH8yH lNxRSk3ZZEcBFu+bK+qVSGcrq/Ij7TWBXlr+C+Rbe2N0XaWi7NS4Y/0o+zaDMj850jnfnAKRTths duyWRQ2IhzUq2n+s8leURMPUSh+Et8Uqk+Th3DixY68PZ3KFmyVabPNQleQFS0U6r+3pwPNd61jo hmmEH+vCueMOoVAVkgqz6pErO3cl9CyJSsCKVSg03/E6l/hVKDR7IkHldM32Cq5rGsah0G6MwDAU 2q1CoY5V2B4vSSgG2U4/io/yZb8HZ7lZHinRVsVH9xAwJvJushmy8kKH+bkpXq7ioznDgypVXY6q ruKjxnR/lHIVH90FNd6e3bhZfDSlmXiPjtYnVXwUIjEl9KcsyVDJCc9xm3lUxUd3IcuDs5LjozpM 2JPEVt58xG3GR6mWb5NoHoV/o6Zf9ISF2rIWaTes98yu2Oxw1PwhGaDYrL6RRVt5i48mhk3mVII+ 2C/LgdH9q1b7yYFR2JUiEdFoMCew10Lyxc+MiEpdRZMlBWnNXe2nAv0gEYHMgpHnnx5dOg+2QAWF +O7QCuzTI+z4WhPVmty8EcUTrXkiiv/DWHaP0xXmAkeBjvWbrJC3iGhV+zkNdgF23p7hulbtJ0jy KtJZRTrX8e9tHOn81X7BEOevVYhzB97UqNozp3qSyYEqLFiFBV/Pgi/JmRVr5rPl/gWbOV8ZE1fx wCoeuBbSXFehVfHAtba3JHGRl6RTxQN3QY1YeFeZKnfBikr+UCVVgbTKxtqmjVUF0nYhBEsPpKmK 0pWbucOQthdIU6g14kZ+5i0G0mS5Lbc0BUtmOPTcU3P+g/PcZ42YUkSq21oYMZUuNJzCNEsrmPn2 YjhNEfevJOonh9PivXk9qIZbvQ9lhkpTkk2ti7EbDo/mxlkDe+gemtcAJ4Nqm0XxeQuqtX1r6Now O+tjWGX4mbdyjbrQtx6cx5kPpZJViLAKEUIJfkn+kthCz3CvrhUijLVTFSisjNhtGrFxSWQ/wooY LuxX4cL9CxcmZUIVNNxDVFjVEr7aa5X36oywFjJ5FKvQZxX6XMsRWoU+WdsZMnz3tt98FfrcpyKs 2LCqQp8rQ58pxVQFQCvbcZu2YxUAXUvvl+RjKj0AKvU03WhK7ZywQrkB0C1GLlW51TV6et46oODF nzrD69MjNtSKVfnQWx37zpq5Af6lKSlyo32Ei54wbLLFLox7XCyUHXLMqt3zMNw6H+MYeA922Nd0 W90Ftx4pzFpSkTBhVHs3ocq7qP8oHaBCha4/1oVUM9vdjmgs1NxpzY4GAUwqaav4n0pmp3+aCAye LBcr+cLQLg0Kn8f1tsW7pSmBxIjD5Yjc6gjX0HZh+TiDVhH3r6y2pB3KadvA2/QmoNVFgfahyctI +PBgYqceeqkeAV2FqSvwDe6W9dpUyCxVUxMbNCGD+9WvMNa5XFuOTOG0FQyQ4Mb+Di2k+18+Czgg 8gahG4b/bij8F/2dl3OXQ53UHA0mUxCRJRJ3YADrgVbD52wJb0rw7Xn/XkkWydYaejVXqeobVriP 87phqDw1EXCDN3Ok4aKCAGmDCmLvLcBwlHBcXJ4pFFB5JygEOj0y/aSD7QETARexEdoQBHNCGJON AGhoz9p1A1ywiaineADWzwmD51gP7549/0FwxsLE9+59ezp9vzS+M8nlm1WEcEDZiMs79sB+vLV9 GrItF+b4zab+cLAvwVli5viBsX5qOeQeiaX5/hX0VI48hoxYGAmO68XbdOR9KNpYJBPAiI04wS65 hdyAzuRD52i0UGbH7MHN2nIANef+sLDVSKRfkTo8uJ1ziLFo3cCyUIkDBoxVx2aVeRxAgZwtqdxf R/+0/aE1ttDvuauJJcCBbCpeRq3Uj2kMPdYY8+/g5RTHT7xCV8TXVIqipAS/dX1hB9mNinfPwEo3 wMHWZh+IjjtkmJxcW6jsuIX8qbVcfP5VOBoFweTkww8beVGyeuoLeNHayYdeobiTl1W6eye6G0hA 0YAwdz16yQuj5Uj7AkYepe4eYoQjZ0sqI+/QjbxIY/BnDsVPvEJXxNdUimIniiI4O8jyJn6MvIyB afO6ClhGQE7ZwAcX1nJdA/RHm1i+dQE57rImdXW1tVAWoYf/HKEbM6Dkf4inOU8XQ7gfVQY0Gi1Z aoo61gfAJbeuabtuf2INnPE9XPN8eiRRzC14mcBEoOF3KywkiG4WlX9E886+sg9RriH7DGhjj929 yIQzUew0O2aPo+5vvJU3SVQMMe+o+Oi4ru3Xvj9OJjVbDpsobist6JbY7Nac0s+SYqfB2e84Y21h IQVKmWAr4DnglM2PHJyBAZ2En1DKJBmGaOodzMrhpNPhHvP6tji2NB69pHN2LFxCQ8HlfnwjkK++ 64wfBJ9qlvyLoURJPSNnGnj+C8hhEuKpZfaDF9eOJPl5dAcmbMsk1bqO4+54WAu8GvwQvtz+YQ8C oTse+C+TwPHGwp3nC8HIFrrfA3s8dW5hBZeQ32Tdo8ax4CNXkO4Ew45t+MULPNh/4d23y6urdLMu OLTxlnEQowuSQ3IWBBWM2MtsdNWzb/2Z5b9QypMivENBlUhyjJef4BhKd+KRYxZDDdyRd3nu7Vyn IN3o3BaAcT2jK2km0jFLJXAD4ySz0W535QrGRXX4TCivI0iBa8La/MwqdSjpBcnPYNx1z1Qbcojh UxqixLG524Ju4cMXgGtxFfP8aP1MuNYwG602nM6cswnUWLbQ2FtV5wXYG7QQ5zy9LS4tDa6Zvjd4 WFC5e//QgK2Gx0KnMMIk055LvAAA0ppMXGdgIaj88McUkOWlPXQs4QZwMIHMj9aT1R/4ziSIUOhn L6DLofoTqkEPAVCC8Pz7L5T90Kh85hJUFBuFoCKlw3FJ+m83qWP5VqGiIvZUsSEZOeqIG6ioqk2t I+euo1KrDPY8nxRp6JINFRGGJ6GiSi18ooRf5rot01+wVaioNotARQkBN8IN+m/k0/tZnj3N7LR6 egMhepYZV/H0Ojy996jroze176aAQI6FfmHoRal6XOpfgF5ta2pLjWP6qcjH5LbD9xqq0LECC919 3hD8eVO+NTXVHocQS20eC18GgRfWIBZEWZSPwiWVK5RFcVWp02wpkmTmSHJuUJZktoyuqGFIodJI 2BqzfIccVdfPHXItlaKLfKIsePgiKEveKcrSzZbZkloVyirDybz3KKs/cnwcyHZdGGJRogOPyvci nDAi9O3BzHeCF+EX14MQqQ/Lh5q2KYZRqQdCHA7kzgmSgFYga44FY3Y/mwYY6hT1Iv4rFv7gkbhV qJNlrIlysys2TLSDshAJN8hKUeROW+5VyKoMLZTtv6JEmBhZaWJTYehtWzrrdhtZaq41Da6hhMH2 7eGVdW+3fdt6oC+C/DUwMnFZRTAXrX1nni29rTQ6bb0KgpbB7dvi39KCoOfebEpTcAuDLkr5OOFR L5uYoAa9tqzJyBmEKWm20H8ZB9Z34Z152X8PIAUS18YBBh3tIaS3PdmuN4HfyOdleoDaxgHFHw/F 7YUy6Vj47D3FvbcKojOyhXnkggqdMXSmi82e2VHyUA036EzqGA2j1W7noMwqErNOJCYbnVHS6Ryd NTTyCnHp99Lg4YtgMHWnfi+pYxpyr5V3NiueXoenDxGDkb3Eo/aNMFgKPy1Ikn0tesjHjanV8Omp 6990/v5LF8H7iglnKCYh1m1PgjkubBXy2lUFCtNgX8bpzVNjgCeLFiiIYqst6WIenuIGF2q6KcpK pUNhOBgbFMg8amUWKFBycYwLG1KklbelcbfitWO+OXz4IrhQ2ykuFCVZajVaGPbK8qhXuDDiwCKZ lNvi0tJ8c33LGQc1Yzz07WPhqmhQVOY25X+tetEU5OIEQGKN64lger6deno+ASPhRBSbx8Kl5Q9G VMQqFcKIVWUC5xhR142W3G3kFX/ygxGbZs+EudGVPt0aRqSzPseI0MGG4dBtad9tYkR4+CIYsbFT jKhommi2O3lVQxVGPCiMeG75w2CNglCoIQcO4NFzeANVCV8wPivIdZECtZ7v/MmqPXu+9WjjPKWD wVUgalLVCJJcCFlV1QicIyu51211O6KZg0jKRVap8RlMMqzdWZUV4W2rWZwigiNa1fKA5h4qM+h3 CU9FQ+nlzXrVUsZYmcWapTgkMB+N1ZFmx4gTPefAMmzoWlh/kdgPhRqarM1hyPNcokWtkEcx6lAH G7XDelbIce1JcquTI3f2+6ApVP68NmPt+0FLHh1Kt1p7hds8OqVIFex39tEb21NwItWpyLRTF0JM u9xCb1tSoKSlVB28WQ8gENcldqUqiThwmHLHNGVNKffvBqTE0KKYfxZfMS6ko1V+Y4WyV1t15gaC 7WtCSSGT9kRo25Zv+8KN92CPhX9AH810+CDiyL1lxhy5mBr2sPeLCPt7sqgHoNvXrPNKV117j9aY vE0GdIE9jcc4EOyq5NyfJhqK1KKdeSRRtbAzPNc3579dda8/JeYTca6Ozmi+EujWGnRyg67Hdc+/ /wAv8V9Ut9XEw6CkKRElHbAc2c3paNzgbLH6Y+/1Tg4BeFOey92TQcgt+DtAABZNUtTbTbmr5wa5 ynWT0nMxyRy1GYte/egwDMVUdFNS89y9e+h22TvTDqizyjFJBU5ha7yvilk3r2EQhjucOve1ASTi yDUZkurg/1TwsT1psK2w9MolFQhWw/YwD/48V/hndlxWpV5P01oL3dAVwzC1JqWXVB2XkT7FWkM+ QhVnz/cer63xvd0PLD+IIhEKZeWv7T6Ej7PMDbyzoqlNXRVlym54Pom+LP4KSjtc+yt48FBm+1BM awwAljUEXAw7R5uDq4t+J6rgwIwwOgQ0IcrC6Mb4rYOdYB/Op8zeyWsPpoPAhKJj4QaSXHEvF8ZZ sneWNjPN4ptNRs5k8bDPfkS5mDybxfP4ZfHfnNmx8GtIk7gT0QJLp6lAYcC1pUAmFcIWthEVls7P lqchlGRABTk8b1v3LqR1f1xnd9XNAqiZuxum4eXu7pbT9La7u33P9VhS1CaSGbaZJPOeu/ByOKsL XWhc6wF4C6cEpNbPTu6NtwwQ1M0iqJmclTi3N14kO9XDDWBudMAziUBVveUIz4QKC78qAT2A2hwz +CqtlLmtJYLfhNTM2NYtN63apcy88SL4lbHuLdvO2103tPYJLFZftSAsE8hcPVjrZiUyx2F9vfpq SL7vWvLs3PGng9ECbcH7GKumg7W6chDCMdB0ARmAhUX+2BUIoUT7KuFCSCCEt2ZdveZAWClyQ/2e ZOPNTC8erNMzlEM3dSFyFKTO8px1914SFRwLKxMleazR+Hb5Seg7KfIsuNT3NRXnfmwFMz/uBsim 1HoDcEzh0Nq4JXNdTC0OeC8e0srFQaKmzF893x0KX52hLXy1b6EeeTz1/MCZPQrm9d9/5QZIwFlh jeNxtYXqUVjGN4+cfH5z+YlvUi9HXOchHuDbopHWhqgYbTO35QRyfVT8MXSeLtC9TTktjUZLlppi qKeCW9e0Xbc/sQZ4np5PnmHcNWHqAIb5nR4Nv1toktJzRbFVunWhIe0jYGWoQcdeu3iH8DMTapIx sVi7w0ZT1Fqailivap2xlfEYUPEBhGUBo3lYEuZ8U6BVYoFWBWaeb9X3cEt3vzWn9LMs0/Hs91Ur KhBnZeUwwJ3zQ/gz46zQB8nUDSOvqRPQrZpsSwxzEI1j0i7g60SogRB0Sq8t4LP9S9wPzuLQYOiO YAZ9QTDNaoN4hCAIpmHMGjatxnEgYZ/qHGQq1aUUWUHSHCgyXVYoUDsUN6ApBkspGMEjT1SwNIRz ckOT5E4HnVJZcI4bWKo2G7LcbHJUd8lbAiAVjydg6XXXxAzAmtRqcTokF6FochVF4Odup+XqzbbR VBq9nNNawc+D6knT9i0YY4a5XFeW5zosyQVxi1kX+hPbhwGr97XLwf+Z2fa4KIrjtuF1sqkhuChm E+ETpGfOoIhPeAcI770gHYZPUYGu0UmhBEEm+9Zn7kIUtfVFeDo3hMnrwzR2piQABR95cRS13dM6 ep4g4UbtS4rW1LQehryy4EvmNjATvWPfWTM3wKa+TUmRG+0jXHSYAT+N/Wu39h1kt8NV6JNhL4xZ 4IUXhO9bd4HtJ39fuIQ5apg/jju1Txg/9EbZt6zvPKeup+jxiyj63Q5sVbrdRrttVvUseD5/1Mu6 9/HMvmvbT6Dfr+PWHR1r5JJKp8DSfN7Wi2BcXVDwKRlDUl5XCqgbbl0ScSl3vmzqstFqdjkQoCvC ImG970+RrS7ADtAFFJyxx2G0hR4AvdJMyGe2dqKR4qEBBWW6dd++gwmHY4iNhmOAok8lMgzhM6A8 8MbLpFO1Tq9hcjFOkyPS/XRhkc9PQHVnAOUCTye+PQgE7IX2r+8oDP/lSKIG2ZjT4MUFbPLsDIPR ifjfI9u5HwUndV2bBEeCdzLyLde5H58eDWDanu2zt6YB3Cb8M/1y57guhXdOj/7LEvF/eGMfmmTA hXcR+9GDAB/C9kTcGMoT+BFGGm9dYH84Gq59F2D91I39HfCVQmlhPj7a4ptPth8Y48HIA/AUwMWI seB2k29g3QxOj+gz0Xu/sffCpRCigkvDulGVxcxSMVC61XKwlOBM9oXg/cRTho8PDwKRVQJ9C9fS Q+X9GbYGHgq/NLwXvPrkeQ9wPckLUTXonneQShdcexi8xfXRwFN8Nf+j6bmzRyBd/PfoDbpk7J23 wRAMPzD2/slehenI8KUdezrwHebwDr/btV68WRDSEy6JifaL7wxx3ffwE76Fra3B+guzBUVXBEjd 5QBXwq6Qew2p2zVwk7PwOH5NkSi3f06sHG2bDL34I4oXoSg+dagScgqNsxlmOorD7gMXmsUgbcKj AdnkHr7E03J61GrNMcmTgYcsetQkfxYJp8t6QwH7Y8/1L6zOdcYgapAS4YvrGcoeK/hkQ6EEI88f g6xt2LZy7tE/IWMvKOI4dgMPZkWSxhvgGlaFLRaid5fe2BoQ+XGtr00lCq8mhr1l/82Kos8fG6tS o4173YEFvH329183X8BPsOgKiFcbCWk8CAN6gWkq7DAvAwmtLZp61zRgV7IOLTza8pkvYERP0jlq tjWElJUwa2ENQJC/5bS3+eoTlhvCsUydvvF9kQCtulz/+6+LMTgHHqF18pMtXMdobpEqBN1A4JLw S8jdSHe1ksprMgjPEnxgWdQtZ/rAw6QVjgfpOjlZQUnVlpE0BP4NLwi8xxWfTyi/jBsw/tqt9mPP sFq3yaoeVqalVV6zGXWchz0trvO0Rk9qqg1UzFnHp6jOK0ZvXN9q1UYAgYEWUlp0SoqoIrHVaHZ6 SjtnHZuKgcqXhmiSGhkjZo8yu0zjiinNTOFkTQdOotUXfCpfXMEfRxmdwVaoHgQvYngE1lU9v8OD F/GfUS0TimCmd0ALMV2E/w2P5yCUgJkc+2OwStLVZktvl63S3iYvb4tDCVoD9zLT6Ad4sg16C1wp LrjMDOZC69aFsB0udL81vcdHSPwxIP8pwKzZK98LPPhy4QmyfciZ9mUQeBBNw9FLolbPUOAodudA CmUwPPcyKkpYQqrU0qUulevyrRUMXZTzI0WZ21AAHL7NkxR5+FK9HjRCdSzCclHr1B07uKt5oLtH tT+eg9otdS3lU1fkLqeIBtnxiEiz2ZWU9kJilNzudSH9vYN6fPn4V3xPoAKE5YIZvvcaJO6dfiyY 1uPklnRJGzIvwnSLSyzseYRIcFaeRaK+WSNnJ55d9GleOg8200PIL0MrQA+KKCk1Ua3JzRtRPNGa J6L4P0cIjvZ8j3L6J97a904cBOFgGUCri6iDeXbDiahKO76MACyjDi2QodefEmtaD5wn13a21PH2 Q1Z39qEPuQu1TI0DTHqESCh1V3yDt604NDLnnEROW8kCe2Gc6Oxj/8tnKqNk7dnfffx68z7dsR1g O3jf7akATrf5BLOQRekevHBnDgVTvWjZyUOBk6hN1zZrHsCBXM7ZEt7UC9CKTcdYIXTia7hRLPMn LkGraKRV5rfk5dDGT3xQpM05d5wqkxw1EmqOtOIQTNeBvAiagAk/nQEbgYmA3yD8Hg3F/MWHDqVT ZNNE60Y+0fqihgGe5kA3hCNDVmHVBeoAqACDi/ncD7YdToScRBVXH70KxWk2fDjg1jailuIBWD8n zJ2jTt7hGF7BGQsT37v3oX/K+4VWU0TyiMsp+nhyiH6HiK879sB+DH30klyU41nv80Pcl+BsXqyr HBjrp5aT5nNK3ztEeuYAMd4MIDiuFwVsoORl3JhBqYdetoSen58pdkOzmBzMuB3bQY1Qy/TDKvAi qvG4ptRX4DGonG1jC53na6c/lBRczjmWnNpHwF7kKAunN0UveWG0HGIsWjWwrAW/WWOzjtAc2EY5 W8Kb2jhM50q8qoxoTKwt8PDNL+TlKM6fGCcPrqXttFjbzW/C3bJzrDY+iZkjRDhVcgc6nJB3j8ZK 9wUlxlZmHRepBStEH/fmyypFvbaiU+uT4V2VQ3Gyh6kyh6XxIjvuqtNDABK95AVU5RCjgFlHmbOV 2thbtRED/BU6I76GGz/g/InLdAJqsbaY35+XExw/8UHROUcucWsWheqhymIIXivhhjkVQwscz1Q7 WZInOTgraZKApimqouk/2mNh5/Wm0H9ONLo6mn5ZFVLg9K8qLIgBi/RSz6wsalA1QmZl0dR6dOVD qi1KLqhAdRFsDewtgOXd1Keqja7UbCoL/d1kGC3QMLuEaiveL8z7e56LF5wlSoqQ5RIKGEy1OIXn YHO7I3uUleaaddyD6L0Q4bJ3FqN2B5u6F5zVj1OcAOsHDM1BvDFnFKKQKJBLLYzWFbP44eYfZhs+ ZlhBeBmXo6c2hx+qn0EZferRU1lZ0E4FSFz5YfbWDwPS9uLNZGUhnyYXzI1fKfXQ158uPv8qHI2C YHLyoVjtZhIC16A/00FsRLZg5bdI97CcShGM6xuXnwS5LkYVm8Z0is1WoOtKVbWp6NTEs1KPe6se D9N9Ha8qI6hdqBdAWp80qrrNkxLaspXkTT4sNRKcxQqkqtX0b2iU72L4mxP/wBk1VFsqd0jJkhWW 5MHW90RISaI6xegV7gS4L5nFsuD+0g82aT04kxopHuDHEZJjjqxXrUkxr4P0l0R8/dl72qBaUz/Y fJ63Wa2pV93QyKW/t4YPHNe34xdMe9Ti+ptCab3U/iO5W3w6FRNBf3AQxnU43C8sRyuHuCpmcW6I dljWXQQK3lrVqX6wEf0c/qyqTo+izEGIh+6qZH2V329J66GInH8AX/HQcWD+xCt7LKScDlIj1nfz j3O34BWajr9V5YgRbhOsQwWXyO/a89S0HAJw6nrMPhur6k71g80wy6Esbxo6aZlkk5ffTIDk2jJC dEuqeg1VN68lSn0JL9ou+dCHRvWcg8mpzgNKUUOht1Z5qh9sJmsOf/KmOGIwvEJ+xNdw4xeaP/GP Vp4umkZRp4L5N/CiLOInPihK5xxDTtVEcFbVnu6yi2Fptadys91UGjTSPatmE6Nd0XjSFSN+C862 BWdUdLOcMd6ZkyOLzDpVuz1FUUiLZ60DvHdV/V3h+rvM2tMm0SasPb35R/1boyXWpVaL5oJGXsby A6Pbmnp6kVxCgfpSWP4u60sbimi0Wm1EqRV/bzbsFqTPqvHh+5MKGpxdULNhml9hucKN7doDGHk6 G4czLabCP8aQip81um7P/ZO4tHDEOpQS3NiD0dhzvfsXoSYY/c91SbDHAw/Hygv+DCZDnQj9iT1w 7qJZHt6d0LamzkDoRpdd42XCu3b3Gtrpm9bYwz1yl/5uwt9p9F/HmeLI2JkzHdnDpcs6eJv//Pt/ BZAOtZu//7qmfQfvKRsl8q0OMu9YQKFXRzQd+4WRtcjmWHOmrCirRsuQ8041N9pX6Ypqo9NamK2p h/8gUKq07w9qXyo5Ydr3i9G/6NfR4KsNYIJlDcp0at6U9TbZ1vnflhrOXksRfSztVB+rRrcj6gZS pdLHP6qPR5Af77vO+EHwacaPfzFUqIHoCKS157+cHklHlHeXTL7rBy+uDZKFho2fR3cIT0HPgwlP 8McSlPp6IzuxN8QYnvlY6C+piHiZS2sp8XFLKkfJaQuwFHuL15QgHSX98ki6X+3HybHw8c0SjrJ7 eSTc1chxJ14QHAvXh0k8HGKXQpzPJ1knj/LTeCRgty5cWq7tp9YIqDpeJA8i8yzLIItXkBCQlKTA I5niKvApGVNQ2hd4oHBoDmMwsmGILyBToW8PZr4TvAjx5UBc/2E2ET5ZYHpZ97bwDssD3wv/BOjK OcnRWgyXHcAptfzh338tQvNjXP9g9PdfsihqSwJqQ8ux2zC0VicHf+JxiVyte+23FRWx2dGUvHVU lqNMfsfnk417BjapAjO0HCf2+KJTv4Tpg3AKeTQZXWsaXINDxvbt4RWsoe3b1gOZ1sHZ71/Syyti Rco7tSJFtdtSoGtm+hRroixqXYOqRSu/SWG/ybZcH2VZVGd968F5nPnWsfAZ2oi1fWvo2i9ob8C/ 3tiegpqAX4e2cGkPbcf34I02vJHoxBa1HwO49NGCjy438cqCG5TawiPcYOdZML3x2B4EsC1MbAkS 56ghO7GBHM8pNJTqydY82OrxKOfs42xsI0YqPg22SV6iQ2zEcwj1xWflQF3N6Bp600DnRJartVyo m2pv2dysfJ3FiSP4XXamQ0NrmFIvN2a0h4gZErrgqWh4e3OzAnLCAHs3dWYeUM5OmCBvDAPeV7Y/ 9aL+88n92L96hW1FesItKALK9RCUw0adoUKcW8hg1Q7owA9Ypkkw+Aqs9Xx6lJk49GS4zv0YLqAY wcDGqDoLEBRJKdJ7PVWTWqh2s+TOnh+0zfKZ9/2gJY5Oi0h+oLrf+9NxXTAUlgH+nls5OWmuVbb5 XhcST6Ej7dB+sl0PArH1R+A+FLtw2AKfqkHwFWM88sOXn+VXko09f2I4PTS23R7X/tH/MPQG0w+R DuZ8adnGI0WH5svnhWA54oLbrPhLJriFkNeQDHGSWHSE9vb05BAjVTy894sIWL9CY+I7LjkTlCUr FI7JAqxEMpF8C/xMWAf4b2L51sXw9EjVe0a3R3XGWaiwXGuUnitCusVxbyF0K8pKoyXlDZ3K3AaW xdex76yZGwDmFpuSIjfaR/hkYWrtdGINMH3z+eTWhkRPO0Tm7IUxC7zwgvB96w4gefL3hUsYHt3T EwPUCVedaf+1Eil71z1Tbkg0omh7J2hbllv48AUsN1gyc37sxmKTWk253Wu2+bHY9tinkRFJUMnk 4jGS0HNsF9PKDzZBaAFpZBGPxBGPxPvFDoIXCIa92cQ8lUL4PJLu0rufuW+ZchS045FyPf9lGrw8 HAvnS/g5Fi7kDKD/7ClCA1ifbS4XyWNWuU1Bv4QaKfR1Hwuf3izxuE1C/2Rbg9GxcHWYlCuWyKxy m4l+U4eJSdDYyZ/WPtl2CpWBuciV5DzLCj/EK5inM6vcZp2fY9VQYH8PhBvfGk/vbF+IU5prNeH8 5ubqg1SXOKciZiiDCQ/OMPBAABajLBuoYW0J71IrS7Bngrjc5qov9m7k7fj9AHDhNuHvqp/iyLdD Mo1bz8piH6A3RDNuHSrnN5ef3upB49aV8o1zmp29X7Jo5lECkBpFA3AN2VTlRm7lPUXJfOaP2O/K J9GUWmYDBX9WILEKwP1w5VOLzjpLwMQYVlNqsuy/beVQbTMABw9fJAC323omqdtqtsUO7nvF0z/a FWNbXFpSrlVwdm1Pof8Mpil2oUxpOVUxw1egcesPR2eA8OUJXAQ3n/i2Us6OU9hve/kIpTHa3IMB UhAK4qwXzOwRxSIODI1bLz7vDoyyAJ/Yasuq1DNzlAo3gE8yRKPTNCrAh5ljP6ocszOuSLvEgE+R Raok2Z6E2yLgw4cvAviUnWZcyR1ZU1Upr4FhZcSsY8TsPeA79+7uHq0xBieL4j1uw7D9S8B7fdt/ cga20P0e2OMptFylTjfU38YW6AoYiwyIEKNHE88PoMHNC7yOGuCkcBZvjlGWR02BI5RFx0LPvvVn lg/YK7Wu7UnX0vAjYEW5EFbkN+z87SZFFO6YrSznoN7uad1Wm3us2GgZUlc1ctZR6dV19Go2ViS7 cI4VWzIhqe1Js21iRXj4IliRWvWDaJj73cHt/tPqqRWp2TQN2ObKOfjj9k+Wb43bPJy+BemKNWM8 9G3uE9+KZk1pvCbWZOeldMfDWuDV4IfQh54LWAKGqX5fbv/Azk3Qrt9/mQQRgMZWkSGkvoUezink siCA97XLM+tFFS3zyrenMLnAnqePvft2eXX1PrUy7jAZNaRiBgAomGPhyyDwbm2ffK9qITzNbSIS 777X7ENaJOudAtInPFYsvOGslga3qUhVVgsrK9ckKF1V290ccMxNkENRWh2lrfdy1lEZrj9uuJJL NTZcVUWkousF3FTiRIktGq748EUMV22nQQ5wf4oaNDqoeLqEwN3eBzl+hTZxOL2F7Jdf6+DM9woG Oxrc5pZGAQvBgDb1TgAm28y3467+bBqdHcTWzaGYNSh+joWOPbAfI7tGK2LXNLjNYuLdrikrp0Tr GUqjQSNNsxIVuYFbUlcz21KvglvbyymhmGAMtzQZalNZVyJkkjDRvMw2LluEW/jwReAWrXBncYKG JmtKQ8vL96pMiHVMiL2HWx3H9h+guQsUTqPDGCYbzNOKC6UUN/hN8AQ3eF7qiPAO0ozfx4hL+CdU lKP7XKrLh4K+UBodC8bsfjYNyKfcLIS9uM0oqrAXc3VJattodtt5ebD8YC/DEKVmu1O5BUpwC2Tn aCQ66EMcCnwwVN7EpasLH74I9op63+8mR0M0ulIHBHPF0yXwdEaORoOsCR6ja4DKxs4A+oFh7m93 uFTLGy+WzKIt2UalZYQW9ehxm1IT++zCoVlCz/MfreBgsCNI03RCQjHwyGvSzRnv4PEHEhK4TSJ5 wwkJNNKSyyySKiGBWWmNRlfuqs0864YbK01TRdFomVWF2vY85KRU5x5yXeM3IUGDhy9ipVEjkZ15 yJWm3tWbzYqny+DpvfeQX1uPUxiRCm2028xHDrkJNzPsMVrQitG5zQ5klZYfLmHciDOZ+RNvagtz y8Zy3CiN3IMRk+/6Hy4vLrvvY1+5UpejmcFCf2IPnDtnYGES+sFYQSCtoKGnNWZlmTA5t1BLDJ3b PBXeraCy0hekZqPTk428ECk34ExuAcxs54YCqlDvOqHebBc6Wc8MnH3t13owWd4nGchnEkNqCUWA WmunmaMNs2HqLalyp78JoPar5SImM8FBfjkAmOJNoY//Jbz6xfOGBNfwBWY5GHXhszW0XGdcFMJx m3H4ZWKPLzqC6Y3HWAkYuqOnkMggHgAMi1qRtZbiIfP4HZiJ2NsUf9y6qJonVAAdDxTsiIquEibL SkXcJx24op/qFhLhcoM9rkUDBmmotz0OBTw9AFrkrPVrljIETxDENU+YMrQGD7WpPWBqMLoay1fZ pHq8Nh5lt0gyqdnSxVYLg0MVyWx/aEWT7X+IZD/dEM/nIyC4M4DBrU8nPgotB+Z+/us7Fu3/y5FE DTKQYDSSC7Mtn51hMDoR/3tkO/ej4KSua5PgSPBORj7I9vvx6VE4c57emgZwm/DP9Mud47q0Y6dH /2WJ+D+8se892HDhXcR+9CDA2EyEgFiJ5QiIE8bs8AuwPXCua98FPd97xKHNp0cKBZt9fLTFN6Fr UWCMByMPhm/iAAw8F3iXb2gnnx7RZ6L3fmPvhUuh3Fe49Ct84hnGobLO9QFM0jg9Gn632HmCv5vg sejHw0DhSho1epJ94aVFxMfHZ7elg7pwLT1U3p+ZdMUvDe8Fj/DJ8x7gepITokqN907uHH8aXHv4 PLg+1wpf0RfSH03PnT0C6eK/R28w4eGdt0GDA57Bj4+9f7JXoccTvrQDTVF9h9W6h9/tWi/eLAjp CZfERPvFd4ZIz3v4Cd/C1tZQI8wKl0ZXvD6XVukaHdUU86BmUZPQPydWjrZNlqn0ipijCEWRDKEq yGksks0w0xEKXqLUwLUtHzc3PBoWDI3Fl3haTo9arXnnwCcDD1n8OajbsX3Gf4UG4GqabjR6ey7E YXWAEuFsISXCF9czlD1WAJOipsRWzyd/DLK2YdtKuUf/hIy9oIDjfBB4MCuSNN4A17Aq/WWhbvHS G1sDIj+u1Zg61unRjfNoT4XP9rNw7UE3OrqjAd3ZTo/Cq0lE3bL/mlP6SbwUbdH8sZ9Ppn9G775u agNvn/39180XGKWzAroiBmFoDzrr0HnIx35SS231Wu2yeXCS7pphWzj6NGxvtAaGy99y2tN89Ylb sAqGkWhlMMy/G9QBhqFXtm6ww5sFxkL5OvE9767r+0AzphzufeuxH1h+eAxgsjf8CdW1KpKTE4QH 6bhL58EWPnpje4rsMrQCPFGipNREtSY3b0TxRGueiOL/HKGczAQiG28Gco0xASto6HwHw2+Rc2gY +fPJIzQSvPGuAdnatJ54GWT4rb0M+DjbX7yvoqlNHTYkFOWZmwjIl+0+e5D461GfnKz99dvZxb// EozBw9h7du3hvf0I8n66uJvs6enAEVJaMLW0XsfQZQPWVCZuTx+3z5ho5X61b9l+rnHerOnAASkG qf6EqGHjR0yuRe8si7JkI6ki53GBuqRSyqPu1hYAZyg7gehmZI0fpkLgQVPwALwLgBGg/yYMnheG znQwm2LNxFTwbRdO/BAvw7Y8ApxFbFYEP1b2HlrQRREVyqNL7rJAIs58J3gRHj2I/DGfEa4xlmK0 xAGszYn8ualVxp8PwJiADUCf07fLT0L0PgQQExvnP/x/9q6uOW0riP4VDS9tZ+qMJCQEechUAmmS tE08xqmnk+ZBgIxpwHJBtHV/fc/ulZAEElggQBAyExuDZF/du3c/zp67K925wSysbpraUlDkG1Ru prLcpyC8mbojtDcdvmScC6128FFmi6tEla8ePYgiiejUe+K6UQGVkZo9TyZeMB31pa/es1ix3gg2 gwppBXi/Nw/g9UAI8Csmr9JyC3u7XvGpjqy2O9y+vUzFN1vEdz0PDwSbylGR+MGE3x5eEL7v3sNB T75euoTV2076Mt9Il7dpNzk3ifOi5OiuB5kSJy2x1VK4oNJqNm09N8eHB8KJsMEN5jP8R5aa3+p4 9y4y5vRJU0HdCou9mtAj+8bXbMkAMr97nwbwEBIJyVmDVkEej4ZWLWslIBoMRCQwkAtwRcDbNwxc qYai220uqZFlmy7A1bJhqNc7jtkxK87+gzE6TeBqyUIwubW6FiLGsuCXhHjf/XjQfnCnWIHw1S2j 8z1vOFpky3Ij9FXXfTcTljVAYB7BlHIUOV4yufaLaziYF/47D1oAS2VW3MgBB+MJjcfy9vdr++aX dx9+lmo16Y+xVAsAaVZ2uCcyvTnyOvMoRR54hKPQWmwS2ZPAiqPnOIIU50wzUJB4hjHPaZ8Nb1Ai h75hAehbFodBdhRTM5Vq4djYtVCBAgxmFlxhLc4B6ULT5OtBvu4l8FsEbacgXkWkEt0J4uckHG4J ADG6B1hG9Di4g/+kWCoGjROfyiHSvwm5ScyPwoh84fnJ3ZFbTxXkKwbLrVcscPHuz3yi9RjPTiMB 4Nzx+3NCmqW3iOX96XNqRNgOmEQeXwbabNhIVrYsAvCzHFss5lYB/I5oc3LVt0uRpHfFqr9QOmid HPJ26ZBcQd3b6CHI2db38+c0dldFhDXwU2KeM8T1G+/wMyv1PECqpBMHUu+ZoVYUDZG8wQgbFx8S Qik9zXvj8BSI5BLMKtE1X76kF2X9xtZlpaFqHdKZFd3Y22XtjrqxTz4VdSUrRYTIaDcdzTLKtg6P 84lwLUfjv4lQJMhPwl3AZ+8WNJuIZBTfwP4FUbCIqyWokky5QjIdhTJZODaD80ldzUh4YadikxTm W3Q87l5tz5mAxcx58x6ROPQG1+7Qs6ae+5VnPcdk3Xj3uBbtTZBBRf7q/V0Xh87ubPrys8hNvr8z pVnyhN1MmrhfKXdFN9RmoGnhZl80g4EeRiWS2o9SDb+T2sJkfLRkf0Tst+eY6WW59FzDXkPejtJ6 4tko4+qOhz6yuA8Tys3O6AwjJuQe9EyaFZxknON/350hrYdMbn/qBd5qXm+Nf6nKmm04Vh7jb1v/ MlYIx9cg24Fv1dUg24WhBbzXQyjH3B1gDgbYyjWQnWIXC9vgeuoDJQO99cb7az6Ch0bEHSSlQtZX IaNpN/VO85xFHixEbNzzMZpqycjCalhxIJF/YxExnxU8GEYP8yHsWjei6dzGNBuTGYej/8QhS+kT dHwbOj4Sd2mEc2Erd5Ix/Eh34gVZjlrinObiV5ygTYyeelbIsDWcjmGYslNyfFUhw4Y6lue1y/cO yxxol2djNm20xBhIv/r/gV7oStcoxQxaOsMHEjHRxt4VebhXINB93+1+/AFcrlngTeDfkcP3/u5W 0Lnef+zaEqjHbuglFtsUqPmiGjgneMabYj+oxSEkB3hRSK9KxL/iwEZhU34q3h5OhY2R4Rd9PomH P0HKue9P6cQcsW4LqXzF1BuW6lQXUuPuT+X7ZfvEK9S94xUljT43oLiS5SLRgWwplmHq1rFUpEjL QRfEnkbZmJp6ZhGxet4RcRvQGh88AAo2ehwFI3csvbNvHWkwBRla6iEwGEjzJzgO/MZVz0VZr9nV n6hzdQV06IrRIQKW/wGMJM38iSe5A+QzCuvXerOumDa3CS0zZXEcMnHCxtbPIVyOMvwpVkCdA+f4 kJzwI2a5nABcD9yLHBFyINJU8obmWC1DN0tWjMdf/TMLo+pnEkato6PDKTkaHT0Fpl+46FAH6XoM 0B7fNhddkR3LsRVysrLMJGnWqLzBmlRosGMRBWYVYW2YulbfOiqm1TyRWgyqapta0664gcKS7Exp T/ou21Ee9pvdWqVrk0sRUgpiQqUoLVNdbGP1MRZkeKzihRafU0AjOuLMMnahxW+knEfzBZnaDWYs IK8XWvymMjDRqrxMil9Ii0/4jmRYN3Pi0T3BMTW9bHpGmv779oi1XTJJOfnbgFcjnySPOX1DGVB/ +t1MApMAjJmV6h4c2mb47VEtslayGNlTPywKE7q03cVhdRT/Ythgqb5Y2vU98VpkwpUXdhsPFtUR S1Ua01Sdu80tFSDTZTkiBybu3FyBTO9olgP8dUfnOaN03OpqbfZtE/fATfEFbrJbxTBN1h3HbFbc SxX+4QG5ckVKaMXOZKb22Ce7o8gwSRmtFvmC+glVvzAA9DXcYf1QBe1B6uodxdJbJ1EHYt/15pIM zSLLeUJSdzPq4+juQLI4E5Ci/NBTLCSQBJG30Ga9bHScZktrEp68C6hRYb3caDR1u/TzGPuAty87 RBxI4J0sbHKRjVwlvax2ZFPTzLIJORepWxy4rZI3YFkfpFuv//Doj/3hyMsKTULfoIhmdup1S1Xz zgC9FG6usGbWGg1FtukgUJbpAWyy1RHYyx6p5B6pisesmGZdlR1KDl+kjixtcUNLvmYYQjIfsaLh JPkDSh0ssQ+SYoAh011pcL2Vx1xXgIE07fPVy0ZH0zuoF3/ZIWH1xLPeIVXRy4ZlN+1Ww75I3bcg deaU2OGBjxZXv5mSqqpyqxw4Q3f0VqvVyZGi03eaGw1DadftS2AZlba9KOdDwMxofW1ofMzh4jSf vdP8qVuKLtbazY7RYDJQltCcgS42EV5o5imEkigWTwQ1rt/SaoQxX9wXSLT02ldysMe/uJfVbYeh 3kqGoHsYNAWk9gSNyV9XxulumLpptvKyPxcIbnPfpxgMiZtaTZmdO303MJifu66lVboZE0rxkmP8 VTg1ZeJ4RRMp03Hvp9HT369m/y7bgsVjRgdK0tA2/ZRVBbTRctpt2X7J+buwL0EkfVXuWLCW0YSp 4JReJCL0naweFTfhjowLfDvZiWHYpa5j3BNR5aYcrx9Qc0tv4jXr0achmhjiisB/wvuauCSsxRX9 2PODwJ/EH4eFu8KLH8ALo14bhqgncu/73Hoj/HE4D8JOHPznQPSkSqmEqqMEKV3Dbw/8PtGG8Amx nq9HQR+jrAvLgucUj8gS0vMHz/wCt3C1zDf/AwAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACk GwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ru hx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7 /x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJg fSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0 NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uY WrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2 cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0r rdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlK xtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9a Qs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXw TYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHl owp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH 8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyz ewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaW AH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANO Frr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/ rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo 3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApN e93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1c yYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3G CxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7 mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+ p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUr pXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4K UiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7 IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW 7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278Q sWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H 9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4yt JTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCd SmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQUAAYACAAAACEAA4AeWHwDAADGBwAAEQAAAHdvcmQv c2V0dGluZ3MueG1snFVNb9w2EL0XyH8QdO5a0nrtpoLXQezE6TZ2GkQ2cqZISiJMcgSSWnnz6zMk JSuu08Doaal5M2++Z8/ePCiZ7LmxAvQ2LY7yNOGaAhO63aZ3t1er12liHdGMSNB8mx64Td+cv/rt bCwtdw7VbIIU2paKbtPOub7MMks7rog9gp5rBBswijj8NG2miLkf+hUF1RMnaiGFO2TrPD9NJxrY poPR5USxUoIasNA4b1JC0wjKp5/ZwrzEb7R8B3RQXLvgMTNcYgygbSd6O7Op/8uGKXYzyf5XSeyV nPXGIv+V5pTuCIY9WrwkPG/QG6DcWmyQkjFdRYR+pCk2z4geS32Epc6i78xToXmRh9cSuZXP7H/S 7djFa1EbYmKbcQB8FIqWu1aDIbXEoRqLTXqOE/UNQCVj2XNDsUk4jnmeZh7AZKCpHHEc4dYQhWO0 TankREcFxhsySHdL6spBj0p7ggH+sZ7sNXweNHVDaPdHbjSWJRDTjhhCHTdVTygKL0E7A3ImYPAJ 3CXOqsFSRk9xcn1QAaw06W/hgxFspy+5lIE1IF8NIvzBfRWuC94X6M7y98S6t1YQfWE4uf8ySG4D 3hoY3w4OGuFigGFRqrhqGJYmCgsWg5jW5wYYTxEajHjWk//sqTcINcLSo6NsLJfE8Bgw6zP0jy8A btbN89fF8fr0IlbCoy9B/tzkFyfHk5eJW5V+XT6b87P4usK6JypGdElUbQRJbvxCYWyqrM39hdAz XnM8KPxHpBrqGVytImAVkfIKezsDYRJUyYTt3/Em0MobYtqFd9IwP5XigP39yOWnk5sPBoY+ehux 1zvNUDy7KzabiU9ody3ULLdDXc1WGpfiB2jQ7J+98YTZUp6xdHhLua/PNdHtXG+uV3eVV8W+SVP5 e8tvSN/jCKNK3RbbVIq2c4Xvs8Mvhnc3fNTtesLWAcMvj4UPQn1mqD09vEJ8otb0WGTHs+x4keFV iXqbRXYyy04W2eksw7s/lt0BV14KfY/zOz+9vAEpYeTsr1m4TZ+JYhHCxu00lQPjOA0MqN1pfzDi VtmO9Bzb7m8ETjaUQTAdDZvsS9zTbcqZcPhv1wumyIO/PutTzz5pS3KAwT3R9ZhX7p9IE0YcQfPQ ySfGYc/+FQveEU4FTmt1UPVyeY5iXlJYV/Eej5QDgxUJK/t7YF7+gM+/AwAA//8DAFBLAwQUAAYA CAAAACEAhO+pOC0PAAB9fAAADwAAAHdvcmQvc3R5bGVzLnhtbOxdW3PbNhZ+35n9Dxo97T6kti6W bE/dTqLEm8wkbVo722eKgiw2FKklqTjOr+/BAQhSACEeiJDq7q4fbAsE8eFc8J1DXKjvf/y6jntf WJZHaXLTH3x33u+xJEwXUfJw0/90f/vist/LiyBZBHGasJv+E8v7P/7w9799/3idF08xy3vQQJJf r8Ob/qooNtdnZ3m4Yusg/y7dsAQuLtNsHRTwMXs4WwfZ5+3mRZiuN0ERzaM4Kp7Ohufnk75sJqO0 ki6XUchep+F2zZIC7z/LWAwtpkm+ijZ52dojpbXHNFtssjRkeQ5Cr2PR3jqIEtXMYGw0tI7CLM3T ZfEdCHMmenTGm4LbB+f43zru99bh9buHJM2CeQzKexyM+z+A5hZp+Jotg21c5Pxj9jGTH+Un/HOb JkXee7wO8jCKbvr30RqU/RN77P2argPo2+M1C/LiZR4FjRdXL5O8+bYwN28445BxkDxAs1+C+KbP khef7nZBVNE8WkDLQfbi7mUfbjxDCcq/NUk2Si5RSxMbDAbmuxNeBEphy/dp+Jkt7gq4cNMHT8TC T+8+ZlGagafc9K+uZOEdW0dvo8WCcactKyaraMF+W7HkU84WVfkvt+iBssUw3SbFTX84maIp4nzx 5mvINtx3AC8J1gD9E78BrAc+XsPBDm2jqjeiQEPFwv+UkAOuINBsE8qKBXyY9bD/e4FQ6m1noGGr RJ6ARqcCGp8K6OJUQMCELV7nyUZTDlT3ZmzXyXEhNHRtQghTG1P0XhRpKIZOXYjR1Z4Bx+/AMeB0 Bzqz0x3olU53oHs53YF+4nSHYfBWXRn2bb3DMOfeO8IAaVf3ohFqg+SJ91ERs9YRM+hI1DKk9T4G WfCQBZtVj8dmvdv7qP5uOy9oXcVgcDjV3xVZmjy0amQohsHBEeXNerMK8ggSrRayGnZU/T1PnHr/ yqJFK9SFcD5DJnsA/hgHIVul8YJlvXv2VVjU4f6f0t7dJgghhrd2rqNZ30cPq6J3t8KEoRVsYlG6 XROi/fdRjjrYm4tMLKK0NU6y4cTil/bGP7BFtF2XqiHkUhPB5w5m1iDas6jJmJvIHMStUnADUEQQ 4cJdBGyf0H8RXNzb5zam9F+EogPbJ/RfBK4D229PXifOTPMannt7pOE1dR67szROs+U2LsdAKz1M nUewgqCJ4DyIVfskkpg6j+Ad+uy9DEN47qT4qbMtKh51QHE2h0DBwUaXxdkoGu0NHCRyNpCGNXTA 6sa1DkDOpPsr+xLxaTXXYIAsrXLN1uE8smgAQhAph/5lmxbtOfTQwnlUlHcJTPbkrEdDG1lGHhVN +pOIdw427hb4HIC6RUAHoG6h0AHI4h/2nEfFRDpI9+DogOVMyyqKoduRmXnqzMwKyC0EeIqbhPzL MnrtvmDGTQKKs4HMuElAcbaOFstU3CRgeYubBCxL1LDbqM6pLkI5x806kMoECBL5IW8CkB/yJgD5 IW8CUHfybgfxR94ELGduUJxaJ28CEFZxedRXQHXyJgA5c4NgOzlnVMY9bGX//I4H8iagOBvIJG8C irN1bORNwMIqLp6gYSmqI2D5IW8CkB/yJgD5IW8CkB/yJgD5IW8CUHfybgfxR94ELGduUJxaJ28C kDM9KKA6eROAsIoLNzSSN476o5M3AcXZQCZ5E1CcraMRqkpSCVjOBtKwFHkTsLCKizNILHRuF6H8 kDdBIj/kTQDyQ94EID/kTQDqTt7tIP7Im4DlzA2KU+vkTQBypgcFVCdvApAzNzSSNw7Go5M3AcXZ QCZ5E1CcraMRquI5ApazgTQsRd4ELPSXzuRNAMIqhwK5SOSHvAkS+SFvApAf8iYAdSfvdhB/5E3A cuYGxal18iYAOdODAqqTNwHImRsayRvHyNHJm4DibCCTvAkoztbRCFWRNwHL2UAalqI6ApYf8iYA oWN2Jm8CEFY5AAhHkYuZ/JA3QSI/5E0A6k7e7SD+yJuA5cwNilPr5E0AcqYHBVQnbwKQMzfwfbaw X5S8PXVgcQLqPoNyVwMZcGgxEhVQCvgrW7IMzmmx9t0hHQFLCR0QLe5BFfFVmn7u0TZ2jywOQoaK 5nGU4pbuJ9ylUzuIMJruOUlw//Os91Yc3zHuQ5fa3XkDJ6Tqh534iSA8PAf9LJ42cOBoU+4s563B QSh+NEweYMKK7+A4kzyUxG/mp5SgIh7UksW4bitR8X84fIU4YoMy1J4zOIkHWINzXOERH19uizQX VSResCwYnMKTtfCTVgmaB4Fk+3B2jcNk5Wm18kzaPZwBBLB1BIff3shzakKh+bey68NxWTLjB91Q HFFWO1KG8rdoTOlI2mSAR7vqWqrOWqFy5gGcEPuZH/gydBhHyeeyvGxutgoy0dXqxEVZRx44aVD9 72FZJ+Pbt0UD6bYABPb+S1xePOcX7AqVx//esvgLK6Iw4B4iz/ZVZUIo8XuW49+QbwstMa6uzuFH 9OAzy5Tgo4koq2wyvixLKpuIso42GVptMhSIbjYZHmYTU/14bMO/+iuNVjquNCrKOmp0ZNXo6BCN jnxpFO3pX6M7Dj3Cn9JVSzcfSs7Ov1WqFmUdVS2O7TYRiqQwN+cd+1I1Gtq3qjvq6sLqlheHuOWF L12hpXzrCgJ5Fc4kwe54X8nuGCcB/ZBwNrFqVNK3m/dNfGkU7XlMjQ6kx9Q1KsrafTSEmB2EkMvs SankwT611xqP9ekJluX0HwZZMx2QpwCruSJRb+csChTZPaHgJ9729BlPxO3NBXtYRYw1s4NwhB67 1NZDSE3nsUju4J93yQJIFt6ngLmjSFoXXwPRFFyfsTj+EGRcd0W6sVeN2bIQVwfn+KSvNTVPiyJd 2+/HTMreAKi13hnxkQth13eyXc9ZJs/wWVNv/oRsjEI4/4flFlegatretx0frpJceGTIeJpqdOit uoJd0mih0ds79l2++gGeLgRiW/K5Bdthys3ftQF+jnflK+5cWBzGDFJt+ITRHl4yAc8n/OMyiuGl FPgJbgGNtfBps+Zu0zhOH9mi0pM+2M0aQq7d54U/S5OTCU97hNL+XE2+vf/wfhbBuRFdgfxCD6+c XnGlE8k4PK+SQFkSaTUircahfsWFBp+Ikoi/RqRZJ7Xrp9eMQJSD81haUJNguk+oC10Fh9Pk2ET9 YVtOQER4AQwKfx3NGG5ziDl3/D00+pzLzgSALpa82Bv0qoSKTLlN0wxyYKtJqNJbZcTWp1pwZqCc Zwl+T7O3/JU/nC31SRh+UU3CwHWcP2i8M8wLOXHD73kFL/oRnZoL0zXR+2hycXuFs4x4K871AlXj Icuq+A7OroN6X92K9mpZc8OEwxDLvJtRzBnYzDj0ZEY5ndGQeUnR1SuFUKfP1Krj28vBq9fcmZqs ij2v2VBNI1WEOsQy7zYUsxQ2G4482bCMsbahqCXP/xU27DAZu5NttdOpmP6w2XDsyYZSnr/eOKyH MpkIl5HAbVSezqJiksZm0QtPFpWzAX8Fi+5MVg7Ho1vxTpYmLi0pVkbIqRkhT2dHMTVks+PEkx1l tPgr2HHPWPwTrbqzXFjNC8BTyMeMr/LB+zYLtmh+DtmpIbK63Yfb+oLiTpaqNV8lvQ2GJE8ylcuU 1CmAGf6ITAqmyvD9mfC3JEg+v8STlk0KL7m8GkhPs1UYXI5ktmarMZyWC2K2GqMJvO4H9WirMb64 lM8tthoX46uWnk7Gg5aeTkcia4aEzaKOy+G4paegsJaewrLwtKWrg/Orq5a+DgZXMPu3V2mDIXS3 pcpoOm7r7nhygd2FPBTUgt4il7vBScoVcdt6OJbL9fDq/53VcMSHxi2r4XLxdpZuswheMgZvb+XO KZdvtVL+WtZ6EapnJ47wNVyxiusxrW4a1UYAgEq9OnF0DgQaqjA0mUca822uvSRP4yDnOtYfgXf2 IdRtUN0iDCA/g/Ydlax4WL6DT1eiLEazkqcJTJXAq/uwiYY5kLlo+5A5ENV5PpV1D9PIj/DCXVg7 0YXA6b3a9a7SUOfI1Tyz2mjSPLTIZt8ZkPrQ4/4R8bcEL8RWHKFxbSyOgPnFhdqDcIdUrTmoi2j8 G5sbphBXev+Aa/8U/dC8qh7ITT+ia15yW4RLQDzA3vTHENFASbgaIz6BI5Q0CH/Rnbjv4D9QUyzz 7Ii45zkxTDdPYs+M7n/VlSbPq0vs2mvlYTVryuhSX34UU5Dt1EAVFd5Ja1iWlx0g3lS8bLPZKEq8 uWiZSBJUMT6zJ0MMXnaAGEf2LXiTqO5UUPT8+pkXJvvysufXU1i4M1TKy55fTzO2MXrKy55fT9Ni ZfSUlz2/nrLM9FNedrqeUmcfs6VJtbysqae2FV57bKP2YgU7HPi7hnUSKstP25soWaZGV7DwtP0A O5ibdrHQpR8qyOlZ4oc0CULcSCCfvWoFZqI3F5hNi10T/OEu054COHqEKb90CbmlSMvubB7qSweQ tOGODJkDmYvpO+nwLf741Qt3Q1MpovQgr/gSJFG+0gR7ZHPxRSJa+Y549f3TlPwQ5hYWWdmg3OoC H/NvN31x7AW23MNqKJ6UQKCbvtzRCrWWGX4JSbmTjDoz9gZ/BJvlGxb+25S23Wcd8j3TNJDwNfuq l7x8z6jkupvNaN5HlTBamALysibP8yKfxeH82QyyR1MkLCTKRN6nNZtxOhCqIj82KuLaUYTLnBfV tMBrpiKwkKiIzjLxKOLXXSGNNWXCwtPIxBlSTCn4c1hIeE2ZsJAoE9lhb2+5yz5bh4V82lQEFh5D EYJJH6/JXg4Wt0z4UFMgyPSGRhqKhU0CHjv1EZgnTv9M+WX6J+d7/yfTP1MpPP07UCP/T/9kiLWP V2oEhUzPNA0WNo1XL+nR3D4qj5P+mQJGi2bP8yLfTtZTPW/4i6aQ6ZkiYSHRZuRo+vzTP1MRkP6d yrjwdafHSP9MmSD9O5VMR0r/TJkg/SPLRHbY55/+mYqA9O84ivCY/u2EE7XErL4XRZ8CVReQkODL XOHrXfFf8uolfI2xOkp0fn45GA0nr0RWr28Z2LtQjKC1eR7vq7qvAjiIlCb4pXO6FuQ18Y10bdRc 36BVa3S274UF5L1Zdm3KxVXLVhq1ZQZ6D/FLVtYtIBfw74MVfJ9xbVtMVYBfVCwuaxYpN3bVV2ZF WXu8pD6T6OrcZ6eu+2FqWMJdj+Dxhr73DgGYh5RT5b7tUWaf+Q9/AAAA//8DAFBLAwQUAAYACAAA ACEAoyDX+D8HAACMiwAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxd2W6jSBR9H2n+wUKax8SsBlvt tLwxymjUGqkzmmeMSYyaTYDtzjz2z8wn9Gf1L8yFAoIDpk1VuWO17kscUwt1D7i45268e//Z9wZ7 J07cMJgK0q0oDJzADjdu8DQV/n4wbwxhkKRWsLG8MHCmwrOTCO/vfv3l3WES7Py1E0PHAcwRJJND ZE+FbZpGk+EwsbeObyW3vmvHYRI+prd26A/Dx0fXdoaHMN4MZVES8/+iOLSdJIF5FlawtxKhmM5v zhZGTgDnegxj30qT2zB+GvpW/GkX3cDskZW6a9dz02eYWxyV04RTYRcHk2JBN9WCsiETsqDioxwR N6RoOS8ZuQztne8EaX7GYex4sIYwSLZu9CIG7Wwg4rZc0r5LiL3vlf0OkaQ2zleJfM41WMbWAS7F y4SN6VrA2JBBvkdwyK7vy1V9PaMkdglTXJFsimoN5yzh+JzlSnzLDapp6KCpgws/CZb7+/c43EXV ciKXbbb74FM1V/bL7LEycZT/8uqiJb0maPx0P26tyBEGvj25fwrC2Fp7sKKDpA6yO1K4g93CWidp bNnph50/OPp2v5kKYt4lSNwNtO0tD47M5ZmozzRhmA32d17q/unsHe/hOXLKPvlRLztKeqV+5JVt 5sxYzRfzGWnx9lmDCx/luWBPi9Oys0R6wYZm+tXB9c7znLQa/+B8rpq+fflaHf/DLmfxnMeie/RX nK06BZmLz7IPnEKA/6MQ8NZlMZtl+NLRDTL5s3lIK3zZWsFTvhcro7J3MXtMThKbYZAm0NNKbBdu qY/P/jqEDQGGzgDQowNuABNvnEcL4CQCJP9CxxzwajH5vLAoACtbfB06KZs2hf0Otrk9XGApv2xM UIYcgJRUtcSmhLyOZN6c4dEXykW4i10nHnxwDjU8Xx9lBVXmD+q3L/9xgFWWqluuDda8mQbWf+B+ zvQLeERWN+nxMVZIlauF1DC67lQ5a75OSNVrhRT2xS5I8+brhFS7VkhVpXoYtP3w8+brhBS0ft4P KD57qSZ2PqLy5uuEVL9aSPXOx5OWNV8npECpr/MuHamdj6e8+VogBQ21RikyTbX2FRZZ+5YxDKKq HjGM1UxRVLNgCP0ZhmpKK0NU1ErTgpMiw0CGkRnOziVrr7kEYWyvj7Kqw8gwgAYjw8isCsgwpkJf Ow0yjCPTFw/TAjIM7pAiw+APKTKMus2bxw//J2YYctOHYc5ESTMUwhD6M4wlOEFW8niFDKPm1GBV htGHAcowMgziZEMfRn91OKcQp/2WyDD6Q4oMg7vuhgyDO6TIMPhDigwDGUYZFvVdH4bSYBiSqC11 zZzTMozFeDmajbUFMgxkGFkQFY1z7zWXQB9GPfgMGUZ/dRgZBndFAxkGd0iRYXCHFBkGf0iRYSDD OJthkFSNepSUZCiitFSLDAkKH8ZSl825ij6MemIG+jB6pbQgw+iKcEeGgQyDKQWLT4Q7Mgzuuhsy DO6QIsPgDykyDGQYZzMMreHDUKXRUhVFndaHIeriSjT1Efow0IeBPow8l79vhHtOITpCerJEcBrX 0HHOBXEMHR9jZcKY6c09tQUzvblDipne3CHFTG/ukGKmN3dIMdObA6Q9M71HTYahjTRRlwofRH8f hi4vZdUwGHwYG8d2fasoUwUVlerFpH6Tbivq8kbFpPhWe+oUVuYhLGPBp3ZxabOkO8VVeIjLqJ63 i0urOXeKq3IRl61IUru4tFptp7gaD3EZDeft4tJqnJ3ijniIy2jUbheXVhvsFFfnIS6jwbldXFpN rVNcg4u4bMbgdnFptahOccc8xGVMZy3Fhc9auZrvxoHrTQ1nLmuSqS5pbajSAoptjhcYB45RGlgt k9RDRRsqU4FcHsUCMA6cu7OWUdk8TE5UHT626l/C0k+r0XaWceZxlzIqtG8IKa3WfHFIGZXmN4SU VjO/PKRsivkbQkqr/V8cUkbl/4dC2pNhGA2GMZJMUTfmBi3DEDVNlJeKXJk6sVrmZMvq/cZaNuBe eB0dzgoqrR344vsNoxn4h+43x++NoLU1Xx5SNlPzG0JKa8++OKTIMLiTNmQY3CFFhsEfUmQYGAd+ dhz4uMEwdE3WFWNMXS1THi8XEEteMJT6a6vI28UYc6S+VszljYI0TiobtbBvYnirHWBVhpFhIMMA po7VMgEEutB6ZBi8n4rIMLjrbsgwuEOKDIM/pMgweO+lP7EPQ2q+VFg3oRrNak4dCL5aKeJoXAaS I8XIkwKRYmAxmyxk8byXXqMTg/tjEcOkuEOKFIM7pEgxuEOKFIM/pEgxkGLUnRjBzgfTH/x9eYlw LVXjflPaBfPyMxBlBT0zZehoGHkzWOuwvOrNiWGk3H/rMOA2pFxH2+lIEc/2cR3DSGWe1mFaxzCS bts6LA/2OiEcyWFpHTbuOBsJTGsd1gUJ8Ta1Dsv9RScWWVDI1nH5e59PjSNvm24dl/u3ynHkc+3E QCHu/gcAAP//AwBQSwMEFAAGAAgAAAAhAMMNl8/hAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVBy b3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDBasMwDIbv g76D0d110nVxU+IUUjfQ69hgV9dxEkNsB9sZG2PvPoeduuNO4pOQvh9Vpw8zoXflg3aWQb7NACkr XaftwOD1pcUHQCEK24nJWcXAOjjVm4eqC8dORBGi8+oalUGpoVO9cgZfTdNc6C5vMW3bPd4XB4rL Mue4uNDm/MQz/kjLb0BJbdOZwGCMcT4SEuSojAhbNyubhr3zRsSEfiCu77VU3MnFKBvJLssKIpek N29mgnrN87v9rPpwj2u0xev/Wm76Nmk3eDGPn0DqivxRrXz3ivoHAAD//wMAUEsDBBQABgAIAAAA IQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BigIxDAbgu+A7lNydzngQkel4WRa8ibjgtXQy M8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9HAz/n79UWFIuNvZ0pooEnMuy75aI9 4WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj6nVdb3T+bUD3YapDbyAf+gbU+ZlK 8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrcC7pr9cd/3QsAAP//AwBQSwMEFAAG AAgAAAAhAF+hN14sAgAAQwQAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAnFRNb9swDL0P2H8QfNoOjT/qZl2hqBjSDkXRNcHstGdVph1ttqRJ StDs14+ym9RZd1pO5CNBPT4+h14+dy3ZgnVSq1mUTpKIgBK6kqqZRavy68l5RJznquKtVjCLduCi S/b+HV1abcB6CY7gCOVm0dp7cxHHTqyh426CZYWVWtuOe0xtE+u6lgKutNh0oHycJck0hmcPqoLq xBwGRsPEi63/36GVFoGfeyh3BgkzWkJnWu6B3Qc67aTSvqPxAaWl9rwtZQcsRfiQ0CVvwLHsE42H iD5qWzn2OUtyGg8xna+55cKjhuwsy6fYO0LoF2NaKbhHfdk3Kax2uvZk0StBwgQaj1soqlOA2Fjp dyyh8Tild1Ihm/wUnxhC5Gd5Y7lZO5Zmp4HlIaeF4C3MUQZW89YBjV8BegM8nHjJJbKmW3+xBeG1 JU7+xiNnEXniDoJ4s2jLreTKo4ihbUj6uDXOW1ZK3+JsrA15H47bxrHMg77Yi8FxYwAHDlg4Zte/ 4BY17ub/QTYdk+05DFQHOisHZI67OIIeJt/h10ZaCO5zBJ1JbovFPVk8/cDtSSEbhZr0jddK2J0J RyMfbhfF9cc3G/Z6Ide/2M11Z7jajU4919Zo2xsAnfFSDqf86Vam1FfBlS8HOgZHxnqUfl0YLvD6 0/QsPx9bbFSjBVoRKvTMfuIrQG/wmrYNz6I9VQPVvudtIZj2YfhPYGk+SfDXu3SPoc8OHyv7AwAA //8DAFBLAwQUAAYACAAAACEAqchcqowAAADaAAAAEwAoAGN1c3RvbVhtbC9pdGVtMS54bWwgoiQA KKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAskmyCs4vLUpOLVYITs1JTS5JTQku qcxJtVWKcQxw1IsI9lFSAAv4JeYCBYFiSgoVuTl5xVZJtkoZJSUFVvr6xckZqbmJxXr5Bal5QLm0 /KLcxBIgtyhdPz8tLTM51SU/uTQ3Na9E38jAwEw/KTMpJzM/vSixIKMSahhVjLKz0Yd7xo6XCwAA AP//AwBQSwMEFAAGAAgAAAAhALIoGlsKAwAAGQ4AABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzUll9v 2jAUxd8n7TtEeW/jhEBbVFrRrmh72B42tj0bY8BabEe2IePb7zpOgBazxvs/qgp67VycX885N9e3 X3kRbajSTIpRnJ6jOKKCyDkTy1H8cTo5u4wjbbCY40IKOoq3VMe3Ny9fXFfDhRRGR3C90ENORvHK mHKYJJqsKMf6XJZUwOJCKo4N/KmWCcfqy7o8I5KX2LAZK5jZJhlCg7hpo7p0kYsFI/SVJGtOhamv TxQtoKMUesVK3XarunSrpJqXShKqNdwzL1w/jpnYtUnzo0acESW1XJhzuJnEnSixreDyFNWfeBFH nAzfLIVUeFYAuyrN45sGXFQNBeZQ/LDlM1nU9RILqWkKSxtcjGLUh58U2YYXaADvfXQRJ7YBWWGl qdltzFx5gTkrtm1VSY6FWyiZIau2vsGK2fO4Jc2WsLDWMwRf2LxiV0lBD48r2dGe3uMKqftcHlwF Feiz6wzHT5xyjkBMGac6eker6H19crvhKZEMKAxQD0jk8JvBp9xPBP0aIg9w8Gw8meyJ3EPl4jJP m8qeyFVT8RKp7z91fboTuZdrxaiyTLz6yEAXPXQFHKw2MmASQoPLOVU+gSzYVzo/VsdJFr0/weIz mNOGkvaS6LcC27/7deF1Cl4b6bb/F0Z5TYsNNYxgL4oM3YFF8loUVhggCz8Kr0V0xbR2+4U0U7Wm 021J69AJY9OK4tD8Llb2loFZU0fPacsgVBstwDKYzyDeTpCxoeHCw4ZIGJnwOLWGQdlheOS2ku8q ISTSqzqEAkjAMJQF9vvFicQlRx6MIjg57Bg5AjG594DokKKhIN5KgYn0KsL+O568ArxyiOG7ZjkR qM03/yWnTPEKxqwXSxshzio2Sn4wQjpGxgPoI3vYqQEiw07ZAerfPZ0s2XP6SFHwlP1E1RyLf4PE 2DplcEjCRgZM9yMS6fPhGRwZY0hO/5Noqwg3UH5iqHRVhL1r33NXa5Z9dD6nCBghjmdAdOKCwRQ5 4Y1J/axVMwhOzoPx2pWENzvHvys7m4dzffMNAAD//wMAUEsDBBQABgAIAAAAIQCv1JWjRAIAAEsO AAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsV8lu2zAQvRfoPwi8x1osKbIQOYAbpChQFF3SD9BC 20RIjkDSVp2v72iz5cQGYqBND9XFpmY4o+F7It/w5vaX4NaWKs1AJsSdOMSiMoeCyVVCfj7cX0XE 0iaVRcpB0oTsqCa38/fvbqq4otkPagzO1BZmkToWeULWxpSxbet8TUWqJ1BSic4lKJEafFQrW6Tq cVNe5SDK1LCMcWZ2tuc4IenSqNdkgeWS5fQO8o2g0jTxtqIcM4LUa1bqPlv1mmwVqKJUkFOtcT2C t/lEyuQ+jeu/SCRYrkDD0kxwMXZbkV2nwnDXaUaCE0vk8aeVBJVmHBGsXJ/MEb6CbXX3b1UxKxIS hjPPjZzrxp1BsbtjW3RtU47MELuejNh9pkvTW/3I2du/s9X6pOMBylPzF2AMiBceLGtRqPpd5hAn kXuCU/VTQvALwUGZ5riWZpwDB6Qs3Rhoi+GDCi+LzI5quixWDdd/SajdcNEtumblw5rx4piaIPLC CH+mDTfPWLj2zrBwMA84OBiPGejs/zX+LRXH0OOOcB08HfxgxP7cjvsT3/5p7P1rJwq9mTdi/+bY O/7UcUN/5ozYvz32QRBE0TTotJhD/vhtA4b2cnlajs8KwdAxkAI81/byfSwGe88oB9tnchD42Fz5 s2nbRWUjNdgdXtLuVPFfU4tp5Dkzz/NbtRipqRv3f0dNK+h9N9vLe2etN1V/0esPtY1kePOj7ZEE pWGCPdF7UAsFlaaquYCknEP19ctHfMBMgyvg/DcAAAD//wMAUEsDBBQABgAIAAAAIQBntG1JtQ8A AG5/AAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzsXUtz2zgSvm/V/geVTruHxNbDku0a ZypR4kmqkplM7OycKYqKOKZILUlZ8fz6bTRAkAQIsSFCGs/u+mBbIIgP/cDXTTyoH378vo56j0Ga hUl80x+8PO/3gthPFmH87ab/9f72xWW/l+VevPCiJA5u+k9B1v/x1d//9sPuOsufoiDrQQNxdr3b +Df9VZ5vrs/OMn8VrL3s5Tr00yRLlvlLP1mfJctl6AdnuyRdnA3PB+f43yZN/CDLAG3mxY9e1hfN rfXWkk0QA9YySddenr1M0m9nay992G5eQOsbLw/nYRTmT9D2+aRoJrnpb9P4WnTohewQu+Wad0j8 Ke5INSkacPmdbxN/uw7iHBHP0iCCPiRxtgo3pRiHtgYiroouPe4T4nEdFfV2m8FYw5MiU2zwNvV2 YIqyQa25BmUs+E3riOuB2be0qtri4HyfMMIirAnZB0oX6phFT9ZeGMtmDlNNVbkwHrr4909pst3I 7mzCbq19iB9kW2xYWvTsfIIjrypaZtWANnTvVt4m6PfW/vWHb3GSevMIerQbjHvMI/uvgCoWif82 WHrbKM/Yx/RzKj6KT/jnNonzrLe79jI/BPXch2tgl5+DXe9LsvbAkrvrwMvy11noNV5cvY6z5tt8 kE9t7YxBRl78DZp99KKbfhC/+HpXB5FF83ABLXvpi7vXfbjxDCUo/lYk2Ui5eC1FbCAIoIs7Tpug lGD5MfEfgsVdDhdu+kC9WPj1w+c0TFLgspv+1ZUovAvW4ftwsQgYSxcV41W4CH5bBfHXLFiU5b/e IkeKFv1kG+c3/eFkiqaIssW7736wYVwFeLG3Buif2Q1AJEDqFRzs0DYse8MLFFQs/HcBOWAKAs02 oawCj8WVHvZ/LxBKve0MNGyVyBHQ6FRA41MBXZwKCGJ1i9c5stGUAVW9Gdu1clzIhbo2wYWpjCl6 L/LE50OnKsToas+AY3fgGLC6A53Z6g70Sqs70L2s7kA/sbpDM3irrjT7tt6hmXPvHb6HtKt60Qi1 QfLE+zCPINS2jJhBR6IWIa332Uu9b6m3WfVYbFa7vY/q77bznNZVDAaHU/1dniYsY23RyJAPg4Mj yrv1ZuVlIST2bUAdVX/PsqfeT2kIGXAL1AV3Pk0mcwD+HHl+sEqiRZD27oPv3KIW9/+c9O42no+P CC2d62jWj+G3Vd6DxJIlDK2amBiUbtYEb/9jmKEO9uYiE4MobY2TbDgx+KW58U/BItyuC9UQcqkJ 53MLMysQ7VnUZMxMpA/iVimYASgi8HBhLwK2T+g/Dy727TMbU/rPQ9GB7RP6zwPXge23J68Ta6Z5 CzMzPdLwmlqP3VkSJelyGxVjoJUeptYjWELQRLAexLJ9EklMrUdwjT57r30fnjspfmpti5JHLVCs zcFRcLDRZbE2ikJ7AwuJrA2kYA0tsLpxrQWQNel+CR5DNo9sGwyQpWWu2TqcRwYNQAgi5dC/bpO8 PYceGjiPivIhhsmeLOjR0EaGkUdFE/7E452FjbsFPgugbhHQAqhbKLQAMviHOeeRMZEO0j04WmBZ 07KMYuh2ZGaeWjOzBLILAY7iJiH/Moxesy/ocZOAYm0gPW4SUKyto8QyGTcJWM7iJgHLEDXMNqpy qo1Q1nGzCiQzAYJEbsibAOSGvAlAbsibANSdvNtB3JE3AcuaGySnVsmbAIRVbB71JVCVvAlA1tzA 2U7MGRVxD1vZP7/jgLwJKNYG0smbgGJtHRN5E7Cwio0nKFiS6ghYbsibAOSGvAlAbsibAOSGvAlA bsibANSdvNtB3JE3AcuaGySnVsmbAGRNDxKoSt4EIKxiww2N5I2j/ujkTUCxNpBO3gQUa+sohCqT VAKWtYEULEneBCysYuMMAgud20YoN+RNkMgNeROA3JA3AcgNeROAupN3O4g78iZgWXOD5NQqeROA rOlBAlXJmwBkzQ2N5I2D8ejkTUCxNpBO3gQUa+sohCp5joBlbSAFS5I3AQv9pTN5E4CwyqFANhK5 IW+CRG7ImwDkhrwJQN3Jux3EHXkTsKy5QXJqlbwJQNb0IIGq5E0AsuaGRvLGMXJ08iagWBtIJ28C irV1FEKV5E3AsjaQgiWpjoDlhrwJQOiYncmbAIRVDgDCUWRjJjfkTZDIDXkTgLqTdzuIO/ImYFlz g+TUKnkTgKzpQQJVyZsAZM0NbJ8t7Bclb08dGJyAus+g2NVABhwajEQFFAJ+CZZBCgcTg/bdIR0B CwktEA3uQRXxTZI89Ggbu0cGByFDhfMoTHBL9xPu0qkcRBhN95wkuP9l1nvPj+9o96FL1XfewAmp 6mEndiIIT4tCP/OnDRw42hQ7y1lrcBCKHQ0TB5iw4gc4ziQOJbGb2SklqIgHtUQxrtsKVPwfDl8h Dt+gDLXnAZwVBazBOa7w8I+vt3mS8SoCz1vmAZz6FLXwk1IJmgeBRPtwdo3BpMVpteJM2j2ceQWw dQgn4N6Jc2pcodkfRdeH46Jkxg66oTi8rHKkDOVv0ZjUkbDJAI92VbVUnrVC5cw9OCH2Czvwpekw CuOHorxobrbyUt7V8sRFUUccOGlQ/e9+USdl27d5A8k2B4Tg42NUXDxnF8wKFcf/3gfRY5CHvsc8 RJztK8u4UPz3LMO/PtsWWmBcXZ3DD+/BQ5BKwUcTXlbaZHxZlJQ24WUdbTI02mTIEe1sMjzMJrr6 8diGe/WXGi11XGqUl3XU6Mio0dEhGh250ija071Gaw49wp/CVQs3HwrOzv4oVc3LOqqaH9ttIhRB YXbOO3alajS0a1V31NWF0S0vDnHLC1e6Qku51hUE8jKcCYKteV/B7hgnAf2QcDYxalTQt533TVxp FO15TI0OhMdUNcrL2n3Uh5jt+ZDL7EmpxME+udcaj/WpCZbh9B8GWT0dEKcAy7kiXq92FgWKzJ6Q sxNve/qMJ+L25oI9rMLHmt5BOEKPXWrrIaSm84gnd/DPh3gBJLsTZ+h50rr47vGm4PosiKJPXsp0 lycbc9UoWOb86uAcn/SVpuZJnidr8/2YSZkbALVWO8M/MiHM+o6363mQimN1xtSbPSFroxDO/2G5 wRWomjb3rebDZZILjwwpS1O1Dr2XV7BLCi00envHvotXP8DTBUdsSz63YDtMudk7bsDP8a5sxZwL i/0ogFQbPmG0h5dMwPMJ+7gMI3gpBX6CW0BjLXzarLnbJIqSXbAo9aQOdr0Gl6v+vPBnaXIyYWkP V9qfq8n3958+zkI4N6IqkF3o4ZXTK65wIhGH52USKEpCpUao1DjUr5jQ4BNhHLLXiDTrpHL99Jrh iGJwHksLchJM9Ql5oavgQ2HH6sO2mIAIsW0wKPy1NKO/zSDm3LH30KhzLrUJAFUscbE36JUJFZly m6YZxMCWk1CFt4qIrU614MxAMc/i/Z6k79krfxhbqpMw7KKchIHrOH/QeKef5WLiht3zBl70wzs1 r3lQ/VFscnF7hbOMeOuMzTsAVeMhy7L4Ds6ug3rf3PL2Kllzw4TDEMucm5HPGZjMOHRkRjGd0ZB5 CdHlK4VQp8/UquPby8Gbt8yZmqyKPa/YUE4jlYQ6xDLnNuSzFCYbjhzZsIixpqGoJM//FTbsMBlb y7ba6ZRPf5hsOHZkQyHPX28cVkOZSISLSGA3Kk9nUT5JY7LohSOLitmAv4JFaxFyOB7d8neyNHFp QbEiQk71CHk6O/KpIZMdJ47sKKLFX8GOe8bin2jV2nJhOS8ATyGfU7bKB69LzYNF83NIrQbP6uoP t9UFxVqWqjRfJr0NhiRPMhXLlNQpgBn+8EwKpsrw/ZnwtyBINr/EkpZNAi+5vBoITzNVGFyORLZm qjGcFgtiphqjCbzuB/VoqjG+uBTPLaYaF+Orlp5OxoOWnk5HPGuGhM2gjsvhuKWnoLCWnsKy8LSl q4Pzq6uWvg4GVzD7t1dpgyF0t6XKaDpu6+54coHdhTwU1ILeIpa7wUmKFXHTejiWi/Xw8v/aajji Q+OG1XCxeDtLtmkILxmDt7cy5xTLt0opey1rtQjVU4sjbA2Xr+I6TKubRrUWAKBSr0ocnQOBgsoN TeaRxnybaS/Okoi9NVt/BK7tQ6jaoLyFG0B8Bu1bKlnysHgHn6pEUYxmJU8T6CqBV/dhEw1zIHPe 9iFzILLzbCrrHqaRd/DCXVg7UYXA6b3K9a7SUOfI5Tyz3GjSPLTUmQ+j2WsDUh16zD9C9pbgBd+K wzWujMURMD+/UHkQ7pCqNQd1Ho1/C+aaKfiV3j/g2j95PxSvqgZy3Y/omhfcFuISEAuwN/0xRDRQ Eq7G8E/gCAUNwl90J+Y7+A/U5Ms8NRH3PCf6yeaJ75lR/a+80uR5VYltey09rGJNEV2qy498CrKd GqiiwjtpNcuysgPEm0LfjEaR4s15y0SSoIrxEDxpYrCyA8Q4sm/Bm0RVp4Ki59fPLNfZl5U9v57C wp2mUlb2/HqaBhutp6zs+fU0ge+7UN2UlT2/ngap7qes7HQ9pc4+pkudallZU09NK7zm2EbtxQp2 OLB3DavWLcpP25swXiZaV7DwtP0AO+ibdrHQph8yyKlZ4qck9nzcSCCevSoFeqI355hiubSW9k3w h7lMewpg6RG6/MIlxJYiJbszeagrHUAmgTsyRA6kL6bX9HKLP271wtxQVwovPcgrHr04zFaKYLtg zr9IRCmviVfdP03JD2FuYZEWDYqtLvAx++Omz4+9wJZ7WA3FkxIIdNMXO1qh1jLFLyEpdpJRZ8be 4Q9ns2wT+P/SpW33WYt8TzcNJHzNvuokL98zKpnuZjOa91ElDBe6gKysyfOcyGdwOHc2g+xRFwkL iTKR92nNZowOuKrIj42SuGqKsJnzopoWeE1XBBYSFdFZJhZF3LorpLG6TFh4GpkYQ/IpBXcOCwmv LhMWEmUiO+ztLXPZZ+uwkE/risDCYyiCM+numuzlYHHDhA81BYJMb6iloVjYJOCxUx+OeeL0T5df pH9ivvd/Mv3TlcLSvwM18v/0T4RY83ilRlDI9HTTYGHTeHWSHs3No/I46Z8uYLho9jwn8tWynvJ5 w100hUxPFwkLiTYjR9Pnn/7pioD071TGhS/kPUb6p8sE6d+pZDpS+qfLBOkfWSaywz7/9E9XBKR/ x1GEw/SvFk7kErP8XhR1ClReQEKCL3OFr3fFf8mrl/C93fIo0fn55WA0nLzhWb26ZWDvQjGCVuZ5 nK/qvvHgIFIS45fOqVoQ1/g30rVRc3WDVqXR2b4XFpD3Zpm1KRZXDVtp5JYZ6D3EL1FZtYBYwL/3 VvB9xmzhUkzNlgX4RcX8smKRYmNXdWWWl7XHS+oziarOfXbquh+mgsXd9Qger+l77xA4nj2K7DN7 9R8AAAD//wMAUEsDBBQABgAIAAAAIQAyBWcsjAEAAN4CAAARAAgBZG9jUHJvcHMvY29yZS54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMkktTwjAUhffO+B8yWemipAUf2Cll RoQFI+IIjI67mFwg0qYxCY/+e9MWKowuXCb33C/nnpuou0sTtAFtRCY7OGj4GIFkGRdy0cGz6cBr Y2QslZwmmYQOzsHgbnx+FjEVskzDs84UaCvAIEeSJmSqg5fWqpAQw5aQUtNwCumK80yn1LqjXhBF 2YougDR9/4akYCmnlpIC6KmaiPdIzmqkWuukBHBGIIEUpDUkaATkR2tBp+bPhrJypEyFzZWbaW/3 mM1ZVazVOyNq4Xa7bWxbpQ3nPyBvo8dJOaonZJEVAxxHnIVW2ATimQHUo8YF5FJEL/C1Froyjlwi aDgZP6HxxycwiyZiIV3wpbAvmc6VdWtBF8PxpH8ZkRpZwJkGajMdj8QK0NDtxpSCw3Wxn4QaO3Kr nAvg9/mJ8ne1aNCwEcVHiIOIHB/de2V21aPAkUsjrLI7VF5bvYfpAMdNP2h5/pXXbE/92/C6Hfr+ e2HspL9Ip7pI9/b+T7w7JR4Acen49EfG3wAAAP//AwBQSwECLQAUAAYACAAAACEASZ+D4qsBAACX BgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAe kRq38wAAAE4CAAALAAAAAAAAAAAAAAAAAOQDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBT 2g2w/AUAAKM1AAAcAAAAAAAAAAAAAAAAAAgHAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAAPp9Ct/6wAAF/YIABEAAAAAAAAAAAAAAAAARg4AAHdvcmQvZG9jdW1l bnQueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsAABUAAAAAAAAAAAAAAAAA9PkAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQADgB5YfAMAAMYHAAARAAAAAAAAAAAAAAAA AM8AAQB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCE76k4LQ8AAH18AAAPAAAAAAAA AAAAAAAAAHoEAQB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAoyDX+D8HAACMiwAAEgAA AAAAAAAAAAAAAADUEwEAd29yZC9udW1iZXJpbmcueG1sUEsBAi0AFAAGAAgAAAAhAMMNl8/hAAAA VQEAABgAAAAAAAAAAAAAAAAAQxsBAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAI AAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAAIIcAQBjdXN0b21YbWwvX3JlbHMvaXRlbTEu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAX6E3XiwCAABDBAAAEAAAAAAAAAAAAAAAAACIHgEAZG9j UHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQCpyFyqjAAAANoAAAATAAAAAAAAAAAAAAAAAOoh AQBjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAGAAgAAAAhALIoGlsKAwAAGQ4AABIAAAAAAAAA AAAAAAAAzyIBAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQCv1JWjRAIAAEsOAAAU AAAAAAAAAAAAAAAAAAkmAQB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQBntG1J tQ8AAG5/AAAaAAAAAAAAAAAAAAAAAH8oAQB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQIt ABQABgAIAAAAIQAyBWcsjAEAAN4CAAARAAAAAAAAAAAAAAAAAGw4AQBkb2NQcm9wcy9jb3JlLnht bFBLBQYAAAAAEAAQABwEAAAvOwEAAAA= --_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: text/xml; name="draft-ietf-jose-use-cases-00+Mike.xml" Content-Description: draft-ietf-jose-use-cases-00+Mike.xml Content-Disposition: attachment; filename="draft-ietf-jose-use-cases-00+Mike.xml"; size=54179; creation-date="Fri, 29 Mar 2013 00:22:22 GMT"; modification-date="Sun, 28 Apr 2013 07:49:14 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPCEtLSBUaGlzIHRlbXBs YXRlIGlzIGZvciBjcmVhdGluZyBhbiBJbnRlcm5ldCBEcmFmdCB1c2luZyB4bWwycmZjLAogICAg IHdoaWNoIGlzIGF2YWlsYWJsZSBoZXJlOiBodHRwOi8veG1sLnJlc291cmNlLm9yZy4gLS0+Cjwh RE9DVFlQRSByZmMgU1lTVEVNICJyZmMyNjI5LmR0ZCIgWwo8IS0tIE9uZSBtZXRob2QgdG8gZ2V0 IHJlZmVyZW5jZXMgZnJvbSB0aGUgb25saW5lIGNpdGF0aW9uIGxpYnJhcmllcy4KICAgICBUaGVy ZSBoYXMgdG8gYmUgb25lIGVudGl0eSBmb3IgZWFjaCBpdGVtIHRvIGJlIHJlZmVyZW5jZWQuCiAg ICAgQW4gYWx0ZXJuYXRlIG1ldGhvZCAocmZjIGluY2x1ZGUpIGlzIGRlc2NyaWJlZCBpbiB0aGUg cmVmZXJlbmNlcy4gLS0+Cl0+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0ndGV4dC94c2wnIGhyZWY9 J3JmYzI2MjkueHNsdCcgPz4KPCEtLSB1c2VkIGJ5IFhTTFQgcHJvY2Vzc29ycyAtLT4KPCEtLSBG b3IgYSBjb21wbGV0ZSBsaXN0IGFuZCBkZXNjcmlwdGlvbiBvZiBwcm9jZXNzaW5nIGluc3RydWN0 aW9ucyAoUElzKSwKICAgICBwbGVhc2Ugc2VlIGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL2F1dGhv cmluZy9SRUFETUUuaHRtbC4gLS0+CjwhLS0gQmVsb3cgYXJlIGdlbmVyYWxseSBhcHBsaWNhYmxl IFByb2Nlc3NpbmcgSW5zdHJ1Y3Rpb25zIChQSXMpIHRoYXQgbW9zdCBJLURzIG1pZ2h0IHdhbnQg dG8gdXNlLgogICAgIChIZXJlIHRoZXkgYXJlIHNldCBkaWZmZXJlbnRseSB0aGFuIHRoZWlyIGRl ZmF1bHRzIGluIHhtbDJyZmMgdjEuMzIpIC0tPgo8P3JmYyBzdHJpY3Q9InllcyIgPz4KPCEtLSBn aXZlIGVycm9ycyByZWdhcmRpbmcgSUQtbml0cyBhbmQgRFREIHZhbGlkYXRpb24gLS0+CjwhLS0g Y29udHJvbCB0aGUgdGFibGUgb2YgY29udGVudHMgKFRvQykgLS0+Cjw/cmZjIHRvYz0ieWVzIj8+ CjwhLS0gZ2VuZXJhdGUgYSBUb0MgLS0+Cjw/cmZjIHRvY2RlcHRoPSI0Ij8+CjwhLS0gdGhlIG51 bWJlciBvZiBsZXZlbHMgb2Ygc3Vic2VjdGlvbnMgaW4gVG9DLiBkZWZhdWx0OiAzIC0tPgo8IS0t IGNvbnRyb2wgcmVmZXJlbmNlcyAtLT4KPD9yZmMgc3ltcmVmcz0ieWVzIj8+CjwhLS0gdXNlIHN5 bWJvbGljIHJlZmVyZW5jZXMgdGFncywgaS5lLCBbUkZDMjExOV0gaW5zdGVhZCBvZiBbMV0gLS0+ Cjw/cmZjIHNvcnRyZWZzPSJ5ZXMiID8+CjwhLS0gc29ydCB0aGUgcmVmZXJlbmNlIGVudHJpZXMg YWxwaGFiZXRpY2FsbHkgLS0+CjwhLS0gY29udHJvbCB2ZXJ0aWNhbCB3aGl0ZSBzcGFjZQogICAg ICh1c2luZyB0aGVzZSBQSXMgYXMgZm9sbG93cyBpcyByZWNvbW1lbmRlZCBieSB0aGUgUkZDIEVk aXRvcikgLS0+Cjw/cmZjIGNvbXBhY3Q9InllcyIgPz4KPCEtLSBkbyBub3Qgc3RhcnQgZWFjaCBt YWluIHNlY3Rpb24gb24gYSBuZXcgcGFnZSAtLT4KPD9yZmMgc3ViY29tcGFjdD0ibm8iID8+Cjwh LS0ga2VlcCBvbmUgYmxhbmsgbGluZSBiZXR3ZWVuIGxpc3QgaXRlbXMgLS0+CjwhLS0gZW5kIG9m IGxpc3Qgb2YgcG9wdWxhciBJLUQgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMgLS0+CjxyZmMgY2F0 ZWdvcnk9ImluZm8iIGRvY05hbWU9ImRyYWZ0LWlldGYtam9zZS11c2UtY2FzZXMtMDEiCiAgICAg aXByPSJ0cnVzdDIwMDkwMiI+CiAgPCEtLSBjYXRlZ29yeSB2YWx1ZXM6IHN0ZCwgYmNwLCBpbmZv LCBleHAsIGFuZCBoaXN0b3JpYwogICAgIGlwciB2YWx1ZXM6IGZ1bGwzNjY3LCBub01vZGlmaWNh dGlvbjM2NjcsIG5vRGVyaXZhdGl2ZXMzNjY3CiAgICAgeW91IGNhbiBhZGQgdGhlIGF0dHJpYnV0 ZXMgdXBkYXRlcz0iTk5OTiIgYW5kIG9ic29sZXRlcz0iTk5OTiIKICAgICB0aGV5IHdpbGwgYXV0 b21hdGljYWxseSBiZSBvdXRwdXQgd2l0aCAiKGlmIGFwcHJvdmVkKSIgLS0+CgogIDwhLS0gKioq KiogRlJPTlQgTUFUVEVSICoqKioqIC0tPgoKICA8ZnJvbnQ+CiAgICA8IS0tIFRoZSBhYmJyZXZp YXRlZCB0aXRsZSBpcyB1c2VkIGluIHRoZSBwYWdlIGhlYWRlciAtIGl0IGlzIG9ubHkgbmVjZXNz YXJ5IGlmIHRoZQogICAgICAgICBmdWxsIHRpdGxlIGlzIGxvbmdlciB0aGFuIDM5IGNoYXJhY3Rl cnMgLS0+CgogICAgPHRpdGxlIGFiYnJldj0iSk9TRSBVc2UgQ2FzZXMiPlVzZSBDYXNlcyBhbmQg UmVxdWlyZW1lbnRzIGZvciBKU09OIE9iamVjdAogICAgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAo Sk9TRSk8L3RpdGxlPgoKICAgIDwhLS0gYWRkICdyb2xlPSJlZGl0b3IiJyBiZWxvdyBmb3IgdGhl IGVkaXRvcnMgaWYgYXBwcm9wcmlhdGUgLS0+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iUmljaGFy ZCBCYXJuZXMiIGluaXRpYWxzPSJSLkwuIiBzdXJuYW1lPSJCYXJuZXMiPgogICAgICA8b3JnYW5p emF0aW9uPkJCTiBUZWNobm9sb2dpZXM8L29yZ2FuaXphdGlvbj4KCiAgICAgIDxhZGRyZXNzPgog ICAgICAgIDxwb3N0YWw+CiAgICAgICAgICA8c3RyZWV0PjEzMDAgTiAxN3RoIFN0PC9zdHJlZXQ+ CgogICAgICAgICAgPGNpdHk+QXJsaW5ndG9uPC9jaXR5PgoKICAgICAgICAgIDxyZWdpb24+VkE8 L3JlZ2lvbj4KCiAgICAgICAgICA8Y29kZT4yMjIwOTwvY29kZT4KCiAgICAgICAgICA8Y291bnRy eT5VUzwvY291bnRyeT4KICAgICAgICA8L3Bvc3RhbD4KCiAgICAgICAgPGVtYWlsPnJsYkBpcHYu c3g8L2VtYWlsPgogICAgICA8L2FkZHJlc3M+CiAgICA8L2F1dGhvcj4KCiAgICA8ZGF0ZSB5ZWFy PSIyMDEzIi8+CgogICAgPCEtLSBJZiB0aGUgbW9udGggYW5kIHllYXIgYXJlIGJvdGggc3BlY2lm aWVkIGFuZCBhcmUgdGhlIGN1cnJlbnQgb25lcywgeG1sMnJmYyB3aWxsIGZpbGwKICAgICAgICAg aW4gdGhlIGN1cnJlbnQgZGF5IGZvciB5b3UuIElmIG9ubHkgdGhlIGN1cnJlbnQgeWVhciBpcyBz cGVjaWZpZWQsIHhtbDJyZmMgd2lsbCBmaWxsCgkgaW4gdGhlIGN1cnJlbnQgZGF5IGFuZCBtb250 aCBmb3IgeW91LiBJZiB0aGUgeWVhciBpcyBub3QgdGhlIGN1cnJlbnQgb25lLCBpdCBpcwoJIG5l Y2Vzc2FyeSB0byBzcGVjaWZ5IGF0IGxlYXN0IGEgbW9udGggKHhtbDJyZmMgYXNzdW1lcyBkYXk9 IjEiIGlmIG5vdCBzcGVjaWZpZWQgZm9yIHRoZQoJIHB1cnBvc2Ugb2YgY2FsY3VsYXRpbmcgdGhl IGV4cGlyeSBkYXRlKS4gIFdpdGggZHJhZnRzIGl0IGlzIG5vcm1hbGx5IHN1ZmZpY2llbnQgdG8K CSBzcGVjaWZ5IGp1c3QgdGhlIHllYXIuIC0tPgoKICAgIDxhcmVhPlNFQzwvYXJlYT4KCiAgICA8 d29ya2dyb3VwPkpPU0U8L3dvcmtncm91cD4KCiAgICA8IS0tIFdHIG5hbWUgYXQgdGhlIHVwcGVy bGVmdCBjb3JuZXIgb2YgdGhlIGRvYywKICAgICAgICAgSUVURiBpcyBmaW5lIGZvciBpbmRpdmlk dWFsIHN1Ym1pc3Npb25zLgoJIElmIHRoaXMgZWxlbWVudCBpcyBub3QgcHJlc2VudCwgdGhlIGRl ZmF1bHQgaXMgIk5ldHdvcmsgV29ya2luZyBHcm91cCIsCiAgICAgICAgIHdoaWNoIGlzIHVzZWQg YnkgdGhlIFJGQyBFZGl0b3IgYXMgYSBub2QgdG8gdGhlIGhpc3Rvcnkgb2YgdGhlIElFVEYuIC0t PgoKICAgIDxrZXl3b3JkPkpXUywgSldFLCBKV0ssIEpXQSwgSldULCBDTVMsIFMvTUlNRSwgSk9T RSwgWE1QUCwgQUxUTywgT0F1dGg8L2tleXdvcmQ+CgogICAgPCEtLSBLZXl3b3JkcyB3aWxsIGJl IGluY29ycG9yYXRlZCBpbnRvIEhUTUwgb3V0cHV0CiAgICAgICAgIGZpbGVzIGluIGEgbWV0YSB0 YWcgYnV0IHRoZXkgaGF2ZSBubyBlZmZlY3Qgb24gdGV4dCBvciBucm9mZgogICAgICAgICBvdXRw dXQuIElmIHlvdSBzdWJtaXQgeW91ciBkcmFmdCB0byB0aGUgUkZDIEVkaXRvciwgdGhlCiAgICAg ICAgIGtleXdvcmRzIHdpbGwgYmUgdXNlZCBmb3IgdGhlIHNlYXJjaCBlbmdpbmUuIC0tPgoKICAg IDxhYnN0cmFjdD4KICAgICAgPHQ+TWFueSBJbnRlcm5ldCBhcHBsaWNhdGlvbnMgaGF2ZSBhIG5l ZWQgZm9yIG9iamVjdC1iYXNlZCBzZWN1cml0eQogICAgICBtZWNoYW5pc21zIGluIGFkZGl0aW9u IHRvIHNlY3VyaXR5IG1lY2hhbmlzbXMgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgb3IKICAgICAgdHJh bnNwb3J0IGxheWVyLiBJbiB0aGUgcGFzdCwgdGhlIENyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50 YXggaGFzCiAgICAgIHByb3ZpZGVkIGEgYmluYXJ5IHNlY3VyZSBvYmplY3QgZm9ybWF0IGJhc2Vk IG9uIEFTTi4xLiBPdmVyIHRpbWUsIHRoZQogICAgICB1c2Ugb2YgYmluYXJ5IG9iamVjdCBlbmNv ZGluZ3Mgc3VjaCBhcyBBU04uMSBoYXMgYmVlbiBvdmVydGFrZW4gYnkKICAgICAgdGV4dC1iYXNl ZCBlbmNvZGluZ3MsIGZvciBleGFtcGxlIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uLiBUaGlz CiAgICAgIGRvY3VtZW50IGRlZmluZXMgYSBzZXQgb2YgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVu dHMgZm9yIGEgc2VjdXJlIG9iamVjdAogICAgICBmb3JtYXQgZW5jb2RlZCB1c2luZyBKYXZhU2Ny aXB0IE9iamVjdCBOb3RhdGlvbiwgZHJhd24gZnJvbSBhIHZhcmlldHkgb2YKICAgICAgYXBwbGlj YXRpb24gc2VjdXJpdHkgbWVjaGFuaXNtcyBjdXJyZW50bHkgaW4gZGV2ZWxvcG1lbnQuPC90Pgog ICAgPC9hYnN0cmFjdD4KICA8L2Zyb250PgoKICA8bWlkZGxlPgogICAgPHNlY3Rpb24gYW5jaG9y PSJpbnRyby1zZWMiIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPgogICAgICA8dD5JbnRlcm5ldCBhcHBs aWNhdGlvbnMgcmVzdCBvbiB0aGUgbGF5ZXJlZCBhcmNoaXRlY3R1cmUgb2YgdGhlCiAgICAgIElu dGVybmV0LCBhbmQgdGFrZSBhZHZhbnRhZ2Ugb2Ygc2VjdXJpdHkgbWVjaGFuaXNtcyBhdCBhbGwg bGF5ZXJzLiBNYW55CiAgICAgIGFwcGxpY2F0aW9ucyByZWx5IHByaW1hcmlseSBvbiBjaGFubmVs LWJhc2VkIHNlY3VyaXR5IHRlY2hub2xvZ2llcywKICAgICAgd2hpY2ggY3JlYXRlIGEgc2VjdXJl IGNoYW5uZWwgYXQgdGhlIElQIGxheWVyIG9yIHRyYW5zcG9ydCBsYXllciBvdmVyCiAgICAgIHdo aWNoIGFwcGxpY2F0aW9uIGRhdGEgY2FuIGZsb3cgPHhyZWYgdGFyZ2V0PSJSRkM0MzAxIi8+PHhy ZWYKICAgICAgdGFyZ2V0PSJSRkM1MjQ2Ii8+LiBUaGVzZSBtZWNoYW5pc21zLCBob3dldmVyLCBj YW5ub3QgcHJvdmlkZSBlbmQtdG8tZW5kCiAgICAgIHNlY3VyaXR5IGluIHNvbWUgY2FzZXMuIEZv ciBleGFtcGxlLCBpbiBwcm90b2NvbHMgd2l0aCBhcHBsaWNhdGlvbi1sYXllcgogICAgICBpbnRl cm1lZGlhcmllcywgY2hhbm5lbC1iYXNlZCBzZWN1cml0eSBwcm90b2NvbHMgd291bGQgcHJvdGVj dCBtZXNzYWdlcwogICAgICBmcm9tIGF0dGFja2VycyBiZXR3ZWVuIGludGVybWVkaWFyaWVzLCBi dXQgbm90IGZyb20gdGhlIGludGVybWVkaWFyaWVzCiAgICAgIHRoZW1zZWx2ZXMuIFRoZXNlIGNh c2VzIHJlcXVpcmUgb2JqZWN0LWJhc2VkIHNlY3VyaXR5IHRlY2hub2xvZ2llcywKICAgICAgd2hp Y2ggZW1iZWQgYXBwbGljYXRpb24gZGF0YSB3aXRoaW4gYSBzZWN1cmUgb2JqZWN0IHRoYXQgY2Fu IGJlIHNhZmVseQogICAgICBoYW5kbGVkIGJ5IHVudHJ1c3RlZCBlbnRpdGllcy48L3Q+CgogICAg ICA8dD5UaGUgbW9zdCB3ZWxsLWtub3duIGV4YW1wbGUgb2Ygc3VjaCBhIHByb3RvY29sIHRvZGF5 IGlzIHRoZSB1c2Ugb2YKICAgICAgU2VjdXJlL011bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4 dGVuc2lvbnMgKFMvTUlNRSkgcHJvdGVjdGlvbnMgd2l0aGluCiAgICAgIHRoZSBlbWFpbCBzeXN0 ZW0gPHhyZWYgdGFyZ2V0PSJSRkM1NzUxIi8+PHhyZWYgdGFyZ2V0PSJSRkM1MzIyIi8+LiBBbgog ICAgICBlbWFpbCBtZXNzYWdlIHR5cGljYWxseSBwYXNzZXMgdGhyb3VnaCBhIHNlcmllcyBvZiBp bnRlcm1lZGlhdGUgTWFpbAogICAgICBUcmFuc2ZlciBBZ2VudHMgKE1UQXMpIGVuIHJvdXRlIHRv IGl0cyBkZXN0aW5hdGlvbi4gV2hpbGUgdGhlc2UgTVRBcwogICAgICBvZnRlbiBhcHBseSBjaGFu bmVsLWJhc2VkIHNlY3VyaXR5IHByb3RlY3Rpb25zIHRvIHRoZWlyIGludGVyYWN0aW9ucwogICAg ICAoZS5nLiwgPHhyZWYgdGFyZ2V0PSJSRkMzMjA3Ii8+KSwgdGhlc2UgcHJvdGVjdGlvbnMgZG8g bm90IHByZXZlbnQgdGhlCiAgICAgIE1UQXMgZnJvbSBpbnRlcmZlcmluZyB3aXRoIHRoZSBtZXNz YWdlLiBJbiBvcmRlciB0byBwcm92aWRlIGVuZC10by1lbmQKICAgICAgc2VjdXJpdHkgcHJvdGVj dGlvbnMgaW4gdGhlIHByZXNlbmNlIG9mIHVudHJ1c3RlZCBNVEFzLCBtYWlsIHVzZXJzIGNhbgog ICAgICB1c2UgUy9NSU1FIHRvIGVtYmVkIG1lc3NhZ2UgYm9kaWVzIGluIGEgc2VjdXJlIG9iamVj dCBmb3JtYXQgdGhhdCBjYW4KICAgICAgcHJvdmlkZSBjb25maWRlbnRpYWxpdHksIGludGVncml0 eSwgYW5kIGRhdGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uLjwvdD4KCiAgICAgIDx0PlMvTUlNRSBp cyBiYXNlZCBvbiB0aGUgQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCBmb3Igc2VjdXJlCiAg ICAgIG9iamVjdHMgKENNUykgPHhyZWYgdGFyZ2V0PSJSRkM1NjUyIi8+LiBDTVMgaXMgZGVmaW5l ZCB1c2luZyBBYnN0cmFjdAogICAgICBTeW50YXggTm90YXRpb24gMSAoQVNOLjEpIGFuZCB0cmFk aXRpb25hbGx5IGVuY29kZWQgdXNpbmcgdGhlIEFTTi4xCiAgICAgIERpc3Rpbmd1aXNoZWQgRW5j b2RpbmcgUnVsZXMgKERFUiksIHdoaWNoIGRlZmluZSBhIGJpbmFyeSBlbmNvZGluZyBvZgogICAg ICB0aGUgcHJvdGVjdGVkIG1lc3NhZ2UgYW5kIGFzc29jaWF0ZWQgcGFyYW1ldGVycyA8eHJlZgog ICAgICB0YXJnZXQ9IklUVS5YNjkwLjE5OTQiLz4uIEluIHJlY2VudCB5ZWFycywgdXNhZ2Ugb2Yg QVNOLjEgaGFzIGRlY3JlYXNlZAogICAgICAoYWxvbmcgd2l0aCBvdGhlciBiaW5hcnkgZW5jb2Rp bmdzIGZvciBnZW5lcmFsIG9iamVjdHMpLCB3aGlsZSBtb3JlCiAgICAgIGFwcGxpY2F0aW9ucyBo YXZlIGNvbWUgdG8gcmVseSBvbiB0ZXh0LWJhc2VkIGZvcm1hdHMgc3VjaCBhcyB0aGUKICAgICAg RXh0ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgb3IgdGhlIEphdmFTY3JpcHQgT2JqZWN0 IE5vdGF0aW9uCiAgICAgIChKU09OKSA8eHJlZiB0YXJnZXQ9IlczQy5SRUMteG1sLTE5OTgiLz48 eHJlZiB0YXJnZXQ9IlJGQzQ2MjciLz4uPC90PgoKICAgICAgPHQ+TWFueSBjdXJyZW50IGFwcGxp Y2F0aW9ucyB0aHVzIGhhdmUgbXVjaCBtb3JlIHJvYnVzdCBzdXBwb3J0IGZvcgogICAgICBwcm9j ZXNzaW5nIG9iamVjdHMgaW4gdGhlc2UgdGV4dC1iYXNlZCBmb3JtYXRzIHRoYW4gQVNOLjEgb2Jq ZWN0czsKICAgICAgaW5kZWVkLCBtYW55IGxhY2sgdGhlIGFiaWxpdHkgdG8gcHJvY2VzcyBBU04u MSBvYmplY3RzIGF0IGFsbC4gVG8KICAgICAgc2ltcGxpZnkgdGhlIGFkZGl0aW9uIG9mIG9iamVj dC1iYXNlZCBzZWN1cml0eSBmZWF0dXJlcyB0byB0aGVzZQogICAgICBhcHBsaWNhdGlvbnMsIHRo ZSBJRVRGIEpTT04gT2JqZWN0IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24gKEpPU0UpIHdvcmtpbmcK ICAgICAgZ3JvdXAgaGFzIGJlZW4gY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBzZWN1cmUgb2JqZWN0 IGZvcm1hdCBiYXNlZCBvbgogICAgICBKU09OLiBXaGlsZSB0aGUgYmFzaWMgcmVxdWlyZW1lbnRz IGZvciB0aGlzIG9iamVjdCBmb3JtYXQgYXJlCiAgICAgIHN0cmFpZ2h0Zm9yd2FyZCAtLSBuYW1l bHksIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IG1lY2hhbmlzbXMsCiAgICAgIGVuY29k ZWQgaW4gSlNPTiAtLSBkaXNjdXNzaW9ucyBpbiB0aGUgd29ya2luZyBncm91cCBpbmRpY2F0ZWQg dGhhdAogICAgICBkaWZmZXJlbnQgYXBwbGljYXRpb25zIGhvcGluZyB0byB1c2UgdGhlIGZvcm1h dHMgZGVmaW5lZCBieSBKT1NFIGhhdmUKICAgICAgZGlmZmVyZW50IHJlcXVpcmVtZW50cy4gVGhp cyBkb2N1bWVudCBzdW1tYXJpemVzIHRoZSB1c2UgY2FzZXMgZm9yIEpPU0UKICAgICAgZW52aXNp b25lZCBieSB0aG9zZSBwb3RlbnRpYWwgYXBwbGljYXRpb25zIGFuZCB0aGUgcmVzdWx0aW5nIHJl cXVpcmVtZW50cyBmb3IKICAgICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBhbmQgb2JqZWN0IGVuY29k aW5ncy48L3Q+CgogICAgICA8dD5Tb21lIHN5c3RlbXMgdGhhdCB1c2UgWE1MIGhhdmUgc3BlY2lm aWVkIHRoZSB1c2Ugb2YgWE1MLWJhc2VkCiAgICAgIHNlY3VyaXR5IG1lY2hhbmlzbXMgZm9yIG9i amVjdCBzZWN1cml0eSwgbmFtZWx5IFhNTCBEaWdpdGFsIFNpZ25hdHVyZXMKICAgICAgYW5kIFhN TCBFbmNyeXB0aW9uIDx4cmVmIHRhcmdldD0iVzNDLkNSLXhtbGRzaWctY29yZTItMjAxMjAxMjQi Lz48eHJlZgogICAgICB0YXJnZXQ9IlczQy5DUi14bWxlbmMtY29yZTEtMjAxMjAzMTMiLz4uIFRo ZXNlIG1lY2hhbmlzbXMgYXJlIGRlZmluZWQKICAgICAgZm9yIHVzZSB3aXRoIHNldmVyYWwgc2Vj dXJpdHkgdG9rZW4gc3lzdGVtcyAoZS5nLiwKICAgICAgU0FNTCA8eHJlZiB0YXJnZXQ9Ik9BU0lT LnNhbWwtY29yZS0yLjAtb3MiLz4gYW5kCiAgICAgIFdTLUZlZGVyYXRpb24gPHhyZWYgdGFyZ2V0 PSJXUy1GZWRlcmF0aW9uIi8+KSBhbmQgdGhlIENBUAogICAgICBlbWVyZ2VuY3kgYWxlcnRpbmcg Zm9ybWF0IDx4cmVmIHRhcmdldD0iQ0FQIi8+LiBJbiBwcmFjdGljZSwgaG93ZXZlciwKICAgICAg WE1MLWJhc2VkIHNlY3VyZSBvYmplY3QgZm9ybWF0cyBpbnRyb2R1Y2Ugc2ltaWxhciBsZXZlbHMg b2YgY29tcGxleGl0eQogICAgICB0byBBU04uMSwgc28gZGV2ZWxvcGVycyB0aGF0IGxhY2sgdGhl IHRvb2xzIG9yIG1vdGl2YXRpb24gdG8gaGFuZGxlCiAgICAgIEFTTi4xIGFyZW4ndCBsaWtlbHkg dG8gdXNlIFhNTCBzZWN1cml0eSBlaXRoZXIuIFRoaXMgc2l0dWF0aW9uIG1vdGl2YXRlcwogICAg ICB0aGUgY3JlYXRpb24gb2YgYSBKU09OLWJhc2VkIHNlY3VyZSBvYmplY3QgZm9ybWF0IHRoYXQg aXMgc2ltcGxlIGVub3VnaAogICAgICB0byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0aGF0IGl0IGNh biBiZSBlYXNpbHkgYWRvcHRlZCBieSBkZXZlbG9wZXJzIHdpdGgKICAgICAgbWluaW1hbCBlZmZv cnQgYW5kIHRvb2xzLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9ImRl Zi1zZWMiIHRpdGxlPSJEZWZpbml0aW9ucyI+CiAgICAgIDwhLS0KICAgICAgPHQ+VGhlIGtleSB3 b3JkcyAibXVzdCIsICJtdXN0IE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1Qi LAogICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5k ICJPUFRJT05BTCIgaW4gdGhpcwogICAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIDx4cmVmCiAgICAgIHRhcmdldD0iUkZDMjExOSI+UkZDIDIxMTk8L3hy ZWY+LjwvdD4KICAgICAgLS0+CgogICAgICA8dD5UaGlzIGRvY3VtZW50IG1ha2VzIGV4dGVuc2l2 ZSB1c2Ugb2Ygc3RhbmRhcmQgc2VjdXJpdHkgdGVybWlub2xvZ3kKICAgICAgPHhyZWYgdGFyZ2V0 PSJSRkM0OTQ5Ii8+LiBJbiBhZGRpdGlvbiwgYmVjYXVzZSB0aGUgdXNlIGNhc2VzIGZvciBKT1NF CiAgICAgIGFuZCBDTVMgYXJlIHNpbWlsYXIsIHdlIHdpbGwgc29tZXRpbWVzIG1ha2UgYW5hbG9n aWVzIHRvIHNvbWUgQ01TCiAgICAgIGNvbmNlcHRzIDx4cmVmIHRhcmdldD0iUkZDNTY1MiIvPi48 L3Q+CgogICAgICA8dD5UaGUgSk9TRSB3b3JraW5nIGdyb3VwIGNoYXJ0ZXIgY2FsbHMgZm9yIHRo ZSBncm91cCB0byBkZWZpbmUgdGhyZWUKICAgICAgYmFzaWMgSlNPTiBvYmplY3QgZm9ybWF0czo8 bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAgICAgICA8dD5Db25maWRlbnRpYWxpdHktcHJvdGVj dGVkIG9iamVjdCBmb3JtYXQ8L3Q+CgogICAgICAgICAgPHQ+SW50ZWdyaXR5LXByb3RlY3RlZCBv YmplY3QgZm9ybWF0PC90PgoKICAgICAgICAgIDx0PkEgZm9ybWF0IGZvciBleHByZXNzaW5nIGtl eXM8L3Q+CiAgICAgICAgPC9saXN0PgoKICAgICAgSW4gdGhpcyBkb2N1bWVudCwgd2Ugd2lsbCBy ZWZlciB0byB0aGVzZSBhcwogICAgICB0aGUgInNpZ25lZCBvYmplY3QgZm9ybWF0IiwKICAgICAg dGhlICJlbmNyeXB0ZWQgb2JqZWN0IGZvcm1hdCIsCiAgICAgIGFuZCB0aGUgImtleSBmb3JtYXQi LCByZXNwZWN0aXZlbHkuCiAgICAgIFRoZSBKT1NFICJzaWduZWQgb2JqZWN0IGZvcm1hdCIgaXMK ICAgICAgSlNPTiBXZWIgU2lnbmF0dXJlIChKV1MpIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtam9z ZS1qc29uLXdlYi1zaWduYXR1cmUiLz4uCiAgICAgIFRoZSBKT1NFICJlbmNyeXB0ZWQgb2JqZWN0 IGZvcm1hdCIgaXMKICAgICAgSlNPTiBXZWIgRW5jcnlwdGlvbiAoSldFKSA8eHJlZiB0YXJnZXQ9 IkktRC5pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbiIvPi4KICAgICAgVGhlIEpPU0UgImtl eSBmb3JtYXQiIGlzCiAgICAgIEpTT04gV2ViIEtleSAoSldTKSA8eHJlZiB0YXJnZXQ9IkktRC5p ZXRmLWpvc2UtanNvbi13ZWIta2V5Ii8+LgogICAgICBBbGdvcml0aG1zIGFuZCBhbGdvcml0aG0g aWRlbnRpZmllcnMgdXNlZCBieSBKV1MsIEpXRSwgYW5kIEpXSyBhcmUgZGVmaW5lZCBpbgogICAg ICBKU09OIFdlYiBBbGdvcml0aG1zIChKV1MpIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtam9zZS1q c29uLXdlYi1hbGdvcml0aG1zIi8+LgogICAgICA8L3Q+CgogICAgICA8dD5JbiBnZW5lcmFsLCB3 aGVyZSB0aGVyZSBpcyBubyBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gYXN5bW1ldHJpYyBh bmQKICAgICAgc3ltbWV0cmljIG9wZXJhdGlvbnMsIHdlIHdpbGwgdXNlIHRoZSB0ZXJtcyAic2ln bmluZyIsICJzaWduYXR1cmUiLCBldGMuCiAgICAgIHRvIGRlbm90ZSBib3RoIHRydWUgZGlnaXRh bCBzaWduYXR1cmVzIGludm9sdmluZyBhc3ltbWV0cmljIGNyeXB0b2dyYXBoeQogICAgICBhcyB3 ZWxsIGFzIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gY29kZXMgdXNpbmcgc3ltbWV0cmljIGtleXMg KE1BQ3MpLjwvdD4KCiAgICAgIDx0PkluIHRoZSBsaWZlc3BhbiBvZiBhIHNlY3VyZSBvYmplY3Qs IHRoZXJlIGFyZSB0d28gYmFzaWMgcm9sZXMsIGFuCiAgICAgIGVudGl0eSB0aGF0IGNyZWF0ZXMg dGhlIG9iamVjdCAoZS5nLiwgZW5jcnlwdGluZyBvciBzaWduaW5nIGEgcGF5bG9hZCksCiAgICAg IGFuZCBhbiBlbnRpdHkgdGhhdCB1c2VzIHRoZSBvYmplY3QgKGRlY3J5cHRpbmcsIHZlcmlmeWlu ZykuIFdlIHdpbGwKICAgICAgcmVmZXIgdG8gdGhlc2Ugcm9sZXMgYXMgInNlbmRlciIgYW5kICJy ZWNpcGllbnQiLCByZXNwZWN0aXZlbHkuIE5vdGUKICAgICAgdGhhdCB3aGlsZSBzb21lIHJlcXVp cmVtZW50cyBhbmQgdXNlIGNhc2VzIG1heSByZWZlciB0byB0aGVzZSBhcyBzaW5nbGUKICAgICAg ZW50aXRpZXMsIGVhY2ggb2JqZWN0IG1heSBoYXZlIG11bHRpcGxlIGVudGl0aWVzIGluIGVhY2gg cm9sZS4gRm9yCiAgICAgIGV4YW1wbGUsIGEgbWVzc2FnZSBtYXkgYmUgc2lnbmVkIGJ5IG11bHRp cGxlIHNlbmRlcnMsIG9yIGRlY3J5cHRlZCBieQogICAgICBtdWx0aXBsZSByZWNpcGllbnRzLjwv dD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9ImJhc2ljLXNlYyIgdGl0bGU9 IkJhc2ljIFJlcXVpcmVtZW50cyI+CiAgICAgIDx0Pk9idmlvdXNseSwgZm9yIHRoZSBlbmNyeXB0 ZWQgYW5kIHNpZ25lZCBvYmplY3QgZm9ybWF0cywgdGhlIG5lY2Vzc2FyeQogICAgICBwcm90ZWN0 aW9ucyB3aWxsIGJlIGNyZWF0ZWQgdXNpbmcgYXBwcm9wcmlhdGUgY3J5cHRvZ3JhcGhpYyBtZWNo YW5pc21zOgogICAgICBzeW1tZXRyaWMgb3IgYXN5bW1ldHJpYyBlbmNyeXB0aW9uIGZvciBjb25m aWRlbnRpYWxpdHkgYW5kIE1BQ3Mgb3IKICAgICAgZGlnaXRhbCBzaWduYXR1cmVzIGZvciBpbnRl Z3JpdHkgcHJvdGVjdGlvbi4gSW4gYm90aCBjYXNlcywgaXQgaXMKICAgICAgbmVjZXNzYXJ5IGZv ciB0aGUgSk9TRSBmb3JtYXQgdG8gc3VwcG9ydCBib3RoIHN5bW1ldHJpYyBhbmQgYXN5bW1ldHJp YwogICAgICBvcGVyYXRpb25zLjxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PlRo ZSBKT1NFIGVuY3J5cHRlZCBvYmplY3QgZm9ybWF0IG11c3Qgc3VwcG9ydCBvYmplY3QgZW5jcnlw dGlvbgogICAgICAgICAgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIg c2hhcmUgYSBzeW1tZXRyaWMga2V5LjwvdD4KCiAgICAgICAgICA8dD5UaGUgSk9TRSBlbmNyeXB0 ZWQgb2JqZWN0IGZvcm1hdCBtdXN0IHN1cHBvcnQgb2JqZWN0IGVuY3J5cHRpb24KICAgICAgICAg IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBzZW5kZXIgaGFzIG9ubHkgYSBwdWJsaWMga2V5IGZvciB0 aGUKICAgICAgICAgIHJlY2VpdmVyLjwvdD4KCiAgICAgICAgICA8dD5UaGUgSk9TRSBzaWduZWQg b2JqZWN0IGZvcm1hdCBtdXN0IHN1cHBvcnQgaW50ZWdyaXR5IHByb3RlY3Rpb24gdXNpbmcKICAg ICAgICAgIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMgKE1BQ3MpLCBmb3IgdGhlIGNhc2Ug d2hlcmUgdGhlIHNlbmRlcgogICAgICAgICAgYW5kIHJlY2VpdmVyIHNoYXJlIG9ubHkgYSBzeW1t ZXRyaWMga2V5LjwvdD4KCiAgICAgICAgICA8dD5UaGUgSk9TRSBzaWduZWQgb2JqZWN0IGZvcm1h dCBtdXN0IHN1cHBvcnQgaW50ZWdyaXR5IHByb3RlY3Rpb24gdXNpbmcKICAgICAgICAgIGRpZ2l0 YWwgc2lnbmF0dXJlcywgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZSByZWNlaXZlciBoYXMgb25seSBh CiAgICAgICAgICBwdWJsaWMga2V5IGZvciB0aGUgc2VuZGVyLjwvdD4KICAgICAgICA8L2xpc3Q+ PC90PgoKICAgICAgPHQ+SW4gY2FzZXMgd2hlcmUgdHdvIGVudGl0aWVzIGFyZSBnb2luZyB0byBi ZSBleGNoYW5naW5nIHNldmVyYWwgSk9TRQogICAgICBvYmplY3RzLCBpdCBtaWdodCBiZSBoZWxw ZnVsIHRvIHByZS1uZWdvdGlhdGUgc29tZSBwYXJhbWV0ZXJzIHNvIHRoYXQgCiAgICAgIHRoZXkg ZG8gbm90IGhhdmUgdG8gYmUgc2lnbmFsZWQgaW4gZXZlcnkgSk9TRSBvYmplY3QuICBIb3dldmVy LAogICAgICBzbyBhcyBub3QgdG8gY29uZnVzZSBlbmRwb2ludHMgdGhhdCBkbyBub3Qgc3VwcG9y dCBwcmUtbmVnb3RpYXRpb24sCiAgICAgIGl0IGlzIHVzZWZ1bCB0byBzaWduYWwgd2hlbiBwcmUt bmVnb3RpYXRlZCBwYXJhbWV0ZXJzIGFyZSBpbiB1c2UgaW4gdGhvc2UgY2FzZXMuCiAgICAgICAg ICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICA8dD5JdCBzaG91bGQgYmUgcG9zc2li bGUgdG8gZXh0ZW5kIHRoZSBiYXNlCgkgIEpPU0Ugc2lnbmVkIGFuZCBlbmNyeXB0ZWQgb2JqZWN0 IGZvcm1hdHMKCSAgdG8gaW5kaWNhdGUgdGhhdCBwcmUtbmVnb3RpYXRlZCBwYXJhbWV0ZXJzIGFy ZSB0byBiZSB1c2VkIHRvIAogICAgICAgICAgcHJvY2VzcyB0aGUgb2JqZWN0LiAgVGhpcyBleHRl bnNpb24gc2hvdWxkIGFsc28gcHJvdmlkZSBhIG1lYW5zIG9mIGluZGljYXRpbmcgb2YgCiAgICAg ICAgICB3aGljaCBwYXJhbWV0ZXJzIGFyZSB0byBiZSB1c2VkLjwvdD4KICAgICAgICAgIDwvbGlz dD4KICAgICAgPC90PgoKICAgICAgPHQ+VGhlIHB1cnBvc2Ugb2YgdGhlIGtleSBmb3JtYXQgaXMg dG8gcHJvdmlkZSB0aGUgcmVjaXBpZW50IHdpdGgKICAgICAgc3VmZmljaWVudCBpbmZvcm1hdGlv biB0byB1c2UgdGhlIGVuY29kZWQga2V5IHRvIHByb2Nlc3MgY3J5cHRvZ3JhcGhpYwogICAgICBt ZXNzYWdlcy4gVGh1cyBpdCBpcyBzb21ldGltZXMgbmVjZXNzYXJ5IHRvIGluY2x1ZGUgYWRkaXRp b25hbCBwYXJhbWV0ZXJzIGFsb25nCiAgICAgIHdpdGggdGhlIGJhcmUga2V5LjwvdD4KCiAgICAg IDx0PjxsaXN0IHN0eWxlPSJzeW1ib2xzIj4KICAgICAgICAgIDx0PlRoZSBKT1NFIGtleSBmb3Jt YXQgbXVzdCBlbmFibGUgaW5jbHVzaW9uIG9mIGFsbCBhbGdvcml0aG0gcGFyYW1ldGVycwogICAg ICAgICAgbmVjZXNzYXJ5IHRvIHVzZSB0aGUgZW5jb2RlZCBrZXksIGluY2x1ZGluZyBhbiBpZGVu dGlmaWVyIGZvciB0aGUKICAgICAgICAgIGFsZ29yaXRobSB3aXRoIHdoaWNoIHRoZSBrZXkgaXMg dXNlZCBhcyB3ZWxsIGFzIGFueSBhZGRpdGlvbmFsCiAgICAgICAgICBwYXJhbWV0ZXJzIHJlcXVp cmVkIGJ5IHRoZSBhbGdvcml0aG0gKGUuZy4sIGVsbGlwdGljIGN1cnZlCiAgICAgICAgICBwYXJh bWV0ZXJzKS48L3Q+CiAgICAgICAgPC9saXN0PjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2Vj dGlvbiBhbmNob3I9ImFwcC1yZXEtc2VjIiB0aXRsZT0iQXBwbGljYXRpb24gYW5kIFByb3RvY29s IFJlcXVpcmVtZW50cyI+CiAgICAgIDx0PgoJSXQgc2hvdWxkIGJlIHVuZGVyc3Rvb2QgdGhhdCB3 aGlsZSBKT1NFIGlzIGNyZWF0aW5nIGRhdGEgZm9ybWF0cywKCWl0IGlzIG5vdCBjcmVhdGluZyBw cm90b2NvbHMgb3IgYXBwbGljYXRpb25zLgoJUmF0aGVyLCB0aGUgSk9TRSBkYXRhIGZvcm1hdHMg YXJlIGludGVuZGVkIHRvIGJlIHVzZWQgaW4gcHJvdG9jb2xzCglhbmQgYnkgYXBwbGljYXRpb25z LgoJVGhlc2UgcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMgd2lsbCBzcGVjaWZ5IGFkZGl0aW9u YWwgcmVxdWlyZW1lbnRzCglvbiB1c2luZyB0aGUgSk9TRSBkYXRhIGZvcm1hdHMgaW4gdGhvc2Ug cGFydGljdWxhciBjb250ZXh0cy4KCVRoZXNlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHdpbGwg aW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzoKCTxsaXN0IHN0eWxlPSJzeW1ib2xzIj4K CSAgPHQ+cmVxdWlyZW1lbnRzIG9uIG1lc3NhZ2UgY29udGVudHMsPC90PgoJICA8dD5yZXF1aXJl bWVudHMgb24gYWxnb3JpdGhtcyB1c2VkLDwvdD4KCSAgPHQ+cmVxdWlyZW1lbnRzIG9uIGtleXMg dXNlZCw8L3Q+CgkgIDx0PnJlcXVpcmVtZW50cyBvbiBrZXkgZGlzdHJpYnV0aW9uIG1ldGhvZHMs IGFuZDwvdD4KCSAgPHQ+cmVxdWlyZW1lbnRzIG9uIGtleSBzZWxlY3Rpb24gbWV0aG9kcy48L3Q+ Cgk8L2xpc3Q+CiAgICAgIDwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9 InVzZS1jYXNlcy1zZWMiIHRpdGxlPSJVc2UgQ2FzZXMiPgogICAgICA8dD5TZXZlcmFsIHdvcmtp bmcgZ3JvdXBzIGRldmVsb3BpbmcgYXBwbGljYXRpb24tbGF5ZXIgcHJvdG9jb2xzCiAgICAgIGhh dmUgZXhwcmVzc2VkIGEgZGVzaXJlIHRvIHVzZSB0aGUgSk9TRSBkYXRhIGZvcm1hdHMgaW4gdGhl aXIKICAgICAgZGVzaWducyBmb3IgZW5kLXRvLWVuZCBzZWN1cml0eSBmZWF0dXJlcy4gSW4gdGhp cyBzZWN0aW9uLCB3ZSBzdW1tYXJpemUKICAgICAgdGhlIHVzZSBjYXNlcyBwcm9wb3NlZCBieSB0 aGVzZSBncm91cHMgYW5kIGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50cyB0aGF0CiAgICAgIHRoZXkg aW1wbHkgZm9yIHRoZSBKT1NFIG9iamVjdCBmb3JtYXRzLjwvdD4KCiAgICAgIDxzZWN0aW9uIGFu Y2hvcj0ic2VjLXRva2VuLXNlYyIgdGl0bGU9IlNlY3VyaXR5IFRva2VucyI+CiAgICAgICAgPHQ+ U2VjdXJpdHkgdG9rZW5zIGFyZSBhIGNvbW1vbiB1c2UgY2FzZSBmb3Igb2JqZWN0LWJhc2VkIHNl Y3VyaXR5LAogICAgICAgIGZvciBleGFtcGxlLCBTQU1MIGFzc2VydGlvbnMgPHhyZWYgdGFyZ2V0 PSJPQVNJUy5zYW1sLWNvcmUtMi4wLW9zIi8+LgogICAgICAgIFNlY3VyaXR5IHRva2VucyBhcmUg dXNlZCB0byBjb252ZXkgaW5mb3JtYXRpb24gYWJvdXQgYSBzdWJqZWN0IGVudGl0eQogICAgICAg ICgiY2xhaW1zIiBvciAiYXNzZXJ0aW9ucyIpIGZyb20gYW4gaXNzdWVyIHRvIGEgcmVjaXBpZW50 LiBUaGUgc2VjdXJpdHkKICAgICAgICBmZWF0dXJlcyBvZiBhIHRva2VuIGZvcm1hdCBlbmFibGUg dGhlIHJlY2lwaWVudCB0byB2ZXJpZnkgdGhhdCB0aGUKICAgICAgICBjbGFpbXMgY2FtZSBmcm9t IHRoZSBpc3N1ZXIgYW5kLCBpZiB0aGUgb2JqZWN0IGlzCiAgICAgICAgY29uZmlkZW50aWFsaXR5 LXByb3RlY3RlZCwgdGhhdCB0aGV5IHdlcmUgbm90IHZpc2libGUgdG8gb3RoZXIKICAgICAgICBw YXJ0aWVzLjwvdD4KCiAgICAgICAgPHQ+U2VjdXJpdHkgdG9rZW5zIGFyZSB1c2VkIGluIGZlZGVy YXRpb24gcHJvdG9jb2xzIHN1Y2ggYXMgU0FNTCAyLjAKCTx4cmVmIHRhcmdldD0iT0FTSVMuc2Ft bC1jb3JlLTIuMC1vcyIvPiwKICAgICAgICBXUy1GZWRlcmF0aW9uIDx4cmVmIHRhcmdldD0iV1Mt RmVkZXJhdGlvbiIvPiwKCU1vemlsbGEgUGVyc29uYSA8eHJlZiB0YXJnZXQ9IlBlcnNvbmEiLz4s CglhbmQgT3BlbklEIENvbm5lY3QgPHhyZWYgdGFyZ2V0PSJPcGVuSUQuTWVzc2FnZXMiLz4sCglh cyB3ZWxsIGFzIGluIHJlc291cmNlIGF1dGhvcml6YXRpb24KICAgICAgICBwcm90b2NvbHMgc3Vj aCBhcyBPQXV0aCAyLjAgPHhyZWYgdGFyZ2V0PSJSRkM2NzQ5Ii8+LAoJaW5jbHVkaW5nIGZvciBP QXV0aCBiZWFyZXIgdG9rZW5zIDx4cmVmIHRhcmdldD0iUkZDNjc1MCIvPi4gSW4gc29tZSBjYXNl cywKICAgICAgICBzZWN1cml0eSB0b2tlbnMgYXJlIHVzZWQgZm9yIGNsaWVudCBhdXRoZW50aWNh dGlvbiBhbmQgZm9yIGFjY2VzcwogICAgICAgIGNvbnRyb2wgPHhyZWYgdGFyZ2V0PSJJLUQuaWV0 Zi1vYXV0aC1qd3QtYmVhcmVyIi8+PHhyZWYKICAgICAgICB0YXJnZXQ9IkktRC5pZXRmLW9hdXRo LXNhbWwyLWJlYXJlciIvPi48L3Q+CgoJPHQ+SlNPTiBXZWIgVG9rZW4gKEpXVCkgPHhyZWYgdGFy Z2V0PSJJLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbiIvPgoJaXMgYSBzZWN1cml0eSB0b2tl biBmb3JtYXQKCWJhc2VkIG9uIEpTT04gYW5kIEpPU0UuIEl0IGlzIHVzZWQgd2l0aCBNb3ppbGxh IFBlcnNvbmEsCglPcGVuSUQgQ29ubmVjdCwgYW5kIE9BdXRoLiBCZWNhdXNlIEpXVHMgYXJlIG9m dGVuIHVzZWQgaW4gY29udGV4dHMKCXdpdGggbGltaXRlZCBzcGFjZSAoZS5nLiwgSFRUUCBxdWVy eSBwYXJhbWV0ZXJzKSwgaXQgaXMgYSBjb3JlCglyZXF1aXJlbWVudCBmb3IgSldUcywgYW5kIHRo dXMgSk9TRSwgdG8gaGF2ZSBhIGNvbXBhY3QsIFVSTC1zYWZlCglyZXByZXNlbnRhdGlvbi48L3Q+ CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiBhbmNob3I9Im9hdXRoLXNlYyIgdGl0 bGU9Ik9BdXRoIj4KCiAgICAgICAgPHQ+VGhlIE9BdXRoIHByb3RvY29sIGRlZmluZXMgYSBtZWNo YW5pc20gZm9yIGRpc3RyaWJ1dGluZyBhbmQgdXNpbmcKICAgICAgICBhdXRob3JpemF0aW9uIHRv a2VucyB1c2luZyBIVFRQIDx4cmVmIHRhcmdldD0iUkZDNjc0OSIvPi4gQSBDbGllbnQKICAgICAg ICB0aGF0IHdpc2hlcyB0byBhY2Nlc3MgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdHMgYXV0 aG9yaXphdGlvbiBmcm9tCiAgICAgICAgdGhlIFJlc291cmNlIE93bmVyLiBJZiB0aGUgUmVzb3Vy Y2UgT3duZXIgYWxsb3dzIHRoaXMgYWNjZXNzLCBoZQogICAgICAgIGRpcmVjdHMgYW4gQXV0aG9y aXphdGlvbiBTZXJ2ZXIgdG8gaXNzdWUgYW4gYWNjZXNzIHRva2VuIHRvIHRoZQogICAgICAgIENs aWVudC4gV2hlbiB0aGUgQ2xpZW50IHdpc2hlcyB0byBhY2Nlc3MgdGhlIHByb3RlY3RlZCByZXNv dXJjZSwgaGUKICAgICAgICBwcmVzZW50cyB0aGUgdG9rZW4gdG8gdGhlIHJlbGV2YW50IFJlc291 cmNlIFNlcnZlciwgd2hpY2ggdmVyaWZpZXMgdGhlCiAgICAgICAgdmFsaWRpdHkgb2YgdGhlIHRv a2VuIGJlZm9yZSBwcm92aWRpbmcgYWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQKICAgICAgICByZXNv dXJjZS48L3Q+CgogICAgICAgIDxmaWd1cmUgYW5jaG9yPSJmaWdPQXV0aCIgdGl0bGU9IlRoZSBP QXV0aCBwcm9jZXNzIj4KICAgICAgICAgIDxhcnR3b3JrPjwhW0NEQVRBWyAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAg ICAgIHwgICBSZXNvdXJjZSAgICB8PC4uLi4uLi4uPnwgQXV0aG9yaXphdGlvbiB8CiAgICAgICAg ICAgICAgfCAgICBTZXJ2ZXIgICAgIHwgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIF4gICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tfC0tKyAgICAgICAgICArLS18LS0tLS0tLS0tLS0t KwogICAgICAgICAgICAgIHwgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAgIFJlc291cmNl ICAgIHwKICAgICAgICAgICAgICB8ICAgICBDbGllbnQgICAgfCAgICAgICAgICB8ICAgICBPd25l ciAgICAgfAogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLStdXT48L2FydHdvcms+CgogICAgICAgICAgPHBvc3RhbWJsZS8+CiAgICAgICAg PC9maWd1cmU+CgogICAgICAgIDx0PkluIGVmZmVjdCwgdGhpcyBwcm9jZXNzIG1vdmVzIHRoZSB0 b2tlbiBmcm9tIHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgU2VydmVyIChhcyBhIHNlbmRlciBv ZiB0aGUgb2JqZWN0KSB0byB0aGUgUmVzb3VyY2UgU2VydmVyIChyZWNpcGllbnQpLAogICAgICAg IHZpYSB0aGUgQ2xpZW50IGFzIHdlbGwgYXMgdGhlIFJlc291cmNlIE93bmVyICh0aGUgbGF0dGVy IGJlY2F1c2Ugb2YKICAgICAgICB0aGUgSFRUUCBtZWNoYW5pY3MgdW5kZXJseWluZyB0aGUgcHJv dG9jb2wpLiBTbyBhZ2FpbiB3ZSBoYXZlIGEgY2FzZQogICAgICAgIHdoZXJlIGFuIGFwcGxpY2F0 aW9uIG9iamVjdCBpcyB0cmFuc3BvcnRlZCB2aWEgdW50cnVzdGVkCiAgICAgICAgaW50ZXJtZWRp YXJpZXMuPC90PgoKICAgICAgICA8dD5UaGlzIGFwcGxpY2F0aW9uIGhhcyB0d28gZXNzZW50aWFs IHNlY3VyaXR5IHJlcXVpcmVtZW50czogSW50ZWdyaXR5CiAgICAgICAgYW5kIGRhdGEgb3JpZ2lu IGF1dGhlbnRpY2F0aW9uLiBJbnRlZ3JpdHkgcHJvdGVjdGlvbiBpcyByZXF1aXJlZCBzbwogICAg ICAgIHRoYXQgdGhlIFJlc291cmNlIE93bmVyIGFuZCB0aGUgQ2xpZW50IGNhbm5vdCBtb2RpZnkg dGhlIHBlcm1pc3Npb24KICAgICAgICBlbmNvZGVkIGluIHRoZSB0b2tlbi4gRGF0YSBvcmlnaW4g YXV0aGVudGljYXRpb24gaXMgcmVxdWlyZWQgc28gdGhhdAogICAgICAgIHRoZSBSZXNvdXJjZSBT ZXJ2ZXIgY2FuIHZlcmlmeSB0aGF0IHRoZSB0b2tlbiB3YXMgaXNzdWVkIGJ5IGEgdHJ1c3RlZAog ICAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyLiBDb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBt YXkgYWxzbyBiZSBuZWVkZWQsCiAgICAgICAgaWYgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGlz IGNvbmNlcm5lZCBhYm91dCB0aGUgdmlzaWJpbGl0eSBvZgogICAgICAgIHBlcm1pc3Npb25zIGlu Zm9ybWF0aW9uIHRvIHRoZSBSZXNvdXJjZSBPd25lciBvciBDbGllbnQuIEZvciBleGFtcGxlLAog ICAgICAgIHBlcm1pc3Npb25zIHJlbGF0ZWQgdG8gc29jaWFsIG5ldHdvcmtpbmcgbWlnaHQgYmUg Y29uc2lkZXJlZCBwcml2YXRlCiAgICAgICAgaW5mb3JtYXRpb24uIE5vdGUsIGhvd2V2ZXIsIHRo YXQgT0F1dGggYWxyZWFkeSByZXF1aXJlcyB0aGF0IHRoZQogICAgICAgIHVuZGVybHlpbmcgSFRU UCB0cmFuc2FjdGlvbnMgYmUgcHJvdGVjdGVkIGJ5IFRMUywgc28gY29uZmlkZW50aWFsaXR5CiAg ICAgICAgcHJvdGVjdGlvbiBpcyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5IGZvciB0aGlzIHVzZSBj YXNlLjwvdD4KCiAgICAgICAgPHQ+VGhlIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IG5l ZWRzIGFyZSBtZXQgYnkgdGhlIGJhc2ljCiAgICAgICAgcmVxdWlyZW1lbnRzIGZvciBzaWduZWQg YW5kIGVuY3J5cHRlZCBvYmplY3QgZm9ybWF0cywgd2hldGhlciB0aGUKICAgICAgICBzaWduaW5n IGFuZCBlbmNyeXB0aW9uIGFyZSBwcm92aWRlZCB1c2luZyBhc3ltbWV0cmljIG9yIHN5bW1ldHJp YwogICAgICAgIGNyeXB0b2dyYXBoeS4gVGhlIGNob2ljZSBvZiB3aGljaCBtZWNoYW5pc20gaXMg YXBwbGllZCB3aWxsIGRlcGVuZCBvbgogICAgICAgIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGUgdHdvIHNlcnZlcnMsIG5hbWVseSB3aGV0aGVyIHRoZXkgc2hhcmUgYQogICAgICAgIHN5bW1l dHJpYyBrZXkgb3Igb25seSBwdWJsaWMga2V5cy48L3Q+CgogICAgICAgIDx0PkF1dGhlbnRpY2F0 aW9uIHJlcXVpcmVtZW50cyB3aWxsIGFsc28gZGVwZW5kIG9uIGRlcGxveW1lbnQKICAgICAgICBj aGFyYWN0ZXJpc3RpY3MuIFdoZXJlIHRoZXJlIGlzIGEgcmVsYXRpdmVseSBzdHJvbmcgYmluZGlu ZyBiZXR3ZWVuCiAgICAgICAgdGhlIHJlc291cmNlIHNlcnZlciBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLCBpdCBtYXkgc3VmZmljZSBmb3IKICAgICAgICB0aGUgQXV0aG9yaXphdGlvbiBT ZXJ2ZXIgaXNzdWluZyBhIHRva2VuIHRvIGJlIGlkZW50aWZpZWQgYnkgdGhlIGtleQogICAgICAg IHVzZWQgdG8gc2lnbiB0aGUgdG9rZW4uIFRoaXMgcmVxdWlyZXMgdGhhdCB0aGUgcHJvdG9jb2wg Y2FycnkgZWl0aGVyIHRoZQogICAgICAgIHB1YmxpYyBrZXkgb2YgdGhlIEF1dGhvcml6YXRpb24g U2VydmVyIG9yIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBwdWJsaWMKICAgICAgICBvciBzeW1tZXRy aWMga2V5LiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJvdG9jb2wgZWxlbWVudCBpZGVudGlmeWluZyB0 aGUga2V5Cgl0byBiZSB1c2VkIGlzIHRoZSA8c3Bhbnggc3R5bGU9InZlcmIiPmNsaWVudF9pZDwv c3Bhbng+IHBhcmFtZXRlciB2YWx1ZS48L3Q+CgogICAgICAgIDx0PlRoZXJlIG1heSBhbHNvIGJl IG1vcmUgYWR2YW5jZWQgY2FzZXMsIHdoZXJlIHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgU2Vy dmVyJ3Mga2V5IGlzIG5vdCBrbm93biBpbiBhZHZhbmNlIHRvIHRoZSBSZXNvdXJjZSBTZXJ2ZXIu IFRoaXMgbWF5CiAgICAgICAgaGFwcGVuLCBmb3IgaW5zdGFuY2UsIGlmIGFuIGVudGl0eSBpbnN0 YW50aWF0ZWQgYSBjb2xsZWN0aW9uIG9mCiAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIChz YXkgZm9yIGxvYWQgYmFsYW5jaW5nKSwgZWFjaCBvZiB3aGljaCBoYXMgYW4KICAgICAgICBpbmRl cGVuZGVudCBrZXkgcGFpci4gSW4gdGhlc2UgY2FzZXMsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8g YWxzbwogICAgICAgIGluY2x1ZGUgYSBjZXJ0aWZpY2F0ZSBvciBjZXJ0aWZpY2F0ZSBjaGFpbiBm b3IgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIsIHNvIHRoYXQgdGhlIFJlc291cmNl IFNlcnZlciBjYW4gdmVyaWZ5IHRoYXQgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIg aXMgYW4gZW50aXR5IHRoYXQgaXQgdHJ1c3RzLjwvdD4KCiAgICAgICAgPHQ+VGhlIEhUVFAgdHJh bnNwb3J0IGZvciBPQXV0aCBpbXBvc2VzIGEgcGFydGljdWxhciBjb25zdHJhaW50IG9uIHRoZQog ICAgICAgIGVuY29kaW5nLiBJbiB0aGUgT0F1dGggcHJvdG9jb2wsIHRva2VucyBmcmVxdWVudGx5 IG5lZWQgdG8gYmUgcGFzc2VkCiAgICAgICAgYXMgcXVlcnkgcGFyYW1ldGVycyBpbiBIVFRQIFVS SXMgPHhyZWYgdGFyZ2V0PSJSRkMyNjE2Ii8+LCBhZnRlcgogICAgICAgIGhhdmluZyBiZWVuIGJh c2U2NHVybCBlbmNvZGVkIDx4cmVmIHRhcmdldD0iUkZDNDY0OCIvPi4gV2hpbGUgdGhlcmUgaXMK ICAgICAgICBubyBzcGVjaWZpZWQgbGltaXQgb24gdGhlIGxlbmd0aCBvZiBVUklzIChhbmQgdGh1 cyBvZiBxdWVyeQogICAgICAgIHBhcmFtZXRlcnMpLCBpbiBwcmFjdGljZSBVUklzIG9mIG1vcmUg dGhhbiAyMDQ4IGNoYXJhY3RlcnMgYXJlCiAgICAgICAgcmVqZWN0ZWQgYnkgc29tZSB1c2VyIGFn ZW50cywKCWFuZCBmb3Igc29tZSBtb2JpbGUgYnJvd3NlcnMsIHRoaXMgbGltaXQgaXMgZXZlbiBz bWFsbGVyLgoJU28gdGhpcyB1c2UgY2FzZSByZXF1aXJlcyB0aGF0IGEgSk9TRQogICAgICAgIG9i amVjdCBoYXZlIHN1ZmZpY2llbnRseSBzbWFsbCBzaXplIGV2ZW4gYWZ0ZXIgc2lnbmluZywgcG9z c2libHkKICAgICAgICBlbmNyeXB0aW5nLCB3aGlsZSBzdGlsbCBiZWluZyBzaW1wbGUgdG8gaW5j bHVkZSBpbiBhbiBIVFRQIFVSSSBxdWVyeQogICAgICAgIHBhcmFtZXRlci48L3Q+CgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiBhbmNob3I9ImZlZC1zZWN0aW9uIiB0aXRsZT0iRmVk ZXJhdGlvbiI+CiAgICAgICAgPHQ+VHdvIGZlZGVyYXRlZCBpZGVudGl0eSBwcm90b2NvbHMgaGF2 ZSBzaW1pbGFyIHJlcXVpcmVtZW50czo8L3Q+CgogICAgICAgIDx0PjxsaXN0IHN0eWxlPSJzeW1i b2xzIj4KCSAgICA8dD5UaGUgT3BlbklEIENvbm5lY3QgcHJvdG9jb2wgPHhyZWYgdGFyZ2V0PSJP cGVuSUQuTWVzc2FnZXMiLz4KCSAgICBpcyBhIHNpbXBsZSwgUkVTVC9KU09OLWJhc2VkCgkgICAg aWRlbnRpdHkgZmVkZXJhdGlvbiBwcm90b2NvbCBsYXllcmVkIG9uIE9BdXRoIDIuMC4KCSAgICBJ dCB1c2VzIHRoZSBKV1QgYW5kIEpPU0UgZm9ybWF0cyBib3RoCiAgICAgICAgICAgIHRvIHJlcHJl c2VudCBzZWN1cml0eSB0b2tlbnMgYW5kIHRvIHByb3ZpZGUgc2VjdXJpdHkgZm9yIG90aGVyCiAg ICAgICAgICAgIHByb3RvY29sIG1lc3NhZ2VzIChwZXJmb3JtaW5nIHNpZ25pbmcgYW5kIG9wdGlv bmFsbHkgZW5jcnlwdGlvbikuCgkgICAgT3BlbklEIENvbm5lY3QgbmVnb3RpYXRlcyB0aGUgYWxn b3JpdGhtcyB0byBiZSB1c2VkIGFuZCBkaXN0cmlidXRlcwoJICAgIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBrZXlzIHRvIGJlIHVzZWQgdXNpbmcgcHJvdG9jb2wgZWxlbWVudHMKCSAgICB0aGF0IGFy ZSBub3QgcGFydCBvZiB0aGUgSldUIGFuZCBKT1NFIGhlYWRlciBwYXJhbWV0ZXJzLjwvdD4KCgkg ICAgPHQ+VGhlIE1vemlsbGEgUGVyc29uYSA8eHJlZiB0YXJnZXQ9IlBlcnNvbmEiLz4gc3lzdGVt IGlzIGEgc2ltcGxlCgkgICAgc2luZ2xlLXNpZ24tb24gKFNTTykgcHJvdG9jb2wgdGhhdCB1c2Vz IEpXVHMgdGhhdCBhcmUgc2lnbmVkCgkgICAgSk9TRSBKV1Mgb2JqZWN0cyB0byByZXByZXNlbnQg aW5mb3JtYXRpb24gYWJvdXQgaWRlbnRpdGllcywKCSAgICBhcHBsaWNhdGlvbnMsIGFuZCBrZXlz IGZvciBwYXJ0aWNpcGF0aW5nIGVudGl0aWVzLgoJICAgIFBlcnNvbmEgZGlzdHJpYnV0ZXMgdGhl IGtleXMgdXNlZCBhcyBjbGFpbXMgaW4gSldUIG1lc3NhZ2VzCgkgICAgYW5kIG5vdCBieSB1c2lu ZyBKT1NFIGhlYWRlciBwYXJhbWV0ZXJzLgoJICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD48L3Q+ CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0ieG1wcC1zZWMiIHRpdGxl PSJYTVBQIj4KICAgICAgICA8dD5UaGUgRXh0ZW5zaWJsZSBNZXNzYWdpbmcgYW5kIFByZXNlbmNl IFByb3RvY29sIChYTVBQKSByb3V0ZXMKICAgICAgICBtZXNzYWdlcyBmcm9tIG9uZSBlbmQgY2xp ZW50IHRvIGFub3RoZXIgYnkgd2F5IG9mIFhNUFAgc2VydmVycyA8eHJlZgogICAgICAgIHRhcmdl dD0iUkZDNjEyMCIvPi4gVGhlcmUgYXJlIHR5cGljYWxseSB0d28gc2VydmVycyBpbnZvbHZlZCBp bgogICAgICAgIGRlbGl2ZXJpbmcgYW55IGdpdmVuIG1lc3NhZ2U6IFRoZSBmaXJzdCBjbGllbnQg KEFsaWNlKSBzZW5kcyBhIG1lc3NhZ2UKICAgICAgICBmb3IgYW5vdGhlciBjbGllbnQgKEIpIHRv IGhlciBzZXJ2ZXIgKEEpLiBTZXJ2ZXIgQSB1c2VzIEJvYidzIGlkZW50aXR5CiAgICAgICAgYW5k IHRoZSBETlMgdG8gbG9jYXRlIHRoZSBzZXJ2ZXIgZm9yIEJvYidzIGRvbWFpbiAoQiksIHRoZW4g ZGVsaXZlcnMKICAgICAgICB0aGUgbWVzc2FnZSB0byB0aGF0IHNlcnZlci4gU2VydmVyIEIgdGhl biByb3V0ZXMgdGhlIG1lc3NhZ2UgdG8KICAgICAgICBCb2IuPC90PgoKICAgICAgICA8ZmlndXJl IGFuY2hvcj0iZmlnLXhtcHAiIHRpdGxlPSJEZWxpdmVyaW5nIGFuIFhNUFAgbWVzc2FnZSI+CiAg ICAgICAgICA8YXJ0d29yaz48IVtDREFUQVsKICAgICAgICAgKy0tLS0tLS0rICAgKy0tLS0tLS0t LS0rICAgKy0tLS0tLS0tLS0rICAgKy0tLS0tKwogICAgICAgICB8IEFsaWNlIHwtLT58IFNlcnZl ciBBIHwtLT58IFNlcnZlciBCIHwtLT58IEJvYiB8CiAgICAgICAgICstLS0tLS0tKyAgICstLS0t LS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLStdXT48L2FydHdvcms+CiAgICAgICAgPC9m aWd1cmU+CgogICAgICAgIDx0PlRoZSB1bnRydXN0ZWQtaW50ZXJtZWRpYXJ5IHByb2JsZW1zIGFy ZSBlc3BlY2lhbGx5IGFjdXRlIGZvciBYTVBQCiAgICAgICAgYmVjYXVzZSBpbiBtYW55IGN1cnJl bnQgZGVwbG95bWVudHMsIHRoZSBob2xkZXIgb2YgYW4gWE1QUCBkb21haW4KICAgICAgICBvdXRz b3VyY2VzIHRoZSBvcGVyYXRpb24gb2YgdGhlIGRvbWFpbidzIHNlcnZlcnMgdG8gYSBkaWZmZXJl bnQKICAgICAgICBlbnRpdHkuIEluIHRoaXMgZW52aXJvbm1lbnQsIHRoZXJlIGlzIGEgY2xlYXIg cmlzayBvZiBleHBvc2luZyB0aGUKICAgICAgICBkb21haW4gaG9sZGVyJ3MgcHJpdmF0ZSBpbmZv cm1hdGlvbiB0byB0aGUgZG9tYWluIG9wZXJhdG9yLiBYTVBQCiAgICAgICAgYWxyZWFkeSBoYXMg YSBkZWZpbmVkIG1lY2hhbmlzbSBmb3IgZW5kLXRvLWVuZCBzZWN1cml0eSB1c2luZyBTL01JTUUs CiAgICAgICAgYnV0IGl0IGhhcyBmYWlsZWQgdG8gZ2FpbiB3aWRlc3ByZWFkIGRlcGxveW1lbnQg PHhyZWYKICAgICAgICB0YXJnZXQ9IlJGQzM5MjMiLz4sIGluIHBhcnQgYmVjYXVzZSBvZiBrZXkg bWFuYWdlbWVudCBjaGFsbGVuZ2VzIGFuZAogICAgICAgIGJlY2F1c2Ugb2YgdGhlIGRpZmZpY3Vs dHkgb2YgcHJvY2Vzc2luZyBTL01JTUUgb2JqZWN0cy48L3Q+CgogICAgICAgIDx0PlRoZSBYTVBQ IHdvcmtpbmcgZ3JvdXAgaXMgaW4gdGhlIHByb2Nlc3Mgb2YgZGV2ZWxvcGluZyBhIG5ldwogICAg ICAgIGVuZC10by1lbmQgZW5jcnlwdGlvbiBzeXN0ZW0gd2l0aCBhbiBlbmNvZGluZyBiYXNlZCBv biBKT1NFIGFuZCBhCiAgICAgICAgY2xlYXJlciBrZXkgbWFuYWdlbWVudCBzeXN0ZW0gPHhyZWYg dGFyZ2V0PSJJLUQubWlsbGVyLXhtcHAtZTJlIi8+LgogICAgICAgIFRoZSBwcm9jZXNzIG9mIHNl bmRpbmcgYW4gZW5jcnlwdGVkIG1lc3NhZ2UgaW4gdGhpcyBzeXN0ZW0gaW52b2x2ZXMKICAgICAg ICB0d28gc3RlcHM6IEZpcnN0LCB0aGUgc2VuZGVyIGdlbmVyYXRlcyBhIHN5bW1ldHJpYyBDb250 ZW50IEVuY3J5cHRpb24KICAgICAgICBLZXkgKENFSyksIGVuY3J5cHRzIHRoZSBtZXNzYWdlIGNv bnRlbnQsIGFuZCBzZW5kcyB0aGUgZW5jcnlwdGVkCiAgICAgICAgbWVzc2FnZSB0byB0aGUgZGVz aXJlZCBzZXQgb2YgcmVjaXBpZW50cy4gU2Vjb25kLCBlYWNoIHJlY2lwaWVudAogICAgICAgICJk aWFscyBiYWNrIiB0byB0aGUgc2VuZGVyLCBwcm92aWRpbmcgaGlzIHB1YmxpYyBrZXk7IHRoZSBz ZW5kZXIgdGhlbgogICAgICAgIHJlc3BvbmRzIHdpdGggdGhlIHJlbGV2YW50IENFSywgd3JhcHBl ZCB3aXRoIHRoZSByZWNpcGllbnQncyBwdWJsaWMKICAgICAgICBrZXkuPC90PgoKICAgICAgICA8 ZmlndXJlIGFuY2hvcj0iZmlnLXhtcHAtc2VjIiB0aXRsZT0iRGVsaXZlcmluZyBhIHNlY3VyZSBY TVBQIG1lc3NhZ2UiPgogICAgICAgICAgPGFydHdvcms+PCFbQ0RBVEFbCiAgICAgICAgICstLS0t LS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLSsKICAgICAgICAgfCBB bGljZSB8PC0+fCBTZXJ2ZXIgQSB8PC0+fCBTZXJ2ZXIgQiB8PC0+fCBCb2IgfAogICAgICAgICAr LS0tLS0tLSsgICArLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLSsgICArLS0tLS0rCiAgICAgICAg ICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgIHwKICAgICAgICAg ICAgIHwtLS0tLS0tLS0tLS1FbmNyeXB0ZWQtLW1lc3NhZ2UtLS0tLS0tLS0+fCAgCiAgICAgICAg ICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgIHwKICAgICAgICAg ICAgIHw8LS0tLS0tLS0tLS0tLS0tUHVibGljLWtleS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAgICAg ICB8LS0tLS0tLS0tLS0tLS0tV3JhcHBlZCBDRUstLS0tLS0tLS0tLS0tPnwKICAgICAgICAgICAg IHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgfF1dPjwvYXJ0d29yaz4K ICAgICAgICA8L2ZpZ3VyZT4KCiAgICAgICAgPHQ+VGhlIG1haW4gdGhpbmcgdGhhdCB0aGlzIHN5 c3RlbSByZXF1aXJlcyBmcm9tIHRoZSBKT1NFIGZvcm1hdHMgaXMKICAgICAgICBjb25maWRlbnRp YWxpdHkgcHJvdGVjdGlvbiB2aWEgY29udGVudCBlbmNyeXB0aW9uLCBwbHVzIGFuIGludGVncml0 eQogICAgICAgIGNoZWNrIHZpYSBhIE1BQyBkZXJpdmVkIGZyb20gdGhlIHNhbWUgc3ltbWV0cmlj IGtleS4gVGhlIHNlcGFyYXRpb24gb2YKICAgICAgICB0aGUga2V5IGV4Y2hhbmdlIGZyb20gdGhl IHRyYW5zbWlzc2lvbiBvZiB0aGUgZW5jcnlwdGVkIGNvbnRlbnQsCiAgICAgICAgaG93ZXZlciwg cmVxdWlyZXMgdGhhdCB0aGUgSk9TRSBlbmNyeXB0ZWQgb2JqZWN0IGZvcm1hdCBhbGxvdyB3cmFw cGVkCiAgICAgICAgc3ltbWV0cmljIGtleXMgdG8gYmUgY2FycmllZCBzZXBhcmF0ZWx5IGZyb20g dGhlIGVuY3J5cHRlZCBwYXlsb2FkLiBJbgogICAgICAgIGFkZGl0aW9uLCB0aGUgZW5jcnlwdGVk IG9iamVjdCB3aWxsIG5lZWQgdG8gaGF2ZSBhIHRhZyBmb3IgdGhlIGtleQogICAgICAgIHRoYXQg d2FzIHVzZWQgdG8gZW5jcnlwdCB0aGUgY29udGVudCwgc28gdGhhdCB0aGUgcmVjaXBpZW50IChC b2IpIGNhbgogICAgICAgIHByZXNlbnQgdGhlIHRhZyB0byB0aGUgc2VuZGVyIChBbGljZSkgd2hl biByZXF1ZXN0aW5nIHRoZSB3cmFwcGVkCiAgICAgICAga2V5LjwvdD4KCiAgICAgICAgPHQ+QW5v dGhlciBpbXBvcnRhbnQgZmVhdHVyZSBvZiBYTVBQIGlzIHRoYXQgaXQgYWxsb3dzIGZvciB0aGUK ICAgICAgICBzaW11bHRhbmVvdXMgZGVsaXZlcnkgb2YgYSBtZXNzYWdlIHRvIG11bHRpcGxlIHJl Y2lwaWVudHMuIEluIHRoZQogICAgICAgIGRpYWdyYW1zIGFib3ZlLCBTZXJ2ZXIgQSBjb3VsZCBk ZWxpdmVyIHRoZSBtZXNzYWdlIG5vdCBvbmx5IHRvIFNlcnZlcgogICAgICAgIEIgKGZvciBCb2Ip IGJ1dCBhbHNvIHRvIFNlcnZlcnMgQywgRCwgRSwgZXRjLiBmb3Igb3RoZXIgdXNlcnMuIEluIHN1 Y2gKICAgICAgICBjYXNlcywgdG8gYXZvaWQgdGhlIG11bHRpcGxlICJkaWFsIGJhY2siIHRyYW5z YWN0aW9ucyBpbXBsaWVkIGJ5IHRoZQogICAgICAgIGFib3ZlIG1lY2hhbmlzbSwgWE1QUCBzeXN0 ZW1zIHdpbGwgbGlrZWx5IGNhY2hlIHB1YmxpYyBrZXlzIGZvciBlbmQKICAgICAgICByZWNpcGll bnRzLCBzbyB0aGF0IHdyYXBwZWQga2V5cyBjYW4gYmUgc2VudCBhbG9uZyB3aXRoIGNvbnRlbnQg b24KICAgICAgICBmdXR1cmUgbWVzc2FnZXMuIFRoaXMgaW1wbGllcyB0aGF0IHRoZSBKT1NFIGVu Y3J5cHRlZCBvYmplY3QgZm9ybWF0CiAgICAgICAgbXVzdCBzdXBwb3J0IHRoZSBwcm92aXNpb24g b2YgbXVsdGlwbGUgdmVyc2lvbnMgb2YgdGhlIHNhbWUgd3JhcHBlZAogICAgICAgIENFSyAobXVj aCBhcyBhIENNUyBFbnZlbG9wZWREYXRhIHN0cnVjdHVyZSBjYW4gaW5jbHVkZSBtdWx0aXBsZQog ICAgICAgIFJlY2lwaWVudEluZm8gc3RydWN0dXJlcykuPC90PgoKCTx0PkEgcmVsYXRlZCBmZWF0 dXJlIG9mIFhNUFAgaXMgdGhhdCBpdCBhbGxvd3MgdGhlIG1lc3NhZ2UgYW5kIHRoZQoJa2V5IHVz ZWQgdG8gZGVjcnlwdCB0aGUgbWVzc2FnZSB0byBiZSBkZWxpdmVyZWQgc2VwYXJhdGVseS4KCVRo aXMgaXMgdXNlZCB0byBlbmNyeXB0IG1lc3NhZ2VzIGluIGEgcmVjaXBpZW50LWluZGVwZW5kZW50 IGZhc2hpb24KCXVzaW5nIGEgcmFuZG9tbHkgZ2VuZXJhdGVkIENvbnRlbnQgRW5jcnlwdGlvbiBL ZXkgKENFSykuCglUaGUgQ0VLIGlzIHRoZW4gZW5jcnlwdGVkIHRvIGluZGl2aWR1YWwgcmVjaXBp ZW50cywgYW5kIGRlbGl2ZXJlZAoJdG8gdGhvc2UgcmVjaXBpZW50cyBpbiBzZXBhcmF0ZSBtZXNz YWdlcy4KCVRoaXMgcmVxdWlyZW1lbnQgZnJvbSBYTVBQIG1vdGl2YXRlZCB0aGUgRGlyZWN0IEVu Y3J5cHRpb24KCWtleSBtYW5hZ2VtZW50IG1vZGUgb2YgdGhlIEpPU0UgZW5jcnlwdGVkIG9iamVj dCBmb3JtYXQgKEpXRSkuCgk8L3Q+CgogICAgICAgIDx0PkluIHRoZSBjdXJyZW50IGRyYWZ0IG9m IHRoZSBYTVBQIGVuZC10by1lbmQgc2VjdXJpdHkgc3lzdGVtLCBlYWNoCiAgICAgICAgcGFydHkg aXMgYXV0aGVudGljYXRlZCBieSB2aXJ0dWUgb2YgdGhlIG90aGVyIHBhcnR5J3MgdHJ1c3QgaW4g dGhlCiAgICAgICAgWE1QUCBtZXNzYWdlIHJvdXRpbmcgc3lzdGVtLiBUaGUgc2VuZGVyIGlzIGF1 dGhlbnRpY2F0ZWQgdG8gdGhlCiAgICAgICAgcmVjZWl2ZXIgYmVjYXVzZSBoZSBjYW4gcmVjZWl2 ZSBtZXNzYWdlcyBmb3IgdGhlIGlkZW50aWZpZXIgIkFsaWNlIgogICAgICAgIChpbiBwYXJ0aWN1 bGFyLCB0aGUgcmVxdWVzdCBmb3Igd3JhcHBlZCBrZXlzKSwgYW5kIGNhbiBvcmlnaW5hdGUKICAg ICAgICBtZXNzYWdlcyBmb3IgdGhhdCBpZGVudGlmaWVyICh0aGUgd3JhcHBlZCBrZXkpLiBMaWtl d2lzZSwgdGhlIHJlY2VpdmVyCiAgICAgICAgaXMgYXV0aGVudGljYXRlZCB0byB0aGUgc2VuZGVy IGJlY2F1c2UgaGUgcmVjZWl2ZWQgdGhlIG9yaWdpbmFsCiAgICAgICAgZW5jcnlwdGVkIG1lc3Nh Z2UgYW5kIG9yaWdpbmF0ZWQgdGhlIHJlcXVlc3QgZm9yIHdyYXBwZWQga2V5LiBTbyB0aGUKICAg ICAgICBhdXRoZW50aWNhdGlvbiBoZXJlIHJlcXVpcmVzIG5vdCBvbmx5IHRoYXQgWE1QUCByb3V0 aW5nIGJlIGRvbmUKICAgICAgICBwcm9wZXJseSwgYnV0IGFsc28gdGhhdCBUTFMgYmUgdXNlZCBv biBldmVyeSBob3AuIE1vcmVvdmVyLCBpdAogICAgICAgIHJlcXVpcmVzIHRoYXQgdGhlIFRMUyBj aGFubmVscyBoYXZlIHN0cm9uZyBhdXRoZW50aWNhdGlvbiwgc2luY2UgYSBtYW4KICAgICAgICBp biB0aGUgbWlkZGxlIG9uIGFueSBvZiB0aGUgdGhyZWUgaG9wcyBjYW4gbWFzcXVlcmFkZSBhcyBC b2IgYW5kCiAgICAgICAgb2J0YWluIHRoZSBrZXkgbWF0ZXJpYWwgZm9yIGFuIGVuY3J5cHRlZCBt ZXNzYWdlLjwvdD4KCiAgICAgICAgPHQ+QmVjYXVzZSB0aGlzIGF1dGhlbnRpY2F0aW9uIGlzIHF1 aXRlIHdlYWsgKGRlcGVuZGluZyBvbiB0aGUgdXNlIG9mCiAgICAgICAgdHJhbnNwb3J0LWxheWVy IHNlY3VyaXR5IG9uIHRocmVlIGhvcHMpIGFuZCB1bnZlcmlmaWFibGUgYnkgdGhlCiAgICAgICAg ZW5kcG9pbnRzLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBYTVBQIHdvcmtpbmcgZ3JvdXAgd2ls bCBpbnRlZ3JhdGUKICAgICAgICBzb21lIHNvcnQgb2YgY3JlZGVudGlhbHMgZm9yIGVuZCByZWNp cGllbnRzLCBpbiB3aGljaCBjYXNlIHRoZXJlIHdvdWxkCiAgICAgICAgbmVlZCB0byBiZSBhIHdh eSB0byBhc3NvY2lhdGUgdGhlc2UgY3JlZGVudGlhbHMgd2l0aCBKT1NFIG9iamVjdHMuPC90PgoK ICAgICAgICA8dD5GaW5hbGx5LCBpdCdzIHdvcnRoIG5vdGluZyB0aGF0IFhNUFAgaXMgYmFzZWQg b24gWE1MLCBub3QgSlNPTi4gU28KICAgICAgICBieSB1c2luZyBKT1NFLCBYTVBQIHdpbGwgYmUg Y2FycnlpbmcgSlNPTiBvYmplY3RzIHdpdGhpbiBYTUwuIEl0IGlzCiAgICAgICAgdGh1cyBhIGRl c2lyYWJsZSBwcm9wZXJ0eSBmb3IgSk9TRSBvYmplY3RzIHRvIGJlIGVuY29kZWQgaW4gc3VjaCBh IHdheQogICAgICAgIGFzIHRvIGJlIHNhZmUgZm9yIGluY2x1c2lvbiBpbiBYTUwuIE90aGVyd2lz ZSwgYW4gZXhwbGljaXQgQ0RBVEEKICAgICAgICBpbmRpY2F0aW9uIG11c3QgYmUgZ2l2ZW4gdG8g dGhlIHBhcnNlciB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIG5vdCB0bwogICAgICAgIGJlIHBhcnNl ZCBhcyBYTUwuIE9uZSB3YXkgdG8gbWVldCB0aGlzIHJlcXVpcmVtZW50IHdvdWxkIGJlIHRvIGFw cGx5CiAgICAgICAgYmFzZTY0dXJsIGVuY29kaW5nLCBidXQgZm9yIFhNUFAgbWVzc2FnZXMgb2Yg bWVkaXVtLXRvLWxhcmdlIHNpemUsCiAgICAgICAgdGhpcyBjb3VsZCBpbXBvc2UgYSBmYWlyIGRl Z3JlZSBvZiBvdmVyaGVhZC48L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIGFu Y2hvcj0iYWx0by1zZWMiIHRpdGxlPSJBTFRPIj4KICAgICAgICA8dD5BcHBsaWNhdGlvbi1MYXll ciBUcmFmZmljIE9wdGltaXphdGlvbiAoQUxUTykgaXMgYSBzeXN0ZW0gZm9yCiAgICAgICAgZGlz dHJpYnV0aW5nIG5ldHdvcmsgdG9wb2xvZ3kgaW5mb3JtYXRpb24gdG8gZW5kIGRldmljZXMsIHNv IHRoYXQKICAgICAgICB0aG9zZSBkZXZpY2VzIGNhbiBtb2RpZnkgdGhlaXIgYmVoYXZpb3IgdG8g aGF2ZSBhIGxvd2VyIGltcGFjdCBvbiB0aGUKICAgICAgICBuZXR3b3JrIDx4cmVmIHRhcmdldD0i SS1ELmlldGYtYWx0by1yZXFzIi8+LiBUaGUgQUxUTyBwcm90b2NvbAogICAgICAgIGRpc3RyaWJ1 dGVzIHRvcG9sb2d5IGluZm9ybWF0aW9uIGluIHRoZSBmb3JtIG9mIEpTT04gb2JqZWN0cyBjYXJy aWVkCiAgICAgICAgaW4gSFRUUCA8eHJlZiB0YXJnZXQ9IlJGQzI2MTYiLz48eHJlZgogICAgICAg IHRhcmdldD0iSS1ELmlldGYtYWx0by1wcm90b2NvbCIvPi4gVGhlIGJhc2ljIHZlcnNpb24gb2Yg QUxUTyBpcyBzaW1wbHkKICAgICAgICBhIGNsaWVudC1zZXJ2ZXIgcHJvdG9jb2wsIHNvIHNpbXBs ZSB1c2Ugb2YgSFRUUFMgc3VmZmljZXMgZm9yIHRoaXMKICAgICAgICBjYXNlIDx4cmVmIHRhcmdl dD0iUkZDMjgxOCIvPi4gSG93ZXZlciwgdGhlcmUgaXMgYmVnaW5uaW5nIHRvIGJlIHNvbWUKICAg ICAgICBkaXNjdXNzaW9uIG9mIHVzZSBjYXNlcyBmb3IgQUxUTyBpbiB3aGljaCB0aGVzZSBKU09O IG9iamVjdHMgd2lsbCBiZQogICAgICAgIGRpc3RyaWJ1dGVkIHRocm91Z2ggYSBjb2xsZWN0aW9u IG9mIGludGVybWVkaWF0ZSBzZXJ2ZXJzIGJlZm9yZQogICAgICAgIHJlYWNoaW5nIHRoZSBjbGll bnQsIHdoaWxlIHN0aWxsIHByZXNlcnZpbmcgdGhlIGFiaWxpdHkgb2YgdGhlIGNsaWVudAogICAg ICAgIHRvIGF1dGhlbnRpY2F0ZSB0aGUgb3JpZ2luYWwgc291cmNlIG9mIHRoZSBvYmplY3QuIEV2 ZW4gdGhlIGJhc2UgQUxUTwogICAgICAgIHByb3RvY29sIG5vdGVzIHRoYXQgIkFMVE8gY2xpZW50 cyBvYnRhaW5pbmcgQUxUTyBpbmZvcm1hdGlvbiBtdXN0IGJlCiAgICAgICAgYWJsZSB0byB2YWxp ZGF0ZSB0aGUgcmVjZWl2ZWQgQUxUTyBpbmZvcm1hdGlvbiB0byBlbnN1cmUgdGhhdCBpdCB3YXMK ICAgICAgICBnZW5lcmF0ZWQgYnkgYW4gYXBwcm9wcmlhdGUgQUxUTyBzZXJ2ZXIuIjwvdD4KCiAg ICAgICAgPHQ+SW4gdGhpcyBjYXNlLCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFyZSBzdHJh aWdodGZvcndhcmQuIEpPU0UKICAgICAgICBvYmplY3RzIGNhcnJ5aW5nIEFMVE8gcGF5bG9hZHMg d2lsbCBuZWVkIHRvIGJlYXIgZGlnaXRhbCBzaWduYXR1cmVzCiAgICAgICAgZnJvbSB0aGUgb3Jp Z2luYXRpbmcgc2VydmVycywgd2hpY2ggd2lsbCBiZSBib3VuZCB0byBjZXJ0aWZpY2F0ZXMKICAg ICAgICBhdHRlc3RpbmcgdG8gdGhlIGlkZW50aXRpZXMgb2YgdGhlIHNlcnZlcnMuIFRoZXJlIGlz IG5vIHJlcXVpcmVtZW50CiAgICAgICAgZm9yIGNvbmZpZGVudGlhbGl0eSBpbiB0aGlzIGNhc2Us IHNpbmNlIEFMVE8gaW5mb3JtYXRpb24gaXMgZ2VuZXJhbGx5CiAgICAgICAgcHVibGljLjwvdD4K CiAgICAgICAgPHQ+VGhlIG1vcmUgaW50ZXJlc3RpbmcgcXVlc3Rpb25zIGFyZSBlbmNvZGluZyBx dWVzdGlvbnMuIEFMVE8gb2JqZWN0cwogICAgICAgIGFyZSBsaWtlbHkgdG8gYmUgbXVjaCBsYXJn ZXIgdGhhbiBwYXlsb2FkcyBpbiB0aGUgdHdvIGNhc2VzIGFib3ZlLAogICAgICAgIHdpdGggc2l6 ZXMgb2YgdXAgdG8gc2V2ZXJhbCBtZWdhYnl0ZXMuIFByb2Nlc3Npbmcgb2Ygc3VjaCBsYXJnZQog ICAgICAgIG9iamVjdHMgY2FuIGJlIGRvbmUgbW9yZSBxdWlja2x5IGlmIGl0IGNhbiBiZSBkb25l IGluIGEgc2luZ2xlIHBhc3MsCiAgICAgICAgd2hpY2ggbWF5IGJlIHBvc3NpYmxlIGlmIEpPU0Ug b2JqZWN0cyByZXF1aXJlIHNwZWNpZmljIG9yZGVyaW5ncyBvZgogICAgICAgIGZpZWxkcyB3aXRo aW4gdGhlIEpTT04gc3RydWN0dXJlLjwvdD4KCiAgICAgICAgPHQ+SW4gYWRkaXRpb24sIGJlY2F1 c2UgQUxUTyBvYmplY3RzIGFyZSBhbHNvIGVuY29kZWQgYXMgSlNPTiwgdGhleQogICAgICAgIGFy ZSBhbHJlYWR5IHNhZmUgZm9yIGluY2x1c2lvbiBpbiBhIEpPU0Ugb2JqZWN0LiBTaWduZWQgSk9T RSBvYmplY3RzCiAgICAgICAgd2lsbCBsaWtlbHkgY2FycnkgdGhlIHNpZ25lZCBkYXRhIGluIGEg c3RyaW5nIGFsb25nc2lkZSB0aGUgc2lnbmF0dXJlLgogICAgICAgIEpTT04gb2JqZWN0cyBoYXZl IHRoZSBwcm9wZXJ0eSB0aGF0IHRoZXkgY2FuIGJlIHNhZmVseSBlbmNvZGVkIGluIEpTT04KICAg ICAgICBzdHJpbmdzLiBBbGwgdGhleSByZXF1aXJlIGlzIHRoYXQgdW5uZWNlc3Nhcnkgd2hpdGUg c3BhY2UgYmUgcmVtb3ZlZCwKICAgICAgICBhIG11Y2ggc2ltcGxlciB0cmFuc2Zvcm1hdGlvbiB0 aGFuLCBzYXkgYmFzZTY0dXJsIGVuY29kaW5nLiBUaGlzCiAgICAgICAgcmFpc2VzIHRoZSBxdWVz dGlvbiBvZiB3aGV0aGVyIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIG9wdGltaXplIHRoZQogICAg ICAgIEpPU0UgZW5jb2RpbmcgZm9yIGNlcnRhaW4gIkpTT04tc2FmZSIgY2FzZXMuPC90PgogICAg ICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiBhbmNob3I9ImF0b2NhLXNlYyIgdGl0bGU9IkVt ZXJnZW5jeSBBbGVydGluZyI+CiAgICAgICAgPHQ+RW1lcmdlbmN5IGFsZXJ0aW5nIGlzIGFuIGVt ZXJnaW5nIHVzZSBjYXNlIGZvciBJUCBuZXR3b3JrcyA8eHJlZgogICAgICAgIHRhcmdldD0iSS1E LmlldGYtYXRvY2EtcmVxdWlyZW1lbnRzIi8+LiBBbGVydGluZyBzeXN0ZW1zIGFsbG93CiAgICAg ICAgYXV0aG9yaXRpZXMgdG8gd2FybiB1c2VycyBvZiBpbXBlbmRpbmcgZGFuZ2VyIGJ5IHNlbmRp bmcgYWxlcnQKICAgICAgICBtZXNzYWdlcyB0byBjb25uZWN0ZWQgZGV2aWNlcy4gRm9yIGV4YW1w bGUsIGluIHRoZSBldmVudCBvZiBodXJyaWNhbmUKICAgICAgICBvciB0b3JuYWRvLCBhbGVydHMg bWlnaHQgYmUgc2VudCB0byBhbGwgZGV2aWNlcyBpbiB0aGUgcGF0aCBvZiB0aGUKICAgICAgICBz dG9ybS48L3Q+CgogICAgICAgIDx0PlRoZSBtb3N0IGNyaXRpY2FsIHNlY3VyaXR5IHJlcXVpcmVt ZW50IGZvciBhbGVydGluZyBzeXN0ZW1zIGlzIHRoYXQKICAgICAgICBpdCBtdXN0IG5vdCBiZSBw b3NzaWJsZSBmb3IgYW4gYXR0YWNrZXIgdG8gc2VuZCBmYWxzZSBhbGVydHMgdG8KICAgICAgICBk ZXZpY2VzLiBTdWNoIGEgY2FwYWJpbGl0eSB3b3VsZCBwb3RlbnRpYWxseSBhbGxvdyBhbiBhdHRh Y2tlciB0bwogICAgICAgIGNyZWF0ZSB3aWRlLXNwcmVhZCBwYW5pYy4gSW4gcHJhY3RpY2UsIGFs ZXJ0IHN5c3RlbXMgcHJldmVudCB0aGVzZQogICAgICAgIGF0dGFja3MgYm90aCBieSBjb250cm9s cyBvbiBzZW5kaW5nIG1lc3NhZ2VzIGF0IHBvaW50cyB3aGVyZSBhbGVydHMKICAgICAgICBhcmUg b3JpZ2luYXRlZCwgYXMgd2VsbCBhcyBieSBoYXZpbmcgcmVjaXBpZW50cyBvZiBhbGVydHMgdmVy aWZ5IHRoYXQKICAgICAgICB0aGUgYWxlcnQgd2FzIHNlbnQgYnkgYW4gYXV0aG9yaXplZCBzb3Vy Y2UuIFRoZSBmb3JtZXIgdHlwZSBvZiBjb250cm9sCiAgICAgICAgaW1wbGVtZW50ZWQgd2l0aCBs b2NhbCBzZWN1cml0eSBvbiBob3N0cyBmcm9tIHdoaWNoIGFsZXJ0cyBjYW4gYmUKICAgICAgICBv cmlnaW5hdGVkLiBUaGUgbGF0dGVyIHR5cGUgaW1wbGVtZW50ZWQgYnkgZGlnaXRhbCBzaWduYXR1 cmVzIG9uIGFsZXJ0CiAgICAgICAgbWVzc2FnZXMgKHVzaW5nIGNoYW5uZWwtYmFzZWQgb3Igb2Jq ZWN0LWJhc2VkIG1lY2hhbmlzbXMpLjwvdD4KCiAgICAgICAgPHQ+QWxlcnRzIHR5cGljYWxseSBy ZWFjaCBlbmQgcmVjaXBpZW50cyB2aWEgYSBzZXJpZXMgb2YKICAgICAgICBpbnRlcm1lZGlhcmll cy4gRm9yIGV4YW1wbGUsIHdoaWxlIGEgbmF0aW9uYWwgd2VhdGhlciBzZXJ2aWNlIG1pZ2h0CiAg ICAgICAgb3JpZ2luYXRlIGEgaHVycmljYW5lIGFsZXJ0LCBpdCBtaWdodCBmaXJzdCBiZSBkZWxp dmVyZWQgdG8gYSBuYXRpb25hbAogICAgICAgIGdhdGV3YXksIGFuZCB0aGVuIHRvIG5ldHdvcmsg b3BlcmF0b3JzLCB3aG8gYnJvYWRjYXN0IGl0IHRvIGVuZAogICAgICAgIHN1YnNjcmliZXJzLjwv dD4KCiAgICAgICAgPHQ+PGZpZ3VyZSBhbmNob3I9ImZpZy1hdG9jYS1zZWMiCiAgICAgICAgICAg IHRpdGxlPSJEZWxpdmVyaW5nIGFuIGVtZXJnZW5jeSBhbGVydCI+CiAgICAgICAgICAgIDxhcnR3 b3JrPjwhW0NEQVRBWyAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLSsgICAg Ky0tLS0tLS0tLS0tLSsKICAgICAgICB8IE9yaWdpbmF0b3IgfCAgICB8IE9yaWdpbmF0b3IgfCAg ICB8IE9yaWdpbmF0b3IgfAogICAgICAgICstLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0r ICAgICstLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgLiAgICAg ICAgICAgICAgICAgLiAgICAgICAKICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLi4u Li4uLi4uLi4uLi4uLi4uICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ViAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLSsgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICB8 IEdhdGV3YXkgfCAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg IFYgICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICAgIAogICAgICAgICAgICAgICst LS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAgICAgCiAgICAgICAgICAgICAg fCBOZXR3b3JrIHwgICAgICAgICAgICAgICB8IE5ldHdvcmsgfCAgICAgICAKICAgICAgICAgICAg ICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgIAogICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgCiAgICAgICAg ICAgICstLS0tLS0rLS0tLS0rICAgICAgICAgICAgKy0tLS0tLSstLS0tLSsgICAgICAKICAgICAg ICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgIAogICAg ICAgICAgICBWICAgICAgICAgICAgViAgICAgICAgICAgIFYgICAgICAgICAgICBWICAgICAgCiAg ICAgICAgKy0tLS0tLS0tKyAgICstLS0tLS0tLSsgICArLS0tLS0tLS0rICAgKy0tLS0tLS0tKyAK ICAgICAgICB8IERldmljZSB8ICAgfCBEZXZpY2UgfCAgIHwgRGV2aWNlIHwgICB8IERldmljZSB8 IAogICAgICAgICstLS0tLS0tLSsgICArLS0tLS0tLS0rICAgKy0tLS0tLS0tKyAgICstLS0tLS0t LSsgCgpdXT48L2FydHdvcms+CiAgICAgICAgICA8L2ZpZ3VyZT48L3Q+CgogICAgICAgIDx0Pklu IG9yZGVyIHRvIHZlcmlmeSBhbGVydCBzaWduYXR1cmVzLCByZWNpcGllbnRzIG11c3QgYmUgcHJv dmlzaW9uZWQKICAgICAgICB3aXRoIHRoZSBwcm9wZXIgcHVibGljIGtleXMgZm9yIHRydXN0ZWQg YWxlcnQgYXV0aG9yaXRpZXMuIFRoaXMgdHJ1c3QKICAgICAgICBtYXkgYmUgInBpZWNlLXdpc2Ui IGFsb25nIHRoZSBwYXRoIHRoZSBhbGVydCB0YWtlcy4gRm9yIGV4YW1wbGUsIHRoZQogICAgICAg IGFsZXJ0IHJlbGF5cyBvcGVyYXRlZCBieSBuZXR3b3JrcyBtaWdodCBoYXZlIGEgZnVsbCBzZXQg b2YKICAgICAgICBjZXJ0aWZpY2F0ZXMgZm9yIGFsbCBhbGVydCBvcmlnaW5hdG9ycywgd2hpbGUg ZW5kIGRldmljZXMgbWF5IG9ubHkKICAgICAgICB0cnVzdCB0aGVpciBsb2NhbCBhbGVydCByZWxh eS4gT3IgZGV2aWNlcyBtaWdodCByZXF1aXJlIHRoYXQgYSBkZXZpY2UKICAgICAgICBiZSBzaWdu ZWQgYnkgYW4gYXV0aG9yaXplZCBvcmlnaW5hdG9yIGFuZCBieSBpdHMgbG9jYWwgbmV0d29yaydz CiAgICAgICAgcmVsYXkuPC90PgoKICAgICAgICA8dD5UaGlzIHNjZW5hcmlvIGNyZWF0ZXMgYSBu ZWVkIGZvciBtdWx0aXBsZSBzaWduYXR1cmVzIG9uIGFsZXJ0CiAgICAgICAgZG9jdW1lbnRzLCBz byB0aGF0IGFuIGFsZXJ0IGNhbiBiZWFyIHNpZ25hdHVyZXMgZnJvbSBhbnkgb3IgYWxsIG9mIHRo ZQogICAgICAgIGVudGl0aWVzIHRoYXQgcHJvY2Vzc2VkIGl0IGFsb25nIHRoZSBwYXRoLiBJbiBv cmRlciB0byBtaW5pbWl6ZQogICAgICAgIGNvbXBsZXhpdHksIHRoZXNlIHNpZ25hdHVyZXMgc2hv dWxkIGJlICJtb2R1bGFyIiwgaW4gdGhlIHNlbnNlIHRoYXQgYQogICAgICAgIG5ldyBzaWduYXR1 cmUgY2FuIGJlIGFkZGVkIHdpdGhvdXQgYSBuZWVkIHRvIGFsdGVyIG9yIHJlY29tcHV0ZQogICAg ICAgIHByZXZpb3VzIHNpZ25hdHVyZXMuPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2Vj dGlvbiBhbmNob3I9IndlYmNyeXB0by1zZWMiIHRpdGxlPSJXZWIgQ3J5cHRvZ3JhcGh5Ij4KICAg ICAgPHQ+VGhlIFczQyBXZWIgQ3J5cHRvZ3JhcGh5IEFQSSBkZWZpbmVzIGEgc3RhbmRhcmQgY3J5 cHRvZ3JhcGhpYyBBUEkgZm9yIHRoZQogICAgICBXZWIgPHhyZWYgdGFyZ2V0PSJXZWJDcnlwdG8i PjwveHJlZj4uICBJZiBhIGJyb3dzZXIgZXhwb3NlcyB0aGlzIEFQSSwgdGhlbiAKICAgICAgSmF2 YVNjcmlwdCBwcm92aWRlZCBhcyBwYXJ0IG9mIGEgV2ViIHBhZ2UgY2FuIGFzayB0aGUgYnJvd3Nl ciB0byBwZXJmb3JtIAogICAgICBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMsIHN1Y2ggYXMgZGln ZXN0LCBNQUMsIGVuY3J5cHRpb24sIG9yIGRpZ2l0YWwgc2lnbmluZy48L3Q+CgogICAgICA8dD5P bmUgb2YgdGhlIGtleSByZWFzb25zIHRvIGhhdmUgdGhlIGJyb3dzZXIgcGVyZm9ybSBjcnlwdG9n cmFwaGljIG9wZXJhdGlvbnMgIAogICAgICBpcyB0byBhdm9pZCBhbGxvd2luZyBKYXZhU2NyaXB0 IGNvZGUgdG8gYWNjZXNzIHRoZSBrZXlpbmcgbWF0ZXJpYWwgdXNlZCBmb3IgdGhlc2UKICAgICAg b3BlcmF0aW9ucy4gIEZvciBleGFtcGxlLCB0aGlzIHNlcGFyYXRpb24gd291bGQgcHJldmVudCBj b2RlIGluamVjdGVkIHRocm91Z2ggYQogICAgICBjcm9zcy1zaXRlIHNjcmlwdGluZyAoWFNTKSBh dHRhY2sgZnJvbSByZWFkaW5nIGFuZCBleGZpbHRyYXRpbmcga2V5cyBzdG9yZWQgCiAgICAgIHdp dGhpbiBhIGJyb3dzZXIuICBXaGlsZSB0aGUgbWFsaWNpb3VzIGNvZGUgY291bGQgc3RpbGwgdXNl IHRoZSBrZXkgd2hpbGUgcnVubmluZwogICAgICBpbiB0aGUgYnJvd3NlciwgdGhpcyB2dWxuZXJh YmlsaXR5IGNhbiBvbmx5IGJlIGV4ZXJjaXNlZCB3aGlsZSB0aGUgdnVsbmVyYWJsZQogICAgICBw YWdlIGlzIGFjdGl2ZSBpbiBhIHVzZXIncyBicm93c2VyLjwvdD4KCiAgICAgIDx0Pkhvd2V2ZXIs IHRoZSBXZWJDcnlwdG9ncmFwaHkgQVBJIGFsc28gcHJvdmlkZXMgYSBrZXkgZXhwb3J0IGZ1bmN0 aW9uYWxpdHksIAogICAgICB3aGljaCBjYW4gYWxsb3cgSmF2YVNjcmlwdCB0byBleHRyYWN0IGEg a2V5IGZyb20gdGhlIEFQSSBpbiB3cmFwcGVkIGZvcm0uICBGb3IKICAgICAgZXhhbXBsZSwgdGhl IEphdmFTY3JpcHQgbWlnaHQgcHJvdmlkZSBhIHB1YmxpYyBrZXkgZm9yIHdoaWNoIHRoZSBjb3Jy ZXNwb25kaW5nCiAgICAgIHByaXZhdGUga2V5IGlzIGhlbGQgYnkgYW5vdGhlciBkZXZpY2UuICBU aGUgd3JhcHBlZCBrZXkgcHJvdmlkZWQgYnkgdGhlIEFQSSAKICAgICAgY291bGQgdGhlbiBiZSB1 c2VkIHRvIHNhZmVseSB0cmFuc3BvcnQgdGhlIGtleSB0byB0aGUgbmV3IGRldmljZS4gIFdoaWxl IHRoaXMKICAgICAgY291bGQgcG90ZW50aWFsbHkgYWxsb3cgbWFsaWNpb3VzIGNvZGUgdG8gZXhw b3J0IGEga2V5LCB0aGUgbmVlZCBmb3IgYW4gZXhwbGljaXQKICAgICAgZXhwb3J0IG9wZXJhdGlv biBwcm92aWRlcyBhIGNvbnRyb2wgcG9pbnQsIGFsbG93aW5nIGZvciB1c2VyIG5vdGlmaWNhdGlv biBvcgogICAgICBjb25zZW50IHZlcmlmaWNhdGlvbi48L3Q+CgogICAgICA8dD5UaGUgV2ViIENy eXB0b2dyYXBoeSBBUEkgYWxzbyBhbGxvd3MgYnJvd3NlcnMgdG8gaW1wb3NlIGxpbWl0YXRpb25z IG9uIHRoZSAKICAgICAgdXNhZ2Ugb2YgdGhlIGtleXMgaXQgaGFuZGxlcy4gIEZvciBleGFtcGxl LCBhIHN5bW1ldHJpYyBrZXkgbWlnaHQgYmUgbWFya2VkIGFzIAogICAgICB1c2FibGUgb25seSBm b3IgZW5jcnlwdGlvbiwgYW5kIG5vdCBmb3IgTUFDLiAgV2hlbiBhIGtleSBpcyBleHBvcnRlZCBp biB3cmFwcGVkIAogICAgICBmb3JtLCB0aGVzZSBhdHRyaWJ1dGVzIHNob3VsZCBiZSBjYXJyaWVk IGFsb25nIHdpdGggaXQuPC90PgoKICAgICAgPHQ+VGhlIFdlYiBDcnlwdG9ncmFwaHkgQVBJIHRo dXMgcmVxdWlyZXMgZm9ybWF0cyB0byBleHByZXNzIHNldmVyYWwgZm9ybXMgb2YKICAgICAga2V5 cy4gIE9idmlvdXNseSwgdGhlIHB1YmxpYyBrZXkgZnJvbSBhbiBhc3ltbWV0cmljIGtleSBwYWly IGNhbiBiZSBmcmVlbHkgCiAgICAgIGltcG9ydGVkIHRvIGFuZCBleHBvcnRlZCBmcm9tIHRoZSBi cm93c2VyLCBzbyB0aGVyZSBuZWVkcyB0byBiZSBhIGZvcm1hdCBmb3IKICAgICAgcHVibGljIGtl eXMuICBUaGVyZSBpcyBhbHNvIGEgbmVlZCBmb3IgYSBmb3JtYXQgdG8gZXhwcmVzcyBwcml2YXRl IGtleXMgYW5kCiAgICAgIHN5bW1ldHJpYyBrZXlzLiAgRm9yIG5vbi1wdWJsaWMga2V5cywgdGhl IHByaW1hcnkgbmVlZCBpcyBmb3IgYSB3cmFwcGVkIGZvcm0sCiAgICAgIHdoZXJlIHRoZSBjb25m aWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBvZiB0aGUga2V5IGlzIGFzc3VyZWQgY3J5cHRvZ3Jh cGhpY2FsbHk7CiAgICAgIHRoZXNlIHByb3RlY3Rpb25zIHNob3VsZCBhbHNvIGFwcGx5IHRvIGFu eSBhdHRyaWJ1dGVzIG9mIHRoZSBrZXkuICBJdCBtYXkgYWxzbwogICAgICBiZSB1c2VmdWwgdG8g ZGVmaW5lIGEgZGlyZWN0LCB1bndyYXBwZWQgZm9ybWF0LCBmb3IgdXNlIHdpdGhpbiBhIHNlY3Vy aXR5IAogICAgICBib3VuZGFyeS48L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4K CiAgICA8c2VjdGlvbiBhbmNob3I9InJlcS1zZWMiIHRpdGxlPSJSZXF1aXJlbWVudHMiPgogICAg ICA8dD5UaGlzIHNlY3Rpb24gc3VtbWFyaXplcyB0aGUgcmVxdWlyZW1lbnRzIGZyb20gdGhlIGFi b3ZlIHVzZXMgY2FzZXMsIGFuZAogICAgICBsaXN0cyBmdXJ0aGVyIHJlcXVpcmVtZW50cyBub3Qg ZGlyZWN0bHkgZGVyaXZlZCBmcm9tIHRoZSBhYm92ZSB1c2UgY2FzZXMuCiAgICAgIFRoZXJlIGFy ZSBhbHNvIHNvbWUgY29uc3RyYWludHMgdGhhdCBhcmUgbm90IGhhcmQgcmVxdWlyZW1lbnRzLCBi dXQgd2hpY2gKICAgICAgYXJlIHN0aWxsIGRlc2lyYWJsZSBwcm9wZXJ0aWVzIGZvciB0aGUgSk9T RSBzeXN0ZW0gdG8gaGF2ZS48L3Q+CgogICAgICA8c2VjdGlvbiBhbmNob3I9ImZ1bmN0aW9uYWwt c2VjIiB0aXRsZT0iRnVuY3Rpb25hbCBSZXF1aXJlbWVudHMiPgogICAgICAgIDx0PjxsaXN0IHN0 eWxlPSJoYW5naW5nIj4KICAgICAgICAgIDx0IGhhbmdUZXh0PSJGMSI+RGVmaW5lIGZvcm1hdHMg Zm9yIHNlY3VyZSBvYmplY3RzIHRoYXQgcHJvdmlkZSB0aGUgZm9sbG93aW5nCiAgICAgICAgICBz ZWN1cml0eSBwcm9wZXJ0aWVzOgogICAgICAgICAgICA8bGlzdCBzdHlsZT0ic3ltYm9scyI+CiAg ICAgICAgICAgIDx0PkRpZ2l0YWwgc2lnbmF0dXJlIChpbnRlZ3JpdHkvYXV0aGVudGljYXRpb24g dW5kZXIgYW4gYXN5bW1ldHJpYyBrZXkgcGFpcik8L3Q+CiAgICAgICAgICAgIDx0Pk1lc3NhZ2Ug YXV0aGVudGljYXRpb24gKGludGVncml0eS9hdXRoZW50aWNhdGlvbiB1bmRlciBhIHN5bW1ldHJp YyBrZXkpPC90PgogICAgICAgICAgICA8dD5FbmNyeXB0aW9uPC90PgogICAgICAgICAgICA8dD5B dXRoZW50aWNhdGVkIGVuY3J5cHRpb248L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAg IFRoYXQgaXMsIHRoZSBzZWN1cmUgb2JqZWN0cyBkZWZpbmVkIGJ5IHRoaXMgd29ya2luZyBncm91 cCBzaG91bGQgcHJvdmlkZSAKICAgICAgICAgIGVxdWl2YWxlbnQgc2VjdXJpdHkgcHJvcGVydGll cyB0byB0aGUgQ01TIFNpZ25lZERhdGEsIEF1dGhlbnRpY2F0ZWREYXRhLCAKICAgICAgICAgIEVu dmVsb3BlZERhdGEsIGFuZCBBdXRoRW52ZWxvcGVkIGRhdGEgb2JqZWN0cyA8eHJlZiB0YXJnZXQ9 IlJGQzU2NTIiPjwveHJlZj4KICAgICAgICAgIDx4cmVmIHRhcmdldD0iUkZDNTA4MyI+PC94cmVm Pi48L3Q+CiAgICAgICAgICA8dCBoYW5nVGV4dD0iRjIiPkRlZmluZSBhIGZvcm1hdCBmb3IgcHVi bGljIGtleXMgYW5kIHByaXZhdGUga2V5cyBmb3IgCiAgICAgICAgICBhc3ltbWV0cmljIGNyeXB0 b2dyYXBoaWMgYWxnb3JpdGhtcywgd2l0aCBhc3NvY2lhdGVkIGF0dHJpYnV0ZXMsIGluY2x1ZGlu ZyBhCiAgICAgICAgICB3cmFwcGVkIGZvcm0gZm9yIHByaXZhdGUga2V5cy48L3Q+CiAgICAgICAg ICA8dCBoYW5nVGV4dD0iRjMiPkRlZmluZSBhIGZvcm1hdCBmb3Igc3ltbWV0cmljIGtleXMgd2l0 aCBhc3NvY2lhdGVkIGF0dHJpYnV0ZXMsCiAgICAgICAgICBhbGxvd2luZyBmb3IgYm90aCB3cmFw cGVkIGFuZCB1bndyYXBwZWQga2V5cy48L3Q+CiAgICAgICAgICA8dCBoYW5nVGV4dD0iRjQiPkRl ZmluZSBKU09OIHNlcmlhbGl6YXRpb25zIGZvciB0aGUgYWJvdmUgb2JqZWN0cy4gIEFuIG9iamVj dAogICAgICAgICAgaW4gdGhpcyBlbmNvZGluZyBtdXN0IGJlIHZhbGlkIGFjY29yZGluZyB0byB0 aGUgSlNPTiBBQk5GIHN5bnRheCAKICAgICAgICAgIDx4cmVmIHRhcmdldD0iUkZDNDYyNyI+PC94 cmVmPjwvdD4KICAgICAgICAgIDx0IGhhbmdUZXh0PSJGNSI+RGVmaW5lIGNvbXBhY3QsIFVSTC1z YWZlIHRleHQgc2VyaWFsaXphdGlvbnMgZm9yIHRoZSBhYm92ZSAKICAgICAgICAgIG9iamVjdHMu PC90PgogICAgICAgICAgPHQgaGFuZ1RleHQ9IkY2Ij5BbGxvdyBmb3IgYXR0cmlidXRlcyBhc3Nv Y2lhdGVkIHRvIHdyYXBwZWQga2V5cyB0byBiZSBib3VuZCAKICAgICAgICAgIHRvIHRoZW0gY3J5 cHRvZ3JhcGhpY2FsbHk8L3Q+CiAgICAgICAgICA8dCBoYW5nVGV4dD0iRjciPkFsbG93IGZvciB3 cmFwcGVkIGtleXMgdG8gYmUgc2VwYXJhdGVkIGZyb20gYSBzZWN1cmUgb2JqZWN0IAogICAgICAg ICAgdGhhdCB1c2VzIGEgc3ltbWV0cmljIGtleS4gIEluIHN1Y2ggY2FzZXMsIGNyeXB0b2dyYXBo aWMgY29tcG9uZW50cyBvZiB0aGUgCiAgICAgICAgICBzZWN1cmUgb2JqZWN0IG90aGVyIHRoYW4g dGhlIHdyYXBwZWQga2V5IChlLmcuLCBjaXBoZXJ0ZXh0LCBNQUMgdmFsdWVzKSBtdXN0CiAgICAg ICAgICBiZSBpbmRlcGVuZGVudCBvZiB0aGUgd3JhcHBlZCBmb3JtIG9mIHRoZSBrZXkuICBGb3Ig ZXhhbXBsZSwgaWYgYW4gZW5jcnlwdGVkCiAgICAgICAgICBvYmplY3QgaXMgcHJlcGFyZWQgZm9y IG11bHRpcGxlIHJlY2lwaWVudHMsIHRoZW4gb25seSB0aGUgd3JhcHBlZCBrZXkgbWF5IHZhcnks CiAgICAgICAgICBub3QgdGhlIGNpcGhlcnRleHQuPC90PgogICAgICAgIDwvbGlzdD48L3Q+CiAg ICAgIDwvc2VjdGlvbj4KICAgICAgCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0ic2VjLXJlcS1zZWMi IHRpdGxlPSJTZWN1cml0eSBSZXF1aXJlbWVudHMiPgogICAgICAgIDx0PjxsaXN0IHN0eWxlPSJo YW5naW5nIj4KICAgICAgICA8dCBoYW5nVGV4dD0iUzEiPlByb3ZpZGUga2V5IG1hbmFnZW1lbnQg ZnVuY3Rpb25zIGZvciBlcGhlbWVyYWwgc3ltbWV0cmljIGtleXMsCiAgICAgICAgaW5jbHVkaW5n IGVuY3J5cHRpb24ga2V5cyBhbmQgTUFDIGtleXMuICBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8g dXNlIGFueQogICAgICAgIG9mIHRoZSBrZXkgbWFuYWdlbWVudCB0ZWNobmlxdWVzIHByb3ZpZGVk IGluIENNUyA8eHJlZiB0YXJnZXQ9IlJGQzU2NTIiPjwveHJlZj46CiAgICAgICAgICA8bGlzdCBz dHlsZT0ic3ltYm9scyI+CiAgICAgICAgICAgIDx0PktleSB0cmFuc3BvcnQgKHdyYXBwaW5nIGZv ciBhIHB1YmxpYyBrZXkpPC90PgogICAgICAgICAgICA8dD5LZXkgZW5jaXBoZXJtZW50ICh3cmFw cGluZyBmb3IgYSBzeW1tZXRyaWMga2V5KTwvdD4KICAgICAgICAgICAgPHQ+S2V5IGFncmVlbWVu dCAod3JhcHBpbmcgZm9yIGEgREggcHVibGljIGtleSk8L3Q+CiAgICAgICAgICAgIDx0PlBhc3N3 b3JkLWJhc2VkIGVuY3J5cHRpb24gKHdyYXBwaW5nIHVuZGVyIGEgZGVyaXZlZCBrZXkpPC90Pgog ICAgICAgICAgPC9saXN0PgoJYXMgd2VsbCBhcyB0aGUgRGlyZWN0IEVuY3J5cHRpb24ga2V5IG1h bmFnZW1lbnQgdGVjaG5pcXVlLgogICAgICAgIDwvdD4KCiAgICAgICAgPHQgaGFuZ1RleHQ9IlMy Ij5Vc2UgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIGluIGEgbWFubmVyIGNvbXBhdGlibGUgd2l0 aAogICAgICAgIG1ham9yIHZhbGlkYXRpb24gcHJvY2Vzc2VzLiAgRm9yIGV4YW1wbGUsIGlmIGEg RklQUyBzdGFuZGFyZCBhbGxvd3MgCiAgICAgICAgYWxnb3JpdGhtIEEgdG8gYmUgdXNlZCBmb3Ig cHVycG9zZSBYIGJ1dCBub3QgcHVycG9zZSBZLCB0aGVuIEpPU0Ugc2hvdWxkCiAgICAgICAgbm90 IHJlY29tbWVuZCB1c2luZyBhbGdvcml0aG0gQSBmb3IgcHVycG9zZSBZLjwvdD4KICAgICAgICAK ICAgICAgICA8dCBoYW5nVGV4dD0iUzMiPlN1cHBvcnQgb3BlcmF0aW9uIHdpdGggb3Igd2l0aG91 dCBwcmUtbmVnb3RpYXRpb24uICAKICAgICAgICBJdCBtdXN0IGJlIHBvc3NpYmxlIHRvIGNyZWF0 ZSBvciBwcm9jZXNzIHNlY3VyZSBvYmplY3RzIHdpdGhvdXQKICAgICAgICBhbnkgY29uZmlndXJh dGlvbiBiZXlvbmQga2V5IHByb3Zpc2lvbmluZy4gIElmIGl0IGlzIHBvc3NpYmxlIHRvIG5lZ290 aWF0ZSAKICAgICAgICBwYXJhbWV0ZXJzIG91dCBvZiBiYW5kLCB0aGVuIGl0IG11c3QgYmUgcG9z c2libGUgdG8gc2lnbmFsIHRoYXQgcHJlLW5lZ290aWF0ZWQgCiAgICAgICAgcGFyYW1ldGVycyBh cmUgdG8gYmUgdXNlZC48L3Q+CiAgICAgICAgPC9saXN0PjwvdD4KICAgICAgPC9zZWN0aW9uPgoK ICAgICAgPHNlY3Rpb24gYW5jaG9yPSJkZXNpZGVyYXRhLXNlYyIgdGl0bGU9IkRlc2lkZXJhdGEi PgogICAgICAgIDx0PjxsaXN0IHN0eWxlPSJoYW5naW5nIj4KICAgICAgICAgIDx0IGhhbmdUZXh0 PSJEMSI+TWF4aW1pemUgY29tcGF0aWJpbGl0eSB3aXRoIHRoZSBXM0MgV2ViQ3J5cHRvIAogICAg ICAgICAgc3BlY2lmaWNhdGlvbnMsIGUuZy4sIGJ5IGNvb3JkaW5hdGluZyB3aXRoIHRoZSBXZWJD cnlwdG8gd29ya2luZyBncm91cAoJICByZXF1ZXN0aW5nIHRoYXQgdGhleSBzdXBwb3J0IHVzaW5n IHRoZSBhbGdvcml0aG1zIG5lZWRlZCBieSBKT1NFIGltcGxlbWVudGF0aW9ucywKCSAgYnkgc3Vn Z2VzdGluZyB0aGF0IHRoZXkgdXNlIEpPU0UgZGF0YSBmb3JtYXRzIHdoZXJlIHRoZXNlIG1ha2Ug c2Vuc2UsCgkgIGFuZCBieSBzdWdnZXN0aW5nIHRoYXQgdGhleSB1c2UgdGhlIHNhbWUgaWRlbnRp ZmllcnMgZm9yIGFsZ29yaXRobXMgYXMgSk9TRSwKCSAgaW4gY2FzZXMgd2hlcmUgdGhpcyBtYWtl cyBzZW5zZS48L3Q+CgogICAgICAgICAgPHQgaGFuZ1RleHQ9IkQyIj5Bdm9pZCBKU09OIGNhbm9u aWNhbGl6YXRpb24gdG8gdGhlIGV4dGVudCBwb3NzaWJsZS4KCSAgVGhhdCBpcywgYWxsIG90aGVy IHRoaW5ncyBiZWluZyBlcXVhbCwgdGVjaG5pcXVlcyB0aGF0IHJlbHkgCiAgICAgICAgICBvbiBm aXhpbmcgYSBzZXJpYWxpemF0aW9uIG9mIGFuIG9iamVjdCAoZS5nLiwgYnkgYmFzZTY0dXJsIGVu Y29kaW5nIGl0KSAKICAgICAgICAgIGFyZSBwcmVmZXJyZWQgb3ZlciB0aG9zZSB0aGF0IHJlcXVp cmUgY29udmVydGluZyBhbiBvYmplY3QgdG8gYSAKICAgICAgICAgIGNhbm9uaWNhbCBmb3JtLjwv dD4KICAgICAgICA8L2xpc3Q+PC90PgogICAgICA8L3NlY3Rpb24+CiAgICA8L3NlY3Rpb24+Cgog ICAgPHNlY3Rpb24gYW5jaG9yPSJpYW5hLXNlYyIgdGl0bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMi PgogICAgICA8dD5UaGlzIGRvY3VtZW50IG1ha2VzIG5vIHJlcXVlc3Qgb2YgSUFOQS48L3Q+CiAg ICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWMtY29ucy1zZWMiIHRpdGxlPSJT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyI+CiAgICAgIDx0PlRoZSBwcmltYXJ5IGZvY3VzIG9mIHRo aXMgZG9jdW1lbnQgaXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgYQogICAgICBKU09OLWJhc2VkIHNl Y3VyZSBvYmplY3QgZm9ybWF0LiBBdCB0aGUgbGV2ZWwgb2YgZ2VuZXJhbCBzZWN1cml0eQogICAg ICBjb25zaWRlcmF0aW9ucyBmb3Igb2JqZWN0LWJhc2VkIHNlY3VyaXR5IHRlY2hub2xvZ2llcywg dGhlIHNlY3VyaXR5CiAgICAgIGNvbnNpZGVyYXRpb25zIGZvciB0aGlzIGZvcm1hdCBhcmUgdGhl IHNhbWUgYXMgZm9yIENNUyA8eHJlZgogICAgICB0YXJnZXQ9IlJGQzU2NTIiLz4uIFRoZSBwcmlt YXJ5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgSk9TRSBmb3JtYXQgYW5kCiAgICAgIENNUyBpcyB0 aGF0IEpPU0UgaXMgYmFzZWQgb24gSlNPTiwgd2hpY2ggZG9lcyBub3QgaGF2ZSBhIGNhbm9uaWNh bAogICAgICByZXByZXNlbnRhdGlvbi4gVGhlIGxhY2sgb2YgYSBjYW5vbmljYWwgZm9ybSBtZWFu cyB0aGF0IGl0IGlzIGRpZmZpY3VsdAogICAgICB0byBkZXRlcm1pbmUgd2hldGhlciB0d28gSlNP TiBvYmplY3RzIHJlcHJlc2VudCB0aGUgc2FtZSBpbmZvcm1hdGlvbiwKICAgICAgd2hpY2ggY291 bGQgbGVhZCB0byB2dWxuZXJhYmlsaXRpZXMgaW4gc29tZSB1c2FnZXMgb2YgSk9TRS48L3Q+CiAg ICA8L3NlY3Rpb24+CiAgPC9taWRkbGU+CgogIDwhLS0gICoqKioqQkFDSyBNQVRURVIgKioqKiog LS0+CgogIDxiYWNrPgogICAgPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVuY2Vz Ij4KICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40NjI3LnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40 NjQ4LnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40OTQ5LnhtbCI/PgoKICAgICAgPD9yZmMg aW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy41MDgzLnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNv dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41NjUyLnhtbCI/PgoKICAg ICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4 bWwvcmVmZXJlbmNlLlJGQy42MTIwLnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDov L3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy42NzQ5Lnht bCI/PgogICAgICA8P3JmYyBpbmNsdWRlPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMv cmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjY3NTAueG1sIj8+CgogICAgICA8P3JmYyBpbmNsdWRl PSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkkt RC5pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLnhtbCI/PgogICAgICA8P3JmYyBpbmNsdWRl PSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkkt RC5pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi54bWwiPz4KICAgICAgPD9yZmMgaW5jbHVk ZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5J LUQuaWV0Zi1qb3NlLWpzb24td2ViLWtleS54bWwiPz4KICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQuaWV0 Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMueG1sIj8+CgogICAgICA8P3JmYyBpbmNsdWRlPSJo dHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkktRC5p ZXRmLWFsdG8tcHJvdG9jb2wueG1sIj8+CgogICAgICA8P3JmYyBpbmNsdWRlPSJodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkktRC5pZXRmLWFsdG8t cmVxcy54bWwiPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3Jn L3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmlldGYtYXRvY2EtcmVxdWlyZW1lbnRz LnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVi bGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi54 bWwiPz4KCiAgICAgIDwhLS0KICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJj ZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQubWlsbGVyLXhtcHAtZTJlLnht bCI/PgogICAgICAtLT4KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9J0ktRC5taWxsZXIteG1wcC1l MmUnPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5FbmQtdG8tRW5kIE9iamVjdCBF bmNyeXB0aW9uIGZvciB0aGUgRXh0ZW5zaWJsZSBNZXNzYWdpbmcgYW5kIFByZXNlbmNlIFByb3Rv Y29sIChYTVBQKTwvdGl0bGU+CiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSIiIGluaXRpYWxz PSJNIiBzdXJuYW1lPSJNaWxsZXIiIC8+CiAgICAgICAgICA8ZGF0ZSBtb250aD0nRmVicnVhcnkn IGRheT0nMTInIHllYXI9JzIwMTMnIC8+CiAgICAgIDwvZnJvbnQ+CiAgICAgIAogICAgICA8c2Vy aWVzSW5mbyBuYW1lPSdJbnRlcm5ldC1EcmFmdCcgdmFsdWU9J2RyYWZ0LW1pbGxlci14bXBwLWUy ZS0wNCcgLz4KICAgICAgPGZvcm1hdCB0eXBlPSdUWFQnCiAgICAgICAgICAgICAgdGFyZ2V0PSdo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taWxsZXIteG1wcC1lMmUt MDQudHh0JyAvPgogICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDw/cmZjIGluY2x1ZGU9Imh0dHA6 Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sMi9yZWZlcmVuY2UuVzNDLlJFQy14 bWwtMTk5OC54bWwiID8+CgogICAgICA8P3JmYyBpbmNsdWRlPSJodHRwOi8veG1sLnJlc291cmNl Lm9yZy9wdWJsaWMvcmZjL2JpYnhtbDQvcmVmZXJlbmNlLlczQy5DUi14bWxkc2lnLWNvcmUyLTIw MTIwMTI0LnhtbCIgPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9Imh0dHA6Ly94bWwucmVzb3VyY2Uu b3JnL3B1YmxpYy9yZmMvYmlieG1sNC9yZWZlcmVuY2UuVzNDLkNSLXhtbGVuYy1jb3JlMS0yMDEy MDMxMy54bWwiID8+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iV2ViQ3J5cHRvIj4KICAgICAg ICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+V2ViIENyeXB0b2dyYXBoeSBBUEk8L3RpdGxlPgog ICAgICAgICAgPGF1dGhvciBmdWxsbmFtZT0iIiBpbml0aWFscz0iUiIgc3VybmFtZT0iU2xlZXZp Ii8+CiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSIiIGluaXRpYWxzPSJEIiBzdXJuYW1lPSJE YWhsIi8+CiAgICAgICAgICA8ZGF0ZSBtb250aD0iSmFudWFyeSIgeWVhcj0iMjAxMyIvPgogICAg ICAgIDwvZnJvbnQ+CiAgICAgIDwvcmVmZXJlbmNlPgogICAgPC9yZWZlcmVuY2VzPgoKICAgIDxy ZWZlcmVuY2VzIHRpdGxlPSJJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIj4KICAgICAgPD9yZmMgaW5j bHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl LlJGQy41MjQ2LnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJj ZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41MzIyLnhtbCI/PgoKICAgICAg PD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwv cmVmZXJlbmNlLlJGQy41NzUxLnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3ht bC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yODE4LnhtbCI/ PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4zMjA3LnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0i aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4z OTIzLnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcv cHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40MzAxLnhtbCI/PgoKICAgICAgPD9yZmMg aW5jbHVkZT0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy4yNjE2LnhtbCI/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNv dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwyL3JlZmVyZW5jZS5PQVNJUy5zYW1sLWNvcmUtMi4w LW9zLnhtbCcgPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3Jn L3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmlldGYtb2F1dGgtc2FtbDItYmVhcmVy LnhtbCcgPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1 YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmlldGYtb2F1dGgtand0LWJlYXJlci54bWwn ID8+CgogICAgICA8P3JmYyBpbmNsdWRlPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMv cmZjL2JpYnhtbDIvcmVmZXJlbmNlLklUVS5YNjkwLjE5OTQueG1sIiA/PgoKICAgICAgPHJlZmVy ZW5jZSBhbmNob3I9IkNBUCI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPkNvbW1v biBBbGVydGluZyBQcm90b2NvbCB2MS4xPC90aXRsZT4KICAgICAgICAgIDxhdXRob3IgZnVsbG5h bWU9IiIgaW5pdGlhbHM9IkEiIHN1cm5hbWU9IkJvdHRlcmVsbCIvPgogICAgICAgICAgPGF1dGhv ciBpbml0aWFscz0iRS4iIHN1cm5hbWU9IkpvbmVzIi8+CiAgICAgICAgICA8ZGF0ZSBtb250aD0i T2N0b2JlciIgeWVhcj0iMjAwNSIvPgogICAgICAgIDwvZnJvbnQ+CiAgICAgIDwvcmVmZXJlbmNl PgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9Ik9wZW5JRC5NZXNzYWdlcyIKICAgICAgICAgICAg ICAgICB0YXJnZXQ9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3Nh Z2VzLTFfMC5odG1sIj4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+T3BlbklEIENv bm5lY3QgTWVzc2FnZXMgMS4wPC90aXRsZT4KCiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJO YXQgU2FraW11cmEiIGluaXRpYWxzPSJOLiIgc3VybmFtZT0iU2FraW11cmEiPgogICAgICAgICAg ICA8b3JnYW5pemF0aW9uIGFiYnJldj0iTlJJIj5Ob211cmEgUmVzZWFyY2ggSW5zdGl0dXRlLAog ICAgICAgICAgICBMdGQuPC9vcmdhbml6YXRpb24+CiAgICAgICAgICA8L2F1dGhvcj4KCiAgICAg ICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJKb2huIEJyYWRsZXkiIGluaXRpYWxzPSJKLiIgc3VybmFt ZT0iQnJhZGxleSI+CiAgICAgICAgICAgIDxvcmdhbml6YXRpb24gYWJicmV2PSJQaW5nIElkZW50 aXR5Ij5QaW5nIElkZW50aXR5PC9vcmdhbml6YXRpb24+CiAgICAgICAgICA8L2F1dGhvcj4KCiAg ICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJNaWNoYWVsIEIuIEpvbmVzIiBpbml0aWFscz0iTS5C LiIgc3VybmFtZT0iSm9uZXMiPgogICAgICAgICAgICA8b3JnYW5pemF0aW9uIGFiYnJldj0iTWlj cm9zb2Z0Ij5NaWNyb3NvZnQ8L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwvYXV0aG9yPgoKICAg ICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IkJyZW5vIGRlIE1lZGVpcm9zIiBpbml0aWFscz0iQi4i CiAgICAgICAgICAgICAgICAgIHN1cm5hbWU9ImRlIE1lZGVpcm9zIj4KICAgICAgICAgICAgPG9y Z2FuaXphdGlvbiBhYmJyZXY9Ikdvb2dsZSI+R29vZ2xlPC9vcmdhbml6YXRpb24+CiAgICAgICAg ICA8L2F1dGhvcj4KCiAgICAgICAgICA8YXV0aG9yIGZ1bGxuYW1lPSJDaHVjayBNb3J0aW1vcmUi IGluaXRpYWxzPSJDLiIgc3VybmFtZT0iTW9ydGltb3JlIj4KICAgICAgICAgICAgPG9yZ2FuaXph dGlvbiBhYmJyZXY9IlNhbGVzZm9yY2UiPlNhbGVzZm9yY2U8L29yZ2FuaXphdGlvbj4KICAgICAg ICAgIDwvYXV0aG9yPgoKICAgICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IkVkbXVuZCBKYXkiIGlu aXRpYWxzPSJFLiIgc3VybmFtZT0iSmF5Ij4KICAgICAgICAgICAgPG9yZ2FuaXphdGlvbiBhYmJy ZXY9IklsbHVtaWxhIj5JbGx1bWlsYTwvb3JnYW5pemF0aW9uPgogICAgICAgICAgPC9hdXRob3I+ CgogICAgICAgICAgPGRhdGUgZGF5PSIyNiIgbW9udGg9Ik1hcmNoIiB5ZWFyPSIyMDEzIi8+CiAg ICAgICAgPC9mcm9udD4KICAgICAgPC9yZWZlcmVuY2U+CgogICAgICA8cmVmZXJlbmNlIGFuY2hv cj0iV1MtRmVkZXJhdGlvbiIKICAgICAgICAgICAgICAgICB0YXJnZXQ9Imh0dHA6Ly9kb2NzLm9h c2lzLW9wZW4ub3JnL3dzZmVkL2ZlZGVyYXRpb24vdjEuMi9vcy93cy1mZWRlcmF0aW9uLTEuMi1z cGVjLW9zLmh0bWwiPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5PcGVuSUQgQ29u bmVjdCBNZXNzYWdlcyAxLjA8L3RpdGxlPgoKICAgICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IkNo cmlzIEthbGVyIiBpbml0aWFscz0iQy4iIHN1cm5hbWU9IkthbGVyIj4KICAgICAgICAgICAgPG9y Z2FuaXphdGlvbi8+CiAgICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAgICA8YXV0aG9yIGZ1bGxu YW1lPSJNaWNoYWVsIE1jSW50b3NoIiBpbml0aWFscz0iTS4iIHN1cm5hbWU9Ik1jSW50b3NoIj4K ICAgICAgICAgICAgPG9yZ2FuaXphdGlvbi8+CiAgICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAg ICA8YXV0aG9yIGZ1bGxuYW1lPSJNYXJjIEdvb2RuZXIiIGluaXRpYWxzPSJNLiIgc3VybmFtZT0i R29vZG5lciI+CiAgICAgICAgICAgIDxvcmdhbml6YXRpb24vPgogICAgICAgICAgPC9hdXRob3I+ CgogICAgICAgICAgPGF1dGhvciBmdWxsbmFtZT0iQW50aG9ueSBOYWRhbGluIiBpbml0aWFscz0i QS4iIHN1cm5hbWU9Ik5hZGFsaW4iPgogICAgICAgICAgICA8b3JnYW5pemF0aW9uLz4KICAgICAg ICAgIDwvYXV0aG9yPgoKICAgICAgICAgIDxkYXRlIGRheT0iMjIiIG1vbnRoPSJNYXkiIHllYXI9 IjIwMDkiLz4KICAgICAgICA8L2Zyb250PgogICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDxyZWZl cmVuY2UgYW5jaG9yPSJQZXJzb25hIj4KCTxmcm9udD4KCSAgPHRpdGxlPk1vemlsbGEgUGVyc29u YTwvdGl0bGU+CgoJICA8YXV0aG9yIGZ1bGxuYW1lPSJNb3ppbGxhIj4KCSAgICA8b3JnYW5pemF0 aW9uIGFiYnJldj0iTW96aWxsYSI+TW96aWxsYTwvb3JnYW5pemF0aW9uPgoJICA8L2F1dGhvcj4K CgkgIDxkYXRlIG1vbnRoPSJBcHJpbCIgeWVhcj0iMjAxMyIgLz4KCTwvZnJvbnQ+CgoJPGZvcm1h dCB0YXJnZXQ9Imh0dHBzOi8vZGV2ZWxvcGVyLm1vemlsbGEub3JnL2VuLVVTL2RvY3MvUGVyc29u YSIgdHlwZT0iSFRNTCIgLz4KICAgICAgPC9yZWZlcmVuY2U+CgogICAgPC9yZWZlcmVuY2VzPgoK ICAgIDxzZWN0aW9uIGFuY2hvcj0iYWNrLXNlYyIgdGl0bGU9IkFja25vd2xlZGdlbWVudHMiPgog ICAgICA8dD5UaGFua3MgdG8gTWF0dCBNaWxsZXIgZm9yIGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8g WE1QUCBlbmQtdG8tZW5kCiAgICAgIHNlY3VyaXR5IG1vZGVsLCBhbmQgdG8gTWlrZSBKb25lcyBm b3IgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byBzZWN1cml0eQogICAgICB0b2tlbnMgYW5kIFhN TCBzZWN1cml0eS4gIFRoYW5rcyB0byBNYXJrIFdhdHNvbiBmb3IgcmFpc2luZyB0aGUgbmVlZCBm b3IgCiAgICAgIHJlcHJlc2VudGluZyBzeW1tZXRyaWMga2V5cyBhbmQgYmluZGluZyBhdHRyaWJ1 dGVzIHRvIHRoZW0uPC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJEb2N1 bWVudCBIaXN0b3J5IiBhbmNob3I9Imhpc3Qtc2VjIj4KICAgICAgPHQ+CglbWyB0byBiZSByZW1v dmVkIGJ5IHRoZSBSRkMgZWRpdG9yIGJlZm9yZSBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgXV0KICAg ICAgPC90PgoKICAgICAgPHQ+CiAgICAgICAgLTAxCiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJv bHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFJlZmVyZW5jZWQgdGhlIEpXUywgSldFLCBK V0ssIGFuZCBKV0Egc3BlY2lmaWNhdGlvbnMKCSAgICBtYWtpbmcgdGhlICJzaWduZWQgb2JqZWN0 IGZvcm1hdCIsICJlbmNyeXB0ZWQgb2JqZWN0IGZvcm1hdCIsCgkgICAgImtleSBmb3JtYXQiLCBh bmQgYWxnb3JpdGhtcyByZXN1bHRpbmcgZnJvbSB0aGVzZSB1c2UgY2FzZXMgY29uY3JldGUuCiAg ICAgICAgICA8L3Q+CgkgIDx0PgoJICAgIEFkZGVkICJBcHBsaWNhdGlvbiBhbmQgUHJvdG9jb2wg UmVxdWlyZW1lbnRzIiBzZWN0aW9uLgoJICA8L3Q+CgkgIDx0PgoJICAgIEJyb2tlIGZvcm1lciBo dWdlICJTZWN1cml0eSBUb2tlbnMgYW5kIEF1dGhvcml6YXRpb24iIFVzZSBDYXNlIHNlY3Rpb24K CSAgICBpbnRvICJTZWN1cml0eSBUb2tlbnMiLCAiT0F1dGgiLCBhbmQgIkZlZGVyYXRpb24iIFVz ZSBDYXNlIHNlY3Rpb25zLgoJICA8L3Q+CgkgIDx0PgoJICAgIENpdGVkIE1vemlsbGEgUGVyc29u YSBhcyBhIHNpbmdsZS1zaWduLW9uIChTU08pIHN5c3RlbSB1c2luZyBKV1RzCgkgICAgYW5kIEpP U0UgZGF0YSBmb3JtYXRzLgoJICA8L3Q+CgkgIDx0PgoJICAgIFNwZWxsaW5nIGFuZCBncmFtbWFy IGNvcnJlY3Rpb25zLgoJICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CiAgICAgIDx0 PgogICAgICAgIC0wMAogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0 PgogICAgICAgICAgICBDcmVhdGVkIHRoZSBpbml0aWFsIElFVEYgZHJhZnQgYmFzZWQgdXBvbgog ICAgICAgICAgICBkcmFmdC1iYXJuZXMtam9zZS11c2UtY2FzZXMtMDEgd2l0aCBzb21lIGFkZGl0 aW9ucy4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4KICAgIDwvc2Vj dGlvbj4gICAgIAoKICA8L2JhY2s+CjwvcmZjPgo= --_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: text/plain; name="draft-ietf-jose-use-cases-00+Mike.txt" Content-Description: draft-ietf-jose-use-cases-00+Mike.txt Content-Disposition: attachment; filename="draft-ietf-jose-use-cases-00+Mike.txt"; size=51574; creation-date="Sun, 28 Apr 2013 07:57:14 GMT"; modification-date="Sun, 28 Apr 2013 07:57:14 GMT" Content-Transfer-Encoding: base64 CgoKSk9TRSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUi4gQmFybmVzCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQkJOIFRlY2hub2xvZ2llcwpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjgsIDIwMTMKRXhwaXJl czogT2N0b2JlciAzMCwgMjAxMwoKClVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIGZvciBKU09O IE9iamVjdCBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChKT1NFKQogICAgICAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi1qb3NlLXVzZS1jYXNlcy0wMQoKQWJzdHJhY3QKCiAgIE1hbnkgSW50ZXJu ZXQgYXBwbGljYXRpb25zIGhhdmUgYSBuZWVkIGZvciBvYmplY3QtYmFzZWQgc2VjdXJpdHkKICAg bWVjaGFuaXNtcyBpbiBhZGRpdGlvbiB0byBzZWN1cml0eSBtZWNoYW5pc21zIGF0IHRoZSBuZXR3 b3JrIGxheWVyIG9yCiAgIHRyYW5zcG9ydCBsYXllci4gIEluIHRoZSBwYXN0LCB0aGUgQ3J5cHRv Z3JhcGhpYyBNZXNzYWdlIFN5bnRheCBoYXMKICAgcHJvdmlkZWQgYSBiaW5hcnkgc2VjdXJlIG9i amVjdCBmb3JtYXQgYmFzZWQgb24gQVNOLjEuICBPdmVyIHRpbWUsCiAgIHRoZSB1c2Ugb2YgYmlu YXJ5IG9iamVjdCBlbmNvZGluZ3Mgc3VjaCBhcyBBU04uMSBoYXMgYmVlbiBvdmVydGFrZW4KICAg YnkgdGV4dC1iYXNlZCBlbmNvZGluZ3MsIGZvciBleGFtcGxlIEphdmFTY3JpcHQgT2JqZWN0IE5v dGF0aW9uLgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBzZXQgb2YgdXNlIGNhc2VzIGFuZCBy ZXF1aXJlbWVudHMgZm9yIGEKICAgc2VjdXJlIG9iamVjdCBmb3JtYXQgZW5jb2RlZCB1c2luZyBK YXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiwgZHJhd24KICAgZnJvbSBhIHZhcmlldHkgb2YgYXBw bGljYXRpb24gc2VjdXJpdHkgbWVjaGFuaXNtcyBjdXJyZW50bHkgaW4KICAgZGV2ZWxvcG1lbnQu CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRl ZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFu ZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMg aXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0 LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE9jdG9iZXIgMzAsIDIwMTMuCgpDb3B5cmlnaHQgTm90aWNl CgogICBDb3B5cmlnaHQgKGMpIDIwMTMgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRp ZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgog ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdz IExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6 Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9m CiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRv Y3VtZW50cwoKCgpCYXJuZXMgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIw MTMgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg IEpPU0UgVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTMKCgogICBjYXJlZnVs bHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJv bSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRl eHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92 aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQg aW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEu ICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMwogICAyLiAgRGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgMy4gIEJhc2ljIFJlcXVpcmVtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgIDQuICBBcHBsaWNh dGlvbiBhbmQgUHJvdG9jb2wgUmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NgogICA1LiAgVXNlIENhc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDYKICAgICA1LjEuICBTZWN1cml0eSBUb2tlbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgICAgNS4yLiAgT0F1dGggIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDUu My4gIEZlZGVyYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDkKICAgICA1LjQuICBYTVBQIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgNS41LiAgQUxUTyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgIDUuNi4gIEVtZXJn ZW5jeSBBbGVydGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMK ICAgICA1LjcuICBXZWIgQ3J5cHRvZ3JhcGh5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE0CiAgIDYuICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAgIDYuMS4gIEZ1bmN0aW9uYWwgUmVx dWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICA2LjIu ICBTZWN1cml0eSBSZXF1aXJlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE3CiAgICAgNi4zLiAgRGVzaWRlcmF0YSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgOC4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAg IDkuICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxOAogICAgIDkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICA5LjIuICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwCiAgIEFwcGVuZGl4 IEEuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyMgogICBBcHBlbmRpeCBCLiAgRG9jdW1lbnQgSGlzdG9yeSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjIKICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCgoKCgoKCgoKCgoKCgoKCgoKCkJh cm5lcyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAg ICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2Fz ZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMwoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIElu dGVybmV0IGFwcGxpY2F0aW9ucyByZXN0IG9uIHRoZSBsYXllcmVkIGFyY2hpdGVjdHVyZSBvZiB0 aGUKICAgSW50ZXJuZXQsIGFuZCB0YWtlIGFkdmFudGFnZSBvZiBzZWN1cml0eSBtZWNoYW5pc21z IGF0IGFsbCBsYXllcnMuCiAgIE1hbnkgYXBwbGljYXRpb25zIHJlbHkgcHJpbWFyaWx5IG9uIGNo YW5uZWwtYmFzZWQgc2VjdXJpdHkKICAgdGVjaG5vbG9naWVzLCB3aGljaCBjcmVhdGUgYSBzZWN1 cmUgY2hhbm5lbCBhdCB0aGUgSVAgbGF5ZXIgb3IKICAgdHJhbnNwb3J0IGxheWVyIG92ZXIgd2hp Y2ggYXBwbGljYXRpb24gZGF0YSBjYW4gZmxvdwogICBbUkZDNDMwMV1bUkZDNTI0Nl0uICBUaGVz ZSBtZWNoYW5pc21zLCBob3dldmVyLCBjYW5ub3QgcHJvdmlkZSBlbmQtCiAgIHRvLWVuZCBzZWN1 cml0eSBpbiBzb21lIGNhc2VzLiAgRm9yIGV4YW1wbGUsIGluIHByb3RvY29scyB3aXRoCiAgIGFw cGxpY2F0aW9uLWxheWVyIGludGVybWVkaWFyaWVzLCBjaGFubmVsLWJhc2VkIHNlY3VyaXR5IHBy b3RvY29scwogICB3b3VsZCBwcm90ZWN0IG1lc3NhZ2VzIGZyb20gYXR0YWNrZXJzIGJldHdlZW4g aW50ZXJtZWRpYXJpZXMsIGJ1dCBub3QKICAgZnJvbSB0aGUgaW50ZXJtZWRpYXJpZXMgdGhlbXNl bHZlcy4gIFRoZXNlIGNhc2VzIHJlcXVpcmUgb2JqZWN0LWJhc2VkCiAgIHNlY3VyaXR5IHRlY2hu b2xvZ2llcywgd2hpY2ggZW1iZWQgYXBwbGljYXRpb24gZGF0YSB3aXRoaW4gYSBzZWN1cmUKICAg b2JqZWN0IHRoYXQgY2FuIGJlIHNhZmVseSBoYW5kbGVkIGJ5IHVudHJ1c3RlZCBlbnRpdGllcy4K CiAgIFRoZSBtb3N0IHdlbGwta25vd24gZXhhbXBsZSBvZiBzdWNoIGEgcHJvdG9jb2wgdG9kYXkg aXMgdGhlIHVzZSBvZgogICBTZWN1cmUvTXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwgRXh0ZW5z aW9ucyAoUy9NSU1FKSBwcm90ZWN0aW9ucwogICB3aXRoaW4gdGhlIGVtYWlsIHN5c3RlbSBbUkZD NTc1MV1bUkZDNTMyMl0uICBBbiBlbWFpbCBtZXNzYWdlCiAgIHR5cGljYWxseSBwYXNzZXMgdGhy b3VnaCBhIHNlcmllcyBvZiBpbnRlcm1lZGlhdGUgTWFpbCBUcmFuc2ZlcgogICBBZ2VudHMgKE1U QXMpIGVuIHJvdXRlIHRvIGl0cyBkZXN0aW5hdGlvbi4gIFdoaWxlIHRoZXNlIE1UQXMgb2Z0ZW4K ICAgYXBwbHkgY2hhbm5lbC1iYXNlZCBzZWN1cml0eSBwcm90ZWN0aW9ucyB0byB0aGVpciBpbnRl cmFjdGlvbnMgKGUuZy4sCiAgIFtSRkMzMjA3XSksIHRoZXNlIHByb3RlY3Rpb25zIGRvIG5vdCBw cmV2ZW50IHRoZSBNVEFzIGZyb20KICAgaW50ZXJmZXJpbmcgd2l0aCB0aGUgbWVzc2FnZS4gIElu IG9yZGVyIHRvIHByb3ZpZGUgZW5kLXRvLWVuZAogICBzZWN1cml0eSBwcm90ZWN0aW9ucyBpbiB0 aGUgcHJlc2VuY2Ugb2YgdW50cnVzdGVkIE1UQXMsIG1haWwgdXNlcnMKICAgY2FuIHVzZSBTL01J TUUgdG8gZW1iZWQgbWVzc2FnZSBib2RpZXMgaW4gYSBzZWN1cmUgb2JqZWN0IGZvcm1hdCB0aGF0 CiAgIGNhbiBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgZGF0YSBvcmln aW4KICAgYXV0aGVudGljYXRpb24uCgogICBTL01JTUUgaXMgYmFzZWQgb24gdGhlIENyeXB0b2dy YXBoaWMgTWVzc2FnZSBTeW50YXggZm9yIHNlY3VyZQogICBvYmplY3RzIChDTVMpIFtSRkM1NjUy XS4gIENNUyBpcyBkZWZpbmVkIHVzaW5nIEFic3RyYWN0IFN5bnRheAogICBOb3RhdGlvbiAxIChB U04uMSkgYW5kIHRyYWRpdGlvbmFsbHkgZW5jb2RlZCB1c2luZyB0aGUgQVNOLjEKICAgRGlzdGlu Z3Vpc2hlZCBFbmNvZGluZyBSdWxlcyAoREVSKSwgd2hpY2ggZGVmaW5lIGEgYmluYXJ5IGVuY29k aW5nIG9mCiAgIHRoZSBwcm90ZWN0ZWQgbWVzc2FnZSBhbmQgYXNzb2NpYXRlZCBwYXJhbWV0ZXJz IFtJVFUuWDY5MC4xOTk0XS4gIEluCiAgIHJlY2VudCB5ZWFycywgdXNhZ2Ugb2YgQVNOLjEgaGFz IGRlY3JlYXNlZCAoYWxvbmcgd2l0aCBvdGhlciBiaW5hcnkKICAgZW5jb2RpbmdzIGZvciBnZW5l cmFsIG9iamVjdHMpLCB3aGlsZSBtb3JlIGFwcGxpY2F0aW9ucyBoYXZlIGNvbWUgdG8KICAgcmVs eSBvbiB0ZXh0LWJhc2VkIGZvcm1hdHMgc3VjaCBhcyB0aGUgRXh0ZW5zaWJsZSBNYXJrdXAgTGFu Z3VhZ2UKICAgKFhNTCkgb3IgdGhlIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKQog ICBbVzNDLlJFQy14bWwtMTk5OF1bUkZDNDYyN10uCgogICBNYW55IGN1cnJlbnQgYXBwbGljYXRp b25zIHRodXMgaGF2ZSBtdWNoIG1vcmUgcm9idXN0IHN1cHBvcnQgZm9yCiAgIHByb2Nlc3Npbmcg b2JqZWN0cyBpbiB0aGVzZSB0ZXh0LWJhc2VkIGZvcm1hdHMgdGhhbiBBU04uMSBvYmplY3RzOwog ICBpbmRlZWQsIG1hbnkgbGFjayB0aGUgYWJpbGl0eSB0byBwcm9jZXNzIEFTTi4xIG9iamVjdHMg YXQgYWxsLiAgVG8KICAgc2ltcGxpZnkgdGhlIGFkZGl0aW9uIG9mIG9iamVjdC1iYXNlZCBzZWN1 cml0eSBmZWF0dXJlcyB0byB0aGVzZQogICBhcHBsaWNhdGlvbnMsIHRoZSBJRVRGIEpTT04gT2Jq ZWN0IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24gKEpPU0UpCiAgIHdvcmtpbmcgZ3JvdXAgaGFzIGJl ZW4gY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBzZWN1cmUgb2JqZWN0IGZvcm1hdAogICBiYXNlZCBv biBKU09OLiAgV2hpbGUgdGhlIGJhc2ljIHJlcXVpcmVtZW50cyBmb3IgdGhpcyBvYmplY3QgZm9y bWF0CiAgIGFyZSBzdHJhaWdodGZvcndhcmQgLS0gbmFtZWx5LCBjb25maWRlbnRpYWxpdHkgYW5k IGludGVncml0eQogICBtZWNoYW5pc21zLCBlbmNvZGVkIGluIEpTT04gLS0gZGlzY3Vzc2lvbnMg aW4gdGhlIHdvcmtpbmcgZ3JvdXAKCgoKQmFybmVzICAgICAgICAgICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDMwLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICBKT1NFIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEz CgoKICAgaW5kaWNhdGVkIHRoYXQgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBob3BpbmcgdG8gdXNl IHRoZSBmb3JtYXRzCiAgIGRlZmluZWQgYnkgSk9TRSBoYXZlIGRpZmZlcmVudCByZXF1aXJlbWVu dHMuICBUaGlzIGRvY3VtZW50CiAgIHN1bW1hcml6ZXMgdGhlIHVzZSBjYXNlcyBmb3IgSk9TRSBl bnZpc2lvbmVkIGJ5IHRob3NlIHBvdGVudGlhbAogICBhcHBsaWNhdGlvbnMgYW5kIHRoZSByZXN1 bHRpbmcgcmVxdWlyZW1lbnRzIGZvciBzZWN1cml0eSBtZWNoYW5pc21zCiAgIGFuZCBvYmplY3Qg ZW5jb2RpbmdzLgoKICAgU29tZSBzeXN0ZW1zIHRoYXQgdXNlIFhNTCBoYXZlIHNwZWNpZmllZCB0 aGUgdXNlIG9mIFhNTC1iYXNlZAogICBzZWN1cml0eSBtZWNoYW5pc21zIGZvciBvYmplY3Qgc2Vj dXJpdHksIG5hbWVseSBYTUwgRGlnaXRhbAogICBTaWduYXR1cmVzIGFuZCBYTUwgRW5jcnlwdGlv bgogICBbVzNDLkNSLXhtbGRzaWctY29yZTItMjAxMjAxMjRdW1czQy5DUi14bWxlbmMtY29yZTEt MjAxMjAzMTNdLiAgVGhlc2UKICAgbWVjaGFuaXNtcyBhcmUgZGVmaW5lZCBmb3IgdXNlIHdpdGgg c2V2ZXJhbCBzZWN1cml0eSB0b2tlbiBzeXN0ZW1zCiAgIChlLmcuLCBTQU1MIFtPQVNJUy5zYW1s LWNvcmUtMi4wLW9zXSBhbmQgV1MtRmVkZXJhdGlvbgogICBbV1MtRmVkZXJhdGlvbl0pIGFuZCB0 aGUgQ0FQIGVtZXJnZW5jeSBhbGVydGluZyBmb3JtYXQgW0NBUF0uICBJbgogICBwcmFjdGljZSwg aG93ZXZlciwgWE1MLWJhc2VkIHNlY3VyZSBvYmplY3QgZm9ybWF0cyBpbnRyb2R1Y2Ugc2ltaWxh cgogICBsZXZlbHMgb2YgY29tcGxleGl0eSB0byBBU04uMSwgc28gZGV2ZWxvcGVycyB0aGF0IGxh Y2sgdGhlIHRvb2xzIG9yCiAgIG1vdGl2YXRpb24gdG8gaGFuZGxlIEFTTi4xIGFyZW4ndCBsaWtl bHkgdG8gdXNlIFhNTCBzZWN1cml0eSBlaXRoZXIuCiAgIFRoaXMgc2l0dWF0aW9uIG1vdGl2YXRl cyB0aGUgY3JlYXRpb24gb2YgYSBKU09OLWJhc2VkIHNlY3VyZSBvYmplY3QKICAgZm9ybWF0IHRo YXQgaXMgc2ltcGxlIGVub3VnaCB0byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0aGF0IGl0IGNhbiBi ZQogICBlYXNpbHkgYWRvcHRlZCBieSBkZXZlbG9wZXJzIHdpdGggbWluaW1hbCBlZmZvcnQgYW5k IHRvb2xzLgoKCjIuICBEZWZpbml0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBtYWtlcyBleHRlbnNp dmUgdXNlIG9mIHN0YW5kYXJkIHNlY3VyaXR5IHRlcm1pbm9sb2d5CiAgIFtSRkM0OTQ5XS4gIElu IGFkZGl0aW9uLCBiZWNhdXNlIHRoZSB1c2UgY2FzZXMgZm9yIEpPU0UgYW5kIENNUyBhcmUKICAg c2ltaWxhciwgd2Ugd2lsbCBzb21ldGltZXMgbWFrZSBhbmFsb2dpZXMgdG8gc29tZSBDTVMgY29u Y2VwdHMKICAgW1JGQzU2NTJdLgoKICAgVGhlIEpPU0Ugd29ya2luZyBncm91cCBjaGFydGVyIGNh bGxzIGZvciB0aGUgZ3JvdXAgdG8gZGVmaW5lIHRocmVlCiAgIGJhc2ljIEpTT04gb2JqZWN0IGZv cm1hdHM6CgogICAxLiAgQ29uZmlkZW50aWFsaXR5LXByb3RlY3RlZCBvYmplY3QgZm9ybWF0Cgog ICAyLiAgSW50ZWdyaXR5LXByb3RlY3RlZCBvYmplY3QgZm9ybWF0CgogICAzLiAgQSBmb3JtYXQg Zm9yIGV4cHJlc3Npbmcga2V5cwoKICAgSW4gdGhpcyBkb2N1bWVudCwgd2Ugd2lsbCByZWZlciB0 byB0aGVzZSBhcyB0aGUgInNpZ25lZCBvYmplY3QKICAgZm9ybWF0IiwgdGhlICJlbmNyeXB0ZWQg b2JqZWN0IGZvcm1hdCIsIGFuZCB0aGUgImtleSBmb3JtYXQiLAogICByZXNwZWN0aXZlbHkuICBU aGUgSk9TRSAic2lnbmVkIG9iamVjdCBmb3JtYXQiIGlzIEpTT04gV2ViIFNpZ25hdHVyZQogICAo SldTKSBbSS1ELmlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmVdLiAgVGhlIEpPU0UgImVuY3J5 cHRlZCBvYmplY3QKICAgZm9ybWF0IiBpcyBKU09OIFdlYiBFbmNyeXB0aW9uIChKV0UpCiAgIFtJ LUQuaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb25dLiAgVGhlIEpPU0UgImtleSBmb3JtYXQi IGlzIEpTT04KICAgV2ViIEtleSAoSldTKSBbSS1ELmlldGYtam9zZS1qc29uLXdlYi1rZXldLiAg QWxnb3JpdGhtcyBhbmQgYWxnb3JpdGhtCiAgIGlkZW50aWZpZXJzIHVzZWQgYnkgSldTLCBKV0Us IGFuZCBKV0sgYXJlIGRlZmluZWQgaW4gSlNPTiBXZWIKICAgQWxnb3JpdGhtcyAoSldTKSBbSS1E LmlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zXS4KCiAgIEluIGdlbmVyYWwsIHdoZXJlIHRo ZXJlIGlzIG5vIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhc3ltbWV0cmljCgoKCkJhcm5l cyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAg ICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2FzZXMg ICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMwoKCiAgIGFuZCBzeW1tZXRyaWMgb3BlcmF0aW9u cywgd2Ugd2lsbCB1c2UgdGhlIHRlcm1zICJzaWduaW5nIiwKICAgInNpZ25hdHVyZSIsIGV0Yy4g dG8gZGVub3RlIGJvdGggdHJ1ZSBkaWdpdGFsIHNpZ25hdHVyZXMgaW52b2x2aW5nCiAgIGFzeW1t ZXRyaWMgY3J5cHRvZ3JhcGh5IGFzIHdlbGwgYXMgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2Rl cyB1c2luZwogICBzeW1tZXRyaWMga2V5cyAoTUFDcykuCgogICBJbiB0aGUgbGlmZXNwYW4gb2Yg YSBzZWN1cmUgb2JqZWN0LCB0aGVyZSBhcmUgdHdvIGJhc2ljIHJvbGVzLCBhbgogICBlbnRpdHkg dGhhdCBjcmVhdGVzIHRoZSBvYmplY3QgKGUuZy4sIGVuY3J5cHRpbmcgb3Igc2lnbmluZyBhCiAg IHBheWxvYWQpLCBhbmQgYW4gZW50aXR5IHRoYXQgdXNlcyB0aGUgb2JqZWN0IChkZWNyeXB0aW5n LCB2ZXJpZnlpbmcpLgogICBXZSB3aWxsIHJlZmVyIHRvIHRoZXNlIHJvbGVzIGFzICJzZW5kZXIi IGFuZCAicmVjaXBpZW50IiwKICAgcmVzcGVjdGl2ZWx5LiAgTm90ZSB0aGF0IHdoaWxlIHNvbWUg cmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgbWF5CiAgIHJlZmVyIHRvIHRoZXNlIGFzIHNpbmds ZSBlbnRpdGllcywgZWFjaCBvYmplY3QgbWF5IGhhdmUgbXVsdGlwbGUKICAgZW50aXRpZXMgaW4g ZWFjaCByb2xlLiAgRm9yIGV4YW1wbGUsIGEgbWVzc2FnZSBtYXkgYmUgc2lnbmVkIGJ5CiAgIG11 bHRpcGxlIHNlbmRlcnMsIG9yIGRlY3J5cHRlZCBieSBtdWx0aXBsZSByZWNpcGllbnRzLgoKCjMu ICBCYXNpYyBSZXF1aXJlbWVudHMKCiAgIE9idmlvdXNseSwgZm9yIHRoZSBlbmNyeXB0ZWQgYW5k IHNpZ25lZCBvYmplY3QgZm9ybWF0cywgdGhlIG5lY2Vzc2FyeQogICBwcm90ZWN0aW9ucyB3aWxs IGJlIGNyZWF0ZWQgdXNpbmcgYXBwcm9wcmlhdGUgY3J5cHRvZ3JhcGhpYwogICBtZWNoYW5pc21z OiBzeW1tZXRyaWMgb3IgYXN5bW1ldHJpYyBlbmNyeXB0aW9uIGZvciBjb25maWRlbnRpYWxpdHkK ICAgYW5kIE1BQ3Mgb3IgZGlnaXRhbCBzaWduYXR1cmVzIGZvciBpbnRlZ3JpdHkgcHJvdGVjdGlv bi4gIEluIGJvdGgKICAgY2FzZXMsIGl0IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIEpPU0UgZm9ybWF0 IHRvIHN1cHBvcnQgYm90aCBzeW1tZXRyaWMKICAgYW5kIGFzeW1tZXRyaWMgb3BlcmF0aW9ucy4K CiAgIG8gIFRoZSBKT1NFIGVuY3J5cHRlZCBvYmplY3QgZm9ybWF0IG11c3Qgc3VwcG9ydCBvYmpl Y3QgZW5jcnlwdGlvbiBpbgogICAgICB0aGUgY2FzZSB3aGVyZSB0aGUgc2VuZGVyIGFuZCByZWNl aXZlciBzaGFyZSBhIHN5bW1ldHJpYyBrZXkuCgogICBvICBUaGUgSk9TRSBlbmNyeXB0ZWQgb2Jq ZWN0IGZvcm1hdCBtdXN0IHN1cHBvcnQgb2JqZWN0IGVuY3J5cHRpb24gaW4KICAgICAgdGhlIGNh c2Ugd2hlcmUgdGhlIHNlbmRlciBoYXMgb25seSBhIHB1YmxpYyBrZXkgZm9yIHRoZSByZWNlaXZl ci4KCiAgIG8gIFRoZSBKT1NFIHNpZ25lZCBvYmplY3QgZm9ybWF0IG11c3Qgc3VwcG9ydCBpbnRl Z3JpdHkgcHJvdGVjdGlvbgogICAgICB1c2luZyBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGVz IChNQUNzKSwgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZQogICAgICBzZW5kZXIgYW5kIHJlY2VpdmVy IHNoYXJlIG9ubHkgYSBzeW1tZXRyaWMga2V5LgoKICAgbyAgVGhlIEpPU0Ugc2lnbmVkIG9iamVj dCBmb3JtYXQgbXVzdCBzdXBwb3J0IGludGVncml0eSBwcm90ZWN0aW9uCiAgICAgIHVzaW5nIGRp Z2l0YWwgc2lnbmF0dXJlcywgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZSByZWNlaXZlciBoYXMgb25s eQogICAgICBhIHB1YmxpYyBrZXkgZm9yIHRoZSBzZW5kZXIuCgogICBJbiBjYXNlcyB3aGVyZSB0 d28gZW50aXRpZXMgYXJlIGdvaW5nIHRvIGJlIGV4Y2hhbmdpbmcgc2V2ZXJhbCBKT1NFCiAgIG9i amVjdHMsIGl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gcHJlLW5lZ290aWF0ZSBzb21lIHBhcmFtZXRl cnMgc28gdGhhdAogICB0aGV5IGRvIG5vdCBoYXZlIHRvIGJlIHNpZ25hbGVkIGluIGV2ZXJ5IEpP U0Ugb2JqZWN0LiAgSG93ZXZlciwgc28gYXMKICAgbm90IHRvIGNvbmZ1c2UgZW5kcG9pbnRzIHRo YXQgZG8gbm90IHN1cHBvcnQgcHJlLW5lZ290aWF0aW9uLCBpdCBpcwogICB1c2VmdWwgdG8gc2ln bmFsIHdoZW4gcHJlLW5lZ290aWF0ZWQgcGFyYW1ldGVycyBhcmUgaW4gdXNlIGluIHRob3NlCiAg IGNhc2VzLgoKICAgbyAgSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGV4dGVuZCB0aGUgYmFzZSBK T1NFIHNpZ25lZCBhbmQgZW5jcnlwdGVkCiAgICAgIG9iamVjdCBmb3JtYXRzIHRvIGluZGljYXRl IHRoYXQgcHJlLW5lZ290aWF0ZWQgcGFyYW1ldGVycyBhcmUgdG8KICAgICAgYmUgdXNlZCB0byBw cm9jZXNzIHRoZSBvYmplY3QuICBUaGlzIGV4dGVuc2lvbiBzaG91bGQgYWxzbyBwcm92aWRlCgoK CkJhcm5lcyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAg ICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2Ug Q2FzZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMwoKCiAgICAgIGEgbWVhbnMgb2YgaW5k aWNhdGluZyBvZiB3aGljaCBwYXJhbWV0ZXJzIGFyZSB0byBiZSB1c2VkLgoKICAgVGhlIHB1cnBv c2Ugb2YgdGhlIGtleSBmb3JtYXQgaXMgdG8gcHJvdmlkZSB0aGUgcmVjaXBpZW50IHdpdGgKICAg c3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byB1c2UgdGhlIGVuY29kZWQga2V5IHRvIHByb2Nlc3MK ICAgY3J5cHRvZ3JhcGhpYyBtZXNzYWdlcy4gIFRodXMgaXQgaXMgc29tZXRpbWVzIG5lY2Vzc2Fy eSB0byBpbmNsdWRlCiAgIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBhbG9uZyB3aXRoIHRoZSBiYXJl IGtleS4KCiAgIG8gIFRoZSBKT1NFIGtleSBmb3JtYXQgbXVzdCBlbmFibGUgaW5jbHVzaW9uIG9m IGFsbCBhbGdvcml0aG0KICAgICAgcGFyYW1ldGVycyBuZWNlc3NhcnkgdG8gdXNlIHRoZSBlbmNv ZGVkIGtleSwgaW5jbHVkaW5nIGFuCiAgICAgIGlkZW50aWZpZXIgZm9yIHRoZSBhbGdvcml0aG0g d2l0aCB3aGljaCB0aGUga2V5IGlzIHVzZWQgYXMgd2VsbCBhcwogICAgICBhbnkgYWRkaXRpb25h bCBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IHRoZSBhbGdvcml0aG0gKGUuZy4sCiAgICAgIGVsbGlw dGljIGN1cnZlIHBhcmFtZXRlcnMpLgoKCjQuICBBcHBsaWNhdGlvbiBhbmQgUHJvdG9jb2wgUmVx dWlyZW1lbnRzCgogICBJdCBzaG91bGQgYmUgdW5kZXJzdG9vZCB0aGF0IHdoaWxlIEpPU0UgaXMg Y3JlYXRpbmcgZGF0YSBmb3JtYXRzLCBpdAogICBpcyBub3QgY3JlYXRpbmcgcHJvdG9jb2xzIG9y IGFwcGxpY2F0aW9ucy4gIFJhdGhlciwgdGhlIEpPU0UgZGF0YQogICBmb3JtYXRzIGFyZSBpbnRl bmRlZCB0byBiZSB1c2VkIGluIHByb3RvY29scyBhbmQgYnkgYXBwbGljYXRpb25zLgogICBUaGVz ZSBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB3aWxsIHNwZWNpZnkgYWRkaXRpb25hbCByZXF1 aXJlbWVudHMKICAgb24gdXNpbmcgdGhlIEpPU0UgZGF0YSBmb3JtYXRzIGluIHRob3NlIHBhcnRp Y3VsYXIgY29udGV4dHMuICBUaGVzZQogICBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB3aWxsIGlu Y2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86CgogICBvICByZXF1aXJlbWVudHMgb24gbWVz c2FnZSBjb250ZW50cywKCiAgIG8gIHJlcXVpcmVtZW50cyBvbiBhbGdvcml0aG1zIHVzZWQsCgog ICBvICByZXF1aXJlbWVudHMgb24ga2V5cyB1c2VkLAoKICAgbyAgcmVxdWlyZW1lbnRzIG9uIGtl eSBkaXN0cmlidXRpb24gbWV0aG9kcywgYW5kCgogICBvICByZXF1aXJlbWVudHMgb24ga2V5IHNl bGVjdGlvbiBtZXRob2RzLgoKCjUuICBVc2UgQ2FzZXMKCiAgIFNldmVyYWwgd29ya2luZyBncm91 cHMgZGV2ZWxvcGluZyBhcHBsaWNhdGlvbi1sYXllciBwcm90b2NvbHMgaGF2ZQogICBleHByZXNz ZWQgYSBkZXNpcmUgdG8gdXNlIHRoZSBKT1NFIGRhdGEgZm9ybWF0cyBpbiB0aGVpciBkZXNpZ25z IGZvcgogICBlbmQtdG8tZW5kIHNlY3VyaXR5IGZlYXR1cmVzLiAgSW4gdGhpcyBzZWN0aW9uLCB3 ZSBzdW1tYXJpemUgdGhlIHVzZQogICBjYXNlcyBwcm9wb3NlZCBieSB0aGVzZSBncm91cHMgYW5k IGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50cyB0aGF0IHRoZXkKICAgaW1wbHkgZm9yIHRoZSBKT1NF IG9iamVjdCBmb3JtYXRzLgoKNS4xLiAgU2VjdXJpdHkgVG9rZW5zCgogICBTZWN1cml0eSB0b2tl bnMgYXJlIGEgY29tbW9uIHVzZSBjYXNlIGZvciBvYmplY3QtYmFzZWQgc2VjdXJpdHksIGZvcgog ICBleGFtcGxlLCBTQU1MIGFzc2VydGlvbnMgW09BU0lTLnNhbWwtY29yZS0yLjAtb3NdLiAgU2Vj dXJpdHkgdG9rZW5zCiAgIGFyZSB1c2VkIHRvIGNvbnZleSBpbmZvcm1hdGlvbiBhYm91dCBhIHN1 YmplY3QgZW50aXR5ICgiY2xhaW1zIiBvcgogICAiYXNzZXJ0aW9ucyIpIGZyb20gYW4gaXNzdWVy IHRvIGEgcmVjaXBpZW50LiAgVGhlIHNlY3VyaXR5IGZlYXR1cmVzCgoKCkJhcm5lcyAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA2 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2FzZXMgICAgICAgICAg ICAgICAgICAgQXByaWwgMjAxMwoKCiAgIG9mIGEgdG9rZW4gZm9ybWF0IGVuYWJsZSB0aGUgcmVj aXBpZW50IHRvIHZlcmlmeSB0aGF0IHRoZSBjbGFpbXMgY2FtZQogICBmcm9tIHRoZSBpc3N1ZXIg YW5kLCBpZiB0aGUgb2JqZWN0IGlzIGNvbmZpZGVudGlhbGl0eS1wcm90ZWN0ZWQsIHRoYXQKICAg dGhleSB3ZXJlIG5vdCB2aXNpYmxlIHRvIG90aGVyIHBhcnRpZXMuCgogICBTZWN1cml0eSB0b2tl bnMgYXJlIHVzZWQgaW4gZmVkZXJhdGlvbiBwcm90b2NvbHMgc3VjaCBhcyBTQU1MIDIuMAogICBb T0FTSVMuc2FtbC1jb3JlLTIuMC1vc10sIFdTLUZlZGVyYXRpb24gW1dTLUZlZGVyYXRpb25dLCBN b3ppbGxhCiAgIFBlcnNvbmEgW1BlcnNvbmFdLCBhbmQgT3BlbklEIENvbm5lY3QgW09wZW5JRC5N ZXNzYWdlc10sIGFzIHdlbGwgYXMKICAgaW4gcmVzb3VyY2UgYXV0aG9yaXphdGlvbiBwcm90b2Nv bHMgc3VjaCBhcyBPQXV0aCAyLjAgW1JGQzY3NDldLAogICBpbmNsdWRpbmcgZm9yIE9BdXRoIGJl YXJlciB0b2tlbnMgW1JGQzY3NTBdLiAgSW4gc29tZSBjYXNlcywgc2VjdXJpdHkKICAgdG9rZW5z IGFyZSB1c2VkIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gYW5kIGZvciBhY2Nlc3MgY29udHJv bAogICBbSS1ELmlldGYtb2F1dGgtand0LWJlYXJlcl1bSS1ELmlldGYtb2F1dGgtc2FtbDItYmVh cmVyXS4KCiAgIEpTT04gV2ViIFRva2VuIChKV1QpIFtJLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbl0gaXMgYSBzZWN1cml0eQogICB0b2tlbiBmb3JtYXQgYmFzZWQgb24gSlNPTiBhbmQgSk9T RS4gIEl0IGlzIHVzZWQgd2l0aCBNb3ppbGxhCiAgIFBlcnNvbmEsIE9wZW5JRCBDb25uZWN0LCBh bmQgT0F1dGguICBCZWNhdXNlIEpXVHMgYXJlIG9mdGVuIHVzZWQgaW4KICAgY29udGV4dHMgd2l0 aCBsaW1pdGVkIHNwYWNlIChlLmcuLCBIVFRQIHF1ZXJ5IHBhcmFtZXRlcnMpLCBpdCBpcyBhCiAg IGNvcmUgcmVxdWlyZW1lbnQgZm9yIEpXVHMsIGFuZCB0aHVzIEpPU0UsIHRvIGhhdmUgYSBjb21w YWN0LCBVUkwtc2FmZQogICByZXByZXNlbnRhdGlvbi4KCjUuMi4gIE9BdXRoCgogICBUaGUgT0F1 dGggcHJvdG9jb2wgZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgZGlzdHJpYnV0aW5nIGFuZCB1c2lu ZwogICBhdXRob3JpemF0aW9uIHRva2VucyB1c2luZyBIVFRQIFtSRkM2NzQ5XS4gIEEgQ2xpZW50 IHRoYXQgd2lzaGVzIHRvCiAgIGFjY2VzcyBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBh dXRob3JpemF0aW9uIGZyb20gdGhlIFJlc291cmNlCiAgIE93bmVyLiAgSWYgdGhlIFJlc291cmNl IE93bmVyIGFsbG93cyB0aGlzIGFjY2VzcywgaGUgZGlyZWN0cyBhbgogICBBdXRob3JpemF0aW9u IFNlcnZlciB0byBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIENsaWVudC4gIFdoZW4KICAg dGhlIENsaWVudCB3aXNoZXMgdG8gYWNjZXNzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UsIGhlIHBy ZXNlbnRzIHRoZQogICB0b2tlbiB0byB0aGUgcmVsZXZhbnQgUmVzb3VyY2UgU2VydmVyLCB3aGlj aCB2ZXJpZmllcyB0aGUgdmFsaWRpdHkgb2YKICAgdGhlIHRva2VuIGJlZm9yZSBwcm92aWRpbmcg YWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpC YXJuZXMgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTMgICAgICAgICAg ICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEpPU0UgVXNlIENh c2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTMKCgogICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICB8ICAgUmVzb3VyY2UgICAgfDwuLi4uLi4uLj58IEF1dGhvcml6YXRpb24gfAogICAgICAg ICAgICAgICAgIHwgICAgU2VydmVyICAgICB8ICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8CiAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLXwt LSsgICAgICAgICAgKy0tfC0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8ICAgICAgICAgIHwgICBSZXNvdXJjZSAgICB8CiAgICAgICAgICAgICAgICAg fCAgICAgQ2xpZW50ICAgIHwgICAgICAgICAgfCAgICAgT3duZXIgICAgIHwKICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCgog ICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogVGhlIE9BdXRoIHByb2Nlc3MKCiAgIElu IGVmZmVjdCwgdGhpcyBwcm9jZXNzIG1vdmVzIHRoZSB0b2tlbiBmcm9tIHRoZSBBdXRob3JpemF0 aW9uIFNlcnZlcgogICAoYXMgYSBzZW5kZXIgb2YgdGhlIG9iamVjdCkgdG8gdGhlIFJlc291cmNl IFNlcnZlciAocmVjaXBpZW50KSwgdmlhCiAgIHRoZSBDbGllbnQgYXMgd2VsbCBhcyB0aGUgUmVz b3VyY2UgT3duZXIgKHRoZSBsYXR0ZXIgYmVjYXVzZSBvZiB0aGUKICAgSFRUUCBtZWNoYW5pY3Mg dW5kZXJseWluZyB0aGUgcHJvdG9jb2wpLiAgU28gYWdhaW4gd2UgaGF2ZSBhIGNhc2UKICAgd2hl cmUgYW4gYXBwbGljYXRpb24gb2JqZWN0IGlzIHRyYW5zcG9ydGVkIHZpYSB1bnRydXN0ZWQKICAg aW50ZXJtZWRpYXJpZXMuCgogICBUaGlzIGFwcGxpY2F0aW9uIGhhcyB0d28gZXNzZW50aWFsIHNl Y3VyaXR5IHJlcXVpcmVtZW50czogSW50ZWdyaXR5CiAgIGFuZCBkYXRhIG9yaWdpbiBhdXRoZW50 aWNhdGlvbi4gIEludGVncml0eSBwcm90ZWN0aW9uIGlzIHJlcXVpcmVkIHNvCiAgIHRoYXQgdGhl IFJlc291cmNlIE93bmVyIGFuZCB0aGUgQ2xpZW50IGNhbm5vdCBtb2RpZnkgdGhlIHBlcm1pc3Np b24KICAgZW5jb2RlZCBpbiB0aGUgdG9rZW4uICBEYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbiBp cyByZXF1aXJlZCBzbyB0aGF0CiAgIHRoZSBSZXNvdXJjZSBTZXJ2ZXIgY2FuIHZlcmlmeSB0aGF0 IHRoZSB0b2tlbiB3YXMgaXNzdWVkIGJ5IGEgdHJ1c3RlZAogICBBdXRob3JpemF0aW9uIFNlcnZl ci4gIENvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIG1heSBhbHNvIGJlIG5lZWRlZCwKICAgaWYg dGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGlzIGNvbmNlcm5lZCBhYm91dCB0aGUgdmlzaWJpbGl0 eSBvZgogICBwZXJtaXNzaW9ucyBpbmZvcm1hdGlvbiB0byB0aGUgUmVzb3VyY2UgT3duZXIgb3Ig Q2xpZW50LiAgRm9yCiAgIGV4YW1wbGUsIHBlcm1pc3Npb25zIHJlbGF0ZWQgdG8gc29jaWFsIG5l dHdvcmtpbmcgbWlnaHQgYmUgY29uc2lkZXJlZAogICBwcml2YXRlIGluZm9ybWF0aW9uLiAgTm90 ZSwgaG93ZXZlciwgdGhhdCBPQXV0aCBhbHJlYWR5IHJlcXVpcmVzIHRoYXQKICAgdGhlIHVuZGVy bHlpbmcgSFRUUCB0cmFuc2FjdGlvbnMgYmUgcHJvdGVjdGVkIGJ5IFRMUywgc28KICAgY29uZmlk ZW50aWFsaXR5IHByb3RlY3Rpb24gaXMgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSBmb3IgdGhpcyB1 c2UKICAgY2FzZS4KCiAgIFRoZSBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBuZWVkcyBh cmUgbWV0IGJ5IHRoZSBiYXNpYwogICByZXF1aXJlbWVudHMgZm9yIHNpZ25lZCBhbmQgZW5jcnlw dGVkIG9iamVjdCBmb3JtYXRzLCB3aGV0aGVyIHRoZQogICBzaWduaW5nIGFuZCBlbmNyeXB0aW9u IGFyZSBwcm92aWRlZCB1c2luZyBhc3ltbWV0cmljIG9yIHN5bW1ldHJpYwogICBjcnlwdG9ncmFw aHkuICBUaGUgY2hvaWNlIG9mIHdoaWNoIG1lY2hhbmlzbSBpcyBhcHBsaWVkIHdpbGwgZGVwZW5k CiAgIG9uIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdHdvIHNlcnZlcnMsIG5hbWVseSB3 aGV0aGVyIHRoZXkKICAgc2hhcmUgYSBzeW1tZXRyaWMga2V5IG9yIG9ubHkgcHVibGljIGtleXMu CgoKCgpCYXJuZXMgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTMgICAg ICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEpPU0Ug VXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTMKCgogICBBdXRoZW50aWNhdGlv biByZXF1aXJlbWVudHMgd2lsbCBhbHNvIGRlcGVuZCBvbiBkZXBsb3ltZW50CiAgIGNoYXJhY3Rl cmlzdGljcy4gIFdoZXJlIHRoZXJlIGlzIGEgcmVsYXRpdmVseSBzdHJvbmcgYmluZGluZyBiZXR3 ZWVuCiAgIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwg aXQgbWF5IHN1ZmZpY2UgZm9yCiAgIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBpc3N1aW5nIGEg dG9rZW4gdG8gYmUgaWRlbnRpZmllZCBieSB0aGUga2V5CiAgIHVzZWQgdG8gc2lnbiB0aGUgdG9r ZW4uICBUaGlzIHJlcXVpcmVzIHRoYXQgdGhlIHByb3RvY29sIGNhcnJ5IGVpdGhlcgogICB0aGUg cHVibGljIGtleSBvZiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgb3IgYW4gaWRlbnRpZmllciBm b3IgdGhlCiAgIHB1YmxpYyBvciBzeW1tZXRyaWMga2V5LiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJv dG9jb2wgZWxlbWVudAogICBpZGVudGlmeWluZyB0aGUga2V5IHRvIGJlIHVzZWQgaXMgdGhlICJj bGllbnRfaWQiIHBhcmFtZXRlciB2YWx1ZS4KCiAgIFRoZXJlIG1heSBhbHNvIGJlIG1vcmUgYWR2 YW5jZWQgY2FzZXMsIHdoZXJlIHRoZSBBdXRob3JpemF0aW9uCiAgIFNlcnZlcidzIGtleSBpcyBu b3Qga25vd24gaW4gYWR2YW5jZSB0byB0aGUgUmVzb3VyY2UgU2VydmVyLiAgVGhpcwogICBtYXkg aGFwcGVuLCBmb3IgaW5zdGFuY2UsIGlmIGFuIGVudGl0eSBpbnN0YW50aWF0ZWQgYSBjb2xsZWN0 aW9uIG9mCiAgIEF1dGhvcml6YXRpb24gU2VydmVycyAoc2F5IGZvciBsb2FkIGJhbGFuY2luZyks IGVhY2ggb2Ygd2hpY2ggaGFzIGFuCiAgIGluZGVwZW5kZW50IGtleSBwYWlyLiAgSW4gdGhlc2Ug Y2FzZXMsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8gYWxzbwogICBpbmNsdWRlIGEgY2VydGlmaWNh dGUgb3IgY2VydGlmaWNhdGUgY2hhaW4gZm9yIHRoZSBBdXRob3JpemF0aW9uCiAgIFNlcnZlciwg c28gdGhhdCB0aGUgUmVzb3VyY2UgU2VydmVyIGNhbiB2ZXJpZnkgdGhhdCB0aGUgQXV0aG9yaXph dGlvbgogICBTZXJ2ZXIgaXMgYW4gZW50aXR5IHRoYXQgaXQgdHJ1c3RzLgoKICAgVGhlIEhUVFAg dHJhbnNwb3J0IGZvciBPQXV0aCBpbXBvc2VzIGEgcGFydGljdWxhciBjb25zdHJhaW50IG9uIHRo ZQogICBlbmNvZGluZy4gIEluIHRoZSBPQXV0aCBwcm90b2NvbCwgdG9rZW5zIGZyZXF1ZW50bHkg bmVlZCB0byBiZSBwYXNzZWQKICAgYXMgcXVlcnkgcGFyYW1ldGVycyBpbiBIVFRQIFVSSXMgW1JG QzI2MTZdLCBhZnRlciBoYXZpbmcgYmVlbgogICBiYXNlNjR1cmwgZW5jb2RlZCBbUkZDNDY0OF0u ICBXaGlsZSB0aGVyZSBpcyBubyBzcGVjaWZpZWQgbGltaXQgb24KICAgdGhlIGxlbmd0aCBvZiBV UklzIChhbmQgdGh1cyBvZiBxdWVyeSBwYXJhbWV0ZXJzKSwgaW4gcHJhY3RpY2UgVVJJcwogICBv ZiBtb3JlIHRoYW4gMjA0OCBjaGFyYWN0ZXJzIGFyZSByZWplY3RlZCBieSBzb21lIHVzZXIgYWdl bnRzLCBhbmQKICAgZm9yIHNvbWUgbW9iaWxlIGJyb3dzZXJzLCB0aGlzIGxpbWl0IGlzIGV2ZW4g c21hbGxlci4gIFNvIHRoaXMgdXNlCiAgIGNhc2UgcmVxdWlyZXMgdGhhdCBhIEpPU0Ugb2JqZWN0 IGhhdmUgc3VmZmljaWVudGx5IHNtYWxsIHNpemUgZXZlbgogICBhZnRlciBzaWduaW5nLCBwb3Nz aWJseSBlbmNyeXB0aW5nLCB3aGlsZSBzdGlsbCBiZWluZyBzaW1wbGUgdG8KICAgaW5jbHVkZSBp biBhbiBIVFRQIFVSSSBxdWVyeSBwYXJhbWV0ZXIuCgo1LjMuICBGZWRlcmF0aW9uCgogICBUd28g ZmVkZXJhdGVkIGlkZW50aXR5IHByb3RvY29scyBoYXZlIHNpbWlsYXIgcmVxdWlyZW1lbnRzOgoK ICAgbyAgVGhlIE9wZW5JRCBDb25uZWN0IHByb3RvY29sIFtPcGVuSUQuTWVzc2FnZXNdIGlzIGEg c2ltcGxlLCBSRVNULwogICAgICBKU09OLWJhc2VkIGlkZW50aXR5IGZlZGVyYXRpb24gcHJvdG9j b2wgbGF5ZXJlZCBvbiBPQXV0aCAyLjAuICBJdAogICAgICB1c2VzIHRoZSBKV1QgYW5kIEpPU0Ug Zm9ybWF0cyBib3RoIHRvIHJlcHJlc2VudCBzZWN1cml0eSB0b2tlbnMKICAgICAgYW5kIHRvIHBy b3ZpZGUgc2VjdXJpdHkgZm9yIG90aGVyIHByb3RvY29sIG1lc3NhZ2VzIChwZXJmb3JtaW5nCiAg ICAgIHNpZ25pbmcgYW5kIG9wdGlvbmFsbHkgZW5jcnlwdGlvbikuICBPcGVuSUQgQ29ubmVjdCBu ZWdvdGlhdGVzIHRoZQogICAgICBhbGdvcml0aG1zIHRvIGJlIHVzZWQgYW5kIGRpc3RyaWJ1dGVz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBrZXlzCiAgICAgIHRvIGJlIHVzZWQgdXNpbmcgcHJvdG9j b2wgZWxlbWVudHMgdGhhdCBhcmUgbm90IHBhcnQgb2YgdGhlIEpXVAogICAgICBhbmQgSk9TRSBo ZWFkZXIgcGFyYW1ldGVycy4KCiAgIG8gIFRoZSBNb3ppbGxhIFBlcnNvbmEgW1BlcnNvbmFdIHN5 c3RlbSBpcyBhIHNpbXBsZSBzaW5nbGUtc2lnbi1vbgogICAgICAoU1NPKSBwcm90b2NvbCB0aGF0 IHVzZXMgSldUcyB0aGF0IGFyZSBzaWduZWQgSk9TRSBKV1Mgb2JqZWN0cyB0bwogICAgICByZXBy ZXNlbnQgaW5mb3JtYXRpb24gYWJvdXQgaWRlbnRpdGllcywgYXBwbGljYXRpb25zLCBhbmQga2V5 cyBmb3IKICAgICAgcGFydGljaXBhdGluZyBlbnRpdGllcy4gIFBlcnNvbmEgZGlzdHJpYnV0ZXMg dGhlIGtleXMgdXNlZCBhcwogICAgICBjbGFpbXMgaW4gSldUIG1lc3NhZ2VzIGFuZCBub3QgYnkg dXNpbmcgSk9TRSBoZWFkZXIgcGFyYW1ldGVycy4KCgoKCkJhcm5lcyAgICAgICAgICAgICAgICAg IEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2FzZXMgICAgICAgICAgICAgICAgICAg QXByaWwgMjAxMwoKCjUuNC4gIFhNUFAKCiAgIFRoZSBFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQg UHJlc2VuY2UgUHJvdG9jb2wgKFhNUFApIHJvdXRlcyBtZXNzYWdlcwogICBmcm9tIG9uZSBlbmQg Y2xpZW50IHRvIGFub3RoZXIgYnkgd2F5IG9mIFhNUFAgc2VydmVycyBbUkZDNjEyMF0uCiAgIFRo ZXJlIGFyZSB0eXBpY2FsbHkgdHdvIHNlcnZlcnMgaW52b2x2ZWQgaW4gZGVsaXZlcmluZyBhbnkg Z2l2ZW4KICAgbWVzc2FnZTogVGhlIGZpcnN0IGNsaWVudCAoQWxpY2UpIHNlbmRzIGEgbWVzc2Fn ZSBmb3IgYW5vdGhlciBjbGllbnQKICAgKEIpIHRvIGhlciBzZXJ2ZXIgKEEpLiAgU2VydmVyIEEg dXNlcyBCb2IncyBpZGVudGl0eSBhbmQgdGhlIEROUyB0bwogICBsb2NhdGUgdGhlIHNlcnZlciBm b3IgQm9iJ3MgZG9tYWluIChCKSwgdGhlbiBkZWxpdmVycyB0aGUgbWVzc2FnZSB0bwogICB0aGF0 IHNlcnZlci4gIFNlcnZlciBCIHRoZW4gcm91dGVzIHRoZSBtZXNzYWdlIHRvIEJvYi4KCiAgICAg ICAgICAgICstLS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLSsK ICAgICAgICAgICAgfCBBbGljZSB8LS0+fCBTZXJ2ZXIgQSB8LS0+fCBTZXJ2ZXIgQiB8LS0+fCBC b2IgfAogICAgICAgICAgICArLS0tLS0tLSsgICArLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLSsg ICArLS0tLS0rCgogICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IERlbGl2ZXJpbmcgYW4gWE1Q UCBtZXNzYWdlCgogICBUaGUgdW50cnVzdGVkLWludGVybWVkaWFyeSBwcm9ibGVtcyBhcmUgZXNw ZWNpYWxseSBhY3V0ZSBmb3IgWE1QUAogICBiZWNhdXNlIGluIG1hbnkgY3VycmVudCBkZXBsb3lt ZW50cywgdGhlIGhvbGRlciBvZiBhbiBYTVBQIGRvbWFpbgogICBvdXRzb3VyY2VzIHRoZSBvcGVy YXRpb24gb2YgdGhlIGRvbWFpbidzIHNlcnZlcnMgdG8gYSBkaWZmZXJlbnQKICAgZW50aXR5LiAg SW4gdGhpcyBlbnZpcm9ubWVudCwgdGhlcmUgaXMgYSBjbGVhciByaXNrIG9mIGV4cG9zaW5nIHRo ZQogICBkb21haW4gaG9sZGVyJ3MgcHJpdmF0ZSBpbmZvcm1hdGlvbiB0byB0aGUgZG9tYWluIG9w ZXJhdG9yLiAgWE1QUAogICBhbHJlYWR5IGhhcyBhIGRlZmluZWQgbWVjaGFuaXNtIGZvciBlbmQt dG8tZW5kIHNlY3VyaXR5IHVzaW5nIFMvTUlNRSwKICAgYnV0IGl0IGhhcyBmYWlsZWQgdG8gZ2Fp biB3aWRlc3ByZWFkIGRlcGxveW1lbnQgW1JGQzM5MjNdLCBpbiBwYXJ0CiAgIGJlY2F1c2Ugb2Yg a2V5IG1hbmFnZW1lbnQgY2hhbGxlbmdlcyBhbmQgYmVjYXVzZSBvZiB0aGUgZGlmZmljdWx0eSBv ZgogICBwcm9jZXNzaW5nIFMvTUlNRSBvYmplY3RzLgoKICAgVGhlIFhNUFAgd29ya2luZyBncm91 cCBpcyBpbiB0aGUgcHJvY2VzcyBvZiBkZXZlbG9waW5nIGEgbmV3IGVuZC10by0KICAgZW5kIGVu Y3J5cHRpb24gc3lzdGVtIHdpdGggYW4gZW5jb2RpbmcgYmFzZWQgb24gSk9TRSBhbmQgYSBjbGVh cmVyCiAgIGtleSBtYW5hZ2VtZW50IHN5c3RlbSBbSS1ELm1pbGxlci14bXBwLWUyZV0uICBUaGUg cHJvY2VzcyBvZiBzZW5kaW5nCiAgIGFuIGVuY3J5cHRlZCBtZXNzYWdlIGluIHRoaXMgc3lzdGVt IGludm9sdmVzIHR3byBzdGVwczogRmlyc3QsIHRoZQogICBzZW5kZXIgZ2VuZXJhdGVzIGEgc3lt bWV0cmljIENvbnRlbnQgRW5jcnlwdGlvbiBLZXkgKENFSyksIGVuY3J5cHRzCiAgIHRoZSBtZXNz YWdlIGNvbnRlbnQsIGFuZCBzZW5kcyB0aGUgZW5jcnlwdGVkIG1lc3NhZ2UgdG8gdGhlIGRlc2ly ZWQKICAgc2V0IG9mIHJlY2lwaWVudHMuICBTZWNvbmQsIGVhY2ggcmVjaXBpZW50ICJkaWFscyBi YWNrIiB0byB0aGUKICAgc2VuZGVyLCBwcm92aWRpbmcgaGlzIHB1YmxpYyBrZXk7IHRoZSBzZW5k ZXIgdGhlbiByZXNwb25kcyB3aXRoIHRoZQogICByZWxldmFudCBDRUssIHdyYXBwZWQgd2l0aCB0 aGUgcmVjaXBpZW50J3MgcHVibGljIGtleS4KCiAgICAgICAgICAgICstLS0tLS0tKyAgICstLS0t LS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLSsKICAgICAgICAgICAgfCBBbGljZSB8PC0+ fCBTZXJ2ZXIgQSB8PC0+fCBTZXJ2ZXIgQiB8PC0+fCBCb2IgfAogICAgICAgICAgICArLS0tLS0t LSsgICArLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLSsgICArLS0tLS0rCiAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgIHwtLS0tLS0tLS0tLS1FbmNyeXB0ZWQtLW1lc3NhZ2UtLS0tLS0tLS0+fAogICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLVB1YmxpYy1rZXktLS0tLS0tLS0tLS0tLXwKICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgfAogICAg ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLVdyYXBwZWQgQ0VLLS0tLS0tLS0tLS0tLT58CiAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgIHwK CiAgICAgICAgICAgICAgICBGaWd1cmUgMzogRGVsaXZlcmluZyBhIHNlY3VyZSBYTVBQIG1lc3Nh Z2UKCgoKQmFybmVzICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBKT1NF IFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEzCgoKICAgVGhlIG1haW4gdGhp bmcgdGhhdCB0aGlzIHN5c3RlbSByZXF1aXJlcyBmcm9tIHRoZSBKT1NFIGZvcm1hdHMgaXMKICAg Y29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gdmlhIGNvbnRlbnQgZW5jcnlwdGlvbiwgcGx1cyBh biBpbnRlZ3JpdHkKICAgY2hlY2sgdmlhIGEgTUFDIGRlcml2ZWQgZnJvbSB0aGUgc2FtZSBzeW1t ZXRyaWMga2V5LiAgVGhlIHNlcGFyYXRpb24KICAgb2YgdGhlIGtleSBleGNoYW5nZSBmcm9tIHRo ZSB0cmFuc21pc3Npb24gb2YgdGhlIGVuY3J5cHRlZCBjb250ZW50LAogICBob3dldmVyLCByZXF1 aXJlcyB0aGF0IHRoZSBKT1NFIGVuY3J5cHRlZCBvYmplY3QgZm9ybWF0IGFsbG93IHdyYXBwZWQK ICAgc3ltbWV0cmljIGtleXMgdG8gYmUgY2FycmllZCBzZXBhcmF0ZWx5IGZyb20gdGhlIGVuY3J5 cHRlZCBwYXlsb2FkLgogICBJbiBhZGRpdGlvbiwgdGhlIGVuY3J5cHRlZCBvYmplY3Qgd2lsbCBu ZWVkIHRvIGhhdmUgYSB0YWcgZm9yIHRoZSBrZXkKICAgdGhhdCB3YXMgdXNlZCB0byBlbmNyeXB0 IHRoZSBjb250ZW50LCBzbyB0aGF0IHRoZSByZWNpcGllbnQgKEJvYikgY2FuCiAgIHByZXNlbnQg dGhlIHRhZyB0byB0aGUgc2VuZGVyIChBbGljZSkgd2hlbiByZXF1ZXN0aW5nIHRoZSB3cmFwcGVk CiAgIGtleS4KCiAgIEFub3RoZXIgaW1wb3J0YW50IGZlYXR1cmUgb2YgWE1QUCBpcyB0aGF0IGl0 IGFsbG93cyBmb3IgdGhlCiAgIHNpbXVsdGFuZW91cyBkZWxpdmVyeSBvZiBhIG1lc3NhZ2UgdG8g bXVsdGlwbGUgcmVjaXBpZW50cy4gIEluIHRoZQogICBkaWFncmFtcyBhYm92ZSwgU2VydmVyIEEg Y291bGQgZGVsaXZlciB0aGUgbWVzc2FnZSBub3Qgb25seSB0byBTZXJ2ZXIKICAgQiAoZm9yIEJv YikgYnV0IGFsc28gdG8gU2VydmVycyBDLCBELCBFLCBldGMuIGZvciBvdGhlciB1c2Vycy4gIElu CiAgIHN1Y2ggY2FzZXMsIHRvIGF2b2lkIHRoZSBtdWx0aXBsZSAiZGlhbCBiYWNrIiB0cmFuc2Fj dGlvbnMgaW1wbGllZCBieQogICB0aGUgYWJvdmUgbWVjaGFuaXNtLCBYTVBQIHN5c3RlbXMgd2ls bCBsaWtlbHkgY2FjaGUgcHVibGljIGtleXMgZm9yCiAgIGVuZCByZWNpcGllbnRzLCBzbyB0aGF0 IHdyYXBwZWQga2V5cyBjYW4gYmUgc2VudCBhbG9uZyB3aXRoIGNvbnRlbnQKICAgb24gZnV0dXJl IG1lc3NhZ2VzLiAgVGhpcyBpbXBsaWVzIHRoYXQgdGhlIEpPU0UgZW5jcnlwdGVkIG9iamVjdAog ICBmb3JtYXQgbXVzdCBzdXBwb3J0IHRoZSBwcm92aXNpb24gb2YgbXVsdGlwbGUgdmVyc2lvbnMg b2YgdGhlIHNhbWUKICAgd3JhcHBlZCBDRUsgKG11Y2ggYXMgYSBDTVMgRW52ZWxvcGVkRGF0YSBz dHJ1Y3R1cmUgY2FuIGluY2x1ZGUKICAgbXVsdGlwbGUgUmVjaXBpZW50SW5mbyBzdHJ1Y3R1cmVz KS4KCiAgIEEgcmVsYXRlZCBmZWF0dXJlIG9mIFhNUFAgaXMgdGhhdCBpdCBhbGxvd3MgdGhlIG1l c3NhZ2UgYW5kIHRoZSBrZXkKICAgdXNlZCB0byBkZWNyeXB0IHRoZSBtZXNzYWdlIHRvIGJlIGRl bGl2ZXJlZCBzZXBhcmF0ZWx5LiAgVGhpcyBpcyB1c2VkCiAgIHRvIGVuY3J5cHQgbWVzc2FnZXMg aW4gYSByZWNpcGllbnQtaW5kZXBlbmRlbnQgZmFzaGlvbiB1c2luZyBhCiAgIHJhbmRvbWx5IGdl bmVyYXRlZCBDb250ZW50IEVuY3J5cHRpb24gS2V5IChDRUspLiAgVGhlIENFSyBpcyB0aGVuCiAg IGVuY3J5cHRlZCB0byBpbmRpdmlkdWFsIHJlY2lwaWVudHMsIGFuZCBkZWxpdmVyZWQgdG8gdGhv c2UgcmVjaXBpZW50cwogICBpbiBzZXBhcmF0ZSBtZXNzYWdlcy4gIFRoaXMgcmVxdWlyZW1lbnQg ZnJvbSBYTVBQIG1vdGl2YXRlZCB0aGUKICAgRGlyZWN0IEVuY3J5cHRpb24ga2V5IG1hbmFnZW1l bnQgbW9kZSBvZiB0aGUgSk9TRSBlbmNyeXB0ZWQgb2JqZWN0CiAgIGZvcm1hdCAoSldFKS4KCiAg IEluIHRoZSBjdXJyZW50IGRyYWZ0IG9mIHRoZSBYTVBQIGVuZC10by1lbmQgc2VjdXJpdHkgc3lz dGVtLCBlYWNoCiAgIHBhcnR5IGlzIGF1dGhlbnRpY2F0ZWQgYnkgdmlydHVlIG9mIHRoZSBvdGhl ciBwYXJ0eSdzIHRydXN0IGluIHRoZQogICBYTVBQIG1lc3NhZ2Ugcm91dGluZyBzeXN0ZW0uICBU aGUgc2VuZGVyIGlzIGF1dGhlbnRpY2F0ZWQgdG8gdGhlCiAgIHJlY2VpdmVyIGJlY2F1c2UgaGUg Y2FuIHJlY2VpdmUgbWVzc2FnZXMgZm9yIHRoZSBpZGVudGlmaWVyICJBbGljZSIKICAgKGluIHBh cnRpY3VsYXIsIHRoZSByZXF1ZXN0IGZvciB3cmFwcGVkIGtleXMpLCBhbmQgY2FuIG9yaWdpbmF0 ZQogICBtZXNzYWdlcyBmb3IgdGhhdCBpZGVudGlmaWVyICh0aGUgd3JhcHBlZCBrZXkpLiAgTGlr ZXdpc2UsIHRoZQogICByZWNlaXZlciBpcyBhdXRoZW50aWNhdGVkIHRvIHRoZSBzZW5kZXIgYmVj YXVzZSBoZSByZWNlaXZlZCB0aGUKICAgb3JpZ2luYWwgZW5jcnlwdGVkIG1lc3NhZ2UgYW5kIG9y aWdpbmF0ZWQgdGhlIHJlcXVlc3QgZm9yIHdyYXBwZWQKICAga2V5LiAgU28gdGhlIGF1dGhlbnRp Y2F0aW9uIGhlcmUgcmVxdWlyZXMgbm90IG9ubHkgdGhhdCBYTVBQIHJvdXRpbmcKICAgYmUgZG9u ZSBwcm9wZXJseSwgYnV0IGFsc28gdGhhdCBUTFMgYmUgdXNlZCBvbiBldmVyeSBob3AuICBNb3Jl b3ZlciwKICAgaXQgcmVxdWlyZXMgdGhhdCB0aGUgVExTIGNoYW5uZWxzIGhhdmUgc3Ryb25nIGF1 dGhlbnRpY2F0aW9uLCBzaW5jZSBhCiAgIG1hbiBpbiB0aGUgbWlkZGxlIG9uIGFueSBvZiB0aGUg dGhyZWUgaG9wcyBjYW4gbWFzcXVlcmFkZSBhcyBCb2IgYW5kCiAgIG9idGFpbiB0aGUga2V5IG1h dGVyaWFsIGZvciBhbiBlbmNyeXB0ZWQgbWVzc2FnZS4KCiAgIEJlY2F1c2UgdGhpcyBhdXRoZW50 aWNhdGlvbiBpcyBxdWl0ZSB3ZWFrIChkZXBlbmRpbmcgb24gdGhlIHVzZSBvZgogICB0cmFuc3Bv cnQtbGF5ZXIgc2VjdXJpdHkgb24gdGhyZWUgaG9wcykgYW5kIHVudmVyaWZpYWJsZSBieSB0aGUK CgoKQmFybmVzICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAyMDEzICAgICAg ICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBKT1NFIFVz ZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEzCgoKICAgZW5kcG9pbnRzLCBpdCBp cyBwb3NzaWJsZSB0aGF0IHRoZSBYTVBQIHdvcmtpbmcgZ3JvdXAgd2lsbCBpbnRlZ3JhdGUKICAg c29tZSBzb3J0IG9mIGNyZWRlbnRpYWxzIGZvciBlbmQgcmVjaXBpZW50cywgaW4gd2hpY2ggY2Fz ZSB0aGVyZQogICB3b3VsZCBuZWVkIHRvIGJlIGEgd2F5IHRvIGFzc29jaWF0ZSB0aGVzZSBjcmVk ZW50aWFscyB3aXRoIEpPU0UKICAgb2JqZWN0cy4KCiAgIEZpbmFsbHksIGl0J3Mgd29ydGggbm90 aW5nIHRoYXQgWE1QUCBpcyBiYXNlZCBvbiBYTUwsIG5vdCBKU09OLiAgU28KICAgYnkgdXNpbmcg Sk9TRSwgWE1QUCB3aWxsIGJlIGNhcnJ5aW5nIEpTT04gb2JqZWN0cyB3aXRoaW4gWE1MLiAgSXQg aXMKICAgdGh1cyBhIGRlc2lyYWJsZSBwcm9wZXJ0eSBmb3IgSk9TRSBvYmplY3RzIHRvIGJlIGVu Y29kZWQgaW4gc3VjaCBhCiAgIHdheSBhcyB0byBiZSBzYWZlIGZvciBpbmNsdXNpb24gaW4gWE1M LiAgT3RoZXJ3aXNlLCBhbiBleHBsaWNpdCBDREFUQQogICBpbmRpY2F0aW9uIG11c3QgYmUgZ2l2 ZW4gdG8gdGhlIHBhcnNlciB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIG5vdCB0bwogICBiZSBwYXJz ZWQgYXMgWE1MLiAgT25lIHdheSB0byBtZWV0IHRoaXMgcmVxdWlyZW1lbnQgd291bGQgYmUgdG8g YXBwbHkKICAgYmFzZTY0dXJsIGVuY29kaW5nLCBidXQgZm9yIFhNUFAgbWVzc2FnZXMgb2YgbWVk aXVtLXRvLWxhcmdlIHNpemUsCiAgIHRoaXMgY291bGQgaW1wb3NlIGEgZmFpciBkZWdyZWUgb2Yg b3ZlcmhlYWQuCgo1LjUuICBBTFRPCgogICBBcHBsaWNhdGlvbi1MYXllciBUcmFmZmljIE9wdGlt aXphdGlvbiAoQUxUTykgaXMgYSBzeXN0ZW0gZm9yCiAgIGRpc3RyaWJ1dGluZyBuZXR3b3JrIHRv cG9sb2d5IGluZm9ybWF0aW9uIHRvIGVuZCBkZXZpY2VzLCBzbyB0aGF0CiAgIHRob3NlIGRldmlj ZXMgY2FuIG1vZGlmeSB0aGVpciBiZWhhdmlvciB0byBoYXZlIGEgbG93ZXIgaW1wYWN0IG9uIHRo ZQogICBuZXR3b3JrIFtJLUQuaWV0Zi1hbHRvLXJlcXNdLiAgVGhlIEFMVE8gcHJvdG9jb2wgZGlz dHJpYnV0ZXMgdG9wb2xvZ3kKICAgaW5mb3JtYXRpb24gaW4gdGhlIGZvcm0gb2YgSlNPTiBvYmpl Y3RzIGNhcnJpZWQgaW4gSFRUUAogICBbUkZDMjYxNl1bSS1ELmlldGYtYWx0by1wcm90b2NvbF0u ICBUaGUgYmFzaWMgdmVyc2lvbiBvZiBBTFRPIGlzCiAgIHNpbXBseSBhIGNsaWVudC1zZXJ2ZXIg cHJvdG9jb2wsIHNvIHNpbXBsZSB1c2Ugb2YgSFRUUFMgc3VmZmljZXMgZm9yCiAgIHRoaXMgY2Fz ZSBbUkZDMjgxOF0uICBIb3dldmVyLCB0aGVyZSBpcyBiZWdpbm5pbmcgdG8gYmUgc29tZQogICBk aXNjdXNzaW9uIG9mIHVzZSBjYXNlcyBmb3IgQUxUTyBpbiB3aGljaCB0aGVzZSBKU09OIG9iamVj dHMgd2lsbCBiZQogICBkaXN0cmlidXRlZCB0aHJvdWdoIGEgY29sbGVjdGlvbiBvZiBpbnRlcm1l ZGlhdGUgc2VydmVycyBiZWZvcmUKICAgcmVhY2hpbmcgdGhlIGNsaWVudCwgd2hpbGUgc3RpbGwg cHJlc2VydmluZyB0aGUgYWJpbGl0eSBvZiB0aGUgY2xpZW50CiAgIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgb3JpZ2luYWwgc291cmNlIG9mIHRoZSBvYmplY3QuICBFdmVuIHRoZSBiYXNlCiAgIEFMVE8g cHJvdG9jb2wgbm90ZXMgdGhhdCAiQUxUTyBjbGllbnRzIG9idGFpbmluZyBBTFRPIGluZm9ybWF0 aW9uCiAgIG11c3QgYmUgYWJsZSB0byB2YWxpZGF0ZSB0aGUgcmVjZWl2ZWQgQUxUTyBpbmZvcm1h dGlvbiB0byBlbnN1cmUgdGhhdAogICBpdCB3YXMgZ2VuZXJhdGVkIGJ5IGFuIGFwcHJvcHJpYXRl IEFMVE8gc2VydmVyLiIKCiAgIEluIHRoaXMgY2FzZSwgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50 cyBhcmUgc3RyYWlnaHRmb3J3YXJkLiAgSk9TRQogICBvYmplY3RzIGNhcnJ5aW5nIEFMVE8gcGF5 bG9hZHMgd2lsbCBuZWVkIHRvIGJlYXIgZGlnaXRhbCBzaWduYXR1cmVzCiAgIGZyb20gdGhlIG9y aWdpbmF0aW5nIHNlcnZlcnMsIHdoaWNoIHdpbGwgYmUgYm91bmQgdG8gY2VydGlmaWNhdGVzCiAg IGF0dGVzdGluZyB0byB0aGUgaWRlbnRpdGllcyBvZiB0aGUgc2VydmVycy4gIFRoZXJlIGlzIG5v IHJlcXVpcmVtZW50CiAgIGZvciBjb25maWRlbnRpYWxpdHkgaW4gdGhpcyBjYXNlLCBzaW5jZSBB TFRPIGluZm9ybWF0aW9uIGlzIGdlbmVyYWxseQogICBwdWJsaWMuCgogICBUaGUgbW9yZSBpbnRl cmVzdGluZyBxdWVzdGlvbnMgYXJlIGVuY29kaW5nIHF1ZXN0aW9ucy4gIEFMVE8gb2JqZWN0cwog ICBhcmUgbGlrZWx5IHRvIGJlIG11Y2ggbGFyZ2VyIHRoYW4gcGF5bG9hZHMgaW4gdGhlIHR3byBj YXNlcyBhYm92ZSwKICAgd2l0aCBzaXplcyBvZiB1cCB0byBzZXZlcmFsIG1lZ2FieXRlcy4gIFBy b2Nlc3Npbmcgb2Ygc3VjaCBsYXJnZQogICBvYmplY3RzIGNhbiBiZSBkb25lIG1vcmUgcXVpY2ts eSBpZiBpdCBjYW4gYmUgZG9uZSBpbiBhIHNpbmdsZSBwYXNzLAogICB3aGljaCBtYXkgYmUgcG9z c2libGUgaWYgSk9TRSBvYmplY3RzIHJlcXVpcmUgc3BlY2lmaWMgb3JkZXJpbmdzIG9mCiAgIGZp ZWxkcyB3aXRoaW4gdGhlIEpTT04gc3RydWN0dXJlLgoKICAgSW4gYWRkaXRpb24sIGJlY2F1c2Ug QUxUTyBvYmplY3RzIGFyZSBhbHNvIGVuY29kZWQgYXMgSlNPTiwgdGhleSBhcmUKICAgYWxyZWFk eSBzYWZlIGZvciBpbmNsdXNpb24gaW4gYSBKT1NFIG9iamVjdC4gIFNpZ25lZCBKT1NFIG9iamVj dHMKCgoKQmFybmVzICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBKT1NF IFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEzCgoKICAgd2lsbCBsaWtlbHkg Y2FycnkgdGhlIHNpZ25lZCBkYXRhIGluIGEgc3RyaW5nIGFsb25nc2lkZSB0aGUKICAgc2lnbmF0 dXJlLiAgSlNPTiBvYmplY3RzIGhhdmUgdGhlIHByb3BlcnR5IHRoYXQgdGhleSBjYW4gYmUgc2Fm ZWx5CiAgIGVuY29kZWQgaW4gSlNPTiBzdHJpbmdzLiAgQWxsIHRoZXkgcmVxdWlyZSBpcyB0aGF0 IHVubmVjZXNzYXJ5IHdoaXRlCiAgIHNwYWNlIGJlIHJlbW92ZWQsIGEgbXVjaCBzaW1wbGVyIHRy YW5zZm9ybWF0aW9uIHRoYW4sIHNheSBiYXNlNjR1cmwKICAgZW5jb2RpbmcuICBUaGlzIHJhaXNl cyB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBpdCBtaWdodCBiZSBwb3NzaWJsZQogICB0byBvcHRp bWl6ZSB0aGUgSk9TRSBlbmNvZGluZyBmb3IgY2VydGFpbiAiSlNPTi1zYWZlIiBjYXNlcy4KCjUu Ni4gIEVtZXJnZW5jeSBBbGVydGluZwoKICAgRW1lcmdlbmN5IGFsZXJ0aW5nIGlzIGFuIGVtZXJn aW5nIHVzZSBjYXNlIGZvciBJUCBuZXR3b3JrcwogICBbSS1ELmlldGYtYXRvY2EtcmVxdWlyZW1l bnRzXS4gIEFsZXJ0aW5nIHN5c3RlbXMgYWxsb3cgYXV0aG9yaXRpZXMgdG8KICAgd2FybiB1c2Vy cyBvZiBpbXBlbmRpbmcgZGFuZ2VyIGJ5IHNlbmRpbmcgYWxlcnQgbWVzc2FnZXMgdG8gY29ubmVj dGVkCiAgIGRldmljZXMuICBGb3IgZXhhbXBsZSwgaW4gdGhlIGV2ZW50IG9mIGh1cnJpY2FuZSBv ciB0b3JuYWRvLCBhbGVydHMKICAgbWlnaHQgYmUgc2VudCB0byBhbGwgZGV2aWNlcyBpbiB0aGUg cGF0aCBvZiB0aGUgc3Rvcm0uCgogICBUaGUgbW9zdCBjcml0aWNhbCBzZWN1cml0eSByZXF1aXJl bWVudCBmb3IgYWxlcnRpbmcgc3lzdGVtcyBpcyB0aGF0CiAgIGl0IG11c3Qgbm90IGJlIHBvc3Np YmxlIGZvciBhbiBhdHRhY2tlciB0byBzZW5kIGZhbHNlIGFsZXJ0cyB0bwogICBkZXZpY2VzLiAg U3VjaCBhIGNhcGFiaWxpdHkgd291bGQgcG90ZW50aWFsbHkgYWxsb3cgYW4gYXR0YWNrZXIgdG8K ICAgY3JlYXRlIHdpZGUtc3ByZWFkIHBhbmljLiAgSW4gcHJhY3RpY2UsIGFsZXJ0IHN5c3RlbXMg cHJldmVudCB0aGVzZQogICBhdHRhY2tzIGJvdGggYnkgY29udHJvbHMgb24gc2VuZGluZyBtZXNz YWdlcyBhdCBwb2ludHMgd2hlcmUgYWxlcnRzCiAgIGFyZSBvcmlnaW5hdGVkLCBhcyB3ZWxsIGFz IGJ5IGhhdmluZyByZWNpcGllbnRzIG9mIGFsZXJ0cyB2ZXJpZnkgdGhhdAogICB0aGUgYWxlcnQg d2FzIHNlbnQgYnkgYW4gYXV0aG9yaXplZCBzb3VyY2UuICBUaGUgZm9ybWVyIHR5cGUgb2YKICAg Y29udHJvbCBpbXBsZW1lbnRlZCB3aXRoIGxvY2FsIHNlY3VyaXR5IG9uIGhvc3RzIGZyb20gd2hp Y2ggYWxlcnRzCiAgIGNhbiBiZSBvcmlnaW5hdGVkLiAgVGhlIGxhdHRlciB0eXBlIGltcGxlbWVu dGVkIGJ5IGRpZ2l0YWwgc2lnbmF0dXJlcwogICBvbiBhbGVydCBtZXNzYWdlcyAodXNpbmcgY2hh bm5lbC1iYXNlZCBvciBvYmplY3QtYmFzZWQgbWVjaGFuaXNtcykuCgogICBBbGVydHMgdHlwaWNh bGx5IHJlYWNoIGVuZCByZWNpcGllbnRzIHZpYSBhIHNlcmllcyBvZiBpbnRlcm1lZGlhcmllcy4K ICAgRm9yIGV4YW1wbGUsIHdoaWxlIGEgbmF0aW9uYWwgd2VhdGhlciBzZXJ2aWNlIG1pZ2h0IG9y aWdpbmF0ZSBhCiAgIGh1cnJpY2FuZSBhbGVydCwgaXQgbWlnaHQgZmlyc3QgYmUgZGVsaXZlcmVk IHRvIGEgbmF0aW9uYWwgZ2F0ZXdheSwKICAgYW5kIHRoZW4gdG8gbmV0d29yayBvcGVyYXRvcnMs IHdobyBicm9hZGNhc3QgaXQgdG8gZW5kIHN1YnNjcmliZXJzLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpCYXJuZXMgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMzAsIDIwMTMgICAgICAg ICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIEpPU0UgVXNl IENhc2VzICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTMKCgogICAgICAgICAgICstLS0tLS0t LS0tLS0rICAgICstLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0rCiAgICAgICAgICAgfCBP cmlnaW5hdG9yIHwgICAgfCBPcmlnaW5hdG9yIHwgICAgfCBPcmlnaW5hdG9yIHwKICAgICAgICAg ICArLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tKwogICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIC4gICAgICAgICAgICAgICAgIC4KICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLi4uLi4uLi4uLi4uLi4uLi4uCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCBHYXRld2F5IHwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICAgViAgICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLSsgICAgICAgICAgICAgICArLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgIHwgTmV0 d29yayB8ICAgICAgICAgICAgICAgfCBOZXR3b3JrIHwKICAgICAgICAgICAgICAgICArLS0tLS0t LS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgKy0tLS0tLSstLS0tLSsgICAg ICAgICAgICArLS0tLS0tKy0tLS0tKwogICAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgIHwgICAgICAgICAgICB8CiAgICAgICAgICAgICAgIFYgICAgICAgICAgICBWICAgICAg ICAgICAgViAgICAgICAgICAgIFYKICAgICAgICAgICArLS0tLS0tLS0rICAgKy0tLS0tLS0tKyAg ICstLS0tLS0tLSsgICArLS0tLS0tLS0rCiAgICAgICAgICAgfCBEZXZpY2UgfCAgIHwgRGV2aWNl IHwgICB8IERldmljZSB8ICAgfCBEZXZpY2UgfAogICAgICAgICAgICstLS0tLS0tLSsgICArLS0t LS0tLS0rICAgKy0tLS0tLS0tKyAgICstLS0tLS0tLSsKCgogICAgICAgICAgICAgICAgICBGaWd1 cmUgNDogRGVsaXZlcmluZyBhbiBlbWVyZ2VuY3kgYWxlcnQKCiAgIEluIG9yZGVyIHRvIHZlcmlm eSBhbGVydCBzaWduYXR1cmVzLCByZWNpcGllbnRzIG11c3QgYmUgcHJvdmlzaW9uZWQKICAgd2l0 aCB0aGUgcHJvcGVyIHB1YmxpYyBrZXlzIGZvciB0cnVzdGVkIGFsZXJ0IGF1dGhvcml0aWVzLiAg VGhpcwogICB0cnVzdCBtYXkgYmUgInBpZWNlLXdpc2UiIGFsb25nIHRoZSBwYXRoIHRoZSBhbGVy dCB0YWtlcy4gIEZvcgogICBleGFtcGxlLCB0aGUgYWxlcnQgcmVsYXlzIG9wZXJhdGVkIGJ5IG5l dHdvcmtzIG1pZ2h0IGhhdmUgYSBmdWxsIHNldAogICBvZiBjZXJ0aWZpY2F0ZXMgZm9yIGFsbCBh bGVydCBvcmlnaW5hdG9ycywgd2hpbGUgZW5kIGRldmljZXMgbWF5IG9ubHkKICAgdHJ1c3QgdGhl aXIgbG9jYWwgYWxlcnQgcmVsYXkuICBPciBkZXZpY2VzIG1pZ2h0IHJlcXVpcmUgdGhhdCBhCiAg IGRldmljZSBiZSBzaWduZWQgYnkgYW4gYXV0aG9yaXplZCBvcmlnaW5hdG9yIGFuZCBieSBpdHMg bG9jYWwKICAgbmV0d29yaydzIHJlbGF5LgoKICAgVGhpcyBzY2VuYXJpbyBjcmVhdGVzIGEgbmVl ZCBmb3IgbXVsdGlwbGUgc2lnbmF0dXJlcyBvbiBhbGVydAogICBkb2N1bWVudHMsIHNvIHRoYXQg YW4gYWxlcnQgY2FuIGJlYXIgc2lnbmF0dXJlcyBmcm9tIGFueSBvciBhbGwgb2YKICAgdGhlIGVu dGl0aWVzIHRoYXQgcHJvY2Vzc2VkIGl0IGFsb25nIHRoZSBwYXRoLiAgSW4gb3JkZXIgdG8gbWlu aW1pemUKICAgY29tcGxleGl0eSwgdGhlc2Ugc2lnbmF0dXJlcyBzaG91bGQgYmUgIm1vZHVsYXIi LCBpbiB0aGUgc2Vuc2UgdGhhdCBhCiAgIG5ldyBzaWduYXR1cmUgY2FuIGJlIGFkZGVkIHdpdGhv dXQgYSBuZWVkIHRvIGFsdGVyIG9yIHJlY29tcHV0ZQogICBwcmV2aW91cyBzaWduYXR1cmVzLgoK NS43LiAgV2ViIENyeXB0b2dyYXBoeQoKICAgVGhlIFczQyBXZWIgQ3J5cHRvZ3JhcGh5IEFQSSBk ZWZpbmVzIGEgc3RhbmRhcmQgY3J5cHRvZ3JhcGhpYyBBUEkgZm9yCiAgIHRoZSBXZWIgW1dlYkNy eXB0b10uICBJZiBhIGJyb3dzZXIgZXhwb3NlcyB0aGlzIEFQSSwgdGhlbiBKYXZhU2NyaXB0CgoK CkJhcm5lcyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAg ICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2Ug Q2FzZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMwoKCiAgIHByb3ZpZGVkIGFzIHBhcnQg b2YgYSBXZWIgcGFnZSBjYW4gYXNrIHRoZSBicm93c2VyIHRvIHBlcmZvcm0KICAgY3J5cHRvZ3Jh cGhpYyBvcGVyYXRpb25zLCBzdWNoIGFzIGRpZ2VzdCwgTUFDLCBlbmNyeXB0aW9uLCBvciBkaWdp dGFsCiAgIHNpZ25pbmcuCgogICBPbmUgb2YgdGhlIGtleSByZWFzb25zIHRvIGhhdmUgdGhlIGJy b3dzZXIgcGVyZm9ybSBjcnlwdG9ncmFwaGljCiAgIG9wZXJhdGlvbnMgaXMgdG8gYXZvaWQgYWxs b3dpbmcgSmF2YVNjcmlwdCBjb2RlIHRvIGFjY2VzcyB0aGUga2V5aW5nCiAgIG1hdGVyaWFsIHVz ZWQgZm9yIHRoZXNlIG9wZXJhdGlvbnMuICBGb3IgZXhhbXBsZSwgdGhpcyBzZXBhcmF0aW9uCiAg IHdvdWxkIHByZXZlbnQgY29kZSBpbmplY3RlZCB0aHJvdWdoIGEgY3Jvc3Mtc2l0ZSBzY3JpcHRp bmcgKFhTUykKICAgYXR0YWNrIGZyb20gcmVhZGluZyBhbmQgZXhmaWx0cmF0aW5nIGtleXMgc3Rv cmVkIHdpdGhpbiBhIGJyb3dzZXIuCiAgIFdoaWxlIHRoZSBtYWxpY2lvdXMgY29kZSBjb3VsZCBz dGlsbCB1c2UgdGhlIGtleSB3aGlsZSBydW5uaW5nIGluIHRoZQogICBicm93c2VyLCB0aGlzIHZ1 bG5lcmFiaWxpdHkgY2FuIG9ubHkgYmUgZXhlcmNpc2VkIHdoaWxlIHRoZQogICB2dWxuZXJhYmxl IHBhZ2UgaXMgYWN0aXZlIGluIGEgdXNlcidzIGJyb3dzZXIuCgogICBIb3dldmVyLCB0aGUgV2Vi Q3J5cHRvZ3JhcGh5IEFQSSBhbHNvIHByb3ZpZGVzIGEga2V5IGV4cG9ydAogICBmdW5jdGlvbmFs aXR5LCB3aGljaCBjYW4gYWxsb3cgSmF2YVNjcmlwdCB0byBleHRyYWN0IGEga2V5IGZyb20gdGhl CiAgIEFQSSBpbiB3cmFwcGVkIGZvcm0uICBGb3IgZXhhbXBsZSwgdGhlIEphdmFTY3JpcHQgbWln aHQgcHJvdmlkZSBhCiAgIHB1YmxpYyBrZXkgZm9yIHdoaWNoIHRoZSBjb3JyZXNwb25kaW5nIHBy aXZhdGUga2V5IGlzIGhlbGQgYnkgYW5vdGhlcgogICBkZXZpY2UuICBUaGUgd3JhcHBlZCBrZXkg cHJvdmlkZWQgYnkgdGhlIEFQSSBjb3VsZCB0aGVuIGJlIHVzZWQgdG8KICAgc2FmZWx5IHRyYW5z cG9ydCB0aGUga2V5IHRvIHRoZSBuZXcgZGV2aWNlLiAgV2hpbGUgdGhpcyBjb3VsZAogICBwb3Rl bnRpYWxseSBhbGxvdyBtYWxpY2lvdXMgY29kZSB0byBleHBvcnQgYSBrZXksIHRoZSBuZWVkIGZv ciBhbgogICBleHBsaWNpdCBleHBvcnQgb3BlcmF0aW9uIHByb3ZpZGVzIGEgY29udHJvbCBwb2lu dCwgYWxsb3dpbmcgZm9yIHVzZXIKICAgbm90aWZpY2F0aW9uIG9yIGNvbnNlbnQgdmVyaWZpY2F0 aW9uLgoKICAgVGhlIFdlYiBDcnlwdG9ncmFwaHkgQVBJIGFsc28gYWxsb3dzIGJyb3dzZXJzIHRv IGltcG9zZSBsaW1pdGF0aW9ucwogICBvbiB0aGUgdXNhZ2Ugb2YgdGhlIGtleXMgaXQgaGFuZGxl cy4gIEZvciBleGFtcGxlLCBhIHN5bW1ldHJpYyBrZXkKICAgbWlnaHQgYmUgbWFya2VkIGFzIHVz YWJsZSBvbmx5IGZvciBlbmNyeXB0aW9uLCBhbmQgbm90IGZvciBNQUMuICBXaGVuCiAgIGEga2V5 IGlzIGV4cG9ydGVkIGluIHdyYXBwZWQgZm9ybSwgdGhlc2UgYXR0cmlidXRlcyBzaG91bGQgYmUg Y2FycmllZAogICBhbG9uZyB3aXRoIGl0LgoKICAgVGhlIFdlYiBDcnlwdG9ncmFwaHkgQVBJIHRo dXMgcmVxdWlyZXMgZm9ybWF0cyB0byBleHByZXNzIHNldmVyYWwKICAgZm9ybXMgb2Yga2V5cy4g IE9idmlvdXNseSwgdGhlIHB1YmxpYyBrZXkgZnJvbSBhbiBhc3ltbWV0cmljIGtleSBwYWlyCiAg IGNhbiBiZSBmcmVlbHkgaW1wb3J0ZWQgdG8gYW5kIGV4cG9ydGVkIGZyb20gdGhlIGJyb3dzZXIs IHNvIHRoZXJlCiAgIG5lZWRzIHRvIGJlIGEgZm9ybWF0IGZvciBwdWJsaWMga2V5cy4gIFRoZXJl IGlzIGFsc28gYSBuZWVkIGZvciBhCiAgIGZvcm1hdCB0byBleHByZXNzIHByaXZhdGUga2V5cyBh bmQgc3ltbWV0cmljIGtleXMuICBGb3Igbm9uLXB1YmxpYwogICBrZXlzLCB0aGUgcHJpbWFyeSBu ZWVkIGlzIGZvciBhIHdyYXBwZWQgZm9ybSwgd2hlcmUgdGhlCiAgIGNvbmZpZGVudGlhbGl0eSBh bmQgaW50ZWdyaXR5IG9mIHRoZSBrZXkgaXMgYXNzdXJlZAogICBjcnlwdG9ncmFwaGljYWxseTsg dGhlc2UgcHJvdGVjdGlvbnMgc2hvdWxkIGFsc28gYXBwbHkgdG8gYW55CiAgIGF0dHJpYnV0ZXMg b2YgdGhlIGtleS4gIEl0IG1heSBhbHNvIGJlIHVzZWZ1bCB0byBkZWZpbmUgYSBkaXJlY3QsCiAg IHVud3JhcHBlZCBmb3JtYXQsIGZvciB1c2Ugd2l0aGluIGEgc2VjdXJpdHkgYm91bmRhcnkuCgoK Ni4gIFJlcXVpcmVtZW50cwoKICAgVGhpcyBzZWN0aW9uIHN1bW1hcml6ZXMgdGhlIHJlcXVpcmVt ZW50cyBmcm9tIHRoZSBhYm92ZSB1c2VzIGNhc2VzLAogICBhbmQgbGlzdHMgZnVydGhlciByZXF1 aXJlbWVudHMgbm90IGRpcmVjdGx5IGRlcml2ZWQgZnJvbSB0aGUgYWJvdmUKICAgdXNlIGNhc2Vz LiAgVGhlcmUgYXJlIGFsc28gc29tZSBjb25zdHJhaW50cyB0aGF0IGFyZSBub3QgaGFyZAogICBy ZXF1aXJlbWVudHMsIGJ1dCB3aGljaCBhcmUgc3RpbGwgZGVzaXJhYmxlIHByb3BlcnRpZXMgZm9y IHRoZSBKT1NFCiAgIHN5c3RlbSB0byBoYXZlLgoKCgpCYXJuZXMgICAgICAgICAgICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMzAsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIEpPU0UgVXNlIENhc2VzICAgICAgICAgICAgICAgICAgIEFw cmlsIDIwMTMKCgo2LjEuICBGdW5jdGlvbmFsIFJlcXVpcmVtZW50cwoKICAgRjEgRGVmaW5lIGZv cm1hdHMgZm9yIHNlY3VyZSBvYmplY3RzIHRoYXQgcHJvdmlkZSB0aGUgZm9sbG93aW5nCiAgICAg IHNlY3VyaXR5IHByb3BlcnRpZXM6CgogICAgICAqICBEaWdpdGFsIHNpZ25hdHVyZSAoaW50ZWdy aXR5L2F1dGhlbnRpY2F0aW9uIHVuZGVyIGFuIGFzeW1tZXRyaWMKICAgICAgICAga2V5IHBhaXIp CgogICAgICAqICBNZXNzYWdlIGF1dGhlbnRpY2F0aW9uIChpbnRlZ3JpdHkvYXV0aGVudGljYXRp b24gdW5kZXIgYQogICAgICAgICBzeW1tZXRyaWMga2V5KQoKICAgICAgKiAgRW5jcnlwdGlvbgoK ICAgICAgKiAgQXV0aGVudGljYXRlZCBlbmNyeXB0aW9uCgogICAgICBUaGF0IGlzLCB0aGUgc2Vj dXJlIG9iamVjdHMgZGVmaW5lZCBieSB0aGlzIHdvcmtpbmcgZ3JvdXAgc2hvdWxkCiAgICAgIHBy b3ZpZGUgZXF1aXZhbGVudCBzZWN1cml0eSBwcm9wZXJ0aWVzIHRvIHRoZSBDTVMgU2lnbmVkRGF0 YSwKICAgICAgQXV0aGVudGljYXRlZERhdGEsIEVudmVsb3BlZERhdGEsIGFuZCBBdXRoRW52ZWxv cGVkIGRhdGEgb2JqZWN0cwogICAgICBbUkZDNTY1Ml0gW1JGQzUwODNdLgoKICAgRjIgRGVmaW5l IGEgZm9ybWF0IGZvciBwdWJsaWMga2V5cyBhbmQgcHJpdmF0ZSBrZXlzIGZvciBhc3ltbWV0cmlj CiAgICAgIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcywgd2l0aCBhc3NvY2lhdGVkIGF0dHJpYnV0 ZXMsIGluY2x1ZGluZyBhCiAgICAgIHdyYXBwZWQgZm9ybSBmb3IgcHJpdmF0ZSBrZXlzLgoKICAg RjMgRGVmaW5lIGEgZm9ybWF0IGZvciBzeW1tZXRyaWMga2V5cyB3aXRoIGFzc29jaWF0ZWQgYXR0 cmlidXRlcywKICAgICAgYWxsb3dpbmcgZm9yIGJvdGggd3JhcHBlZCBhbmQgdW53cmFwcGVkIGtl eXMuCgogICBGNCBEZWZpbmUgSlNPTiBzZXJpYWxpemF0aW9ucyBmb3IgdGhlIGFib3ZlIG9iamVj dHMuICBBbiBvYmplY3QgaW4KICAgICAgdGhpcyBlbmNvZGluZyBtdXN0IGJlIHZhbGlkIGFjY29y ZGluZyB0byB0aGUgSlNPTiBBQk5GIHN5bnRheAogICAgICBbUkZDNDYyN10KCiAgIEY1IERlZmlu ZSBjb21wYWN0LCBVUkwtc2FmZSB0ZXh0IHNlcmlhbGl6YXRpb25zIGZvciB0aGUgYWJvdmUKICAg ICAgb2JqZWN0cy4KCiAgIEY2IEFsbG93IGZvciBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgdG8gd3Jh cHBlZCBrZXlzIHRvIGJlIGJvdW5kIHRvCiAgICAgIHRoZW0gY3J5cHRvZ3JhcGhpY2FsbHkKCiAg IEY3IEFsbG93IGZvciB3cmFwcGVkIGtleXMgdG8gYmUgc2VwYXJhdGVkIGZyb20gYSBzZWN1cmUg b2JqZWN0IHRoYXQKICAgICAgdXNlcyBhIHN5bW1ldHJpYyBrZXkuICBJbiBzdWNoIGNhc2VzLCBj cnlwdG9ncmFwaGljIGNvbXBvbmVudHMgb2YKICAgICAgdGhlIHNlY3VyZSBvYmplY3Qgb3RoZXIg dGhhbiB0aGUgd3JhcHBlZCBrZXkgKGUuZy4sIGNpcGhlcnRleHQsCiAgICAgIE1BQyB2YWx1ZXMp IG11c3QgYmUgaW5kZXBlbmRlbnQgb2YgdGhlIHdyYXBwZWQgZm9ybSBvZiB0aGUga2V5LgogICAg ICBGb3IgZXhhbXBsZSwgaWYgYW4gZW5jcnlwdGVkIG9iamVjdCBpcyBwcmVwYXJlZCBmb3IgbXVs dGlwbGUKICAgICAgcmVjaXBpZW50cywgdGhlbiBvbmx5IHRoZSB3cmFwcGVkIGtleSBtYXkgdmFy eSwgbm90IHRoZQogICAgICBjaXBoZXJ0ZXh0LgoKCgoKCgoKQmFybmVzICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDMwLCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBKT1NFIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAg ICBBcHJpbCAyMDEzCgoKNi4yLiAgU2VjdXJpdHkgUmVxdWlyZW1lbnRzCgogICBTMSBQcm92aWRl IGtleSBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBmb3IgZXBoZW1lcmFsIHN5bW1ldHJpYyBrZXlzLAog ICAgICBpbmNsdWRpbmcgZW5jcnlwdGlvbiBrZXlzIGFuZCBNQUMga2V5cy4gIEl0IHNob3VsZCBi ZSBwb3NzaWJsZSB0bwogICAgICB1c2UgYW55IG9mIHRoZSBrZXkgbWFuYWdlbWVudCB0ZWNobmlx dWVzIHByb3ZpZGVkIGluIENNUwogICAgICBbUkZDNTY1Ml06CgogICAgICAqICBLZXkgdHJhbnNw b3J0ICh3cmFwcGluZyBmb3IgYSBwdWJsaWMga2V5KQoKICAgICAgKiAgS2V5IGVuY2lwaGVybWVu dCAod3JhcHBpbmcgZm9yIGEgc3ltbWV0cmljIGtleSkKCiAgICAgICogIEtleSBhZ3JlZW1lbnQg KHdyYXBwaW5nIGZvciBhIERIIHB1YmxpYyBrZXkpCgogICAgICAqICBQYXNzd29yZC1iYXNlZCBl bmNyeXB0aW9uICh3cmFwcGluZyB1bmRlciBhIGRlcml2ZWQga2V5KQoKICAgICAgYXMgd2VsbCBh cyB0aGUgRGlyZWN0IEVuY3J5cHRpb24ga2V5IG1hbmFnZW1lbnQgdGVjaG5pcXVlLgoKICAgUzIg VXNlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBpbiBhIG1hbm5lciBjb21wYXRpYmxlIHdpdGgg bWFqb3IKICAgICAgdmFsaWRhdGlvbiBwcm9jZXNzZXMuICBGb3IgZXhhbXBsZSwgaWYgYSBGSVBT IHN0YW5kYXJkIGFsbG93cwogICAgICBhbGdvcml0aG0gQSB0byBiZSB1c2VkIGZvciBwdXJwb3Nl IFggYnV0IG5vdCBwdXJwb3NlIFksIHRoZW4gSk9TRQogICAgICBzaG91bGQgbm90IHJlY29tbWVu ZCB1c2luZyBhbGdvcml0aG0gQSBmb3IgcHVycG9zZSBZLgoKICAgUzMgU3VwcG9ydCBvcGVyYXRp b24gd2l0aCBvciB3aXRob3V0IHByZS1uZWdvdGlhdGlvbi4gIEl0IG11c3QgYmUKICAgICAgcG9z c2libGUgdG8gY3JlYXRlIG9yIHByb2Nlc3Mgc2VjdXJlIG9iamVjdHMgd2l0aG91dCBhbnkKICAg ICAgY29uZmlndXJhdGlvbiBiZXlvbmQga2V5IHByb3Zpc2lvbmluZy4gIElmIGl0IGlzIHBvc3Np YmxlIHRvCiAgICAgIG5lZ290aWF0ZSBwYXJhbWV0ZXJzIG91dCBvZiBiYW5kLCB0aGVuIGl0IG11 c3QgYmUgcG9zc2libGUgdG8KICAgICAgc2lnbmFsIHRoYXQgcHJlLW5lZ290aWF0ZWQgcGFyYW1l dGVycyBhcmUgdG8gYmUgdXNlZC4KCjYuMy4gIERlc2lkZXJhdGEKCiAgIEQxIE1heGltaXplIGNv bXBhdGliaWxpdHkgd2l0aCB0aGUgVzNDIFdlYkNyeXB0byBzcGVjaWZpY2F0aW9ucywKICAgICAg ZS5nLiwgYnkgY29vcmRpbmF0aW5nIHdpdGggdGhlIFdlYkNyeXB0byB3b3JraW5nIGdyb3VwIHJl cXVlc3RpbmcKICAgICAgdGhhdCB0aGV5IHN1cHBvcnQgdXNpbmcgdGhlIGFsZ29yaXRobXMgbmVl ZGVkIGJ5IEpPU0UKICAgICAgaW1wbGVtZW50YXRpb25zLCBieSBzdWdnZXN0aW5nIHRoYXQgdGhl eSB1c2UgSk9TRSBkYXRhIGZvcm1hdHMKICAgICAgd2hlcmUgdGhlc2UgbWFrZSBzZW5zZSwgYW5k IGJ5IHN1Z2dlc3RpbmcgdGhhdCB0aGV5IHVzZSB0aGUgc2FtZQogICAgICBpZGVudGlmaWVycyBm b3IgYWxnb3JpdGhtcyBhcyBKT1NFLCBpbiBjYXNlcyB3aGVyZSB0aGlzIG1ha2VzCiAgICAgIHNl bnNlLgoKICAgRDIgQXZvaWQgSlNPTiBjYW5vbmljYWxpemF0aW9uIHRvIHRoZSBleHRlbnQgcG9z c2libGUuICBUaGF0IGlzLCBhbGwKICAgICAgb3RoZXIgdGhpbmdzIGJlaW5nIGVxdWFsLCB0ZWNo bmlxdWVzIHRoYXQgcmVseSBvbiBmaXhpbmcgYQogICAgICBzZXJpYWxpemF0aW9uIG9mIGFuIG9i amVjdCAoZS5nLiwgYnkgYmFzZTY0dXJsIGVuY29kaW5nIGl0KSBhcmUKICAgICAgcHJlZmVycmVk IG92ZXIgdGhvc2UgdGhhdCByZXF1aXJlIGNvbnZlcnRpbmcgYW4gb2JqZWN0IHRvIGEKICAgICAg Y2Fub25pY2FsIGZvcm0uCgoKCgoKCgoKQmFybmVzICAgICAgICAgICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDMwLCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICBKT1NFIFVzZSBDYXNlcyAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDEz CgoKNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gcmVx dWVzdCBvZiBJQU5BLgoKCjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHByaW1h cnkgZm9jdXMgb2YgdGhpcyBkb2N1bWVudCBpcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBhIEpTT04t CiAgIGJhc2VkIHNlY3VyZSBvYmplY3QgZm9ybWF0LiAgQXQgdGhlIGxldmVsIG9mIGdlbmVyYWwg c2VjdXJpdHkKICAgY29uc2lkZXJhdGlvbnMgZm9yIG9iamVjdC1iYXNlZCBzZWN1cml0eSB0ZWNo bm9sb2dpZXMsIHRoZSBzZWN1cml0eQogICBjb25zaWRlcmF0aW9ucyBmb3IgdGhpcyBmb3JtYXQg YXJlIHRoZSBzYW1lIGFzIGZvciBDTVMgW1JGQzU2NTJdLgogICBUaGUgcHJpbWFyeSBkaWZmZXJl bmNlIGJldHdlZW4gdGhlIEpPU0UgZm9ybWF0IGFuZCBDTVMgaXMgdGhhdCBKT1NFCiAgIGlzIGJh c2VkIG9uIEpTT04sIHdoaWNoIGRvZXMgbm90IGhhdmUgYSBjYW5vbmljYWwgcmVwcmVzZW50YXRp b24uCiAgIFRoZSBsYWNrIG9mIGEgY2Fub25pY2FsIGZvcm0gbWVhbnMgdGhhdCBpdCBpcyBkaWZm aWN1bHQgdG8gZGV0ZXJtaW5lCiAgIHdoZXRoZXIgdHdvIEpTT04gb2JqZWN0cyByZXByZXNlbnQg dGhlIHNhbWUgaW5mb3JtYXRpb24sIHdoaWNoIGNvdWxkCiAgIGxlYWQgdG8gdnVsbmVyYWJpbGl0 aWVzIGluIHNvbWUgdXNhZ2VzIG9mIEpPU0UuCgoKOS4gIFJlZmVyZW5jZXMKCjkuMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmlldGYtYWx0by1wcm90b2NvbF0KICAgICAgICAgICAg ICBBbGltaSwgUi4sIFBlbm5vLCBSLiwgYW5kIFkuIFlhbmcsICJBTFRPIFByb3RvY29sIiwKICAg ICAgICAgICAgICBkcmFmdC1pZXRmLWFsdG8tcHJvdG9jb2wtMTQgKHdvcmsgaW4gcHJvZ3Jlc3Mp LAogICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMuCgogICBbSS1ELmlldGYtYWx0by1yZXFzXQog ICAgICAgICAgICAgIEtpZXNlbCwgUy4sIFByZXZpZGksIFMuLCBTdGllbWVybGluZywgTS4sIFdv dW5keSwgUi4sIGFuZAogICAgICAgICAgICAgIFkuIFlhbmcsICJBcHBsaWNhdGlvbi1MYXllciBU cmFmZmljIE9wdGltaXphdGlvbiAoQUxUTykKICAgICAgICAgICAgICBSZXF1aXJlbWVudHMiLCBk cmFmdC1pZXRmLWFsdG8tcmVxcy0xNiAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAg SnVuZSAyMDEyLgoKICAgW0ktRC5pZXRmLWF0b2NhLXJlcXVpcmVtZW50c10KICAgICAgICAgICAg ICBTY2h1bHpyaW5uZSwgSC4sIE5vcnJleXMsIFMuLCBSb3NlbiwgQi4sIGFuZCBILgogICAgICAg ICAgICAgIFRzY2hvZmVuaWcsICJSZXF1aXJlbWVudHMsIFRlcm1pbm9sb2d5IGFuZCBGcmFtZXdv cmsgZm9yCiAgICAgICAgICAgICAgRXhpZ2VudCBDb21tdW5pY2F0aW9ucyIsIGRyYWZ0LWlldGYt YXRvY2EtcmVxdWlyZW1lbnRzLTAzCiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBN YXJjaCAyMDEyLgoKICAgW0ktRC5pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtc10KICAgICAg ICAgICAgICBKb25lcywgTS4sICJKU09OIFdlYiBBbGdvcml0aG1zIChKV0EpIiwKICAgICAgICAg ICAgICBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0xMCAod29yayBpbiBwcm9n cmVzcyksCiAgICAgICAgICAgICAgQXByaWwgMjAxMy4KCiAgIFtJLUQuaWV0Zi1qb3NlLWpzb24t d2ViLWVuY3J5cHRpb25dCiAgICAgICAgICAgICAgSm9uZXMsIE0uLCBSZXNjb3JsYSwgRS4sIGFu ZCBKLiBIaWxkZWJyYW5kLCAiSlNPTiBXZWIKICAgICAgICAgICAgICBFbmNyeXB0aW9uIChKV0Up IiwgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMTAKICAgICAgICAgICAgICAo d29yayBpbiBwcm9ncmVzcyksIEFwcmlsIDIwMTMuCgoKCkJhcm5lcyAgICAgICAgICAgICAgICAg IEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2FzZXMgICAgICAgICAgICAgICAgICAg QXByaWwgMjAxMwoKCiAgIFtJLUQuaWV0Zi1qb3NlLWpzb24td2ViLWtleV0KICAgICAgICAgICAg ICBKb25lcywgTS4sICJKU09OIFdlYiBLZXkgKEpXSykiLAogICAgICAgICAgICAgIGRyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1rZXktMTAgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAg IEFwcmlsIDIwMTMuCgogICBbSS1ELmlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmVdCiAgICAg ICAgICAgICAgSm9uZXMsIE0uLCBCcmFkbGV5LCBKLiwgYW5kIE4uIFNha2ltdXJhLCAiSlNPTiBX ZWIKICAgICAgICAgICAgICBTaWduYXR1cmUgKEpXUykiLCBkcmFmdC1pZXRmLWpvc2UtanNvbi13 ZWItc2lnbmF0dXJlLTEwCiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBBcHJpbCAy MDEzLgoKICAgW0ktRC5pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuXQogICAgICAgICAgICAgIEpv bmVzLCBNLiwgQnJhZGxleSwgSi4sIGFuZCBOLiBTYWtpbXVyYSwgIkpTT04gV2ViIFRva2VuCiAg ICAgICAgICAgICAgKEpXVCkiLCBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA3ICh3 b3JrIGluCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBBcHJpbCAyMDEzLgoKICAgW0ktRC5taWxs ZXIteG1wcC1lMmVdCiAgICAgICAgICAgICAgTWlsbGVyLCBNLiwgIkVuZC10by1FbmQgT2JqZWN0 IEVuY3J5cHRpb24gZm9yIHRoZQogICAgICAgICAgICAgIEV4dGVuc2libGUgTWVzc2FnaW5nIGFu ZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCkiLAogICAgICAgICAgICAgIGRyYWZ0LW1pbGxlci14 bXBwLWUyZS0wNCAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgRmVicnVhcnkgMjAx My4KCiAgIFtSRkM0NjI3XSAgQ3JvY2tmb3JkLCBELiwgIlRoZSBhcHBsaWNhdGlvbi9qc29uIE1l ZGlhIFR5cGUgZm9yCiAgICAgICAgICAgICAgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpT T04pIiwgUkZDIDQ2MjcsIEp1bHkgMjAwNi4KCiAgIFtSRkM0NjQ4XSAgSm9zZWZzc29uLCBTLiwg IlRoZSBCYXNlMTYsIEJhc2UzMiwgYW5kIEJhc2U2NCBEYXRhCiAgICAgICAgICAgICAgRW5jb2Rp bmdzIiwgUkZDIDQ2NDgsIE9jdG9iZXIgMjAwNi4KCiAgIFtSRkM0OTQ5XSAgU2hpcmV5LCBSLiwg IkludGVybmV0IFNlY3VyaXR5IEdsb3NzYXJ5LCBWZXJzaW9uIDIiLAogICAgICAgICAgICAgIFJG QyA0OTQ5LCBBdWd1c3QgMjAwNy4KCiAgIFtSRkM1MDgzXSAgSG91c2xleSwgUi4sICJDcnlwdG9n cmFwaGljIE1lc3NhZ2UgU3ludGF4IChDTVMpCiAgICAgICAgICAgICAgQXV0aGVudGljYXRlZC1F bnZlbG9wZWQtRGF0YSBDb250ZW50IFR5cGUiLCBSRkMgNTA4MywKICAgICAgICAgICAgICBOb3Zl bWJlciAyMDA3LgoKICAgW1JGQzU2NTJdICBIb3VzbGV5LCBSLiwgIkNyeXB0b2dyYXBoaWMgTWVz c2FnZSBTeW50YXggKENNUykiLCBTVEQgNzAsCiAgICAgICAgICAgICAgUkZDIDU2NTIsIFNlcHRl bWJlciAyMDA5LgoKICAgW1JGQzYxMjBdICBTYWludC1BbmRyZSwgUC4sICJFeHRlbnNpYmxlIE1l c3NhZ2luZyBhbmQgUHJlc2VuY2UKICAgICAgICAgICAgICBQcm90b2NvbCAoWE1QUCk6IENvcmUi LCBSRkMgNjEyMCwgTWFyY2ggMjAxMS4KCiAgIFtSRkM2NzQ5XSAgSGFyZHQsIEQuLCAiVGhlIE9B dXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yayIsCiAgICAgICAgICAgICAgUkZDIDY3NDks IE9jdG9iZXIgMjAxMi4KCiAgIFtSRkM2NzUwXSAgSm9uZXMsIE0uIGFuZCBELiBIYXJkdCwgIlRo ZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIEZyYW1ld29yazogQmVhcmVy IFRva2VuIFVzYWdlIiwgUkZDIDY3NTAsIE9jdG9iZXIgMjAxMi4KCiAgIFtXM0MuQ1IteG1sZHNp Zy1jb3JlMi0yMDEyMDEyNF0KICAgICAgICAgICAgICBFYXN0bGFrZSwgRC4sIFJlYWdsZSwgSi4s IFlpdSwgSy4sIFNvbG8sIEQuLCBEYXR0YSwgUC4sCgoKCkJhcm5lcyAgICAgICAgICAgICAgICAg IEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2FzZXMgICAgICAgICAgICAgICAgICAg QXByaWwgMjAxMwoKCiAgICAgICAgICAgICAgSGlyc2NoLCBGLiwgQ2FudG9yLCBTLiwgYW5kIFQu IFJvZXNzbGVyLCAiWE1MIFNpZ25hdHVyZQogICAgICAgICAgICAgIFN5bnRheCBhbmQgUHJvY2Vz c2luZyBWZXJzaW9uIDIuMCIsIFdvcmxkIFdpZGUgV2ViCiAgICAgICAgICAgICAgQ29uc29ydGl1 bSBDUiBDUi14bWxkc2lnLWNvcmUyLTIwMTIwMTI0LCBKYW51YXJ5IDIwMTIsCiAgICAgICAgICAg ICAgPGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMTIvQ1IteG1sZHNpZy1jb3JlMi0yMDEyMDEyND4u CgogICBbVzNDLkNSLXhtbGVuYy1jb3JlMS0yMDEyMDMxM10KICAgICAgICAgICAgICBFYXN0bGFr ZSwgRC4sIFJlYWdsZSwgSi4sIFJvZXNzbGVyLCBULiwgYW5kIEYuIEhpcnNjaCwKICAgICAgICAg ICAgICAiWE1MIEVuY3J5cHRpb24gU3ludGF4IGFuZCBQcm9jZXNzaW5nIFZlcnNpb24gMS4xIiwg V29ybGQKICAgICAgICAgICAgICBXaWRlIFdlYiBDb25zb3J0aXVtIENSIENSLXhtbGVuYy1jb3Jl MS0yMDEyMDMxMywKICAgICAgICAgICAgICBNYXJjaCAyMDEyLAogICAgICAgICAgICAgIDxodHRw Oi8vd3d3LnczLm9yZy9UUi8yMDEyL0NSLXhtbGVuYy1jb3JlMS0yMDEyMDMxMz4uCgogICBbVzND LlJFQy14bWwtMTk5OF0KICAgICAgICAgICAgICBCcmF5LCBULiwgUGFvbGksIEouLCBhbmQgQy4g U3BlcmJlcmctTWNRdWVlbiwgIkV4dGVuc2libGUKICAgICAgICAgICAgICBNYXJrdXAgTGFuZ3Vh Z2UgKFhNTCkgMS4wIiwgVzNDIFJFQy14bWwtMTk5OCwKICAgICAgICAgICAgICBGZWJydWFyeSAx OTk4LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnczLm9yZy9UUi8xOTk4L1JFQy14bWwtMTk5 ODAyMTAvPi4KCiAgIFtXZWJDcnlwdG9dCiAgICAgICAgICAgICAgU2xlZXZpLCBSLiBhbmQgRC4g RGFobCwgIldlYiBDcnlwdG9ncmFwaHkgQVBJIiwKICAgICAgICAgICAgICBKYW51YXJ5IDIwMTMu Cgo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbQ0FQXSAgICAgIEJvdHRlcmVsbCwg QS4gYW5kIEUuIEpvbmVzLCAiQ29tbW9uIEFsZXJ0aW5nIFByb3RvY29sCiAgICAgICAgICAgICAg djEuMSIsIE9jdG9iZXIgMjAwNS4KCiAgIFtJLUQuaWV0Zi1vYXV0aC1qd3QtYmVhcmVyXQogICAg ICAgICAgICAgIEpvbmVzLCBNLiwgQ2FtcGJlbGwsIEIuLCBhbmQgQy4gTW9ydGltb3JlLCAiSlNP TiBXZWIgVG9rZW4KICAgICAgICAgICAgICAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZAogICAgICAgICAgICAgIEF1dGhvcml6YXRpb24gR3JhbnRz IiwgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA1CiAgICAgICAgICAgICAgKHdvcmsgaW4g cHJvZ3Jlc3MpLCBNYXJjaCAyMDEzLgoKICAgW0ktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlcl0K ICAgICAgICAgICAgICBDYW1wYmVsbCwgQi4sIE1vcnRpbW9yZSwgQy4sIGFuZCBNLiBKb25lcywg IlNBTUwgMi4wCiAgICAgICAgICAgICAgUHJvZmlsZSBmb3IgT0F1dGggMi4wIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQKICAgICAgICAgICAgICBBdXRob3JpemF0aW9uIEdyYW50cyIsIGRyYWZ0 LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTE2CiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jl c3MpLCBNYXJjaCAyMDEzLgoKICAgW0lUVS5YNjkwLjE5OTRdCiAgICAgICAgICAgICAgSW50ZXJu YXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24sICJJbmZvcm1hdGlvbgogICAgICAgICAg ICAgIFRlY2hub2xvZ3kgLSBBU04uMSBlbmNvZGluZyBydWxlczogU3BlY2lmaWNhdGlvbiBvZiBC YXNpYwogICAgICAgICAgICAgIEVuY29kaW5nIFJ1bGVzIChCRVIpLCBDYW5vbmljYWwgRW5jb2Rp bmcgUnVsZXMgKENFUikgYW5kCiAgICAgICAgICAgICAgRGlzdGluZ3Vpc2hlZCBFbmNvZGluZyBS dWxlcyAoREVSKSIsIElUVS1UIFJlY29tbWVuZGF0aW9uCiAgICAgICAgICAgICAgWC42OTAsIDE5 OTQuCgogICBbT0FTSVMuc2FtbC1jb3JlLTIuMC1vc10KICAgICAgICAgICAgICBDYW50b3IsIFMu LCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIuLCBhbmQgRS4gTWFsZXIsCgoKCkJhcm5lcyAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDIw XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2UgQ2FzZXMgICAgICAgICAg ICAgICAgICAgQXByaWwgMjAxMwoKCiAgICAgICAgICAgICAgIkFzc2VydGlvbnMgYW5kIFByb3Rv Y29sIGZvciB0aGUgT0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uCiAgICAgICAgICAgICAgTWFya3Vw IExhbmd1YWdlIChTQU1MKSBWMi4wIiwgT0FTSVMgU3RhbmRhcmQgc2FtbC1jb3JlLQogICAgICAg ICAgICAgIDIuMC1vcywgTWFyY2ggMjAwNS4KCiAgIFtPcGVuSUQuTWVzc2FnZXNdCiAgICAgICAg ICAgICAgU2FraW11cmEsIE4uLCBCcmFkbGV5LCBKLiwgSm9uZXMsIE0uLCBkZSBNZWRlaXJvcywg Qi4sCiAgICAgICAgICAgICAgTW9ydGltb3JlLCBDLiwgYW5kIEUuIEpheSwgIk9wZW5JRCBDb25u ZWN0IE1lc3NhZ2VzIDEuMCIsCiAgICAgICAgICAgICAgTWFyY2ggMjAxMywKICAgICAgICAgICAg ICA8aHR0cDovL29wZW5pZC5uZXQvc3BlY3MvCiAgICAgICAgICAgICAgb3BlbmlkLWNvbm5lY3Qt bWVzc2FnZXMtMV8wLmh0bWw+LgoKICAgW1BlcnNvbmFdICBNb3ppbGxhLCAiTW96aWxsYSBQZXJz b25hIiwgQXByaWwgMjAxMy4KCiAgIFtSRkMyNjE2XSAgRmllbGRpbmcsIFIuLCBHZXR0eXMsIEou LCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLAogICAgICAgICAgICAgIE1hc2ludGVyLCBMLiwgTGVh Y2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICJIeXBlcnRleHQKICAgICAgICAgICAgICBUcmFu c2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5OTkuCgogICBbUkZD MjgxOF0gIFJlc2NvcmxhLCBFLiwgIkhUVFAgT3ZlciBUTFMiLCBSRkMgMjgxOCwgTWF5IDIwMDAu CgogICBbUkZDMzIwN10gIEhvZmZtYW4sIFAuLCAiU01UUCBTZXJ2aWNlIEV4dGVuc2lvbiBmb3Ig U2VjdXJlIFNNVFAgb3ZlcgogICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSIs IFJGQyAzMjA3LCBGZWJydWFyeSAyMDAyLgoKICAgW1JGQzM5MjNdICBTYWludC1BbmRyZSwgUC4s ICJFbmQtdG8tRW5kIFNpZ25pbmcgYW5kIE9iamVjdCBFbmNyeXB0aW9uCiAgICAgICAgICAgICAg Zm9yIHRoZSBFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQgUHJlc2VuY2UgUHJvdG9jb2wKICAgICAg ICAgICAgICAoWE1QUCkiLCBSRkMgMzkyMywgT2N0b2JlciAyMDA0LgoKICAgW1JGQzQzMDFdICBL ZW50LCBTLiBhbmQgSy4gU2VvLCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIGZvciB0aGUKICAgICAg ICAgICAgICBJbnRlcm5ldCBQcm90b2NvbCIsIFJGQyA0MzAxLCBEZWNlbWJlciAyMDA1LgoKICAg W1JGQzUyNDZdICBEaWVya3MsIFQuIGFuZCBFLiBSZXNjb3JsYSwgIlRoZSBUcmFuc3BvcnQgTGF5 ZXIgU2VjdXJpdHkKICAgICAgICAgICAgICAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiIsIFJG QyA1MjQ2LCBBdWd1c3QgMjAwOC4KCiAgIFtSRkM1MzIyXSAgUmVzbmljaywgUC4sIEVkLiwgIklu dGVybmV0IE1lc3NhZ2UgRm9ybWF0IiwgUkZDIDUzMjIsCiAgICAgICAgICAgICAgT2N0b2JlciAy MDA4LgoKICAgW1JGQzU3NTFdICBSYW1zZGVsbCwgQi4gYW5kIFMuIFR1cm5lciwgIlNlY3VyZS9N dWx0aXB1cnBvc2UgSW50ZXJuZXQKICAgICAgICAgICAgICBNYWlsIEV4dGVuc2lvbnMgKFMvTUlN RSkgVmVyc2lvbiAzLjIgTWVzc2FnZQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMg NTc1MSwgSmFudWFyeSAyMDEwLgoKICAgW1dTLUZlZGVyYXRpb25dCiAgICAgICAgICAgICAgS2Fs ZXIsIEMuLCBNY0ludG9zaCwgTS4sIEdvb2RuZXIsIE0uLCBhbmQgQS4gTmFkYWxpbiwKICAgICAg ICAgICAgICAiT3BlbklEIENvbm5lY3QgTWVzc2FnZXMgMS4wIiwgTWF5IDIwMDksIDxodHRwOi8v CiAgICAgICAgICAgICAgZG9jcy5vYXNpcy1vcGVuLm9yZy93c2ZlZC9mZWRlcmF0aW9uL3YxLjIv b3MvCiAgICAgICAgICAgICAgd3MtZmVkZXJhdGlvbi0xLjItc3BlYy1vcy5odG1sPi4KCgoKCgoK CkJhcm5lcyAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAg ICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgSk9TRSBVc2Ug Q2FzZXMgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxMwoKCkFwcGVuZGl4IEEuICBBY2tub3ds ZWRnZW1lbnRzCgogICBUaGFua3MgdG8gTWF0dCBNaWxsZXIgZm9yIGRpc2N1c3Npb25zIHJlbGF0 ZWQgdG8gWE1QUCBlbmQtdG8tZW5kCiAgIHNlY3VyaXR5IG1vZGVsLCBhbmQgdG8gTWlrZSBKb25l cyBmb3IgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0bwogICBzZWN1cml0eSB0b2tlbnMgYW5kIFhN TCBzZWN1cml0eS4gIFRoYW5rcyB0byBNYXJrIFdhdHNvbiBmb3IgcmFpc2luZwogICB0aGUgbmVl ZCBmb3IgcmVwcmVzZW50aW5nIHN5bW1ldHJpYyBrZXlzIGFuZCBiaW5kaW5nIGF0dHJpYnV0ZXMg dG8KICAgdGhlbS4KCgpBcHBlbmRpeCBCLiAgRG9jdW1lbnQgSGlzdG9yeQoKICAgW1sgdG8gYmUg cmVtb3ZlZCBieSB0aGUgUkZDIGVkaXRvciBiZWZvcmUgcHVibGljYXRpb24gYXMgYW4gUkZDIF1d CgogICAtMDEKCiAgIG8gIFJlZmVyZW5jZWQgdGhlIEpXUywgSldFLCBKV0ssIGFuZCBKV0Egc3Bl Y2lmaWNhdGlvbnMgbWFraW5nIHRoZQogICAgICAic2lnbmVkIG9iamVjdCBmb3JtYXQiLCAiZW5j cnlwdGVkIG9iamVjdCBmb3JtYXQiLCAia2V5IGZvcm1hdCIsCiAgICAgIGFuZCBhbGdvcml0aG1z IHJlc3VsdGluZyBmcm9tIHRoZXNlIHVzZSBjYXNlcyBjb25jcmV0ZS4KCiAgIG8gIEFkZGVkICJB cHBsaWNhdGlvbiBhbmQgUHJvdG9jb2wgUmVxdWlyZW1lbnRzIiBzZWN0aW9uLgoKICAgbyAgQnJv a2UgZm9ybWVyIGh1Z2UgIlNlY3VyaXR5IFRva2VucyBhbmQgQXV0aG9yaXphdGlvbiIgVXNlIENh c2UKICAgICAgc2VjdGlvbiBpbnRvICJTZWN1cml0eSBUb2tlbnMiLCAiT0F1dGgiLCBhbmQgIkZl ZGVyYXRpb24iIFVzZSBDYXNlCiAgICAgIHNlY3Rpb25zLgoKICAgbyAgQ2l0ZWQgTW96aWxsYSBQ ZXJzb25hIGFzIGEgc2luZ2xlLXNpZ24tb24gKFNTTykgc3lzdGVtIHVzaW5nIEpXVHMKICAgICAg YW5kIEpPU0UgZGF0YSBmb3JtYXRzLgoKICAgbyAgU3BlbGxpbmcgYW5kIGdyYW1tYXIgY29ycmVj dGlvbnMuCgogICAtMDAKCiAgIG8gIENyZWF0ZWQgdGhlIGluaXRpYWwgSUVURiBkcmFmdCBiYXNl ZCB1cG9uCiAgICAgIGRyYWZ0LWJhcm5lcy1qb3NlLXVzZS1jYXNlcy0wMSB3aXRoIHNvbWUgYWRk aXRpb25zLgoKCkF1dGhvcidzIEFkZHJlc3MKCiAgIFJpY2hhcmQgQmFybmVzCiAgIEJCTiBUZWNo bm9sb2dpZXMKICAgMTMwMCBOIDE3dGggU3QKICAgQXJsaW5ndG9uLCBWQSAgMjIyMDkKICAgVVMK CiAgIEVtYWlsOiBybGJAaXB2LnN4CgoKCgoKCkJhcm5lcyAgICAgICAgICAgICAgICAgIEV4cGly ZXMgT2N0b2JlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCg== --_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_ Content-Type: text/html; name="draft-ietf-jose-use-cases-00+Mike.html" Content-Description: draft-ietf-jose-use-cases-00+Mike.html Content-Disposition: attachment; filename="draft-ietf-jose-use-cases-00+Mike.html"; size=84919; creation-date="Sun, 28 Apr 2013 07:57:32 GMT"; modification-date="Sun, 28 Apr 2013 07:57:32 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+VXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgZm9yIEpTT04gT2Jq ZWN0CiAgICBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChKT1NFKTwvdGl0bGU+CjxtZXRhIGh0dHAt ZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4K PG1ldGEgbmFtZT0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IlVzZSBDYXNlcyBhbmQgUmVxdWlyZW1l bnRzIGZvciBKU09OIE9iamVjdAogICAgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoSk9TRSkiPgo8 bWV0YSBuYW1lPSJrZXl3b3JkcyIgY29udGVudD0iSldTLCBKV0UsIEpXSywgSldBLCBKV1QsIENN UywgUy9NSU1FLCBKT1NFLCBYTVBQLCBBTFRPLCBPQXV0aCI+CjxtZXRhIG5hbWU9ImdlbmVyYXRv ciIgY29udGVudD0ieG1sMnJmYyB2MS4zNiAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvKSI+Cjxz dHlsZSB0eXBlPSd0ZXh0L2Nzcyc+PCEtLQogICAgICAgIGJvZHkgewogICAgICAgICAgICAgICAg Zm9udC1mYW1pbHk6IHZlcmRhbmEsIGNoYXJjb2FsLCBoZWx2ZXRpY2EsIGFyaWFsLCBzYW5zLXNl cmlmOwogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsgY29sb3I6ICMwMDA7IGJhY2tn cm91bmQtY29sb3I6ICNGRkY7CiAgICAgICAgICAgICAgICBtYXJnaW46IDJlbTsKICAgICAgICB9 CiAgICAgICAgaDEsIGgyLCBoMywgaDQsIGg1LCBoNiB7CiAgICAgICAgICAgICAgICBmb250LWZh bWlseTogaGVsdmV0aWNhLCBtb25hY28sICJNUyBTYW5zIFNlcmlmIiwgYXJpYWwsIHNhbnMtc2Vy aWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgZm9udC1zdHlsZTogbm9ybWFs OwogICAgICAgIH0KICAgICAgICBoMSB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgdGV4dC1hbGlnbjogcmlnaHQ7IH0KICAgICAgICBoMyB7IGNvbG9yOiAjMzMz OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQoKICAgICAgICB0ZC5SRkNidWcgewog ICAgICAgICAgICAgICAgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 CiAgICAgICAgICAgICAgICB3aWR0aDogMzBweDsgaGVpZ2h0OiAzMHB4OyBwYWRkaW5nLXRvcDog MnB4OwogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjoganVzdGlmeTsgdmVydGljYWwtYWxpZ246 IG1pZGRsZTsKICAgICAgICAgICAgICAgIGJhY2tncm91bmQtY29sb3I6ICMwMDA7CiAgICAgICAg fQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLlJGQyB7CiAgICAgICAgICAgICAgICBmb250LWZhbWls eTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwg dmVyZGFuYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBj b2xvcjogIzY2NjsKICAgICAgICB9CiAgICAgICAgdGQuUkZDYnVnIHNwYW4uaG90VGV4dCB7CiAg ICAgICAgICAgICAgICBmb250LWZhbWlseTogY2hhcmNvYWwsIG1vbmFjbywgZ2VuZXZhLCAiTVMg U2FucyBTZXJpZiIsIGhlbHZldGljYSwgdmVyZGFuYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAg ICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IHRleHQtYWxpZ246IGNlbnRlcjsgY29sb3I6ICNGRkY7 CiAgICAgICAgfQoKICAgICAgICB0YWJsZS5UT0NidWcgeyB3aWR0aDogMzBweDsgaGVpZ2h0OiAx NXB4OyB9CiAgICAgICAgdGQuVE9DYnVnIHsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGNl bnRlcjsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVweDsKICAgICAgICAgICAgICAgIGNvbG9yOiAj RkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjOTAwOwogICAgICAgIH0KICAgICAgICB0ZC5UT0NidWcg YSB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFyY29hbCwgZ2VuZXZh LCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAg IGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXNpemU6IHgtc21hbGw7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsKICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFu c3BhcmVudDsKICAgICAgICB9CgogICAgICAgIHRkLmhlYWRlciB7CiAgICAgICAgICAgICAgICBm b250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiB4LXNt YWxsOwogICAgICAgICAgICAgICAgdmVydGljYWwtYWxpZ246IHRvcDsgd2lkdGg6IDMzJTsKICAg ICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjNjY2OwogICAgICAg IH0KICAgICAgICB0ZC5hdXRob3IgeyBmb250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNt YWxsOyBtYXJnaW4tbGVmdDogNGVtOyB9CiAgICAgICAgdGQuYXV0aG9yLXRleHQgeyBmb250LXNp emU6IHgtc21hbGw7IH0KCiAgICAgICAgLyogaW5mbyBjb2RlIGZyb20gU2FudGFLbGF1c3MgYXQg aHR0cDovL3d3dy5tYWRhYm91dHN0eWxlLmNvbS90b29sdGlwMi5odG1sICovCiAgICAgICAgYS5p bmZvIHsKICAgICAgICAgICAgICAgIC8qIFRoaXMgaXMgdGhlIGtleS4gKi8KICAgICAgICAgICAg ICAgIHBvc2l0aW9uOiByZWxhdGl2ZTsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI0OwogICAg ICAgICAgICAgICAgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgIH0KICAgICAgICBhLmlu Zm86aG92ZXIgewogICAgICAgICAgICAgICAgei1pbmRleDogMjU7CiAgICAgICAgICAgICAgICBj b2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgYS5p bmZvIHNwYW4geyBkaXNwbGF5OiBub25lOyB9CiAgICAgICAgYS5pbmZvOmhvdmVyIHNwYW4uaW5m byB7CiAgICAgICAgICAgICAgICAvKiBUaGUgc3BhbiB3aWxsIGRpc3BsYXkganVzdCBvbiA6aG92 ZXIgc3RhdGUuICovCiAgICAgICAgICAgICAgICBkaXNwbGF5OiBibG9jazsKICAgICAgICAgICAg ICAgIHBvc2l0aW9uOiBhYnNvbHV0ZTsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGxl cjsKICAgICAgICAgICAgICAgIHRvcDogMmVtOyBsZWZ0OiAtNWVtOyB3aWR0aDogMTVlbTsKICAg ICAgICAgICAgICAgIHBhZGRpbmc6IDJweDsgYm9yZGVyOiAxcHggc29saWQgIzMzMzsKICAgICAg ICAgICAgICAgIGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOwogICAgICAgICAg ICAgICAgdGV4dC1hbGlnbjogbGVmdDsKICAgICAgICB9CgogICAgICAgIGEgeyBmb250LXdlaWdo dDogYm9sZDsgfQogICAgICAgIGE6bGluayAgICB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNv bG9yOiB0cmFuc3BhcmVudDsgfQogICAgICAgIGE6dmlzaXRlZCB7IGNvbG9yOiAjNjMzOyBiYWNr Z3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQogICAgICAgIGE6YWN0aXZlICB7IGNvbG9yOiAj NjMzOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQoKICAgICAgICBwIHsgbWFyZ2lu LWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBwLmNvcHlyaWdodCB7IGZv bnQtc2l6ZTogeC1zbWFsbDsgfQogICAgICAgIHAudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9u dC13ZWlnaHQ6IGJvbGQ7IG1hcmdpbi1sZWZ0OiAzZW07IH0KICAgICAgICB0YWJsZS50b2MgeyBt YXJnaW46IDAgMCAwIDNlbTsgcGFkZGluZzogMDsgYm9yZGVyOiAwOyB2ZXJ0aWNhbC1hbGlnbjog dGV4dC10b3A7IH0KICAgICAgICB0ZC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdo dDogYm9sZDsgdmVydGljYWwtYWxpZ246IHRleHQtdG9wOyB9CgogICAgICAgIG9sLnRleHQgeyBt YXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIHVsLnRleHQgeyBt YXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQogICAgICAgIGxpICAgICAgeyBt YXJnaW4tbGVmdDogM2VtOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDxzcGFueD5zIGFuZCA8YXJ0 d29yaz5zLiAqLwogICAgICAgIGVtICAgICB7IGZvbnQtc3R5bGU6IGl0YWxpYzsgfQogICAgICAg IHN0cm9uZyB7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAgZGZuICAgIHsgZm9udC13ZWln aHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQogICAgICAgIGNpdGUgICB7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQogICAgICAgIHR0ICAgICB7IGNvbG9y OiAjMDM2OyB9CiAgICAgICAgdHQsIHByZSwgcHJlIGRmbiwgcHJlIGVtLCBwcmUgY2l0ZSwgcHJl IHNwYW4gewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6ICJDb3VyaWVyIE5ldyIsIENvdXJp ZXIsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsKICAgICAgICB9CiAgICAgICAgcHJlIHsK ICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGxlZnQ7IHBhZGRpbmc6IDRweDsKICAgICAgICAg ICAgICAgIGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAgIH0KICAg ICAgICBwcmUgZGZuICB7IGNvbG9yOiAjOTAwOyB9CiAgICAgICAgcHJlIGVtICAgeyBjb2xvcjog IzY2RjsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQzsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgfQogICAg ICAgIHByZSAua2V5IHsgY29sb3I6ICMzM0M7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAg cHJlIC5pZCAgeyBjb2xvcjogIzkwMDsgfQogICAgICAgIHByZSAuc3RyIHsgY29sb3I6ICMwMDA7 IGJhY2tncm91bmQtY29sb3I6ICNDRkY7IH0KICAgICAgICBwcmUgLnZhbCB7IGNvbG9yOiAjMDY2 OyB9CiAgICAgICAgcHJlIC5yZXAgeyBjb2xvcjogIzkwOTsgfQogICAgICAgIHByZSAub3RoIHsg Y29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNGQ0Y7IH0KICAgICAgICBwcmUgLmVyciB7 IGJhY2tncm91bmQtY29sb3I6ICNGQ0M7IH0KCiAgICAgICAgLyogUkZDLTI2MjkgPHRleHR0YWJs ZT5zLiAqLwogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCwgdGFibGUuaGVhZGVycywgdGFi bGUubm9uZSB7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsOyB0ZXh0LWFsaWduOiBj ZW50ZXI7IGJvcmRlci13aWR0aDogMnB4OwogICAgICAgICAgICAgICAgdmVydGljYWwtYWxpZ246 IHRvcDsgYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZTsKICAgICAgICB9CiAgICAgICAgdGFibGUu YWxsLCB0YWJsZS5mdWxsIHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsgYm9yZGVyLWNvbG9yOiBibGFj azsgfQogICAgICAgIHRhYmxlLmhlYWRlcnMsIHRhYmxlLm5vbmUgeyBib3JkZXItc3R5bGU6IG5v bmU7IH0KICAgICAgICB0aCB7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgYm9y ZGVyLWNvbG9yOiBibGFjazsKICAgICAgICAgICAgICAgIGJvcmRlci13aWR0aDogMnB4IDJweCAz cHggMnB4OwogICAgICAgIH0KICAgICAgICB0YWJsZS5hbGwgdGgsIHRhYmxlLmZ1bGwgdGggeyBi b3JkZXItc3R5bGU6IHNvbGlkOyB9CiAgICAgICAgdGFibGUuaGVhZGVycyB0aCB7IGJvcmRlci1z dHlsZTogbm9uZSBub25lIHNvbGlkIG5vbmU7IH0KICAgICAgICB0YWJsZS5ub25lIHRoIHsgYm9y ZGVyLXN0eWxlOiBub25lOyB9CiAgICAgICAgdGFibGUuYWxsIHRkIHsKICAgICAgICAgICAgICAg IGJvcmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogIzMzMzsKICAgICAgICAgICAgICAg IGJvcmRlci13aWR0aDogMXB4IDJweDsKICAgICAgICB9CiAgICAgICAgdGFibGUuZnVsbCB0ZCwg dGFibGUuaGVhZGVycyB0ZCwgdGFibGUubm9uZSB0ZCB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQoK ICAgICAgICBociB7IGhlaWdodDogMXB4OyB9CiAgICAgICAgaHIuaW5zZXJ0IHsKICAgICAgICAg ICAgICAgIHdpZHRoOiA4MCU7IGJvcmRlci1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiAwOwog ICAgICAgICAgICAgICAgY29sb3I6ICNDQ0M7IGJhY2tncm91bmQtY29sb3I6ICNDQ0M7CiAgICAg ICAgfQotLT48L3N0eWxlPgo8L2hlYWQ+Cjxib2R5Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSI2NiUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkPjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIy IiBjZWxsc3BhY2luZz0iMSI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Sk9TRTwvdGQ+PHRkIGNs YXNzPSJoZWFkZXIiPlIuIEJhcm5lczwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5J bnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkJCTiBUZWNobm9sb2dpZXM8L3Rk PjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+SW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlv bmFsPC90ZD48dGQgY2xhc3M9ImhlYWRlciI+QXByaWwgMjgsIDIwMTM8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImhlYWRlciI+RXhwaXJlczogT2N0b2JlciAzMCwgMjAxMzwvdGQ+PHRkIGNsYXNz PSJoZWFkZXIiPiZuYnNwOzwvdGQ+PC90cj4KPC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KPGgx PjxiciAvPlVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIGZvciBKU09OIE9iamVjdAogICAgU2ln bmluZyBhbmQgRW5jcnlwdGlvbiAoSk9TRSk8YnIgLz5kcmFmdC1pZXRmLWpvc2UtdXNlLWNhc2Vz LTAxPC9oMT4KCjxoMz5BYnN0cmFjdDwvaDM+Cgo8cD5NYW55IEludGVybmV0IGFwcGxpY2F0aW9u cyBoYXZlIGEgbmVlZCBmb3Igb2JqZWN0LWJhc2VkIHNlY3VyaXR5CiAgICAgIG1lY2hhbmlzbXMg aW4gYWRkaXRpb24gdG8gc2VjdXJpdHkgbWVjaGFuaXNtcyBhdCB0aGUgbmV0d29yayBsYXllciBv cgogICAgICB0cmFuc3BvcnQgbGF5ZXIuIEluIHRoZSBwYXN0LCB0aGUgQ3J5cHRvZ3JhcGhpYyBN ZXNzYWdlIFN5bnRheCBoYXMKICAgICAgcHJvdmlkZWQgYSBiaW5hcnkgc2VjdXJlIG9iamVjdCBm b3JtYXQgYmFzZWQgb24gQVNOLjEuIE92ZXIgdGltZSwgdGhlCiAgICAgIHVzZSBvZiBiaW5hcnkg b2JqZWN0IGVuY29kaW5ncyBzdWNoIGFzIEFTTi4xIGhhcyBiZWVuIG92ZXJ0YWtlbiBieQogICAg ICB0ZXh0LWJhc2VkIGVuY29kaW5ncywgZm9yIGV4YW1wbGUgSmF2YVNjcmlwdCBPYmplY3QgTm90 YXRpb24uIFRoaXMKICAgICAgZG9jdW1lbnQgZGVmaW5lcyBhIHNldCBvZiB1c2UgY2FzZXMgYW5k IHJlcXVpcmVtZW50cyBmb3IgYSBzZWN1cmUgb2JqZWN0CiAgICAgIGZvcm1hdCBlbmNvZGVkIHVz aW5nIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uLCBkcmF3biBmcm9tIGEgdmFyaWV0eSBvZgog ICAgICBhcHBsaWNhdGlvbiBzZWN1cml0eSBtZWNoYW5pc21zIGN1cnJlbnRseSBpbiBkZXZlbG9w bWVudC4KPC9wPgo8aDM+U3RhdHVzIG9mIHRoaXMgTWVtbzwvaDM+CjxwPgpUaGlzIEludGVybmV0 LURyYWZ0IGlzIHN1Ym1pdHRlZCAgaW4gZnVsbApjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNp b25zIG9mIEJDUCZuYnNwOzc4IGFuZCBCQ1AmbmJzcDs3OS48L3A+CjxwPgpJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwpUYXNr IEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZQp3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJy ZW50CkludGVybmV0LURyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwphbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLgpJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGVy aWFsIG9yIHRvIGNpdGUKdGhlbSBvdGhlciB0aGFuIGFzICZsZHF1bzt3b3JrIGluIHByb2dyZXNz LiZyZHF1bzs8L3A+CjxwPgpUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE9jdG9i ZXIgMzAsIDIwMTMuPC9wPgoKPGgzPkNvcHlyaWdodCBOb3RpY2U8L2gzPgo8cD4KQ29weXJpZ2h0 IChjKSAyMDEzIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCmRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvcD4KPHA+ClRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwooaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKcHVibGljYXRpb24gb2YgdGhp cyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCmNhcmVmdWxseSwgYXMg dGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAp0 byB0aGlzIGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1 bWVudCBtdXN0CmluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDQuZSBvZgp0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHBy b3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLjwvcD4KPGEgbmFtZT0idG9jIj48L2E+PGJyIC8+PGhyIC8+CjxoMz5UYWJsZSBv ZiBDb250ZW50czwvaDM+CjxwIGNsYXNzPSJ0b2MiPgo8YSBocmVmPSIjaW50cm8tc2VjIj4xLjwv YT4mbmJzcDsKSW50cm9kdWN0aW9uPGJyIC8+CjxhIGhyZWY9IiNkZWYtc2VjIj4yLjwvYT4mbmJz cDsKRGVmaW5pdGlvbnM8YnIgLz4KPGEgaHJlZj0iI2Jhc2ljLXNlYyI+My48L2E+Jm5ic3A7CkJh c2ljIFJlcXVpcmVtZW50czxiciAvPgo8YSBocmVmPSIjYXBwLXJlcS1zZWMiPjQuPC9hPiZuYnNw OwpBcHBsaWNhdGlvbiBhbmQgUHJvdG9jb2wgUmVxdWlyZW1lbnRzPGJyIC8+CjxhIGhyZWY9IiN1 c2UtY2FzZXMtc2VjIj41LjwvYT4mbmJzcDsKVXNlIENhc2VzPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNzZWMtdG9rZW4tc2VjIj41LjEuPC9hPiZuYnNwOwpTZWN1cml0 eSBUb2tlbnM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI29hdXRoLXNl YyI+NS4yLjwvYT4mbmJzcDsKT0F1dGg8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2ZlZC1zZWN0aW9uIj41LjMuPC9hPiZuYnNwOwpGZWRlcmF0aW9uPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN4bXBwLXNlYyI+NS40LjwvYT4mbmJzcDsKWE1Q UDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYWx0by1zZWMiPjUuNS48 L2E+Jm5ic3A7CkFMVE88YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2F0 b2NhLXNlYyI+NS42LjwvYT4mbmJzcDsKRW1lcmdlbmN5IEFsZXJ0aW5nPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN3ZWJjcnlwdG8tc2VjIj41LjcuPC9hPiZuYnNwOwpX ZWIgQ3J5cHRvZ3JhcGh5PGJyIC8+CjxhIGhyZWY9IiNyZXEtc2VjIj42LjwvYT4mbmJzcDsKUmVx dWlyZW1lbnRzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNmdW5jdGlv bmFsLXNlYyI+Ni4xLjwvYT4mbmJzcDsKRnVuY3Rpb25hbCBSZXF1aXJlbWVudHM8YnIgLz4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3NlYy1yZXEtc2VjIj42LjIuPC9hPiZuYnNw OwpTZWN1cml0eSBSZXF1aXJlbWVudHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2Rlc2lkZXJhdGEtc2VjIj42LjMuPC9hPiZuYnNwOwpEZXNpZGVyYXRhPGJyIC8+Cjxh IGhyZWY9IiNpYW5hLXNlYyI+Ny48L2E+Jm5ic3A7CklBTkEgQ29uc2lkZXJhdGlvbnM8YnIgLz4K PGEgaHJlZj0iI3NlYy1jb25zLXNlYyI+OC48L2E+Jm5ic3A7ClNlY3VyaXR5IENvbnNpZGVyYXRp b25zPGJyIC8+CjxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczEiPjkuPC9hPiZuYnNwOwpSZWZlcmVu Y2VzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZmMucmVmZXJlbmNl czEiPjkuMS48L2E+Jm5ic3A7Ck5vcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczIiPjkuMi48L2E+Jm5ic3A7Cklu Zm9ybWF0aXZlIFJlZmVyZW5jZXM8YnIgLz4KPGEgaHJlZj0iI2Fjay1zZWMiPkFwcGVuZGl4Jm5i c3A7QS48L2E+Jm5ic3A7CkFja25vd2xlZGdlbWVudHM8YnIgLz4KPGEgaHJlZj0iI2hpc3Qtc2Vj Ij5BcHBlbmRpeCZuYnNwO0IuPC9hPiZuYnNwOwpEb2N1bWVudCBIaXN0b3J5PGJyIC8+CjxhIGhy ZWY9IiNyZmMuYXV0aG9ycyI+JiMxNjc7PC9hPiZuYnNwOwpBdXRob3IncyBBZGRyZXNzPGJyIC8+ CjwvcD4KPGJyIGNsZWFyPSJhbGwiIC8+Cgo8YSBuYW1lPSJpbnRyby1zZWMiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4xIj48L2E+PGgzPjEuJm5ic3A7CkludHJvZHVjdGlvbjwvaDM+Cgo8 cD5JbnRlcm5ldCBhcHBsaWNhdGlvbnMgcmVzdCBvbiB0aGUgbGF5ZXJlZCBhcmNoaXRlY3R1cmUg b2YgdGhlCiAgICAgIEludGVybmV0LCBhbmQgdGFrZSBhZHZhbnRhZ2Ugb2Ygc2VjdXJpdHkgbWVj aGFuaXNtcyBhdCBhbGwgbGF5ZXJzLiBNYW55CiAgICAgIGFwcGxpY2F0aW9ucyByZWx5IHByaW1h cmlseSBvbiBjaGFubmVsLWJhc2VkIHNlY3VyaXR5IHRlY2hub2xvZ2llcywKICAgICAgd2hpY2gg Y3JlYXRlIGEgc2VjdXJlIGNoYW5uZWwgYXQgdGhlIElQIGxheWVyIG9yIHRyYW5zcG9ydCBsYXll ciBvdmVyCiAgICAgIHdoaWNoIGFwcGxpY2F0aW9uIGRhdGEgY2FuIGZsb3cgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNSRkM0MzAxJz5bUkZDNDMwMV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+S2VudCwgUy4gYW5kIEsuIFNlbywgJmxkcXVvO1NlY3VyaXR5IEFyY2hpdGVjdHVyZSBm b3IgdGhlIEludGVybmV0IFByb3RvY29sLCZyZHF1bzsgRGVjZW1iZXImbmJzcDsyMDA1Ljwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT48YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzUyNDYnPltSRkM1 MjQ2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EaWVya3MsIFQuIGFuZCBFLiBS ZXNjb3JsYSwgJmxkcXVvO1RoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgUHJvdG9j b2wgVmVyc2lvbiAxLjIsJnJkcXVvOyBBdWd1c3QmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uIFRoZXNlIG1lY2hhbmlzbXMsIGhvd2V2ZXIsIGNhbm5vdCBwcm92aWRlIGVuZC10 by1lbmQKICAgICAgc2VjdXJpdHkgaW4gc29tZSBjYXNlcy4gRm9yIGV4YW1wbGUsIGluIHByb3Rv Y29scyB3aXRoIGFwcGxpY2F0aW9uLWxheWVyCiAgICAgIGludGVybWVkaWFyaWVzLCBjaGFubmVs LWJhc2VkIHNlY3VyaXR5IHByb3RvY29scyB3b3VsZCBwcm90ZWN0IG1lc3NhZ2VzCiAgICAgIGZy b20gYXR0YWNrZXJzIGJldHdlZW4gaW50ZXJtZWRpYXJpZXMsIGJ1dCBub3QgZnJvbSB0aGUgaW50 ZXJtZWRpYXJpZXMKICAgICAgdGhlbXNlbHZlcy4gVGhlc2UgY2FzZXMgcmVxdWlyZSBvYmplY3Qt YmFzZWQgc2VjdXJpdHkgdGVjaG5vbG9naWVzLAogICAgICB3aGljaCBlbWJlZCBhcHBsaWNhdGlv biBkYXRhIHdpdGhpbiBhIHNlY3VyZSBvYmplY3QgdGhhdCBjYW4gYmUgc2FmZWx5CiAgICAgIGhh bmRsZWQgYnkgdW50cnVzdGVkIGVudGl0aWVzLgo8L3A+CjxwPlRoZSBtb3N0IHdlbGwta25vd24g ZXhhbXBsZSBvZiBzdWNoIGEgcHJvdG9jb2wgdG9kYXkgaXMgdGhlIHVzZSBvZgogICAgICBTZWN1 cmUvTXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwgRXh0ZW5zaW9ucyAoUy9NSU1FKSBwcm90ZWN0 aW9ucyB3aXRoaW4KICAgICAgdGhlIGVtYWlsIHN5c3RlbSA8YSBjbGFzcz0naW5mbycgaHJlZj0n I1JGQzU3NTEnPltSRkM1NzUxXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SYW1z ZGVsbCwgQi4gYW5kIFMuIFR1cm5lciwgJmxkcXVvO1NlY3VyZS9NdWx0aXB1cnBvc2UgSW50ZXJu ZXQgTWFpbCBFeHRlbnNpb25zIChTL01JTUUpIFZlcnNpb24gMy4yIE1lc3NhZ2UgU3BlY2lmaWNh dGlvbiwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT48 YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzUzMjInPltSRkM1MzIyXTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5SZXNuaWNrLCBQLiwgRWQuLCAmbGRxdW87SW50ZXJuZXQgTWVzc2Fn ZSBGb3JtYXQsJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAwOC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LiBBbgogICAgICBlbWFpbCBtZXNzYWdlIHR5cGljYWxseSBwYXNzZXMgdGhyb3VnaCBhIHNl cmllcyBvZiBpbnRlcm1lZGlhdGUgTWFpbAogICAgICBUcmFuc2ZlciBBZ2VudHMgKE1UQXMpIGVu IHJvdXRlIHRvIGl0cyBkZXN0aW5hdGlvbi4gV2hpbGUgdGhlc2UgTVRBcwogICAgICBvZnRlbiBh cHBseSBjaGFubmVsLWJhc2VkIHNlY3VyaXR5IHByb3RlY3Rpb25zIHRvIHRoZWlyIGludGVyYWN0 aW9ucwogICAgICAoZS5nLiwgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMjA3Jz5bUkZDMzIw N108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9mZm1hbiwgUC4sICZsZHF1bztT TVRQIFNlcnZpY2UgRXh0ZW5zaW9uIGZvciBTZWN1cmUgU01UUCBvdmVyIFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eSwmcmRxdW87IEZlYnJ1YXJ5Jm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+KSwgdGhlc2UgcHJvdGVjdGlvbnMgZG8gbm90IHByZXZlbnQgdGhlCiAgICAgIE1UQXMg ZnJvbSBpbnRlcmZlcmluZyB3aXRoIHRoZSBtZXNzYWdlLiBJbiBvcmRlciB0byBwcm92aWRlIGVu ZC10by1lbmQKICAgICAgc2VjdXJpdHkgcHJvdGVjdGlvbnMgaW4gdGhlIHByZXNlbmNlIG9mIHVu dHJ1c3RlZCBNVEFzLCBtYWlsIHVzZXJzIGNhbgogICAgICB1c2UgUy9NSU1FIHRvIGVtYmVkIG1l c3NhZ2UgYm9kaWVzIGluIGEgc2VjdXJlIG9iamVjdCBmb3JtYXQgdGhhdCBjYW4KICAgICAgcHJv dmlkZSBjb25maWRlbnRpYWxpdHksIGludGVncml0eSwgYW5kIGRhdGEgb3JpZ2luIGF1dGhlbnRp Y2F0aW9uLgo8L3A+CjxwPlMvTUlNRSBpcyBiYXNlZCBvbiB0aGUgQ3J5cHRvZ3JhcGhpYyBNZXNz YWdlIFN5bnRheCBmb3Igc2VjdXJlCiAgICAgIG9iamVjdHMgKENNUykgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNSRkM1NjUyJz5bUkZDNTY1Ml08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+SG91c2xleSwgUi4sICZsZHF1bztDcnlwdG9ncmFwaGljIE1lc3NhZ2UgU3ludGF4IChDTVMp LCZyZHF1bzsgU2VwdGVtYmVyJm5ic3A7MjAwOS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBD TVMgaXMgZGVmaW5lZCB1c2luZyBBYnN0cmFjdAogICAgICBTeW50YXggTm90YXRpb24gMSAoQVNO LjEpIGFuZCB0cmFkaXRpb25hbGx5IGVuY29kZWQgdXNpbmcgdGhlIEFTTi4xCiAgICAgIERpc3Rp bmd1aXNoZWQgRW5jb2RpbmcgUnVsZXMgKERFUiksIHdoaWNoIGRlZmluZSBhIGJpbmFyeSBlbmNv ZGluZyBvZgogICAgICB0aGUgcHJvdGVjdGVkIG1lc3NhZ2UgYW5kIGFzc29jaWF0ZWQgcGFyYW1l dGVycyA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0lUVS5YNjkwLjE5OTQnPltJVFUuWDY5MC4xOTk0 XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5JbnRlcm5hdGlvbmFsIFRlbGVjb21t dW5pY2F0aW9ucyBVbmlvbiwgJmxkcXVvO0luZm9ybWF0aW9uIFRlY2hub2xvZ3kgLSBBU04uMSBl bmNvZGluZyBydWxlczogU3BlY2lmaWNhdGlvbiBvZiBCYXNpYyBFbmNvZGluZyBSdWxlcyAoQkVS KSwgQ2Fub25pY2FsIEVuY29kaW5nIFJ1bGVzIChDRVIpIGFuZCBEaXN0aW5ndWlzaGVkIEVuY29k aW5nIFJ1bGVzIChERVIpLCZyZHF1bzsgMTk5NC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBJ biByZWNlbnQgeWVhcnMsIHVzYWdlIG9mIEFTTi4xIGhhcyBkZWNyZWFzZWQKICAgICAgKGFsb25n IHdpdGggb3RoZXIgYmluYXJ5IGVuY29kaW5ncyBmb3IgZ2VuZXJhbCBvYmplY3RzKSwgd2hpbGUg bW9yZQogICAgICBhcHBsaWNhdGlvbnMgaGF2ZSBjb21lIHRvIHJlbHkgb24gdGV4dC1iYXNlZCBm b3JtYXRzIHN1Y2ggYXMgdGhlCiAgICAgIEV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlIChYTUwp IG9yIHRoZSBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbgogICAgICAoSlNPTikgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNXM0MuUkVDLXhtbC0xOTk4Jz5bVzNDLlJFQyYjODIwOTt4bWwmIzgyMDk7 MTk5OF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QnJheSwgVC4sIFBhb2xpLCBK LiwgYW5kIEMuIFNwZXJiZXJnLU1jUXVlZW4sICZsZHF1bztFeHRlbnNpYmxlIE1hcmt1cCBMYW5n dWFnZSAoWE1MKSAxLjAsJnJkcXVvOyBGZWJydWFyeSZuYnNwOzE5OTguPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPjxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNDYyNyc+W1JGQzQ2MjddPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNyb2NrZm9yZCwgRC4sICZsZHF1bztUaGUgYXBw bGljYXRpb24vanNvbiBNZWRpYSBUeXBlIGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAo SlNPTiksJnJkcXVvOyBKdWx5Jm5ic3A7MjAwNi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8 L3A+CjxwPk1hbnkgY3VycmVudCBhcHBsaWNhdGlvbnMgdGh1cyBoYXZlIG11Y2ggbW9yZSByb2J1 c3Qgc3VwcG9ydCBmb3IKICAgICAgcHJvY2Vzc2luZyBvYmplY3RzIGluIHRoZXNlIHRleHQtYmFz ZWQgZm9ybWF0cyB0aGFuIEFTTi4xIG9iamVjdHM7CiAgICAgIGluZGVlZCwgbWFueSBsYWNrIHRo ZSBhYmlsaXR5IHRvIHByb2Nlc3MgQVNOLjEgb2JqZWN0cyBhdCBhbGwuIFRvCiAgICAgIHNpbXBs aWZ5IHRoZSBhZGRpdGlvbiBvZiBvYmplY3QtYmFzZWQgc2VjdXJpdHkgZmVhdHVyZXMgdG8gdGhl c2UKICAgICAgYXBwbGljYXRpb25zLCB0aGUgSUVURiBKU09OIE9iamVjdCBTaWduaW5nIGFuZCBF bmNyeXB0aW9uIChKT1NFKSB3b3JraW5nCiAgICAgIGdyb3VwIGhhcyBiZWVuIGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIGEgc2VjdXJlIG9iamVjdCBmb3JtYXQgYmFzZWQgb24KICAgICAgSlNPTi4gV2hp bGUgdGhlIGJhc2ljIHJlcXVpcmVtZW50cyBmb3IgdGhpcyBvYmplY3QgZm9ybWF0IGFyZQogICAg ICBzdHJhaWdodGZvcndhcmQgLS0gbmFtZWx5LCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0 eSBtZWNoYW5pc21zLAogICAgICBlbmNvZGVkIGluIEpTT04gLS0gZGlzY3Vzc2lvbnMgaW4gdGhl IHdvcmtpbmcgZ3JvdXAgaW5kaWNhdGVkIHRoYXQKICAgICAgZGlmZmVyZW50IGFwcGxpY2F0aW9u cyBob3BpbmcgdG8gdXNlIHRoZSBmb3JtYXRzIGRlZmluZWQgYnkgSk9TRSBoYXZlCiAgICAgIGRp ZmZlcmVudCByZXF1aXJlbWVudHMuIFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyB0aGUgdXNlIGNh c2VzIGZvciBKT1NFCiAgICAgIGVudmlzaW9uZWQgYnkgdGhvc2UgcG90ZW50aWFsIGFwcGxpY2F0 aW9ucyBhbmQgdGhlIHJlc3VsdGluZyByZXF1aXJlbWVudHMgZm9yCiAgICAgIHNlY3VyaXR5IG1l Y2hhbmlzbXMgYW5kIG9iamVjdCBlbmNvZGluZ3MuCjwvcD4KPHA+U29tZSBzeXN0ZW1zIHRoYXQg dXNlIFhNTCBoYXZlIHNwZWNpZmllZCB0aGUgdXNlIG9mIFhNTC1iYXNlZAogICAgICBzZWN1cml0 eSBtZWNoYW5pc21zIGZvciBvYmplY3Qgc2VjdXJpdHksIG5hbWVseSBYTUwgRGlnaXRhbCBTaWdu YXR1cmVzCiAgICAgIGFuZCBYTUwgRW5jcnlwdGlvbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1cz Qy5DUi14bWxkc2lnLWNvcmUyLTIwMTIwMTI0Jz5bVzNDLkNSJiM4MjA5O3htbGRzaWcmIzgyMDk7 Y29yZTImIzgyMDk7MjAxMjAxMjRdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVh c3RsYWtlLCBELiwgUmVhZ2xlLCBKLiwgWWl1LCBLLiwgU29sbywgRC4sIERhdHRhLCBQLiwgSGly c2NoLCBGLiwgQ2FudG9yLCBTLiwgYW5kIFQuIFJvZXNzbGVyLCAmbGRxdW87WE1MIFNpZ25hdHVy ZSBTeW50YXggYW5kIFByb2Nlc3NpbmcgVmVyc2lvbiAyLjAsJnJkcXVvOyBKYW51YXJ5Jm5ic3A7 MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNXM0Mu Q1IteG1sZW5jLWNvcmUxLTIwMTIwMzEzJz5bVzNDLkNSJiM4MjA5O3htbGVuYyYjODIwOTtjb3Jl MSYjODIwOTsyMDEyMDMxM108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RWFzdGxh a2UsIEQuLCBSZWFnbGUsIEouLCBSb2Vzc2xlciwgVC4sIGFuZCBGLiBIaXJzY2gsICZsZHF1bztY TUwgRW5jcnlwdGlvbiBTeW50YXggYW5kIFByb2Nlc3NpbmcgVmVyc2lvbiAxLjEsJnJkcXVvOyBN YXJjaCZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gVGhlc2UgbWVjaGFuaXNt cyBhcmUgZGVmaW5lZAogICAgICBmb3IgdXNlIHdpdGggc2V2ZXJhbCBzZWN1cml0eSB0b2tlbiBz eXN0ZW1zIChlLmcuLAogICAgICBTQU1MIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjT0FTSVMuc2Ft bC1jb3JlLTIuMC1vcyc+W09BU0lTLnNhbWwmIzgyMDk7Y29yZSYjODIwOTsyLjAmIzgyMDk7b3Nd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNhbnRvciwgUy4sIEtlbXAsIEouLCBQ aGlscG90dCwgUi4sIGFuZCBFLiBNYWxlciwgJmxkcXVvO0Fzc2VydGlvbnMgYW5kIFByb3RvY29s IGZvciB0aGUgT0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAgICAgICAg ICAgICAoU0FNTCkgVjIuMCwmcmRxdW87IE1hcmNoJm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+IGFuZAogICAgICBXUy1GZWRlcmF0aW9uIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj V1MtRmVkZXJhdGlvbic+W1dTJiM4MjA5O0ZlZGVyYXRpb25dPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkthbGVyLCBDLiwgTWNJbnRvc2gsIE0uLCBHb29kbmVyLCBNLiwgYW5kIEEu IE5hZGFsaW4sICZsZHF1bztPcGVuSUQgQ29ubmVjdCBNZXNzYWdlcyAxLjAsJnJkcXVvOyBNYXkm bmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIGFuZCB0aGUgQ0FQCiAgICAgIGVt ZXJnZW5jeSBhbGVydGluZyBmb3JtYXQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNDQVAnPltDQVBd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJvdHRlcmVsbCwgQS4gYW5kIEUuIEpv bmVzLCAmbGRxdW87Q29tbW9uIEFsZXJ0aW5nIFByb3RvY29sIHYxLjEsJnJkcXVvOyBPY3RvYmVy Jm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBJbiBwcmFjdGljZSwgaG93ZXZl ciwKICAgICAgWE1MLWJhc2VkIHNlY3VyZSBvYmplY3QgZm9ybWF0cyBpbnRyb2R1Y2Ugc2ltaWxh ciBsZXZlbHMgb2YgY29tcGxleGl0eQogICAgICB0byBBU04uMSwgc28gZGV2ZWxvcGVycyB0aGF0 IGxhY2sgdGhlIHRvb2xzIG9yIG1vdGl2YXRpb24gdG8gaGFuZGxlCiAgICAgIEFTTi4xIGFyZW4n dCBsaWtlbHkgdG8gdXNlIFhNTCBzZWN1cml0eSBlaXRoZXIuIFRoaXMgc2l0dWF0aW9uIG1vdGl2 YXRlcwogICAgICB0aGUgY3JlYXRpb24gb2YgYSBKU09OLWJhc2VkIHNlY3VyZSBvYmplY3QgZm9y bWF0IHRoYXQgaXMgc2ltcGxlIGVub3VnaAogICAgICB0byBpbXBsZW1lbnQgYW5kIGRlcGxveSB0 aGF0IGl0IGNhbiBiZSBlYXNpbHkgYWRvcHRlZCBieSBkZXZlbG9wZXJzIHdpdGgKICAgICAgbWlu aW1hbCBlZmZvcnQgYW5kIHRvb2xzLgo8L3A+CjxhIG5hbWU9ImRlZi1zZWMiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4yIj48L2E+PGgzPjIuJm5ic3A7CkRlZmluaXRpb25zPC9oMz4KCjxw PlRoaXMgZG9jdW1lbnQgbWFrZXMgZXh0ZW5zaXZlIHVzZSBvZiBzdGFuZGFyZCBzZWN1cml0eSB0 ZXJtaW5vbG9neQogICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzQ5NDknPltSRkM0OTQ5 XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5TaGlyZXksIFIuLCAmbGRxdW87SW50 ZXJuZXQgU2VjdXJpdHkgR2xvc3NhcnksIFZlcnNpb24gMiwmcmRxdW87IEF1Z3VzdCZuYnNwOzIw MDcuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gSW4gYWRkaXRpb24sIGJlY2F1c2UgdGhlIHVz ZSBjYXNlcyBmb3IgSk9TRQogICAgICBhbmQgQ01TIGFyZSBzaW1pbGFyLCB3ZSB3aWxsIHNvbWV0 aW1lcyBtYWtlIGFuYWxvZ2llcyB0byBzb21lIENNUwogICAgICBjb25jZXB0cyA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1JGQzU2NTInPltSRkM1NjUyXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5Ib3VzbGV5LCBSLiwgJmxkcXVvO0NyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50YXgg KENNUyksJnJkcXVvOyBTZXB0ZW1iZXImbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4uCjwvcD4KPHA+VGhlIEpPU0Ugd29ya2luZyBncm91cCBjaGFydGVyIGNhbGxzIGZvciB0aGUg Z3JvdXAgdG8gZGVmaW5lIHRocmVlCiAgICAgIGJhc2ljIEpTT04gb2JqZWN0IGZvcm1hdHM6PC9w Pgo8b2wgY2xhc3M9InRleHQiPgo8bGk+Q29uZmlkZW50aWFsaXR5LXByb3RlY3RlZCBvYmplY3Qg Zm9ybWF0CjwvbGk+CjxsaT5JbnRlZ3JpdHktcHJvdGVjdGVkIG9iamVjdCBmb3JtYXQKPC9saT4K PGxpPkEgZm9ybWF0IGZvciBleHByZXNzaW5nIGtleXMKPC9saT4KPC9vbD48cD4KCiAgICAgIElu IHRoaXMgZG9jdW1lbnQsIHdlIHdpbGwgcmVmZXIgdG8gdGhlc2UgYXMKICAgICAgdGhlICJzaWdu ZWQgb2JqZWN0IGZvcm1hdCIsCiAgICAgIHRoZSAiZW5jcnlwdGVkIG9iamVjdCBmb3JtYXQiLAog ICAgICBhbmQgdGhlICJrZXkgZm9ybWF0IiwgcmVzcGVjdGl2ZWx5LgogICAgICBUaGUgSk9TRSAi c2lnbmVkIG9iamVjdCBmb3JtYXQiIGlzCiAgICAgIEpTT04gV2ViIFNpZ25hdHVyZSAoSldTKSA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI0ktRC5pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlJz5b SSYjODIwOTtELmlldGYmIzgyMDk7am9zZSYjODIwOTtqc29uJiM4MjA5O3dlYiYjODIwOTtzaWdu YXR1cmVdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvbmVzLCBNLiwgQnJhZGxl eSwgSi4sIGFuZCBOLiBTYWtpbXVyYSwgJmxkcXVvO0pTT04gV2ViIFNpZ25hdHVyZSAoSldTKSwm cmRxdW87IEFwcmlsJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICBU aGUgSk9TRSAiZW5jcnlwdGVkIG9iamVjdCBmb3JtYXQiIGlzCiAgICAgIEpTT04gV2ViIEVuY3J5 cHRpb24gKEpXRSkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0Zi1qb3NlLWpzb24td2Vi LWVuY3J5cHRpb24nPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtqb3NlJiM4MjA5O2pzb24mIzgyMDk7 d2ViJiM4MjA5O2VuY3J5cHRpb25dPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpv bmVzLCBNLiwgUmVzY29ybGEsIEUuLCBhbmQgSi4gSGlsZGVicmFuZCwgJmxkcXVvO0pTT04gV2Vi IEVuY3J5cHRpb24gKEpXRSksJnJkcXVvOyBBcHJpbCZuYnNwOzIwMTMuPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPi4KICAgICAgVGhlIEpPU0UgImtleSBmb3JtYXQiIGlzCiAgICAgIEpTT04gV2Vi IEtleSAoSldTKSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ktRC5pZXRmLWpvc2UtanNvbi13ZWIt a2V5Jz5bSSYjODIwOTtELmlldGYmIzgyMDk7am9zZSYjODIwOTtqc29uJiM4MjA5O3dlYiYjODIw OTtrZXldPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvbmVzLCBNLiwgJmxkcXVv O0pTT04gV2ViIEtleSAoSldLKSwmcmRxdW87IEFwcmlsJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LgogICAgICBBbGdvcml0aG1zIGFuZCBhbGdvcml0aG0gaWRlbnRpZmllcnMg dXNlZCBieSBKV1MsIEpXRSwgYW5kIEpXSyBhcmUgZGVmaW5lZCBpbgogICAgICBKU09OIFdlYiBB bGdvcml0aG1zIChKV1MpIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjSS1ELmlldGYtam9zZS1qc29u LXdlYi1hbGdvcml0aG1zJz5bSSYjODIwOTtELmlldGYmIzgyMDk7am9zZSYjODIwOTtqc29uJiM4 MjA5O3dlYiYjODIwOTthbGdvcml0aG1zXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5Kb25lcywgTS4sICZsZHF1bztKU09OIFdlYiBBbGdvcml0aG1zIChKV0EpLCZyZHF1bzsgQXBy aWwmbmJzcDsyMDEzLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgIAo8L3A+CjxwPklu IGdlbmVyYWwsIHdoZXJlIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBh c3ltbWV0cmljIGFuZAogICAgICBzeW1tZXRyaWMgb3BlcmF0aW9ucywgd2Ugd2lsbCB1c2UgdGhl IHRlcm1zICJzaWduaW5nIiwgInNpZ25hdHVyZSIsIGV0Yy4KICAgICAgdG8gZGVub3RlIGJvdGgg dHJ1ZSBkaWdpdGFsIHNpZ25hdHVyZXMgaW52b2x2aW5nIGFzeW1tZXRyaWMgY3J5cHRvZ3JhcGh5 CiAgICAgIGFzIHdlbGwgYXMgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlcyB1c2luZyBzeW1t ZXRyaWMga2V5cyAoTUFDcykuCjwvcD4KPHA+SW4gdGhlIGxpZmVzcGFuIG9mIGEgc2VjdXJlIG9i amVjdCwgdGhlcmUgYXJlIHR3byBiYXNpYyByb2xlcywgYW4KICAgICAgZW50aXR5IHRoYXQgY3Jl YXRlcyB0aGUgb2JqZWN0IChlLmcuLCBlbmNyeXB0aW5nIG9yIHNpZ25pbmcgYSBwYXlsb2FkKSwK ICAgICAgYW5kIGFuIGVudGl0eSB0aGF0IHVzZXMgdGhlIG9iamVjdCAoZGVjcnlwdGluZywgdmVy aWZ5aW5nKS4gV2Ugd2lsbAogICAgICByZWZlciB0byB0aGVzZSByb2xlcyBhcyAic2VuZGVyIiBh bmQgInJlY2lwaWVudCIsIHJlc3BlY3RpdmVseS4gTm90ZQogICAgICB0aGF0IHdoaWxlIHNvbWUg cmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgbWF5IHJlZmVyIHRvIHRoZXNlIGFzIHNpbmdsZQog ICAgICBlbnRpdGllcywgZWFjaCBvYmplY3QgbWF5IGhhdmUgbXVsdGlwbGUgZW50aXRpZXMgaW4g ZWFjaCByb2xlLiBGb3IKICAgICAgZXhhbXBsZSwgYSBtZXNzYWdlIG1heSBiZSBzaWduZWQgYnkg bXVsdGlwbGUgc2VuZGVycywgb3IgZGVjcnlwdGVkIGJ5CiAgICAgIG11bHRpcGxlIHJlY2lwaWVu dHMuCjwvcD4KPGEgbmFtZT0iYmFzaWMtc2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u MyI+PC9hPjxoMz4zLiZuYnNwOwpCYXNpYyBSZXF1aXJlbWVudHM8L2gzPgoKPHA+T2J2aW91c2x5 LCBmb3IgdGhlIGVuY3J5cHRlZCBhbmQgc2lnbmVkIG9iamVjdCBmb3JtYXRzLCB0aGUgbmVjZXNz YXJ5CiAgICAgIHByb3RlY3Rpb25zIHdpbGwgYmUgY3JlYXRlZCB1c2luZyBhcHByb3ByaWF0ZSBj cnlwdG9ncmFwaGljIG1lY2hhbmlzbXM6CiAgICAgIHN5bW1ldHJpYyBvciBhc3ltbWV0cmljIGVu Y3J5cHRpb24gZm9yIGNvbmZpZGVudGlhbGl0eSBhbmQgTUFDcyBvcgogICAgICBkaWdpdGFsIHNp Z25hdHVyZXMgZm9yIGludGVncml0eSBwcm90ZWN0aW9uLiBJbiBib3RoIGNhc2VzLCBpdCBpcwog ICAgICBuZWNlc3NhcnkgZm9yIHRoZSBKT1NFIGZvcm1hdCB0byBzdXBwb3J0IGJvdGggc3ltbWV0 cmljIGFuZCBhc3ltbWV0cmljCiAgICAgIG9wZXJhdGlvbnMuPC9wPgo8dWwgY2xhc3M9InRleHQi Pgo8bGk+VGhlIEpPU0UgZW5jcnlwdGVkIG9iamVjdCBmb3JtYXQgbXVzdCBzdXBwb3J0IG9iamVj dCBlbmNyeXB0aW9uCiAgICAgICAgICBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgc2VuZGVyIGFuZCBy ZWNlaXZlciBzaGFyZSBhIHN5bW1ldHJpYyBrZXkuCjwvbGk+CjxsaT5UaGUgSk9TRSBlbmNyeXB0 ZWQgb2JqZWN0IGZvcm1hdCBtdXN0IHN1cHBvcnQgb2JqZWN0IGVuY3J5cHRpb24KICAgICAgICAg IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBzZW5kZXIgaGFzIG9ubHkgYSBwdWJsaWMga2V5IGZvciB0 aGUKICAgICAgICAgIHJlY2VpdmVyLgo8L2xpPgo8bGk+VGhlIEpPU0Ugc2lnbmVkIG9iamVjdCBm b3JtYXQgbXVzdCBzdXBwb3J0IGludGVncml0eSBwcm90ZWN0aW9uIHVzaW5nCiAgICAgICAgICBN ZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGVzIChNQUNzKSwgZm9yIHRoZSBjYXNlIHdoZXJlIHRo ZSBzZW5kZXIKICAgICAgICAgIGFuZCByZWNlaXZlciBzaGFyZSBvbmx5IGEgc3ltbWV0cmljIGtl eS4KPC9saT4KPGxpPlRoZSBKT1NFIHNpZ25lZCBvYmplY3QgZm9ybWF0IG11c3Qgc3VwcG9ydCBp bnRlZ3JpdHkgcHJvdGVjdGlvbiB1c2luZwogICAgICAgICAgZGlnaXRhbCBzaWduYXR1cmVzLCBm b3IgdGhlIGNhc2Ugd2hlcmUgdGhlIHJlY2VpdmVyIGhhcyBvbmx5IGEKICAgICAgICAgIHB1Ymxp YyBrZXkgZm9yIHRoZSBzZW5kZXIuCjwvbGk+CjwvdWw+Cgo8cD5JbiBjYXNlcyB3aGVyZSB0d28g ZW50aXRpZXMgYXJlIGdvaW5nIHRvIGJlIGV4Y2hhbmdpbmcgc2V2ZXJhbCBKT1NFCiAgICAgIG9i amVjdHMsIGl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gcHJlLW5lZ290aWF0ZSBzb21lIHBhcmFtZXRl cnMgc28gdGhhdCAKICAgICAgdGhleSBkbyBub3QgaGF2ZSB0byBiZSBzaWduYWxlZCBpbiBldmVy eSBKT1NFIG9iamVjdC4gIEhvd2V2ZXIsCiAgICAgIHNvIGFzIG5vdCB0byBjb25mdXNlIGVuZHBv aW50cyB0aGF0IGRvIG5vdCBzdXBwb3J0IHByZS1uZWdvdGlhdGlvbiwKICAgICAgaXQgaXMgdXNl ZnVsIHRvIHNpZ25hbCB3aGVuIHByZS1uZWdvdGlhdGVkIHBhcmFtZXRlcnMgYXJlIGluIHVzZSBp biB0aG9zZSBjYXNlcy4KICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPkl0IHNo b3VsZCBiZSBwb3NzaWJsZSB0byBleHRlbmQgdGhlIGJhc2UKCSAgSk9TRSBzaWduZWQgYW5kIGVu Y3J5cHRlZCBvYmplY3QgZm9ybWF0cwoJICB0byBpbmRpY2F0ZSB0aGF0IHByZS1uZWdvdGlhdGVk IHBhcmFtZXRlcnMgYXJlIHRvIGJlIHVzZWQgdG8gCiAgICAgICAgICBwcm9jZXNzIHRoZSBvYmpl Y3QuICBUaGlzIGV4dGVuc2lvbiBzaG91bGQgYWxzbyBwcm92aWRlIGEgbWVhbnMgb2YgaW5kaWNh dGluZyBvZiAKICAgICAgICAgIHdoaWNoIHBhcmFtZXRlcnMgYXJlIHRvIGJlIHVzZWQuCjwvbGk+ CjwvdWw+PHA+CiAgICAgIAo8L3A+CjxwPlRoZSBwdXJwb3NlIG9mIHRoZSBrZXkgZm9ybWF0IGlz IHRvIHByb3ZpZGUgdGhlIHJlY2lwaWVudCB3aXRoCiAgICAgIHN1ZmZpY2llbnQgaW5mb3JtYXRp b24gdG8gdXNlIHRoZSBlbmNvZGVkIGtleSB0byBwcm9jZXNzIGNyeXB0b2dyYXBoaWMKICAgICAg bWVzc2FnZXMuIFRodXMgaXQgaXMgc29tZXRpbWVzIG5lY2Vzc2FyeSB0byBpbmNsdWRlIGFkZGl0 aW9uYWwgcGFyYW1ldGVycyBhbG9uZwogICAgICB3aXRoIHRoZSBiYXJlIGtleS4KPC9wPgo8cD48 L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5UaGUgSk9TRSBrZXkgZm9ybWF0IG11c3QgZW5hYmxl IGluY2x1c2lvbiBvZiBhbGwgYWxnb3JpdGhtIHBhcmFtZXRlcnMKICAgICAgICAgIG5lY2Vzc2Fy eSB0byB1c2UgdGhlIGVuY29kZWQga2V5LCBpbmNsdWRpbmcgYW4gaWRlbnRpZmllciBmb3IgdGhl CiAgICAgICAgICBhbGdvcml0aG0gd2l0aCB3aGljaCB0aGUga2V5IGlzIHVzZWQgYXMgd2VsbCBh cyBhbnkgYWRkaXRpb25hbAogICAgICAgICAgcGFyYW1ldGVycyByZXF1aXJlZCBieSB0aGUgYWxn b3JpdGhtIChlLmcuLCBlbGxpcHRpYyBjdXJ2ZQogICAgICAgICAgcGFyYW1ldGVycykuCjwvbGk+ CjwvdWw+Cgo8YSBuYW1lPSJhcHAtcmVxLXNlYyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LjQiPjwvYT48aDM+NC4mbmJzcDsKQXBwbGljYXRpb24gYW5kIFByb3RvY29sIFJlcXVpcmVtZW50 czwvaDM+Cgo8cD4KCUl0IHNob3VsZCBiZSB1bmRlcnN0b29kIHRoYXQgd2hpbGUgSk9TRSBpcyBj cmVhdGluZyBkYXRhIGZvcm1hdHMsCglpdCBpcyBub3QgY3JlYXRpbmcgcHJvdG9jb2xzIG9yIGFw cGxpY2F0aW9ucy4KCVJhdGhlciwgdGhlIEpPU0UgZGF0YSBmb3JtYXRzIGFyZSBpbnRlbmRlZCB0 byBiZSB1c2VkIGluIHByb3RvY29scwoJYW5kIGJ5IGFwcGxpY2F0aW9ucy4KCVRoZXNlIHByb3Rv Y29scyBhbmQgYXBwbGljYXRpb25zIHdpbGwgc3BlY2lmeSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50 cwoJb24gdXNpbmcgdGhlIEpPU0UgZGF0YSBmb3JtYXRzIGluIHRob3NlIHBhcnRpY3VsYXIgY29u dGV4dHMuCglUaGVzZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB3aWxsIGluY2x1ZGUsIGJ1dCBh cmUgbm90IGxpbWl0ZWQgdG86Cgk8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5yZXF1aXJlbWVu dHMgb24gbWVzc2FnZSBjb250ZW50cywKPC9saT4KPGxpPnJlcXVpcmVtZW50cyBvbiBhbGdvcml0 aG1zIHVzZWQsCjwvbGk+CjxsaT5yZXF1aXJlbWVudHMgb24ga2V5cyB1c2VkLAo8L2xpPgo8bGk+ cmVxdWlyZW1lbnRzIG9uIGtleSBkaXN0cmlidXRpb24gbWV0aG9kcywgYW5kCjwvbGk+CjxsaT5y ZXF1aXJlbWVudHMgb24ga2V5IHNlbGVjdGlvbiBtZXRob2RzLgo8L2xpPgo8L3VsPjxwPgogICAg ICAKPC9wPgo8YSBuYW1lPSJ1c2UtY2FzZXMtc2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uNSI+PC9hPjxoMz41LiZuYnNwOwpVc2UgQ2FzZXM8L2gzPgoKPHA+U2V2ZXJhbCB3b3JraW5n IGdyb3VwcyBkZXZlbG9waW5nIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29scwogICAgICBoYXZl IGV4cHJlc3NlZCBhIGRlc2lyZSB0byB1c2UgdGhlIEpPU0UgZGF0YSBmb3JtYXRzIGluIHRoZWly CiAgICAgIGRlc2lnbnMgZm9yIGVuZC10by1lbmQgc2VjdXJpdHkgZmVhdHVyZXMuIEluIHRoaXMg c2VjdGlvbiwgd2Ugc3VtbWFyaXplCiAgICAgIHRoZSB1c2UgY2FzZXMgcHJvcG9zZWQgYnkgdGhl c2UgZ3JvdXBzIGFuZCBkaXNjdXNzIHRoZSByZXF1aXJlbWVudHMgdGhhdAogICAgICB0aGV5IGlt cGx5IGZvciB0aGUgSk9TRSBvYmplY3QgZm9ybWF0cy4KPC9wPgo8YSBuYW1lPSJzZWMtdG9rZW4t c2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNS4xIj48L2E+PGgzPjUuMS4mbmJzcDsK U2VjdXJpdHkgVG9rZW5zPC9oMz4KCjxwPlNlY3VyaXR5IHRva2VucyBhcmUgYSBjb21tb24gdXNl IGNhc2UgZm9yIG9iamVjdC1iYXNlZCBzZWN1cml0eSwKICAgICAgICBmb3IgZXhhbXBsZSwgU0FN TCBhc3NlcnRpb25zIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjT0FTSVMuc2FtbC1jb3JlLTIuMC1v cyc+W09BU0lTLnNhbWwmIzgyMDk7Y29yZSYjODIwOTsyLjAmIzgyMDk7b3NdPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkNhbnRvciwgUy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4s IGFuZCBFLiBNYWxlciwgJmxkcXVvO0Fzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FT SVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAgICAgICAgICAgICAoU0FNTCkg VjIuMCwmcmRxdW87IE1hcmNoJm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgog ICAgICAgIFNlY3VyaXR5IHRva2VucyBhcmUgdXNlZCB0byBjb252ZXkgaW5mb3JtYXRpb24gYWJv dXQgYSBzdWJqZWN0IGVudGl0eQogICAgICAgICgiY2xhaW1zIiBvciAiYXNzZXJ0aW9ucyIpIGZy b20gYW4gaXNzdWVyIHRvIGEgcmVjaXBpZW50LiBUaGUgc2VjdXJpdHkKICAgICAgICBmZWF0dXJl cyBvZiBhIHRva2VuIGZvcm1hdCBlbmFibGUgdGhlIHJlY2lwaWVudCB0byB2ZXJpZnkgdGhhdCB0 aGUKICAgICAgICBjbGFpbXMgY2FtZSBmcm9tIHRoZSBpc3N1ZXIgYW5kLCBpZiB0aGUgb2JqZWN0 IGlzCiAgICAgICAgY29uZmlkZW50aWFsaXR5LXByb3RlY3RlZCwgdGhhdCB0aGV5IHdlcmUgbm90 IHZpc2libGUgdG8gb3RoZXIKICAgICAgICBwYXJ0aWVzLgo8L3A+CjxwPlNlY3VyaXR5IHRva2Vu cyBhcmUgdXNlZCBpbiBmZWRlcmF0aW9uIHByb3RvY29scyBzdWNoIGFzIFNBTUwgMi4wCgk8YSBj bGFzcz0naW5mbycgaHJlZj0nI09BU0lTLnNhbWwtY29yZS0yLjAtb3MnPltPQVNJUy5zYW1sJiM4 MjA5O2NvcmUmIzgyMDk7Mi4wJiM4MjA5O29zXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5DYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIuLCBhbmQgRS4gTWFsZXIsICZs ZHF1bztBc3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2Vy dGlvbiBNYXJrdXAgTGFuZ3VhZ2UgICAgICAgICAgICAgKFNBTUwpIFYyLjAsJnJkcXVvOyBNYXJj aCZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKICAgICAgICBXUy1GZWRlcmF0 aW9uIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjV1MtRmVkZXJhdGlvbic+W1dTJiM4MjA5O0ZlZGVy YXRpb25dPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkthbGVyLCBDLiwgTWNJbnRv c2gsIE0uLCBHb29kbmVyLCBNLiwgYW5kIEEuIE5hZGFsaW4sICZsZHF1bztPcGVuSUQgQ29ubmVj dCBNZXNzYWdlcyAxLjAsJnJkcXVvOyBNYXkmbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4sCglNb3ppbGxhIFBlcnNvbmEgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNQZXJzb25hJz5b UGVyc29uYV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TW96aWxsYSwgJmxkcXVv O01vemlsbGEgUGVyc29uYSwmcmRxdW87IEFwcmlsJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LAoJYW5kIE9wZW5JRCBDb25uZWN0IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjT3Bl bklELk1lc3NhZ2VzJz5bT3BlbklELk1lc3NhZ2VzXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5TYWtpbXVyYSwgTi4sIEJyYWRsZXksIEouLCBKb25lcywgTS4sIGRlIE1lZGVpcm9z LCBCLiwgTW9ydGltb3JlLCBDLiwgYW5kIEUuIEpheSwgJmxkcXVvO09wZW5JRCBDb25uZWN0IE1l c3NhZ2VzIDEuMCwmcmRxdW87IE1hcmNoJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LAoJYXMgd2VsbCBhcyBpbiByZXNvdXJjZSBhdXRob3JpemF0aW9uCiAgICAgICAgcHJvdG9j b2xzIHN1Y2ggYXMgT0F1dGggMi4wIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNjc0OSc+W1JG QzY3NDldPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhcmR0LCBELiwgJmxkcXVv O1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmssJnJkcXVvOyBPY3RvYmVyJm5i c3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJaW5jbHVkaW5nIGZvciBPQXV0aCBi ZWFyZXIgdG9rZW5zIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNjc1MCc+W1JGQzY3NTBdPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvbmVzLCBNLiBhbmQgRC4gSGFyZHQsICZs ZHF1bztUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBCZWFyZXIgVG9rZW4g VXNhZ2UsJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ LiBJbiBzb21lIGNhc2VzLAogICAgICAgIHNlY3VyaXR5IHRva2VucyBhcmUgdXNlZCBmb3IgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBmb3IgYWNjZXNzCiAgICAgICAgY29udHJvbCA8YSBjbGFz cz0naW5mbycgaHJlZj0nI0ktRC5pZXRmLW9hdXRoLWp3dC1iZWFyZXInPltJJiM4MjA5O0QuaWV0 ZiYjODIwOTtvYXV0aCYjODIwOTtqd3QmIzgyMDk7YmVhcmVyXTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5Kb25lcywgTS4sIENhbXBiZWxsLCBCLiwgYW5kIEMuIE1vcnRpbW9yZSwg JmxkcXVvO0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gR3JhbnRzLCZyZHF1bzsgTWFyY2gmbmJz cDsyMDEzLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT48YSBjbGFzcz0naW5mbycgaHJlZj0nI0kt RC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlcic+W0kmIzgyMDk7RC5pZXRmJiM4MjA5O29hdXRoJiM4 MjA5O3NhbWwyJiM4MjA5O2JlYXJlcl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ Q2FtcGJlbGwsIEIuLCBNb3J0aW1vcmUsIEMuLCBhbmQgTS4gSm9uZXMsICZsZHF1bztTQU1MIDIu MCBQcm9maWxlIGZvciBPQXV0aCAyLjAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3Jp emF0aW9uIEdyYW50cywmcmRxdW87IE1hcmNoJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+Lgo8L3A+CjxwPkpTT04gV2ViIFRva2VuIChKV1QpIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjSS1ELmlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4nPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtv YXV0aCYjODIwOTtqc29uJiM4MjA5O3dlYiYjODIwOTt0b2tlbl08c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+Sm9uZXMsIE0uLCBCcmFkbGV5LCBKLiwgYW5kIE4uIFNha2ltdXJhLCAm bGRxdW87SlNPTiBXZWIgVG9rZW4gKEpXVCksJnJkcXVvOyBBcHJpbCZuYnNwOzIwMTMuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPgoJaXMgYSBzZWN1cml0eSB0b2tlbiBmb3JtYXQKCWJhc2VkIG9u IEpTT04gYW5kIEpPU0UuIEl0IGlzIHVzZWQgd2l0aCBNb3ppbGxhIFBlcnNvbmEsCglPcGVuSUQg Q29ubmVjdCwgYW5kIE9BdXRoLiBCZWNhdXNlIEpXVHMgYXJlIG9mdGVuIHVzZWQgaW4gY29udGV4 dHMKCXdpdGggbGltaXRlZCBzcGFjZSAoZS5nLiwgSFRUUCBxdWVyeSBwYXJhbWV0ZXJzKSwgaXQg aXMgYSBjb3JlCglyZXF1aXJlbWVudCBmb3IgSldUcywgYW5kIHRodXMgSk9TRSwgdG8gaGF2ZSBh IGNvbXBhY3QsIFVSTC1zYWZlCglyZXByZXNlbnRhdGlvbi4KPC9wPgo8YSBuYW1lPSJvYXV0aC1z ZWMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjIiPjwvYT48aDM+NS4yLiZuYnNwOwpP QXV0aDwvaDM+Cgo8cD5UaGUgT0F1dGggcHJvdG9jb2wgZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3Ig ZGlzdHJpYnV0aW5nIGFuZCB1c2luZwogICAgICAgIGF1dGhvcml6YXRpb24gdG9rZW5zIHVzaW5n IEhUVFAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM2NzQ5Jz5bUkZDNjc0OV08c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SGFyZHQsIEQuLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBB dXRob3JpemF0aW9uIEZyYW1ld29yaywmcmRxdW87IE9jdG9iZXImbmJzcDsyMDEyLjwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4uIEEgQ2xpZW50CiAgICAgICAgdGhhdCB3aXNoZXMgdG8gYWNjZXNz IGEgcHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzIGF1dGhvcml6YXRpb24gZnJvbQogICAgICAg IHRoZSBSZXNvdXJjZSBPd25lci4gSWYgdGhlIFJlc291cmNlIE93bmVyIGFsbG93cyB0aGlzIGFj Y2VzcywgaGUKICAgICAgICBkaXJlY3RzIGFuIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIGlzc3Vl IGFuIGFjY2VzcyB0b2tlbiB0byB0aGUKICAgICAgICBDbGllbnQuIFdoZW4gdGhlIENsaWVudCB3 aXNoZXMgdG8gYWNjZXNzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UsIGhlCiAgICAgICAgcHJlc2Vu dHMgdGhlIHRva2VuIHRvIHRoZSByZWxldmFudCBSZXNvdXJjZSBTZXJ2ZXIsIHdoaWNoIHZlcmlm aWVzIHRoZQogICAgICAgIHZhbGlkaXR5IG9mIHRoZSB0b2tlbiBiZWZvcmUgcHJvdmlkaW5nIGFj Y2VzcyB0byB0aGUgcHJvdGVjdGVkCiAgICAgICAgcmVzb3VyY2UuCjwvcD48YnIgLz48aHIgY2xh c3M9Imluc2VydCIgLz4KPGEgbmFtZT0iZmlnT0F1dGgiPjwvYT4KPGRpdiBzdHlsZT0nZGlzcGxh eTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8n PjxwcmU+ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICAgfCAgIFJlc291cmNlICAgIHwmbHQ7Li4uLi4uLi4mZ3Q7 fCBBdXRob3JpemF0aW9uIHwKICAgICAgICAgICAgICB8ICAgIFNlcnZlciAgICAgfCAgICAgICAg ICB8ICAgICBTZXJ2ZXIgICAgfAogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgXiAgICAg ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICstLS0tLS0tLS0tLS18LS0r ICAgICAgICAgICstLXwtLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfCAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgIHwKICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCAgICAgICAgICB8ICAgUmVzb3VyY2UgICAgfAogICAgICAgICAgICAgIHwgICAgIENsaWVu dCAgICB8ICAgICAgICAgIHwgICAgIE93bmVyICAgICB8CiAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tKyAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKzwvcHJlPjwvZGl2Pgo8cD4KPC9w Pjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249 ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNh bnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzE6IFRoZSBPQXV0aCBwcm9j ZXNzJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48aHIgY2xhc3M9Imlu c2VydCIgLz4KCjxwPkluIGVmZmVjdCwgdGhpcyBwcm9jZXNzIG1vdmVzIHRoZSB0b2tlbiBmcm9t IHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgU2VydmVyIChhcyBhIHNlbmRlciBvZiB0aGUgb2Jq ZWN0KSB0byB0aGUgUmVzb3VyY2UgU2VydmVyIChyZWNpcGllbnQpLAogICAgICAgIHZpYSB0aGUg Q2xpZW50IGFzIHdlbGwgYXMgdGhlIFJlc291cmNlIE93bmVyICh0aGUgbGF0dGVyIGJlY2F1c2Ug b2YKICAgICAgICB0aGUgSFRUUCBtZWNoYW5pY3MgdW5kZXJseWluZyB0aGUgcHJvdG9jb2wpLiBT byBhZ2FpbiB3ZSBoYXZlIGEgY2FzZQogICAgICAgIHdoZXJlIGFuIGFwcGxpY2F0aW9uIG9iamVj dCBpcyB0cmFuc3BvcnRlZCB2aWEgdW50cnVzdGVkCiAgICAgICAgaW50ZXJtZWRpYXJpZXMuCjwv cD4KPHA+VGhpcyBhcHBsaWNhdGlvbiBoYXMgdHdvIGVzc2VudGlhbCBzZWN1cml0eSByZXF1aXJl bWVudHM6IEludGVncml0eQogICAgICAgIGFuZCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbi4g SW50ZWdyaXR5IHByb3RlY3Rpb24gaXMgcmVxdWlyZWQgc28KICAgICAgICB0aGF0IHRoZSBSZXNv dXJjZSBPd25lciBhbmQgdGhlIENsaWVudCBjYW5ub3QgbW9kaWZ5IHRoZSBwZXJtaXNzaW9uCiAg ICAgICAgZW5jb2RlZCBpbiB0aGUgdG9rZW4uIERhdGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uIGlz IHJlcXVpcmVkIHNvIHRoYXQKICAgICAgICB0aGUgUmVzb3VyY2UgU2VydmVyIGNhbiB2ZXJpZnkg dGhhdCB0aGUgdG9rZW4gd2FzIGlzc3VlZCBieSBhIHRydXN0ZWQKICAgICAgICBBdXRob3JpemF0 aW9uIFNlcnZlci4gQ29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gbWF5IGFsc28gYmUgbmVlZGVk LAogICAgICAgIGlmIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBpcyBjb25jZXJuZWQgYWJvdXQg dGhlIHZpc2liaWxpdHkgb2YKICAgICAgICBwZXJtaXNzaW9ucyBpbmZvcm1hdGlvbiB0byB0aGUg UmVzb3VyY2UgT3duZXIgb3IgQ2xpZW50LiBGb3IgZXhhbXBsZSwKICAgICAgICBwZXJtaXNzaW9u cyByZWxhdGVkIHRvIHNvY2lhbCBuZXR3b3JraW5nIG1pZ2h0IGJlIGNvbnNpZGVyZWQgcHJpdmF0 ZQogICAgICAgIGluZm9ybWF0aW9uLiBOb3RlLCBob3dldmVyLCB0aGF0IE9BdXRoIGFscmVhZHkg cmVxdWlyZXMgdGhhdCB0aGUKICAgICAgICB1bmRlcmx5aW5nIEhUVFAgdHJhbnNhY3Rpb25zIGJl IHByb3RlY3RlZCBieSBUTFMsIHNvIGNvbmZpZGVudGlhbGl0eQogICAgICAgIHByb3RlY3Rpb24g aXMgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSBmb3IgdGhpcyB1c2UgY2FzZS4KPC9wPgo8cD5UaGUg Y29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgbmVlZHMgYXJlIG1ldCBieSB0aGUgYmFzaWMK ICAgICAgICByZXF1aXJlbWVudHMgZm9yIHNpZ25lZCBhbmQgZW5jcnlwdGVkIG9iamVjdCBmb3Jt YXRzLCB3aGV0aGVyIHRoZQogICAgICAgIHNpZ25pbmcgYW5kIGVuY3J5cHRpb24gYXJlIHByb3Zp ZGVkIHVzaW5nIGFzeW1tZXRyaWMgb3Igc3ltbWV0cmljCiAgICAgICAgY3J5cHRvZ3JhcGh5LiBU aGUgY2hvaWNlIG9mIHdoaWNoIG1lY2hhbmlzbSBpcyBhcHBsaWVkIHdpbGwgZGVwZW5kIG9uCiAg ICAgICAgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0d28gc2VydmVycywgbmFtZWx5IHdo ZXRoZXIgdGhleSBzaGFyZSBhCiAgICAgICAgc3ltbWV0cmljIGtleSBvciBvbmx5IHB1YmxpYyBr ZXlzLgo8L3A+CjxwPkF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyB3aWxsIGFsc28gZGVwZW5k IG9uIGRlcGxveW1lbnQKICAgICAgICBjaGFyYWN0ZXJpc3RpY3MuIFdoZXJlIHRoZXJlIGlzIGEg cmVsYXRpdmVseSBzdHJvbmcgYmluZGluZyBiZXR3ZWVuCiAgICAgICAgdGhlIHJlc291cmNlIHNl cnZlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBpdCBtYXkgc3VmZmljZSBmb3IKICAg ICAgICB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaXNzdWluZyBhIHRva2VuIHRvIGJlIGlkZW50 aWZpZWQgYnkgdGhlIGtleQogICAgICAgIHVzZWQgdG8gc2lnbiB0aGUgdG9rZW4uIFRoaXMgcmVx dWlyZXMgdGhhdCB0aGUgcHJvdG9jb2wgY2FycnkgZWl0aGVyIHRoZQogICAgICAgIHB1YmxpYyBr ZXkgb2YgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIG9yIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBw dWJsaWMKICAgICAgICBvciBzeW1tZXRyaWMga2V5LiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJvdG9j b2wgZWxlbWVudCBpZGVudGlmeWluZyB0aGUga2V5Cgl0byBiZSB1c2VkIGlzIHRoZSA8dHQ+Y2xp ZW50X2lkPC90dD4gcGFyYW1ldGVyIHZhbHVlLgo8L3A+CjxwPlRoZXJlIG1heSBhbHNvIGJlIG1v cmUgYWR2YW5jZWQgY2FzZXMsIHdoZXJlIHRoZSBBdXRob3JpemF0aW9uCiAgICAgICAgU2VydmVy J3Mga2V5IGlzIG5vdCBrbm93biBpbiBhZHZhbmNlIHRvIHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIFRo aXMgbWF5CiAgICAgICAgaGFwcGVuLCBmb3IgaW5zdGFuY2UsIGlmIGFuIGVudGl0eSBpbnN0YW50 aWF0ZWQgYSBjb2xsZWN0aW9uIG9mCiAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXJzIChzYXkg Zm9yIGxvYWQgYmFsYW5jaW5nKSwgZWFjaCBvZiB3aGljaCBoYXMgYW4KICAgICAgICBpbmRlcGVu ZGVudCBrZXkgcGFpci4gSW4gdGhlc2UgY2FzZXMsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8gYWxz bwogICAgICAgIGluY2x1ZGUgYSBjZXJ0aWZpY2F0ZSBvciBjZXJ0aWZpY2F0ZSBjaGFpbiBmb3Ig dGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIsIHNvIHRoYXQgdGhlIFJlc291cmNlIFNl cnZlciBjYW4gdmVyaWZ5IHRoYXQgdGhlIEF1dGhvcml6YXRpb24KICAgICAgICBTZXJ2ZXIgaXMg YW4gZW50aXR5IHRoYXQgaXQgdHJ1c3RzLgo8L3A+CjxwPlRoZSBIVFRQIHRyYW5zcG9ydCBmb3Ig T0F1dGggaW1wb3NlcyBhIHBhcnRpY3VsYXIgY29uc3RyYWludCBvbiB0aGUKICAgICAgICBlbmNv ZGluZy4gSW4gdGhlIE9BdXRoIHByb3RvY29sLCB0b2tlbnMgZnJlcXVlbnRseSBuZWVkIHRvIGJl IHBhc3NlZAogICAgICAgIGFzIHF1ZXJ5IHBhcmFtZXRlcnMgaW4gSFRUUCBVUklzIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjUkZDMjYxNic+W1JGQzI2MTZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBI LiwgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgJmxkcXVvO0h5 cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSwmcmRxdW87IEp1bmUmbmJzcDsx OTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFmdGVyCiAgICAgICAgaGF2aW5nIGJlZW4g YmFzZTY0dXJsIGVuY29kZWQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NjQ4Jz5bUkZDNDY0 OF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Sm9zZWZzc29uLCBTLiwgJmxkcXVv O1RoZSBCYXNlMTYsIEJhc2UzMiwgYW5kIEJhc2U2NCBEYXRhIEVuY29kaW5ncywmcmRxdW87IE9j dG9iZXImbmJzcDsyMDA2Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFdoaWxlIHRoZXJlIGlz CiAgICAgICAgbm8gc3BlY2lmaWVkIGxpbWl0IG9uIHRoZSBsZW5ndGggb2YgVVJJcyAoYW5kIHRo dXMgb2YgcXVlcnkKICAgICAgICBwYXJhbWV0ZXJzKSwgaW4gcHJhY3RpY2UgVVJJcyBvZiBtb3Jl IHRoYW4gMjA0OCBjaGFyYWN0ZXJzIGFyZQogICAgICAgIHJlamVjdGVkIGJ5IHNvbWUgdXNlciBh Z2VudHMsCglhbmQgZm9yIHNvbWUgbW9iaWxlIGJyb3dzZXJzLCB0aGlzIGxpbWl0IGlzIGV2ZW4g c21hbGxlci4KCVNvIHRoaXMgdXNlIGNhc2UgcmVxdWlyZXMgdGhhdCBhIEpPU0UKICAgICAgICBv YmplY3QgaGF2ZSBzdWZmaWNpZW50bHkgc21hbGwgc2l6ZSBldmVuIGFmdGVyIHNpZ25pbmcsIHBv c3NpYmx5CiAgICAgICAgZW5jcnlwdGluZywgd2hpbGUgc3RpbGwgYmVpbmcgc2ltcGxlIHRvIGlu Y2x1ZGUgaW4gYW4gSFRUUCBVUkkgcXVlcnkKICAgICAgICBwYXJhbWV0ZXIuCjwvcD4KPGEgbmFt ZT0iZmVkLXNlY3Rpb24iPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjMiPjwvYT48aDM+ NS4zLiZuYnNwOwpGZWRlcmF0aW9uPC9oMz4KCjxwPlR3byBmZWRlcmF0ZWQgaWRlbnRpdHkgcHJv dG9jb2xzIGhhdmUgc2ltaWxhciByZXF1aXJlbWVudHM6CjwvcD4KPHA+PC9wPgo8dWwgY2xhc3M9 InRleHQiPgo8bGk+VGhlIE9wZW5JRCBDb25uZWN0IHByb3RvY29sIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjT3BlbklELk1lc3NhZ2VzJz5bT3BlbklELk1lc3NhZ2VzXTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5TYWtpbXVyYSwgTi4sIEJyYWRsZXksIEouLCBKb25lcywgTS4sIGRl IE1lZGVpcm9zLCBCLiwgTW9ydGltb3JlLCBDLiwgYW5kIEUuIEpheSwgJmxkcXVvO09wZW5JRCBD b25uZWN0IE1lc3NhZ2VzIDEuMCwmcmRxdW87IE1hcmNoJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+CgkgICAgaXMgYSBzaW1wbGUsIFJFU1QvSlNPTi1iYXNlZAoJICAgIGlkZW50 aXR5IGZlZGVyYXRpb24gcHJvdG9jb2wgbGF5ZXJlZCBvbiBPQXV0aCAyLjAuCgkgICAgSXQgdXNl cyB0aGUgSldUIGFuZCBKT1NFIGZvcm1hdHMgYm90aAogICAgICAgICAgICB0byByZXByZXNlbnQg c2VjdXJpdHkgdG9rZW5zIGFuZCB0byBwcm92aWRlIHNlY3VyaXR5IGZvciBvdGhlcgogICAgICAg ICAgICBwcm90b2NvbCBtZXNzYWdlcyAocGVyZm9ybWluZyBzaWduaW5nIGFuZCBvcHRpb25hbGx5 IGVuY3J5cHRpb24pLgoJICAgIE9wZW5JRCBDb25uZWN0IG5lZ290aWF0ZXMgdGhlIGFsZ29yaXRo bXMgdG8gYmUgdXNlZCBhbmQgZGlzdHJpYnV0ZXMKCSAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUg a2V5cyB0byBiZSB1c2VkIHVzaW5nIHByb3RvY29sIGVsZW1lbnRzCgkgICAgdGhhdCBhcmUgbm90 IHBhcnQgb2YgdGhlIEpXVCBhbmQgSk9TRSBoZWFkZXIgcGFyYW1ldGVycy4KPC9saT4KPGxpPlRo ZSBNb3ppbGxhIFBlcnNvbmEgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNQZXJzb25hJz5bUGVyc29u YV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TW96aWxsYSwgJmxkcXVvO01vemls bGEgUGVyc29uYSwmcmRxdW87IEFwcmlsJm5ic3A7MjAxMy48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+IHN5c3RlbSBpcyBhIHNpbXBsZQoJICAgIHNpbmdsZS1zaWduLW9uIChTU08pIHByb3RvY29s IHRoYXQgdXNlcyBKV1RzIHRoYXQgYXJlIHNpZ25lZAoJICAgIEpPU0UgSldTIG9iamVjdHMgdG8g cmVwcmVzZW50IGluZm9ybWF0aW9uIGFib3V0IGlkZW50aXRpZXMsCgkgICAgYXBwbGljYXRpb25z LCBhbmQga2V5cyBmb3IgcGFydGljaXBhdGluZyBlbnRpdGllcy4KCSAgICBQZXJzb25hIGRpc3Ry aWJ1dGVzIHRoZSBrZXlzIHVzZWQgYXMgY2xhaW1zIGluIEpXVCBtZXNzYWdlcwoJICAgIGFuZCBu b3QgYnkgdXNpbmcgSk9TRSBoZWFkZXIgcGFyYW1ldGVycy4KCSAgICAKPC9saT4KPC91bD4KCjxh IG5hbWU9InhtcHAtc2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNS40Ij48L2E+PGgz PjUuNC4mbmJzcDsKWE1QUDwvaDM+Cgo8cD5UaGUgRXh0ZW5zaWJsZSBNZXNzYWdpbmcgYW5kIFBy ZXNlbmNlIFByb3RvY29sIChYTVBQKSByb3V0ZXMKICAgICAgICBtZXNzYWdlcyBmcm9tIG9uZSBl bmQgY2xpZW50IHRvIGFub3RoZXIgYnkgd2F5IG9mIFhNUFAgc2VydmVycyA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1JGQzYxMjAnPltSRkM2MTIwXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5TYWludC1BbmRyZSwgUC4sICZsZHF1bztFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQgUHJl c2VuY2UgUHJvdG9jb2wgKFhNUFApOiBDb3JlLCZyZHF1bzsgTWFyY2gmbmJzcDsyMDExLjwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRoZXJlIGFyZSB0eXBpY2FsbHkgdHdvIHNlcnZlcnMgaW52 b2x2ZWQgaW4KICAgICAgICBkZWxpdmVyaW5nIGFueSBnaXZlbiBtZXNzYWdlOiBUaGUgZmlyc3Qg Y2xpZW50IChBbGljZSkgc2VuZHMgYSBtZXNzYWdlCiAgICAgICAgZm9yIGFub3RoZXIgY2xpZW50 IChCKSB0byBoZXIgc2VydmVyIChBKS4gU2VydmVyIEEgdXNlcyBCb2IncyBpZGVudGl0eQogICAg ICAgIGFuZCB0aGUgRE5TIHRvIGxvY2F0ZSB0aGUgc2VydmVyIGZvciBCb2IncyBkb21haW4gKEIp LCB0aGVuIGRlbGl2ZXJzCiAgICAgICAgdGhlIG1lc3NhZ2UgdG8gdGhhdCBzZXJ2ZXIuIFNlcnZl ciBCIHRoZW4gcm91dGVzIHRoZSBtZXNzYWdlIHRvCiAgICAgICAgQm9iLgo8L3A+PGJyIC8+PGhy IGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9ImZpZy14bXBwIj48L2E+CjxkaXYgc3R5bGU9J2Rp c3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBh dXRvJz48cHJlPgogICAgICAgICArLS0tLS0tLSsgICArLS0tLS0tLS0tLSsgICArLS0tLS0tLS0t LSsgICArLS0tLS0rCiAgICAgICAgIHwgQWxpY2UgfC0tJmd0O3wgU2VydmVyIEEgfC0tJmd0O3wg U2VydmVyIEIgfC0tJmd0O3wgQm9iIHwKICAgICAgICAgKy0tLS0tLS0rICAgKy0tLS0tLS0tLS0r ICAgKy0tLS0tLS0tLS0rICAgKy0tLS0tKzwvcHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGln bj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxi PiZuYnNwO0ZpZ3VyZSZuYnNwOzI6IERlbGl2ZXJpbmcgYW4gWE1QUCBtZXNzYWdlJm5ic3A7PC9i PjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxw PlRoZSB1bnRydXN0ZWQtaW50ZXJtZWRpYXJ5IHByb2JsZW1zIGFyZSBlc3BlY2lhbGx5IGFjdXRl IGZvciBYTVBQCiAgICAgICAgYmVjYXVzZSBpbiBtYW55IGN1cnJlbnQgZGVwbG95bWVudHMsIHRo ZSBob2xkZXIgb2YgYW4gWE1QUCBkb21haW4KICAgICAgICBvdXRzb3VyY2VzIHRoZSBvcGVyYXRp b24gb2YgdGhlIGRvbWFpbidzIHNlcnZlcnMgdG8gYSBkaWZmZXJlbnQKICAgICAgICBlbnRpdHku IEluIHRoaXMgZW52aXJvbm1lbnQsIHRoZXJlIGlzIGEgY2xlYXIgcmlzayBvZiBleHBvc2luZyB0 aGUKICAgICAgICBkb21haW4gaG9sZGVyJ3MgcHJpdmF0ZSBpbmZvcm1hdGlvbiB0byB0aGUgZG9t YWluIG9wZXJhdG9yLiBYTVBQCiAgICAgICAgYWxyZWFkeSBoYXMgYSBkZWZpbmVkIG1lY2hhbmlz bSBmb3IgZW5kLXRvLWVuZCBzZWN1cml0eSB1c2luZyBTL01JTUUsCiAgICAgICAgYnV0IGl0IGhh cyBmYWlsZWQgdG8gZ2FpbiB3aWRlc3ByZWFkIGRlcGxveW1lbnQgPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNSRkMzOTIzJz5bUkZDMzkyM108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ U2FpbnQtQW5kcmUsIFAuLCAmbGRxdW87RW5kLXRvLUVuZCBTaWduaW5nIGFuZCBPYmplY3QgRW5j cnlwdGlvbiBmb3IgdGhlIEV4dGVuc2libGUgTWVzc2FnaW5nIGFuZCBQcmVzZW5jZSBQcm90b2Nv bCAoWE1QUCksJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAwNC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LCBpbiBwYXJ0IGJlY2F1c2Ugb2Yga2V5IG1hbmFnZW1lbnQgY2hhbGxlbmdlcyBhbmQKICAg ICAgICBiZWNhdXNlIG9mIHRoZSBkaWZmaWN1bHR5IG9mIHByb2Nlc3NpbmcgUy9NSU1FIG9iamVj dHMuCjwvcD4KPHA+VGhlIFhNUFAgd29ya2luZyBncm91cCBpcyBpbiB0aGUgcHJvY2VzcyBvZiBk ZXZlbG9waW5nIGEgbmV3CiAgICAgICAgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIHN5c3RlbSB3aXRo IGFuIGVuY29kaW5nIGJhc2VkIG9uIEpPU0UgYW5kIGEKICAgICAgICBjbGVhcmVyIGtleSBtYW5h Z2VtZW50IHN5c3RlbSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ktRC5taWxsZXIteG1wcC1lMmUn PltJJiM4MjA5O0QubWlsbGVyJiM4MjA5O3htcHAmIzgyMDk7ZTJlXTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5NaWxsZXIsIE0uLCAmbGRxdW87RW5kLXRvLUVuZCBPYmplY3QgRW5j cnlwdGlvbiBmb3IgdGhlIEV4dGVuc2libGUgTWVzc2FnaW5nIGFuZCBQcmVzZW5jZSBQcm90b2Nv bCAoWE1QUCksJnJkcXVvOyBGZWJydWFyeSZuYnNwOzIwMTMuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPi4KICAgICAgICBUaGUgcHJvY2VzcyBvZiBzZW5kaW5nIGFuIGVuY3J5cHRlZCBtZXNzYWdl IGluIHRoaXMgc3lzdGVtIGludm9sdmVzCiAgICAgICAgdHdvIHN0ZXBzOiBGaXJzdCwgdGhlIHNl bmRlciBnZW5lcmF0ZXMgYSBzeW1tZXRyaWMgQ29udGVudCBFbmNyeXB0aW9uCiAgICAgICAgS2V5 IChDRUspLCBlbmNyeXB0cyB0aGUgbWVzc2FnZSBjb250ZW50LCBhbmQgc2VuZHMgdGhlIGVuY3J5 cHRlZAogICAgICAgIG1lc3NhZ2UgdG8gdGhlIGRlc2lyZWQgc2V0IG9mIHJlY2lwaWVudHMuIFNl Y29uZCwgZWFjaCByZWNpcGllbnQKICAgICAgICAiZGlhbHMgYmFjayIgdG8gdGhlIHNlbmRlciwg cHJvdmlkaW5nIGhpcyBwdWJsaWMga2V5OyB0aGUgc2VuZGVyIHRoZW4KICAgICAgICByZXNwb25k cyB3aXRoIHRoZSByZWxldmFudCBDRUssIHdyYXBwZWQgd2l0aCB0aGUgcmVjaXBpZW50J3MgcHVi bGljCiAgICAgICAga2V5Lgo8L3A+PGJyIC8+PGhyIGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9 ImZpZy14bXBwLXNlYyI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7 IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KICAgICAgICAgKy0t LS0tLS0rICAgKy0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0rICAgKy0tLS0tKwogICAgICAgICB8 IEFsaWNlIHwmbHQ7LSZndDt8IFNlcnZlciBBIHwmbHQ7LSZndDt8IFNlcnZlciBCIHwmbHQ7LSZn dDt8IEJvYiB8CiAgICAgICAgICstLS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICstLS0tLS0tLS0t KyAgICstLS0tLSsKICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAg ICAgICAgICAgfAogICAgICAgICAgICAgfC0tLS0tLS0tLS0tLUVuY3J5cHRlZC0tbWVzc2FnZS0t LS0tLS0tLSZndDt8CiAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwg ICAgICAgICAgIHwKICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tUHVibGljLWtleS0t LS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8 ICAgICAgICAgICB8CiAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tV3JhcHBlZCBDRUstLS0t LS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICAgfDwvcHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48 Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3Vy ZSZuYnNwOzM6IERlbGl2ZXJpbmcgYSBzZWN1cmUgWE1QUCBtZXNzYWdlJm5ic3A7PC9iPjwvZm9u dD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPlRoZSBt YWluIHRoaW5nIHRoYXQgdGhpcyBzeXN0ZW0gcmVxdWlyZXMgZnJvbSB0aGUgSk9TRSBmb3JtYXRz IGlzCiAgICAgICAgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gdmlhIGNvbnRlbnQgZW5jcnlw dGlvbiwgcGx1cyBhbiBpbnRlZ3JpdHkKICAgICAgICBjaGVjayB2aWEgYSBNQUMgZGVyaXZlZCBm cm9tIHRoZSBzYW1lIHN5bW1ldHJpYyBrZXkuIFRoZSBzZXBhcmF0aW9uIG9mCiAgICAgICAgdGhl IGtleSBleGNoYW5nZSBmcm9tIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIGVuY3J5cHRlZCBjb250 ZW50LAogICAgICAgIGhvd2V2ZXIsIHJlcXVpcmVzIHRoYXQgdGhlIEpPU0UgZW5jcnlwdGVkIG9i amVjdCBmb3JtYXQgYWxsb3cgd3JhcHBlZAogICAgICAgIHN5bW1ldHJpYyBrZXlzIHRvIGJlIGNh cnJpZWQgc2VwYXJhdGVseSBmcm9tIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZC4gSW4KICAgICAgICBh ZGRpdGlvbiwgdGhlIGVuY3J5cHRlZCBvYmplY3Qgd2lsbCBuZWVkIHRvIGhhdmUgYSB0YWcgZm9y IHRoZSBrZXkKICAgICAgICB0aGF0IHdhcyB1c2VkIHRvIGVuY3J5cHQgdGhlIGNvbnRlbnQsIHNv IHRoYXQgdGhlIHJlY2lwaWVudCAoQm9iKSBjYW4KICAgICAgICBwcmVzZW50IHRoZSB0YWcgdG8g dGhlIHNlbmRlciAoQWxpY2UpIHdoZW4gcmVxdWVzdGluZyB0aGUgd3JhcHBlZAogICAgICAgIGtl eS4KPC9wPgo8cD5Bbm90aGVyIGltcG9ydGFudCBmZWF0dXJlIG9mIFhNUFAgaXMgdGhhdCBpdCBh bGxvd3MgZm9yIHRoZQogICAgICAgIHNpbXVsdGFuZW91cyBkZWxpdmVyeSBvZiBhIG1lc3NhZ2Ug dG8gbXVsdGlwbGUgcmVjaXBpZW50cy4gSW4gdGhlCiAgICAgICAgZGlhZ3JhbXMgYWJvdmUsIFNl cnZlciBBIGNvdWxkIGRlbGl2ZXIgdGhlIG1lc3NhZ2Ugbm90IG9ubHkgdG8gU2VydmVyCiAgICAg ICAgQiAoZm9yIEJvYikgYnV0IGFsc28gdG8gU2VydmVycyBDLCBELCBFLCBldGMuIGZvciBvdGhl ciB1c2Vycy4gSW4gc3VjaAogICAgICAgIGNhc2VzLCB0byBhdm9pZCB0aGUgbXVsdGlwbGUgImRp YWwgYmFjayIgdHJhbnNhY3Rpb25zIGltcGxpZWQgYnkgdGhlCiAgICAgICAgYWJvdmUgbWVjaGFu aXNtLCBYTVBQIHN5c3RlbXMgd2lsbCBsaWtlbHkgY2FjaGUgcHVibGljIGtleXMgZm9yIGVuZAog ICAgICAgIHJlY2lwaWVudHMsIHNvIHRoYXQgd3JhcHBlZCBrZXlzIGNhbiBiZSBzZW50IGFsb25n IHdpdGggY29udGVudCBvbgogICAgICAgIGZ1dHVyZSBtZXNzYWdlcy4gVGhpcyBpbXBsaWVzIHRo YXQgdGhlIEpPU0UgZW5jcnlwdGVkIG9iamVjdCBmb3JtYXQKICAgICAgICBtdXN0IHN1cHBvcnQg dGhlIHByb3Zpc2lvbiBvZiBtdWx0aXBsZSB2ZXJzaW9ucyBvZiB0aGUgc2FtZSB3cmFwcGVkCiAg ICAgICAgQ0VLIChtdWNoIGFzIGEgQ01TIEVudmVsb3BlZERhdGEgc3RydWN0dXJlIGNhbiBpbmNs dWRlIG11bHRpcGxlCiAgICAgICAgUmVjaXBpZW50SW5mbyBzdHJ1Y3R1cmVzKS4KPC9wPgo8cD5B IHJlbGF0ZWQgZmVhdHVyZSBvZiBYTVBQIGlzIHRoYXQgaXQgYWxsb3dzIHRoZSBtZXNzYWdlIGFu ZCB0aGUKCWtleSB1c2VkIHRvIGRlY3J5cHQgdGhlIG1lc3NhZ2UgdG8gYmUgZGVsaXZlcmVkIHNl cGFyYXRlbHkuCglUaGlzIGlzIHVzZWQgdG8gZW5jcnlwdCBtZXNzYWdlcyBpbiBhIHJlY2lwaWVu dC1pbmRlcGVuZGVudCBmYXNoaW9uCgl1c2luZyBhIHJhbmRvbWx5IGdlbmVyYXRlZCBDb250ZW50 IEVuY3J5cHRpb24gS2V5IChDRUspLgoJVGhlIENFSyBpcyB0aGVuIGVuY3J5cHRlZCB0byBpbmRp dmlkdWFsIHJlY2lwaWVudHMsIGFuZCBkZWxpdmVyZWQKCXRvIHRob3NlIHJlY2lwaWVudHMgaW4g c2VwYXJhdGUgbWVzc2FnZXMuCglUaGlzIHJlcXVpcmVtZW50IGZyb20gWE1QUCBtb3RpdmF0ZWQg dGhlIERpcmVjdCBFbmNyeXB0aW9uCglrZXkgbWFuYWdlbWVudCBtb2RlIG9mIHRoZSBKT1NFIGVu Y3J5cHRlZCBvYmplY3QgZm9ybWF0IChKV0UpLgoJCjwvcD4KPHA+SW4gdGhlIGN1cnJlbnQgZHJh ZnQgb2YgdGhlIFhNUFAgZW5kLXRvLWVuZCBzZWN1cml0eSBzeXN0ZW0sIGVhY2gKICAgICAgICBw YXJ0eSBpcyBhdXRoZW50aWNhdGVkIGJ5IHZpcnR1ZSBvZiB0aGUgb3RoZXIgcGFydHkncyB0cnVz dCBpbiB0aGUKICAgICAgICBYTVBQIG1lc3NhZ2Ugcm91dGluZyBzeXN0ZW0uIFRoZSBzZW5kZXIg aXMgYXV0aGVudGljYXRlZCB0byB0aGUKICAgICAgICByZWNlaXZlciBiZWNhdXNlIGhlIGNhbiBy ZWNlaXZlIG1lc3NhZ2VzIGZvciB0aGUgaWRlbnRpZmllciAiQWxpY2UiCiAgICAgICAgKGluIHBh cnRpY3VsYXIsIHRoZSByZXF1ZXN0IGZvciB3cmFwcGVkIGtleXMpLCBhbmQgY2FuIG9yaWdpbmF0 ZQogICAgICAgIG1lc3NhZ2VzIGZvciB0aGF0IGlkZW50aWZpZXIgKHRoZSB3cmFwcGVkIGtleSku IExpa2V3aXNlLCB0aGUgcmVjZWl2ZXIKICAgICAgICBpcyBhdXRoZW50aWNhdGVkIHRvIHRoZSBz ZW5kZXIgYmVjYXVzZSBoZSByZWNlaXZlZCB0aGUgb3JpZ2luYWwKICAgICAgICBlbmNyeXB0ZWQg bWVzc2FnZSBhbmQgb3JpZ2luYXRlZCB0aGUgcmVxdWVzdCBmb3Igd3JhcHBlZCBrZXkuIFNvIHRo ZQogICAgICAgIGF1dGhlbnRpY2F0aW9uIGhlcmUgcmVxdWlyZXMgbm90IG9ubHkgdGhhdCBYTVBQ IHJvdXRpbmcgYmUgZG9uZQogICAgICAgIHByb3Blcmx5LCBidXQgYWxzbyB0aGF0IFRMUyBiZSB1 c2VkIG9uIGV2ZXJ5IGhvcC4gTW9yZW92ZXIsIGl0CiAgICAgICAgcmVxdWlyZXMgdGhhdCB0aGUg VExTIGNoYW5uZWxzIGhhdmUgc3Ryb25nIGF1dGhlbnRpY2F0aW9uLCBzaW5jZSBhIG1hbgogICAg ICAgIGluIHRoZSBtaWRkbGUgb24gYW55IG9mIHRoZSB0aHJlZSBob3BzIGNhbiBtYXNxdWVyYWRl IGFzIEJvYiBhbmQKICAgICAgICBvYnRhaW4gdGhlIGtleSBtYXRlcmlhbCBmb3IgYW4gZW5jcnlw dGVkIG1lc3NhZ2UuCjwvcD4KPHA+QmVjYXVzZSB0aGlzIGF1dGhlbnRpY2F0aW9uIGlzIHF1aXRl IHdlYWsgKGRlcGVuZGluZyBvbiB0aGUgdXNlIG9mCiAgICAgICAgdHJhbnNwb3J0LWxheWVyIHNl Y3VyaXR5IG9uIHRocmVlIGhvcHMpIGFuZCB1bnZlcmlmaWFibGUgYnkgdGhlCiAgICAgICAgZW5k cG9pbnRzLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBYTVBQIHdvcmtpbmcgZ3JvdXAgd2lsbCBp bnRlZ3JhdGUKICAgICAgICBzb21lIHNvcnQgb2YgY3JlZGVudGlhbHMgZm9yIGVuZCByZWNpcGll bnRzLCBpbiB3aGljaCBjYXNlIHRoZXJlIHdvdWxkCiAgICAgICAgbmVlZCB0byBiZSBhIHdheSB0 byBhc3NvY2lhdGUgdGhlc2UgY3JlZGVudGlhbHMgd2l0aCBKT1NFIG9iamVjdHMuCjwvcD4KPHA+ RmluYWxseSwgaXQncyB3b3J0aCBub3RpbmcgdGhhdCBYTVBQIGlzIGJhc2VkIG9uIFhNTCwgbm90 IEpTT04uIFNvCiAgICAgICAgYnkgdXNpbmcgSk9TRSwgWE1QUCB3aWxsIGJlIGNhcnJ5aW5nIEpT T04gb2JqZWN0cyB3aXRoaW4gWE1MLiBJdCBpcwogICAgICAgIHRodXMgYSBkZXNpcmFibGUgcHJv cGVydHkgZm9yIEpPU0Ugb2JqZWN0cyB0byBiZSBlbmNvZGVkIGluIHN1Y2ggYSB3YXkKICAgICAg ICBhcyB0byBiZSBzYWZlIGZvciBpbmNsdXNpb24gaW4gWE1MLiBPdGhlcndpc2UsIGFuIGV4cGxp Y2l0IENEQVRBCiAgICAgICAgaW5kaWNhdGlvbiBtdXN0IGJlIGdpdmVuIHRvIHRoZSBwYXJzZXIg dG8gaW5kaWNhdGUgdGhhdCBpdCBpcyBub3QgdG8KICAgICAgICBiZSBwYXJzZWQgYXMgWE1MLiBP bmUgd2F5IHRvIG1lZXQgdGhpcyByZXF1aXJlbWVudCB3b3VsZCBiZSB0byBhcHBseQogICAgICAg IGJhc2U2NHVybCBlbmNvZGluZywgYnV0IGZvciBYTVBQIG1lc3NhZ2VzIG9mIG1lZGl1bS10by1s YXJnZSBzaXplLAogICAgICAgIHRoaXMgY291bGQgaW1wb3NlIGEgZmFpciBkZWdyZWUgb2Ygb3Zl cmhlYWQuCjwvcD4KPGEgbmFtZT0iYWx0by1zZWMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi41LjUiPjwvYT48aDM+NS41LiZuYnNwOwpBTFRPPC9oMz4KCjxwPkFwcGxpY2F0aW9uLUxheWVy IFRyYWZmaWMgT3B0aW1pemF0aW9uIChBTFRPKSBpcyBhIHN5c3RlbSBmb3IKICAgICAgICBkaXN0 cmlidXRpbmcgbmV0d29yayB0b3BvbG9neSBpbmZvcm1hdGlvbiB0byBlbmQgZGV2aWNlcywgc28g dGhhdAogICAgICAgIHRob3NlIGRldmljZXMgY2FuIG1vZGlmeSB0aGVpciBiZWhhdmlvciB0byBo YXZlIGEgbG93ZXIgaW1wYWN0IG9uIHRoZQogICAgICAgIG5ldHdvcmsgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNJLUQuaWV0Zi1hbHRvLXJlcXMnPltJJiM4MjA5O0QuaWV0ZiYjODIwOTthbHRvJiM4 MjA5O3JlcXNdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPktpZXNlbCwgUy4sIFBy ZXZpZGksIFMuLCBTdGllbWVybGluZywgTS4sIFdvdW5keSwgUi4sIGFuZCBZLiBZYW5nLCAmbGRx dW87QXBwbGljYXRpb24tTGF5ZXIgVHJhZmZpYyBPcHRpbWl6YXRpb24gKEFMVE8pIFJlcXVpcmVt ZW50cywmcmRxdW87IEp1bmUmbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRo ZSBBTFRPIHByb3RvY29sCiAgICAgICAgZGlzdHJpYnV0ZXMgdG9wb2xvZ3kgaW5mb3JtYXRpb24g aW4gdGhlIGZvcm0gb2YgSlNPTiBvYmplY3RzIGNhcnJpZWQKICAgICAgICBpbiBIVFRQIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjUkZDMjYxNic+W1JGQzI2MTZdPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlr LCBILiwgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgJmxkcXVv O0h5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSwmcmRxdW87IEp1bmUmbmJz cDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT48YSBjbGFzcz0naW5mbycgaHJlZj0nI0kt RC5pZXRmLWFsdG8tcHJvdG9jb2wnPltJJiM4MjA5O0QuaWV0ZiYjODIwOTthbHRvJiM4MjA5O3By b3RvY29sXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbGltaSwgUi4sIFBlbm5v LCBSLiwgYW5kIFkuIFlhbmcsICZsZHF1bztBTFRPIFByb3RvY29sLCZyZHF1bzsgRmVicnVhcnkm bmJzcDsyMDEzLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRoZSBiYXNpYyB2ZXJzaW9uIG9m IEFMVE8gaXMgc2ltcGx5CiAgICAgICAgYSBjbGllbnQtc2VydmVyIHByb3RvY29sLCBzbyBzaW1w bGUgdXNlIG9mIEhUVFBTIHN1ZmZpY2VzIGZvciB0aGlzCiAgICAgICAgY2FzZSA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1JGQzI4MTgnPltSRkMyODE4XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5SZXNjb3JsYSwgRS4sICZsZHF1bztIVFRQIE92ZXIgVExTLCZyZHF1bzsgTWF5Jm5i c3A7MjAwMC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBIb3dldmVyLCB0aGVyZSBpcyBiZWdp bm5pbmcgdG8gYmUgc29tZQogICAgICAgIGRpc2N1c3Npb24gb2YgdXNlIGNhc2VzIGZvciBBTFRP IGluIHdoaWNoIHRoZXNlIEpTT04gb2JqZWN0cyB3aWxsIGJlCiAgICAgICAgZGlzdHJpYnV0ZWQg dGhyb3VnaCBhIGNvbGxlY3Rpb24gb2YgaW50ZXJtZWRpYXRlIHNlcnZlcnMgYmVmb3JlCiAgICAg ICAgcmVhY2hpbmcgdGhlIGNsaWVudCwgd2hpbGUgc3RpbGwgcHJlc2VydmluZyB0aGUgYWJpbGl0 eSBvZiB0aGUgY2xpZW50CiAgICAgICAgdG8gYXV0aGVudGljYXRlIHRoZSBvcmlnaW5hbCBzb3Vy Y2Ugb2YgdGhlIG9iamVjdC4gRXZlbiB0aGUgYmFzZSBBTFRPCiAgICAgICAgcHJvdG9jb2wgbm90 ZXMgdGhhdCAiQUxUTyBjbGllbnRzIG9idGFpbmluZyBBTFRPIGluZm9ybWF0aW9uIG11c3QgYmUK ICAgICAgICBhYmxlIHRvIHZhbGlkYXRlIHRoZSByZWNlaXZlZCBBTFRPIGluZm9ybWF0aW9uIHRv IGVuc3VyZSB0aGF0IGl0IHdhcwogICAgICAgIGdlbmVyYXRlZCBieSBhbiBhcHByb3ByaWF0ZSBB TFRPIHNlcnZlci4iCjwvcD4KPHA+SW4gdGhpcyBjYXNlLCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1l bnRzIGFyZSBzdHJhaWdodGZvcndhcmQuIEpPU0UKICAgICAgICBvYmplY3RzIGNhcnJ5aW5nIEFM VE8gcGF5bG9hZHMgd2lsbCBuZWVkIHRvIGJlYXIgZGlnaXRhbCBzaWduYXR1cmVzCiAgICAgICAg ZnJvbSB0aGUgb3JpZ2luYXRpbmcgc2VydmVycywgd2hpY2ggd2lsbCBiZSBib3VuZCB0byBjZXJ0 aWZpY2F0ZXMKICAgICAgICBhdHRlc3RpbmcgdG8gdGhlIGlkZW50aXRpZXMgb2YgdGhlIHNlcnZl cnMuIFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50CiAgICAgICAgZm9yIGNvbmZpZGVudGlhbGl0eSBp biB0aGlzIGNhc2UsIHNpbmNlIEFMVE8gaW5mb3JtYXRpb24gaXMgZ2VuZXJhbGx5CiAgICAgICAg cHVibGljLgo8L3A+CjxwPlRoZSBtb3JlIGludGVyZXN0aW5nIHF1ZXN0aW9ucyBhcmUgZW5jb2Rp bmcgcXVlc3Rpb25zLiBBTFRPIG9iamVjdHMKICAgICAgICBhcmUgbGlrZWx5IHRvIGJlIG11Y2gg bGFyZ2VyIHRoYW4gcGF5bG9hZHMgaW4gdGhlIHR3byBjYXNlcyBhYm92ZSwKICAgICAgICB3aXRo IHNpemVzIG9mIHVwIHRvIHNldmVyYWwgbWVnYWJ5dGVzLiBQcm9jZXNzaW5nIG9mIHN1Y2ggbGFy Z2UKICAgICAgICBvYmplY3RzIGNhbiBiZSBkb25lIG1vcmUgcXVpY2tseSBpZiBpdCBjYW4gYmUg ZG9uZSBpbiBhIHNpbmdsZSBwYXNzLAogICAgICAgIHdoaWNoIG1heSBiZSBwb3NzaWJsZSBpZiBK T1NFIG9iamVjdHMgcmVxdWlyZSBzcGVjaWZpYyBvcmRlcmluZ3Mgb2YKICAgICAgICBmaWVsZHMg d2l0aGluIHRoZSBKU09OIHN0cnVjdHVyZS4KPC9wPgo8cD5JbiBhZGRpdGlvbiwgYmVjYXVzZSBB TFRPIG9iamVjdHMgYXJlIGFsc28gZW5jb2RlZCBhcyBKU09OLCB0aGV5CiAgICAgICAgYXJlIGFs cmVhZHkgc2FmZSBmb3IgaW5jbHVzaW9uIGluIGEgSk9TRSBvYmplY3QuIFNpZ25lZCBKT1NFIG9i amVjdHMKICAgICAgICB3aWxsIGxpa2VseSBjYXJyeSB0aGUgc2lnbmVkIGRhdGEgaW4gYSBzdHJp bmcgYWxvbmdzaWRlIHRoZSBzaWduYXR1cmUuCiAgICAgICAgSlNPTiBvYmplY3RzIGhhdmUgdGhl IHByb3BlcnR5IHRoYXQgdGhleSBjYW4gYmUgc2FmZWx5IGVuY29kZWQgaW4gSlNPTgogICAgICAg IHN0cmluZ3MuIEFsbCB0aGV5IHJlcXVpcmUgaXMgdGhhdCB1bm5lY2Vzc2FyeSB3aGl0ZSBzcGFj ZSBiZSByZW1vdmVkLAogICAgICAgIGEgbXVjaCBzaW1wbGVyIHRyYW5zZm9ybWF0aW9uIHRoYW4s IHNheSBiYXNlNjR1cmwgZW5jb2RpbmcuIFRoaXMKICAgICAgICByYWlzZXMgdGhlIHF1ZXN0aW9u IG9mIHdoZXRoZXIgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gb3B0aW1pemUgdGhlCiAgICAgICAg Sk9TRSBlbmNvZGluZyBmb3IgY2VydGFpbiAiSlNPTi1zYWZlIiBjYXNlcy4KPC9wPgo8YSBuYW1l PSJhdG9jYS1zZWMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjYiPjwvYT48aDM+NS42 LiZuYnNwOwpFbWVyZ2VuY3kgQWxlcnRpbmc8L2gzPgoKPHA+RW1lcmdlbmN5IGFsZXJ0aW5nIGlz IGFuIGVtZXJnaW5nIHVzZSBjYXNlIGZvciBJUCBuZXR3b3JrcyA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI0ktRC5pZXRmLWF0b2NhLXJlcXVpcmVtZW50cyc+W0kmIzgyMDk7RC5pZXRmJiM4MjA5O2F0 b2NhJiM4MjA5O3JlcXVpcmVtZW50c108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ U2NodWx6cmlubmUsIEguLCBOb3JyZXlzLCBTLiwgUm9zZW4sIEIuLCBhbmQgSC4gVHNjaG9mZW5p ZywgJmxkcXVvO1JlcXVpcmVtZW50cywgVGVybWlub2xvZ3kgYW5kIEZyYW1ld29yayBmb3IgRXhp Z2VudCBDb21tdW5pY2F0aW9ucywmcmRxdW87IE1hcmNoJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LiBBbGVydGluZyBzeXN0ZW1zIGFsbG93CiAgICAgICAgYXV0aG9yaXRpZXMg dG8gd2FybiB1c2VycyBvZiBpbXBlbmRpbmcgZGFuZ2VyIGJ5IHNlbmRpbmcgYWxlcnQKICAgICAg ICBtZXNzYWdlcyB0byBjb25uZWN0ZWQgZGV2aWNlcy4gRm9yIGV4YW1wbGUsIGluIHRoZSBldmVu dCBvZiBodXJyaWNhbmUKICAgICAgICBvciB0b3JuYWRvLCBhbGVydHMgbWlnaHQgYmUgc2VudCB0 byBhbGwgZGV2aWNlcyBpbiB0aGUgcGF0aCBvZiB0aGUKICAgICAgICBzdG9ybS4KPC9wPgo8cD5U aGUgbW9zdCBjcml0aWNhbCBzZWN1cml0eSByZXF1aXJlbWVudCBmb3IgYWxlcnRpbmcgc3lzdGVt cyBpcyB0aGF0CiAgICAgICAgaXQgbXVzdCBub3QgYmUgcG9zc2libGUgZm9yIGFuIGF0dGFja2Vy IHRvIHNlbmQgZmFsc2UgYWxlcnRzIHRvCiAgICAgICAgZGV2aWNlcy4gU3VjaCBhIGNhcGFiaWxp dHkgd291bGQgcG90ZW50aWFsbHkgYWxsb3cgYW4gYXR0YWNrZXIgdG8KICAgICAgICBjcmVhdGUg d2lkZS1zcHJlYWQgcGFuaWMuIEluIHByYWN0aWNlLCBhbGVydCBzeXN0ZW1zIHByZXZlbnQgdGhl c2UKICAgICAgICBhdHRhY2tzIGJvdGggYnkgY29udHJvbHMgb24gc2VuZGluZyBtZXNzYWdlcyBh dCBwb2ludHMgd2hlcmUgYWxlcnRzCiAgICAgICAgYXJlIG9yaWdpbmF0ZWQsIGFzIHdlbGwgYXMg YnkgaGF2aW5nIHJlY2lwaWVudHMgb2YgYWxlcnRzIHZlcmlmeSB0aGF0CiAgICAgICAgdGhlIGFs ZXJ0IHdhcyBzZW50IGJ5IGFuIGF1dGhvcml6ZWQgc291cmNlLiBUaGUgZm9ybWVyIHR5cGUgb2Yg Y29udHJvbAogICAgICAgIGltcGxlbWVudGVkIHdpdGggbG9jYWwgc2VjdXJpdHkgb24gaG9zdHMg ZnJvbSB3aGljaCBhbGVydHMgY2FuIGJlCiAgICAgICAgb3JpZ2luYXRlZC4gVGhlIGxhdHRlciB0 eXBlIGltcGxlbWVudGVkIGJ5IGRpZ2l0YWwgc2lnbmF0dXJlcyBvbiBhbGVydAogICAgICAgIG1l c3NhZ2VzICh1c2luZyBjaGFubmVsLWJhc2VkIG9yIG9iamVjdC1iYXNlZCBtZWNoYW5pc21zKS4K PC9wPgo8cD5BbGVydHMgdHlwaWNhbGx5IHJlYWNoIGVuZCByZWNpcGllbnRzIHZpYSBhIHNlcmll cyBvZgogICAgICAgIGludGVybWVkaWFyaWVzLiBGb3IgZXhhbXBsZSwgd2hpbGUgYSBuYXRpb25h bCB3ZWF0aGVyIHNlcnZpY2UgbWlnaHQKICAgICAgICBvcmlnaW5hdGUgYSBodXJyaWNhbmUgYWxl cnQsIGl0IG1pZ2h0IGZpcnN0IGJlIGRlbGl2ZXJlZCB0byBhIG5hdGlvbmFsCiAgICAgICAgZ2F0 ZXdheSwgYW5kIHRoZW4gdG8gbmV0d29yayBvcGVyYXRvcnMsIHdobyBicm9hZGNhc3QgaXQgdG8g ZW5kCiAgICAgICAgc3Vic2NyaWJlcnMuCjwvcD4KPHA+PGJyIC8+PGhyIGNsYXNzPSJpbnNlcnQi IC8+CjxhIG5hbWU9ImZpZy1hdG9jYS1zZWMiPjwvYT4KPC9wPgo8ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4gICAgICAgICstLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0rICAgICstLS0tLS0t LS0tLS0rCiAgICAgICAgfCBPcmlnaW5hdG9yIHwgICAgfCBPcmlnaW5hdG9yIHwgICAgfCBPcmln aW5hdG9yIHwKICAgICAgICArLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tKyAgICArLS0t LS0tLS0tLS0tKwogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIC4gICAgICAgICAgICAg ICAgIC4KICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLi4uLi4uLi4uLi4uLi4uLi4u CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFYKICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCBHYXRld2F5IHwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgViAgICAgICAg ICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAgICAgICAgICAg ICArLS0tLS0tLS0tKwogICAgICAgICAgICAgIHwgTmV0d29yayB8ICAgICAgICAgICAgICAgfCBO ZXR3b3JrIHwKICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0t LS0rCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgKy0tLS0tLSstLS0tLSsgICAgICAgICAgICArLS0tLS0tKy0tLS0tKwogICAgICAgICAg ICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8CiAgICAgICAgICAgIFYg ICAgICAgICAgICBWICAgICAgICAgICAgViAgICAgICAgICAgIFYKICAgICAgICArLS0tLS0tLS0r ICAgKy0tLS0tLS0tKyAgICstLS0tLS0tLSsgICArLS0tLS0tLS0rCiAgICAgICAgfCBEZXZpY2Ug fCAgIHwgRGV2aWNlIHwgICB8IERldmljZSB8ICAgfCBEZXZpY2UgfAogICAgICAgICstLS0tLS0t LSsgICArLS0tLS0tLS0rICAgKy0tLS0tLS0tKyAgICstLS0tLS0tLSsKCjwvcHJlPjwvZGl2Pjxw Pgo8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWdu PSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBT YW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJzcDs0OiBEZWxpdmVyaW5nIGFu IGVtZXJnZW5jeSBhbGVydCZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwvdGFibGU+ PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8L3A+CjxwPkluIG9yZGVyIHRvIHZlcmlmeSBhbGVydCBz aWduYXR1cmVzLCByZWNpcGllbnRzIG11c3QgYmUgcHJvdmlzaW9uZWQKICAgICAgICB3aXRoIHRo ZSBwcm9wZXIgcHVibGljIGtleXMgZm9yIHRydXN0ZWQgYWxlcnQgYXV0aG9yaXRpZXMuIFRoaXMg dHJ1c3QKICAgICAgICBtYXkgYmUgInBpZWNlLXdpc2UiIGFsb25nIHRoZSBwYXRoIHRoZSBhbGVy dCB0YWtlcy4gRm9yIGV4YW1wbGUsIHRoZQogICAgICAgIGFsZXJ0IHJlbGF5cyBvcGVyYXRlZCBi eSBuZXR3b3JrcyBtaWdodCBoYXZlIGEgZnVsbCBzZXQgb2YKICAgICAgICBjZXJ0aWZpY2F0ZXMg Zm9yIGFsbCBhbGVydCBvcmlnaW5hdG9ycywgd2hpbGUgZW5kIGRldmljZXMgbWF5IG9ubHkKICAg ICAgICB0cnVzdCB0aGVpciBsb2NhbCBhbGVydCByZWxheS4gT3IgZGV2aWNlcyBtaWdodCByZXF1 aXJlIHRoYXQgYSBkZXZpY2UKICAgICAgICBiZSBzaWduZWQgYnkgYW4gYXV0aG9yaXplZCBvcmln aW5hdG9yIGFuZCBieSBpdHMgbG9jYWwgbmV0d29yaydzCiAgICAgICAgcmVsYXkuCjwvcD4KPHA+ VGhpcyBzY2VuYXJpbyBjcmVhdGVzIGEgbmVlZCBmb3IgbXVsdGlwbGUgc2lnbmF0dXJlcyBvbiBh bGVydAogICAgICAgIGRvY3VtZW50cywgc28gdGhhdCBhbiBhbGVydCBjYW4gYmVhciBzaWduYXR1 cmVzIGZyb20gYW55IG9yIGFsbCBvZiB0aGUKICAgICAgICBlbnRpdGllcyB0aGF0IHByb2Nlc3Nl ZCBpdCBhbG9uZyB0aGUgcGF0aC4gSW4gb3JkZXIgdG8gbWluaW1pemUKICAgICAgICBjb21wbGV4 aXR5LCB0aGVzZSBzaWduYXR1cmVzIHNob3VsZCBiZSAibW9kdWxhciIsIGluIHRoZSBzZW5zZSB0 aGF0IGEKICAgICAgICBuZXcgc2lnbmF0dXJlIGNhbiBiZSBhZGRlZCB3aXRob3V0IGEgbmVlZCB0 byBhbHRlciBvciByZWNvbXB1dGUKICAgICAgICBwcmV2aW91cyBzaWduYXR1cmVzLgo8L3A+Cjxh IG5hbWU9IndlYmNyeXB0by1zZWMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjciPjwv YT48aDM+NS43LiZuYnNwOwpXZWIgQ3J5cHRvZ3JhcGh5PC9oMz4KCjxwPlRoZSBXM0MgV2ViIENy eXB0b2dyYXBoeSBBUEkgZGVmaW5lcyBhIHN0YW5kYXJkIGNyeXB0b2dyYXBoaWMgQVBJIGZvciB0 aGUKICAgICAgV2ViIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjV2ViQ3J5cHRvJz5bV2ViQ3J5cHRv XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5TbGVldmksIFIuIGFuZCBELiBEYWhs LCAmbGRxdW87V2ViIENyeXB0b2dyYXBoeSBBUEksJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAxMy48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiAgSWYgYSBicm93c2VyIGV4cG9zZXMgdGhpcyBBUEks IHRoZW4gCiAgICAgIEphdmFTY3JpcHQgcHJvdmlkZWQgYXMgcGFydCBvZiBhIFdlYiBwYWdlIGNh biBhc2sgdGhlIGJyb3dzZXIgdG8gcGVyZm9ybSAKICAgICAgY3J5cHRvZ3JhcGhpYyBvcGVyYXRp b25zLCBzdWNoIGFzIGRpZ2VzdCwgTUFDLCBlbmNyeXB0aW9uLCBvciBkaWdpdGFsIHNpZ25pbmcu CjwvcD4KPHA+T25lIG9mIHRoZSBrZXkgcmVhc29ucyB0byBoYXZlIHRoZSBicm93c2VyIHBlcmZv cm0gY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zICAKICAgICAgaXMgdG8gYXZvaWQgYWxsb3dpbmcg SmF2YVNjcmlwdCBjb2RlIHRvIGFjY2VzcyB0aGUga2V5aW5nIG1hdGVyaWFsIHVzZWQgZm9yIHRo ZXNlCiAgICAgIG9wZXJhdGlvbnMuICBGb3IgZXhhbXBsZSwgdGhpcyBzZXBhcmF0aW9uIHdvdWxk IHByZXZlbnQgY29kZSBpbmplY3RlZCB0aHJvdWdoIGEKICAgICAgY3Jvc3Mtc2l0ZSBzY3JpcHRp bmcgKFhTUykgYXR0YWNrIGZyb20gcmVhZGluZyBhbmQgZXhmaWx0cmF0aW5nIGtleXMgc3RvcmVk IAogICAgICB3aXRoaW4gYSBicm93c2VyLiAgV2hpbGUgdGhlIG1hbGljaW91cyBjb2RlIGNvdWxk IHN0aWxsIHVzZSB0aGUga2V5IHdoaWxlIHJ1bm5pbmcKICAgICAgaW4gdGhlIGJyb3dzZXIsIHRo aXMgdnVsbmVyYWJpbGl0eSBjYW4gb25seSBiZSBleGVyY2lzZWQgd2hpbGUgdGhlIHZ1bG5lcmFi bGUKICAgICAgcGFnZSBpcyBhY3RpdmUgaW4gYSB1c2VyJ3MgYnJvd3Nlci4KPC9wPgo8cD5Ib3dl dmVyLCB0aGUgV2ViQ3J5cHRvZ3JhcGh5IEFQSSBhbHNvIHByb3ZpZGVzIGEga2V5IGV4cG9ydCBm dW5jdGlvbmFsaXR5LCAKICAgICAgd2hpY2ggY2FuIGFsbG93IEphdmFTY3JpcHQgdG8gZXh0cmFj dCBhIGtleSBmcm9tIHRoZSBBUEkgaW4gd3JhcHBlZCBmb3JtLiAgRm9yCiAgICAgIGV4YW1wbGUs IHRoZSBKYXZhU2NyaXB0IG1pZ2h0IHByb3ZpZGUgYSBwdWJsaWMga2V5IGZvciB3aGljaCB0aGUg Y29ycmVzcG9uZGluZwogICAgICBwcml2YXRlIGtleSBpcyBoZWxkIGJ5IGFub3RoZXIgZGV2aWNl LiAgVGhlIHdyYXBwZWQga2V5IHByb3ZpZGVkIGJ5IHRoZSBBUEkgCiAgICAgIGNvdWxkIHRoZW4g YmUgdXNlZCB0byBzYWZlbHkgdHJhbnNwb3J0IHRoZSBrZXkgdG8gdGhlIG5ldyBkZXZpY2UuICBX aGlsZSB0aGlzCiAgICAgIGNvdWxkIHBvdGVudGlhbGx5IGFsbG93IG1hbGljaW91cyBjb2RlIHRv IGV4cG9ydCBhIGtleSwgdGhlIG5lZWQgZm9yIGFuIGV4cGxpY2l0CiAgICAgIGV4cG9ydCBvcGVy YXRpb24gcHJvdmlkZXMgYSBjb250cm9sIHBvaW50LCBhbGxvd2luZyBmb3IgdXNlciBub3RpZmlj YXRpb24gb3IKICAgICAgY29uc2VudCB2ZXJpZmljYXRpb24uCjwvcD4KPHA+VGhlIFdlYiBDcnlw dG9ncmFwaHkgQVBJIGFsc28gYWxsb3dzIGJyb3dzZXJzIHRvIGltcG9zZSBsaW1pdGF0aW9ucyBv biB0aGUgCiAgICAgIHVzYWdlIG9mIHRoZSBrZXlzIGl0IGhhbmRsZXMuICBGb3IgZXhhbXBsZSwg YSBzeW1tZXRyaWMga2V5IG1pZ2h0IGJlIG1hcmtlZCBhcyAKICAgICAgdXNhYmxlIG9ubHkgZm9y IGVuY3J5cHRpb24sIGFuZCBub3QgZm9yIE1BQy4gIFdoZW4gYSBrZXkgaXMgZXhwb3J0ZWQgaW4g d3JhcHBlZCAKICAgICAgZm9ybSwgdGhlc2UgYXR0cmlidXRlcyBzaG91bGQgYmUgY2FycmllZCBh bG9uZyB3aXRoIGl0Lgo8L3A+CjxwPlRoZSBXZWIgQ3J5cHRvZ3JhcGh5IEFQSSB0aHVzIHJlcXVp cmVzIGZvcm1hdHMgdG8gZXhwcmVzcyBzZXZlcmFsIGZvcm1zIG9mCiAgICAgIGtleXMuICBPYnZp b3VzbHksIHRoZSBwdWJsaWMga2V5IGZyb20gYW4gYXN5bW1ldHJpYyBrZXkgcGFpciBjYW4gYmUg ZnJlZWx5IAogICAgICBpbXBvcnRlZCB0byBhbmQgZXhwb3J0ZWQgZnJvbSB0aGUgYnJvd3Nlciwg c28gdGhlcmUgbmVlZHMgdG8gYmUgYSBmb3JtYXQgZm9yCiAgICAgIHB1YmxpYyBrZXlzLiAgVGhl cmUgaXMgYWxzbyBhIG5lZWQgZm9yIGEgZm9ybWF0IHRvIGV4cHJlc3MgcHJpdmF0ZSBrZXlzIGFu ZAogICAgICBzeW1tZXRyaWMga2V5cy4gIEZvciBub24tcHVibGljIGtleXMsIHRoZSBwcmltYXJ5 IG5lZWQgaXMgZm9yIGEgd3JhcHBlZCBmb3JtLAogICAgICB3aGVyZSB0aGUgY29uZmlkZW50aWFs aXR5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIGtleSBpcyBhc3N1cmVkIGNyeXB0b2dyYXBoaWNhbGx5 OwogICAgICB0aGVzZSBwcm90ZWN0aW9ucyBzaG91bGQgYWxzbyBhcHBseSB0byBhbnkgYXR0cmli dXRlcyBvZiB0aGUga2V5LiAgSXQgbWF5IGFsc28KICAgICAgYmUgdXNlZnVsIHRvIGRlZmluZSBh IGRpcmVjdCwgdW53cmFwcGVkIGZvcm1hdCwgZm9yIHVzZSB3aXRoaW4gYSBzZWN1cml0eSAKICAg ICAgYm91bmRhcnkuCjwvcD4KPGEgbmFtZT0icmVxLXNlYyI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjYiPjwvYT48aDM+Ni4mbmJzcDsKUmVxdWlyZW1lbnRzPC9oMz4KCjxwPlRoaXMgc2Vj dGlvbiBzdW1tYXJpemVzIHRoZSByZXF1aXJlbWVudHMgZnJvbSB0aGUgYWJvdmUgdXNlcyBjYXNl cywgYW5kCiAgICAgIGxpc3RzIGZ1cnRoZXIgcmVxdWlyZW1lbnRzIG5vdCBkaXJlY3RseSBkZXJp dmVkIGZyb20gdGhlIGFib3ZlIHVzZSBjYXNlcy4KICAgICAgVGhlcmUgYXJlIGFsc28gc29tZSBj b25zdHJhaW50cyB0aGF0IGFyZSBub3QgaGFyZCByZXF1aXJlbWVudHMsIGJ1dCB3aGljaAogICAg ICBhcmUgc3RpbGwgZGVzaXJhYmxlIHByb3BlcnRpZXMgZm9yIHRoZSBKT1NFIHN5c3RlbSB0byBo YXZlLgo8L3A+CjxhIG5hbWU9ImZ1bmN0aW9uYWwtc2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uNi4xIj48L2E+PGgzPjYuMS4mbmJzcDsKRnVuY3Rpb25hbCBSZXF1aXJlbWVudHM8L2gz PgoKPHA+PC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+RjE8L2R0Pgo8ZGQ+ RGVmaW5lIGZvcm1hdHMgZm9yIHNlY3VyZSBvYmplY3RzIHRoYXQgcHJvdmlkZSB0aGUgZm9sbG93 aW5nCiAgICAgICAgICBzZWN1cml0eSBwcm9wZXJ0aWVzOgogICAgICAgICAgICAKPHVsIGNsYXNz PSJ0ZXh0Ij4KPGxpPkRpZ2l0YWwgc2lnbmF0dXJlIChpbnRlZ3JpdHkvYXV0aGVudGljYXRpb24g dW5kZXIgYW4gYXN5bW1ldHJpYyBrZXkgcGFpcikKPC9saT4KPGxpPk1lc3NhZ2UgYXV0aGVudGlj YXRpb24gKGludGVncml0eS9hdXRoZW50aWNhdGlvbiB1bmRlciBhIHN5bW1ldHJpYyBrZXkpCjwv bGk+CjxsaT5FbmNyeXB0aW9uCjwvbGk+CjxsaT5BdXRoZW50aWNhdGVkIGVuY3J5cHRpb24KPC9s aT4KPC91bD4KICAgICAgICAgIFRoYXQgaXMsIHRoZSBzZWN1cmUgb2JqZWN0cyBkZWZpbmVkIGJ5 IHRoaXMgd29ya2luZyBncm91cCBzaG91bGQgcHJvdmlkZSAKICAgICAgICAgIGVxdWl2YWxlbnQg c2VjdXJpdHkgcHJvcGVydGllcyB0byB0aGUgQ01TIFNpZ25lZERhdGEsIEF1dGhlbnRpY2F0ZWRE YXRhLCAKICAgICAgICAgIEVudmVsb3BlZERhdGEsIGFuZCBBdXRoRW52ZWxvcGVkIGRhdGEgb2Jq ZWN0cyA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzU2NTInPltSRkM1NjUyXTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Ib3VzbGV5LCBSLiwgJmxkcXVvO0NyeXB0b2dyYXBoaWMg TWVzc2FnZSBTeW50YXggKENNUyksJnJkcXVvOyBTZXB0ZW1iZXImbmJzcDsyMDA5Ljwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4KICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTA4 Myc+W1JGQzUwODNdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhvdXNsZXksIFIu LCAmbGRxdW87Q3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCAoQ01TKSBBdXRoZW50aWNhdGVk LUVudmVsb3BlZC1EYXRhIENvbnRlbnQgVHlwZSwmcmRxdW87IE5vdmVtYmVyJm5ic3A7MjAwNy48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L2RkPgo8ZHQ+RjI8L2R0Pgo8ZGQ+RGVmaW5lIGEg Zm9ybWF0IGZvciBwdWJsaWMga2V5cyBhbmQgcHJpdmF0ZSBrZXlzIGZvciAKICAgICAgICAgIGFz eW1tZXRyaWMgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zLCB3aXRoIGFzc29jaWF0ZWQgYXR0cmli dXRlcywgaW5jbHVkaW5nIGEKICAgICAgICAgIHdyYXBwZWQgZm9ybSBmb3IgcHJpdmF0ZSBrZXlz Lgo8L2RkPgo8ZHQ+RjM8L2R0Pgo8ZGQ+RGVmaW5lIGEgZm9ybWF0IGZvciBzeW1tZXRyaWMga2V5 cyB3aXRoIGFzc29jaWF0ZWQgYXR0cmlidXRlcywKICAgICAgICAgIGFsbG93aW5nIGZvciBib3Ro IHdyYXBwZWQgYW5kIHVud3JhcHBlZCBrZXlzLgo8L2RkPgo8ZHQ+RjQ8L2R0Pgo8ZGQ+RGVmaW5l IEpTT04gc2VyaWFsaXphdGlvbnMgZm9yIHRoZSBhYm92ZSBvYmplY3RzLiAgQW4gb2JqZWN0CiAg ICAgICAgICBpbiB0aGlzIGVuY29kaW5nIG11c3QgYmUgdmFsaWQgYWNjb3JkaW5nIHRvIHRoZSBK U09OIEFCTkYgc3ludGF4IAogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NjI3 Jz5bUkZDNDYyN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q3JvY2tmb3JkLCBE LiwgJmxkcXVvO1RoZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQg T2JqZWN0IE5vdGF0aW9uIChKU09OKSwmcmRxdW87IEp1bHkmbmJzcDsyMDA2Ljwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4KPC9kZD4KPGR0PkY1PC9kdD4KPGRkPkRlZmluZSBjb21wYWN0LCBVUkwt c2FmZSB0ZXh0IHNlcmlhbGl6YXRpb25zIGZvciB0aGUgYWJvdmUgCiAgICAgICAgICBvYmplY3Rz Lgo8L2RkPgo8ZHQ+RjY8L2R0Pgo8ZGQ+QWxsb3cgZm9yIGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB0 byB3cmFwcGVkIGtleXMgdG8gYmUgYm91bmQgCiAgICAgICAgICB0byB0aGVtIGNyeXB0b2dyYXBo aWNhbGx5CjwvZGQ+CjxkdD5GNzwvZHQ+CjxkZD5BbGxvdyBmb3Igd3JhcHBlZCBrZXlzIHRvIGJl IHNlcGFyYXRlZCBmcm9tIGEgc2VjdXJlIG9iamVjdCAKICAgICAgICAgIHRoYXQgdXNlcyBhIHN5 bW1ldHJpYyBrZXkuICBJbiBzdWNoIGNhc2VzLCBjcnlwdG9ncmFwaGljIGNvbXBvbmVudHMgb2Yg dGhlIAogICAgICAgICAgc2VjdXJlIG9iamVjdCBvdGhlciB0aGFuIHRoZSB3cmFwcGVkIGtleSAo ZS5nLiwgY2lwaGVydGV4dCwgTUFDIHZhbHVlcykgbXVzdAogICAgICAgICAgYmUgaW5kZXBlbmRl bnQgb2YgdGhlIHdyYXBwZWQgZm9ybSBvZiB0aGUga2V5LiAgRm9yIGV4YW1wbGUsIGlmIGFuIGVu Y3J5cHRlZAogICAgICAgICAgb2JqZWN0IGlzIHByZXBhcmVkIGZvciBtdWx0aXBsZSByZWNpcGll bnRzLCB0aGVuIG9ubHkgdGhlIHdyYXBwZWQga2V5IG1heSB2YXJ5LAogICAgICAgICAgbm90IHRo ZSBjaXBoZXJ0ZXh0Lgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxhIG5hbWU9InNlYy1yZXEt c2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4yIj48L2E+PGgzPjYuMi4mbmJzcDsK U2VjdXJpdHkgUmVxdWlyZW1lbnRzPC9oMz4KCjxwPjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRl eHQiPjxkbD4KPGR0PlMxPC9kdD4KPGRkPlByb3ZpZGUga2V5IG1hbmFnZW1lbnQgZnVuY3Rpb25z IGZvciBlcGhlbWVyYWwgc3ltbWV0cmljIGtleXMsCiAgICAgICAgaW5jbHVkaW5nIGVuY3J5cHRp b24ga2V5cyBhbmQgTUFDIGtleXMuICBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIGFueQog ICAgICAgIG9mIHRoZSBrZXkgbWFuYWdlbWVudCB0ZWNobmlxdWVzIHByb3ZpZGVkIGluIENNUyA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzU2NTInPltSRkM1NjUyXTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5Ib3VzbGV5LCBSLiwgJmxkcXVvO0NyeXB0b2dyYXBoaWMgTWVzc2Fn ZSBTeW50YXggKENNUyksJnJkcXVvOyBTZXB0ZW1iZXImbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT46CiAgICAgICAgICAKPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPktleSB0cmFuc3Bv cnQgKHdyYXBwaW5nIGZvciBhIHB1YmxpYyBrZXkpCjwvbGk+CjxsaT5LZXkgZW5jaXBoZXJtZW50 ICh3cmFwcGluZyBmb3IgYSBzeW1tZXRyaWMga2V5KQo8L2xpPgo8bGk+S2V5IGFncmVlbWVudCAo d3JhcHBpbmcgZm9yIGEgREggcHVibGljIGtleSkKPC9saT4KPGxpPlBhc3N3b3JkLWJhc2VkIGVu Y3J5cHRpb24gKHdyYXBwaW5nIHVuZGVyIGEgZGVyaXZlZCBrZXkpCjwvbGk+CjwvdWw+CglhcyB3 ZWxsIGFzIHRoZSBEaXJlY3QgRW5jcnlwdGlvbiBrZXkgbWFuYWdlbWVudCB0ZWNobmlxdWUuCiAg ICAgICAgCjwvZGQ+CjxkdD5TMjwvZHQ+CjxkZD5Vc2UgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1z IGluIGEgbWFubmVyIGNvbXBhdGlibGUgd2l0aAogICAgICAgIG1ham9yIHZhbGlkYXRpb24gcHJv Y2Vzc2VzLiAgRm9yIGV4YW1wbGUsIGlmIGEgRklQUyBzdGFuZGFyZCBhbGxvd3MgCiAgICAgICAg YWxnb3JpdGhtIEEgdG8gYmUgdXNlZCBmb3IgcHVycG9zZSBYIGJ1dCBub3QgcHVycG9zZSBZLCB0 aGVuIEpPU0Ugc2hvdWxkCiAgICAgICAgbm90IHJlY29tbWVuZCB1c2luZyBhbGdvcml0aG0gQSBm b3IgcHVycG9zZSBZLgo8L2RkPgo8ZHQ+UzM8L2R0Pgo8ZGQ+U3VwcG9ydCBvcGVyYXRpb24gd2l0 aCBvciB3aXRob3V0IHByZS1uZWdvdGlhdGlvbi4gIAogICAgICAgIEl0IG11c3QgYmUgcG9zc2li bGUgdG8gY3JlYXRlIG9yIHByb2Nlc3Mgc2VjdXJlIG9iamVjdHMgd2l0aG91dAogICAgICAgIGFu eSBjb25maWd1cmF0aW9uIGJleW9uZCBrZXkgcHJvdmlzaW9uaW5nLiAgSWYgaXQgaXMgcG9zc2li bGUgdG8gbmVnb3RpYXRlIAogICAgICAgIHBhcmFtZXRlcnMgb3V0IG9mIGJhbmQsIHRoZW4gaXQg bXVzdCBiZSBwb3NzaWJsZSB0byBzaWduYWwgdGhhdCBwcmUtbmVnb3RpYXRlZCAKICAgICAgICBw YXJhbWV0ZXJzIGFyZSB0byBiZSB1c2VkLgo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCjxhIG5h bWU9ImRlc2lkZXJhdGEtc2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4zIj48L2E+ PGgzPjYuMy4mbmJzcDsKRGVzaWRlcmF0YTwvaDM+Cgo8cD48L3A+CjxibG9ja3F1b3RlIGNsYXNz PSJ0ZXh0Ij48ZGw+CjxkdD5EMTwvZHQ+CjxkZD5NYXhpbWl6ZSBjb21wYXRpYmlsaXR5IHdpdGgg dGhlIFczQyBXZWJDcnlwdG8gCiAgICAgICAgICBzcGVjaWZpY2F0aW9ucywgZS5nLiwgYnkgY29v cmRpbmF0aW5nIHdpdGggdGhlIFdlYkNyeXB0byB3b3JraW5nIGdyb3VwCgkgIHJlcXVlc3Rpbmcg dGhhdCB0aGV5IHN1cHBvcnQgdXNpbmcgdGhlIGFsZ29yaXRobXMgbmVlZGVkIGJ5IEpPU0UgaW1w bGVtZW50YXRpb25zLAoJICBieSBzdWdnZXN0aW5nIHRoYXQgdGhleSB1c2UgSk9TRSBkYXRhIGZv cm1hdHMgd2hlcmUgdGhlc2UgbWFrZSBzZW5zZSwKCSAgYW5kIGJ5IHN1Z2dlc3RpbmcgdGhhdCB0 aGV5IHVzZSB0aGUgc2FtZSBpZGVudGlmaWVycyBmb3IgYWxnb3JpdGhtcyBhcyBKT1NFLAoJICBp biBjYXNlcyB3aGVyZSB0aGlzIG1ha2VzIHNlbnNlLgo8L2RkPgo8ZHQ+RDI8L2R0Pgo8ZGQ+QXZv aWQgSlNPTiBjYW5vbmljYWxpemF0aW9uIHRvIHRoZSBleHRlbnQgcG9zc2libGUuCgkgIFRoYXQg aXMsIGFsbCBvdGhlciB0aGluZ3MgYmVpbmcgZXF1YWwsIHRlY2huaXF1ZXMgdGhhdCByZWx5IAog ICAgICAgICAgb24gZml4aW5nIGEgc2VyaWFsaXphdGlvbiBvZiBhbiBvYmplY3QgKGUuZy4sIGJ5 IGJhc2U2NHVybCBlbmNvZGluZyBpdCkgCiAgICAgICAgICBhcmUgcHJlZmVycmVkIG92ZXIgdGhv c2UgdGhhdCByZXF1aXJlIGNvbnZlcnRpbmcgYW4gb2JqZWN0IHRvIGEgCiAgICAgICAgICBjYW5v bmljYWwgZm9ybS4KPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+Cgo8YSBuYW1lPSJpYW5hLXNlYyI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjciPjwvYT48aDM+Ny4mbmJzcDsKSUFOQSBDb25z aWRlcmF0aW9uczwvaDM+Cgo8cD5UaGlzIGRvY3VtZW50IG1ha2VzIG5vIHJlcXVlc3Qgb2YgSUFO QS4KPC9wPgo8YSBuYW1lPSJzZWMtY29ucy1zZWMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi44Ij48L2E+PGgzPjguJm5ic3A7ClNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9oMz4KCjxwPlRo ZSBwcmltYXJ5IGZvY3VzIG9mIHRoaXMgZG9jdW1lbnQgaXMgdGhlIHJlcXVpcmVtZW50cyBmb3Ig YQogICAgICBKU09OLWJhc2VkIHNlY3VyZSBvYmplY3QgZm9ybWF0LiBBdCB0aGUgbGV2ZWwgb2Yg Z2VuZXJhbCBzZWN1cml0eQogICAgICBjb25zaWRlcmF0aW9ucyBmb3Igb2JqZWN0LWJhc2VkIHNl Y3VyaXR5IHRlY2hub2xvZ2llcywgdGhlIHNlY3VyaXR5CiAgICAgIGNvbnNpZGVyYXRpb25zIGZv ciB0aGlzIGZvcm1hdCBhcmUgdGhlIHNhbWUgYXMgZm9yIENNUyA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI1JGQzU2NTInPltSRkM1NjUyXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5I b3VzbGV5LCBSLiwgJmxkcXVvO0NyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50YXggKENNUyksJnJk cXVvOyBTZXB0ZW1iZXImbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRoZSBw cmltYXJ5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgSk9TRSBmb3JtYXQgYW5kCiAgICAgIENNUyBp cyB0aGF0IEpPU0UgaXMgYmFzZWQgb24gSlNPTiwgd2hpY2ggZG9lcyBub3QgaGF2ZSBhIGNhbm9u aWNhbAogICAgICByZXByZXNlbnRhdGlvbi4gVGhlIGxhY2sgb2YgYSBjYW5vbmljYWwgZm9ybSBt ZWFucyB0aGF0IGl0IGlzIGRpZmZpY3VsdAogICAgICB0byBkZXRlcm1pbmUgd2hldGhlciB0d28g SlNPTiBvYmplY3RzIHJlcHJlc2VudCB0aGUgc2FtZSBpbmZvcm1hdGlvbiwKICAgICAgd2hpY2gg Y291bGQgbGVhZCB0byB2dWxuZXJhYmlsaXRpZXMgaW4gc29tZSB1c2FnZXMgb2YgSk9TRS4KPC9w Pgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlcyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjki PjwvYT48aDM+OS4mbmJzcDsKUmVmZXJlbmNlczwvaDM+Cgo8YSBuYW1lPSJyZmMucmVmZXJlbmNl czEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8aDM+OS4xLiZuYnNwO05vcm1hdGl2ZSBSZWZlcmVuY2VzPC9oMz4KPHRhYmxl IHdpZHRoPSI5OSUiIGJvcmRlcj0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxp Z249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtYWx0by1wcm90b2NvbCI+W0ktRC5pZXRmLWFsdG8t cHJvdG9jb2xdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkFsaW1pLCBSLiwgUGVu bm8sIFIuLCBhbmQgWS4gWWFuZywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYWx0by1wcm90b2NvbC0xNCI+QUxUTyBQcm90b2NvbDwvYT4sJnJk cXVvOyBkcmFmdC1pZXRmLWFsdG8tcHJvdG9jb2wtMTQgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJy dWFyeSZuYnNwOzIwMTMgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtYWx0by1wcm90b2NvbC0xNC50eHQiPlRYVDwvYT4pLjwvdGQ+PC90cj4K PHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJJLUQuaWV0 Zi1hbHRvLXJlcXMiPltJLUQuaWV0Zi1hbHRvLXJlcXNdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiPktpZXNlbCwgUy4sIFByZXZpZGksIFMuLCBTdGllbWVybGluZywgTS4sIFdvdW5k eSwgUi4sIGFuZCBZLiBZYW5nLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1hbHRvLXJlcXMtMTYiPkFwcGxpY2F0aW9uLUxheWVyIFRyYWZmaWMg T3B0aW1pemF0aW9uIChBTFRPKSBSZXF1aXJlbWVudHM8L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1h bHRvLXJlcXMtMTYgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lJm5ic3A7MjAxMiAoPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hbHRvLXJlcXMt MTYudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtYXRvY2EtcmVxdWlyZW1lbnRzIj5bSS1ELmll dGYtYXRvY2EtcmVxdWlyZW1lbnRzXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5T Y2h1bHpyaW5uZSwgSC4sIE5vcnJleXMsIFMuLCBSb3NlbiwgQi4sIGFuZCBILiBUc2Nob2Zlbmln LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1h dG9jYS1yZXF1aXJlbWVudHMtMDMiPlJlcXVpcmVtZW50cywgVGVybWlub2xvZ3kgYW5kIEZyYW1l d29yayBmb3IgRXhpZ2VudCBDb21tdW5pY2F0aW9uczwvYT4sJnJkcXVvOyBkcmFmdC1pZXRmLWF0 b2NhLXJlcXVpcmVtZW50cy0wMyAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoJm5ic3A7MjAxMiAo PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1h dG9jYS1yZXF1aXJlbWVudHMtMDMudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtam9zZS1qc29u LXdlYi1hbGdvcml0aG1zIj5bSS1ELmlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zXTwvYT48 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Kb25lcywgTS4sICZsZHF1bzs8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3Jp dGhtcy0xMCI+SlNPTiBXZWIgQWxnb3JpdGhtcyAoSldBKTwvYT4sJnJkcXVvOyBkcmFmdC1pZXRm LWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0xMCAod29yayBpbiBwcm9ncmVzcyksIEFwcmlsJm5i c3A7MjAxMyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMTAudHh0Ij5UWFQ8L2E+LCA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0xMC5wZGYiPlBERjwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJJLUQuaWV0Zi1qb3NlLWpzb24t d2ViLWVuY3J5cHRpb24iPltJLUQuaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb25dPC9hPjwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvbmVzLCBNLiwgUmVzY29ybGEsIEUuLCBhbmQg Si4gSGlsZGVicmFuZCwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTEwIj5KU09OIFdlYiBFbmNyeXB0 aW9uIChKV0UpPC9hPiwmcmRxdW87IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9u LTEwICh3b3JrIGluIHByb2dyZXNzKSwgQXByaWwmbmJzcDsyMDEzICg8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5j cnlwdGlvbi0xMC50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTEwLnBkZiI+ UERGPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0 b3AiPjxhIG5hbWU9IkktRC5pZXRmLWpvc2UtanNvbi13ZWIta2V5Ij5bSS1ELmlldGYtam9zZS1q c29uLXdlYi1rZXldPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvbmVzLCBNLiwg JmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1rZXktMTAiPkpTT04gV2ViIEtleSAoSldLKTwvYT4sJnJkcXVvOyBkcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWIta2V5LTEwICh3b3JrIGluIHByb2dyZXNzKSwgQXByaWwmbmJzcDsy MDEzICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWIta2V5LTEwLnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0x MC5wZGYiPlBERjwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZh bGlnbj0idG9wIj48YSBuYW1lPSJJLUQuaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZSI+W0kt RC5pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij5Kb25lcywgTS4sIEJyYWRsZXksIEouLCBhbmQgTi4gU2FraW11cmEsICZsZHF1bzs8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13 ZWItc2lnbmF0dXJlLTEwIj5KU09OIFdlYiBTaWduYXR1cmUgKEpXUyk8L2E+LCZyZHF1bzsgZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0xMCAod29yayBpbiBwcm9ncmVzcyksIEFw cmlsJm5ic3A7MjAxMyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0xMC50eHQiPlRYVDwvYT4sIDxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1zaWduYXR1cmUtMTAucGRmIj5QREY8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQg Y2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtb2F1dGgt anNvbi13ZWItdG9rZW4iPltJLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbl08L2E+PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Sm9uZXMsIE0uLCBCcmFkbGV5LCBKLiwgYW5kIE4uIFNh a2ltdXJhLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNyI+SlNPTiBXZWIgVG9rZW4gKEpXVCk8L2E+LCZy ZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNyAod29yayBpbiBwcm9ncmVz cyksIEFwcmlsJm5ic3A7MjAxMyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNy50eHQiPlRYVDwvYT4s IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt b2F1dGgtanNvbi13ZWItdG9rZW4tMDcucGRmIj5QREY8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQg Y2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELm1pbGxlci14bXBw LWUyZSI+W0ktRC5taWxsZXIteG1wcC1lMmVdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPk1pbGxlciwgTS4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1taWxsZXIteG1wcC1lMmUtMDQiPkVuZC10by1FbmQgT2JqZWN0IEVuY3J5cHRpb24g Zm9yIHRoZSBFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQgUHJlc2VuY2UgUHJvdG9jb2wgKFhNUFAp PC9hPiwmcmRxdW87IGRyYWZ0LW1pbGxlci14bXBwLWUyZS0wNCAod29yayBpbiBwcm9ncmVzcyks IEZlYnJ1YXJ5Jm5ic3A7MjAxMyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWlsbGVyLXhtcHAtZTJlLTA0LnR4dCI+VFhUPC9hPikuPC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzQ2 MjciPltSRkM0NjI3XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Dcm9ja2ZvcmQs IEQuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDYyNyI+ VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlwZSBmb3IgSmF2YVNjcmlwdCBPYmplY3QgTm90 YXRpb24gKEpTT04pPC9hPiwmcmRxdW87IFJGQyZuYnNwOzQ2MjcsIEp1bHkmbmJzcDsyMDA2ICg8 YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM0NjI3LnR4dCI+VFhUPC9h PikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxh IG5hbWU9IlJGQzQ2NDgiPltSRkM0NjQ4XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5Kb3NlZnNzb24sIFMuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNDY0OCI+VGhlIEJhc2UxNiwgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2Rpbmdz PC9hPiwmcmRxdW87IFJGQyZuYnNwOzQ2NDgsIE9jdG9iZXImbmJzcDsyMDA2ICg8YSBocmVmPSJo dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM0NjQ4LnR4dCI+VFhUPC9hPikuPC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJG QzQ5NDkiPltSRkM0OTQ5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5TaGlyZXks IFIuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDk0OSI+ SW50ZXJuZXQgU2VjdXJpdHkgR2xvc3NhcnksIFZlcnNpb24gMjwvYT4sJnJkcXVvOyBSRkMmbmJz cDs0OTQ5LCBBdWd1c3QmbmJzcDsyMDA3ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JmYy9yZmM0OTQ5LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJh dXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzUwODMiPltSRkM1MDgzXTwvYT48 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Ib3VzbGV5LCBSLiwgJmxkcXVvOzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUwODMiPkNyeXB0b2dyYXBoaWMgTWVzc2Fn ZSBTeW50YXggKENNUykgQXV0aGVudGljYXRlZC1FbnZlbG9wZWQtRGF0YSBDb250ZW50IFR5cGU8 L2E+LCZyZHF1bzsgUkZDJm5ic3A7NTA4MywgTm92ZW1iZXImbmJzcDsyMDA3ICg8YSBocmVmPSJo dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MDgzLnR4dCI+VFhUPC9hPikuPC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJG QzU2NTIiPltSRkM1NjUyXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Ib3VzbGV5 LCBSLiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU2NTIi PkNyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50YXggKENNUyk8L2E+LCZyZHF1bzsgU1REJm5ic3A7 NzAsIFJGQyZuYnNwOzU2NTIsIFNlcHRlbWJlciZuYnNwOzIwMDkgKDxhIGhyZWY9Imh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzU2NTIudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0 cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNjEyMCI+ W1JGQzYxMjBdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPlNhaW50LUFuZHJlLCBQ LiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxMjAiPkV4 dGVuc2libGUgTWVzc2FnaW5nIGFuZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCk6IENvcmU8L2E+ LCZyZHF1bzsgUkZDJm5ic3A7NjEyMCwgTWFyY2gmbmJzcDsyMDExICg8YSBocmVmPSJodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2MTIwLnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8 dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzY3NDki PltSRkM2NzQ5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5IYXJkdCwgRC4sICZs ZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5Ij5UaGUgT0F1 dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrPC9hPiwmcmRxdW87IFJGQyZuYnNwOzY3NDks IE9jdG9iZXImbmJzcDsyMDEyICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3Jm Yy9yZmM2NzQ5LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3It dGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzY3NTAiPltSRkM2NzUwXTwvYT48L3RkPgo8 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Kb25lcywgTS4gYW5kIEQuIEhhcmR0LCAmbGRxdW87PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc1MCI+VGhlIE9BdXRoIDIuMCBB dXRob3JpemF0aW9uIEZyYW1ld29yazogQmVhcmVyIFRva2VuIFVzYWdlPC9hPiwmcmRxdW87IFJG QyZuYnNwOzY3NTAsIE9jdG9iZXImbmJzcDsyMDEyICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL3JmYy9yZmM2NzUwLnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlczQy5DUi14bWxkc2lnLWNv cmUyLTIwMTIwMTI0Ij5bVzNDLkNSLXhtbGRzaWctY29yZTItMjAxMjAxMjRdPC9hPjwvdGQ+Cjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkVhc3RsYWtlLCBELiwgUmVhZ2xlLCBKLiwgWWl1LCBLLiwg U29sbywgRC4sIERhdHRhLCBQLiwgSGlyc2NoLCBGLiwgQ2FudG9yLCBTLiwgYW5kIFQuIFJvZXNz bGVyLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvVFIvMjAxMi9DUi14bWxkc2ln LWNvcmUyLTIwMTIwMTI0Ij5YTUwgU2lnbmF0dXJlIFN5bnRheCBhbmQgUHJvY2Vzc2luZyBWZXJz aW9uIDIuMDwvYT4sJnJkcXVvOyBXb3JsZCBXaWRlIFdlYiBDb25zb3J0aXVtIENSJm5ic3A7Q1It eG1sZHNpZy1jb3JlMi0yMDEyMDEyNCwgSmFudWFyeSZuYnNwOzIwMTIgKDxhIGhyZWY9Imh0dHA6 Ly93d3cudzMub3JnL1RSLzIwMTIvQ1IteG1sZHNpZy1jb3JlMi0yMDEyMDEyNCI+SFRNTDwvYT4p LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBu YW1lPSJXM0MuQ1IteG1sZW5jLWNvcmUxLTIwMTIwMzEzIj5bVzNDLkNSLXhtbGVuYy1jb3JlMS0y MDEyMDMxM108L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RWFzdGxha2UsIEQuLCBS ZWFnbGUsIEouLCBSb2Vzc2xlciwgVC4sIGFuZCBGLiBIaXJzY2gsICZsZHF1bzs8YSBocmVmPSJo dHRwOi8vd3d3LnczLm9yZy9UUi8yMDEyL0NSLXhtbGVuYy1jb3JlMS0yMDEyMDMxMyI+WE1MIEVu Y3J5cHRpb24gU3ludGF4IGFuZCBQcm9jZXNzaW5nIFZlcnNpb24gMS4xPC9hPiwmcmRxdW87IFdv cmxkIFdpZGUgV2ViIENvbnNvcnRpdW0gQ1ImbmJzcDtDUi14bWxlbmMtY29yZTEtMjAxMjAzMTMs IE1hcmNoJm5ic3A7MjAxMiAoPGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvVFIvMjAxMi9DUi14 bWxlbmMtY29yZTEtMjAxMjAzMTMiPkhUTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iVzNDLlJFQy14bWwtMTk5OCI+W1cz Qy5SRUMteG1sLTE5OThdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkJyYXksIFQu LCBQYW9saSwgSi4sIGFuZCBDLiBTcGVyYmVyZy1NY1F1ZWVuLCAmbGRxdW87PGEgaHJlZj0iaHR0 cDovL3d3dy53My5vcmcvVFIvMTk5OC9SRUMteG1sLTE5OTgwMjEwLyI+RXh0ZW5zaWJsZSBNYXJr dXAgTGFuZ3VhZ2UgKFhNTCkgMS4wPC9hPiwmcmRxdW87IFczQyZuYnNwO1JFQy14bWwtMTk5OCwg RmVicnVhcnkmbmJzcDsxOTk4LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi IHZhbGlnbj0idG9wIj48YSBuYW1lPSJXZWJDcnlwdG8iPltXZWJDcnlwdG9dPC9hPjwvdGQ+Cjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPlNsZWV2aSwgUi4gYW5kIEQuIERhaGwsICZsZHF1bztXZWIg Q3J5cHRvZ3JhcGh5IEFQSSwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDEzLjwvdGQ+PC90cj4KPC90 YWJsZT4KCjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzMiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxoMz45LjIuJm5ic3A7SW5m b3JtYXRpdmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8 dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkNBUCI+W0NB UF08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Qm90dGVyZWxsLCBBLiBhbmQgRS4g Sm9uZXMsICZsZHF1bztDb21tb24gQWxlcnRpbmcgUHJvdG9jb2wgdjEuMSwmcmRxdW87IE9jdG9i ZXImbmJzcDsyMDA1LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGln bj0idG9wIj48YSBuYW1lPSJJLUQuaWV0Zi1vYXV0aC1qd3QtYmVhcmVyIj5bSS1ELmlldGYtb2F1 dGgtand0LWJlYXJlcl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Sm9uZXMsIE0u LCBDYW1wYmVsbCwgQi4sIGFuZCBDLiBNb3J0aW1vcmUsICZsZHF1bzs8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDUiPkpTT04g V2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEF1dGhvcml6YXRpb24gR3JhbnRzPC9hPiwmcmRxdW87IGRyYWZ0LWlldGYtb2F1dGgt and0LWJlYXJlci0wNSAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoJm5ic3A7MjAxMyAoPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC1q d3QtYmVhcmVyLTA1LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmVhcmVyLTA1LnBkZiI+UERGPC9h PikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxh IG5hbWU9IkktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlciI+W0ktRC5pZXRmLW9hdXRoLXNhbWwy LWJlYXJlcl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Q2FtcGJlbGwsIEIuLCBN b3J0aW1vcmUsIEMuLCBhbmQgTS4gSm9uZXMsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xNiI+U0FNTCAyLjAg UHJvZmlsZSBmb3IgT0F1dGggMi4wIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXph dGlvbiBHcmFudHM8L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTYg KHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCZuYnNwOzIwMTMgKDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTE2 LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTYucGRmIj5QREY8L2E+KS48L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSVRV Llg2OTAuMTk5NCI+W0lUVS5YNjkwLjE5OTRdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPkludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uLCAmbGRxdW87SW5mb3Jt YXRpb24gVGVjaG5vbG9neSAtIEFTTi4xIGVuY29kaW5nIHJ1bGVzOiBTcGVjaWZpY2F0aW9uIG9m IEJhc2ljIEVuY29kaW5nIFJ1bGVzIChCRVIpLCBDYW5vbmljYWwgRW5jb2RpbmcgUnVsZXMgKENF UikgYW5kIERpc3Rpbmd1aXNoZWQgRW5jb2RpbmcgUnVsZXMgKERFUiksJnJkcXVvOyBJVFUtVCZu YnNwO1JlY29tbWVuZGF0aW9uIFguNjkwLCAxOTk0LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJPQVNJUy5zYW1sLWNvcmUtMi4wLW9z Ij5bT0FTSVMuc2FtbC1jb3JlLTIuMC1vc108L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+PGEgaHJlZj0ibWFpbHRvOmNhbnRvci4yQG9zdS5lZHUiPkNhbnRvciwgUy48L2E+LCA8YSBo cmVmPSJtYWlsdG86Sm9obi5LZW1wQG5va2lhLmNvbSI+S2VtcCwgSi48L2E+LCA8YSBocmVmPSJt YWlsdG86cnBoaWxwb3R0QHJzYXNlY3VyaXR5LmNvbSI+UGhpbHBvdHQsIFIuPC9hPiwgYW5kIDxh IGhyZWY9Im1haWx0bzpldmUubWFsZXJAc3VuLmNvbSI+RS4gTWFsZXI8L2E+LCAmbGRxdW87PGEg aHJlZj0iaHR0cDovL2RvY3Mub2FzaXMtb3Blbi5vcmcvc2VjdXJpdHkvc2FtbC92Mi4wL3NhbWwt Y29yZS0yLjAtb3MucGRmIj5Bc3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNl Y3VyaXR5IEFzc2VydGlvbiBNYXJrdXAgTGFuZ3VhZ2UKICAgICAgICAgICAgKFNBTUwpIFYyLjA8 L2E+LCZyZHF1bzsgT0FTSVMgU3RhbmRhcmQmbmJzcDtzYW1sLWNvcmUtMi4wLW9zLCBNYXJjaCZu YnNwOzIwMDUuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0 b3AiPjxhIG5hbWU9Ik9wZW5JRC5NZXNzYWdlcyI+W09wZW5JRC5NZXNzYWdlc108L2E+PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+U2FraW11cmEsIE4uLCBCcmFkbGV5LCBKLiwgSm9uZXMs IE0uLCBkZSBNZWRlaXJvcywgQi4sIE1vcnRpbW9yZSwgQy4sIGFuZCBFLiBKYXksICZsZHF1bzs8 YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1tZXNzYWdlcy0x XzAuaHRtbCI+T3BlbklEIENvbm5lY3QgTWVzc2FnZXMgMS4wPC9hPiwmcmRxdW87IE1hcmNoJm5i c3A7MjAxMy48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRv cCI+PGEgbmFtZT0iUGVyc29uYSI+W1BlcnNvbmFdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPk1vemlsbGEsICZsZHF1bzs8YSBocmVmPSJodHRwczovL2RldmVsb3Blci5tb3ppbGxh Lm9yZy9lbi1VUy9kb2NzL1BlcnNvbmEiPk1vemlsbGEgUGVyc29uYTwvYT4sJnJkcXVvOyBBcHJp bCZuYnNwOzIwMTMuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzI2MTYiPltSRkMyNjE2XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZmllbGRpbmdAaWNzLnVjaS5lZHUiPkZpZWxkaW5n LCBSLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpqZ0B3My5vcmciPkdldHR5cywgSi48L2E+LCA8YSBo cmVmPSJtYWlsdG86bW9ndWxAd3JsLmRlYy5jb20iPk1vZ3VsLCBKLjwvYT4sIDxhIGhyZWY9Im1h aWx0bzpmcnlzdHlrQHczLm9yZyI+RnJ5c3R5aywgSC48L2E+LCA8YSBocmVmPSJtYWlsdG86bWFz aW50ZXJAcGFyYy54ZXJveC5jb20iPk1hc2ludGVyLCBMLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpw YXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzp0 aW1ibEB3My5vcmciPlQuIEJlcm5lcnMtTGVlPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzI2MTYiPkh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAt LSBIVFRQLzEuMTwvYT4sJnJkcXVvOyBSRkMmbmJzcDsyNjE2LCBKdW5lJm5ic3A7MTk5OSAoPGEg aHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjYxNi50eHQiPlRYVDwvYT4s IDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzI2MTYucHMiPlBTPC9h PiwgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjYxNi5wZGYiPlBE RjwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9y ZmMyNjE2Lmh0bWwiPkhUTUw8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL3htbC9yZmMyNjE2LnhtbCI+WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzI4MTgiPltSRkMyODE4 XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5SZXNjb3JsYSwgRS4sICZsZHF1bzs8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyODE4Ij5IVFRQIE92ZXIgVExT PC9hPiwmcmRxdW87IFJGQyZuYnNwOzI4MTgsIE1heSZuYnNwOzIwMDAgKDxhIGhyZWY9Imh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzI4MTgudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzIw NyI+W1JGQzMyMDddPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkhvZmZtYW4sIFAu LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIwNyI+U01U UCBTZXJ2aWNlIEV4dGVuc2lvbiBmb3IgU2VjdXJlIFNNVFAgb3ZlciBUcmFuc3BvcnQgTGF5ZXIg U2VjdXJpdHk8L2E+LCZyZHF1bzsgUkZDJm5ic3A7MzIwNywgRmVicnVhcnkmbmJzcDsyMDAyICg8 YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzMjA3LnR4dCI+VFhUPC9h PikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxh IG5hbWU9IlJGQzM5MjMiPltSRkMzOTIzXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij48YSBocmVmPSJtYWlsdG86c3RwZXRlckBqYWJiZXIub3JnIj5TYWludC1BbmRyZSwgUC48L2E+ LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzkyMyI+RW5k LXRvLUVuZCBTaWduaW5nIGFuZCBPYmplY3QgRW5jcnlwdGlvbiBmb3IgdGhlIEV4dGVuc2libGUg TWVzc2FnaW5nIGFuZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCk8L2E+LCZyZHF1bzsgUkZDJm5i c3A7MzkyMywgT2N0b2JlciZuYnNwOzIwMDQgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvcmZjL3JmYzM5MjMudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291 cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMzkyMy5odG1sIj5IVE1MPC9hPiwgPGEgaHJlZj0i aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMzkyMy54bWwiPlhNTDwv YT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48 YSBuYW1lPSJSRkM0MzAxIj5bUkZDNDMwMV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+S2VudCwgUy4gYW5kIEsuIFNlbywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzQzMDEiPlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlIEludGVybmV0 IFByb3RvY29sPC9hPiwmcmRxdW87IFJGQyZuYnNwOzQzMDEsIERlY2VtYmVyJm5ic3A7MjAwNSAo PGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNDMwMS50eHQiPlRYVDwv YT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48 YSBuYW1lPSJSRkM1MjQ2Ij5bUkZDNTI0Nl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+RGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2Ij5UaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChU TFMpIFByb3RvY29sIFZlcnNpb24gMS4yPC9hPiwmcmRxdW87IFJGQyZuYnNwOzUyNDYsIEF1Z3Vz dCZuYnNwOzIwMDggKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzUy NDYudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNTMyMiI+W1JGQzUzMjJdPC9hPjwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpwcmVzbmlja0BxdWFsY29tbS5jb20iPlJl c25pY2ssIFAuLCBFZC48L2E+LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTMyMiI+SW50ZXJuZXQgTWVzc2FnZSBGb3JtYXQ8L2E+LCZyZHF1bzsgUkZDJm5i c3A7NTMyMiwgT2N0b2JlciZuYnNwOzIwMDggKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvcmZjL3JmYzUzMjIudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291 cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjNTMyMi5odG1sIj5IVE1MPC9hPiwgPGEgaHJlZj0i aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjNTMyMi54bWwiPlhNTDwv YT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48 YSBuYW1lPSJSRkM1NzUxIj5bUkZDNTc1MV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+UmFtc2RlbGwsIEIuIGFuZCBTLiBUdXJuZXIsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzUxIj5TZWN1cmUvTXVsdGlwdXJwb3NlIEludGVybmV0IE1h aWwgRXh0ZW5zaW9ucyAoUy9NSU1FKSBWZXJzaW9uIDMuMiBNZXNzYWdlIFNwZWNpZmljYXRpb248 L2E+LCZyZHF1bzsgUkZDJm5ic3A7NTc1MSwgSmFudWFyeSZuYnNwOzIwMTAgKDxhIGhyZWY9Imh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzU3NTEudHh0Ij5UWFQ8L2E+KS48L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iV1Mt RmVkZXJhdGlvbiI+W1dTLUZlZGVyYXRpb25dPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPkthbGVyLCBDLiwgTWNJbnRvc2gsIE0uLCBHb29kbmVyLCBNLiwgYW5kIEEuIE5hZGFsaW4s ICZsZHF1bzs8YSBocmVmPSJodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy93c2ZlZC9mZWRlcmF0 aW9uL3YxLjIvb3Mvd3MtZmVkZXJhdGlvbi0xLjItc3BlYy1vcy5odG1sIj5PcGVuSUQgQ29ubmVj dCBNZXNzYWdlcyAxLjA8L2E+LCZyZHF1bzsgTWF5Jm5ic3A7MjAwOS48L3RkPjwvdHI+CjwvdGFi bGU+Cgo8YSBuYW1lPSJhY2stc2VjIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQSI+PC9h PjxoMz5BcHBlbmRpeCBBLiZuYnNwOwpBY2tub3dsZWRnZW1lbnRzPC9oMz4KCjxwPlRoYW5rcyB0 byBNYXR0IE1pbGxlciBmb3IgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBYTVBQIGVuZC10by1lbmQK ICAgICAgc2VjdXJpdHkgbW9kZWwsIGFuZCB0byBNaWtlIEpvbmVzIGZvciBjb25zaWRlcmF0aW9u cyByZWxhdGVkIHRvIHNlY3VyaXR5CiAgICAgIHRva2VucyBhbmQgWE1MIHNlY3VyaXR5LiAgVGhh bmtzIHRvIE1hcmsgV2F0c29uIGZvciByYWlzaW5nIHRoZSBuZWVkIGZvciAKICAgICAgcmVwcmVz ZW50aW5nIHN5bW1ldHJpYyBrZXlzIGFuZCBiaW5kaW5nIGF0dHJpYnV0ZXMgdG8gdGhlbS4KPC9w Pgo8YSBuYW1lPSJoaXN0LXNlYyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkIiPjwvYT48 aDM+QXBwZW5kaXggQi4mbmJzcDsKRG9jdW1lbnQgSGlzdG9yeTwvaDM+Cgo8cD4KCVtbIHRvIGJl IHJlbW92ZWQgYnkgdGhlIFJGQyBlZGl0b3IgYmVmb3JlIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBd XQogICAgICAKPC9wPgo8cD4KICAgICAgICAtMDEKICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4 dCI+CjxsaT4KICAgICAgICAgICAgUmVmZXJlbmNlZCB0aGUgSldTLCBKV0UsIEpXSywgYW5kIEpX QSBzcGVjaWZpY2F0aW9ucwoJICAgIG1ha2luZyB0aGUgInNpZ25lZCBvYmplY3QgZm9ybWF0Iiwg ImVuY3J5cHRlZCBvYmplY3QgZm9ybWF0IiwKCSAgICAia2V5IGZvcm1hdCIsIGFuZCBhbGdvcml0 aG1zIHJlc3VsdGluZyBmcm9tIHRoZXNlIHVzZSBjYXNlcyBjb25jcmV0ZS4KICAgICAgICAgIAo8 L2xpPgo8bGk+CgkgICAgQWRkZWQgIkFwcGxpY2F0aW9uIGFuZCBQcm90b2NvbCBSZXF1aXJlbWVu dHMiIHNlY3Rpb24uCgkgIAo8L2xpPgo8bGk+CgkgICAgQnJva2UgZm9ybWVyIGh1Z2UgIlNlY3Vy aXR5IFRva2VucyBhbmQgQXV0aG9yaXphdGlvbiIgVXNlIENhc2Ugc2VjdGlvbgoJICAgIGludG8g IlNlY3VyaXR5IFRva2VucyIsICJPQXV0aCIsIGFuZCAiRmVkZXJhdGlvbiIgVXNlIENhc2Ugc2Vj dGlvbnMuCgkgIAo8L2xpPgo8bGk+CgkgICAgQ2l0ZWQgTW96aWxsYSBQZXJzb25hIGFzIGEgc2lu Z2xlLXNpZ24tb24gKFNTTykgc3lzdGVtIHVzaW5nIEpXVHMKCSAgICBhbmQgSk9TRSBkYXRhIGZv cm1hdHMuCgkgIAo8L2xpPgo8bGk+CgkgICAgU3BlbGxpbmcgYW5kIGdyYW1tYXIgY29ycmVjdGlv bnMuCgkgIAo8L2xpPgo8L3VsPjxwPgogICAgICAKPC9wPgo8cD4KICAgICAgICAtMDAKICAgICAg ICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgQ3JlYXRlZCB0aGUgaW5p dGlhbCBJRVRGIGRyYWZ0IGJhc2VkIHVwb24KICAgICAgICAgICAgZHJhZnQtYmFybmVzLWpvc2Ut dXNlLWNhc2VzLTAxIHdpdGggc29tZSBhZGRpdGlvbnMuCiAgICAgICAgICAKPC9saT4KPC91bD48 cD4KICAgICAgCjwvcD4KPGEgbmFtZT0icmZjLmF1dGhvcnMiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+QXV0aG9yJ3Mg QWRkcmVzczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5SaWNoYXJkIEJhcm5lczwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PkJCTiBUZWNobm9sb2dpZXM8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4m bmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4xMzAwIE4gMTd0aCBTdDwvdGQ+PC90 cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiPkFybGluZ3RvbiwgVkEgIDIyMjA5PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJh dXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+VVM8L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDombmJzcDs8L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCI+cmxi QGlwdi5zeDwvYT48L3RkPjwvdHI+CjwvdGFibGU+CjwvYm9keT48L2h0bWw+Cg== --_007_4E1F6AAD24975D4BA5B1680429673943676F9ABFTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Sun Apr 28 01:23:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7845E21F9954 for ; Sun, 28 Apr 2013 01:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12ZHFnERGxdb for ; Sun, 28 Apr 2013 01:23:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 415A821F9940 for ; Sun, 28 Apr 2013 01:23:01 -0700 (PDT) Received: from BY2FFO11FD024.protection.gbl (10.1.15.203) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.675.0; Sun, 28 Apr 2013 08:22:59 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Sun, 28 Apr 2013 08:22:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Sun, 28 Apr 2013 08:22:42 +0000 From: Mike Jones To: Jim Schaad , Karen O'Donoghue Thread-Topic: Annotated interim meeting agenda Thread-Index: Ac5D6YxvtIpURbx1SW6O2hvZ126YZA== Date: Sun, 28 Apr 2013 08:22:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943676F9CE4@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(22804001)(199002)(189002)(4396001)(49866001)(81542001)(77982001)(512954001)(59766001)(51856001)(63696002)(69226001)(71186001)(47736001)(54316002)(56776001)(81342001)(20776003)(33656001)(44976003)(6806003)(53806001)(76482001)(54356001)(66066001)(55846006)(16406001)(65816001)(56816002)(31966008)(564824004)(15202345002)(16236675002)(16297215002)(46102001)(80022001)(47976001)(74366001)(79102001)(50986001)(74662001)(74502001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0830866D19 Cc: "jose@ietf.org" Subject: [jose] Annotated interim meeting agenda X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 08:23:06 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I annotated the attached copy of the interim meeting agenda published by Ji= m to mark which issues I believe were closed in the -09 drafts, and therefo= re don't need meeting time on Monday and Tuesday. See the lines in red. I= t contains no other changes from the version published at http://www.ietf.o= rg/proceedings/interim/2013/04/29/jose/agenda/agenda-interim-2013-jose-1. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I annotated the attached copy of the interim meeting= agenda published by Jim to mark which issues I believe were closed in the = -09 drafts, and therefore don’t need meeting time on Monday and Tuesd= ay.  See the lines in red.  It contains no other changes fr= om the version published at http://www.ietf.org/proceedings/interim/2013/04/29/jose/agenda/agenda-inter= im-2013-jose-1.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="agenda-interim-2013-jose-1.docx" Content-Description: agenda-interim-2013-jose-1.docx Content-Disposition: attachment; filename="agenda-interim-2013-jose-1.docx"; size=17410; creation-date="Sat, 27 Apr 2013 22:13:47 GMT"; modification-date="Sat, 27 Apr 2013 23:02:09 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQB8O5c5IgEAALkDAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTTU+EMBCG7yb+B9K7FFZdjdmyFzXZq67x3C1T aISWdMYP/r0VswrKogcuTWaavs/TSbtav9VV9AIejbOCpXHCIrDK5cYWgj1sb08uWYQkbS4rZ0Gw FpCts+Oj1R1UksIhLE2DUUixKFhJ1FxxjqqEWmLsGrBhRztfSwqlL3gj1ZMsgC+SZMl9P4Nlg8xo kwvmN/kpi7ZtE8h/ZzutjYJrp55rsDSC4AhE4WYYMqUvgATbd+Lgyfi4wuKAQm2Ud+g0xcrV/JP+ Qb0YXowjtRXgo6HyRmtQ1Mf/3JrySA94jIz5H6PoyL1BdPUUfjknnsILgW96V/JuTacczud00M7S Vu6qnsdXa0ribE6JV9jd/3qVveZehA8+XPYOAAD//wMAUEsDBBQABgAIAAAAIQDFq4NmJxMAAEwl AQARAAAAd29yZC9kb2N1bWVudC54bWzsXd1S40qSvt+IfYdan4id7l0Mtvn3HnyGY6CH7oF2YHqI mZuNQipsNZJKXSVh3Ff7DvOG8yT7ZUkyCNs09IFol7t8AbYsS6rKrMyszC8zf/3tNgrZjVA6kPFe rbnaqDERe9IP4sFe7dP5UX2nxnTKY5+HMhZ7tbHQtd86//5vv47avvSySMQpwyVi3R4l3l5tmKZJ e21Ne0MRcb0aBZ6SWl6lq56M1uTVVeCJtZFU/lqr0WyYd4mSntAa9+vy+IbrWnG5aPpqMhEx7nUl VcRTvSrVYC3i6jpL6rh6wtPgMgiDdIxrN7bKy8i9WqbidvFA9ckD0U/a+QMV/8pfqKlRzLhv/suD YgbMHdeUCPEMMtbDILkbxvdeDUMclo9089ggbqKwPG+UNDem7jcZ8lNocKD4CKS4u+DU5WZMhp// KArzeSD63lH14RWbjccGU1CELjF5hqc8QvWe5ZNEPIgnl/m+qbk/uVgRf4S/3ymZJZPHSYI/drXj +HpyLVqYz3iyxpZZefeHpp91gaml2x/yRNRY5LWPB7FU/DLEE42aG4w4staBsLiU/pj+J2zUhrDx z/ZqjeJVKw/1sPQajeZBq3kIqVOcdyCueBam9E2rsb61vVt+06NDR5vbO60dc4ekp8wN+uk4FPj1 DQ/3ar0QLHAubtPaGn2p8nPUkYxTjXO49gLQoSszFQjFTsWIrj7cj/X0UQ9zdP9Ec0H9tbxTq5Hf Qn/t0pXN3fNja8V98b94RoUTzCRURvzDH3DUNrK8rRPugX6JElqoG1HrHKcs0IxrDXnvs3TIU5YI mdA0DyXjSjCepiImpYFvBYuESOk9fTOQ9G7IbwRTgtOvBYPAuEr1CstiH5qHtIs5HOAGQrMgvpHh DW5Exy8Fw3MkuBLOwb18H0+l2a+YzLRDf0F0mljHW5byliNlbbaYcFxtFjZJbDcVk6mAwFtY5dE5 kdgnjOlZnWzOlVPJveV/p6YWXk11duu77fVGm7EzMQh0KtQK64s0S9jhlyxIaMdbHrgQl4e3TNP2 VcbGXPHINlJSRtqtgtlqbaEFGBG+XqEcTEuQ8+pQkdhNxwns4oHiUT/lqtxTLK48brbajQZrP2VA h7FfbJEWdjjkGJrem2Bt0vJ7MMYFVpIx+6VZeVpn3dB0GL3gpmIyFYssJ+esRMbYJy1Yl+NP6Rp1 nG6fGpxPXlCYXZCJ44HG8AjBvxPBawMPz2+O0MtJ6CGPBwWpYyF8uOGCOHfiFcEPR3nnwFk+lzdJ uvcXhxM9ZnZ3EeKiCGHmUT4n8GYLPGfDWW7DEesfBNrLEGehaA0CLgjAaSavzMfu0dk79gWBGhPr Zr7gIUV4RkE6hEEwyCEB2DSnwjNnuHUye53YaeATc/RBb8T+eFwh7SKPp+OzE/BwQCHLM+EFSUC4 FQ9YjVRlhk0rQ3EibCLC3FRMpmKRGfzxLVtvIo1JiA8RhgfY4SoQoa9ZHTH8wBuWHynmPhq6GI6z 6ZfTpif9dUw4E3hhm212wq+FsWqO/2Ys/HM+QDwHcBOeCiYV9rpemN3b9BKMyamKZTNoCobYRsxv PxxIBVM2YoEPGwHbPSCU1oghIoFQIKGTSrApwZ/I6EUUsKvGSVqNQTxdcf7eXW80D2tl3GXBAW+p Cq6Fwb55MsQKKaBuR0eE5ishcOXRnFFG7WUExUGQVCSBpebB42MoePN1oIkvzEqEOilFe6sNOz+S QGGSxXO76eX2DbtSMiK/zrxRE6b0wXrMMZqvOREvspAw+jlG4JszGHxjBtg880KpM4Jrmt18vbH7 hHl4Fdq/8pBzgOkTBlcKXXuI3HlbGdbT1YzDVUNC/xDg9/ylSdZo/nJEnW1UOv4mzlh80JyBGi0T dOonQE79NYu9oRM8swXPIpvznSa4c4kW2+ZPsNhymCLAfy234mavOKfqrVD1c3aZMGMdXuJ70kEd 21vO9rSBq8j0KdPhNZ1HiGC/qEP2nhdtq52DPYtIoUF7UiWIVKqxiZaMhiJmUaZTCqGMmfS8TM2b CedZu8t7f01+cJ6174pDENs7z9qcqPeUQCt8ia/iGn6ODv2mZ62MB2y2WX8osxBFBVIWCg6RhXI2 7HqetFq4wgwdyNcAFRYAPoUfH1URolISO/z1snLt7oRpRwjZ+P5DK8PizMQp7ODMsdiblFh7IFim hqcTEYZ2ZJHqJHjSaCygVqeWx4Er43EbMJqOhQ8xzPc7TG3AHEWXgKKF6bZRIDkAtlI8SZB/di3G OgdyBHEqBkBrjRnqDXpVY87xwIQH3FRMpsL+ncx6mx3GVGCP7R/uH7AP2BeYhYGcDBqlK7wzXXjH fqJDCPazJJEKm1eJfFzALu8LQ1Tki9nH/cMe42EoR672zJwdoROEyyMId9pIUlTIMWTIyhUG3QjD gPGBEsJUJaZsdQ0wP3zSZCHwmIdjHbi14dbGtzJbnJiwXExUDCGrK3gZIDOqloehUPXPUotvon4s cix9HolvUcqMxgbHUh0ePsp4F/5yUai6qZ6xlqoUmvJzUrE8C+g3x7n0nzxK/sf8YWdIkuXKZz0l E6l5WOFcpzGWSWM4ak6o6abCTYVdDpXOOUrTuCrU6H0xG2W7yM4wU3q5SVgNU2+ZalHoYBAD+OC0 rY3UbIOW3zSHyUK0IxD+E5VTRp7Cultzs9ecs4kmNtEiK5M5WzqTp9B3dR0rLaqeUqHDsb3VbF+R 5nauW0bOl6KspCtkZrrV/URN6AjlRa9J9UlX0xEdDZ+DlicJ7hoRmR6Q5VTYKghdxtm3M87sqekz x1R9TuGmV0nF+aG5ZPaQ70HiGDW7ldfUmdq4NVBiKvCR/UgF/mJUEdyr/e87+Tv3rvNieeW5CJJN zoRWd9a21dZ2bqqU2WcoLLmP9J0/PbDBp4KlFsXueeY/aTQWxH47fzLJzMtEnUBXcW7fjNtTHc/F 7EgN6qDvM/Uh2FhtoqijaUnts7/kRax7RWHWB7y4wMNR7BRKoEoeJ+yXSNgDmAphb7qUn+x3KVuF hcEVGqJHgjoOeELFjvoWBifnGOm5pq+m5rr1PFnPbiomU7HIvoaOq9+4wI3V54geV78R9b2txLmY +o1U9ZCgLnn38F82Kjask5sTuemmYjIVi6xC5ggp2EfvL/ZZDqJ+f/HBRd5d5P0naxNitgilLxBF 9T6dHZfdZcbUOpEzOP486ixqdovor8uxZj4gdzH9tk54rFtF6dR5vKXMvWp0RRGQpJ+OqbtN2+jX XsiD+FzcpjnZTPwMgujFSum/SJSBlATFNu2UkMQhFVJPDeMekV6cAK9YQrKJGlYk/k0y7lKNcI66 g68yX8yUcczQVYzarmS6aBVFFXL3D/sPaf3cQIBtzIAiFVSv4AH9Z496OmDgKoe6yqG1hY5vPwgA P33D8kB5P66njza3d1o7ZiZ+iJ5+aTVRquynT9fStzByU0E6woHU2ksAUrtY77KulMoPYk6N4Cva 3zG6Y3S78krn2PvYuJ1ia8z6qUhcWHfpwrqsi4pqqDaJTdxxjL+RE2WWxlzmr1/jnuvKWItYZ5p5 RHGnrGbnPk75pazpBMDef+wfEgDnSigBFI6jc+7dnU1nZ585+2zaPnNcMeGKRRaEnY+AyyoWpCLS BJ5FtxBf8DBloyAdMpmlOkDFTPRFjwRgiQhAETbRabw/Kgmtcua9btDNtgBFEZxdZ3V2VlkIU8vc spHNtnqFluGNINFAkSkCJfNUwEuTF9d/GJ2agOl/SCDmpb3OVCL9X//3z5+Ayqw75IGqbmXu8fMP oeaLiJ35Xb+ekzFZgiPuzcNCB5lmL2VmKsQuJ5FdWK3ReEGolGWqq1Mo5U0o5U+xh6Z9MGljqIPM o3BC7pSj7Bp0wuODvOZ73cm8TKFXnCbrvt7YnaflnMwrsGKLBWIj28Q1IbUwiNDpowGVnwEzabyM J8W+WokvKEaa5uGDw/MjdtQ6gjTL7TKTdFxUla6sU+dloelwIAB7QACd/3qZl1sGf9QHtfQIqXsb 2IXr0Tx7h3aO0gUVxr43hHt2WLkdXbhRdajLogqieWNYuAeeTQY4v8OQDTn8XpxdiMvDWzSN5HEs wlXGiEa+SHmAWD9Xol0Zq9PHNB1OH9ujj2evgHOZBB7SMSgOfvEOeBazrKuyyfH6hNfviWlLRNwB PPjoDnoj1Jg1GXogrORtck9kbD7sJyoIWWt3hbUazXVy/xe9ElZY/tV6o/jKyb/Zhph9PHGO0G6b 7SLVnPFohZ3ILIaai9kBH4fBYJgyOoG9ORAx2GaFvTs5rze2cPZbJxcs9EPMFvylO+I0iy6FarOt jRbbbG2xra0tR2ULqdwpCdrjWo+AsK+Ia/tkVJs1W+sbjhXnsKKzySY2mZuKyVTYt8zr3/dycmGO XMCeXEl5dagIoJOOE1QWtqeX0rlknyXsUCrsKeMwiMUEjfjmVI7yjUskLwPEVHxxE3hC/0c1NDZn +NP545bs3hyfz+XzCQLNElJ+n6CrOw6wkAM6zVX2DgWKJRumaaLba2uBSK9WR+JS3K56MjIf1z6v JsPkt8ODveb2ztZ2Y3Nz2xTE+nSMI+vbm83t7cZWyxyy3JbvXeydnp6H0T8ODlsn0fG6GdPZ+d5J cNJy/G0hf892KbRW2fEVK/ANwl9hgrzJbCwzxajJgQE3iAgBFcbzYsirjvpLQ/11Q33OksL/wAJt eCFQd6xAhl2ZX1Ke5zb6ldp/2M1aXudhY5V1w8C7ZrX3MOZrbo3Pq0brHBcWOy6wV70JxAjoYyYh 1pTJl2NfZSyAs1Us5PEgAwJZr7AEKGXKqDFrgiQgNrbXbaf57NN8IdfpmYh9JIv7PRD3dyX4tem2 mHZmG/qWG+7P3afMNPQ/Oku/rJo6O4Ds9IDFesC5dUY1sLen92pdbPQCaMJTMXrBDKWFLyZy32uN DmiBvF9QBG7ssVP19qn6dLaLw632n2e1d6jMV53CURIg4djgZNibT/21LnILff4WjgvLzbv61maj vrG9W19vNXaclJojpZx5ZoV51tn3EA9GqTbpV+vWzIkJmz68RfeCxc2zaAOX90DKzAzw2xvhdqBD tzs0PhT9tasfnwoHb7or+t8wL9p6TbfoLQ8ueOn4r1Vqj9rLyAFHcAYjIhbolFOByYosd5aFFZaF 2wqaTd9wP9ZB1cuDBfwTO36eBPKJPLfm52ysFlmddwBm+ZgjUUNxlQK/chMMTJ1vdsmRE0XRvIos X+TBzBZgCND3sySRKnUx+rkdY52KtlhF/11mqOgdkz8+5V4K6BHjqYu8z8Oj2CfCvEiqAY//zCMd Eq7WqVoLVe1s7dSsbzbhnN5t1TcaO5uOsHMI6/STxfoJkWMAoZHuBKhsCYtFzoABTKPjCJBGKG8J dy9lcLE31G9G3PIIeDJ2EnhKagnD9GOWhlJev81N0uv8Yg5h9lgfi0XWc3NwZM8FYh13+3snxybP 4q/IJskTLg72liKbpH9eDKj/l/3W3j69gqPxh15Dbm/dvN+NjjbXml824wsEalve33tH796/+3Cx KXpf/vaP4+tbl3vyBDer0yo2axVAjJOQjy85MPgo+fupewTYQhyglovmIdovRlEWB6jubwomwz+N /mVvmQq8IZSQH3B2hfzaSe4Gap8lUEGoEoRCQua6uMwqK+HPRndRnjHdaeoaRS5vodvuoNBDgUcb DYUBTkPd5SXYLPenELSb5h3zY2pSAz2C3gkyLvS5jJKM0qEux2yAvAg0WHk8O1CPNXq1gB6DWCJ8 QLmCLpVi3tbVCSyLBVY/GMQsS0xFZEgfJdCFBOImJJGSF2WsSAZHa4tpTWkSSIcejUb3sqEHci3y RESUzwnv6O0yBZYOCzKL9Z1fy/m1bEY9dbrdXkVY2w22/O+njMVaqGUTcG+gvQnsfQtYKYCXeP3i RNBzRNDR5vZOa8fB7g5azcOd2qv0RtPPwAVSc5zjkx5STPdPz9npx/Pj7mG1UPsiO3tnR75QeB7x gHzjo4WiMmfwJ3hh5sMrg/2R4Cn1c0qHPGXwMcgRjpq0Mx77KLEyZr70sgi1V3AcR/LsdPh4UK+f o5S9uKUS9wNyTSiTwo53PhL3yCMBD4YGhh6OIfJOoEWsEh5KiQp/lf0+NrXZ8tPwfMV5K+TdwP1T iTvAqRQi3Q3hdrRNT+kSOoNXKb8Ifgm/EQrE0A98yWKZ3j+T7p2f+EAG21bnC+NcYX6gvQzJCHko B700hUJzMtNqlwZaBnuGEo2A4FoDJTBZZvpTrlLa+N7NB005TiimbFIgryDAKuvl9QUwnyVTgAce TDz6oY2Jnjq7/CyAhMDd6BGlKQteeOnEDRENtw6DtMA6zXE4aVyiN6EL9at4gljs40fm1O317aN9 IzqSQZ/W+miv1my1NhokVYd4v7mD9wYSngxOEAHDIpcJjm/kpygqUY2PjR3zi0uZgvnuvia41t23 Q8GRrr9X28aGChe6kpilu4+DLDUfi9uhESXtOnTCPdRNpJ+Yp8B6eqcCH99QScJekHp4yvUt8y2c EflsmMbYl9IfmzflEuz8vwAAAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29y ZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDS SX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwd EiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteX lqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrA Z2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bps QXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ /sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRg Dq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjW DPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+/ /ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb 5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJ iaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQO SUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6 SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrd vsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68G t2noiDQLED0zERW+vE64E7+DKRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV 5cz2iUK9CHeyPHe5COjbX5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKu e0wZG6gpIzekabwl7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVK uYTDohmupK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6 M7e6Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7S es/7qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHb azWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHVFpaR DQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKIGETBERqx idjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpSIYN5K4kHulXK bpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC 2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmWETIRVRJXplbsETkkbKhr4Kre 2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bn e29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw48OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11 yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz 2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPkt R7N04y8AAAD//wMAUEsDBBQABgAIAAAAIQCqUOMOlQMAABkJAAARAAAAd29yZC9zZXR0aW5ncy54 bWy0Vttu2zgQfV9g/8HQcx1JtmOnQpyiderdFnFbVOkHUNLYJsIbSMqK+/UdkmLUNN4g2KJPHs7l zH3kyzf3nI0OoA2VYpnkZ1kyAlHLhordMvl2ux5fJCNjiWgIkwKWyRFM8ubq778uu8KAtahmRggh TMHrZbK3VhVpauo9cGLOpAKBwq3UnFh86l3Kib5r1biWXBFLK8qoPaaTLJsnPYxcJq0WRQ8x5rTW 0sitdSaF3G5pDf1PtNAv8Rssr2XdchDWe0w1MIxBCrOnykQ0/n/RMMV9BDk8l8SBs6jX5dlzmn26 ndTNg8VLwnMGSssajMEGcRbS5YSKB5h89gToodRnWOo0+E4dFJrnmaeGyA17Yn+i26GLN7TSRIc2 4wC4KHhdfNgJqUnFcKi6fJZc4UR9l5KPukKBrrFJOI5ZlqROgMnIbWmJBRQbBYz5+awZEATrip0m HCdrmQSOt2lgS1pmb0lVWqlQ6UAw5sWkh6z3RJPagi4VqRFtJYXVkkW9Rn6SdoVTqrGIIYgwsy6c QJVh/tFCEI5ZBG4/0xvZgIus1fRJof6z0M7AR4n18DmcdiRxXzVtAFNjUNojgzUGX9Lv8FY0H1tj KW6Jn+zfiOC5AEA4z59xu2+PCtZAbItl+kPOfCfWjKoN1VrqD6LB2fhdZ2lsomsnHr/GROKrlDa2 IcuyyXT1eh1q4dReIsmvJ/n7i1M2k2w6X7w+JZnO0dH7U5J3q2mWn5SszxcXk5N+1ovpYv3WoWGe fXa8cAfqi766DJQbmREP47YivNKUjDbuhKEVLyp9946KKK8ATzj8LCnbKgrH4yAwnDC2xp2KAr9o vGioUdew9bBsQ/RuwO019Eku7u/HByx3D0D/o2WrgrdOExVGIbrLZ7Mejwp7Q3nkm7Yqo5XAM/ST qBXN54N2gOlQnq6w+PXyK3VDxC52HMT4W+lUcXKYLt0XDjZEKTwdqFLt8mXC6G5vc7cGFl8Nfun8 o9pNetnEy/DlZP5BapcZaveEUwgkavXEwJtG3nTg4R0PerOBdx555wNvHnn4pe2KPe6txiN6h8cp ko6/lYzJDpp/I3OZPGGFIpg9UYB9dTcWl0cWntEfXTM6FHCPFxwaavEPhKINJ/fuoE/mzrzXZuQo W/tI18mcsnrEHTXEEjT3rXpk7Ef8l1i6ooGa4jiWR14NJ/0sBM6osSUovP5WakzZH9xXHnn4T3P1 AwAA//8DAFBLAwQUAAYACAAAACEAF6AWTgIBAACsAQAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1s jNDBSgMxEAbgu+A7LLm32ZUisnS3IFLxIoL6AGl2dhvMZMJMaqxPb9qqIF56yySZj5l/ufpAX70D i6PQqWZeqwqCpcGFqVOvL+vZjaokmTAYTwE6tQdRq/7yYpnbDJtnSKn8lKooQVq0ndqmFFutxW4B jcwpQiiPIzGaVEqeNBp+28WZJYwmuY3zLu31VV1fq2+Gz1FoHJ2FO7I7hJCO/ZrBF5GCbF2UHy2f o2XiITJZECn7oD95aFz4ZZrFPwidZRIa07wso08T6QNV2pv6eEKvKrTtwxSIzcaXBHOzUH2Jj2Jy 6D5hTXzLlAVYH66N95SfHu9Lof9k3H8BAAD//wMAUEsDBBQABgAIAAAAIQD3Bl2FXggAADRAAAAa AAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWy8m9ty2zYQhu8703fg8N7RwY6VeKp0UufkmTRJ I3t6DVGQhTFJsCRlxX36LhYkRJGiuGsyvXJEEfvtYhc/YAf72+8/otB7lGmmdDz3Jy/GvifjQK9U fD/3724/nL3yvSwX8UqEOpZz/0lm/u9vfv3lt91Vlj+FMvPAQJxd7ZJg7m/yPLkajbJgIyORvYhU kOpMr/MXgY5Ger1WgRztdLoaTceTMf4rSXUgswxo1yJ+FJlfmIua1nQiY2CtdRqJPHuh0/tRJNKH bXIG1hORq6UKVf4EtseXpRk997dpfFU4dOYcMkOurEPFj3JE2ojiCNeOfKeDbSTjHImjVIbgg46z jUr2YTzXGoS4KV16PBXEYxSW7+2SyUWD50Km5OBdKnaQir3Bhrkjk7Gyg6LQzoPJ7z6rdYuT8alg iowYE84HiguHzNKTSKjYmXne1FQnF9ZDn/r+mOpt4txJVD9rN/GDs2WWJcOz8SWuvGpoGctAY+ku NiKRvhcFVzf3sU7FMgSPdpMLz1Sk/wakYqWDd3IttmGemY/pt7T4WHzCHx90nGfe7kpkgVK3ICFg JVJg8NPbOFM+fCNFlr/NlDj65ca8dfSbIMsr1v5QK+WPDDH7F2w+inDuT6flk2vjwcGzUMT35TMZ n90tqp7MffdoCXbnvkjPFm+NsRGGWf6shJscBA+f0JVEBLDygCPWuQQRAhUznFCZ7E5noGj2w/et mVyxzXUBQQMAq5qFj7UZB20CpVpYxYZv5fqzDh7kapHDF3MfWfDw7uZbqnQKMjr3X782THi4kJH6 pFYraTaI4tldvFEr+fdGxneZXO2f//UB5bmwGOhtnIP7lzOsgjBbvf8RyMTIJJiOhcnwFzMANAzS UeGgQ1u198Y+qFHx4T8lcmJzeJSykcJsaR76fxKEUW97g6YmomoAaJfl63l/Exf9TbzsbwKLt99c zPp7AQeZvhmxtVGpSnpScx3Y4qvOw/nrEyVrRjSqqHNEo2g6RzRqpHNEoyQ6RzQqoHNEI+GdIxr5 7RzRSOfJEYFA4apX0TnOBmlh36o8hH2yQ+kmPaWu2Gq8byIV96lINp7ZWOtunxLLxXaZ01xFOX2+ WC7yVJvjZseMwO5slu6zNfl9lGxEpuBU3gXqOfW35ujjfUwVHF87UC9t8TViwoPJ0S3sWygCudHh SqberfxhM8oY/0V7C3vK6HSuZ1o/q/tN7sGp0Gy5nbDLlklvnwlr/7PKcA5O7uaXLaF0GSfl8LKl LtuN/ylXahuVU0M4jVxaPWekuYZAF09P0YVJUXN1dUZhEkAJwW4X/BDQPsF/u7nw7ZscU/y3W9Ez 7RP8txvXM+1jfZzOL1tp3sGfVTzS8pqx1+61DnW63oblGuiUhxl7BTsELQT2Inb2SSIxY6/gA/n0 3gYB/OZGqVN2LvY6yqCw02EpuNjosbCTUpO9CSMidoJqrCmD1U9rGSC26H6Xj8r8EZi7GaBKu7Nm 53I+b5kB2IJIZ+i/tjrvPkNPWzSPSrmJ4c8lmfRotPOWlUelFfVk9ztGjvttfAxQvx2QAeq3FTJA LfXRfuZxeyId0n9zZLDYsux2MSw7sjLP2MrsQLwtYKB9k3D+alm97bXQ3DcJFHaCmvsmgcLOTm0v c/smgTXYvklgtewa7TmqaionKPa+WQW5kwAhomHEmwAaRrwJoGHEmwDqL97dkOHEm8Bia4PT1Kp4 E0D4CudXfQeqijcBxNYGq3bF34zKfQ+tnP7ldgDxJlDYCWqKN4HCzk6beBNY+AqnEmosJ3UE1jDi TQANI94E0DDiTQANI94E0DDiTQD1F+9uyHDiTWCxtcFpalW8CSC2PDhQVbwJIHyFow1HxRtX/U8X bwKFnaCmeBMo7OzUBNUdUgksdoJqLCfeBBa+wimGgoXFzQlqGPEmRDSMeBNAw4g3ATSMeBNA/cW7 GzKceBNYbG1wmloVbwKILQ8OVBVvAoitDUfFGxfjTxdvAoWdoKZ4Eyjs7NQE1ekcgcVOUI3lxJvA wnrpLd4EEL7yXBAnomHEmxDRMOJNAA0j3gRQf/Huhgwn3gQWWxucplbFmwBiy4MDVcWbAGJrw1Hx xjXy08WbQGEnqCneBAo7OzVBdeJNYLETVGM5qSOwhhFvAggLs7d4E0D4yjNAuIo4aRpGvAkRDSPe BFB/8e6GDCfeBBZbG5ymVsWbAGLLgwNVxZsAYmuDuWcL90XJ11MnLUVAvWdQ3mogA6ctSaICiwC/ y7VMoatQdt8O6QksI2QQW8qDGuIfWj94tIvd5y0FQkapZag0Xul+wls6lUaE89mJToLbr9feJ9sA 0xiHJXV48wa6h6rtQtieZBqHwM/8KYGWnaS8WW6sQYOQ6esqWoCwJ/QGGoKKth4z2PT5wIvYVFU8 xv+3LajwbyDiwCYq2AArgI6oE6jiwru7g4TX3evgllvx6Mi+JaN0s7gdvz9D2fcO7mie9Ds3N8FP +Iw3xU/OkYev2Kw2HYTmLHSpy0NI2TK0LWbwj5t4BRHuiu4sm8zVD2FNwffXMgz/FNiQluuk/dVQ rnP77WSMO2DN1FLnuY7ax6d4QRw9OWYAyqHqjP1ogmivk3gbLWVaXDdvLUmzc2An2mFJ2ruuLaVA nel23w6Wi1sgcJ1fxXiPv16q+I294o8+LQW02H01HXONJQTtgQ/lc2fwGtZMV90cHsIQAy3gpjqQ MR5/eDl7NX1lzbT1KOL/vRYdihfuw/EOxaIbEn4ctHnO/Wtomdah6fzeXWELZ+WRLfF9l2a5LP+t dGniM5h86Ck9VSAHQhJsM6hP7Ias69bhLLanxtvPci0/R+UIIzmara5MtacFI/7fJrSs7+zNfwAA AP//AwBQSwMEFAAGAAgAAAAhAM+6wVxOAQAAgQIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySX0vDMBTF3wW/Q8l7m/6RKaXNQGUP4kBw ovgWkrsurElDEtft25u2W23RBx+Tc+4v59y2WB5lHRzAWNGoEiVRjAJQrOFCVSV626zCOxRYRxWn daOgRCewaEmurwqmc9YYeDGNBuME2MCTlM2ZLtHOOZ1jbNkOJLWRdygvbhsjqfNHU2FN2Z5WgNM4 XmAJjnLqKO6AoR6J6IzkbETqL1P3AM4w1CBBOYuTKME/XgdG2j8HemXilMKdtO90jjtlczaIo/to xWhs2zZqsz6Gz5/gj/Xza181FKrbFQNECs5yZoC6xpC12EPw5NdnCzy57lZYU+vWfttbAfz+NHP+ VrsBAwfRfSuyKPD06N/r6w2PAg984Hyod1Hes4fHzQqRNE6yML4J09tNmuZJlsfxZxdsNt8VGC7k Od4/iR6XzokXAOkTz38a8g0AAP//AwBQSwMEFAAGAAgAAAAhAFmI53XaBwAAQz0AAA8AAAB3b3Jk L3N0eWxlcy54bWy8m99T2zgQx99v5v4Hj99pSKCkZZp2KC1XZvqDNjD3rNgK0WBbOdsp0L++q5Uj HDu2d7F7TxDb2o9Wu/quA9o37x7iyPsp00zpZOaPXxz6nkwCHarkdubfXF8cvPK9LBdJKCKdyJn/ KDP/3du//3pzf5rlj5HMPDCQZKdxMPNXeb4+HY2yYCVjkb3Qa5nAzaVOY5HDx/R2FIv0brM+CHS8 FrlaqEjlj6PJ4eGJX5hJKVb0cqkC+UEHm1gmOY4fpTICizrJVmqdba3dU6zd6zRcpzqQWQZOx5G1 FwuVODPj45qhWAWpzvQyfwHOjOyMRsYUDB8f4m9x5HtxcHp5m+hULCJYvPvxsf8WVi7UwQe5FJso z8zH9CotPhaf8MeFTvLMuz8VWaDUNSwpGIgV2Pp0lmTKhztSZPlZpsTemyvz1N47QZaXrL1XofJH hpj9Aps/RTTzJ5PtlXMzg51rkUhut9dkcnAzL89k5rtLC7A780V6MD8zxkbo5vZnyd31jvPwCaey FgEEAzhimUtICsgRw4mUycHJFPLFfvixMesqNrkuIGgAYGWz8LGy4pArkDlzm8BwVy4/6+BOhvMc bsx8ZMHFm8urVOkUknTmv35tmHBxLmP1SYWhNPuluHaTrFQo/13J5CaT4dP17xeY/IXFQG+SHKZ/ MsUsiLLw40Mg1yZtwXQiTIS/mgGQOBCOEgcntFFPs7EXKlS8+N8WObYx3EtZSWF2uIfzbwWh15ve oInxqOwA2mXN9ai/ieP+Jl72N4HJ228tpv1nAbreNyI2N0pZSQ9qrgObfOV1OHrdkrJmRC2LOkfU kqZzRC1HOkfUUqJzRC0DOkfUAt45ohbfzhG1cLaOCAQKVzWLjnA1SBv7WuWRNONbBWjcU+qKUuNd iVTcpmK98kxhrU67TSznm0VOmyrK6fPFcp6nOrntXBGozmbrPluTP8brlcgUvCV1LP2k59Jfm7ce 759UhZ2olzb5aj7hi8neEnYViUCudBTK1LuWDzaijPFftTe3bxmdk+sZ1s/qdpV78xWW3E7YScOi N6+Etf9ZZbgGrZvppMGVLuOkGJ405GWz8S8yVJt4uzSEt5ETq+eMMFcQOMX2JTo2Iarvrk4vTAAo LthywXcB7RPmb4sL376JMWX+thQ90z5h/rZwPdM+5kd7fNlK8wG+tHqk7TVl791zHel0uYm2e6BT HqbsHewQNBfYm9jZJ4nElL2Dd+TTOwsC+OZGyVN2LJ50lEFhh8NScLPRfWEHpSJ7Y4ZH7ABVWBMG q5/WMkBs0f0hfyrzNzFuMUCVdu+andv5qGEFoASR3qG/b3Te/Q49adA8KuUygT+XZNKj0Y4adh6V VuSTrXeMGPcrfAxQvwrIAPUrhQxQQ340v/O4mkiH9C+ODBZbll0Vw7QjK/OUrcwOxCsBA9VNwvtX w+5tzoV63SRQ2AGq100ChR2dSi1zdZPAGqxuElgNVaM5RmVN5TjFrptlkHsTIHg0jHgTQMOINwE0 jHgTQP3FuxsynHgTWGxtcJpaFm8CCB/hfNV3oLJ4E0BsbbBqV/zNaFv30Er7l9sBxJtAYQeoLt4E Cjs6TeJNYOEjnEyosJzUEVjDiDcBNIx4E0DDiDcBNIx4E0DDiDcB1F+8uyHDiTeBxdYGp6ll8SaA 2PLgQGXxJoDwEY427BVv3PV/XLwJFHaA6uJNoLCjUxFU95JKYLEDVGE58Saw8BFOMhQsTG6OU8OI N8GjYcSbABpGvAmgYcSbAOov3t2Q4cSbwGJrg9PUsngTQGx5cKCyeBNAbG3YK964Gf+4eBMo7ADV xZtAYUenIqhO5wgsdoAqLCfeBBbmS2/xJoDwkeeCOB4NI94Ej4YRbwJoGPEmgPqLdzdkOPEmsNja 4DS1LN4EEFseHKgs3gQQWxv2ijfukT8u3gQKO0B18SZQ2NGpCKoTbwKLHaAKy0kdgTWMeBNAmJi9 xZsAwkeeAcJdxAnTMOJN8GgY8SaA+ot3N2Q48Saw2NrgNLUs3gQQWx4cqCzeBBBbG8w5WzgvSj6e Om5IAuo5g+2pBjJw0hAkKrBw8IdcyhSarGT36ZCewK2HDGJDelBdfK/1nUc72H3UkCBklFpESuOR 7kc8pVNqRDiatnQSXH879z7ZBpjaOEyp3ZM30D1UbhfC9iTTOATzzB/X0LKz3p4sN9agQcj0dRUt QNgidwkNQUVbjxls+nzgQWyqKi7j/20LKvwORBxYRwUrYAXQEdWCKg68uzNIeNy9Cm44FY8TeWrJ 2E6zOB3/9A5ln9s5o9k679ycBG+ZM54Ub10jDx+xUa1PEJqzcEpdM4SQLSLbYga/XCYheAhNgvhf MxvM8EFYU3D/XEbRF4ENableNz8ayWVu744PsQJWTC10nuu4eXyKB8RxJvsMQDqUJ2M/Giea8yTZ xAuZQodXy5p/1aZyYCfabkras64NqUBd6ea57WwXt0HgOL9K8Bx/NVXxjj3ij3NaCGix+2Y65mpb CNoD77bXncFz2DNdebP7EoYY6Ig12YGMw8OLl9NXk1fWTFOPImZR0aF47D7s71AsuiHhx06b58w/ hxZWHYnMBA5bOEuXbIo/dWlut+WvUpcmXoPFh57StgTZEZJgk0F+YjdkVbd2V7E5NN7TKlfis1eO 0JO90eqKVHNY0OP/bUG3+Z29/Q0AAP//AwBQSwMEFAAGAAgAAAAhAD90CEYEAgAAtwYAABIAAAB3 b3JkL2ZvbnRUYWJsZS54bWy8VMtu2zAQvBfIPwi8x6Jk5WEhcpC6NdBLD0X6ATRN2UT4ELi0Ff99 V6SsHlwBcgpEAghpljvYHczu0/O7VslROJDWVCSbUZIIw+1Wml1Ffr+ubx9JAp6ZLVPWiIqcBJDn 5c2Xp7asrfGQYL6BUvOK7L1vyjQFvheawcw2wmCwtk4zj79ul2rm3g7NLbe6YV5upJL+lOaU3pOe xk1hsXUtufhm+UEL40N+6oRCRmtgLxs4s7VT2Frrto2zXABgz1pFPs2kGWiy4oJIS+4s2NrPsJk0 VpR2VJie0fClFUk0L3/sjHVso1C7NivIshcuaUvDNIIrpuTGyRBomLEgMowdmaoIzema3uHZvQWd dydJOwa+Zw6EHy7SCNdMS3U6o9BKgBhopOf7M35kTnYFxRDIHQYOsKEV+Z5RSvP1mkQkq0iBwMtq QHIsKj6L/s58QNA5WFjgCVeyReBBBHn6rFBnGq1zocSr1AKSn6JNflnNzIgiOb1HJe5Qj06Z+VWK uMAbFJyqCBaevwz9YycrRB4ei6zv/ypFIs90RVZoaKsYjEjxFaVYfNAc2m6FM/9wRy3fxXaqNdaf ZI2VPTgpXGeOES0e0ApRi84WxVW2uFqLMVPMP8UUTOO+YCM6dGMRx6Mbk+sWxsfG43Jh0GIYmL/j EdYDrpn/WRj95oDlHwAAAP//AwBQSwMEFAAGAAgAAAAhAIbcb+fsAQAA9gMAABAACAFkb2NQcm9w cy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPLbtswELwX6D8I useUXedlrBkUDooc2saAleTMUiubqEQS5MaI+/VdSolDtz1Vp31hdjSzhJuXviv2GKJxdllOJ1VZ oNWuMXa7LB/qL2dXZRFJ2UZ1zuKyPGAsb+THD7AOzmMgg7FgCBuX5Y7IL4SIeoe9ihNuW+60LvSK OA1b4drWaLx1+rlHS2JWVRcCXwhtg82ZPwKWI+JiT/8L2jid+MXH+uCZsIQae98pQvk90ekmjaMe xLEKtSPV1aZHOb/g+jGDtdpilJ9AjAE8udBEeXldgRhDWO1UUJpYQjk/r+YgsgJ89r4zWhGrK78Z HVx0LRX3gw5FAgCRjwBrs0H9HAwdJK/IU/hqbKJyCWKMmFtQ26D8LsopD2cpbLTqcMUSyFZ1EUG8 F+AOVbJ3rQxThj0t9qjJhSKaX2zwrCx+qIhJuGW5V8EoSyxgGhuTIe58pCBrQx1jc2/MhzAfy2Mz l9NhgIPTwQQwcuDGKbthQ7xv+d/oH2SnOdmBw0g1o5OFxx1/oK5c75U9ZAatXPAuDLaxn6/tZMDP +OBrd5su6VXY02J2DU+GdhuvNHt2Prs6uYusBRs+H2zY6DfA9wLcsQmhS1v5puwWm7eZvxvp0h7H Zyyn80nF33BabzU+j+P7kr8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAAkkh4KBAQAAjgUAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABO AgAACwAAAAAAAAAAAAAAAAC6AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAfDuXOSIBAAC5 AwAAHAAAAAAAAAAAAAAAAADeBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQA BgAIAAAAIQDFq4NmJxMAAEwlAQARAAAAAAAAAAAAAAAAAEIJAAB3b3JkL2RvY3VtZW50LnhtbFBL AQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAAJgcAAB3b3JkL3RoZW1lL3Ro ZW1lMS54bWxQSwECLQAUAAYACAAAACEAqlDjDpUDAAAZCQAAEQAAAAAAAAAAAAAAAABzIwAAd29y ZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAF6AWTgIBAACsAQAAFAAAAAAAAAAAAAAAAAA3 JwAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA9wZdhV4IAAA0QAAAGgAAAAAA AAAAAAAAAABrKAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAAACEAz7rB XE4BAACBAgAAEQAAAAAAAAAAAAAAAAABMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAA ACEAWYjnddoHAABDPQAADwAAAAAAAAAAAAAAAACGMwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAG AAgAAAAhAD90CEYEAgAAtwYAABIAAAAAAAAAAAAAAAAAjTsAAHdvcmQvZm9udFRhYmxlLnhtbFBL AQItABQABgAIAAAAIQCG3G/n7AEAAPYDAAAQAAAAAAAAAAAAAAAAAME9AABkb2NQcm9wcy9hcHAu eG1sUEsFBgAAAAAMAAwACQMAAONAAAAAAA== --_004_4E1F6AAD24975D4BA5B1680429673943676F9CE4TK5EX14MBXC283r_-- From trac+jose@trac.tools.ietf.org Sun Apr 28 05:43:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84621F9959 for ; Sun, 28 Apr 2013 05:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ+c3Ym6w+bI for ; Sun, 28 Apr 2013 05:43:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id ACFD821F994B for ; Sun, 28 Apr 2013 05:43:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:37035 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWQwc-0003Io-Hm; Sun, 28 Apr 2013 14:43:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, ietf@augustcellars.com X-Trac-Project: jose Date: Sun, 28 Apr 2013 12:43:06 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/19#comment:4 Message-ID: <073.925e6229b2b03c3602ab8a24caf3827f@trac.tools.ietf.org> References: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <058.8ab7e9fb3e5c44c53a9f01ea0b317516@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130428124315.ACFD821F994B@ietfa.amsl.com> Resent-Date: Sun, 28 Apr 2013 05:43:14 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #19: JWA needs to specify an IV for use with JWE AES Key Wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 12:43:16 -0000 #19: JWA needs to specify an IV for use with JWE AES Key Wrap Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- watsonm@netflix.com | algorithms@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: json-web- | Version: algorithms | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sun Apr 28 05:46:38 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290E21F9959 for ; Sun, 28 Apr 2013 05:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxkRinGmJ53P for ; Sun, 28 Apr 2013 05:46:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3D21F9929 for ; Sun, 28 Apr 2013 05:46:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:37303 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWQzk-0005SC-PU; Sun, 28 Apr 2013 14:46:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, ietf@augustcellars.com X-Trac-Project: jose Date: Sun, 28 Apr 2013 12:46:20 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/3#comment:4 Message-ID: <069.406f09588732051659d5c305db8d2543@trac.tools.ietf.org> References: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130428124637.B8A3D21F9929@ietfa.amsl.com> Resent-Date: Sun, 28 Apr 2013 05:46:37 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #3: Concat used outside of key agreement X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 12:46:38 -0000 #3: Concat used outside of key agreement Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From James.H.Manger@team.telstra.com Sun Apr 28 06:41:34 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25221F99E9 for ; Sun, 28 Apr 2013 06:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdcMlp5996BL for ; Sun, 28 Apr 2013 06:41:33 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4718221F99E4 for ; Sun, 28 Apr 2013 06:41:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,566,1363093200"; d="scan'208";a="132423441" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 28 Apr 2013 23:41:28 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7058"; a="128274249" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 28 Apr 2013 23:41:28 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Sun, 28 Apr 2013 23:41:27 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Sun, 28 Apr 2013 23:41:25 +1000 Thread-Topic: JOSE multiple recipients Thread-Index: Ac5EFhP9yXmcpm99S7iao6bTWGvzKw== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150CD91C87@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] JOSE multiple recipients X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 13:41:34 -0000 TWlrZeKAmXMgcHJvcG9zYWwgZm9yIHN1cHBvcnRpbmcgbXVsdGlwbGUgcmVjaXBpZW50cyBieSBq b2luaW5nIG11bHRpcGxlIGJhc2U2NHVybC1lbmNvZGVkIEpPU0UgZmllbGRzIHdpdGggYSAifiIg Y2hhcmFjdGVyIGlzIGN1dGUgW2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTEw OyBzZWN0aW9uIDUuMTsgc3RlcCAxNV0uIEhvd2V2ZXIsIGl0IGlzIG5vdCB0aGUgYXBwcm9hY2gg d2Ugc2hvdWxkIHRha2UuDQoNCkpPU0UgaXMgYWJvdXQgdXNpbmcgSlNPTiwgZXhjZXB0IHdoZXJl IGJpbmFyeSBxdWFudGl0aWVzIChzdWNoIGFzIGNpcGhlcnRleHQpIHdvdWxkIGJlIHRvbyBpbmVm ZmljaWVudCBpbiBKU09OLiBEZXRhaWxzIGZvciBhbGwgcmVjaXBpZW50cyBzaG91bGQgYmUgY29t YmluZWQgaW4gYSBzaW5nbGUgSlNPTiBoZWFkZXIuDQoNClByb3Bvc2FsOiBDaGFuZ2UgSldFIHRv IGhhdmUgYSByZWNpcGllbnQgYXJyYXkuDQoNCkZvciBleGFtcGxlIChlbGlkaW5nIGJhc2U2NHVy bCBlbmNvZGluZyk6DQp7DQogICJvIjp7IC4uZGV0YWlscyBvZiBvcmlnaW5hdG9yIGtleS4uIH0s DQogICJyIjpbDQogICAgeyAuLmRldGFpbHMgb2Yga2V5IGV4Y2hhbmdlIGZvciAxc3QgcmVjaXBp ZW50Li4gfSwNCiAgICB7IC4uZGV0YWlscyBvZiBrZXkgZXhjaGFuZ2UgZm9yIDJuZCByZWNpcGll bnQuLiB9LA0KICAgIC4uLg0KICBdDQp9DQouPGJpbmFyeSBibG9iIGFzc29jaWF0ZWQgd2l0aCBv cmlnaW5hdG9yPg0KLjxiaW5hcnkgYmxvYiBhc3NvY2lhdGVkIHdpdGggMXN0IHJlY2lwaWVudD4N Ci48YmluYXJ5IGJsb2IgYXNzb2NpYXRlZCB3aXRoIDJuZCByZWNpcGllbnQ+DQouPHJlc3Qgb2Yg Sk9TRSBtZXNzYWdlPg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From James.H.Manger@team.telstra.com Sun Apr 28 06:41:34 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5861821F99E4 for ; Sun, 28 Apr 2013 06:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdm9aOMtPU7i for ; Sun, 28 Apr 2013 06:41:33 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 97DBC21F99E8 for ; Sun, 28 Apr 2013 06:41:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,566,1363093200"; d="scan'208";a="134453901" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Apr 2013 23:41:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7058"; a="130056999" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Apr 2013 23:41:31 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Sun, 28 Apr 2013 23:41:31 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Sun, 28 Apr 2013 23:41:29 +1000 Thread-Topic: AEAD and multiple recipients Thread-Index: Ac5EFhYlXV17JaaZQOqVMnV6Tpl4Xg== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150CD91C88@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] AEAD and multiple recipients X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 13:41:34 -0000 Rm9yIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTEwLCBpdCBsb29rcyBsaWtl IE1pa2UgaGFzIHBpY2tlZCAib3B0aW9uIDM6IFB1dCBhbGwgcGVyLXJlY2lwaWVudCBpbmZvIGlu dG8gb25lIGhlYWRlcjsga2VlcCB0aGlzIGhlYWRlciB1bmRlciB0aGUgQUVBRCBpbnRlZ3JpdHkg Y2hlY2s7IGhhdmUgb25lIG5vbmNlIiBbaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2pvc2UvY3VycmVudC9tc2cwMjA5My5odG1sXQ0KDQpJIHRoaW5rIHRoZXJlIGlzIGEgYmV0 dGVyIGNob2ljZS4NCg0KMS4gRGVmaW5lIGEgSk9TRSBtZXNzYWdlIGZvciBhcHBseWluZyBhbiBB RUFEIGFsZ29yaXRobS4gVGhpcyBpcyBiYXNpY2FsbHkgYSBjdXJyZW50ICJhbGciOiJkaXIiIChk aXJlY3QpIEpXRSBtZXNzYWdlLiBUaGVyZSBpcyBubyBrZXkgZXhjaGFuZ2UgaW5mby4gVGhlIEpT T04gaGVhZGVyIGlzIHRoZSBBQUQuDQoNCiAgPGhlYWRlcj4uPG5vbmNlPi48Y2lwaGVydGV4dD4N Cg0KMi4gRGVmaW5lIGEgSk9TRSBtZXNzYWdlIGZvciBrZXkgZXhjaGFuZ2UuIEhhdmUga2V5IGFn cmVlbWVudCwga2V5IHRyYW5zcG9ydCwga2V5IHdyYXBwaW5nLCBhbmQgcGFzc3dvcmQtYmFzZWQg a2V5IG9wdGlvbnMuIEEga2V5IGV4Y2hhbmdlIEpPU0UgbWVzc2FnZSBjYW4gYmUgY29uY2F0ZW5h dGVkIHdpdGggYW5vdGhlciBKT1NFIG1lc3NhZ2UgdGhhdCB1c2VzIHRoZSBleGNoYW5nZWQga2V5 IChzdWNoIGFzIGEgSk9TRSBtZXNzYWdlIGZyb20gcG9pbnQgMSkuDQoNCiAgPGhlYWRlcj4uPG9y aWdpbmF0b3I+LjxyZWNpcGllbnQgMT5bLjxyZWNpcGllbnQgMj4uLi5dLjxKT1NFIG1lc3NhZ2U+ DQoNCg0KVGhpcyBhcHByb2FjaCBrZWVwcyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBvdmVyIHRoZSBB RUFEIGFsZ29yaXRobSBwYXJhbWV0ZXJzLCB3aGljaCBqdXN0IHBvc3NpYmx5IG1pZ2h0IG1ha2Ug c29tZSBhdHRhY2tzIGhhcmRlci4NCkl0IGRvZXNu4oCZdCBsaW1pdCBKT1NFIG1lc3NhZ2VzIHRv IGEgZml4ZWQgc2V0IG9mIHJlY2lwaWVudHMga25vd24gdXAgZnJvbnQgKGJlZm9yZSBhbnkgY29u dGVudCBpcyBwcm90ZWN0ZWQpLCB3aGljaCB3b3VsZCBvdGhlcndpc2UgcHJldmVudCBhIGJ1bmNo IG9mIHVzZSBjYXNlcyBhbmQgcHJpdmFjeSBvcHRpb25zLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoN Cg0K From James.H.Manger@team.telstra.com Sun Apr 28 07:30:44 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102AA21F987E for ; Sun, 28 Apr 2013 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVCgrfWiT353 for ; Sun, 28 Apr 2013 07:30:42 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4304A21F9977 for ; Sun, 28 Apr 2013 07:30:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,566,1363093200"; d="scan'208";a="132426879" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 29 Apr 2013 00:30:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7058"; a="128277051" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 29 Apr 2013 00:30:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 29 Apr 2013 00:30:36 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Mon, 29 Apr 2013 00:30:34 +1000 Thread-Topic: "crit" (Critical) header parameter: unnecessary constraints Thread-Index: Ac5EHPH0IHQJQWrpT/W+TNqUbu9Inw== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150CD91C8D@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] "crit" (Critical) header parameter: unnecessary constraints X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 14:30:44 -0000 VGhlICJjcml0IiBoZWFkZXIgcGFyYW1ldGVyIGhhcyBiZWVuIG1hZGUgdW5uZWNlc3NhcmlseSBj b21wbGljYXRlZC4gSXQgc2hvdWxkIHNheSB0aGUgImNyaXQiIHBhcmFtZXRlciBpcyBhbiBhcnJh eSBvZiBzdHJpbmdzOyBhIEpPU0UgbWVzc2FnZSBNVVNUIGJlIHJlamVjdGVkIGlmIGFueSBvZiB0 aGUgc3RyaW5ncyBpbiB0aGUgYXJyYXkgaXMgbm90IHVuZGVyc3Rvb2QuDQoNClRoZSBjdXJyZW50 IGRlZmluaXRpb24gaW5jbHVkZXMgYWRkaXRpb25hbCBjb25zdHJhaW50czogdGhlIGFycmF5ICJN VVNUIE5PVCBpbmNsdWRlIGhlYWRlciBwYXJhbWV0ZXJzIGRlZmluZWQgYnkgdGhpcyBzcGVjaWZp Y2F0aW9uLCBkdXBsaWNhdGUgbmFtZXMsIG9yIG5hbWVzIHRoYXQgZG8gbm90IG9jY3VyIGFzIGhl YWRlciBwYXJhbWV0ZXJzIHdpdGhpbiB0aGUge0pXRXxKV1N9Ii4NCg0KVGhpcyBleHRyYSAiTVVT VCBOT1QiIGp1c3QgYWRkcyBleHRyYSB3b3JrIGZvciBpbXBsZW1lbnRhdGlvbnMuIEluc3RlYWQg b2Ygc2ltcGx5IGNoZWNraW5nIHRoYXQgZWFjaCAiY3JpdCIgc3RyaW5nIGlzIGluIGFuIGltcGxl bWVudGF0aW9u4oCZcyBoYXJkd2lyZWQgbGlzdCBvZiB1bmRlcnN0b29kIHN0cmluZ3MgKHByb2Jh Ymx5IDEgbGluZSBvZiBjb2RlIGluIG1hbnkgbGFuZ3VhZ2VzKSwgYW4gaW1wbGVtZW50YXRpb24g YWRkaXRpb25hbGx5IGhhcyB0byBjaGVjayBlYWNoICJjcml0IiBzdHJpbmcgYWdhaW5zdCBoZWFk ZXJzIGRlZmluZWQgaW4gSldFL0pXUyBzcGVjcyAod2hpY2ggdmVyc2lvbj8pLCBhbmQgY2hlY2sg Zm9yIGR1cGxpY2F0ZXMsIGFuZCBjaGVjayB0aGF0IGVhY2ggImNyaXQiIHN0cmluZyBpcyBwcmVz ZW50IGluIHRoZSBKT1NFIG1lc3NhZ2UgKGF0IHRoZSB0b3AgbGV2ZWw/KS4NCg0KSSBjYW5ub3Qg c2VlIGFueSBiZW5lZml0IGZyb20gdGhlc2UgYWRkaXRpb25hbCBjaGVja3M7IGp1c3QgYW4gZXh0 cmEgYnVyZGVuIG9uIGltcGxlbWVudGVycy4gSSBhbSBhbHNvIHN1cmUgbWFueSBpbXBsZW1lbnRh dGlvbiB3aWxsIG5vdCBib3RoZXIgZW5mb3JjaW5nIHRoZXNlIGFkZGl0aW9uYWwgY2hlY2tzLCBt YWtpbmcgdGhlbSBhbiBpbnRlcm9wIG1lc3MuDQoNCg0KImNyaXQiIHN0cmluZ3MgbmVlZCBhIHJl Z2lzdHJ5LiBXZSBzaG91bGQgcmVwbGFjZSB0aGUgInR5cCIgcmVnaXN0cnkgd2l0aCBhIHJlZ2lz dHJ5IG9mICJjcml0IiB2YWx1ZXMuICJ0eXAiIHdhcyBpbGwtZGVmaW5lZCBldmVuIGJlZm9yZSBh IHJlY2VudCBkcmFmdCBtdWRkaWVkIGl0IGZ1cnRoZXIgYnkgZGVmaW5pbmcgZGlmZmVyZW50IHZh bHVlcyBiYXNlZCBvbiB0aGUgc2VyaWFsaXphdGlvbiBiZWluZyB1c2VkIChlZyAidHlwIjoiSldF IiBhbmQgInR5cCI6IkpXRS1KUyIpLg0KDQpQLlMuIFdlIHJlYWxseSBuZWVkIHRvIHN0b3AgZGVm aW5pbmcgc28gbWFueSB0aGluZ3MgaW4gZHVwbGljYXRlIG9yIHdvcnNlIC0tIGluIEpXUyBhbmQg aW4gSldFLiBXZSByZWFsbHkgbmVlZCB0byBkZWZpbmUgYSBKT1NFIG1lc3NhZ2UuDQoNCi0tDQpK YW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Sun Apr 28 08:03:31 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2247121F9387 for ; Sun, 28 Apr 2013 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, FS_REPLICA=0.994, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0l8MDpzgjHw for ; Sun, 28 Apr 2013 08:03:30 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 71C8821F8D8E for ; Sun, 28 Apr 2013 08:03:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,566,1363093200"; d="scan'208";a="134458837" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 29 Apr 2013 01:03:28 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7058"; a="130061227" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 29 Apr 2013 01:03:28 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 29 Apr 2013 01:03:27 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Mon, 29 Apr 2013 01:03:25 +1000 Thread-Topic: JWA replicating mcgrew-aead-aes-cbc-hmac-sha2 Thread-Index: Ac5EIYicMEZT77oGS+2g3rgYBdJD9w== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150CD91C8F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] JWA replicating mcgrew-aead-aes-cbc-hmac-sha2 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 15:03:31 -0000 Sk9TRSBpcyBhdCBsYXN0IHVzaW5nIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEy LCBidXQgd2h5IGlzIHNvIG11Y2ggZHVwbGljYXRlZCBpbiBKV0EgaW5zdGVhZCBvZiByZWZlcmVu Y2VkPyBKT1NFIHNob3VsZCBoYXZlIDEgc2VudGVuY2Ugc2F5aW5nOg0KDQogIFRoZSBKT1NFICJh bGciIHN0cmluZ3MgIkExMjhDQkMtSFMyNTYiIGFuZCAiQTI1NkNCQy1IUzUxMiIgY29ycmVzcG9u ZCB0byB0aGUgQUVBRF9BRVNfMTI4X0NCQ19ITUFDX1NIQV8yNTYgYW5kIEFFQURfQUVTXzI1Nl9D QkNfSE1BQ19TSEFfNTEyIGFsZ29yaXRobXMgZGVmaW5lZCBpbiBbSS1ELm1jZ3Jldy1hZWFkLWFl cy1jYmMtaG1hYy1zaGEyXS4NCg0KVGhhdCBzaG91bGQgYmUgZW5vdWdoLiBEcm9wIHRoZSBvdGhl ciA0IHBhZ2VzIG9mIEpXQSBvbiB0aGlzLg0KDQpJZiB3ZSByZWFsbHkgaW5zaXN0IG9uIGJyZWFr aW5nIHRoZSBSRkMgNTExNiBBRUFEIG1vZGVsLCBhZGQgMSBtb3JlIHBhcmFncmFwaC4NCg0KICBJ biBbSS1ELm1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyXSB0aGUgY2lwaGVydGV4dCBpbmNs dWRlcyB0aGUgQ0JDIGluaXRpYWxpemF0aW9uIHZlY3RvciBhcyBhIHByZWZpeCBhbmQgdGhlIHRy dW5jYXRlZCBITUFDIGFzIGEgc3VmZml4LiBJbiBhIEpPU0UgdGhlc2UgdHdvIGZpZWxkcyBhcmUg c2VwYXJhdGVkIGZyb20gdGhlIGNpcGhlcnRleHQgYW5kIHRyZWF0ZWQgYXMgdGhlIEpXRSBOb25j ZSBhbmQgSldFIEF1dGhlbnRpY2F0aW9uIFRhZyByZXNwZWN0aXZlbHkuIFRoZSBKV0UgQ2lwaGVy dGV4dCBpcyB0aGUgcmVtYWluaW5nIGNpcGhlcnRleHQgKGllIG1pbnVzIHRoZSBwcmVmaXggYW5k IHN1ZmZpeCkuDQoNCg0KV2h5IGRvZXMgSldBIGR1cGxpY2F0ZSB0ZXN0IGNhc2VzIGZvciBBRVNf Q0JDX0hNQUNfU0hBMiAoQXBwZW5kaXggQykgdGhhdCB3aWxsIGJlIGluIGRyYWZ0LW1jZ3Jldy1h ZWFkLWFlcy1jYmMtaG1hYy1zaGEyPyBUaGUgdGVzdCBjYXNlcyBhcmUgbm90IGV2ZW4gSk9TRSBt ZXNzYWdlcy4gSSBob3BlIHRoaXMgaXMgYSB0ZW1wb3JhcnkgYWRkaXRpb24gcGVuZGluZyB0aGUg cHVibGljYXRpb24gb2YgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTItMDIgKHdp dGggdGhlIHRlc3QgY2FzZXMpLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From trac+jose@trac.tools.ietf.org Tue Apr 30 10:42:07 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5AD21F9A97 for ; Tue, 30 Apr 2013 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAokoHAQJOmO for ; Tue, 30 Apr 2013 10:42:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B167721F9A96 for ; Tue, 30 Apr 2013 10:42:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:50007 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXEYu-0002oj-A3; Tue, 30 Apr 2013 19:41:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com X-Trac-Project: jose Date: Tue, 30 Apr 2013 17:41:56 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/12#comment:6 Message-ID: <080.b82411f3f613cce5f0cf88c326255323@trac.tools.ietf.org> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130430174206.B167721F9A96@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 10:42:06 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 17:42:07 -0000 #12: x5c incorrect in JWE Changes (by bcampbell@pingidentity.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-jose-json- bcampbell@pingidentity.com | web-encryption@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: json-web-encryption | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: jose From Michael.Jones@microsoft.com Tue Apr 30 23:36:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DFD21F8D92 for ; Tue, 30 Apr 2013 23:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF6BBX76iffB for ; Tue, 30 Apr 2013 23:36:01 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 924A221F8D90 for ; Tue, 30 Apr 2013 23:35:59 -0700 (PDT) Received: from BN1AFFO11FD005.protection.gbl (10.58.52.203) by BN1BFFO11HUB027.protection.gbl (10.58.53.137) with Microsoft SMTP Server (TLS) id 15.0.687.1; Wed, 1 May 2013 06:35:58 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Wed, 1 May 2013 06:35:57 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.161]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 1 May 2013 06:35:56 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: JWA replicating mcgrew-aead-aes-cbc-hmac-sha2 Thread-Index: Ac5EIYicMEZT77oGS+2g3rgYBdJD9wCE4WwQ Date: Wed, 1 May 2013 06:35:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367706674@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E1150CD91C8F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150CD91C8F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(13464002)(33656001)(46406003)(74366001)(74706001)(56816002)(76482001)(54316002)(56776001)(6806003)(74662001)(23726002)(46102001)(51856001)(50466002)(54356001)(74502001)(47446002)(77982001)(79102001)(59766001)(55846006)(81542001)(16406001)(47736001)(53806001)(31966008)(50986001)(47976001)(4396001)(69226001)(49866001)(81342001)(66066001)(80022001)(65816001)(20776003)(47776003)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB027; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08331F819E Subject: Re: [jose] JWA replicating mcgrew-aead-aes-cbc-hmac-sha2 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 06:36:06 -0000 Hi James, The text was duplicated so that there would be a complete description of th= e new algorithms, including test cases for implementers, in time for the in= terim JOSE working group meeting held the last two days. Once the McGrew draft has been refactored to separate the description of th= e calculation steps (which JOSE is using) from the AEAD representation step= s (which JOSE is not using), and to include test vector values that show re= sults without performing the AEAD representation concatenations, I agree th= at we'll be able to just reference it, rather than duplicating it. (I have no objection to the McGrew draft also describing the additional AEA= D representation steps and including additional test result values that com= bine the outputs in the AEAD manner for implementations that choose to use = that encoding - indeed, I agree that there's value in doing so for some use= cases - they just need to be factored out, because they're separable from = the cryptographic algorithm itself.) Cheers, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Sunday, April 28, 2013 8:03 AM To: jose@ietf.org Subject: [jose] JWA replicating mcgrew-aead-aes-cbc-hmac-sha2 JOSE is at last using draft-mcgrew-aead-aes-cbc-hmac-sha2, but why is so mu= ch duplicated in JWA instead of referenced? JOSE should have 1 sentence say= ing: The JOSE "alg" strings "A128CBC-HS256" and "A256CBC-HS512" correspond to = the AEAD_AES_128_CBC_HMAC_SHA_256 and AEAD_AES_256_CBC_HMAC_SHA_512 algorit= hms defined in [I-D.mcgrew-aead-aes-cbc-hmac-sha2]. That should be enough. Drop the other 4 pages of JWA on this. If we really insist on breaking the RFC 5116 AEAD model, add 1 more paragra= ph. In [I-D.mcgrew-aead-aes-cbc-hmac-sha2] the ciphertext includes the CBC in= itialization vector as a prefix and the truncated HMAC as a suffix. In a JO= SE these two fields are separated from the ciphertext and treated as the JW= E Nonce and JWE Authentication Tag respectively. The JWE Ciphertext is the = remaining ciphertext (ie minus the prefix and suffix). Why does JWA duplicate test cases for AES_CBC_HMAC_SHA2 (Appendix C) that w= ill be in draft-mcgrew-aead-aes-cbc-hmac-sha2? The test cases are not even = JOSE messages. I hope this is a temporary addition pending the publication = of draft-mcgrew-aead-aes-cbc-hmac-sha2-02 (with the test cases). -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose